スケジュールがタイトでも、交渉含め自分の裁量だけでかなりの部分に自由が効くから、少しずつ挑戦して技術を高めたり、固めたりできるのは正直楽しい。

一方で、組織内で回す案件の場合は上流にいる事が多いので、手を動かしてもの作りする楽しみからは少し離れる。こんな時は、実際にプログラミング自体をやっている自分だからこそ、そのレイヤーの仕事が辛く無いような状況に持って行かなきゃならないよな、と思う。

ステークホルダーと意見が合わずに理不尽な要件を飲まなきゃならない場合はよくある。そういう場合は「どうしてそんなクソ仕様にしなきゃならんのか」ということでムカつきもする。それでも、開発の仕事自体は楽しい状態。少なくともつらさを減らしてくれる仕組み（意識を含めたチームの状態）を構築せねば。

例えばテストの自動化。

といってもこれが常態化したからと言って「作っても意味ないじゃんそんなシステム」という楽しくない状況が変わるわけではないけど、膨大なテストを機械的に手を動かして実行するつらさは軽減される。最初のハードルは高いけど確実に身になり、確実に辛さが減って楽しさが増えると言えるのだけど、言っただけではなかなかできるようにならないので、やって見せて、教えて、少しずつ浸透させていかねば。

いずれにせよ、異なる領域の間に立って繋げる仕組みを作るのが自分の人生におけるビジョンだと考えているので、これはこれで楽しく無いわけが無い。仕事が楽しいってかなりラッキーなことなんだろうな。。。

ctpファイルはPHPのコードがそのまま含まれているので、PHPファイルとして認識してくれるのが良いでしょう。デザインビューでレイアウトの確認が出来、PHPコードのある程度のアシストをしてくれるようになります。

1. Extensions.txtファイルにCTPを追加します。
   1. /Users/ユーザ名/Library/Application Support/Adobe/Dreamweaver CS5/ja_JP/Configuration/Extensions.txt ファイルを適当なテキストエディタで開きます。
   2. 1行目に、CTPを追加します。
      ※1行目は全ファイルの拡張子が列挙されていて、行末にある:All Documentsの直前までのどこかに大文字で追記します。
   3. 16行目辺りにあるPHP Filesの行にもCTPを追加します。
   4. 保存して閉じます。
2. MMDocumentTypes.xmlにCTPを追加します。
   1. /Users/ユーザ名/Library/Application Support/Adobe/Dreamweaver CS5/ja_JP/Configuration/DocumentTypes/MMDocumentTypes.xml ファイルを適当なエディタで開きます。
      ※このファイルが無い場合は、/Applications/Adobe Dreamweaver CS5/Configuration/DocumentTypes からディレクトリごとコピーしてきてください。
   2. documenttype要素で、id属性値がPHP_MySQLの要素を探します。
   3. winfileextension属性に、ctpを追加します。
   4. macfileextension属性に、ctpを追加します。
   5. 保存して閉じます。
3. DWを再起動します。

これで、ctpファイルをDWで開いたときにPHPとして扱われるようになります。

単純にHTML部分を修正するときは実際に開発に使うeclipseなどでやってしまえますが、DWにある便利な機能を使いたい場合はこうすると役に立つかも。

プログラミングはやっぱ楽しい。

でも同時に腕が激しく鈍ってる事を思い知らされて、ちょっとションボリ。

8月まではリハビリだなこりゃ。

そんな状況を改善したくて、自己管理ツールの構想を練ってきました。ただ、Web制作会社の業務支援ツールという触れ込みだとあまりウケが良くないなと感じていて、どう話を進めれば具体化できるか悩みどころでもありました。

そんな折、DSで万歩計付きの生活リズム計なるソフトが発売されたようです。

あ、なるほど。自分の生活のリズムはなかなか見えるもんじゃない、ってのは仕事でも同じですね。自分の仕事のリズムも、なかなか見えるもんじゃない。売り上げの数字とか勤務時間とか、そういうサマリーされた数字じゃ見えてこないのが、リズムというものかもしれません。

適切な言葉で表現することで、作りたいものが明確化された好例だったかも。

iPhoneWebアプリ開発セミナーに行ってきた時の、Safari Nightly Buildについて聞いた時に思った。

毎日ビルドして改善が続けられる物質的なモノって存在しない。有るとすれば、それは生命体だ。

そう考えると、ソフトウェア開発って生命の創造に近いって言えるかも？禁断の知恵の実がもたらした本当の禁忌は、コンピュータによる生命存在の創造？

