あるAnonymous Coward曰く、

著名エンジニアのmattn氏がソースコード上でのtypoについて投稿したtweetに対し、小飼弾氏が「APIでtypoすると末代まで祟るのはcreat（）で全unixenが噛み締めた」と反応したり、結城浩氏が「HTTP referer」などと反応している。

この辺のネタは以前小飼氏がブログでネタにしているが、英語に不慣れな日本人プログラマであればソースコード上で英語に関連するtypoの1つや2つあるだろう。

個人的には（厳密にはtypoではないが）「datas」とか「pathes」とかの複数形絡みは結構ミスっているのだが、皆さんがやってしまった恥ずかしいtypoを（後学のためにも）ぜひ披露して欲しい。

現在Googleが策定を進めているChrome拡張機能プラットフォームのマニフェスト新バージョンManifest V3のドラフトには、広告ブロック拡張機能の動作を制限するAPI変更が盛り込まれている(9to5Googleの記事、 gHacksの記事、 The Registerの記事、 Chromium Bug Issue 896897 — Raymond Hill氏のコメント)。

現在のManifest V2では、広告ブロック拡張機能はwebRequest APIを使用してネットワークリクエストを変更・リダイレクト・ブロックできる。しかし、Chromeから拡張機能へリクエストを転送し、拡張機能の処理を待つ必要があるため、大幅な遅延が発生することもあるという。

対策としてManifest V3ではブロッキング用途でのwebRequest API使用が制限され、ブロッキング用としては新たにdeclarativeNetRequest APIが追加される。declarativeNetRequest APIではリクエストに対してどのような処理をするのか拡張機能に問い合わせ、それをChrome側で処理する形になる。これにより、効率の悪いルールをChorme側で無効化することも可能だ。

しかし、uBlock OrginとuMatrixを開発するRaymond Hill氏(gorhill)によれば、declarativeNetRequest APIはAdblock Plus互換のフィルタリングを強制するもので、uBlock OrginやuMatrixが存在できなくなるだけでなく、新たなフィルタリングエンジンの登場も不可能になるという。また、ルールの数も30,000件に制限されることから、広く使われているEasyListのルールだけでも制限を上回る。

一方、Googleは変更後にも不可欠な場面での利用がすべて可能になるようにしたいと考えており、引き続き拡張機能が動作し続けるよう拡張機能の開発者と協力しているとのことだ。

PHP開発チームは10日、PHP 5.6.40/7.1.26/7.3.1/7.2.14をリリースした。いずれもセキュリティ修正のためのリリースだが、PHP 5.6.40を除き、セキュリティ以外のバグ修正も含まれる(PHP 5 ChangeLog、 PHP 7 ChangeLog)。

これについて あるAnonymous Coward 曰く、

新年早々mbstring等のバッファオーバーフローの脆弱性対策が行われたのだが、それが7系のみならず、年末でセキュリティ対策も含めてサポート終了となったはずの5.6にも適用されたようである。EOLとはいえ、さすがにまだ放置できないということだろうか。今後もこうした対応が続くのか気になるところである。

PHP 5.6.39のアナウンスでも同じことが書かれていたが、PHP 5.6.40はPHP 5.6ブランチのスケジュールされていた最後のリリースとのこと。今後、重大なセキュリティ上の問題が発見されれば追加のリリースが出る可能性もあるが、そうでなければPHP 5.6.40が最後のリリースとなる。

maia曰く、

厚生労働省の「毎月勤労統計」において2004年から2017年まで不適切な調査や統計処理が行われていた問題で（過去記事）、すでに発表されていた統計値を補正した再集計値が発表された（朝日新聞）。また、厚生労働省は1月22日付けで毎月勤労統計調査を巡る不適切な取扱いに係る事実関係とその評価等に関する報告書を発表している。

統計の信頼性は重大な問題だが、経緯は少々複雑で、手続き上の問題もさることながら、初歩的な計算上のミスがあった（池田信夫氏の勤労統計問題の原因は「COBOLプログラムのバグ」）。

経緯としては、2004年に中小企業の抽出率を上げるのと同時に東京都の大企業（従業員500人以上）だけを対象とした抽出調査にしたが（大企業は本来全数調査）、システム更改時に抽出した調査結果を復元処理するのを忘れていたという。3分の1を抽出したら3倍に復元しないと全国平均がずれてしまう。統計調査に係るシステムの言語はCOBOLで、改修は外注ではなく内部で行っているが、「システム担当係でCOBOLを扱える者は1人又は2人に過ぎなかった」。バグがあっても、ダブルチェックが働かなかった。そして2018年にサンプルの入替方法の変更にともなう改修に併せ、復元処理を入れた。14年間気づかなかったバグに、システム更改時に気づいて（黙って）修正したようだ。その後、統計数値の上振れについて指摘されたという。

問題をCOBOLプログラムに押しつけるような印象の記事に対しては多数のツッコミも寄せられている。

IPA（情報処理推進機構）が基本情報技術者試験で出題されるプログラミング言語について、COBOLを廃止してPythonを追加すると発表した。

COBOLについては2019年の秋期試験を持って廃止され、2020年春期試験からは代わりにPythonが追加される。これにより、試験で出題される言語はC、Python、Java、アセンブラ（CASL Ⅱ）になる。

そのほか、2020年の春期試験からは午後試験の出題数や解答数、配点の見直しも行われるという。

あるAnonymous Coward曰く、

GitHubの無料プランユーザーは今まで非公開（プライベート）リポジトリを1つまでしか作成できなかったが、1月7日にこの制限が撤廃され、プライベートリポジトリを無制限で作成できるようになった（The GitHub Blog、TechCrunch）。

