現代萌衛星図鑑

本

現代萌衛星図鑑

現代萌衛星図鑑

かわいい表紙で擬人化されていますが、それぞれの衛星に課されているミッションはどれもこれもすごいもの。
失敗して当たり前の挑戦。だけど、億円単位の予算がつぎ込まれており、ただの失敗は許されない。

そんな衛星を、宇宙のことが大好きな筆者が、やさしい文体で丁寧に綴った良書。

「現代」の衛星

「ひまわり」「きく」「はやぶさ」「かぐや」など、多くのひとが「名前は聞いたことがある」衛星が、どんなミッションを目標とし、どのような成果を持ち帰り、それが次にどのようにつながっていっているか。
そこにはどんな苦労があったのか。
決して詳しく専門的な書きぶりではないかもしれませんが、多くのことを教えてくれます。推薦図書として図書館にあってもよいレベル。
「萌え」だからといって敬遠するのはもったいない。おすすめ。

「はやぶさ」帰還の予習にも

2010年6月には、「はやぶさ」が帰還予定。
今までどのような試練にあってきたかを予習しておくと、帰還イベントをもっと楽しめるかもしれません。

合わせて観たい

D
D
D

ウェブアプリケーションのためのユニバーサルデザイン

本

ウェブアプリケーションのためのユニバーサルデザイン

ウェブアプリケーションのためのユニバーサルデザイン

W3Cでアクセシビリティの普及に携わってきた人の本といわれれば、W3CのWAI(Web Accessibility Initiative)とか、そのへんの文献かじったことがある人なら興味を持てるのでは。

現在、WebのアクセシビリティといえばWeb Content Accessibility Guidelines 2.0(WCAG2.0)がW3Cから出ていますが、正直情報が多すぎてとっかかりにはきついです。
だけどWebアプリケーションにかかわる者としてアクセシビリティの基本は押さえておきたい。
そんな人にお勧め。
良書でした。

特に押さえてほしいのは 「4章 構造とデザイン」「5章 フォーム」

アクセシビリティのポイントは「仕様に沿った正しいHTMLとCSS、JavaScriptを書くこと」だと思っています。

その際に重要になってくるのが「HTMLで文書構造を正しく定義し、CSSで表現を定義する」ということ。
このへんの考え方がよくまとまってるのが、この本の4章です。

そして5章はフォーム。フォームはユーザとのインタラクションの基盤になっています。
「Webアプリケーション」を設計する人なら、（静的なHTMLと比較して）フォームの重要性はわかっているはず。
そのフォームをいかにアクセシブルにつくるかが書かれています。

発展的な内容も

後半の章では、スクリプト、WAI-ARIA(Accessible Rich Internet Applications)など、やや発展的な内容の導入が出てきます。ソースコードも多くなってきます。
このあたりが読める人は、もしかしたら実際にW3Cの文献に当たったほうが早いかもしれません。

Mobile Web Best Practiceの解説がもう少しあるとよかった

付録ではWCAGとMWBPの比較などがありますが、もう少しMWBPの解説があってもよかったかも。

今までHTMLをあまり意識していなかったかたに読んでほしい

HTMLはなんとなく書いても動いてしまうところもあって、しっかり押さえていないWebアプリケーション設計者のかたも見受けられます。
ひとこと「もったいないです」

この本を読むと、アクセシビリティにかかわるテクニックがどのような設計思想を体現しているのかが、少しみえてくると思います。
設計思想は、今後HTML5などにフロントエンドの技術が移行していっても、大きく変わることはなく、これからしばらくは生かし続けることができるでしょう。

この本を「とっかかり」として、アクセシビリティ、正しいHTMLを書くことの重要さについての意識が高まるといいなと思います。

ドメイン駆動を読む（第2部 DDDの応用 第6章 インフラのための準備）

本
  • 実際のデータベースを操作せずに、セーブシナリオのためのテストを書けるようにする
  • 目指すところは、インフラに左右されないコードを書くこと

