スターバックスが新型コロナウイルス感染症(COVID-19)対策の一つとして、日本と北米の店舗で再使用可能食器の使用を一時中止したそうだ(スターバックスコーヒージャパンの告知、 starbucks.comの告知)。

これにより、店舗で用意しているマグカップやステンレスフォーク/ナイフといった「フォーヒア(店内での飲食)」食器の使用を一時中止するほか、客が持参したカップでのドリンク提供も一時中止し、紙カップやプラスチックフォーク/ナイフを使用する。米国では持参したカップやフォーヒア用マグカップの使用を指定した客への10セント値引きは引き続き行うという。

日本のスターバックスでは国内でのCOVID-19感染者確認後、早い段階から従業員のマスク着用や店頭での手指消毒用アルコール提供、コーヒーセミナー中止などの対応を行っている。商品や代金・釣銭を手渡しする場合の方法も変更しているとのこと。starbucks.comおよびCOVID-19感染者が100人以上出ている各国のスターバックスWebサイトを確認してみたが、日本と北米、中国以外の情報は見当たらなかった。ただし、特に発表していないだけで何らかの対策は行われていると思われる。中国では2月27日時点で店舗の85%が営業を再開しているそうだ。

東京都が3月4日、新型コロナウイルス感染症対策サイトを公開した。このサイトのソースコードはMITライセンスとなっており、GitHubで公開されているだけでなく、プルリクエストの受付も行われている（ITmedia）。

また、サイトで利用しているデータは今後「東京都オープンデータサイト」でも公開される予定とのこと。

headless曰く、

StatCounterの2月分Windowsバージョンシェア国別データによると、Windows 10が中国で初めて1位となっている。

Windows 10は東ティモールで初めて1位になったほか、シリアでも1位に復帰しており、トルクメニスタンと北朝鮮を除くアジア全域でWindows 10が1位となった。アフリカでもWindows 10が1位の国・地域が一気に増加しており、世界235か国・地域中227か国・地域でWindows 10が1位となった。世界全体のWindowsバージョン別シェアはWindows 10が69.2%（+1.85）、Windows 7が23.18%（-1.72）。デスクトップOS種別ではWindowsが77.26%（-0.44）、OS Xが17.69％（+0.65）、Linuxが1.89%（-0.01）、Chrome OSが1.47%（-0.05）となっている。

中国でのシェア変動にCOVID-19の影響があるかどうかは不明だが、日単位のデータをみると2月前半は多くの日でWindows 10がWindows 7をやや上回る状態が続き、21日に急増・23日に急減してWindows 7に逆転されている。28日にはWindows XPも急増した。12月～1月のデータではWindows 7が休日に増加する傾向がみられ、春節前後は大幅に増加している。なお、中国の2月分データでは、読み込むタイミングによってWindows 10とWindows 7の順位が入れ替わる現象が発生している。原因は不明だが、変動が激しい2月下旬の日単位データも読み取りが不安定だ。

SteamではWindows 10 64 bitが80.37%（+1.14）、32ビット版との合計では80.53%（+1.15）となり、初めて80%を超えた。Windows 7 64 bitは12.39%（-1.17）で、32ビット版との合計は13.13%（-1.11）。Windows全体では96.02%（-0.07）、OSXは3.15%（+0.14）、Linuxは0.83%（-0.07）となっている。こちらもCOVID-19の影響は不明だが、言語別シェアで2位の簡体字中国語が22.53%（+4.16）まで増加した。Steamでは2017～2018年に簡体字中国語とWindows 7が連動して大きく増減する現象がみられ、アジア地域のネットカフェで顧客数を実際よりも多くカウントしていたと説明されていた。問題は修正済みだが、ネットカフェ利用者が減少した可能性もある。このほか韓国語や日本語、繁体字中国語、タイ語、ベトナム語が増加。1位の英語や3位のロシア語など多くの言語はシェアを減らしている。

NetApplicationsのデスクトップOSバージョン別シェアは1位のWindows 10が0.31ポイント増加し（57.39%）、2位のWindows 7が0.36ポイント減少した（25.2%）程度で大きな変動はない。デスクトップOS種類別ではWindowsが88.20%（+0.06）、Mac OSが9.42%（-0.32）、Linuxが1.82%（+0.35）、Chrome OSが0.42%（-0.07）などとなっている。

headless曰く、

