サクッと書くと言いながら、2週間以上かかるという。
これまで前書きで色々関係ないことを書いていましたが、人によってはゴミなので後に回しました。なんか、最後に競馬の話を書く人とかいますが、そんな感じで。特にコロナとかはスタンスによっては信仰に関わる(笑)話なので、読みたい人だけ読んで下さい、と。所詮、気になったことをちゃんと考えて調べたいというだけの、医学に関しては素人の人間が公的機関の出してる情報とか信用できそうな人の記事から辻褄が合うように考えただけの話だったりしますし。
はい、というわけですぐに本題です。ちょっと早めの公開のためリンク先行で説明後から更新して足す感じにします。説明なくても書籍から飛んだら公式の説明はあるので。また、良い本を見つけたらここに足していきます。
- はじめに
- プログラミングの裏の動きを把握できる本
- 一歩上のエンジニアになるための本
- プログラミングを本気でやりたい人向け
- プログラムに慣れてきたら読んで欲しい本
- C++er向け
- Pythonista向け
- Java開発者向け
- その他
- まとめ
- [おまけ] コロナの話
はじめに
プログラミングを学ぶ際には知っておくと良い知識にはプログラミング言語への依存が少ない(方言程度も含む)部分と言語への依存が強い部分があります。
例えば、基礎構文であったり、データ構造のようなものは方言程度の違いがあれ、似通っています。1つの言語とその裏の動きを抽象的に理解できれば言語が変わってもあまり問題はありません。
一方、イディオムと呼ばれる言語特有の特徴を活かす慣用表現であったり、標準ライブラリの使い方に関しては言語に特化しています。ただし、後述しますがEffective XXXシリーズあたりはかなりイディオムとしては定番となっています。まずは依存の低い部分から紹介していこうと思います。
基礎構文とかは独学であったりYouTubeでも結構取り上げられてるだろうし、古くはとほほさんのHPで学んだ人も多いと思うので、ここでは取り上げません。ただ、一つだけ言うと、基礎構文を使いこなすには手を動かすのが大事で、そのために何か作りたいものがあった方が良いと思います。個人的にはスポーツにおける基礎体力やスピーチにおける語彙力と同じだと思っていて、それがないと始まらないけど、しっかりとした土台がある方が良い。僕はまだアーティストHPがない頃に情報を集めたりファンのたまり場になれるような場所を作りたいと独学でHPを作って公開したのがプログラムのきっかけです。高校時代の1997年くらいかな。
あと、以前にも書いていますが、前提として、最初から本を読んだら全て理解できるとは思わないで下さい。それは天才の所業です。あなたが学生の時、授業で学んだことを一発で全て理解できたでしょうか？もやっとこんな感じかな、という理解でテスト前に知識を確認する。それでも解けない問題もあって、次の学期辺りでひらめいて突然理解できるようになる。学年が上がるとあんなに苦戦したのに、下の学年の内容は簡単に感じる。プログラミングの知識や経験にはパズルのような部分もあり、少しずつ部分部分組み上げていたら突然全体像が見えて霧が晴れることは結構あります。できれば、気になった点をメモして、わかる人に聞いたり、他の本を読みながら時折不明瞭だった点を確認したりすると学習は進みやすいと思います。一番ダメなのが、簡単に理解できないから自分には向いてない、と投げ出すことなのは間違いないと思います。
プログラミングの裏の動きを把握できる本
ここで紹介する本は是非プログラミングを学ぶ上で知っていて欲しいことが書いてある本です。若干俯瞰図のような部分があるので、定期的に読み直して自分の理解を確認することをお薦めします。
未経験や文系でIT業界に入ってとりあえず動くコードは書けるけど裏側で何が起こってるかよくわかってないという人も一読した方が良いです。僕もSI業界から転職時に読んで自分が全然わかってないと気付いたりしました。この辺がわかってないと、例えばバグ修正で暫定対処はできても根本原因がわからずに恒久対応ができない、というような自体になり、継ぎ接ぎのメンテナンスの難しいコードベースになっていきます。そして「これを消すとバグが発生する」というような謎のおまじないコメントが生まれたりします。
プログラムはなぜ動くのか
なぜシリーズは色々出ていますが、詳細でなく外観を掴むためには非常にお薦めです。往年の定番で、2021/05/18に第3版の発売で現代にも追随して来ると思います。プログラムとメモリやCPUの関わり、OSやプログラムがどう解釈されるかなど、趣味でただ書いてるだけでは理解できない裏側の知っていて欲しいことの入り口的な内容です。
プログラマーのためのコンピューター入門
これもなぜ〜と似た内容です。グラフィックスや抽象化・仮想化の話も入っています。
一歩上のエンジニアになるための本
プログラミングは知識と経験が結びついて上達していくものですが、自分一人で経験できる量には限界があるし、長い経験をしている人の叡智を本から学ぶことは追体験という経験をブーストする非常に効率的な行為と言えるでしょう。この辺の本は筆者の経験に基づいているので、全部そのまま採用するのでなく、良いと思ったら自分のやり方に取り入れると良いと思います。ただ、経験が浅いと同意できなかったり、重要性がわからないかも知れません。経験とともに同意できることが増えていくかも知れません。自分の場合、すごいと思ってる人はやはり、この辺の本で書かれていることはしっかり押さえている印象です。
基本的に商業用のコードは書いた人より他の人が読んだり修正することが多いです。優れた命名は詳細なコメントより圧倒的に優れています。短く書くことの呪いにかからないようにしましょう。
経験を積むほどに納得できる、共感できる本に思えるので、一冊本棚に置いておいて定期的に読むのも良いと思います。
Clean Code
アンクル・ボブこと、Robert C. Martin 先生による、コードを書くために知っておきたい、意識しておきたい知識が詰まっています。
と言っても、最終的にコードが最高のドキュメントになるような、パフォーマンスと可読性を保ちつつCleanなコードを、速く正しく動く美しいコードの指南書です。
Clean Coder
コーダーとして、ITエンジニアとしての生き方、立ち振舞に関してのアンクル・ボブ先生の経験から、プロはかくあるべし、というものを示されています。やりがちな間違いであったり、状況をウェットにユーモラスに語っています。
Clean Architecture
同じくアンクル・ボブ先生シリーズの設計編。ソフトウェアアーキテクチャの各種原則であったり、あるべき姿を示しています。これをベースにした思想でシステムを作ったことがありますが、規律あるメンテナンスのしやすいかなり品質の高いコードになりました。詳細の入れ替えをしてもコア部分に影響がない、拡張に強いシステムになりました。ただし、イニシャルコストはかかります。SIとかでやるのは厳しいので自社製品向けですね。もし、売り切りで作っておしまいのシステムであれば微妙かも知れませんが、リリースが始まりになるようなシステムは最初から意識しておけばツギハギになりにくいソフトウェアが作れると思います。主に拡張部分(詳細)だけの開発で済むので、リリース後のコストは小さくなり、急いで作ったとりあえず動くシステムとの生産性の差は徐々に埋まっていきます。技術的負債が出来づらい設計なので、ありがちな保守が進むに連れて影響範囲が広がり小さい機能追加にかかるコストが累乗的に増えるような事態になりにくいです。とはいえ、経験が求められるので、勘違いなく実践することは経験が浅いうちには難しいと思われます。同様に実践の場(アーキテクチャを1から決められる権限)が与えられることが少ないので、個人プロジェクトから経験を積んで、きたるべき大きなプロジェクトで力を発揮できるように力を付けることをお薦めします。
この辺の一種のバイブル系の本は一定の批判者を持ちます。だいたいが詳細を突っ込んだりで時代遅れ的なツッコミですが、詳細の批判をする(いわゆる重箱の隅をつつく)人は抽象的な捉え方が苦手なのかな？という気がします。抽象レイヤーまで上げて理解をすると適用範囲はかなり広がって、「時代を超えて使える学び」となると思います。例は時代を反映しますが、その裏にある思想は基本的に時代に縛られないと思います。逆に言うと抽象的な学び方を身に着けないと、本質的に同じことを学ぶのに数年おきに詳細を更新されたものでないと理解できない人になってしまいます。素直に考え方の下敷きに取り入れれば多くの学びを得られると思うので、自分の中で抽象化して、もちろん「考え方」に言及する以上、全てが正しい本などないので、自分が良いと思って、取り入れられると思った部分だけ他人の経験から自分の経験に流用すれば良いと思います。
リーダブルコード
某インフルエンサーが否定していましたが、読むべき書籍の一つですね。コードは自分より他人が読むことが多く、開発時より保守時の方が読まれると思うので、名前を大事に、コードが最大のドキュメントと言えるような意図や
達人プログラマー
コードコンプリート
CAREER SKILLS
SOFT SKILLS
プログラミングを本気でやりたい人向け
ただ動くだけ、言語を最大限に活かしたブルートフォースなプログラムを書くだけではなく、ビッグデータを利用したり、NP完全のような複雑な問題を解く力を付けたい人にはこちら。と言っても、アルゴリズムとデータ構造でプログラムが成り立っている(自分でアルゴリズム書いてなくてもライブラリの中で使ってる)ので知っていた方が良いでしょう。ここで言うアルゴリズムとはただの手順でなく抽象化して、数学で言う公式の一種ようなものです。
プログラミングコンテストチャレンジブック
プログラミングコンテスト攻略のためのアルゴリズムとデータ構造
問題解決力を鍛える！アルゴリズムとデータ構造
世界で戦うプログラミング力を鍛える本
アルゴリズム設計マニュアル
プログラムに慣れてきたら読んで欲しい本
レガシーコード改善ガイド
レガシーコードからの脱却
Pythonista向け
Effective Python
まとめ
勉強を積み重ねると見えなかった世界が見えるようになります。是非、良書を読んでエンジニアとしての血肉にして下さい。
評価良さそうなら専門領域編も書くかも？専門領域はプログラミングは手段であり、目的を達成するための理論(主に数学)をベースにプログラムによってそれを実現することになります。個人的に本当に楽しい、魔法のようなプログラミングは数学という世界を表す言語をプログラミングに取り込んだ後だと思っています。その魔法使いへの道のMPを貯めるために、魔法の具現化の能力を上げるために今回紹介させて頂いた書籍を役立てて頂ければ！
[おまけ] コロナの話
終わりのないコロナですが、都知事もモニタリングでちゃんと分析してるのに結果とチグハグなコメントと対策で嘘だろ、という気持ちがすごいです。アンケートに関しては、主張が決まってて、それの根拠にしたかったんだろうけど、予想外の結果でも結論はそのまま、という印象。
98%が常にもしくはほぼ常にマスクしてて、それと別に同居者以外とマスクなしでの会話の有無を聞いてますが、両方な場合、基本的に付けてたけど、一時的にマスクを外しての会話はあった、ということでしょう。頻繁にであれば常になんて言わないだろうし。常にが本当で、うつした側も同じような傾向(4週間分以上のデータならそうなるはず)で感染ってるなら、95%以上のマスクを付けてる陽性者から95%以上のマスク付けている人に感染ってるという話で、それマスク効いてんの？ユニバーサルマスクでウイルス倒せるんじゃなかったの？という感じです。
また、マスクを外しての会話に関しては、これはクラスター追ってるはずなので、その会話が原因で感染したかは確認取れると思いますが、確認してないし、する気はないのでしょう。高めに見せたいから。それでも25%で、75%はマスクなしの会話なくても感染ってる。マスクの感染症対策での優先順位いい加減下げたら、という感じです。2/3以上の人が会話時にも常にマスクしていても感染しているので、マスクをしても距離を取りましょう、と言うべきに感じますが、「普段マスクをしていても、ちょっとした会話・食事などで、あっという間に感染してしまう」とか言ってて鼻から鳩出るかと思った。
僕は以前からマスクを信用せず、付けても距離取りましょうという思想です。マスクで防げるのは飛沫だけで、届かない距離ならマスクいらないし、万が一変異によりマスクをすり抜ける大きさの飛沫でも感染しまくる様になっても(エアロゾル感染を認定できるレベルでも)問題ありません。あくまでマスクは距離を取れない場合の飛沫感染のリスクを多少下げる、程度なわけです。届かない距離は基本リスクは極めてゼロに近いです。
また、動画によると既婚者はほとんどの人が会食をしてない(飲食店での感染の可能性がない)とのことですが、家庭内感染が56.9%で施設内感染が11.2%、これって、飲食店に厳しい規制かけても、下手すると人流抑えてもダメじゃない？という。接触不明が半分くらいなので、そこで変わってくるとは思いますが、わかってる中では7割位が人流と関係ない。更に次も職場で、3位まで一種の閉鎖されたプライベート空間なので関係者以外がうつしてるとは考えにくいわけです。尾身さんの主張してる、「飲食店での会食でもらって家庭に持ち込んでる」、というシナリオをアンケート結果を期待したのでしょうが、大多数の感染経路に飲食店が関係ないことがわかっても方向転換しないというヤバさ。
そして東京都の判断でかなりクリティカルなのは飲食店で働く非正規雇用者です。都知事は「お願い」でなく、「法的根拠」に基づく休業要請をしたかったみたいだけど、労働基準法第26条での「使用者（会社）の責めに帰すべき事由による休業の場合、休業期間中、平均賃金の6割以上の休業手当を払うこと」とあり、今回は行政の法的な要請なので、会社の責任(判断)ではないため、最低6割の休業手当を出す必要がありません。協力金が雀の涙程度だし、時間に対して賃金が払われることの多い非正規雇用だとかなりの確率で回ってこないし、法的に抗弁できないことになる。
最悪なのは、その法的根拠の元になっている緊急事態宣言の基準のステージ4を病床利用率で満たしてない状態で政府に「要請(お願い)」して例外的に対象になったことですよね。これで検証により飲食店は感染源として大きくなかったと証明されたらどう責任を取るのでしょう。感染症の専門家の意見しか聞いてないので眼中にないのですかね。いろんな分野の専門家に意見を聞いてバランスを取るのが知事の仕事だと思うんですが、ちょっと目がくらんでる感じ。
しかし、緊急事態宣言がまたも延長で「短期集中で我慢のお願い」ってなんだったの、という話で我慢も限界な(しかも大半の人が身内に高齢者以外の重症・死亡いないから実感ゼロな)わけで人流は増え、路上飲みなんてお願いされても、法的根拠があろうがお願いであって命令でもなく罰則もないので止めないですよね。なのに陽性者が減少に転じてる。平均5日位で発症するらしいので、延長後の期間の感染状況が既に出てきてるわけで、人流増えてからですよね。簡単な話で、季節の変わり目の気温の変化とそれに伴う気圧の変化で体調崩した人が検査受けて軽症者が見つかって、濃厚接触者の無症状が芋づる式に出てきてたのでは。で、気温高めに安定してきて気圧も上がり飽和水蒸気量増えて湿度も上がり飛沫が蒸発しやすくなった。ただの季節的な外部要因だっただけでは、と思ってしまう自分がいます。
それで従わない業者に休業命令とかやってる都知事ってなんなんですかね。振り上げた拳の行き場に困っているのでしょうか。緊急事態宣言の間に感染者減ったら「緊急事態宣言の効果」と言い、どの施策が効いたかの検証もしないで延長、延長と痛みだけで効果のないこと繰り返してるように見えます。外的要因の方が大きくても無視。もし今回の緊急事態宣言が効いてるのであれば、宣言無視して外出した人達とか路上飲みや開いてる居酒屋、そこで飲み歩いてる人はウイルスを撒き散らすのに全く寄与せず、今我慢してる人達の自粛(=罹患していてうつさなかった)により収まった、ということになります。つまり、宣言下に出歩いてる人を批判してる人達のような属性の層が感染源だった、という事になってしまうけど大丈夫か、それ。まぁ、これはたちの悪い冗談ですが、都知事達の主張が正しければ行動の是正を求められてる人達が自粛するまで減少に転じないはずでしょう。延長後路上飲みは減ったように見えないし、営業再開・酒類提供再開した飲み屋も結構ある印象です。これでは辻褄が合わない。間違いを認めて検証しないと次も間違えるのでは。個人的にはほとんどの対策がマスク神器論からきてるので間違って当然に思えます。人間なので間違ってもいいと思いますが、間違ったと思った時はなるべく早く認めて軌道修正することが大事に感じます。
あと、前回T細胞の数が免疫暴走に関わってるという研究があるって話でしたが、コチラの理研の論文でBCGワクチンがアレルギーを抑制する機構の話の中に
とありますが、この辺がBCGがコロナの重症や死亡の差になってるのでは論と繋がる気がしました。まぁ、医療はただの調べたがりの素人ですが。
それにしても、コロナは東京都が出している分析結果とかを見れば見るほど、「あれ、これただの風邪では？」という気になります。都知事選で「コロナはただの風邪」と言ってる候補者を「流石に気が狂ってるな」と思ったけど、結構正しかったのかも。厳密にはただの風邪とインフルの中間でただの風邪寄りに感じます。そんな分析結果の一次データを持っていて毎週モニタリング会議の報告聞いてるはずなのに、知事の人は2兆もぶちまけて飲食店いじめて何してるんですかね。ウィズコロナとか言いながら感染者ゼロを目指すとか迷走しすぎでしょう。共存する気なんてサラサラないだまし討ですね。しかし、これで「人流抑制の効果が遅れて出てきた」、とか言ったら、都政はもうダメだ、と思って良いでしょう。あ、大阪言っちゃってる･･･だめだこりゃ･･･。
