死語の世界：オブジェクト指向

３０年以上前の発行ですが，「人月の神話」という題の本があります．
この本にプログラム開発に狼男を倒す銀の弾丸はないという話がありました．
いまだ，この話は正鵠を射ていると思います．

で最近，「オブジェクト指向で開発する」という案件を聞きました．
これからはオブジェクト指向だそうで，優秀なオブジェクト指向技術者を集めて，
新しい製品を作るらしいです．

オブジェクト指向が流行りだしたのは1980-90年代だと思います．
オブジェクト指向で開発すると「素晴らしいなにか」があるらしいです．
今年は2010年ですが，まだそんなことをいう人がいるものだと．

 Java，C++，RubyやPythonといったオブジェクト指向言語は多数あり，
 今の若手開発者はオブジェクト指向言語で開発しています．

でも生産性とか効率は，昔のCとかで作っていたころと大差ないのが現状です．
で，オブジェクト指向を知らないマネージャーや営業は，
「オブジェクト指向がしっかりできていないから生産性が上がらない」
と思っているようです．
UMLとRUPとかXPとかなんらかの技術力が足らないという意見らしいです．

技術者でもたまに，「現実をオブジェクトとしてモデリングする」みたいなことを真顔でいう人もいます．（初期のオブジェクト指向方法論の教科書が今も流通しているのでしょうか？）

やれやれだぜ．

ここからは私見になるかもしれませんが，私の考える「オブジェクト指向」のメリットはなにかを書きたいと思います．

オブジェクト指向の最大且つ唯一のメリットはフレームワークを作れること．

と考えています．

古くはMacApp,ET++,MFC，新しくはRuby On Railsといったアプリケーションフレームワークが
オブジェクト指向の成果として上げられます．

私は，「フレームワークによる再利用性の向上こそがオブジェクト指向の最大の利点」と認識しています．

しかし，現実には，１度作ったプログラムをうまく再利用するのは，技術以前の問題があります．
たとえば，A社向けに作ったシステムを他のB社，C社に展開する
といったことができれば，再利用性の向上は有効です．

しかし，日本のソフトウェア開発は自社製品開発より，作業請負で行うことが多く，
A社向けの作業成果は，簡単にB社，C社に持っていくわけにはいかなかったりします．
（著作権を発注者が持つ場合もあれば，A社担当者と，B社，C社の担当者が異なる場合もあります）

そもそも作業請負で，迂闊に作業効率を向上させると，売り上げが落ちるという問題があります．

結論：日本終わったな．

最強のデバッグツール，その名は，，，

printf

Google App Engineが使えたのをいいことに，ajaxに挑戦したが，見事に玉砕した．
（いやプログラムできたけどね，時間かかり過ぎ）
幾度かJavaScriptは使っているがどうにも使いにくいしデバッグできない．

いや言語使用がどうのという話ではない．単純にデバッグプリントが使えないから，
調子が上がらないだけである．
Safariを使ったがBreak Pointも設定できるし，デバッガは問題ではない．
alert()を使うのが昔の方法だったが，いちいちOK押さないといけないのでメンドクサイ．

ちょっと調べたら，デバッグプリントをする方法があるようだ．
問題はブラウザ毎に違うようだ．orz

http://diaspar.jp/node/92

あと，jQueryを使ったがこいつはすごく楽だ．

組込みエンジニアはもういらない。

最近、Androidが流行のようだ。
Androidはgoogleの組込みOSだ。無料なのが素晴らし。
これから日本でもDoCoMoやSoftbankから新しい機種がでるという話だし、海外を含めれば数十機種発売されるようだ。
日本では、Androidを入たれフォトフレームなるものも発売される。

「これからはAndroid」と言う、バズワードに弱い人たちもいるが、
これからは組込みソフトウェアエンジニアがいらなくなる前兆のように思える。

今までは組込み機器（デジタル家電や携帯電話など）は、それぞれCPUや周辺回路、OSからドライバ全て自前で用意していた。そのため、その上で動作するプログラムは1製品毎に開発ということになっていた。よって多くの技術者がそこでご飯を食べていた訳だ。

しかし、組込み機器でも汎用OSが使えるようになると、1回作ったプログラムが延々と使い続けることができるため、開発がすごく少なくなるのではないだろうか？
（多くの技術者がお払い箱になるのではないか？）

