NFuji's Café: 2010

2010/12/31

HTMLをサーバー側で生成すべきか？

DjangoTemplateとAjax でも書きましが、Django Template はサーバー側でのHTML生成をサポートする仕組みです。GAE/Python では Django Template が標準装備されており、スタートガイドのチュートリアルでも使用方法が紹介されています。その流れでDjango Templateを使用して自分でもアプリを作ってみました。しかしAjaxを使用する段になって、サーバー側でHTMLを生成してクライアント側でinnerHtmlを書き換えるという手法に、違和感を覚えました。

HTMLはMVCパターンでいうところのViewに当たる部分です。そのViewをサーバー側で作ってしまったら、疎結合なサービスとして提供できなくなってしまいます。たとえデフォルトのViewは提供するとしても、Viewと切り離したサービス(つまりデータとビジネスロジックであるModel)のインターフェースを公開しておけば、誰でも好きなViewを勝手に作ることができるようになります。（お前のアプリのViewなんか誰が作るんだ、という話は別にして(^_^;)）。

従って、AjaxではJSON(XMLだとデータサイズが大きくなるのでJSONを第一選択としたい)でデータを取得して、JavaScriptのControllerでHTMLを生成というのが、ストレートな解法だと思います。

しかし、課題もあります。
1. Django Template のような仕組みを、JavaScript + JSON で実現する必要がある
2. クライアント側に処理負担がかかる(未検証)

1. についてはライブラリを探すとして、2. についてはちょっと注意が必要です。
処理を「サーバー側処理＋通信＋クライアント側処理」に分けると、クライアント側でHTMLを作成する場合は、サーバー側処理と通信(HTML > JSONとして)の負荷が減ります。しかし、サーバー側の処理が減った分、クライアント側で処理が増えます。
モバイル端末の性能向上には目覚しいものがあるとは言え、比較的重たい処理を行う場合は処理速度の検証が必要でしょう。

とここまで考えて探してみると、中島聡氏がブログでもっと正確で判り易くて格好良い説明を図入りでされていました(「RESTful MVC」なアーキテクチャの話)。しかも 1. のクライアント側Templateの仕組みをjQueryのplug-inとして作成されていました(jQBinder, ブラウザー側でのHTML templateを可能にするjQuery plug-in)。ちょっと凄過ぎです。
さらに、既に2005年の段階でAjaxの本質として「データ・バインディングはサーバー側ではなく、クライアント側で行う」ということを挙げられています(Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ)。

以前ブログを読んだ時にはちゃんと分かっていなかったということが、わかりました。

それでは皆さん、良いお年を (^O^)／

ChromeExtensionsのpopupで選択中のタブを取得する方法

ポップアップタイプの Chrome Extensions で選択中のタブを取得する方法のメモです。
結論としては、以下のようになります。

chrome.windows.getCurrent(function(currentWindow){
    chrome.tabs.getSelected(currentWindow.id, function(selectedTab){
            :
            :
    })
});

chrome.tabs モジュールにはもっとシンプルな getCurrent() 関数があります。
しかし、ドキュメントに

May be undefined if called from a non-tab context (for example: a background page or popup view).

との記載がある通り、ポップアップタイプのChrome Extensionsで使用しても現在のタブが取得できません。そこで

chrome.windows.getCurrent() 関数で選択されているWindowのIDを取得する
WindowのIDを指定してchrome.tabs.getSelected() 関数で選択中のタブを取得する

という段取りになります。
JavaScript初心者に分かり難いのは、getCurrent()/getSelected() 関数がともに、WindowやTabを受け取るコールバック関数を引数にとるという点です。たとえば、getSelected() であれば以下のような形です。

    chrome.tabs.getSelected(integer windowId, function callback)
    callback --->  function(Tab tab) {...};

そのコールバック関数を無名関数でカスケードさせたのがこの記事の最初のスニペットです。

ところでドキュメントを読めば、chrome.tabs.getSelected()の第一引数WindowIDはOptionalでDefaultはCurrentWindowとなっています。そのため以下のように、第一引数にnullを指定することで、コールバック関数のカスケードを回避するが可能です。

chrome.tabs.getSelected(null, function(selectedTab){

            :
            :
});

とはいえ、JavaSccriptで省略可能な引数を引数リストの末尾に持ってこないのは、ちょっとマナー違反です。明示的にnullを渡さないといけないのですが、これではもう省略可能ではありません。また後でコードを読んだ時に、null が何を表すかわからなくなりそうです。

DjangoTemplateとAjax

Django Template は、サーバー側(GAE)でHTMLを生成する仕組みです。その対比でいくとAjaxは、クライアント側(ブラウザ)でHTMLを生成／変更／削除する仕組みと言えます。ではDjango Templateを使ってAjaxを実現するにはどうしたら良いのか、ちょっと悩んでしまいました...

