ある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.」について、「どうしても必要な場合を除いて避ける」と記載されている。

headless 曰く、

Googleは10日、デスクトップ版Google ChromeでSharedArrayBuffer APIを使用するサイトに対するクロスオリジン分離義務付け開始をM92(Chrome 92)に延期すると発表した(Chromium Blogの記事)。

SharedArrayBuffer APIは2018年にSpectre対策としてすべての主要ブラウザーで無効化されたが、Googleはサイト分離を導入したChrome 67で再び有効化している。クロスオリジン分離義務付けはSharedArrayBufferのような攻撃者に広い帯域を与えるAPIを制限し、Spectreなどのサイドチャネル攻撃を緩和するものだ。MozillaはFirefox 79でクロスオリジン分離義務付けを導入しており、SharedArrayBufferをM88で導入したAndroid版Chromeでは、当初からクロスオリジン分離が義務付けられている。

Googleはデスクトップ版ChromeでもM91からSharedArrayBufferやperformance.measureUserAgentSpecificMemory()といったAPI使用にクロスオリジン分離の義務付けを開始する計画を2月に発表していた。しかし、フィードバックや報告された問題を受けてSharedArrayBufferのクロスオリジン分離義務付けをM92に延期するとのこと。

なお、Chrome 92のリリースまでに対応が間に合わない場合、Chrome Origin Trialsで取得したオリジンのトークンを「Origin-Trial」HTTPヘッダーに追加することでChrome 96までは現在のAPIの挙動を維持できる。

headless 曰く、

Microsoftは10日、eBPFをWindows上で実行できるようにする計画を発表した(Microsoft Open Source Blogの記事、 Phoronixの記事、 The Registerの記事、 BetaNewsの記事)。

eBPFはカーネルソースコードを変更したり、カーネルモジュールを読み込んだりすることなしにLinuxカーネル上でサンドボックス化されたプログラムを実行する仕組み。プログラム可能性や拡張性、敏捷性を提供する革新的な技術として知られており、DoS保護などのユースケースに適用されてきた。eBPFサポートは元々Linuxカーネル上に実装されたものだが、他のOSで利用可能にすることや、カーネルだけでなくユーザーモードのサービスやデーモンにも拡大することへの関心が高まっているという。

Microsoftのebpf-for-windowsプロジェクトはWindows 10/Server 2016以降でeBPFを動作させるもので、開発者が使い慣れたeBPFツールチェーンやAPIを利用可能にすることを目指す。プロジェクトはeBPFのフォークではなく、IO VisorのuBPFやvbpfのPREVAIL eBPF verifierを含む既存の複数のeBPFオープンソースプロジェクトがWindows上で実行できるよう、Windows特有のホスト環境を追加する。プロジェクトは一般に適用可能(Linux固有ではない)なフックやヘルパーをeBPFプログラムでサポートすることを意図しており、eBPFプログラムとやりとりするアプリケーションにソースコードの互換性を提供するLibbpf APIをWindows上で公開するとのことだ。

headless 曰く、

Googleは6日、Google Playのアプリがユーザーから収集するデータの扱いについて明示する安全性セクションの追加計画を明らかにした(Android Developers Blogの記事)。

安全性セクションはアプリのプライバシーに関する情報を開発者が容易に公開し、ユーザーが容易に確認できるようにするものだ。アプリが収集または共有するデータの種類や用途に加え、1)データの暗号化などセキュリティに配慮しているか、2)ファミリーポリシーに従っているか、3)機能上必要なデータまたはユーザーが許可した場合に限定してデータを収集するか、4)安全性セクションの内容がサードパーティーにより確認されているか、5)ユーザーがデータの削除を要求できるか、といった要素が導入されるとのこと。

Appleは既にApp Storeでアプリのプライバシー情報表示を開始しているが、Google Playの安全性セクションも同様のものになるとみられる。開発者の正直さに依存し、不正確な情報の申告が判明した場合に修正を求める点もApp Storeと同様だ。

