2008年12月17日水曜日

問題フレーム

マイケル・ジャクソンの問題フレームは, 原著を何回か読んだことしかないのだが.

某研究会にて, 日本における問題フレームの巨匠のひとり, 大槻さんから問題フレームの極意 (の多分ごく一部) を伝授される.

  • 問題フレームの極意は額縁に入れて掲げよ
  • 問題を要求とドメインと機械に分けて考えよ
    • 系 - 要求仕様書ではなく, 要求書とドメイン記述書と仕様書を書け
  • 問題フレームとは問題のスコープを切り取る枠を与えるための方法論である

問題フレームは, プロセスとしては静的で一方通行的である. でも問題と現実の相互作用によって, 問題フレームが平衡状態に落ちたときが問題が「完成」したときと言えそうだ. もちろん発散したら, それは悪い問題だったか, プロセスが間違っていたかのどちらかだ.

2008年12月3日水曜日

サービスのアーキテクチャ

と言うわけでこの 2 週間, Unix 系のいわゆるサーバをいじってきたのだが.


サーバはサービスの集合体だ. だから次のような性質を持たなければならない.



  • モジュール性


  • コンパクト性


  • 独立性


  • 接続性


  • 同一性


でも Unix (Windows でも同じだろう) 上に載っている多くのサービスはこれらの性質を満たしていない. だから何かあったときに復旧するのが大変だ.


モジュールは, 論理的なサービス単位に対応する物理的単位 (ファイルとか). これが明確でない. 例えば imap サービスを構築するモジュールがどれか, 明確に & ソフトウェア的に定義されていない (ドキュメント読めばいいというのはなしね). だからどれを戻すと復旧するのか分からない.


コンパクトとは, モジュールが集中していること (高い凝集). 例えば imap だと /var/imap も必要だし, /var/spool/imap も重要で, 両方が正しい構成で揃わないと正しいサービスが動かない.


独立とは, 他のサービスへの依存がない/少ない/明確であること (低い結合). imap はそれ以外のいろんなサービスや定義ファイルやコマンドに依存している. その一部はパッケージ・マネジャが解決するけど, それはインストール時だけ.


接続とは, あるサービスを使うためのインタフェイスが明確に & ソフトウェア的に定義されていること. もちろんドキュメントには書いてある. けどそれでは複雑すぎるし, 人ががんばらなくちゃいけない. 何を変えるとどう変わるか分からない.


同一とは, あるサービスに (ユーザから見て) 同じ状況である依頼をしたら, 同じ仕様を満たす答えが返ってこなければならない. ある時点では 2 年分のメイルを検索できたけど, しばらく立ったら今週のメイルしか検索できない, というのはサービスではないのだ.


これらを何とかするためにいろんな手は打たれている.


MacOSX Server だとサーバ管理, 一般的には Webmin のような抽象的なインタフェイスを作る. でもこれは運用管理だけだ. しかも抽象度は高くない.


サービスごとにハードウェアの境界を切る. いわゆる仮想環境もそうだし, クラウドもそう. これならばサービスはマシンに閉じ込められるので, インタフェイスは単純 (プロトコルだけ) になるし, いざとなったらマシンごと取っ替えればいい.


もっと細かい話しも入れれば, 僕は Unix をいじってきた二十数年の間にものすごいノウハウと改良の積み重ねは確かにある. Unix 系サーバは長い歴史の中で創発的に作られてきたものなので, なかなか難しいのは確かだ. けど, サービスのアーキテクチャはない, あったとしても貧弱と言わざるを得ない.


今 Web 系のサービスで広く使われているものの多くは明確で単純なプロトコル・インタフェイスを持つものだ. 例えば Gmail は smtp と imap にだけ依存している (うそ. それは言い過ぎ:-). インタフェイスはプロトコルだけじゃない. モデルもインタフェイスだし, 言語 (DSL) もインタフェイス.


