It's okay to be weird

レールの無い道を行くプログラマーのブログ

『Clean Code』を読んだ

達人に学ぶDB設計 徹底指南書に続き、言語やフレームワークに依存しない本として何か読みたいと思い、評判の良さを以前から聞いていたClean Codeを読みました。なかなか読み応えのある良い本でした。

日本ではリーダブルコードがよく新人にお勧めする本として挙がりますが、redditの開発系subredditなどを読んでいると、海外ではリーダブルコードの名前が挙がることは少なく、代わりにこのClean Codeの名前をよく目にするような気がします。内容としては読みやすい = 綺麗なコードの書き方ということで似ているのですが、Clean Codeは日本では訳書が絶版になってしまっていることが影響しているのか、あまり広く読まれていないようです。

構成としては、1〜13章が本編、14〜16章がバッドコードをリファクタリングするケーススタディ、17章がコードの臭い・ヒューリスティック集となっています。

どういう本か

序文で、近代建築の巨匠であるミース・ファン・デル・ローエの「神は細部に宿る」という言葉を引用し、ソフトウェア開発では細部にこだわることが重要と言っています。また、この本は読んだだけで"feel good"にしてくれる本ではなく、Clean Codeを書くのは”hard work”であると述べています。例となるコードがたくさん含まれており、頭に入ってきやすいように作られています。

以下、特に印象に残ったことを章ごとに箇条書きで書いていきます。Scrapboxに読書メモを残しているので、さらに読みたい方がいたらそちらを読んでいただければと思います。

Chapter 1: Clean Code

  • 最近は人工知能の躍進が著しいので、やがてプログラマーの職も奪われるのではないかと危惧している人もいるのではないかと思いますが、この本では、「人間でさえ顧客の曖昧な仕様をシステムに落とせないのだから、機械がコードを勝手に作ってくれるようになるなんていうのは幻想。もしそうなったとしたら、今度は仕様書がそれだけ形式的になるというだけ」と述べており、なるほどと思いました。
  • マネージャーにバッドコードを放っておかないよう伝えるのはプログラマーの務め。バッドコードを放っておくのは、医者が手術をする際に時間がかかるからといって手洗いをしないのと同じ。
  • 「この本は柔術の流派の1つを教えるようなもので、絶対的に”right”であるとは考えないで欲しい」と言っていますが、確かに著者の得意とするJavaアジャイルの文化が色濃く反映されているので、全てを鵜呑みにする必要はないと思いました。

Chapter 3: Functions

  • 関数の最初のルールは小さくあること、2番目のルールはさらに小さくあること。
  • 関数の長さは20行を超えるべきではない (異論が挟めそう)。
  • Kent Beckの視覚効果を画面に出すJava/Swingプログラムを見せてもらったら全ての関数が2〜4行に納まっていた。
  • 文章を推敲するように、まずは汚く書いて徐々に綺麗にしていく。その際にテストコードをまず書いておき、改良したあともテストが通るようにすると良い。

Chapter 4: Comments

  • コードの表現を補わなければいけなかったという意味でコメントは常に"failure"である。
  • コメントはメンテナンスされずにいると正確性を欠くようになっていまう。コードだけにしか真実は表されていない。

Chapter 5: Formatting

  • 新聞には見出しがあり、最初の段落であらすじが書かれ、次に詳細が書かれる。ソースファイルも同じように名前は簡潔かつ明瞭で、上部に高レベルな概念とアルゴリズム、下部に低レベルな関数と詳細が書かれているべき。
  • かけ算、割り算の演算子は1*2のようにひっつけて書き、足し算、引き算の演算子は3 + 4のように離して書くと優先度が分かりやすい。

