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

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が起動し，日本語もちゃんと出る（泣）

ソースコードの管理

たいがいソフトウェア開発では、バージョン管理ツールが使われるが、
うちとかだと、Microsoft のVisual Source Safeとかしか使っていない。

しかし、こいつでは、分散開発とかがやり難い。
（もっともVisual Source Safe 2005あたりから、Webアクセスとかできるようになってだいぶ改善しているようだ。使ったことないけど）

いまは、Microsoftももっと進んだ製品を出していて、Visual Studio Team Foundation Serverというのがあるらしい。

でも高いので買いたくないです。*1

やりたいことは、客先と自社で分散で作業し、自社で開発したソースを客先のリポジトリに格納したい。で客先のリポジトリからお客や他社が作ったソースとともに統合作業ができればOK。
「パッチファイルをメールで送る」でできれば万々歳なのだが、

git/Mercurialでなんとかならないか考え中

とりあえずMercurialを使ってみるか（←いまここ）

*1:

参考価格

・Team Foundation Server : 380,000 円

・Team Foundation Server CAL : 68,000 円

・Visual SourceSafe 2005 : 88,800 円

・git                                       : 0 円

・Mercurial                          : 0 円