『コーディングを支える技術』読書メモとか

大学四年生になって自分の勉強をする時間がようやく取れるようになったので、体系的な知識をつけるために技術書を読むことにしている。 ただ漫然と読んでいるとサラーッと読んでしまうので、人に説明できる程度には自分のものにしたかったので、自分用のwikiに読書メモをまとめている。 しかし、圧力がないと飽きてしまうのでとりあえずブログに公開してみることにした。

まとめ方は基本的に一つの節を一つの疑問文に直し、その答えを極力簡潔にその節の中からまとめる形。

以下自前wikiより転載。

---

コーディングを支える技術

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

読むことにしたわけ

1. プログラミングについての知識を深める以前に、全体の俯瞰をしたかった

2. 例外とかよく知らないなと思った

3. 勉強法についても乗ってるっぽくて良さそうだった

読後の感想

☆5

もっと早く読むべきだったとも思うが、今読むことが出来て本当に良かった。 知ってはいるし使ってもいるが何となくも理解しきれていない技術がどのような歴史的経緯で発明されて、今後どこに向かっていきそうなのかがかなりよくまとまっていた。 オブジェクト指向の章は今まで読んだ中で一番納得感のある内容だった。

ただ、この本を読んだからと言って実装ができるようになるとは限らず、また細かいところも省略されているのであとは自分で調べる必要がありそう。

読書メモ

第1章 言語を深く効率的に学ぶには

タイトルの通り

• 1.1 比較から学ぶ -why?

  • 言語ごとに共通な知識と違いを知ることが出来るから

  • RubyとCでtrueになるものの違い

• 1.2 歴史から学ぶ -why?

  • なぜその機能が必要なのかを、言語設計者の視点から知ることが出来るから

• 1.3 まとめ

第2章 プログラミング言語を俯瞰する

どうしてプログラミング言語が生まれたか?

• 2.1 プログラミング言語誕生の歴史 -what?

  • ケーブルをつなぎ替える→テープでのプログラミング(機械語)→FORTRAN等で人間が読み書きしやすく、という歴史

• 2.2 プログラミング言語の生まれた目的 -what?

  • 特定の目的を「楽」にするため

    • C++ならCと同等の速さのコードをきれいに書く

    • Schemeは言語仕様を最小限 仕様書全体で50ページ！

    • Pythonは読むのが楽

    • MLは言語処理が楽

    • etc

• 2.3 まとめ

第3章 文法の誕生

なぜ文法が必要か?

• 3.1 文法って何だろう？

  • 演算子の優先順位など、言語設計者が決めたルール

  • この章では演算子の様々な処理方法を比較する

• 3.2 スタックマシンとFORTH -what

  • スタックに値を入れていって、演算子/関数が来たらスタックから値を取り出すもの

  • PythonとかJavaのVMもスタックマシン型

• 3.3 構文木とLISP -what

  • 関数ノードの下に値が葉として生えてる木とその再帰的な組み合わせが構文木

  • 実は、LISPとFORTHは構文木を辿る順番が違うだけ

• 3.4 中置記法 -what

  • 1+2 みたいな+の使い方

  • 同じ構文木を作るためにいろんな文法があるが、それぞれを実現するために適切な構文解析器(パーサ)が必要

• 3.5 まとめ

第4章 処理の流れのコントロール

なぜ制御構造が必要か?

• 4.1 構造化プログラミングの誕生 -what

  • ifとかwhileとかが生まれた → なぜ?

• 4.2 ifが生まれる前 -what

  • アセンブリレベルではジャンプ(=Cでのgoto)を使っている。直感に反しており読みづらい。

  • elseも同様。楽で読みやすい方が良い！

• 4.3 while ──繰り返しのifを読みやすく表現 -what

  • ifとgotoだけで実現できるが、読みやすさ書きやすさが良い

• 4.4 for ──数値を増やしながらのwhileを読みやすく表現 -what

  • forを使うとループの初期化と週条件とステップがまとまってるので意図が分かりやすい。foreachも同様の目的。

• 4.5 まとめ

  • 使わなくても出来るけど、制御できるおかげで分かりやすい

第5章 関数

何故関数が必要か？

• 5.1 関数の役割 - what?

  • 理解のため - いくつかの行を一塊にして名前をつけることで 組織 のようになる

  • 再利用のため - 部品としてコンパクトに再利用できる。

