else に書かれるべきロジック

2 種類が混ざって使われていないか？という気づきをメモしておく。

• 正常系パス
  • 例えば、boolean を返す問い合わせメソッドのように 分岐のコードパスが 2 つしかない場合
  • これは何も問題ない
• 例外を避けて安全側に倒したデフォルト
  • これが正常系パスのように扱われているケースがないか？
  • ほんとに後続処理をして問題ないか？
  • 例外を出せない理由があるなら、ログを追加して運用で対処したりすべきではないか？（と考えているが、そのように判断されることがないように思うのでこの記事をメモした次第。）

Rails で RESTful な URL にこだわらないと...

備忘録。

ダメなルーティングの臭い

• 名詞ではなく動詞が使われている
• resources/resourceよりもget/post/put/patch/deleteが使われている
• コントローラ内にscaffoldで生成される7つのアクション以外のアクション定義が多い
• resources/resourceのonlyオプションで本来使われるべき7つのアクションがcollection/memberブロック中に登場する

ダメなルーティングだと起こりえる問題

• リソースの発見を逃す
• モデルとテーブルの発見を逃す
• 機能追加の際に、テーブルにNULL可なカラムを追加し、レコードをUPDATEする処理を書くようになる
• 1つのテーブルに複数の要件が盛り込まれ、モデルのコールバックなどで「関心事の分離」ができない状態になる
• しばしば正規化が崩れ、状態管理が複雑になる/過去の状態が追跡不可能になる
• コントローラにアクションが増えるにしたがって、モデルにあるべきロジックがコントローラに残る（Fat Controller）

避けるためのヒント

• resource/resources の単数/複数の違いを知る（inflector なども調べとくとよい）
• shallow/module/namespace/path オプションとコントローラの書き方を学ぶ
• scaffold で生成される以外のアクションを極力書かない
• 永続化しないモデルを導入してエントリポイントとする（サービスパターン、ファサードパターン）
• DB のイベント系エンティティと REST のリソースを対応させて考えてみる
• UPDATE SQLがリソースの更新以外で発行されたら検討の余地あり

エンジニアが事業計画を知らなくてモノが作れるのか？

駄文ポエムです。

• 先のことなんてわからないし、事業計画通りにいくわけがない。だがしかし

• • 何ヶ月後にどのくらいのユーザを集めたいのか、それがどれくらいのトランザクションを発生させるのか知らなくて作れる？
  • たとえYAGNIといっても直近作るfeatureぐらいは知っているべき

• 事業規模に合わせて段階的にスケールさせていけばいいが、そのタイミングがいつなのか知っているか？
  • プロトタイプレベルの実装とプロダクションレベルの実装は違う
  • 機能が変われば最適なデータモデルやアプリケーションアーキテクチャも違う
  • チーム体制だって違う

• プロトタイプレベルの実装にいくらテストを足したところで改善なんてしない
  • 大量のワークアラウンド実装とそれを保証するテストが追加される
  • 本来、リファクタリングの足場とすべきもののはずが、消して書きなおした方が早いという矛盾

• エンジニアは、トレードオフを都度判断し、決定する
  • エンジニアリング上の判断がサービスの成長や企業の収益に直結する時代
  • 設計を統合したり、ビジネスサイドや経営層にリスクを説明したり諸々提案、交渉する役割を担う人が重要

• プログラミングできればそれで満足なエンジニアなんてほとんどいない
  • サービスが提供する価値は何か、自分のやったことが会社にどういった利益をもたらすのか、世の中にどう役立つのかを知らないで仕事できないよね
  • にんげんだもの

ユアン・マクレガーがフリチンで歌う映画『ベルベット・ゴールドマイン』がBlu-rayで発売されて、レンタルショップでも借りられるようになった！

