内部からの告発によって動き出した内部調査委員会の報告が遅れている。
元々24年内予定だったのが遅くとも2月までと遅延し、2月18日には最終的な取りまとめを行なっているとしている。
PyCon JPにおける登壇者採択に関する内部調査委員会の設立
https://pyconjp.blogspot.com/2024/10/selection-view-3.html
なお、調査結果の報告は年内を目標にしており、遅くとも2025年2月までにはご報告できるよう進めています。どうか今しばらくお時間いただけますようお願い申し上げます。
2025年2月18日 現在最終的な取りまとめを行っております。当初の予定より報告が遅れていることをお詫び申し上げます。
経緯はこれら
https://b.hatena.ne.jp/entry/s/qiita.com/python_bokume2/items/7aa80b73010919007581
そして3月に入り休日も過ぎ、平日も過ぎた現在も特に進捗の報告もなく、先日動画配信の報告記事が更新されたが内部調査の進捗には文章中では触れられていない。
信頼が揺らいだ騒動についての報告が最終取りまとめから思ったとおりに進まないということは、単に問題はなかったという報告ではなく込み入った事情が絡んだ報告になるのか。
内容はわからないがともかく、当時の対応、二度の遅延、今の遅延の釈明なし、と現段階では不誠実と感じざるを得ず、報告が問題ないとしても疑わしいし、問題があったと断定してもよほど誠意ある内容でなければこの不信感は消えないものだろう
幾つか理由が考えられます。
1. 拡張性：データサイズには限界があるだろう。おそらくMSとしてはExcelで扱うには不満がある程度には大きなデータを対象にしてる。しかし巨大なデータサイズには対応しそうにない。MS Accessのサーバーを複数台へスケールアウトするのって、ちょっと想像できない。
2. 継続性：Officeファミリーの一部は新版からなくなるモノが多い。継続してくれるか不安。
3. 互換性：新版が出た場合、以前の物と互換性があるか不安。
4. 情報漏洩：セキュリティに不安がある。
.
わたし的には、1レコードのアクセスごとにロックされず、前後の数レコードまとめてロックされるのがいや(RecordLocks プロパティで、2人のユーザーが同じ1つのレコードを同時に編集しようとした時の動作の事ではない)。アプリの設計で、異なるレコードへの同時アクセスの動作が保証されてないとか、例外処理で悩みたくない。例えば、1000番目のレコードと1001番目のレコードを比較してその結果で更新して書き戻すプログラムは書けるが、動作させると（それらは同じ記憶領域の1つのブロックだから）デッドロックになって止まる…とか。
そういうバカみたいな制約から解放されるなら、無料のPostgreSQLを選ぶ。
ちなみに……やたらプロパティとメソッドの呪文がダラダラ長くなる悪癖を持っていても、VBAはロジックとして分かり易いからそれは（わたし的には）問題ない。
経営がDXを推進すべきなのは当然ですが「まずは経営が意識改革しなくてはダメだ」というのも誤認です。「会社でDXが進まないのは、経営|レガシーシステムのせいだ」というのは正しいですが、
- まずは経営が変わらねば
- まずはレガシーシステムを一掃せねば
- まずは内製エンジニア組織を作りSIerを一掃するのだ
という思考に向かうのは、非生産的です。屏風の虎は出てきません。
そんな解けない問題を前に腕を組んで批評だけしていても事態は一向に進みません。もう、2025年です。物事を自分の手で前に進める気がない人は黙ってていただきたい。害悪です。やる気のある若者でも、そういう言説に影響されて腕を組んでしまう。
そうじゃなくて、意識が変わりきらない経営層、色々な問題があるレガシーシステム、足りていない人材という中で「どうやったら会社のDXを進めることができるのか？」という視点に立つべきなのです。
20年前のweb開発、「みんな知らないけど…… HTMLに値を出力するときは………… エスケープというのをするといいらしい！！！！！」（一同感動）みたいなノリだった記憶がある。
本当にみんなエスケープという概念を知らなかったので、その辺のフォームに変な字を入れると30%くらいの確率でXSSできてました。さすがに偽の記憶では？
今回研究者たちが謎のコードを発見したのは、ATARI2600で1982年に発売されたゲーム『Entombed』です。
これは上から下へと画面が移動していく縦スクロールアクションゲームで、プレイヤーは画面に押しつぶされないようにルートを選んで迷路を攻略していきます。
後戻りはできないため、行き止まりにぶつかってしまうとゲームオーバーです（アイテムにより決められた回数だけ壁は破壊できます）。
このゲームの迷路はひどく単純なものに見えますが、当時のゲームカートリッジのメモリでは、予めデザインした迷路セットを保存し、後から読み出して表示するということができませんでした。
そのためこのゲームは、迷路を設定された「手続き」に従ってランダム生成しています。
問題は、このゲームの迷路がどうやって無用な壁の生成や、侵入できないようなエリアの生成を避けているのかという部分です。
このゲームでは、進行に合わせて迷路を連続生成しています。プログラムは現在描画されている迷路を解析し、次に現れるスペースそれぞれに壁を描画するかしないか判断します。
問題は、この壁の配置を決定する基礎理論が、どうやって作られているのか理解できないことです。
壁の配置決定に使われているパラメータテーブルの値が、どうやって導き出されたものなのか全くわからないのです。研究者たちは、テーブルに含まれる値のパターンを見つけようと試みましたが、無駄に終わりました。
しかし、このテーブルの値が僅かに異なったりすると、もう迷路は通行可能な形で描画されません。
研究者たちは後に、このゲームの開発者の1人と接触することに成功しましたが、その開発者も迷路生成のアルゴリズムは当時から理解できなかったと話します。
彼の話によると、担当したプログラマーは「酔って頭をぶつけた拍子に、このアルゴリズムを思いついた」と語ったそうですが、研究者らは問題のプログラマーと接触することはできなかったとのこと。
日本のインターネット黎明期を支えたISPのホームページサービスが徐々に消えつつある。NTTドコモは、ISPサービス「ぷらら」の個人向けホームページサービスを3月末に終了、30年近い歴史に幕を閉じる。
ドコモがぷららの「プライベートホームページ」サービスの終了を発表したのは、2024年6月だった。これによると、25年の3月末をもってサービスを終了し、ユーザーのコンテンツは4月30日に「完全に削除」されるという。
終了の理由は「サービスの利用が近年減少しており、今後継続的にサービスを提供していくことが困難となった」ため。同時に法人向けサービス「BUSINESSぷらら」のホームページサービスも終了する。
4月1日以降はアカウント名やパスワードなどの確認ができなくなるため、過去にアップしたコンテンツをFTPソフトなどでダウンロードしたいユーザーは、3月中に確認することが推奨される。
ドコモのぷらら事業は、1995年に日本電信電話やソニーら5社の共同出資会社として設立されたジーアールホームネットが起源。翌96年からプロバイダー事業を展開してきた。同社はその後NTT東日本傘下となり、22年にはNTTドコモと事業統合している。
インターネット黎明期から続くホスティングサービスには、テキストサイト全盛期に有名になったホームページも複数ある。このためSNSなどでは「（著名ホームページの）侍魂、終わっちゃうの？」「先行者のページ（2000年に中国人民解放軍国防科技大学が発表した二足歩行ロボットを揶揄したコンテンツ）も失われるのか」「我らネット黎明期世代の青春がああああ」などと一部で注目を集めている。
2025年3月2日、C++言語の創始者Bjarne Stroustrup氏が、C++言語を「深刻な攻撃」から守るため、C++コミュニティに支援を呼びかけた。
背景には、過去数年間でサイバーセキュリティ機関や技術専門家がC/C++のメモリ安全性の欠点を指摘し、Rust、Go、C#などの代替言語の使用を推奨してきたことがある。
2024年10月、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、2026年1月1日までにメモリ安全でない言語を使用している製品のメーカーに対し、メモリ安全性のロードマップ作成か、メモリ安全な言語への移行を求めるガイダンスを発表した。
Stroustrup氏は2025年2月7日に「C++標準委員会（WG21）へのノート」を発表し、Profilesと呼ばれるメモリ安全性フレームワークを提案した。
一方、TrapCプロジェクトを主導するRobin Rowe氏は、Profilesが2026年までに間に合わないと指摘し、自身のTrapCコンパイラが2025年後半に準備できる見通しを示した。
ケンブリッジ大学の客員研究員David Chisnall氏は、言語レベルのメモリ安全性ソリューションに懐疑的な見解を示し、CとC++をより安全にするアプローチを支持している。
現在、C/C++で書かれたコードは世界中で数十億行に及ぶと推定されており、これらを短期間で書き換えることの困難さが指摘されている。
Inceptionという会社のMercuryという拡散言語モデルがすごい。
いつか出るだろうと思っていたのだが、なかなか姿を見せなかった、拡散言語モデルである。
いまAIは、「頭の良さの差」を競う段階に来ている。
「頭の良さ」を測る尺度はたくさんあるが、僕は答えの用意されたテストを解くことをたいして良い尺度だと思っていない。まあ答えの用意されたテストしか解いてこなかった人たちにはそれでも十分な尺度なのだと思うが。
拡散モデルは、画像生成の世界ではトップランナーだった。
最近は拡散TransformerのFLUXのようなものが台頭してきたが、速度という点では未だに拡散モデルに軍配があがる。
ただし画像の拡散モデルも、「正確さ」という点ではなかなか厳しいものがある。
しかしMercuryは、速い上に正確な答えを出す。
Go Module providing robust framework for running complex workload scenarios in isolation, using Go and Docker. For integration, e2e tests, benchmarks and more! 💪
Go と Docker を使用して、複雑なワークロード シナリオを分離して実行するための堅牢なフレームワークを提供する Go モジュール。統合、e2e テスト、ベンチマークなどに使用できます。💪
この世に「プログラミング言語」という存在が生まれた1950年代にも、「使いものにならない」と述べるプログラマがいたらしい。アセンブラどころか、バイナリでプログラムを組んでいた人々だ。
生成AIの吐くコードを「使いものにならない」というプログラマを見るたびに、この逸話を思い出す。
実際、当時のコンパイラは性能が悪く、マシンパワーも弱々だったので、彼らの言い分には一理も二理もあったようだ。そういうところも、現在の「生成AIが吐くコード」に似ている。内容を理解していないのに改修どうすんねん？保守性は？セキュリティは？ってツッコミ、ぜんぶド正論だ。
プログラミング知識ゼロのぼくは、今のところClaude 3.7 sonnetで生成したコードをo1 proにデバッグさせて、o1 proで生成したコードをClaude 3.7 sonnetにデバッグさせている。分からない用語が出てきたらo3-miniに解説してもらう。（※Geminiは触っていないから分からない）
簡単なJavaScriptのゲームなら、爆速で作れる。あと、画像生成AIで作った膨大な枚数のイラストを整理（※一括で名前変更したりリサイズしたり1枚に繋げたり）するためのプログラムを、Pythonで作ったりしている。
計算機の歴史からいえば、Claude 3.7 sonnetのようなコーディングに強い生成AIは、「BASIC」に似ているかもしれない。当時主流だったFORTRANなどの言語は扱いが難しく、文系の学生でも扱える言語を目指して――コンピューティングの民主化を目指して――BASICは生まれたらしい。
かつてコンピューターは非常に高額な道具で、大学や企業の「電算室」から動かせないものだった。パーソナル（個人用）コンピューターなど夢物語だった。しかし1960年代になると「タイム・シェアリング」という技術が開発され、1台のコンピューターを複数人で同時に使えるようになった。
タイム・シェアリングによってコンピューターにアクセスできる人間が急に増え始めたことも、BASIC誕生の背景にはあるらしい。
どの製品を「世界初のパソコン」と見做すかには議論がある。有力な候補の1つが、Altair 8800だ。このマシンで動作するBASICを開発したところから、ビル・ゲイツはキャリアをスタートした。BASICは（直接的にも間接的にも）たしかにコンピューティングを民主化した。
同じようなコンピューティングの民主化が、生成AIで起きようとしている……と俺は感じる。生成AIが起こすであろう世の中全体の変化から見れば、これはごくわずかな一端かもしれないけど。
さて、結論から書くと、クリーンアーキテクチャとフロントエンドの関係は以下です。
- クリーンアーキテクチャは、ソフトウェアの中で変わりやすく重要でない部分と変わりにくい重要な部分を、オブジェクト指向プログラミングの機能を使ってオニオン型のレイヤーで分けようというアプローチ
- クリーンアーキテクチャでは、フロントエンド（UI）やフレームワーク、Web、CLIといった外部と、ビジネスルールを表現する内部を分離、独立させることが重要と説いている
- モダンフロントエンドは、HTML/CSS/JS をセットにした小さいコンポーネントを組み合わせたUI管理のためのフレームワークを使って、単方向なデータフローでスケーラブルなアプリケーションを作るというアプローチ
両者を比較するだけでも、UI構築を主戦場とするフロントエンドにクリーンアーキテクチャを持ち込むという発想自体がナンセンスであることがわかります。
東京商工リサーチ（TSR）が2025年1月に発表した調査では、2024年におけるソフトウエア業の倒産数が223件と2015年以降、過去10年間の調査で最多となった。帝国データバンク（TDB）の調査でも倒産数が189件と、こちらも過去10年間の調査で最多だった。倒産企業の大半は中小規模の事業者という特徴があり、最も大きい倒産規模でも負債額は10億円未満だった。
倒産したソフトウエア業の中でも最も大きな割合を占めるのが、受託開発ソフトウエア業だ。TSRの調査で223件のうち209件、TDBの調査で189件のうち160件を占める。「（2024年の受託開発ソフトウエア業における倒産件数は）2023年調査との比較で約20％増加しており、増加率は高い」（帝国データバンクの旭海太郎情報統括部情報統括課副主任）。
贅沢言うなって言われそうだけど、僕が未経験やジュニアのエンジニアに求めるのは、前述した「具体と抽象を行き来する思考回路」を組み上げる工程に時間がかかることを知ったうえで、時には寝る時間を削ってコードを書くのも厭わない姿勢と踏ん張ってみようとしてくれるか。「このままでは終われんぞ！」っていう気持ちが、少しでも持てるかどうか。
一言で言えば、「もっとわかりたい」と思えるストイックさがあるかどうか。それが全くないなら、この領域は向いてない。この一コマがすごい好きです。
一部CTO達や技術系著者、関係する協会などは、
「開発者体験」「開発の不確実性」「事業へのコミットメント」といった、
今となっては私には不適切に思える言葉を多用する
なぜ不適切に思うか。後述するけど、要するに、過剰なあめ玉を開発者コミュニティに供給し続けたことになっていたと私はみているから
よかれと思ってやってきたのかもしれないけど、日本の開発者とビジネス側の分断、また開発者間の分断、そしてなにより効率低下を促進してしまったように思う
よく誤用される意味での「心理的安全性」をむやみに与えたように見える。不要なぬるま湯
企業を全体最適の視点から、そのビジネスプロセスとシステムを再設計するエンタープライズ・アーキテクト。エンタープライズ・アーキテクトは、データサイエンティストを抜き、今や、米国で人気トップの職業となっています（2022年、米国グラスドア調査による）。 ビジネスプロセスのアーキテクチャ設計の基盤となる概念構造化モデリング手法が「PRePモデル」です。
PReP（プレップ）モデルは、NAIST（奈良先端科学技術大学院大学）ソフトウェア設計学研究室で研究開発された、業務プロセス改善、サービス開発、システム要件定義など、多くのプロジェクトでその有効性が検証されている、プロセスの構造を分析し、設計するための方法です。
最近、SOLIDの原則について考えていて、その有用性に疑問を感じている。 SOLIDの原則は曖昧で、範囲が広すぎて、混乱を招き、場合によっては完全に間違っている。しかし、これらの原則の動機は正しい。問題は、ニュアンスの異なる概念を簡潔な文に落とし込もうとすることにあって、翻訳の過程で価値の大部分を失っているのだ。 これはプログラマーを間違った道へと導いてしまう（私にとっては確かにそうだった）。
私からのアドバイスだ： 単一責任について話すのをやめて、凝集性の話を始めよう。
NHKシステム開発・移行中断の件について
2025年02月7日
2025年2月4日、日本放送協会（以下、NHK）より、日本アイ・ビー・エム株式会社（以下、当社）に対し、営業基幹システムの開発・移行業務（以下、本プロジェクト）に関する業務委託契約の解除に伴う既払の代金の返還及び損害賠償を求める民事訴訟を東京地方裁判所に提起したこと、およびこれまでの経緯が公表されました。
当社は、本日時点において訴状を受領していないことから、NHKによる請求内容に関するコメントは差し控えますが、経緯に関する当社の見解についてご説明いたします。
本プロジェクトは、NHK指定の移行方針のもと営業基幹システムを新しい基盤へ移行するものであり、プロジェクト開始後に現行システムの解析を実施の上、移行方針及びスケジュール等を確定するという契約に沿って検討を進めてまいりました。
現行システムの解析を進める中で、提案時に取得した要求仕様書では把握できない、長年の利用の中で複雑に作り込まれた構造となっていることが判明したため、当社はNHKに対し、解析の進捗状況、課題およびそれに対する対応策を随時報告し、共にその対応を検討してまいりました。こうした中で当社は、同システムを利用する業務の重要性も鑑みて、NHK指定の移行方針による2027年3月までの安全かつ確実なシステム移行にはリスクを伴うことを伝えてまいりました。そして、2024年5月に、従来の納期のもとで品質を確保した履行は困難であることを報告し、取りうる選択肢とそれぞれの利点およびリスク等を提示いたしました。 NHKは、これをふまえて契約を解除することを決定されました。
当社は、これまでの解析・調査結果等をふまえて、より確実な移行方式の実現に向けた建設的な協議の開始について、2024年の夏以降、先月に至るまで幾度も申入れてまいりました。しかしながら、NHKは、協議の開始に応じることなく代金の返還と損害賠償請求を主張するにとどまり、この度当社に対し訴訟提起したことを公表されました。
こうした結論となり、当社としては大変残念ではありますが、当社は、これまでと変わらずNHKと協議の継続を希望します。
並行して、当社は訴状の内容も検討し、裁判のなかで当社のこれまでの対応と見解を主張してまいります。
2月11日、Creston Blogが「WASMはコンテナを置き換えるだろう（WASM will replace containers）」と題した記事を公開した。この記事では、WebAssembly（WASM）がコンテナ技術を置き換える可能性について詳しく紹介されている。以下に、その内容を紹介する。
僕はもう、カーネル開発プロセスやコミュニティ管理アプローチになんの信頼も置いていない（I no longer have any faith left in the kernel development process or community management approach.）―2020年のプロジェクトローンチ以来、Asahi Linuxのリードデベロッパを務めてきたHector Martinは2月7日、Appleシリコン（ARM）コードのアップストリームカーネルメンテナーを辞任する意向をLinux開発者メーリングリストで表明した。突然の辞任の背景には、Cベースの古参メンテナーとRustコード推進派の対立とMartin自身によるソーシャルメディアを使った炎上狙いがある。
MartinはすでにLinus Torvaldsからメンテナーを外されており、今後、メインラインにおけるAppleシリコンコードのメンテナンスはMartinと共同メンテナーを務めてきたSteve Peterと、Asahi LinuxプロジェクトのメンバーであるJanne Grunauがともに担当することになる。なおMartinはメインラインのメンテナーは辞めたものの、Ashahi Linuxでの貢献は続けるようだ。
Linuxカーネル開発コミュニティに禍根を残すようなメッセージを残し、メンテナーとしての責任を放り出す格好で突然辞任したMartinだが、その直接の原因はAshahi LinuxやAppleシリコンコードではなく、メインラインカーネルへのRustコード統合の進捗に関する自身のいらだち（MartinはRustコード推進派）をMastodonなどのソーシャルメディア上でぶつけたことによる。それも感情的で突発的な行為というよりも、コミュニティ内での古参メンテナーとRust推進派（Rust for Linux / R4L）の議論をMastodonやReddit上で大げさに書きたて、内情に詳しくない一般人に「古参メンテナーはR4Lの活動を妨害している」というイメージを植え付けようとしていたようだ。
こうした特定の個人やグループに対してソーシャルメディア上で攻撃する行為は「ブリゲーディング（brigading）」と呼ばれるが、LKMLでオープンな議論を重ねてきたLinuxカーネル開発コミュニティにとっては当然ながらあまり好ましいアプローチではない。LKMLの複数のメンバーからブリゲーディングを咎められたMartinは2月6日、「もううんざりだ（I'm tired.）」としてCコード守旧派の古参メンテナーの“妨害”行為やパッチレビューシステムの煩雑さに対する不満を書き連ね、最後に「ソーシャルメディアで非難しても効果がないというなら、何をやれば効果があるのか教えてほしい。こっちにはもうアイデアがない」と挑戦的な内容を投稿している。
この記事では、単一責任原則とそれに関連するいくつかのテクニックが、コードにまさにこの品質を与える方法について説明します。優れたコードを書くのは芸術ですが、いくつかの原則は、開発作業が堅牢で保守可能なソフトウェアを作成するために必要な方向性を常に与えるのに役立ちます。 モデルがすべてです
新しい MVC (MVP、MVVM、またはその他の M**) フレームワークに関するほぼすべての本には、悪いコードの例が散りばめられています。これらの例は、フレームワークが提供するものを示しようとしています。しかし、初心者にとって悪いアドバイスにもなります。「モデルにはこの ORM X があり、ビューにはテンプレート エンジン Y があり、これらすべてを管理するコントローラーがあるとします」などの例は、巨大なコントローラー以外の何ものにもなりません。
これらの本を擁護するために言うと、例はフレームワークを使い始めるのが簡単であることを示すためのものです。ソフトウェア設計を教えるためのものではありません。しかし、これらの例に従う読者は、何年も経ってから初めて、プロジェクトにモノリシックなコード チャンクが存在することがどれほど非生産的であるかに気づきます。
モデルはアプリの心臓部です。モデルをアプリケーション ロジックの残りの部分から分離しておけば、アプリケーションがどれだけ複雑になっても、メンテナンスがはるかに簡単になります。複雑なアプリケーションでも、モデルを適切に実装すれば、非常に表現力豊かなコードを作成できます。それを実現するには、まずモデルが本来の機能だけを実行し、モデルを中心に構築されたアプリの機能には関心を持たないようにします。さらに、モデルは基盤となるデータ ストレージ レイヤーが何であるかにも関心を持ちません。アプリは SQL データベースに依存しているのでしょうか、それともすべてをテキスト ファイルに保存しているのでしょうか。
この記事を読み進めていくと、優れたコードとは関心の分離に大きく関係していることに気付くでしょう。
単一責任原則
おそらく、SOLID 原則について聞いたことがあるでしょう。単一責任、オープンクローズ、リスコフ置換、インターフェース分離、依存性反転です。最初の文字 S は単一責任原則 (SRP) を表し、その重要性はいくら強調してもし過ぎることはありません。私は、それが優れたコードに必要かつ十分な条件であるとさえ主張します。実際、下手に書かれたコードには、複数の責任を持つクラスが必ず見つかります。数千行のコードを含む form1.cs や index.php はそれほど珍しいものではなく、おそらく誰もが見たことがあるか、やったことがあるでしょう。
C# (ASP.NET MVC および Entity Framework) の例を見てみましょう。C# 開発者でなくても、OOP の経験があれば簡単に理解できるでしょう。
これは通常の OrderController クラスで、その Create メソッドが表示されています。このようなコントローラーでは、Order クラス自体がリクエスト パラメーターとして使用されるケースがよく見られます。ただし、私は特別なリクエスト クラスを使用することを好みます。繰り返しますが、SRP です。
上記のコード スニペットで、コントローラーが「注文の配置」についてあまりにも多くのことを知っていることに注目してください。これには、Order オブジェクトの保存、電子メールの送信などが含まれますが、これらに限定されません。これは、1 つのクラスには多すぎるジョブです。小さな変更ごとに、開発者はコントローラーのコード全体を変更する必要があります。また、別のコントローラーでも注文を作成する必要がある場合に備えて、開発者はコードをコピーして貼り付けることがよくあります。コントローラーはプロセス全体を制御するだけでよく、プロセスのロジックをすべて実際に収容する必要はありません。
しかし、今日は、これらの巨大なコントローラーの作成をやめる日です。
まず、コントローラーからすべてのビジネス ロジックを抽出し、それを OrderService クラスに移動します。
これが完了すると、コントローラーは、プロセスの制御という本来の目的だけを実行するようになります。コントローラーは、ビュー、OrderService、および OrderRequest クラスのみを認識します。これは、コントローラーが要求を管理し、応答を送信するというジョブを実行するために必要な最小限の情報です。
この方法では、コントローラー コードを変更することはほとんどありません。ビュー、要求オブジェクト、サービスなどの他のコンポーネントは、ビジネス要件にリンクされているため、変更することができますが、コントローラーは変更できません。
これが SRP の目的であり、この原則を満たすコードを作成するための手法は多数あります。その一例が依存性注入です (これは、テスト可能なコードを作成する場合にも役立ちます)。
依存性注入
依存性注入なしで単一責任原則に基づく大規模プロジェクトを想像するのは困難です。OrderService クラスをもう一度見てみましょう。
このコードは動作しますが、理想的とは言えません。OrderService クラスの作成メソッドがどのように動作するかを理解するには、SMTP の複雑さを理解する必要があります。また、必要な場所に SMTP の使用を複製するには、コピー アンド ペーストしか方法がありません。しかし、少しリファクタリングすれば、状況は変わります。
すでにかなり良くなりました! しかし、OrderService クラスは、電子メールの送信についてまだ多くのことを知っています。電子メールを送信するには、まさに SmtpMailer クラスが必要です。将来的に変更したい場合はどうすればよいでしょうか? 開発環境で実際に送信するのではなく、送信する電子メールの内容を特別なログ ファイルに出力したい場合はどうすればよいでしょうか? OrderService クラスを単体テストしたい場合はどうすればよいでしょうか? インターフェイス IMailer を作成して、リファクタリングを続けましょう。
SmtpMailer はこのインターフェースを実装します。また、アプリケーションは IoC コンテナを使用するので、IMailer が SmtpMailer クラスによって実装されるように構成できます。OrderService は次のように変更できます。
これで、何かがうまくいきました。この機会に、もう 1 つ変更を加えました。OrderService は、すべての注文を保存するコンポーネントとやり取りするために、IOrderRepository インターフェイスに依存するようになりました。インターフェイスの実装方法や、インターフェイスを駆動するストレージ テクノロジについては、もう気にしなくなりました。OrderService クラスには、注文ビジネス ロジックを処理するコードのみが含まれるようになりました。
このように、テスターがメールの送信で何かが誤って動作していることを発見した場合、開発者はどこを調べればよいかを正確に把握できます。SmtpMailer クラスです。割引で何か問題があった場合も、開発者はどこを調べればよいかを把握できます。OrderService (または、SRP を心から理解している場合は、DiscountService) クラス コードです。
イベント駆動型アーキテクチャ
しかし、私はまだ OrderService.Create メソッドが気に入りません。
電子メールの送信は、メインの注文作成フローの一部ではありません。アプリが電子メールの送信に失敗しても、注文は正しく作成されます。また、注文が正常に行われた後に電子メールの受信をオプトアウトできる新しいオプションをユーザー設定領域に追加する必要がある状況を想像してください。これを OrderService クラスに組み込むには、依存関係 IUserParametersService を導入する必要があります。これにローカリゼーションを追加すると、さらに別の依存関係 ITranslator (ユーザーが選択した言語で正しい電子メール メッセージを生成する) が必要になります。これらのアクションのいくつかは不要です。特に、多くの依存関係を追加して、画面に収まらないコンストラクターを作成するという考えは不要です。私は Magento のコードベース (PHP で記述された人気の e コマース CMS) の 32 個の依存関係を持つクラスで、この良い例を見つけました。
時々、このロジックをどのように分離するかがわかりにくいことがあります。Magento のクラスはおそらくそのようなケースの 1 つに該当します。そのため、私はイベント駆動型の方法が好きです。
注文が作成されるたびに、OrderService クラスから直接電子メールが送信されるのではなく、特別なイベント クラス OrderCreated が作成され、イベントが生成されます。アプリケーションのどこかにイベント ハンドラーが構成されます。そのうちの 1 つがクライアントに電子メールを送信します。
OrderCreated クラスは、意図的に Serializable としてマークされています。このイベントをすぐに処理することも、キュー (Redis、ActiveMQ など) にシリアル化して保存し、Web リクエストを処理するプロセス/スレッドとは別のプロセス/スレッドで処理することもできます。この記事では、イベント駆動型アーキテクチャについて詳しく説明しています (OrderController 内のビジネス ロジックには注意を払わないでください)。
注文を作成するときに何が起こっているのか理解するのが難しくなったと主張する人もいるかもしれません。しかし、それは真実からかけ離れています。そう感じる場合は、IDE の機能を活用してください。IDE で OrderCreated クラスの使用箇所をすべて見つけることで、イベントに関連付けられたすべてのアクションを確認できます。
しかし、依存性注入はいつ使用し、イベント駆動型アプローチはいつ使用すればよいのでしょうか。この質問に答えるのは必ずしも簡単ではありませんが、役立つ可能性がある 1 つの簡単なルールは、アプリケーション内のすべての主要なアクティビティに依存性注入を使用し、すべての二次的なアクションにイベント駆動型アプローチを使用することです。たとえば、IOrderRepository を使用して OrderService クラス内で注文を作成するなどの処理で依存性注入を使用し、メインの注文作成フローの重要な部分ではない電子メールの送信を何らかのイベント ハンドラーに委任します。
結論
最初は非常に重いコントローラー、たった 1 つのクラスから始めましたが、最終的には複雑なクラスのコレクションになりました。これらの変更の利点は、例から明らかです。ただし、これらの例を改善する方法はまだたくさんあります。たとえば、OrderService.Create メソッドは、独自のクラス OrderCreator に移動できます。注文の作成は、単一責任原則に従うビジネス ロジックの独立した単位であるため、独自の依存関係を持つ独自のクラスを持つのは当然のことです。同様に、注文の削除と注文のキャンセルは、それぞれ独自のクラスに実装できます。
この記事の最初の例に似た、高度に結合したコードを書いた場合、要件に小さな変更を加えると、コードの他の部分に多くの変更が簡単に発生する可能性があります。SRP は、各クラスに独自のジョブがある、分離されたコードを開発者が書くのに役立ちます。このジョブの仕様が変更された場合、開発者はその特定のクラスのみを変更します。他のクラスは、もちろん最初から壊れていた場合を除き、以前と同じようにジョブを実行するため、変更によってアプリケーション全体が壊れる可能性は低くなります。
これらの手法を使用して事前にコードを開発し、単一責任の原則に従うことは困難な作業のように思えるかもしれませんが、プロジェクトが拡大し、開発が継続するにつれて、その努力は確実に報われるでしょう。
「見積もりをしない」という考え方は簡単に実践できるように思えるが、実際にはもう少し複雑だ。見積もりをしないとしても、リリースのスケジュールや統合作業、マーケティング、フィードバックセッションの時期を把握しておく必要があるからだ。
#NoEstimatesムーブメントは「予測を放棄しろ」と言っているのではない。このムーブメントは、多大な苦痛の原因となってきた有害な慣行、つまり「個々のタスクにかかる時間の推測」をやめることに焦点を当てている。
では、推測なしで予測を立てるにはどうすればいいのか。それには、タスクの細分化、実績データ、確率的予測という3つの主要メカニズムが必要だ。
■ タスクの細分化
データを意味のあるものにするには、ばらつきや分散を抑える必要がある。ばらつきの大きさは不確実性を表す。ばらつきには未知の要素が潜むため、一見小さなタスクに思えてもタスクが膨れ上がる可能性を秘めている。
そのため、チームは定期的にタスクを精緻化、細分化し、タスクの複雑さを慎重に調べ、未知の要素を明らかにしようとする。そのタスクに設定した制限時間（例えば3日間）を超える可能性がある場合は、そのタスクをさらに細分化する。
これによって未知の要素による影響を大幅に軽減でき、チームは早い段階で複雑さを把握できるようになる。
■ 実績データ
タスクの進行状況や効率性を把握するため、タスクを開始したら、タスク完了までにかかる時間（サイクルタイム）とタスクの完了頻度頻度（スループット）に関するデータを収集する。このデータ収集にはさまざまな方法がある。
例えば、サイクルタイムやスループットなどの「フローメトリクス」を累積フロー図や散布図で視覚化することで、外れ値を発見して早期対応することができる。同時に、チームは個々のタスクがおおよそどの程度の時間で完了するのかという感覚をつかむことができる。
■ 確率的予測
まだ着手していないタスクについて、チームの推測に基づいて時間を割り当てるのではなく、過去のタスクのデータを使って特定の期間内にタスクが完了する可能性を予測する。これによって、見積もりによる「誤った確実性」の危険性を排除し、確率に基づいたより正直な議論が可能になる。
例えば、「最近完了したタスクを考慮すると、このタスクが2週間で終わる確率は50％だが、4週間なら90％の確率で完了する」といった形で予測できる。
このアプローチによって、チームは工数見積もりなしで予測ができる。これによって、タスクに関する議論の進め方が根本的に変わる。任意の期日に固執するのではなく、状況の変化に応じてリアルタイムで調整されるタスクの完了確率を提示できる。見積もりの精度を上げることに時間をかける代わりに、最もリスクの高い項目を見つけ、それらを分解することに集中する。
特に複雑なプロダクトの場合、従来の見積もり手法から離れ、確率的予測や#NoEstimatesを採用することを検討してほしい。
3行でまとめ
- 自作の OSS、fujiwara/apprun-cli のマルウェア入り偽物を作られて GitHub で公開されました
- 偽物には大量の新規アカウントがスターを付けていたため、検索でオリジナルのものより上位に表示される状態でした
- GitHub に通報したところ、偽物を作ったアカウントはbanされたようです
ゾンビ化ドキュメントを防ぐには・・・
・タイトルだけでドキュメントの中身を見つけやすくする
・同じ内容だが、重複した内容のドキュメントを作らない
・必要な情報が不足している場合は、ドキュメントが必要だった人が加筆していく
・使用されていないものは即時アーカイブする
・ドキュメントマネジメントを諦めない心（マネージャーが諦めない）
さくらインターネットは、同社のクラウドサービス「さくらのクラウド」の新機能として、いわゆるサーバレスなコンテナの実行基盤である「AppRun」の製品トライアル開始を発表しました。
AppRunは現在ベータ版で、2025年中に正式リリース予定です。製品トライアル期間中は全機能が無料で提供されます。
NHKは4日、営業基幹システムの開発中止に伴い、業務委託していた日本IBMに支払った代金の返還や損害賠償を求める訴訟を東京地裁に提起したと発表した。請求額は約54億7000万円。開発方式の見直しにより納期を1年半以上遅らせる必要があるとIBMが申し入れたため、NHKは2024年8月に契約を解除していた。
NHKによると受信料関連の業務を担う現行システムが27年3月に使用期限を迎えるため、新たなクラウド型システムの開発・移行を目指して入札を実施。IBMが約80億円で落札した。22年12月に契約を結んだが、NHKの担当者は「24年3月に入って突然、（IBM側から）開発方式の見直しと、納期の大幅な延伸について申し入れがあった」と説明する。
契約の解除後も既払い代金31億円の返還がなされず、3日に訴訟を提起した。NHKは既に28億5000万円を減損処理している。開発中止を受けて、NHKは現行システムを開発した富士通に委託し、機械の更新という形で対応する。
日本IBMの広報担当者は「NHKには協議を重ねて申し入れてきたが、このような形になったことは非常に残念。訴状が届いていないため、現時点では詳細なコメントは差し控える」と述べた。
転職して割と間もないけど、ばいばいベンチャー！！！！！！！！！！
ベンチャー本当向いてない、利益追求とか売上伸ばすとか、それはまぁいいが競争心とか闘争心とかはなから無いから、ノルマのために頑張るぞみたいなの自分の意識から全然出てこない。ノルマ達成しないとささやかなやりたいことも出来ない。いやそんな、ノルマ達成のために泥沼ベンチャー入るつもりなかったんだよな。内定を貰って受けた俺の見通しが甘すぎた。
組織内はすっかりギスギスして、というか疑心暗鬼で、出社しても誰も愚痴らないし、リモートなら余計に仕事以外の話はしない。個別に飲み会なんかするとポツポツ話されるが、誰がいつチクるか分かったもんじゃない。社内チャットでキラキラ交わされる合言葉は、「ポジティブ」「爆速」「アンラーニング」！
不定期に「自分/プロジェクトの良くないところ」を挙げたうえで「しかし組織の考え方を改めて捉え直して成功させました！」と発表させる会が行われる。情報統制。環境操作。マインドコントロールしてるつもりでじわじわ下がるエンゲージメント。結果が優先、エンゲージメントは後、って言っても言うほど結果出てないんだよな。
勤めたことのあるベンチャーの中でもダントツにノリが険しかった。裁量もなければ報酬も高くない。上位レイヤーは事業創出ごっこでキャッキャして遊んでる。人材開発？ 自己研鑽をしない「他責思考」のやつに得られるスキルやマインドセットはないから。ノルマ達成できないのは自責思考が出来ないお前のせい。ノルマ達成のための商談・獲得はお前のコミットメントじゃねーから口出さないで黙って爆速で成長。
いやーもうベンチャーは懲りたんで、JTCに転職キメた。さよなら「熱量」、さよなら「圧倒的成長」、さよなら「裁量なき責任感」。この組織にいた事、秒で忘れます。ばいばい。
僕の結論は、字面が同じ、つまりコードの重複があるないだけでは、判断できない。意図や目的が同じかどうかも関わってくる、ということ。表にまとめると以下。これが原則的な考え方だと思う。
①字面が同じで意図が同じケース
②字面が異なるが意図が同じケース
③字面が同じで意図が異なるケース
④字面も異なるし意図も異なるケース
というわけで先に示した表を見たらわかるが、字面が同じかどうかというより、意図や目的が同じかどうかで判断するとよい。というか、「字面が同じなら共通化だ！」だと思い込んでると、事故る可能性あるので要注意。
テスト容易性の確保にかかわる責務設計、リファクタリングのためのデザインパターンに、Humble Objectパターン（Humbleオブジェクトパターン、質素なオブジェクトパターン）があります。
Humble Objectパターンは、ユニットテストのデザインパターン集であるxUnit Test Patternsで定義されたものです。近年は書籍「単体テストの考え方/使い方」でテスト容易性を確保する基礎的技術として紹介され、認知が広がっています。
Humble Objectパターンは自動テスト、特にユニットテストをターゲットとします。大まかな概要として、以下を実施します。
- 自動テストで実行しにくいオブジェクトを、「自動テストで実行できるオブジェクト」と、「自動テストで実行しにくいコード」に分離する
- テストすべきロジックの責務をなるべく「自動テストで実行できるオブジェクト」に集中させる。
このHumble Objectパターンはいくつかバリエーションがあります。以下にまとめます。
最近の若手エンジニアの金銭感覚、バグってませんか？という話です。
嬉しいことに、最近のスタートアップやフリーランス市場、外資企業などでのエンジニアへの報酬が明らかに高騰しているように感じます。
[...]
一方で、私みたいな老害おっさんからすると、彼らが高すぎるこの市場で何かが麻痺してしまわないか不安になってしまったのです。
私の個人的なエゴでしかありませんが、エンジニアリング技術は、もっと資本主義から離れて自由な世界線で生きていて欲しいです。
[...]
でも、私は稼ぐ以外にも大事なこと・楽しいことがIT業界にはあると思うのです。私のこれまでのエンジニア人生の中で、一番楽しかったのは、0→1で携わったアプリをリリースする瞬間でした。この瞬間ほど素晴らしいものはなかったと思っています。
お金も大事ですが、お金を稼ぐだけが人生じゃないとも思います。綺麗事のような気もしますが、バランスが大事だと思うのです。
エンジニアという素晴らしい職種に就いた最終的な着地点が「沢山稼いだ。だけ。」はあまりにも悲しいし、寂しいなぁと。
MIXIは新SNS「mixi2」で、「問い合わせを多くいただいていた」という生成AIについての考え方を「生成AIについてのポリシー」として1月14日に公表した。
「創作者の方の懸念に配慮」し、「mixi2上に投稿されたイラストを、生成AIのモデルのトレーニングに活用し、それを利用した新たなイラストコンテンツを生成するプロダクトを提供することはない」との姿勢を示している。
またmixi2では、第三者によるクローリングやスクレイピングなどの行為を利用規約で禁止していると説明している。
Amazon Web Services（AWS）は、コンテナに最適化したLinux OS「Bottlerocket」を2020年9月にリリースしています。
Bottlerocketは一般的なLinux OSが備えるさまざまな機能のなかから、コンテナの実行に必要な機能だけを残して徹底的にスリムダウンし、セキュリティなどを強化したLinuxベースのOSです。Pythonなどスクリプト言語の実行系はもちろん、シェルやSSHも省かれています。
AWSはこのBottlerocketをベースに、同社が提供するコンテナサービスであるAmazon Elastic Container Service（Amazon ECS）に最適化した派生版や、Amazon Elastic Kubernetes Service（Amazon EKS）に最適化した派生版などをAMI（Amazon Machine Images）として提供しています。