NHKは5月に、国や全国の都道府県から川の氾濫による浸水想定データを集めた「NHK全国ハザードマップ」を公開している。この発表時、NHKには市町村が出しているハザードマップがあれば十分といった意見も寄せられたようで「34テラバイトのデータと格闘して「全国ハザードマップ」を公開した理由」とする説明記事を21日に公開している（NHK）。

理由一つは使い勝手。現在、ハザードマップは市区町村が紙に印刷して住民に配布する前提となっており、PDF形式で掲載されていることが一般的だ。このため、検索性がいまいちで紙やPDFで自宅や職場を探すのは大変だということを理由の一つとしている。またハザードマップは自治体ごとに配布されているため、職場がある隣の市のリスクを確認したい、他県にある実家のリスクを調べたいといった場合、各自治体のサイトに個別にアクセスする必要があるなどの問題も記事では指摘している。

こうした問題はデジタルデータを活用した地図であれば、住所や目印になる施設を検索して表示するできることから「リスクを確認する手間」を大幅に省くことができるとしている。なお自治体では紙やPDFのデータしか持っていないことから、災害シミュレーションを実施した企業から直接データを提供してもらうこともあったようだ。こうして収集したデータは34テラバイトにも及んだとしている。

ESA は火星探査機 Mars Express が搭載する地表下測深レーダー高度計 MARSIS のソフトウェアを更新すべく、準備を進めているそうだ (ESA のブログ記事、 The Register の記事、 The Verge の記事、 Neowin の記事)。

MARSIS は 2007 年に火星の南極で大量の氷を発見し、2012 年 ～ 2015 年の観測データはその下に液体の水が存在する地底湖の発見につながった。しかし、2003 年 6 月の打ち上げ以来ソフトウェアは更新されておらず、20 年前に Windows 98 ベースの環境で開発されたものを使い続けている。今回の更新について開発環境等は説明されていないが、目的はミッション開始当時よりも高いパフォーマンスの実現だという。

これまで大量の高解像度データを保持するため複雑な処理を行ってきたが、更新後は不要なデータを削除することでスペースが確保される。また、受信感度の改善や地球に送るデータの量と質を増すオンボードデータ処理の改善も含まれるとのこと。これらのソフトウェアアップグレードで MARSIS を稼働できる時間は 5 倍に伸び、より広い領域の調査が可能になる。Mars Express は 20 年前の古い探査機だが、新しい測定機器を追加したかのような性能向上が期待できるとのことだ。

headless 曰く、

Snyk が Linux Foundation の協力によりまとめた報告書「State of Open Source Security 2022」によると、オープンソースパッケージの依存関係によりソフトウェアサプライチェーンの複雑さが増し、脆弱性の修正にかかる時間が長くなる傾向がみられるそうだ(プレスリリース、 BetaNews の記事)。

オープンソースパッケージは現代的なアプリケーションで重要な要素となっており、開発者は数多くのオープンソースパッケージをプロジェクトで使用する。プロジェクトごとの直接的な依存関係は平均 80、最も多い JavaScript プロジェクトでは平均 174 まで増加する。依存関係は直接的なものだけでなく、推移的 (間接的) な依存関係もある。推移的依存関係は見えないリスクを生むだけでなく、修正も困難だ。脆弱性全体の 40 % が推移的依存関係で見つかっており、プロジェクトごとの平均的な脆弱性の数 49 に対し、18 ～ 20 が推移的依存関係から発生することになる。

その一方でオープンソースソフトウェア (OSS) の開発・利用に関するセキュリティポリシーを確立している組織は 49 %。組織内の OSS のセキュリティを信頼していないという回答は 41 % にのぼる。ただし、72% は 2022 年末までにある程度以上のセキュリティを確保できると回答しているという。オープンソースプロジェクトで脆弱性が修正されるまでの (平均) 時間は 2018 年の 49 日間から 2021 年には 110 日間まで増加しており、プロプライエタリプロジェクトよりも 18.75 ％ 長い時間を要するとのことだ。

headless 曰く、

Microsoft は 16 日、Microsoft Store ポリシーやアプリ開発者契約書などを改定して開発者に通知した (改定版ポリシー、 改定版アプリ開発者契約書: PDF、 Neowin の記事)。

Microsoft Store ポリシー改定では一般に無料提供されているアプリケーションの収益化や、機能に見合わない高額な価格設定が禁じられた(10.8.7)。収益化禁止部分は日本語版で「オープンソースや無料で一般公開されているその他のソフトウェアから利益を得ようとしたり」(～してはなりません) となっており、有料のオープンソースソフトウェアは Microsoft Store で提供できない。一方、英語版ではオープンソースの収益化禁止は他で一般に無料提供されている場合に限られるとも読める。ドイツ語版はさらに明確に「一般に無料提供されている」がオープンソースソフトウェアにもかかっている。

