検索

• [ Prev ]
• [ 読書メモ/「CPUの創りかた」 ]

最後に後書きとか感想とかをだらだらと書きつけて〆とします。

実は、「CPUの創りかた」を購入したのは2003年の10月。つまり初版本が本屋に並んだのを見つけて即座に購入したのです。
が・・・「実際に製作せねば読んだことになるまい」と自分勝手な設定を作ってしまい、本腰入れて製作するには相当時間が取られるだろう、一ヶ月か、二ヶ月か・・・とびくびくおびえているうちに7年も過ぎてしまっていたというオチ。

作例日記の日付を見れば分かりますが、モジュール分割してROM部分をスポイルしてしまえば、製作の正味はたった4日間だったわけです、やってみたら。自分の腰の重さに呆れると同時に、今までROM部分をスポイルするという発想を思いつかなかった自分を駿河問いにかけたくなります。しかも、4日間という数字には単芯細線で苦労した分や、秋葉原への買出し（午前中）ｘ３日も含まれてます。その辺りが準備万端整っていれば、さらに正味の製作期間は短縮できたはず。心理的なハードルもぐっと下がり、もっと早く腰を上げていたはず・・・口惜しい、妬ましい。

よくぞ「人力ROM」という抜け道を探し出し、手抜きと罵られようと完成させた、えらいぞ自分・・・と褒めたくなりますが。
Web上の製作記事とか見ると、最初からROM部分もフル装備で、しかも殆どトラブル無く製作できてる人多数・・・。
いや、自分、ぜんぜん偉くないよ。最初から腰が引けた姿勢で安全圏でおままごとしてただけじゃないのか？
・・・とかぐちぐち考え出すと鬱々としたスパイラルに陥りますのでこの辺で切り上げます。

結局、7年越しの宿題をようやくクリアしたわけですが・・・7年も経ってしまえば、提出期限は（あるとすれば）とっくの昔に過ぎてるわけで。いまさらクリアしたところで、マラソンで言えば閉会式が終わった後にようやくゴールに到着し、会場の後片付けも終わりつつある、人もまばらな夕暮れ時、一人寂しくタオルで汗をぬぐってる・・・そんな感じです。完全に乗り遅れました。もちろん本の内容は誰もが認めるとおりユニークでピカイチですが、それを咀嚼するためのハードルを自分の中で勝手に上げすぎて、空転してたなという感じです。

この作例日記で示せた通り、ROM部分をスポイルして、回路をモジュール分割することで製作ハードルはかなり下げることが出来ます。ALUや命令デコーダ、レジスタ群を独立して動作確認できますので、論理回路がCLOCK信号により出力を組み替えていく様子を細かく観察できるのも楽しいです。
実際の製作に挑戦しようと思い立ってはみたものの、ROM部分の半田付けや細かい配線で足踏みしてしまう。今一歩材料集めや半田付けに踏み出せない・・・。そんな方にとって、本記事の作例が少しでも敷居を下げるお手伝いをできれば、幸いです。

• [ Prev ]
• [ Up ]
• [ 読書メモ/「CPUの創りかた」 ]

• [ Prev ]
• [ Next ]
• [ 読書メモ/「CPUの創りかた」 ]

いよいよ動作確認です。

説明する内容は無いので、LEDが光ってる＝動いてるっぽい感じのする写真を並べて紹介するだけになっちゃいました。

最後に、各モジュールの（ぴんぼけしてない）写真と、使用した工具や配線材を紹介して終わりです。

• [ Prev ]
• [ Next ]
• [ 読書メモ/「CPUの創りかた」 ]

今日は

• 単芯の細線, 半田, 半田吸い取り線の買出し
• CPU部分の配線

を終えました。ALU、命令デコーダ部分は昨日終わってますので、レジスタ部分の配線がメインとなります。

• [ Prev ]
• [ Next ]
• [ 読書メモ/「CPUの創りかた」 ]

今日は

• 工具の購入
• ALUと命令デコーダ、ただし配線のみ

