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）として提供しています。
JavaScriptランタイム「Deno」の開発元であるDeno Landが、オラクルが所有する「JavaScript」の商標登録の取り消しを米国特許商標庁に申請した件について、オラクルはJavaScriptの商標を自主的に手放すつもりはないとDeno Landに通告したことを、Deno Landが下記のX/Twitterへのポストで明らかにしました。
米国のサイバーセキュリティーを担当する政府機関は10日までに、ショートメッセージサービス（SMS）を使った認証について「外部から傍受される恐れがあり、強力な認証にならない」と注意喚起する声明を公表した。認証アプリなどの利用を推奨している。X（旧ツイッター）や日本のデジタル庁もSMS認証を廃止しており、見直しの動きが広がる可能性がある。
CISAは「SMSは暗号化されていないため、通信事業者のネットワークにアクセスできる攻撃者により傍受され、メッセージを読み取られることがある」と指摘する。SMS認証を使うユーザーに対し、米グーグルや米マイクロソフトなどの認証アプリに変えるよう求めた。
安全な通信手段として、米アップルの対話アプリ「iMessage（アイメッセージ）」といった「E2EE（エンドツーエンド暗号化）」と呼ばれる秘匿性の高いサービスを提示した。偽メールやSMSで認証情報を盗み取るフィッシング攻撃を防ぐため、テック大手が推進する生体認証などの「FIDO（ファイド）」を使うよう推奨している。
SMS認証を巡っては、フィッシングによる「スミッシング」が20年ごろから増えている。契約者になりすまして再発行したSIMカードを使ってスマホを乗っ取る「SIMスワップ」という手口も横行しており、国内でも23年に愛知県警や警視庁が容疑者を摘発している。
現在の主流であるHDDや光ディスク、フラッシュメモリには物理的な限界があり、さらなる大容量化が難しい状況である。この課題を解決する新技術として、研究チームは原子間力顕微鏡（AFM）の探針を使って、ポリマー表面に微細なへこみを付けてデータを記録する手法を開発した。この技術の革新的な点は、硫黄を含む新しいポリマー材料を使用したことである。
ytt は、YAML ファイルのテンプレートとパッチ作成に使用されるコマンドライン ツールです。また、YAML の断片や山をモジュール チャンクにまとめて簡単に再利用できるようにする手段も提供します。
実際には、これらの YAML ファイルは、Kubernetes 構成、Concourse Pipeline、Docker Compose、GitHub Action ワークフロー ファイルなど、YAML 形式のあらゆるものです。
ytt は、これらのファイルを手動で管理するのが面倒になったり、面倒になりそうになったりする場合に最も役立ちます。
これはおそらくLLMなどの強化学習でも使えるテクニックで、強化学習での教師生成のために(探索を行って)質の高い教師を生成する必要はなく、既存の(質の低い)教師データで桁違いに大きなモデルに学習させて、そいつを蒸留するほうが低い計算コストで済む可能性がある。
先程も述べたような差分が数百行、数千行規模の PR をいきなりレビューしてもらうのは、PR の description やコメントをいくら丁寧に書いたとしても、レビュアーの負担は大きいです。
そこで実装に入る前の段階で Design Doc を作成して、大筋の実装内容について合意を取るようにしています。
Design Doc は以下のようなアウトラインで書いています。
## このドキュメントの目的
## やりたいこと
// ここではビジネス的な視点でなぜこの施策をするのかを書きます
## 仕様
// ここでは上記のやりたいことを満たす機能要件を書きます
## 対応内容
// ここではシステム的な視点でどんな対応が必要なのかを書きます
揉め続けるBcachefs、Linusはサポートを後悔！？
“開発者は殺人犯”のRaiserFSがついにメインラインから完全に削除へ
20年来の悲願、リアルタイムLinuxのサポートが実現
ロシアの開発者12名がメンテナーリストから削除
こんにちは，リファクタリング大好きなミノ駆動です。『良いコード／悪いコードで学ぶ設計入門』の著者です。このたび2024年12月25日に，本書の改訂新版を出版します。
私のさまざまな知見のアップデートを経て，このたび改訂新版を出す運びとなりました。改訂内容は主に以下の7つです。
- 【変更】凝集度，結合度からカプセル化，関心の分離へ
- 【加筆】インターフェースと実装の分離
- 【変更】interfaceの解説を改善
- 【加筆】インターフェースと実装の分離にもとづいたinterface設計
- 【加筆】アンカリング効果
- 【加筆】ジョシュアツリーの法則
- 【加筆】説明による設計スキルアップ
順番に説明します。
滋賀銀行は2024年12月20日、次世代勘定系システムの構築を中止することで日立製作所と合意したと発表した。日立は和解金として滋賀銀行に80億円を支払う。次世代システムの構築は一旦仕切り直しになり、滋賀銀行と日立の双方にとって痛手になる。
滋賀銀行は次世代システムについて「想定を上回るハードルの高さと銀行システムの安定的な提供という観点からサービスインの時期を延伸してきたが、早期の完成が見通せないため、プロジェクトの中止を決めた」（総合企画部）と説明する。
滋賀銀行は2020年9月、日立のオープン勘定系パッケージである「OpenStage」を利用して勘定系システムを刷新する計画を打ち出した。当初は2024年1月の稼働を見込んでいたが、稼働時期を2度にわたって延期した。
次世代システムの完成が見通せないことから、滋賀銀行は約61億円を投じて富士通製メインフレームを更改し、現行システムを使い続ける計画だ。更改時期は2027年1月を予定する。現行システムを継続利用し、次世代システムを構築する時間を確保する。