読者です 読者をやめる 読者になる 読者になる

「モバイルアプリ開発エキスパート養成読本」を読んだ

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパートになりたいので読んでみた。
初っ端からいきなり Kotlin の話があり攻めてて良い。

iOS エンジニアなので iOS 関連のところの心に残ったことだけ、さらにこれは書評ではなくメモに近いので、本の内容がどうこうよりもそれを読んで感じたことを書いておく。

3-1 Swift 3.0 入門

Swift 3 の命名規則についての記事を読むたびに、英語力が足りないと Swifty なコードをかけないと感じる…。

Protocol の命名、 HogeProtocol とか書いてるのみたりするけどそれは思考停止で Swifty じゃないのだろうな。
メソッドの定義はなんとなく動詞で書きたくなってしまうのだが、これは Swift 関係なく改めないとマズそう。

3-2 Xcode 8 入門

Memory Graph Debug の使い方などが書かれている。
Xcode Extension については、私は XVim のために署名を外して使ってしまっている、誰か XVim-Extension を作ってくれと言う気持ちしかない。

4-1 リアクティブプログラミングと Rx, 4-3 RxSwift 入門

Rx なんとなく理解してきたタイミングで読んだが、やっぱり概念はわかるけどモヤモヤが晴れないと言う感じ。難しい。

Subject や Value は積極的に使うべきではないと書かれていて、でも MVVM やるなら PublishSubject とか使うわけじゃないですか、これもアンチパターンなのだろうか。
宣言的にかけるのは確かに良い。のだが、素人が Rx してしまうとわけがわからない複雑な Stream ができてしまう気がする。と言うか私の書いている個人開発の MVVM がだいぶ辛くなっている。
自分一人でやっていると間違いに気がつきにくいので、複数人でレビューし合いながらやるのは良いと思う、自分の理解力や実装力が足りないと言われてしまえばそれまでだが。

UITextField の初期化時に空文字列が bind されてしまうのに困っていたのだが、 skip(1) で初期化時の空文字列は無視しよう書かれていて、一つ疑問が晴れてよかった。

5-2 タイプセーフでモダンな iOS アプリの設計

storyboard, TableViewCell の初期化やキャストを Swifty に書いていこうという内容。
会社でやっているのは segue で画面遷移しているので、 segue は早く引き剥がしたい。
TableViewCell のもこのやり方に変えるぞ!

6-3 iOS アプリのテスト

めちゃくちゃためになる。
UITest は書いたことないし、パフォーマンスがテストできるのも恥ずかしながら知らなかった。
今後 UITest を書くかと言われると微妙、でも書いてある通りログイン画面などの非常に重要なところはあったほうがいいかなと思った。

全体として

読むのにそんなに時間はかからないし、ポイントがわかりやすくまとまっているので良かった。
やはり読んだだけではモバイルアプリ開発エキスパートにはなれなかったので、学んだことを少しでも実践していきたい。

あと表紙のおっさんは誰なんだろう。

「SOFT SKILLS ソフトウェア開発者の人生マニュアル」を読んだ

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

めっちゃいい本だった。

ソフトウェアエンジニアとして勝ち組になるためには〜みたいなことがひたすら書かれており、意識が高い。

面接、給料、資産運用、健康などとソフトウェアとは関係ないことも多く、確かに人生マニュアルだった。
1年に1回読み直したい。

特に強く心に残ったことが2つあった。

バカにされるのを恐るな

何かをやろうと思うとき、バカにされるのが怖くて一歩を踏み出せないことがある。
例えば勉強会に登壇して失敗したらどうしようとか、記事を公開した時に内容を間違えていたらどうしようか、などである。 しかし勉強会で上手く話せなかった人のことをあなたは覚えているだろうか、そんなことは誰も気にしないし過ちにも気がつけるのだから勇気を出しなさい、と書かれていた。

また、失敗は敗北ではないのでどんどん失敗し学んでいけとあり、自分は割と失敗を怖がり安全に走るので心にクる内容だった。

本を読み終わりとりあえず勉強会の登壇ボタンをポチッと押した。

ポモドーロ