GitHubではこれまで無料プランではパブリックリポジトリしか作成できず、プライベートリポジトリを作るには有料プランを契約する必要があったが、これが解放されるという。共同作業者数は3人と制限されるものの、個人ユーザーにとっては大変朗報である。

GitHubのプラン比較ページによると、無料プランのプライベートリポジトリではGitHub PagesやWiki機能が利用できないほか、ブランチへの変更を制限する「Protected branches」や「Code owners」、AWSなどのアクセスに必要なトークンを誤って公開することを防ぐ「Public token scanning」、リポジトリの分析機能「Repository Insights」にも対応しない。

Microsoftは16日、Windows 10 Insider Preview ビルド18317をファーストリング向けに提供開始した(Windows Experience Blogの記事)。

本ビルドでは、タスクバーの検索とCortanaが分離しており、タスクバーには「検索」と「Cortana」を個別に表示できるようになった。「設定」アプリでも独立した設定項目が用意されている。この機能は数ビルド前からWindows Insider Program参加者の一部に提供されていたが、本ビルドでは全員が利用できるようになった。

このほか本ビルドではスタートメニューの信頼性を高めるために独立したホスティングプロセス(StartMenuExperienceHost.exe)が割り当てられており、「設定」アプリではフォント設定ページの改善やWindows Insider Program設定ページの簡素化が行われた。また、Windows Consoleも改善されている。

Microsoftは3日、Windows 10 Insider Preview ビルド18309(19H1)をファーストリング向けに提供開始した(Windows Experience Blogの記事)。

ISOイメージが提供されていないため実際の動作は確認できないが、ビルド18309のPro/Enterprise/Educationエディションでは、初回起動時のOOBE(Out of Box Experience)でCortanaによるセットアップ最終段階の案内がデフォルトで無効になっているそうだ。スクリーンリーダーを使用するユーザーは、Windows+Ctrl+Enterでいつでもナレーターを起動できるとのこと。デフォルト無効と説明されているが、OOBEでCortanaを有効にする方法の有無については記載がない。

このほか本ビルドでは、ビルド18305でHomeエディションにのみ提供されていたサインイン画面でのPIN(Windows Hello 暗証番号)リセット機能や、電話番号を使用して作成したパスワードなしのMicrosoftアカウントでサインインする機能が全エディションで利用できるようになった。また、ナレーターの改善や、「設定→簡単操作→カーソルとポインターのサイズ」で選択可能なポインターサイズの追加も行われている。

なお、ビルド18305では累積更新プログラムKB4483214(ビルド18305.1003)をインストールするとWindows Defender Application GuardやWindows Sandboxを起動できなくなる問題が発生していたが、本ビルドでは修正されているとのことだ。

Googleは15日、Google Playで公開するAndroidアプリの64ビット対応必須化の詳細を発表した(Android Developers Blogの記事、 Neowinの記事、 BetaNewsの記事、 9to5Googleの記事)。

対象となるのはネイティブコードを使用するアプリで、32ビット版に加えて64ビット版を提供する必要がある。JavaやKotlinのみで書かれたアプリを変更する必要はないが、SDKやライブラリを使用している場合は要確認だ。また、現在のところ64ビットコードをサポートしていないWear OSやAndroid TVにのみ対応するアプリや、Android 9 Pie以降に提供しないアプリについては対象外となる。なお、32ビットサポートに対するポリシーの変更はなく、32ビットデバイスには今後もアプリを提供していくとのこと。

2019年8月から64ビット対応が必須となることは2017年に発表されていたが、今回はさらに詳細なスケジュールが出ている。まず、2019年8月1日以降、ネイティブコードを使用する新しいアプリとアップデートのすべてが32ビット版に加えて64ビット版を含めることが必須になる。ただし、Unity 5.6またはそれ以前のバージョンを使用する既存のゲームについては、2021年8月まで32ビット版のみをアップデートも受け付ける。2021年8月1日にはUnity 5.6またはそれ以前を使用するものを含め、64ビット版を含まないアプリはGoogle Playで64ビットデバイスに提供されなくなるとのこと。

アプリ開発者に対しては、APK Analyzerによるネイティブコードの確認、64ビットアーキテクチャーの有効化、SDKやライブラリの更新などが求められている。SDKやライブラリの提供者に対しては、アプリ開発者が対応する時間をとれるよう、なるべく早く64ビット対応版を提供し、それを開発者に知らせるよう求められている。Unityを使用するゲームのみ猶予期間が設けられたのは、メジャーなゲームエンジン(Unreal、Cocos2d、Unity)の中でUnityが64ビットサポートを追加した時期が遅かったためとのことだ。

あるAnonymous Coward曰く、

PHP向けのパッケージ管理ツールPEAR（Wikiepdiaページ）の公式サイトpear.php.netが19日、攻撃を受けた痕跡が見つかり、さらに改竄されたgo-pear.pharが発見されたことを明らかにした（今回のクラッキングに関するアナウンス）。

PEARは公式サイトをクリーンな状態で再構築しようと試みており、いまだサイトは停止中の状態にある。過去半年以内に公式サイトで配布されていたgo-pear.pharは改竄されていた可能性があるとのことで、ダウンロードしたユーザーにはGitHubのリリースページを元にハッシュのチェックや、再ダウンロードを行うよう呼びかけられている（改竄対策のアナウンス）。

最近ではPHPのライブラリ周りはComposerへの移行が進んでおり、PEARを使う機会は少ないかもしれないが、該当する方は注意されたし。