とよしまさんが、 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

32歳、新しい技術を習得する余裕がなく昔取った杵柄でいつまで食えるか不安です 生産性への強迫観念を振り払う儀式としての、子育て そうね、と思ったのでちょっと書いてみる。シアトル在住30代男性です。 私の子供はもう新生児ではないけれど、たとえば20代のときに比べると、勉強の時間は減っている。これは、使える時間が減ったのが半分、体力なのか必死さなのか、一時間あったときに、本を読んだりするのが減ったのが半分というかんじで、たとえばこうやってインターネットで遊ぶかわりに読書したらいいのでは、というところはある。週末や仕事のあとに、勉強会にいったりするのは止めた。 それでも、オープンソース活動は維持したかったのもあり、2人目の子供がうまれた年に、仕事でオープンソースができるようなチームにうつって、いまは containerd などを開発している。日本でオープンソース仕事というと、Ruby コミッタと

ソフトウェアの日本語文字が中華フォントに侵食されていて想像以上の危機らしい「違和感すごい」 というのが盛り上がっていた。 「想像以上」は主観的だけど、個人的にはちょっと煽りすぎのように思った。 前提: Han Unification はひっくりかえせない そもそも、UTF-8 がよく使われるようになって、絵文字もはいった UCS で、Han Unification しなくてもいいのでは、という話はある。 でもこれは後の祭りで、今更ひっくりかえすのは無理だと思うので、ここでは検討しません。 ユーザー側の言語情報を参照すれば、日本語のグリフは選べる ほとんどの OS には、このユーザーの言語はこれですよ、という情報があって、それでメニューやボタンの文字が日本語になる。日付の表示方法とかも、これを参照する。統合漢字でも日本語のグリフでレンダリングしたい、というのは、8割くらいはこれで解決するはな

8月に注文していた Framework Laptop が、9月になってやっと届いた。 Framework Laptop はアメリカの Framework Computer が開発しているラップトップで、修理しやすい構造と、部品単位のアップグレードが可能なことを特長としている。 2021年に最初のモデルが出たときから気になってはいたのだけど、当時はそこまで新しいラップトップを必要としていなかったこと、会社そのものへの存続への不安から、二の足をふんでいた。 それから一年がたち、会社はちゃんと存続して、タブレットやその他のフォームファクターにも浮気せず、無事に Intel の第12世代プロセッサに対応した二代目 Framework Laptop が発売された。当初の約束通りに、第一世代をアップグレードするための部品も売っている。 ここで買わずに会社がつぶれてしまったら、それもまた後悔しそうなので

Why is building the Ruby environment hard? の、 ソフトウェアは何もしないと壊れる というのは事実ではあるんだけど、それが良いことかというと、どうなのかなあと思う。ほかにも、我々プログラマはつい「ソフトウェアは完成しない」とかいってしまうし、それは雇用のためには良いことなんだろうけど、でも本当に完成しないんだろうか。 Go の logrus の README には、こんな段落がある。 Logrus is in maintenance-mode. We will not be introducing new features. It’s simply too hard to do in a way that won’t break many people’s projects, which is the last thing you want fro

私は web3 は基本的にダメだと思っていて、Letter in Support of Responsible Fintech Policy にも同意して、署名している。 一方で、Web 2.0 時代によく読んでいた、渡辺千賀さんは暗号通貨勉強会をやっているし、UIEvolution の中島さんは Nouns DAO を高く評価している。中島さんは AWSやAzureどころか、IPFSにすら頼らないフルブロックチェーンのスマートコントラクトは、ブロックチェーンそのものが無くならない限り未来永劫、動き続けるのです。その事実とそれが意味するところに気づいた時には、稲妻の様な衝撃が走りました。 と書いていて、その、インターネット上に巨大なデータベースとチューリングマシンが出現していて、それがかっこいいな、という気持ち自体はわかる。 あるいは、伊藤穣一さんも日本国内では web3 の人としての活動

