2010年2月24日水曜日

Rails 3.0 beta をインストールしてみた

gemいろいろ

sudo gem install tzinfo builder memcache-client \
     rack rack-test rack-mount erubis mail \
     text-format thor bundler i18n
sudo gem install rack-mount -v=0.4.0
sudo gem install rails --pre
sudo gem cleanup bundler

bundlerの古いバージョンが入っているとcleanupしろという警告が出ます。

ブログ作ってみる

途中だけど、1.8.7と1.9.1では動きました

rails blog
cd blog
bundle install
rails g scaffold article title:string body:text #2ではscript/generateだった
rake db:migrate
rails s #2ではscript/serverだった

動きました。てか、1.9系を使ったというのもあってか、速くなってるって分かります。まだbetaなので今すぐ何かに使おうとは思いませんが、安定板がリリースされたらプラグインの対応状況を見つつ、Rails3やってみようかなと思います。ローカルではどんどん開発していきたいけど、仕事でも使うと考えるとまだ2.3系をしっかりマスターしとかないといけない。

2010年2月23日火曜日

オフショア〜!

賃金が日本一安いと噂の県で働いています

なんだか、東京に比べて人件費が安いからということで、東京で仕事とってこっちで開発ってことを考えてる(実際やってる)人?会社?がありますが。全然勝てる気感がねーなーと思ってたんです。なんでかなと思ってたら分かりました。オフショア開発ですね。案の定、東京進出に失敗してる会社がちらほらとありますね。たぶん技術や経験値を見てもオフショアできるところの方がこっちの名の知れてない会社よりかは全然上でしょうね。安易に人件費を低くしたってデフレしかおきねーよ!賃金上げて><(切実) これは僕の言葉じゃありません(笑)

まー給料安いといい人材は集まらないし、いい人材に育ってもどこかに流れちゃうでしょう。

どうなんですか、オフショア

自分が経営者で英語、中国語が堪能だったらオフショアやっちゃうかも。でも、エンジニアだから、ウォーターフォールみたいな感じで下請けとか孫請けとかなってるとつまらないと思うだろうし、そういう面は日本より明らかにドライな人たちが多いだろうから、ある程度アジャイルの要素も入れないと人材流動がすごそうだ。

オフショアよりグローバルなSOHOがいいんじゃね

僕はデザインが苦手というか、よくツールの使い方も分からないし、あまりセンスもないので、デザインは外注にしたいなーとか、ロゴデザインとか他人に任せたいと思うんです。で、そこで対日本人よりも、よその国の方がおそらく今は安くで働いてくれるんだろうから、SOHOのもっとグローバル化してしまえば、個人や集団とがそれぞれやり取りして仕事しちゃうんじゃないかと思ってます。企業はでかいことをやりつつ、個人事業や5人に満たない企業で回るんじゃないかと。お給料はPayPalで払いますみたいな感じだと税関系とかどうなんだろ?

危機感を持ちつつ抜け道を探す

テクノロジーのいいところか悪いところか知らないけど、プログラマーって基本的に何かを効率化させるわけで、その効率化によってそれまでそれを仕事としていた人たちの職を奪う仕事をしてるわけですが。だからといってプログラマーは永遠かというと、日本の工場が中国に移ったように、プログラマーの仕事も分業化されて日本SIerが要件定義や設計をして、インドや中国に開発を発注するという感じになる流れは普通なんだと思います。アメリカもインドに支えられてるし。

今は日本で特に専門の資格も持たずにプログラマーの職業につけたり起業できます。オフショアのせいでそれがすぐに厳しくなるとは思わないのですが、今までよりは厳しい現状に立たされるんだろうとは思います。それよりも深刻なのは既に受託開発を収入源にしてる起業でかつ大半が日本人というところ。たぶん日本人よりインドや中国の方がハングリー精神は旺盛だろうし、過酷な競争をサバイバルしてきた人たちがたくさんらしい(インドは1000万人のSEがいる)。しかも専門の教育を受けているとあれば、大抵の日本人プログラマはかなわないのかなー。どうなんでしょう。僕は勝てる気配はなさそうですが、でも大学とか出てる人とか中学生や高校生の頃からプログラミング三昧な人たちはいけるだろう!と思います。でも、きっとそういう人たちが日本には不足してるんでしょうね。むしろあっちがそういう人たちばかりなのかな。

ん、これはまとめられない気配... 仕事って、一つは依頼主ができないことを代りにやってその手間賃をいただくってのがあると思います。だとすれば、コストがそれなりに納得のいく範囲であれば、オフショアのデメリットよりも、身近でなんとなく信頼の置ける人に依頼するんじゃないかと思います。とはいっても、安くて安心ならそっちに金が動いちゃいますね〜。

ん〜、やはりこれからは個人の時代だなー。あれーまとめられない。個人というか、仕事を作れる人間が仕事をする時代が来てるんじゃないかと思う。大学出ないとまともに就職できないって、不況が理由なんじゃなくて、効率化が招いた部分もあるんじゃないかな。パソコンのスペックが良くなるほど、それを使う人がこなす仕事が増えるって言うから、自分がこなす仕事が増えた分他人から仕事を奪ってるとか奪われてると考えてみたら分かる。これからのPGやSEやPMは営業やプロデュース能力がないと厳しいってことですね!おわり!

2010年2月19日金曜日

Gitでバージョン管理してCakePHPを使う SVNも同様

開発環境に依存するファイルはバージョン管理に含んではならぬ!

いきなり余談でごめんなさい。この記事の一つ前の記事が釣りなんですが、ちょっとアクセスが多くて焦りましたw

