はてなブックマーク

Go 1.27でnet/http/httptestにhttptest.NewTestServerが追加されました。 httptest.NewServerと名前はかなり似ていますが、実際にAPIクライアントのテストで使ってみると、テストコードがシンプルになるだけでなく、これまでテストできなかった箇所までテストできるようになる変更だと感じました。 自分がメンテナンスしているnotify_slackでもhttptest.NewServerからhttptest.NewTestServerへ変更したので、そのときに分かったことをまとめます。 これまでのAPIクライアントのテスト notify_slackではSlack APIを呼び出してファイルをアップロードしています。 例えば、ファイルのアップロード先を取得するAPIとして以下のURLを使っています。 var filesGetUploadURLEx

GenRec：Netflixが目指すLLMネイティブな推薦システム 元記事：GenRec: Towards LLM-native Recommendation at Netflix 概要 NetflixのGenRecは、ユーザーの視聴履歴や作品情報を自然言語へ変換し、Netflix向けに追加学習したLLMで読み取ったうえで、Netflixのカタログ内に存在する作品だけをランキングする推薦モデルです。 名前から想像されるような、「LLMにおすすめ作品名を文章として生成させる方式」ではありません。 実際には、LLMを巨大な履歴・文脈エンコーダーとして利用し、その出力にカタログ限定のスコアリングヘッドを接続しています。 推論時にはトークンを逐次生成せず、vLLMのprefill-only推論によってプロンプトを一度だけ処理し、得られた内部表現から候補作品をまとめて採点します。 つまりGenRec

全体像 この記事は、数学組版を「文字入力」ではなく、抽象的な知識を二次元平面へ配置するデータ可視化・工芸・アルゴリズムの複合領域として捉え、その技術史を活版印刷からTeX、LaTeX、PDFまでたどる論考です。 中心的な主張は次のとおりです。 数式は通常の文章よりもはるかに多次元的で、文字種・サイズ・上下配置・罫線・余白を組み合わせる必要がある。 印刷技術の歴史は、単純な高速化ではなく、人間の職人的判断をどこまで機械やアルゴリズムへ移せるかという歴史だった。 Donald KnuthのTeXは、単なる文書作成ソフトではなく、活版印刷時代に蓄積された組版技術を数学とプログラムによって保存したものだった。 現代は出版コストがほぼゼロになったため、次の課題は高速化ではなく、むしろ意図的に摩擦を増やし、考える時間を取り戻すことにある。(Practically Efficient) なぜ数学組版は難

以前、以下の記事を書きました。 今回はその補足のような話です。 ただし、この記事だけ読んでも分かるように書きます。 開発環境やCI/CDでは、外部通信を見られることが重要です。 どのプロセスが動き、どのファイルに触り、どこへ通信したのか。特に、package install中に普段とは違う通信が発生したり、credentialに触った直後に外部へ通信したりする場合、それを後から追えることには意味があります。 このあたりの話は、今後Podcast「八百万のOSS」でも扱っていきたいと思っています。 一方で、Web全体の流れを見ると、これまで企業ネットワークやCI/CD環境が便利に使ってきた観測点は、少しずつ弱くなっていきそうです。 特に大きいのがDNSとSNIです。 これまで、HTTPSの中身は暗号化されていても、DNS問い合わせやTLSのSNIを見ることで、どこに通信しようとしているのかは

RFC10008のQUERYは、GET bodyやPOSTでの参照リクエストを置き換えるための即効性ある互換性対策というより、「bodyに問い合わせ内容を入れられ、かつHTTPレベルでsafe/idempotent/cacheableだと分かる参照用メソッド」を標準化するための仕様です。 GraphQLのように、実務上は参照系queryも含めてPOSTに寄せているAPIは、RFC10008が解こうとしている問題の中心にかなり近いです。ただし、RFC10008本文がGraphQLを名指ししているわけではありません。 RFC10008が解こうとしている問題 従来の選択肢にはそれぞれ欠点があります。 GETはsafe/idempotentでHTTPキャッシュとも相性がよい一方、問い合わせ条件をURIに載せる必要があります。複雑な検索条件、GraphQL document、variables、SQ

