Linuxディストリビューション5.15では、Linus Torvalds氏がLinuxカーネルにParagon Software製のNTFS3カーネルドライバーを導入を認め、WindowsのNTFSファイルシステムをサポートするためのNTFS3カーネルドライバーが導入されることとなった。新たなドライバーは現在利用可能なNTFSドライバーと比較して機能およびパフォーマンスにおいて優れているとされる（Linus Torvalds氏のコメント、The Register、Phoronix、Market Research Telecast、ZDNet Japan）。

Torvalds氏は8月にNTFS3カーネルドライバーの統合許可を行い、Paragon Softwareに対し、「とにかくGitのpullリクエスト出してほしい」と伝えていたそうだ。対してParagon Softwareは3日にプルリクエストを送ったと回答していたものの、それはTorvalds氏の意向に反し、GitHubのウェブインターフェースから送信されたものだったとのこと。

Torvalds氏は、将来のプルリクエストを改善するため、Paragon SoftwareのKomarov氏にいくつかの注意を行っている。一つはGitHubのウェブインターフェースからLinuxカーネルにコードをマージするのは「絶対に」避けるべきだとするもの。

曰く、GitHubが生成するマージは全く使い物にならない。Linuxカーネルのマージは「適切に」行う必要があるが、マージに関連する情報を含む適切なコミットメッセージが必要だ。しかし、GitHubのマージはすべてを台無しにすると話している。ほかにも、GitHubのアカウントを使用する場合、プルリクエストにブランチだけでなく署名付きタグを付けてほしいなどに関しても指摘している（Linus Torvalds氏のコメントその2）。

あるAnonymous Coward 曰く、

C#のコーディング規約として一番権威あるのは本家Microsoftのものだと思われるが、そのページに、いつの間にか「private/internalフィールドには _ プレフィックス」「private/internalなstaticフィールドには s_ プレフィックス」「ThreadStaticの場合は t_ プレフィックス」を付ける必要がある(should)という項目が追加され、C#er達が大混乱に陥っている(C#のコーディング規則、 発端となったツイート）。

C#においては、後発のUnityがプレフィックスを付ける文化を持っている一方、本家のC#においては、プレフィックスを付けずに this. で参照する文化があり、StyleCop.Analyzersなどのスタイルチェックもこれをデフォルトとしている。また、2010年頃のプログラミング書籍では「メンバー変数にプレフィックスを付けるのはIDEが未発達の頃の名残で、IDEが発達した現代では不要」としてプレフィックスを付けないことが推奨されていたと記憶している。

今回の記述はそうしたこれまでの流れと真っ向から対立するもので、Twitter上ではアンダースコア派が歓喜する一方、this派からは大ブーイングが起こっているようだ。ただし、この規約が書かれたのは6年前でそれが今になって反映されただけといったコメントもあるなど、なんでこうなったかはよく分からない。

元となったコーディング規約はオープンソースの.NETランタイム貢献者向けに書かれたものであり、C#開発者一般に向けたものではない。日本語版にはまだ反映されていないが、英語版には「.NET Runtime, C# Coding Style」から取り入れられたものであることが明記され、使いたければ使えばいいという感じになっている。「s_」「t_」の使用はハンガリアン記法を使用しないよう求める.NETの一般的な名前付け規則に反するが、この点は解決されていない。

なお、元のコーディング規約では「this.」について、「どうしても必要な場合を除いて避ける」と記載されている。

GitHubは6月29日、開発者のコード作成を支援するためのAIプログラミング機能「GitHub Copilot」を発表した。開発者の生産性を向上させる目的のもので、関数名とコメントから関数のコードを丸ごと自動補完するなどの提案も行えるという。Microsoftの「Visual Studio Code」および「GitHub Codespaces」向けの拡張機能として提供されるとしている。登録を行うとテクニカルプレビュー版の招待が受けられるようになるとしている（CNBC、ITmedia、TechCrunch）。

GitHub CopilotはOpen AIと提携してこのツールを開発したという。このAIは何十億行ものコードを使って訓練を受けており、コードを書き進めていくと途中でGitHub Copilotからコードの提案が行われるという。開発者はそうした提案を受け入れたり拒否したりできるとしている。

一方でこのOpen AIの学習にはGitHub上にあるGPLコードも使われていると見られ、GitHub Copilotがプロプライエタリコードを利用している扱いとなり、GPLに違反する可能性もあるのではないかとする指摘も出ている模様（eevee氏のツイート）。

あるAnonymous Coward 曰く、