本題ですが、例えばtmpフォルダ内のキャッシュなどの一時的なファイル(ログとかも)、config内の開発環境に依存するもの(開発環境によって設定を変えるもの)はバージョン管理に含みません。変更して間違ってコミットしたら、他の人の環境にも反映されて動かなくなっちゃうっていうトラブルが発生するからです。

無視して別名ファイルを用意する

キャッシュ系は別名ファイルは要りません。Gitの場合は空ディレクトリはバージョン管理の対象にできないので、emptyとかいうてきとうな名前の空ファイルを置けばいいです。.gitignoreで管理するのがいいと思います。

設定ファイルは別名ファイルを用意しておきます。例えばdatabase.phpをdatabase.php.sampleにしておいて、実際に開発する時にdatabase.phpというファイルにコピーして使います。database.phpは.gitignoreでバージョン管理対象外として指定されていることが前提です。core.phpもお忘れなく!

OS依存のものはグローバルに無視するようにする

Thumbs.dbとか.DS_Storeなどは、バージョン管理に含めないのはもちろんですが、各リポジトリの.gitignoreに書くよりも、各ユーザの.gitignoreに書いておく方が良いと思います。とは言っても、Thumbs.dbをコミットしそうな人がいる場合は、早めにリポジトリの.gitignoreに書いてコミットして先手を打っておいた方がいいかもしれませんねw

いい感じの.gitignoreが出来たら晒します

近々自分でもCakePHPを使う案件用に.gitignoreを用意しとこうと思うので、それが出来たらgistで晒します。この記事にも貼付けようと思います。あ、誰かが先にやってたら、そこにリンクを張ろう♪

2010年2月17日水曜日

GitとCakePHPとRedmineでスーパーアジャイルな開発!!

釣りです

今職場実習生が来てるので、CakePHPで社内ツールのプロトタイプを作成してもらってます。

実習生の実力はというと、VB.NETとC#をやっていたということでオブジェクト指向OK!でも3年間のブランクありという僕より10歳くらい上の淑やかな女性です。

なぜいきなりGit?CakePHP?Redmine?

理由は至ってシンプルです。実習が終わった後に実習生が「何をしたかが言葉以外の情報でも見えるようにしたかったから」。どういうコードを書いたのかを知っておかないと、社内ツールとして採用された場合にメンテナンスをどうするかっていうことを考えれば、期間が短くてもやっておいて損はないと思います。そんなのやってる時間がねーよ!って会社ほどやるべきですね。でないとノウハウが貯まらない会社になってしまって、人が辞めるとそこでいろんなことが終わっちゃいますから。

RedmineとGitを採用しているのは会社に既に導入しているのと、Gitの方は導入実験も兼ねてですが、ブランチ開発をしてもらって、変更が追いやすい良質なコミットをしてもらうことと、一部CI的な要素も含んでます。CIについてはまだやらないので、良いコミットの仕方について何度か説明することになると思います。

CakePHPを採用した理由は、構造が分かっていればコードを追いやすいことと、CakePHPのルールに従って書いていれば、独特なコードがあまり生まれないということからです。社内ツールとして採用されれば、社内の人間がメンテナンスする日がくると思いますし、おそらく機能追加は必須です。そういった場合に、まずどういった作りになってるか調べて...という作業をせず、規約に沿っていることを前提に進める方が効率がいいと思います。また実習生に自社の独自のフレームワークについて教える場合は資料が必要ですが、CakePHPの場合はググって下さいと言えばOKです。ですが、ググっても分かりませんでしたと言われた時に、その問題を解決する手段を提示できることは大事です。

実はA4のしかも文字が羅列されてるだけのプロジェクトの概要と、目的、背景、目標と機能一覧みたいなものを描いた紙しか渡してません。口頭での説明もしましたが、自分で設計して実装して下さいと伝えました。なので実装の仕方は自由ですから、CakePHPを使うということを半強制的におしつけましたw

手書きの設計書からいきなりbake!

This is agile. とにかく動くものに仕上げてレビューをして、目的に合った使いやすいものにどんどん仕上げていくというポリシーで、画面設計に必要な項目を出してもらい、あとシステム上必要な項目を洗い出せば、画面設計とDB設計は完成です。もし詳しいドキュメントが欲しいとなれば、開発が終わった後にまとめる感じです。

アジャイルって設計書とかのドキュメント書かないんじゃないの?と思う人もいるかもしれませんが、そうではなく、最初にどういったもの作るかという使う側と作る側のコンセンサスを得るのは大事です。途中で大きな変更があってもプロジェクトが快活に進むなんてどんな開発手法であれほぼありえません。スコープをある程度明確にしておくことはアジャイルでも大事だと思います。

手書きが個人的に好きなのには理由があります。変更しやすいのと、誰でも鉛筆さえ持てば書き込めるからです。鳥頭なので会議の内容なんてすぐに忘れるので、紙に重要な点だけ書いておくというのは大事です。画面項目とその配置とかって、実際に絵にしてイメージを共有した方が早いし、資料として残るので後で整理しやすいです。画面を書いて、画面遷移も書きたくなってとなれば、手書きの方が絶対早い。お客さんも参加しやすいはずです。見やすいようにまとめるという作業はとにかく後回しにして、要点だけを抑えて、すぐに実装できるように持って行くことが大事だと思います。要求分析や業務分析や要件定義もこの中で全部やってしまって気づいたことはメモしときます。

必要な項目が分かって、項目の型も分かればテーブルを作って必要に応じてbakeします。もしくは、まだ項目に自信がもてない場合は自動のscaffoldを使って、使う側に項目の確認を実際に使ってみてもらって判断してもらえばいいかと思います。OKが出ればbakeして仕上げの作業に入ります。動くもののレビューをしては開発を進めるというイテレーションの繰り返しですね。社内の人間とは基本的に業務時間内であればいつでもコミュニケーションが取れるので、社内での開発はアジャイルが向いていると思います。

