『プロトタイピング実践ガイド』読んだ

趣味でWebサービスやiOSアプリを開発していると、 ついすぐコーディングに入りがち。

自分が欲しい（または作りたい）アプリを作るから、 頭の中に完成イメージがあるとはいえ、その輪郭はたいていぼやけている。 そのため、勢いで実装し始めたものの、途中で使いづらいと感じて、 UI を変更することも少なくない。

実装中に UI を変更するのは大変だし、 UI の修正中は動いているところを見れないことも多い。 結果、モチベーションが下がる、というよくあるパターンに陥ってしまう。 それを回避するためにもプロトタイピングが必要。

ただ、闇雲にプロトタイプを作ればいいってものではない。 需要をリサーチし、ターゲットユーザーや利用状況を決め、 機能とコンテンツを選定する。 必要な機能だけに絞って実装し、その他の機能は潔くあきらめる。

そして、ペーパープロトタイピングまたは POP みたいなアプリを使ったツールプロトタイピングで、 レイアウトや画面遷移を検討。 デザインだけでなく使用感までチェックして改善を繰り返す。 なるほど、ここまで固めることが出きれば、開発の出戻りは少なそうだ。

WebサービスやiOSアプリの新規作成または改善で、 本書の手順で開発してみようと思う。

プロトタイピング実践ガイド スマホアプリの効率的なデザイン手法

『達人に学ぶ DB 設計徹底指南書』読んだ

データベースについて今までちゃんと勉強してこなかったことは、過去のエントリで書いた。 まったく勉強しなかったわけじゃないけど、 せいぜいソフトウェア開発技術者(現・応用情報技術者)の資格を取るときに少し勉強した程度。

データベース設計は、既存のデータベースを参考にしたり、過去の経験をもとに設計してきた。 理論的というよりも感覚的に作成していたと言っていい。 本書を読むことで、感覚的に行っていたやり方が、理論的なものに再構築された気がする。

気になった箇所に付箋を貼りながら読んだので、それをメモしておく。

概念スキーマ

• 概念スキーマは、外部スキーマと内部スキーマの間に位置する
  • 外部スキーマと内部スキーマの両者の変更が互いに影響しあわないようにするための緩衝材

ハードウェアのサイジング

• 性能問題のほとんどはストレージの I/O ネックによって引き起こされる

ストレージの冗長構成

• データベースの RAID は少なくとも RAID 5 で構成する
• お金に余裕があれば RAID 10
• RAID 0 は論外

バックアップ設計

• バックアップ方式は、「フルバックアップ + 差分バックアップ」または「フルバックアップ + 増分バックアップ」が一般的

正規化

• 第 3 正規形までは原則として行う
  • 関連エンティティが存在する場合は、関連とエンティティが 1 対 1 になるように注意する
• 原則として非正規化は許さない
  • 非正規化はあくまでも最後の手段
  • パフォーマンスを向上させるためのその他すべての戦略が要件を満たさない場合だけ

インデックス

• 大規模なテーブルに対して作成する
• カーディナリティの高い列に作成する
• SQL 文で WHERE 句の選択条件、または結合条件に使用されている列に作成する
• レコード数が 1 万件以下の場合はほぼ効果が無いと考えていい
• 特定のキー値を指定したときに、全体のレコード数の 5% 程度に絞り込めるだけのカーディナリティがあること

達人に学ぶDB設計 徹底指南書

金田家

福岡県の行橋市にある人気ラーメン店『金田家』。 行橋市は場所的に大分に近く、車を持っていないから行くことは無いだろうなと思っていたら、 なんとキャナルシティのラーメンスタジアムに出店していた。 この期を逃すわけにはいかないので、 さっそく会社帰りに行ってみることに。

注文したのはラーメンと餃子とご飯のセット。 ラーメンはポタージュスープかと思うくらいクリーミーな豚骨。 今まで食べたラーメンの中でも1位2位を争うクリーミーさ。

餃子は非常にジューシーで旨かった。 ラーメン屋の餃子っていうレベルじゃない。 餃子とご飯だけでモリモリ食べれそう。

あとご飯。

ようやく念願の金田家のラーメンを食べることができた。 ラーメンは期待通り、そして餃子は期待以上の旨さだった。

金田家 キャナルシティ博多店

関連ランキング：ラーメン | 祇園駅、中洲川端駅、渡辺通駅