うーん、なんか思考が妄想で暴走してきたのでこの辺で止めておこう。

1. まずはMacPortsのサイトからdmgファイルをダウンロードする。
2. .dmgをマウントするとパッケージがあるので、ダブルクリックしてインストールを進める。

と、ここでなぜかkernel_taskがCPUを食いつぶし始めた。MacPortsは無関係だと思うのだが、なんだろう。いったんAIRを閉じてスリープしてから解除したら正常に戻った。そのままにしても戻っただろうか？謎だ。

サイトの説明によれば、インストールしたらコマンドたたいてアップデートせよとのこと。

sudo port -v selfupdate

Terminalを起動して叩いてもダメだった。まぁパスが通ってないんだろうけど、どこにインストールされたのかわからん。しょうがないから再度.pkgを開いてcommand-Iでファイルを表示したら、どうやら/opt/local/binに入れるらしい。

気を取り直して、MacPortsセットアップの続き。

3. Terminalでsudo /opt/local/bin/port -v selfupdateと叩く。もちろん後々考えるとPATHを通した方が楽。
4. しばらくしたらプロンプトが戻るので、これで準備完了。ブルワーカー並にカンタンっすね。

そもそも、このMacPortsはwgetとかncftpとかのCPAN使うのにあると便利なパッケージを入れるために入れたので、後は必要なパッケージを入れましょう。


$ sudo port
> install wget

とかね。

あー、ectoでこのエントリを書いていたらまたkernel_taskが暴走し始めた。ectoのせいなのか？
最近はWordPressアプリかWordPressの管理画面で入力することが多かったのでecto離れしてたんだけど、こりゃ本格的にダメかも。そういえばMacBook AIR使っている人でネット上でブログにkernel_task暴走のことを書いてる人ってectoユーザが多かった気もする。

気のせいなら良いのだけど。

派生開発が続くと思われるような場合はJavaを選ぶことが多い気がします。画面数は少なくてもロジック数が多そうな場合も、やっぱりJavaを選ぶことが多い感じです。Perlを選ぶのは、画面数もロジック数も少ない場合。それと、環境が指定されている場合にPerlになったりします。他社ホスティングでJavaを入れてくれているところは少ないけど、Perlはほぼ100％に近い確率で入ってますからね。

今回から何回かに分けて、開発環境の構築、開発、デプロイ、運用に渡ってJavaとPerl[Catalyst]の違いについてまとめてみようと思います。
Javaを使う場合の開発は、環境を整えるのが楽です。基本的には以下の二つのソフトをダウンロードしてインストーラでセットアップすれば良いです。

• JavaのSDK
• Eclipse
• Apache Tomcat

あとは、好みのフレームワークを落としてくればオッケーです。まぁその辺りで面倒と言えば面倒なのですが、サーバ側ではJREとTomcatだけでオッケーというシンプルさ。Windowsマシンがあってネットにつながってれば、小一時間で開発が開始できるくらい簡単です。

対して、Perlで開発する場合は、場合によってはJavaの時より簡単なのですが、諸事情によりちょっと画面数があったりするものをPerlで作る必要が出てきたら、じゃあCatalystでも使ってみますか、という話になってとたんにややこしくなります。

Perl[Catalyst]で開発する場合、まず大前提としてLinux環境を用意すべきです。そして、その後大量のCPANモジュールとCatalystのRuntimeと開発ライブラリをインストールする必要があります。

• Linux環境を用意する。VMwareなどで事足りるでしょう。
• cat-installをwgetとかで落としてきて実行して、Runtimeをインストールする
• CPANで開発ライブラリをインストールする（perl -MCPAN -e shell ‘install Catalyst::Devel’）

とまぁ、項目で書くとこんだけでJavaと変わらないんですが、これがまた時間がかかるかかる・・・。小一時間じゃ終わらない気がします。慣れると小一時間という話があって、確かにそうなんですが環境構築に関しては、Javaより知らなきゃいけないことが多い気がします。得にCPANモジュールを入れるときに失敗した場合、その問題を探って解決するのは初心者には厳しいものがあると思います。

とりあえず「その１」は、こんなとこで。
次回はもっと具体的な手順について突っ込んでいきましょう。

聞いたセッションは4つ。

• Google Gadget
• Desktop Gadget
• DataAPI
• Software Engineer in Google

基調講演とかが聴けなかったので、Gearsの話は帰ってから知りました。知ってたら最後のレセプションパーティでGoogleの人に聞いたのに、知らなかったんで聞けなかったっす。なんてこったい・・・orz