何かを達成して実習を終えてほしい

実は教わる側より教える側の方が学ぶ事が多いと思います。そして今回は社内ツール開発なので外目には触れません。じゃあ実習生は損ばかりかというと、経験が積めるからいいじゃないか!という話になると思うのですが、じゃあその経験の質をどうするかと考えると、本人が無意識に定めている以上の限界をこちらで設けて、それを達成できるよう持って行くのがいいんじゃないかと思っています。上から目線の生意気なクソガキが!とこれ見たら思われるかもしれないけどw

もう二日目にして、チケット駆動開発、DVCS、フレームワーク、ユニットテストと、その方が知らなかったワードがいっぱい出てきています。本人が大丈夫かなー?という心配に少しかられている様子です。教える側としても「順序組が下手でごめんなさい」とか思いますが、いずれ出てきたワードがいずれ芽吹いていくんじゃないかと思います。開発を進めるにあたって、どれも実際にやっていくので、その中のどれかがその方の未来で役に立つものがあれば嬉しいです。

成長できた気がします!とか本人が自覚している上でそう言われる、これに勝る喜びはないです。

my issues

うまく達成してもらうためには、教える側が指導の仕方を時間の合間をぬって工夫していかなきゃいけないところですが、今のところ全敗な気がするので、ちゃんとうまく説明できる人間になろうと思います。これをやってくれ、あれをやってくれは時間をかければある程度は説明ができるんですが、指示以外の部分でどう動くかという、動きが見えない部分の洞察力も必要だなーと感じます。将来部下を持った時に、その洞察力がないと、報連相がうまくいかない時に、それが開発効率のボトルネックになるのは防がないといけないと思うので。迷いは開発を鈍らせるので、迷いが発生する時にどうするかを見てみたいなとも。迷ったら聞きにきてという指示はもちろんありだと思うし言いますが、言ったからといって毎回そういう行動は取らないし、相手の事を考えて忙しいから聞くのを後にしようとか思うものだと思うので、何かうまいやり方というのがないのかなーと思います。100%は無理だし過干渉は良くないので、あれ?(妙に変だなー 某ラジオ番組出典)とすぐに気づけるぐらいになりたいです。上司の仕事の一つは、自分がいなくても仕事がまわるようにするだと思うので、latent observer パターン的上司を目指します!(笑)

2010年2月16日火曜日

PHPでDependency Injection Container

依存注入

英語だけど、DIとは何かとDIコンテナをどう実装するかについて分かりやすくまとめてるサイトを発見!!てかSymfony関連サイト?Dependency Injection Reinventing how you manage PHP classes

セッションDI

セッションの場合は、PHPのビルドインセッションモジュールか、DB使うか、memcachedを使うか(レンサバは厳しい)と方法があるので、インタフェースで各クラス間のメソッドと振る舞いを共通化するようにしといて、簡単に乗り換えができるようにするというのは極自然に理解できますね。でも必要に迫られない限りはやらなくてもいい部類です。GoFのデザパタには入ってないと思うけど、広い意味でのデザインパターン(MVCなども含む)って必要に迫られない限りはやらない方が賢明だと思います。

別件で

依存注入は普通にやるし、こういうのやりだしたらインターフェースとか抽象クラス使ったりとなりますが、ログを取るクラスの場合ってどう実装すればいいんだろ。グループウェアの活動履歴みたいなのを、クラス単位で取りたい場合って、それぞれのクラスにログクラスのインスタンスを注入すんのかな?? PHPだとそれが限界でしょうか。もう少し調べてみよう。できれば、各クラスはログのことを全く意識しないでいいような作りにしたいし。継承もせずに。というか単一継承なので途中でLoggableみたいな継承を入れると、それ以降のサブクラスも全部影響受けるから避けたいです。

2010年2月13日土曜日

アジャイルって契約どうすんの?

釣られちゃおう

アジャイルって受託開発との相性が最悪な気がする。んー受託というか、大規模開発には向かないのかもしれない、と薄々感じてます。

薄々というのは、まだアジャイル開発を実際に仕事でやったことがないからで実際なんとも言えないんだけど...

アジャイルは客を選ぶ

どういうものが欲しいかがある程度明確なお客さんじゃないと厳しいという意見を聞いた事があります。で、実際そうだと思います。というのも、要件やそもそもの目的を認識してないお客さん相手だと、ゴールを定めにくいから、アジャイルでやろうとしても、変更が激しくでどんでん返しもあり得そうで、怖いんじゃないかと思います。

イテレーションを繰り返す中でお客さんにレビューをしてもらって、じゃあそれを完成させるのに、あと一日かかりますと言うとして、それが契約日外に達する場合、まー通常だと1人日3〜5万として、あと3万下さいって言うようなもんで、チキンな僕にはそういうこと言えるのか??とか、もっと優秀なプログラマーなら2時間で終わるんじゃないか??とかいう自信のなさもあって、言えないんじゃないかと思ってしまいます。個人事業主でやってたら一日2万くらいが限度でしょう。だって税金収めるってなったら1人日2万以上はないと、いつ職に溢れるか分からないし

契約と開発人数?

今いる会社だと、開発を外注にまるなげするようなことはせずに自前でやっちゃうという態勢の方が絶対いいと感じるんですが、でも人数がきつきつなので、ドキュメントドリブンじゃちょっと割に合わないというのは感じます。

作成するもののうち成果物として先方に収めるものが出ると思うのですが、そのうち何を収めなければならないかは、契約で決まってくると思います。例えば受託開発でも製品の著作権が先方にあれば結構綿密な設計書を先方に成果物として収めるのが筋だろうし、逆に著作権がこちらの場合、収めなくてもいいとは思うけど、そういう場合は運用や保守はこちらでやるというケースがあるので、運用手順書やらは自社ないでちゃんと作成しとく必要はあると思います。人に依存させると会社としてのノウハウが貯まらないから。