現在はテクニカルプレビューだが、将来的にはこの機能をベースにした商用製品の発売を予定しているという。ただし関数名やコメントは「平易な英語で」記述する必要があるため、日本人プログラマーが活用するのにはまだ難しいだろう。

headless 曰く、

Ars TechnicaのRon Amadeo氏によれば、Huaweiの「独自OS」HarmonyOS 2.0のベータ版はAndroidのフォークにしか見えないそうだ(Ars Technicaの記事、 The Vergeの記事)。

Huaweiは最悪の事態に備えて2012年から独自OSを開発しており、IoTデバイス用のOSとして使用していたが、最悪の事態が現実化してAndroid OSを使用できなくなったことからスマートフォンにも投入する計画を示している。HarmonyOSについてHuaweiの王成録氏は先月、Androidのコピーでもなく、iOSのコピーでもないと述べていた。

HarmonyOS 2.0のユーザーインターフェイスはHuaweiのAndroidデバイスと同じEMUIを使用するため、外見が似ているのは当然といえば当然だが、HuaweiのアプリストアApp Galleryで入手可能なシステム情報アプリを実行すると、「Android 10 Q」と表示されるという。また、設定アプリでインストール済みアプリのリストを表示すると、Androidのパッケージがいくつも表示されるようだ。さらに「HarmonyOS System」というパッケージのバージョンは「2」ではなく「10」になっている。

HuaweiはHarmonyOSを「OpenHarmony」としてオープンソース化する計画を示しており、既にIoT向けバージョンはソースコードが公開されているが、こちらはHarmonyOS 1.0ベースであり、HarmonyOS 2.0とは明らかに異なるようだ。スマートフォン向けのバージョンは4月以降の公開となるため、現在のところソースコードを照合してフォークかどうかを確認することはできない。ただし、Amadeo氏が実行してみた限りAndroidと明らかに異なる点は見当たらないとのこと。ベータ版のOSにしては完成度が高過ぎるとも指摘している。

HuaweiがAndroid Open Source Project(AOSP)をフォークして独自OSを開発することに問題はないものの、Huaweiはフォークしたとは言っていない。HarmonyOS開発者サイトのドキュメントを検索しても「Android」を含むページはヒットしない。ただし、Google検索により、AOSPに言及するオープンソースライセンス関連ドキュメントが2件見つかった。

なお、SDK入手には登録が必要であり、写真入り身分証明書やクレジットカード表面のスキャンをアップロードするなどしたうえで、2日間の確認待ちが入るという大掛かりなものとのことだ。

あるAnonymous Coward 曰く、

元ネタが投稿されたのは1年ほど前のようだが、「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？」(Why doesn’t Japan excel in software as they did in hardware?) というQuora記事の翻訳が話題になっていたので共有したい（Quoraの英語記事, Qiitaの翻訳）。

この記事では複数の仮説が挙げられているが、要約すると
1. 「日本人の職人気質や完璧主義が、ソフトウェア開発のパレートの法則やアジャイル文化と合っていない」
2. 「ソフトウェア開発職を他の技術職と同じように新卒一括採用や専門軽視で採用している」
3. 「英語が話せず、海外では古くなった技術や開発スタイルが今も跋扈している」
4. 「国際標準との互換性を軽視する」
となっている。

日本の中から見ていると分かる部分分からない部分もあるだろうが、スラド諸氏はこの分析、どう感じるだろうか？

情報元へのリンク

Apache Log4j 2 でリモートコード実行の非常に深刻な脆弱性 (CVE-2021-44228) が見つかり、修正版の Log4j 2.15.0 が公開された (Apache Log4j Security Vulnerabilities、 The Register の記事、 LunaSec のブログ記事、 The Verge の記事)。

この脆弱性はLog4j 2 の JNDI 機能が攻撃者にコントロールされた LDAP やその他の JNDI 関連エンドポイントに対する保護を行わないというもので、Log4j 2.0-beta9 から 2.14.1 までのバージョンが影響を受ける。攻撃者は脆弱性のある Log4j 2 に特定の文字列をログとして記録させることで、LDAP サーバーから任意のコードを読み込んで実行させることが可能だ。この脆弱性を使用するエクスプロイトが既に公開されており、「Log4Shell」などと呼ばれている。

これについて あるAnonymous Coward 曰く、

Java のログ出力ライブラリ「Apache Log4j」にリモートコード実行 (RCE) の脆弱性が存在することが明らかになった。

この脆弱性を悪用するために特別な設定は不要で、「Apache Struts 2」、「Apache Solr」、「Apache Druid」、「Apache Flink」などが影響を受けるとのこと (窓の杜の記事)。

