はてなブックマーク

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

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

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 方眼紙をしている人には「

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

ここ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 とかを使ってみても、シェルスクリプトには落とし穴が多すぎる。自分で書いたものを自分で使っている分には大丈夫なのだけど、スクリプトがチーム内で使われるようになると、考慮していなかったところ、例えばファイル名に空白文字が含まれるとか、そういうレベルの微妙なところで、ちゃんと書かれていないスクリプトは壊れ

たまに 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

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 を追加した。 ドメイン

今更になって、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 のように、実際に本屋で売っていた

firecracker-containerd は、VMM の Firecracker を Docker などでも使われているコンテナ実行環境の containerd から使うためのソフトウェアだ。具体的には、Firecracker 上で Linux を立ち上げてから、その Linux の中でさらにコンテナを実行する、という動作をする。 私は2019年の7月から AWS で働いていて、firecracker-containerd の開発にも関わっている。Amazon で働くこと自体はもう7年になるけれど、オープンソースソフトウェアの開発が主な仕事になるのは今回が初めてだ。せっかくなので、これから数回に分けて firecracker-containerd の実装について説明したい。 Firecracker とは といっても「Firecracker なら手元の Linux にインストールして毎日