Railsの本のイテレーション開発のサンプルを見てると、とりあえず契約なんかの話は置いといて、お客さんと先に概要の打ち合わせをして、だいたいやる事が決まって、画面遷移なんかを手書きで書いてイメージを共有してから、イテレーション開発に入るという感じです。

これはフリーでやってる人はそれで問題ないかもしれないけど、会社の場合は、開発に入る前の契約と、後のドキュメント生成のところが気になるはずです。Rubyの場合は僕はYardでドキュメント(JavaDocみたいなの)は作ってしまって、あとは運用マニュアルとかは、製品が出来た後から作るか、お客さんと一緒に開発してるんだし、お客さんの方で作ってもらうというのもありだと思います。問題はそのプロジェクトのスコープと役割分担であって、どっちが何をするかをはっきり決めておけば、アジャイルでも別に問題はないんじゃないかという点です。

個人的なアジャイルのイメージはウォーターフォールをV字型にして、内部設計からユニットテストから統合テストあたりをグルグル回すというのがあります。その外枠の要件定義や外部設計、それの対象にあたる成果物の承認なんかは、アジャイル開発の外でやって、うまくいったら終わり、まだ開発が必要なら再度契約という感じになるんじゃないかなーと思います。そこでお客さんが納得できるかどうかは分からないから、客を選ぶとか、プロジェクトの性格に依存するんだろうなと思いますが、設計書なしに何十人ものプログラマーを動かすってそうとう難しいと思うので、少人数態勢で開発にあたれないなら、アジャイルは不向きなのかもしれません。でも、どっちみち社内での開発の一部のプロセスをアジャイル化はできると思います。納品物に含まれる設計書のうち、誰も必要としないような細かい設計書を作っても意味がないので、そんなの作るより、動くものを作ってしまおうと考えるのは普通のような気がします。

やっぱり中庸!バランス感覚!

契約がうまく取れれば、半ウォーターフォール半アジャイルで進めるのがいいのかなと思います。どんな開発手法にしろ、いいものをできるだけ速く最良の品質で顧客満足度を満たし費用対効果を最大限に得られるものが、理想の目的であると思うので、それを達成するためにはどうするかを毎度考えることになると思います。「これ!」という答えがない分野でしょうしね。

開発メンバーも選ばれるかも

アジャイルは客を選ぶというけれど、開発メンバーもそれなりに腕のあるプログラマーじゃないと勤まらない気が薄々してます。だって変更を受け入れるというのもあるし、お客さんが言う要件を分析して実装するという要素もあるし、ということはそれなりの知識経験、そしてそれをひっくるめたセンス(テイスト)が問われるということですよね... 個人プレーならいいけど、組織のためにノウハウを残すとかなると... うー、頑張ります><

2010年2月10日水曜日

ホンモノになりたい

Professional

プロでもないくせにプロを語る輩が多い。

仕事でする以上はプロだ!という精神論でしか言わない人も同様に多いと思いますが。本物になりたい。Web系エンジニアの本物って何かというと結構いろいろあって難しいですね。

探究心

プロになる条件はいろいろあると思います。費用対効果、プロジェクト管理、プロジェクト管理の中でもリスク管理、契約管理、スコープ...その他もろもろができること。でも最終的に大事なのは目的(目標)をできるだけ短期間で達成すること。そのためには何をするか、それが一番大事。その要をきちっとやれるのがプロなんだなと思います。

仕様書にしろ設計書にしろ、システム構成図、グランドデザイン、納品物といろいろ作るものは多いかもしれないけど、結局それは何を達成したいがためで誰のためで何を解決するかというのが根本にあるんだと思います。根本を解決するための逆算こそが仕事に求められている気がします。

悔しいけれどアマグラマーな自分

プログラマーの中にアマグラマー(かアマグラマーに毛が生えた程度の人)が蔓延っていると思います。悔しいけれど自分もその一人だと自覚せざるを得ません。SEとPGを分けるのが日本流っぽいですが、関係ありません。仕事としていただいた以上はちゃんとやり遂げないと。そのためにはレンタルサーバありきとか、レンタルサーバに毛が生えた程度のシステム構成でプログラマーなんて名乗れませんね>< マスタースレーブだの、データキャッシュ、メンキャッシュ、ハッシュDB、ロードバランサー、ルータによるセグメント分け、ファイヤウォール、ウイルスチェックといろいろ考慮することがあります。

要件の分析、要件から推測されるシステムの構成の費用別パターンの割り出し、システム構成に依存したアプリ設計などなど。やること覚えること山積みというのが分かってきました。

そしてプログラムの著作権や瑕疵担保責任などなど契約管理とか。そういうのをほぼ一通り知って経験して本物になれるんだなと思います。

レンタルサーバに毛が生えた程度で終わってもいい場合もあると思います。それでも僕はそれが自分のできることの範囲にと決めず、ちゃんとお客様の要望を効率よく実現できるエンジニアになりたいなと思った今日この頃でした。もっといろんなことをちゃんと知って自分をスケールアウトしたい。

久々に今日は独り言というラベルをつけたいけど、ラベルなしで行こう。あ、メモで。

追記: コメントありがとうございます