インプレスから出ている、いちばんやさしいWeb3の教本が良くないという話からはじまって、 「いちばんやさしいWeb3の教本」というのが試し読みできたので開いてみたら、出だしから「Web1の時代は1970年代から80年代にかけて整備され」とめちゃくちゃなことが書いてあってその先を読む気力が失せた。インターネットとWebを混同している? 専門家なのに? いろいろ謎。 そこから、 最近のWeb3への雑感 Web3のここがすごい 書籍「いちばんやさしいWeb3の教本」は本当に酷い内容だし、Web3界隈の人は一致団結して間違いを指摘して、インプレスは回収して内容修正するべき と、また Web3 の話が盛り上がっている。 私はいわゆる GAFA の一つ (Amazon) に勤めているので、人々の「現状の GAFA はいかがなものか」という話には関心がある。また、インターネットの利用者の一人として、例え

yomoyomo さんの Web3の「魂」は何なのか？ を読んだ。私は、Web3 には批判的で、Web3 は Web 2.0 より有意に「悪い」と思っているので ただ、ワタシ自身はWeb3というコンセプトを実は楽観的に見ています。なぜかというと、結局、言葉は成功についてくると考えるからです。 つまり、Web3というコンセプトに厳密に従ったサービスだから成功するのではなく、今後成功を収めたサービスが自然とWeb3の代表格と見なされると予測するわけです。 といってしまうのは、ちょっと「どっちもどっち論」が過ぎると思った。 確かに Web 2.0 にも明確な定義は無かった。Tim O’Reilly の What Is Web 2.0 (2005) の冒頭には、 But there’s still a huge amount of disagreement about just what Web

Twitter で議論をするのと、Excel を方眼紙にするのは似ている。道具には向き不向きがあり、なんでもを目の前にある見知ったソフトウェアですませるべきではない。 Twitter は議論に向いたソフトウェア/メディアとは言い難い。議論に巻き込みたいひとが使っている率が高いところは良いけれど、それ以外は、短文を投稿するメディアであるという人々の認識も、リツイートやお気に入りのような機能で外部から茶々を入れられるのも、こみいった話をするのに向いた場所とは言い難いと思う。 Excel を方眼紙にしない程度には分別のある人々が、Twitter で議論めいたものをしているのをみると残念に思う。議論というか、だれかのつぶやきにだれかが反論して、程度のことなんだけど、それを Twitter でやりだしたら、こじれないものがこじれませんか、と思ってしまう。 一方で、Excel 方眼紙をしている人には「

英語のほうに書いた通り、containerd コミッターになった。去年には会社でシニアエンジニアになれたし、直近の目標が二つ達成できて、一段落ついたように思う。 専門性 数年前に、キャリア近況 (2018) というのを書いた。当時の私は、自分の専門性の無さというのを気にしていた。 いまは結局、Linux とコンテナが専門になっている。containerd のような、一つのホストで動いて、ややレイヤーが低く、アプリケーションからちょっと距離のあるソフトウェアを良くしていく、というのは自分の好みにあっている。会社から給料をもらいつつ、仕事の成果をオープンソースにできて、個人名が出せるのも良い。 だんだんレイヤーが高くなって、プログラミングから離れてマネージャーとかになる人々とか、デジタル庁とかに関わって社会の矢面に立つ人々に比べると、あまりに趣味嗜好が若い頃から変わらなくて「好きなものはカレー

水島さんが Scalaの学習コストについての私見 で、 実際、Scala難しいならKotlinも難しいとなりそうなくらい両者は似ている……というより、KotlinはScalaの主要な機能をほぼ継承しているのですが、その辺りはJetBrainsのマーケティングが上手なのと、ライブラリの互換性を軽視しなかったこと、厳格な立場をとる人があまりいないこと、JetBrainsの政治がうまい辺りが主要因だろうなと感じています（これは悪口ではなくて、逆にLightbendの言語マーケティングが上手くなかったというのが正直な実感です）。 と書いていたけれど、マーケティング、互換性、コミュニティ、政治、といってしまうのは、言語も含めたソフトウェアそのものの違いを無視しすぎていると思うので、そういう話をします。 Kotlin と Mapped Types 以前に書いた、Kotlin のコレクションと Mapp