実際、Windowsが普及し、PCが各家庭に1台くらいあるような状況になったが、
うちの会社でも、PCアプリの開発は激減している。
（今は、ほとんどがWebアプリということもあるが、、）

PCと同じ道を、組込み機器も進むのではないだろうか？

GoogleがなぜAndroidを無料で配っているか考えてみよう。

自身のWebサービスを携帯などでも使えるようにして、

ユーザを囲い込みたいに違いない。

まあ、ユーザとしてはGoogleのサービスで大体問題ないが、

しかし、他の会社のサービスは撃沈だろう。

特に若いソフトウェア技術者は、今後どこを頑張るべきかよく考えた方がよいのではないか？

Google App Engine

今までWebアプリを作るためには、レンタルサーバを借りるなりして、自分で環境設定やプログラムを配置したりといろいろ手間が掛かった。

しかし、時代は変わった。（遠い目）

Google App Engineを使えば、簡単に自分のサービスを立ち上げることができる。
テストなど小トランザクションなら無料だ。

いい時代になったものだ。

でちょっと立ち上げてみた。

http://bad-workers.appspot.com/

いわゆるHello Worldだが、

Google App Engine詳解：さっそくHello Worldから作ってみた

を見て作った。（というかコピペ）

注意点をいくつか

Mac版SDKで試したが

SDKをダウンロードして中のランチャーアプリを適当なフォルダ（アプリケーションとか）にコピーダブルクリックしてランチャーアプリを起動。

