大洗レポート

大洗町に行ったので写真を
あんこう鍋食べて神社行ってマリンタワー登っただけです

2012年が終わろうとしている・・・

反省はサルでもできるという現実

ELECTROCUTICAのXENOVERSE(Prerelease Edition)を聴きながら書いてます。いいですねこれ。
今年も結局ブログあんまり書けませんでした。最初は結構書いていたのですが、、

今年は仕事にRailsをマトモに触ってある程度書けるようになってきたのが大きな収穫です。
仕事でもgitメインで使うようになるとは思ってなかったです。

歴史重点

今やっていることが10年後にも通用するかというと微妙なところなのですが、新しい技術を追っていけるということは基礎体力の向上に繋がるとは思っています。なんでかというと、未来の技術は必ず過去の技術の延長線上にあるからです。物事にはだいたい因果関係があります。因果律を破ってしまうことはそうそうできません。歴史は大事。

今やっていることは未来への投資なんです。決して仕事をサボっているわけではありません

新技術要素なんですが、いっぱいありすぎて専門的に全てを学ぶことは不可能な状態だと思います。幅広く概要を知りながら、活用できるチャンスを作ったり、発想の種にできることが大事になってきます。

ここ数年は並列化に関するものがトレンドになりそうな気配がしてますが、これも10年後には知ってて当たり前みたいな状態になっているかもしれません。（メニーコアだったらこう書くのが普通だよね、みたいな）

また、UI/UXのように感覚的で正解が無いものもトレンドに上がっていて、これは2013年に大きく状況が変わっていく気がします。OOP、DDDのように「共通理解」の対象となっていくかもしれません。

関係無いですが、プログラマがサボっているように見えるとき、そいつの脳内では最大限のパフォーマンスで働けています。そっとしてやってください。

来年は本気出す

仕事でいかに人間が頑張らずにすむか本気出してやっていきたい。IT業界で非生産的なことに身体を使って仕事を頑張れるのは小学生まで。頭脳労働者なんだからもっと頭を使って仕事をしたい。

あと、何度プロジェクトをやってもソースを一から作り直したい病になってしまうのをなんとかしたい。納期もあるしこんなんでいっかー（ゲス顔）で作ったものが最後までそのまま使われてしまうのが多すぎる。後悔すること多し。そこで自分の未熟さが露呈します。来年は全体最適をちゃんと考えた上で取り組みたい。そもそも仕事に納期があるのが悪い？その通り。

プログラミングを学習するということ

脳内コンパイラを育む作業

　思考実験内での動作をコンパイラの動作に近づけていく作業

　推論　→　実行　→　フィードバック　→　
- 実行結果が正しい場合：推論が正しいことにする(間違っているかもしれないが)
- 実行結果が異なる場合：脳内思考回路の修正。どうしてそうなったか考える

良いプログラムとは何か？

　プログラム言語には人間の感覚が入り込む余地があり、そこには文学的な側面が生まれる。日本語の文章に正解が無いように、プログラムコードにも正解は無い。
　ただ、良い日本語文章というのが存在するように、プログラムコードにもそのようなものは存在する。

　良いとされているものの特徴を列挙する。

• シンプル
• 意図がわかる
• 程よく抽象化されている
• 表現に一貫性がある
• （直感的に）読みやすい。整理されている。　日本語で言うと、句読点の使い方や改行の使い方

　感動的な日本語の文章があるように、感動的なプログラムコードも存在する。どんなにすごい人も、最初は誰かの真似をして上達してきたという事実がある。上達の近道は良いとされる文章・コードを読み、真似てみること。真似たことは小さい単位でパーツとなって自分のものになる（はず）。
　そうすると、小さいものを組み合わせて大きなものを作り上げることができるようになる。（1からセーターを編むことを想像するといいかもしれない。）

変化に対応できる力

　上記の文章では、プログラムを書けば書くほど上達するように見えるし、それはある意味では正しい。（特に初期段階では書けば書くほど上達する。）ただ、現実ではお年の召された方ほどプログラミングスキルが高いということは無い。むしろ、ある1つのことには強いが、他のことに応用できなかったり、新しい技術についていけなくなるといった傾向が生まれてくる。本当に良いプログラマに年齢は関係ない。ただ、日頃からの情報収集（アンテナ・トレンド）や作業効率を高める工夫（開発環境・エディタ）といった部分でもかなりの差が出てくると思われる。

夏風邪

治らない！
だるい！
鼻水止まらない！

プログラムについて思うこと

• オブジェクトの責任範囲大事
• 責任範囲を決めるのは名前
• 名前大事
• 名前がひどいと混乱を招く
• 何か処理は書いているが何をやっているのかよくわからないのは悪い兆候
• 難しい処理、ローレベルな処理は裏に隠蔽する。使う側で簡単にさせることを意識
• 本質的な処理を書いていくようにする。オブジェクトに値を詰め詰めするとかどうでもいい部分は書きたくないし意識したくない
• 知りたくないことまで知りたくない

コードで表すと、

PagerFilter filter = new UnlimitedFilter();
Searcher searcher = UserService.getUserSearcher();
SearchInfo searcheInfo = searcher.search(
  Searcher.USER_SEARCH_SCHEME, 
  LoginUserInfo.getCurrentUserId(),
  filter
);
User user = (User) searchInfo.getFirstObject();

みたいなインターフェースよりも

User.current

の方がわかりやすくて良いよねという話

レビューをするときはなるべく本質的な所を突っ込みたい

• 軽い誤字脱字レベルをチクチク指摘しても根本的に良くならない
• どうでもいい部分・表面的な部分を指摘して思考停止しない
• 逆に、お役所向け文書なんかは中身どうでもよくて体裁が一番大事なので注意。腐っている

同じようなミスを2回したらどうすんの？

特にミスったわけじゃないけど
・落ち度は誰にある？その仕事をした人、その仕事を任せた人
・同じ失敗すんな！！！！　→　プレッシャーでもう一度失敗
・フォローが大事。起こしてしまったことはしゃーない
・むしろ、ミスったら報告できる雰囲気は大事
・だいたい、何回もミスっていることを人にやらせるのが悪い。人間はミスする生き物なんだから自動化しろよ