安全性セクションに関するポリシーは第3四半期に公開され、第4四半期にはGoogle Playコンソールで開発者が安全性セクションに表示する情報の設定が可能になる。ユーザーが情報を閲覧可能になるのは2022年第1四半期で、第2四半期には既存・新規を問わず、安全性セクションに表示する情報の設定がすべての開発者に義務付けられる。

著名投資家バフェット氏率いる投資会社バークシャー・ハザウェイ（Berkshire Hathaway）のクラスA株価が、ナスダックのシステムで処理できる株価の上限に迫ったことから、ナスダックがデータ送信を停止する措置を取ったという。ナスダックのコンピューターがカウントできる株価の上限は42万9496.7295ドルで、一方のバークシャー・ハザウェイの株価は5月10日時点で44万2500ドルとこれを突破してしまっている（CNN、WSJ）。

WSJの記事によると、表示の上限があるのは株価の記録に採用している数値の形式に32ビットを採用しているためで、32ビットで表せる最大値は「4,294,967,295」であることからこうなってしまったそうだ。各記事では株式市場版の2000年問題であるとしている。

この結果、一部の証券会社やメディアはナスダックから同株の情報を得られない状態に陥ったことから、別の企業などから情報を得ることで対処している模様。CNNの記事によれば、ナスダックから再び同株の株価情報が再び入手できるようになるのは今月17日以降になる見込みだそうだ。

あるAnonymous Coward 曰く、

任天堂は6日、Nintendo Switch用プログラミング学習ソフト「ナビつき！ つくってわかる はじめてゲームプログラミング」を6月11日に発売すると発表した( ニュースリリース、 製品情報、 ファミ通.comの記事、 4Gamer.netの記事)。

デモ動画を見て頂くとわかりやすいが、コントローラの入力や動作などを司るノードを繋いでいくことでプログラミングを行ういわゆるビジュアルプログラミングとなっている。アクションゲームやシューティングゲームなど7種類のゲームに対応したナビつきレッスンと、自由にプログラミングを行うフリープログラミングモードを搭載する。作ったゲームはNintendo Switch Onlineで公開するほか、ダウンロードしたゲームをアレンジすることもできるようだ(編注: ゲームの公開やダウンロードをするにはNintendo Switch Onlineへの加入が必要がある。加入しなくてもローカル通信で共有することは可能)。

デモの後半には製作されたゲームの例が写っているが、アイディア次第ではいろいろなジャンルのゲームを作る事ができそうだ。プログラミング学習ソフトの決定版となるか？

税込価格はパッケージ版が3,480円、ダウンロード版が2,980円。パッケージ版にはレッスンで覚えたことを後で参照できる「ノードンふりかえりカード」が付属する。