ライフスタイルとしてのPOCO

  • PIかどうかを見分けるには、「ドメインモデルにインフラ関連の外部DLLに関する参照が含まれているかどうか」を確認するのがはやい
    • 例）O/RマッパーとしてNHibernateを使用している場合、nhibernate.dllに対する参照がドメインモデルのコードに含まれていたら、不吉なにおい


以下のようなものは不吉のにおい
  1. 特定の基底クラス(object以外）の継承

    ドメインモデル開発後、永続記憶に対応しようとしたときに、継承が要求されてドメインモデルを変更しなければならないリスク

  2. 与えられたファクトリだけでインスタンス生成

    ファクトリの強制は、ダーティーチェックで便宜を受けるためであることが多い

  3. コレクションのために特別な(自由に選択できるなら使っていなかった)データ型を使用

    レイジーロードをサポートするために使うことがある

  4. 特別なインターフェースを実装

    永続可能とするためにインフラ提供のインターフェースを（ひとつまたは複数）実装する
  5. 特別なコンストラクタを提供

    　　　
    データベースの値でインスタンスを再構成できるようにするために
  6. 特別な必須フィールドを提供

    インフラがGuidベースのIdフィールドや、intのVersionを要求
  7. 特定の言語要素を避ける

    readonlyフィールドを避ける

  • PIのメリット…TDDにとって好都合である。EntityやValueObjectが明確でクリーンになる
  • リポジトリにとってのPI…リポジトリはインフラを動かさなければならない。
  • 解決策：永続記憶抽象化レイア（NWorkspace)の導入
    • ドメインモデルにRepositoryを置いて、インフラを参照する
    • 参照するのは、永続化フレームワークではなくNWorkspace DLL
    • 同じRepositoryがO/Rマッパーとフェイクの両方を対象に動作する
    • フェイクはインスタンスを永続化せず、メモリ内ハッシュテーブルにインスタンスを格納。初期のリファクタリングに便利
    • インフラベンダーのAPIではなく、素朴なAPIをターゲットとしてRepositoryを書く

セーブのシナリオの処理

  • 論理的なUnitOfWorkを作って、その特徴をセーブに活かしたい
  • RepositoryがUnitOfWorkとやり取りするのを筆者は好む
  • 「ひとつのシナリオ」が「ひとつのUnitOfWork」「ひとつのIdentityMap」を持つべき
  • 集約(Aggregate)はPersistAll()呼び出し時に一貫性の取れた状態になるように設計するべき
  • 物理トランザクションとUnitOfWorkは同じでありたい

フェイクメカニズムの構築

  • トランザクションを非常に重要な概念として扱わなければならない
  • UIプログラマにトランザクション管理の仕事を押し付けたくない
  • フェイクメカニズム…2つのレイヤを持つIDマップを使う。
    • 第1レイヤ…現在のシナリオで読み出したすべてのEntityを管理する
    • 第2レイヤ…永続化エンジンをシミュレート
    • GetById()を呼び出したとき、要求された型のIDマップにIDが見つかったらそのまま返す。みつからなければ第2レイヤにフェッチ。返ってきたオブジェクトを第1レイヤにコピーして呼び出し元にオブジェクトを返す。
  • すべてのテストがフェイクと本物のインフラの両方で実行できるのは、早い段階でテストが書けるのでよい目標
  • フェイクでテストできることにより、リファクタリングに積極的になれる

クエリー

  • QueryObjects
  • SELECTですべての行を取得し、取得した行数を数えるようなものはまずい
  • クエリーとキャッシュ
    • GetByQuery()は永続記憶にアクセスする前にIDマップをチェックしない
    • 問題：IDマップ/UnitOfWorkに追加されているが永続化されていないCustomerは、IDで問い合わせれば見つかるがクエリーだと見つからない
    • 解決策：GetByQuery()はデフォルトで暗黙的にPersistAll()を呼んで、その後DBアクセスする
  • クエリーの置き場所
    • Repositoryの中
    • Repositoryのコンシューマの中
    • ドメインモデルの中
      • 型付きQueryObjectを使うことにより、ドメインモデルをカプセル化できる
      • これは柔軟性をさげるが、よい。なんでもできてしまうのはよくない

SLAP(Single Level of Abstraction Principle : 抽象化レベル統一の原則)

