headless 曰く、

世界的な半導体チップ部品不足が続く中、Tesla では対策としてソフトウェアの書き換えを進めているそうだ(The Verge の記事)。

Tesla の2021年第2四半期決算発表資料 (PDF) では半導体不足による影響を軽減するため、新たに 19 種類のコントローラーに対応するファームウェアを開発して検証中だと説明されている。イーロン・マスク氏は決算発表の中で、代替チップに置き換えるだけでなく、ソフトウェアの書き換えが必要になると説明したとのこと。

headless 曰く、

次期 Android 12 をベータテスト中の Google だが、さらに次の Android 13 のコードネームが「Tiramisu」になったのではないかと XDA-Developers が報じている(XDA-Developers の記事、 The Verge の記事、 SlashGear の記事)。

Android のメジャーバージョンにはコードネームとしてデザートの名前がアルファベット順に付けられており、愛称としても使われてきたが、Android 4.4 KitKat 以降はコードネームとは別に同じ頭文字のデザート名が正式名称として付けられていた。

デザート名の正式名称は Android 9 Pie を最後に廃止されたが、コードネームは以降のバージョンでも使われており、Android 10 (Q) は「Quince Tart (QT)」、Android 11 (R) は「Red Velvet Cake (RVC)」、Android 12 (S) は「Snow Cone (SC)」とされる。

Android 13 (T) が「Tiramisu」となった根拠は、AOSP のコミットだ。このコミットは「Rename T to Tiramisu」と題され、「PLATFORM_VERSION_CODENAME.TP1A」の値が「T」から「Tiramisu」に変更(diff)されている。

Google が Android のコードネームを愛称として使うことはもうないとみられるが、The Verge の記事では「Toffee」「Treacle Tart」「Trifle」「Truffles」といった「T」から始まるデザートの名前を挙げている。スラドの皆さんなら何を選ぶだろうか。

headless 曰く、

Googleはページエクスペリエンスによるランキング方式の変更を6月中旬から段階的に導入すると4月に発表していたが、これに伴うAMPに関する変更が始まったようだ(Android Police の記事)。

Web 検索結果の「トップニュース」カルーセルには AMP 形式以外の記事も表示されるようになっており、AMP コンテンツを示す AMP バッジ (稲妻アイコン) は表示されなくなっている。Google ニュースアプリでも非 AMP コンテンツの使用を拡大しているとのこと。

モバイル Web の高速化を目標に発表された AMP (Accelerated Mobile Pages) だが、Web 開発者にとってもユーザーにとっても複雑さが増しただけだったと Android Police は指摘する。スラドの皆さんのご意見はいかがだろうか。

あるAnonymous Coward 曰く、

戦国時代だったテキストエディタ界をVisual Studio Codeが天下統一しつつあるそうだ。

Stack Overflowの調査によると、Visual Studio Codeの人気は2018年の35%から2019年には51%に達し、他のエディタが越えられれなかった40%のラインをオーバーしてきたとのこと。また、記事ではVisual Studio Codeを「テキストエディタの進化の最終地点」と評価している。

エディタ戦争というと長らくEmacs vs VI (最近はvim)が語られていたが、これらの「初期のエディタ」は「コピーやペースト、アンドゥなどの機能を利用するのに独自の方法を使うなど、新たに使い始めるにはハードルが高い」と評価している。人気度もEmacsが4～5%、vimが25%程度とVisual Studio Codeには及んでいない。

Amazon が Amazon Appstore における Android App Bundle (AAB) 形式のアプリ公開フォーマットサポート計画を発表している(Appstore Blogs の記事、 Android Police の記事、 SlashGear の記事、 On MSFT の記事)。

Google Play では 2018 年から AAB 形式でのアプリ公開が可能となっており、既に 100 万本以上のアプリが AAB 形式で公開されている。8 月以降に Google Play で新規公開するアプリは AAB 形式の使用が必須となる。

一方、Amazon Appstore で AAB の使用が必須化されることはなく、既存の APK 形式を使い続けることも可能だという。Amazon Appstore では AAB サポートに向けた準備を進めている段階であり、年内に進捗状況を発表するとのことだ。

Microsoft は 6 月に Windows 11 を発表した際、DirectStorage テクノロジーが Windows 11 限定で提供されると説明していたが、Windows 10 でも利用可能になるようだ( DirectX Developer Blog の記事、 BetaNews の記事、 Ars Technica の記事、 Ghacks の記事 )。

DirectStorage はストレージテクノロジーの進歩に合わせ、ゲームデータのロードを高速化する DirectX ファミリーの API で、当初は Xbox Series X に Xbox Velocity Architecture の一部として導入された。昨年 9 月には Windows PC での提供計画が発表されていたが、Windows 11 発表時には Windows 11 限定で提供とされた。

Microsoft によれば、DirectStorage SDK は DirectX 12 Agility SDK と同様に Windows 10 バージョン 1909 以降と互換性があるという。ただし、Windows 11 は DirectStorage の利用を想定して構築されており、ストレージスタックが最適化されていることから DirectStorage の潜在能力全てを利用可能になるとのことだ。