Vim を更新したら undofile が作成されるようになっていた

久しぶりに Windows 版の Vim を更新したら、 編集したファイルと同じディレクトリに .{ファイル名}.un~ というファイルが作成されるようになっていた。

これは undo の情報をセッションを越えて保持できるようにするためのファイルのようだ。 どうも、Vim は 7.4.227 からデフォルトでこのファイルが作成される設定になったらしい。

ファイルを開きなおした後もアンドゥできるのは便利機能だけど、 今のところ必要としていないので、.vimrc に

set noundofile

を追加して無効にしておく。

『達人に学ぶSQL徹底指南書』読んだ

最近は RDB や SQL について集中的に学習したい衝動に駆られているので、 今度は SQL のテクニックを身に着けるために本書を購入してみた。

本書では数々の SQL のテクニックが紹介されているが、 その中心はなんといっても CASE 式。 CASE 式徹底指南書と呼んでもいいじゃないだろうか。

特にインパクトがあったのは次の一文。

WHERE 句で条件分岐させるのは素人のやること。 プロは SELECT 句で分岐させる。

似たようなのにこんなのもあった。

HAVING 句で条件分岐させるのは素人のやること。 プロは SELECT 句で分岐させる。

WHERE 句や HAVING 句の条件が違う SQL を、 IF で分岐させて記述したり、 パラメータを変えて何回も実行したりしていた自分は、 まさに SQL 素人だったというわけだ。

CASE は式なので、式が書ける場所はどこでも使える。 SELECT だけじゃなく、GROUP BY や集約関数の中でも使えたりするから、 書ける SQL の幅が一気に広がる。

CASE 式を使いこなせるようになることが、 SQL の素人を脱してプロになるための第一歩だな。

達人に学ぶ SQL徹底指南書

『How Google Works』読んだ

去年話題になった、Google 会長が Google について書いた本。 去年のうちに一度読んだけど、あらためて読み返してみた。

Google の強さは、『スマートクリエイティブ』と呼ばれる飛びぬけて優秀な人材に、 自由と権限を与えていることに尽きる。 規則で彼らの手足を縛らないことで、予想以上の成果をあげてもらう。 『エンジニアに聞け』という言葉がすべてだと思った。

ただ、魅力的なプロダクトやオフィスや福利厚生を持ち、 AdSence という絶対的な収益源がある Google だからこそ成功した感が強い。 スマートクリエイティブが集まってくる好循環がすでに出来上がっている。

Google と同じことをやろうとしたら、 自由にやらせて成果が出なくても耐えられるだけの体力が企業に必要。 大企業ならその体力があるだろうけど、規則でがんじがらめでは無理。 トップダウンで改革すればいけるかもしれないが。

一方、身動きがとりやすいスタートアップだと、 スマートクリエイティブを引き寄せる武器が、 プロダクトの成長性やストックオプションくらいしかない。 収益が安定していないとスマートクリエイティブは他所に移ってしまうから、 成長し続けなければいけない。

結局、『Google みたいにするのは至難の業』という、 わかっていたけどうむむな感想。 真似しようと思って真似できるものではないね。

How Google Works

『SQL 実践入門』読んだ

『SQL実践入門』という名前だけど、 実行計画がバンバン出てくるので、とても初心者向けではない。 SQL と実行計画の解説がたっぷりの、中級者以上向けの本だった。

SQL の実行計画が読めれば、SQL のパフォーマンス問題の大半が解決できそうに思える。 例えば、テーブルに何度もアクセスしていたり、インデックスが使われていなかった、 といったことが原因なら実行計画を見れば判断できる。 また、結合時に TMP 落ちしていて余計なディスク IO が発生している、ということも 実行計画を見て推測できる、かもしれない。

ただ、実行計画は統計情報から作成されるので、統計情報が実際のデータと違っていたら、 実際のデータに即した実行計画は作成されない。実行計画を100%鵜呑みにはできない。 モデルの設計を変更しないと根本的に解決できないようなケースも存在するので、 実行計画が読めれば全て OK というものでもないのがツライところ。

自分の場合、実行計画については無頓着だったので、実行計画を意識して SQL を書くように心がけよう。 本当は実行計画を意識しないで済むのが一番いいし、SQL はそれを理想としているみたいだけど、 理想にまだ現実は追いつけていないから。

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)