最近のサプライチェーンアタックを見ていると、これまでとは明らかにフェーズが変わったと感じています。 この記事は、具体的な解決策を提示するというより、最近のサプライチェーン攻撃を見て、自分が開発環境やCI/CDについて考えていることを整理したものです。 以前の攻撃は、どちらかというとコンピュータリテラシーがそこまで高くない人を狙うものが多かったと思います。怪しいメールを開かせる、怪しい添付ファイルを実行させる、偽サイトに認証情報を入力させる、というようなものです。もちろんそれらも深刻ではありますが、少なくとも「気をつける」という個人の努力である程度防げる余地がありました。 しかし最近の攻撃は、明確に開発者を狙っています。 開発者は、一般的な業務利用者よりも強い権限を持っていることが多いです。GitHub token、npm token、SSH key、cloud credentialなどを持

Let’s Encryptの短期証明書は、90日証明書の延長くらいの感覚で入るとかなり厳しいです。 サブドメインを含む複数の証明書を短い間隔で発行・更新する構成では、証明書発行まわりのレート制限に引っかかりやすくなります。短期証明書では更新回数が増えるので、その影響がかなり表面化しやすくなります。 まずステージング環境で試した方がよい 開発やテストでは、本番ではなくステージング環境を使った方がよいです。本番と同じ種類の挙動をかなり緩い制限で試せるので、証明書の切り方や更新方法を確認する段階では先にこちらを使う方が安全です。 環境 ACME directory URL 短期証明書はレート制限に当たりやすい 短期証明書は有効期限が160時間しかなく、Let’s Encryptは3日ごとの更新を勧めています。90日証明書より更新回数が大きく増えるので、レート制限に当たりやすくなります。 特に厳し

最近のWebサービスでは、画像配信の設計を昔のままにしておくのは難しくなっています。 以前は、画像をアップロードした時に固定サイズのサムネイルをいくつか生成し、それをそのまま配信する形でも大きな問題はありませんでした。しかし今は、高精細なディスプレイを持つスマートフォンが一般的になり、同じ画像でも表示環境に応じて適切なサイズやフォーマットを選ぶ必要があります。さらに、CDNや画像最適化サービスを使えば、元画像から必要な派生画像を動的に生成してキャッシュできるようになりました。こうなると、画像配信は単なるフロントエンドの都合ではなく、サービス全体の設計の一部として考える必要があります。 私が重要だと考えているのは、次の4点です。 画像の綺麗さにおいては、qualityよりも画像サイズの方が重要であること 画像URLの設計はフロントエンドではなくバックエンドが握るべきであること 同じ画像に対し

発表資料 自己紹介 本名：金子達哉 株式会社PR TIMES PR TIMES事業ユニット 第一開発部長CTO 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践（技術評論社）（通称：ISUCON本）の著者の1人 6章「リバースプロキシの利用」・7章「キャッシュの活用」・8章「押さえておきたい高速化手法」を担当 catatsuyのIDで各種SNSにいます ISUCON練習用のprivate-isuや、GoのCLIツールとしてsed/grep代替のpurl、Slackにいい感じに投稿するnotify_slack、大量のファイルのリストを出せるlls、ChatGPTやGemini APIを手軽にCLIで利用できるbentoなどのOSSを趣味で開発・メンテナンスしています この資料について この発表資料は、私が著者として執筆したISUCON本の「キャッシュ」に関する内

私はMySQLが好きです。長く使ってきましたし、オンプレミスでの運用もやってきました。 しかし現職に来てからは、PostgreSQLを使う機会が増えました。最初は正直かなり抵抗感がありました。ずっとMySQLを使ってきたので、慣れの問題もありますし、PostgreSQLに対して必要以上に構えていたところもあったと思います。 ただ、実際に使っていくうちに、PostgreSQLの良さが少しずつ見えてきました。最近では、新規開発でどちらを選ぶかと聞かれたら、PostgreSQLを選びたいと思うようになっています。 私はMySQLを長く使ってきたので、昔のMySQLの雑さも知っています。ただ同時に、今でも昔の印象だけでMySQLを語るのは不正確だとも思っています。sql_modeをきちんと設定すれば危ない挙動の多くは避けられますし、MySQL 8でかなり多くの機能が入りました。 また、今回はオンプ