語らず作る ここ数年、語ることはまあまあ出来ている (ブログを書いている) けど、作ることができてないので、だんだん作ることの比重を増やしていきたい。 語らないことは目標というよりは副作用に近い。寡黙さへの漠然とした憧れはあるけれど、これは考えるとあまり理がない。面白いものを作って、それについて話せるのが一番良い。ただ、時間の配分としては作るほうをがんばりたい。 読まずに書く Twitter とかを見ていると「その話なら、おれにも言いたいことがあるぞ」ということが結構ある。でもこれは Duty Calls の一種で、あまり良くない。広いインターネットで、私がツッコめる程度にスキがあるひとは沢山いる。でも、それにツッコむことが自分の本来やりたいことであることは、あまりない。余暇の時間になんの問題を解くかを、他人に決めさせるべきではない。 これはすでにまあまあ出来てるので、継続していきたい。

小関さんが TikTokの発明：起動すると始まること (2018) で書いていたことだけど、フォローしている人々の投稿を時間順に表示する、昔の Twitter のようなシステムには、 人々が自分にあう人々をフォローして フォローされた人がフォローしている人の興味にあうことを投稿して 投稿は他の人々のものが流されてしまわないように、適度に流量が制御されていて 1 について人々の変化に応じて定期的に見直し、整理する という前提がある。1 と 4 は自分で頑張れるけど、2 と 3 は他人の働きへの期待だし、この全ての条件が満たされた状態は、滅多に発生しない。 なので、いまの Twitter も含めた運営側が、順番を並び替えたり、フォローしていないものを突然表示したりするのは、私は理解できてしまう。彼らも別に嫌がらせでやっているわけではなくて、全体を見て最適化したときに、人々の明示的に選んだ意思を

ここ2年くらい、仕事では大体 Go を書いている。jmuk さんが Go言語は、なんというか「ちょうどいい」言語だな、と思っている。異論は認める。 と書いていたけれど、私はやっぱり Scala や Kotlin あたりが好きで、これは変わらなそう。 例えばコレクションを map しているのをみると、私は「なるほど、ここではコレクションの要素数は変わらないんですね」と思う。filter だったら「コレクションの要素数は変わるけど、個々の要素は変わらないのか」ということを、あるいは Result を map していたら「ここではエラーのほうは触らないのね」ということを読みとっている。 こういう意図が、素朴な for ループと、if err != nil だと読みきれなくて、いや真面目に字面を追っていけばわかるんだけど、私が「map するか」と思いながら for ループを書いて、その for ル

Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値

ここ数年、仕事で JavaScript を書く機会がないのだけど、Error Handling in Node.js はコードレビューでよくリンクしている。 JavaScript 固有のところではなく、オペレーショナルエラーとプログラマーエラーを分けて考えましょうよ、というところが良い。日本語だとどう訳すんだろう? People use the term “errors” to talk about both operational and programmer errors, but they’re really quite different. Operational errors are error conditions that all correct programs must deal with, and as long as they’re dealt with, they

BPF というと、memcached を速くするとか、Ruby からコンパイルするとか、まず高度な話題を見かける2021年だけど、BCC についてくる色々なスクリプトを使うだけでも、色々とトラブルを解決できることがある。 opensnoop opensnoop は文字通りシステムで発行されている open(2) をリアルタイムに覗き見できるツールだ。 去年に containerd/cgroup でメトリクスが来ないバグを直したときには、そもそも最初はこのパッケージまで絞り込めてなくて、 なんかメトリクスが来ないんだけど… このメトリクスって /sys/gs/cgroup/blkio 以下のファイルから来てるんだよね? これって containerd 本体が読んでるんだっけ? 多分 shim のほうだとは思うんだけど… runc が読んでるってことはないよねえ? ファイルは読まれているけど、

ちょっと前に、他のチームの書いたものをセキュリティ的な観点でレビューする、という仕事があった。「SQL インジェクションはありませんか?」みたいなチェックリストを片目に AWS SDK で DynamoDB にアクセスするようなコードをレビューするのは、なかなか隔世の感があった。 私は2000年代の後半から2010年台の頭にかけて、いわゆる Web プログラマ仕事をしていて、Perl から MySQL に SQL を投げて結果を HTML に入れて返すようなものをよく書いていた。当時は SQL インジェクションとか XSS が、よくある脆弱性として語られていた。 この感じ、パブリッククラウドの SQL じゃないデータベースを使っている人々や、最終的には SQL になるけど基本的には OR マッパーを使っている人々、React で HTML を作っているような人々には伝わらないんじゃないかと