生産性を高めるためにポモドーロが良いと書いてあり、実際にやってみたらめちゃくちゃ進捗出てすごい。
25分仕事して5分休む、というのは前にもやってみたけど全然効果がなかったけど、「ちゃんとその日やるタスクを決めてからそれを25分以内に1つ消化できるように全力を出す」ようにしたらめっちゃ効果が出て、ちゃんとタスクを決めるのが重要なんだなと思った。

また、ポモドーロやっていると、誰かから話しかけられた時にタイマーを指差して「その話めっちゃ緊急ですか?10分後でもいいですか?」とできるので良い。(向こうは面倒だと思うだろうけど…)

Deep Work にも、毎週・毎朝のスケジュールを決めて時間を意識し仕事をすると進捗が出るなどと書いてあって、本当にその通りだった。

KanbanFlow というサービスがあって、これはタイマーとタスクリストを連携させて、そのタスクがどれだけ時間かかったかなどの分析も丸っとできて良い。

kanbanflow.com


以下 wikihub 日報 で雑に書いてた感想のまとめ。


読み始めた、17%くらい。読み応えがある。
耳が痛いことがめちゃくちゃ書かれている。この本は毎年読み返した方が良い気がする。

特に

自分の仕事はコードを書くことだと思っているなら、考え直すべきだ。…他のあらゆる職種と同様、人と接することである。

がだいぶ心にきた。 :sweat:

以下雑なメモ:

  • あなたはソフトウェア開発の事業主であり、雇用主は顧客である
  • キャリアの目標を決めよ、そして今からその目標に対する月、週、日単位での目標を立てよ
    • ぐぅ、ハードだ…
  • あなたの仕事はコードを書くことではなく人と接すること
  • 悪い行動を懲らしめるのでなくいい行動を褒めよ
    • チームとして〜に出てきた失敗を許容しろって話だ
  • 社交術を学ぶことから得た利益はは一生モノであり、値段をつけられないほどの価値がある
  • 面接する前に相手の会社のブログ読んでマサカリ投げとけ
  • 面接では、能力の高さよりも「頼まれなくても仕事を終わらせるタイプの開発者」と強調しろ
  • まず専門性を特化させ、それから多才になれ
  • ソフトウェア開発で食べている会社は、雇っているソフトウェア開発者に高い価値を置いていることが多い
    • 弊社〜 :innocent:
  • 他の人が嫌がる仕事をすると信頼上がって出世や!
  • プロであれ
    • 自分が正しいとわかっていることのために、難しい選択をあえてすることを厭わない
    • めんどいしこの実装で妥協するか〜というのはプロではない
  • 他人のために働くときは一生懸命度合いが半分くらいになる
    • 独立すると自分のために働くので、その差を感じることになるらしい

5% くらい読み進めた。


32% くらいまできた。
自分の価値を高めよみたいな話で、有名な Podcast にでろとか言ってるけど、そもそも有名な Podcast に出る人は価値が高いんじゃないですかね?

  • 履歴書はプロに書いてもらうのもアリ
  • 自分が選んだテクノロジー以外にもいいものはたくさんあるから選択肢を制限するな
  • 自分をマーケティングするとは、あなたが提供できるものを、欲しいと思っている人と結びつけることに他ならない
  • 質の高いブログを毎週書け

ためになる。
自分をプロモーションするために SNS をうまく使え、カンファレンスで講演しろみたいな話が続く。
ひたすら意識が高い。

  • 自分がやってることの90%は無料で公開せよ(自分のプロモーションのため)
  • SNS で朝食に何を食べたみたいなツイートばっかりしてると人々は離れるから価値のあるツイートをせよ
    • :scream:
  • バカにされるのを恐るな、勉強会にでよ、ブログを書け、マサカリを恐るな
  • 独学
    • 基礎的な知識は何が必要か
    • テーマの幅: どれくらいの規模で、どんなことが可能か
    • 基礎: 20%の知識で日常の80%をカバーするにはどうしたら良いのかを知る
  • 基礎的な理解を得て、その上で何を学習するかの範囲と成功のイメージを定義する