1) S3の“外から見える単純さ”と“中の現実” S3がユーザーに見せている基本操作は極端にシンプルで、会話でも繰り返し「put/getが心臓」と言っています。ところが中では、 数百万台規模のサーバ／数千万台規模のドライブ 38リージョン・120AZ 500兆オブジェクト・数百EB 毎秒数億〜数億超のトランザクション（発言上 “hundreds of millions TPS”） という“常時故障が起きて当たり前”の世界で、しかもユーザーはそれを意識せず「ただ動く」を期待する。 このギャップを埋めるために、S3は データプレーン(put/get)とは別系統の、耐久性・修復・監査の宇宙（多数のマイクロサービス）を常時動かし、故障を「例外」ではなく「前提」として扱っています。 2) 強整合(Strong Consistency)を“ほぼ一夜で”ロールアウトできた理由の分解 会話で出てくる「re

Google CloudのMemorystore for Memcachedがdeprecatedになり、最終的にサービス終了します（2029年1月31日終了、2027年2月1日以降は新規プロジェクトで新規作成できない、などの制限が入ります）。マネージドサービスから消えると「memcachedは古い」と思いやすいのですが、私はそう単純ではないと思っています。 memcachedは、用途が噛み合うと今でもかなり強いです。ここでは「memcachedのどこが良いのか」と「どこを割り切るべきか」をまとめます。 memcachedの良さ マルチスレッドで高スループット・機能がシンプル memcachedはマルチスレッドで高スループットを出せます。実績が多く、挙動が安定しているのも良いところです。 キャッシュ用途で必要な機能は揃っていますが、命令がシンプルで、基本的に状態を持たない操作しかありません

最初に三行まとめ サムネイル画像のURLはフロントエンドで組み立てず、バックエンドで生成して返す 理由は「後方互換性」と「CDNキャッシュ効率」 画面サイズ最適化はJavaScriptの計算ではなくpicture/srcsetでブラウザに選ばせる 最近はサムネイル画像を静的に全パターン作るより、変換を動的に行い、CDNでキャッシュしていく設計が一般的になってきました。すると「画面サイズはフロントエンドが知っているのだから、JavaScriptで最適なwidthを計算してURLに付ければいいのでは？」という発想が出てきます。 しかし、この実装は明確に危険で、やってはいけません。画像URLの生成はバックエンドで行い、フロントエンドは返ってきたURLを表示するだけにするようにしましょう。 ちなみに画像変換やCDNの活用方法について詳しく知りたい方は自分が以前書いた以下の資料がおすすめです。 なぜ

Takumiのオープンソース開発者応援プログラムに選ばれて、Takumiを3ヶ月無料で利用できるようになったので、現在試し中です。 Takumiはソースコードをしっかり読んでセキュリティの問題を見つけてくれるAIで、指摘内容がしっかり読まないと理解できないような報告である点が非常に好印象です。一方で、今回診断してもらったrepoはCLIツールなので、Webアプリ前提の助言が刺さらない場面が多くありました。 また修正方法までは出してくれない（簡単な変更は出してくれることはある）のは少し惜しいと感じています。言いたいことは分かるが、実際どうすれば解決するのか、という点は自分や他のAIに考えてもらう必要がありました。 使いどころがうまくハマれば十分役に立つし、運用と組み合わせると良さそうな印象です。以下でよかった点と気になった点を紹介します。 よかった点 ソースコードをじっくり読み、観察結果をレ

Go Conference 2025発表資料 自己紹介 本名：金子達哉 株式会社PR TIMES PR TIMES事業ユニット 第一開発部長CTO 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践（技術評論社）（通称：ISUCON本）の著者の1人 6章「リバースプロキシの利用」・7章「キャッシュの活用」・8章「押さえておきたい高速化手法」を担当 catatsuyのIDで各種SNSにいます ISUCON練習用のprivate-isuや、GoのCLIツールとしてsed/grep代替のpurl、Slackにいい感じに投稿するnotify_slack、大量のファイルのリストを出せるlls、ChatGPTやGemini APIを手軽にCLIで利用できるbentoなどのOSSを趣味で開発・メンテナンスしています 新作としてソースコード改竄検知ツールkekkaiをGoで開発