で、結論としては、Django Templateで部分HTMLを作成してAjaxでHTMLを差し替える、というのが解の１つかと思いました。

つまり以下のようなHTMLを用意しておいて、

<html>
    <head>
            :
            :
    </head>
    <body>
            :
            :
        <div id="TargetForAjax"></div>
            :
            :
    </body>
</html>

getElementById("TargetForAjax").innerHTML = (Templateで作成したHTML)
としてやれば良いわけです。

prototype.jsを使用するのであれば、クライアント側のJavaScriptは以下のような感じです。

new Ajax.Request(
    URL,
    {
        method: "get",
        parameters: {arg: myArgument},
        onSuccess: function(transport){
            Element.update($("TargetForAjax"), transport.responseText);
        },
        onFailure: function(){alert("Something went wrong...") }
    }
);

Ajaxというと受信するデータはついつい、XML/JavaScript/JSONなどを想定してしまいますが、部分HTMLでも良いわけですね。

2010/12/30

DjangoTemplateでGAEデータストアのIDを使用する

２ヶ月ぶりのブログ更新です。遊んでいたわけではなく、GAEとChrome Extensionsで遊んでいた(^_^;)からです。ということで、Code Snippets いきます。

GAEのデータストア内のレコードには、アプリケーション全体で一意となる数値IDが自動でふられます。しかしGAEのドキュメントには、そのIDをDjango Templateで使用する方法が書かれていませんでしたので、メモを残しておきます。

Python側
例えば以下のように、MyModelのレコードを10件取得するとします。

template_values = {
  "items" : MyModel.all().fetch(10)
}

Template側
「key.id」でアクセス可能です。

{% for item in items %}
    {{ item.key.id }}</br>
{% endfor %}

たったこれだけですが、意外に悩んでしまいました。

2010/10/23

GAEで、世界よこんにちは #3

今週はいよいよ、GAEにアプリケーションを登録します。

前回まで

#1. 'Install' & 'hello world on local PC with SDK'
#2. Brush up the hello-world application using the framework.

11. GAEのユーザー登録を行う
GAEの管理サイトにアクセスしてログインします。
ログイン自体は、Gmailなどの他のGoogleのアカウントと共通です。

以下の画面が表示されたら「Create Application」ボタンをクリックします。

初回のみ(?)次のように認証が必要です。

12. SMSによるカウント認証をおこなう
以下のようなSMSによるアカウント認証画面が表示されます。

GAEにアプリケーションを登録するには認証コードが必要で、それを登録した携帯メールに送信されてくるということのようです。

選べる国は、カナダ、日本、合衆国の３つです。
日本を選ぶと、キャリア選択ドロップダウンが表示されます。
vodafoneのアドレスにも対応していてほっとしました。

日本を選ぶと携帯番号の入力欄が、ユーザー名称入力欄に変わります。
携帯メールの＠より前を指定して「Send」ボタンをクリ～ック！
認証コード入力画面に遷移するとともに、すぐにポケットの携帯が震えました。
届いたのは至って簡素なメールです

============================

from : noreply@google.com
subject : Google App Engine Code
text : Google App Engine Cone:*******

============================

認証コードを入力して「Send」ボタンをクリックして、アカウント認証の完了です。

13. GAEにアプリケーションを登録する
アカウントの認証が終わると、以下の画面に遷移します。

一行目に、残アプリケーション数が「10」とでていますね。

まずは、アプリケーションIDを決めないといけません。トップレベルドメインを指定せずに無料のサービスでいく場合、「http://[アプリケーションID].appspot.com/」がURLになります。また作成後の変更はできませんので、本来は慎重に考えるべきところです。今回は適当に「helloworldongae」として「Check Availability」ボタンをクリック。すると
「Yes, "helloworldongae" is available!」とでましたので、これで行けそうです。なので、アプリケーションのタイトルも「Hello World on GAE」で決定です。
＃こんな一般的な名前がまだ空いていたのですね...

認証オプションは「Edit」リンクをクリックして何があるかを確認します。

選択肢は以下の３つ。

1. 全グーグルアカウントユーザーに公開（デフォルト）
2. GoogleAppsの特定ドメインユーザー限定
3. OpenIDユーザーに公開するか（実験段階）

今回はデフォルトのまま、「全グーグルアカウントユーザーに公開」で行きます。

最後に約款を読みます。ほとんどが一般的な内容ですが、次の２点がちょっと目に止まりました。

1. 13歳未満はこのサービスを使用してはいけない
2. 複数アプリを単一アプリのように見せかけるアプリはNG

小学生とズルはお断りだそうです。
それでは「 I accept these terms.」にチェックを付けて、「Create Application」ボタンをクリックします。これでアプリケーションの登録が完了しました。

14. アプリケーションをGAEにアップロードする