こういう同業者にも、そうでない人にも煙たがられそうな、嫌われそうな記事にコメントしてもらえると、向き合ってもらえている感じがして、とてもありがたいです。お金をもらった時点でプロというのも、そういう捉え方もありだと思っています。というかそうでないといけないんだなという感じです。じゃあ、それをプロしたなら、この記事で書いているプロってなんなのか?となると、要するにプロの中でも一流かどうかなのかだと思います。表現の違いにせよ、プロの中でも一流な人や一流を目指している人にはプロを感じます。プロを哲学していて、それを体現しようとしてる人や一部を体現している人。僕はそういう人にプロというものを感じます。そして所詮三流止まりでも、プロを目指したいと思います。

2010年2月9日火曜日

フレームワークが作りたくなってきた

PHPでmixinができるって知らなかったの

というか知ろうともしてませんでした。危ない傾向ですね。プログラマーとしてプログラミング言語を知りたがろうとしないのはかなり危険な状態だと思います。いかんいかん...

きっかけはCakePHP

CakePHPは機能が豊富で助かります。豊富な分、ソースを追えません。僕の力量では無理です。気力的に。

でも大事なことを学びました。PHPイケてんじゃん(※但しイケ鯖に限る)。

ActsasはRailsにもあるけど、CakePHPで見てみて、「へーこんなことできるんだ!どうやってやるだろう?」と久々にPHPに興味が湧きました。あとCakePHPをやるにつれ不明な点が出てきて他人に訊く前にソースリーディングをしてみたのですが、それがいろいろ勉強になりました。やっぱり他人様のソースを読むというのは大事ですね。面白いです。(辛いけど)

ルーティングと構造とMixinとJavaScriptの軽いラッパー的なものがあればそれでいい

フレームワークにいろいろ求めるときりがないですが、CakePHPはよくできてる分、違うアプローチには対応しにくいように思えます。効率的なところは効率的!でも、それをやるためにあるソースが多すぎてちょっと困る。

フレームワークって、結局は「自作したい」ってなるものかなと思います。あれもいい、これもいい、でもあれが足りない、これが足りない、あれが違う、これが違うで、模索するうちに、理想の形が見えてきて自分で作ってみようかなと。そして泥沼にハマって...(ネガティブ)

しかし、なんとなく自分が求めてるものが分かってきました。とくにPHPでは、SQLは直書きでも問題がないケースばかりだし、その方が速いし、逆にバリデーションをモデルから分離してmixinさせたいし、JavaScriptと連動させたい。万人向けでなくても、そういうコアだけどありがちな用途で使える貧乏フレームワークを作ってみたいなーと。dispatcherでルーティングとディレクトリ構造とを決めて、あとは必要なところは規約か設定ファイルに依存させてしまえばいいのかなと思います。

作るかどうか分からないけど、作るならPHP5.3以上でやろうと思います。作らなくても、CakePHPから学んだ事をどんどん活かして行きたいと思います。コードジェネレータ的なものは欲しいよね。HTTPサーバもPHPでできると最高なんだけど... まー、まずはPHPでmixinからです!

2010年2月8日月曜日

JavaScriptでプライベート変数

コツはthisを書かないこと

隠蔽というかカプセル化もオブジェクト指向の醍醐味の一つだと思っていますが、JavaScriptでは言語がプライベート変数のようなものはサポートしていません。ですが、クロージャをうまく使えばできるのです!

var f = function(){
  var _private_var = '';
  return {
    getter:function(){ return _private_var; },
    setter: function(string){ _private_var = String(string); return this; }  
  };
};

return this;が好みです

上記の例ではシンプルにゲッターとセッターだけ実装してます。セッターの場合は何もreturnしなくてもいいんですが、return thisをしとけばメソッドチェーン(カスケード?)ができるので好きです。表現力が増しますし、複数の処理を一つにまとめてしまうことを回避できる場合があります。

Rails3がベータリリース

期待感が高まってきました!

公式ブログに「Rails 3.0: Beta release」という記事があがっています。インストールの仕方も載っています。

個人的にRailsで遊んでいて、merbに手を出してから少し経った後に、この(当時)Rubyの二大フレームワークが統合されるというアナウンスが出ました。それから約一年経った頃から、矢吹田猫(wycats)さんがいろいろブログに書き始めました。Rails3とSinatraを同時に使う方法とか。

Rails3はパフォーマンスの改善、XSSの強化、フルスタックからモジューラ?に変わってます。ActiveRecordからActiveModelにバリデーションが分離されたのもかなりいいと思っています。prototypeからjQueryにデフォルトが変ったのか、それともjQueryに簡単に置き換えられるようになったかRailsの最新版を落として試したけど確認できてませんが、jQueryのことが気になりますw

コマンド周りも変わっていて、script/serverだったのがrails serverになるなど、さらにシンプルで分かりやすくなっていますね!残念なことにドキュメント生成ツールにyardがまだ採用されていませんが、いずれはされるんじゃないかと思います。あとはPHP文化みたいにドキュメントを異常なほどに多国語でそろえてほしいなーw

Rails3はHTML5を使うことを想定してるみたいで、DOCTYPEがHTML5のものになってますね。で、JavaScriptで必要なDOM属性をdata-*を使ってのをDHHが言ってたけどどうなるのかな。個人的にはRailsに限らず、業務系アプリはHTML5を使ってdata属性を使おうかと思ってます。(IE対応だと厳しいのかも?)

Sinatra1.0もリリース間近

これも何気にすごい。RubyがDSLパターンに強いのを活かしたWeb用フレームワークで単純なウェブアプリはこれで作っちゃえばいいんじゃないかと思います。英語圏の方ではSinatra Bookを作ろうと頑張っていて、アプリを作りながら進めているようです。今年はRubyで面白いサイトを作ろう!!

2010年2月7日日曜日

SubversionからGitへ移行した理由とこれから

その前に、Macユーザ諸君!

