いまさら聞けないAdobe AIR「超」入門（1/4）- ＠IT は「AIR とは何か」を知るには良い記事なっているようです。ただ、JavaScript を使っている身としては、Flex Builder を使えば・・・という開発環境はちょっと面倒です。

JS 使いなら、クジラ飛行机さんが書かれている AIR に関する連載「八角研究所 : JavaScript使いのためのAIR入門(1)」の方が身近に感じられるかもしれません。オフラインアプリや jQuery との連携など JS 使いにとって実践的な内容が紹介されています。

などと、勝手に宣伝してしまっていいのだろうか。
ToDo：「後で了解を取る」

今、Kodougu の dojo を 0.4.3 から 1.0.1 に上げる作業をしています。その過程で見つかったちょいネタです。DojoX に含まれる Dojo Strage は Google Gears をラッピングしているそうです。夢が広がるなぁ・・・。

例：

dojox.storage.put("someKey", "someValue");

SQL 直打ちも可能：

var results = dojox.sql("SELECT * FROM DOCUMENTS");

情報元は The Book of Dojo です。
http://dojotoolkit.org/book/dojo-book-0-9/part-5-dojox/dojo-offline/storing-offline-data

■ 追記（2007/12/5 15:48）
以下から読み始める方が、理解が深まります。
http://dojotoolkit.org/book/dojo-book-0-9/part-5-dojox/dojo-offline

八角研究所で書いた技術記事の紹介です。Kodougu でユースケース図を実装した時に、include、extend、汎化の使い方を整理した記事を書きました。

ユースケース図は誤用が多い図というか、結構よくわからない図です。extend、include、汎化を多用していると、何を書いてあるのかよくわからなくなる場合も多く、それぞれの意味を正確に把握している人も多くないように感じます。クラス図が最もポピュラーでありながら、正確に使用できる人が少ないことと同じかもしれません。

UML に関係したモデリングツールの開発に携わるのは、非商用含めてかれこれ 5 本目くらいなのですが、その私も理解はかなりあいまいです（オイオイ）。そういう事情もあって、include、extend、汎化の使い方を整理した記事を、Kodougu の仕様検討という形で書きだしてみました。

ユースケース図の extend は必要か？
http://www.hakkaku.net/articles/20071107-66

UML の参考書片手に読んでいただければ幸いです。特に、私も執筆にかかわったその場でつかえるしっかり学べるUML2.0 が最も優れていると思います。（私は 5% くらいしか書いていませんが。。。）
# 手前味噌・・・とか言わないで！(^^;

shi3z 氏のマシン語関係のエントリを読んでいたら、久々にアセンブリ言語で書かれたプログラムを読みたくなったので、かつて自分が書いたコード（Delphi のインラインアセンブラですが）を読み返していました。まだ書けるかどうかは怪しいですが、読むことはできるようです。10 代のころにやったことはなかなか忘れませんね。

さて、shi3z 氏の言わんとしていることはわかりますが、IT もこれだけ複雑になると、「××が必須」というのはなかなか難しくなるのではないかなと常識的な反応をしてみます。SE なら、会計知識だったり、物流の仕組みだったり世の中のことを知っているほうが重要な場合もたくさんあります。

思うに、システム作る人ってあまり生き残らない気がするのです。パッケージを利用したり、SaaS（この言葉自体は微妙ですけど）だったり。SE の仕事は何を使えば業務が遂行できるか判断するのとツールのカスタマイズが主な仕事になるのではないかとさえ思います。組み込みやゲームは違うかもしれませんけど。もっともそういう人は、SE じゃなくて IT コンサルとか名乗っていくのかもしれません。

パッケージや既存システムに問題があったらサポートに連絡です。これは MySQL だって一緒です。大体、企業でオープンソース製品が話題になるのは、オープンソース製品が重要というよりは、製品サポートビジネスが立てたい人たちが仕掛けているところもあると思います。コードの中身が公開されていて安全ですよ、しかも弊社のサポートがあるので何があっても大丈夫です、みたいな感じで。

結局サポートに頼るなら MS だっていっしょじゃん！
# パッチリリース速度なら MS だって OSS に負けてないし。

