はてなキーワード: javaとは
生成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倍くらいパフォーマンスが違ってくることも、ザラではないからね。
90年代はもう成熟してバブル崩壊して日本が傾き始めてた時期だと思うよ…😟
日本が平和で幸せだったのは、皮肉なことにメガゾーン23の台詞にあるように、80年代だと思う
スネ夫みたいな金持ちの子の家に行って、ファミコンのダックハントするのが好きだった
小学校の社会の授業で、日本が世界で一番経済的に豊か、と言われて、へー、そうなんだ、と思ってた
でも、自分が大学に入った辺りから、もう日本の半導体は台湾に負け始めていた
大学時代は、PC-9801、X68000、FM-TOWNS、AMIGAなどのパソコンがあったが、
それらがDOS/V、Windows 3.1、そしてWindows95が決定打になり、PC/AT互換機がパソコンの主流になっていく
家でもLinuxやFreeBSDが動作するようになり、日本のパソコンは急速に色褪せていく
Microsoftさえ、最初はインターネットに否定的であったが、ネットは急速に広まっていく
C++に挫折した自分はJavaを書くようになり、そこからまたC++に戻っていった
半導体は負け始めていようが、バブルが崩壊していようが、オウム事件、ノストラダムスの大予言があろうが、
自分にはまったく関係ないと思ってた、日本のメカトロ、ロボット技術はまだまだ健在であった
中身をどう評価するかはともかく、あの今の中国のような勢いが、今の日本にはまったく感じられない
まるで老人が元気な若者たちを見て、まだまだ若いな、青いな、みたいに嘲るような雰囲気がまだ日本にはある
これまでの間、我々は台湾に負け、韓国に負け、そして中国に負けようとしている
セルアニメとしての限界を迎えていて、やがてデジタル作画に移行するわけだが、デジタルの色彩は酷いものであった
正にセルアニメ時代の最後尾、素晴らしいセルアニメが大量に作られた
メタルも80年代の若い時代から、90年代は成熟して落ち着いた感じさえあった、
大学になってメタルを聴くようになった自分は、小中高と洋楽にどっぷり浸かってきた勢にはバカにされたが、
80年代はもう整理されていて、それを落ち着いて摂取することができた気がする
勢いがあったのは、やはり80年代であろう
バックエンド開発だと、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年ほどウェブ系の言語だけ触ってれば十分みたいなところも多い印象
技術力よりコミュ力やサービスや会社の考え方にマッチするかどうかみたいな
たしかに解決が難しい技術課題があるわけじゃないならそういう採用方針にはなるなと
あとは意外とウォーターフォールが多いらしい
ウェブ系企業なんてみんなアジャイルだろと思ったのに、数割のところは設計書書いてからコード書くとかやってるらしい
お堅いところで設計書を完璧にしてレビューして通ってからみたいなところもあれば、方眼紙エクセルで書いてますまであって絶句
流石につらすぎないかと思う
実装し始めて初めて気づく問題とかいくらでもあるわけで、ウォーターフォールで当初の予定通りに上手くいくのは稀だと思うけど
ベンダですらアジャイルよりな開発が増えてきてるというのに・・・
むしろ契約上の厳密な納期がないからこそ自社でサービスやってるところのほうが向いてるのか?
ここにSES企業があるとします。あなたは、晴れてその会社にエンジニアとして採用されました。しかし未経験で採用されたあなたは、何のスキルも無ければ、経験もありません。強いて言うなら、入社前に取っていた運転免許とITパスポートの資格くらいです。
入社後間も無くして、営業がある会社の案件に空きが出たから、企業様との面談に参加して欲しいと電話が!これでエンジニアとして働ける!とウキウキのあなた。すると営業からこう言われます、「面談するにあたってスキルシートを書いて欲しい」と。
このスキルシートというのは、所属しているエンジニアに案件の参画前に必ず書かせる経歴書みたいなもので、現状で何のスキルがあるか(Javaが使えます〜とか、WordやExcelは人並みに以上に使えます〜とか)や、何の資格を持ってるかとか、今までどんな案件に携わっていたかとかをダラダラ書かせるものです。営業担当は、これを派遣先の企業の人に見せて、果たしてこれから派遣しようとしているエンジニアは、今回の案件(現場)に適した人材かのミスマッチを無くすようにするのです。
あくまで表向きはね。確かにスキルシートは、エンジニアと案件(現場)のミスマッチを無くすための役割なのですが、営業からしたらそんなこと知ったことじゃありません。
営業の立場からしたら、毎日ノルマ(どれだけ自社のエンジニアを現場へ派遣し、どれだけ収益を上げるのか)に追われ、その達成のことしか頭にありません。それはそうですよね、それが営業の役割ですから。だからそう意味では、営業からしたら、その現場に如何にミスマッチな人材だろうが、エンジニアをその現場へねじ込みたい、ぶち込みたい。これなんですね。
Gemini Deep Researchで本当の話なのか調査させ、はてな匿名ダイアリーへ投稿出来るように要約させた
はてな匿名ダイアリーを指定したら口調が勝手に変わって吹いたw
2025年末、「娘のはじめてPCにLinux」という議論がネット上で波紋を呼んだ。これは単なるOSオタクの戯言ではない。 「エリート層は子供にRaspberry Pi(ラズベリーパイ)を与えて"支配側"へ育て、一般家庭や公教育はiPadを与えて"消費側"に留め置く」という、現代の身分制度(デジタル階級社会)への警告だ。
本稿は、英国王立協会やGIGAスクール構想の実態、労働市場データを分析した「公教育の機能不全と家庭内資源動員に関する調査報告書」の要約である。 結論から言えば、「中流以下の家庭こそ、なけなしの金を払ってでも子供にLinuxを触らせろ」ということになる。
かつてのデジタルデバイドは「ネットに繋がるか否か」だった。スマホ普及後の現代における格差は、「コンピュータの制御権(Root権限)を持っているか否か」である。
英国王立協会はすでに2012年の段階で「学校のICT教育はオフィスソフトの使い方しか教えていない」と酷評している。 その結果、富裕層の私立校では専門家を雇ってRaspberry PiやAI活用を教え、貧困地域の公立校では管理が楽なiPadを配って終わり、という絶望的な「質の乖離」が起きている。米国でも同様に、富裕層の子供ほど「消費的なスクリーン(TikTokやYouTube)」から離れ、ChromeOSやRaspberry PiやUbuntuなどを導入し創造的なプログラミング教育を受けている。
日本の金のある自治体の公立小中学校で配られたiPadは、MDM(管理ツール)によってガチガチに制限されている。 逆に、ChromeOSはLinuxベースであり開発環境として優秀なのだが、教育委員会は「セキュリティ」と「管理コスト」を理由にその扉(ChromeOSやLinuxでの創造的な授業)を諦めた。 結果、公立校の生徒はiPadで「Web閲覧」と「ドリルアプリ」しかできない。
一方で、開成や筑駒といったエリート校の生徒は、制限のない環境でサーバーを構築し、Unityでゲームを作り、競技プログラミングに没頭している。iPadの 「サンドボックス(砂場)」の中で遊ばされている公立校生と、システムの内側に触れているエリート校生。このスタート地点の差は、10年後に致命的な「年収の差」となって現れる。
「社会に出ればWindowsだろ?」というのは20年前の常識だ。 現代の高付加価値インフラ(AWS、Google Cloud、AI開発、IoT)は、ほぼ全てLinuxで動いている。
GUI(マウス操作)はAIにとってコストが高いが、CLI(コマンド操作)はAIへの命令(プロンプト)そのものであるため、相性が抜群に良い。 Linuxを学ぶことは、「AI時代におけるコンピュータへの正しい命令作法」を学ぶことと同義だ。
「MOS(Microsoft Office Specialist)」というフィルター機能は低下し、GithubやPixiv、Youtubeなどでのクリエイティブな活動履歴(何を作れるか)がパスポートになる。貧困・中流層がこの壁を越える唯一の武器が「技術力(ポートフォリオ)」だ。
中流以下の公教育が頼りにならない以上、家庭で動くしかない。幸い、Linuxの世界は「金はかからないが、知恵と時間はかかる」。これは資金力のない家庭にとって最大の勝機だ。
30万円のMacBookは不要。企業落ちの中古ビジネスPC(ThinkPad X250/X260等)なら、秋葉原や通販で1.5万〜3万円で買える。 Windows 11が入らない型落ちこそ、軽量なLinuxには最高の機体だ。Raspberry Pi 4や400の中古も良い選択肢となる。
親が教えられないなら、CoderDojo(無料のプログラミング道場)のようなコミュニティに子供を連れて行けばいい。そこには「技術を楽しんでいる変な大人」がいる。その出会いが重要だ。
「壊れるから触るな」ではなく、「壊してもOSを入れ直せば直るから、好きにいじれ」と言って管理者権限(Sudo)を与えること。 YouTubeを見る端末を、YouTubeを作る端末に変えること。
高価なiPadを買い与えて安心するのではなく、1万円の中古PCを与えて「黒い画面」に向かう子供を応援すること。 その小さな投資が、子供を「デジタル小作人」から救う唯一の手段になるかもしれない。
娘の為にパソコンへ詳しすぎる夫を倒したいで注目された「学生、それも幼さの残る年頃の子へはじめてPCをどうするのか?」というテーマで、Linuxを与えた家庭の別例としてこのエントリを書いている。
そして前提として、このエントリは「実はLinux使ったこと無いんだ」「Raspberry Piって稀に聞くラズパイってヤツだよね?」みたいな、ふわっとした認識の層に向けて書いている。
決して「KVMで完全仮想化してLinuxとWindowsで用途に応じてリソース分配してる。ディストロは純関数型のNixOSで、Nix言語で可能な限り-march=nativeで自家コンパイルしてるんだよね」みたいな層には書いてない。
勿体ぶっても仕方ないので結論から言えば、WindowsやMac、AndroidやiOS(iPadOS)に染まりきっていない子供は親の想定を超えて極々普通にLinux、Raspberry Piの工場出荷状態でプリインストールされているRaspberry Pi OSを使う。
ここで言う「染まる」というのは「ウチの子は普段からiPadでYoutubeとかゲームとかしてるからなぁ」程度の染まり具合なら無視できるレベルなので全く障害にならない。
手遅れな染まり具合としては「ウチの子はWindowsでOBS使って自らYoutube配信してます」とか「ウチの子はWindowsでAbleton Live使ってDTMしてます」とか「ウチの子は大学のレポート書くのにmacOS使ってます」とか「ウチの子はiPadでSwift Playgrounds使ってプログラミング学習してます」とかそういうレベルだ。
アナタ達の子供がこのレベルにまで染まっていない場合、アナタ達の子供へRaspberry Pi 500を与えると何も疑問に思わず普通にパソコンとして使う(パソコンの操作方法へ疑問を持つとかそういう話じゃなく、目の前のモノをパソコンとして認識する)。
ラズパイ、Raspberry Piは英国で立ち上げられたRaspberry Pi財団(注:英字ページ)が規格・設計・販売をするシングルボードコンピュータという種別の小型コンピュータのことだ。
現在の最新版は第5世代のRaspberry Pi 5で、搭載ワーキングメモリによって価格が違うが、最も高価なワーキングメモリ16GB版で25,000円前後(2025/12/09現在価格)という圧倒的な低価格が人気の理由の1つだ。
何故ここまで低価格なのか?と言えば安価な部品で構成され、搭載されるSoC(CPUみたいなもん)も低性能で、その性能は約10年前の普及価格帯(〜15万円くらい)のノートパソコン程度の性能しか無い。
「いや10年前ってゴミじゃん」と考えるのは早計で、逆に言えば10年前の普及価格帯ノートパソコンで可能だったことはRaspberry Pi 5でも可能。
そう言われ「自分は10年前に普及価格帯ノートパソコンでネットしたりMS Officeで文書作成したり軽くゲームしてたけど?」と気付いた人は「Raspberry Pi 5で何ができるか?」の想定が浮かんだのではないだろうか?そう、かなり色々できる。
そして工場出荷状態でプリインストールされるRaspberry Pi OSはRaspberry Pi 5自体の計算リソースをできるだけ使わないよう軽量にできており、10年前当時のWindowsで使われていたExplorerよりも計算リソースの消費が少ないので、技術の進歩も相まって当時よりも出来ることの幅が少々広くなっている。
何故そんなに話題なのか?手のひらの上に10年前の普及価格帯ノートパソコン並みの性能のコンピューターが乗るのだ。そしてすごく安い。
更にラズパイには電子工作へ活用できるGPIOピンというのが実装されていて各種電子センサー類などと連携することで電子工作もできてしまう。
こんなもの情報工学畑の連中が注目しないわけがなく、前述したRaspberry Pi財団のページを読めばわかるが世界中で大定番のシングルボードコンピューター、何ならシングルボードコンピュータの代名詞となっており、情報工学に詳しくない人が「ラズパイってよく聞くけど何なの?」と何処かで耳にするレベルなのである。
安心して欲しい、Raspberry Pi OSではGoogle Chromeが動く。
まずGoogleアカウントは子供用に作成したGoogleアカウントを管理するためのファミリーリンクというサービスが存在する。ファミリーリンクは子供用GoogleアカウントでログインされたGoogle Chromeブラウザでのインターネットコンテンツフィルタ機能を提供してくれる。
このインターネットコンテンツフィルタは小学生・中学生・高校生・高校生プラスと4段階に分かれており、それぞれに適したフィルタリング強度で働く。
続いて、実はGoogle Chromeは様々な設定をポリシーとして持つことが可能で、例えばゲストモードの無効化やシークレットモードの無効化、指定したGoogleアカウント以外でログイン不可が可能だったりする。
情報技術へ親和性の高いヤンチャな子はGoogle Chromeからログアウトしたりゲスト・シークレットモードでフィルタリングを回避しようとするので、子供へRaspberry Piをはじめてパソコンとして与える場合はこれらを無効化しておくことをオススメする。
補足を続けると子供が勝手にFirefoxとか別のWebブラウザを導入することを防ぐこともRaspberry Pi OSはできる。
Raspberry Pi 5をパソコンキーボードへ内蔵した形態を持つRaspberry Pi 5シリーズの1つ。ワーキングメモリは8GBで価格は20,000円未満。
パソコンキーボードへRaspberry Pi 5が内蔵されているのでRaspberry Pi 500に電源取ってHDMIケーブル(注:ラズパイ側はmicro HDMI)をTVへ接続すると直ぐにパソコンというコンセプト。
小学生の子供にとっての目玉はJava版Minecraftが動作すること。SwitchやiPadでいつも遊んでる統合版マイクラじゃなくてYoutubeとかで観るJava版マイクラが自分のパソコンで動いちゃうのだ。
Switch 2の登場でPCゲーが色々リリース(予定)されている中で、Java版マイクラはどうしても"パソコン"が必須だったが、Raspberry Pi 5シリーズはそれを実現する。それが2万円のお値段で出来るので親の懐的にもありがたい。
Steamは動かないがオープンソース系のゲームも充実している(Steam開発のValve社がRaspberry Piシリーズが採用しているARMアーキテクチャ対応を進めているというかなり確度の高い噂は存在する)。
実は直近でRaspberry Pi 500の上位版Raspberry Pi 500+(日本語配列)が登場予定で、こちらはワーキングメモリが16GBのお値段40,000円くらい。
4万円とそこそこの価格になってきているが、キーボード自体がメカニカルキーボードとなりキーキャップはCherry MX互換、256GB SSD搭載でストレージのスピードもアップ(=Minecraftのワールド読み込みが速くなる)。上位版Raspberry Pi 500+が高すぎると感じるなら素のRaspberry Pi 5ワーキングメモリ16GB版は25,000円前後だしこちらで良い。
ある、というかコッチがメインなんだけれども、何処までゆるい感じでやって良いのかわからなくて最後に回した。
まずLinux界隈が中心となって開発されているGIMPやKritaみたいな画像編集・お絵かきソフトはLinuxたるRaspberry Pi OSの方が安定かつ速い。しかもWacomやXP-Penなどのペンタブ・液タブが動作するので絵描きに興味のある子は嬉しいんじゃなかろうか?(クリスタじゃないけれどね。安い分ペンタブ費用に回せるよ)
音楽ではDTMもステップシーケンサー系のDAWであるLMMS(Linux MultiMedia Studio)は日本の無料DTMシーンでREAPERと人気を二分していた歴史があり、Web上に情報がいっぱいあるし何ならREAPERはLinuxでも動作する。オープンソース系のシンセ音源やCC0で提供されるサンプリング音源も大量にある。
オフィス環境もLibreofficeは言うまでもないだろう。Blenderで3DCGをすることだって出来るし、LibreCADやFreeCADで設計だって出来てしまうし、OBSも動くから実際やろうと思えばYoutube配信もできる。
そして当然ながらプログラミング環境、WindowsやMacでも動くと言われてしまえばそれまでだが、古典的なVimやEmacs、そして近年人気のVS Code、スマホアプリ開発にAndroid Studio、ゲーム開発にGodot Engine、他にはtmuxやGit、Dockerなどなど挙げればキリがないほど充実している。これらは子供向けRaspberry Pi OSだからといってニセモノの子供だましなんかじゃない、それでお金を稼いでる現役プログラマーが使っているアプリケーションと全く同一のアプリケーションだ。
んで、子供がRaspberry Pi 500をどうしてるのか?と言えば、まぁ呆れるほど毎日触っている。
何なら電源なければ動かないのに布団へ持ち込んで抱きかかえて寝ているのを見つけてしまい、そんなに嬉しかったんかと笑ってしまった。
「お父さんコレどうするの?」とほぼ毎日聞かれて「こういうのはこのソフトを使う。使い方教えてやる」というのが毎日の親子の会話になっている。
今年からJTCで働いてるんだけど
まず、年末調整を社内システムから投入するんだけどこのシステムが昔のJavaのUIそのまんまっていうチープっぷり
そんで鬼のように分かりにくいシステムになっていて、別で共有されるPPTのマニュアルがあるんだけどこれも分かりにくい
おまけに「年収欄を入力しろ」みたいに指示されててマジで意味不明
もちろん他に収入がある人もいるだろうけど初期値で入れとけばよくない?どういう神経してるのか意味不明
別のウィンドウで給与明細を確認しようとしたら同時に開けないらしく、一度全部閉じてから給与明細を確認
1〜11月までの給与とボーナス、12月の想定給与とボーナスをエクセルで足してメモして、年末調整画面まで戻って入力
その後、なんだかんだ全部埋め終わったら「これとこれの書類について原本を郵送しろ」って出てくる
ただ、該当書類が何種類かあって「これで合ってるの?」っていうのを聞きたくても連絡先が無い
どこを調べても説明されてないし連絡先もないからとりあえず添付して郵送
まぁ間違えてたら連絡くるだろうと思ってたんだけど、1週間ほど連絡なし
大丈夫だったのかな、と思ってたらシステムから「処理完了」の通知が来て、年末調整は完了
と、思いきや、しばらくしたら職場から連絡があって(フルリモートなので職場にはほとんど行かない)郵便物があるとのこと
ちょうど用事もあったので出社して受け取ったらでっかい封筒に「年末調整書類不備のお知らせ」って感じで紙が入ってて
「この書類ではなくてこっちの書類になります」的なことが丁寧に書かれていて
「二次補正期間(12/9〜12/12)に提出してください」って書いてある
よくある間違いだからテンプレペーパーなんだろうけど、ペーパーに手書きで加筆されてて絶句
「この期間に申請がない場合は【確定申告】をしてもらうことになります!」
いや、どうせ確定申告するんだけどちょっと楽になるから年末調整してんだよね
プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…!」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。
近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。
開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のものが出回っている。Eclipseとか今考えるとよくあんなので開発できてたな。
いまや小学生からおばあちゃんまでアプリ作りに熱中し、高校生はIoTとかやり始め、大学生は商業レベルか?ってレベルのものをネットで発表し、私はウェブアプリのスマホでのレイアウト崩れひとつすら直せず静かにエディタを閉じてnoteで過激タイトル記事を書いている。
掛け算に順序があると思っているような知能の下級雑用係(自分のことを教育専門職だと思い込んでいる)ですら「小学生にプログラミングを教えるぞ!」と意気込んでいる。やめろ。お前らには無理だ。無理だからマジでやめろ。考え直せ。無理だって。掛け算に順序つけないと相手に教えられないレベルのやつがプログラミング教えるのマジで無理だって。算数とは次元が違うって。「ピーチ姫いつも簡単に誘拐できるし今度はベヨネッタも誘拐してみるか」ぐらいの無謀さだって。やめとけ。マジでやめろ。
まあそんなこんなで入り口はめちゃくちゃ広く、入門するのはマリオカートより簡単である。話逸れるけどSwitchのマリオカート、運転アシスト機能ついて初心者でもコース完走できるようになったから心折れちゃった人ももう一度チャレンジしてみてね。
それとは特に関係ないんだけど、大学行ってた時ティーチングアシスタント(TA)っていう授業のお手伝いさせられたのよね。ちゃんとお金出るやつ。
学部の3年か4年から始まって、院の1年か2年までやってて、途中で休学挟んだから、ええと、あー、うん、数年間TAやってたんよ。数学とプログラミングのコマ。CとOctaveとかいうやつ。Cのほうは情報学科で、Octaveは違う学科。JavaとかC++のコマはTA入れさせてもらえなかった。
プログラミングの実習は週2コマ(連続)あって、情報学科なら必修科目。なのでサポートは相当手厚く、先生とTAが絶え間なく机間巡視し、わからないことがあればセンパイがなんでも答えてくれるというわけだ。授業外でもサポートはしており、わからなければ先生や研究室にいる学生に好きなだけ聞きにいっても良いということになっていた。必修だから落とされたら困るしな。
2コマだから3時間 * 15回で、45時間。そして私の時は2年まででC/C++/Javaと必修だった(今はなんの言語かは知らない)ので、その3倍、135時間は最低やることになる。プログラミング実習以外にもプログラミング触る授業多いから実際はもっと多い。宿題やる時間もあるので実際はもっともっと長くプログラミングに触れることになる。卒論書く時期に入ると、テーマによっては書く人はさらに書くので、もっともっともっともっと長い。
これだけ時間をかければほとんどの人がプログラミングできるように……ならない。むしろできない人の方が多い。なんで。why。教えて。
会社になるとさすがにプログラミングできるできないは死活問題である。
「今日から入ったxxでーす。業界未経験ですがよろしくおねがしまーす。さっそくなんですけどPythonのここわかんないんですけどどうすれば……あっそうすればいいんですね。次はここなんですけど……なるほど!ありがとうございます。じゃあまた明日ー」
いやー社会人にもなると熱意が違うね。学生なんかわかんなくてもほとんど聞きに来ないのにな。こりゃガンガン伸びますわ。私も社会人1年生でPythonなんて3秒ぐらいしか触ったことないから適当答えてるけど。
「ちょっとお時間よろしいですか?」「いやちょっと今忙しいから後になっちゃいますわ。すんません……」
そんなこんなで1週間ぐらい放置してしまった。やべー絶対嫌われる。どこまで進んだかな……?えっまだそこ?進んでなくない?
もしかしてこれ全部教えないとダメなやつか。そりゃ大学4年間プログラミングやったやつでもプログラミングできないんだから、そうか。よく考えると当たり前だよな。
プログラミングをやめろ
大学4年間と大学院2年間プログラミングやったやつでもできないし、会社で毎日8時間を数週間プログラミングについやしてもできないやつはできないし、そもそも人類というのはプログラミングできない可能性がある。
少年少女たちに「プログラミングはいいぞ!自由にものが作れて達成感がある!頭が良くなった気分にもなれるし!」と吹聴してまわんのもいいけど、6年間情報科学について勉強したようなやつの大半がプログラミングできないんですよ。それもごくごく初歩的な部分。
野球とかサッカーなら、まあ友達との試合には参加できなくてもごく稀にバットにボールを当てたり、ボールを1回あらぬ方向に蹴ったり、ぶっちゃけ周りとのレベル差で楽しくなくてすぐやめちゃうだろうけど、なんとか基礎の一部ぐらいはできるじゃないですか。
ピアノとかダンスでも、猫踏んじゃったをごくごくゆっくり弾くぐらいはできるかもしんないし、学芸会の振り付けを10秒ぐらいは踊れたりできるかもしれない。その後やっぱ周りのレベル見て諦めちゃうかもしんないけどさ。
プログラミング、6年やってミットを頭にかぶってるバッターとか、鍵盤蓋の上から殴って音鳴らそうとするやつとか、まずそういうレベルのやつが大量発生するんですよ。だいたい7割ぐらいの率。どうすんだよこいつら。私の教育の問題か?マジで?本当に?
プロが練って考えて凝縮した本や授業、センパイたちによる指導。それらを結集して得られるはずのものが7割ぐらいどっかに消し飛んでる。無駄だろこれ。
今からプログラミングやろうとしてるやつ、お前は確実に向いてないからさっさと諦めて刺身にタンポポ乗せる仕事に戻ってくれ。参加しても鍵盤蓋叩き割るやつと同じ病室に入るだけだ。
プログラミングをやめろ。
ぼくはこう思うんですよ
そもそもなんで大の大人がそんな両手にバット持ってセカンドに立ったりゴールの方をボールのところまで動かす奇行に走るんだろうな。わかんねえや。
綺麗な分析はできないけど、いわゆる「できない」やつが共通して言ってたフレーズがある。
「ぼくはxxxだと思ってるんですけど、動かないんですよ」
うん、そうだね。そう思うんだ。でも動いてないじゃん。じゃあ違うんじゃない?モニターに「にらみつける」やってもバグは取れないし防御力下がるだけだぞ。
まず根本的に考えと事実が違ってるって結果出てるじゃん。じゃあもう考え変えちゃえば早くない?
名言の引用は好きではないけど、「プログラムは思った通りには動かない。書いた通りに動く」って言葉がある。実に名言だと思う。次点で好きなのが「ある問題を解決しようと正規表現を使うと問題が2つに増える」かな。
お前が何を思っているかはプログラミングにおいて一切影響しないんだよ。お前が何を書いて、コンピュータがどう処理したか、それが全て。
深く考えないことについてぎゃーぎゃーいうやつもいるけどプログラムなんてまず最初は動けばいいんだから何も考えずに次試せばいいだろ。んで3回ぐらいは自分で思い浮かんだの試して、全部ダメだったら調べるとか先生に聞いてみるとかさ。逆に1発で通ったら自分の思考見直して理解深めるとかさ。
ドキュメントとかあんまり理解できない初心者のうちは、とにかくお試しと修正のサイクル回すの重要で、「これがこうだから動くはず」というカードを3種類ぐらい作って全部片っ端から試すのが早いと思うよ。モニターをにらみつけるな。
お前がどう思ってるかよりも、まずはお前の書いたプログラムがどう動いているか(どう動いていないか)を確認するのが先だ。動かなかったら考えが違う、はい次のプラン、はいその次のプラン、はい次。
この「ぼくはこう思ってる」が出てくるの、なんの教育の成果なんだろうね。お前の気持ちなんてどうでもいいって現国でも数学で散々教えられただろ。
Error: variable 'a' is undefined, line 24
↑のエラーは架空のエラー文(英語下手でも許して)だけど、エラー、出るよね。プログラム組んでたら。んでやっぱいるのよ。エラーを「にらみつける」やつ。解決しねえって言ってんだろ。
「エラー出たんですけど、どうすればいいんですか」
「エラーにはプログラムがなぜコンパイル通らないかの原因がそのまま書かれている。例えば今出ているError: variable 'a' is undefined, line 24は、24行目の変数aが未定義ということを示している。事前に変数aを定義していないか、打ち間違えてsになっているとかではないのかな?」
だいたいが「腑に落ちねぇー」みたいな顔する。まあ、一気に喋りすぎたしな。疑問点1個1個潰していくか。
「何か疑問点ありそう?変数ってなにー、とか、定義ってなにー、とか」「ないです。わかりました!」
わかったのか。よかった。またモニターをにらみつける開始。なんでだよ!!!!「お前顔にチョコついてるぞ」って言われたらチョコ拭き取るだろ。変数aが未定義ですねって言われたら変数a定義すりゃいいだろ。
でもプログラミングド下手なやつ(全人類の7割ぐらい)は、エラーをにらみつけてる。ずっとにらみつけてる。防御力下限まで下がったかな。にらみつけてて何が変わるんだよ。
「英語読めなくて……」
いや「a is undefined」なんて「He is Superman」ぐらいの英語だろなんで読めないんだよ。お前この大学どうやって入ったんだよ。たしかどの入試方式でも英語あっただろ。単語わからんかったらググれ。
「aが未定義って書いてあるんですけど、ここのfor文の私の考えが間違ってるのでしょうか」
いや24行目のaって書いてるだろ。まずなんでそこ無視するんだよ。お前がfor文で使ってんの教科書通りのiだろ。24行目ってわかるか?for文あるの40行目あたりだよな?aとiが違う文字ってわかるか?
「さっきのエラー直したら新しいエラーが出たんですけど、どうすればいいですか」
千尋!贅沢な名だねえ
変数に名前をつけろ。関数に名前をつけろ。クラスに名前をつけろ。全てに名前をつけろ。
C言語の古い教科書だと「a」とか「b」とか「i」とかで書いてるけど、そんなの人間が読めるわけねえだろ。冷静に考えろ。「input」「output」「index」とかにしとけ。
2重for文の変数名i, jにしたら絶対途中で打ち間違えるだろ。お前は打ち間違える。そういうやつだ。2重ループなんてどうせ行列計算の課題だろ。rowとcolumnにしとけ。これで打ち間違っても気づくし、それぞれに意味が付いてくる。
ちなみに同じ長い名前にも優劣がある。「result」よりも「sum」のほうが強い。「result」はなんの結果かわからない(全ては結果であるので)が「sum」は合計値であることがわかるからだ。「password」と「plainPassword」なら「plainPassword」が勝つ。暗号化されていないパスワードであることがわかるので、情報量が多いからだ。
ただし例外はいくつかある。「tmp」は一時変数であることが(プログラマにとって)明らかだ。「dir」はディレクトリであることがわかる。「src」「dist」あたりもよく使われる。このあたりは短くていいんじゃねーかな。
でも、この前温度センサ扱うプロジェクトで「tmp」って変数名使って温度(temperature)と脳内で混線してバグって発狂してた同僚いたけど。そういうときは名前長くするか別の名前使おうな。
関数の名前なんて「calcAverageFromArray」ぐらい長くしていいから。「myFunc」とかしなくていいから。「fetchJsonDataFromUniversityInternalServer」とかでいいから。マジで。いやこれ本当に。
そもそも今時ディスプレイでかいし、識別子なんて先頭数文字打ったらエディタが補完してくれるし、短くするメリットがない。
それでも名前が長いと感じる?関数がでかすぎるんじゃないか。細かく処理を分けるとかしてみろ。「combineArrayAndFindMax」関数は「combineArray」と「findMax」に分割したらいいと思うぞ。名前が長いと思っても名前を削るな、機能を分割しろ。自然と名前が短くなる。
それかシンプルでかっこいい名前を見つける。「convertEvilHtmlToPeacefulText」は「sanitize」に置き換えることができる。イカす名前だ。
プログラミングできない奴はマジでこれらのことをやらない。ずっとaとかbとかzとか使ってる。お前それ自分で読めんのか。読めねえだろ。myfuncってなんだよ何するんだよ。お前自分で理解できてんのかそれ。
それでも頑なにaとかbとか使う。なんでだよ。
動作原理わからず書き散らすな。動作原理っつってもそんな深いところじゃなくて言語表面上レベルの動作な。
リテラルは値を作成して、代入は値に名前をつけている、とかその程度のレイヤー。メモリがどうこうとかはいらんと思う。あっでもポインタのときはいるか……。めんどくせえな。
まあ動作原理っていうか自分が何やってんのか理解してくれって程度の話になるんだが。
例えばfor文で処理50回まわすとき、「50回分の処理を行なっている」ではなく「ループ開始時に変数を初期化。条件判定して成立していれば文の中を実行する。条件変数の値を変化させてまた条件判定からやり直す」ぐらいの粒度で捉えててほしいかな、という気持ち。
これはfor文で詰まる人がやたら多かったからだ。彼らはfor文をアトミックな操作だと思っていた。つまりfor文はひとまとまりの命令であり、長いfor文とprintfの間に粒度の違いはないと思っていたらしい。
つまり、「for文の中でエラーが起こる」という事象がほぼ理解できない。forはアトミックであり、内部など見えないのだから。じゃあお前が今書いたfor文の中身はなんなんだってやんわり聞くと「さあ…?」みたいな反応が返ってくる。はあ。
関数についてもなかなか誤解が多かった。関数「sum_array(a, b)」と関数「average_three_numbers(a, b, c)」は全く別の原理で動いているのだと。ここでの「全く別の原理」というのはシグネチャが違うとか実装が異なるとかそういう意味ではなく、コーラを飲んでゲップが出る原理と糸電話で声が伝わる原理ぐらいの全くの別、という意味である。
彼らは関数ひとつひとつについて「新しく原理を学習」していたのだ。マジかよ……。どうやったらそんな発想に行き着くんだろう。そりゃ時間かかるわな。
そのため、関数が値を返す(または返さない)ということも理解できておらず、「関数の戻り値と関数の戻り値を足す」とか「関数の引数に関数の戻り値を直接渡す」とかやりだすと大パニックになる。メソッドチェーンとかやった日には大学潰れると思う。ただ、これはC言語が悪い部分もあると思う。配列とかいじりだすと、初心者が書けるレベルの関数だとあんまり値返さないしな。
たのむ、他のはできなくてもこれはできてほしい。自分が何をやりたいのかは理解してほしい。流石にお前のやりたいことなんて他人にはわからんぞ。
「配列の中の数値の合計値を求めたいんです」とか「名前と身長と体重をひとつにまとめた構造体が作りたいんです」とか。簡単なのでいいから。
「いま何やろうとしてどこで詰まってる?」って聞いても「……?」みたいな反応されたら困るんだよ。
例えば「キーボードから数値を10回入力し、それぞれの値を配列に格納して、最後に配列の値を逆順に表示せよ」みたいな問題が出てきたときに、「キーボードから値を入力する」「10回繰り返す」「配列に値を格納する」「配列の値を逆順に表示する」に分解できると思うんだけど、自分が何やりたいのかわからない奴はまずこれができない。
彼らには「キーボードカラスウチヲジュッカイニュウリョクシソレゾレヲハイレツニニュウリョクシテサイゴニハイレツノアタイヲギャクジュンニヒョウジセヨ」に見えている。
かろうじて「キーボード」「ハイレツ」あたりの単語は拾えるらしく、標準入力から値とったり配列を作ったりはしてるんだけど、そこから先に進まない。モニターにらみつけてる。またにらみつけるかよ。
あれだ、算数の文章題できなくてとにかく文章に出てくる数値足したり引いたりするやつ。あれのプログラミング版。文章が読めない。
こういう人にはメモ用紙取り出して、まず文章が何について言ってるのか、どういう工程に分けることができるのか、今後も同じことが起こったときにどうやって分けるのか。みたいなのを教えるんだけど、大抵あんまりしっくりこないらしく、成功したことは皆無。なんとかうまく教えたいんだが。
もうこのあたりになってくるとプログラミング関係なくね……?ってなるんだけど、意外とそういうプログラミング関係ないところで詰まる人めちゃくちゃ多いよ。
今すぐプログラミングをやめろ
ChatGPT:
はい、Delphi(Object Pascal)のソースも読めますし、解説・リファクタ・バグ箇所の指摘・他言語への移植案など対応できます。
VCL / FMX、Generics、Interface/RTTI、プロパティ/イベント、レコード・セット型、メモリ管理(string/AnsiString/UnicodeString の違い)、スレッド(TThread / TTask)、WinAPI/COM 呼び出し、uses 単位構成、.dfm(フォーム)やリソース周りもOKです。
コードを貼ってくれれば、1ステップずつ説明や改善案を出します(DelphiのバージョンやVCL/FMXも書いてあると精度上がります)。
UNIFACEはどう?
ChatGPT:
はい、UNIFACE(Proc言語)も対応できます。フォーム/サービス/レポート/エンティティなど各コンポーネントのトリガ(initialize, validate, leave field など)、operation/entry、newinstance/activate/call、retrieve/e, read, write、エラー制御($status, $procerror)や論理名・assignment(.asn)、署名/パラメータ、DSP/REST・SOAP連携、DBドライバ設定までOKです。
コードや .asn を貼っていただければ、処理フローの解説、バグ箇所の指摘、リファクタ、他言語・他フレームワークへの移植案(例:REST API化、Java/Python 置き換え)まで具体的にやります。
可能なら UNIFACE のバージョン(9/10/10.4 など)、DB(Oracle/SQL Server 等)、OS を添えてください。
駆け出しはなるべく早く一人前になるか技術を背景にPMとかにシフトしてくとかしないと厳しいでこの世界
昔っからそうだしReactがRESTかけます!でもJavaでクラスかけます!でも同じ
https://laylo.com/laylo-conjuring4nghilecuoicung/XkU4F652
https://laylo.com/laylo-thecatngonthuhai/qpOT6DjQ
https://laylo.com/laylo-thecatngonthuhai/dya4lHlo
経歴書を見て、ちょっと引いた。
GitHubのスター数が現実離れしてるし、技術ブログも見たことない分量。
使える技術は自分の三倍。React、Vue、Go、Rust……カタカナを追うだけで手一杯だった。
「また意識高い系か」
隣の田村が呟く。俺も同じことを考えてた。
古いコードを一目見て渋い顔をする。会議で「そろそろモダンな構成にしませんか」みたいな提案。
コードレビューは容赦なし。「ここ、コンポーネントに責任持たせ過ぎですね」「エラー処理、もっと丁寧に」「テストコード、当たり前に書きましょう」。
ひたすら正論。
うざかった。
俺たちがどうして汚いコードを書いてるか、この男には分からない。
毎日終電、土日は障害対応で呼び出されて、ただ“動くもの”を積み上げるしかないんだ。
俺たちが一週間かかる仕事を、三日で終わらせてくる。
正直、悔しかった。
前職を調べた。同僚が「有名Web系だったらしい」「やっぱり恵まれてるよな」と言う。
自分はSIer、古い文化に浸かりきった人間。あいつは最初から違った世界の住人。
最初から条件が違うのだから、そりゃ勝てるわけがない、そう思っていた。
「実は俺、文系です。完全未経験からSIerでCOBOLとJavaだけで食ってたんです。毎日終電、土日も当然出勤」
……俺たちと同じだ。いや、むしろスタートはもっと後ろだった。
それでも佐々木は毎朝5時に起きて、出社前2時間、帰ってからも1時間。
土日は技術書を読み倒し、何年でも続けた。
「4年やりました。最初の転職活動は100社受けて全滅。でも勉強して、2回目でやっとWeb系に引っかかりました」
7,000時間近く積み上げて、そこにいる。
俺はと言えば、「環境が悪い」「仕方ない」「時間がない」と言い訳して、家ではYouTubeとゲームだけ。
土日もゴロゴロして何も変えなかった。
才能でも環境でもない。ただ、努力したかどうか。それだけだった。
素直に屈辱を噛みしめ、うなずいた。
明日から一緒に朝活を始める。1時間だけでも、たぶんそれでいいんだと思う。
朝活は、正直きつかった。
寝不足のまま早朝の会議室に集まってコーヒーを流し込み、黙ってテーブルを挟む。もちろん最初は普通に勉強だ。
けれど、だんだんと慣れてくると、俺なりの意地も芽生えてきた。
「ああ、昨日この分野を調べてきたんだ」
「なるほど、そっちの技術ではこうやるのか」
ただ教わるばかりじゃ悔しいので、眠い頭で資料を漁って少しでも佐々木に食らいつく。
知識の差は大きい。でも、佐々木も意外と勝負事が好きらしい。「今日はどっちが新しいツールを導入できるか」みたいな余計なルールまで作り出し、コードレビューでお互いをねちねちいじり始める。
気がつけば、朝活は勉強会というより妙な競争の場になっていた。
「あ、そっちの書き方の方が効率いいな」
「また変なイースターエッグ仕込んでる」
仕事でも張り合うようになった。
些細な設計やリファクタリングの方針ひとつで、絶対譲れなくて熱くなった。むきになって議論する。
他のメンバーには「仲悪いのか」と言われたけど、本人たちは別に悪い気がしない。不思議な高揚感。
次第に会社での評価も上がっていた。成果が出ると、お互いに無言でアイコンタクト。
なんとなく、ライバルってやつになっていた。
飲みに誘ったり、逆に誘われたりすることも増えた。くだらない愚痴をこぼし合い、バグの話で夜中まで笑った。
仕事が終わった金曜に、そのまま繁華街で朝まで過ごすこともあった。
ある日、こんな風に、飲みに誘われた。
静かな居酒屋、少しアルコールが入る。気づけば昔話になり、くだらない話、恥ずかしい話、お互いの情けなさをさらし合う夜。
気付いたら閉店まで二人だけ、なぜか離れがたくて、一緒に深夜の街をふらふら歩いた。
妙な感情が残った。
帰り道、不意に言葉がこぼれる。
「なんかさ、お前といるとずいぶん楽なんだよ」
「……わかる。俺もそう」
見ればわかるくらい、距離が近づいた。
休日に技術イベントがあれば二人で出かけ、休日の帰り道は自転車を並べて走った。
日曜の朝、駅前の喫茶店で合流して、黙ってノート開いて並んでいる時間が、いつの間にかすごく安心するようになった。
仕事も私生活も地続きで、ただ一緒にいることが普通になっていく。
もしかすると、お互い惹かれたのかもしれない。でもはっきり「好き」と言うのは、たぶん、もっと先になる気がする。
この歳で、こういう物語があるとは思っていなかった。でも悪くない。
淡々とした毎日のなかで、少しずつ少しずつ、何かが変わっていた。