Chapter 6: Objects and Data Structures

  • オブジェクトはデータを抽象化の背後に隠蔽し、公開された関数を通してデータを操作する。データ構造はデータを公開し、意味のある関数を持たない。
  • 手続き型コード (データ構造を使用するコード) は既存のデータ構造を変更することなく関数を追加することが容易。オブジェクト指向コードは既存の関数を変更することなく新しいクラスを追加することが容易。
  • 手続き型コードは全ての関数の変更が必要なため、新しいデータ構造を追加することが困難。オブジェクト指向コードは全てのクラスの変更が必要なため、新しい関数を追加することが困難。
  • 全てのものがオブジェクトというのは神話でしかない。時にはシンプルなデータ構造と手続きが必要なときもある。

Chapter 9: Unit Tests

  • 3つのことがテストを綺麗にする。それは可読性、可読性、可読性である。テストコードではプロダクションコードより可読性が重要とも言える。

Chapter 10: Classes

  • クラスのサイズを測定する際、行数ではなく責任 (responsibilities) によって測定する。
  • 70個のpublicメソッドを持つクラスを5個に減らしたからといって、責任が減るというわけではない。
  • SuperDashboardのように、Super、Processor、Managerといった名前のつくクラスや、"if"、"and"、"or"、"but"のような言葉で繋げなければ説明できないクラスは責任の多さを示唆している。

Chapter 15: JUnit Internals

感想

「そうなのか!」という驚きというよりは、「ふんふん、そうだよね」という感じが多かったです。ある程度、開発経験を積んだからかもしれません。

ただ、「どこまで当たり前のことを当たり前にやれるか」ということが開発をする上で大事なことのように思います。一度サボりだすと雪崩を打って、割れ窓理論で言われるように全てが崩壊してしまうものだと思います。そこのところを注意しつつ、最初から完璧に綺麗なコードを書こうとせず、初めはダーッと書いて、まとまったところですぐにリファクタリング、の繰り返しをしていくのがいいのではないかとこの本を読んで思いました。

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

my_age = pow(2, 5)

本日2017/07/03をもって、年齢が2進法で6桁に桁上りしました。

class Tommy:
    def __init__(self, age):
        self.age = age


def birth_day_2017():
    tommy = Tommy(0b11111)
    tommy.age += 1
    print(bin(tommy.age))  # 0b100000
    print(tommy.age)       # 32


def main():
    alive = True

    birth_day_2017()

    while alive:
        try:
            move_forward()
        except:
            dont_give_up()


main()

これからも自分なりに人生を楽しんでいきたいと思っています。
よろしくお願いいたします。

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

これから自分の関わる業務がどういうものになるか見通せない状態にあることもあり、特化した技術や流行りを追いかけるよりは、5年10年通用してくれそうな基礎的な技術を学ぼうと思い、データベースの勉強を進めることにしました。

そこで選んだのが、訳書を含めてデータベースについて多くの著書を執筆されているミックさんの本です。

まずは復習がてら『SQL 第2版 ゼロからはじめるデータベース操作』から始めて、『達人に学ぶ SQL徹底指南書』に進みました。そして、この記事で言及する『達人に学ぶ DB設計徹底指南書』を読み終えました。

どれも大変興味深く、理論と実践のバランスの取れた素晴らしい本でしたが、その中でも本書は特に面白かったのでブログ記事にしました。

本書のテーマ

「はじめに」に書かれていますが、リレーショナルデータベースにおける設計を、(1) 正規化やER図を使ったモデル設計である「論理設計」、(2) サーバーやストレージと行った物理的なハードウェアレベルの設計である「物理設計」、(3) 特定のデータベース製品に対する設計である「実装設計」の3つに分類した場合、本書は実装設計を除いた、論理設計と物理設計の2つについてカバーしています。

論理設計と物理設計は「あちらを立てればこちらが立たず」のトレードオフの関係にあるため、それぞれについての望ましい設計というものを学んだうえで、そのトレードオフを学ぶのが本書の目的と著者は言っています。トレードオフという言葉は本書の中で頻繁に登場する重要ワードになっています。

章の構成

