2013年12月29日日曜日

Frameworkに依存しないcodeをどう書くか

元々はSymfonyのLTSが3年間というところから。
え〜、そんなに短いんだ。

フレームワーク(FW)よりビジネスのほうが長生きなので、フレームワークに依存しないコードが書きたいな、と。
もっともFWのサポート期間とはなんだろう?期間が過ぎても動くものは動いているし、PHPとかアップグレードしなければ(!)大丈夫なはずだし。脆弱性は最初から入ってないという仮定も必要だけど。
本来、プロジェクトで一番大事な部分はFWというより、それ以外の部分だと思う。それ以外の部分、と言うのはMVCでのモデルというところか。あるいはDDDで言うドメインというところか。

その部分がFWに依存しなければ、何も悩む必要はない、はず。

その部分をどう書くのかな、と最近考え始めた。

DDDとDCI

モデルやドメインといえばDDD。あるいはDCI。

ただDDDとかDCIなど、どうPHPコードに落とせばいいのだろうか?どう書くと、仕様が分かりやすい、テストしやすいコードになるのか。今のところさっぱり。

一方、今の仕事でDDDが必要になるほど複雑な仕様は無いという話もある。ということで、今後少しずつ勉強する予定。

FWとのインターフェース

モデル・ドメインを分離して書いても、フレームワークとのインターフェースは必要だ。ここがFW依存になるので、何かを挟む、ということになるのだろうか?

モデルを、ひとまずエンティティと考えれば、エンティティとフレームワークとの接点は、
*Persistence、
*Validation、
*Presentation、
それと、DBやHTMLフォームはテキストベースなので、エンティティとテキストの変換機能も必要かも。これぐらいあれば、簡単なことなら出来そう。

ということで、以上を抽象化したFWモデルを作っておけば、フレームワークが変わってもFWモデルを変えるだけで、ドメイン側には修正は必要ない、とか考えている。

ちょっと作ってみた

この1年以上PHP5.3で新フレームワークを開発していたら、受注した仕事がPHP5.2ばかり。ということで、PHP4時代から使っているライブラリで開発する羽目になった。

頭にきたので、FWモデルを書いてみた。
モデル内で、PHP4時代(コンストラクターがクラス名とかw)のオブジェクトをnewしまくりながら、ぱっと見は格好良いクラスに見せかける。もうテスタビリティとか無視してざざっと書いてみた。

時間がない中で、わけの分からんことを始めたので、方針はブレるしで、ひどいコードだが、考え方自体は気に入ってます。

ただ、このまま機能を追加してゆき、コードや複雑性が増えてゆき、結局FWモデル自体がフレームワーク化してしまうという未来が見えなくもないですが。

2013年を振り返って

年の瀬なので今年を振り返ってみる。
年内中に書けそうだ。

今年の抱負は「アウトプットを増やす」だった。

結果は、
2013 (15) ←今年!
2012 (40)
2011 (23)
2010 (41)
2009 (22)

と減ってしまいました。

ブログは減ったが、増えたのがgithubのプロジェクト。
とうとうフルスタック可能なWScoreフレームワークを作ってしまいました

作成は楽して、学ぶことが多かった一方、
自分の知識の無さを実感もしました。

大学も機械工学、卒業後の10年はほぼマネージャー、プログラマーになってからは一人での開発がほとんどだったので、よくて知識が偏っている感じ。はっきり言えば知識不足。

だからか人と会話をする際に、自分の考えを正確に説明できない。まぁツイッターで絡んでも、今ひとつ相手の内容が理解できてないので、こちらも色々と書き込めないことが多かった。やはり網羅的な知識を一度は頭に入れたいと思うようになった。

これが来年の課題かなと考えている。

2013年12月20日金曜日

「寄付」は英語でDonationかContribution?

ちょっと英訳をしていて。

英語で寄付といえば「Donation」とばかり思ってたが、
「Contribution」という言い方もあると知った。
http://ejje.weblio.jp/content/寄付

何が違うのだろう?
と調べてみたら、
Donation refers to a gift to a charitable organization whereas a contribution is generally associated with a gift to a common fund or collection.

つまり「Donation」は慈善団体に寄付するときに使い、
それ以外の組織に対する寄付の場合は「Contribution」になると。