55%まできた。
理解を深める一番の方法は人に教えること、というのが強調されている。
また、生産性の章では Deep Work に書いてあるのとほぼ同じことが書かれている。

本の前半で「あなたの仕事はコードを書くことではなく人間とコミュニケーションを取ること」と書いてあったが、この章では「オフィスのドアの前に'話しかけるな!'と書いた札を置いておけ」と書かれてて、ハア〜どっちなんじゃいという感じだ。

  • 何かを学び始める前に全体概要を把握しておけ
  • 何かを学び終えたと証明できる目標を立てろ、その目標はできる限りスコープを絞れ
    • C# で website 作るぞ、みたいな目標
  • 1冊の本だけでなく多くの異なる本を集めよ
    • 5冊の目次を見比べると重要なことが見えたりする
  • 学習-実践-学習-教え(LDLT方式)
  • メンターは経験をあなたに伝授してくれる重要な存在
    • メンター欲しい〜〜〜〜 :sob:
  • メンターいない人は本を仮装メンターとする
  • あなた自身もメンターになれ、難しそうだけど他者より1歩前に進んでいるだけで良い
  • しかし弟子は選べ、ぶたに真珠を投げてはならない
  • 学位はあって損はない、ない人は資格を取ろう
  • なんかよくわからんけどそのままにしていることは都度メモっていけ、早めに理解した方が今後のためになる
  • チャットは完全な時間の無駄。メールの方が割り込みがないので良い
  • ポモドーロやる時は進捗を計測し分析しろ
  • 毎月、毎週、毎日何をやるのか予定を立てよ。
    • Deep Work で読んだわ…
  • 毎週ブログを1回は更新すること、本を1冊読むことみたいにキメを作ると習慣化される
  • シャローワークはバッチ処理として1日にまとめてやろう

75%くらい。めっちゃためになる。
「この本を読んでる君たちは特別だから勝ち組になろうや」みたいに書いてあって、読んでるだけで肯定感があって上手いな〜と感心してる。

  • 大きなタスクはやる気が出ないかもしれないが小さく分解しよう
    • プログラムだってメソッド分けるでしょ?
  • ハードワークは大変だ、つらい、けどやらないといけない
    • ハードワーク楽しいって口でいう人はいるけど本当に楽しいと思っている人はいない
  • やる気が出ない?いいからデスクに座ってやるしかねえんだごちゃごちゃいうな
  • 怖くて行動に移せない奴がいるが、行動に移さないことが一番怖いんだぞ
  • 給与交渉では先に金額を出すな、会社に言わせろ
  • 筆者もかなりの苦労をした結果金持ちになっているし、運が良かったのもある
    • でも幸運はある程度は自分で引き寄せるもの
  • 不動産投資はローリスクでリターンが見込めて最高

85%、明日読み終わる気がする。 筋肉は素晴らしい、体の健康は心も健康にするなどと書かれている。

私は胃下垂というやつで食べても太れない側の人間で、筋肉をつける前にまず一般的な体型になりたい…。 BMI は17.5とかで異常値であり、大変厳しい。まず病院に行こうと思う。

  • 食事を変えてエクササイズすることで体と頭どっちもよくなる
  • 腹筋割れてるやつは脂肪なさすぎて死ぬやつだからそれを目標にするな
  • トレーニングはつらいが結局最後は根性で歯を食いしばってやるしかない
  • 思考を制御し考えたことを具現化せよ
  • 意志が体を動かす

読み終わった。
いい本過ぎた、感化されたので勉強会に登壇するボタンを押し、病院に予約を入れた。

失敗は良いことだしどんどん失敗しろ、怖いかもしれないが失敗は敗北ではない!とあり、なるほどという感じがある。

  • マイナス思考は実際によくないことにつながる
  • プラス思考は現実を変えるパワーがある
  • プラス思考は、悪いことではなくいいことを考えることを選ぶこと
  • 瞑想はいいぞ
  • 結局正しく実行するためには時間と忍耐が必要である
  • 失敗を喜び、期待し、受け入れ、正面からぶつかることを学ぼう

「軽量・高速モバイルデータベース Realm入門」を読んだ