3月16日から20日まで米国・サンフランシスコのモスコーネセンターで開催が予定されていたゲーム開発者向けカンファレンス「GDC 2020」だが、新型コロナウイルス感染症（COVID-19）の影響で開催を延期し、今夏に変更する方針だという（GDCのニュース記事、Ars Technica、The Verge、SlashGear）。

サンフランシスコでは2月25日に市長がCOVID-19に関する非常事態宣言を出しているが、モスコーネセンターでは予定通り2月28日までRSAC 2020が開催された。しかし、GDCでは2月20日にSonyとFacebook/Oculusが出展取りやめを表明したのをはじめとして、EAやコジマプロダクション、Unity、Microsoft、Epic Games/Unreal Engine、AWS、Activision/Blizzardといったメジャーブランドが次々と出展取りやめを表明しており、このまま開催するのは困難だと考えたようだ。

新たな計画については、今後数週間のうちに発表するという。なお、延期に伴って3月のパス購入者には全額返金が行われ、GDC提携サイトを通じて予約したホテルではキャンセル料が不要となる。また、予定されていたプレゼンテーションやIndependent Games Festival、Game Developers Choice Awardはオンラインでの視聴を可能にする計画とのことだ（FAQ）。

Gitではコミットに対し「コミットハッシュ」と呼ばれるIDが付与されるが、このIDの先頭を「ゾロ目の数字」など特定の文字の並びにするという手法が開発された（Qiitaへの投稿：「お前らのコミットは汚い」）。

コミットハッシュは修正内容とコミット者の情報などをハッシュ関数に与えて出力したもの。開発された手法は、ハッシュ値の先頭が指定した文字と一致するまでコミット時の「Committer」情報を書き換えながらハッシュ値を計算するというもの。コミットハッシュ全体を指定した文字にするには最大で16の40乗ほどの試行が必要となるが、7桁であれば最大で16の7乗（2億6843万5456）回の試行で足りるとのことで、現実的に可能であることからこの手法を思いついたという。

京都大学が2月13日、Pythonによるプログラミング学習のための教材「プログラミング演習 Python 2019」を公開した（CodeZine）。Creative Commonsの「CC-BY-NC-ND」（表示-非営利-改変禁止）ライセンスで公開されており、このライセンスに従う限り無償かつ自由に利用・複製が可能。

同大学の授業で使用された教材をベースにしたものとのことで、単にPythonの文法や機能を紹介するだけでなく、コンピュータの仕組みやデータの扱い方といった内容についても言及されている。

The Linux FoundationがLaboratory for Innovation Science at Harvardと共同で実施したフリー・オープンソースソフトウェア(FOSS)のセキュリティに関する調査報告書の暫定版「Preliminary Report and Census II of Open Source Software」を公開している(報告書: PDF、 The Registerの記事)。

The Linux Foundationは2014年、Heartbleed脆弱性の問題を受けてオープンソースプロジェクトを援助するCore Infrastructure Initiative(CII)を設立。2015年には調査プロジェクト(Census I)を実施して報告書を公開しており、今回のCensus IIはその第2弾となる。冒頭で「典型的なアプリケーションの80％～90%は(オープンソースの)コンポーネントでできている」というSonatypeによる2016年の報告書(PDF)からの引用を掲げている通り、セキュリティ上の問題点特定に活用するため、どのようなFOSSパッケージが幅広く使われているのかを特定することが主目的となっている。

報告書では付録として最も広く使われているFOSSパッケージ(JavaScript: 10、JavaScript以外: 10)がまとめられている。JavaScriptとそれ以外を分けたのは、使用したデータソースでJavaScriptが多くを占めており、どのようなランキングを作成しても使用したJavaScriptが上位を独占する状態になってしまうからだという。ただし、JavaScript以外のパッケージでも同じ問題があり、すべてがJavaのパッケージとなっている。

Googleは19日、次期Android初の開発者プレビュー版となるAndroid 11 Developer Preview 1 (DP1)を公開した(Android Developers Blogの記事、 Android 11 Developer Preview、 リリースノート)。

DP1では5Gの帯域幅に関連するAPIのほか、フロントカメラ用の穴が開いたピンホールディスプレイや両端がデバイス側面まで伸びたウォーターフォールディスプレイといった新しいディスプレイタイプに対応するためのAPI、通知からの会話を容易にするAPI、Neural Networks API(NNAPI)などの強化・追加が行われている。また、アプリに一時的なパーミッションを与えるone-time permissionの追加や、バイオメトリクスのサポート拡大など、プライバシー・セキュリティ面での強化も行われている。

