「楽々ERDレッスン」が実務で役立つ実践的な良書だった

「楽々ERDレッスン」というデータベース設計に関する書籍を読みました。

楽々ERDレッスン (CodeZine BOOKS)

タイトルでも書いたとおり、かなり実践的で役立つ本です。

「教科書的な知識はあるけど、実務経験があまりなく自信がない」という人にピッタリの本だと思います。

読んでいる最中に「あ、そうそうこれ困るんだよね」とか「ここはこういう風に考えたら良かったのか」とか「あの時の俺の判断は正しかった……！」とか、 これまで自分が実際にデータベース設計をする際に遭遇した「教科書通りにいかなかった点」がいくつもあり、読んで非常に楽しかったです。

以下の記事でも軽く触れました*1が、 この本が提案する ID とコードの捉え方については自分的には目から鱗でしたので、 一度目を通してみることをオススメします！

necojackarc.hatenablog.com

ID はそのレコードへのポインタであり、データライフサイクルを表す。 コードとは業務に基づく恣意的なもの、というのがザックリとしたまとめです。

ID リクワイアドもこの観点でみると、アリだなぁという気がします。 実際便利なことも多く、他で制約をキッチリつけておけば問題を引き起こすことも少ないと思います。

とまぁ、そんな感じで非常に有用な本ですので、実践的なデータベース設計について学びたい方は是非読んでみてください！

ただ、正規化などの基本的知識に関する内容についてはこの本には書かれていないので、 一旦他の本で「教科書的な知識」を身につけた上で取り掛かるのが良いかなと思います。 あくまでこちらは「データベース設計の実践入門」という位置づけだと思います。

RDB 力あげて行きましょう(´∀｀∩)↑age↑

*1:この記事を書いた当時は、軽く立ち読みしただけでちゃんと読んでいませんでした。

「UNIXという考え方」が「成功者の哲学」という感じの良書だった

「UNIXという考え方―その設計思想と哲学」を読みました。

UNIXという考え方―その設計思想と哲学

タイトルにも書いてありますが、「成功者の哲学」という印象を受けました。

基本的にはソフトウェア開発に関する「設計思想」や「哲学」について書かれている本ですが、 その考え方や哲学はソフトウェア開発という狭い枠を超えて適用できるんではないかと思います。

おそらくこの考え方の最も根底にあるのは柔軟で在り続けることです。

常に変化し続ける世界を想定し、将来を見据えたアプローチをすることが UNIX の考え方だとも書かれています。

リーンスタートアップやアジャイル開発の考え方とも繋がる感じがして面白いです。 全ては変化の激しい環境で生き残っていくためにどうするか、という共通点があるかなと思います。

個人的に面白かった話は「ソートアルゴリズムすら満足に書けない成功したプログラマ」の話でした。 これに関して、アインシュタインが言ったとされる『複利』に関する話が取り上げられてるのも印象的でした。

読んでみて、色んな人が若者課題図書としてあげる理由がわかるなーと感じました。 本編が140ページちょっとな薄めの本なので、一度読んでおくと良いと思います！

変化への適応能力の重要性を再認識させてくれる良書でした！

新規サービスを6ヶ月開発してみての感想、主に品質、技術的負債、開発スピードについて

スピード重視の方々が「今はテストは不要」とか「今はリファクタリングせずに負債を抱えるべき」とか、 そういったことを主張している場面によく遭遇してきたのですが、開発初期段階に対する経験不足が原因で、 それに対する自分の意見を自信を持って主張するということがこれまではできませんでした。

しかし、今年に入ってから6ヶ月間、主に1人（+デザイナーさん1人）で新規サービスの開発を行ってきました。

その結果、開発初期段階における品質、技術的負債、開発スピードのバランスについて、 色々と自分の中に考えができてきたので、それを書きたいと思います。

前提

ちょっとした前提ですが、自分が思う良いソフトウェアというのは「要求仕様通りに動作して、なおかつ変更しやすいソフトウェア」といったものです。

そのため、基本的には品質が悪い場合、開発スピードは落ちると思います。