アプリ開発者契約書の主な変更点は Win32 アプリを Microsoft Store で提供する場合の更新に関する記述の追加と、オーストラリアでの Microsoft の住所変更だ。新ポリシーやアプリ開発者契約書は 7 月 16 日に発効する。

ネット歴がの長い人なら割とおなじみの、ネット掲示板上で「ぬるぽ」と書かれたら「ガッ」っと突っ込む一連の流れ。ITmediaの記事によれば、この一連の流れが誕生してから2022年6月20日で20周年となるそうだ。誕生したのは当時の2ちゃんねる（現5ちゃんねる）で、プログラマー板に「NullPointerExceptionを『ぬるぽ』と呼ぶスレ」が立てられたのがきっかけとなっている（ITmedia）。

このスレでは、1が「ぬるぽ」と書き込んだ2分後、次に書き込んだ人（>>2）が>>1を「ガッ」とたたくアスキーアートを投稿。その後、その流れがネットスラングとして定着することとなった。記事によればなぜ「ガッ」と返すのかは当時書き込みをした「>>2」にしか分からないとしている。スラドならリアルタイムで該当スレの当時の流れを見ていた人もいそうではある。

あるAnonymous Coward 曰く、

2ちゃんねるのプログラマー板に当該スレッドが建てられたのが2002/6/20とのこと

headless 曰く、

オランダの消費者・市場庁 (ACM) は 11 日、オランダのデーティングアプリによる支払いシステム選択について Apple が不当な条件を解消したとの判断を示した (ニュースリリース)。

ACM は昨年 12 月、デーティングアプリが Apple のアプリ内購入 (IAP) 以外の方法で課金できないことを不当な条件だとして、これを解消するよう Apple に命じた。Apple は命令に従うと発表しつつ、支払いシステムの変更を困難にする条件を提示し、週 500 万ユーロの制裁金支払いを命じられていた。最終的に Apple は制裁金の最高額として設定されていた 5,000 万ユーロを支払っている。

そのため、Apple が ACM の要求を無視しているような印象を受けるが、実際は要求に従って修正を行っており、10 日に発表した修正で ACM の示す要件をすべて満たしたようだ。

Microsoft は 9 日、Windows 11 Insider Preview ビルド 25136 を Dev チャネルで提供開始した (Windows Insider Blog の記事、 The Verge の記事、 Softpedia の記事、 The Register の記事)。

本ビルドではエクスプローラーにタブ表示機能が追加され、ナビゲーションウィンドウも更新されている。Windows 11 Insider Preview ではビルド 22572 にタブ表示機能が無効化された状態で追加されていたが、この時は特に発表がなく、その後のビルドで削除されていた。今回は正式に追加が発表され、段階的にロールアウトしていくとのこと。まだ有効になっていない環境でも ViVeTool のようなツールで構成 ID「37634385」を有効にして Windows 11 を再起動すれば利用可能になる。

なお、タブにファイルを直接ドロップすることはできないが、ドラッグしたファイルをタブ上でホバーするとタブが切り替わるため、別のタブに移動・コピーすることは可能だ。タブを並べ替えたり、他のウィンドウに移動したりといったことはできない。ビルド 22572 で発生していた「タイトルバーとウィンドウ枠線にアクセントカラーを付ける」オプション有効時の問題は解消している。

更新されたナビゲーションウィンドウには OneDrive のプロファイルフォルダーが追加され、「PC」に既知の Windows フォルダーが表示されなくなる。このほか、ウィジェットで気象情報以外のニュースアラート等もタスクバーに表示されるようになるとのこと。これらの機能も段階的なロールアウトとなるため、有効化されるまでに時間がかかる可能性もある。

headless 曰く、

Google は 8 日、次期 Android 13 の 3 番目のベータ版となる Android 13 Beta 3 をリリースした (Android Developers Blog の記事、 リリースノート、 9to5Google の記事、 Android Police の記事)。

Beta 3 はプラットフォームの安定版のマイルストーンに到達し、API も最終版の API 33 となっている。今後は 7 月の Beta 4 を経て最終リリースとなるが、開発者 API やアプリ側から見たシステムの挙動が変更されることはないため、開発者は互換性の最終確認を開始する時期となる。Android 13 での変更点として確認すべきポイントとしては、通知に関する実行時の権限や、クリップボードプレビュー機能でセンシティブ情報が表示されないようにするためのフラグ付け、JobScheduler によるプリフェッチジョブの処理が挙げられている。