を終えました。

後日工具についてはまとめますが、とりあえずワイヤストリッパの径が合ってなかったのと、モジュール間をつなぐときに使うコネクタとピンは昨日購入したのですが、圧着式のやつだったので、圧着ペンチが無かったので、昨日に引き続き秋葉原まで午前中はお買い物に行ってきました。

昨日１セット作ったコネクタは、無理やり半田付けででっちあげたやつです。

今日はALUと命令デコーダを作ることにします。

• [ Prev ]
• [ Next ]
• [ 読書メモ/「CPUの創りかた」 ]

今日は

• 部品の購入
• ウォーミングアップ：IOポート, 人力クロック, 人力ROM モジュールの作成

を終えました。

お昼までは秋葉原に出向いて、千石電商でゴソゴソパーツ集めしてました。
お昼ごはん食べてお家に帰ったら、久しぶりに半田ごて取り出してはじめました。

買ってきた部品とか、以前電子工作やってたときに買い置きしていた余剰パーツとか集めて、とりあえず「CPUの創りかた」手抜き版の部品一式です。

このほかにも、当然工具類としてニッパー、ラジオペンチ、ワイヤストリッパー、さらに何種類かの配線材が控えています。

• [ Prev ]
• [ Next ]
• [ 読書メモ/「CPUの創りかた」 ]

「CPUの創りかた」は良書だが、実際に手を動かして作るのはかなり大変そうに見えた。
それで一度はあきらめたのだけれど、お風呂に入ってる時「なんで大変なんだろう」と、もやもやとアレコレ考えた結論として、

• ROM部分のDIPスイッチの配線が面倒くさい。
• 全部作った後にテスタでチェックし始める流れ：ソフトウェア開発の世界では単体テストもろくにせず、いきなり結合テスト：ビッグバンテストする流れで、チキン野郎にはとてもじゃないけど出来ない恐怖の流れ。

の２点が大きい。これに至った瞬間、

なら、ROM部分を作らなければスゲー楽にならない？

と頭上にランプが点った。

1. アドレスラインにはLEDを付けて、「何番地をFETCHするか」が分かればそれでいい。
2. データラインにはインバーター(74HC540)を挟むとしても、DIPスイッチが一基つながっていればそれでいい。

人間がアドレスラインのLEDを目視して、その都度DIPスイッチを組みなおす、いわば「人力ROM」にしてしまえば、思いっきり製作コストが下がる。

となると嬉しい副作用として、クロック回路から発振回路を削れる。なぜなら、人力ROM方針で進む以上、クロックすら人力で入力しないと困ってしまう。発振回路が勝手にクロックを進められても追いつかないからだ。
つまり「人力クロック」オンリーにしてしまう。(リセットはつけときます。)

もう一つの、製作コストは上がってしまうけど、ビッグバンテストを回避するためのアイデアとして「とにかくモジュール分割して、モジュールごとに単体テストを可能にできないか？」というアイデア。

本のほうで紹介されているように、電子工作初心者が見たら全力で引いてしまいそうな、一枚の基盤にCPU部分からROMまで全て集約するような作り方を全力で回避する。
人力ROMモジュール、人力クロックモジュール、CPU部分もOUT(LED4基), IN(DIPスイッチ), CPU(レジスタ+データセレクタ), 加算器, 命令デコーダに細かく分割して、適当なコネクタでモジュール間を接続できるようにする。
これなら、各モジュールごとに独立して動作確認できる。１ステップごとに「作成・テスト・動作確認・デバッグ」のサイクルをリズミカルに繰り返せるし、何より、初心者にとって「動くうれしさ」をよりたくさん、細かいけど確実に味わうことが出来る。

・・・だってさ・・・これから本格的に仕事に就くであろう学生じゃなくて、単に知的好奇心を満たしたいだけの、趣味で挑戦しようとしてる素人ですよ？
やっぱり、「一発で全部作って、ビッグバンテスト」よりは「ちょこっと作ってちょこっと動作確認、ちょこっと動いてやったー！」を繰り返したほうが、気分的にも楽しいと思うのですよ。