DDDに使えそうなのでメモ。

この考え方を知ったのは「プロダクティブ・プログラマ」の13章から。

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

細かい解説はIBM developerworksの 「進化するアーキテクチャーと新方式の設計: Composed Method と SLAP」がほぼこの本と同じコンセプトの解説をしているのでそちらを･･･

SLAPはざっくり言うと、以下のようなものを分離するための考え方

  • DB接続を管理するような下位レベルの詳細
  • ビジネス・アナリストが理解するような上位レベルのメソッド

一方、Domain Driven Design(DDD)では「Making Implicit Concepts Explicit(暗黙的な概念を明確化する)」という章がある。

ここでは、以下の記述があります。(P205)

Many transformations of domain models and the corresponding code happen when developers recognize a concept that has been hinted at in disscussion or present implicitly in design,and they then represent in explicitly in the model with one or more objects or relationship

概念が議論で示唆されたり設計の中に暗黙的に現れたりしたと開発者が認識すると，ドメインモデルと対応するコードに多くの変化が生じ，一つ以上のオブジェクトまたは関連としてモデルの中に明確に表現されます．

DDD/Chapter Nine. Making Implicit Concepts Explicit - Java EE勉強会

そして、以下の記述(P223)

The key to distinguish a process that ought to be made explicit from one that should be hidden is simple:Is this something the domain experts talk about,or is it just part of the mechanism of the computer programs?

隠すべきプロセスから明確にするべきプロセスを区別するのは簡単で、それが、ドメインのエキスパートが話したことか、コンピュータプログラム上のメカニズムの一部なのかで決まる。

DDD/Processes as Domain Objects - Java EE勉強会

これって、SLAPをうまく使えばできそうだよね！

