TDDとパラダイムは関係ないんじゃないかなぁ

世の中には手続き型言語、オブジェクト指向言語、関数型言語あたりがあるとして、どれがTDDに向いてるかというと、いや特に差異はないよねという話です。

それぞれのやり方で、「手続き」なり「オブジェクト」なり「関数」なりがパターン爆発しない大きさに収まる限り、ユニットテストのコードを書くことは現実的に可能だし、RED->GREEN（もしくはその逆も）の変化を観察することに対して、大きな違いがあると思ったことはない。穿った見方をすると、書籍としてオブジェクト指向の本が多いのは、オブジェクト指向言語のパラダイムが難しいことを説明してると考えることもできる。リスコフの置換原則は我々には早すぎた道具だったのだ！！

まぁとりあえず、テスト性をよくすることで自然と高凝集かつ低結合なモジュール構成が出来上がったりします。ので、私が作る程度のプログラムでは、テスト可能な感じにまとめつつ、意図通りに変化していることが観察できれば、それで十分だと考えています。

結合テストでも、よく、RED->GREENは観察しますよね。パラダイムは関係ない。

以上、 http://d.hatena.ne.jp/y_sumida/20130619/1371654638 のあたりの話題でした。

方針はエリート教育

育児

この記事は子育てエンジニア advent calendar 2012 : ATNDの12/3のエントリです。

日曜日

俺「ねぇ、なんか足し算の問題だしてよ」
娘「じゃぁ、せん足すー、せん足すー、せん足すー、せん足すー、せんはー？」
俺「ちょいまち」

gosh> (+ 1000 1000 1000 1000 1000)
5000

俺「ほら、5000だ、すごいだろ」
娘「ふーん、じゃぁ」
俺「（反応うすいな…）」
娘「せん足すー、ごましお足すー、ごみぶくろはー？」
俺「！？」

gosh> (* 1000 gomashio gomibukuro)
*** ERROR: unbound variable: gomashio

俺「ぐぬぬ………ﾋﾟｺｰﾝ！」

gosh> (define gomashio (+ 5 4))
gomashio
gosh> (define gomibukuro (+ 5 3))
gomibukuro
gosh> (+ 1000 gomashio gomibukuro)
1017

俺「1017！！（ﾄﾞﾔｯ」
娘「えっ？ちがうよ？1014だよ？」
俺「えっ？ごましおと、ごみぶくろだから、5と4と5と3でしょ？」
娘「あっ。な、なんでもなーい。」

きっと、schemeの、プログラミングのすばらしさが伝わったものだと思います！！！１１１！

ちょっと湯豆腐を作ってみますね…

料理 #vgadvent2012

いよいよ本格的な冬になってきたような気がしないでもないと思ってたらもう師走な今日このごろですが、いかがお過ごしでしょうか？自称お料理ブロガーの[twitter:@katzchang]です。

VOYAGE GROUP エンジニアブログ : Advent Calendar 2012の12/2のエントリーを書かなければいけないですが、何を書こうか迷ったので、ここは湯豆腐について調査した結果を報告致します。

作り方

醤油に酒・昆布を入れて弱く加熱し、温まった程度で昆布を取り出してさらにそのまま加熱する。沸騰したくらいで加熱を止め、鰹節を投入してひと混ぜしたあとに少し放置し、漉し、冷ます。ようするにダシ醤油を作っておく。

柚子の果汁を絞っておく。

鍋に水と昆布を入れ、適当な大きさに切った豆腐を入れ、弱火にかける。丁寧に作る場合は水と昆布を合わせて一晩おいて〜みたいにするかもしれないが、ここはまぁいいや。

で、沸騰前に加熱を止め、小皿にとり、ダシ醤油と柚子果汁を1:1程度の割合でかけて、食べる。

さて、

一口に「湯豆腐」といっても作り方は様々なようで、豆腐だけではなく、野菜などもはいったものも「湯豆腐」と呼ぶことがあるようです。こうなると「湯豆腐が湯豆腐たらしめるのは何か」ということが気になってくるわけでして。これはドメイン駆動設計におけるコア・ドメインの抽出と同じパターンだと思いませんか？