Dictionary.comで「Donation」調べてみたが、はっきりとは書いてないなぁ。DonationはContributionでもあると書いてあるし。

確かにContributionの方が広い意味があり、Donationのように善意を受け付けるというより自分たちに賛同する人の助けを(お金として)受け取る、という使い方になるのかもしれない。

ということで、今回は「Contribution」を使うことにした。

2013年10月29日火曜日

Marvericks上でVirtualBoxが不安定に。

どうやらMacのOSをMarvericksにアップデートしたら、VirtualBoxが不安定になったようです。

参考:

https://forums.virtualbox.org/viewtopic.php?f=8&t=58058
http://blog.offline-net.com/2013/10/27/virtualbox-mavericks-update-error/

■症状は、

VirtualBoxを走らせた後、仮想マシーン(VM)を立ち上げようとすると

Kernel driver not installed (rc=1908)
Make sure the kernel module has been loaded successfully.


とエラーメッセージが出てVMが立ち上がりません。
■対応方法1

このエラーが出たら、VirtualBoxを再インストールするしかないようです。インストール作業は5分もかからないのですが、面倒です。

再びVMを立ち上げると、動きました。
VMのイメージ自体は問題ないようです。
よかった。

とは言え毎度再インストールは、本当に面倒です。

■対応方法2

原因は、マックのウィンドウの赤い「×ボタン」、名前なんて言うんでしょうね?を使うと問題が出るようです。つまり、VMが正しくシャットダウンされてない状態になるようです。

なので、*nix系であれば、
sudo shutdown -h now
とコンソールからシャットダウンすれば問題ないようです。

【追記:2013/10/30】
本日また同じ問題が発生。どうやら、上記の対策では対応できないようです。残念。こうなると、↓ですか。

■Oracle様待ち

Marvericksに対応したVirtualBox修正版がリリースされるまで待つしかなさそう。


2013年10月27日日曜日

時代は「CYOFW」

時代は「CYOFW」。
BYOFWは「Create Your Own FrameWork」の略ということで。

自分が言ってるのではなくて、SymfonyやComposer、PSR-3、そしてBEAR.Sundayが何を達成しようとしているかを考えれば、この方向に未来があると思う。

好みのコンポーネントを組み合わせて、自分のFWを作る。Laravel風も、FuelPHPだって、CodeIgniter風も作れるはず。


■コンポーネントが輝く

そうなると、コンポーネントが競争し始めると思う。Smartyかtwigか、プレーンPHPのどれ使うか悩むよね、程度の話なんですが。

いまさらフレームワークを新しく作るより、キラリと光るコンポーネント作ったほうが使われる気がする。

全く新しい機能を提供できれば一番。
それが難しくても、早い&小さい、あるいは、使いやすい、といった面で特徴を出せる方がいいのかなぁと。

理想のコンポーネントは、簡単で小さくて使いやすく、その上、必要になれば様々な機能を簡単に追加できる、なんていうことができれば文句はないだろう。

自分で言えばCenaは他にはないコンポーネント。
と考えると、今後はCenaに集中すべきだろう。

一方、Requestやテンプレートは、今更作ってもと思う。


■グルー(糊)をどうするか

コンポーネント間をつなぐのがグル〜、つまり糊なのだけれど、コンポーネント間、あるいはコンポーネント内の依存性は、どう解決すべきなのだろう。

DI対応しているのが前提で、コンテナをどうするのか?
JSR-330のように、PHPでのDIの仕方も標準化されるのだろうと思う。


■FWってなんだろう?

CYOFWとなると、FWってなんだろうと思う。
さすがに全てのPHPerがFW自作するとも思えないので、有名なFWを使うという状態は変わらないと思う。なので、あまり意味のない疑問かもしれないが。

何を持ってFWというのか?
何がSymfonyで、どこからSilexになるのだろう。

FWがアップデートしても、それまで書いたものが無駄にならない、というのがFWを特定するものだとすると、

  • 設定の仕方・手順、
  • MVの分け方(コントローラーの書き方)、

あたりがFWの肝になるのかな。

WScore:逡巡(2013年10月)

先月、「展望」というエントリを書いていて、
今「逡巡」してるということで、迷走中です。

せっかく作った自作WScoreフレームワーク