GAEにアプリケーションは登録されましたが、中身はまだ空です。アクセスしてもページが見つかりませんと怒られます。ということで、先週作ったアプリをGAEにアップロードする必要がありますが、方法は簡単です。
まず「app.yaml」ファイルを編集し、「application」項目の設定値を「helloworld」から先程登録した「helloworldongae」変更します。
次いでコマンドラインから「appcfg.py update helloworld/」を実行すれば終わりです。

SDKの新バージョンがリリースされているとか、SSLのモジュールがないのでセキュアでないとか警告がでますが、そのまま流れていってGmailアカウントによる認証入力待ちになります。
認証が通ると、GAEにアプリケーションがデプロイされてコマンドが終了します。

これでアップロードも完了です。早速ブラウザでアクセスしてみるとちゃんと画面が表示されました。ログイン画面も以下のように本物で、登録したアプリケーション名も表示されます。

でちょっと焦ったのが、このHelloWorldアプリ、チュートリアルのまま使用すると危険です。ログイン後にメッセージを登録すると、他の人にもメールアドレスが丸分かりになってしまいます。慌てて修正して再アップロードしました。∑（;￣□￣Ａｱｾｱｾ

ということで、これで「GAEで、世界よこんにちは」は完結です。

Access ---> 'Hello World on GAE'

2010/10/16

GAEで、世界よこんにちは #2

先週に引き続き、GAEのスタートガイド(Python)に従って、「Hello World」に挑戦します。
今週はGAEの機能を使用してアプリケーションのブラッシュアップを行ないます。

6. ユーザーからの入力を受け付ける
webapp を使ったウェブフォームの処理。チュートリアル通りに、「helloworld.py」のコードをコピー＆ペースト。

1. Mainページでテキストエリアに文字列を入力。
2. ボタンクリックで /sign ページにPostする。

とはいえ、Mainページとかsignページとかが物理的に存在するわけではない。
ハンドラは「helloworld.py」だけなので、Request中のURIで実行処理を分けているだけ。

7. データを永続化する
データストアの使用。世界中での分散処理によるデータアクセス処理が隠蔽されるので、どこからでもどのセッションからでも同じデータにアクセス可能。

[データ構造の定義(CRUD共通)]

1. モデルクラスを定義する（RDBのテーブルのカラムを決めるようなもの）

[データの追加(C)]

1. モデルクラスのインスタンスを生成する
2. モデルインスタンスに値を詰める
3. モデルインスタンスの put() メソッドを呼ぶ

[データの取得(R)]

1. GQL(SQLのSELECT文。必ずSELECT * FROM model になる)オブジェクトを作成する
2. GQLオブジェクトをイテレーターとしてモデルインスタンスにアクセスする

[データの更新(U)]

1. モデルインスタンスに値を変更する
2. モデルインスタンスの put() メソッドを呼ぶ（i.e. 追加時と同じ）

[データの削除(D)] 何故かスタートガイドには記述がありませんが...

1. モデルインスタンスの delete() メソッドを呼ぶ
あるいは
2. GQLオブジェクトを指定してdbクラスのdelete()メソッドを呼ぶ

8. コードとHTMLを分離する（Djangoテンプレートの使用）

DjangoのテンプレートエンジンはApp Engineの一部であり、 SDK にも含まれているとのこと。

前回、WebアプリケーションのフレームワークではDjangoの使用を諦めてwebappにしましたが、そのwebapp内Djangoのテンプレート機能が取り込まれてるようです。

HTMLテンプレート「index.html」を作成して画面デザインを持たせる。
「helloworld.py」は以下の修正を行う。

1. 「index.html」で使用するデータを用意する
2. 「index.html」とデータをバインドしてレンダリングする

GQLオブジェクトへのイテレータ的アクセスも、HTML側のDjangoテンプレートに任せる。

3. 結果を Responseに出力する

9. 画像、CSS、JavaScript等の静的ファイルをWebサーバーで公開する
(通常)GAEでは、アプリケーションのディレクトリにファイルを置いても「URL/ファイル名」で自動的にアクセスできるわけではないとのこと。確かに、「8. コードとHTMLを分離する」でも直接「index.html」にアクセスせずに、「helloworld.py」で「index.html」を読み込んでいました。
Webへの公開は「app.yaml」にハンドラを追加することで可能になります。ハンドラは上から順にURIを正規表現でマッチングしていき、最初に見つかったもので終了。

スタートガイドに従ってスタイルシートを追加しました。

これでアプリケーションは完成です。
次はいよいよGAEへのアップですが、本日はここまで。ビールと餃子が呼んでいるので、続きはまた来週です。

10. おまけ
CMD.exeで立ち上げているWebサーバーですが、アクセス毎にログが出力されます。ブラウザからの HTTP-GET が以下の順で呼ばれていることがよく分かります。