とりあえずみんな大好きwikipediaから引用してみると、

豆腐、水、昆布だけが材料である。鍋に昆布を敷き豆腐を入れ、温まったところを引き揚げてつけダレで食べる。
塩ひとつまみ、あるいは刻んだ大根をいれると豆腐が硬くならず、やわらかいまま食べられるといわれている。ただし、多く投入すると雑味となって湯豆腐ならではの淡味が失われる恐れもある。
湯豆腐 - Wikipedia

つまり、豆腐を温めて食べる、ということらしい。温奴。煮るではないという感覚ですね。

豆腐は強く加熱すると硬くなる（スが入る状態）。内側を加熱しつつ外側の加熱を抑えるために、今回は水から、弱めの火で加熱してみました。まぁ、ここはあまりこだわんなくてもいいかもしれないけど。

冷奴のレシピとしては、ネギなど薬味をつけたり、キムチなど他の食材と合わせる場合があるので、「温かい豆腐なら、だいたい似たようなものだろー」と思ってそれらの食材と合わせてみたけど、やっぱりポン酢醤油が一番美味しく食べれたような気がします。ネギも不要。

終わりに

ということで、今回は「湯豆腐は昆布出汁で暖めた豆腐であり、薬味なしのポン酢醤油をあわせる」という湯豆腐のコア・ドメインを蒸留してみました。食べ物は万人がドメイン・エキスパート。

これがなんでVOYAGE GROUP Advent Calendarかというと、ようするに今度AJITOでやろうぜという話です。電気鍋は2,000円くらいである*1し。

あすのカレンダーを埋めるのは[twitter:@suzu_v]です。お楽しみに〜。

*1:http://shopping.ecnavi.jp/keyword_search/?keyword=%C5%C5%B5%A4%C6%E9 で価格比較とかできるらしいですね

プログラマに最も必要なのは読解力である

たぶんあとで書かない

細かいコーディング規約を排除できる

あなたはコーディング規約の詳細まで理解しているか？
よし、しているとしよう。すばらしい。
では、あなたのチームメンバも同じか？

無意味に思う規則に乗るなら、乗らないで失敗したほうがマシだ。

書き手のスタイルに沿った設計・プログラミングができる

まだ見ぬ読み手に自分を縛られてるくらいなら、自由に書いたほうが、よほど読みやすい。

本当に読みにくい部分を読みにくいと指摘できる

読みにくいコードは、変数の名付けがダメなのだ。状態管理が混乱しているのだ。
読みにくいのはコメントがないせいでもないし、インデントが崩れているせいでもない。読むに耐えないほどインデントが崩れたコードは実際に見たことはないし、気になるなら読み手が修正してコミットすればよい。

他人に読みやすいコードを書ける

読解力とはレビュー能力である

娘ちゃんは5歳になりました。

育児

なんか久しぶりなような気がするが、思い出した順にとりとめなく：

  • 新しい幼稚園は、とりあえず元気にいっているらしい。
    • 「今日は何をしたの？」と聞いても「忘れた」ということが多かったが、最近は答えるようになってきた。答えるのが面倒なのかなーと思っていたが、どうやら本気で忘れてるらしい。
    • ちょっと周りを意識して、あまり浮かないように服装を選んだりする。スカートの下にスパッツを履くか履かぬかとか。
  • 「なんか暇だなー、暇だなー」=「iPhoneでゲームさせろ」
  • トイレでうんこするときに、本を2冊持ち込む。30分間楽しむ。
  • 小児喘息は落ち着いたので、毎日の薬は止めている。
    • たまに咳がでるので、その時は吸入薬などを使っている。
    • 他には発熱は年に2〜3回くらい。それほど体調を崩すこともない。
  • おねしょとの戦い
    • 防水シーツ大活躍（昨夜も活躍）
  • 食べ物の好みは変わってきた。梅干しの量は減り、ハンバーグなどひき肉料理が食べれるようになった。
  • 夕食時の行儀が悪すぎたので食後のデザートを抜き宣言をした日は、大変だった。いやあんた、毎日なんか食べてるわけじゃなかろうに。
  • 先日、「田植え体験」なるイベントに連れて行ったところ、到着が遅れてすでに終わっており、これも大変だった。
    • っていうか、金沢でいくらでもできるだろうに、なんでわざわざと思うが、まぁいいや。
  • スキー道具を購入。林間コースは一人で滑れる程度の実力。
  • 将来やりたいのは、ケーキ屋さんらしい。3際の頃、ケーキ屋さんごっこする夢を見て、楽しかったのだそうな。
    • あれは一見華やかに見えるが体力的に辛いぞ、という話はしている。
  • 掛け算をすこし練習していたが、最近は飽きたようだ。
  • 曲を流しながらトイ・ピアノを適当に弾くときの音が、たまに的確になってきた。