GitのGUIで何かいいのないかなーと探しているあなたに、GitXをおすすめします。ログの閲覧だけかと思いきや、ステージとコミット、ブランチ切りががGUI上でできます。コマンドからの呼び出しもできるので、CUIとGUIの両方の架け橋を綺麗な画面でやってくれる便利君です。GitはGUIがないからなーとか、gitkの画面に絶望したあなたにおすすめです。何ができるかまとめようと思ったんですが、公式サイトに書いてあるので(See it参照 Screencasts=動画もあります)見てみて下さい。ソフトの方はOSSなので、時間を見つけて日本語化の作業をしてpull requestしてみたいと思います。

Windowsユーザの方はTortoiseGitがいいんじゃないでしょうか。

Subversion否定派ではありません

推進派でもないけれど、最初に断っておかないと。SVNは現在も使ってますし、フックスクリプトを書いたり、コマンドを組み合わせて遊んだりしてるので、それなりに使っている方だと思います。中央管理型なので、分散管理型よりも使いどころがあるところはあります。

理由1) リポジトリの作成と複製が簡単

Subversionはまず個人向けではないという気がしています。リポジトリを作るのにadminという他のコマンド系が存在し、リポジトリはチェックアウトして作業用ディレクトリを作らないと使えません。そしてチェックアウトした方の全ディレクトリに.svnというディレクトリが作られます。これはディレクトリをそのままコピーした時に副作用を起こすので扱いに注意が必要です。.svnのアクセス制限を忘れてapache上からリポジトリの中身を見れるという事態も招きます。一方GitやMercruial(以下hg)、Bazaar(以下bzr)は.git .hg .bzrというディレクトリをトップにだけ置くので管理体制がシンプルです。リポジトリの作成は作成したいディレクトリでinitするくらいです。このサクサクやれるのが個人的に好きです。

無責任な話ですが、分散管理の場合、最悪リポジトリサーバがお亡くなりになられても、チームがcloneしているリポジトリから復旧できます。無責任な話と言え、ぶっちゃけ!、社内サーバの管理は徹底してない会社がほとんどじゃないでしょうかw

理由2) ブランチ開発が簡単

SVNでブランチ開発をやったことがないのであれですが、そもそもあまりやろうと思う程にまで便利でないような気がしています。Gitの場合、ブランチを作るのが簡単で、ブランチ用にディレクトリを作る必要はありません。ブランチを切り替えればその状態にファイルを自動で入れ替えてくれます。

Gitでは基本的にmasterは統合ブランチです。統合ブランチの細かい説明は省きますが、要するにいつでもお客さんに見せていい状態であったり、最新版(ただし安定板とは別)という位置づけです。バグ修正や機能追加はトピックブランチを立てそちらで作業を行いテストにパスしたら統合ブランチにマージします。この流れが普通なので、Gitでは簡単にできるようになっています。ブランチで機能追加中に見つけてしまったバグの対応、割り込みの対応、そういったこともGitでは難なく対応できます。

バージョン管理の副作用

バージョン管理というよりも、チーム間でのソースコードの共有という点で問題になるケースがあります。リリースが何回かに分けてされるものは、リリース間近になるとある時点から後に追加される機能は取り込まずに(影響を受けたくないから)、バグ修正に徹底したい時期がくると思います。ここで新機能についてはコミットを中止させておくというのは避け、リリースブランチ(統合ブランチの一つ)を設け、masterブランチ(SVNではtrunk)に新機能、リリースブランチではリリースに特化した作業(バグ修正など)を行います。

SubversionでもGitでも共有するリポジトリにリリースブランチを作ることはしますが、Gitの場合はローカルにだけブランチを作ることが可能なので柔軟に対応できます。(hg、bzrも同様)

Gitに限らず気をつけておくこと

コミットはクリーンでクリアなものでなければなりません。バグ修正と機能の実装が同じコミットに入っていると、他の開発者がバグ修正だけほしい(pullまたはcherry-pickしたい)のに、必要ない機能まで取って来てしまいます。とりあえず何をやっただけ記録するものという運用のやり方では、チーム開発の場合だと限界がやってくると思います。Gitではコミットの前にステージというステップを踏むので、SVNほどシンプルではありませんが、逆にそれが良いコミットができるよう助けてくれます。Gitのコミットの仕方については別の機会に触れます。

SVNからGitへ移行しようと考えている方へ

SVNよりもGitは覚えなければならないことが多いです。SVNとは違い、分散管理は自分自身でリポジトリを管理する能力が必要になるからです。How-to的にまとめておくことが親切ですが、概念もしっかり覚えてもらわないとリポジトリが乱れます。ただし覚えてしまうと開発効率はグンと上がると思います。

それからリポジトリ管理を自分ですることに不安がある方は大丈夫です。やり方はありますが、基本的にgitはあなたがgitにさせたことを全て記録しています。これはコミットだけではなく、resetなどの取り消しも含まれます。間違って取り消してしまっても、実は復旧できるのです!最初のうちは救われますよw というか復旧の仕方をまず最初に知るべきです。これもまた別の機会に。

ちなみに、gitはgit-svnがあるので、gitを使いながら、svnリポジトリにアクセスすることができます。

これから

今年の案件のうち、カスタマイズ用リリースブランチを作る必要があるであろう案件があります。契約がまだ曖昧なのでどうなるか分からないのと、明確になるのかさえ定かでないので、手間ですがカスタマイズ用のリリースブランチ、もしくはリポジトリを作成して作って行く予定です。カスタマイズ用のリリースブランチにするかリポジトリにするか、または別の手段でいくか、いい方法が見つかり実績ができたら、そのことについてまとめたいと思います。

2010年2月4日木曜日

PHPで関数の引数の順番を忘れたら

しかもphp.netを開くのがめんどいというあなた!

