「aとtheの底力」が英文の見え方を変えてくれる良書だった

「aとtheの底力 -- 冠詞で見えるネイティブスピーカーの世界」を読みました。

aとtheの底力 -- 冠詞で見えるネイティブスピーカーの世界

あまりに面白くてほぼ1日で読みきってしまいました*1。

どう頑張っても劣化した説明しか書ける気がしないので、本の内容に関しては言及しませんが、英文の見え方が変わったなぁという感じがします。

1年前に英語の勉強を開始した際に読んだ一億人の英文法 ――すべての日本人に贈る「話すため」の英文法（東進ブックス）も「コイツは革命だー！」という気持ちになったのですが、 この本もまた新しいイメージを身体の中に作ってくれる良書でした。

とても面白いし読みやすいので、冠詞って謎だなぁと思っている人は一度読んでみて欲しいです！

久しぶりにあまり苦しまずに読みきれましたっ！

*1:寝落ちと戦うために途中から立って読んでました。本読んでると凄い確率で寝落ちします……。

「今までにない前置詞講義」が確かに今までにない感じだった

「今までにない前置詞講義」を読みました。

今までにない前置詞講義

色々評価が高い前置詞本がある中でこれを選んだ理由ですが、 前置詞どうしの因果関係を点→線→円と立体的に関連付けて解説している点に惹かれたためです。

読んでみた結果、確かに今までにない感じだなと思いました。 ただ、全体的に独自理論な感じがするので、人を選ぶかもしれません。

個人的には、これまでにない考え方で前置詞に触れることができてかなり有意義でした。

自分の中の前置詞のイメージが一段厚くなった感じがします。

語学全般そうだと思いますが、特に前置詞に関しては身体に叩き込むしかないと思うので、 こんな感じでいろんな方向からインプットしていきたいです。

英語沼から抜け出せる日を夢見て……。

「発信型英語 類語使い分けマップ」がとても良かった

「発信型英語 類語使い分けマップ」を読みました。

発信型英語 類語使い分けマップ

タイトルどおりの内容で、とても良かったです。

アウトプットする際に良く使用する語彙がかなり網羅的に載っており、各グループごとの類語の説明もとても丁寧に書いてありました。

「これってそういう意味だったんだ！」となることも多く、基本語彙でも表面的な理解しかしてなかったんだなぁと思い知らされました。

また、知らない語彙もたくさん載っていました。それについては当然一度読んだだけでは覚えられないので、 「この辺りの類語ってどうなってたっけ？」と普段から意識し、ちょこちょこ読み返していきたいと思います。

まさに発信力をあげるための良書でした。

スマホアプリで歌声をスペクトル分析してみたら面白かった

先日カラオケ後、色々あってアナライザーで声を分析して遊んでました。

ミドルボイスとファルセット*1、つまりいわゆる「地声っぽい裏声（実声）」と「裏声らしい裏声（仮声）」で明らかに違いが出て面白かったです。

面白かったのでキャプチャして検証してみました。

家で恐る恐る声を出した際のキャプチャなので、普段の歌声通りではないと思いますが、それに近くなるように頑張ってみました。

使ったアプリはこちら。

play.google.com

まずは「地声っぽい裏声」です。

そしてこちらが「裏声らしい裏声」です。

それぞれ hiA*2 を狙って声を出しています。

一番左側の山が基音である A 440Hz 付近で、それより右の山は順に、2倍音、3倍音、という感じだと思います。 2倍音はオクターブ上、3倍音は1オクターヴと完全5度、4倍音は2オクターブ、5倍音は2オクターヴと長3度上の音です。

そして明らかに地声っぽい声の方が倍音の出方が強いです。というか、一部倍音の方がでかく出ています。 特に3倍音、つまり1オクターブと完全5度上の E 音がかなり大きく出ています。

この辺が地声っぽく聞こえる理由な気がします。 というわけで、今度はオクターブ下の A を「普通の地声」で出してみました。

こちらもやはり3倍音の出が大きいです。この3倍音が強く出るのが「自分の地声の特徴」なのかなーという感じがします。

普段から声がよく通る*3と言われるのですが、それもこの倍音の出方が関係ありそうな気がします。 声の特徴が図として表示されるので色々と面白いですね！もっと細かく詳しく、色々な人と比較しながら見ると更に面白そうです！

科学的アプローチによる超効果的なボイストレーニングレッスンを受けたい……！

*1:だとそれぞれ自分では思っている声

*2:A4: 440Hz

*3:というか、うるさい

「楽々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 エディションしか読んでいません