自宅警備員なのを良いことに、今まで読もう読もうと思いつつもまとまった時間がとれそうになくて、実際取れなくて、本棚に眠ってた技術書をぼちぼち消化しつつある昨今、ようやく自分なりに、いろいろなタイプの技術書があって、それぞれなりの付き合い方があるんだなということが、本格的にプログラミングの勉強を始めて10年以上経ってようやく分かってきた。

技術書にもいろいろなタイプがある

• 豊富なサンプルコードで「手を動かして覚えてもらう」事を目的とした書籍
  • 読者が置いてけぼりにならないよう、丁寧かつ「簡潔な」サンプルコードや、分かりやすい明快な文章で書かれたタイプ
  • サンプルコードに複数の機能のデモンストレーションを詰め込んで一気に解説するタイプ
• 著者のメモ書きを体系立てた教科書的な構成の書籍
• ハウツーを分野ごとにまとめた書籍
• 電子マニュアルを紙にした書籍

要注意なのが「サンプルコードに複数の機能のデモンストレーションを詰め込んで一気に解説するタイプ」と「著者のメモ書きを体系立てた教科書的な構成の書籍」の二つ。

一見サンプルコードが掲載されていて親切に思えるが、一つのサンプルコードに機能が詰め込まれすぎていたりして逆に理解するのが億劫になったり面倒くさくなるタイプ。たとえば一つのChapterにつき、単体で実行できるサンプルが一つしかないなど。複数のサンプルがいろいろ載っている場合でも、一つのサンプルあたりで取り扱っている機能がたくさん有ったりして、結局、「手を動かして」覚えるのではなく、おいしいところだけ真似すればお仕舞い。
そうした書籍だと、頑張って「手を動かして」も、やたらソースコードが長かったり、使う機能とは本質的には無関係な、見た目だけ多少「実用的」にするための余計なオプションだの読者向けの宿題だのが混じってて、読者が置いてけぼりにされてしまう。というかされた。

「著者のメモ書きを体系立てた教科書的な構成の書籍」も注意すべきタイプの一つで、著者としては体系的にまとめているつもりが、それを後から、最初から、通読しようとする読者に取って「物語」として読める構成にはなっていない。「書いてあることはすばらしいのだけれど、読んでるとなんか眠くなってくる」タイプの書籍はほぼこのタイプ。

技術書にはその構成、著者の意図に応じて上記以外にもタイプがあると思うが、重要なのが、それぞれのタイプとの付き合い方をきちんと対応していかないと、読み手が不必要に気疲れしたり、本の内容とは無関係に、本に対して嫌悪感を抱いてしまう。後述のように「理屈抜きの好き嫌い」とか、「なぜか分からないが読みづらい、読んでると眠くなる」というのはどの本にもあるので、それについて一々自分を責める必要は無い。

どの本も、その著者も、読者の読みやすさや読者が期待している「物語性」を最大限考慮してくれるわけではない。そこは読み手側で調整したり、「あ～、もう、わかんねーもんはわかんねーんだよー！！！」と資源ごみのカレンダーをめくったりして、「好きなように対処して」全く問題ない。

ムーブメントに流されて購入した書籍の殆どが、読まずに廃棄処分

IT系は流行廃りが激しい。メディアとかBlogで暫く目立っていたのに、1年もすれば騒ぎも沈静化する。
「有名なBloggerの○○が推薦していたし、ムーブメントで周りが騒いでいるから、乗り遅れたくない、取り残されたくない」で購入した書籍。その殆どを、結局読まずに廃棄処分した。
まず上で書いたように、技術書にもさまざまなタイプがあり、読み手側で対応を調整する必要があるということを知らず、全てに対して全力でぶつかろうとしてしまった。「全力でぶつかる以上は、じっくり時間を取る必要がある」
・・・ドアtoドア片道1時間半～2時間、忙しくなってくると朝7時-8時起床、帰ってくるのは夜中の22-23時、しかも通勤ラッシュの電車を立ちっぱなしで1時間。
土日はその疲れを取るので精一杯。