• 5.2 戻る命令 - how?

  • 従来の goto 文だと戻ることができなかった。

  • 戻り先を書き換える方式だと上書きされたら戻れなくなる。

  • 戻り先をスタックに保存しておくことでネストした関数呼び出しにも対応できる。

• 5.3 再帰呼び出し - why?

  • 入れ子構造のデータを扱うために必要。

• 5.4 まとめ

第6章 エラー処理

なぜ例外処理が返り値を使う方法よりもよいのか？

• 6.1 プログラムも失敗をする - what?

  • ファイルの書き込みの失敗などは起きうるが、それを伝える必要がある。

• 6.2 失敗をどうやって伝える？ - how?

  1. 返り値で失敗を伝える - 失敗を見落とす、エラー処理がifの中にあるのでコードが読みづらくなるなどの問題がある

  2. 失敗したらジャンプする - 失敗したときにジャンプする場所を決めておくことでコードの可読性は向上する。

• 6.3 失敗しそうなコードを囲む構文 - why?

  • 例外の可能性を忘れる/不適切な例外処理を書くというもんだいを解決するためには、失敗しそうな処理を囲ってエラーをあとに書くという try ~ catch が必要。

• 6.4 出口を1つにしたい - why?

  • try, catch だけでなく finally も生まれた。

  • 対になる処理(file の lock , unlock など)を絶対に行う必要があるから。

  • D言語では scope(exit) というスコープガードを発明。

• 6.5 どういうときに例外を投げるか

  • 何が例外的状況なのかは一通りではない

  • 筆者としては、すぐ例外を投げてくれたほうが異常事態に気づきやすいので良い(フェイルファースト)

• 6.6 例外の伝搬

  • 関数fの中で呼ばれた関数gで例外が発生したとき、gで処理されない例外はfで処理されるか、fの上の関数に伝搬していく。

    • ある関数が発生させうる例外を特定するためにはその関数が呼び出しているすべての関数をチェックする必要がある。

  • Javaの検査例外では、例外を投げる可能性のあるメソッドを呼ぶときにその例外を処理するか自分も投げるのかを明示する。

    • かなり良いが、Javaの実装だと苦しい。

    • 型システムでどうにかならないか?

• 6.7 まとめ

第7章 名前とスコープ

なぜ名前の有効範囲を制限する必要があったのか？

• 7.1 名前はなぜ必要だったか

  • メモリの番地よりも人にとってわかりやすい

  • 名前は衝突しうるので、長い変数名をつけることとスコープを利用することが対策としてうまれた。

• 7.2 スコープの進化 - what?

  1. 動的スコープ - 入り口で元の値をとっておき、出口で戻す。呼び出された関数のスコープが呼び出し元と同じになってしまう。

  2. 静的スコープ - 関数ごとの名前と値の対応表を専用に持っているので、影響範囲を関数内だけに限定できる。←これが普通

• 7.3 静的スコープは完成形？

  • ネストした関数でのスコープや、外の関数への束縛など問題は残っており、各言語が頑張って解決している

• 7.4 まとめ

第8章 型

• 8.1 型とは何か

  • ビット列をどのように解釈するのかを定めた追加の情報

• 8.2 数値をオンとオフで表現する方法

  • 0~9をランプで表現するためには、位取りや7セグメント、そろばん形式など多くの形式がある

• 8.3 1つの位に必要なランプはいくつか？

  • 4つで良いが、2新方で表せばもっと節約できる。

• 8.4 実数はどうやって表現しよう

  • 固定小数点数ではどこまでを小数部に決めたかを覚えておく必要があり大変。

  • どこからか少数部かの情報自体を値に含めれば良い→浮動小数点数

• 8.5 型は何のため？

  • コンピュータにとってはビット列が何を表しているかわからない→言語処理系で宣言しておけばどのように処理すればよいかわかる。

• 8.6 型のいろいろな展開

  • 既存の型を組み合わせて作るユーザー定義型や、さらにデータの処理の仕方もまとめたクラスへと発展した。

  • 方があっているかはコンパイラがチェックできるので、型を仕様として用いることができるようになった。

  • 構成要素の型の一部が変わる型が生まれた。ex. Javaのジェネリクス, Haskellの型コンストラクタ。

  • 動的型付け: 情報の種類と値をセットにした上でメモリに保存することで、言語処理系で宣言する必要がなくなった。

    • メモリ上で同じように扱えるように設計されている。

    • 柔軟な処理ができるものの、コンパイル時に型の整合性チェックができなくなった。

  • 型推論

    • 型チェックかつ型宣言なし

    • より強力な型推論によってバグがないことを証明しようとする研究もある