勉強のためという言い訳で、HttpRouterTemplateまで作ってしまった。全部で1万5千行ぐらいとはいえ、仕事の合間に自分ですべてをメンテナンスするのは無理だなぁと。

少なくとも、今の全自作から少しずつ良さげなコンポーネントに入れ替えてゆくべきだろう。

そもそも自作FWにこだわる必要はあるのか?
SymfonyやfuelPHPなど、有名&確実なFW使えばいいのでは?

そんなことを思っては逡巡する最近。

2013年9月24日火曜日

WScore:展望(2013年9月)

WScoreフレームワークの開発方向について、考えてみる。

1)現状のスタイルを踏襲する

一番無難。
また新しいことを試すのも楽。

なので、WScoreの開発は続けてゆくと思う。
DIをどうするか(Ray.DIに乗り換えるか)など、結構基本的な部分で悩みがあるのだけど、そういうのも含めて、自分の勉強のためになると思っている。

本音を言えば、最初はフルスタック可能なフレームワークを作る気はなかった。それが、勉強のためという理由で自分で開発したり、100行ぐらいでできそうかも、と思ってしまったとかで、機能が膨れ上がっていった。 
でもコード量は1万5千行ぐらいと比較的小さめなFWだと思う。


2)Cena on Doctrine 2

Cena技術は、本来どんなORMの「薄いマッパー」として動く、はず。
なのでDoctrine 2上でCenaを開発してみたい。

実は、これを最初に検討した。
エンティティの状態が知りたいので、UnitOfWorkの3000行のコードを見ているうちに、気がついたらwsCoreというレポジトリをgithubで作っていたのだった…

あれからDataMapperやCenaについての知識も増えたし、もう一度試してみたいと思う。

もう一度Doctrineのコードを見たら、「getEntityState」というメソッドを発見。これを使えば楽に作れる気がしてきた。どうして一年前に見つからなかったのか謎ではあるが。 
でも、Cena on Doctrineができたら、WScoreを使ってくれる人はいなくなるなぁ、と思いつつ、どちらにしろ使ってくれる人は殆どいないと思うので、これが正しい道だと思う。


3)クライアント側の開発(JavaScript)

クライアント側のライブラリを開発する。
つまりJavaScriptを書くということ。

前にCena-DTAというのを作ったことがある。
初めての本格的JS開発ということで、jQueryのプラグインとして開発したので、複雑な動きに対応しづらくて大変だった。また当時はWebSqlしか使えなかったので、SQLを使って作った。

今ならBackboneかAngularを利用して、モデルか何かのプラグインみたいな形で開発してみたい。それとIndexed Databaseを使ってみたい。


4)XaaS

開発は楽しいのだけど、世界はすごいスピードで進んでいる。
BaaS(Backbone As a Service)など、こういうところでCenaを使ってほしいと思ってたレイヤーがサービス化している。

今のペースで間に合うような気はしないが、何かはしてみたい。

2013年9月19日木曜日

WScore:フレームワークを自作する理由

わざわざフレームワークを自作するのはなぜか?
なぜ面倒なフレームワークづくりを続けられるのか?

フレームワークの自作は大変なだけで、既存のものを使うか利用するほうがはるかに楽だと思います。大体動くところまではできますが、細かなバグを見つけたり、きちんとテストを書くのは大変な作業です。


自分の場合は、明確な理由が一つ。

Cenaデータ転送という技術を思いついてしまったたから。
ハマりすぎて特許まで取得してしまった。

これで何ができるのか見てみたい。
そして周りにデモを見せたい。

ちなみにこんなサイトでCenaについて書いています。

世界で唯一の技術(かもしれない)と思うと、不思議とやる気が湧いてきて、開発を続けています。高揚と幻滅を繰り返しながら、少しずつ機能を追加してゆく作業は、なかなか楽しいです。


もちろん、他にも理由はあります。

まずは、勉強のため、というのがあります。

例えばDIコンテナとはなにか?
実際に作って、そして使ってみることで理解できた気がします。

やはりフレームワークを作るとなると、いろいろなデザインパターンを使う場面が増えてきます。そういう意味で、自分のプログラミング能力を伸ばすのに最適な気がします。
もっとも勉強なら、既存のフレームワークを使って何かサービスを立ち上げるほうが広い範囲の技術を覚えられるので、フレームワーク自作よりおすすめな気がする。


