元ネタSpeakerDeck
- 学び方を学ぶ
- 四半世紀毎に技術書を読む
- 手を動かして学ぶ
- 毎年少なくとも１つの言語を学ぶ
- 身の回りをプログラミング対象にする
- アウトプットを行う
- 現役プログラマでいるために
- おわりに
- 達人プログラマーの監修者
- 記憶期間の話
- 感覚記憶(0.5sec ~ 2sec)、短期記憶(15 ~ 30sec)、長期記憶(死ぬまで？)
- 脳内の雑然とした記憶を整理する
- ピッカーを育てる => 長期記憶化すべく出し入れしまくる
- 読んだ本でインデックスを作成 => 時系列で並べる等
-
正の循環のイメージ
- やる => できる => 好きになる => できる
-
技術書の写経の方法
- ローカルで使える SCM を用意
- ほんたったなどで技術書を固定
- ひたすらサンプルコードを写経
- 実行するたびにコミット
- コミットログにページ番号を含める
- 疑問点があったらコミットログや本に書き込む
- 章ごとにタグを打つ
-
備考：
このSpeakerdeckに何度か登場するデールの円錐。正式名称はエドガー・デールの「経験の円錐」という。
http://www.hi-ho.ne.jp/tgoto/medic3/1253.html
記憶に残る程度を動作とセットにして定着率（？）を数字で表した図形。
- 読むだけ 10%
- 効くだけ 20%
- 見るだけ 30%
- 見て聴く 50%
- 言う書く 70%
- 教える 90%
能動的でインタラクティブなほど効果が高い。
リンク先に書かれているとおり、この段階にはエビデンスは無く、デールの原著に％もない。 ただ、直感的な正しさは感じる。脳の構造的にも正の循環が起こってるわけだし。
- プログラミング言語は複数習得すべき
- パラダイムの違う言語を学ぶとアルゴリズム、イディオム、パターンの実装についても嫌でも考えるようになる
- アルゴリズム一つとっても実装方法には色んなやり方があることがわかる。
前提として、アルゴリズムに対してそれを表現する実装を行う。 同じ心理描写を別の言語（プログラム言語ではない方の言語）で行うことで、各国の表現方法を理解するのと同じかと。
なのでアルゴリズムを先ず理解しないと。
-
備考：
- パラダイム: ある時代や分野において支配的規範となる「物の見方や捉え方」のことです。
- アルゴリズム: 問題を解決するための手順や計算方法
- イディオム: 二、三の語が結びついて、原義とは幾分違った特殊な意味を持つ、習慣的な言いまわし。慣用語。成句。（Wikipedia）
-
言語だけではなく文化も学ぶ
- 達人プログラマでも勧めている１年に１言語は新たに習得しましょう、という話がある。
- t_wadaさんはこれを実践するなかで、言語の文法や構文などを学ぶのではなく背景の文化を学ぶという重要な教訓を得た
-
TechnologyRader
- ページ内のスクショはここのもの。
ここで何を話されていたのかわからないが、上記は世にある言語を体系的にならべ紹介しているっぽい。
- 技術者と英語
- 英語ができるようになることは「大きな図書館の鍵」を渡されたようなもの。
特に独学で何かを勧めていると解決策がStackoverflowにかかれているなんてことがほとんど。 これで英語を読む力を鍛えられたところはある。英語、ちゃんとやっておくと問題解決速度が爆上がりするし情報を正確に拾うことができるようになる。
- プログラマ向け本の監修者はどうあるべきか
- プログラマらしく
- 怠惰、傲慢、短期
- プレーンテキストを好む
- 全てをバージョン管理する
- 全てを自動化する
- 変化を内包する
- 原稿は markdown 形式
- 原文はスクレイピングして取得
- git を使いバージョン管理
- heroku に push してサイトに反映
- 監修差分は docdiff で表示
- プログラマらしく
監修ってどうやったら回ってくるんだろ。 文章を発信し続け、それが信用に値する内容であると評価を積み重ね、業界外（IT外の出版社とか）の目に止まり、それが初めてオファーの要因になる、みたいな感じかな。
- 何かをマスターしたいなら、それを教えろ => twitter
- 正のフィードバックループ
- インプット => アウトプット => インプット …
- 量は質に転化する
- blogに書く
- 情報発信、blog、発表、公表などは数学の証明ではなく料理のようなもの
- 執筆する
- gihyo.jp の連載
- コードを公開する
- power-assert
- Assert失敗時(テストが通らなかった時)に分かりやすい情報を表示できるようにする機能の事を言います。 シンプルにassert()を使うだけでも十分な失敗時の情報が得られるため、沢山のアサーションを使い分けしなくていいというメリットがあります。[参照](https://efcl.info/2014/0406/res3809/#:~:text=Assert%E5%A4%B1%E6%95%97%E6%99%82(%E3%83%86%E3%82%B9%E3%83%88%E3%81%8C,%E3%81%AE%E4%BA%8B%E3%82%92%E8%A8%80%E3%81%84%E3%81%BE%E3%81%99%E3%80%82&text=%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%ABassert%E3%82%92,%E3%81%84%E3%81%84%E3%81%A8%E3%81%84%E3%81%86%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82)
- 講演する
- ライブコーディングが最もハイリスク・ハイリターン
- アウトプットのチャンネル
- blog, Qiita
- 雑誌、書籍
- 講演
- ライブコーディング
- GitHub
後半。
- あの John Resing でも上手く行かなかった
- jQuery 作者 John Resig は週末に自分のプロダクト開発を頑張ろうとしたが失敗。
- 平日と同じ馬力ではかけない
- 全ての週末が空いているわけではない
- 一週間（あるいは２週間）は長い。コードを忘れる。
- そこでJohn Resig が行ったことは…
- Write Code Every Day
- ４つのルール
- 毎日コードを書く
- 意味のあるコードを書く
- 深夜２４時前に終わらせること
- githubで全てOSSにする
- ４つのルール
- 当時の @jeresig の github profile は緑一色
- Write Code Every Day
- JohnResigに起こった変化
- 必要最小限のコードへんの集中:
- 一日30分 ~ 1時間程度で意味のあるコードを書くことを強いられる（休日にはもっと強いられる）
- プログラミングの習慣化:
- githubに草を生やすのが目的ではない。自分で自分自身のために生活習慣を変えるのが大事
- 不安との戦い:
- 以前は「十分に」進んでいるか、「十分に」完成しているか、不安があった。
- 毎日コードを書いてみて、進んでいるという実感は、実際の進捗と同じくらい重要だという気付きを得た。
- 週末の過ごし方:
- 以前は開発のすべてを週末にかけて失敗していたが、今や週末はそれほど重要でなくなった。
- リアルライフを充実できるようになった。
- バックグラウンド処理:
- 散歩中、シャワー中う、常にコードのことをバックグラウンドで考えるようになり、良いアイディアが浮かぶようになった
- コンテクストスイッチ:
- 以前は週に1回の開発だったのでコンテクストスイッチのコストがあった。
- いまは毎日なのでそれがない。
- ワークライフバランス:
- 仕事・生活・自分のプロジェクトのバランスのとり方がわかったのが最大の収穫だった。
- 毎日やるということは、バランスを取るということ。
- まわりからの理解:
- 「毎日コードを書く」という習慣を公言したことで、パートナーからの理解も得られるようになった
- どれだけコードを書いたか:
- この習慣を続けると書くコードやアウトプットは自分でも覚えられないくらいの量になり充実感を得られる
- 必要最小限のコードへんの集中:
- jQuery 作者 John Resig は週末に自分のプロダクト開発を頑張ろうとしたが失敗。
- イチローが2004年にNBA年間最多安打を更新した時のことば
いま、地位いさなことを多く積み上げることが、とんでもないところへ行くただ一つの道なんだなというふうにかんじています。
-
DAN KOGAI: 一生プログラマーでいれるかどうかは、言い換えれば年下から学べるか否か。
-
過剰適合とタコツボ化
- できる => 好きになる
-
ベンチマークとアンラーニング
- 定期的に自分のスキルの棚卸しをする
- 積極的に外部に出て、自分のスキルを相対化する
- 使う道具を定期的に変える
- 道のコミュニティに参加する
- 若者から学ぶ
- 若者と同じ土俵で競う
-
ペアプログラミング
- ベテランにはアンラーニングのチャンス
-
アンラーニング:
- アンラーニングとは、一度学習した知識や価値観を意識的に棄却し、新たに学習し直すことです。 個人や組織が継続的に成長するためには、ラーニング（学習）とアンラーニング（学習棄却）のサイクルを回していくことが必要です。 近年、人材育成やイノベーションに有効な手法として注目されています。
- 技術は振り子
- 技術は螺旋
- 技術選定の審美眼
- T字型ではなく複数の柱を
-
組織の時代から個人の時代へ（github）
-
子が多く集まると何かが起こる（ロードマップ指向からエコシステム指向へ）
-
- しかし、今の業界は、「エコシステム」の時代だ。熱帯雨林のように、食いあいつつ共生しあうさまざなタイプのプレイヤーが、自分の為だけの個別の意思決定をして、その相互作用で技術が発展していく。
- 「ロードマップ」が指し示す未来の方向と違う方向に進むことは致命的な間違いだが、「エコシステム」はむしろ中心部がレッドオーシャンで、周辺部に生き残りが容易なブルーオーシャンがある。
- 普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ。
-
デザインの「悪い方がよい」原則:rpg@lucid.com 日本語訳
- MIT/Stanford方式
- 簡潔性
- デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。
- 正当性
- デザインは全ての点において正しいものでなければならない。誤りは許されない。
- 一貫性
- デザインは一貫性を書いたものであってはならない。
- 一貫性を保つために完全性は少しだけ犠牲にしても良い。
- 一貫性は正当性と同じくらい重要である。
- 完全性
- デザインは実際に起こる重要な状況には全て対応できなければならない。
- 起こることが予想される場合は全て扱えなければならない。
- 簡潔さのために完全さが大きく損なわれることが有ってはならない。
- 簡潔性
悪いほうが良い原則はこれと異なる- 簡潔性
- デザインは実装と使用法の両面に置いて単純でなければならない。
- この時、実装が単純な方が使用法が単純なことより重要である。
- 正当性
- デザインは全ての点において正しいものでなければならない。
- ただし、どちらかといえば、正しいことより単純な方が重要である。
- 一貫性
- デザインは一貫性を大きく欠いたものであってはならない。
- 単純さを保つために、一貫性は犠牲にされることがある。
- しかし、あまり起こらない状況に対応しようとして実装を複雑にしたり、一貫性を書いたものにするよりは、それを捨てるほうが良い。
- 完全性
- デザインは実際に起こる重要な状況に全て対応できなければならない。
- 普通に起こると思われる場合は全て扱えるべきである。
- ただし、他の条件のためなら完全さはいつでも犠牲にしてよい。 さらに、実装の単純さが損なわれる場合は完全さを犠牲にしてもそれを守るべきである。
- 単純さが保たれるならば、完全なものにするために一貫性を犠牲にしても良い。
- 何より意味がないのは、使用法の一貫性を守ることである。
- 簡潔性
- MIT/Stanford方式
勝手に解釈すると下記のとおり（？）かな？
-
MIT / Stanford方式
- 完全性 > 一貫性 > 正当性 > 簡潔性
-
悪いほうが良い原則
- 簡潔性 > 正当性 > 完全性 > 一貫性
-
- Worse Is Better に関する自分の解釈は「設計の正しさ/美しさと実装の単純さが対立する（両立できない）ときは、実装の単純さを選択した方が、たとえそれが漏れのある抽象になったとしても現実の問題を解決し、実装の単純さによって開発参加のハードルが下がり、進化的な強さを獲得できる」というもの
-
過去を知り、未来に備える技術選定の審美眼2019
- 本:エッセンシャル思考
- 生き甲斐の図
- 学び続ける姿勢
- 技術を学ぶのではなく、技術の学び方を学ぶ
- 誇りあるプロになってください