グッドバイ2017、ハロー2018

毎日特に何をするでもなく寝てばかりいたら、あっというまに年末年始休みが終わろうとしています。まぁたまには生産性も何もないこんな休みもいいかなと思っています。

2017年

とりあえず2017年の振り返りが出来ていないのでそこからします。

会社

1年少し勤めた初めての会社を2月末に辞め、間にもう1つの会社を渡り、最終的に今の会社に10月終わりに落ち着きました。まだアルバイトの身ですが、ようやく活躍できそうな「場」を与えられた感じがするので、あとはそこで力を発揮できるよう努力していきたいと思っています。

勉強

勉強的にはこの辺をやってました。

• 長岡の教科書II+B (読了)
• 達人に学ぶ SQL徹底指南書 (読了)
• 達人に学ぶDB設計 徹底指南書 (読了)
• Clean Code (読了)
• プログラミングコンテスト攻略のためのアルゴリズムとデータ構造
• 世界で闘うプログラミング力を鍛える本
• Problem Solving With Algorithims and Data Structures Using Python
• Khan Academy - Algorithms
• freeCodeCamp
• The Grumpy Programmer's PHPUnit Cookbook (読了)
• テスト駆動開発

この中でも読了した数でいうとたった5冊なので、やっぱ足りてないですね。最低でも1ヶ月に1冊ぐらい読んでいきたいです。

ただ、就職前に数学やデータベース、アルゴリズムとデータ構造といった基礎的なところを勉強できたのは有意義だったと思います。

趣味

趣味でいうと、ライブによく行った年でした。数えてみたら合計13回も行っていたようです。引き続きライブはどんどん行きたいですね。ライブって、当日までは「その日まで頑張ろう」、終わった後は「次のライブまで頑張ろう」という気にさせてくれる本当にいいものです。

そして、新たな趣味としてコーヒーが加わりました。豆から挽いて毎朝飲む習慣ができました。朝が苦手な自分にはいい贅沢が出来ていい感じです。

2018年

勉強

まずは仕事で必要とされるスキルを最優先に身につけていきたいです。主にWeb開発全般とPHP周辺ですね。コードリーディング力が足りてないことを実感したのでそこも埋めていきたいです。あとはN予備校のプログラミングコースでWeb開発を体系的に学び直し、抜けを無くしていこうと思います。

趣味

ギターをやるかやらまいか、上達を考えてやろうとするとキツいので迷いましたが、ストイックに向上を目指すのは技術だけに絞ろうと思い、週末にコードをジャガジャガかき鳴らして気分良くなれればいいやぐらいな感じでとりあえずはやっていくことにしました。仕事が落ち着いたら弾き語り教室でも通ってガッツリやってみたいなーとは思ってます。

あとは体力の無さを実感しているのでランニングの習慣をつけたいです。寒さが和らいだらサイクリングもまた色んな場所に行きたいですね。

まとめ

勉強は毎日コツコツやりつつも、週末は思いっきり遊ぶ。そのメリハリをつけていく年にしたいなーと思っています。

乗り遅れただけ乗り遅れた人生なので、使える時間を全部使って息切れするまで勉強しまくって一発逆転を狙おうなんて思うこともたまによくありますが、自分はそんなにタフじゃないし、人生は他人との競争ではないと思うし、自分なりに成長を少しずつ重ね、毎日を楽しく生きて行けたらいいなーと思います。

数学好きの皆さん、Software Design 2017年12月号の特集が「ITエンジニアと数学」ですよ！

今日 (2017/11/18) 発売のSoftware Design 2017年12月号が数学特集です。

Software Design 2017年12月号｜技術評論社

ソフトウェアデザイン 2017年 12 月号 [雑誌]

下のような記事を書いた僕としては、買うしかないわけで。即購入、一気に読み通しました。 tkykhk.hatenablog.com

感想

感想はScrapboxに書いてるので興味があれば読んで下さい:
Software Design 2017年12月号 数学特集 - トミー - Scrapbox

まとめると「手を動かすこと大事！」ですね。

オンラインコミュニティ欲しい

感想の中でも書いてますがオンラインの数学コミュニティ欲しいなーと。数学の独学って詰まるからけっこうきついんですよね。

主催者になったりするのはそういう経験ないんでアレですけど誰かやってくれるならお手伝いとかしたいところ。誰かやってくれないかなー (チラッ)。

必読

