  |
はてなキーワード: javaとは
ドライバ開発においてAI（LLM）が生成したコードをそのまま信頼するのが危険な理由は、単に「コードが間違っている可能性がある」というレベルを超え、**「AIが物理世界（ハードウェア）の挙動を直接観測できない」**という根本的な制約に起因します。
具体的に、なぜ不安定になりやすいのか、4つの技術的な視点から解説します。
ハードウェアには、マニュアルに書かれていない挙動や、特定の条件下でのみ発生するバグ（エラッタ）が必ずと言っていいほど存在します。
AIの限界: AIは「公開されている一般的な情報」を学習していますが、特定のチップの特定のバージョンにおける隠れた不具合（エラッタ）への対策コードを生成することは困難です。
リスク: 仕様通りに書いているのに、特定のタイミングでチップがハングアップする、といった現象を防げません。
通信処理（I2C、SPI、UARTなど）では、信号を「HIGH」にしてから「LOW」にするまでの待ち時間など、厳密なタイミングが求められます。
AIの限界: AIは論理的な手順は書けますが、実行環境（CPUクロック、OSのスケジューリング）における実時間の経過を考慮したウェイト処理を正確に組み込むのが苦手です。
影響: 通信波形が乱れ、データ化けやデバイスの認識失敗が頻発する原因になります。
ドライバは通常、OSの核心部（カーネル空間 / Ring 0）で動作します。
致命的な違い: アプリケーション層のプログラム（PythonやJavaなど）であれば、エラーが出ても「アプリが落ちる」だけで済みますが、ドライバの不備は**OS全体のクラッシュ（ブルースクリーンやカーネルパニック）**に直結します。
AIの弱点: 割り込みハンドラ内での禁止事項（メモリ割り当ての制限やスリープ不可など）を、AIが完璧に守り切るのは非常に難易度が高いです。
ドライバは、メモリの特定の番地（レジスタ）に値を書き込むことでハードウェアを動かします。
AIの弱点: AIはよく似た型番のチップのレジスタマップを混同することがあります。
結果: 全く別の機能を操作してしまったり、予約済みの領域を上書きしてハードウェアを物理的に損傷（過熱や過電圧など）させたりするリスクもゼロではありません。
AIをドライバ開発に使う場合は、**「コードを書かせる」のではなく「レビューの壁打ち相手」や「定型文の生成」**に限定するのが賢明です。
https://claude.com/blog/how-ai-helps-break-cost-barrier-cobol-modernization
読んだけど、コボルをpython/javaに乗り換えるくらいなら、
人工知能（AI）開発の米新興アンソロピックがプログラミング言語「COBOL（コボル）」を使った従来システムの改修をAIがすべて解決すると発表し話題になっています。これは全世界に500万人いるとされるCOBOLプログラマが全員不要になる革新的な技術です。これがIT業界にもたらす影響について考察してましょう。
脱COBOL・マイグレーションの劇的な加速: これまで数年単位で数億円〜数十億円かかっていたJavaなど現代的な言語への移行プロジェクトが、AIの活用により数ヶ月〜1年程度へと劇的に短縮されます。
ブラックボックスの可視化: 長年の改修により誰にも内容が理解できなくなった「ブラックボックス化」したシステムを、AIが解析・ドキュメント化し、ビジネスロジックを正確に抽出します。
高コストなメンテナンスの脱却: 40年前のコードを管理する高額なシステム維持費や、COBOLメインフレームの維持コストを削減できます。
COBOL技術者からAI活用エンジニアへ: COBOLの構文を理解する「COBOL言語の技術者」から、AIが変換したコードの品質を担保し、再構築できる「AI活用能力を持つ技術者」へ需要がシフトします。
レガシー技術者の新たな価値: 過去のシステムを理解する技術者が、AIの成果物（新コード）を検証する「AIの指導者」として不可欠となり、彼らの経験が再評価されます。
エンジニア不足の解消: 金融、公共、インフラ系企業において、若手への技術継承課題が解消され、JavaやPython等のモダン言語への移行により最新開発環境へエンジニアが流動します。
ミッションクリティカルなシステムの延命と安定化: 銀行の口座管理や年金システムなど、止まらないことが求められるシステムを安全かつ高速に最新化し、高い可用性を保ち続けます。
DX（デジタルトランスフォーメーション）の実現: システムがモダン化することで、AIやクラウドなどの先進技術を導入しやすくなり、ビジネスの競争力向上につながります。
新旧対向テスト（リグレッションテスト）の重要性: AIが自動生成したコードが元のCOBOLコードと「全く同じ結果」を出すか検証するテストに、AIが生成したドキュメントやデータが活用されます。
「100%正確」ではない前提の人間によるチェック: AIによる自動変換は非常に高精度ですが、完璧ではありません。最終的な品質担保には、技術者による厳格な検証が引き続き必要です。
COBOLコーディングレスの動きは1950年代にCOBOL言語が開発された以降、繰り返し発生していたものです。
1990年代に発生したEUC（エンドユーザーコンピューティング）やCASEツール（コンピュータ支援ソフトウエアエンジニアリング）がたどった「技術の民主化と保守の属人化」という結末は、現在のプロンプトエンジニアリング（プロンプト職人）にも当てはまる可能性が高いです。
具体的には、以下のメカニズムで「プロンプト職人のレガシー化」が進むと考えられます。
EUC/CASEツールの結末: ユーザーやエンジニアが簡易ツールで大量のプログラムを生成したが、作成者の意図や背景がドキュメント化されず、後に「誰も中身が分からない（理解できない）ブラックボックス（レガシー）コード」として残った。
プロンプト職人の未来: AIに対する複雑な呪文（プロンプト）を組める専門職が、AIに具体的な指示を出して大量のコンテンツやコードを生成する。しかし、そのプロンプト自体が「AIという巨大なブラックボックスへのパッチ」となり、後から修正・保守できない「レガシー・プロンプト」となる。
AIモデルの進化による陳腐化: 高度な推論機能を持つ次世代AIエージェントは、人間が苦労して書いた「呪文」を必要とせず、意図や目的を伝えるだけでタスクを遂行できるようになりつつある。
「職人技」の共有・標準化の難しさ: 熟練職人が作成したプロンプトは文脈に依存するため、他のAIモデルや異なるタスクに適用しにくい。そのため、メンテナンスされず、使い捨てられる。
属人化とブラックボックスの維持: 「プロンプト職人にしか修正できないAIへの命令」がシステムに残ることで、かえって業務の俊敏性が低下する「負の遺産」となる。
現在の「魔法の呪文」を研究するプロンプト職人は、将来的にAIと対話しながらプロセス全体を設計する「AIエージェント・オーケストレーター」や「ドメイン特化型ビジネスアナリスト」へと役割を変える必要があります。
単なる「プロンプトの記述力」を武器にする職人は、技術進化によって、かつてEUCで乱立したメンテナンス不能なマクロツールのように、レガシー化していく可能性が高いでしょう。
ひろゆきさんがJavaScriptをJavaって呼んだり、「PythonやるならJavaScript必須ですｗ」と言って知識が20年止まってる切り抜き動画あったけど、
あれわざとツッコミどころ満載なことを言ってプチ炎上させてる可能性がワンチャンスあるな
娘の進学について、もし自分と似た所があったら何を助言できるかなぁと考えて過去を整理したので、ここに書き留めておくことにする。
中学受験コースに通い四科目の勉強を始めた。途中から社会の勉強がつまらなくて(楽しんで覚えられなくて)、二科目コースに移った。すると受けられる学校の幅が狭くなり、その中には強く行きたいと思う学校も無かったので、嫌になって中学受験コースから学校のサポートコースみたいなコースに編入した。
サポートコースは受験コースと比べると当然易しい内容で、簡単すぎると感じることもあった。
中学に上がると流石に高校受験を目指すコースになったが、そこでは上位クラスをキープできた。小学校の頃の助走があったこと、最初から三科目で行くと割り切っていたことも大きかったと思う。五科目で理科社会をやっていたら潰れていたか、結果的に総合的な偏差値を下げていたと思う。(社会は相変わらず覚えられなかったので……)
夏期講習や夜遅くまでの授業、正月特訓などを経て、無事に高校受験には成功した。
さすがに塾に通うことにはうんざりしていたので、絶対に予備校なんて行かない、大学の付属校に行くぞという気持ちで付属校ばかりを受けまくり、五校のうち四校に合格した。
高校ではその後、色々な点で苦しみながらも、友達や趣味に恵まれそれなりによい思い出を持った状態で卒業することができた。
苦しみについて補足すると、学校の授業で学び、家で宿題をするという当たり前の習慣に馴染めなかった。要するに勉強するモチベーションが沸かなかった。鬱に近い状態であったと思う。
勉強しなくてもちゃんと成績が取れる、という世界線を望んでいたのだと思われる。しかし自分はそのような天才ではなかったので、普通に悪い点を取ってはしょげてた。
それを認識した上でも、まだ勉強することに面白みを見いだせない時期が続いた。勉強は苦しみであった。もしも、目的意識がある、学問領域としての面白さに気付く、得意な科目で無双する、楽しんで競争する、といったことが出来ていたら、また違ったのかもなぁと思う。
そういう意味では情報の授業では割と無双してHTMLやJavaをやっていたかもしれない。
あとは、試験勉強を友達と学校やファミレスでやるというのも、楽しかったな。それに、そこで救われていたとも思う。
その反省も踏まえ、エスカレーターで進学した大学ではこの勉強が次にどう繋がっていくか、ということを少しは考えていたと思う。
B1は学部内で学科が分かれずに、B2で振り分けがあるタイプだったので、行きたい学科に行くためにはよい成績を取らなければならない、しかもこの学習はB2の基礎になるはずだ……とまでは考えたのかは覚えていないが、それなりに頑張ったと思う。
学科への振り分けも決まると、ようやく勉強と職業との繋がりが見えるようになってきて、学んでおきたいというモチベーションは増えた。またB3では研究室配属があるため、行きたい人気の研究室に入るためには良い成績を取らないとなぁという観点でも、諦めたりすることは無かった。
また、サークルに参加したのも良かったし、普段から内部進学の友達やB1でクラスが一緒だった友達とつるんでいたのも良かった。サークル活動に励んだり、喋ったりご飯を食べたりするのは楽しかったし、必然的に情報交換をして、頑張ろ〜なのかやんなきゃ〜なのか分からないけど、勉強のモチベーションになっていたのかもしれない。
サークル活動が専攻の内容ともリンクしていたことも価値があったと思う。これってどういうことだ？という疑問がサークル活動の遊びの中から生じて、別に宿題でも何でもないけど図書館に行って調べたり、活動の成果物を作るためにあれこれやったりしていた。
この頃は結構成績も良くなってきて、専門科目は一部を除いて良くできていた気がする。
そんなこんなで気になっていた研究室にも入ることが出来て、やりたい分野の企業にも就職することができた。今の仕事にも満足している。
勉強の苦い経験というのは、成長しているということであり、多かれ少なかれ苦しむことになると思う。その時に折れないで頑張れるかどうかは、自分の経験では目的意識と交友関係が大事だったのだと思う。
娘には、色々な事に興味を持てるといいね、仲間と一緒に遊んだり勉強したり色々やれるといいね、という方向性を提示していきたい。
C++は、現在でも世界で最も高速な部類に入るプログラミング言語です。2025年時点でも、高いパフォーマンス、低レイテンシ、細かいハードウェア制御が要求される分野（ゲーム開発、高頻度取引、組み込みシステムなど）において、依然として最高レベルのパフォーマンスを提供し続けています。
1. なぜC++が「最も速い」と言われるのか
機械語への近い変換: C++はコンパイラ言語であり、ソースコードが非常に効率的なネイティブ機械語に直接変換されるため、中間ランタイムが存在せず高速に動作します。
手動メモリ管理: ガベージコレクション（GC）がないため、自動メモリ解放による突発的な遅延が発生せず、決定論的なレイテンシ（安定した速度）を実現します。
ゼロコスト抽象化: 高度な抽象化（オブジェクト指向など）を用いても、パフォーマンスのオーバーヘッドがほぼかからないように設計されています。
ハードウェアへの直接アクセス: ポインタやSIMD（Single Instruction, Multiple Data）命令など、CPUの能力を最大限に引き出す低レベルな操作が可能です。
C言語: C++の基盤であり、同等の速度を持っています。C++は抽象化能力が高いため、同等のパフォーマンスを保ったまま複雑なアプリケーションを記述しやすいです。
Rust: 近年C++の最大のライバルです。多くのベンチマークでC++と同等の速度を示し、安全性を保証しながらC++を凌駕するケースもあります。
Go/Java/C#: GC（ガベージコレクション）を持つため、メモリ負荷が高いタスクではC++やRustに遅れを取る傾向がありますが、開発速度や並行処理には強みがあります。
Python/JS: インタプリタ言語であり、C++に比べて実行速度は非常に遅いです。
必ず速いわけではない: C++は速い「言語」ですが、非効率なコードを書けば遅くなります。高速化にはコンパイラの最適化設定や、高度な最適化テクニック（メモリアクセス最適化など）の知識が必要です。
安全性のトレードオフ: 手動メモリ管理は高速ですが、バグ（メモリーリークなど）が起きやすく、パフォーマンスを高めるために安全性を犠牲にする場合があります。
C++は極限のパフォーマンス（最高速度）を求めるなら依然として最強の選択肢の一つです。しかし、Rustのようなモダンで安全な言語も台頭しており、用途に合わせて選ぶのが現代的なアプローチです。
https://b.hatena.ne.jp/entry/s/xenospectrum.com/toyota-fluorite-flutter-game-engine-digital-cockpit/
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large Language Model(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(Network Interface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (Programmable Logic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
最近だと、Scala/Java、Golang、Rust、C#、Swift、Kotlin、JavaScriptあたりを並行して使っている。
フロントは、できるとか言うと、仕事量がバカにならないので、できないことになってる。
そんなかで、と言うと、サーバサイドでは、ロジックが単純で、高速性が求められるならRust。ビジネスロジックが複雑だとか、スイート化(大規模化)する可能性があるのなら、Scala2(w/o cats/scalaz)/Java。
Golangはね、基本部分の隠蔽化がちょっと難しい感じがするので、5人を超えてくる規模だったら、お勧めしたくない。
Golangはたくさんいる。
って言われることがあるんだけど、質がね。
Rustなら大丈夫か？ って言われたら、最近の生成 AI ででっち上げてくる手合いが増えてきて、大丈夫とは言い切れないんだけど、言語仕様に難しい部分が含まれているので、足切り効果で最低限の質は担保されているので、結果、採用で当たり引く確率は高くなると思う。
そう言うできるエンジニアを惹きつけるだけの魅力を備えてくれ、と言いたい。
「わからなければ書けない」
「わかってないけどなんとなく書ける」とか「完全に勘違いしてるけど書ける、動く」ってのが、発見撤去困難な遅延信管地雷をプロダクトに埋めるのだよな。
なもんで、IT技術者不足！とか言われても、一定程度のハードルがある言語にしておいた方がいいと思う。
なんとなくエンジニアを3人雇うくらいなら、その金額にちょっと色つけて、できるエンジニアを2人とか、むちゃくちゃできるエンジニアを1人雇った方が、確実に元がとれるんだよな、この世界って。
他の職種と違ってエンジニアは、下手すりゃプロダクトの生涯通してみれば、100倍くらいパフォーマンスが違ってくることも、ザラではないからね。
バックエンド開発だと、main.ts とか main.java みたいなエントリポイントで依存ツリーを頑張って構築するか、DIコンテナを使って解決することが結構多いじゃん？
実行時はそれで組んで、テスト時はコンストラクタ経由でモックをDIする、みたいなのが一般的だと思うんだけど。
最近Next.jsを勉強してて、バックエンドと同じ感覚でこれをやろうとしたら、まあややこしい。
ファイル先頭で直接関数を import してそのまま実行してるけど、それって密結合じゃないの？ テスタビリティ低くないの？
って思って調べたら、テスト時は vi.mock とか jest.mock とかを使って、モジュールごと無理やり上書きする方法が主流っぽい。
例えば「テスト対象のコンポーネント」と「その孫コンポーネント」が異なるGatewayに依存していた場合、
しかも「サーバーコンポーネント → クライアントコンポーネント」だとPropsで関数（依存）を渡せないから、Context経由でのDIになるっぽいよね？
でもそれだと最上位でDIしたものが最下層のコンポーネントまで全部使えちゃうから、「なんだかなぁ」ってなる。PropsバケツリレーもContextも、どっちもまあまあ面倒くさい。
あとバックエンドだと、こういう「モジュールをグローバルに上書きしてテスト」みたいなのって割とアンチパターン扱いされる文化が強いと思うんだけど、フロントエンド界隈だと「そういうもんだ」って割り切るのが普通なのかな？
みんなはどんな感じで単体テスト書いてるの？
技術ブログみたいの見かけるしそういうのでは先進的なことしたり技術的なところ力入れてそうに思ったけど転職活動してて実態は違うなと思った
やりたいことが現実にはできないから暇時間にあれこれ試してブログ書いて発散してる感じなのかな
たしかに大きなサービスとも慣れば頻繁に大幅に技術更新してリプレースなんてできないだろうし、メンテや機能の変更とかもある
話聞いてもそっちで手一杯でこのままの予定というところばかり
使う技術はレガシーな物が多くて、何が流行るかわからなかった頃にとりあえず選んでもう全く聞かなくなったフレームワークとか
比較的知名度あって今名前覚えてるものでも、Perl,Java,CodeIgnior,Riotjs,Cordva,VBA,Angularjsとかがあった
もう何年もOSSのリポジトリ更新されてないだろってのもあったはずなんだけどな
選定理由もとりあえず使える人が多いとかそういうの
RoRとかもう長いこと話題を見なくて絶滅したのかと思っていたものがかなりあちこちで使われていて驚く
PHPもまだ5系が動いてるところが多くて怖い
ソフトウェアベンダで働いてたことあるが、大手企業が相手だとEOLとかは顧客側が許さないところが多くて1年,2年は前から検討して余裕持って更新とかは必要になっていたから意外だった
外部に非公開の社内システムでこれなんだぜ？
自社でサービス持ってる有名どころの公開サービスがサポート切れで動いてるのは攻撃する側から狙われて当たり前だろと
新しさをアピールしてるといってるところもあったけど、「AI開発してます」がLLM有料契約して裏でプロンプトを自動で入れてその結果を画面に表示しますだけだったり
開発とは？
あとはバイブコーディングでAIがコード書いてる事が多いですと言ってるところ
現在のは最低限動く程度にはなってもそこまでクオリティ高いコードにならないと思うけど
一般エンジニアはAIのほうが多くてリードポジになると自分で書いたほうがいいから自分で書くことが多いらしい
OSSコミットしてますﾄﾞﾔｧ、とかじゃないんか？スクール上がりとかを雇ってるんか？
まあ結局そういう古い技術ばかりだから新しいものを積極的に使いたいとか、経歴でそういうものを導入してきたとアピールしてみても合わないと言われたりする
技術面でフルスタックに開発できて言語等のコア部分まで詳しく仕様書レベルで読んだり新機能提案みたいなレベルまでキャッチアップしてますとか言っても、すごいですねと言われるだけで通らない
エージェント通した場合の評価を見ててもスキルや得意としてることをウチでは活かせないと言われることもある
まぁ求人だと◯◯を作ってますというからそこに興味持って応募しても、面接で詳細を聞いたらそのコア部分は外部のライブラリに任せていて作ってる部分はただそれをウェブページに埋め込むだけだったりということも普通にあるし
どういうことやりたいかみたいな話でも、技術面を強く押すと避けられる印象
結局はユーザーありきなので技術的に難しいことをするわけではなく要望にある機能を淡々と実装していけばいいみたいなものなんだろうなと
プライベートでは開発系に一切かかわらず仕事のみのエンジニアで2,3年ほどウェブ系の言語だけ触ってれば十分みたいなところも多い印象
技術力よりコミュ力やサービスや会社の考え方にマッチするかどうかみたいな
たしかに解決が難しい技術課題があるわけじゃないならそういう採用方針にはなるなと
あとは意外とウォーターフォールが多いらしい
ウェブ系企業なんてみんなアジャイルだろと思ったのに、数割のところは設計書書いてからコード書くとかやってるらしい
お堅いところで設計書を完璧にしてレビューして通ってからみたいなところもあれば、方眼紙エクセルで書いてますまであって絶句
流石につらすぎないかと思う
実装し始めて初めて気づく問題とかいくらでもあるわけで、ウォーターフォールで当初の予定通りに上手くいくのは稀だと思うけど
ベンダですらアジャイルよりな開発が増えてきてるというのに・・・
むしろ契約上の厳密な納期がないからこそ自社でサービスやってるところのほうが向いてるのか？