以前SNIや検閲について以下の記事を書きました。 この記事はその続編としてEncrypted Client Hello (ECH)の現状と展望を整理します。何か誤りがあれば教えてもらえると非常にうれしいです。 ESNIからECHへ 以前の記事では韓国政府によりESNIがブロッキングされたことを紹介していましたが、その後に中国政府からもESNIがブロックされました。これによりESNIの標準化が事実上中止され、その後ECHの標準化作業が開始されました。 ESNIの問題点はESNIを利用していることが検閲側から分かってしまうことでした。そこでClientHello全体を暗号化し、既存のClientHello (Outer)にダミー拡張を加え、真のClientHello (Inner)を暗号化して送信する仕様に進化しました。 ブラウザ側はencrypted_client_hello拡張を常に付与す

古いGoのコードが腐ったという話を聞いて、状況はよく分かりませんが、そんなことは基本ないので安心して欲しいという話を書きます。 2行まとめ 一般的なアプリケーション（cgoやHTTPやgoroutineの細かい挙動に依存していない限り）であればGoは古いコードでも動くはず ただし依存先のコードが消えていたり、非互換な変更が入っていたら動かなくなるので、動かしたいならvendorディレクトリ以下にソースコードを入れて完全固定するべき Goは非常に互換性が高い言語 Goはversion 1のリリース以降、互換性を維持しており、コードが動かなくなることは基本的にありません。 実はGo 1.22で初めて非互換な変更（forループの変数を毎回生成する変更）が入りましたが、これにより問題が出るのは、もともとバグがあったコードである可能性が極めて高いです（少なくともGoogle社内で見つかった非互換なコ

SNSなど、ユーザー名をURLに含めているサービスは色々ある。このZennもそうだ。ただ、考えることが多い。例えば以下の点だ。 システムで使いたい文字列をユーザー名に使われる可能性があるので、ユーザー名に使えない膨大な文字列のリストを管理する必要がある 実装に失敗すると、一部のユーザーだけ特別扱いするルーティングを独自実装する必要が出かねない 簡単な対応策としては /user/{ユーザー名} のようなURLの規則にすること これを採用しているサービスもあるが、見た目がダサいからか、あまり好まれていない印象がある ということで、現実的な解決策として @user_name みたいな@始まりのURLにする方法がある。 自分が知る限り、最初にこれをやったのはMediumだが、Mediumは現在サブドメインにするルールになったようで、いつの間にかこの形式を辞めてしまった。 実はTwitter（現X）

個人的にはビッグニュースなのに、あまり話題にしている人がいなかったのでメモ的に書いておきます。 nginxは最近開発がGitHubに移ってから、開発が活発になっており、以前から期待されていたupstreamでresolveを指定する機能がOSS版でも使えるようになりました（有料版では以前から使えていた）。 今までの問題 nginxのproxy_passにドメインを指定すると、起動時に名前解決が走り、その後はずっとそのIPアドレスに対してproxy_passされます。よってDNSが更新されても古いIPアドレスにリクエストが行く問題がありました。 その状態で直したい場合はreloadすればまた名前解決されるので、reloadするくらいしかありません。 reloadをせずにDNS更新を反映させる方法としては、以下のように一度変数にsetするという荒技もありました。 resolver 8.8.8.

ISUCON向けにGoのcacheライブラリを作成しています。 このライブラリは、ISUCONのように高パフォーマンスが求められる場面での利用を想定し、次のような経緯で開発を始めました。 以前は、キャッシュ用のコード片をコピーして微調整しながら使っていましたが、最近のGoのアップデートにより、状況が大きく改善されました。Genericsが一般的に使えるようになり、型ごとにコードを修正する必要がなくなったほか、deferのパフォーマンス問題もほとんど解消されています。こうした背景から、よりシンプルかつ効率的なキャッシュライブラリが作れると考え、次の方針で開発に取り組みました。 Genericsを活用して型安全かつ柔軟なキャッシュ機能を提供 標準ライブラリのみを使用して依存関係を最小限に 実際の利用を想定したシンプルで効率的な実装 使い方は以下で紹介しています。 この記事では日本語で簡単に使い

