2015年に読んだ本まとめ
2015年に読んだ本を読書メモから簡単にまとめておきます。
まず、ベストの一冊を先に記載し、 そのあとに読んだ本リストという形にしておきます。
最高の一冊
- How Google Works
- 作者: エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル,ラリー・ペイジ
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2014/10/17
- メディア: Kindle版
- この商品を含むブログ (6件) を見る
これを技術書と分類して良いのかな?ってところもありますが、
自分にとって技術者として進む道をある意味決定付けた一冊です。
この本に書いてある自分にとって共感できるやりたいことが
全くできていない当時の自分にとってある種の踏ん切りをつける助けになった一冊となりました。
結局、他にもいろいろありましたが、当時の職場を辞めて自分のための道を進むことになりました。
読んだ本リスト
読んだ順とかではなく、大体の分類順です。
特に感想もここには書きません。
技術書
プログラミング系
ミドルウェア系
- Ansible入門
- Redis入門
- 理論から学ぶデータベース実践入門
- みんなで使うGithub
- グラフデータベース
- 実践Vagrant
- 内部構造から学ぶPostgreSQL設計・運用計画の鉄則
キャリア、マネジメント系
テスト系
- システムテスト自動化標準ガイド
- テストから見えてくるグーグルのソフトウェア開発
その他
技術書以外
まとめ
2015年はその前年がマネジメントに偏った読書をしていた影響もあってかかなり幅広く読んだと思います。
基本的に遅読なので割いている時間の割に多く読めてはいませんが、そういうものと割り切っています。
とにかくHow Google Worksは自分にとってエポックメイキングでした。
ついでに言うと、上記を読んだ人は気づいているかもしれませんが、本ブログの題名もHow Google Worksで出てきた一言から取っています。
自分がとっても好きな言葉です。
キャッシュサーバーをスケールアウトしたい人はtwemproxyを使うといいよ
最近ちょこちょこ触っているtwemproxyの知見を書き残しておきます。
言いたいことはタイトルが全てって感じです。
twemproxyとは?
twitterでも使われている。memcacheまたはredis向けproxy。
以前はnutcrackerと呼ばれていたそうです。
twemproxyの使いどころ
例えば、普通のキャッシュサーバーを使ったこんな構成を考えてみます。
この構成からキャッシュサーバーをスケールアウト複数台構成にする場合、普通のLBだとヒット率が下がるためあまり良くありません。 同じキーは必ず同じサーバーへと振り分けて欲しい。 そんな時にお手頃なのがtwemproxyというわけです。 構成はこんな感じ。
twemproxyはアプリケーションとキャッシュサーバーの間で透過的に動作し、キャッシュサーバーのクラスタリングやそこからのスケールアウトを出来るようにするためのプロキシサーバーです。
デーモンとして、プロセスを立ち上げておきアプリケーションからキャッシュサーバーへのアクセスを振り分けたりするのが主な使い方でしょう。
また、twemproxyは動作中の状態をログ以外はディスクに書き込まない、つまりほぼオンメモリで動作するアプリケーションなので非常に軽快です。
永続化しないためdockerのようなコンテナベースの仮想化とも相性が良いと思います。
例えば、memcacheを複数台でクラスター化したい場合とか、redisの古いバージョンしか使えない状況でredis cluster使いたい場合とかに重宝する感じです。
利点
特徴でもある、メモリモデル。
キーの振り分けアルゴリズムさえ同じにしておけば容易にスケールする。(複数台のtwemproxyが同じ振る舞いをするので負荷分散が容易)
デメリット
あまりバッファリングできないためキャッシュサーバーへ接続できないとデータロストの可能性がある。
スループットには限界がありそう。*1
てな感じです。
ちょっと先にはなりますが、本番投入も見据えているので、そしたら運用面の知見も得られるかなー
*1:そこらへん見きれていないのでどの程度とかの知見はなし。
ちゃちゃっとWebサーバーを立てる方法
自分のやってきた方法の履歴を公開してみます。
やりたいこと
開発環境(Windows)であるところの自分のPCでちゃちゃっとWebサーバーたてて、静的コンテンツ確認したいな。
的な場合の話です。
題名とちょっとずれているような気もするけど気にしない。
例えば、htmlとcssとJavaScriptだけ用意して簡単な見栄えや動きを確認する場合なんかです。
動的なサーバーサイドの確認はまた違ったやり方することが多いです。
IIS
WindowsならIISっしょ常識的に考えて!
そんなふうに考えていた時期が僕にもありました。
- メリット
- Windowsと親和性が高い。
- UIでポチポチやってWebサーバーが動かせる
- デメリット
- 最初に使うときはIISインストール必要。(特に昔はインストールディスクが必要でうざかった。)
- ぶっちゃけ、UIで設定とかメンドイ
apache http server
Webサーバーならapacheっしょ。というわけでapacheも試しました。
- メリット
- デメリット
- たまにしか触らないのにhttpd.confの書き方が分からん!って毎回なった。
- 前職の現場に入っていたウィルス対策ソフトに通信をブロックされてしまった。
Jetty
サーブレットコンテナのjettyは単独でjavaプロセス起動してWebサーバーとして機能するので重宝していました。
- メリット
- 業務プロダクトでもつかっていたので精通していた
- 起動終了をコマンドたたいて簡単に出来た
- デメリット
- 設定の仕方とかそんなに情報はない(5年くらい前の当時)
> java -jar jetty.jar
みたいな実行の仕方だったと思う。(うろ覚え)
Python http.server
Python2系とPython3系で異なるようですが、pythonは処理系に簡易なWebサーバーが最初から入っていることを最近知りました。
例えば、Python2系なら
> python -m SimpleHTTPServer [ポート番号(デフォルトは8000)]
python3系だと
> python -m http.server [ポート番号(デフォルトは8000)]
みたいな感じ
まとめ
今ならpythonかなぁ。
コマンド実行したディレクトリがドキュメントルートになるので使い勝手がよいのですよ。
あと、たぶんrubyやnodeでも出来るんだろうけど自分がやり方を知らないというだけなので。
そこらへん調べて分かったら追記なりフォローしよう。
twemproxyのソースを緩く読む
これを緩く読み始めた。
エントリーポイントは
/src/nc.c
ありとあらゆるところにプリフィックスとして"nc"が振られている。
うーん?こういうものかな?
twemproxyとは?みたいのは面倒だから書かない。
もう、これは自分用のメモと割り切るよ!
ちなみに、"nc"はnutcrackerの2単語の頭文字かな?
nutcrackerはtwemproxyのもともとの名前っぽい。
ソースの隅々まで、アプリ名の略称をプリフィックスを付けたけど、後でツール名が変わって意味わからない感じになってしまっている・・・。
ここまでで、30分。 ちょっとずついくか。
Yahoo! JAPANデータサイエンスソリューションワークショップ+懇親会 #yjdsw2
参加してきました。
なぜ参加したか?
最近業務でデータサイエンスを利用できそうな大規模なデータを扱う可能性が出てきたという経緯があります。
ただ、自分のバックグランドとして受託開発の何でも屋だったので大規模なデータとは全く縁がなかったのでその学習機会に飢えていたということがあります。
感想
まず、このような場を提供してくれたYahoo Japanに感謝します。
素晴らしいホスタビリティで彼らのデータサイエンスにかける意気込みというか本気度も良く伝わってきました。
機会があれば、正のフィードバックループが築けたら嬉しいですね。
まとめ
Yahooさんが数年前からデータサイエンスの分野に投資してきた種が芽吹きだしたというのが分かる内容でした。
逆に言うと、安易に結果だけ求めてもこの分野でビジネス的に成果を上げられると考えるのは早計だということです。
懇親会で、Yahooの社員さんと何人かおはなしさせていただきましたが、現状の課題を伝えるとすぐ詳しい人を紹介してもらえ、懇親会でぼっちになるというよくあるコミュ障エンジニアにとっては非常に助かりました。
第二回 Tokyo Apache Drill Meetup #tokyodrill に参加したよ
こちらに参加しました。 drill.connpass.com
経緯
実は今回、Apache Drillに興味があっての参加というわけではありませんでした。
大規模データを扱う勉強会に意図的にここのところ参加しているのですが、昨日の「Yahoo! JAPANデータサイエンスワークショップ+懇親会」に参加したかったのですが無理っぽかったので何かないかなー?って探していて見つけて行ってみた。とそういう経緯です。
ただ、ゆるいモチベーションで参加したにも関わらず得るものは非常に多かったと思います。
内容
あまり、ちゃんとメモってなかったのですがApache DrillがCSVからRDBMSから何から何までSQLで扱ってやろうという野心的なプロダクトというのが分かった。それだけでも収穫です。
最近はMySQLでその特徴的なSQLにびっくりしていたんですが、ANSI互換のApache Drillの方が自分には扱いやすそうです。
あと、最初のプレゼンでApache Drillのコミッタ?かなの方の発表が全編英語だったのですが、比較的平易な言葉を選んでくれたおかげか結構聞き取れたのが嬉しかったですね。
英語のpodcastをたまに聞いていた甲斐があったかなー
Apache DrillのAdvent calendarもあるようなので、もう少し触ってみれたら書いてみようかとか勉強会直後のモチベーション最大の時期なので思っています。
ソフトウェアエンジニアとしての目標を立てたよ
ポエムを少々書きます。
自分は今年で38才。
一時騒がれたプログラマーの定年とされる35才をとっくにすぎたこの時期に至って未だに5年後、10年後の目標を漠然としか思い描けないままここまできてしまいました。
ただ、物事を始めるのに遅すぎることはない。はずです。
というわけで、自分のソフトウェアエンジニアとしての目標=ゴールを策定してみようと決心しました。
なぜ目標を立てようと思ったのか?
直接的には以下の本を読み始めたからです。
Soft Skills: The Software Developer's Life Manual
- 作者: John Z. Sonmez,Scott Hanselman,Robert C. Martin
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2014/12/29
- メディア: ペーパーバック
- この商品を含むブログを見る
また、間接的というか最近の自分の学習傾向を振り返った際に、非常にまとまりがないというか軸がない状態であることを反省したという部分があります。*1
どのように目標をたてたのか?
比較的"Soft Skills"の記載内容に立脚していますが、以下のような手順でざっくりたてました。
- 自分のキャリアを棚卸しし
- さらにその中で自分が能力を発揮できそうなことを抽出
- さらにその中で将来にわたって基軸となるような領域からゴールを定める
ゴールとしてはちょっと難しそうだけど、絶対できないというわけじゃないくらいの目線の高さを設定しました。
目標立てたらどうする?
目標は立ててお終いというわけにはいきません。
今後の作業になってしまうのですが、大きな最終目標にたいしてブレイクダウンというか道標になるようなものとして直近1年の目標を立てる。
それを一つのプロジェクトとして個人プロジェクトをbacklogかなんかでプロジェクトマネジメントしながら進めていこうと思います。
最終目標は不可侵なものではないのでつどつど修正していきたいですし、その途中となる1年ごとの目標も適宜修正しながら進めていこうと思っています。