ねーよ。全力でぶつかる時間なんて。

で、「いつか、いつか通読してムーブメントに乗ってやる」と思っていたらいつのまにかそのムーブメントは過ぎ去っているし、結局現場の業務でも使うことは無かったという罠。

メディアとかBlogが宣伝してるのは、結局のところ広告費とか、Amazonアフィリエイトが目的。もちろん善意はあるだろうし、より良い技術・書籍を世に広めるためというのもある。

けど、主体性無くそれに振り回されていると、ひたすら疲れるだけ。大丈夫。読まなくても、日は昇るし夜も来る。現場の仕事に対して誠実に取り組んでいれば、評価されるときもある。
外野がやいのやいの騒いでいるのは、ただのお祭り騒ぎなのだから、気にする必要は無い。
そんなの一々気にして、「オレもキャッチアップしなくちゃ取り残される～～～！！！」とか焦っていたら、きりが無い。

技術書をどう読むのかは読み手の勝手

本棚に積んでいる技術書を見るたびに、「これは○○の環境を整えて、あーしてこーして、それでようやく実験する準備が整うから、それをするには○○日かかって、だから今の仕事が一段楽してから・・・」と、心が勝手に反応する。
「いつか、いつか、読むから・・・読めば、何か得られるから・・・」
と、勝手に被害妄想を膨らませていく。
「時間が無い、時間が無いなんて、言い訳してるオレが悪いんだ・・・時間は作ればあるはずなんだ・・・」

ねーよ。

通勤でぼろぼろ。メディアだのBlogだので、「次はあの技術が、こんどはあの言語がアツイ」と振り回されて気疲ればかり。時間作る余裕なんてあるわけねー。

別にね、全力で読まなくて良いの。「まじめにサンプルコードは全て打ち込み、自分の目で動作確認して、一文たりとも見落としてはいけない」なんて、そこまで真剣にならなくて良いの。
「でも、斜め読みとか飛ばし読みしたら著者に失礼なんじゃ・・・？」
代金払ってるんだから、あとはどうしようが読者の勝手でしょ？
それよりも、あれこれ考えて結局一ページもめくらず、廃棄処分するなんて、そっちのほうがよほど、著者や本に対して失礼じゃない？旬のものは、旬のうちに頂かなくちゃ。
それならいっそ、斜め読みでも飛ばし読みでも良いからとにかく読んじゃって、その後で、それでピリオド打つか、もうちょっと深く読み直すか決めても良いんじゃない？

特に書籍のタイプ（手で打ち込む「学ぶ」系か、教科書系か、リファレンス系か）については、ざっと読んでみないと分からない部分もある。

最初から全力でぶつからず、まずはざらっと読んでみて、「この本に対して自分はどう付き合うべきか」を考えてみてから、リファレンスとして手元においておくなり、環境構築してサンプルコード打ち込むなり、不幸にも相性が悪ければとりあえずピリオド打って処分するなりしてみれば良い。

最初から真摯に真面目に全力でぶつかる必要は無いし、そのために時間を取ろうとして結局取れなくて、賞味期限が切れちゃう方がよほど勿体無い。

通読しても理解しきれない自分を責める必要は無い。もちろん読んでるうちに眠くなってしょうがなくとも。

全力でぶつかっても理解し切れなかった、置いてけぼりになった、後半よく分からなくなった、何度も眠りかけた・・・。
「自分の頭が悪いからだ・・・。本は悪くない、理解できない自分が悪いんだ。」

いーえ、あなたは悪くない。

じゃぁ本が、著者が悪いのかというと、そもそも誰が良い悪いの問題ではない。
ただ少なくとも、「読み始めたからには全て理解しないといけない」と自縄自縛することは間違い。
上に書いたように、どう読もうと代金を払った以上読者の勝手なのだから、難しい理屈とかすっ飛ばしてサンプルコードを目で追うだけ、とか、図とかタイトルの位置だけ把握する、とか、とにかく
「いい加減に読んでも、誰もあなたを非難する人なぞ居ない」
ってこと。たとえ読んでるうちに眠ってしまっても、授業中とか仕事中でなければ、誰もあなたを叱ったりしない。