自分の仕事のためのライブラリづくり。

自分の思い通りに動くのは気持ちがいい。

と言うのはありますが、大事なのはサポート期間が無期限なこと。
これがメリットなのか、大変なだけなのかはわかりませんが。

SymfonyのLTSが3年と聞いて、短いなと感じました。
自分の仕事だと、ほとんどは5年以上動いている。最長で10年のプロジェクトがあるので、サポート期間としては5年ぐらいはほしいところ。

他の人はどうしてるのだろう?
まぁサポート期間が切れて動かなくなることはないし、そんなに気にしなくてもいいのかな?

正しく作れば、サイトのコアとなるドメインコードはフレームワークから独立するので大丈夫、となるのだろうか?

2013年9月17日火曜日

WScore開発を始めてから1年。

ふとgithubを見返したら、wsCoreの最初のコミットが2012年9月5日。
早いもので、開発を始めてから1年が経過した。

その後2月頃にcomposerを使ったコンポーネントベースに移行。
また名前もWScore.*に変更。
「*」は、各コンポーネントの名前。

特徴は:
・Cenaデータ転送技術がある!
・コンポーネント・ベースでフルスタック可能、
・小さい(16,000行ぐらい)、
といったところ。

開発の現状は、ほぼアルファぐらい。

大まかな機能は実装できた。
明らかなバグ・不具合もなし。
ただテストは足りない。
微妙に機能が足りてない(i18nなど)。

今後は、細かな構成やAPIを調整したい(見返すと汗が出る箇所が幾つかある)ので、状況としてはアルファぐらいかなと思う。

もう少しAPIを煮詰めてベータと言えるぐらいにはしたい。

2013年2月28日木曜日

php5.4のcliだけインストール

phpのAuraというフレームワークがあるのを知った。

BEAR.Sundayはすごいが、Auraはコードが綺麗。
またコンポーネントが独立していて、他の依存性がない。
ので、すごく追いかけやすい上に勉強になる。

今までgithubでコードを見てたが、ぜひPhpStormで見たい。

が、ちょっとした問題が。
Auraはphp5.4必須で、今のPCはまだバージョンが5.3なので、インストールで失敗する。正確にはComposerが依存性をチェックしてくれるので、そこから先に進まない。

そんなことを短くtwitしたら、すぐに教えてくれた。

https://twitter.com/hidenorigoto/status/306970679943786496

ありがとうございました。

しかし、どうやってphp5.4のcliを手に入れるんだ?
自分でインストール?

php5.4のcliインストール


実は自分でphpをインストールしたことがなかった。

ということでメモ。

1.php.netから最新tarballをダウンロード。

そして下記のフォルダーに展開した。
/usr/local/src/php-5.4.12

2.configureを走らせる。

./configure --prefix=/usr/local/src/php-5.4.12 --enable-mbstring --with-pear
すると色々足りないと怒られた。
適当にapt-get。

sudo apt-get install libxml2
sudo apt-get install xml2
sudo apt-get install libxml2-dev

多分、libxml2-devというのがUbuntuでは必要。ディストリビューションによって、少しずつ名前が違うみたい。

またapx2を入れることが多いが、cliのみ作るのでバッサリ削除。

3.make

通った。
ちなみにmake installすると既存のphpを置き換えると思うので、走らせない。

4.インストール

自分でインストール。

目的のcliバージョンのphpは
/usr/local/src/php-5.4.12/sapi/cli/php
cd /usr/local/bin
sudo ln -s /usr/local/src/php-5.4.12/sapi/cli/php php54
5.Auraインストール

Auraのどれをインストールするか悩んだが、これで。
git clone https://github.com/auraphp/system.git
mv system/ Aura.system
cd Aura.system/
php54 composer.phar install
さらに、
cd web/
php54 -S localhost:8080 index.php
でサーバーとしても動いたようです。

ところでAuraのデモは「hello world」だけなのかな。
う〜ん、インパクトが弱い。

2013年1月31日木曜日

27インチモニターがやってきた(EIZO)


クリスマスプレゼントは何がいいと妻に聞かれて27インチモニターと答えた。出来れば、目に優しくて有名だったNanaoがいいな。

年が明けて、円安になる前に購入することにした。




インストールしたPCは、

  • SandyBridgeのP68チップセット。
  • Ubuntu 11.10