php -hをご覧あれ

  --rf <name>      Show information about function <name>.
  --rc <name>      Show information about class <name>.
  --re <name>      Show information about extension <name>.
  --ri <name>      Show configuration for extension <name>.

そうです。php --rf (関数名)でターミナル上から確認できるんです。便利ですね!

PHP 妥当性チェックとかで楽がしたくて。。。

is_numeric & over zero

PHPではfalse null 0 '0'が==演算子だと同じなので、厳密にチェックしたい時は===を使いますが、数値の0と文字列の0は違うものとして扱われるので、データベースのint型で(特に1か0のフラグ系)、is_numeric関数と不等号で確認しますよね? それが何個もあるとif文が長くなるので、こういう関数を作っちゃいますw

is_numeric_over_zero(){
  foreach(func_get_args() as $v) { if(!is_numeric($v) || $v < 1){ return false; } }
  return true;
}
is_numeric_over_zero(1,2,3); # true
is_numeric_over_zero(0,1,2); # false

可変引数にしておくと便利で、ifの条件のところが長ったらしくなるのを防げます。もう少し短い名前の関数にした方がいいけどね!

return ( comparison );

三項演算を知ってるとそれ止まりというか、あまり見かけないのでやる人が少ないからあえて書いてみます。

//引数1が0以上であればtrue そうでない場合はfalseを返す関数の例
//三項演算の場合
function is_over_zero($numeric) { return ($numeric > 0) ? true : false; }
//こう書ける
function is_over_zero($numeric){ return ($numeric > 0); }
//郵便番号の例
function is_jp_zipcode($zipcode) { return (preg_match('/^\d{3}-\d{4}$/', $zipcode) > 0); }

比較演算子が返す値を知ってれば思いつくやり方です。僕はタイピングは遅い方じゃないと思いますが、なるべくコードを書かずして同等かそれ以上の成果を得られるよう心がけています。そしてコードが簡潔で意図を明確に表現するように頑張ってます><。Program Intently and Expressively(PIEの原則)とKeep It Simple, Stupid(KISSの原則)です。

2010年2月3日水曜日

PHPの配列でちょっと楽がしたくって。。。

集計とかする時にNOTICEエラーが

+=演算子を使う時に、あらかじめ用意されてないキーを指定するとNOTICEエラーが出るんですよね。NOTICEレベルだからいいとは言っても目障りだし、header関数の邪魔をするし、NOTICEレベルのエラーも回避せよ!なんて命令された日には大変ですよね。なので。。。

$array = ('a' => 0,'b' => 0,'c' => 0,....);
//こういう一々丁寧に書くのはやめてこう書く
$keys = explode(',', 'a,b,c,d,e,f,g....');
//5.2以前
foreach($keys as $key){ $array[$key] = 0;}
//5.2以降
$array = array_key_fill($keys, 0);

こうすると、やたら長いキーや、キーが多い時、追加したい時が非常に楽なのでおすすめです。嫌う人もいそうだけど。

5.2.0以降はarray_fill_keys関数があるんですね。便利!

Redmineの上手な使い方2(あえて最適化しない)

Redmineを合わせるよりも、Redmineに合わせてみる

「え?普通逆じゃん!?」と思われる方もいると思いますが、ツールを最適化してしまうデメリットも当然存在します。例えば、Redmineを複数使っていた場合、統合する際にカスタマイズした部分を統合するのはきっと大変ですし、もともとRedmineはそういったケースまでは想定されていません。ロールやワークフローやステータスは増やせますが、増やす際に一度考えるべきです。(結構面倒ですしw)

Redmineよりも、まずは手順を疑ってかかる

社内のワークフローや手順というものは、目的があってそれを効率的に行うために定められてると思いますが、手順書を作成する際に現場の声が入っていなかったりして、結局は使えない手順書というのもありますし、そもそもの目的が曖昧なものもあります。Redmineを導入した最初の目的は何でしょうか? Redmineを使う事を想定された手順ですか?PDCAサイクルは回ってるでしょうか?そこで「はい!」と即答できない場合は立ち止まって考えるべきです。

私的に思うのは、Redmineは部署が複数存在する会社で使う場合はよく使いどころを考えるべきだと思います。おそらくウォーターフロー型で言えば、内部設計から統合テストくらいまで(開発部門内で使うこと)が関の山ではないでしょうか。あとは営業マンが顧客に出向く前に進捗を確認するくらいの使い方ができると思いますが、要求分析や要件定義のフェーズから使うことは、Redmineのチケットのステータスを見る限りでは想定されてないことが窺えます。

もう一つ、Redmine以外にも言えることですが、グループウェアは「慣れ」が肝心です。要するに、運用ルールや習慣でカバーしてしまうということです。使う側に合わせるのも大事ですが、使う側も時間と共に成長し変わります。どう変わるかは分からないというのが難点です。Redmineを使ってどんなタスクも管理というのは理想的に見えますが、Redmineが最初から何もせずに使える分野が本来の専門分野の筈と考え、適材適所でいくべきです。(小さい会社では顧客管理までできるかもしれませんね!)

最適化で失うもの

それは汎用性であったり、工夫することであったりします。最適化が工夫の一つでもありますが、本当に最適化してしまうことが合理的なのか、長期的に見てそうでない場合は、運用面での工夫をするのがいいでしょう。カチッと決めてしまわずに、弛みを持たせるのもコツです。Redmineと自社の使い方の中庸を得ておくことが大事です。

Redmineの得意分野を知っておく