たまに「品質を捨ててスピードを重視する」と聞きますが、これはその場でその機能を実装する瞬間だけの超短期的な話であり、 今後そこに何か変更していくという段階になった時に、確実にスピードを奪います。

それなのになぜこの話が話題になるかと言いますと 「新規事業では生き残ることが大事であり、今後そこに対して変更を加えるかどうかが不確かである」 というのが原因だと思います。

結論

変更はすぐにどんなものに対してもやってきます。

そこで、やはり初期段階から常に変更を見据えて進めるべきです。 ただし、力の入れどころ、抜きどころは確実に存在していると思います。

話題になることが多いリファクタリングとテスト、それと個人的に重要だと思ったデータベースに関して、それぞれやるべきだと思ったことを紹介します。

• 初期段階でデータベース設計を徹底的に行う
• リファクタリングは常に作業の一環として行い設計とコードを綺麗に保つ
• テストは事業継続上絶対に落とせない箇所だけは最低書く

それぞれ、なぜそう思ったかを書いていきますが、まずはサービスの状況を背景として説明しておきます。

背景（サービスの状況）

• エンジニアは主に1人（7月上旬時点）
• 開発開始は2016年1月中旬
• リリースは2016年2月末
• 2016年の業績次第では撤退も十分ありえる
  • 撤退してしまえば当然全ては水の泡

では、先ほどの結論を順番に説明していきます。

初期段階でデータベース設計を徹底的に行う

追加や変更に強いデータベースを初期段階で設計しておくべきだと思いました*1。 Web サービス系の会社ではドキュメントが軽視されがちですが、ERD は絶対あったほうが良いです。

ERD があるのとないのでは、機能の追加/変更時の設計コストがまるで違います。 ERD の保守コストよりもリターンのほうが確実に大きいと感じました。 ちなみに ERD は概念設計のみを保持しています。論理/物理設計は Rails のマイグレーションファイルと内容が重複し、かつ簡単にリバースエンジニアリングできるため管理していません。

主な理由は、

• データベースは経営資産であり、ERD はビジネスの写像である
• データベースはアプリケーションの根幹であり、ここが破綻していると全てが破綻すると言っても過言ではない
  • 逆にデータベース設計がしっかりしていると、かなりコーディングがしやすく開発スピードがあがる
• データベースは基本的にリファクタリングが難しく、スタート段階で設計がコケていると立ち直しが非常に難しい
• 新規事業では要件や機能の追加、変更が非常に多く、データベース設計が頻繁に変更される

です。

コーディング速度、変更時の対応コストを考えると、最初に時間をとってデータベース設計をみっちりすべきだと思います。

また、アプリケーションコードでは「要るか要らないか迷ったら YAGNI に従いとりあえず作らない」が大抵の場合正解になりますが、 データベースの場合は「迷ったらとりあえず作る（詳細にしておく）」というのが良いと思います。

というのも、データを統合するのは比較的簡単ですが、分割するのは難しいからです。

リファクタリングは常に作業の一環として行い設計とコードを綺麗に保つ

リファクタリングというのはそもそも、日々の作業の一環として行うべきものというのは問題ないかと思います。

アプリケーションの変更は常に発生し、その変更に対応していくためには適宜その時々で最適な設計に変えていく必要があるからです。

ここでは「完璧」ではなく「最適」というのが重要です。 完璧にするのはそもそも不可能だと思いますし、目指すことそのものにコストが掛かり過ぎます。

そのため、その時点での「最適」は何か、つまり現時点ではどの程度の品質を目指し、どんな負債を受け入れ、将来的にはどう対応していくかということを常に見極めていく必要もあります。

やり方としては、基本的には何かの作業に合わせて「周りのお掃除」的な感じでリファクタリングをするのが良いと思っています。 「リファクタリング中に機能追加をするな、逆もまた然り」といいますが、それはプログラミング中の話なので、 タスクレベルで考えると「機能追加前に設計をブラッシュアップし、そこに機能追加していく」という流れは全然問題ないと思います。