ISUCONの練習で過去問を用意しようとすると、repoが壊れていてセットアップできなかったり、セットアップできても諸々バージョンが古すぎてつらい、とかが起こりがちです。 ということでISUCON練習用に自分がメンテナンスしている問題があるので紹介します。何か問題があったらPRを送ってくれればベストエフォートで見るつもりなので何かあったら教えてください。 いずれも詳しい使い方は各repoのREADMEに書いてあるので参照してください。 private-isu 気付いたらISUCON練習用のデファクトスタンダードになっていて、ISUCON本の題材にもなっています（私はISUCON本の著者の1人です）。CIも整備されて、現在も精力的にメンテナンスをされています。 元々新卒研修用に作られたので、難易度は本家ISUCONより低めですが、ISUCONのエッセンスはふんだんに取り入れられているので、I

タイトルの通りです。 自分はnginx（最近はfreenginx）を趣味で運用しています。そこでLet's Encryptで証明書を作成してTLSを有効にしています。 これまではOCSP staplingを有効にしていましたが、Let's Encrypt側がOCSP staplingのサービスを停止しました。 元々OCSP staplingは失敗したから何か問題が起こる仕組みではない（だからこそ廃止されたわけですが）ので、このまま放置してもいいと言えばいいですが、nginxのエラーログが地味に埋まるし、動かない設定を残しておくのも健全ではないので削除するべきでしょう。 ちなみに自分のサーバーではそれまで出ていなかった以下のエラーが2024/07/20 17:35:15 JSTから断続的に出るようになりました。 2024/07/20 17:35:15 [error] 98574#98574:

使い方は柔軟ですが、自分が使っている方法を紹介します。 まず環境変数OPENAI_API_KEYにChatGPTのAPIのtokenをセットします。 ~/.gitconfigに以下の設定を足します。 [alias] sb = !git diff -w | bento -branch -model "gpt-4o" sc = !git diff -w --staged | bento -commit -model "gpt-4o" git sbでブランチ名推薦、git scでコミットメッセージ推薦をしてくれます。-modelでモデルを指定できますが、精度や速度の問題でgpt-4oがおすすめです。 色々使った結果、実際にGitのフローで使う場合、以下のことを考える必要があります。 ブランチ名を作りたい時はaddする前 新規ファイルは特に自動生成のファイルだとかなり大きくなることがあり、そういう

先日以下の記事を書きました。 ここでUTF-8の最初の文字かどうかの判定を以下の自作した関数で実装していました。 const ( t1 = 0b00000000 tx = 0b10000000 t2 = 0b00000110 t3 = 0b00001110 t4 = 0b00011110 ) func isUTF8LeadByte(tmp byte) bool { if tmp&tx == t1 { return true } tmp >>= 3 if tmp == t4 { return true } tmp >>= 1 if tmp == t3 { return true } tmp >>= 1 if tmp == t2 { return true } return false }

作りました。 Go製です。 何で作ったのか、どういう機能があるのか簡単に紹介します。 これまでの課題 sedやgrepには以下の問題があります。 正規表現の記法がPerl互換ではなく、使いにくい sedはmacとLinuxで互換性がなく（BSDとGNUで互換性がない）、OS依存のコードになりやすい これまでその問題を避けるために私はPerlのワンライナーを利用してきました。Perlは正規表現が使いやすく、柔軟な指定もできます。OS依存にもなりにくいです。しかしPerlには以下の問題がありました。 最近のmacやLinuxにはデフォルトでinstallされていないので使いにくい 特にDockerのようなコンテナ環境は顕著 最近は利用例が減っているので敬遠されがち ワンライナー専用ツールではないのでオプション名がわかりにくい そこで以下のツールを求められていると思います。 Perl互換の使いや

TechFeed Experts Night#21 発表資料 自己紹介 本名：金子達哉 株式会社PR TIMES開発本部長CTO 2021/4入社 達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践（技術評論社）（通称：ISUCON本）の著者の1人 6章「リバースプロキシの利用」・7章「キャッシュの活用」・8章「押さえておきたい高速化手法」を担当 ISUCON9予選・ISUCON6本選運営 今年のISUCON13はアドバイザーとして運営に関わります catatsuyというIDで各種SNSをやっています かたついと呼ばれることが多いです 本発表の対象者 ISUCON本は既に読んでいて、実際にCDNを活用して高速なWebサービスを提供したい人 初心者向けの一般論の話はしないので、一般論を知りたい方はISUCON本を読むのがおすすめです ISUCON本で紹介されていな