梱包されているDisplayPortケーブルで繋いで、電源を入れたら一発で認識してくれた。解像度も問題なし。



ただ認識はしてくれるが画像が表示されない。
このモニターが3台目だったのだが、一番小さい19インチのモニターを外して21+27インチの構成にしたら、動いた。

モニター3台同時接続はできないのかも。


もうひとつ。

Skypeがかかってきたら、
いきなり音声がモニターから出てきた。

いつもはマイク付きのヘッドフォーンを使っているのだが、
どうもDisplayPortは音声もモニターに転送するらしい。

システム設定 > サウンド > ハードウェア
から
選択したデバイスの設定で「アナログステレオ入出力」を選択したら戻った。



一週間ぐらい使った感想は・・・

いや素晴らしい。
大きいことはいいことだ。

とはいえ、27インチモニターにすると、
開発の効率が上がるのだろうか???

ま、少しは上がるだろう。

やたらと横に長い仕様書も一目でみれるし、
仕様書を見ながらコードを書くのが楽になったし。

それと、高さ方向については、一応十分な高さが得られた感じ。
もっと高さが欲しい、とは感じなくなった。




画面については、きれいの一言。

白が白い。輝度を落としても、白い。


一方、前の機種と比較すると、少し目が疲れる気がする。ちなみに前のはEIZO FlexScan L997-Rという目にやさしいので有名なモニター。

ただし、単にDPIが大きくなった=文字が小さい、という理由で目が疲れるだけな気もする。なにしろ少し老眼気味になってきているので。



2013年1月26日土曜日

Simple@溝の口(2013/1/26)

平成25年度、最初のSimple勉強会。
大事なことだから、もう一度書くと今年は平成25年度。

おや?充電しない…

別の電源ユニットを借りると充電する。

どうもMacBook Airの電源が死んだらしい。

スリープしてもバッテリ消費するし、早くアップルケアで修理してもらわないと。そのためにTime Machine対応のネットワークHDDも購入したし。

作業ログ

ブログのデザインを微妙に変更。

■「自分の理解したDCI」のエントリを描き上げ。

■400コラム×50フォームを作るアイディアを募集。

・50モデル作る、
・jQueryでフォームを制御、
・これはMongoでしょう、
などなど。

できるだけビューに近いレイヤーで制御したほうが楽そう。

自分の理解したDCI

去年の秋頃からDCIについて書き始めてるので、DCIとは何なのか自分なりの理解をまとめてみようと思う。例によって、いろんな人が書いたことをつまんでまとめてます。

DCIとはData, Context, and Interactionの略で、新しいアーキテクチャのこと。
The DCI Architecture: A New Vision of Object-Oriented Programming」で最初に発表された。この日本語訳もあります。

読み物として面白かったのがtogetterでまとめられた「Jim Coplien 氏講演会「DCIアーキテクチャ」(2010年1月14日、早稲田大学)」。これは、すごいものに違いない、という感じがじわじわ来る。

MVCの問題を解決する

DCIが生まれた背景には、MVCモデルの問題点を解決するという視点がある。
Data Context Interaction: What is it good for?
(DCIの要点が詰まっているプレゼンだと思います。)

よくMVCで問題になるのが
Fat Controller
検索で一番最初に出たページが分かりやすい。ウェブ・Httpとのやり取り、ビューの管理、そしてビジネスロジックのコードまでまで入り込んでしまう。

そこで、モデル側にコードを移してゆくと、
今度は
Fat Model
と言われて、これまた嫌われる。
#個人的には、モデルは小さくて堅牢なほうがいいので、同じ選ぶならFat Controllerかな。などと書いては見たが、実はMVCでコーディングあまりしたことがない…

DCIによる解決方法

原因は、モデルとコントローラだけではレイヤーが足りてない。
ので、レイヤーを足しましょうというのがDCI。

Model + Controller
Data + Context + Interaction + Controller

それぞれ、どんな意味や役割があるのか?
思想的背景は何なのか?

これが理解できると、よりよい(DCIな)コードが書けるはず。

Data, Context and Interaction

と、ここまで書いておいて自分の理解が間違っていたことが発覚。
InteractionとContextを取り違えていたようだ。

気を取り直して、もう一度。
今の自分の理解を図にしてみた。