• 8.7 まとめ

第9章 コンテナと文字列

「いくつものモノを入れるためのモノ」について、色々な種類がある理由とその長所と短所について。後半は特に文字列について。

• 9.1 いろいろな種類のコンテナがある - what?

  • e.g. Cの配列、 Lispのリスト、 Pythonのタプル、Rubyのアレイ……

  • これらをまとめてコンテナと呼ぶ

• 9.2 なぜいろいろな種類のコンテナがあるのか

  • それぞれのコンテナに長所と短所があるから。

  • ex. 配列と連結リストでは、操作によって効率の優劣が違う。

• 9.3 辞書，ハッシュ，連想配列 - what?

  • 「キー: 値」という組み合わせ。

  • 万能のコンテナはない

• 9.4 文字とは何か

  • これを文字と呼びましょうとし決めた記号の集合。「文字集合」

  • 文字集合をデジタルに表現するための符号化の方法が文字符号化方式であり、結局UTF-8が標準になりそう。

    • 混じってると困る。

• 9.5 文字列とは何か

  • 文字が並んだもの。C言語は長さの情報を持たないがPascal,Java,Pythonなどは持つ

• 9.6 まとめ

  • 文字列の実現へのアプローチにはいくつかの方法があるが、実装で解決するだけでなく標準化での解決も進んでいる。

第10章 並行処理

同時に複数の処理が実行される時何が起こっているのか。どんな問題が起こりうるのか。

• 10.1 並行処理とは何か

  • 複数の処理を時間軸上でオーバラップして実行すること。

• 10.2 細かく区切って実行する -what

  • 実際には、 人間が気付かないくらい短い間隔で複数の処理を切り替えながら実行している。

• 10.3 処理を切り替える2通りの方法 -what

  • どういう時に交代するのかには2つの方法がある。

    1. 協調的マルチタスク - キリの良いところで交代を宣言する。

    2. プリエンプティブマルチタスク - 一定時間で交代する。 ← 最近のOSはこれが多い。

• 10.4 競合状態を防ぐには -how

  • 競合状態が起こるには3つの条件がある。

    1. 2つの処理が変数を共有している。

    2. 少なくとも1つの処理がその変数を書き換える。

    3. 一方の処理が一段落付く前にもう一方の処理が割り込む可能性がある。

  • 3条件のどれかを解消すれば良い

    1. 共有しない: メモリを共有しない方法・メッセージを送り合う方法(アクターモデル)

    2. 書き換えない: Immutable パターン, const, val などなど

    3. 割り込まない: 協調的なスレッドを作る(RubyのFiberなど)、割り込まれたくないときは印をつける(ロック、mutex、セマフォ)

• 10.5 ロックの問題点と解決策 -what

  • デッドロック・合成できない(アトミックに実行されて欲しい一連の処理を扱えない)

  • DBのトランザクション理論を転用して、トランザクショナルメモリというものができた。→これからどうなる？

• 10.6 まとめ

第11章 オブジェクトとクラス

「オブジェクト指向という言葉がさすものは言語によって異なります。」

• 11.1 オブジェクト指向とは何か

  • BJarne Stroustrup(C++設計者)はオブジェクト指向における型や継承に肯定的

  • Alan Kay(Smalltalk設計者)はそれらには否定的だが、「オブジェクト同士がメッセージを送り合うというモデルでプログラムを表現すること」としオブジェクト指向を表している

  • 現実世界のもののモデルをコンピュータの中に作るための概念がオブジェクト指向

• 11.2 変数と関数を束ねて模型を作る方法

  • クラス以外の3つをまず以下で説明

• 11.3 方法1 モジュール，パッケージ

  • 関連性の強い関数や変数のまとまりを表現するもの。

  • Perlでの例。最初はデータもモジュール(パッケージ)に含めていたが、データを外部のハッシュにし、blessでモジュールと紐付けて実現。

• 11.4 方法2 関数もハッシュに入れる

  • JSでは関数もハッシュ(Object)に入れる。

  • ただObjectに入れるだけだと各Objectに関数があってメモリの無駄なので、prototypeに関数を入れておくことでオブジェクト指向を実現。