さて, SOAはこの教訓を乗り越えることができるのか.


Unixだって, できた頃はすごかったのだよ.



2008年11月30日日曜日

MacOS X Serverさようなら

WebObjects を使っていたこともあり, サーバの運用にコストと時間を取られたくなくて, うちでは MacOSX Server を使ってきた. しかし.


11/17 に続いて, 11/29 に Apple のソフトウェア・アップデートの後, MacOS X Server が壊れた. 今回は再起動すると OpenLDAP の設定内容がみごとに吹っ飛んでいる. その後も動かしているとだんだんファイルが消えていく.


うーん.


mac mini をサーバとして 3 年以上も使い続けたせいでハードウェアがおかしくなったのか (TechTool Pro による診断では異常なし), ソフトウェアがおかしいのか.


前回のクラッシュ時は CCC (Carbon Copy Cloner) でバックアップを取っていたので楽勝, のハズだったのだが, CCC のバックアップは bootable じゃなかった... 使用直後には bootable であることを検証していたのに.


で, 今回はこれに凝りて Timemachine でバックアップを取っていたのでクラッシュしても楽勝, のハズだったのだが, 何と肝心の /var/spool/ がバックアップされていないではないか!!!


# どうもそういう仕様らしい. しかし spool がまったくバックアップ対象にならないのならばサーバを毎時バックアップする理由がないではないか


いい加減嫌になったので, Google の軍門に下り, メイルとカレンダを Google Apps に移行する. サーバ・マシンを買いに行く手間も費用も要らない. 実際の使い勝手は使ってみなければ分からないが.


インタネットの黎明期からさまざまなサーバを動かしてきたが, もはや自前でサーバを運用する時代ではなくなったということなのだろう.



2008年10月16日木曜日

MagicDraw goes wrong?

2001年のversion 4の頃からMagicDrawというUMLモデリング・ツールを使い続けてきた. 最初はProfessionalバージョンが$568と大変安かった (その頃は何十万円かするRational Roseくらいしかなかったのだ). シンプルだけど, UMLメタモデルがよく見通せるような, 使い勝手の悪くないツールだった.


それ以来, 毎年保守料という名目で$159とか, $319とかずつ払ってきている. ライセンス内容も少しずつあがってきた. いや, 自分でアップグレードしたのもあるんだけど (SysMLとかフローティング・ライセンスとか), 向こうから勝手におまけしてくれたライセンス(Rational Requsite Pro用アダプタとか) もあるのだ. そんなの僕は使わないのだけど, まぁ保守料も取らないし, それならまぁいいわけですよ.


(SysMLも最初は無償で付いてたんだけどなぁ. そういえばEnterpriseへのアップグレードも向こうからのオファーだったような...)


しかし! 今年は保守料がやけに高い! 向こうが勝手に付けてきたおまけにまで保守料を掛けて来て, $617ですよっ. 最初のバージョンの値段より高いではないですかっ.


いやぁ悪くなかったんだけどなぁ, MagicDraw. UIもよくなってきたし (ちょっと重くなっちゃったけど). でもこの世知辛い世の中, こんなお金は払えないよなぁ. 仕方ないから今年中にある (はずの) version 16へのアップデートを最後に, 保守料の支払いは打ち止めとしますか... もちろん保守はなくても, 使い続けますけどね (しばらくはプラットホームが変わることも, UMLの仕様が大幅に変わることもないでしょう).



ArchiMate

最近, と言ってもこの何年か, ビジネス・モデリングやエンタプライズ・アーキテクチャにも関心が寄せられるようになって, ビジネス・モデルやエンタプライズ・アーキテクチャをどういう表記で描くかもあちこちでお賑やかだ.


UMLでいいんじゃねえかと言うのも居るし, BPELだのBPMNだのというのもあるし, EA側から言うとTOGAF (これはどちらかというと表記法というよりはプロセスだ) やDoDAFなどもある.


