たくさん書いて、エラーして、改善して、やったー！って身につくしかないと思う。
やる気のある方の参考になりますように。
どこぞと比べて良心的な価格だし、カリキュラムも高品質だと思う。羨ましい。
①フィヨルドブートキャンプ
Web開発。Ruby。手をたくさん動かしそう。カリキュラムも実務寄りだし、エンジニアの方々が実名。
②Recursion
ソフトウェア開発を、コンピュータサイエンス(CS)という基礎から、実際に何かを作るまでできるようにカリキュラムが組まれている。開発者の方はシリコンバレー出身。最近、Recursionの開発一本でやっていくと決めたそう。
③freeCodeCamp
文字通り無料。Web開発メイン。Javascript、React。モダンな技術スタックを手を動かして身に付ける。ここから入ってコンピュータの動きの裏側を学んでいくのはありだと思う。英語だけど、慣れていこう。
追記(じっくりコトコト自分を煮込んでもいいと思ってる人向け)
煮込み甲斐がすごいサイト。
・TeahYourselfCS
上司から松下幸之助さんの本を教えてもらった。曰く、素直な心がとても大事とのこと。
「素直な心になるために」を読んだ。読むだけでは足りない。実践してこそ、分かったといえる。言ってることは、頭で理解するには難しくない。うんうん、そうだよね、となる。けど、自分の行動に伴っているか？イエスとは言えない。
＜素直な心の意義について＞
よいものはよく、悪いものは悪い。今、何がいいものなのかを考えて、行動する。自分にとっての利害ではなく、誰かを貶めるのではなく、ただ万人にとってよいと思われるものを推奨し、実践していく。お互いに協力して、よりよい生活、よりよい心で栄える。個人的にはそのように受け取ったが、具体的な指針や全体像が分からないので、受け売りになっていると思う。
＜素直な心の内容十か条＞
◎私心にとらわれない
この判断は、相手のためになるのだろうか？自分にとって都合がいいだけではないだろうか。相手は困らないだろうか？誰かのためになるのだろうか。逃げではないか？考えるべきことを考えないようにしてはいないか？
◎耳を傾ける
相手の言葉をきちんと聞いたか？意味が分かるように理解したか？伝えてくれようとしていることを、たとえ意見の相違があっても、しっかりその意見を、その意図を聞いたか？
◎寛容
相手が失敗した時、うまくいかなかった時、責めはしなかったか？自分が失敗した時、厳しく当たらなかったか？うまくいかないことがあった時、いらだちはしなかったか？
◎実相が見える
物事をありのままに見たか？本当に大事なことは、本当のことは、何なのかを感じたか、考えたか？何か、自分なりの意見があって、それに当てはめようとして物事を見ていないか？自分が考えたいことだけ考えて、考えたくないこと、知らないことはほっておいて、物事を見ていないか？
◎道理を知る
物事の道理。ことの進む順番。こうしたら、きっとこうなるだろう。考えたか？自分の行動がどんな影響があるのか、考えたか？色んな立場から、何がすべきで何がすべきでないか、考えたか？
◎すべてに学ぶ心
自分に得意なところ、良いところがあるように、誰しも得意なところ、良いところがあるのに、それを見過ごしてはしなかったか？誰かを勝手にくだらないと決めつけなかったか？透明な眼で、判断したか？良いところを取り入れたい、謙虚な気持ちで向き合ったか？
◎融通無碍
いじっぱりで、固執してないか？あるがままに対応方法を考えたか？それが本当に正しいのか？
◎平常心
慌てなかったか？自分の心にとらわれなかったか？
◎価値を知る
よいものはよいと受け止めたか？
◎広い愛の心
困っている人を見て見ぬふりしなかったか？自分の心をとりあえず優先していないか？
下心があるから出るのです。
下心が出るのなら、それはよくないんです。よくないと思ってるものは、相手にもよくないと伝わります。もしくはどこかで気付かれます。人間、隠し通すのはそんなに簡単じゃない。
これ、お客さんに言った方がいいか言わない方がいいか？迷ったときは、言った方が勝率7，8割あると思います。逆に言わない方がよくない。言ってみないと、何なら言ってもいいの経験値にもならない。地雷でも、言うべきことは言った方がいいです。
じゃあ、どうやって言うか？よくないと思ってるもの、自分たちだけが得するもの、そういうものは、どうやっても自信よくよいと言えないですよ。ばれちゃいますしね。だから、よく考えて、そうした方がよいんであれば、そうやって言うべきだし、自信持って言ったらお客さんにも伝わりますよ。
だから、どっちかだけ得するのではだめなんです。それじゃ長続きしない。相手に1億の利益が出て、こっちに500百万しか利益がなかったら、続かないですよ。そこまで極端じゃなくても、例えば工数がかかるのならその分報酬はもらうべきだし、逆にぼったくりしようとしたって、そこで関係は終わりでいいんですね？そういうことになります。
大事なのは、やましさをなくすことです。なくせないのなら、それは提案すべきことじゃない。ジャパネットたかたの社長さんはすごいですよね。あの人が話すと、なんだか買う気になっちゃう。何ででしょうか？
もののいい面を見なくちゃいけません。良い面も悪い面もありますから。第一印象で悪かったらそれで全部決まっちゃうんですか？自分がそうやって見られたら悲しいですよね？どんな人でも、探そうと思えば見つかります。保身すごいけど経理ちゃんと見てるとか、仕事適当だけど集中モード入ったらすごいとか、たくさんありますよね。利益を出さなくっちゃいけないので、天秤にかけて、必要なものは必要だと言って、そうやって素直にやればいいと思うんです。
英語版3rdを使用。
Question
P60 Amdahl's law 改善率
・60%カバーの場合、全体のパフォーマンスを1.25×から1.67×に上げるだけでも、カバー範囲を2×改善する必要がある。
・90％カバーの場合でも、全体のパフォーマンスを4×に上げるには、カバー範囲を6×改善する必要がある。
まとめ
・コンピュータは色んな部品からできている。より早く計算するため、より多く計算するため、色んな手法が生み出された。
・すべての元はビットであり、使う場所によって表現が違う。プログラムはテキストやバイトコードに翻訳される。
・ソースプログラムはプリプロセッサ→コンパイラ→アセンブラ→リンカを経て実行可能プログラムになる。
・CPU(PC, ALU, RegisterFile)とMainMemory, I/ODevice間でBUSによるデータの引き渡しが行われ、プログラムを実行している。（例：HelloWorldをキーボード打ち込み→RegisterFileに登録→DiskにあるファイルをMainMemoryに読み出し→CPUがMainMemoryを読む→グラフィックに出力）。データが何回も移動するので時間がかかる。
・スペースが大きくなるほど読み取りに時間がかかる。つまりRegisterFileは速いけど小さい、MainMemoryは遅いけど大きい。このスピード差を埋めるためのCache技術。RegisterFile用にCacheMemoryを設け、将来使いそうなデータをあらかじめ格納しておく。
・DiskもMainMemoryのためのCacheになる。こうしてより速い、スペースが小さいメモリのためのメモリが用意され、MemoryHierarchyの概念ができる。一般的にRegisterが頂点となり、例：L1→L2→L3(ここまでSRAM)→MainMemory(DRAM)→Disk→RemoteStorage
・Softwareであるプログラムは直接HardwareであるCPUやMainMemory,I/ODeviceにアクセスしていない。実行ステップ間にはOSの制御ステップが差し込まれる。
・OSはAbstractionsと呼ばれる概念でSoftwareとHardwareを結び付け、管理している。ProcessesはProcessor, MainMemory, I/O Devicesからなり、VirtualMemoryはMainMemory, I/O Devicesからなり、FilesはI/O Devicesからなる。
・ProcessはContextSwitchをして複数のタスクを同時にやっているように見せる。切り替え時はKernelCodeが動いている。
・今だとProcess内で複数持つことができるThreadのほうが優先して使われている。複数Threadのほうがデータ共有が簡単でネットワークサーバの要求を満たし、プログラム実行も速い。
・VirtualMemoryはアドレススペースを番号が若い順からプログラムの使用に使い、終わりの方でKernelのVirtualMemoryに使う。
・並列処理。①スレッドレベル並列処理：シングルチップに複数CPUを載せている。それぞれのCPUがL1, L2等のCacheを持ち、L3は共有Chache（図例）。スレッドが複数使える。②Instructionレベル並列処理：パイプ処理。③SIMD並列処理
・Networkもシステムのある一部から見るとI/O Deviceのようなもの。
予感がする。
人はみな予感を持っている。
でも、自分自身になることはつらく苦しい。
たとえ逃げることができなくても、逃げ続けるままに終わることを選ぶ。
でも、良くも悪くも、目を向けてしまう人たちがいる。
ありのままになろうとする人たちがいる。
彼らはきっと、少しは心安らかにしんでいく。
めっちゃ分かりやすい。
概要：
オブジェクト指向でシステム設計をする時の実践方法。
所感：
変更しやすいシステムを作るにはどうすればいいか？全ての実践方法はこのために書いてあると思う。そして、そのアプローチとして、オブジェクト指向設計が挙げられている。
目から鱗。変数名の書き方とかメソッド独立とか、分かりやすかったけど、最初に衝撃だったのは、業務で使うデータごとにクラスを作って入力範囲を通常使用の範囲に収める所。intとかStringのままのデータ型ではなく。その次にびっくりしたのは、データとデータ操作をデータクラスの中にまとめる所。controllerクラスで書いてる。あとは、elseは使わないとか。あと、ドキュメントは作らなくてもコードがドキュメントになるとか、感動した。そういう意見に同意はしてたけど、理想だとばかり思ってたので。
あと、優秀な開発者は業務をやる人と同じぐらい業務が分かってる、という記述を別の本読んでて見たことがあったけど、ドメイン駆動って、まさにそれが必要なんだね。
設計と実装を同じ人がするのも、効率がよさそう通り越してそうである必要があって、そこも、理想だとばかり思ってたところだった。
継続的な開発モデルとか、それに合った契約方法がふつうになっていけば、いいシステムが作れるし、キャッシュフロー的にも許容できるよね。
あとは、このやり方に頑張って慣れるという所だよね。そこが一番難しいかもしれない。
てっきりこの本はオブジェクト指向の書き方Tipsかなと思って読んだら、まさかの名前だけはよく知っているドメイン駆動の実践入門的な内容で、びっくりしてるけど読めてとってもよかった。
いやぁ学生って本当にすごいよね。
私もかつては学生だったんだけどね。
社会人になってから勉強すると、もう目が点になって思考が止まっちゃう。なんだこれ、え、どういうこと？何この概念、何がしたいの、どういう意味？、、、
よく考えたら、学生の頃は毎日そんな感じだったと思う。高校とか大学とか。でも、毎日新しいことを知るのが当たり前で、それに慣れるからへえこんなのあるんだ、とか、こういうものだから覚えてこれはこう使って、、、みたいな、自己防衛？いい感じに気にしなかった。
社会人になってからそういった勉強をすると、毎日の業務がふつうにコミュニケーションだったりコードを書いたりしてるので、まあ未知の領域に出会わない。エラーは毎日見てるし、データの流れを読むのに四苦八苦してるけど、それと全然違う領域だよね、勉強って。特に今、CS系の数学を勉強してるので特にそう思ってるかも。グラフ理論の平面グラフ、平面的グラフ（何が違うねん、いや今は何となく知ってるけど）とか、離散数学の概念とか、え？？ナニコレ？？っていちいち内容にもうびっくりしてる。
そう考えると、学生の頃の勉強って本当に今でいう仕事みたいなもので、だってめちゃくちゃ大変だし、競争のプレッシャーもあるし、でも好きなこともしたいだろうし、いや本当に学生って大変。学生は勉強しかできないとかいう大人は信用できないなぁとしみじみ思う。あと、勉強をやってくれればいいと思うのだって多分違う。勉強はその程度のものじゃないよ。