そういうこともあるのか、昨今の SE はアセンブリ言語どころか、複数の言語を操れない人さえいます。プログラミングわからない IT コンサルを何とかしてくれという人もいますが、彼らは彼らでないと困る様々なスキルを持っています。

この手の議論は、SE は理系出身でないと務まらないかどうかという話題に近いと思います。これだけ複雑化してきた世の中なら、お決まりの文句になりますが、「いろいろな人が必要なんだから、それぞれの専門を尊重しながら仕事しましょうね」ってことになりますかね。何かひとつふたつベースになるものを身につけてくださいってことで。（で、これらの人たちがコミュニケーションするにはモデリングが欲しいよねってことで、Kodougu をよろしく！）

でも、作る側に残りたいのなら、アセンブリくらいやっとかないとね。というわけで、MySQL とかの中の人になりたい人は必須でしょう。

複雑な GUI を持つアプリケーションの設計について（Web アプリ編）を書いていたときに見ていた本は POSA 本だったのですが、以下のエントリでも同じようですね。

Flex2におけるアーキテクチャパターン @ 2007年08月 @ ratio - rational - irrational @ IDM

少なくともPACでいうAgentの開放/閉鎖は意識したほうがよさそうで、それだけでもイベントでワケワカになるのはかなり解消できます。

続報を強く期待します。Flex2 の固有事情とかもありそうです。

PAC で対処しやすい問題と対処しにくい問題があるから、その辺をどう考えるかですね。私はモデリングツールの開発経験が多いのですが、この種のアプリでは、構造ツリーとダイアグラムウィンドウという大きな枠組みがある場合が多いです。こういう大きな枠組みがあると、その単位で Agent を認識できるので、PAC の適用可能性が高く、スパゲティ対策に有効に働きます。

問題は、PAC が対応していない複雑性をどう制御するかでしょうか。たとえば、GUI アプリの状態やモードによって、中間レベル、下位レベルの Agent の枠を越えたアプリの制御を行わなくてはならなくなる場合があります。こういう場合、より上位の Agent に記述しますが、結局そのレベルの Agent の肥大化を招くことになります。これは、フォームやウィンドウのサブクラスを実装するタイプの開発スタイル（VB、Delphi 型）でよく遭遇します。

で、まだ整理されていないようですが、上記エントリに書かれているイベント翻訳（この言葉、知りませんでした。例外翻訳は聞いたことがありましたが。）や Command の適用などの話が出ていますから、その辺に対応策がありそうです。どういう解決策があるのか楽しみですね。

