購入する技術書を電子書籍のみにしてみた結果
技術書
紙と電子書籍の使い分けについて雑文を書いてみようと思います。
経緯
我々ソフトウェアエンジニアは常に勉強し続けなければ時代に取り残されてしまう哀れな生き物です。
なので、片時も技術書が手放せません。
しかし、良書と世に言われている技術書の中には分厚いものも多く、率直に言って保管するにも場所は取るし、混雑する電車内では読むのも憚られるし、で物理的に扱いやすいものではありません。
そこで、電子書籍なのですがここ数年Kindleの最初版をアメリカのAmazon.comより取り寄せて以来徐々にkindle版を購入する比率を高めていました。
そういうこともあり特に昨年は購入する技術書をほぼ全て電子書籍化するという試みを実行してみました。
その、結果を以下にまとめてみます。
要約した結論
最初に結論を言ってしまえば
- 良いことばかりじゃないけど、悪いことばかりでもない
という当たり前過ぎて無意味な結論で、メリット、デメリットも目新しくもないよく言われていることの再確認になりました。 ただ、電子書籍で買ったほうが良いものと私の用途や現時点での有り様として電子書籍にそぐわないものとが何となくわかってきたのでそこれについてもまとめておきます。
便利な点
不便な点
- kindleのせいか、その使い方の問題か内容を俯瞰的に見づらい
- 紙のパラパラざっと読み感に勝てない
- 簡単に購入でき過ぎるため不必要な本まで買ってしまう*1
- pdfのうちkindleで読めないものがある*2
- 電子書籍として発売されていないと読めない
そして、上記から導かれる電子書籍に合う技術書と合わない技術書は?
電子書籍に合う技術書
- 英語の技術書
- 理由:読みながら知らない単語をクリックして意味を辞書で引けるので
- 分厚い技術書
- 理由:重くて持ち運びづらい技術書も出先で読める!こんなに嬉しいことはない!
電子書籍に合わない技術書
- 入門書
- 理由:自分の使い方の問題かもしれないけど、入門書はその技術をどうすれ使いはじめられるかをザーッと流し読んで理解するために読むものなのだけど、そのパラパラかいつまんで読むっていうのがやりづらい。
- 逆引きっぽいリファレンス系
- 理由:検索はできるけど、それだったらWebで検索すりゃいいし、リファレンス自体書籍で持ってる意味ないのかも…。*3
というわけで、昨年読んだ技術書のうち特に(紙ではなく)電子書籍で読めてよかったと思えたのは以下の二つです。
物理では重い本
システムテスト自動化 標準ガイド CodeZine BOOKS
- 作者: Mark Fewster,Dorothy Graham
- 出版社/メーカー: 翔泳社
- 発売日: 2014/12/17
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
辞書ひきながら読みたかった本
Soft Skills: The Software Developer's Life Manual
- 作者: John Z. Sonmez,Scott Hanselman,Robert C. Martin
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2014/12/29
- メディア: ペーパーバック
- この商品を含むブログを見る
でも、ぶっちゃけ最強なのは電子書籍と紙の本両方買うのが一番だと思いますよ!
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もあるようなので、もう少し触ってみれたら書いてみようかとか勉強会直後のモチベーション最大の時期なので思っています。