1. デフォルトのページ（成功）
2. スタイルシート（成功）
3. ファビコン（失敗：404 Not Found。そりゃ作ってないですから）

あと、Ctrl ＋ C でWebサーバーを終了させるときに、ちょっと時間がかかるようです。慌てないでゆっくり待ちましょう。

See you next Saturday!

Ze Frank's web playroom が面白い

TEDをながら見していて面白かったのでメモ的エントリー。
英語で20分程度ですが、最初のころの young me now me の写真だけ見ても面白いです。
Ze Frank's web playroom @ TED

地球サンドイッチなどもそうですが、ネットワークを利用した遊びを編み出し続けているのはすごいですね。ビデオで紹介されているもの、されていないものも以下のサイトで視聴できます。参加も可能です。

zefrank.com
http://www.zefrank.com/

2010/10/11

GAEで、世界よこんにちは #1

Google App Engine で、'Hello, World!' に挑戦してみました。
開発環境は Windows(Vista Home Premium) + Python です。

1. Python をインストールする
ガイドラインに「Python 2.5 をダウンロードしてインストールしてください」とあるので
Python Official Website へのリンクをクリック。普通にリンクを辿るとPython 2.5.5 のダウンロード画面に遷移するが、ソースコードしかダウンロード出来ない模様。

Pythonのバイナリモジュール自体をビルドする環境がない(というか構築が面倒な)ので、URLの「2.5.5」を「2.5.4」に書き換えてトライしてみる。まんまと「msi」のダウンロードリンクを発見できました。

ということで、今回使用するPythonのバージョンは 2.5.4 に決定です。「msi」をダウンロードしてインストール。Twitterを見ている間に終わりました。

２. App Engine SDK for Python をインストールする
特に問題なく、リンク先から「msi」を取得できました。

これもTwitterを見ている間にインストール完了です。

3. ローカルで「こんにちは」する。
「Hello, World!」のチュートリアルに従って、リクエストハンドラ(helloworld.py)と設定ファイル(app.yml)を作成します。今回はCドライブ直下に「helloworld」フォルダを作成してその中に作りました。
次に「Web サーバーを起動します」とあります。SDKには、Webサーバーまで含まれているのですね。コマンドは「google_appengine/dev_appserver.py helloworld/」とありますが、Windowsの場合「google_appengine」までのパスは通っているので「google_appengine」は不要です。むしろ、「helloworld」の前にパスを指定してあげる必要があります。

前：google_appengine/dev_appserver.py helloworld/
後：dev_appserver.py C:\helloworld\

「Allow dev_appserver to check for updates on startup? (Y/n):」と聞かれたので「y」と答えると以下のように表示されました。警告が２件（datastoreからデータが読めない、images APIの初期化失敗）でていますが、とりあえず「http://localhost:8080」で helloworldアプリが起動しているとのこと。

早速ブラウザでアクセスしてみると、予想通り左上に小さく「Hello, world!」と表示されました。チュートリアルにある通り、Webサーバーを起動中のまま「helloworld.py」での出力を「Hello, world! Hello, everyone!」に書き換えてブラウザをリロードすると、表示も変わりました。なかなか優れものです。

4. Webアプリケーションのフレームワークを導入する(webapp)
Djangoを使ってみたいところですが、最初なので欲張らずにチュートリアル通りにGoogle独自のフレームワーク webapp を使用することにします。インストール自体はSDKに含まれているので、「helloworld.py」をチュートリアルに従って書き換えるだけです。ブラウザをリロードすれば、「Hello, webapp World!」に早変わりです。

5. SDKを通じてGoogleのサービスを利用する(ユーザーサービス)

チュートリアルでは、Googleアカウントでのログイン状態を確認しています。

ログインしていなければ、デフォルトのログインページにリダイレクトさせます。このときログイン後の戻りURLを指定することで、自アプリへ制御を戻せます。

ログイン後は、ユーザーのニックネームを取得して、動的に表示メッセージを切り替えることが可能になります。

そろそろ食事の時間なので、本日はここまでです。See you next Saturday!

2010/10/10

トノサマバッタ、ヒメアカタテハ、何かのタマゴ

本日のお散歩の結果です。
まずはトノサマバッタ。

茶色いやつが一杯いました。群生相・大群での移動が「飛蝗」です。字面からイナゴと思われる向きもありますが、トノサマバッタです。

次は、ヒメアカタテハ。

漢字で書くと姫赤立羽。英名が、Painted Lady という、ちょっと立派な名前です。世界中に広く分布しているとのこと。もちょっと近づいて撮ろうとしたら、逃げられてしまいました。

で、最後は逃げられないタマゴ。

何のタマゴかよく分かりません。昆虫のタマゴのだとは思いますが... 右の写真ではカラが破られていますね。孵ったのたか、捕食されたのか...

