  |
はてなキーワード:オライリーとは
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
---
この週のオープンチャットは、生活・仕事・家庭・技術が自然に交差する現代生活のスナップショットとなった。
AIや経済への高い関心とともに、家族・子育て・住宅など身近な現実的テーマが根強く語られているのが特徴。
テクノロジーが進化しても、最終的に焦点は「人と人の関係」「生活の実感」「安心して暮らすこと」に戻る流れが一貫して見られた。
全体として、情報感度の高さと共感力の両立が感じられる成熟したコミュニティの会話であった。
https://anond.hatelabo.jp/20240722084249
ちょい前にAIのポチョムキン理解って言ってたけど、正直厄介で致命的なのは、エンジニアのポチョムキン理解なんだよな。
オライリーとかWeb記事とか、「読みました」「理解しました」って議論してる。
「うちは最新の関数型プログラミングを採用して非同期処理を導入しています」
「マイクロサービスに切り分けて、疎結合にしています。そうですね。今でサービス数は120をちょっと超えたところです」
「分散型DBを使って処理速度を上げています。PKは前テナント通してUUIDを使って適切にばらけさせています」
正しく理解できていれば、炎上もしないし、新機能投入、要件変更も容易に行えるはずなのに、それができない。
クライアントが増えてデータ量が多くなってくると処理に時間がかかるようになっていく。
炎上の原因。
停滞の原因。
理解できてるはず正しいはずという思い込みがあるから、「今の炎上停滞状態が異常だ」と思い至らない。
「前にいた某社ではこうやっていた」
って見よう見まね、行動だけなぞって、本来目的とされていた効果が一切得られない、カーゴカルトエンジニアリングもそう。
そうして積み上げられたデブでよろよろのサービスが、今大量にあるのだよな。
これ、なんとかできるかって聞かれたら、規模がデカすぎて、どうせお前ら、なんで新機能も増えないのにこんなに金がかかるんだよ！ ってキレるだろ？ ってんで、やりたくねぇ。
10年ほど前の規模と複雑度ならなんとかリーズナブルになんとかできたけど、そろそろ無理になってきてる。
オライリーの本ばかり読んでるITエンジニア、沢山オライリーの本読んでるアピールするのはいいんだけど、特定分野であまり活かされてない印象。
オライリーにはマネジメント分野やチームビルディング系のラインナップも沢山あるし、自分もそのジャンルも読んではいるんだけど、あまり参考になった試しがない。
というよりそのままでは使えない、自分の中で現場とのすり合わせをして利用可能にするためのプロセスが必要でそのコストが高いものが多い。
と言うのは、やはり海外翻訳版なので、企業というスコープでもチームというスコープでも日本にマッチしない内容が多すぎるから。
文化や環境が違うのに、ある人は書いてあることそのまま実践しようとしたり、「オライリーのなになににはこう書いてありました」なんて言って、自分の頭で考えることなく無条件に受け入れてもらえると思っている。
ある人は、オライリー読んだアピールを頻繁にするもののうまくいかないばかりか、空回りばかりで、いかにもITエンジニアっぽい振る舞いしてるなぁって思ってる。
日本の開発環境でチームや組織を良くしていきたいなら、せめて日本のマネジメントの本も読んでみてはどうかなって思うけど言わない。小心者だから。
実際そう言う人に、どんな書籍やドキュメント参考にしてるか聞くと大体オライリーか海外翻訳本しか読んでないし、なんなら本自体そういうの以外はあまり読まないらしい。
読書はあまりしない、時間をかけるならハズレを引きたくない、エンジニアに人気のオライリーならエンジニアに特化した有益な情報を得られそう、ってどこなんだと思う。
誤解しないで欲しいのは、オライリーには良い本はあるし、自分も沢山読む。けれど当たり前だけど中にはよくないと感じる本はあるし、日本にあってないなと思うものも多いってこと。
特にマネジメント系組織系の本を頑張って読んでる人たちが実際うまく行ってないからな。
ダメかダメじゃないかの責任なんて取れないけど、オライリー読んでわかった気になるより、ダメな本にツッコミ入れて反面教師にしてみるのもいいんじゃないか。
全てが異なるスペシャルな処理の対象(ドメインオブジェクト)に見えるSIer崩れは、
なんたるかを
まるで分かって
いないな
ゲームプログラマなら、色違いポケモンみたいなデータの準備はとりあえず置いておいても、メインのゲームシステムを先に設計実装するものだが、そういう感覚が全くなく、一個一個スペシャルな処理を考えて書く。
メリハリなく全てを平面上にばら撒いて片っ端から実装するとか、計画的とか組織的とか構造的とかいう知性的な世界の対極の住人だな。
なぜそれで、「エンジニア」を自称できるのか、さっぱりわからん。
恥ずかしくないのか？
それでなぜDDDを名乗る？
机の上にオライリー本とかこれみよがしに置いてあるけど、説明のためのサンプルコードを理解もせずつまみ食いしてドヤ顔してんじゃねぇよ。
ファイアは使えるようになったんだけど。
YouTubeみても偽動画ばっかりでファイアすら使えてないから参考にならんし。
今の現場で信奉されているんだが、おいおいおいおい、考える頭がねーな、AIに駆逐されてぇのか？SIer仕草のままじゃねーか。
と呆れてものも言えん。
90年代の、箱庭的な単機能小規模完納プロダクトなら帳票・画面駆動開発で十分だったが、常に成長し続ける宿命を背負った多機能なWebサービスでは、帳票や画面遷移、デザインから立ち上げたら、絶対に発生する手戻り、仕様変更についていけなくなるだろ？ ってアンチテーゼとしてドメイン駆動開発が提案されたんだけどな。
手戻り、仕様変更はドメインのコンセプト、概念に沿って発生する。
というのが基本アイディアだ。
帳票・画面という具象はあえて捨象し、コンセプトという抽象に昇華することが本質ということだ。
抽象思考に不自由なエンジニアが、すぐに具象に飛びつきたくなるのはわからんではないが、それによって以前の帳票・画面駆動開発のマイナスが消せてるか？ w
画面、帳票のグルーピングをしてるだけじゃねーか w
本当のDDDの観点からすれば、帳票・画面は、ドメインコンセプトの一断面での切り出しに過ぎない。
如何様にも切り出せる。
足りなきゃアトリビュートを追加すれば済む。
手戻り、仕様変更なんて、道端の犬糞の向きを変えるほどの手間ですらない。
一旦ドメインコンセプトを実装したら、他の機能のほとんどは、それをどう適用するか、パラメータレベルの違いしかない。
ドメインコンセプトレベルで検証(テスト)すれば、いくら機能が増えようが、パラメータの検証だけで済む。
Doyou understand ?
こちとら、オライリー本のつまみ食いとか三下が書くWeb記事をありがたがって鵜呑みしてやってるわけではない。
他のいろんなエンジニアが同じことに悩み始めていた20年以上前、クライアントの先輩エンジニアにヒントをもらって始めた内容だ。
当時、上司の設計で交渉を続けていたが、毎度毎度仕様変更が入り、何かずれているんでしょうか？ と聞いた。
「君は僕たちの業務を理解できてない。僕たちにとって〇〇がどういうものか。僕が足りないと感じるのは、君がその要素を理解できていないからだ」
とヒントをくれて、気がついた。
「僕たちにとって〇〇がどういうものか」
つまり、その業務(ドメイン)のコンセプトを無視したら、利用者が本当に欲しいものが実現できないし、手戻りが発生したら対応できないし、変更についていけない。
そりゃ当然だ。
そのドメインのコンセプトの集合体、「ドメイン世界」と一致してないから。
手戻り、仕様変更、いずれにおいても障害が生じるのは、そのねじれのせいだからだ。
コピペして無意味な消し忘れをしたジュニアのエンジニアをカーゴカルトプログラミングと笑う無能エンジニアをたくさん見てきたが、この手のWebの何の根拠もない言説を鵜呑みにして、検証することもなく、HowToの上っ面だけをなぞる猿こそ、何百倍も罪深いカーゴカルトエンジニアだと、自覚しろよ。
お前のことだよ。
お前の語るのはDDDじゃない？
ITなどではしゃいでる人をみると必ず、冷や水をかけに現れるブクマカがいる。
昔は存在しなかったこういう人たちが、ITをつまらなくしてる側面は確かにあると思う。
はてブでもマンガとかのジャンルとかでは、ハラスメントは注目コメントに入ってこない。
最近では、注目ブコメで露骨に暴言、ハラスメントしてくる奴らも増えた
足引っ張り屋のせいでオモテで素直にはしゃげない
私は統合失調症患者で、人生に迷いを感じることがある。そのため、自己啓発本を買ったこともある。
しかし、生活で実践するレベルの話だと、本を読まずとも英語でググって「こういう習慣を身につけると○○に効果があるというエビデンスがある」ぐらいの情報は山のようにある。
そして有限の精神と時間の中では実践できる内容にも限りがあるから、あまりたくさんやろうとしても疲弊するだけである。
それこそ謙虚さを身につけるという意味において、よくわからない自己啓発本より聖書の箴言のほうが実りは多いだろう。
私はプログラマーなので技術書も読むことはあるが、周辺の本屋で売っているような本を買うぐらいならオライリーを探したほうが良い。
オライリーの時代背景としては、ヘルシープログラマーが売られていた頃の空気感が好きだ。「生きていく上で健康に気を配る必要がある」というあたりまえのことに気がついていなかった当時。
そういえば人間関係は幸福度のために最も重要な要因の一つらしい。私にとって両親や兄弟、そして飼っている🐶は大切な存在である。
といっても私はすでに結婚することは諦めている。統合失調症患者の遺伝子を残しても、誰も喜ばないだろう。
今日はまず朝起きて冷水を浴びた。最近この習慣を続けているが、眠気が一気に冷めてパワー全開になる。
そして行こうか迷っていたインドカレー屋に行った。ベジタブルカレーの中辛を選んだが、これまた旨い。
帰りに本屋へ寄ったが、買いたくなるような本は見つからなかった。正直、自分でもどういう本を求めているかはっきり言語化できない。ただ「これじゃない」ということがわかるだけだ。
自費や会社の補助で技術書を購入している。オライリーとか翔泳社とかSBプロダクツとか色んなとこの。推薦図書とか書泉とかで見かけて買ったり一貫性も無い
なるべく読んだりハンズオンをやってみたりしたんだが、どんどん面白そうな本も出てきて買っては積んである。読むのは苦じゃないくテンポよく読み終えているが読み終わった本の処分に悩んでいる
知り合いとかは裁断してスキャンしてPDFにして切ったのをメルカリで売ってるようだが自分は紙をめくるのが好きだったりPDFだとなんか読まないのとスキャン環境を持っていないので出来ないと思っている
実際読んでから見直さない本もあるのだが処分してからやっぱ読みたくなるとかもありそうでなかなか踏ん切りがつかない
部屋の本棚の容量もあるので処分はしたいのだけど同じような悩みの人はスキャン以外ではどうしてたり、どういう本は処分してるのか参考にしたいから教えてください
定期的にはてブやSNSを見ているとITエンジニアの投稿を見ることも多いだろう。それを見ると色んな感情が湧くと思う。
これ以外にも色々あるだろうが端的に言うと自分のITエンジニアとしての偏差値が低いんじゃないか？って思うことが多いのではないか。
そんなわけ無いぞ。上に書いているようなレベルの人ってホント上澄みレベルで世間のエンジニアが全員勤勉だと思うなよ。
あと結果のみアウトプットしているから凄い事スラスラしているように見えるけど、実際はインプットからアウトプットまでに時間結構あるぞ
結構気にしてあれこれ手を出して潰れる人を見てきたし、じゃあ自分はその上澄み除いた部分でどの辺なんだって拘る人も居るのでいくつかアドバイス
エンジニアあるある。応用なんて学生が取るもの。高度でやっと書類に書ける。んな訳ない。あの時代遅れ試験を午前午後クリアできるエンジニアは少ない。ITパスポートだって立派。業界変われば評価も変わる。取らないけど凄い人も居るけど大半の凡人は取ることで土台が固まる。IPAでもベンダーでも興味のあるものは取ろう。転職エージェントが何を言おうが資格の目的はその技術の知識の確認だ。
上澄みの人の業務形態は様々だ。経営者、正社員、フリーランス。職場によっては業務中の勉強も可能だったりする。フリーランスなら仕事も勉強も自由だ。その相手と同じ環境でも無いのに自分もやろうと捻出して睡眠時間削っても意味ない。ある日2時間やるより毎日10分で良い。重要なのは今の稼ぎ。努力教信者が意味なく努力しろと言うけど気が向いたときにやれば良い。週末に遊びと勉強あったら遊び取れ。仕事のパフォーマンス最優先。
最新技術キャッチアップしてサンプル作ってって焦るだろうけどとりあえず本読もう。読み終わって全部知ってるわ！って本かも知れないが今はメルカリで売れるから傷は浅い。オライリーの本を手あたり次第買って積むのは焦った人が良くやるパターンだけど、とりあえず自分が興味ある分野の本を1冊買って読もう。はてブにはだいたいこの季節に上澄みの方が書いた読んだ技術書を書評付きで載ることが多い。そこから1冊選んで読む。ハンズオンあるなら自宅のPCでやる。やり切ったらぶっちゃけだいぶ偉い。業務じゃ使えないとか言われるけど基本と実際はどこが変わるか分かるだけでもだいぶ役に立つ。ちなみに裁断してPDFにするのは個人的にはお勧めしない。電子化するとマジで読まない。個人差あるけど
もちろん年収1000万とか稼ぐフリーランスとかは無理だけど緩やかなキャリアアップ目指すなら基本情報持ってれば良いのよ。マジで社会には自分達より手に技術持ってないくせに年収1000万越えの変な人多いよ。だから企業案件で現場に行ってプロジェクトの全体像も分からず毎日コード書いているだけで漠然とした不安を抱えているなら一足飛びではなくまずは土台を固めよう。レーダーチャートのどっか1か所だけ飛びぬけるのはマジで選ばれた人間。大半は平均的に高めるしか無いよ。焦んな、何もやらないのは駄目だけどコスパは求めるな。
