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やオムロン、ドコモなどが想定されているとしている。事業者同士の規格統一もしくはマイナポータルを経由してデータを共有する方法などが検討される模様。

headless 曰く、

4月の月例更新でWindows 10 バージョン2004/20H2向けに提供された累積更新プログラム(KB5001330)と3月に提供されたプレビュー版の累積更新プログラム(KB5000842)では、一部のユーザーからゲームのパフォーマンス低下が報告されていたのだが、既知の問題のロールバック(KIR)を使用した対策が行われたそうだ(KB5001330、 KB5000842、 Neowinの記事、 Windows Centralの記事)。

KIRは変更前のコードを残したまま新しいコードを追加し、ポリシーで新しいコードの有効・無効を切り替える仕組みだ。広く影響する問題が確認されるとクラウド上で設定が変更され、Windows Update/Windows Update Businessを通じて変更がデバイスに通知される。これにより、更新プログラム自体をアンインストールしなくても問題が発生した部分だけを無効化できる。

KB5001330で影響を受けたユーザーの多くはゲームをフルスクリーンまたはボーダーレスウィンドウモードで実行し、2つ以上のディスプレイを利用しているという。非マネージドデバイスではインターネットに接続していれば24時間以内に変更が適用されるが、マネージドデバイスの場合は特別なグループポリシーをインストールして構成する必要がある。

なお、レジストリキー「HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\1837593227」が存在し、DWORD値「EnabledState」に「1」がセットされていれば修正済みとのことだ。

あるAnonymous Coward 曰く、

Pythonのインタプリタ等々をCししやしゃしゃー♯というか.Netにしたものです。長年更新が止まっていたもののPython3.4に対応した模様です。尤もPythonの現行最新版は3.9あたりですが。

情報元へのリンク

プログラミング言語「IronPython」が4月20日（日本時間）、IronPython 3となってリリースされた。IronPythonは.NET Frameworkに対応したPython。最新版は2020年11月にリリースされたものだが、ベースとなっているPython 2のサポートは昨年終了していることから、IronPython側も「Python 3」に準拠したバージョンの登場が期待されていたとのこと。リリースされた「IronPython 3」のバージョンは「IronPython 3.4.0-alpha1」となっている（GitHub、IronPython Team公式Twitter、窓の杜）。

一般的な紅茶の注ぎ方は、ティーバッグを入れた後にミルクを入れるという方法だが、硬水の地域ではこの方法では紅茶の風味を生かすことができないという。英国リーズ大学のAlan Mackie教授とINTUの発表の研究によれば、紅茶ではミネラル分が多いことから、茶葉に含まれる風味を形成するフレーバー化合物が適切に形成されず、風味が妨げてしまうそうだ。あとはタレコミにあるとおりだが、硬水地域の場合は、先にミルクを加えてからお湯を注ぐのが良いとしている（INTU、FINDERS）。

あるAnonymous Coward 曰く、

「硬水の地域に住んでいる人は、紅茶の味を最大限に引き出すために、お湯より先にミルクを入れる必要があります」
「最初にカップにミルクを加えてからお茶の成分を抽出すると、ミルクのタンパク質が水の中のタンニンが固形化するのを防ぎ、素晴らしい風味が得られるのです」
だからミルクティー前提。
日本の様に、上水道が軟水である事が普通の場合は旧来の方法で問題無いし、その日本で態々市販ミネラル水を使って旧来方で淹れて粋がっている場合は度し難いって事か。

情報元へのリンク

Googleは21日、次期Androidの開発者プレビューとしては最終版となるAndroid 12 Developer Preview 3(DP3)をリリースした(Android Developers Blogの記事、 リリースノート)。

DP3ではSplashScreen APIや通話通知用のCallStyleテンプレートなどが追加されており、ハプティックフィードバックAPIの拡大やウェブリンクの改善、より柔軟なバックアップ構成などユーザーエクスペリエンスを向上させるさまざまなツールや機能が盛り込まれた。また、機械学習の高速化やGPU演算の標準化、NDK関連のクラッシュ発生時のデバッグ性向上、サードパーティ製アプリでも超高解像度カメラセンサーの能力を発揮できるようにするAPI追加なども行われている。

DP3はPixel 3/3 XL/3a/3a XL/4/4 XL/4a/4a 5G/5のシステムイメージが提供されており、既にプレビュービルドがインストールされた端末はOTAで自動アップデートされる。Android Emulatorでテストすることも可能だ。

Android 12の開発者プレビュー版はDP3が最後となり、5月には最初のベータ版がリリース予定だ。そのため、開発者はアプリの互換性テストを行い、Android 12に向けた準備を開始すべき時期だという。Googleでは今後数週間のうちに互換性の確認されたアップデートをリリースするよう推奨している。ただし、現時点ではtargetSdkVersionを変更する必要はないとのことだ。