今年から、できるだけシェルスクリプトを書くのをやめようとしている。私が毎日 zsh に打ち込んでいるのも広義のシェルスクリプトだし、自分用の雑なスクリプトを書くことはあるけれど、チームの他の人も将来に使ったり改変したりするようなものは、なるだけ他の言語を使っている。 シェルスクリプトを書くのは難しいし、その難しさは、学ぶに値しないといったら言い過ぎかもしれないけれど、2021年に初心者が取り組むべき問題とは言い難いと思う。 シェルは悪いプログラミング言語である Bash Strict Mode とかを使ってみても、シェルスクリプトには落とし穴が多すぎる。自分で書いたものを自分で使っている分には大丈夫なのだけど、スクリプトがチーム内で使われるようになると、考慮していなかったところ、例えばファイル名に空白文字が含まれるとか、そういうレベルの微妙なところで、ちゃんと書かれていないスクリプトは壊れ

日本に住んでいたころの私は、いわゆる「政治的な正しさ」というのにあまり関心がなかった。とりわけ、最近のアメリカのドラマでは、主要な登場人物として黒人やアジア人を入れなくてはいけないのですよ、みたいな話を「それは窮屈な話だなあ」と受け取っていたように思う。本来は自由であるはずの創作に PTA 的な正しさを持ち込んできてうっとうしい。 そこから色々あって、アメリカに引越して、子供を育てる立場になった私にとって「政治的な正しさ」、とりわけメディアにおける人種や性別の構成というのは、結構切実な問題になった。自分の子供たちがアメリカ社会から受け取る印象というのを心配していて「アジア人も女性も、政治家にもポップスターにもエンジニアにも、主人公にもなれる人種なんですよ」というのをわかってほしいと思っている。 これは、私とその家族がここでは少数派になってしまった、ということから来ていると思う。 「アジア人

たまに Rust の勉強もかねて何かを再実装しようと思うんだけど、大抵は途中で飽きてしまう。一方で、最近に仕事で使っている雑なスクリプトをきれいに書き直して、これはなかなか楽しかった。というわけで、自分の中での楽しさを書き出してみようという試みです。 自分の生活が便利になった 仕事で書くスクリプトとか、個人的な便利コマンドとかはここの楽しさが大きい。 仕事で関わって製品としてリリースされるものが、自分の生活を便利にするかは、まあ半々くらい。「確かにこれあるといいですね。自分でも使います。」というものもあるし、正直いって自分は使わなそうなものもある。 コンシューマ向け製品だと、自分の好みはだんだんメインストリームとずれてきていて、それは将来に不安を感じる。携帯電話のプッシュ通知とか、なるべく来ないで欲しい。 無理そうなことが出来てかっこいい 昔に作っていた、SIMBL で Mac のアプリを

アンテナウェア (2003) や、アンテナ（Webサイト更新時刻自動取得システム）の歴史 (2006) にある程度はまとめられているものの、年月日とセットになった、教科書には載らないニッポンのインターネットの歴史ヽ(´ー｀)人(´ー｀)ノ形式のものが欲しかったので、自分で作ってみた。 Linux Diary Links や Ruby Hotlinks みたいな、アンテナのインスタンスについてもまとめたら面白そうだけど、そちらは大変そうなので、とりあえずはソフトウェアだけです。 1995/10/XX?: べんりくん、サービス開始 今日のさそり座（更新時刻取得ページ） 更新時刻取得Agentの元祖べんりくん。原作はかうぽんX氏。ぽくだい某音室の後輩いわくによって受け継がれて今にいたっている。 教科書には載らないニッポンのインターネットの歴史ヽ(´ー｀)人(´ー｀)ノ 藤井洋之氏のご指摘によれば