• 11.5 方法3 クロージャ

  • 状態を持った関数を作る。

  • 自由変数を束縛し、関数の中に閉じ込める。

  • ここの説明はサラッとしてるので、オブジェクト指向なJavaScriptプログラミングのススメ(2) | ゆっくりと… を見ると良い。

• 11.6 方法4 クラス

  • 言語によってクラスの主要な意味は異なるが、主に3つの意味がある。

    • まとまったものを作る生成器(上述の例)

    • どういう操作が可能かという仕様としてのユーザー定義型(C++での主目的)

    • 継承しコードを再利用する単位

• 11.7 まとめ

第12章 継承によるコードの再利用

いろいろな継承の仕組みの長所と短所

• 12.1 継承とは

  • 実装を自動で引き継ぐ考え方。主に3つの考え方がある。

    • 一般化/特殊化

    • 共通部分の抽出 - 複数のクラスの共通部分を親クラスとして抽出する

    • 差分実装 - 変更分だけ実装していく → コードの場所がわかりづらくなるという批判あり。

  • リスコフの置換原則(継承はis-aの関係でなければならない)

• 12.2 多重継承 -what

  • 現実世界では、1つのモノが複数の分類に属することがほとんど。→多重継承

• 12.3 多重継承の問題点──またしても衝突！

  • 多重継承した結果複数のクラスで同じメソッドを持っていたらどうするか?

    • 多重継承の禁止(Javaなど) - 委譲を用いてオブジェクトを持つにとどめる(依存性の注入)。インターフェースを用いる。

    • メソッド解決順序を工夫する(Pythonなど) - 深さ優先探索(Python2.3まで)、C3線形化(Python2.3以降)

    • 処理を混ぜ込む:Mix-in(Rubyなど) - 再利用したい機能だけを持った小さなクラスを混ぜ込む。(衝突は解決できない)

    • トレイト - 再利用の単位としての役割をインスタンス生成機としての役割から分離する。Rubyのmodule同様メソッドをまとめる束だが、mix-inでの衝突時に明示的にエラーにする。トレイトを利用するクラスに必要とするメソッドを明示しておく。

• 12.4 まとめ

さらに欲しいものを頂いた

前回の二冊に加え、ほしいものリストの中から、徳丸本・珠玉のアルゴリズムデザイン・正規表現技術入門を頂きました！

ありがとうございます急いで勉強します(o_ _)o(o_ _)o

ほしいものを頂いた

誰ですか！院試前の僕に『オブジェクト指向入門』と『型システム入門』を買ってくださったのは！

段ボール届いたとき重すぎて絶対何かヤバいやつだと思いましたよ！

ありがとうございますこれからも誠意勉強してまいります本当にありがとうございます（院試ヤバいです）

Kindle Unlimitedの技術書一通り見たので良さそうな本をコメント付きでまとめた

TL;DR

Kindle Unlimitedのコンピュータ・ITカテゴリの2826冊を一通り見たので良さそうな本を http://www.amazon.co.jp/registry/wishlist/9K6RC0XIUX58 にまとめた。結局19冊になった。
ちょっと出遅れたので、差別化のために本記事では説明とか個人の感想多めでお送りしてます。

前置き

Kindle Unlimited ついに始まりましたね。
最近Kindle PaperWhiteを買ったばかりなので嬉しいところですが、 院試が終わるまではとりあえず保留です。
漫画がもっと多いと思ってたらそうでもないみたいなので、 そのうち来るであろう「Kindle Unlimitedで読むべき漫画100選」 みたいな記事を待って判断することにします。

漫画まとめについては誰か詳しい人にお任せして、 僕はプログラミングとか関連の良さそうな本を探してみました。
KindleUnlimitedのコンピュータ・ITカテゴリの全部の本（Amazon.co.jp: コンピュータ・IT - Kindle本: Kindleストア ）のタイトルと表紙だけ見てみて、 まあまあ欲しいなと思える本をほしい物リストに突っ込んでいった感じです。
完全に自分のためにメモ取りつつ見ていましたが、 自分と同レベルの人の役には立つかなあと思い、 記事にしておきます。
読んだわけではないので、その点には注意してください。