「でもBloggerの○○さんが、記事で「プログラマならこれを読むべき」って書いてあったから購入した。やっぱり通読して理解しないと、プログラマとして失格じゃないの？」

大丈夫。誰もあなたを「ハイ、全部通読して理解できましたね、プログラマ試験合格でーす！」とか、「え～、まだあの本読んでないの？ってか、読んでも理解できなかったの？ばっかじゃね～？プログラマーなんてやめちゃえ！」とか、言いません。

全部、あなたが勝手に、自分自身の中で膨らませた妄想です。

確かに著者の力量不足はあったかもしれない。あるいは、理解に必要な最低限度の前提知識を持っていないあなたの準備不足があったかもしれない。
でも、本との付き合いは一種、「恋人探し」「恋人との恋の駆け引き」めいたところがあるため、どうしたって「理屈抜きでの好き・嫌い」「生理的にこの本とはやっていけない」というのは出てきてしまう。

なぜって、結局本の向こう側には、それを書いた、生身の人間、著者や編集者がいるわけだから。
好き嫌い、得手不得手はどうしたって出てきてしまう。

「なんか波長が合わないな、あるいは読者である自分が置いてけぼりにされてるな」とか、「この本を読みこなすにはまだまだ修行が足りないな、自分。」とか思ったのであれば、それについて深刻に自分を責める必要は無くて、むしろ「これ以上この本と付き合うにはどういう姿勢がベストか、あるいはどういう予備知識が必要か」、不幸なケースだと「だめ～～～、もう無理～～～！！どうしても読んでると眠くなる～～！！！」という場合ならいつ資源ごみに出すか、について考えたほうが建設的。

「でも、やっぱり○○さんの記事で紹介されてた以上は、読み込んで、それで得た知識で○○さんみたいなスーパーエンジニアになりたい！！」

気持ちはよく分かるのですが、「○○さん」は「○○さん」であって、読者と同一ではない。その本は「○○さん」にとってはベストな「My Lover」だったのかもしれないが、あなたにとってはイマイチだっただけ。そういうところ、恋人とか家族、仕事とよく似てる。

もちろん恋人や仕事と同様、本にも出会う時期とかタイミングはあると思います。ですので、他人が絶賛してる古典名著を今のあなたが読んで「さっぱりわからん・・・」となったとしても、将来読み返してみたときに「おお！！あのときはさっぱりだったが、今ならすらすら頭に入る！！！」という場合もあるかもしれません。

もしも他者の推薦を参考に購入した古典名著系で、「今」、理解し切れなかったとしても、そくざに資源ごみのカレンダーをめくるのは早すぎるかもしれません。その辺の匙加減は自分で調整・・・というか、何回か痛い目にあって体得するかも。（「あ～～～！！！何であのとき、あの名著をごみに出してしまったんだ～～！！！」とか。）

結局、周りのムーブメントに振り回されてるだけでは「苦しみ」が増えるばかり。

自分がIT技術者、それもWeb系出身というのが大きく影響していると思いますが、とにかく、"メディア"とか"スーパーエンジニアの○○さんが云々"というのに敏感に反応してしまいます。
で、ついついAmazonのリンクをクリックして、買ってはみたけれど、上述の通り読む時間が取れなくて、本棚で誇りを被っている・・・。

そして時々本棚に目を遣っては、「いつか読んでやる、いつか読んでやるから・・・」と誰にとも無く弁解している。

これ、「苦しい」だけですよ。

仕事で必要に駆られて購入した書籍であれば、そんなに時間をおかず目を通すはずです。

でも、「ネットでメディアが/スターエンジニアの○○さんが推薦していたから」って、あなたの日常とどーゆー関係があるんですか？
その本読まないと、仕事がストップしちゃいます？日常生活に甚大な支障が出ちゃいます？