あれ、dataと書くつもりがentityと書いていた。
「entity」→「data」と脳内変換しつつ説明すると…
  • Data(=entity):
    俗にいうエンティティと言われるデータのオブジェクト。
    データがどうあるべきかについての知識を蓄積したオブジェクト。
  • Interaction:
    データと外側の世界をつなぐのがinteraction。
    要は「Dataに動的に付与したメソード」のことで、必要に応じてデータが何を行うかを実装する。多分、data+interactionでRoleと呼ぶ。Role自体はステートレスのオブジェクトで、例としてscalaの動的traitを使った実装例があげられいる。
  • Context:
    複数のエンティティにまたがる、ユースケース(ユーザー画面)由来の挙動、などを表現するオブジェクト。オブジェクト指向にとらわれず、システムの挙動を手続き的なコードで記述する。
    変更の多いユーザー画面やたまにしか使わないメソードをentityオブジェクトの外に持って行けるので、変更に強いコードになるはず。
自分としては、
・Contextとは何なのか、
・Interaction/RoleのPHPでの実装方法と設計要求、
・結局どうウェブアプリを作るの?楽になるの?
あたりが今の興味になります。


2013年1月22日火曜日

design pattern criticismの検索メモ

書いたのだから、検索してみた。
「design pattern criticism」の検索結果メモです。

Googleトップに輝いたのはCoding Horrorさんのページでした。



Rethinking Design Patterns


1.複雑なことを複雑に解きかねない。
2.言語の問題をパタンで解いてるだけ。


コードのコピペならぬ、

アルゴリズムのコピペ

を始めてしまう、とう批判のようです。
(アルゴリズムのコピペはどこかで見た言葉ですが、ソースを失念)。




次はこちら。

StackExchangeのエントリーです。
「Design Pattern」タグで他のエントリーを探してみましたが、批判に関するものはこれぐらいでした。




自分でも批判を調べてもあまり建設的ではないと思うので、ここらへんでメモは終了。コップに半分牛乳が入ってるのか、半分空なのか、いや実は半分ではなくて1/3だ、みたいな話なのでしょう。

アレクサンダーさんのパターン・ランゲージが目指したものを考えると、現状のデザインパターンは極めて限られた部分しかできてないのは間違いないと思います。

本来パターンは、小さいパターンが重層的に織りなって複雑なパターンを形成すると思いますが、デザパタはパターンの関連や組み合わせがすっぽり抜け落ちてます。

あと最初の印象があまりよくない。

パターンの名前が聞きなれないのは仕方ないと思うものの、30近くのパターンが何の関連もなく(?)ずらりと並び、しかも中のクラスまで聞きなれない名前がついていて、もうDQN名かと。

個人的には、確実に役に立ちます。

「あのコンポーネント使って〜」
「アダプターかまします〜」
「了解〜」

みたいな会話が出来るし。

最後に、このページを。


Software Design Pattern Critique


このページが批判を一番上手にまとめてます。

が、最後の一文が・・・

Maybe this is because there is not yet really a PatternLanguage but only a PatternCollection? and the real fun hasn't yet begun.

まだパターン言語になってなく、今はパターン集だから?
本当の楽しみは始まってすらいない、よね。

2013年1月18日金曜日

Pattern Languageについての検索メモ

せっかくデザイン・パターンとの出会いを書いたので、もう少し調べてみた。今度は「デザイン・パターン パターン・ランゲージ」で検索して、調べた結果メモ。





Generalization of the Concept of Pattern Language


http://www.slideshare.net/quolc/generalization-of-the-concept-of-pattern-language

「パターン・ランゲージをソフトウェア工学に適用したのがXP、Agile。」

パターン・ランゲージの論理において、パターンそのものは論理の一部でしかない。大事なのは利用者が参加すること、漸進的な成長を促す、などの原理がある、と。

なんとXPやAgileもだったのか。これは知らなかった。

そういえばアレクサンダーさんが書いた本がパターン・ランゲージであり、一方GoFが提唱したのがデザイン・パターンだった。のでデザパタというのはパターン・ランゲージの一部という理解でいいのかも。





暗黙知の共有に効く?パターンランゲージの可能性


http://irritantis.info/2012/01/pattern_language/

パターン・ランゲージを応用して、ラーニング・パターン、デザイン・パターンなど応用範囲を大きく広げている。