といっても 読むべき技術書についてはその人の技術レベルに大きく左右されるので、 一応先に僕の技術レベルを自己評価しておくと、

• rubyが好きで、普通の言語で普通の事なら書ける(関数型とかはすごいH本読んだくらいしか経験なし)
• railsとかandroidアプリづくりはまあ普通のことならできる。
• 競プロとかは興味あるけど始める度に挫折してる。
• プログラミングは好きだけどエンジニアとしてやっていけるかは不安

という、まあ初心者〜中級者の中級者寄りって感じでしょうか。
あの有名なグラフで言うと下がり始めって感じですかね。*1

*2

このレベルを念頭にして僕のメモや思いも読んで戴けると、paizaさんの プログラミング初心者向け！Kindle Unlimitedで読み放題な技術系の書籍26冊と4シリーズ - paiza開発日誌とは差別化出来るのではないかという感じです。
もちろん、paizaさんの紹介している冊数のほうが多いですし、言語等の分野も広いので、こちらもご参照ください。

以下のものについてはアフィリンク？とかいうものを貼っていない（貼り方を知らない）ので、お気軽にクリックしてください。
(Kindle Unlimitedの商品クリックが収益になるかは知りませんが)

自分用のメモも兼ねてるのでこっからは丁寧語やめます。恐縮です。

本題

技術全般

全般。

エンジニアのためのGitの教科​書［上級編］ Git内部の仕組みを理解する

エンジニアのためのGitの教科書［上級編］ Git内部の仕組みを理解する

昔授業でgitのソースをいじってプルリク送った時、自分はgitについて何も知らないと思ったため。
また、add commit push merge などの基本操作はできても、ちょっと応用的な操作はあまり知らないものが多いため選出。

Gitの仕組みを理解して使いこなせば、必ず同期と差がつく――新人エンジニアや初級者が学ぶべき点とは？：CodeZine（コードジン） で紹介されていたので知っていた。
本当はこの基礎編である Amazon.co.jp： エンジニアのためのGitの教科書 実践で使える！バージョン管理とチーム開発手法 eBook: 株式会社リクルートテクノロジーズ, 株式会社リクルートマーケティングパートナーズ, 河村聖悟, 太田智彬, 増田佳太, 山田直樹, 葛原佑伍, 大島雅人, 相野谷直樹: Kindleストア が欲しい気もするが、Unlimited入りはしなかった模様。残念。

Webエンジニアが知っておきた​いインフラの基本

Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~

インフラ知っておきたいため選出。

学生時代に知っておきたかったWeb技術の学び方の学び方 | リブセンスで紹介されていたので知っていた。 ななめ読みで良いらしいので、Kindle Unlimited に向いてそう。こういう本が増えてほしい。

SQL ゼロからはじめるデータベース​操作

CD付 SQL ゼロからはじめるデータベース操作 (プログラミング学習シリーズ)

ORマッパに頼りまくってた自分を反省し、SQLの勉強したいので。

DB/SQLに関しては名著がたくさんあるのは知っているので、 実際にはこれを読むことはないかもしれない。
でもレビューが良かったので試し読みはすると思う。
試し読みが出来る本が増えるのは嬉しい。

コンピュータグラフィックス [改訂新版]

コンピュータグラフィックス [改訂新版]

これと同じシリーズの ディジタル画像処理 [改訂新版] が学科の教科書になってたので、これも網羅的で良いのではないかと期待。
このシリーズは他にも入門CGデザイン-CG制作の基礎というものもあるらしい。

……だが、教科書だった『ディジタル画像処理』は正直なところ学部の教科書としては広く浅すぎたので、この本もあまり期待できないかもしれない。評価は高いけど……

（カテゴリが倫理学・道徳とか自己啓発になってるのは何なんだろう……）

実践的な本

超高レイヤなところ。この辺は結構がっしりしているし、実戦で使っていきながら覚える必要があるので、Unlimitedでさくっと読むのには向いてないのかもしれない。

Docker実践ガイド

Docker実践ガイド

Docker使いたいから。
昔無料セールやってた時にプログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化 : 阿佐 志保, 山田 祥寛 : 本 : Amazonを買ったので、僕はこっちで良いのだけれど、まあ一応記録しておく。
KubernetesについてはDocker教科書にはなかった気もする。

Game Programming Patterns ソフトウェア開発の問題解決メニュー impress top gear