それで、なぜこの当然の話を持ち出しているかと言いますと、 「そもそもリファクタリングを日々の作業としてやるという考えがない人」や 「その機能は今後変更されないと言って汚いままひたすら追記を繰り返す人」が リファクタリングは必要ないと主張してくることがあるからです。

リファクタリングを何のために何故どのタイミングでやるかに対しては、以下の本を読んでください状態*2なので今回の範囲外とします。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

リファクタリング:Rubyエディション

ここで言いたいのは「リファクタリングは新規サービスでも日々の作業としてやるべき」ということです。

その根拠ですが、半年間開発してみて、リリース後に変更しなかった機能が一切存在しないというのが最も大きいです。

データベースの項でも述べましたが、新規事業では要件や機能の追加、変更が本当に多いです。 ここで設計の見直しやリファクタリングをせず、とりあえずのコードを追記し続けると即破綻します。

破綻とまでは行かなくとも、すぐに書いた本人もなにしてるかわからないコードが量産されます。

たった数ヶ月の開発でそんな複雑にならないでしょと思う人もいるようですが、数時間あれば動く暗号は書けます。

テストは事業継続上絶対に落とせない箇所だけは最低書く

余裕があれば当然可能なかぎり書くべきですが、事業継続上絶対に落とせない箇所を最低カバーしてれば問題ないかなと思いました。

流石に最低レベルのカバー率だと色々困ることも多いので、現段階ではユニットレベルのテストは全て書いています。 ただ、E2E テストは一部の機能でしか書いていません。

理由としては、

• 複雑な機能が少なく、短時間の手動テストで大部分がカバーできる
• 変更が非常に多く、特に E2E テストの変更が多発する
• 多少サービスの一部機能が落ちたところで大きな問題が起きるフェーズじゃない

と言ったところです。

もちらん、あるに越したことはないですが、ホントに大事なとこ以外はなくても何とかなります。

ただ、動作確認自体に手間がかかるようになってきた場合は、今後のことを考える即テストを書くべきだと思います。 そういった機能については、積極的にテストを拡充していくようにしています。

また、その時点でうまく設計できなかった箇所や、可読性が低くなってしまった部分にも、 未来の自分を助けるためにテストを書いておいたほうが良いかもしれません。

まとめ

• 初期段階でデータベース設計を徹底的に行う
  • やや手間も時間もかかるが、短期的にも長期的にも得られるリターンがかなり大きい
• リファクタリングは常に作業の一環として行い設計とコードを綺麗に保つ
  • 変更は全機能で発生する可能性があり、難解な設計や難読コードは早ければその日のうちに自分の時間を奪いに来る
• テストは事業継続上絶対に落とせない箇所だけは最低書く
  • 手動テストを繰り返す時間的コストや、機能の重要度と相談し、リターンの方が大きい物は書く

スピードを維持し続けるのに大切なのは「設計」と「継続的改善」だと感じました。

最低限のテストで大量の変更を乗り切るためにも、拡張しやすい設計と読みやすいコードを維持し続ける必要があると思います。

補足

テストの伴わないリファクタリングはコード破壊やエンバグ作業とも言われますが、手動テストでカバーしてたり、機能自体が仮に落ちても業務上の損失があまりないのであれば、やっちゃって良いんじゃないかなと思ってます。

特に、新規事業は「数ヶ月後にそのサービスがあるかないかわからない」といったステージですので、それを判断軸に色々大胆に行っていけば良いと思います。

感想

ソフトウェア開発において常に発生する唯一のものは「変更」というありがたいお言葉が結局のところ全て。

*1:ちなみにオススメはイミュータブルデータモデルです

*2:私は Ruby エディションしか読んでいません

「映画英語のリスニングシリーズ」がメッチャおすすめ！

本日「映画英語のリスニング 恋するブルックリン」との1周目の戦いを終えました。

CD付き ボトムアップ式映画英語のリスニング 恋するブルックリン (CD BOOK)

全16章で構成されてるのですが、自分にはややチャレンジングなレベルなので毎回1章進めるのに1-2時間かかりました。 まぁ、やってる途中に集中力が欠けて、合間合間に休憩を入れていたのも時間がかかった原因のひとつですが……。

閑話休題。