前回の記事にコメントをいただいているので書いてみようと思います。Redmineはファイル共有として使える機能もありますが、ファイルの中身までは検索対象になりません。印刷系には弱いですし、Wikiをすべて印刷するのは大変です。その辺はプログラムを自作してしまえばいいですが時間がかかります。Web上での情報共有には向きますが、オフライン(印刷して紙媒体にするとか)への対応はあまり考慮されていません。すごく残念ですが、WikiはPDF化されません(T_T)。それを踏まえて、従来の書類ベースのところは、Redmineのファイル共有と活動履歴を使うか、切り離して、情報の通達(ニュースやフォーラム、またはチケット)手段として使うのが良いと思います。そこがRedmineの得意分野です。印刷物にするとか、見た目が求められるもの、WYSWYG的な操作感はRedmineは得意としません。ファイル名やコメントにどういった情報が載っているのかを分かりやすく端的に表現して、ファイルはExcelや画像など自社で良しとされているフォーマットで作成する方が合理的だと思います。仕様が決まるまでは文書の改訂がいろいろ発生すると思います。そういった時は、その文書の置き場を決めておいてそこでやるか、バージョン管理で別に情報共有して、成果物をRedmineに上げるという方法が合理的だと思います。Excelや従来のソフトが得意とすることや、その方が速いというものをRedmineに取り込む時は注意が必要です。

それでも我慢できなくなったら

プラグインを作っちゃいましょう。もしくはRedmineを使うのを諦めましょう。選択肢を増やし、合理的なものをその中から選びましょう!

Ruby 1.8.x 1.9.x を使い分けるRVM(Ruby Version Manager)

インストール簡単、設定簡単、笑っちゃうほど簡単!

ridiculously easyと書いてある通り、RVMいいですね。use 1.9.2ってコマンドだけで切り替えられます。使ってみたいと思います。ちょっとまとめる時間がないので、また後日この記事を更新します。

Mac版にバグ?それとも仕様?

Mac版だとrvm use >バージョン< しても、ログアウトか再起動するとシステムのものに戻ってしまうようです!

Redmineの上手な使い方(チケット・フォーラムの切り分け編)

運用ルールを作ることが大事

Redmineは高機能で自由度の高いプロジェクト管理系アプリです。そして、こう使え!という態度を取りません。なので運用ルールがないと煩雑になってしまうことがあります。

うちではこんな使い方をしてるとか、良いアイデアがあったらコメントをお願いしますm(_ _)m

何をするか、しているか、したか、を見える化するツール

Redmineでタスクやソースの管理を行えば活動履歴で見える化はできます。しかし、その中には過去になると見えなくなるものが含まれます

流動していいものと、してはいけないものを分ける

例えばチケット。チケットは終了すると通常のチケット一覧からは消えます。探せば見つけ出せますが、面倒です。こういった流動してしまうものの中に、仕様に関することや調査内容、添付ファイルを入れてしまうと、一緒に見えなくなってしまって、見落としや情報へのアクセシビリティが損なわれます。

仕様やドキュメントはWikiや文書に載せておくのがベターです。例外的にトップページの画像の入れ替えで画像をチケットに添付したりというのはいいと思います。でもそれが流れてしまっては困る場合は、ファイルにアップしてチケットにはそのリンクを載せた方がいいです。情報共有には時間軸も含まれるため、過去の自分から未来の自分へはまだいいとして、過去の誰から現在の自分へなど、人と時間とがクロスする場合に、そういった流動による見落としや情報の伝達が断絶されることは避けるべきです。

チケットを発行する前にフォーラムで話し合う

フォーラムも頻繁に使えば流動するものの一つですが、トピックは大抵その時大事なもので、流動してもかまわないものだし、検索すれば出てくるのでフォーラムが適任です。フォーラムの中で流れては困るものは、ファイル、文書、Wikiのどれかを併用すればいいと思います(調査結果をまとめたものなど)。やる事が決まらないうちは、フォーラムで話し合い、決まったらチケットに落とすというのが良いでしょう。そういう決めごとがあるフォーラムは最初の記事にToDoを書いて明確にしておけば尚良いと思います。

2010年2月2日火曜日

設計する時に気をつけておく事

今日ちょっと反省したのでメモメモ。

依存度

設計する時に気をつけなければならないもののうち、今日気がついたことを一言で言えば依存度。

簡単にまとめると、例えばHTML構造にそった文脈セレクタを使ったCSSは、HTML構造に非常に依存しているため、HTML側で少しでも構造が変われば(divが抜けたり入ったり)スタイルが適用されなくなる。

ほんとに簡単な例なので、ピンとこないかもしれないけど、もっと悪い例の場合、規約に依存させる設計には落とし穴がある。例外的に規約違反が起きたらたちまち使えなくなる。

なるべく疎結させておく

やっぱり大事なのは疎結!CSSの例であればIDかクラスを指定するくらいで、文脈セレクタは使わないのがベターだし、そのコーディング手法を身につけておくとパーツデザインができるようになる。サーバやPCのパフォーマンスチューニングが必要にならない限りは、多少重いコードになっても、依存度を下げるプログラムを書いておいた方が身のためだと思いました。

ちなみにうまく疎結させるには、それぞれの役割を明確にすることが必要です。ここが難しくて、えーい書いてしまえ!となって、気持ち悪いコードを書いてしまうんだけど、ここさえクリアできれば、それなりのプログラマーにはなれそうな気がする!

追記

この記事を投稿してブログを表示したら奇跡が起きました。しかも悪い方の。なんと!例に上げたCSSの通り、なぜかBloggerの各要素のクラスが若干変更されてます!(汗 前はdiv.entry-bodyだったのが、div.itemtextになってたりと。。。なので一時的にフォントサイズがきちんと指定されず読みにくくなっていたかもしれません。しかし、こればっかりは設計とかの問題じゃなく、仕方がないのレベルですね。ただこういう問題は同じ組織内では起きてほしくないし、個人のタスクでは絶対に避けたいところ><