はっきり言って、JavaのほうがRubyよりもぜんぜんマシな道具だ。昔のエンプラJavaが愚鈍だったのは、まあ時代のせいだろう。開発環境とかフレームワークは進化してるんじゃないか?知らんけど。すくなくとも言語自体は、Javaのほうがはるかにクリーンな枠組みを用意しやすいと思う。
しかしながら、低コストで実践可能なエンジニアリングだけが、役に立つエンジニアリングであるとは思う。さもなくば単に実行されない。
Ruby on Rails長年使ってるけど、見かたによっちゃ実践的なフレームワークではあるのかもしれないけど、あれを使ってる限り理想のエンジニアリングなんて、なんにもできやしないんだよな。あと開発者のデバッグ時間を無駄に長びかせることをRailsは得意としすぎてる。よってRailsなんて大嫌いである。
継続的デリバリーすばらしい本なんだけど、運用チームとデリバリーチームが分かれてるみたいな記述が、大企業未経験の身にはまことに信じがたくて、ビルドパイプラインの構築ごときに専門性なんか不要だろとしか思えないんだよなー。devops、devops。全員が同等のスキルセットで、はじめから運用まで一気通貫で行うのが一番効率良いと思う。
実用品を作って探る生成AIを使ったソフトウェア開発の現在 - 電通総研 テックブログ tech.dentsusoken.com/entry/202…
よく臭い芝居って言うけど、臭いのは芝居じゃなくて脚本だ、ということも往々にあるわけでして、そこら辺の区別はしっかりしていきたいですね。
継続的デリバリー(読み途中で半年くらい放置)に戻ってきた。「すべての環境にデプロイするのに、同じスクリプトを使え」。これは、この本全体に通底する原理に基いてる。要は、コードは使われれば使われるほど磨かれてくし、使われないコードパスはすこしずつ腐敗していく。依存性逆転原理を使って、ミドルウェアを差し替えられるようにし、複数のミドルウェアをサポートするみたいなのも、それら両方がほんとうに必要でよく使われるのでなければナンセンスで、一つのコードパスを磨き続ける方が良い。Amazonでもそういう考え方があると、弊社のスタッフエンジニアが言うてました。
AutoGenを使えば、複数の会話型エージェントが自律的に連携して、タスクを達成することができる？ほんとにそんな複雑なものがまともに機能するんだろうか。にわかには信じられんなあ。
LLMがどこまでいってもテキスト補完に過ぎないということの意味がようやくわかってきた