映画英語のリスニングシリーズは、以下の記事で軽くだけ触れてますが、非常にオススメです。

necojackarc.hatenablog.com

映画やドラマなどの自然な英語を聞き取ることを目的としてるので、 学習用教材の中ではかなり自然なスピード、それでいて丁寧な英語なんじゃないかと思います。

1番良いなと思う点は、今すぐに使えそうなフレーズが詰まってる点です。 流石自然な英語に重点を置いた教材だけあって、自然なフレーズがたくさん出てきます。

特にこのシリーズ3作目の「恋するブルックリン」は題材が恋愛なので、よりフレーズの身近度が高い気がします。 自分が恋愛物の登場人物のような立場に置かれることは正直全く想像できませんが、使える場面は思いつきやすいと思います！

また、このシリーズの特徴として、ストーリーが基本的に面白いという点も挙げられます。 次の話を聞きたいなと思えるスピード感があるストーリーですので、難易度が高くてもやり切ることができました。

せっかくなので、以前取り組んだ別シリーズについても簡単にご紹介します。

New York Detective Story

シリーズ1作目はニューヨーク市警察を題材にした刑事物です。

ボトムアップ式 映画英語のリスニング 新装版―NewYork Detective Story (CD BOOK)

Detective という言葉は日本だと「探偵」として有名ですが、ここでは「刑事」の意味です。

個人的には一番優しかったかな？という印象です。 それでも十分手強かったですが、ストーリーにスピード感があったため、サクサク楽しんで進めることができました。

この本の一番最高な点は北米版平野綾*1こと Wendee Lee がメインキャラクターを演じているところですかね！！

Wendee Lee は涼宮ハルヒ（涼宮ハルヒの憂鬱）やこなた（らき☆すた）などを担当している声優だそうです。

なんかメッチャ良い声してるやんけ！と思って調べてみたら、この動画が出てきてびっくりしました！

アニメ好きな方にオススメです。笑

New York Pediatrician Story

こちらはシリーズ2作目で医療物で、とある小児科医が主人公の話です。

CD付 海外ドラマが聴きとれる! ストーリーで学ぶ英語リスニング (CD BOOK)

1作目と比べると、難易度が高く感じました。

• 速く話す人も居ればゆっくり話す人も居る
• オーストラリア出身の医師がオーストラリア訛りで攻めてくる
• 教材ではめったに出会うことのない子供も登場する

といった、色々な英語が聞ける点が特徴です。

基本はアメリカ英語ですが、1人オーストラリアからやってきた医師が居り、 その人がオーストラリア訛りでしかも結構な速度で話します。ボコボコにされました。

こちらもストーリーにスピード感があり、難しいながらも楽しく進めることができました。

これから

映画英語のリスニングシリーズですが、なんと4作目が今年の5月にリリースされていました！

CD付 ボトムアップ式 映画英語のリスニング ファティマに何が起こったか (CD BOOK)

もう余裕で購入済みですので、次はこれに取り組んでみたいと思います！

軽く見てみたところ、どうやら次は家族物のようです。 これまた身近なフレーズ満載な雰囲気で楽しみです。 正直ボコボコにされる予感しかしませんが！

2016/6/24 追記

4作目の「ファティマに何が起こったか」を終えました。

内容的には確かにファミリードラマだなという感じでした。 家出、ドラッグ、恋愛、イジメ、アルコール中毒、なんか盛り沢山です。

リスニングの難易度は1作目に近いかなと思います。 各シーンの長さの平均はこれまでで一番長いように感じました。

最後まで終えると、1年後のアフターストーリーが手に入るようになっていました！

粋な計らい！

追記終わり。

それと、しばらくは「恋するブルックリン」を通勤中にひたすら聴きこんで復習します。

あ、そういえば TOEIC の受験票も届いてましたね……ﾋｨｰ(((ﾟДﾟ)))ｶﾞﾀｶﾞﾀ

し、新形式……不安だ……。

*1:プロアニメ見る人な後輩がそう呼んでました

「同時通訳者が教える ビジネスパーソンの英単語帳 エッセンシャル」を読んだ