Clojureの学習でSICPは使えるかと問われ、Rich曰く、

最初の文章のまま載せていますので、コメント欄のshiroさんの添削と合わせてどうぞ：

一概には言えないが、2点だけ。


僕は、SICPはプログラミング言語の本じゃなくて、あれはプログラミングの本なんだと思ってる。本の中でSchemeを使っているのは、アトミックなプログラミング言語だからなんだ。ラムダ計算、末尾再帰、継続を使った抽象制御、抽象構文（マクロ）、可変状態など。軽量で、かつ十分だ。


SICPでは、プログラミングをする上での課題を扱っている。モジュラリティ、抽象、状態、データ構造、並列処理など。generic dispatchやオブジェクト、並列処理、遅延リスト、（可変な）データ構造、「タギング」なんかの、明確な課題設定に対する実装例と解説が書いてある。


Clojureはアトミックなプログラミング言語じゃない。僕はもう、アトミックにプログラミングするのは古くて遅くて飽きた。Clojureでプロダクトとして実装されているのは、generic dispatch、連想マップ、メタデータ、並列処理基盤、データ構造の永続化、遅延シーケンス、多態ライブラリなどなど。SICPで実装するだろうものは、Clojureでは既に用意されている。


そう、SICPの価値はプログラミングの概念を学習するところにあるんだ。もし、既に理解しているとしたら、これは私見だが、Clojureを使ってロバストで価値を生むプログラムを素早く書けるだろうと思っている。それに、Schemeと比べて、Clojureのコア部分は極端に大きいとは思っていない。Schemerはどう思う？


私としては、ClojureよりもLispを学習する利点は、関数型プログラミングやリストを学ぶための良い道筋になると思っている。高次で簡潔なデータ構造を学習すると、急ぎの割にコロコロ変わる要件をこなすような、実務でのプログラミングで役に立つ*1。Lispが劣っている点としては、プロセス内並列処理が広まる以前に設計されたものだったり、高パフォーマンスな多態ディスパッチ（例えば仮想関数）がライブラリ化される価値が理解される以前のものだったりすることだ。Lispのライブラリは明らかに制限のある多態性しか持てない。


Stuart Hallowayが書いた「Proguramming Clojure」は、e-bookで出版されてて、もうすぐ紙媒体も発売する予定だ。もちろん、Scheme標準よりも拡張して、（必要となりそうな）より多くの機能を用意しているが、そのあたりは本には書かれていない。どちらの場合のドキュメント*2。


SchemeやCommon Lispを学習して、Clojureを理解する方法はよいことだ。直訳できない仕様は幾つかある（Schemeと比べてTCOはなく、false, nil, ()は違うし、継続はない。CLやLisp-1と比べてsymbol, var dichotomy がない）。しかし、私個人としては、SICPはClojureを学習するには、あまりマッチしないと思っている。


※効果は人によって異なります。


Clojure for Scheme Programmers | Clojure Programming/Tutorials and Tips
http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips#Clojure_for_Scheme_Programmers

以上、勝手訳*3。Rich HickeyはClojureの作者。

ところどころ怪しいが、要するに、Clojureを使うための教科書としては、SICPはアトミックすぎるということですかね。

逆をする分には問題ないという感じか。

*1:この辺は自信がない

*2:？？

*3:この文章のライセンスは原文に従い、 http://creativecommons.org/licenses/by-sa/3.0/deed.ja です。