プログラムで Java を導入しているところは Log4j も入っているものと考えると影響は広範囲に及ぶものと見られ、GitHub では Apple、Steam、Minecraft などでの実証した画像が公開されている。

ミシガン大学教授のMark Guzdial氏は、同業のコンピューターサイエンス（CS）の教育者二人から、最初のコースでプログラミング言語を気にする必要はない。学生が概念をしっかり学んでいれば、次に学ぶ言語では最初に学習した言語の知識を応用できるとする意見を聞いたという。しかし、Mark Guzdial氏本人は、過去の経験などから二つ目の言語習得はそう簡単ではないとして、先の二人とは異なる考えを持っている（Mark Guzdial氏のブログ、GIGAZINE）。

LISPやMICRO-PLANNERのように、基本的な概念が全く異なる第二言語の学習は、第一言語の学習と同等かそれ以上に難しい可能性が高い。学生がデータサイエンティストになりたいのであれば、C言語を学ぶよりもRやPythonを学ぶ方が合理的だ。こうしたことから、Mark Guzdial氏は、「なぜ最初に学ぶプログラミング言語は重要ではない」という考え方が定着しているのか考えるようになったそうだ。 同氏の考えとしては、1960年代後半にCSカリキュラムが定義されたとき、プログラミングの数学的基盤に重点が置かれていた。このため、現在教育者になってるような人は、現代の学生と比較すると数学的に強い基盤を持っている。このため、言語の違いは表記法の違いに過ぎないと考えているのではないかとしている。

あるAnonymous Coward 曰く、

パーソルキャリア株式会社が運営するIT・テクノロジー人材のためのコミュニティ「TECH Street」が、日本国内のITエンジニア403名を対象とした「理想の開発環境」のWebアンケートを行い、その結果を発表したのだが、いろいろとツッコみどころ満載の結果にネット上に困惑の声が広がっている（アンケート結果, はてなブックマーク）。

特に注目度が高い項目としては「使いたいプロジェクト管理ツール: 1位 Excel 32.3%」「使いたいIDE: 1位 IDEは使わない 32.8%」「使いたいエディタ: 1位 サクラエディタ 38.0%」辺りであろう。またその他も、全体的にMicrosoft TeamsやMicrosoft Projectなどのランキングが高いのも特徴的である。

この結果に対しては、「使いたいではなく使っているでは」「日頃見かける話と違う」「回答者の42.9%がSEで、60%超が40代以上だからでは母集団が偏っているのでは」「むしろ日本の平均を表しているのでは」などの様々なコメントが寄せられている。サクラエディタはともかく、プロジェクト管理ツールでExcelは無いと思うのだが、世の中こんなものなのだろうか？

情報元へのリンク

あるAnonymous Coward 曰く、

たまに燃えることのある「エンジニア」と「プログラマ」の呼称を巡る問題だが、プログラマのための情報共有サイトであったQiitaがガイドラインを改訂し、今後は「プログラマ」のことは「エンジニア」と呼ぶと宣言してまたちょっと燃えているようだ（Qiitaの発表, はてなブックマークのコメント）。

一般的には、プログラミングをする人が全て「プログラマ」である一方、「エンジニア」は機械エンジニアや航空エンジニアなども含めた技術者全般を指す言葉で、特にプログラミングをする人を指す言葉では無いと思うが、Qiitaでは「世の中のエンジニアの定義とは少しずれた定義とはなってしまいますが」と断った上で、同サイトにおいて以後エンジニアを「プログラミングの知識と経験を活用している人」に変更して、今後はこの定義を用いていくとしている。

昨今では未経験者が経緯を知らずにエンジニアを使っている例は非常に多くなったが、だからと言って世の定義と間違っていることを承知で間違った定義に改める理由はないと思うのだが、スラド諸氏の見解は如何に？

情報元へのリンク

就活支援サービス「サポーターズ」は、登録されてるトップエンジニア学生436名を対象に実施した開発環境に関するアンケート調査結果を発表した。ここでいうトップエンジニア学生4は自主的に開発した制作物を保有している学生のことだそう（サポーターズリリース、Ledge.ai）。

調査によると「普段もっとも使っているor好きなプログラミング言語」の項目ではPyhtonが45.6％と2位のJavaScripsの16.5％に大差を付けて1位となった。AIやデータ分析ニーズの高まりから選ばれたとされている。なお3位はRuby、4位はC++、5位はPHPとなっている。「これから挑戦してみたいプログラミング言語」の項目では、Goが41.1％、Rustが23.4％と世間の注目度に合わせたものとなっている。なお開発端末のOSはmacOSが57.8％と最も多く、Windowsは31.9％、Linuxは9.9％であったとしている。