エンジニアの知的生産術読書メモ
読んでたけどメモほっぽりっぱなしだったので放出。エンジニアなら大なり小なりやっていることを、明確に言語化せしめたのは素晴らしいことだと思う。間違いなくエンジニアに限らない、誰でもためになる良書。なにかに取り組む前にさっと目を通して備えられるように、自分の中に積みあげておきたく感じる。
学び
- やる気の維持
- 小さいゴール
- 良い参考書を選ぶコツ
- 大学の講義の参考図書に選定されている
- 正誤表が充実
- 改定されたロングセラーである
- 学習のサイクル
- 情報収集→モデル化→検証
- 情報収集
- 知りたいと思うところから学ぶ
- ソースコードの読み方 by Matz
- 全体を読もうとしない
- 目的を持って読む
- 達成可能な目標。明示的な目標を掲げる
- 大雑把に全体を把握する
- 写経が再び必要になるとき
- 写経の必要もなくすんなり理解できたとおもったのなら、それはすでに学んだことで構成されていて、新しいことを学べていないということ
- どうやって抽象化するか
- 比較する。同じ箇所と違う箇所の間を見る
- 例える。どこが同じでどこが違うのかを明確にする
- 違いに注目する
- 歴史から学ぶ。以前と以後で何が変わったか
- すでに抽象化されたパターンから学ぶ。ただし、自分の言葉で、自分の経験として、自分の目的に使えるか？
やる気
- やる気がでないのは、やることを絞れていないせいである
- 絞るためにはまず全体像を把握する
- 優先順位付け自体が難しい
- タスクが大きすぎる
- タイムボックス
- ポモドーロテクニック
記憶
- アウトプットで記憶が鍛えられる
- 覚えている自信がなくてもテストを繰り返すと成績は高くなる
- 忘れてから復習するのは長期の記憶に役立つ
- ライトナーシステム
- supermemo
- 間隔反復法
- 知識を構造化する２０のルール
読書
- 「読んでない本」は、先に概要を調べる・読んだ人に聞くなどして、読むべきかどうかの判断ができる
- Whole Mind System
- プレビューする。
- ５分ほどで目次やキーワードについて把握する。
- 質問を作るためによむ。
- ○○せよと書いてあるが、これは具体的にどういう行動か？
- 答えを探すために読む
- マインドマップでメモする
- プレビューする。
- フォーカス・リーディング
- 読む速度をコントロールすることで理解度を測る
- どちらも見出しに注目する
- 難解な本を読む技術
- 本棚を見て分野の全体像をスケッチする
- 読書ノートを作る
- わからないことを記録する
- 何度も出現する単語を記録する
- 概念や理由の関係性を矢印でつなぐ
- わからないことを解消するために読む
- 読むという行為の目的はなにか
- 必要なときに読み返せるように頭の中に地図を作る
- 本の内容とそのほかの知識を結びつけるために読む。Syntopic Reading
- 概念の名前を知ることで思考の道具を手に入れる
- 復習のためのメモを作る
- レバレッジメモ
- Incremental Reading
思考
- 書き出し法
- テーマに対して書き出す
- 質ではなく量
- 重複も気にしない
- 情報をまとめる
- KJ法
- ふせんに書き出し並べて一覧性を上げる
- 関係ありそうなものをまとめる。
- グループ化して表札をつける
- 分類できないと思ったときは分類の基準が間違っている。
- 既存の分類を使うのではない
- 階層は作らない
- 短縮化
- 表札は作らずとも良い
- 中断可能であるように工夫する。ふせんをはるのはA4用紙にするなど
- 表札は作らずとも良い
ひらめき
- ３つのフェーズ
- 耕す
- 芽生える
- 育てる
- 「アイデアのつくりかた」ジェームズ・W・ヤング
- 資料集め
- 資料の加工
- 努力の放棄
- アイデアの誕生
- 「発想方」川喜田二郎
- 情報を収集する
- 言語化を促す
- 言葉になっていないもの
- 磨き上げる
- 最小限の実現可能な製品
- 他人の視線
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2018/08/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
2018年を振り返って
前年度たてた目標
コードリーディングする
Django
Goole App Engine SDK
自社製品のコード
周辺環境やライブラリについて調べる癖をつける
アップデートしたりメンテナンスしたりできるようになる
漫画を書く
例大祭と冬コミ
目標を達したか
所感
漫画しか書いてねえなこいつ…（１年ぶり二度目
プログラミングができなくて困っているのだが、できるようになる道筋はもはや見えない。なんでプログラマになったのか。なのでプログラマ以外の職業へと転職を考えてはいるのだが年齢がいきすぎてもはや機会を逸している。苦痛なプログラミングといかに向き合っていくのかということを考えていかなければならない。
１０年やってプログラミングが身につかなかったという事実から自分の才能をすでに見限っているのだが、ことWebに関して言えばまだ触れ始めて５年であるともいえる。できる人は半年もすれば全てを掴んでしまうのであるが、そこは凡人以下の私であるので天才の 1000倍時間がかかったとしても驚きはない。
という風に将来を悲観しているのだが、仕事で完全新規のAndroidアプリを一人で作ったりしていた。そういうのはできるようだ。もしかしてWebよりもネイティブモバイルのほうが性に合っていたかとかそういう話なのだろうか？
ならWebやめてモバイルやるかーと思ったが、これも年齢のせいで転職はできない。作れるだけなら若い人間でいいわけで、プラスアルファーが必要という話である。とはいえアプリ作るの意外と嫌でなかったので勝手に勉強するのはやぶさかではない。
これはそういう勉強のやり方ばっかりやってたのでそうなったのだと思う。つまり新しい技術のプロトをさっと作るという方面には可能性があるようだ。ただこれ正社員ポジションでやることじゃないんだよな…。
そうはいっても今いるのはWebの会社なので。Webの中でやれるようなことを探していく必要があるのだが、技術側は諦めて人間寄りの方を模索するのも１つだなと気づいた。好きじゃないけど。私は好きと得意がかけ離れるタイプの人間のようなのでおそらくやってやれないことはないのだろう。
組織寄りプロダクト寄りビジネス寄り、技術を理解できる人間がそっち方面で果たせる役割というのを探ってみたいと思う。
漫画描き。好きではないがわりかしこなせるというだけでプログラミングをやっているので大変なストレスと苦痛と共に過ごしている。そこでストレス解消のために全然別のクリエイティング行為であるところの漫画がハマったのではないだろうか。まんがかくのたのしいかみえしになりたい
来年の目標
kotlin fest 2018に行ってきた話
最近Androidアプリをkotlinで書こうとしています。ちょうどkotlin fesがあったので行ってきました。 スライド公開されているのでだいたいこの辺から見ることができます。
「Kotlinアプリのリファクタリングポイント」と「Kotlin コルーチンを理解しよう」あたりが私に良かったなぁという気がします。 実際kotlinでモバイルやろうとすると、それはAndroidの仕組みの話なの？Javaの話なの？kotlinの話なの？みたいのが混ざってしまいさっぱりわからなくなってしまいがちです。
結局Javaなので詰まったらJavaまで降りていかないと行けないみたいなときもあるっぽいので、絶対に降りないように凝ったことするくらいならその仕様にNoを突きつけるくらいでいきたいですね。大変な思いをするためにプログラミングをやっているわけではないのでツラさを押し付けてくるなら殴り飛ばしてやるからなまじでおまえまじでこの野郎おまえ
あとyahooブースでモブプログラミングとか初めて見ましたけど。昔ペアプロもそんなうまくやれなかったし。ほんとに効果あるんでござるかぁ？みたいな気持ちでいます。ああいうの合うタイプと合わないタイプがあるんですかね。ペアプロとかモブプロって優秀な人がさらに加速するための装置であって、普通の人が普通のことをやるには向いてない気がします。でもOvserber.delegate()でしたっけ？は初めて知ったのでありがとうございます。
あとwebDB pressの特集でkotlinがきたり、kotlin盛り上がってますねー
Androidアプリを手動で別の端末にインストールする
Androidアプリを手動で別の端末にインストールする。 OculusGoのVRビュワーが使いにくいので一番使いやすいと思ったやつをOculusGoで動かせるか試したりしたので覚書。ちなみに動きませんでした。ですよねー
$ adb devices List of devices attached XXXXX17510009999 device $ adb shell pm path se.chai.vrtv.free package:/data/app/se.chai.vrtv.free-1/base.apk $ adb shell cp /data/app/se.chai.vrtv.free-1/base.apk /storage/emulated/0/Download $ sudo adb pull /storage/emulated/0/Download/base.apk /storage/emulated/0/Download/base.apk: 1 file pulled. 23.4 MB/s (15921479 bytes in 0.650s) $ adb devices List of devices attached XXXXX8177 device $ adb install base.apk Success
Linuxのしくみを呼んで
Linuxのしくみの読書メモ。ていうかこれほぼ目次だ
- ユーザーモード/カーネルモード
- プロセス管理
- fork()
- execve()
- プロセススケジューラー
- コンテキスト
- 状態と状態遷移
- スループットとレイテンシ
- 経過時間と仕様時間
- メモリ管理
- 割当
- 仮想記憶
- ページテーブル
- ファイルマップ
- デマンドページング
- スワップ
- ページテーブル
- ヒュージページ
- 記憶階層
- キャッシュメモリ
- 局所性
- ページキャッシュ
- バッファキャッシュ
- ファイルシステム
- ストレージデバイス
- HDDのしくみ
- シーケンシャルアクセス
- ランダムアクセス
- ブロックデバイス
- スケジューラー
![[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識](https://images-fe.ssl-images-amazon.com/images/I/51r%2BeNsY2fL._SL160_.jpg "[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識")
[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識
- 作者: 武内覚
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/23
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
Inspired: 顧客の心を捉える製品の創り方 を読んで
Inspired: 顧客の心を捉える製品の創り方 の読書メモ。だいぶいい本だったのでおすすめ。実際に積んだ人間が、こうしたときはうまくいったよ。というのを教えてくれる。
ベストプラクティス
- プロダクトマネジメントの役割
- ユーザーエクスペリエンスの役割
- 製品の市場性評価
- ユーザーモニター制度
- 製品原則
- ペルソナ
- 製品のアイデアを見つけ出すことに集中得する
- プロトタイプの活用
- ターゲットユーザーとプロトタイプをテストする
- 改善するためにはデータを使う
プロダクトマネージャーの懸念事項リスト
- この製品は、ターゲット顧客の心に届いているだろうか
- 私達は、出来る限りのことをやり尽くしてこの製品を使いやすいものにしただろうか
- この製品は、競争に勝てるだろうか。今現在の競争ではなく、製品をリリースする時点での競争に勝てるだろうか。
- 私は、この製品を実際に買ってくれる顧客のことを理解してるだろうか。私が望んでいる製品ではなく、自分たちが作ろうとしている製品を買ってくれる顧客のことである。
- この製品は、本当に差別化できているだろうか。どう差別化できているかを、会社の経営陣には２分で、頭の良い顧客には１分で、業界アナリストには３０秒で説明できるだろうか
- この製品は、実際に動くだろうか
- この製品は、欠けているところがなくあるべき製品として全体となっているだろうか。顧客はどう思ってこの製品を買うだろうか。それは私達が計画した売り方と一致しているだろうか。
- この製品の強みは、顧客にとって大切なことと一致しているだろうか。私たちはその強みを積極的にアピールしているだろうか
- この製品にお金を払う価値はあるだろうか。それはいくらで、理由はどうか。顧客はこの製品に代わるものを他でもっと安く手に入れることができるだろうか
- 私は製品開発チームのメンバーがこの製品のどこが優れていると思っているかを理解しているだろうか。それは私の考えと一致しているだろうか
市場調査
- 現実にユーザーはだれなのかを理解しているか？
- ユーザーは製品をどんなふうに使っているのか？
- ユーザーは製品をどうやって使うかを理解できているか？ユーザーはどこでつまずくだろうか？
- なぜユーザーはこの製品を使うのか？
- ユーザーは製品のどこが気に一致得るのか？
- ユーザーは製品のどこが気に入っているか？
- ユーザーが製品にあればいいと思っていることや、変えてほしいと思っていることは何か？
製品仕様
- 仕様書には、ユーザーエクスペリエンスが全て記載されていなければならない
- 仕様書には、ソフトウェアの動作を正確に表現しなければならない
- 仕様書はそれぞれの立場にとって必要な内容が全部盛り込まればならない
- 仕様書はアップデートされなければならない
- 曖昧さ、混同を避けるため、マスターを１つ用意する必要がある
- これらを満たすのはハイファイプロタイプである。ハイファイとは提案されているユーザーエクスペリエンスを正確に再現することである
製品仕様の検証
- 実現可能性の検証
- 使いやすいかどうかの検証
- 買いたいと思ってもらえるかどうかの検証
製品における感情の役割
- 顧客に製品を買う気を起こさせる感情にどんなものがあるか
- 自分たちの製品以外には他のどこでその欲求を満足させることができるか
個人向け製品で大切なこと
企業向け製品で大切なこと
- 使いやすさ
- ちゃんと動くこと
- 特別仕様
- ユーザーモニター制度
- 顧客vsユーザー
- 製品のインストール
- 製品の設定・カスタマイズ
- 製品のアップデート
- 販売プロセス
- 作者: マーティケイガン
- 出版社/メーカー: 株式会社 マーレアッズーロ
- 発売日: 2015/02/07
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
2017年を振り返って
前年度たてた目標
コンピューターサイエンスを勉強する
特にアルゴリズム
新しいプログラミング言語について勉強する
たぶんelixirかGo
積極的にコードリーディングする
何かアプリかサービスとかを気軽に作る
漫画を書く
例大祭と夏コミと冬コミ
目標を達したか
所感
漫画しか書いてねえなこいつ？
とにかくプログラミングができなくて困っているのだが、できるようになるビジョンが見えないままプログラミング自体を嫌いになっている状況にある。学習行為に手がついていないのは、その極限にまで落ち込んだモチベーションのせいであろう。
プログラミングを初めて10年になるができるようになっているわけではなく、どうにも自分には向いていなかったようだ。とはいえ10年をつぎこんでしまったのでいまから別の業種に転換することも難しい。かなり厳しい状況におかれている状況に間違いない。
仕事においてもデキる人との差が顕著になってきており、なんとかしてほしい的なことを要請されている。ふふふ。。。それができたらとっくに私も圧倒的成長を遂げていたましたとも。
とりあえず色々なものを諦めて、基本からやり直したほうがいいのだろうと思っている。例えば、コードを読んだ絶対量がそもそも少ないのでは？持ってるコードの引き出しが少ないせいで書くときにも困るのでは？ということをボスに言われたりしたのだが、これは私が思っていることとだいたい同じで、おおよく見ていてくれるのだなと感慨深かったりした。コードだけからこういうのがわかるのは私のボスはやはり優秀な人物なのは間違いない。
というわけでコードリーディングをしてみようというのが１つ。コード書かない仕事にシフトしてもいいよということを提案されているのだが、それってコード書けること前提ですよね！？という感じがあるのでやっぱり基礎的なことをおさらいせんことにはどうにもならないだろう。ていうか自分の力にするためのコードリーディングってどうやればいいだろう…？ということがわからなかったのでやっぱり能力がそもそも足らないきがする。というわけでただわかるだけじゃなくて、自分の力にするためのコードリーディングのやり方ご存知でしたら教えてください。
あとは製品作るよりも、コードのメンテナンス、コードを描きやすい環境を整える的な方が、ゴールが明確なので取り組みやすくそっち方面にいってもいいかなと思い始めている。ライブラリのバージョン管理したりメンテナスしたり、既存のAPIに追随したりとか。そういう感じのやつ。
そんなふうに全く暗い話しかでてこないのだが、年いってから始めたお絵かきやら漫画やらは新刊3冊までこぎつけて多分逃避的な意味もあるのだろうが、とりあえず出せたのでよかった。ていうかここで技術ブログで漫画の話してもしょうがないのでさわりだけ。 書くのは結構大変で一ヶ月二ヶ月の可処分時間を全て捧げてやっと1冊という感じなので、春と冬だけとかそういう感じにしたい。漫画描きは趣味の1つとして今後も続けたい。
