blog.8-p.info

とよしまさんが、

ISO-2022-JPのサポートをChromeからdropするかどうかって話があって、個人的には落としても良いような気がするけど「落としても良いんじゃ？」と積極的にいうのは少し責任重大で怖いな。

と書いていて、いやいや落としてはいかんでしょう、と思って

個人的には落とさないでほしい (don’t break the web!) なんですが、これは ICU-22166 にコメントするのと https://bugs.chromium.org/p/chromium/issues/detail?id=430823 にコメントするのではどっちが良いんでしょうか。それとも、コメントよりパッチでしょうか?

と返信した問題のつづき。

経緯

HTML5 の策定で知られる WHATWG には、さらに Encoding Standard というのがあり、そこで規定されている挙動と、Chrome の挙動が違うのではないの、というのが最初の問題。

invalid byte sequence handling is not compliant to the WHATWG encoding spec in multibyte encodings

The encoding spec requires that if the second byte of an invalid two-byte input sequence belongs to the ASCII-range, the first byte be converted to U+FFFD while the second byte being unconsumed.

ここから派生して、そもそも ISO-2022-JP いらないのでは、という話がはじまっていて、

Consider dropping ISO-2022-JP from the list of legacy encodings to support

Now in 2022 with the vast majority of web pages in UTF-8 with a small percentage of legacy encodings (non-stateful at that) in use, we should seriously consider dropping ISO-2022-JP (“ugly” stateful encoding) from the list of legacy encodings to support.

さらに ICU のほうに、不正なバイト列のとりあつかいが WHATWG の仕様に準拠していないですよ、というバグが立てられている。

Incomplete ESC sequence handling when converting ISO-2022-JP to Unicode is different from WHATWG spec

ICU’s handling of ISO-2022-JP escape sequences and SI/SO when converting ISO-2022-JP to Unicode needs to be revisited. The encoding spec wants to add back any ASCII character in an incomplete/invalid ESC sequence (e.g. ‘$’) to the stream. Currently, it’s eaten up.

じつは、とよしまさんの最初の発言からしばらくたって、最初のバグは無事に修正されている。二個目のバグには、ISO-2022-JP 使われていたよ、という趣旨のコメントをした。最後のバグも、私が議論を追いきれていないので、ちょっと質問のコメントをしてみた。

ブラウザにはレガシーなエンコーディングのサポートを続けてほしい

Google にこういったデータがあるのかはわからないけれど、Chrome で最近つかわれたエンコーディングとか、検索からクリックされたページとかを調べると、ISO-2022-JP は殆ど使われていないと思う。

ただ、日本のインターネットの過去についていうと、ISO-2022-JP はそれなりに使われていた。昔からあるページとか、Wayback Machine で過去の記録をたどっているときに、ISO-2022-JP がデコードできなくなると、アクセスできないページは一定量ある。

ほんとうはこれを定量的に示せるといいのだけど、まだできていません。

youtube-dl が GitHub から追い出されそうになったときに、youtube-dl をジャーナリストのツールだとしていた人がいて、

Music industry forces widely used journalist tool offline

In fact, youtube-dl is a powerful general purpose media tool that allows users to make local copies of media from a very broad range of sites. That versatility has secured it a place in the toolkits of many reporters, newsroom developers, and archivists.

ブラウザも、おなじような立ち位置にあって、過去の記録をたどるジャーナリストの人々に「ISO-2022-JP というのがあるから、これはローカルに保存してから、変換ツールにかけてください」というのは、われわれエンジニアがさぼりすぎだと思う。

そうね、と思ったのでちょっと書いてみる。シアトル在住30代男性です。

私の子供はもう新生児ではないけれど、たとえば20代のときに比べると、勉強の時間は減っている。これは、使える時間が減ったのが半分、体力なのか必死さなのか、一時間あったときに、本を読んだりするのが減ったのが半分というかんじで、たとえばこうやってインターネットで遊ぶかわりに読書したらいいのでは、というところはある。週末や仕事のあとに、勉強会にいったりするのは止めた。

それでも、オープンソース活動は維持したかったのもあり、2人目の子供がうまれた年に、仕事でオープンソースができるようなチームにうつって、いまは containerd などを開発している。日本でオープンソース仕事というと、Ruby コミッタとか、趣味ではじめた活動で頭角をあらわしてから、仕事になったひとをよくみかけるように思う。私の containerd 活動は完全に仕事からはじまっていて、これはアメリカのプログラマ雇用の絶対数の多さの反映だと思っている。仕事が1,000個あれば、1%のチャンスが10人にまわってくる。

勉強しないと死ぬの?

むかしむかしに、高橋征義さんが、

