2017-10-15

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歩、力を付けていきたいと思っています。

2017-07-03

『Clean Code』を読んだ

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

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

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

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

作者:Robert C.Martin
KADOKAWA

Amazon

構成としては、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 アジャイルソフトウェア達人の技

作者:Robert C.Martin
KADOKAWA

Amazon

2017-07-03

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()

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

2017-03-20

『達人に学ぶ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設計徹底指南書

作者: ミック
出版社/メーカー: 翔泳社
発売日: 2013/08/07
メディア: Kindle版
この商品を含むブログ (4件) を見る

2017-01-05

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

こんな記事を読んだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これから

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

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

2016-12-31

2016年振り返り

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

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

技術面の振り返り

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

Python

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

Kotlin

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

iOS / Swift

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

その他振り返り

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

数学

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

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

ロードバイク

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

ギター

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

まとめ

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

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

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

2016-11-05

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

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

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

日々最新の情報を収集するため、僕が行っている方法を紹介したいと思います。僕の興味のある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というニュースレターの作者

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

2ch→redditで対応させると、板→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を貼れないためこういう書き方になっています。実際に入力する際はスペースを省いて下さい。