軽量・高速モバイルデータベースRealm入門

軽量・高速モバイルデータベースRealm入門

Realm は個人開発でそこそこ使っててそれなりに理解しているけど、雰囲気でしか理解してない気がしていたのでちゃんと理解しようと思って読み始めた。

内容的には基礎 + 応用という感じで上級者向けという感じではない。

私は基礎がガバガバだったので、Part2 の基礎編を読むだけで今まで知らなかったことや間違いに気がつけたりしたので大変良かった。
(今まで List クラスを使っておらず、LinkingObject を乱用していたのだが多分使い方が間違っていることに気がついてしまった。)

特に良かったのが Part3 の活用編で、暗号化とか keychain とか Apple に申請するときとか、細かいけどこれを知るのには結構な経験が必要そうなのがまとめられててめっちゃためになった。

Part4 の Twitter クライアントを作る編もためになるのだが、本だけで文字を追うのが辛すぎて流し読みした。多分これはコードを Xcode で開いてちゃんと読みながらやった方が良い。
サーバサイドAPI -> Realm -> UI という流れを経ることで UI は Realm のデータだけを見ればよく、 Realm の Notification で UI も更新できるので、データの流れが綺麗でめっちゃよさそう。

内容はとても良かったのだが、1つどうしても許せない点があって、説明文とサンプルコードが読み手の想像した位置と違うのが大変つらい。
リスト10.3 のサンプルコードを参照、と書いてあるのにその下にリスト10.2のサンプルコードが載っていていて、リスト10.3は隣のページの右下にあったりする。
ページの都合なのかも知れないが、読んでるときめっちゃ混乱したしかなりイライラした。

とはいえ内容は良いし、Realm これからやる人はもちろん、 Realm それなりに理解している人なら2時間くらいでザーッっと読めるのでとりあえず読んでみるといいと思う。
Qiita などに落ちている記事よりずっとためになり、今後のリファレンスになります。

以下個人的な雑メモ:
  • String,Date, Data をオプショナル型で定義するには dynamic var を使用するが Bool, Int などの数値は RealmOptional を使う
    • これは RealmSwift 内部で ObjC の機能を使っているための技術的問題による制約
  • 一対多は List を使う
  • 逆方向の関連に LinkingObject を使う
  • 検索には indexedProperties メソッドをオーバライドする
  • マネージドオブジェクト/アンマネージドオブジェクト
    • 保存したやつをマネージド、保存前をアンマネージドと呼ぶ
  • Xcodeデバッグ
    • lldb で po object する
  • 異なる Realm に同じ object を追加できる
    • add じゃダメ、 create でやる
  • 暗号化キー
    • 文字列で持っていると ipa 解析される恐れがある
    • 動的に生成し keychain に保存するのがいいが、 keychain が消えたら復元できない
    • ローカルに貯めとくデータは最悪見られても良いものにしておこう

potatotips #39 で fastlane android について話した

potatotips.connpass.com

最近業務で android も fastlane に乗せたので、 android 枠で話した。
fastlane android 良いと思う、継続的デリバるためのやつだからダメになったら捨てればいい、という軽い気持ちでいけるし。

発表では、たぶん自分はせわしなく話していて、他の人の発表見て「みんな落ち着いててすごいな〜」って思って見てた。
次話すときは資料の枚数もっと減らしてもっとゆっくり話すようにしてみようと思う。

「遅読家のための読書術」を読んだ

遅読家のための読書術

遅読家のための読書術

自分は本を読むのが遅く、さらに理解度が低いというつらい感じなので、そこらへんをなんとかしたいと思ってこの本を手にとってみた。

「本を読むのが遅い人は無駄に頑張って読みすぎなので、音楽を聴くようにもっと気軽に本を読んで、1行でも心に残る文章があったらそれで良いんだぞ」みたいな内容だった。あと見出しで判断して違うと思ったら読まなくて良いんだぞ、とか。

無駄に頑張って本を読みすぎというのは心当たりがあるのだが、見出しレベルで判断するというのはする気になれない…それが遅読の原因なのかもしれないが。

言っていることはわかるのだが、あなたはそう考える人なんですね、という感じで自分にはあまりためにならない本だった。