自分で本を買って読むのはよいことだ。就業時間以外にコードを書くのもよいことだ。しかし、それは個人のたのしみのために行われるべきものであって、職業上の義務としてなされるべきものではない。それでは単なる時間外労働である。

業務のために、就業時間外にたくさん本を読め、と説く人々は、時間外労働を対価なしに（むしろ本代を払って）行え、と説いていることに他ならないはずだ。これを問題だと思わないのだろうか。私は非常に重大な問題だと思う。そのような行動をとらなければキャリアに支障を来たすというなら、それは業界そのものが深く病んでいるとしか思えない。

と書いていて、当時に、お勉強好きだった私はちょっと反省した。

その後にシアトルにきたら、連邦法に、高給とりのプログラマには残業代はらわないでいいですよ、という例外条項があったり、ジェントリフィケーションの文脈で「プログラマが増えたから家賃があがって困る」みたいな話を読んだりで、プログラマというのは、勉強してバリバリ働いて、ガンガン金を稼ぐ種類の、特殊な仕事なのかなあと思いなおしたりもした。

でもいまは子供がいるので、9時から5時だけバリバリ働きます、ということにしている。我ながら、自分に都合がいいように認識をまげている。さらに、この労働時間のなかに本を読んだりするのをいれるのも、理は通っていると思うけど、まだ実践できてはいない。

勉強しないと死ぬというのは例え話であって、まあ死ぬことはないけど、とりわけ勉強できる環境にあるひとに比べて、競争優位であるとか、分散投資にまわす原資では負けますよね、とは思う。これはしょうがない。また「子育てで学んだことが仕事に生きます」みたいな話は、今度は独身の人々に不利になるので、ほどほどにしておいたほうがいい。そういうこともあるかもしれませんが、それは登山やプラモデルでも学べます。だれもが子供がもてるわけでもない。

寝かしつけとマルチタスク

子供をだっこして寝かしつけていたころは、YouTube で Cars の短いビデオをみてから、My Analog Journal の長いビデオをみるというのをよくやっていた。これが、ポッドキャストとかオーディオブックまでいくと、私としてはちょっとやりすぎというか、会議中にラップトップで別のことをやるような、後ろめたさがある。

私の子供はもう色々がわかる年齢なので、子供と接しているときに、マルチタスクするのはやめないとなと思っている。思っているということは、完全にできてはいないということだけど。

すきま時間の活用みたいなのも「寝ないと生産性があがります」みたいなはなしと紙一重というか、たまには、なにもしない時間がないと死ぬのではと思う。こっちは例え話ではなく、本当に死にそう。

Twitter のタイムラインを、ふだんは Latest Tweets にしている。たまに Home にすると、面白いというか、一言いいたくなるような tweet がならんで、推薦がうまくいっていてすごいなあと思う。一方で、インターネットでみかけた見知らぬ誰かの一言にかえしてみせるのはあんまり意味のあることでもなく、スルーして Latest Tweets にもどすことが多い。

テレビのワイドショーとか、むかしの久米宏とか、世の中のいろいろなことに一言いってみせる「賢さ」みたいなものは、あらゆる専門家が自分自身のチャンネルをもてるインターネット時代にはあまり求められないのだろうと昔は思っていた。実際には、橋下徹がロシアのウクライナ侵攻について語ってみたり、ひろゆきが沖縄の基地問題について語ってみたりするのを、みんなで見ていたりするので、なかなか思ったようにはいかない。人々が話題にするのと、それに納得するのはまた別なので、そこまで悲観すべきものでもないのかもしれないけれど。

マライ・メントラインの小泉悠評は面白いし、実際私もよく本を買っているけれど、一方で「教養人」というのはよくわからないなと思った。軍事以外も語れるのよ、というのはわかる。じゃあとなにができれば教養人になれるのかはよくわからない。たぶん、そもそも「教養」がわかっていないのと、私自身が専門家よりなので、ジャンル横断的な活躍というのは、あったらいいけど、なくてもいいと思っている嫌いがある。

ソフトウェアの日本語文字が中華フォントに侵食されていて想像以上の危機らしい「違和感すごい」というのが盛り上がっていた。

「想像以上」は主観的だけど、個人的にはちょっと煽りすぎのように思った。

前提: Han Unification はひっくりかえせない

そもそも、UTF-8 がよく使われるようになって、絵文字もはいった UCS で、Han Unification しなくてもいいのでは、という話はある。

でもこれは後の祭りで、今更ひっくりかえすのは無理だと思うので、ここでは検討しません。

ユーザー側の言語情報を参照すれば、日本語のグリフは選べる

ほとんどの OS には、このユーザーの言語はこれですよ、という情報があって、それでメニューやボタンの文字が日本語になる。日付の表示方法とかも、これを参照する。統合漢字でも日本語のグリフでレンダリングしたい、というのは、8割くらいはこれで解決するはなしだと思う。