所詮さじ加減といわれるとそれまでですが・・・。(^^;

秋葉原のザ・コンピュータ館が閉館されるらしいです。知らなかった・・・。10年前は、秋葉原といえば、ザ・コンだっただけにショックです。もっとも、ここで PC を買ったことはないような気もしますが。(^^;

ラオックス、旗艦店「ザ・コンピュータ館」を閉館へ－経営再建で - アキバ経済新聞 - 広域秋葉原圏のビジネス＆カルチャーニュース
http://akiba.keizai.biz/headline/575/index.html

ここの書籍スペースは IT 系では最大クラスなので、職業柄重宝していました。でも、言われてみると、最近は専門書も Amazon で買ってますし、私は PC は元々大手ではなく、ショップブランドか自作なので、ザ・コンが閉まっても影響はありません。

まぁ、そういうことなんでしょうね。。。

以下の記事について非常に頷けるものがありました。

小野和俊のブログ:IT業界の大企業での生々しい話を5つほどより

1. 2ch へのアクセス禁止で開発効率が大幅に低下
＜中略＞
2. 人事評価制度の歪みを解消するためにあえて優秀でない人材を採用
＜中略＞
3. 社内では使われない自社パッケージ
＜中略＞
4. 競合他社への販売禁止を条件に出されパッケージ販売を断念
＜中略＞
5. IPAのプロジェクトで間接業務に忙殺される

1, 2, 3 については、私にも経験があります。1 についてですが、2ch はともかくとして、会社の枠を越えた（仕事に関係する）横のつながりを重視する人としない人とで意見が分かれてくると思います。少し文面の内容とはずれますが、プライベートはともかくとして、仕事面で会社で枠を作ってしまうことで、活動の幅を狭めている人は多い気がします。
（そういう人がわりと悪気なしにこういうコミュニケーションを阻害する仕組みを作ってしまうんですよね。）

2 ですが、優秀でない人材云々はともかくとして、人事評価は相対評価なので、仕方の無いことだと思います。ま、高く評価されない変わりに、低く評価もされないということです。私のように独りものならともかく、養わなくてはならない家族がいる人には、リスクが低いほうがいいと思うので、これはこれでアリなのかなと考えたりもします。

3 は・・・以下、まったくおっしゃるとおりです。(--;。

保守の問題があるから簡単には捨てることはできないかもしれないが、そんな状況なら少なくとも新規の販売は差し止めた方がよいのではないかと思う。自社でも使いたくない製品を買わされる側はたまったものではない。

5 について・・・未踏は恵まれてるんですね～。実際、未踏では間接業務に費やす時間はほとんどありません。その上、プロジェクト管理組織というある意味雑用を一手に引き受けてくれる方がいらっしゃるので、開発者は本当に楽です。

久々に IT 業界のどろどろとした話を思い出しました。(^^;

最近私が実践している「くそエディタ」を立ち上げる方法について。

「くそエディタ」については以下を参照してください。

射撃しつつ前進 - The Joel on Software Translation Project
http://local.joelonsoftware.com/mediawiki/index.php/%E5%B0%84%E6%92%83%E3%81%97%E3%81%A4%E3%81%A4%E5%89%8D%E9%80%B2

このやり方は Windows にのみ対応しています。でも別に他の OS でも実践できるでしょう。［スタート］-［すべてのプログラム］-［スタートアップ］にエディタもしくは IDE のショートカットを追加します。すると、PC を起動すると、勝手にエディタが立ち上がってくれます。間違っても、スタートアップでメーラやブラウザを立ち上げないこと。

わーい、これでたくさんプログラムが打てるぞ！

mixi の日記に外部のブログを設定すると、非常に使い勝手が悪いわけですが、以下のブログにローテクですがとてもいいやり方が載っていました。

小野和俊のブログ:mixi で外部ブログを使っている人への提案より

だが、仕様は変えられなくてもストレスを回避するための方法を考えることができる。そこで提案したいのが、外部ブログを使っている人は、設定自体はミクシィ日記にしておいて、外部ブログに記事を書いたときには概要とリンクをミクシィ日記に書く、という運用面でのワークアラウンドである。記事が短い場合にはリンク自体張らずに内容を全部貼り付けてしまい、記事が長かったり、記事中にテーブルがあったりする場合には概要とリンク先 URL を貼り付ける。

確かに手間なのですが、読み手にとってはとてもいいやり方だと思います。早速これから実践してみます。

以下のエントリを読んで少し気になることがありました。

Collection & Copy - 日記 2007-02-9、ブログを書くことより

「ブログに載る新しい情報も、企業の中ではもうずっと前から使っていて、あたりまえになっていることがよくある。技術を専門に研究する人たちもいて、金もある。そして、そこで生まれた知識は社内だけで共有される。」

こういう発言に嫌悪感を示すのはそれはそれでいいのですが、少し冷静に考えて見ましょう。そもそも社内の技術共有ってそんなにうまくいくのでしょうか。私は以前の会社で、上記で言うところの専門に研究する人っぽい仕事をちょこっとだけしていたことがあります。その経験上、得た知識を社内に広めようとすると、会社という枠内の活動では非常に薄まったものしか広められないという現実に突き当たったことがあります。

つまり、以下のエントリに同意です。

yosisの日記より

「確かに"技術を専門に研究する人"はいるが、"ブログに載る新しい情報"→"企業：当たり前"ではない。 　また、"そこで生まれた知識は社内だけで共有される"は嘘。社内でも共有されない。」

ブログ、勉強会、オープンコミュニティの活動では非常に濃い密度の情報交換が行われます。これだけ濃い共有が土日にできるのに、平日にはこんな薄い情報の共有しかされないのかと驚いた記憶があります。

これは、モチベーションの違い・・・ということなのでしょうか。誰かが調査してそれを社内で共有という理路整然としたプロセスに無理があるのかもしれません。