あるAnonymous Coward 曰く、

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

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

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

情報元へのリンク

筑波大学の授業データベース「KdB」が、履修登録期間中の新学期早々にメンテナンスに入りし、そんな状況で7000以上科目から履修する科目を選択しなければならず、学生を困らせていたという。そんな中、新入生が代替システムを作ってしまったことが話題となっている（ねとらぼ、Togetter、ITmedia）。

開発したのは大学メディア創成学類の1年生の「いなにわうどん（@kyoto_mast21）」さん。この代替ツールは「KdB（もどき）」と名付けられ、授業名のキーワードや学期、曜日、対面かオンデマンドかといった実施形態、履修年次を指定すると授業予定や内容が表示される。公式のKdBよりも動作が軽量になり、検索時間も短縮されているという。

ねとらぼがいなにわうどんにインタビューを行ったところ、当初は一人で制作して公開したものの、GitHub上にソースコードをアップしたところ、同級生や上級生などからバグ報告や新機能の実装などがあったことから、現在は複数人で開発しているとのこと。

英航空事故調査局(AAIB)は8日、昨年7月に英国の航空会社のフライトで発生した重大インシデントの報告書を公開した(報告書、 Flight Globalの記事、 The Vergeの記事、 The Registerの記事)。

インシデントは7月21日5時にバーミンガムを出発したボーイング737-8K5型機による旅客便で、チェックイン結果を踏まえて作成されるロードシートに実際より1,244kg少ない重量が記載されていたというもの。この航空会社はインシデント発生前にCOVID-19の影響で数か月運航を停止しており、その間に予約システムの更新を行った。ところが、更新を請け負ったプログラマーの国では敬称の「Miss」を子供に対して用い、成人女性に対しては「Ms」を用いる習慣があったため、「Miss」としてチェックインした成人女性(標準体重69kg)ではなく、子供(標準体重35kg)として重量を計算するプログラムになっていたそうだ。

この問題はシステム更新直後のフライトで確認されており、予約を確認して「Miss」が指定された成人女性の予約を「Ms」に手作業で置き換える解決法が2つのチームで共有されていた。地上スタッフにはチェックインカウンターやゲートで大人かどうかを確認するよう勧告されていたが、オペレーションズマニュアルには追加されてはいなかった。一方、プログラマーは大人の未チェックインの予約について「Miss」を「Ms」に自動で置き換える機能を実装したが、既に「Miss」としてチェックインしている場合には対応していなかったという。

しかし、週末には2つのチームが作業を行わなかったうえ、同便はフライト24時間前の7月20日(月曜日)にはオンラインチェックインが可能になった。そのため、同便のフライトプランでは29人だった子供の乗客がロードシートでは38人に増え、実際よりも1,244kg少ない機体重量が記載されることになる。このような差が出ることは珍しくないため、機長はロードシートを信じて離陸。その結果、離陸時の推力はわずかに小さくなったものの、運航の安全性に影響はなかったとのこと。

再発防止のため、7月24日にはより正式な確認手順が導入される。報告書にはロードシート作成のためのシステムがアップグレードされたとも記載されている。報告書に航空会社名は記載されていないが、機体記号G-TAWGはTUIエアウェイズの保有機材だ。TUIはインシデント発生を認めているが、プログラマーがどこの国の人だったかという質問には回答しなかったとのことだ。

MozillaがFirefox 88のリリースを1日繰り上げ、Firefox 89のリリースを2週間先送りしている(Firefox Release Calendar、 Ghacksの記事)。

FirefoxのメジャーリリースサイクルはFirefox 73以降、4週間間隔に短縮されており、Firefox 88は4月20日リリース、Firefox 89は5月18日リリースが予定されていた。しかし、MozillaWikiのFirefox Release Calendarは9日に更新され、Firefox 88が4月19日、Firefox 89は6月1日のリリースとなっている。以降のリリースは再び4週間間隔になっており、全体に2週間ずつ先送りされている。

なお、fx-trains.herokuapp.comによれば、通常のFirefoxのBetaサイクルとNightlyサイクルがそれぞれ4週間なのに対し、Firefox 89ではBetaサイクルが6週間、Firefox 90ではNightlyサイクルが6週間に延長されている。また、Firefoxのメジャーリリース日は通常火曜日だが、Firefox 88のみ月曜日のリリースになる。

スケジュール変更の理由は特に説明されていないが、GhacksではUIの大幅刷新Protonとの関連を指摘する。Proton UIはFirefox Nightly(バージョン89)で一部がデフォルト有効になっているが、まだまだ未完成だ。また、Firefox 89ではトップレベルでの非同期処理を可能にするTop Level Awaitが追加され、デフォルト有効になる。