エクソコーテクス(Exocortex)

Exocortex／エクソコーテクス／外大脳皮質。灰色の脳細胞の外にある人工情報処理システムで、脳の認知能力を拡大するものを言うようです。
「リファクタリング・ウェットウェア達人プログラマーの思考法と学習法」Andy Hunt を読んでいて出てきた言葉です。耳慣れなかったのでメモ的にエントリー。

よく言われることですが、自動車は運動能力を、携帯電話は(視)聴覚能力を拡張し、コンピュータ(とインターネット)は脳機能を拡張します。

自動車の運転に熟達すると、運転中はあたかも車が自分自身であるかのような感覚になる時があります。脳が車を自らの身体として使いこなしているのでしょう。携帯電話は、なかった頃の生活が想像し難いほどです。みんな何の疑いもなく、毎日テレパシーを使っています。

このように身体機能の拡張については余り疑問もありません。
しかし、脳機能はどこまで拡張されているといえるのでしょうか。

いまでも、複雑で単調な計算をコンピュータにさせたり、大量のデータをハードディスクに保存したりしています。しかし車が自分の体の一部だと感じられるほどには、まだコンピュータは自分の脳の一部には思えません。今後はハードウェアとマンマシーンインタフェースの改善が進み、より脳と一体化していくのだと思います。
ことの善悪の判断は難しいですが、テクノロジーの発展を押しとどめることは無理でしょう。従って、賢く付き合っていく方法を学ぶ必要があります。

コンピュータを使え。コンピュータに使われるな。

2010/10/03

レビューチェックリストへのフィードバック

ソフトウェアの開発では、障害をDBに蓄積したり、レビュー時にレビューレポートを残すことも多いです。欠陥を記録し、修正が完了すると、ほっと一息つけますね。そこで忘れがちなのが、次の開発へのフィードバックです。定期的に蓄積した記録を分析して、レビュー用のチェックリスト等にフィードバックしていけると嬉しいですね。

2010/10/02

複雑をもって複雑を制する

母なる自然は非常に複雑で、対応が難しいことで有名です。人類は原始時代からその自然の中で生き延び、さらにはより豊かに生活するために、社会を作ってきました。当初はシンプルだった(かもしれない)社会も、時間の経過と共に発展し、複雑になってきました。そして社会が複雑になればなるほど、人類は自然に対抗できるようになり、より豊かな生活ができるようになってきました。

しかし現代社会においては、日々自然の脅威に怯えることはなくなりましたが、複雑な人間関係や利害関係のなか上手に世渡するのが難しいのも事実です。社会科学にも複雑系の考え方が導入されることから、その複雑さは推して知るべしです。かと言って、いまさら自然に怯える生活に逆戻りもできません。というか、したくはありません。つまり、自然という複雑な問題を社会という複雑な問題で制した、とも言えなくないでしょう。

もちろん、複雑な問題をシンプルに解決できるにこしたことはありません。しかし、必ずしも単純な解法が得られるとは限りません。かと言って複雑な問題に直接対峙すれば、敗れ去る可能性が高くなります。そこで次善の策として、苦手な複雑性を別の(比較的)得意な複雑性に置き換えて対応するということになります。

ここまで書いて、この話は４月に書いた「問題を解きやすいように変形する」の１ケースだと思い当たりました。う～む。この半年間で、あまり思考に進歩が見られませんな。

なお、時として複雑な解法は元の問題よりも厄介な問題を持たらします。そのことは忘れないようにしたいですね。

2010/09/19

Google Docs Drawings で透明色を使用する

（私だけかもしれませんが...）「Google Docs Drawings」で描画図形の色を半透明にする操作が、ちょっと分かり辛かったです。探せば、Google Docs のヘルプ「書式設定: 描画図形を書式設定する」にあったのですが、個人用のメモも残しておきます。

（１）[塗りつぶし] ボタンをクリックし、好きな色を選択する

（と、ダイアログが消える (￣▽￣;)!!ｶﾞｰﾝ）

（２）再度[塗りつぶし] ボタンをクリックし、[Custom Color...] をクリックする

上部の[Transparent]ではないので注意。

（クリックすると100%透過となり色は関係なくなる。 Σ(￣ロ￣lll)　ｶﾞﾋﾞｰﾝ）

（３）右端にある不透明度セレクタをドラッグする（ここは[OK]ボタンで確定）

（４）すると任意の透過率の透明色にできます　ヽ(^◇^*)/

（５）なのでこんな感じの画像が簡単につくれます

2010/09/18

抽象化と曖昧性

私たちITエンジニアは、システムやソフトウェアのモデリングを行います。最近はズバリな名称を持つUML(Unified Modeling Language：統一モデリング言語)を使用することも多いですね。
このモデリングには、抽象化が必要です。複雑な現実世界から、構築対象のシステムにとって関心のあることを重点的に選び、それ以外を捨て去ります（捨象）。