というところに, 最近ArchiMateという表記法を見つけて, これがなかなか軽量で悪くないような気がするんだけれど, どうだろう. ArchiMateは, 明確な表記法を持たないTOGAFと仲が良さそうだ.


OmniGraffleやVisio用のステンシルがある.



SPEM 2.0

SPEMとはSoftware Process Engineering Metamodelで, 「すぺむ」とか「えすぺむ」とか読むのかな. 要はソフトウェア開発プロセスそのものをUML (拡張) で表記するためのOMG標準だ. 2002年に1.0が出ている. その頃は日本ではあまり使われていなかったけど, ソフトウェア開発プロジェクトを担当したり, コンサルしたりすると, プロジェクトごとに, あるいは会社ごとにプロジェクト経営やプロセスが異なるから, それを表したり, 改良したり, 提案したりするのに, 便利だった. 仕様が100ページ足らずで, まぁプロセスという分かりにくいものを表すのだから, わかりにくい部分もないわけではないけど, それなりに理解しやすいものであった.


ところが今年2008年の4月にSPEM2.0が出た. これが一挙に200ページを超えた. しかも非常に細かい話になっている. ぺらっと見て分かる, という具合には行かない.


実はSPEM2.0はEPF (Eclipse Process Framework) というプロセス・ツールのベースになっているのだな. なのでSPEM2.0はEPFを頭に置いて読まないといけない. ツールが先にあって, それで使うための (メタ) モデルなのである. これがいいことかどうか, よく分からんが, まぁメタモデルだけが定義されていて, 誰も使っていない, ツールもないと言うのよりはましなのかもしれない. 「モデルは動くべき」なのだから.


# それはそれとして, EPF, MacOSXでも動くようにして欲しいんですがね.



NoteShare

その昔, NeXTStep上で動くキラー・アプリケーションの一つにMillennium SoftwareのNoteBookがあった. 開発用のツール (もちろんInterface Builder!) やNeXTStepに付属するアプリケーション (Mail, Librarian, Editなど) を除けば, LotusのImprov (多次元スプレッド・シートと言えばいいのか?), LightHouse DesignのDiagram! (OmniGraffleやVisioの祖先だ) とこのNoteBookがNeXTStepの上で生活するのに欠かせないソフトウェアだった. 逆に言えばこいつらのおかげで僕らはNeXTStep以外の環境では生きていけない身体 (頭) になってしまったのだ. 今から十数年前 (NoteBookが発表されたのは1993年のことだ) に, 僕らはもしかしたら今の計算機環境とさほど変わらないくらいの (いや, 今のOfficeよりは完全に勝っている!) すごい知的生産性を上げていた.


NeXTStepはその後, MacOSXになり, NoteBookはAquaMindsのNoteTakerとCircus PoniesのNoteBookに分裂した. たぶんどちらも同じNeXTStep/AppKitのコード・ベースを引き継いでいる. どういういきさつがあったかは知らないけれど, Millenniumを経営していたScott LoveとJason Adams (その前はNeXTの従業員だった. NeXTはシリコンバレーで人材の供給元で, ex-NeXT clubという元NeXT従業員のコミュニティもあった) がそれぞれAquaMindsとCircus Poniesを立ち上げたのだった. そして僕は今も毎日NoteTakerを使い続けている. NoteBookではなく, NoteTakerを選んだ理由はNoteTakerの方が早く日本語が使えるようになったとか, そういう単純な理由だったろう.


NoteTakerは基本的にはマルチ・ページのアウトライナだ. どんなファイルやデータでも放り込める. 索引を勝手に作ってくれる. タグを付けられる. Webにパブリッシュすることもできる. こういうだけだとたいした機能はないように思えるかもしれないけれど, シンプルなものこそ道具として使いやすいし, 十数年にわたって作り込まれてきた使い勝手もよい. 僕はこれで1995年以来のライフ・ログを取っているし, マニュアルや仕様書, 技術資料のほとんどをこれで作っていた時代もある. ま, 使ってみなはれ.