顔、明後日の方向向いてませんか？
ちゃんと地面見てます？
目の前の、隣で頑張ってる、あなたの同僚とかお客さんの顔、目の前の仕事、見てます？

その上で、「いや、もう今の現場ブラック過ぎて付き合いきれない。転職の準備でスキルアップしときたい」ということでAmazonリンクをぽちっとな、ってーんなら話は分かりますが。

「ネットじゃみんな○○というプログラミング言語に手を出してる、自分も勉強しないと取り残される」と周りの動きに焦りを感じて不安に駆られたり、「これからのIT技術者たるもの、Linuxカーネルくらい読みこなせないと話にならないだろう」と自分勝手な妄想で勝手にIT技術者の「あるべき姿」のハードルを高くしたり。

全部、自分の勝手な脳内妄想っすよ。

一人褌の相撲取って、一人で勝手に疲れるだけっす。

そりゃまぁ将来に備えてある程度は新しい技術だのプログラミング言語に手を出しておくのは無駄ではないと思いますが・・・でもなぁ。

ぶっちゃけ、今の時点で「○○言語がHotだ！」とか騒いでいても、現場で普通に使われるようになる頃には別の「今度は△△言語がHotだ！！」ってなるんでしょ？

いや、確かに現状満足ばかりで新しいこと何も覚えたくないよー、ってゆーのはやはりどーかと思いますけど。・・・ちょっと寂しいです。
でも、それでも、「今の仕事や将来の仕事でこれこれこーゆー理由で必要になりそうだから、オレはこの技術書買って勉強する！」ってーのと、「今の仕事にはぜんぜん関係ないけど、ネットで有名な○○さんが/ニュースサイトの○○の記事が推薦してたから、自分も読まないと不安、買う！」ってーのとじゃ、やっぱり前者のほうが、まぁ・・・「苦しく」は無いだろうなぁと思うのです。

自宅警備員が偉そうに薀蓄垂れちゃいましたけど、それでも、ぶっちゃけ就職活動してないのはこうして「積み残した技術書」の消化に励んでいるからです。
だから・・・ふと、思ったりしちゃうんですよね。技術書読んで勉強してるだけよりかは、とっとと就職して世の中の役に立ったほうがよほどマシなんじゃないかなーと。
技術書つったって、ン万円もするわけじゃないです。
せいぜい２～３千円、高くても5千円台。
それを読みきるために、全て理解しようと全力でぶつかろうと気負ったがために、普通に就職して普通に働いていれば一日分の給与以下の書籍を「いつか読もう、いつか読もう」とぐちぐちと後回しにしていたがために・・・。

ぜんぜんペイしねーな。

と。ふと、思ったりするわけです。

そーなんです、技術書つったって、月給手取り15万としたって、１～２日分の給与にしか相当しないわけです。

そりゃ、買っちまった以上はないがしろにするのは勿体無いですが。だからといって、最初から真剣に全力でぶつかろうとしたって・・・１～２日分の給与相当ですよ？

だから、そこまで真剣に「通読して全て理解せねば！」と気負う必要は、なかったのかなぁ・・・って最近は思うのです。

• [ Prev ]
• [ Next ]
• [ 技術 ]

fork(), setsid(), ファイル記述子のclose()などを処理するdaemonize()関数を使った、daemon習作。
単にログファイルにPIDとかPGIDをprintf()し続けるだけ。

参考：APUE, Chapter13, Daemon Processes

• [ Prev ]
• [ Next ]
• [ 技術 ]

何をいまさら当たり前の事を・・・と思われるだろう。

$ nohup long_run_batch.sh &

SSHからログアウト後も実行を続けたいバッチジョブを、"&"を付けてバックグラウンドジョブとしてnohupから起動するのは定番中の定番である。

しかし、「nohupを使わなくても実行を続けることが出来る」やり方があったり、さらには「nohupを付けてもログアウト時に終了してしまう」パターンがあるとしたらどうだろう？