章ごとの概要をまとめると、第1章はシステムとデータベースについて、第2章は論理設計と物理設計、第3章は正規化、第4章はER図、第5章は論理設計とパフォーマンス、第6章はインデックス・統計情報とパフォーマンス、第7章は論理設計のバッドノウハウ、第8章は論理設計のグレーノウハウ、第9章はSQL木構造を扱う方法が書かれています。

部に分けるならば、1、2章が概要編、3〜5章が論理設計編、6章が物理設計編、7〜9章が応用編といったところでしょうか。

論理設計と物理設計、どちらを優先するか?

本書のテーマである論理設計と物理設計のトレードオフですが、ではどちらを優先すべきかという点において、「おわりに」の中で著者は「特別な事情のない限り、論理設計は物理設計に優先するべき」と述べています。 第5章の中でも、非正規化によりパフォーマンスの向上が見込めるケースはあるものの、クリス・デイトの「非正規化はあくまでも最後の手段である」という言葉を引用し、基本的には整合性を優先するべきだと示しています。
その理由の1つに「パフォーマンスをはじめとする物理層に起因する問題は、いずれハードウェアによる解決が可能になっていくことが予想される」ことを挙げています。論理設計の改修には大きなコストがかかるのに対し、物理設計は物量による対応が可能なのです。

ただし、物理設計について無知であっていいかというとそうではないので、論理設計を優先することでどういう影響があるのか知った上で設計できるようになることが重要だと強調しています。著者があえて「おわりに」の中で結論を述べているのは、物理設計を疎かにして欲しくないという気持ちの表れでしょう。

感想

銀の弾丸などない」という言葉があるように、「これを選んでおけば何も考えなくていい」といった簡単で最善な解決策がない場面がソフトウェア開発においてはほとんどで、常に難しい選択の連続です。本書はデータベースの世界においてどういった選択をすればいいかという指標を示してくれます。リレーショナルデータベースに関わる開発者 (そうでない人なんてほとんどいない?) なら読んでおいて損のない1冊だと思います。

ちなみに出版社の紹介文として「『達人に学ぶ SQL徹底指南書』の続編」と書いてありますが、『達人に学ぶ SQL徹底指南書』を読んでいなければ理解できないような箇所は少ないですし、内容的に得るものがより多いうえ、理解もしやすいため、こちらの方を優先して読んだほうが有益なのではないかと僕は感じました。

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

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

一流エンジニアなんて目指さなくていいのかも

こんな記事を読んだ。

林修「仕事をするのに好きかどうかは関係ない、重要なのは勝てる土俵なのかどうか」

この記事の中で林さんは「一流しか存在価値がない」と思っていると語っている。もちろん、これは林さんの信条であって、皆に強制しているわけではないという前提なのだけど、一流なんて目指さなくていいんじゃないかと最近思うようになった。

クラスで1番だった人とインターネット

ずっと思ってきたことなのだけど、インターネットというものが生まれたせいで、「クラスで1番」だった人が輝けない世界になったような気がする。せいぜい40人程度の集団では輝けていた人が、インターネットでは一気に70億人の世界に晒されるわけで。

特にソフトウェア開発の世界では、GitHubやらQiitaやらで、承認される人とされない人にはスター数やいいね数などで数値として違いが大きく可視化されてしまう。そして、インターネットを見ていると、仕事をバリバリこなしつつ、サイドプロジェクトを何個も持っていて、アウトプット量が半端ないといったようなスーパーエンジニアばかりが目についてしまう。

こうなると「クラスで1番」だった人は自信を失ってしまう。「結局自分なんて井の中の蛙」なんだなと。

これはインターネットに限った話じゃなくて、NHKのスーパープレゼンでスプツニ子!さんが、MITに入る学生はそれぞれの高校では1番だったのに、天才達に囲まれて自信を失ってしまうことも多いということを話していた。

しかし、そもそも考えてみれば「クラスで1番」っていうだけで誇っていい話だし、40人いれば他の39人は1番じゃないわけだ。その人達には存在価値はないのか、というとそんなことは全くない。むしろ他の39人がいることで世の中は成り立っている。