DP1のシステムイメージはPixel 2/2 XL/3/ 3 XL/3a/3a XL/4/4XLに対応したものが提供されているが、開発者専用という位置付けのためダウンロードおよびフラッシュ作業は手動で行う必要がある。また、Android Studioにシステムイメージを追加すればAndroid Emulatorでも利用可能となる。Android 11 Preview SDKはAndroid Studio 3.3以降で利用可能だが、一部互換性のない変更が行われているため、Android Studio 4.0 Previewの使用が推奨される。既存アプリでAndroid 11互換性をテストし、新しいAPIを使用するには、モジュールレベルの「build.gradle」ファイルで「compileSdkVersion」を「android-R」に、「targetSdkVersion」を「R」にすればいい。

Android 11は3月のDP2、4月のDP3を経て5月にはBeta 1が提供され、6月にはBeta 2、第3四半期にはリリース候補となるBeta 3を経てファイナル版がリリースされる見込みとのことだ(Overview & timeline)。

headless曰く、

数多くのカジュアルゲームをMicrosoft Storeで公開しているRandom Salad GamesのCEO、Sam Kaufmann氏が独自にストアアプリ（UWPアプリ）向け広告プラットフォーム「Pubfinity」を立ち上げた（CNBC、On MSFT、Windows Central）。

MicrosoftはUWPアプリ向け広告収益化プラットフォームの廃止計画を1月末に発表したが、Kaufmann氏が独自の広告プラットフォーム開発を考え始めたのはそれよりも早い時期だという。2019年1月にMicrosoftはWindows 10 Mobileのサポート終了計画を発表し、Android/iOSデバイスへの移行を推奨。これによりユニバーサルなWindowsプラットフォームはモバイルプラットフォームを失うことになる。さらに2019年にはMicrosoftの広告収益化プラットフォームSDKを通じた不正広告キャンペーンが発生したが対応は遅く、Kaufmann氏はMicrosoftが広告で無料UWPアプリを支える意欲を失いつつあると感じ始める。

Random Salad GamesがMicrosoft Storeで公開している「Simple Solitaire」などの50本以上のカジュアルゲームはすべて無料であり、広告収入ですべてをまかなっている。CNBCの記事によると同社の広告収入は7桁で、Microsoft Store最大の広告付きアプリ開発者だという。Kaufmann氏は9年に及ぶ広告付きアプリ開発の経験を生かして広告主と話し合うなど、広告プラットフォームを研究した末にPubfinityが誕生する。既に同社のゲームではPubfinityを使用しているが、他の開発者にもSDKを提供する計画だ。当初は厳選した開発者への提供に限られるが、Microsoftが広告収益化プラットフォームを廃止する6月1日までには幅広い開発者への提供が可能になることを目指しているとのことだ。

昨今では実装したコードをJavaScriptにトランスコンパイル（トランスパイル）できるような言語が複数登場している。代表的なものとしてはTypeScriptやDartがあるが、それ以外にもClojureのような、JavaScriptコードを出力できるコンパイラが用意されている言語もある。その中でもおすすめの言語はどれだろうか。

Anonymous Coward曰く、

タイトルのまんまですが、イケてると思う言語を挙げて欲しい。

Object Pascalベースのプログラミング言語およびその開発環境であるDelphiが最初にリリースされたのは1995年2月14日で、今年で25周年になるそうだ。これを記念して、現在Delphiの開発・提供を行っているEmbarcadero TechnologiesのDelphiページでは25周年記念コンテンツが公開されている（Embarcadero日本法人代表によるブログ）。

Delphiの最初のバージョンはWindows 3.1向けの開発環境として登場し、1996年にリリースされたDelphi 2でWindows 95向けの32ビット環境に対応した。現在の最新バージョンは2019年12月にリリースされた「Delphi 10.3.3」で、WindowsだけでなくmacOSやiOS、Android向けアプリケーションの作成にも対応している。

Anonymous Coward曰く、

昨夜Twitterで見かけた「数億円規模のプロジェクトをたった二人で開発させられた話」という開発失敗談が酷かったので共有してみる。

