僕はもう、カーネル開発プロセスやコミュニティ管理アプローチになんの信頼も置いていない(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コード守旧派の古参メンテナーの“妨害”行為やパッチレビューシステムの煩雑さに対する不満を書き連ね、最後に「ソーシャルメディアで非難しても効果がないというなら、何をやれば効果があるのか教えてほしい。こっちにはもうアイデアがない」と挑戦的な内容を投稿している。
「見積もりをしない」という考え方は簡単に実践できるように思えるが、実際にはもう少し複雑だ。見積もりをしないとしても、リリースのスケジュールや統合作業、マーケティング、フィードバックセッションの時期を把握しておく必要があるからだ。
#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月を予定する。現行システムを継続利用し、次世代システムを構築する時間を確保する。