ソフトウェア開発で一発逆転を目指した

僕の場合、中学では学力でいい位置にいたものの、高校を中退してしまい大学進学を経験していないので、潜在的な学力での自分の位置づけが分かっていない。大学を受験していたとしたらどこまでいけたかなんかを考えることも時々ある。位置づけが分かっていない分、どこまでやれるかの限界を試してみたいというような気持ちがあった。

そんなものだから人生一発逆転してやる、というような気持ちで今まで技術の勉強を頑張っていたところがあった。そして、ソフトウェア開発の世界は努力して技術を磨けば逆転が可能だと思わせてくれた。

そうやって頑張っていたものの、仕事では思った内容の業務をやらせてもらえず、「毎日の8時間が勿体無い」と思いながら、焦る気持ちがどんどん積もっていった。映画やドラマ、アニメ、本を楽しむ時間も削って勉強にあてようとした。僕は年齢が30を超えていて、キャリアを考えるとゆっくりはしていられない。そんな焦りが積もった結果、ついには心が折れてしまった。

結局こうやって自分を追い込むことで、自分を不幸にしてしまっていたと気づいた。

もちろん強靭なメンタルと熱意と才能がある人は一流になることができるのだろうし、それを目指すべきなんだろう。

だけど僕は自分が思っているより脆い人間なんだと今更ながら気づいた。

これから

これからは技術は業務をこなせる範囲で程々に頑張りつつ、趣味のサイクリングやギターをもっと楽しんでいきたいと思っている。

今年の1文字は「緩」と決めている。緩やかな上昇はしつつも、無理はしない。自分をいじめず、周りの人と笑って楽しめる、そんな1年にしたいと思っている。

2016年振り返り

このブログを読んでくださっている皆さん、今年もお疲れ様でした。皆さんにとってどんな年だったでしょうか。

参加しているCOUNTDOWN JAPAN 16/17の会場から今年を振り返ってみようと思います。何気にiOSアプリからブログ書くのは初めてだったり。

技術面の振り返り

技術的には個人的に3つほどやってました。振り返ってみると、どれも中途半端に終わり、迷走感があります。

Python

仕事で触れたことをきっかけにCheckiOの問題を解いたり、Flask、Djangoチュートリアルをやってみたりしました。

Kotlin

バージョン1.0が出たことをきっかけに公式チュートリアルをやったり、Android本をやったりしてみました。

iOS / Swift

アプリを作り上げることを目的に、Stanfordの講義なんかを見つつメインにやっていたものの、色々あって途中で断念しました。

その他振り返り

技術以外だとどんなことをやってたか振り返ってみます。

数学

プログラマーとして社会人になったけど高校数学を1から独学しているという、かなり久々に書いた記事が、ブログを書き始めて以来初めてバズりました。機械学習なんかで必要になることもあり、数学ブームと、学習し直したい人の需要の高まりを感じました。

進捗的には1年をかけて数I+Aの範囲を終えることができました

ロードバイク

ロードバイクを購入しました。これが一番大きな変化かも。ただ、あんまり乗れてないので2017年はもっと乗っていきたいです。他県への泊まり込みでの遠出なんかもしてみたいところです。

ギター

去年から継続してゆるくやってます。これももっと上手くなって他の人と合わせたりとかしてみたいです。

まとめ

振り返ってみると、何かこれといって成し遂げたものはないですが、それなりに楽しく過ごせたので、まあいいかなと思ってます。

来年も何か大きな目標をドンと立てるというよりは、数学やらギターやら技術やらを毎日地道にコツコツやってスキル向上していけたらと思っています。
働きながら何かを身につけようとすれば、時間が足りないぶん、やはり小さく積み重ねていくしかないと思っています。

ではでは皆さんよいお年を!

海外のテクノロジー・開発系の情報収集のために自分が行っている方法

テクノロジー・開発系の分野に携わっていると、日々の情報収集は欠かせません。国内の情報だけでも十分ではありますが、海外の情報に触れることも大切だと思います。

