Hachioji.pmとEmacsでテストっぽいファイルを開きたい話
八王子あんまり関係ないところに住んでるけど面白そうだからHachioji.pmに遊びに行ってきた。 良かった。Hachioji.pmは良い。本当に良い。
1枚資料: Hachioji.pm #37
現在書いているコードに対応するテストを開きたい欲求があって、実現への第一歩として、現在編集しているファイル名にtestとかspecとか付けてhelm-ls-gitで開くようにしてみた。helmで候補として表示されるファイルがテストっぽかったら決定して開く。便利。いつもファイル名+testとかを手で打ってたからそれを自動化しただけなので、自分にとって便利なのは当たり前だけど。
ファイル名ベースの解決策だと限界があるけど、テストクラスが含まれているファイルを探したり、他にもやり様があると思う。
DDD本を読んだ感想
DDD本を1周しての雑多な感想。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (129件) を見る
コーディングに早さと質の、うまい早い安いのバランスを求めたいのだけどモデリングでうだうだと悩んでて遅筆になっちゃってるし、最初は名案やと思ってた方向性で突き進んだ結果、結局コレジャナイ感の高いコードができあがる。
近況を述べますとリポジトリとかサービスだとかの用語をネットや会話やコードで見るようになって、俺の中でDDDが話題沸騰中という雰囲気になっていた。リポジトリって何するの?サービスじゃ抽象的すぎでよく分からん。何も考えずパターンに当てはめてるだけでは。なんて中身も見ずに思っていた。でもパターンというものは良いもので、人との認識をある程度共通化できるコミュニケーションツールとしてや、昔からのノウハウが蒸留された知識として決断を支援してくれることもある。僕が用語を理解していないだけで、実はかなり便利なものなのではという流れで読み始めた。
DDD本の内容
DDDでは取り組むドメインを理解し続けようと努め、その理解を具現化することに重点を置く。ドメインを理解していなければ、一時的にしか使われないようなところに力を入れてしまったりと的はずれな開発方針になる。なので、プロダクトの重要な部分においてドメインエキスパートと開発者達はプロダクトの成長という目的のために、二人三脚で進む。
ドメインエキスパートの考えている概念とそれを表現するコードの前提に齟齬があると、手戻りが発生することになる。概念とプロダクトのコードはモデルレベルでマッピングできるよう努めると、ドメインエキスパートと開発者間の溝は小さくなる。概念をそのままコードとして表現できれば、ソフトウェアとして表現したいものが全然表現されていなかった!ということが減る。
ドメインに対する深い理解を得るには時間がかかるし、そもそも完全な理解というものは無いので、探求し続ける必要がある。その中でブレイクスルーがあったり、理解がめちゃくちゃ間違ってたりで今まで具現化していたものに大幅に修正を加える必要が出てくる。そういう状況がきても対処できるような、しなやかな設計にできる高度なスキルが必要になる。
というのがDDD本を読んで知ったこと。納得のいく、まっとうな話だと思う。
DDDは、オブジェクト指向コミュニティの間で長年培われてきたドメインモデリングのノウハウやベストプラクティスを集大成した、1つの設計思想/哲学です。ドメインモデルをこれから構築しようとする人に、設計上の判断を下すための枠組みと、ドメイン設計について議論するためのボキャブラリを提供するものです。
http://wwww.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html
DDD本は上記のように、ボキャブラリを提供してくれることが一番良い所だと感じている。モデリングに関するブログ記事とかコードとかも読みやすくなる。
DDDを適用するとき
ドメインへの理解があって開発も自分でするなら、自分が書きやすい・保守しやすいと思う方法を取れば良い。でも、自分がベストだと思っている方法が人から見ると分かりにくかったりすることは当たり前にある。ドメインという概念をベースに抽象化されたパターンは誰にでも分かりやすそうだと思うし、蒸留されたドメインモデルも扱いやすそうだと思う。出来上がっているモデルへの分かりやすさや手の入れやすさという点では良いと思うけど、高度なモデリングスキルをもってチーム全体で開発していくという点が厳しい。DDDを本格的に採用するにはドメインに対する深い理解があるドリームチームが望まれる。なので、できる部分はDDD本に書いてあることを実践しましょうという印象をもった。
個人的にはドメインへの理解がどうのこうのというよりも、ドメイン知識に頼らずとも取り回しやすいコードを書こうという意識が第一にありたいなと思う。そういう点では、レイヤ化アーキテクチャとかのDDD本に書いてあるいくつかのパターンが有効に使える。次の段階でドメインモデルの蒸留等のドメインへの理解を元にしたパターンがくる。
最後の結論に書いてあることが良かった。基本的に良い話が多く、しっかりプログラミングしよう!!!!!!!!!という気持ちになる。
実際に動く複雑なソフトウェアを、素人が作成できる時代にはなっていない。初歩的なスキルを持ったプログラマを大勢集めても、ある種のソフトウェアを作り出すことはできるが、そうやって作れるのは、土壇場にある企業を救い出せるような類のものではない。
あけまして
おめでとうございます。今年もよろしくお願いします。
去年買ったものを思い出してたら、Bamboo Touchを買ったのを思い出して、1回も使ってないのはさすがにまずいだろうと引っ張りだして描いた絵。思い立ったが吉日の勢いで描いたので、お絵かき掲示板クオリティなのはご愛嬌。最近は全然描いてないので、元から下手なのがどんどん下手になっている……。
今年はもう少し汎用的な力を積極的に付けていきたい
新しい技術がこれからもいろいろ出てくるはずだけど、大抵のものは既にある技術や考え方がベースにあると思う。例えば、副作用のない機能は状態を考慮しないで済むから複雑にならなくて嬉しいよねということを知っていれば、Immutable Infrastructureという考え方に至るまでの道のりは短くなる(知識に捕らわれて遠回りするという可能性も考えられるけど、それは別な話)。こういうベースになりそうな考え方を知っておくと、新しい技術への理解が早くなったりするはずだし、自分でも何か新しいものを作るときに応用できる。何かを学ぶときは、学ぶものから汎用的に使える部分を意識的に切り出せると良いと思う。
今年は人とものを作るときにうまくいく方法についても何か学べたらと思う。それはコミュニケーションの仕方とか、システムの構成とか多岐に渡るけど、特にどんなインターフェースにすれば取り回しやすいかとかの、システムの構成に関わる部分について知りたい。
- 誰かが作った部分に手を加えるとき、テストが無かったりコンポーネントが大きかった時にどう対処すればいいのか
- 自分の作った部分に他人が手を加えるとき、容易に手を加えることができるか
- 不必要なものを作っていないか
というのが最近、自分にとって課題だな思うことのいくつか。 これらを考えることはコストでもある。2はテストを書いたり取り回しやすい設計を熟考することが必要になるし、3はシステム構成に関する情報の共有のため、ドキュメントを書くこともある。取り扱う対象にこれらのコストが果たして必要なのか判断するには〜〜〜というのも気になっている。
とりあえず、去年よりも良い年を過ごしましょう。
魔女っこ姉妹のヨヨとネネ
初日1本目の上映で見てきた。 めちゃくちゃ面白い!という程ではないけど楽しく観れるアニメ映画だった。 あと、プレゼントで焼きそばもらった。
ヨヨが異世界に飛ばされて…という話で、ネネが完全に遠隔でのサポート側にまわっていたから姉妹で活躍するシーンが少なかったのが残念、ネネが活躍するのを見たいと思った。でも、漫画の方を読むとネネが魔力無いのを工夫でカバーしてたりするので、前線に立てないのはしょうがなかった。前提知識なくてもなんとなく分かる映画ではあるけど漫画の方も読んでおいたほうが分かりやすい。氷漬けになってしまったヨヨを12年かけて助ける話をやってる漫画の方では、ネネにスポットライトが当たってるので、ネネの活躍分はそちらで満足できる。
ヨヨが歌うシーンが映像的に面白くて、もう一回見たい。
- 作者: ひらりん
- 出版社/メーカー: 徳間書店
- 発売日: 2012/01/13
- メディア: コミック
- 購入: 1人 クリック: 1回
- この商品を含むブログ (4件) を見る
- 作者: ひらりん
- 出版社/メーカー: 徳間書店
- 発売日: 2013/03/13
- メディア: コミック
- この商品を含むブログを見る
- 作者: ひらりん
- 出版社/メーカー: 徳間書店
- 発売日: 2008/06/20
- メディア: コミック
- 購入: 5人 クリック: 61回
- この商品を含むブログ (24件) を見る
クリスマス活動報告
酔ってたら作ろうという気持ちになったから、作ってみたら目に悪いゲームになった。