Microsoftは6日、Windows 10 Insider Preview ビルド21376をDevチャネルで提供開始した(Windows Insider Blogの記事、 WSLのGitHub Issue #6839)。

前回のビルド21364ではWindows Subsystem for Linux(WSL)のLinux GUIアプリサポート機能(WSLg)が導入されたが、一部の環境では無効化しないとWSL上のLinuxディストリビューションが動作しなくなる問題が発生していた。本ビルドでは問題が解消しており、前ビルドでWSLgがサポートされなかったSandy Bridge世代CPU搭載機でもLinux GUIアプリの実行が可能になっている。

なお、本ビルドではフォント「Segoe UI」の改良版となる「Segoe UI Variable」が追加されている。Segoe UIは名前の通りUIフォントで、英語版などのWindowsではデフォルトのUIフォントになっている。従来、フォントは小さい文字を印刷する用途と大きい文字を画面に表示する用途とで異なるデザインが行われてきた。Segoe UIは9ptでの使用を想定してデザインされており、この文字サイズでは非常に優れたフォントだが、より大きなサイズでの表現は制約され、より小さなサイズでは読みやすさに欠ける問題があったという。

Segoe UI Variableではサイズに応じて文字間隔やカーブの強さ、小文字の高さの基準となるxの高さなどを動的に変化させることで問題を解決したそうだ。実際のUIへの適用は時間をかけて順次行われていくとのことだ。

先日、筑波大で新入生が高機能な代替授業データベースを作ったという話題があったが、このシステムが大学の公認システムとして運用されることになったそうだ。大学側「システムとして優れたものであるため」ことや在学生が開発したことも考慮した結果、内部の会議を経て公認されることになったとしている。大学の旧来のシステムと併用される形になる模様（ITmedia）。

Googleは4月29日、Google Playストアで公開するアプリのメタデータに関するポリシー変更の事前発表と、プレビュー用アセットに関する新ガイドライン発表を行った(Android Developers Blogの記事、 プレビュー用アセットのガイドライン、 The Vergeの記事、 Android Policeの記事)。

今回の変更はユーザーをミスリードするメタデータやプレビュー用アセットの使用を禁じ、アプリの品質と見つけやすさを向上させるのが目的だ。メタデータに関するポリシー変更では、アプリのタイトルを30文字以内に制限し、アイコンやタイトル、開発者名にアプリのPlayストアでの評価や宣伝、ユーザーをミスリードするテキストや画像の使用を禁止する。

禁じられる評価の例としては「top」「#1」「best」といった語句や優勝カップの画像、宣伝の例としては「free」「sale」「NoAds」といった語句、ミスリードの例としては「update now」「download now」といった語句が挙げられている。また、絵文字の使用や記号の繰り返し、単語すべての大文字表記(アプリのブランド名がすべて大文字表記の場合を除く)も禁じられる。

プレビュー用アセットに関しては、アプリやゲームの内容を正確に伝えてユーザーの選択の助けになることや、適切なローカライズのほか、メタデータと同様に「free」「best」などのバズワードを含まないことが挙げられている。

新ポリシーや適用開始時期については今年中に発表し、プレビュー用アセットのガイドラインは今年下半期に使用開始するとのことだ。

Holy Cater氏の作成した究極のプラグラミングツール（自称）がバズっている。リンク先の画像を見ていただければ、一発で何か分かるネタなのだが、SimPad Nanoという小型キーパッドを利用して作成したコピー・ペーストの専用キーボードとなっている。キートップにデカデカと貼られた「コピ」＋「ペ」の文字のインパクトが強烈だ。左のキーにコピー(Ctrl+C)、右のキーにペースト(Ctrl+V)が割り当てられており、プログラミング時に必要不可欠なコピー＆ペーストが手早く行えるのが特徴となっている（Holy Cater氏のツイート、PC Watch）。

headless 曰く、

GoogleのCOVID-19接触通知システムで、プライバシーリスクにつながるデータがサードパーティーのプリインストールアプリから読み取れる状態になっていたそうだ(The AppCensus Blogの記事、 The Markupの記事、 The Vergeの記事、 SlashGearの記事)。

問題のデータは近くにいるユーザー同士が送受信する近接識別子「Rolling Proximity Identifier (RPI)」と、RPIを送ってきたユーザーのMACアドレスだ。GoogleのシステムではこれらのデータをAndroidのシステムログへ書き込むようになっていたという。ユーザーがインストールしたアプリはシステムログを読み取ることはできないが、プリインストールアプリは読み取り可能だ。発見者のAppCensusによれば、システムログ読み取りのパーミッションを得たプリインストールアプリは数多くあるようだ。

RPIは公開されるデータなので一見問題なさそうだが、MACアドレスと組み合わせて大量のデータを照合すればユーザー同士の相関図を作ることができる。また、RPIは10～20分ごとに更新されるものの、陽性者が保健当局に秘密鍵「Temporary Exposure Key (TEK)」を提供し、診断鍵として公開された場合、その陽性者に複数のRPIを結び付けることも可能になる。さらに、ユーザーに接触の有無を通知する際、そのデータもシステムログに記録されるとのこと。そのため、個人を特定可能なデータをログに記録しない、というAndroidのベストプラクティスをGoogle自身が守っていないとAppCensusは批判する。

AppCensusは今回の調査を米国土安全保障省(DHS)科学技術局(S&T)から受注して実施しており、この問題を2月に報奨金プログラムを通じてGoogleへ報告したという。しかし、Googleは報告を却下し、自らバグ報告後の修正期限として推奨する60日以上経過しても修正する様子がなかったため、倫理面について議論した末に開示を決めたとのこと。一方、Googleは報告を受けて数週間前に修正をロールアウトし、今後数日中に完了する見込みだとThe Markupに伝えたとのことだ。

元Appleのスコット・フォーストール氏によれば、AppleはiOSにFlashをもたらすべくAdobeに協力したが、残念な性能しか得られなかったのだという(9to5Macの記事、 SlashGearの記事)。

昨年末でサポートが終了したFlash PlayerをiOSは当初からサポートしておらず、iPad発表直後に故スティーブ・ジョブズ氏がFlashのバギーさを批判したとも報じられていた。Appleは2010年にiPhone OS SDKの利用規約を変更してFlashアプリをiPhone用にパッケージングしたアプリを禁じており、同年AdobeはiPhone用Flash技術の開発打ち切りを決めている。

フォーストール氏によると、当時AppleはFlashがiPhone上で動作すれば素晴らしいと考えており、どうにか使えるようにしようとAdobeに協力したそうだ。しかし、FlashはWindowsやMacでセキュリティ上の問題を引き起こしていたうえ、iOS上ではパフォーマンスが非常に低く、消費者に付加価値を提供できるようなものではなかったとのことだ。

headless 曰く、

AppleがiOS 14.5/iPadOS 14.5のリリースに合わせてHuman Interface Guidelinesを更新し、ユーザートラッキング許可を求める際の禁止事項を追加している(Human Interface Guidelines - Accessing User Data、 Mac Rumorsの記事、 Softpediaの記事)。

iOS 14.5/iPadOS 14.5ではアプリがユーザーをトラッキングしたりデバイスの広告識別子にアクセスしたりする場合、AppTrackingTransparencyフレームワークを通じた許可を得ることが必須となった。更新された項目はタイトルがこれまでの「Requesting Permission」から「Accessing User Data」に変更され、ユーザートラッキングに関する内容が追加された。

禁止事項としては、追跡許可と引き換えに金銭的なインセンティブを提供することや、ユーザートラッキングリクエストに似せた画面を表示すること、AppTrackingTransparencyフレームワークが表示するアラート画面の画像を使用したり、注釈を入れたりすることが挙げられている。

Microsoftは4月19日、Visual Studioの次期バージョンとなる「Visual Studio 2022」を発表した。2021年夏のリリース予定となっている。特徴としては64bit化されたことにより、メインプロセスである「devenv.exe」にあった約4GBのメモリ制限がなくなる。これまで通り32bitアプリの開発も行えるとしている（Visual Studio 2022、窓の杜、GIGAZINE）。

またアイコンのアップデート、新しい等幅フォントの採用などにより、UIがより簡略化されユーザーが作業に集中できる用にしているという。このほか、複数の開発ボックスをデバイス間で同期する機能なども用意される。

あるAnonymous Coward 曰く、

32bit版Windowsで、Cython使った開発するのは諦めろって事なのかな？

情報元へのリンク

先日、ドコモの健康管理サービスが終了することにより、クラウド連動機器の機能が使えなくなるといった話があったが、経済産業省が各社の心拍数や投薬情報などのデータを利用するアプリ間で、データを自由に移せるためのルールを作るという報道が出ている。読売新聞の記事によれば、ルールの内容検討はこの夏から開始し、2022年に事業者を集めて新団体を作成するそうだ（読売新聞）。

記事によれば、規格の違いや運営者の方針で健康アプリ間のデータ移行が自由にできないケースが指摘されているという。参加企業にはAppleやオムロン、ドコモなどが想定されているとしている。事業者同士の規格統一もしくはマイナポータルを経由してデータを共有する方法などが検討される模様。