海外の情報であっても、ニュース系の記事は大抵すぐに翻訳されますが、コラムやエッセイなどは数ヶ月遅れでやっと翻訳されて、日本で話題になるのは結構あとだったりすることも多いです。

日々最新の情報を収集するため、僕が行っている方法を紹介したいと思います。僕の興味のあるiOS開発やSwiftでの例もとりながら紹介していきたいと思います。

Twitter

まずは基本のTwitter。興味のない記事が並びまくるメディア系のアカウントではなく、個人のアカウントを中心にフォローしています。日本人に多い、1日にツイートが途切れなく続くような人は少ないため、フォローを増やしてもそんなにノイズが無いのでいい感じです。

フォローしているTwitterアカウントの例です:

ユーザー名 名前 説明
@SwiftLang Swift Language AppleのSwift公式アカウント
@clattner_llvm Chris Lattner Swift、LLVMの作者
@modocache Brian Gesiak Swift、LLVMのコミッターで、Quickテストフレームワークの作者
@NatashaTheRobot NatashaTheRobot This Week in Swiftというニュースレターの作者

reddit

次に、日本では海外の2chと紹介されることが多いredditです。

2chredditで対応させると、板→subreddit、スレッド→post、レス→commentとなります。カテゴリーごとに区切られたsubredditの中で、誰かがpostを作成し、その中でcommentにより議論するという流れです。self postという、リンクを伴わずpost作成者の質問などに対して議論する場合もありますが、基本は記事へのリンクを貼って、それに対してみんなで議論するというのが主流です。

2chと大きく異なる点は、commentがツリー型となっている点と、それぞれのpostやcommentに対してupvote (👍)、downvote (👎) が出来る点です。これにより多くの人の支持を集めたpostやcommentが上位に来るような仕組みになっています。誹謗中傷や的外れなcommentは勝手に沈んでいきます。

興味のあるsubredditを登録してチェックしていくのですが、僕なりのredditの歩き方としては以下のような感じです:

  • 賑わっている、または重要なsubredditは、毎日同じ時間に、上部のtopタブを押し、links fromを24 hoursにしてチェック。これでその1日に話題になったpostをチェックすることができる。
  • 毎日きっかり同じ時間に見れるとは限らないので、24時間から外れて話題になったpostの漏れを逃さないため、hotタブを押し、"1 day"をキーワードにブラウザで検索、引っかかったpostをチェックする。
  • 賑わっていない、またはそこまで重要でないsubredditは https://www. reddit. com/r/[subreddit名]/top/?sort=top&t=week*1をブックマークに追加して毎週チェック。それらのブックマークをまとめたフォルダを作って、一気に全部開けるようにしておくと良い。
  • Reddit Enhancement Suiteという拡張機能を入れて使いやすく見た目や機能をカスタマイズ。

登録しているsubredditの例です:

subreddit 説明
/r/programming プログラミング全般
/r/iOSProgramming iOSプログラミング
/r/swift Swift

Hacker News

次はHacker Newsです。ポール・グレアムY Combinatorによって運営されている、テクノロジー特化のredditみたいなところです。redditジョーク受けがいいですが、こちらはもうちょっと真面目なコメントが上位に来やすいという印象があります。

Hacker Newsはそのままでは素っ気がなく、記事の数も多く使いづらいので、僕はhnrssという、条件でフィルターしてRSSとして垂れ流してくれるサービスを経由して購読しています。具体的にはhttp://hnrss.org/newest?points=200というフィードで、200ポイント以上のポストだけ流れてくるようにしています。

あとはHacker NewsにもHacker News Enhancement Suiteという拡張機能redditと同じようにあるので、これも入れています。redditと違いコメントの折りたたみなどが素のサイトでは出来ないため、redditのものより重宝しています。

メールマガジン

メールマガジンもいくつか購読しています。Podcastと同じく、近年見直されている昔からあるツールではないでしょうか。

