はてなキーワード: オライリーとは
しかも「3分間待ってやる」レベルのフラグ追加とかの小さい機能だとか。
そのくせ、オライリー本やWebページの1行をとりあげては先輩エンジニアに噛み付く、噛み付く、噛み付く、お前は狂犬病野犬か? って勢いの新卒女性エンジニアがいるとか聞いて、大学は何を教えてるんだ? って暗澹たる気持ちになった。
ここは地獄か?
たかがWebページ、誰が書いたかわからんし、内容が正しいとは限らん。
同じ内容がたくさんあるからといって、オリジナルをコピーして増殖しただけの水増し記事でないとは限らん(一時期の技術系ブログ、この手の文末だけ修正したコピー記事が結構あったんだよな。最初の記事が和訳ミスって、間違えた内容が日本語では増殖してたりね)。
オライリー本だって、内容が結構でっち上げというか、本の厚さを増やすために無理やり追加した適当な内容やなー、ってのもあれば、日本語オリジナルの技術本ではありえない内容のも結構発行されてる。
内容が正しかったとして、前提条件が同じでなければ目の前の事態に適用できるとは限らん。
背後の、というかご本尊の構造を理解できないで、表面的に言葉を弄ぶだけってのは、エンジニアじゃない。
誰も見て見ないふりしてるけど。
問題は繋がっていて、ごく単純な話。
「この規模、この内容のサービスで、なんでこんなにエンジニアが大量にいるんだろう?」って疑問は、どこにいっても、どこと話しても、わく。
先日の才能問題がまさにそうなんだけど、ソフトウェアエンジニア業界に滞留している人、ぶら下がってる人が多すぎやしないか? と。
リモートをいいことに、サボりまくってる「エンジニア」、特に最近は生成AIででっち上げてサボれるようになってからは、まぁまぁの数、存在していると思う。
実際に観測してもいるし。
そういう極端な例に限らず、才能がない、向いてない「エンジニア」が相当数寄生している。
ジュニアとかコーダーレベルだけじゃなく、いや、むしろリーダー、マネージャー、CTOレベルに。
その組織、企業のそのレベルの「エンジニア」が、それに占拠されたら、多分事態が好転することはない。
アリバイづくり程度の活動は行われるだろうが、永遠の停滞に陥るだろう。
誰か一人抜けても、残りがスクラムを組んで、異分子を排除することに全能力を傾けるだろうから。
まさに獅子身中の虫。
「あの企業が?」ってところが、すでにそう言う状態に陥ってたりする。
名前はあげられないけど w
政府はソフトウェアエンジニアが足りない足りないって喚いてるけど、頭数だけ用意しても現場、プロダクトが混乱するし、利用者が困るだけだ。
これ、旧日本軍の失敗の原因であった「員数主義」って言うんよな。
正直、「え? ソフトウェアエンジニア……? を名乗って……んの……?」って人が多い。
語るけど。
延々と語るけど。
滔々と語るけど。
毎度毎度、会議室でMCバトルの、青菜に塩をかけたような真似事をして。
誰が一番最初に、新しいイケてるWebページを見つけたかを競って、ドヤ顔くらべ。
勉強会開いてみたり。
この量と質か?
みたいな。
多分、この手の「エンジニア」の半分以上が、人手不足の工場とか大工とか解体業とかライフライン保守に行ってるべきだったんだろうな、と思う。
どっちが上とか下とか言う話じゃなく、向き不向きの話。
向いてないんよ。
多層抽象化に不自由とか、概念構造の構築に不自由とか、専門書とかの読解に不自由とか。
2、30年ほど前はそこまでの能力がいらなかったからうまくエンジニアに滑り込んだ人もいただろうけど、今時のプロダクトでそれでは通用しないんだよね。
SQL文の書き方とか、DockerFileの書き方とか、ソースファイルのタブの入れ方とか、Web記事のある場所とか、ディレクトリ構成とかの形式的な知識とか、マジで、あったから何? って。
大事なのは形式的な知識じゃなく、本質的な理解とメタ思考なんだよね。
お前なんていらない。
それだけ。
使いたいっすよね。
って、よく言われる。
この言葉のままじゃないけど、まぁ、だいたいこういったニュアンスだ。
自分はそこそこの腕だと思うなら、彼我の実力の差は正しく測れるようになっとけよ。
こちとら、「だいたいこういう実装されてて、長所短所はこんなもん。こういう処理のために作られたようなもんだな。だから、今のプロダクトだと使い所がないね。料金も高いし」あたりまでチェック済みじゃボケ!
ってことしかない。
こいつら、自分の業務経歴書に書き込む単語を増やすことしか考えてねぇんだよな。
関連サービスなんて増やせば増やすほど、保守運用改善が大変になっていくだろ!
経費もかかるだろ。
「仕組み」は、よりシンプルな方法で実現できるならシンプルな手段を選べ、ってのは常識中の常識だろ。
「KISSの原則? 知ってますよ」って、知識として知ってる。
KISSが"Keep it simple, stupid"の略だってことを知っている。
けど実現できないんじゃぁ意味がねーんだよ。
この手の「自分はイケてると錯覚しているエンジニア」は、Web記事つまみ食いしながら雰囲気で設計実装するから、リクエストやデータが増えてきたら破綻するような、間違えた設計実装しかできない。
そういう新しいサービスは、それ以前のサービスの欠点を埋めるために作られてるんだから、それ以前のサービスと同じノリで設計実装して十分な性能を引き出せるわけがねーんだわ。
今までの複数の炎上現場で、正しく設計実装できてたところはなかったよ。
おいらが関わった炎上現場はほとんど、こうやって生まれてきている。
そういう炎上現場を作り出したエンジニアは、ふくらし粉で増量した業務経歴書片手に、「サービスの立ち上げを『僕の技術力で』やり切りました」って転職していくんだ。
新しいことに挑戦したくなって。とか言って。
みたいなエンジニアを、なぜどこもかしこもありがたがって採用するか全く理解できないんだが、そういう「エンジニア」が次の現場で生まれ変わったように的確で素晴らしい成果を出せるかって、そんなわけもなく、日をおうごとにグダグダになっていくサービスがさらに一個増えるだけだったりする。
こういうエンジニアが、初回リリースしてからしばらくして、ソフトウェアエンジニア業界に飛び散る。
まるでがん細胞。
こうなると立て直すスピードより、グダグダな新しいサービスが生まれるスピードの方が何十倍、何百倍も早い。
もうね、半ば絶望してるんですよ。
今、生成AIも参戦してきてて、物量だけは爆発的に増えてるから。
多分、そう遠くなく、グダグダサービスで日本は覆われると思う。
AIベビーシッターが必要になってくるだろうけど、それができるだけの技術力を持ったエンジニアの数が圧倒的に少ないし、何よりそういう腕利のエンジニアを、ふさわしい金額で雇おう、招こうと考える経営者が皆無。
今までの炎上現場ですら、高すぎる。無駄金を払わされてる。って扱いをうけてたからな。
「同じエンジニアなのに、どうしてこんなに高いの?」
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が? それとも自分が? w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか?
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
ちょい前も、PostgreSQLの中身いじれます! って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ!
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か?
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね? w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
はっきりいう。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス? w
才能のない人は河岸変えろ。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの?」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか? って聞いてんねんけど……。
って現場、多い。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は?」
「……デプロイの時、どうすんの?」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「Cloneして立ち上げます」
「これ……、モノリポ?」
「120個?」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、++のブランチを……」
5日で立ち上げ切れるんか?
って現場がね、案外たくさんあるんだ。
「ほう……?」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは?
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は?」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
LINEオープンチャット「はてなブックマーカー」の1週間分の要約を、さらにAIを使用し、試験的にまとめまています。
---
この週のオープンチャットは、生活・仕事・家庭・技術が自然に交差する現代生活のスナップショットとなった。
AIや経済への高い関心とともに、家族・子育て・住宅など身近な現実的テーマが根強く語られているのが特徴。
テクノロジーが進化しても、最終的に焦点は「人と人の関係」「生活の実感」「安心して暮らすこと」に戻る流れが一貫して見られた。
全体として、情報感度の高さと共感力の両立が感じられる成熟したコミュニティの会話であった。
https://anond.hatelabo.jp/20240722084249
ちょい前にAIのポチョムキン理解って言ってたけど、正直厄介で致命的なのは、エンジニアのポチョムキン理解なんだよな。
オライリーとかWeb記事とか、「読みました」「理解しました」って議論してる。
「うちは最新の関数型プログラミングを採用して非同期処理を導入しています」
「マイクロサービスに切り分けて、疎結合にしています。そうですね。今でサービス数は120をちょっと超えたところです」
「分散型DBを使って処理速度を上げています。PKは前テナント通してUUIDを使って適切にばらけさせています」
正しく理解できていれば、炎上もしないし、新機能投入、要件変更も容易に行えるはずなのに、それができない。
クライアントが増えてデータ量が多くなってくると処理に時間がかかるようになっていく。
炎上の原因。
停滞の原因。
理解できてるはず正しいはずという思い込みがあるから、「今の炎上停滞状態が異常だ」と思い至らない。
「前にいた某社ではこうやっていた」
って見よう見まね、行動だけなぞって、本来目的とされていた効果が一切得られない、カーゴカルトエンジニアリングもそう。
そうして積み上げられたデブでよろよろのサービスが、今大量にあるのだよな。
これ、なんとかできるかって聞かれたら、規模がデカすぎて、どうせお前ら、なんで新機能も増えないのにこんなに金がかかるんだよ! ってキレるだろ? ってんで、やりたくねぇ。
オライリーの本ばかり読んでるITエンジニア、沢山オライリーの本読んでるアピールするのはいいんだけど、特定分野であまり活かされてない印象。
オライリーにはマネジメント分野やチームビルディング系のラインナップも沢山あるし、自分もそのジャンルも読んではいるんだけど、あまり参考になった試しがない。
というよりそのままでは使えない、自分の中で現場とのすり合わせをして利用可能にするためのプロセスが必要でそのコストが高いものが多い。
と言うのは、やはり海外翻訳版なので、企業というスコープでもチームというスコープでも日本にマッチしない内容が多すぎるから。
文化や環境が違うのに、ある人は書いてあることそのまま実践しようとしたり、「オライリーのなになににはこう書いてありました」なんて言って、自分の頭で考えることなく無条件に受け入れてもらえると思っている。
ある人は、オライリー読んだアピールを頻繁にするもののうまくいかないばかりか、空回りばかりで、いかにもITエンジニアっぽい振る舞いしてるなぁって思ってる。
日本の開発環境でチームや組織を良くしていきたいなら、せめて日本のマネジメントの本も読んでみてはどうかなって思うけど言わない。小心者だから。
実際そう言う人に、どんな書籍やドキュメント参考にしてるか聞くと大体オライリーか海外翻訳本しか読んでないし、なんなら本自体そういうの以外はあまり読まないらしい。
読書はあまりしない、時間をかけるならハズレを引きたくない、エンジニアに人気のオライリーならエンジニアに特化した有益な情報を得られそう、ってどこなんだと思う。
誤解しないで欲しいのは、オライリーには良い本はあるし、自分も沢山読む。けれど当たり前だけど中にはよくないと感じる本はあるし、日本にあってないなと思うものも多いってこと。
特にマネジメント系組織系の本を頑張って読んでる人たちが実際うまく行ってないからな。
ダメかダメじゃないかの責任なんて取れないけど、オライリー読んでわかった気になるより、ダメな本にツッコミ入れて反面教師にしてみるのもいいんじゃないか。
全てが異なるスペシャルな処理の対象(ドメインオブジェクト)に見えるSIer崩れは、
なんたるかを
まるで分かって
いないな
ゲームプログラマなら、色違いポケモンみたいなデータの準備はとりあえず置いておいても、メインのゲームシステムを先に設計実装するものだが、そういう感覚が全くなく、一個一個スペシャルな処理を考えて書く。
メリハリなく全てを平面上にばら撒いて片っ端から実装するとか、計画的とか組織的とか構造的とかいう知性的な世界の対極の住人だな。
なぜそれで、「エンジニア」を自称できるのか、さっぱりわからん。
恥ずかしくないのか?
それでなぜDDDを名乗る?
机の上にオライリー本とかこれみよがしに置いてあるけど、説明のためのサンプルコードを理解もせずつまみ食いしてドヤ顔してんじゃねぇよ。
今の現場で信奉されているんだが、おいおいおいおい、考える頭がねーな、AIに駆逐されてぇのか? SIer仕草のままじゃねーか。
と呆れてものも言えん。
90年代の、箱庭的な単機能小規模完納プロダクトなら帳票・画面駆動開発で十分だったが、常に成長し続ける宿命を背負った多機能なWebサービスでは、帳票や画面遷移、デザインから立ち上げたら、絶対に発生する手戻り、仕様変更についていけなくなるだろ? ってアンチテーゼとしてドメイン駆動開発が提案されたんだけどな。
手戻り、仕様変更はドメインのコンセプト、概念に沿って発生する。
というのが基本アイディアだ。
帳票・画面という具象はあえて捨象し、コンセプトという抽象に昇華することが本質ということだ。
抽象思考に不自由なエンジニアが、すぐに具象に飛びつきたくなるのはわからんではないが、それによって以前の帳票・画面駆動開発のマイナスが消せてるか? w
画面、帳票のグルーピングをしてるだけじゃねーか w
本当のDDDの観点からすれば、帳票・画面は、ドメインコンセプトの一断面での切り出しに過ぎない。
如何様にも切り出せる。
足りなきゃアトリビュートを追加すれば済む。
手戻り、仕様変更なんて、道端の犬糞の向きを変えるほどの手間ですらない。
一旦ドメインコンセプトを実装したら、他の機能のほとんどは、それをどう適用するか、パラメータレベルの違いしかない。
ドメインコンセプトレベルで検証(テスト)すれば、いくら機能が増えようが、パラメータの検証だけで済む。
Do you understand ?
こちとら、オライリー本のつまみ食いとか三下が書くWeb記事をありがたがって鵜呑みしてやってるわけではない。
他のいろんなエンジニアが同じことに悩み始めていた20年以上前、クライアントの先輩エンジニアにヒントをもらって始めた内容だ。
当時、上司の設計で交渉を続けていたが、毎度毎度仕様変更が入り、何かずれているんでしょうか? と聞いた。
「君は僕たちの業務を理解できてない。僕たちにとって〇〇がどういうものか。僕が足りないと感じるのは、君がその要素を理解できていないからだ」
とヒントをくれて、気がついた。
「僕たちにとって〇〇がどういうものか」
つまり、その業務(ドメイン)のコンセプトを無視したら、利用者が本当に欲しいものが実現できないし、手戻りが発生したら対応できないし、変更についていけない。
そりゃ当然だ。
そのドメインのコンセプトの集合体、「ドメイン世界」と一致してないから。
手戻り、仕様変更、いずれにおいても障害が生じるのは、そのねじれのせいだからだ。
コピペして無意味な消し忘れをしたジュニアのエンジニアをカーゴカルトプログラミングと笑う無能エンジニアをたくさん見てきたが、この手のWebの何の根拠もない言説を鵜呑みにして、検証することもなく、HowToの上っ面だけをなぞる猿こそ、何百倍も罪深いカーゴカルトエンジニアだと、自覚しろよ。
お前のことだよ。
お前の語るのはDDDじゃない?
ITなどではしゃいでる人をみると必ず、冷や水をかけに現れるブクマカがいる。
昔は存在しなかったこういう人たちが、ITをつまらなくしてる側面は確かにあると思う。
はてブでもマンガとかのジャンルとかでは、ハラスメントは注目コメントに入ってこない。
最近では、注目ブコメで露骨に暴言、ハラスメントしてくる奴らも増えた
足引っ張り屋のせいでオモテで素直にはしゃげない
私は統合失調症患者で、人生に迷いを感じることがある。そのため、自己啓発本を買ったこともある。
しかし、生活で実践するレベルの話だと、本を読まずとも英語でググって「こういう習慣を身につけると○○に効果があるというエビデンスがある」ぐらいの情報は山のようにある。
そして有限の精神と時間の中では実践できる内容にも限りがあるから、あまりたくさんやろうとしても疲弊するだけである。
それこそ謙虚さを身につけるという意味において、よくわからない自己啓発本より聖書の箴言のほうが実りは多いだろう。
私はプログラマーなので技術書も読むことはあるが、周辺の本屋で売っているような本を買うぐらいならオライリーを探したほうが良い。
オライリーの時代背景としては、ヘルシープログラマーが売られていた頃の空気感が好きだ。「生きていく上で健康に気を配る必要がある」というあたりまえのことに気がついていなかった当時。
そういえば人間関係は幸福度のために最も重要な要因の一つらしい。私にとって両親や兄弟、そして飼っている🐶は大切な存在である。
といっても私はすでに結婚することは諦めている。統合失調症患者の遺伝子を残しても、誰も喜ばないだろう。
今日はまず朝起きて冷水を浴びた。最近この習慣を続けているが、眠気が一気に冷めてパワー全開になる。
そして行こうか迷っていたインドカレー屋に行った。ベジタブルカレーの中辛を選んだが、これまた旨い。
帰りに本屋へ寄ったが、買いたくなるような本は見つからなかった。正直、自分でもどういう本を求めているかはっきり言語化できない。ただ「これじゃない」ということがわかるだけだ。
俺も一応ITに関わる仕事してるけど、オライリーってほとんど持ってないな。純粋なコンピュータサイエンスって興味ないんだよなあ正直。