この記事はフリーランスのWebエンジニアの投稿者の方が最近まで参加していたプロジェクトの炎上話ということだが、数億円規模で見積もられたシステムリプレース案件を、企業ではなく有名なフリーランスエンジニアの方が個人で受注したのだという。この受注者は自分がPMとなる形でTwitterで開発者を募集。当初は20名程度のプロジェクトとなるという話だったのが、受注者の暴言などもあり結局3名しか集まらないまま開発がスタートしたとのこと。

その後も、受注者はPMとしても開発者としても仕事を全くしないまま、自身は海外旅行やトークショーに明け暮れる日々を過ごしてプロジェクトは大混乱。終いには他人にPMを押し付けようとするも辞められてしまい、納期直前で増員を図るも結局解決はしないまま、投稿者の方もいい加減付き合いきれなくなり、プロジェクトを抜けたという。プロジェクトがその後どうなったのかは記されていない。

この記事がどこまで真実かは分からないが、Twitterには誰だか分かったというレスや、関係者らしきコメントも付くなど、何かしらそういう事件があった様子である。スラド読者諸氏もこうした案件を目にしたことはあるだろうか？

エアバスがA350型機で操縦室内の液体禁止ゾーンを定義する航空機運航マニュアル(AFM)暫定リビジョン(TR)を発行したことを受け、EU航空安全機関(EASA)が緊急の耐航空性改善命令(AD)を出し、AFM TRに従ってAFMを訂正するよう運航会社に命じた(AD、 The Registerの記事、 Flight Globalの記事)。

同型機では2つの操縦席の間にある制御パネルの組み込まれた台に誤って液体をこぼした後、運航中にエンジンの1つが停止し、再始動することもできずに緊急着陸するトラブルが2件報告されているという。異常の原因は液体が制御パネルにこぼれたことが原因とみられ、修正が行われなければ大きな事故につながる可能性もある。そのため、エアバスではAFM TRで操縦室内の液体禁止ゾーンを定義し、誤って液体をこぼした場合の対応を追加したほか、操縦室内での液体の扱いに関する航空会社への通達も発行したとのこと。

操縦室内で液体をこぼしたことによる緊急着陸はエアバスA330でも昨年発生しているが、こちらは電子回路の短絡・過熱による発煙が原因であり、エンジンの問題は報告されていない。

gf1e曰く、

寿司チェーン店のくら寿司が提供しているスマートフォン向けアプリ「スマホdeくら」では、事前予約や事前注文といったサービスが利用できるが（過去記事）、このアプリのiOS版を使用しており、かつOSの日時表示設定で和暦表示を選択していた場合、予約日時が「4038年」や「4008年」などと表示される不具合が発生しているという（日経xTECH、黒翼猫のコンピュータ日記 2nd Edition）。

日時表示を西暦で行うように設定している場合、この問題は発生していない。原因としては、ロケールの設定を適切に行なっていないため、年が「令和2020年」と解釈されてしまったのではないかと推測されている。

headless曰く、

Linuxカーネル5.6（Linuxカーネル5.4/5.5にバックポートされる可能性も高い）の32ビット版で2038年問題（Y2038）への対応が初めて行われたという（Arnd Bergmann氏のメーリングリスト投稿、Phoronix、The Register）。

Y2038はUNIX時間が2038年1月19日3時14分7秒（UTC）以降、符号付き32ビット整数で表現できる範囲を超えてしまうという問題だ。OpenBSDは2014年にY2038対応しているが、Linuxの場合64ビットシステムでは64ビット整数が標準のため影響は少ないものの、カーネルとユーザー空間が分かれていることから32ビットシステムでの対応は簡単に進められる問題ではなかったという。なお、2038年に32ビットPCが使われていない可能性は高いが、32ビットの埋め込みシステムが多数残っている可能性もある。

Arnd Bergmann氏らは何年にもわたってY2038対応に取り組んでおり、32ビットシステムでも64ビットのtime_tが使われるようにするなどの修正を進めていた。Bergmann氏によればLinuxカーネル5.6が2038年以降も32ビットシステムで実行可能な初のリリースとなるが、いくつか注意すべき点が残されているという。たとえば、ユーザー空間は64ビットtime_tを使用するようコンパイルする必要がある。また、タイムスタンプに符号付き32ビット整数を使用するファイルシステムの問題など、64ビットシステムに影響する問題は32ビットシステムにも適用されるとのことだ。