API 33 以降をターゲットにするアプリでは、付近の Wi-Fi デバイスに対する実行時の権限やメディアファイルに対する細かいアクセス権限、ボディセンサーのバックグラウンド使用時の権限、一致しないインテントをブロックするインテントフィルタ、PlaybackState から派生するメディアコントロールといった動作の変更に注意する必要がある。また、タブレットや大画面デバイスのサポートに関しても確認すべきとのこと。

Beta 3 はサポートされる Pixel デバイスでベータプログラムにエンロールすれば OTA 配信されるほか、システムイメージをダウンロードすることも可能だ。GSI バイナリも Beta 3 に更新されており、Android エミュレーターでは新規仮想デバイス作成時に API 33 のシステムイメージをダウンロードして指定すれば Beta 3 が利用可能になる。時期は不明だが、ベータプログラムに参加するパートナーの対応デバイスにも Beta 3 が提供されるだろう。

nemui4 曰く、

日本のお役所には、数字が一桁の場合は全角、二桁以上の場合は半角で記述するという変態的なルールがあるそうな。

９月１日　第一回目会議
９月10日　第二回目会議
10月３日　第三回目会議
10月30日　第四回目会議

ワープロで文書を作成していた頃にできたルールだそうだけど、知らんかった。
Excel方眼、セル結合、セル内改行とかも根っこは同じなんでしょうね。

情報元へのリンク

ざっくり調べたところ、この件は慣例としては存在しているが、役所全体で一桁の数字は全角、二桁以上は半角と決められているわけではないようだ。今年1月に出された「「公用文作成の考え方」について（建議）では15ページ目の「I-4数字の使い方」の項目では、

算用数字で全角を用いるか半角を用いるかについては、特に定めは無いが、使い分けの考え方を文書で統一する。その際、全角と半角が混在すると、印刷文字（フォント）の選択可能によっては、不ぞろいや不自然な空白などが生じ、読み取りにくくなる場合があることに留意する（以下略）

と指摘されている。またその直前に出された、「新「公用文作成の要領」（仮）」（案）に関する意見募集の結果の6ページの意見11では、半角全角の使い分けを止めるべきだとの指摘もおこなわれている。

文化庁が2020年7月に公開している「公用文作成に関するアンケート」の結果の概要」でも用語の関する様々な問題が指摘されている。この中の8ページ目の最後に数字の全角半角の扱いについて触れられているが、

数字の全角半角について，役所の文章は１桁全角，２桁以上半角となっていること が多いが，調べる限り，統一的なルールはないかと思う。何らかのルールがあるとよいのではないか。
また，英字の全角半角についてのルールもあると良いのではないか。（例：ＧＤＰ は全角？，Society5.0 は半角？）

となっており、やはり慣例的なルールであったようだ。

ロシア独自の Android アプリストア「RuStore」がベータ版のサービスを開始した (公式サイトの Google 翻訳、 TV360 の VK 投稿、 NR の VK 投稿、 Neowin の記事)。

RuStore はロシアのソーシャルメディア VK が提供するもので、Kaspersky と提携してアプリのセキュリティを保つという。Android デバイスに RuStore アプリをインストールし、RuStore アプリをアプリストアとして利用する仕組みのようだ。有料アプリの提供も可能で、VK の Alexander Tobol 氏は手数料率が 15 % 未満になると述べているそうだ。利用可能なアプリは現在のところ 100 本程度だが、今後追加していくとのことだ。

なお、公式サイト rustore.ruは断続的に接続が不安定になるので、Google 翻訳にリンクしている。RuStore で入手可能なアプリの大半はロシア企業によるものとみられるが、飲食カテゴリには契約上ロシア国内での営業を中止できないと判断したバーガーキングやドミノ・ピザのアプリなども掲載されている。

headless 曰く、

Google Project Zero のバグハンター、Tavis Ormandy 氏が Lotus 1-2-3 を Linux に移植したそうだ (Ormandy 氏のブログ記事、 GitHub リポジトリ、 The Register の記事、 動画)。

Lotus 1-2-3 が大好きだという Ormandy 氏は DOS 版の Lotus 1-2-3 R4D を DOSEMU2 上で実行するためのディスプレイドライバーも開発している。さらに数年前から Lotus 1-2-3 の機能を拡張できるアドインについて調査を進め、今回の Linux への移植につながったという。

Lotus 1-2-3 のアドインは LPL と呼ばれる専用の言語で書かれているが、SDK は 395 ドルで販売されていたことからユーザー数は少なく、SDK もコンパイラーも失われている。Ormandy 氏はアドイン開発の解説本をなんとか見つけたものの、SDK を手にすることができなかった。それから 1 ～ 2 年が過ぎ、Ormandy 氏は 90 年代の BBS シーンでシスオペだったという人物に出会う。彼は古い BBS システムのテープバックアップを保存しており、その中から不正コピー版の SDK を発見し、復元できたとのこと。

