Eclipse 3.5 Galileo インストール
「明日はTDD勉強会第2回なので予習予習」と思っていたら、Eclipseの最新版がリリースされたことを知りました。
というわけで、せっかくなのでインストール。
ダウンロード
こちらから。http://www.eclipse.org/downloads/
開発言語ごとにパッケージが分かれているので、自分は「Eclipse IDE for Java Developers (92 MB) - Windows」を選択。
日本語化
Pleiadesとか、日本語パックサードパーティ版とか。うーん、どっちにしよ？
http://mergedoc.sourceforge.jp/
http://www.igapyon.jp/blanco/nlpack/eclipse/index.html
迷ったので、とりあえず今回は英語のままで。
誰かをスケープゴートにするよりも、問題解決することが先決だろ
「誰のせい」とかどうでもいい。
目の前にある問題を解決することに注力しろよと思う。
問題が解決した後も、「誰のせい」ってのは追及しなくていい。追及すべきは「なぜそうなったか」だ。
原因追及。
誰かが問題発生のトリガーを引いてしまったのだろうけど、その人を「お前が悪い」と責めるのは意味がない。むしろ原因追及が遅れ、同じ過ちが繰り返される。
そんなくだらないことより、どうやったら今後同じ過ちを繰り返さなくて済むのかを考えろよと思う。
同様に、自分がトリガーを引いてしまった場合でも、「私のせいです」とは言わなくていい。
他の人に「お前のせいだ」という認識を与えてしまって、原因追及の妨げになるから。
だいたい、たいていの問題は複合要因だから、誰かひとりのせいとかめったにない。
反省は大事だけれど、反省ってのは自分を責めることじゃない。
今後同じ過ちを繰り返さないためにはどうしたらいいかを考えることが反省だ。
業務ってなんだ。システムってなんだ。
SIerの世界で言われる「業務」って何だろう。
「SEはお客様の業務を熟知していなくてはならない」とか言われる、あれ。
自分は「業務＝仕事の手順」だと思う。
販売管理の手順、経費精算の手順、輸出入の手順、…。
この「業務」の中で、システム化できる部分は、データの記録や照会をするところ。
どういうデータを記録するか。そして、そのデータをどのようにDBに記録するのか、どのように画面に表示するか、DBと画面間の変換はどうするか、データのチェックはどうするか、…。
ちょっと考えると、これってルールの話だということに気づく。
記録・照会したいデータがあって、それをどういうルールで処理するか。
そのルールを定義すること＝基本設計。
で、そのルールを手続き的な言語に落とし込むのが詳細設計と製造。*1
今はこのルールを手続き型言語で書いているので効率が悪い。
処理フェーズを適切に分けて、各フェーズをルールベースで記述すると生産性は高くなる。
それこそ「コンサルタントがガリガリと設定を書く」という世界になる。製造不要。オフショア不要。短納期。低コスト。
「人間にわかる形」でルール設定を書いて、それを処理エンジンに食わせたら必要な処理をしてくれるという仕掛けがあればよい。
こうなると、テストフェーズの重要性が増す。設定ミスを防ぐにはテストしかないから。
「この設定でほんとうに予定通りの動きをするよね？」という確認が必要。
で、それはお客さん（ユーザ企業内の人）でもできるんじゃないか。むしろお客さんのほうが自社データの扱い方に慣れているから、チェックは確実なんじゃないか。
また、要件をお客さんと共有して、理解して、ルールに落としこめる人の存在が重要になる。今もそうだけど。
逆に、単純に「日本語で書かれたロジックをプログラム言語に翻訳するだけの人」は不要になる。集めてこなくてよくなる。そうしたら、コミュニケーションコストが下がるから生産性はその点でも向上する。
無論、一部に複雑なロジック（ルール設定できるようにあらかじめ作り込まれていない処理）ってのもあるだろうから、そこはプラガブルにしておく。そのロジックは優秀なエンジニアがさくっと書けばいい。難しくても物量は少ないから。これで解決。
なので、DSL、ルールベース、クエリ処理ってあたりは今後ますます重要になってくると思うなぁ。
こんなことを
3ヶ月前くらいまではよく考えてました。
いや、今でもこれはそう思ってるけどね。
でも、今は自分でコードを書けばいいだけなので、プログラム中にSQLを書くだけでだいたい解決できちゃってるんだよね。
上記のような考えって、大量にコードを書いたり、「標準化」の「標準」を低い位置にあわせなきゃいけない場合に役立つんじゃないかな。
*1:論理飛躍すると、だから詳細設計と製造は融合・一体化できる。工夫とスキル次第では。
意外なところでアクセス増加
ここ数日アクセス数が少し増加しています。
特に記事も書いてないのになんでだろ？と思って掘り下げて調べてみました＠Google Analytics
⇒ここ数日のトップキーワード「東京アメッシュ レーダー」
調べてみたら、なんとGoogle検索結果で2番目。
そりゃ増えるわけです。*1
◇
ちなみに、その記事はこちら。http://d.hatena.ne.jp/shozzy/20090227/1235702731
東京アメッシュのレーダー画像が特徴的な形になっていたのを記録した記事でした。
*1:増えたといっても、増分は30hit/日くらいだけどねｗ 所詮ネットの隅っこにあるしがない個人ブログなんで。
非同期画面
XMLHttpRequestとかの関連。
サーバ側で重い処理をするとき、リクエスト開始でひとまず画面を返す。
その後、ポーリングなりcometなりでステータス更新して、最終的に結果を画面に反映する。
これができるとユーザビリティはかなり向上する。
普通に画面遷移しようとして小さなステータスバーがにゅーっと伸びるだけじゃわかりにくい。
（ユーザ層をどこに絞るかにもよるけど）
ある意味当たり前なことなんだけど、Webの普通の仕組みだと難しかったり。
フレームワークが力を発揮できる場所。
もうあるのかな？あるよねきっと。
※作ればできるのはわかるんだけど、フレームワークでさくっとできるのかな？ってことで。
電気自動車は充電がネックだよね
7月に電気自動車が相次いで市販化されるようです。
将来は間違いなく電気自動車の時代になると思いますが、
当面のネックは価格と充電でしょう。
価格のほうは量産化でどうにかなると思うのですが、
充電は何かブレークスルーが必要そうです。
普通に充電したら、どうやっても数十分単位で時間がかかるので。
そこで考え付くのは次の２つ。
１．電池の共通化
２．燃料電池
電池を共通化すれば、充電スタンドでは空になった電池パックを
フル充電済みの電池パックと交換するだけで済みます。
（自動車用の電池は重いから、交換するのも大変そうですが…）
燃料電池はすでに実験している通り、メタノールとかを流し込む仕組みなので
ガソリンと同等の時間で補給できますね。
こう考えると、将来は燃料電池車が生き残るのかなぁ。