というかそもそもこの本は内容が薄く、1/3くらいでかける内容を冗長に書いている感じがして、遅読家向けの本なのに内容が薄く長いというのはどうなんだ。
遅読の人が読むんだからもっとページ数少なくするべきでは。わざと冗長に書くことで読み飛ばすことを実践させるという高度な内容になっているのかもしれない、などと思いながら読んでいた。

本を読んだ後に「もっとも素晴らしいと思った引用を1つだけ選ぶようにしよう」とあったので、1つだけ引用する。

「なにか」が頭の片隅に残っているのだとすれば、少なくともその部分が自分にとって必要だということ。
その本から得られる価値の全てはまさにそこにあり、1冊を読み通したことの意味は、その一節に出会えたことにある

以下雑なまとめ。


  • 本はそんなに真剣に読むな、音楽聴くみたいに雑に流せ
    • フローリーディング
  • 1冊に1フレーズでも心に残るものに出会えればいい
  • 100%を得ようとするな価値を感じられる1%と出会え
  • 引用することでその本のどこに心を動かされたか可視化される
  • もっとも素晴らしいと思った引用を1つ選ぶ
  • 12冊ごとに振り返りをし、その中からベストの1冊を選ぶ
  • 小見出しをみて読むべきパートか判断する
  • 自分語りは読み飛ばせ、まとめだけ読めばいい
    • この本かなり自分語りあったな?
  • 本を気軽に読み始められないのは、その本から何を得たいかがはっきりしていないからでは?
  • マーカー引くのは良くない
  • 電子書籍より紙の方が良い(筆者の意見

「プログラムはなぜ動くのか」を読んだ

プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識

プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識

プログラムを書き始めて5年ほど経つが、今までずっと「何かアプリケーションを作る」という目的のためだけにソフトウェアを作ってきて、それゆえに低レイヤで何が起きているのか全然知らなかった。
プログラムを書くのにコンパイラが何をしているのかわからんのもよくないので、そこらへんを知りたくて読み始めた。

CPU から2進数、メモリ、コンパイラ、OS、アセンブラと今まで避けてきたことが色々書いてあった。

特にコンパイラアセンブラの章がよかった。
コンパイラは色々ゴニョゴニョっとライブラリ入れたりスタティックライブラリ使ったりとかしてやっと exe ファイルができるらしい。
アセンブリ言語も mov とかでチョチョっと書ける、逆アセンブルというのはマシン語アセンブリ言語に逆変換することだったのか、それすら知らなかった。

2進数とかってどうなんだろうか、どの程度まで理解していた方が良いのだろうか。あの 1001010101 みたいな数字が苦手で、 2進数を10進数に計算するのもろくにできない。
でもそれで困ったことがないと感じてて、それは私のレベルが低いから困ったことがないだけで他の人は2進数の理解によりメリットを感じているのだろうか。

本の内容としてはためになったけど、この本を読む前とあとで自分の書くコードは変わらないのかな、とも思う。
コンパイラを理解しているとデバッグがしやすいとか書いてあったけど、果たして iOS の Swift などでそれが役に立つことがあるのだろうか…。
自分の理解度が低いのか、時代に即していないのか、果たして。

とはいえ、ためになるいい本でした、終わり。

以下 wikihub 日報 のまとめ。


読み始めた。いつだかに買ったけど積んでたやつ。 ソフトウェアは書けるけどなぜ動くかわかっていないのでためになる気がする。 1章読んだけど全然わからんかった、パソコンは難しい。

  • レジスタ
    • 命令やデータを格納する領域でメモリみたいなもんらしい
  • 制御装置
    • メモリ上の命令やデータをレジスタに読み出し、命令の実行結果に応じてコンピュータを制御するらしい
  • 演算装置
    • メモリからレジスタに読み出されたデータを演算するらしい
  • クロック
    • CPU が動作するタイミングとなるクロック信号を発生させるもんらしい
    • クロックは大きければ大きいほど CPU は早い
  • みなさんが書いたコードがマシン語となり CPU の内部でレジスタを使った処理結果になるらしい
  • コール命令やリターン命令で関数を実行したりするらしい
  • この本を読むと今まで何気なく書いていたプログラムがこれからは生きたものに見えてくるようになるとのこと

備忘録として書いてたらめっちゃ長くなった。

2章 データを2進数でイメージしよう

2進数めっちゃ苦手だ。というか知らなくてもプログラム書けないですか?

  • ビット
    • 2進数の1桁に相当する
  • バイト
    • 8桁の2進数
  • 基数
    • 数の数え方、10進数は10を基数、2進数は2が基数
  • シフト演算
    • 2進数で表された数値の桁を左右にシフトする
    • シフト演算や論理演算の仕組みをイメージできることは 必ず 身につけておかなければならないこと
      • まじ?
  • 符号ビット
    • 0の場合はプラスで1はマイナス
  • 補数
    • プラスの値でマイナスの値を表す
    • 「反転して +`1」で補数を求める
  • 論理右シフト
    • シフト後の上位桁に0を入れる
  • 算術右シフト
    • シフト前の符号ビットの値を入れる?
  • 符号拡張
    • 例えば8桁の2進数を、値を変えずに16桁や32桁の2進数に変換すること
  • 算術演算
  • 論理演算
    • NOT,AND,OR,XOR など
  • 真理値表
    • 2進数の0がfalseで1がtrue

3章 コンピュータが少数点数の計算を間違える理由

計算とかだいたい Math.floor とかしちゃうから気にならないくないですか?

  • 0.1 を 100 回加えても10にならない
  • 10進数の小数点の中には、2進数に変換できないものがある
  • 正確に表せない数は近似値になってしまう
  • 倍精度浮動小数点型
    • 64 bit の double
  • 短精度浮動小数点型
    • 32 bit の float
  • 浮動小数点では、少数点数を「符号」「仮数」「基数」「指数」の4つに分ける
  • 符号部
    • 1bit を使って数値の符号を表す、0は負で1は正
  • 仮数
    • 様々な形式で表せる浮動小数点型を糖質的な表現にする
  • 指数部
    • イクセス表現を使う。
    • 中央の値をゼロと見做すことでマイナスの値を表す工夫、トランプでいうと7を中心とし6以下はマイナスみたいな

4章 四角いメモリーを丸く使う

メモリに関しての内容。
C言語も書いたことないしポインタとか概念としてしか理解してない。

  • 制御信号
    • WR(write), RD(read) のように IC に動作を行わせる信号
  • メモリの物理的な仕組み
    • モリーIC の内部に8ビットデータを格納できる入れ物がたくさんあり、その場所をアドレスで指定してデータの読み書きを行うだけ
  • データ型
    • どのような種類のデータを格納するか示すもので、メモリからすると占有するサイズを意味するもの
  • 変数を使うことで物理アドレスを指定しなくてもプログラムでメモリの読み書きが可能
  • ポインタ
    • データの値そのものでなく、データが格納されているメモリーのアドレスを持つ変数
    • 参照型って理解でいいのかな?
  • 配列
    • 同じデータ型の複数のデータがメモリ内に連続して並んだもの
  • スタック/キュー
    • どちらもアドレスやインデックスを指定せずに配列の要素を読み書きできるもの
  • スタック
    • LIFO = Last In First Out
  • キュー
    • FIFO = First In First Out
  • リスト
    • データの値だけでなく、次の要素のインデックスも付加できる
    • リストでない配列を使うと、途中の要素を消した時に後ろの要素を全て移動しないといけない

ためになる!

5章 メモリーとディスクの親密な関係

メモリとディスク(HDDとかフロッピーとか)について。

  • ストアド・プログラム方式
    • プログラムが記憶装置に格納されていて順次読み出されて実行される仕組み
    • この方式の前はコンピュータの配線を変えてプログラムを変更してていたらしい
  • ディスクキャッシュ
    • 一度ディスクから読み出されたデータを保存しておくメモリ内領域
  • 仮想記憶
    • ディスクの一部を仮想敵にメモリとして使うもの
    • 物理メモリと仮想メモリスワップしながらプログラムを実行する
  • ページング方式
    • 実行されるプログラムを構造に関係なく一定の「ページ」の大きさに分割する
    • ページイン、ページアウトとかいう
  • ページングファイル
    • 仮想記憶を実現するためにデゥスク状に仮想メモリとなるファイルをおく
  • スタティックリンク
    • アプリケーションの実行ファイルの中に関数を埋め込むこと
    • これをやると同じコードが複数アプリケーションに存在することになり微妙っぽい
  • スタックのクリーンアップ処理
    • 関数の引数を受け渡すために使われるメモリ状のスタック領域から不要となったデータを削除すること
    • 関数の前に _stdcall をおく
  • ディスク
  • セクター方式
    • 固定長の領域に区切る
    • ディスクの表面を同心円状に区切った領域をトラックと呼び、それを固定長サイズに区切った領域をセクターと呼ぶ
    • 複数のファイルを1つのクラスタに格納はできない、両方削除されちゃう
  • バリアブル方式
    • 可変長の領域に区切る

6章 自分でデータを圧縮してみよう

zip とかの仕組みが書いてあって面白い。

  • ランレングス法
    • ファイルの内容をデータ*繰り返し回数で表すことで圧縮する方法
    • 同じデータが続いている場合が多い画像ファイルなどでは有効打が文書ファイルではあまり…
  • ハフマン法
    • よく使われるデータを判別して、それを小さいbit数で表す
    • ハフマン木とか使う
  • BMP
    • bitmap は圧縮していないやつ
  • 可逆圧縮
    • 元に戻せる、zipとか
  • 非可逆圧縮
    • 元に戻せない、jpeg とか

7章 プログラムはどんな環境で動くのか

戦うプログラマーでいろんな環境で動くように作るみたいな話をしていたやつだった。

  • ネイティブコード
  • ソースコード
    • テキストファイルで書かれたやつ
  • アプリケーションの機能の中に、ハードウェアを直で触るところがあると汎用プログラムにならない
  • API
    • Application Programming Inteface
  • Ports
  • Java
  • JVM
  • BIOS
    • ROM に記憶され、キーボードとかの基本制御プログラムやブートストラップ・ローダーをもつ
  • ブーとストラップ・ローダー
    • 起動ドライブの先頭領域に記憶された小さなプログラム
    • OS はブーとストラップ・ローダーによって起動する

8章 ソース・ファイルから実行可能ファイルができるまで

コンパイラとかのはなし。
知らないことばっかりだ。

  • ダンプ
    • ファイルの内容を1バイトずつ2桁の16進数で表示すること
  • ロスコンパイラ
    • 動作環境で使われる CPU とは異なる CPU 用のマシン語を生成
  • オブジェクトファイル
    • コンパイルした後に生成される .obj 形式のファイル
    • まだ exe ファイルではない
    • printf() など実行する場合は必要な処理内容が格納された状態に結合しないといけない
  • リンク
    • 複数のオブジェクトファイルを結合して1つのexeファイルを作る処理
    • リンクを行うプログラムのことをリンカーという
  • スタートアップ
    • 全てのプログラムの先頭に結合する共通的な処理が書かれたオブジェクトファイル
  • ライブラリファイル
    • 複数オブジェクトファイルをまとめて1つのファオルに格納したもの
  • 外部シンボル
    • 他のオブジェクトファイルの中にある変数や関数
    • printf() とか
  • 標準関数
    • ライブラリファイルの形式でコンパイラと一緒に提供される
  • DLL
    • Dynamic Link Library、プログラムの実行時に結合されるもの
  • インポートライブラリ
    • 外部にあるライブラリファイル
  • スタティックリンクライブラリ
    • exe ファイルに直接結合するライブラリファイル
  • 再配置情報
    • 実行時にメモリを仮想敵に与えてうまく動くようにするやつ
  • スタック
    • 関数の内部で一時的に使用される変数などのメモリ領域
    • 自動でメモリを確保し自動で解放
  • ヒープ
    • プログラムの実行時に任意のデータやオブジェクトを格納するためのメモリ領域
    • 自分でメモリを解放する

コンパイラはこんな感じの処理になるっぽい。

ソースファイル
-> .obj + タートアップ + スタティックリンクライブラリ + インポートライブラリ
-> スタティックリンク + ダイナミックリンクライブラリ
-> exe


読み終わった。

9章 OS とアプリケーションの関係

  • モニター・プログラム
    • プログラムをロード・実行する機能だけを備えるやつ
  • OS 上で動くアプリはハードウェアを OS を介し間接的にアクセスする
  • システムコール
    • OS の関数とかを呼び出す行為
  • 時分割
    • 短い時間間各区で複数のプログラムを切り替えながら実行する
  • マルチスレッド
    • 関数の単位で時分割を行う
  • ミドルウェア
    • ネットワークやデータベース機能のような、OSには不可欠でないがOSに近い存在のこと
  • システム・ソフトウェア
  • フラグ&プレイ
    • 新しいデバイスをすぐに使えるようにする仕組み
  • バイス・ドライバ
    • 新しいデバイスを接続した時にそれを制御するプログラム

10章 アセンブリ言語からプログラムの本当の姿を知る

この本で一番ためになる章だったと思う。
コードがコンパイルされ、それがどうコンピュータに読まれるかみたいなのを順を追って解説してくれる。

11章 ハードウェアを制御する方法

  • システムコールを使いアプリケーションからハードウェアを制御する
  • IN命令
    • 指定したポート番号のポートからデータを入手する
  • OUT命令
    • CPU のレジスタに格納されているデータを指定しポート番号のポートに出力
  • I/Oコントローラ
    • コンピュータ本体と周辺装置をいい感じに繋ぐやつ?
  • ポート
    • 入出力されるデータを一時的に格納しておくための一種のメモリ
    • えっポートってメモリなの、マジで
    • ポートって行っても https:443 みたいなポートとか USB ポートとか色々あるし何がどれなんだ
  • ポート番号
    • I/Oアドレスとも呼ぶ。ポートを区別するやつ。
  • IRQ
    • Interrupt Request, 割り込み要求
  • 割り込み処理
    • 現在実行中のプログラムを一旦止めて他のを実行する
    • 割り込み番号が振られる
    • 割り込みコントローラが間にいる
  • ポーリング
    • 複数の周辺装置の状態を順番に調べること。パソコンには不向き
  • DMA
    • CPU を仲介せずに周辺装置が直接コンピュータのメインメモリとデータ転送をおこなう
    • DMAチャネル
  • I/Oポート番号、IRQ、DMAチャネルは周辺装置を識別するための3点セット
  • VRAM
    • ディスプレイに表示される情報を記憶するメモリ

12章 コンピュータに「考え」させるためには

プログラムに人間の傾向とかを学ばせるみたいな話。
ディープラーニングみたいに深い話ではなく、人間がグーを出した後はパーを出しやすいとかを覚えるとかの話。

  • 擬似乱数
    • 数式によって得られる乱数、本当の乱数とは言えない

「リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす」を読んだ

個人でアプリを開発するときによく思うのが「とりあえずまずリリースしてみる」というのが大事だと思っていた。
MVP とかいったりするし、そこらへんちゃんと理解したいという思いで読み始めた。

実際に読んで見ると「とりあえずまずリリースしてみる」というのは正しくなくて、「検証可能な仮説が正しいのか検証するための最速の一手を打つ」みたいなのが大事。
最速の一手というのはスケールしない方法という意味で、例えば洗濯をするサービスを作ろうと思ったとき「本当にそのサービスは必要なのか?」を検証するために、街中の人に1000円で洗濯するけどどう?って話して実際に CEO が洗濯する、というのを通して開発する意味があるのか検証しよう、という感じである。

昨今のサービスは、企画があってすぐに開発に移るけどそれはよくなくて、本当にその企画が正しいのか?というのを理解してからやったほうが良さそう。 そういう意味での Minimum Value Product を作っていこう、というのが印象に残った。

検証するときにはちゃんとそこから学習して、次は良い結果になるように企画を変えるのはもちろん次の検証はもっと早く実施できるようにしよう、とかもよかった。

以下 Twitter に投げた感想。