ところで、ソフトウェア開発においては、「曖昧性の除去」という課題もあります。実装時に曖昧で良く判らないことが出てくると、手戻やプログラマの独断など、好ましくない事態になってしまいます。

この「抽象化」と「曖昧性の除去」とは両立すべき項目ですが、なぜか「抽象化すると曖昧になる」と思い込んでいる人もいるようなので、簡単に整理してみました。

「関心のある箇所」まで捨ててしまっているとか、「関心のない箇所」を十分に捨て切れていないとか、そういう「変な抽象化」にたくさん出合ってきたのでは、「抽象化すると曖昧になる」と思ってしまって無理がないのかもしれません。

2010/09/04

アサガオ、イトトンボ、トリ

今朝の散歩で撮った写真をアップ。

緑色のイトトンボが印象的。
止まっていた看板も、なんか緑色に汚れて(?)います。

路地の朝顔は今日も元気そうでした。
英名「morning glory」（朝の栄光）はちょっと大仰過ぎるかと思いますが。

トリ（種類不明）には余り近付けず、遠目からの撮影。カメラの性能に難有りです。

余り書く事もないので、無意味にスーパーインポーズして終了。

（See original photos）

2010/08/29

ルトワクの戦略論に学ぶソフトウェア開発

ルトワク（Edward Luttwak）の戦略論では、戦略が５つのレイヤーに分けられています。

大戦略(grand strategy)
戦域(theater)
作戦(operation)
戦術(tactics)
技術(technology)

基本的には、上位のレイヤーが下位のレイヤーを規定しています。政治・経済を含む大戦略に適合するように戦域が設定され、戦域内での戦略目的を達成するために作戦が立てられ、作戦を遂行するために戦術を決定し、戦術に見合った兵器(技術)が選定されます。つまり、目的に合わせて手段を選ぶということです

このアナロジーをソフトウェア開発に適用すると

ビジネス戦略
IT戦略
プロジェクト
開発プロセス
技術

の５レイヤーというところでしょうか。ビジネス戦略に適合するようにIT戦略が設定され、IT戦略の戦略目的を達成するためにプロジェクトが計画され、プロジェクトを遂行するのに都合の良い開発プロセスを決定し、プロセスに見合った管理・開発ツール(技術)が選定されます。

しかし、時間の経過と共に全てのレイヤーで変化が発生し得ます。そしてその変化が上位レイヤーの陳腐化と変化を促すことも多いです。

第二次世界大戦以降の例では、航空技術の発達が洋上艦隊戦の戦術を一変させました。また核兵器の登場によって、戦術のみならず最上位の大戦略までもが大幅な更新を迫られました。つまり、手段に合わせて目的を設定する必要があるということです。

ソフトウェア開発においては、Hudsonのような継続的インテグレーション(CI)ツールの登場が開発プロセスに影響を与えています。またGAEのようなクラウドサービスが可能になったことによって、開発プロセスだけでなく最上位のビジネス戦略までもが、見直しを迫られています。

実際には上記の２つのアプローチのどちらか一つではなく、トップダウン、ボトムアップ、さらにはミドルアップダウンのアプローチの相互作用によって５つのレイヤーが決定されます。世界は複雑で常に変化していますので、５つのレイヤーが全てが変化し続けていてこそ、戦略が機能していると言えるのかもしれませんね。

2010/08/23

コーヒーブレイクテストによるタスク分割

仕事のある日は朝に１日のタスクの一覧を洗い出し、優先度の高い順から対応しています。その日できなかったものは、翌日以降に回します。言わば、GTD(Getting Things Done)の簡易版です。
この方法で胆になるのは、リスト化するタスクの粒度です。もちろん、１日で終わらないサイズのタスクを計画しても上手く管理できません。かといって、あまり細かくするとタスクリストの作成と管理に時間がとられてしまい、本末転倒です。

そこで私が利用しているのが、「コーヒーブレイクテスト」(Coffee-Break Test)です。

作業と作業の間にコーヒー休憩を入れても問題ないと思えるような切れ目があれば、別のタスクとして扱います。限度はありますが、タスクに要する時間は余り関係ありません。電話１本、５分程度で済むものから、２～３時間くらい集中して作業が必要なものまで、休憩なしで一連の作業としてやってしまうべきものは、１つのタスクと考えます。
感覚的には、10～14個くらいのタスクに分けると１日の作業がスムーズにいくように感じています。

なお、この「コーヒーブレイクテスト」は、もともとアリスター・コーバーンの「ユースケース実践ガイド」でユースケースの境界を明確にする基準として挙げられてたのを転用しました。

2010/08/22

久しぶりの英文和訳