先日リリースされた Chrome OS 91.0.4472.165 ではアップデート後にログインできなくなるなどのトラブルが報告されていたが、原因は 1 文字の Typo だったようだ(Android Police の記事 [1]、 [2]、 The Verge の記事、 SlashGear の記事)。

問題発生を受けて Google はこのビルドの提供を中止したが、既にインストールしてしまった場合はログイン画面から先に進めなくなるほか、最悪の場合はブートループに入ってログイン画面にも到達できなくなることもあったという。

7 月 21 日には問題を修正した 91.0.4472.167 がリリースされた。変更された vault_keyset.cc の diff をみると、修正前は2つの条件式のビット論理積 (&) を評価していた部分で、「&」が1つ追加されて論理積 (&&) に修正されている。

Microsoft は 15 日、Windows 10 バージョン 21H2 に導入予定の新機能を紹介するとともに、Windows 10 Insider Preview 初の 21H2 ビルドとなるビルド 19044.1147 を提供開始した(Windows Experience Blog の記事、 Windows Insider Blog の記事)。

Microsoft は Windows 11 を発表する一方で Windows 10 バージョン 21H2 を今年下半期に提供開始する計画を示していたが、具体的な更新内容が発表されるのは今回が初めてだ。バージョン 21H2 は生産性とセキュリティに注力して新機能を提供するとのことで、Wi-Fiのセキュリティを強化する WPA3 H2E 標準サポートの追加、Windows Hello for Business における簡略化されたデプロイのサポート、Windows Subsystem for Linux (WSL) および Azure IoT Edge for Linux on Windows (EFLOW) における GPU 演算サポートの 3 点が挙げられている。ただし、同日提供が始まったビルド 19044.1147 にこれらの機能は含まれない。

メジャービルド番号はバージョン 2004 の 19041 以降、20H2 の 19042 、21H1 の 19043 と 1 つずつしか進んでいない。21H2 はバージョン 2004 以降に高速でインストールできると説明されており、バージョン 20H2 / 21H1 と同様に小規模なアップデートがイネーブルメントパッケージの形で提供されることになるとみられる。機能アップデートが年に 1 回の提供となる Windows 11 に対し、Windows 10 は現在のところ年 2 回提供のままになっている。

21H2 ビルドが提供される条件は、これまでベータチャネルでビルドを受け取っていたが、ベータチャネルが Windows 11 Insider Preview へ移行することに伴い、Windows 11 の要件を満たさないためリリースプレビューチャネルに変更されたデバイスという複雑なものだ。対象のデバイスでは Windows Update で「更新プログラムの確認」をクリックし、21H2 ビルドのインストールを選択した場合にのみインストールされる。

Windows 11 の提供要件を満たすかどうかにかかわらず、Windows Insider Program に新規エンロールしたデバイスでリリースプレビューチャネルを選択すると普通に 21H1 のリリースプレビュービルドが提供され、21H2 ビルドは提供されない。なお、リリースプレビューチャネルには 21H1 のビルド 19043.1147、Dev チャネルには Windows 11 Insider Preview ビルド 22000.71 の提供が同日始まっている。ベータチャネルには近く Windows 11 Insider Preview ビルドを提供開始する予定とのことだ。

Google は 14 日、次期 Android の 3 番目のベータ版となる Android 12 Beta 3 をファイナル API および公式 SDK とともに提供開始した(Android Developers Blog の記事)。

Beta 3 では ScrollCapture API によるスクロール可能コンテンツのスクリーンショット撮影や、AppSearch によるオンデバイス検索、Game Mode API などが追加されている。Pixel 4 以降ではフロントカメラを使用した顔認識による画面の自動回転機能の改善も利用可能だ。

これまでのタイムラインでファイナル API と公式 SDK のリリースは 8 月の Beta 4 となっていたのだが、前倒しされたようだ。同じ内容で一つにまとめられていた Beta 2 と Beta 3 が新しいタイムラインでは分割され、Beta 3 にファイナル API と API 31 の公式 SDK に関する説明が追記されている。プラットフォーム安定版のマイルストーンは Beta 4 のまま変更されていないが、Android 12 API をターゲットにアプリをコンパイルしている場合は最新の環境に更新して再コンパイルすることが推奨されている。

Beta 3 は Pixelやデバイスメーカーのベータプログラムで入手できるほか、エミュレーターや GSI イメージを利用することも可能だ。Android TV 向けにも提供が始まっている。アプリ開発者にとっては Beta 2 に引き続き、アプリと Android 12 との互換性を確認する時期でもある。Beta 3 を実行する実機やエミュレーターで自分のアプリの動作を確認し、問題点があったら Android 12 Beta ユーザーのために修正版をなるべく早く公開することが推奨される。

Google は 8 日、8 月末にリリース予定の Google Play 開発者サービス バージョン 21.30.99 を最後に Android 4.1 ～ 4.3 Jelly Bean (JB、APIレベル 16 ～ 18)のサポートを終了すると発表した(Android Developers Blog の記事、 Neowin の記事、 SlashGear の記事)。