なんかコピーするらしい。(/usr/local/google_appengine/が作られる)
パスを設定。(tcshの場合）

set path = ($path /usr/local/google_appengine/)

とか

アプリケーションの作成(Create)するのに携帯のアカウント（SMSなど）
を入力する必要がある。docomoの場合、i-modeメールアカウントでOK。
あとは、携帯宛にメールが届くので、それを入力して作成完了。

日本語などを使う場合、.pyファイルの先頭に、


# -*- coding: utf-8 -*-

をいれutf8で保存する。

ファイルの先頭のutf-8宣言がないと、テストサーバでは動いても、実環境(appspot.com)で

エラーが発生した。

ってな感じ。1時間くらいでできるので、お手軽だ。

今後、Big Tableなんかを使ってみたい。

追記：

スタートガイドを参考に、ユーザ情報(Googleアカウント）、永続化、テンプレートエンジンを試してみた。

簡単だ。。。

Big Table のキーの管理がちょっと特殊である。
Big TableはKey-Value Storeの一種で、1つしかキーがない。
PythonのO/RマッパーであるModelクラスでは、key_nameという特殊な変数でアクセスする。

たとえば、E-Mailアドレスをキーにしてオブジェクトを取得する場合、

    note = Note.get_by_key_name("key:"+users.get_current_user().email())

というようにした。

Modelオブジェクトを生成するときにキーを指定しないと、キーはユニークな値で自動生成される。
GQLという問い合わせ言語(SQLの親戚）で検索(SELECT)する場合、このキーを含めるない方がよいようだ。（いろいろ制限がある）

あと、Google App Engineでは静的なファイル（.cssや画像など）を置けるので、
次回は、静的なHTMLからAjax的なアクセスをやってみたい。

Win-WinよりLose-Lose

よく偉い人が好きな言葉にWin-Winの関係とかいうものがある。
相手（顧客）も儲かる(Win)し、うちも儲かる（Win)ようにするっていうことらしい。

まあ、100％計画通りに儲かるなら、そういうのもありかもしれないが、
今回のような不景気だと、計画が下ぶれして、Win-Lose/Lose-Winとなりやすい。

だいたい、IT企業なんて、Win-Winとかいいながら、
リスク管理とかいって如何にリスクを顧客に負わせ、
いかに自分が危ない目にあわないかしか考えてない。

本当に顧客から信用されるためには、実は、
相手が損(Lose)したら、自分も損(Lose)する関係が必要なのではないだろうか？

例えば、あるIT企業が、顧客からシステムを受注したとすると、
まあ巧く開発が成功してたとして、
顧客が納品されたシステムが、使い勝手が悪い、性能が十分でないなので、
使えなかったとする。
でも、契約上検収しちゃったら、お金は払わないといけなくて、
顧客はガッカリってことはよくあるのではないか？

まあ、IT企業としては、とりあえずお金貰えりゃOKって感じだろうけど、
それでは、次の受注に繋がらないし、
顧客はIT化が遅れ市場競争力を失ってしまったりする。

ではどういう契約形態が理想か考えてみる。
例えば、
 - システムの開発費はIT企業側が負担する。
 - 顧客は、そのシステムの使用料を払う。
という形はどうだろう？

使えないシステムを作った場合、IT企業側も損するわけだ。
当然使えないシステムは作れない、非常にリスクを追うことになるが、
顧客がトンチンカンなこと言ってきても、開発費は自分たちで出しているので、
断ることもできる（はず）。
かなり厳しい開発になるが、こういうのが理想ではないだろうか？

もう，若者は車に乗るな！

最近，残業も少なく収入も減っている（ような気がする）
ので，外食を控え，自炊を始めたのだが，大学時代に自炊していたころに比べ，
あらゆるものが安い！
肉類，野菜などなど，大学時代と比べずいぶん安い．
（アメリカ産だったり，産地不明だったりするが．．．）

薄型テレビもどんどん安くなっているし，デフレが進行しているように思えるが，
値段が上がっているものがある．

「自動車」である．

昔，若気の至りでCivic Type R（初代）という車を買ったことがある．
車両本体価格１９９万だったはずだ．

Type Rという車は特別な車だが，
Civicなんか100万ちょっいで，若者向けの安い車という認識だ．
Type Rとはいえ，H社の中では，お子ちゃま（初心者）向けスポーツカーの位置付けだったはずだ．

あれから，ｘｘ年（正確な年数が分かるが書きたくない）
今のCivic Type Rは2,835,000円だ！
あれから，ｘｘ年（正確な年数が分かるが書きたくない）
知らない間にずいぶん値段が上がった．ドアが４枚になったり，
「かっこよさ」や「スポーティさ」はダウンしまくりなのに，値段だけずいぶんになったじゃない．

もう若者はフィットに乗るしかないね．

と思ったら，フィットベースのType Rが出たらしい．

ホンダ・シビックタイプR

http://response.jp/article/2009/11/05/132023.html

価格は298万円！
orz


「もう若者は車に乗るな！」と言っているようなものだ．

いや，若者に買える価格のスポーツカーを出さないと，
日本で車買う人いなくなるよ．

昔は，トヨタとかが（かっとび！）スターレットを69万8千円とかで売って，
若者に車を買わせるようにしていたが，
そういう若者が大人（中年）になると，高い車を買うようになるのであって．
若いうちに車乗らなかったら，「一生乗らないでもいいじゃん！」ってことになりかねない．

ちょっと，日本の自動車メーカー（とくにH社）はよく考えた方がいいんじゃない？

Mercurial(TortiseHG)でWinMerge（日本語版）を使う

マージツール・Diffツールを設定する．
（MercurialHGは0.8.3 環境変数LANG=jaで日本語化，コンテキストメニューはそのまま英語）

参考：
http://d.hatena.ne.jp/Wacky/20080503/1209817242

http://www.02.246.ne.jp/~torutk/mercurial/intro.html


まず日本語版WinMergeをインストール

WinMerge

右クリック→TortoiseHG→Global Settings
で設定ダイアログを出す．

ダイアログの「ファイルを開く」 をクリックして設定ファイルを開く（HOMEフォルダに設定ファイル「mercurial.ini」が作られる．

 

赤字の部分を追加 

# Generated by tortoisehg-config

[ui]
username = Miura

[merge-tools]
winmergeu.args=/e /ub /dl other /dr local $other $local $output
winmergeu.regkey=Software\Thingamahoochie\WinMerge
winmergeu.regname=Executable
winmergeu.fixeol=True
winmergeu.checkchanged=True
winmergeu.gui=True

[extensions]
extdiff =

[extdiff]
cmd.wmdiff = C:\Program Files\WinMerge\WinMergeU.exe
opts.wmdiff = /r /e /x /ub

一旦，Global Settingを閉じ，再度Global Settingを開く．

3-wayマージツールに「winmergeu」

GUI差分表示コマンドに「wmdiff」を設定する．

 

あとは，右クリック→TortiseHG→Visual Diffをクリック

ダイアログから修正ファイルをクリックすると，

WinMergeが起動し，日本語もちゃんと出る（泣）