今日、久しぶりに英文の和訳を行ないました。500Wordsちょっと位ですが、もしかしたら大学卒業以来かもしれません。
普段適当に読み流して分かったつもりでいる英文でも、一つ一つ訳をつけていくと実は正確には理解していなかったということがよく分かりました。適切な日本語の単語が思い当たらないものも多いですね。また、参考文献の記述方法などは、知っていないとどうすればよいのかわからりません。
さらに原文がWikipediaなので、リンクの処理方法等も迷いました。基本的には Google Translator Toolkit 任せですが、どうも動きにバグがあるようで（真ん中のフレームの区切りを左右に動かすと左の英語側で時々消えるセンテンスがあるなど）、どこまで信頼できるかわかりません。
さらに、原文の文構造が曖昧なものや文法間違い(?)もあり、どう対処するのかも難しいところです。

2010/08/04

バイオミミクリー（Biomimicry）

生き物からインスピレーションを得て創り出された課題解決型デザイン。

Biomimicry is the science and art of emulating Nature's best biological ideas to solve human problems.

３８億年に及ぶ地球生命の試行錯誤の結果を、学んで活かさない手はないですね。

先日写真を撮ったハスの葉からは、自己洗浄機能のある塗料が生まれています（ロータス効果）。

その他にも、JR西日本の新幹線がフクロウやカワセミに学んだことも有名ですね(カワセミの写真)。
私の頭ではまだソフトウェア開発への応用は思いつきません。ありきたりですが、アリやハチなどが少数のシンプルなルールの組み合わせだけで複雑で美しい作業を大勢で連携してやってのける仕組みなどは、コミュニケーションや開発プロセスの参考になるかもしれませんね。
アトランティック大学(COA)のデルタプロジェクト2010におけるJanine Benyus氏の基調講演がYouTubeに公開されています。アメリカの大学の講義なので、１時間半と長くかつ英語ですがおすすめです。

Janine Benyus - Nature's Blueprints: Biomimicry in the Built World

2010/07/31

夏の山田池公園#2

今朝の山田池公園の続きです。

まずは、モミジアオイ（紅葉葵）です。

モミジというのは、花ではなく、葉っぱが大きく５つに裂けていることに由来するようです。
アオイ科のハイビスカスの仲間です。どことなく南国風の顔つきですね。

お次はハス（蓮）です。

子供(あるいは中トトロ)なら傘にできそうな葉っぱです。茎が私の身長よりも高くその上に花が咲いているので、残念ながら横からしか写真を取れませんでした。ちなみにレンコンはこいつの地下茎ですね。

夏の山田池公園#1

今朝撮ってきた写真から、まずはサルスベリ。

花の色は、白とピンク(紅)と２種類ありますが、ピンクの方が有名(？)なので、今回はピンクです。長く花が咲くことから「百日紅」とも呼ばれます。紙風船のようなラインの入った蕾が面白いですね。

お次は、ガマ（蒲）です。

水辺に群生しています。ガマの穂は円柱形で、ソーセージか秋田のきりたんぽを思わせる形です。雄花と雌花が離れているのでヒメガマだと思います。
花粉は黄色く、集めたものはホオウ(蒲黄)という生薬として古くから使われています。外用で傷薬となるとのことで、古事記の「因幡の白兎」の話では、ワニ(サメ？)に毛皮を剥がれた兎が蒲黄で傷を癒しています。味には甘みがあり(?!)、飲めば利尿作用があるようです。

これはトンボ（蜻蛉）です。おそらくはシオカラトンボでしょう。

2010/07/24

状態を減らしてテストケースを減らす

状態遷移とテストケースで書きましたが、「Inputs * States = Outputs = Test Cases」です。であれば、入力や状態を減らせば、テストケースも減ることになります。今回は状態を減らすことを考えてみます。

プログラムにおいて「変数」は「状態遷移するオブジェクト」であり、「変数への値の代入」は「状態遷移」と言えます。オブジェクト指向プログラミングではデータはメソッドによって隠蔽されますが、メソッド呼び出しにより内部データが変更されればそのオブジェクトの状態が遷移したことになります。

では、状態を減らすにはどうすればよいでしょうか？

状態（とその遷移）の絶対数を減らす
- オブジェクト（＝変数）の数を減らす
- オブジェクト（＝変数）に代入する値のバリエーションを減らす
- オブジェクト（＝変数）への代入回数を減らす
状態（とその遷移）の相対数を減らす
- オブジェクト（＝変数）の寿命を短くする
- オブジェクト（＝変数）のスコープを狭くする

1. 状態遷移の絶対数を減らす
純粋関数型言語のように言語自体で高い参照透過性が保証されている場合は別ですが、手続き型言語（やそこから発展したオブジェクト指向言語）を使用している場合は、アプリケーション全体で状態遷移を大幅に減らすことは難しいでしょう。クラスのメンバ変数を変更するメソッドが書けなくなったりします。

