英航空事故調査局(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が追加され、デフォルト有効になる。

Microsoftは7日、Windows 10 Insider Preview ビルド21354(CO_RELEASE)をDevチャネルでリリースした(Windows Insider Blogの記事)。

本ビルドでは「ペイント」と「Snipping Tool」の更新がMicrosoft Storeで提供されるようになった。Microsoftは2017年にペイントを将来削除予定の機能としてWindowsストア(現Microsoft Store)で提供する計画を示していたが、結局取りやめになったとの見方も出ていた。今回の変更に伴ってペイントはMicrosoft Storeにも登録されているが、インストールはできない。Snipping Toolは既にMicrosoft Storeで更新が提供されている「切り取り ＆ スケッチ (切り取り領域とスケッチ)」と一緒のパッケージになり、同時に更新できるようになったとのこと。アプリの設定画面も統合されている。

また、ビルド21343ではスタートの「Windows 管理ツール」サブメニューが「Windows Tools」サブメニューに変更されていたが、本ビルドでは「Windows Tools」フォルダーへのリンクに変更された。さらに、サブメニュー「Windows PowerShell」「Windows アクセサリ」「Windows システム ツール」がなくなり、これらのサブメニュー下のアイテムはすべてWindows Toolsフォルダーに移動している。メモ帳やペイント、エクスプローラーはメニューのルートへ移動しているため影響を受けないが、Internet ExplorerやWindows Media Playerなどはピン留めしない限りスタートからの直接起動ができないことになる。

本ビルドの新機能としては、タスクバーの「ニュースと関心事項」の新しいカスタマイズオプションや、「設定→システム→ディスプレイ」に表示内容によってディスプレイの輝度を自動調整するCABCを無効化するオプションの追加、「設定→デバイス」へのカメラ設定ページ追加が挙げられている。新機能とは別に記載されているが、タスクバー上の天気をクリックしない限り「ニュースと関心事項」が表示されないようにするオプションも追加されている。

なお、本ビルドではブランチがこれまでのRS_PRERELEASEからCO_RELEASEに切り替わっているが、ブランチの切り替えをテストするだけで特に意味はないとのこと。Devチャネルのブランチは昨年5月にMN_RELEASE、10月にFE_RELEASEへ切り替えられており、単にマンガン→鉄→コバルトと原子番号順に進んでいるだけのようだ。

headless 曰く、

スターバックスが米国・シアトルの5店舗で3月30日から5月31日まで、再使用可能な持ち帰り用カップを貸し出す「Borrow A Cup」プログラムを試験的に実施しているそうだ( Starbucks Storiesの記事、 GeekWireの記事)。

再使用型カップは客によるカップの持ち込みとは異なり、1回使用するごとに回収して専門の業者が洗浄・消毒後に店舗へ届けられ、最大30回まで再使用される。客は1ドルのデポジットを支払うことで再使用型カップを選択でき、使用後は実施店舗の店内やドライブスルーに設置された非接触の返却キオスクで返却する。返却時にスターバックスアプリをスキャンするとデポジットはスターバックスリワードアカウントのクレジットとして返金され、10 Bonus Stars(ポイント)が付与される。自宅からの回収サービスも提供しているとのこと。

スターバックスは持ち込みカップでのドリンク購入時に値引きするサービスを1980年代から実施しているが、COVID-19パンデミックの影響で世界各地で持ち込みカップでの提供が一時見合わせられた。日本のスターバックスでは既に持ち込みカップでの提供を再開しているが、米国とカナダでは提供が再開されていないという。

スターバックスで販売されるドリンクの80%は持ち帰りとなっており、リサイクル可能な1回使い捨てカップで提供されるものの、実際にリサイクルされるのは一部にとどまるとのこと。スターバックスは昨年、2030年までに廃棄物を50%削減する目標を発表しており、Borrow A Cupプログラムは使い捨てカップの利便性を大きく損なわずに廃棄物を減らす方法として考案されたようだ。

先日、マイナンバーカードを健康保険証として利用できる「マイナ健康保険証」制度の本格的な導入予定が延期された。その原因は、健康保険証に記載された情報とマイナンバー上の情報が一致しない事例が多数発見されているためだ。日経新聞の記事によれば、2月の段階では一致しない例が最大3万件に達しているそうだ（日経新聞）。

マイナ保険証は医療データの収集・閲覧も可能な機能を持っていることから、問題を抱えたまま導入してしまっていた場合、特定健診データや薬剤情報などが他人の目に触れるリスクがあったとしている。こうした基本情報データの不一致は、保険者が持つデータにマイナンバーを加える段階で入力ミスが生じている可能性があるという。

マイナンバーは「番号法」により、その取得や保管・管理に厳しいルールが課せられている。健保は個人から直接マイナンバーの提供を受けられないことから、勤務先を経由して番号を入手する。しかし、企業の持つデータ12ケタある個人番号を手書きで提出して入手したものであり、誤記の可能性は常にある。家族が複数人居ればその分、誤記の確率は上がるとしている。

Microsoftは4月6日、OpenJDKの自社ビルド版「Microsoft Build of OpenJDK」をプレビュー公開した。WindowsやmacOS、Linuxのx64サーバー環境およびデスクトップ環境で利用できるJava 11のバイナリーが含まれている。GitHubからダウンロード可能となっている（Microsoft、ZDNet、窓の杜）。

あるAnonymous Coward 曰く、

Microsoftは米国時間4月6日、「OpenJDK」の長期サポート（LTS）ディストリビューションである「Microsoft Build of OpenJDK」のプレビュー版を公開した。このディストリビューションには「Java 11」のバイナリーが含まれており、「Windows」「macOS」「Linux」のx64サーバー環境およびデスクトップ環境で利用できる。また同社は、Arm版Windows用「Java 16」の早期アクセス版もリリースした（MicrosoftのJava Engineering Groupは、2020年6月にArm版Windows向けのOpenJDKを移植する作業の最初のフェーズを完了したと発表している）。
Microsoft Java VMから幾星霜再びMicrosoft純正Javaが生まれるのだ。

情報元へのリンク

あるAnonymous Coward 曰く、

https://gigazine.net/news/20210404-5-programmers-30000-hours/

プロになるには1万時間の練習が必要という1万時間の法則というのがあるが、ドナルド・クヌース（The Art of Computer Programmingの著者）やスティーブン・ウルフラム（Mathematicaの作者）クラスになるには、3万時間超のプログラミングが必要なようだ。

情報元へのリンク

何事も一流のスキルを身につけるには1万時間の練習が必要とする「1万時間の法則」なるものがマルコム・グラッドウェルによって提案されている。この法則の自体の是非はさておき、プログラマーのBreck yunits氏は、実際に1万時間プログラミングしてみて、実際にその効果に自信を持てなかったそうだ。そこで自身が尊敬する著名なプログラマー25人にプログラミングに費やした時間を問い合わせたという。そのうち返答は5人あり、その結果をGitHub上で公開したという（GitHub、GIGAZINE）。

なお返答のあった5人は以下の通り。

• Donald Knuth　56000時間
• Rob Pike　30000時間
• Peter Norvig　30000時間
• Stephen Wolfram　50000時間
• Lars Bak　30000時間

いずれも3万時間以上プログラミングに時間を費やしており、yunits氏は次は3万時間を目指すとしている。

headless 曰く、

4月のTIOBE IndexでObjective-Cがトップ20から落ち、Fortranが十数年ぶりにトップ20入りしている(InfoWorldの記事、 Neowinの記事)。

Fortranは最古の高級プログラミング言語でありながら滅びることなく使われ続けている。最後にトップ20入りしていたのは2007年だが、その後も常にトップ50に入っていた。最近は科学技術計算需要の高まりに伴って再びレーティング(シェア)を伸ばし、4月は前年から倍以上に増加(0.91%、+0.58)。順位も前年の34位から大きく上昇した。

Objective-CはiOSアプリのプログラミング言語として2010年代前半に人気が高まり、2012年にはTIOBE Indexで3位まで上昇。2011年と2012年の2年連続でレーティングを最も伸ばしたプログラミング言語に選ばれていたが、2015年にAppleがオープンソース化した新プログラミング言語Swiftに人気を奪われる形で低迷が始まった。Objective-Cは昨年7月にもトップ20から落ちているが、今回のトップ20落ちについてTIOBEではObjective-Cの「ゲームオーバー」と評している。ただし、Fortranが復活したのと同様、Objective-Cに復活の目がないわけではないとのこと。

4月のTIOBE Indexトップ3はC・Java・Pythonの順。全言語中、前年比でレーティングが最も増加したのはPython(11.03%、+1.72)であり、C(14.32%、-2.40)とJava(11.23%、-5.49)は大きく減少した。それでもCは昨年5月にJavaを抜いて以来の1位を維持している。一方、Javaは昨年11月にPythonにも抜かれて3位となり、以降は2位に復帰しているものの、Pythonとは横並びの状態が続く。

このほか、順位・レーティングともに伸ばしたのはアセンブリー言語(14位→8位、+1.16)とクラシック(.NETではない)Visual Basic(19位→11位、+0.71)、Delphi/Object Pascal(22位→12位、+0.77)、Groovy(48位→17位、+0.86)となっている。

headless 曰く、

米連邦最高裁判所は5日、GoogleがJava SE APIライブラリから宣言部分のコードをコピーした行為はフェアユースに当たるとの判断を示した(裁判所文書: PDF、 The Vergeの記事、 9to5Googleの記事)。

この裁判は2010年にOracleがJavaの特許および著作権を侵害されたとしてGoogleを訴えていたものだ。特許については侵害なしとの判決が早々に確定しているが、著作権に関しては一審・二審で判断が分かれた。Java APIの宣言部分が著作権保護されるという2014年の連邦控訴裁判所判決を受けたGoogleの上告は却下されたが、2018年には連邦控訴裁判所がフェアユースに当たらないとの判断を示し、全法廷での再審理請求が却下されたことを受けてGoogleが再び上告。こちらは受理されて今回の判断に至った。

今回GoogleはJava APIの宣言部分が著作権保護されないこと、著作権保護されるとしてもフェアユースに当たること、の2点に関して確認を求めていた。連邦最高裁では著作権保護の有無については明確な判断を示さなかったが、著作権保護されると仮定してもフェアユースに当たるとの判断を示している。

まず、機能を主とするコンピュータープログラムに従来の著作権の概念を適用するのは難しいが、宣言部分は事前に用意されたプログラムによる処理をプログラマーが容易に呼び出せるようにする「ユーザーインターフェイス」であり、コードの各行は著作権保護の対象とならないアイディアに相当する。そのため、これらをまとめた著作物に対する著作権保護は弱く、フェアユースが支持されるという。

また、GoogleによるJava APIの利用は必要最低限のものだけを取って新たな価値を生み出す変容的利用であること、コピーされた約11,500行のコードはJava API全体の0.4%に過ぎないこと、GoogleのスマートフォンプラットフォームはJava SEの市場を奪うものではなく、他の市場向けに再実装されたことによる利益を著作権者も得ていること、といったフェアユースの要件を満たすと判断した。

これらの理由により、GoogleによるJava APIの使用がフェアユースに当らないとした二審判決を破棄し、下級審に差し戻した。

ノーベルコンピューティング賞などとも呼ばれている ACMチューリング賞の2020年にコンパイラの開発に貢献したアルフレッド・エイホ（Alfred Aho）氏とジェフリー・ウルマン（Jeffrey Ullman）氏が選出された（コロンビア大学リリース、スタンフォード大学リリース、CNET、GIGAZINE）。

2人はプログラミング言語の基礎となる基本的なアルゴリズムと理論の構築、そして多くのコンピューター科学者の育成につながる著作を持つことが認められた。チューリング賞では100万ドルの賞金が用意されている。今回の受賞では賞金は二人で分け合うことになるとしている。

headless 曰く、

PHPメインテナーのNikita Popov氏は3月28日、独自にgitインフラストラクチャーを維持するのは不要なセキュリティリスクになるとして、git.php.netを廃止してこれまでミラーだったGitHubのリポジトリを正規のリポジトリにする計画を発表した(PHPのニュース記事、 The Registerの記事)。

GitHubへの移行のきっかけとなったのは、3月28日にPHPクリエイターのRasmus Lerdorf氏とPopov氏の名前で不正なコミットが行われたことだ。不正なコミットに含まれるのは、User-Agent HTTPヘッダーの文字列が「zerodium」から始まっている場合にヘッダー内のコードを実行するコード。まずLerdorf氏の名前でコミットされ、Popov氏がコミットを取り消したが、Popov氏の名前で取り消しが取り消されている。まだ攻撃の全容は明らかになっていないが、個別のアカウントが侵害されたのではなく、git.php.netのサーバーが侵害されたとしか考えられないという。そのため、調査を続ける一方でGitHubへの移行を決めたとのこと。

GitHubに移行することで、リポジトリへの書き込みアクセスを行うにはphp organization(組織アカウント)のメンバーに含まれるGitHubアカウントが必要となる。まだ組織アカウントのメンバーになっていない場合や、可能なはずのアクセスができない場合にはPopov氏に連絡してほしいとのこと。なお、組織アカウントのメンバーになるには2要素認証を有効にする必要があるとのことだ。

数値処理向けプログラミング言語Juliaの開発チームは24日、最新版となる「Julia 1.6」をリリースしたと発表した。同時にマニュアル「The Julia Languageも公開した。プリコンパイルを並列化することでさらに高速化したほか、コンパイル時間を計測するタイミングマクロが追加されているとしている。Julia 1.6は次期LTSになる可能性があるが、フィールドテスト後のv1.7が提供されることに決定するとのこと（Julia公式ブログ、CodeZine、TECH+）。

headless 曰く、

Appleが豪競争・消費者委員会(ACCC)に提出したフィードバックで、iOSのコンテンツ配布手段はApp Storeに限られないと主張している(PDF、 9to5Macの記事、 Mac Rumorsの記事)。

AppleはACCCによるデジタルプラットフォームサービスに関する調査のフィードバック募集に応じて複数のフィードバックを提出している。今回のフィードバックは先日話題になったApp Storeのレビュープロセスに関するフィードバックよりも先に提出されたものだが、公開はそれより後の3月24日になっている。

このフィードバックはiOSデバイスのユーザーに対するコンテンツ配布手段をApp Storeが独占しているわけではなく、App Storeと他のコンテンツ配布手段との競争が存在することを説明する内容だ。Appleはユーザーの多くはiOS以外のデバイスも所有しているため、iOSエコシステム外のコンテンツ配布手段とも競合するとしたうえで、iOSデバイスのみを所有するユーザーもWebを利用できるため、コンテンツ配布手段はApp Storeに限定されないと主張する。

Webで配布するコンテンツの窓口はWebブラウザーに限らず、プログレッシブWebアプリ(PWA)を開発すればApp Storeを利用することなくアプリを配布できると説明。StarbucksやPinterest、Uber、FTなどWebアプリの導入例が増加していることや、AmazonやGoogle、MicrosoftのWebアプリを通じたiOSでのゲームアプリ提供などを紹介し、App StoreによるiOSエコシステムの独占を否定している。

Motorolaは25日、消滅が危惧されるブラジルの先住民族言語、カインガング語(kgp-BR)とニェエンガトゥ語(yrl-BR)の2言語を同社のAndroid 11対応デバイスでサポートすると発表した(Motorolaのブログ記事、 The Vergeの記事)。

Motorolaの最大のユーザーベースはラテンアメリカにあるが、この地域の先住民族言語がAndroidでサポートされていないことに気付いたそうだ。現在のブラジルにポルトガルが到達した当時の同地域では1,215の言語が話されていたが、500年後の現在は200言語程度まで減少しており、1世紀以内にすべて消滅する可能性もあるという。

言語が消滅すれば文化遺産も失われるため、Motorolaではソフトウェア上の体験を通じて危機に瀕する言語を保存、さらには再活性化もできるのではないかと研究開発を開始したそうだ。その結果、ブラジル・カンピーナス州立大学(Unicamp)教授のWilmar D'Angelis氏が率いる先住民族言語学者などのチームの協力のもとに、同社のデバイスへのカインガング語とニェエンガトゥ語の追加が実現した。

headless 曰く、

Appleが豪競争・消費者委員会(ACCC)に対し、App Storeのレビュープロセスで同社と渡り合えるかどうかをまじめに懸念する開発者がいたことに驚いたと述べている(PDF、 Mac Rumorsの記事)。

ACCCではデジタルプラットフォームサービスに関する調査の2021年3月版中間報告書作成に向けてフィードバックを募集しており、Appleは昨年10月にフィードバックを提出していた(PDF)。しかし、開発者が提出したフィードバックでレビュープロセスの問題点が指摘されたことを受け、App Storeのレビューに関する追加のフィードバックを提出したようだ。フィードバックを提出した開発者は具体的に示されていないが、Developers Alliance(PDF)やEpic Games(PDF)はレビュープロセスの問題点を含むフィードバックを提出している。

Appleはレビュープロセスについて、同社と開発者が共通の目標を目指すものだと説明。アプリのレビューは人間のスタッフが主導するプロセスであり、却下する場合にはその理由と抵触するApp Store Reviewガイドラインの条項、ガイドライン違反とみなされた理由を開発者に提供するという。Appleではアプリが公開できるようさまざまなサポートを提供しており、開発者は異議申し立ても可能だ。アプリのレビューの主目的は悪質なアプリから消費者を保護することであり、開発者に繰り返しアプリの再提出を要求することがあるのは、ガイドラインの要件をすべて満たすようにするためとのことだ。