置き場所とコスパの都合で、ある時から映像作品はDVDを持たずに都度レンタルすることに決めたのですが、レンタルできない作品や、販売用のみの特典がある作品だけは手元に残していました。『ベルベット・ゴールドマイン』は、DVDが廃盤状態でレンタルできるWebサービスもなかったので、手元に残していました。ところが、最近、BD盤で再発されて、それに合わせて、TSUTAYAあたりでもDVDレンタルができるようになりました。これで手放すことができます。内容は、アッー！な感じです。ちなみにですが、本作品中で、ユアン・マクレガーがライブ中に裸になるシーンがあり、北米盤BDなら無修正のユアン・マクレガーのフリチンが見られるかもしれません（未確認）。

ベルベット・ゴールドマイン [DVD]

ベルベット・ゴールドマイン [Blu-ray]

サントラも当時買いました。

Velvet Goldmine: Music From The Original Motion Picture

これが北米盤なのかな？修正入ってるのかな？

Velvet Goldmine [Blu-ray]

MacBook Air用にちっちゃいUSBメモリを買った

普段使ってるMacBook AirのSSD容量は128GBなのですが、容量が苦しくて、スキャン業者に頼んだファイルが入らなくなり、別マシンへのバックアップ作業もかねて16GBのUSBメモリを買いました。以前、KickStarterでパトロンを募っていたNifty MiniDriveを申し込みすればよかったかなと思っていたのですが、どうやら不良品が多いらしいという噂もあって、まぁそんなに後悔してないかなと。

BUFFALO マイクロUSBメモリー 16GB ホワイト RUF2-PS16GS-WH

16GBのUSB2.0仕様のものは家電量販店で2000円くらいのようですが、これはヤマダ電機で3000円くらいでした。買ったのは白で、黒と赤があり、赤もワンポイントでかっこいいかなと思います。

BUFFALO マイクロUSBメモリー 16GB レッド RUF2-PS16GS-RD

つけるとこんな感じ。
[:large]

よかった点

• 小さいのではめたままカバンに入れたりできる。これにつきる。

よくない点

• マウント解除しても青色LEDが点灯しっぱなしでまぶしい！
• 買う前から分かっていたがキャップがある
• 小さい分、引っこ抜きやすい形状をしていて、何かの拍子に外れそうなのが心配

これまでUSBメモリやSDカードは、何度か読み取り不能になったり、書き込み不可能になったりしたので、あくまで一時保存用として使うべきかなと思います。

『リーダブルコード』を他書と読み比べる（その1）

よい本なので、他書と比較しながら再読していきます。短期集中連載のつもり。

1章 理解しやすいコード

ここでは本書の根底となる「すべての原則が生じるテーマ」と「読みやすさの基本定理」について説明がされています。

コードは理解しやすくなければいけない。

コードは他の人が最短時間で理解できるように書かなければいけない。

『C++ スタイルブック (IT Architects’ Archive―CLASSIC MODERN COMPUTING)』の「はじめに」には次のように書かれています。

チームが成果を上げるには、誰もが、他の人の書いたコードを読んで理解できなければならない。

『Code Craft ~エクセレントなコードを書くための実践的技法~』1章「防御的プログラミングの技法」には次のように書かれています。

簡潔性よりも明瞭性を重視してコードを書く

簡潔ではあるのものの混乱を招くおそれのあるコードと、明瞭ではあるものの長く退屈に感じられる可能性のあるコードのどちらかを選べる状況では、洗練性には多少欠けるとしても、誤解なく明確に意図を読み取れるコードの方を使用します。（中略）自分が書いたコードが誰かに読まれる可能性があるのかを考えてみてください。そのコードの保守を比較的経験の浅いプログラマーに任せなければならない場合もあるかもしれません。その担当者がコードのロジックを理解できないとしたら、間違いが起きることは必至でしょう。複雑な構文や言語仕様を巧みに利用した小技を使えば、演算子の優先順位を知り尽くした博識ぶりを見せつけることはできるかもしれませんが、それによってコードの保守性は無残に損なわれてしまいます。「コードは常にシンプルに」が鉄則です。

『Javaプログラミングの処方箋 (Programmer’s foundations)』には、逆に読みにくいコードがもたらす弊害について書かれています。