毎週決まった曜日に、その週のニュースをまとめてキャッチアップできるので、役に立っています。また、複数購読しておくと、重要な記事が何回も目に触れるという利点があります。

購読しているメールマガジンの例です:

まとめ

ここまで僕なりの海外の情報収集について紹介しました。

1次ソースを直接見るのではなく、コミュニティによってキュレートされた情報を収集している形になります。これでも十分だと思いますが、自分の専門分野については1次ソースに当たったほうがいいかと思われます。

皆さんもこういう情報収集しているよーというのがあったら是非ブコメなどで教えてください。

*1:スパム対策のためか、はてなブログredditドメインを含むURLを貼れないためこういう書き方になっています。実際に入力する際はスペースを省いて下さい。

高校数学独学の途中経過ー数学I+Aを終えて

タイトルの通り、『プログラマーとして社会人になったけど高校数学を1から独学している』という記事で紹介した長岡の教科書の数学I+Aを終えることが出来ました。

Studyplusのログによると、今年の1/4に手をつけ始めて、途中2月半ばから1.5ヶ月ほど休みを入れたものの、そこからはコツコツと継続して、10/2にようやく終えることができました。休みの期間を省くと約7.5ヶ月かかったことになります。標準的な高校生が1年をかけてこの範囲を学習することを考えると、それなりにいいペースなのではないかと思います。ただ、問題集などは全くやっていないので、問題を解いた量なんかは比べ物にはならないですが。

勉強法

長岡の教科書を教材にするにあたって僕が取った勉強法を書いていきます。

勉強のスタイルとしては、解説のあとの問とセクションごとの演習だけ解いていく形で進め、センター試験対策である章末問題は飛ばしました。また、間違えた問題を繰り返し解くといったこともしませんでした。
あくまで必要になった時に引っ張れるような知識として蓄えることが目的で、受験数学の問題解決能力をつけたいのではないからという理由です。問題解決はプログラミングの世界でやっていこうという方針です。数学が得意な知人の方に、受験数学と大学からの数学は別物であると教えていただいたこともあります。
そのため、『プログラマーとして社会人になったけど高校数学を1から独学している』を書いた時点では目標としていた数検の受験も止めることにしました。さくっと高校教科書を終わらせて、その先の大学数学に進もうという考えです。

早速役に立っている

高校数学を勉強していて早速嬉しいことがありました。
ソフトウェアの世界では枯れた技術であるデータベースの勉強をしようと、『達人に学ぶ SQL徹底指南書』を読み進めているのですが、そこに数学Iで学習した集合や、数学Aで学習した順列と組合せが出てきたのです。『1-2 自己結合の使い方』という章で、自己結合の背後には「順列」、「組合せ」、「集合」が隠れているというところです。
もし数学I+Aを勉強していなければ、これらのキーワードに首をひねっていたところでしょうが、勉強していたお陰ですっと頭に入ってきました。著者は、この本をただのSQLレシピ本として読むのではなく、集合指向的考えでSQLに臨むことができるようになって欲しいといったことを書かれていますが、集合とはなんたるかが分かっている分、そういった考えが出来やすくなっていました。
高校数学がプログラミングに効果を発揮した一例です。

数学の旅は続くよ、どこまでも

次は数学II+Bとなります。

これまでは中学数学のそのまま延長といった感じでしたが、これからは複素数微分積分、ベクトルといった、特に独学で学ぶにはなかなか手強そうな単元に入ってきます。
しかし、プログラミングで手強い問題を解決する快感を覚えてしまったからか、こういったキーワードを目次で見るだけでワクワクしてしまいます。数学が楽しくてしょうがないのです。

果てしなく続く数学の旅、新たな世界へ運んでくれると信じて、これからも続けていこうと思います。

【音声DVD-ROM付】長岡の教科書 数学I+A 全解説

【音声DVD-ROM付】長岡の教科書 数学I+A 全解説

【音声DVD-ROM付】長岡の教科書 数学II+B 全解説

【音声DVD-ROM付】長岡の教科書 数学II+B 全解説