Game Programming Patterns ソフトウェア開発の問題解決メニュー (impress top gear)

ゲームプログラミングはあまりやったことがないけれど、近々やることになるかもしれないので。何より評価が高い。
内容としてはゲームプログラミングでのデザインパターンの本らしい。

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ぼく「あじゃいるってなんやねん」

アジャイルサムライとかの有名な本に比べてどうかは知らないです。ごめんなさい。何も分かりません。生きててごめんなさい。
書いてから気づいたんですが、 id:hitode909 さんがKindle Unlimitedでよさそうなソフトウェア関係の本 - hitode909の日記で紹介していらっしゃったので多分いい本。ごめんなさい。id:hitode909 さんが紹介していらっしゃる本は多分他のも良い本です。ただ、自分にはまだ難しそうという気持ちで一杯です。

プログラミングコンテスト関連

何故かマイナビのこのシリーズがやたら豊作だった。有名な本だらけ。 多分この辺の本のメインターゲットは学生だろうから、安く読めるのはとても助かる。
ただし、よく指摘されている通り、アルゴリズムの教科書ではないので、きちんと学問的なバックグラウンドのあるアルゴリズム・イントロダクションとかの鈍器をちゃんと読んだほうが良いはず（ぼくはよんだことないです）。証明とかも楽しそうだし。参考まで。

プログラミングコンテストチャレンジブック [第2版]　～問題解決のアルゴリズム活用力とコーディングテクニックを鍛える～

プログラミングコンテストチャレンジブック [第2版]　?問題解決のアルゴリズム活用力とコーディングテクニックを鍛える?

いわゆる蟻本。競プロの入門書としてめっちゃ良いらしい。
ちなみに僕も一応持ってるけど1章で挫折したので、そろそろ再開したい。

プログラミングコンテスト攻略の​ための

プログラミングコンテスト攻略のためのアルゴリズムとデータ構造

アルゴリズムとデータ構造

1/30 発売！「プログラミングコンテスト攻略のためのアルゴリズムとデータ構造」 - iwiwiの日記 によると、蟻本よりも前段階の本らしい。AOJと連携してるってのはとても良さそう。 内容も競プロに限らない、基礎的で網羅的な内容になってるらしくて良さそう。

友人の id:Tak_Yaz と、AOJでアルゴリズムの勉強を一緒にしようという話を前にしたけれど、彼だけが真面目に進めているようなので僕もまじめに始めたいところ。

オンラインジャッジではじめるC​/C++プログラミング入門

オンラインジャッジではじめるC/C++プログラミング入門

先述の id:iwiwi さん曰く、『プログラミングコンテスト攻略の​ためのアルゴリズムとデータ構造』の前著らしい。競プロにはまってC++を勉強したくなったらこれかなあ。

セキュリティコンテストチャレン​ジブック CTFで学ぼう！情報を守るた​めの戦い方

セキュリティコンテストチャレンジブック -CTFで学ぼう! 情報を守るための戦い方-

CTFの有名な入門書。とても良い。僕は友達のを借りてSECCONにお試しで出たくらいだけど、とてもためになったと思う。何よりCTFは楽しい。むずいけど。

世界で闘うプログラミング力を鍛える150問 トップIT企業のプログラマになるための本

世界で闘うプログラミング力を鍛える150問　トップIT企業のプログラマになるための本

wantedlyのインターンしてる時に、突然リードエンジニアの方（特定可能ですね）にgoogleの入社試験（めっちゃ特定可能ですね）風のものをしていただいた際、死ぬほどテンパったという苦い経験があるため、コーディング面接の問題には興味があるので選出。

あと、某企業（これは特定しないでください）のインターンの面接に行ったら英語のコーディング面接で、これもかなりテンパったので。
こっちの面接はよくある競プロの問題とかawakiaさんからの問題よりは簡単だったけど、最初は簡単なコードを提示し、そのあとで面接官と議論しながらコードを改善していくというプロセスはコーディング面接特有な感じもしたし、何より楽しかった。

友人とかと出し合いながらやっとくと就活対策になるのかもしれない。

世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~

競プロではないけど。僕は世界で戦いたいので。

内容はキャリアプランに関する本らしい。院試前の今、人生で一番キャリア選択に悩んでいるので多分これは読むと思う。