このようなコードは非常に読みにくく、このあとにこのコードを読む人に誤解を与えます。また、一度このような「汚いコード」が入ると、その汚いコードがほかにもどんどん波及していきます。元のコードが美しければ、それを「汚す」には勇気がいりますが、もともとが汚ければ誰しもコードを綺麗に保とうとしなくなります。

『プログラマのためのサバイバルマニュアル』には次のように表現されています。

人は、複雑さの逆と言われると、単純を思い浮かべる。しかし、私たちの分野には避けられない複雑さがあるので、いつでも単純なコードが書けるとは限らない。複雑さの反対語としてより適切なのは、明快である。あなたのコードがしていることは、読者にとって明解だろうか。

『プログラマのためのサバイバルマニュアル』は上記文章のあとで「2つの明快」について説明が続くのですが、「避けられない複雑さ」というのが気になります。『Developer's Code 本物のプログラマがしていること』（電子書籍もあるよ！）第4章「複雑さ」に面白いことが書かれています。

ほとんどのアイデアーーー見た目にはシンプルなアイデアーーーはその詳細に立ち入るとひどく複雑なものになる。高いレベルで考えている限り、アイデアはいつもシンプルだ。（中略）詳細に分け入ってみれば、ロジックのどこに穴があるのか、そのすべての場所が見えてくる。詳細とはそういうものなんだ。最後まで考え抜かれていないアイデア（つまりほとんどのアイデア）はこの時点で、複雑であることから逃れられなくなる。（中略）僕らは不十分であることを恐れている。そこにその答えがある。何かをシンプルに構築すると、それが十分なもののような気がしないんだ。

『Developer's Code』ではこのあと、複雑さを「コードが書くのが難しい」ことと複雑さがユーザに転移してしまった「使うのがむずかしい」ことの2つを引き起こし、「複雑さを表に出さない」こと、コードの複雑さを嫌うあまり「リファクタリングをあまりに早い段階で行うことの危険性」についての議論になっていきます。

コーディングの際にバイブル的な本として有名な『CODE COMPLETE 第2版 上 完全なプログラミングを目指して』を参照してみると、5.2.1「ソフトウェアの鉄則: 複雑さへの対応」に、Fred Brooksの定義を引用していますね。

Brooksによれば、ソフトウェア開発を難しくするのは、本質的な(essential)問題と偶発的な(accidental)問題という、2種類の問題であるという。

どうやら、複雑さへの対応として読みやすさが重要であるようですね。また、『CODE COMPLETE』5.2.2「設計に望ましい特性」に設計の内部特性を10個挙げています。

• 最小限の複雑さ
• 保守性
• 粗結合
• 拡張性
• 再利用性
• 高いファンイン
• 低いファンアウト
• 移植性
• 無駄のなさ
• 階層化

このうち、保守性がリーダビリティに関係あります。

保守の容易さとは、保守プログラマのために設計することである。保守プログラマがあなたの書いているコードについてどのような質問をするか常に想像しよう。保守プログラマを顧客と見なし、見ればすぐわかるようなシステムを設計しよう。

Kent Beckは『実装パターン』で次のように述べています。

何をシンプルとするかは人それぞれだ。ツールと技術を知り尽くしたプログラマから見たシンプルは、初心者には複雑すぎるかもしれない。相手を意識したときに、よい文章が生まれるように、よいプログラムも読み手を意識したときに生まれる。読み手の少し上を行くのはよいが、あまり複雑すぎると、相手にされなくなってしまう。（中略）コミュニケーションとシンプルは一体となって働くことが多い。余分な複雑性が減少すると、システムの理解が容易になる。コミュニケーションを重視すれば、どの複雑性を捨てるべきかが明確になる。

コミュニケーションまで含めているのがKent Beckらしいですね。相手あっての読みやすさということでしょうか。読みやすさが重要ということが十分に意識できたので、明日は2章「名前に情報を詰め込む」に入りたいと思います。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

Twitter がまだ Ruby on Rails を使っているらしい証拠を発見した。

ERBらしいですよ。変数名は reason と deadline ですって。