柴田芳樹のレビュー一覧
-
Posted by ブクログ
本書は、Goの並行処理を「概念→実装→パターン→落とし穴」の流れで系統立てて掴める良書という印象でした。序盤はCSP思想やアムダール/グスタフソンの法則を押さえ、なぜGoがゴルーチンとチャネルを中核に据えるのかを腹落ちさせます。続く章で、OS/ユーザースレッドとM:Nスケジューリング、LRQ/GRQやワークスティーリングまで踏み込むため、ブラックボックスだった実行時の挙動が見える化され、設計判断の根拠が増えます。共有メモリの競合・ハイゼンバグから出発して、Mutex/RWMutex、Cond、セマフォ、WaitGroup/バリアと段階的に同期原語を学び、目的別にどう使い分けるべきかが明瞭です。チャネルとselectは、クローズ、方向制限、バッファ、タイムアウト、nilチャネルなど実務で必要な作法が網羅され、CSPパターン(パイプライン、ファンイン/アウト、quitチャネル、ブロードキャスト)も具体的です。さらに、分解戦略やワーカープール、フォーク/ジョイン、パイプライン最適化といったパフォーマンス志向の視点が実装に橋を架けます。デッドロックはCoffmanの4条件、RAG、銀行家のアルゴリズムまで扱い、チャネルでも循環待ちが起こるという“Goならでは”の注意点を明示。終盤のアトミックやスピンロック、Mutex内部のセマフォ実装への言及は、低レイヤの理解を補強し、いたずらな最適化や誤用を戒めます。総じて、基礎理論からランタイム、言語機能、設計パターン、アンチパターンまで縦断的に学べるため、Goで並行処理を本気で身につけたい読者に強く勧められる内容です。実装時の指針が増え、トレードオフを自分で評価する力が確実に養われます。
-
Posted by ブクログ
# 1周目 読み終えた 2022-12-25
Linuxの世界に完全に移り住んでから結構経つ。特に意識してLinuxを使うためのトレーニングをしてきたことはなく、まとまって取り組むのは今回が初めてだった。なんとなく使えてるからまあいいか、みたいな感じで使ってきていた。改めて気づいたことは、偏りがあるということ。主にプログラミング環境として共にしてきたため、システム管理やカーネルに近いところといった部分へのスキル配分ができてなかった。各章で話題が変わるごとに、やたら難しく感じたり、そうでもなかったりした。そうした偏りに気づいたことはなかなかの収穫だった。難しく感じたところに少しスキルポイントを配分していって、偏りを修正していこうと思う。この本は平均的なバランスの取れたLinuxユーザーになるための評価基準として活用できそうだ。
## 全体的な感想
情報が新しい。最新のディストリビューションで実験しながら読み進めても一致しないところがなかった。加えて、古くなったもの、古くなりつつあるものにも言及がある。
一度で理解するには詳細過ぎるところがある。初心者向けの装いをしている割に、かなり奥深くまで踏み込んでいる。軽い気持ちで手に取るとしっぺ返しを食らう。
緩急が激しい。読者の背景にもよるが、詳細すぎて難しい章から妙に基礎的に見える章までばらつきがある。カーネルに近いところやsystemdが絡むシステムの管理を扱う3章から8章までが難解に感じた。特にデバイスというタイトルの3章は全く理解できなかった。他の章は平均的な難易度だった。
## 5章の残りを読んだ
§5.4 ブートローダ から。Grubの設定、インストール、その仕組み。ちゃんとした解説を読むのは初めて。分かりやすかった。まだUEFIでの仕組みの理解は怪しい。セキュアブートについて少し書かれていた。最近PCを新調して、セキュアブートに引っかかってOSがインストールできない事態になった。オフにすればよかったのだけど、してもいいのかどうか判断がつかず、いくつか試して、Ubuntu 22.10が成功したのでそのまま使っている。その前のPCではデフォルトでオフになっていたため問題に気が付かなかった。また、BIOSはShift、UEFIはEscを長押しするとGrubのメニューに入れる、ということを知った。OSを選択できなくなるのが不便なのでタイムアウトを0にしていなかったけど、0でも問題なさそうだ。
## 3章の残りを読んだ
§3.5.2 udevd
§3.6 詳細:SCSIとLinuxカーネル
全く意味がわからない。何の話をしているかさえわからない。この3章がこの本の中で一番とっつきにくく、難しく感じた。デバイスドライバをかじったことがないと理解できないのではないだろうか。2章からの落差がすごい。
## 17章を読んだ ➤ 仮想化技術
システム仮想マシンとコンテナ。システム仮想マシンとはVirtualBoxのような形態の仮想化のことを指している。QEMU/KVMやVirtualBoxには何度もお世話になってきて、ちゃんとした訓練をしたわけではないけど、特に不便もなく使ってきていた。書いてあることも素直に読める内容だった。コンテナの代表格はもちろんDockerになる。
ちょっと触ったことある程度で、いい加減ちゃんと使い方を覚えないといけないとは思っていた。習熟度の違いからか、なかなか理解が難しいところがあった。どうも、この本全体を通してそのような傾向がある。つまり、普段から接している領域のトピックはあまり苦労せずに理解できて、そうではないところはなかなか難しい。内容そのものに難易度のばらつきがあるためかと思っていたけど、そうではなく、実は割と均一で、読み手の方の経験に左右されているのではないかと思い始めた。この本を通して理解がしやすかったとか難しかったとかの感触から、どの程度通っているかの指標になる。もし、15章とかの内容の難易度が基準であったとするなら、この本自体がかなり基本的なところの内容ということになる。どの章に置いても理解できる程度にまではなっていなければならない基礎知識だとみなしたほうがいい。この章のコンテナについても、Dockerでしばらく遊んだあとに読み直せば、また全然違った印象になるだろうと思う。
## 16章を読んだ ➤ Cソースコードからのソフトウェアのコンパイル
autoconfがメイン。何度も使ってきたconfigureスクリプトがautoconfでパッケージ化されたものだということすら知らなかった。もっと詳しくなるには自分でautoconfを利用してみる必要もありそうだ。ただ、CMakeの方がはるかに使いやすいので、わざわざautoconfを採用するちょっと動機が弱い。自身のソフトウェアを配布するために利用するよりも、広く使われている優れた既存のソフトウェアを理解するために習得しておくことが主な目的となりそうだ。
## 15章を読んだ ➤ 開発ツール
最も馴染み深い内容だった。概要と注意点をまとめたもの。最初にプログラミングの経験は必要ないと書かれていたけど、本当に経験がない人が読んでもなかなか厳しいものがあるように思う。ちょうど自分が3章、6章あたりで感じたような、一体何の話をしているのだろうという感じになりそうに思える。それでも、プログラミングを完全に避けてLinuxを使い続けるのは困難なので、欠かすことのできない章だ。
## 14章を読んだ ➤ Linuxデスクトップと印刷の概要
この本の良いところの一つは情報が新しいところ。XとWaylandが混在している現状がちゃんと反映されていて、実用的だ。D-BusとかWaylandって何なのという疑問が少し解消された。Xの細かなユーティリティが紹介されていて、知らないものもあった。
## 13章を読んだ ➤ ユーザー環境
かなり短い章だった。主にスタートアップファイルの話。LD_LIBRARY_PATHを設定してはいけないとある。やってしまっていたので見直そう。大体デフォルトのままで、必要になったらその場しのぎの設定を追加するという典型的な未熟者の使い方をずっと続けてきた。こういうのはよくない、やたらめったらPATHを変更したりするべきではないとある。理想的なスタートアップファイルを構成するのはなかなか難しい。
## 12章を読んだ ➤ ネットワークでのファイル転送と共有
rsyncは用途が広いので、積極的に使ってマスターしておくのが良い。選択肢は色々あるけど、ファイル共有という目的だけなら、SSHFSだけで事足りそうだ。
## 11章を読んだ ➤ シェルスクリプトの概要
一気に難易度が下がった。新たな発見もいくつかあった。例えば LANG=C man man のようなコマンドが、サブシェルの記法を簡略化した構文だということ。基本は大体は身についているものとみなしても良いのかも。というのは浅はかかもしれない。
タイトルは概要となっているので、まだまだ学ぶことはありそうだ。例えば、awkやsedを使うシーンは結構あるのに、まだちゃんとやったことがない。
## 10章を読んだ ➤ ネットワークのアプリケーションとサービス
やっと水面下から抜け出して、地上に戻ってきた感じがする。もうここからはさほど苦労しなくても読み進められそうだ。と思っていたところ、SSHの暗号化の仕組みで混乱した。セキュリティの話題などもあって、特に興味が湧いた。ネットワークのプログラミングもやりたい。
## 9章を読んだ ➤ ネットワークとその設定の理解
身近なところであるのと、関心があるためか、意識を途切れさせずに読み進めることができた。今まで読んだことのあるネットワークの解説の中では、最良の部類に入るものだった。少しでも予備知識があれば、過剰なまでに詳細であってもプラスに働くようだ。3章以降がやたら難解に感じられたのは、まだそれを読み解くだけの予備知識を持っていないからだと分かった。もし準備ができていれば、この章と同じくらいの収穫を得られたのではないかと思える。
## 8章を読んだ ➤ プロセスと資源利用の詳細
topを始めとした監視のためのツールの詳解から始まる。
top
lsof
strace
ltrace
ps m
top -p pid
time
renice
uptime
psでページフォルトの情報を得る: ps -o pid,min_flt,maj_flt pid
vmstat
iostat
iotop
最後はcgroupで締める。実際にどうやって活用するのかイメージできず、よく分からなかった。それを除けば比較的わかりやすい章だった。
## 7章を読んだ ➤ システム設定:ロギング、システム時間、バッチジョブ、ユーザー
この章は比較的わかりやすく、置いてきぼりになることはなかった。それでも、§7.9のユーザーアクセスの話題以降は難しかった。そこは高度な話題になるからスキップしてもいいと警告があったので、初見で理解できなくても仕方ない。
journalctlはシステムに問題が起こったとき、問題の特定と解決のための強力なツールになる。このツールの存在を知れたことが、今のところ最も実利用に即した情報だったように思う。
## 6章を読んだ ➤ ユーザー空間の開始の仕組み
主にsystemdの仕組み。もともと難しい上に、詳細すぎてついていけない。欲を言えば、いきなり最深部に飛び込むのではなく、まず表面をざっと解説してから中に入っていく流れにして欲しい。System V initは直感的で分かりやすい。この本は見た目に反して全く初心者向けではないと思い始めた。
## 5章 途中まで読んだ ➤ Linuxカーネルの起動の仕組み
§5.3まで読んだ。§5.4からブートローダーの話になるが、遠慮なく6章に進めばいいと書いてあるのでそうする。
## 4章を読んだ ➤ ディスクとファイルシステム
良かった、3章みたいについていくのがやっとというような展開ではなかった。ちゃんと順を追ってわかりやすく進めてくれている。実際にfdiskやpartedディスクをいじくり回すことで、内容が正しいことを体感できる。3章がよく分からなかったのは、デバイスに関する知識がかけていたせいだったのだろう。ずっとその状態が続くのかという不安は解消された。…と思ったけど、LVMのところでちょくちょく理解できないところがあった。§4.6は、初めて読む場合は先に次の章を読むようにと書かれていたけど一応読んでみたらやはり理解できな部分があった。
## 3章の途中まで読んだ ➤ デバイス
何か言っているのはわかるのだけど、なぜその話をしているのかすら見えてこない。実際に手を動かしてみると、書いてあることと一致する結果が得られるので、何かしら分かったような感触は得られる。なんとかそれでごまかしながら読み進めた。
§3.5.2で、次の章を読んでから戻ってくることを進められているのでそれに従って次に進むことにした。
## 2章を読んだ ➤ 基本コマンドとディレクトリ階層
コンパクトにまとまっていてなかなか良い感じ。必要最小限に抑えられている。標準的なガイドで、特に変わったことはなかった。
## 1章を読んだ ➤ Linuxシステムの全体像
情報の密度が高い。ぎちぎちに詰め込んである。まえがきで言っていたLinuxの経験があまりない人、例えば、GUIしか使ったことがなく、lsを一度も叩いたことのないような人でも理解できるのかどうか、はなはだ疑問だ。逆に、ここをすんなり飲み込めるようであれば、幸先の良いスタートを切れたと言える。
## まえがきを読んだ
4章まで読んであったけど、時間が空いてしまって覚えていないので、最初から読み直すことにした。この本を読むのにプログラマである必要はなく、基本的なスキルすら必要としないと書かれている。GUIでファイルやフォルダが何であるか分かっているくらいで十分とのこと。以前読んだときはそれほど簡単な内容に思えなかった記憶がある。 -
購入済み
最新の話題
Javaがハードウェアの多様化に対応していこうという大きな流れの中心的な話題と、いくつかの最新の話題について、踏み込んだ記述がされているようです。
-
Posted by ブクログ
「プログラマー現役続行」の加筆・修正・再構成・改題を行った本。
改めて読み直し。
ソフトウェアエンジニアのレベル
(スティーブ・マコネル コードコンプリート第2版)
レベル1 初心者
1つの言語の基本的な機能を使用できる。クラス、ルーチン、ループ、条件文を書くことができ、言語の機能の多くを使用することができる。
レベル2 中級者
複数の言語の基本的な機能を使用することができ、少なくとも1つの言語を使いこなしている。
レベル3 上級者
言語、環境、または両方の専門知識を持っている。このレベルのプログラマーは、J2EEの難解な機能を全て知っていたり、「Annotated C++ Reference Manual」を記憶していたりする。このレベルのプログラマーは、企業にとって貴重な存在であり、多くのプログラマーはこのレベルを超えられない。
レベル4 指導者
レベル3のプログラマーの専門知識を持ち、プログラミングにおいてコンピュータとのやり取りはほんの15%にすぎず、85%が人とのコミュニケーションであることを心得ている。(途中省略)指導者は、マシンではなく人が読むためのコードを書く。指導者レベルのプログラマーは、水晶のように澄み切ったコードを書き、しかもそれを文書化する。
メイリアー・ページジョーンズ 7つの段階
段階1 無知の段階
(技術Xについて聞いたこともない)
段階2 きがかりな段階
(技術Xについての論文を読んだことがある)
段階3 見習いの段階
(技術Xについての3日間のセミナーに通った)
段階4 実践しようとする段階
(技術Xを実際のプロジェクトに適用しようとしている)
段階5 職人の段階
(技術Xを仕事の上で自然に自動的に使っている)
段階6 名人の段階
(技術Xを完全に消化していて、いつルールを破るべきか知っている)
段階7 エキスパート
(専門書を著作し、講演し、技術Xを拡張する方法を探究する)
柴田芳樹 「職人」という意味で名称を変更して定義しなおしたレベル(ソフトウェア・スキル・インデックス)
レベル1 初心者
ソフトウェア開発を行うには、プログラミングの基礎知識やコンピュータに関する基礎知識が不足している。
レベル2 見習い
指導を受けながら簡単なプログラミングなどの実践ができる。
レベル3 初級職人
見習いレベルの実践はできるが、時々指導が必要である。
レベル4 中級職人
必要な技術を仕事の上で自然に自動的に使っている。
レベル5 上級職人
新たな技術も含めて自分で常に学習を行い、自然と実践できている。
レベル6 名人
技術を完全に消化していて、いつルールを破るべきか知っている。また、技術記事などを執筆している。さらに、中級職人以下の職人を上級職人にすべく、組織に対して教育・指導を行っている。
レベル7 匠
専門書を著作し、講演し、技術を拡張する方法を業界に問う。一方で、より良い方法で職人を育成するための方法も探究している。
今現在私はレベル4くらいではないかと思う。何時の日か匠になれる日を夢見て。 -
Posted by ブクログ
筆者のソフトウェアエンジニアとしての生き様を惜しげも無く披露してくれている。プログラミングが好きな中堅のエンジニアで、これからの行く末に迷っている人におすすめな本。(まさに自分もそうなのだが。)
常々、周りのマネージャ指向にはうんざりしていて、「プログラミングを捨てて」マネージャになるしか生き残る道はない、みたいな人の話には漠然と疑問を感じていたが、本書を通してその霧が晴れた思いだ。これからは、何歳になってもコードを書き、専門性を高め、若手の指導、育成を行う、(筆者のような)かっこいいエンジニアを目指していきたいと強く感じた。
しかし、一方で自分のスキル不足も痛感した。
本書では推薦図書が多く紹介されていたが、読んだ事があったのは2、3冊であった。(!)
これから、一流のソフトウェアエンジニアを目指そうという人間が、これでは寂しい。これから、本書で紹介されている本を最低ラインとして、自分に課し、身につけていこうと思う。(死ぬまでに読み切れるといいが。)
そういう意味では、本書で定義されている職人の段階からすると、自分はまだまだ「初級職人」といったところか。
これからもっともっと知識を増やし、若手に影響を与えられるエンジニアになっていきたい。
ソフトウェア開発プロジェクトは年々難易度が増してきている。そういった一流の職人が引っ張る強い開発チームこそ、生き残っていく時代になっていくと思うのだ。(というか、既にそういう時代かも。) -
Posted by ブクログ
IT業界で、ある意味一生、技術者として40代、50代もプロジェクトリーダーやマネージャーにならずに、プログラマとして、生き残って行くことは、野球で言えば、イチローみたいなこと。若い世代に負けず、職人として勝ち続けるためには、圧倒的な技術力が必要だ。ですので、この本の著者のように、誰もがなれるか、というと、ほとんどの人は、まず無理、というのが現実。この著者のように、相当数の勉強と努力、英語の技術翻訳までやっている。ここまでの労力と時間を費やすならば、やはり、通常は、現役は若い世代に譲り、自分は監督業として成長していくことの方が良いだろう。そうしなさい、とは言いませんが、それの方が堅実的な生き方になります。というのも、リーダーやマネージャーの立場になる人も、また、少なく、需要として大きいからです。