例:SFCのラーニング・パターン

私が感じているパターンランゲージ最大の魅力は、『状況(context) – 問題点(problem) – 解決策(solution)』という基礎フォーマットです。常に課題と解決(コンサル風に言うとAsIsとToBe)がセットになっているので、一つ一つのパターンが、常に何かしらの問題を解決する方法になるわけです。
複数のパターンが階層的につながり合って(シーケンシャルに)全体を構成しているということです。

シンプルなパターンを組み合わせることにより、複雑な系を作り上げる。
一時期はやったカオス理論みたい。

ソフトウェアにおいては、複雑な要求を複雑に解決すると、運用できなくなってしまう。そこで複雑な動きを、シンプルなパターンに分解する。

分解したものを組み上げる際、線形に積み重ねると複雑な系を作れない。非線形な言語を使って再構築することで複雑な系を作れる、と理解してみた。




フレームワークへの異常な愛情

http://overkast.jp/2012/08/framework/

「フレーム」という言葉は、人工知能やコンピュータ理論の領域において、文字通り「枠組み」という意味で使われる。さらにコンピュータ以前まで遡ると、「スキーマ」(schema)という認知科学のキーワードにたどり着く。「フレーム」とは「スキーマ」の長期記憶的な表象と定義される言葉である。

非常に面白い分析。
「スキーマ」という言葉は聞いたことがあるが、意味について考えたことがなかった。

自分の頭の中にあるスキーマを具現化したものがフレームワーク、といったところか。

パターンとの類似で言えば、スキーマを細かく分解して、名前をつけて、関連付けたものがパターンであり、それを構築する手段がパターン・ランゲージ。






重要な原則は「ユーザーの参加」か。江渡浩一郎「パターン、Wiki、XP ~時を超えた創造の原則」


http://www.heartlogic.jp/archives/2009/09/wikixp.html

と調べていたら、まとめた本が出版されていた。
http://www.amazon.co.jp/exec/obidos/ASIN/4774138975/heartlogic-22/



自分で調べなくても、すでに本になっていた。
次の積ん読候補。

2013年1月17日木曜日

Design Patternとの出会い

ふとデザインパターンに関するこんなページを読んだ。
Coding Horror: Rethinking Design Patterns

ある思い出が蘇った。



もう15年ぐらい前の話。
当時はアメリカで仕事をしていた。

友人のG君が、パターン・ランゲージというのを教えてくれた。
彼はオレゴン州に住んでいるソフトウェアエンジニア。ユージーン市ダウンタウンの改修に深く関わったりした過去を持っていた。

そう、まさにパターン・ランゲージのアレクサンダー教授のいるオレゴン大学のある市。実際、アレクサンダー教授との知り合いだったらしい。


その彼が、GoFのデザインパターンについても語っていた。
いわく、「ダメだ」と。

肝心な何かが欠けているのだそうだ。
それが何なのか。
手振りを加えて説明しようとしてくれたが、言葉にならない。

代わりに読むなら、と勧められたのが、この二冊。




残念ながら、当時の肩書きはマネージャ。たまにCやperlで、プロジェクトで担当者からあぶれたプログラムを書くぐらい。

ちょっと読んで面白いとは思ったものの、オブジェクト指向に深く理解してたわけもなく、積んどく状態になっていた。

G君が間違ってたとは思わないが、ネガティブな出会いというのは良くなかったかもしれない。何かが足りないデザインパターンという記憶だけが残って、10年以上が過ぎた。

さすがに、デザインパターンは大事、というか便利なものだという認識に改まっている。
が、また何が足りないのか、あるいはデザインパターンがもとにしているパターン・ランゲージとは何なのか、もっと知りたいなと思うようになった。

2013年1月7日月曜日

新年の抱負:アウトプットを増やすには

さて、去年2012年の抱負と同じです。
「アウトプットを増やす」と言ったのですが、結果は?

ブロガーのアーカイブから、年度ごとのエントリー数を抜き出すと。

2012 (40)
2011 (23)
2010 (41)
2009 (22)

2012年になって、アウトプットが持ち直した感じですな。

もう少しアウトプットを増やしたい。


そのために、今年は

  質より量

と割りきろうと思っています。

まぁ2〜3回連続ツイートするような内容をブログにする感じです。