そのNoteTakerが最近, また進化の階段をひとつ上った. NoteShareという分散共有の技術を実現した. NoteShare Serverを立ち上げてノートブックをそこに置いておけば, ネットワーク経由でみんなでノートブックを編集できるのだ. MacOSX以外のプラットホームからはWebブラウザ上のJava Appletビューアがある (今のところは編集はできない). これは面白い. こういうことは昔からみんな考えていたわけだけど, 実際にはあまりうまく動かないものも多かった. NoteShareはよく動いている. 今ならたったの$50だ. NoteTakerとセットで$100.


で, 言いたいことは何かというとNoteShare Server (NoteShareも同じ) は些細なバグのため, 日本語環境ではうまく動かないと言うことだ. NoteShare Serverを動かしたい場合はNoteShare Server.appを右クリック, 「パッケージの内容を表示」して, Contents/Resources/Japanese.lprojを捨てるか, 名前を変えるかしてくれ給え. メニューなどは英語表示になってしまうけど, 日本語の読み書きはできるし, サーバとして使う分にはほとんど関係ない. いや, 実はそこまでしなくてもどれかのnibファイルのメニューのアクションがnullになっているとか言う話なので, それを直せばいいのだが, どれを直せばいいのか, nibの中を探すのは面倒なので:-) Aquamindsには言ってあるから, 次のバージョンではたぶん治るだろう.


Webで探しても日本語でNoteShareについて書いているものがあまりに少ないので書いてみた. 日本ではこういうイノベーティブな技術はみんなあまり必要としないのだろうか?



2008年5月13日火曜日

Plone3.1用initスクリプト

Plone-3.1.1-UnifiedInstallerに含まれているRedHat - FedoraCore用のinitスクリプトは3.0-buildout用のままで, そのままでは使えない. そこで以下のように変更すればよい (ただしここに挙げているのはZEO版のみ). init.dの設置の仕方などはREADME.txtにあるとおり.


最初の方にある


clusterpath="/opt/Plone-3.0-buildout/zeocluster"



clusterpath="/opt/Plone-3.1/zeocluster"

に変更する.

さらに


${clusterpath}/server/bin/zeoctl



${clusterpath}/bin/zeoserver


に (start, stop, statusの3行あり) 変更する.


同様に


${clusterpath}/${client}/bin/zopectl



${clusterpath}/bin/${client}


に (start, stop, statusの3行あり) 変更する.


多分これで大丈夫 (CentOS-5ではちゃんと動いている).



2008年5月12日月曜日

FUNCTIONALITY IS FREE

「機能性はただである」


Phil Crosbyが1970年代末に「品質はただである」と言ったのをパラフレーズして少し極端なことを言えば, 2000年代末, 「機能性はただである」.


今, ソフトウェアを開発するのは機能性を提供するためだということになっている. 「こういう機能があったらいいな」と思って, それを実現するためにソフトウェアを作る (何たって見積もりに使うのがファンクション・ポイント = 機能点だもんね). 確かにそういうソフトウェアは今もこれからも無数に存在するだろう. けど, ソフトウェアで機能を実現するためにはその裏にある「様相」をかたちにしなくちゃいけない.


「様相」というのは, ドメイン・モデル, オントロジ, 背景知識, 文化が作るテクスチャのようなものだ. ソフトウェアの本当の仕事はそれらを (任意の時点では不完全にしかできないけど) かたちにすること. それらが (よいアーキテクチャで) かたちにできていれば, そこから「機能」を作り出すのは (ほとんど) ただ. 本当ならばユーザにでもできる仕事でなければならない.


様相については改めて書いてみたい.


参照




2008年2月24日日曜日

Leopard Graphics Update 1.0が危ない件につい