Developer Summit2010 (デブサミ）に初めて行ってみた

世界は変わった。開発の現場はどうか？　Developers Summit 2010

2日目（2010年2月19日）に行ってきました。
3つほどセッションに参加してきました

masakanou 4000円でオライリーはタンブラか。実用Gitとあと1さつなにかかな #devsumi2010 (2010-02-19 13:00:36) link

kentaro714おすすめの実用Gitは購入予定なので、あとなにを買うか試案しつつ、セッションへ

実用Git

実用Git

三周遅れのXP -僕とドワンゴのXP- （庄司嘉織さん）

masakanou A会場でドワンゴ #devsumi2010 (2010-02-19 13:02:03) link
masakanou 一週目のひとはケントベック。顔など知らない。 #devsumi2010 (2010-02-19 13:14:44) link

XPがテーマのセッションということで、Kent Beckの写真。（私は顔を存じ上げず）

masakanou 三周目のぼくらは高速道路つくろう。 #devsumi2010 (2010-02-19 13:17:42) link

この言葉は響いた。XPの「知の高速道路」のつくるのが、遅れてきた自分の役割なんだというメッセージ。
このあとに続くXP/TDDに対する真摯な（しかし熱い）セッションのアジェンダ。

masakanou なんかみたことある資料だ #devsumi2010 (2010-02-19 13:22:16) link

java-ja 第1回チキチキ 地方巡業withひがやすを飲み会in富山 - YoshioriのBlog ですね。

masakanou ｢動かないきれいなコードがゴールにたどり着けるとは思わない｣ (2010-02-19 13:26:37) link

ウォーターフォール的な「すべて設計して、それから作る」の逆を行く。

masakanou TDDはぜんぶやろうとすると大変だけど、部分的にでもやると、いらん｢勇気｣をだす必要が減っていいよね #devsumi2010 (2010-02-19 13:29:56) link

ここは感想。セッションのなかで、XPの価値のひとつに「勇気」という言葉が出てきていたので。
XPの勇気は抵抗に耐えて周囲を説得する勇気だけど、ここでは「まとめてえいやっと後でテストするリスクを冒す勇気」
TDDなら、そんないらん勇気を無駄に発揮する必要がなくていいよねーという話。

masakanou ｢分割して統治｣だな #devsumi2010 (2010-02-19 13:32:57) link

自分はそんなに優秀じゃないから、小さくしてそこだけみられるように開発をすすめていく。
（TDDやXPのなかでよく出てくる考え方）
ここから後半に向けて、一貫して「分割して統治」のメッセージが自分には伝わってきた。

masakanou SLOWTEST問題知らなかった #devsumi2010 (2010-02-19 13:43:27) link

xUnit Test Patterns(xUTP)読書会 - 担当割当表/PART?/Slow Tests
テストを流すのに時間がかかると、みんなテストやらなくなる負のスパイラルになる。CIへの導入。

masakanou WEB+DBVol35のテスト駆動特集は確かによかた #devsumi2010 (2010-02-19 13:36:00) link

この特集はオススメ。

WEB+DB PRESS Vol.35

WEB+DB PRESS Vol.35

masakanou ｢アジャイルな見積りと計画づくり｣は確かに良書やね。マコネルの見積もり本と合わせて読むとよい感じ #devsumi2010 (2010-02-19 13:48:37) link

PMカンファレンス2010 Winterで講演しましたPMカンファレンス2010 Winterで講演しました - 角谷HTML化計画(2010-02-19)でも言っているように、「アジャイルな」は「見積もりと計画作り」に係る本。アジャイルプロセスの本とはちょっと違う。
よい感じなんだけど読みこなしきれていないので、これを気に強化したい。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

これもよいです
ソフトウェア見積り

ソフトウェア見積り

masakanou 付箋、白板に貼るとはがれちゃうんだよなー。ひとつのタスクが大きすぎるのかな #devsumi2010 (2010-02-19 13:54:10) link

白板に付箋は「みんな更新しなくなって」「ぽろっと付箋がはがれて」「そのままたなざらし」の記憶が･･･うー


とりあえずここまで。これ以降（DDD難民、HTML5）については後で書く予定。

ドメイン駆動を読む（第2部 DDDの応用 第4章 新しいデフォルトアーキテクチャ）

本

勉強会用のメモを兼ねています。

新しいデフォルトアーキテクチャ…DomainModelを基礎としたもの

  • データベース中心の設計からドメインモデル中心の設計に変わったのは、（主として効率性より）メンテナンスを重視するようになったから
    • より明快な設計になっており、実装がドメインの抽象に近いから長期的にみてメンテナンス性に優れている
    • テストのしやすさも増す

レイヤ分割

  • ドメインレイヤに注力。
  • コーディネートを担当するアプリケーションレイヤは、処理をドメインレイヤに委ねるだけの薄いもの（ServiceLayer参照）
    • POEAAのServiceLayerとDDDのServiceは言葉が似ているので注意。
    • アプリケーションレイヤはシナリオクラスみたいなもの
  • すべての呼び出しが下向きだとは限らない。インフラは永続記憶からインスタンスを再生成するときにドメインレイアの知識を持ち、インスタンスを作ってよい。（DDDのRepositoryのことかと思われ）

最初のスケッチ

  • 複雑で柔軟性に富むフィルタ…QueryObjectが一つの解決策。QueryObjectを使っていることはカプセル化しておくとよい
  • Repositoryを使ってカプセル化。クライアントはAPIを使いやすくなる
  • Repositoryはインスタンスのライフサイクルの面倒をみる
  • Repositoryメソッドに膨大な引数を取ることもできるが、「不吉な匂い」
    • stringのNameという引数があったとき、使い方がわからない。
      • 文字列が空のときは？その顧客を探す？名前はどうでもいい？
  • 双方向性はコストがかかる
    • Repository経由でたどり着くことにより、片方向の関連になる
  • 並行処理単位をつくるにはAggregateを使う。
    • パフォーマンス問題は、例えばLazyLoadを使って解決する
  • 最初からSPECIFICATIONに飛びつかなくてもよいのでは

ドメインモデルにUIを結びつける最初の試み

  • 目標：
  1. UIプログラマのために単純なAPIが提供てきているか
  2. UIプログラマはモデルを簡単に理解できてUIに集中できるか
  3. ドメインモデルとの間に複雑なプロトコルがあって気になるようなことはないか

さらに別の次元

ドメイン駆動 (Programmer’s SELECTION)

ドメイン駆動 (Programmer’s SELECTION)