ここは最近地味に良くなっていて、POSIX ロケールの時代だとユーザー:言語 = 1:1 だったのが、最近の Android や macOS では複数の言語を優先順位をつけて設定できるようになっている。私はアメリカに住んでいるのもあり、英語を最優先で、次に日本語という順にしていることが多い。

データ側の言語情報を参照するのも、実装されているところはある

データ側の言語情報を見るのはちょっと手間だけど、実装されているところもある。Twitter で日中で話題になっていそうなもの、例えば「習近平」とかで検索すると、日本語の検索結果は日本語のグリフで、中国語の検索結果は中国語のグリフでちゃんと表示される。HTML をみると、Twitter は div にちゃんと lang=zh みたいな言語情報を持たせている。

書籍や音楽だと、本文や歌詞の言語というかたちで、何らかの言語情報がついているかもしれない。これをレンダリングの時までなんとか引き回すというのは、面倒だけど不可能ではないと思う。

ユーザー側に言語情報がなくて、データ側に言語情報がない場合にも、日本語のグリフで表示してほしい

それは理がないですね。これはどの国のグリフを選んでも誰かが不満をもつ負け戦なので、この条件にならないように頑張るのがプログラマの仕事かと思う。

冒頭のまとめを読んでいると、日本の主導権とか、国力とか、そういう話にもっていきたがる人々もいるけれど、これは「UCS というのは言語に関するメタデータとコードポイントでグリフが決まるものなので、言語情報なしでレンダリングするケースを減らしましょうね」という話でしかないと思う。対立構造を持ち込むのはやめましょう。

8月に注文していた Framework Laptop が、9月になってやっと届いた。 Framework Laptop はアメリカの Framework Computer が開発しているラップトップで、修理しやすい構造と、部品単位のアップグレードが可能なことを特長としている。

2021年に最初のモデルが出たときから気になってはいたのだけど、当時はそこまで新しいラップトップを必要としていなかったこと、会社そのものへの存続への不安から、二の足をふんでいた。

それから一年がたち、会社はちゃんと存続して、タブレットやその他のフォームファクターにも浮気せず、無事に Intel の第12世代プロセッサに対応した二代目 Framework Laptop が発売された。当初の約束通りに、第一世代をアップグレードするための部品も売っている。

ここで買わずに会社がつぶれてしまったら、それもまた後悔しそうなので、応援の気持ちもこめて買ってみた。

ハードウェア

ラップトップとしては、いわゆるウルトラブックとして標準的なかたちで、可もなく不可もない。ホームページでもうたわれているように「薄くて今風の見た目でありながら、修理もできます」という線をまもれていると思う。

The conventional wisdom in the industry is that making products repairable makes them thicker, heavier, uglier, less robust, and more expensive. We’re here to prove that wrong and fix consumer electronics, one category at a time.

とはいえ、私がいままで使っていた MacBook Pro に比べると、ちょっと剛性は落ちる感じがするし、ディスプレイの解像度も 2256 x 1504 と、100% で使うとピクセルが小さすぎ、200% で使うとやや狭い、という微妙なところになっている。

面白いのは、外部端子を自由に選べるところで、私は USB-C x 2, USB-A x 2, MicroSD x 1 にした。ラップトップ本体には USB-C が4つ付いていて、上の写真にあるような小さい部品をそこに差し込める。

また、製品の性格上 Linux ユーザーが多いみたいで、公式に Linux についてのページがあるのも頼もしい。私は Fedora 36 を使っている。

こわれたと思ったらフタを開けてみよう

買った理由の一つには、私に子供がいることもあると思う。家で、こわれたおもちゃを「直す」のは私の担当だ。9割はただ電池を入れ替えるだけだけど、残り1割は、はんだ付けをしてみたり、電源端子を圧着したり、他の家からもらった別のところが壊れているおもちゃから部品をとって、いわゆるニコイチにしてみたりして、本当に直している。「こわれたと思ったらフタを開けて、できそうだったら直してみよう」というのは、私が子供に伝えたいことのひとつなのだと思う。

そう考えると、私がずっと使っている Apple のラップトップは、どんどん直せない方向に進んでいて悲しい。大学のころに使っていた iBook G4 は、コインだけでバッテリーを外して交換できた。いま使っている MacBook Pro のバッテリーは接着されているし、それ以降のモデルでは SSD も交換できない。

M1 以降は、例えばメモリを交換できないかわりに、省電力高性能にできている面はあるだろうから、Apple が悪いというよりはトレードオフなんだろう。世の大半の人々はラップトップを開けたりはしないのもわかっている。でも私は、とりわけ子供の前では、フタを開ける側の人々でいたいと思う。

Source: posts/2022/framework/index.md