「同時通訳者が教える ビジネスパーソンの英単語帳 エッセンシャル」を読みました。

同時通訳者が教える ビジネスパーソンの英単語帳 エッセンシャル (ディスカヴァー携書)

本屋で立ち読みして、良さそうだな〜と思って買いました。

内容は凄いシンプルで「こうじゃなくて、こういったほうが効果的ですよ」という単語やフレーズの紹介です。 確かにこういったほうが良さそうだな〜とか、あ、これ言う場面ありそう、というのが多く良かったです。

単語数がそんなに多くなく、本当にエッセンシャルという感じでした。 表現が単調になってきたなーとか思った時に読むと良いかなと思いました。

章の間にあるコラムもなかなか面白かったです。

久しぶりに適度なサイズ感の本で読むのが楽でした！

「英語のしくみがわかる基本動詞24」という本が素敵だった

「英語のしくみがわかる基本動詞24」という本を読みました。

英語のしくみがわかる基本動詞24〈新装版〉

"DISCOVER the SPIRIT of the ENGLISH LANGUAGE" というイカした副題がついています。

英語の基本動詞について、それぞれの「中核的意味」を軸にしっかり解説している本です。

基本動詞のコアイメージを身体に染み込ませる必要があるなと常々感じていたんですが、 先週ふらっと本屋に寄ったらこのドンピシャな感じがする本が平積みしてあり、すぐに買ってしまいました。

読んでみた結果「そうそう！こういう基本動詞についてみっちり書かれてる本が読みたかったんだ！」ってなりました。

基本動詞って意味も広ければ使いかたも多く、身体に馴染ませるのが大変な気がします。 しかも、それが馴染んでないと、うまく意図がつかめない表現というのも沢山あると思います。

また、英語ネイティブと日本語話者の言葉の選び方や表現の発想の違いというのも、 こういった基本語彙へのイメージの違いから来ているんじゃないかと思っていたので、 ほんとにこういった「英語の中心部分をみっちり解説する本」というのを読みたいなと思っていました。

こういった基本知識や「こころ」みたいなモノを体系的に仕入れておくと、今後の吸収力に違いがでると思うので、読んでみてとても良かったです。 今後も定期的に見返すだろうな〜という感じがします。

読むのメッチャ時間かかりましたがとても面白かったです！

英語でライトニングトークしてきた！

人生初 LT を英語でキメてきました！

Tech Talk Tokyo #2 というイベントに参加しました。 ざっくり言うと、エンジニア同士の国際交流が目的のイベントなようです。基本会場では英語で交流する感じでした。

Lightning talk

超ざっくり新サービスの紹介して、ざっくりイミュータブルデータモデルについてとか、Rails に層を追加するの良いよとかって話をしました。

LT については、5分という制約を考えると「メッチャ狭くやや深く」くらいを目指したほうが良かったなーと思いました。 突貫でスライドを作ったんですが「やや広くメッチャ浅く」になってしまい、正直微妙な感じでした。

まぁでも、英語でプレゼンテーションをするという貴重な経験が得られて良かったです。

次はもっと色々と改善して臨みたいなーと思います。

Networking

交流タイムもなかなか楽しかったです。もっと色んな人と話せばよかった……！ が、英語だろうが日本語だろうが、知らん人にどうやって話しかけるのかようわからん！

ただ、日本語だときっかけさえつかめばその後なんやかんや話が続くんですが、 今の英語力だと「雑談で盛り上がる」というのが至難の業……！

ホント英語はもっとどうにかしないと生きてけないなと感じます。

まとめ

英語で人前で話し、英語で知らない人と交流するという、かなり貴重な経験ができました。 なんか、一歩前進した感じがします。メッチャ楽しかったです。

あと、こういう「とりあえず突撃してみる」というのは、結構大事だなと再認識しました。 自分が納得行くレベルまでは実践を避ける、というのをやりがちなので、もっと色々なものに突撃していきたいと思います。 全力でガラスぶち破っていこ。

ちなみに、Hacker News のイベントがなかなかおもしろい、らしいです。

英語もっと頑張ろ！