ともかく。数学に興味のあるITエンジニアの皆さん、必読 ですよー。

Software Design 2017年12月号｜技術評論社

ソフトウェアデザイン 2017年 12 月号 [雑誌]

32歳にしてWebプログラマーとしてやり直すことにした

3ヶ月ぶりのブログ更新です。自分の状況に変化が起こったのでお知らせしたいと思い、記事を書きました。

これまで

僕は高校を中退して長い空白期間のあと、25歳で情報系の専門学校に入学し、2015年に29歳で卒業してから会社を2社渡り歩きました。1社目は開発者が2人だけのプロジェクトに配属されたあと、リーダーが辞めてしまい、1人で後始末を任されるという状況に耐えられなくて辞めました。そして、2社目は零細が故に開発の仕事をやらせてもらえなかったうえ、給料面で折り合いがつかず辞めました。

どちらも次の転職先を見つける前に辞めてしまったので、その間はコンビニのバイトをしながら食い繋いでいました。Twitterなどのプロフィールにプログラマーと書いていましたが、実際はコンビニ店員だったわけです (心はいつもプログラマーですが)。

そんなこんなで、次はどうするかと考えながらレジを打ったり検品したりしていたわけですが、ここはいきなり高いところを目指すよりは、しっかり地に足を着けて、エントリーレベルの求人を探した方がいいのではないかと思いました。それも正社員ではなく、アルバイトという条件で探すことにしました。そうすることで、立場は低いものの、先輩方に教えてもらいながら働けるのではないかと考えたのです。30を過ぎて未だにバイトというのも少し悲しくなりますが、高校を中退してから散々レールを外れて生きてきたのだから、今さら焦る必要はないと思いました。

もう1つの条件として、Webの会社にしようというのがありました。学校を卒業する以前はAndroidやiOSの勉強をしたり、モバイルアプリ系の仕事がしたいと思っていたのですが、結局モバイルアプリだけで収益を上げられるのはほんの一握りの会社で、Webこそ堅実なのではないかと思ったのです。

そして、学生だった頃からネット上で交流があり、関東にライブで遠征した時には実際にお会いしたこともある、くもキャストというポッドキャストをホストされているがみさんたちがWebの世界に生きていることもあり、せっかくそういう縁があるのだから自分もWebをやろうじゃないかと思ったのです。

あとは最近、なむさんや黒澤俊文さんといった、同じ30代にしてWebエンジニアの世界に踏み込んだ方に刺激を受けたのも大きいです。

そうして条件が決まったので求人を探してみると、まさに先輩に学びながら働けると書いてあるうえ、労働環境もよさそうな会社が見つかり、早速応募、先週無事に内定をいただきました。

現在

Webで行くと決めたので、今まで数学やアルゴリズムなどの基礎的な勉強をしていたのですが、仕事に直結するWeb開発周りの勉強を始めました。

今はfreeCodeCampというインタラクティブにWeb開発を学べるサイトで、"Front End Development Certificate"という修了書の取得を目的に勉強中です。これは指定されたJavaScriptのアルゴリズム問題と、HTML/CSS/JavaScriptのプロジェクトをいくつか完成させることで取得できるものです。プロジェクトベースなのが実践力をつけるためにかなりいい感じです。ちなみにプロジェクト用に作ったものはCodePenに置いています。

これから

freeCodeCampでフロントエンドの勉強はしつつ、セキュリティは重要なので、まずは徳丸本を読もうと思っています。そのあとは、ES6も含めたプレーンJavaScriptを抑えつつ、React / Redux、Vue.jsなどにも触れ、freeCodeCampのバックエンドに移っていこうと思っています。会社で扱っているのが主にPHPなので、その勉強も必要ですね。

Webって本当に勉強しなきゃいけないことが多いけど、それだけにやりがいのある世界だと思います。焦らず1歩1歩、力を付けていきたいと思っています。

『Clean Code』を読んだ

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

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

(2018/01/24 追記)
訳書が2017/12/18より再出版されているようです。

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

• JUnitは、Javaを学びたいKent Beckと、テストフレームワークを学びたいEric Gammaが、乗り合わせたアトランタに向かう飛行機の中で、3時間の間で基礎を作り上げた。

感想

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

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

Clean Code アジャイルソフトウェア達人の技

100000歳になった

本日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設計 徹底指南書

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

こんな記事を読んだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これから

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

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