本ブログ再開の一番の目的の一つである、予告編にて予告した太字の部分からです。
@t_wadaさん講演 @ 新人研修
というわけで私sylph01は4月から会社でお仕事を始めることとなりプログラマのプロフェッショナル[要出典]としての道を歩み始めたわけですが*1 、新人研修の一環として日本のTDD界の第一人者ともいえる @t_wada さんに社内で講演していただくというイベントがありました。まあこの時点でもはや身バレ同然*2なんですが、この際開き直って、同期よりも面白い記事を書こうと思います（きっぱり）。
まず第1部では実況ログ（一部私のメモ有り）を記載して第2部でそれを受けての私の話をしようと思います。研修の記録みたいなのはまた別記事でしようと思います。
title: この先生きのこるために
（このせんせいきのこるために、と読む）
id: t-wada @t_wada github: twada
ネット上の印象：「テスト書いてないとかお前それ@t_wadaの前でも同じこと言えんの？」 ネット上でマサカリを投げたことはない（本人談）
製品開発・コンサルティング・ライセンス販売とかをやってる会社。
『プログラマが知るべき97のこと』 #97prog_ja 日本向けには+10本で107本になりました
プログラマが知るべき97のこと なのできのこ。
システム開発の世界へようこそ
最初にキャリアの話
ありがたい話の「ありがたさの完了条件・テスト条件がわからない」ので自分の話。一個人としてどうやって生きたか。
1977年生まれ「（定年済）」（プログラマ35歳定年説にかけて）id:naoyaとかが同い年。
「きのこ18: 学び続ける姿勢」（#97prog_ja）
キャリアの3つの時代 – 読むread・書くwrite・話すtalk
1996/07/22（日本がブラジルに勝った日） – コンピュータとの出会い
（サッカーファンはものを2年単位・4年単位で覚えられる。ワールドカップ、オリンピック）
ホームステイをする。家族と打ち解けるための手段を探してた。家にファミコンがあった。無限1upをやってみせる。 一つの原体験 -> 人の心をつかむ上で何が大事か: 実際にやってみせる。 結果としては家帰ったら毎日ファミコンやらされた。
大学ではソフトウェア工学をしてた。「OO厨をこじらせる」「完璧主義の呪い」 完璧な設計を得るまではコードを書いてはならないという思想にとりつかれる。いろんなパターンを知ってることがエラいみたいなムード。
2002/06/07 – まさーるさん(masarlさん)に出会う。ネット上の師匠となった人。アジャイルの初期にJUnitの使い方等に造詣が深かった。 「写経」を知る。サンプルコードを実際に手で写して動かす。何がいい -> わかった気になってるかどうかがわかる。フィードバックの種類が多ければ多いほど覚えやすい。
https://twitter.com/t_wada/statuses/9000231741
深夜バスでTDD写経（最近は「第二終電」といわれる深夜バスがあるようなのですが…）
異なる道を知る（図：「汚い・動かない」→「きれい・動かない」→「きれい・動作する」の道と、「汚い・動かない」→「汚い・動作する」→「きれい・動作する」の道）
残業代を技術書に使ってひたすら本を読む
『達人プログラマー – システム開発の職人から名匠への道』を読む（絶版）
2004/07/01 読むから書くへ移行。
「チームかくたに*3」に参加。 1000人のプロジェクトから4人のプロジェクトへ。 はてダ開始、t-wadaさんになった。
お客さんからアジャイルプロセス「全開でやってくれ」
ロールプレイングゲーム 理想のプログラマを演じてしまう … だって仕事でしょ？ というわけで厳しい講師を演じた。
54: 見えないものを見えるように ： todo doing done 80: 1人より2人 ： ペアプロ 65: バージョン管理システムを有効に使う 79: テストのないソフトウェア開発はあり得ない 51: プロジェクト自身にしゃべらせる ： CI (当時はJenkinsもなくHudsonになる前のものだった)
はてダに書きまくった
2005/4/25 話す、へ
福知山線脱線事故の日。なんでこの事件をきっかけに話すことになったか。masarlさんがこの電車に乗ってた。お師匠さんがいなくなってしまった。恩返しができなくなってしまったので恩送りをしなければ。
テスト、テスト駆動開発、masarlさんから教わったことと自分の解釈
テストの再分類。粒度・大きさ・いつやるかで分類すると誤解しやすい。TDDのテストはテストじゃない議論。Rails ConfでDHHが「TDDは死んだ」と発表などよく燃える話題。
一人一人考えてるテストというものが違う。テストという言葉の広がりを示してるのでまあよい。
大きいテストというものを分割。誰が何のためにやるのか。Developer, Customer, QA。 Customer Testing = 受け入れtest。これが動けばできてるとみなす。0と1に分類、進捗可視化。「進捗は90%です」「95%」「97%」…ってのが原理上なくなる。100か0かしかない。 開発者がやるものはDeveloper Testingの領域に入る。
これで議論がかみ合ってくる。
TDDのサイクル
- テストを書く
- そのテストを実行して失敗させ(red)
- 目的のコードを書く
- テストを成功させる(green)
- テストが通るままでリファクタリング(refactor)
- 以上ループ。
システム開発のタブー「動くコードに触れるな」というルールをこれによって破ることができる。
触れないと腐ってしまう。ビジネスも死んでしまう。動くコードが動かなくなるリスクもあるけどしないと死んじゃう。
TDDと黄金の回転
（黄金の回転はスティールボールランの概念）
回転が歪んでしまってテスト駆動開発がうまく行かなくなることがある。どっかが短くなる。でそれは必ずRefactoring。開発が忙しくてリファクタリングの時間ないので…みたいなことで。
汚い-動作するの象限は 堕落と恐怖 「動いてるからいいじゃん」
こうすると汚いのところで矢印がぐるぐるしだす。テスト駆動開発のリファクタリングは汚いからきれいへ向かう唯一の矢印。
機能が追加されたらリファクタリングではない。 -> 何も機能が増えないことに対して時間を使わせてくれというのは技術者以外にはなかなか受け入れてもらえない。
リファクタリング を リファクタリング と呼ぶことによって リファクタリング できないというジレンマ。リファクタリングもプログラミングスタイル。個人レベルで小さくはじめよう。
戻ると。
アウトプットするとインプットが増える。インプットはさらなるアウトプットへ。 出せば出すほど出す人へ情報が集まる。
Web+DB PRESSの巻頭特集を書く。紙媒体でアウトプットをするようになる。
gihyo.jp の連載をするようになる。動画付きで解説。
http://gihyo.jp/dev/serial/01/tdd/
自分の得意分野ができた。セルフブランディング。
One more thing…
（これをやりたかった）
2008/2/14、デブサミ2008で登壇。デベロッパーテスティングライブ。
やってみせる（背景マリオ） ＜原体験：強い印象をもってもらうためにはやってみせる＞ ライブコーディング。
java-jaとの遭遇 「ジャバジャ」
Twitterの渦に入る
4つ目の時期 – 渦を作る influence
教わったもの
現実と立ち向かう術
ペアプロの楽しさ
プロとしてのたしなみ
それを伝えるイベントを作れないか 教えられる人を増やそう
TDDBC東京 テスト駆動開発を1日で体験するごっついイベント。ずっとペアプロで演習する。 北陸、名古屋、札幌、福岡、…
渦ができた
恩返しできなくなったので恩送り。フィードバックの渦をもっと多くの人に広げていく。渦をつくる側に。
この先生きのこるために
一生プログラマでいたい。どういうことを考えてるか。
1: 身の回りをプログラミング対象にする
学びたいものと違ったとして仕事ではこの言語でメンテナンスしつつ… 仕事と自分の興味がずれてくる。こうしたときこそ手段を目的化しよう。自分が実験台になる。自分だけの日常に関連するものをプログラミング対象にする。利害関係者は自分だけ。欲望に従う形に。学びたい言語が出てきたら実験台になろう。
本の監訳自体をプログラミング対象にした。 プログラマらしさとは？
- 怠惰・傲慢・短気
- プレーンテキストを好む
- すべてをバージョン管理
- すべて自動化
- 変化を抱擁する
- 編集者が不都合を感じたらさらに技術力で解決。
原稿をmarkdown形式、原文をスクレイピングして取得、gitにぶちこむ、herokuにpushしてサイトに反映、監修差分はdocdiffで表示。 ここまでやって安心してもらえた。 （コミット数グラフ：7月はW杯があったのでコミット数が減った）
自分の身の回りくらい手段を目的化しないと…
2: 年下から学ぶ
@dankogai : 一生プログラマでいられるかどうかは、言い換えれば年下から学べるか否か。
謙虚であること。いろんな人に対して礼儀正しく誠意を持ってふるまう。これは最終的に自分にとって得になること。人として大事な姿勢。
86世代・91世代・96世代 …
3: 過去から未来を知る
技術は「振り子」 トレンドに揺り戻しがある。分散システム -> 中央集権システム -> 分散システム -> … 時代は○○だ！みたいなのに揺り戻しがある。 サーバー側で全部やるアーキテクチャとクライアント側で可能なだけやるというアーキテクチャにも揺り戻しがある AJAX -> Rails -> Angular.js -> (security, testability issues…) hogehogeはいい！ -> hogehogeの暗黒面 -> …
振り子になっている技術自体はどうやって見えてるか？
-> 技術は「らせん」 僕たち自体が成長してるし、技術も成長している。 戻ってきたように見えるが同じところにとどまっていない。
技術者として枯れてしまう状態とは？ -> らせんではなく振り子になってしまっている。何が変わったかに敏感であるべき。何らかの進歩が自分も技術もあるハズ。パラダイムが可能になった土壌があるはず。何？
ベテランが有利なのは「らせん」を何周も見てる。学び方について意識的になれる。
4: 人と流れを見る
組織から個人へ
オープンソース開発は大きく変わりました。開発の世界が組織から個人へ。何らかのコミュニティに入ってコミュニティのプログラムを作ってた。
sourceforge -> github 重心が圧倒的に変わった。組織がほぼない。個人がオープンソース開発を行ってその集合体としてコミュニティを構成する。Apache Foundationに参加しないとApache開発できなかったのがApacheに対してパッチ送りつければよくなった。
個が多く集まると何かが起こる。とてつもなく活発になった。github上の個人のレポジトリとcontributionを視覚化した図。たくさん集まってるのは何らかの中心。ゆるやかなオープンソースのコミュニティになっている。
before/after Rails この変化はGithubによって生まれた
node.js バカにされてきたJSが実際にサーバー・クライアント・… あまねく浸透して使われる時代が来た。個々人の集合が互いに影響しあって先にすすんできた。
委員会設計(design by committee)の終焉
標準になったあとに実装がされていた。Java本体とか。
よいソフトウェアは先に実装があってそれが使われることでde facto standardになる。今まで使われてきたソフトウェアはそうなっていた。
社会が選択したのは：個人やチームのよいものが磨かれて事実上の標準になる -> そこから標準が逆算される
5: アウトプットする
- ブログ。はてブロへ移行。目標は月記。
- Github
- power-assert, qunit-tap
- 使われるようになるために考えたこと・フィードバックがスキル向上の刺激になった。 *いち技術者として考えてることを世に出すのがよいのでは。
- 自分の得意分野を作る。
セルフブランディングとは
not 実力を虚飾すること but 実力を価値ある状態にすること
ネット上で目立つことではない。自分の実力を魅力ある状態にすること、し続けること。
学び方を学ぶ
レッテルをつけてしまうと罠になる。 技術を学ぶのではなく、技術の学び方を学ぶ
寿命があって螺旋構造になってるから学び続けないと価値ある状態におき続けられない。
手を動かす
人の話をその通りに受け取らない。 自分で動かしながら自分で判断する。自分の軸をつくる。
技術者と英語
英語からは逃げられない。英語で情報を収集する・発信することからは逃げられない。英語と日本語の情報量は決定的な差があります。個人の中で埋めないといけない。ということは差別化要因になりうる。 英語を学ぶことで自分のスキルセットのインプット量を増やせる。覚悟を持って立ち向かえ。
好きこそものの上手なれ
好きだからこそ上達する。最初から好きだってわけでもない。 まず知っていないとできる状態にはならない。まだできないからやらない -> ×。やってるうちにできるようになる。やらないとできるようにならない。最初から好きというものはそんなにはないはず。やってるうちにだんだん好きになってくる。はじめてくるとだんだん好きになってくる。好きになれば上達するための力が生まれる。できないからやらない、嫌いだからやらない -> ×。やらないと好きにならない。多くのフィードバックに対して決定的なきっかけになる。 何をやるか、は技術者の戦略そのもの。自分のinputから判断する。どうやって真ん中から離れて立ち位置を設定して差別化要因とするか。
『達人プログラマー』
毎年ひとつ新しく言語を学ぶ 毎四半期ごとに新しい技術書を読む → ほんとに効果がある。
言語はひとつひとつ文化や価値観がある。できれば違うパラダイムの言語。
コンサルタントとして仕事してるので言語が増えれば増えるほど仕事にもいいフィードバックがある。 今年t_wadaさんがやってるのはGo言語。
おわりに: why TDD？
ひとりから始められる 味方がいないとアジャイルやペアプロはできない。TDDは結果としてコードとの向き合い方、姿勢。開発プロセスに関係ない。がっつりウォーターフォールの中でもできる。その結果の共有で人に影響を与えることができる。自分自身から変われる。 TDDはスキル。 習得可能。 : 練習すればできるようになります。 量は質になる。 : やればやるほどうまくなる。フィードバックサイクルが働く。最初はできなくていい。 写経！ : まずはやってみましょう テスト駆動開発入門 リファクタリング どちらも絶版だけど返ってくる Clean Code 渦に入り、渦をつくる
次はあなたの番です。
（講演おわり。続いてフリーディスカッション）
open discussion
Q1. テスト書くのだるいんですけど
個人としては別に書かなくてもいいかなとは思ってる。チームだったらチーム員のために書く。 不安に対してテストを書く。不安じゃないことに対してテストを書くのは言って見ればだるい。 だるいのであればテストコード作成の自動化、さらにそれの自動化、… 自動化そのものがプログラマとしての興味になっている。 TDDは不安の制御の方法。一定のレベルの人はTDDする必要がない。一発でバグが出ないのかけるならTDDは要らない。動作するドキュメントとしてテストコードを残す、etcという目的でテストコードを書く。天才型プログラマはテスト書かない(e.g. まつもとさん)。自分の能力の限界を超えるためにテストを書く。忘れてしまったもののメモとしてテストを使う。
Q2. テストとドキュメントの関係はどうとらえるか
“test works. document doesn’t.”
どこをどうメンテナンスするか識別しにくいというのがドキュメントの弱点。動作しないからドキュメントは要らないではなく、それぞれ得意分野・不得意分野に応じて適切な量を書いていく。
やっていないことをコードで示すことはできない。こういう意図でこうしてる、というのはコメントやドキュメントで書くしかない。
コードの視点は実装に近すぎる。アーキテクチャの視点を書くことができるのはドキュメンテーション。設計選択とその意図はドキュメントにしよう。利用例・使い方・細かい仕様はテストコードのほうが得意。
Q3. オープンソースのプロジェクトでこれはすばらしいと思うものは？
多くの人が使っているものは結果としてドキュメントは増える。 最初はどのプロジェクトもドキュメント不足。プログラマの怠惰さが勝る。その後コミュニティが大きくなるとドキュメントへのcontributionが増える。 RoRのコード自体はコードの中に大量のドキュメントを含んでいる。テストコードとドキュメントの量が多い。
Q4. DoxygenとかJavadocの自動生成ってどうですか
詳細なのができすぎてリファレンスには向くけど設計などの俯瞰視点には全く向かない。ソースコードとは別にMarkdownやwikiで書かないと…。
Q5. エンジニアでいれる人/いれない人ってのがいるけど何が分けるのかどう思うか
（質問者「（自分の周りは）ほぼだいたい『死亡』していてですね…」）
意思でも能力でも努力でもないと仮定すれば環境か。ロールモデルとかキャリアパスが日本では全然ない。環境面での試練として出てくる。一生エンジニアでいたいと思っても管理職せざるを得ないとか会社に居続けるためにはそうできないとか…。時間が使えなくなって手を動かせなくなってフェードアウトしてしまうってケースが一番多い。プログラミングの世界はキャリアパスを作れて来れなかった。35歳以降プログラマするっていうパスが最近はやっと出てきた。待遇を上げるためには管理職になる、家族を養うためには待遇を上げる必要がある、…
ひとつの会社での会社員としての人生より技術者としての人生のほうが長い。社外の人と関わる。
姿勢：年下から学ぶができなくなると危ない。
50代でエンジニアっていうとぶち抜けていてかつ家族の理解があってでないと…。 30代で子供ができて時間なくなる・管理職になって技術できない・でも仕事安定させないと家族養えない・我慢してたらついてけなくなった… ってのが多いので意識的にやらないといけない。
Q6. （プログラミング・システム開発において）「銀の弾丸」が現れる可能性・必要性はあるか？
出ません。
近いものは出てくるけどそれさえあればってのは出てこない。対象が変わっていくから。オオカミに撃てば死ぬけどほかの対象には撃てない。銀の弾丸と思ったらそれは技術者としての自分をbindingしてしまっている。
Q7. Visual Programmingって教えるものとしてどうですか
プログラミングと思わずに興味を持ってもらうためにはいいのでは。まずは興味もってもらわないと話にならない。
入門してもらうときはJSでやってもらっている。why?対象への作用が目に見える。開発環境がないとって言われると入り口に立ってすらもらえない。そして作用がハデ。
何が楽しいかって自分の考えたとおりにものが動くこと。それを小さくしたスケールで。
セミナーの裏番組がScratchで保育園とかの子にプログラミングを教えるみたいなのだった。
可視化って意味では未来ありますよね。
Q8. コンピュータ科学の理論とか数学の理論とか、どうやって仕事に生かしていくかとか考えたことはありますか
理論が差別化要因になった。喜ばしい話です。
今までも理論的背景の強い分野と経験的(heuristics)な分野があった。わださんがやってたのは後者。両者はバランスをとって学ぶ必要がある。サイエンスなのか知恵なのかは技術者として嗅覚を持っておいたほうがいい。プラグマティズムによって世の中は動いているけれど、背景になるものには数学的・論理的背景があってそれは強い。嗅ぎ分けるのが大事。
データベースの話。Relational, Object, …。Relationalには数学的・論理的背景がある。関係代数がベース。あの世界の中では閉じてる。実装としてSQLになって若干破綻してるけどそれでも強固。Non-relational DBはまだ数学的バックグラウンドがないため技術の選択が揺れ動いている。
“Worse is Better”という技術エッセイ。相対的に悪い・間違えていると思ってきたものが強く生き残っているのはなぜか？正しさだけではない要因で生き残っている技術がある。タネンバウムとLinus Torvaldsの争い(multics vs monolithic)とか。技術的きれいさではmulticsだけどlinuxが生き残った。 どうやら理論的正しさだけでは生き残らないけれど両方生き残ったら技術的正しさよりも、ざっくりした結果としてはシンプルなほうが生き残ってる。いつもシンプルなものが生き残っているとは限らない。”Simplicity Matters”
サイエンスは大事。diffには強固なアルゴリズム背景がある。diffの実装の論文読むと超面白い。ポーティングできるのもサイエンスの背景があるから。
Q9. （我々の努力以外の面で）仕事を効率よくするための制度とかを考えた場合どういう制度がいいのか
僕らの世代の義務でもあるなあとも思ってる。 技術者として居続けるための居場所をシステム会社ほど作れてこなかった。CTOになるか出るか。待遇を含めたキャリアパスのあるところにいい人ほど集まる。待遇面は大手のシステム会社しかなかったのがいろんなところができた。エンジニアに来てもらうためには魅力的でないとダメみたいになってきた。
技術者の転職事情：やりたいことができるか、面白いことができるか、成長できるか。2/3になっても面白いことできるなら転職しちゃう。
待遇を上げるために管理職にならなきゃいけないではなくキャリアパスがあるっていうのは魅力。
何をやりたいかに加えて誰とやりたいっていうベクトルもある。
技術者としてのアウトプット：どこの誰ですって言える会社のほうが魅力的になる。外に発信することを認めてくれる・後押ししてくれるっていうのは魅力。会社としてアウトプットにインセンティブを働かせてくれることはよい。
技術ブログは大好き。会社を見るきっかけになる。
Q10. 良いテストって何ですか？
バグを見つけるテストはいい っていうのが一般論。
developer testingの文脈でのいいテストコードは、と狭めると、読みやすいテストコードはいいテストコード。何をやっているかわかりやすい、というのが大事。 オールグリーンだからオッケー！ではない。何やってるかわからないけど通ってるからいい、ってのはマズい。何をテストしているか、何の動作確認をしているかっていうのがわかりやすいコードはよい。
1個のコードで1個のことをテストしているほうが「人間にとってわかりやすい」。assertionを各テストあたり1個に減らす。そういうテストコードのほうが何をやってるかはっきりしている。そのテストで落ちたらそこ。
スピードのことはあまり気にしないでください。速いテストが偉い訳ではない。
よいtestはrepeatableである必要がある。何度動かしても同じように動く必要がある。対象コードが変わってなければ緑である必要がある。「僕の手元では動きます」「ほかでは動かない」はnot repeatable。
よいtestはindependent。A,B,CのテストコードがあってABCなら動くけどACBなら動かないは×。依存関係があっちゃいけない。
repeatableでindependentさえ守れていればスピードのことは気にしないでいい。速さは正義ってなりがちだけど速さを追い求めるために難しいコードになってしまうと本末転倒。一つだけをテストするコードをガンガン機械にやらすのがよいテスト。
Q11. もし自分が今からやるとしておすすめの言語は？
言語には背景・paradigmってのがあります。自分の得意な言語と違うparadigmのものを学ぶのがよいでしょう。 オブジェクト指向 <-> 関数型、静的で強い型付け <-> 動的型付け。 自分の持ってるものと違うものを学ぶのは学びが多い。 Rubyistの場合PythonやるよりはHaskellやるほうが学びは多いよ。 『7つの言語、7つの世界』 : いろんなパラダイムのいろんな言語を3日ずつで学ぶ。 LISP系言語触ったことなければLISP系やると影響大きいよ。 githubの使用言語ランキングとか。 仕事につなげると考えないほうがいい。色気が出てノイズが入る。
Q12. 一つのバグに対して最長どれくらい悩んだ？
潜在期間っていうのはあるけど、わかってから悩んだ期間でいえば…
IE6の実装に起因する不具合っていうのが多かった。「IE6だけでときどき動かない、再現性がない」「OSSじゃないからコードの中身見れない」「ある特定のお客さんのところでしか動かない」っていうのが大変だった。
バグがわかったらそれを再現するテストコードを書く。そのテストコードが通ればバグは消えた。というエッセイを書いたことがあるけど
JSの同期処理・非同期処理に基づくエラー。
Q13. 職業エンジニアと自己実現はかけ離れているけれど、その葛藤はあったか？会社の中でやる？or独立？
コンサルティングやってると助けてくれっていう依頼が多い。そうしたときは相手先の人にスキルアップしてるという実感をもってもらうっていうのは多い。
日々のプログラミングと仕事が離れてきたらどうするか -> 仕事のプログラミング以外のものをすべて自分のエゴで満たす。ビルドスクリプトとか。
GHで集団から個人に移った。OSSコミュニティが自己実現の場になった。GHを契機とした仕事の依頼/Hiringの依頼が来る。海外の会社からスカウトのメールが来る。技術者として成功したいと思ったらそれに乗ってみるのはアリかもしれない。自己実現のためのエンジニアリングを自分で閉じないために本業以外のコードやOSSを自分のエゴでやっていく。
やりたい仕事をやれる会社に転職していける社会のほうが健全。言語と会社の関係がわりと鮮明になってきた。転職の一条件になってきた。生存戦略として会社と言語ひもづけることも。だけど会社にとっては試練のとき。
（質問者：昔の会社は何で作ってたかもしゃべることすら許されない。会社の名前と自分の名前出せない。ヘッドハントされるから。）
講演の場で会社の名前出せるほうがいい印象。dwangoとか、ある技術選択することによって人が集まってさらに人が集まる吸引力を発揮する。ここ数年でほんとに健全な方向になった。ネガティブじゃない形で転職できるようになったいい時代になった。
この会社こういうことやってるんだな・この会社こういう人がいるんだなっていうのがわかるのはいい。アウトプットに意識的な会社は面白い。技術ブログとか。
自己実現できないから独立するってなると面倒ごとのほうが多い。決算とか営業とかしなきゃいけなくなる。フリーランスになるとプログラミングの時間増えるかというと考えなきゃいけないことが増える。そういう面で頼れる人を探すのもあるけど…。
ギルド的な働き方ができるようになってきた。「共有の大蔵大臣」みたいなのをたてられる制度もできてきた。個として立つためのフォローアップ制度ができてきた。
独立したからバラ色かというとそんなことは全くない。
仕事がないとお金にならないっていう事実をまざまざと知ることはできるので独立してみるのも経験かもしれない…
Q14. よい読み物・本はどうやって見つければいいのか
一つは人を見る。know-howではなくknow-who。探し方を知ってそうな人を探す。誰が見つけたか・いつ見つけたか。はてブは人をフォローできるので面白い情報をブックマークする人をフォローするといい。
もう一つ。技術書は引用にグラフ構造を持っている。リンクをたどるのはよい本のたどり方。たくさんのリンクが向いてる本はいい本。リンク集的な本を読むのがいい。（きのこ本の営業）
一番引用数の多い本がわかる。達人プログラマーは70人中18人くらい引用してる。
Q15. 技術書は紙と電子どっちがいいか
写経をする上では電書のほうが有利。同じディスプレイにあるほうがいいですよね。紙のときは書見台が欲しかった。
デメリットがあるとすればコピペ可能は罠。電子書籍で写経しつつコピペの誘惑には勝たないといけない。指を動かすことそのものがインプット。「なんでこの人はここにスペース入れるんだろうか？」みたいな記述の癖とかも気づきやインプットになる。
電書だけ買って読みやすいかというと微妙。電書の検索をするためにはそのワードの存在を知らないといけない。読んだことのある本の検索には向いてる・前からみっちり読むことには向いてるけどざっくり頭の中に入れるには向いてない。精読とざっと読むのと2種類ある。頭の中のデータ構造としては連想配列しか残らない。検索可能化するためのインデックスを作るためには紙のほうがいいことがある。悩ましい。両方買っちゃったほうがいいという話も。
検索されることを主眼としているような本は電書。O’Reillyのサイ本は圧倒的に電子。概観をざっととらえる本は紙かな。迷ったら電書でいいかも。なぜならどこでも読めるから。必要なときには本が手元にないみたいなパターンはけっこう多いが電子だとそれはない。量と検索性においては電子のほうが圧倒的に強い。技術者の学びは電書にシフトしていくだろうなあと思うし、電書に積極的な会社そうでない会社は技術者にとっては差別化要因になってくる。もっと電子書籍化は進むでしょう。しかし永遠の課題は残る。
Q16. UIのTDDについて
（質問者：ビジネスロジックが安全だからいいよねみたいだったけどモバイルになってからビジネスロジックよりUIのほうが長くなった。UI重視の開発でTDDするにはどうしたらいいのか？）
自動テストとUIは相性が悪いです。隠しようがない。UI以外のことにロジックを書きましょう、が教科書的なことだった。
サーバーサイドが薄くなってブラウザ側でやらなきゃいけないことが多くなった。コードは増えてきてるのにテストがしにくい。コード量に対してカバレッジが減ってきている。MVC, MVVMパターンとかを使ってUIの中でもテストできる領域を増やしていこうっていうのはあるけど超ナマモノ。まだ研究中。
fragileなテスト（レイアウトが変わったらテストが落ちちゃう、項目1つ増やすと死ぬとか）を書かないためにはレイアウトのテストをせず（例:DOMのテストをしない）画面に何が出てるかみたいなやり方でやる。
UI/UXじゃないところはテストはしやすくなった。
JSのテストフレームワークは昔は戦国時代だったけど今は2強になってきた。昨年末の時点ではJasmineが44%、Mochaが42%になってきた。UI側のテストの仕組みは増えてきた。
レイアウト・色合い・重なり・使用感は現状テストできないししばらくできない。人間がやるしかない領域に人間のリソースを全力で使えるようにほかのところを固めよう。
最近の技術のトレンド：画像のdiffをとるframeworkがいくつか出てきた。BBC Newsがオープンソースにしたもの*4とか。従来無理だろうと思われてきたものもできてきている。でも銀の弾丸は全然ないしそもそもまともな弾丸すら少ない。
この記事は第2部に続きます。