もう一度言いますが、僕は世界で戦いたいので外資系のIT企業とかでインターンとかアルバイトとかしたいです！！何かそういったお話あればご連絡お待ちしております！！！
以上宣伝でした。

特定技術

特定の技術関連の本。僕の興味範囲に偏ってます。

改訂3版 基礎 Ruby on Rails 基礎シリーズ

改訂3版基礎 Ruby on Rails (KS IMPRESS KISO SERIES)

たしか前バイト先でオススメされた。RESTとかについての解説が詳しいと伺った気がする。

基礎シリーズは他にも 基礎pythonとかもあるようなので、参考まで。

Android実践プログラミング 現場で生まれた設計パターン

Android実践プログラミング 現場で生まれた設計パターン

android好きなので。 androidのベストプラクティスではfuturice/android-best-practices: Do's and Don'ts for Android development, by Futurice developersが有名だが、TechBoosterなのでこれも信用が置けそう。一通りは読んでおくべき氣がする。

今回はあまり調べていないが、TechBooster以外にも良い同人サークルはたくさんあるはずなので、そういうところの本が読めたら良いなと思う。

UNIXの絵本 UNIXが楽しくわかる9つの扉

UNIXの絵本

「hogeの絵本」シリーズはかなりのものがあるみたい。とても良い。
僕が買うなら多分UNIXの絵本かなあということで登録。

絵本シリーズはアンク社の一覧から探すのが良さそう。
Amazon.co.jp: 株式会社アンク: Kindleストア

その他

読み物とか

ゲーム界のトップに立った天才プログラマー 岩田聡の原点: 高校同期生26人の証言

ゲーム界のトップに立った天才プログラマー　岩田聡の原点: 高校同期生26人の証言

超読みたい。

魔法の世紀

魔法の世紀

落合先生の話題の本。僕も研究分野はHCIなので、読まなきゃいけない感じがする。

こんな最近の本も入ってるんだなあと言った感想。

すべてがＦになる THE PERFECT INSIDER S&M

すべてがFになる (講談社文庫)

コンピュータ・ITじゃないけど、そういう内容らしいし一度読んでみたくて……

感想

出版社によっては結構良い本があるなあと感じた。 19冊もあれば数ヶ月は持ちそうだし、そもそも一冊数千円するものがほとんどなので、読み放題1000円弱/月はかなりお得感ある。

ただ、Kindleで本を探す度に思うが、Amazonは自分が読みたいと思う本がとても見つけづらい。結局いつも全部見てから選ぶ事になっているので、もっと詳細で正確なカテゴリ分けがほしい。
今のところ、おすすめ順もレビュー順も上の方はあまり信頼出来ない（自己評価なんじゃないかと思う）ので、結構したの方まで見ていかないと上に挙げたような有名な本は出てこない。
逆に、下に行き過ぎると個人出版地獄(*3)が待っているので、なかなか難しい。 全部見た感じ、おすすめ順だと概ね20ページ目以降はほぼ地獄と言って良さそうです。
どうにかしてスクリーニングできないものかな……。

Kindle Unlimitedにはさっと読み捨てるのに向いてる本、向いてない本が明らかにあるので、今後どうなるかは見守っていく必要がありそう。
出版者に同利益が入るのか知らないけど、同人サークルとかの良い本がもっと入手しやすくなってサークルの方にも収益が入ると良いなと思った。

最初にも書きましたが、まとめは http://www.amazon.co.jp/registry/wishlist/9K6RC0XIUX58 （ほしい物リスト）にあります。僕はまだUnlimited登録してないので、(書籍版を)買ってくださるととてもありがたいです(^o^)(^o^)
ちなみに本当に欲しいもののリストは http://www.amazon.co.jp/registry/wishlist/2QVK1V1EB7XIN にまとまっているので、買ってくれると死ぬほど嬉しいです。
ちなみにですが、僕の誕生日は8/17です。再来週です。近いですね。8/17。パイナ(817)ップルの日と覚えてください。よろしくお願いいたします。

注

*1 このグラフの中でどこら辺かという自己評価、結構有用な気がするので就活とかで使って欲しい

*2 Figure 1 - The three stages of expertise. より改変

*3 個人出版が悪いというわけではないですが、Numbersの使い方を超細かく分けて300円で売ってる本とか、

タイトルも著者名も表紙も謎すぎて怪しすぎる本とか

を見てしまうとなかなか地獄感ありますね……