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回連続ツイートするような内容をブログにする感じです。