先日Leopard Graphics Update 1.0が出たわけだが, うちのPowerMacG5では, これのせいでJournlerで何か (WebArchiveとかPDFとか) を見ようとするたびに画面が固まる (リモート・マシンからシャットダウンするしかない!) 羽目に陥った. ただし, ほぼ同じ環境でもMacBookではこの症状は出ない. またJournlerはたまたま引っかかっただけで, 特に悪いことをしているわけでもないように思える.


/var/log/system.logを見ると固まるときに


NVChannel(GL): Graphics channel exception! status = 0xffff info32 = 0xd = GR: SW Notify Error


などというエラーを吐いている.


世間を眺めてみると, このアップデートは他にも何かと災厄を引き起こしているようである.


Leopard Graphics Update1.0を掛けようとする方はご注意を.


もし運悪く上のエラー・メッセージを見るはめに陥ったら, Leopardを再インストールすることになる (旧システムをアーカイブし, ユーザ・データなどは保存するモードでよい). 時間がかかる.


NVRAMとかPRAMをクリアするとよいという説もあるが, 気付いたのが遅かったので試してない.


# 丸一日半潰しちまったぜ.



2008年1月20日日曜日

timemachineが重い件について

TimeMachineはバックアップのやり方としては, アップルらしく思い切った, なかなか良いものだとは思うんだけど, さすがに毎時間は重い. うちのG5 1.8GHz singleだと, TimeMachineとSpotlightが動き始めると, 仕事にならないし:-)


おまけに, 僕はデータの類を貯めるのにDVD大のdisk imageを多用しているんだけど, これが負担になる.


そこで...


TimeMachineはLaunchDaemonで動いているということなので, /System/Library/LaunchDaemons/com.apple.backupd-auto.plistをいじることにする. 書き方は, % man launchd.plist すれば分かるはず.


StartIntervalを長くするのが一般的だろうけど, StartCalendarIntervalを設定すれば一定の日時に動かせる. こっちの方が普通のバックアップの概念に近い. どちらの場合も, 実行すべきときにマシンが寝ていたら, 起きたときに実行してくれる.


Nice (スケジューリングの優先度を変える - この場合には多分下げること) も掛けられるけど, TimeMachineの場合にはこれはどうかな... やってみないと分からない.



2008年1月4日金曜日

ビジネス

1970年代のイギリスにIslandとVirginという音楽レーベルがあった.


Islandはその名前の通り, 「島」の音楽 (例えばその当時メジャ=グロバールではなかったレゲエなど) に特化したレーベルだった.


一方Virginはファン向けの通信販売から出発したレーベルだ. Virginの元のオーナーのリチャード・ブロンソンは今やヴァージン・アトランティック航空のオーナーでもあり, 気球で飛んだりする変な伯父さんであったりもする.


どちらも「変な」レーベルであったのは間違いない. そして思春期だった僕はどちらのレーベルからも大きな影響を受けた. 音楽的にも, ビジネスとしても.


今ならば「ニッチ」という言葉で説明されるのだろうけど, それがふさわしいとは思わない. IslandやVirginからリリースされるのは「変わった」音楽だった. その何と楽しかったことか. Virginはマイク・オールドフィールドの「チューブラベルズ」で成功し, ファウストやカンタベリ系の音源をいっぱいリリースしていた (レゲエも出してたな). Islandもレゲエだけではなく, EG Production (キング・クリムゾンやロキシー・ミュージックをマネジメントしていたオフィス) に連なるアーティストの音源をリリースし続けた.


その後, ロックは死んで, パンクやニュー・ウェーブの時代になった. その時にはRough TradeやFactoryが「変な」音源をリリースし続けた. Rough Tradeはもともとレコード屋だ. Factoryを作ったのは「ファン」(実際にはちょっとした金を持っていたジャーナリスト) だった. その時代に限らず, とがったポップ音楽というものはいつもそうだったのではないかと思う.