それだけでも大きな進展だが、BBS からはさらに Lotus 1-2-3 for UNIX が発見される。インストールディスクから見つかった「123.o」は UNIX の実行形式ファイル COFF であり、GNU objcopy により Linux の ELF 形式にできるが、システムコールや関数の互換性、リロケーションの問題などを解決する必要がある。そのため、Ormandy 氏は coffsyrup と呼ばれる小さなツールも作成している。

数多くのハックの結果、Lotus 1-2-3 は でクラッシュすることなく Linux 上で実行できるようになった。ライセンスファイル 「LICENSE.000」が見つからなければ起動を拒否する機能も搭載されているとのことだ。

headless 曰く、

米国で 19 日、スターバックスのモバイルアプリに障害が発生してコーヒードリンカーを絶望させたそうだ (GeekWire の記事)。

スターバックスによれば事前注文機能と支払い機能が利用できなくなっていたといい、店員に口頭で注文を伝えることや、現金で支払うことが昔の人のようだといった苦情がコーヒードリンカーから出ていた。

スラドでは 2017 年に米スターバックスのモバイル注文システムが好調すぎて売り上げに悪影響を与えたことが話題となったが、2019 年にApple Payに抜かれるまではユーザー数で米国1位のモバイルペイメントシステムだったという。

個人的に口頭での注文は苦にならないが、現金で支払うのは面倒だ。スラドの皆さんはいかがだろう。スターバックスに限らず、アプリが使えないと利用困難になるような店は他にもあるだろうか。

headless 曰く、

Microsoft は 24 日、Windows 11 の Amazon Appstore 提供地域拡大計画を発表した (Windows Developer Blog の記事 [1]、 [2]、 Neowin の記事、 Windows Central の記事)。

Windows 11 の Android サブシステム Windows Subsystem for Android (WSA) でアプリストアとして機能する Amazon Appstore は、現在のところ米国でのみ利用可能だ。システム要件を満たす環境で Windows の地域の設定で米国を選択すればインストールは可能だが、Amazon アカウントにログインしてもアプリをインストールすることはできない。同時にインストールされる WSA は日本でも機能するものの、Android アプリを実行するには別途 Android アプリのパッケージファイル (APK) を入手してサイドローディングする必要があるので面倒だ。

年内に Amazon Appstore が利用可能になるのは日本のほか、フランス・ドイツ・イタリア・英国の計 5 か国。Amazon Appstore は Google Play と比べて入手可能なアプリが限定されるとはいえ、直接アプリをインストール可能になれば利用しやすくなるだろう。

いつもあさってというブログ記事によると、エンジニアは信心深いところがあるのだそうだ。曰く、サーバーをお祓いしたり、デバッグ神社を建てたり、リリースするときにお祈りしたりもする。こんなことから、ブログ主は全面リニューアルと一部サービス終了があったiOS、Androidアプリをソースコードへの感謝の気持ちを込めて、お焚き上げをすることにしたそうだ（ソースコードをお焚き上げしました）。

ブログ記事ではこの過程を紹介しているのだが、実際にやるとなるとソースコードを外部に持ち出すための許可やお焚き上げをするのに適しており、かつ現実的に移動もできるIT系神社探し、必要な予算の確保など結構な手間がかかっている。

Google が Android Studio の Android バージョン分布チャートを更新している (9to5Google の記事)。

今回のデータは 5 月 9 日版。それによると、Android 7.0 Nougat 以降の合計が 91.7 % と 90 % を超えており、Android 6.0 Marshmallow を含めると 95.6 % まで増加する。ただし、前回 11 月分のデータと比べて増加しているのは Android 11 以降 (35.0 %、10.7 ポイント増) のみであり、Android 10 以前のバージョンは減少している。

9to5Google の記事では Android 12 以降の個別データがないとしつつ Android 11 を 28.3 % としているが、その根拠は示されていない。11 月分のデータで Android 11 以降は 24.3 % だったが、9to5Google の記事ではやはり根拠を示さずに Android 11 を 24.2 % としていた。ありそうな数字ではあるが根拠が示されないのは気になるところで、記事のコメントでも指摘されている。

なお、Google Play のポリシー改定により 11 月 1 日以降、既存のアプリは 2 年以内にリリースされた Android OS メジャーバージョンをターゲットにすることが義務付けられ、遵守しないアプリは新しいユーザーからのアクセスが制限されるようになる。ちょっと期間が分かりにくいのだが、実際にはリリースから 3 年を過ぎてから次のメジャーバージョンに移るようだ。Play Console ヘルプによると、既存のアプリは 11 月 1 日から Android 11 (2020 年 9 月リリース) 以降、2023 年 11 月 1 日から Android 12 (2021年 10 月リリース) をターゲットにすることが義務付けられることになる。