2. 状態遷移の相対数を減らす
たとえソフトウェアの起動から終了までに膨大な状態遷移があったとしても、Input があった時の可能なStateの数が少なければ、そのInputに対するOutputs(=Test Cases)も少なくてすむということです。こちらは絶対数を減らすのに比べて簡単です。

プログラム入門者向けの書籍にも「グローバル変数を無闇に使うな」とか「関数は長くし過ぎない」など、よく書かれています。ソースコードの可読性を高めることで、バグの混入を予防したり、バグ修正や機能追加等の保守を容易にするという文脈で語られることが多いように思いますが、テストケースの数を減らせるというご利益もあるわけです。

2010/07/10

グリーンIT, Green Computing

ふと、環境に優しいソフトウェアって一体何なのか、と思っていくつかに分類しみました。

環境に優しいことを目的としたソフトウェア

電力使用量を最適化する
ペーパーレス化を支援する
ガソリンエンジンの空燃比を最適化する

アルゴリズム的に優れた効率の良いソフトウェア

ハードウェアへのアクセスが少ない
CPUに負荷をかけない
通信量/頻度が少ない

UIのシンプルなソフトウェア

無駄にアニメーションしない
無駄に音を出さない
無駄な機能がない

品質の高いソフトウェア

不具合がない（対応に必要な資源はえてして多量）
ソースコードが読み易い
ソースコードが変更し易い

で、横道に逸れますが、このブログを書くにあたってWikipediaを参照したのですが、日本語版(グリーンIT)と英語版(Green Computing)とでの情報格差が怖いです。日本語のページは情報量が少ないだけでなく、ソフトウェアについての言及もありません。「手法」の項ではハードウェアについての話ばかりです。英語のページには「Algorithmic efficiency」の項があり、「ハードウェアの価格がエネルギーコストに比べて相対的に下がってくるにつれて、アルゴリズムの効率性が重要になってくる」などと色々書いてあります。

2010/06/28

雨上がりのクチナシの花

今回はこの一枚だけ。

雨上がりのクチナシの花。
年末におせち料理の一品として作る「栗きんとん」に使うのがこの木の実です。英名のGardeniaはガーデン＝庭を連想してしまいますが、スコットランド生まれのアメリカの自然科学者のDr. Alexander Garden (1730-1791)の名前からとられたそうです。

2010/06/26

実現間近(?)のコンピュータ高性能化技術

何のめぐり合わせか、日経サイエンス2010年08号の「NEWS SCAN」で、コンピュータの高性能化に繋がる近未来の技術が３つも取り上げられていました。半導体産業の端っこに住まう身として、まとめて紹介します(括弧内は元記事のタイトルです)。

高速動作の不揮発性メモリ（ReRAMデビューへ一歩）
高密度記録の光ディスク（光で金属と半導体を行き来する)
低熱損失のトランジスタ（接合なしの新トランジスタ）

1. 高速動作の不揮発性メモリ（ReRAMデビューへ一歩）

確かにDRAMなみの高速動作が可能な不揮発メモリができれば、省電力化できますね。安くて高速なのは揮発性メモリ、という常識(?)を疑ったことはなく、盲点でした。
記事中でもWikipediaのReRAMの項にも書かれていますが、シャープ/サムスン/インテル/富士通などが実用化向けて研究中です。モバイル端末にとっては朗報ですね。

2. 高密度記録の光ディスク（光で金属と半導体を行き来する)

記録密度はブルーレイディスクの360倍だそうですが、面白いのはその表面積と体積の関係からくる仕組みです。
物質の表面と内部とでは原子の振る舞いが異なります。通常は表面の原子量は内部の原子量に比べれば微々たるもので、無視できます。しかし直径が10nmを切ると、10%程度の原子が表面に出てきて物質の結晶構造が変わってしまいます。それで今までになかった、光を当てる毎に金属半導体になったりするやつが出てきたようです。

3. 低熱損失のトランジスタ（接合なしの新トランジスタ）

トランジスタのサンドイッチ構造が微細化限界にきているので、サンドイッチ構造はやめて１種類のドープ半導体だけを使ってトランジスタを作るという話です。低電圧で動作し、熱損失も少なく、動作速度も速いと良いことづくめです。
さらに、既存の半導体プロセスを利用出来るということで、ムーアの法則が復活するかもしれませんね。

2010/06/15

ビジネス文書の要諦

The Elements of Business Writing　Gary Blake, Robert W. Bly
前に読んだ"技術文書の要諦"の姉妹版をようやっと読了しました。
短くてわかりやすく、かつ読み手を説得するに足る文章を書こうということです。まあ、それが難しいのですが。
ざっくりまとめると、短い文章を書くコツは