そして、ある日あなたの後輩や同僚がこれらについてあなたに質問してきたら、あなたはどう答えるだろうか？

「Web上で検索したら見つかったのでそれに従ってる」

と答えてお茶を濁すだろうか？
それとも、

「OK, いい質問だ。それはシェルが終了時にSIGHUPをだね・・・」

のように理路整然とした華麗な語り口で受け答えるべきだろうか？

「お茶を濁せればそれでよい」と答えた方、あるいは「よし、じゃぁ一緒にBashのソースコードやプロセス終了時のカーネルのソースを追ってみようか。おっとその前にSUSv3をベースに端末制御とSIGHUPについて復習だ・・・」と颯爽とリードできる人はこの先読む必要は無い。

• エンジニアのジレンマ ～悩む立ち位置と仲間の境界～：第12回　エンジニアの信頼性を考える｜gihyo.jp … 技術評論社
  • http://gihyo.jp/lifestyle/serial/01/dilemma/0012

これ読んでて気になったのが

エンジニアの信頼性は長く仕事をしていると，ある程度決まってくるものです。
平たくいうと，仕事を安心して任せられる人と任せられない人に分かれてきます。

これ、結局「本人が勉強しなかったからアイツは使えねー。」で切り捨てる考え方なのか？
「使えるエンジニア」「使えないエンジニア」でばっさり区別して、「使えないエンジニア」は「ハイ、サヨウナラ」で済ますってこと？
でさ、結局は「使えるエンジニアに成長できる会社に就職して、そうした仕事を与えられて、ぐんぐん勉強して伸びた人間」と「成長できない場末の会社に就職して、運悪く保守作業ばっかりで、勉強する機会を与えられなかった人間」でもうバッサリ、ってこと？

あまりにも、あまりにも救いが無い。

100%の性能・品質を目指すばかりに、「ぼちぼち」「ほどほど」を切り捨てた結果、異常にコスト高になったり人への依存度が高くなりすぎて身動き取れなくなったりとか、どっかで見た風景じゃない？
それよりも「ぼちぼち」「ほどほど」だけど量は大量に供給されてる部品を使って、「まぁまぁ」の品質で大量生産した方が良いっつー意見は無し？

短所だけ見て、長所には目もくれず「アイツは使えないやつ」ってラベリングした可能性、無いと言い切れる？

「デキるエンジニア」「デキないエンジニア」って切り分けるんなら、その判断基準はどこよ？
どこまで知ってれば、実際に手を動かせれば良いの？んなもん環境で変動する至極いい加減な基準じゃないの？
突き詰めれば、コンパイラを機械語だけで作れて、OSも機械語だけで作れて、アルゴリズム系も全て機械語だけで実装できて、CPUの論理回路をVHDLでさくっと作れて、周辺I/O用の回路も全て作れるやつ？

そのレベル、ホイホイいるわけねーだろ。

ほどほどの、あるいは品質にばらつきのある部品をうまく組み合わせて、ほどほど満足できる成果を出すやり方って無いの？ある程度の欠陥があっても、「まぁ死ぬわけじゃないし、いいよねー、あっはっはー。」で済ませる寛容さって無いの？・・・いや、人命に直結する分野はさすがに無理だろうけど。

なんなんだよ、この地獄。ほんと現世は地獄だぜﾌｩｰﾊﾊﾊｧｰ。

・・・あ。そーゆー会社、一つだけ知ってたわ。さすがにそこまでのどかなわけじゃないけど、「うちはうち、他は他」って感じの割りきりが、わりとこう「アッサリ」とした雰囲気で朗らかに感じられる、珍妙な会社。
不幸にもご縁が無く入社叶わなかったけど、あそこの雰囲気というか、「まぁぼちぼち自分たちなりのやり方でいきましょうや」って感じの、とかいいつつちゃっかりiPhoneとかAndroidにも抜かりなく手を出してるあのセンス、いつまでも変わらないでいてほしいなぁ。