ガジェットはプラットホームとしてかなり魅力的でした。それにしても似たようなコンセプトのプラットホームが五つもありますよ。OS別にすると七つ。

• Google Gadget
• Yahoo! Widget
• Windows Vistaのウィジェット
• Dashboard Widget
• Apollo

大杉。この状況は過去のブラウザ戦争を彷彿とさせますね。開発環境もだいぶ整っていて、GoogleTalkと連携させればコミュニケーション関連の処理も書けるGadgetが一歩リードしている感じです。

すごく参考になったのは、Software Engineer in Google。今うちの会社でもGoogleを参考に20%ルールという制度を取り入れようとしているんですが、やっぱり元祖のやり方は参考になります。ビジネスモデルが全く違うので元々そううまく行くとは思ってませんでしたが、うまく生かせそうなヒントはもらえました。

エンジニアに居心地の良さそうなGoogleですが、どうしてこんなにも違うのかと思ったとき、Googleの人は地力が違うのかなぁという気も一瞬したんですが、それほど技術力の差が天と地ほどもあるようには思えないんです。もちろん彼らがすごいのはわかるしまだまだ自分は太刀打ちできねーなーとも思いますが、そうじゃないところで差が付いちゃって、それが広がり続けている感じがします。

Googleの人たちがやってる一つ一つの点は、自分たちもやっている。やれていないこともあるけど、やってることも多い。じゃあ何が違うのか？

目的に向かって突き進む組織を、継続して運営できているかどうか。そこが決定的に違うんだと思いました。Googleはそういう土台をずっと続けて築いてきた。だから今がある。会社名が残っているかどうかじゃなくて、志を共にしている人たちがその方向に向かって進み続けているかどうか。そういう人たちの集団にできているかどうか。

１年以上前の自分を思い浮かべると、そういう芯が持ててなかった。でも今は違う。信頼に足る上司・仲間と一緒に信じる道を目指せる土台ができつつあります。今年１年は勝負時です。

Google Developer Day 2007は、ガジェットとかそういうのの情報が知りたかったのはもちろんあるんですが、そもそも今の職場環境、シゴトに取り組む精神、組織のビジョンその他諸々について、開発者である自分たち自身が理想とする環境を作っていかねばならんと思うわけで、そのために技術者にとって理想といわれるGoogleの環境を参考にさせてもらおうと思って参加してみたわけでした。

やっぱり良い会社だなぁ、と思いますね。みんな生き生きしています。特にシニアプロダクトマネージャの人が言った言葉が印象に残りました。

「Googleの作ったソフトウェアは、必ず皆様のお役に立てます！是非活用してください！」

こういう事を誇りを持って言えるものを作らねば、作れる環境にしていかねば、と改めて心に決めた一日でした。

前々から試してみようと思っていた、Subversionリポジトリにアクセスするためのライブラリをちょろっといじってみた。

サンプルコードを落として動かしつつドキュメント見たりとか、そんな程度だが、非常に簡単にリポジトリにアクセスできることがわかった。

なんか日本語で書かれたページが全然なかったんだけど、あんまり書くことがないからかもしれん。

うーん、これをあーしてこーして・・・夢は広がるなぁ（ｗ

宝探しをしていて、トラップを発見し、どうやってそれを切り抜けていこうかと真剣に考えるのが楽しいですね。クリアしたら経験値ゲット。まさにゲーム感覚。

という風に前向きにとらえないとやってられん。正直。

今、他人が１年かけて育ててきたシステムを引き継いで、さらに機能を追加しようという案件に携わっている訳です。

が、これがまたひどい。ひどすぎる。
同じ処理を意味するロジックがあちこちに分散していて、コピペコードが蔓延し、ほどけないスパゲッティコードの嵐。コードに埋め込まれたSQLと大量のStringBuffer#append()。ユニットテストのためのコードは一つもなし。DBのテーブル設計も正規化されてないし。

ここ３年ほど、他人のプログラムを全部引き継いだ上での派生開発はしてこなかったので、かなり新鮮ではあります。何がだめなのか、という意味でものすごい勉強になるし。

しかし同時にものすごいストレスも・・・。ハイリスクハイリターン。

それでも来年に控えているターゲットRDBMSの変更に備えて可能な限りDBアクセス部分をすっきりさせておかないと大変なことになります。なので休日である今日もまたトラップを慎重に取り除いてます。おそらくDB周りを整理したらコード量が10分の1程度にはなるんじゃないかと、怖い予感がしている今日この頃です。

トホホ。