JB は最初にリリースされてから9年が経過し、アクティブデバイス数は Android アクティブデバイス全体の 1% を割っているという。Android のさまざまな新機能や改善のすべては JB にバックポートされておらず、対応しようとすれば開発者の手間が増加することになる。

現行の SDK バージョンに含まれる機能は今後も利用可能だが、新しい SDK で API 16 ～ 18 をサポートしようとするとビルドエラーが発生する可能性がある。そのため、アプリでも API 19 以降のみをサポートするよう変更することが推奨される。

JB のサポートを継続する場合、Gradle でビルドバリアントを設定して API 19 未満・以降でフレーバーを分け、それぞれ対応したバージョンの Google Play 開発者サービスを指定すればいい。

ニュースや新聞で量子コンピュータが取り上げられることが増え、量子コンピュータであればすべて解決できる的な言説が増え、危機感を感じている研究者がいるそうだ。このため、「むしゃくしゃしてやった,今は反省している日記」の記事では、この問題を指摘しておくことにしたそうだ（むしゃくしゃしてやった,今は反省している日記）。

例えば、古典コンピュータでは組合せ最適化を解けないという考えに関しては、量子じゃないと解けないわけではなく、古典コンピュータでも解くことはでき、むしろ量子アニーリングでは厳密解の意味では解いたことにならないと指摘している。このほか巡回セールスマン問題（TSP）古典コンピュータでは時間がかかるといった問題に関しても指摘を行っている。

headless 曰く、

7 月 28 日に発効する Microsoft Store ポリシー バージョン 7.14 では、Chrome や Firefox などのブラウザーを Microsoft Store で公開可能にする変更が含まれている(Microsoft Store ポリシー最新版、 変更履歴)。

これまでのポリシーは 10.2.1 で「Web を閲覧する製品では、Windows プラットフォームによって提供される適切な HTML エンジンと JavaScript エンジンを使用する必要があります」となっており、Chrome や Firefox をそのまま UWP 化しても公開できなかった。

今回の改訂では Web エンジンに関する指定が「Web を参照する製品では、Chromium または Gecko オープン ソース エンジンのいずれかが使用されている必要があります 」に変更された。これらオープンソースエンジンの最新 2 つ以内のバージョンに更新する必要があること、セキュリティ上の問題を迅速に修正する必要があることといった要件も追加されている。既存の EdgeHTML エンジンを使用するブラウザーに関しては、引き続き公開可能だという。

このほか、バンドルソフトウェアの提供を禁止する文言が 10.2.3 に追加されており、完全なアンインストールが可能であることを必須とする 10.2.7 などが新規に追加されている。また、Microsoft Edge の拡張機能に関しては独立したMicrosoft Edge アドオンストアの開発者ポリシーが既に公開されており、Microsoft Store ポリシーの 10.12 は削除された。

headless 曰く、

BitTorrent が 7 月 2 日に 20 周年を迎えた(TorrentFreak の記事、 BetaNews の記事)。

Bram Cohen 氏が BitTorrent クライアントアプリの完成を Yahoo! 掲示板で発表したのは 2001 年 7 月 2 日。Internet Archive に保存されている公開ページの最古のスナップショットは 2001 年 8 月 12 日に保存されたもの。その 3 日前の 8 月 9 日には既にバージョン 2.0.2 が公開されている。

当時はインターネット上でのファイル共有がブームになっており、多数のアプリが公開されていたが、BitTorrent 分散化と速度への注力でライバルとは一線を画していたという。1 つのファイルを 1 対 1 で共有するのではなく分割して多対多で共有し、ダウンロード者がアップロード者にもなるという仕組みで、ダウンロード者が増えれば増えるほど高速化する。

公開ページでは FTP に対する BitTorrent の優位性として、FTP は人気が出ると帯域が使われてサイトが罰せられるのに対し、BitTorrent でそのような問題は発生しないと説明されている。

Google は 6 月 29 日、Google Play ストアで 8 月以降に新規公開するアプリについて Android App Bundle (AAB) 形式での公開を必須にする計画を発表した(Android Developers Blog の記事、 The Verge の記事、 SlashGear の記事)。

AAB は APK に代わる Android の新しいアプリ公開フォーマットで、APK と比較してリリース管理の効率が向上し、アプリサイズの縮小や機能配信のカスタマイズが可能といったメリットもある。AAB 形式でリリースされているアプリは既に 100 万本を超えており、 Adobe や Duolingo 、 Gameloft 、 Twitter を含むGoogle Play でトップ 1000 アプリ・ゲームの大半が AAB 形式を使用しているという。APK から AAB へ移行するにはビルド時のオプションを変更するだけでよく、主要なビルドツールがサポートしているとのことだ。

4Gamer.netの記事によれば、ゲームに使われるドアは開発が複雑すぎるのだそうだ。インディ開発者のStephan Hövelbrinks氏のTwitterでの発言がきっかけで、開発者の間で議論が活発化した模様。「CONTROL」のリードゲームプレイデザイナーであるSergey Mohov氏は、武器やスキルシステムの開発時間より扉の開発にかかる時間の方が長いと話しているそうだ。こうした意見に賛同する開発者も多かった模様（4Gamer.net、游研社）。