Firecrackerはコンテナランタイムなのかという話への返信および補足です。「コンテナラインタイムではない」という結論は このユースケースにおけるFirecrackerの立ち位置は、「runCをコンテナごとに隔離するための環境を作成」するためのVMプロバイダーになっている。 すでに出ているんですが、色々と補足したいことがあったので。 Firecracker は、コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する で定義されているような ランタイムの実装には様々なものがありますが、それらは役割に応じて下図に示すように高レベルランタイム（CRIランタイム）と低レベルランタイム（OCIランタイム）という2つのレイヤに分類されます。 Kubernetes の Container Runtime Interface (CRI) を実装した高レベルランタイムや、Open Conta

Rust には aHash という、x86 系の新しい CPU についている AES 暗号のための命令を使った、高速なハッシュ関数がある。これは hashbrown という Rust 向けの SwissTable 実装ではデフォルトになっていて、hashbrown は Rust 本体の HashMap の実装でもあるんだけど、そちらでは SipHash 1-3 がハッシュ関数として使われている。 という話を、英語ブログの方に書いた後に、ふと Ruby はどうなっているんだっけ、と思ったので調べてみた。 昔に趣味で Ruby, 仕事で Perl を書いていたころは「CRuby のソースコードはまあ読めるよねえ。でも Perl は謎のマクロが多くてまじできつい。」と思っていたんだけど、2020年に CRuby のソースコードを読むと、全体的にコメントが少ないのと、とりわけ昔のコミットのコミット

r7kamura さんのこのサイトの実装 2020年版に倣って、このブログの実装を書いてみる。 「サイト」じゃないのは、8-p.info は仕組みなどが似ていながらも別れているからで、それでいうと blog.8-p.info のトップにある目次ページも、別のシステムで動いている。今回は /ja/ と /en/ 以下の話です。 ホスティング S3 + CloudFront で静的ファイルを配信している。 Jekyll をはじめて使ったのは2011年だけど、当時の Makefile を確認すると、どこかの VPS の Nginx に rsync していた。S3 を使い出したのは Amazon に転職したあとの2013年なので、我ながらドッグフード1精神がある。 以前はS3 の静的サイトホスティングだけを使っていて、数年前に HTTPS 対応するべく、CloudFront を追加した。 ドメイン

セコンさんの心のざわめきを無くして日記を書くということ / secon.dev への移転が良くて、なにか書こうかと思っていたら、森井さんに先を越されてしまった。 過去のインターネットを懐かしむ話と、いやいや、いまだって大丈夫だよ、というのはここ最近よく見かける話題で、 If I could bring one thing back to the internet it would be blogs Rediscovering the Small Web The Return of the 90s Web 無料のホスティングを提供する Neocities から、href.cool や OMGLOAD といったリンク集、webring.xxiivv.com のようなウェブリングまで、少しの揺り戻しは来ているように思う。 これらがメインストリームになるとは主張しないけど、過去のインターネットにあ

今更になって、karino2 さんの F2戦役の思い出 シリーズを聞いた。大変面白かった。 私はこういう規模のデスマーチというのは体験したことが無くて、mixi プラットフォームは大変だったし、OpenSocial に国内3大 SNS (というのは mixi, DeNA, GREE のことです) が仕様を揃えてプラットフォーム化をする、というのは当時はなかなか大戦感があったけれど、多分携帯電話開発に比べたらだいぶ規模の小さい話なんだろうなと思う。他の会社に依存されたりはするけど、国とかは出てこないし、損害賠償とかもされていなかった、はず。少なくとも開発系のマネージャーが口にする単語ではなかった。 YRP というのは知識としては知っていて、多分これは 2ch の影響だろうと思う。 【軍曹が】携帯電話開発の現状【語る】 【軍曹が】携帯電話開発の現状【語る】(後半) あと、村上春樹的みずほ銀行と

最近 hitode909 さんが、ここ最近ドキュメントについて書いているのを読んで、 Creating Documentation in an Agile Scrum Environment チームのScrapbox3000ページくらいを見返して整理した The Product is Docs: Writing technical documentation in a product development group そういえば、Increment が Documentation 特集だった号 があったなあと思い出したので、読んでみた。 Increment は Stripe のやっている雑誌 (という話は2017年にも書いた)。もともとはオンライン雑誌だったのだけど、今は紙版も売っている。といっても Airbnb Magazine や Offscreen のように、実際に本屋で売っていた