DRAKON（ロシア語: ДРАКОН; Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность）はソ連がブラン計画のため開発したビジュアルプログラミング言語。
本言語には純粋なDRAKONだと考えられるモデリング及びマークアップ言語としての使い方と、複数の言語ハイブリッドにおける一プログラミング言語としての使い方がある。言語ハイブリッドにおいてはDRAKON-C, DRAKON-ASM, DRAKON-Java等の言語ファミリーとして使用される。その際にファミリー内のすべての言語は統一されたグラフィカル文法を持つ。それが異なる言語使用における図表の類似を実現する。
クラウドファンディングサイト「Makuake」を手掛けるマクアケは8月20日、19日午後3時13分から4時1分の48分間にかけて、ログインしているアカウントが他人のものに入れ替わる不具合が発生したと発表した。これにより、少なくとも1人分の情報が他のユーザーに閲覧されたという。
影響を受けたユーザーは計3916人。それぞれ最大10分にわたって不具合の影響を受け、アカウントが入れ替わったユーザーに氏名、電話番号、住所、メッセージ機能内の送受信情報、登録済みクレジットカードの下4桁や有効期限を閲覧された可能性がある。
このうち1人は、入れ替わり中にクラウドファンディング中のサービスや商品を先行購入できる機能を利用。クレジットカード決済で商品を購入した。ただし、入れ替わり先の氏名やクレジットカード情報は利用せず、新たに自分の氏名やクレジットカード情報を登録し、商品を購入したという。この際、入れ替わり先の氏名やクレジットカード番号の下4桁なども閲覧した。入れ替わり中の決済はこの1件のみで、すでにキャンセルした。
すでに不具合は修正し、全ユーザーを強制ログアウトさせることで入れ替わりの問題は解消した。不具合の原因については「19日午後3時13分に内部的な認証フローの変更対応をリリースした後、本不具合が生じたことが判明した。内部システム変更により発生したものであり、サイバー攻撃などの外部に起因するものではない」（マクアケ）としている。
影響を受けたユーザーには連絡済み。マクアケは今後、決済以外の要因などで個人情報を閲覧されたケースがないかの調査を進めるという。
【編集履歴：2024年8月21日午後4時54分】当初、「登録済みクレジットカードの下4桁や有効期限を閲覧・設定変更された可能性がある」としていましたが、追加の取材により設定が変更された可能性がないことが分かったため、表記を変更しました。また「現時点では、他に個人情報などを閲覧された例は確認していないという」とも表記していましたが、実際には調査中のため、削除しました。
『ドメイン駆動設計をはじめよう』の概要説明
①この本で学んでほしいこと（原著者の思い）
②原著者のドメイン駆動設計のとらえ方
③この本の特徴
④ソフトウェア実装と事業戦略を結びつける方法
⑤事業の成長とソフトウェアの成長
⑥開発チームの学習と成長
2024年7月20日に発売された『ドメイン駆動設計をはじめよう』の概要説明と、ソフトウェア開発現場での活用方法。
①何が書いてあるか？
②事業活動の分析（１章）⇒設計判断 ５章、6章、7章、８章、10章
③業務知識の発見（２章）
④事業活動の複雑さに立ち向かう（３章）
⑤区切られた文脈どうしの連係（４章）⇒実装方法 ９章
⑥事業の成長とソフトウェアの成長（１１章）⇒１章、５章、６章、７章
⑦開発チームの学習と成長（付録A）⇒１章、２章、３章、５章、６章、７章
⑧ドメイン駆動設計の分散型アーキテクチャ（14章、15章、16章）⇒３章、４章
個人的には、ゲームエンジンを書く仕事がなくなった
これはデカいと思うんだよな
ゲームエンジンって職人芸的なところがあった
Unityとか、Unrealとか、物理エンジンもBox2DとかBulletとか、当然昔はなかったので、みんな自前で書いてたはず
例えば、スーパーマリオの物理挙動とか衝突判定は当たり前だけど自前で書いてたはず
でも、今はブロック崩しさえUnityとかUnrealに含まれてる物理エンジンで剛体力学使って書けちゃう
なんかそういうの無駄な計算力だよなと思うけど、まあ書けちゃう、動いちゃう
たしか、チュートリアルかなんかにもあったはず
昔はゲーム作るときって、リードプログラマーが1人いて、他も数人で、少人数で職人芸的に作ってたわけだよ
全て自前でやらなければいけないから、簡易的なものを作るにしても、一応大学でやった物理を再度勉強したりするわけだ
剛体力学とか、流体力学とか、材料力学とか、そのための数学とか勉強し直したりした
あと、ゲーム業界がバブル？だった頃は、海外なんかでは物理とか数学で博士号取ったような奴までゲーム産業に入って来た
彼らはゲーム業界に進まなければ、銀行とか保険会社、証券会社とかもある、もっと高給な仕事がいっぱいあるはずなのに、薄給のゲーム産業に飛び込んできた
彼らが高度な知識で色々な試みをしてくれたおかげで、今のゲーム産業があると言っても過言ではないと思う
だって、日本のゲームってどれも枯れた技術の水平思考ばっかりなんだもん
よく言えば、アイディア勝負
悪く言えば、保守的、必ず作り上げるという意思から石橋を叩きすぎたようなものを作る
今の日本も産業全般まったく同じだよね
例えば、初代のバイオハザードだったか、カメラ固定だったじゃん
今どきアローン・イン・ザダークかよｗって思ったよなｗ
あの頃、自分はPCでDOSとかで普通にFPSやってたから、あくまで技術的にだけど、アホじゃないかと思ったんだよな
でも、周囲のプログラムとかIT業界に関係のない知人とかは喜んで遊んでる
個人的には、凄い冷ややかに眺めてた
なに周回遅れやってんだ、日本のゲームは、って正直思ってた
日本のバイオが固定視点なのに対して、海外勢はFPSとか三人称視点ちゃんと作ってたよな
日本でFPSっぽいの初代PSでちゃんとやってたの、攻殻機動隊だと思うんだよね
今に至るまで、最も原作の意味をくみ取ってたアニメだったし、石野卓球なりの曲も良かった
時は流れて、今の日本のゲームもみんなUnityとかUnrealになった
Godot選択する人もいるかもしれないけど、あれ、良さそうだと思ったけど、情報少なすぎるよね
ソースは公開されてるんだから、ソースを読め的な感じもしたし、今どき？
独自スクリプト勉強するのもなんだな、と思って、ちょっと使う以上に使う気になれなかったんだよな
調べてもらわなくても、まあ、分かるだろうけど、UnityとかUnrealの開発者、日本人とかもいる、はかなり著名なゲームを開発した人も含まれてるよね
彼らは、当たり前だけどUnityとかUnrealがない時代は、当然自分たちで全てを書いてきた人たちだ
リードプログラマーが一人といったけど、かなりの分量をリードが書くはず
ほとんど一人開発と言ってもいい
あと、そういうリードプログラマーは職人みたいなものなので、自分で書いた数学ライブラリとか、物理エンジンとか、持ち歩いて会社を転々としてる人もいたはず
厳密には権利の問題もあるかもしれないけど、そういう優れた人材は引っ張りだこなので、会社を転々として、
その場その場で、自分で1行目から書いた、自分しか持ってない自前のvecmathライブラリとか、物理とか、ノウハウを財産として持って移動しまくってた
で、そうやって業界をサバイバルしてきた人たちのトップランナーが、今はUnityとかUnrealで開発とか営業とかやってる
多分だけど、もうコアな部分を書くことなんてなくなっているだろう
Unity、Unreal以前は、行く場所行く場所で、ゲームエンジンレベルからゼロから書いていた
でも、Unity、Unrealはそれを当たり前だけど共通化するわけで、そしたら一度書けば、それはずっと使われるコードになる、当たり前のこと言ってるけど
で、困っちゃうのは、そんなトップランナーになれなかったゲーム開発者だ
ゲームエンジンを開発するための、数学や物理、コードに関する能力、特にCやC++が多いだろうけど、そういう能力はある
自分は凡人以下だろうけど、かなり凄い人もいるんだろうけど、そういう人も含めて、ゲームエンジンレベルから作る職人芸は無意味、無価値になった
もちろん、まったく無駄にはならない
結局、Unity、Unrealを使うときに、単に使うだけでも中の挙動を勉強しなければいけない
だから、より深く知ることができる能力はあるんだと思う
でもね…
もう、ゲーム開発がコードをガリガリ書く仕事というより、コンテンツを作る作業にほぼなっちゃってないか？
3DCGのモデリング、シェーダー、ゲーム本体も含めて、箱と箱を線で繋ぐような作業でゲームができるようになってる、とっくになってる
そうすると、もうC、C++でガリガリゼロから書いていた人とか、
それこそ、PS2の開発はよく知らんが、悪評が高い、あれはOSレベルから書かされたりしていたように聞いてるし、
そういう人たちもゲーム開発の現場でそういった知識が活かされることはもうない
逆に、北欧で生活保護もらったりしてただろうNotchのマインクラフトとかの方が成功しちゃったりしてるよね
あれはゲームエンジン？と言っていいのか分からんけど、あの独特のボクセルの世界はゼロからJavaで書いたものだ
彼は時間制限でゲームを開発するイベントに数多く参加していて、いつもJavaでサクッとゲームを作っていた
でも、彼は日本だったら成功しなかったように思う
だって、プロのゲームプログラマーっぽくはない、Javaでしか書いてないとか、それこそJavaの方が生産性が高いみたいに言ったら、日本のゲーム業界だったら鼻で笑われてただろう
彼はマインクラフトの前に、ゲーム会社に所属していたし、そこで開発していたのは、世界をすべて緻密に構築するようなゲームだったらしいけど、
自分の予想だけど、そんなの全地球シミュレーターの簡易版みたいなもので、無謀な試みというか、かなり複雑な仕組みになっていたはずだ、自分が聞いてたら、実現できるかさえ怪しい、と思っただろう
彼は途中で会社を辞めて、マインクラフトを作り始めている
彼は世界を緻密なボクセルやポリゴンではなくて、大きなボクセルで実現することにした、まずそこが出発点であることは間違いないだろう
そこからセルオートマトンで川とか水を実現できるんじゃないかみたいに発想が膨らむよね、プログラマーなら
話をまとめると、ITがつまらなくなった話はゲーム開発にも置き換えることができる気がしている
昔のゲーム開発に少しでも携わっていた自分のような人たちは、今の時代では老害だということは重々承知しているし、
多分、今、ゲーム開発に興味がある子供とかがゲームに望んでいること、ゲーム開発でやりたいと思っていること、と自分たちの世代のゲーム開発者がやりたいと思ってたこと、やってきたことは、もう全然乖離してるんだと思う
考えてることが乖離してるんだから、話が通じないのはおかしくない
違う世界を生きてる人、偏差値がいくつ違えば会話が成立しないなんて話もあるように、今の子供たちと会話が成立しないのはおかしくない
そして、当たり前だが、現状を正しく認識しているのは、今の子供の方の可能性が高い
ゲーム開発は職人芸だった
基本的にはCやC++で膨大なコードを短期間に書くことが要求される仕事だった
それが今の子供たち、というか、今の時代の環境に慣れた人たちにできる仕事とは到底思えない
そういうトッププレイヤーは、今はAIなり何か、最先端のものをそういった企業のコアの部署で、コアなものを開発しているはずだ
でも、そうなれなかった人たちはどうなる？
そういう仕事はなくなってしまったんだぞ？
高度な彫り物とかするような職人が、NC工作機器とかで彫り物をするようになったら、職人は必要なくならないか？
伝統工芸だの、人間国宝だの、そうやって手で作ったものの方が温かみがあるみたいなオカルトに守られて生きられる人間がどれだけいるだろうか？
その、人間国宝レベルの人たちがUnityやUnrealのような企業に吸収されていく
あとは過去に開発したゲームのネームバリューを活かして講師職になるとか、そういう感じだろう
そうなれた人間がどれだけいるだろうか？
優れたリードプログラマーに触発され、職人になるべく数学や物理、プログラミングの知識習得を重ね、朝から晩までひたすらコードを書いていたのに、
一発の銃弾で、そういった職人はすべて無意味になった
今の生成AIは大したことないと自分も思うが、驚き屋ｗｗｗとか馬鹿にしてる奴らは、いつかうっかりAIに職を失われないか、よく普段から考えた方がいい
あと、AIに職を奪われたくないから、プログラミング頑張る、みたいな奴は、俺的には間違った頑張り方だと思うｗ
そのプログラミング自体がなくなるかもしれない、って言ってるんだって
技術習得とか、自分の技術でマウンティングし合ったりする暇があるなら、別業種のことでも勉強した方がいい
そういえば、優れたアニメーターだった人が、作画として年齢的に限界にあるし、親族にもアニメーター辞めるように言われてたらしいけど、
ある日バイク事故にあって、アニメーターを続けられなくなって、その人は年齢的にギリギリで清掃車運転する仕事についてたはず
立派な公務員になれて、空いた時間で絵を描いては、市役所などで販売してたはずだ
何が人生として幸運かなんて分からないけど、必ずしもアニメーターが庵野とか宮崎駿を目指すのが幸せなのだろうか？
どこかで自分の仕事を辞めて、それを趣味にして、安定した仕事に就いた方が、心の平安が得られるのではないだろうか？
名誉を優先して、心労で死ぬみたいな人生が良い人生なのか？
というか、富野アニメなんか、やたら名誉を優先して失敗する人が出てくるよね
長い人生生きてきた老害には、ああいうのなんかよくわかるんだよね…😟
■ 追記：驚き屋とバカにしがちな人も注意した方がいい
みんなが驚き屋って読んでる人たちは、基本的にPythonとかも書けないし、計算機科学とか数値計算の知識とか曖昧というか、まったくないような輩がいるし、
元の文章である「ITがつまらなくなった」だったかの文章にもあったように、ビジネスのアイディアだけある胡散臭い素人が乱入してきた感があるわけだけど、
でも、老害って若い世代とか新しいものを疑ったり反発しがちなんだよな、自分も含めて
だから、たしかに驚き屋の連中のかなりは胡散臭い、詐欺師みたいな、出まかせで大金持ちになったスティーブジョブズの極小コピーみたいな連中ばかりではあるけど、
でも、生成AIとか、これから汎用AIとかもどうなるのか分からんけど、どんどん素人に有利になってくと思うんだよな
だって、UnityとかUnrealで作ってる世代はガリガリC++書くのなんて馬鹿げてると思ってるだろうし、
プログラミン技術がもっと怪しいのはWebアプリ界隈も同じだと思うんだよな
RailsやPHPで書いてる連中と、C++で書いてる連中の世界は、見えてる世界がかなり違うんだよ
そもそも、そういう輩はLinuxとかWindows上で書いてるわけで、いわゆる家庭用ゲーム機とかでコード書いたことないだろ？
でも、Xbox発売時にビルゲイツが言ったように、（なんかSEGAだかソニーだか知らんけど）所詮ゲーム機なんて機能が制限されたパソコンだよね、
nVIDIAとかGPUカードどんどん作るんだし、パソコンの方が最先端のグラフィックスが体験できるよね、
みたいに言いつつ、Xbox発売したわけだけど、自分もそう思ったけど、あの預言は的中したよね
もう、Steamでパソコンで十分だろ
情弱と信者だけ任天堂Switchとか使ってるんであって、ビルゲイツが言ったように、ゲーム機の中身は機能が制限されたパソコンだよ
昔、TRONというプロジェクトがあって、あれを孫正義がクソミソに言ったという話があったと思うんだけど、
日本だけで閉じたプロジェクトを出発させても、アメリカの豊富な資金で、カネと資源という暴力で作られるオープンな世界に絶対負ける、ようなことを言ってて、
当然、そのあとIntelなりWindowsに日本は負けるし、半導体としては台湾に90年代で既に負け始めてたわけで、
家庭用ゲーム機も同じで、家庭用ゲーム機の新しいバージョンが出るまでのスパン、機能は固定されるから安定して確実に動作するゲームが販売できるとか、
色々利点はあるんだろうけど、でも、その間に日進月歩で、それこそnVIDIAみたいな企業がどんどん進んでいくわけで、
グラフィクスシンセサイザーｗとか名前はカッコいいけどさ、名前に準じてたら、今頃ソニーNVIDIAに勝ってない？違うでしょ？
話を戻すと、どんどん素人が参入してきて、その素人が頓珍漢なことを言ってるのが不愉快だ、許せない、驚き屋氏ね、みたいな気持ちは分かるけど、
素人が参入できるようになった、というのは、世の中の流れが変わったわけで、そういう若い世代をただバカにするというのは、老害しぐさだよね
気持ちは分かるけど、ドラえもんのように生暖かく見守るとともに、老害も新しい技術とか、素人が驚いていることをちゃんと咀嚼して、吸収していく必要があるんじゃないの？
だって、老害なんだからさ、経験だけは豊富にあるんだからさ？
ちゃんと大学、大学院で計算機科学、情報科学をやってきったわけだし、あやふやな知識でイキってる若者に対して老人が取るべき態度ってそういうもんじゃないの？
例えば、子供が初めて何かを見て驚く、それを大人が見て、そんなのはありふれてる、驚き屋ｗｗｗと思うだろうか？
子供は素人だから初めて体験したわけで、なぜ子供がそれを見て驚いたのか？とか、子供の目線でちゃんと考えられる人は、教える人に向いてる人だと思う
他人に教えることがうまい人は、自分の経験、能力も整理することがうまい
深く理解しているからこそ、他人に教えられるんだよな
だから、驚き屋という子供、素人が何に驚いたのか？という目線を持つのは大事だと思うんだよな
顧客だって素人なんだし、Webとか特に
素人がいちいち驚いてるのを見てバカにする、って姿勢は、老害以前に人として自分は嫌いなんだよな
発送物の印刷や送付を委託していたイセトーがランサムウェア攻撃を受けた影響で、情報が漏えいした恐れがある件を巡り、公文教育研究会（公文）は8月20日、新たに個人情報など約75万人分の漏えいを確認したと発表した。
漏えいしたのは、（1）2023年2月までに公文で算数か数学、英語、国語を学習した会員の会員番号、利用した学習教材、教室名、学年、入会年月など72万4998人分、（2）同月までに公文内部の認定テストの受験資格を満たした会員の氏名、学年、過去に合格した認定テストのうち最もランクが高いものの情報など7万1446人分、（3）0～2歳向けサービス「Baby Kumon」に同月時点で加入していた会員の氏名、生年月日、年齢、保護者の氏名など9922人分、（4）23年8月の認定テストを受けた会員の会員番号や合格情報など2人分──という。
（1）～（4）は重複もあり、漏えいしたのは計73万9714人分。加えて、公文で指導をしていた人の氏名、教室名、住所、銀行口座番号1万7481人分も漏えいした。銀行口座情報は1人分を除いて下3桁がマスキングされた状態だったという。
公文は今後、9月中旬をめどに情報が漏えいした対象者に書面で連絡する。ただしBaby Kumonについては、入会時に住所や電話番号を取得しておらず、会員に連絡ができないため、代わりに対象者向けの問い合わせフォームを設置。問い合わせ内容を確認し、対象者であると確認が取れた場合、指定の住所に手紙を送るという。
公文は今後、委託先に対する審査基準、不正アクセス対策、契約条項の確認、監査や社員教育などを徹底・厳格化し、再発防止を目指す。
公文は6月に情報漏えいの可能性を、7月には会員向けサイト「iKUMONサイト」ユーザーの住所など4678人分が漏えいしたと発表。一方でその後も独自に調査を進めており、今回の発表に至ったという。
イセトーへのランサムウェア攻撃を巡っては、他にも京都商工会議所、クボタ子会社、和歌山市、徳島県などが同様の発表をしており、それぞれ数万件から数十万件の情報が漏えいした可能性があると明らかにしている。
PGlite is a WASM Postgres build packaged into a TypeScript/JavaScript client library, that enables you to run Postgres in the browser, Node.js and Bun, with no need to install any other dependencies. It's under 3mb Gzipped, and has support for many Postgres extensions, including pgvector.
Presentational/Container Component Patternはコンポーネント設計パターンの一つです。 この設計手法ではコンポーネントを"Presentational Component"と"Container Component"の2つに分類してコンポーネントツリーを組み立てていきます。
reduceを使わなくてもおそらく全ての場面においてループ処理で記載でき、そのほうが読みやすいので、わざわざreduceを使う必要がまずありません。
関数型的な、array.forEachや、array.map、array.filter、array.find、array.findIndex、これらは使いやすく直感的なので私はよくつかいます。なので、関数型的なコードを否定するわけではないです。
その関数型プログラミング的なものの中でも、reduce は圧倒的に使いにくく読みにくく、置き換え可能なので使う必要がないだろうと思っています。reduce は forEach, for ,for of などで置き換え可能です。そして置き換えたほうが可読性があがり、修正も機能拡張も高いだろうと思います。
forではなくreduceを使って「こんな新しい構文使いこなせる俺すげー」的な記事を、両手の指の数くらいは見てきたと思います。ループでは数行かかるけど、reduce使えば1行で短いぜ、みたいな記事も多いです。
従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。
著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が発生し、保守性が低下することがある。この問題を解決するために、本の後半でヘキサゴナルアーキテクチャ1による解決策が提示されるという構成になっています。
私のやり方
「2回実装する」
まず、プロトタイプはUXテストだけを目的に実装します。多くの場合、MVCフレームワークのコントローラーレイヤー（本書で言うWeb 層）にベタ書きします。
人間の使い心地を確認したのち、次の段階でソフトウェア視点での使い心地を考慮して書き直します。この時、インターフェイスを決定し、全てのマイグレーションを無かったことにして、インターフェイスからクエリを決め、スキーマも決定します。実行計画でクエリの効率もこの時点で確認しておく。
インターフェイスが決まったら、それを使ってテストコードとプロダクションコードを書きます。Viewレイヤーは、プロトタイプのものをそのまま使えることが多いです。
一発で解決するのは難しいため、このスタイルに落ち着きました。2倍の時間がかかるかというとそうでもありません。ほとんどがコードの移動作業ですし、UXテスト中に発生する「やっぱりこう変えたい」という手戻りを回避できるので、感覚的には同じくらいの時間で済むと感じています。
function TodoList() {
const [todos, setTodos] = useState(['Buy groceries', 'Clean house']);
// イミュータブルな方法で新しいTodoを追加
const addTodo = (newTodo) => {
setTodos(prevTodos => [...prevTodos, newTodo]);
};
// イミュータブルな方法でTodoを削除
const removeTodo = (index) => {
setTodos(prevTodos => prevTodos.filter((_, i) => i !== index));
};
return (
// ... レンダリングロジック
);
}
この例では、addTodoとremoveTodoの両方がイミュータブルな方法で状態を更新しています。これにより、Reactは効率的に変更を検出し、必要な部分のみを再レンダリングできます。
会社の人が困ってSlackで悩んでる時に、答えを知っていて「それは〇〇ですね」って単に答えれば良いのに「☓☓の経験があれば分かりますよ^^」みたいな空中リプライを投稿する嫌味な人の意思決定に従うのマジで無理になってきたんだよな
社内Slackは5chじゃねえ
最近まであまり関わらなかったが
「GenAI Playground Meetup #01 生成AI時代におけるアプリケーション設計と思想」での発表資料
①データの量と種類の爆発
②大規模データを扱うモデル
③中央集権、完全分散、協調分散
④大規模データ、機械学習、深層学習、生成AI
⑤設計の経験則、習熟、共創
⑥設計活動に生成AI技術を利用する
エンジニアに「自分たちのプロダクトをどうしたいですか？」って聞いた時に「こういう機能を作りたい」という意見が少なく、「ここのバグを直したい、リファクタリング・リアーキテクトをしたい、この技術を使いたい」という話ばかりでてくるようだと、まだチームとして未成熟なんだろうな、と感じる
これは、エンジニアのマインド的な話だけではなく、ちゃんとプロダクトのWhyが開発に共有されていないとか、内部品質を犠牲にしまくっているしわ寄せで、どうしてもそちらに目が向いてしまうとかそういう話が背景にあることも多い
「チームが」未成熟と書いたのはそういうことで、開発者がそういう方向に意識が向けられることを促すことが組織としてできているか。顧客と対話できないから顧客のことを想像できないのはそうだし、張り子の虎を必死こいて動かしている状況でプロダクト価値とか考えられないのはそう。
内部品質が低い環境はエンジニアのマインド成長を妨げる、という話なのかも知れない
クリーンアーキテクチャの例は、データの詰め替え過剰にみえる。
『Get Your Hands Dirty on Clean Architecture 』にこのマッピング戦略(詰め替え戦略)が書かれている
- No Mapping (レイヤ間でモデルを共有し、詰め替えをしない)
- 2-way Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しは上位レイヤが詰め替えの責務を負う)
- Full Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しには専用のモデルを使う)
またこの戦略のどれを選ぶかの基準は『Balancing Coupling in Software Design』を合わせて検討すると良い。Balancing Couplingではモジュール間の統合強度として、次の2つを区別している。
モデル結合 (モジュール間でモデルを共有する。契約結合よりも強い結合)
契約結合 (モジュール間のやり取り専用のモデルを作る)
AWS ODBC Driver for MySQLは、MySQLコミュニティが配布している純正のMySQL用ODBCドライバと置き換えて使える互換性を備えつつ、AWSでMySQLを利用する際により優れた機能と性能を実現できるように実装されています。
具体的には、Amazon Auroraにおけるフェイルオーバー時の再接続の高速化です。AWS ODBC Driver for MySQLはクラスタのトポロジーと各 データベースインスタンスがプライマリなのかレプリカなのかの役割のキャッシュを保持することで、接続先のデータベースインスタンスに障害が発生し、別のデータベースインスタンスへのフェイルオーバーが発生したときには、この情報を利用して接続を切り替えることで、DNSによる解決を待たずに高速に新しい接続に切り替えることができると説明されています。
またAWS Secret ManagerやAWS IAMなどによる認証にも対応しています。
今回の問題は突然発生したかのように思えますが、実は同じような問題が数ヶ月前にも発生し、DebianとRocky Linuxのユーザーが大きな影響を受けていたことがわかりました(Neowin)。
Hacker Newsによると今年の4月、CrowdStrikeのアップデートによって、市民技術ラボのすべてのDebian Linuxサーバーが同時にクラッシュし、起動できなくなる問題が発生していたとのこと。
アップデートが、最新の安定版Debianと互換性がなかったことが原因で、ラボのITチームは、CrowdStrikeを削除するとマシンが起動することを発見し、このインシデントを報告しています。
CrowdStrikeは1日後に問題を認めましたが、根本的な原因の分析に数週間かかり、分析の結果、Debian Linuxの設定がテストマトリックスに含まれていないことが判明したとのことです。
RockyLinuxでも9.4へアップグレードしたあと、カーネルのバグが原因でサーバーがクラッシュするという同様の問題が報告されています。CrowdStrikeのサポートはこの問題を認め、不十分なテストと異なるオペレーティングシステム間の互換性の問題への注意が不十分であったと説明しています。
致命的な問題が繰り返し発生していることは、CrowdStrikeのソフトウェア・アップデートとテストの手順について深刻な懸念を引き起こしており、同社の製品に依存している顧客にとっての潜在的なリスクが存在することを浮き彫りにしています。
<クラウドストライクの分析結果>
①C++で書かれたコードがぬるぽ
②その結果Windowsは即座にブルースクリーンを引き起こす
③プログラマがテストやチェックせずに本番環境へアップして強制配布でユーザーを地獄へ
④しかもそれがシステムドライバーゆえにWindows自身にはどうにもできない
「絵柄の真似は許さん」ってのは無理筋なんだよなー
絵柄なんてものを「個人のもの」にしちゃ文化が発展しないってのはもうわかりきった答えだからさ
それでもなお「人間はいいけど、機械に絵柄の真似はさせない」なんて言うなら
「速度に制限をかけろ」って言ってるも同然で
他のAIも全部制限かけなきゃおかしくなっちゃう
自動運転も半自動運転までだし、機械翻訳も人間並みに時間かかるし、AIチャットも実際に雇える人数分しかチャンネル開けない
それが「速度制限」だからね
日本時間7月19日午後1時以降、Windowsデバイスでブルースクリーン（BSoD）エラーが発生し、クラッシュしている報告が数多く寄せられている。地域を問わず、世界規模で発生しているようだ。
この問題は、「CrowdStrike Falcon Sensor」に含まれるドライバー「csagent.sys」によるもののようだ。CrowdStrike社より、問題の発生を認める技術アラートが発表されている。同社は解決に向けて取り組んでおり、詳細がわかり次第顧客と共有するとしている。
「CrowdStrike Falcon Sensor」は、クラウドベースの総合セキュリティソリューション「CrowdStrike Falcon」のエージェントアプリ。このソリューションは企業、政府をターゲットにしているため、個人が影響を受けることはあまりないだろう。
東京ガスの子会社が不正アクセスを受けて個人情報約416万人分が漏洩した可能性がある問題を巡り、侵入経路はVPN（仮想私設網）装置経由であったことが日経クロステックの取材で2024年7月18日までに分かった。現在は外部との接続を遮断するなど対策を講じた上で、被害範囲や原因などについて調査を進めている。2024年7月18日午前10時時点で情報の不正利用は確認されていないという。
不正アクセスを受けたのは、ガスや電力の営業を手掛ける東京ガスエンジニアリングソリューションズ（TGES）。2024年6月26日に、同社ネットワークへの不正アクセスを検知したという。同社は即日、外部との接続を遮断した上で専門機関による協力を受けて調査を進めたところ、特定のファイルサーバーへのアクセスに必要な従業員のIDとパスワードが複数窃取されていたことが、2024年7月9日に判明したという。
窃取されたIDとパスワードは、TGESが顧客情報を保管するファイルサーバーのほか、東京ガスが持つ法人顧客の情報を保管するファイルサーバーにもアクセス可能だった。ただ、実際に窃取したIDとパスワードを使ってサーバーにアクセスした形跡は見つかっていないという。
「何者かによるファイルの暗号化や身代金要求などはない」（東京ガス広報）といい、ランサムウエア（身代金要求型ウイルス）の可能性については否定した。侵入経路はTGESが持つVPN装置経由であることが分かっているが、脆弱性の有無などについては「セキュリティーの関係で回答は控える」（同）とした。
今回の不正アクセスに関しては、TGESへガスや水道などのインフラ情報管理システムの運用業務を委託している顧客に被害が及んでいる。TGESの顧客である神奈川県が2024年7月17日に、県営水道の顧客情報約3万7000件がTGESへの不正アクセスによって流出した可能性があると発表した。このほかTGESの顧客である金沢エナジーも同日、顧客情報が流出した可能性があると発表している。
[...]さらにTenstorrentは、2024年末に第2世代の多目的AIプロセッサを販売する準備をしているとのこと。記事作成時点では、AI向けチップ市場はNVIDIAによってほぼ支配されていますが、ケラー氏はNikkei Asiaに「NVIDIAがうまく対応していない市場はたくさんあります」と述べ、NVIDIAが目を向けていない分野でチャンスがあると考えています。
AIは現代社会のさまざまなシチュエーションで活用されていますが、NVIDIAのハイエンドGPUは2万～3万ドル(約310～470万円)に達するため、企業はより安価な代替品を探しています。Tenstorrentが狙っているのはこの層であり、同社のGalaxyシステムはNVIDIAのDGXシステムより3倍も効率的で、価格も33％安いと主張しています。
ケラー氏はTenstorrentのプロセッサが安い理由のひとつに、大量のデータを高速転送するための高帯域幅メモリ(HBM)を使用していない点を挙げています。HBMは生成AIチップの重要なコンポーネントであり、NVIDIA製品の成功においても大事な役割を果たしてきました。しかし、HBMはAIチップの膨大なエネルギー消費や高価格の原因になっているそうで、ケラー氏は「HBMを使用する人々でさえ、そのコストと構築のための設計時間に苦労しています」と述べ、HBMを使用しないと決定したとのこと。
一般的なAIチップセットでは、GPUはプロセスが実行されるたびにデータをメモリに送信しており、これにはHBMによる高速データ転送機能が必要です。しかし、Tenstorrentはこのデータ転送を大幅に減らすようにチップを設計し、HBMを使わないAIプロセッサを実現しました。
Tenstorrentが開発するAIプロセッサの特徴は、100個を超える各コアにそれぞれCPUが搭載されているという点です。各コアに搭載されたCPUがデータ処理の優先順位を決定することで全体的な効率が向上するほか、各コアが比較的独立しているため、コア数を調整することで幅広いアプリケーションに適応可能だとのこと。ケラー氏は、「現時点ではAIに最適なアプリケーションがどれほどのサイズになるのかわかりません。ですから、私たちの戦略は幅広い製品に適した技術を構築することです」と述べました。
多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。
そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。
※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとんどでした。
しかしながら、ソフトウェアというのは実装してみないとわからないことが多く、実装前に完成の形を予測するのは難しいものです。そのため、適切にソフトウェアを構築したいのであれば、事前に作成された設計に完全に従うことは求めず、実装にともなって変更が加わっていく前提にする必要があります。もし設計にたいして忠実に実装できて価値があるソフトウェアになることを保証したいのであれば、実装相当の検証作業が必要になるはずです。
けれども、上で書いたように設計というのは契約の一部であり作業指示です。そうなると、そのとおり忠実に作ることが前提であり、修正は例外という扱いになり「もし変更が必要になれば差し戻す」という感じになります。変更するには上位存在の承認が必要ということもあったりします。
その結果、多少の不備であればいびつな実装になろうとも従ったほうがマシとなり、大きな変更の必要性に気づいたとしてもそれを差し戻していたら作業開始が遅れるのでそのままにするということも起きかねません。
不備であれば差し戻すとしても、よりよいアイデアが浮かんだからといって、わざわざ差し戻すインセンティブはありません。ソフトウェアのアイデアは実装時に浮かびがちにもかかわらず。
また設計側でも、実装しながらの試行錯誤をしないのであれば実装確度の高い前例踏襲で無難なものになりがちで、やることにあわせた特別な設計は行われにくくなると思います。
実装者に創造的能力を期待せず裁量をもたせず責任をもたせず設計通りにやることを求めるということであれば、「PG」という職種は取り換え可能なコーダーということになりますね。
その結果、価値のあるソフトウェアを開発するというモチベーションは失われ、よいソフトウェアを作ることではなく、契約どおり仕様書どおり設計どおりプロジェクトを完了することが目的化します。
それは、「「実装者が設計を勝手に変えてはいけない」というのはダメでは」のようなことを書いたときに「勝手に変えるのはダメ」という反応がいくつかあったものが、それではよいソフトウェアにならないというものではなく、トラブルなく契約を遂行してビジネスをまわすためにダメという指摘であったことからも伺えます。
その設計では使えないソフトウェアになることがわかったとしても、実装者には責任がなく、むしろそれを指摘して設計やりなおしになると実装開始が遅れるものの納期は変わらなかったりするので、価値をうまないソフトウェアをそのままつくるほうがビジネス的に正しいという、モラルハザードのようなものも発生しがちです。
このように、多重下請け構造ではプロセス自体がソフトウェアの性質を反映してよいものを作れるようになっていないために、よりよくビジネスをまわすことがよりよいソフトウェアにつながっておらず、むしろちゃんとまわそうとすると いいソフトウェアを求めてはいけないビジネス形態になっていて、よりよいものを作ることにインセンティブが働かず、構造的にいいソフトウェアが作れなくなってると思います。
「進歩とは指数関数的なものだ」とはよく言うが、この指数関数は２つのパターンがある。
先へ進むほど段々と効能が下がっていくもの、たとえば何かの練習をしたとき最初は１時間２時間でグイグイ成長していたのがやがて１００時間鍛えてもプラトーが終わらなくなるようなタイプの指数関数。
反対に最初はあまり進まなかったものが途中からドンドン倍々ゲームにインフレしていく、バイバインのような加速度的な増加を起こす指数関数。
そして多くの進歩はこの二つの進化関数が重なりあっている。
つまり、ある部分においてはだんだんと効能が落ち、ある部分においては突然急加速が起きる。
今のAI絵師は一見すると加速的な指数関数が先に起きてから、減速気味な指数関数へと移行したようにも見える。
だが、私はそうは思わない。
今いる場所は単なる一時的なプラトーでしかなく、そのプラトーに滞在する間もAI進歩の倍々ゲームは物凄い勢いで進んでいて、堰が切られた直後に世界は全く別物へと変化するのだろうと。
その瞬間、今まで私のようなパソコンチョットツヨイが保有していた優位性は一気に消し飛ぶのだと思っている。
今でこそAIの活用さえも私のようなパソコンチョッツヨイこそが有利な土壌となっているが、こんなのは本当に今だけだろう。
インターネット黎明期においてパソコンオタクだけがネットの恩恵を受けていた時代があったが、今はもう小学生ですら簡単にスマートフォンでネットに接続できるわけだが、AIがそのレベルになる日が本当にもうすぐそこのようだ。
AIに読み込ませるプロンプトを吐き出すAIの開発が完了したとき、もうそこにあるのは「母国語さえ使えれば、パソコンで出来ることはなんでもAIにやらせられる時代」だ。
そうなったとき、色んな所から送られてきたバラバラの書式のエクセルをサクサクと変換するようなことでさえ「スゴーイ！」「ハヤーイ！」と言われていた我々マクロチョットデキルおじの黄金時代は完全に消えさるだろう。
問題はその時代において我々が何を売り物にして食べていけばいいのかということだ。
第二第三の武器があるならいいが、俺にはない。ないのだ。
この人生、いよいよ先がなくなってきたということである。
ヤバイなー。
どうやって食っていけばいいんだろう。
2年ちょっとくらい前まで、イラストで食っていた。
ただし、バリバリ企業と契約とかして1枚10万とか取っているプロイラストレーターではない。
ココナラとかSkebとかSKIMAとか、そういうコミッションサイトでフリゲーやTRPGやVtuber用の立ち絵イラストを1枚1万弱で売り捌いている、いわゆる「アマチュア底辺絵師」だった。
（そう呼ばれる層にいた、という意味で「底辺」という言葉をあえて使う）
でもよく考えてみたらなんのこっちゃない。起こったのは至極当然のこと。
「自分だけの絵を描く仕事」は奪われてない。消えたのは「クライアントの要望通りの画像を用意する仕事」だ。
技術の進歩によって、機械が「指示に合わせて画像を作る能力」を得たから私みたいな層の受けていた「指示に合わせて絵を描く依頼」は、「機械でもできる簡単な仕事」になったってだけの話である。
さて、AIに代替されたイラスト依頼の話をしているわけだから、
ここらで「依頼者側」としての話もさせてほしい。
私は絵を売る一方で、絵を買う側だった。
[...]
これがAIが出てきてどう変わったかと言う話をする。
結論から言えば、「依頼数は減ったが、使用額は同じ」
これまでは質が低くてもいいから枚数を優先して安い依頼を選んでいたのだが、細部に拘らないなら自分の絵のi2iで簡単にオリキャラのイラストを量産できるようになったから、そう言った画像を作るのはAIに任せて数ヶ月に1度しっかり吟味したイラストレーターさんに数万円の絵を頼んでいる。
絵の依頼って、大きく分けて2種類ある。
1つ目が、「誰でもいいから希望通りの画像を用意してくれ」というもの。
2つ目が、「この人のイラストがほしい」というもの。
1つ目はAIに代替された。AIの方が早くて安くて失敗してもノーダメで文句言わなくて権利関係面倒じゃなくて改変も加筆もし放題だから。ほんのちょっとのイラストスキルがあれば細部は簡単に修正できるし。
2つ目には影響がない。「その人」を求めるクライアントはLoRaがあろうがi2iができようが「その人」に頼むから。「その人の手描きである」という事実に、上で挙げたAIのメリット全部を凌駕する価値があるから。
問題は多分、1つ目の依頼しか貰えない立場なのに自分が売っているのは2つ目だと思い込んでいる絵師が多すぎることだ。
ボーナスタイムは終わってしまったのだ。
もう、対人スキルも、宣伝能力も、人脈も、自分をブランドにできるだけのイラストの実力もないアマチュアインターネット絵描きの絵が売れる時代は過ぎ去った。
思えば本来私程度の人間が、一時的とは言え絵で食えるだけの稼ぎを得られていたと言うのが奇跡だったのだ。
本当にいい夢だった。
IT技術者、そんなにプログラミングをやりたければ、趣味でやれば良いのよ。仕事にするのはプロジェクトマネジメントやコンサルやって、しこたま稼いで超富裕層になろうよ。
建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？という質問がブコメであって、似たような話もいくつか見かけたのですが、建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです。なのでソフトウェアでは自動化されています。
もしも業務システムの納品物が、バベッジの階差機関のような歯車を組み合わせた機械式の計算機で、ビル一棟分に歯車をつめこんで組み立てて納品するというようなことになれば、多重下請けで分業してビルドするのが最もよい方法ということになると思います。
追記
「継続的デリバリーのソフトウェア工学」では、「ソフトウェア開発を選んだ私たちがバカでない限り、私たちにとっての製造とは、ビルドボタンのクリックです」とあります。橋梁建設を例に、物理的な製造・生産との違いが説明されています。
論文執筆は、多くの研究者にとって時に苦痛を伴う作業です。英語を母語としない研究者にとっては特に、言語の壁が大きな障害となります。ChatGPTは、この障壁を一気に取り払ってくれます。翻訳、校正、要約作成—かつては数日を要したこれらの作業が、数分で完了する。その魅力は、抗いがたいものです。
特定の分野、特にコンピューターサイエンスや工学系の論文において、ChatGPT特有の言い回しや表現が急増しているという傾向があります。これは、多くの研究者が既にChatGPTを論文執筆に活用していることを示唆しています。
この傾向は非英語圏の研究者の間でより顕著とのことであり、言語の壁を越えるためのツールとして、ChatGPTは確かに強力です。しかし、それは同時に、学術論文の画一化、さらには研究の多様性の喪失につながる危険性を孕んでいます。
私たちは今、学術界の大きな転換点に立っています。AIによる支援は、確かに研究のスピードと効率を飛躍的に向上させる可能性を秘めています。しかし同時に、研究の本質ー独創性、批判的思考、そして何よりも人間の知性による深い洞察—を脅かす存在ともなり得ます。
この新しい時代において、私たち研究者には、これまで以上に高い倫理観と批判的思考力が求められています。AIを賢く活用しつつ、真の学術的価値を守り抜く、そのバランスを取ることこそが、現代の研究者に課せられた使命かもしれません。
ChatGPTがもたらす功罪：効率と倫理のジレンマ
ChatGPTの登場は、学術界に変革をもたらしています。しかし、この技術は、メリットとデメリットを併せ持つ諸刃の剣です。ここでは、その功罪を詳細に分析し、我々研究者が直面する倫理的ジレンマについて考察します。
メリット：効率化の誘惑
(1) 時間の節約：単純作業の自動化
- ChatGPTは、文献レビュー、要約作成、参考文献のフォーマット調整など、時間のかかる単純作業を驚異的なスピードで処理します。例えば、数百件の論文要約を数分で生成することも可能です。これにより、研究者は 本質的な研究活動により多くの時間を割くことができます。
(2) 言語の壁の低下：非英語圏研究者の支援
- 英語を母語としない研究者にとって、ChatGPTは 頼れるツールとなり得ます。文法の修正、適切な学術的表現の提案、さらには全文の翻訳まで、言語面でのサポートは極めて強力です。これにより、研究成果の国際的な公表が促進される可能性があります。
(3) 文章の洗練：文法的正確性の向上
- ChatGPTは、文法的に正確で読みやすい文章を生成する能力に長けています。この特性は、論文の可読性を高め、査読者や読者の理解を助けるポテンシャルを秘めています。
デメリット：学術の本質への脅威
(1) 正確性の欠如：ハルシネーションと出典捏造の危険性
- ChatGPTは時として、存在しない情報や事実と異なる内容を「ハルシネーション」として生成することがあります。さらに危険なのは、実在しない論文や著者を引用するケースです。これらは、学術的誠実性を根本から揺るがす重大な問題です。（筆者注：このあたりは対策すれば防げます）
(2) 独創性の喪失：既存の再構成に過ぎない文章生成
- ChatGPTの生成する文章は、既存の言葉の再構成に過ぎません。真に革新的なアイデアやパラダイムを変えるような概念を生み出すことは、現状のAIには不可能です。過度の依存は、学術界の知的停滞を招く恐れがあります。
(3) 倫理的問題：盗用、AI authorship、論文millsの横行
- AIが生成した文章をそのまま使用することは、盗用と見なされる可能性があります。（筆者注：参照なしに他の論文を引っ張ってくる可能性は少ないですがAIの書いた文章をそのまま使うこと自体には倫理的に問題があると思います）また、AI自体を著者として認めるべきではないという AI authorship の問題や、ChatGPTを使用して大量の低質な論文を生産する「論文量産工場」の出現など、新たな倫理的課題が浮上しています。
この連休はなんだかSIerについて考えることが多かったのですが、そういうことを考えると、なぜアメリカのソフトウェアが強いのかがわかってきた気がします。
[...]そうすると、アメリカのソフトウェアを開発している人は600万人ということになり、「なぜアメリカのソフトウェアは強いのか」の答えのひとつが「日本の4倍のIT人材がかかわってるから」であり、ではなぜアメリカ国内でもIT人材が増えたかというと、設計をそのままコードに置き換えればいいような付加価値の低い部分はアメリカの国外にだして、アメリカ国内では高付加価値のソフトウェアに集中した結果「稼げる産業」になったからというのがあるんではないかと思います。
プロパー社員が詳細設計書を書き、派遣の方がプログラムするという建前になっているけど、実は詳細設計書も優秀な派遣の方が書いていて、その人の派遣契約をうっかり終了してしまってめっちゃ困るという光景をその昔見たことがある気がする。
納品前に実装者が詳細設計書を書き直す、というのは良くある話な気がする。ちゃんと書き直すだけマシという説もある。
原則として:
- nil, nil はダメ。エラーでなければ何らかの値かオブジェクトを返そう
パターンとして:
- エラーの一種で「なかった」を返す
- ゼロ値や特別な値
- 結果のオブジェクトが「なかった」を表現する
- 結果と取り出すデータが別になっている
コピーコストが問題になる場合を除いては、基本的に値を返すべきです。
なるべく値型を使用したほうがいい理由の一つとして、コードの保守性の問題があります。
値型の場合、メンバへのアクセスがエラーを引き起こさないことはコンパイル時に確定しています。
しかし、ポインタの場合は参照先が存在するかどうかは実行時にしか分かりません。
つまり、アクセスする前にnilでないかどうかをチェックするか、関数がエラーを返していない場合にnilを返さないことを知っている上で取り扱わないと、panicを引き起こす可能性があります。
2024年7月13日の大吉祥寺.pmで発表した「古典ドメインモデリング(パターン)の解脱」のスライドログです。
それがAlways-Valid Domain Modelです。これはドメインモデル(の実装)は、必ずValidな状態でなければならない、Validな状態としてしか生成できないようにしようというものです。 すなわちビジネスロジック層みたいなものは、業務上Validなデータのみを扱うAlways-Valid Layerとして考えよう、というものです。
某62万行だか67万行のゲーム
どんなコーディングしてんのかと思ってghidraにかけてみたけど
・変数はほぼすべて静的に配置されてる
・たしかにCreateWindowAから始まるとか、素のWin32 APIを使ってて、スクラッチからっぽい
・起動時に画像や音楽などすべてのリソースをメモリーに読んでる
・VC++6のデバッグ用のmemsetだかのシグニチャが検出されました。スタックフレームを0xccでうめるコードとかはいっててデバッグ用コンパイルオプションのままで製品用プログラムが吐かれてる
・最適化オプションはoff
・なかみは静的配置されたフラグと即値をの比較分岐の嵐。いわゆる「データドリブン」ではない。プログラムの塊でできている。
・どこでもセーブ・ロードができるのはそういうフラグデータの静的な領域をそのままファイルに書き出してるから。これはこれで皮肉なしにすごい
・exeファイルのなかみはすっからかん。100MBをちょっと超えるサイズだが、zip圧縮すると3.2MBにまで縮まる。
・画像とサウンドはEXE外だが、たぶんマップとかはEXEプログラム内なんだろう。
通常のプログラマーは頭が悪いので「楽をするために苦労をする」性質があり、なるべくあとから修正が楽にできるようにとか、プログラムをどのようにすれば見通しが良く保守性に優れるコードになるかを考えてるが、フォ◯ンアイルの作者は天才なのでそんなことはしない
あまり深く考えることなしに、地道にプログラムを書き続けてできた作品であることがうかがわれる。普通の人はその前に悲鳴を上げてもっと効率の良い方法に逃げる。
プログラミングのセンスや技術は最悪だが、努力という点では他の追随を許さないのではないだろうか。
ちなみに、普通にゲームをプレイする人にとっては、プログラミングの苦労なんてのはめっちゃどうでもいい話なので、プログラム頑張ったんだよ！は普通はアピールポイントにはしない。
頭の悪い普通のプログラマーはもっと短くコードを書いてしまうので普通はアピールしないだけだ。
もうすちーむに返品しちゃったからわかんないよ……ゲーム自体はprotonでちゃんと動くんだが、いろいろやる気が起きなくて。申し訳ない
グラフィックの枚数だとかそういうのはまだ自慢になるが、ふつうはプログラムコード量を自慢するのはよくない。
プログラムコード量がおおいのは、それに見合った規模のプロジェクトでない限り、「私はプログラムを効率よくコンパクトに書く能力がありません」と言ってるのに等しいので。
中身がどうであれ、一作作り上げて完成まで持っていったのはすごいよ。低レベルな話だが、ワナビーの中には妄想だけして手を動かさずに結局何もできないやつばっかりなんだから。
大した事がないエンジニアが社内でスーパーエンジニアだと持て囃され、営業は「スーパーエンジニアは難解なことを言うし、コミュ力が低いからこの人の言う事が理解できないのは仕方がない」と、商材理解を諦める、と言う共犯関係を大昔見た事があります
「スーパーエンジニア」側も、自分の本当のスキルを誤魔化すために適当なことを言ってケムに巻く、というムーブをするようになるという
無能なエンジニアと無能な営業が共に生き残るための共犯関係
当時の僕は今以上に性格が悪かったので、その「スーパーエンジニア」の誤りを淡々と指摘することで、社内で技術者として一定の評価を得た、みたいな事がありました
PyCon JP 2022の発表資料。
イベント駆動アーキテクチャについて実用的なTipsを交えて解説していきます。普段は手続型のプログラミングに慣れている方が、設計パターンから非同期タスクの運用までを理解していただけるようお届けします。
Ladybird は、まったく新しいブラウザと Web エンジンです。Web 標準を第一に考えたアプローチを採用した Ladybird は、優れたパフォーマンス、安定性、セキュリティを備えた最新の Web のレンダリングを目指しています。
SerenityOS 趣味のオペレーティング システム プロジェクト用の HTML ビューアとして始まった Ladybird は、その後、Linux、macOS、その他の Unix 系システムをサポートするクロスプラットフォーム ブラウザに成長しました。
Ladybird は現在、鋭意開発中です。2026 年に早期導入者向けの最初のアルファ版リリースを予定しています。
アルファ版がリリースされたら使ってみるか
Cloud-native search engine for observability (logs, traces, and soon metrics!). An open-source alternative to Datadog, Elasticsearch, Loki, and Tempo.
可観測性 (ログ、トレース、そして近々メトリクスも) のためのクラウドネイティブ検索エンジン。Datadog、Elasticsearch、Loki、Tempo に代わるオープンソースの代替品です。
2024年9月中旬に正式リリースが予定されている統合デスクトップ環境「GNOME 47」では大型のアップデートがいくつも予定されており、今秋リリース予定の「Ubuntu 24.10」や「Fedora Linux 41」などメジャーディストリビューションへの搭載も予定されている。現在、リリースに向けて多くのプルリクエストのマージが進められているが、6月27日にはGNOME Shell/MutterともにX11サポートを無効にし、Waylandのみでデスクトップ環境を構築できるオプションがリリースされた。
GNOMEでは2022年にX11の依存関係をオプションにするためのイシューが立てられ、Waylandのみのデスクトップ環境を構築する動きが活発化していた。今回のプルリクエストのマージにより、GNOME Shell/MutterともにX11の依存関係を必要とすることなくビルドできるようになり、GNOME 47でのX11フリー環境が実現することになる。
https://anond.hatelabo.jp/20240625191650
競プロ出身者だけじゃなく、機械学習出身者も問題コードが多い
印象の問題ではなく実際に下記のようなコードが多い
念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある
■ 正常系しか意識していない
一番多いのはコレで異常系の動作を全く意識していない
入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない
「エラーが出たらとにかくtry-catchしてログ吐いて終わり」
ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる
「ここの処理でエラーログが出てるから対処よろしく」
「対処しました！（握りつぶし）」
とか滅茶苦茶多い
■ セキュリティに関する意識が低い
異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い
API作らせてもリクエストの内容を信用して実装するしサニタイズチェックもしない
サーバー作らせてもrootか共通ユーザーだけで運用するしファイル管理も滅茶苦茶
とにかく「目の前に与えられた課題を解く」だけのコードなので他のことに関する配慮が全く無い
■ 型定義しないし配慮しない
TypeScript使わせてもanyだらけだし、JavaとかだとObjectだらけ
うちはPythonでは型は使わないけど命名規則で担保してるのにそれもガン無視で実装する
結果としてできあがるのは
「一応、正常系では動いているけれど他の入力が来たときにどうなるか分からないし誰も修正できない」
っていうコード
最近はそういうコードはChatGPTにぶち込んで型付けて貰ったりするけど
8割ぐらいの確率でChatGPTも型付けできない状態になっててお手上げになる
■ コピペコードが異常に多い
ネット検索したコードのコピペ、ではなくて
自分で書いたコードのコピペがめっちゃ多い
全く同じ処理なのにメソッド化しないでコピペしてたり
一部の変数を切り出すだけでメソッド化できるのにコピペしてる
そりゃ動くし性能も変わらないけど後でバグがあったり変更するときにすげー困る
これもChatGPTにぶち込んで「共通的な処理をメソッド化して」って言うとやってくれるのでめっちゃ便利
■ 結果が出るだけでクソ遅い（機械学習出身者）
同じファイルをオンメモリに3回ぐらいロードしたり
ほぼ同じDBへの問い合わせが10回ぐらい走ってたり
クソ重いwhileループになってるメソッドをフレンドリーに何回も呼び出したり
とにかく「最終的に出来上がるものが良好であれば時間がかかっても構わない」的なコードが非常に多い
競プロ系はこういう人はあんまりいないんだが機械学習出身者はマジでこれ
彼らはデータを解析したり優秀なモデルを作るために頑張ってきたので継続的に処理負荷を減らす、みたいなことに意識が回ってくれない
「これはPoCですから」
とか言うんだけど誰でも分かるようなクソ遅いコード書いておいて
「ここの処理は時間かかります」
とかしれっと言ってくる