はてなブックマーク

はじめに これははてなエンジニア Advent Calendar 2025 18日目の記事です。昨日は id:kouki_dan の毎日1コミットを続けて1年が経った - Lento con forzaでした。 id:utgwkk です。Goを書いていて、頻出のイディオムをもっと短く書きたい！ という欲求に駆られることがあると思います。そのような場面に出くわした人は、プロダクト内にちょっとしたコードを書いて便利に使うようになります。 今日の記事は、そうやってプロダクトのあちこちに登場する、ともすれば脚光を浴びることのないかもしれないコード片たちのことを思い出す、という趣旨になっています。 func Must[T any](T, error) T func Must[T any](x T, err error) T { if err != nil { panic(err) } return

参加しました。会社のパーカーを着て会場をふらふら歩いていたり*1、コーヒーを飲んでいたりしたと思います。 yapcjapan.org 印象的だったトーク・セッション なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える speakerdeck.com アプリケーションコードにおいては実装の詳細を隠蔽して処理を記述することが抽象化の目的であるのに対して、インフラコード (IaC) においては実装の詳細 (インフラ構成) を再利用可能にすることが目的であり、異なる目的に対して同じような考え方で抽象化を行うとうまくいかない、ということがうまく分析・言語化されていました。 「データ無い！ 腹立つ！ 推論する！」から 「データ無い！ 腹立つ！ データを作る」へ チームでデータを作り、育てられるようにするまで speakerdeck.com プロダクトの価

終業後、会社にインターン生が集まっている中で、確か id:Windymelt あたりと雑談していたと思うけど、なんやかんややっていたら「QRコード」「おみくじ」2つの要素が合体して、これは作ってみるしかないという流れになった。誰か詳しい経緯を覚えていたら教えてください。 0:22ぐらいに npm create vite でボイラープレートを用意して、 github.com 0:34ぐらいまでに、QRコードが高速に切り替わって読み取り結果でおみくじができることが確認されていそう。ReactでQRコードを描画するにはqrcode.reactというライブラリを使うと楽に実現できる。 github.com しばらく、Xやはてなブックマークのシェアボタンを置いていたけど、QRコードを読み取ってただちにシェアできたほうがいいだろう、ということで試行錯誤していそう。ハッシュタグつけるのに苦戦している様子

「筆者よりも真に賢いキャラクターを描写できない」みたいなことが昨今のAI技術活用にも適用されると信じていて、自分の底力を上げるのはいずれにせよまだ怠れないだろうと思っている。いつまでこの考え方で通用するかは不明— うたがわきき (@utgwkk) 2025年4月29日 筆者自身は生成AIの利用を否定するつもりはないです。必要な制約を満たした上で活用したらいいと思う。実際、生成AIによって生産性が上がっている様子を各所で観測している*1。信条として使わないというのもまた自由なので、否定できるものではないだろう。 その上で、生成AIが出した結果だから……と無条件に受け入れるのではなく、まず自分の頭で考えたり検証したりする、というのを自分は求めたい。結果の妥当性を評価するためには、その前提となる知識が欠かせないだろう。たぶん検索エンジンが台頭してきた頃*2にも同じことを言われていたんじゃないか。

はじめに これは はてなエンジニア - Qiita Advent Calendar 2024 - Qiita 14日目の記事です。昨日は id:ymse の compose.yamlはマージができるし、YAMLのtagでその挙動をコントロールできる - 風に吹かれても でした。 id:utgwkk です。来週末に韓国に行くことが決まりました。それはさておいて…… 先日 (12/8)、ISUCON14が開催されました。ISUCON14に参加したことの記録は以下の記事をご覧ください。 blog.utgw.net 話は変わりますが、みなさまはAWS Step Functionsを使っていますか？ 今日はISUCONの感想戦を支えるStep Functionsについてお話しします。 できたもの いきなりですが以下のステートマシンをご覧ください。どうですか？ できあがったものがこちらになります この

はじめに 表題のようなCLIツール aws-iam-policy-sim を書きました。 github.com 使い方 Statement フィールドに、以下のようなオブジェクトの配列が入っている、というJSONファイルを用意しましょう。 Action フィールドにアクション名もしくはその配列 Resource フィールドにリソースもしくはその配列 たとえば以下の通りです。うっすらお気づきの方もいると思いますが、実はポリシードキュメントのJSONがそのまま使えます。 { "Statement": [ { "Action": [ "s3:PutObject", "s3:GetObject", "s3:GetObjectTagging", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::example-bucket/*" ] }, { "Act

参加しました。 kaigionrails.org 普段の仕事では主にGo/TypeScript/Reactあたりを書いています。Rails周辺のぼんやりとした世界観は知ってるかも、ぐらいの立場です。 よかったトーク speakerdeck.com 推しVTuberのために匿名質問サービスを高速に作り、仲間を集める、という流れが非常に美しく、懐しさすら感じさせる発表でした。こういう勢いをたぶん失っているんだろうな、とも……。 speakerdeck.com どこのプロダクトでも長時間の非同期ジョブに悩まされているのだ、と知れて勇気づけられました。非同期ジョブの実装側でlong-runningなジョブを中断・再開できるようにする仕組みは面白かったです。一方で、ジョブをじゅうぶん小さな単位に分割して並列実行したのち結果をマージする、といった手法も考えられないか？ と思い、そのあたりを懇親会で議論

大吉祥寺.pmに参加しました。この記事の公開をもって吉祥寺からの帰還といたします。 登壇した speakerdeck.com タイトルは「君たちはどう生きるか」をモジりました。 コードレビューの目的は「コードの品質を保つこと」「知見を共有すること」である、という観点を踏まえ、自分がどのようにしてコードレビューに向き合っているか・向き合うべきと考えているか を話しました。発表後や懇親会などでポジティブな感想をいただいたり、コードレビューの難しさや向き合い方の話をしたりできて、自分が当初思い描いたよりもいい発表ができたんだろうな、と思っています。 実は、発表のテーマ自体はすぐ思いついたのですが、何をどう話すか・正解をどこに置くべきか など非常に悩みながら発表資料を作りました。弊社の人は知っているかもしれませんが、発表資料を一度レビューしてもらったあと、ほぼ全てのスライドを書き直して再構成してい

Go Conference 2024に参加し、登壇してきました。 登壇しました Dive into gomockというタイトルで発表しました。2トラックのどちらかで40分トークかな? と思っていたら2部屋ぶち抜きでトークだったのでビビっていました。 発表資料はこちらです。 speakerdeck.com gomockの内部実装を見て、なぜライブラリの内部実装を見るのがよいことなのか、という話をしました。reflectパッケージが好きなので合間にreflectパッケージの話もしています。つまり主題が3つあるわけですね。 gomockの内部実装を見よう リフレクションを知ろう なぜライブラリの内部実装を見るのか知ろう 今回はgomockの実装を掘り下げることで、魔法のように見えるイディオムの裏にある処理を知ろう、という方向性でやりました。今回の発表でgomockの内部実装を全員が完全理解できた

参加しました。前日祭や懇親会・アフターイベント・YAYAPCも含めて全て出席していました。 yapcjapan.org どの発表もおもしろく、全てについて詳細に取り上げるには紙面 (紙じゃなくない??) が足りないので、ピックアップ形式にさせていただきます。 とほほのWWW入門 キーノートが本当によかったです。ちょうど生まれたぐらいの頃*1からずっとインターネットで発信を続けられていて、まさにアウトプットの祖といえるでしょう。好きだから継続しているという話だったけど、しかしあの情熱は「好き」だけでは説明がつかないのでは?? 若者にじゃんじゃん来てほしい よく言ってるのですが、YAPCは学生支援制度が整っていて、学生でも交通宿泊費を気にせずに参加できるようになっているんですよね*2。YAPC::Japan運営ブログの方にも、学生支援制度を活用してくれ!! という趣旨のブログ記事を寄稿させてい

はじめに これは はてなエンジニア Advent Calendar 2023 の記事です。昨日の記事は id:onishi さんの ショートカット.app で遊ぶ - 大西ブログ でした。 アプリケーションエンジニアの id:utgwkk です。みなさまは知見に飢えていませんか? 今日は、知見がどんどん集まってくるところを見るために普段から心がけていることについてお話しします。 心がけていること 「サブ会」に出る 「サブ会」というのは以下のような取り組みです (会社のブログから引用しました)。 社内勉強会やはてなグループによる情報共有は日々行っていますが、より集中して取り組み、ときには具体的なタスクを受けもつ、技術的な競争力を持つエンジニアの小集団として（技術グループの）サブ会、というのを設けています。 はてなの技術組織2016 - Hatena Developer Blog 特定の技術分

tl;dr 表題のようなツールを作りました。go install コマンドでただちにインストールできます。 $ go install github.com/utgwkk/bulkmockgen/cmd/bulkmockgen@latest 従来の //go:generate コメントから移行するツールもあります。 $ go install github.com/utgwkk/bulkmockgen/cmd/mockgen-to-bulkmockgen@latest tl;dr 課題感 モックを使った開発と問題 mockgenのコード生成に時間がかかる //go:generate コマンドを1行で書くと人間に優しくない bulkmockgen mockgenから移行する ベンチマーク before (1つずつ生成する) after (まとめて生成する) bulkmockgenの制約 他の方針

あらすじ go test が出力するログはシンプルです。シンプルなのはいいんですがテストサマリ的な情報が乏しくて、ログを全部見返さないとどのテストが落ちたのか分からなくなりがちという問題があります。 tparseというツールを使うと、go test を使いつつテストサマリが見れるようになるので紹介します。 tparseについて tparseは、go test の出力をパースして人間に分かりやすいサマリを生成してくれるツールです。 github.com 最も簡単な使い方としては、READMEにあるように go test の出力をそのままパイプする (あるいは一時ファイルを経由する) ことで動作します。 % set -o pipefail && go test ./... -json | tparse -all # あるいは % go test ./... -json > fmt.out %

今どきlinterを使っていないプロジェクトなんて、と思われるあるかもしれませんが、歴史の長いプロジェクトだとそういうこともあるでしょうし、あるいは一部のDSLやスキーマ*1に対してのみlinterを走らせたいということもあるでしょう。 そういったプロジェクトに対してlinterを導入する前に、デフォルト設定でlinterを走らせたときにどういう出力になるのかを一通り眺める、というのをやっています。 どういうエラーがどこで何件出ているのか、warningなのかerrorなのか、linterのルールがプロジェクトにとって妥当なのか、一通り吟味した上で設定を調整してからlinterを導入するようにしています。なぜなら、linterのノイズが多いとlinterの言うことに従うモチベーションが下がる (と自分では思っている) からです。 最初からlinterが入っているなら、とりあえずlinter

GoでSQLを書いて実行するとき、素のdatabase/sqlだけだとさすがに心もとないのでsqlxなどのライブラリを使ってDBの行をstructにマッピングすると思います。db struct tagでマッピング元のカラム名を指定できるのが便利ですね。 一方で、このstructを定義する作業ですが、テーブルのカラムが多いと大変だし、typoしていたので直して再チャレンジする……ということが往々にしてあると思います。 こういうときのためにstruct定義を生成するツールを書いてみました。 go install github.com/utgwkk/rowstructgen@latest を実行したら使えるようになると思います。今のところMySQLにしか対応していません (普段はMySQLしか使っていないため)。main.goに全ての実装が書いてあってひどい感じなので、気が向いたらなおします。

sugarheart.utgw.net イベント支出記録君は、同人誌即売会などでの支出をすぐに記録するためのツール。プリセットに金額を登録しておけば、ワンボタンで支出を記録することができる。CSVダウンロード、TSV形式でのコピー、URLシェアなど、いろいろな方法でデータをエクスポートできる。 下にあるのは、先日のイベントでの自分の支出記録が確認できるURL。 https://sugarheart.utgw.net/event-expenses-tracker/#3AAtzwAAAYeIkjSMzQH0oM8AAAGHiIwcRM0B9KDPAAABh4iIiQ3NAligzwAAAYeIhB9GzQH0oM8AAAGHiEjof80B9KDPAAABh4hGZ8LNA+igzwAAAYeIRHAXzQH0oM8AAAGHiELJ080B9KDPAAABh4hAf3jNASygzwAAAY

久しぶりのオフライン開催であるYAPC::Kyoto 2023に参加しました。 前日祭見た 前日祭にも参加して、RejectConと東西対抗LTバトルを見ました。みんないい話をしていて、かつ、なんだかついにYAPCが始まったのだな、という感慨がありました。 その後のHelpfeelさん主催の飲み会では、席を詰めまくった結果dankogaiさんの隣に座っていろいろ話していておもしろい感じでした。 トークした 「prototype大全」というタイトルで発表しました。発表スライドはSpeakerDeckで公開しています。 speakerdeck.com 誰もPerlのprototypeに特化した話をしていないのでは？ というのが発表のモチベーションでした。もはや業務ではPerlを書いていないのですが、Perlのこういう言語機能によって表現力が広まっている、というのを伝えたかったです。 一方で最近

tl;dr キーワードは「monotonic clock」です。 あらすじ Goで以下のようなコードを書いていた*1*2。あるAPIを叩くクライアントで、APIコールに必要なアクセストークンを4時間キャッシュしている。c.getToken() で得られたトークンを使ってAPIコールを行えばよい。 type Client struct { mu sync.RWMutex expiresAt time.Time token string } // トークンのキャッシュがあればキャッシュから返し、なければ更新してから返す func (c *Client) getToken() string { if cachedToken, ok := c.getTokenFromCache(); ok { return cachedToken } return c.refreshToken() } // トー

これは Perl Advent Calendar 2022 13日目の記事です。昨日の記事は Perlで戻り値として呼び出した子サブルーチンのコンテキストは親と同じ - hogashi.* でした。 perlcriticは、Perl向けのlinterです。詳しくは以下の記事などを参照してください。 blog.utgw.net perlcriticの組み込みポリシー*1の1つに Subroutines::ProhibitBuiltinHomonyms があります。これは、Perlの組み込みサブルーチンや予約語と同じ名前のサブルーチンの定義を禁止するポリシーです。podから引用すると、以下のようなサブルーチン定義がポリシー違反だとみなされます。 sub open {} #not ok sub exit {} #not ok sub print {} #not ok sub foreach {}

これは React Advent Calendar 2022 7日目の記事です。 Recoilを使っているアプリケーションでWebpackのDefinePluginを使って環境変数の値をビルド時に埋め込むとき、Webpackの設定によっては環境変数の名前がビルドしたコードに含まれてしまう場合があります。 具体的には、以下のようにDefinePluginの process.env キーに対してobjectを渡す場合に発生しえます。 new webpack.DefinePlugin({ 'process.env': { FOO: JSON.stringify(process.env.FOO), }, }); ここでRecoilのコードを見てみましょう。ランタイムに process.env の値を参照するコードがあるのに気づくと思います。 github.com optional chaining

今年も id:nonylene id:wass80 と出場しました。最終スコアは50,696点で予選突破できました。分析基盤 (Kibanaやプロファイラ) に流れてきたデータを見つつ作戦を立てて実装する、という流れがうまくはまって順調にチューニングを進められたのがよかったと思います。 最終的なサーバー構成 isuports-1 App (Go) nginx isuports-2 DB (MySQL, player_scoreのみ) isuports-3 DB (MySQL) やったこと リポジトリはこちらです。 github.com 分析基盤まわりの話を id:nonylene が書いてくれたので、こちらもあわせてどうぞ。 nonylene.hatenablog.jp id:wass80 視点の記事もあるので、こちらもあわせてどうぞ。 memo.wass80.xyz テナントごとのDBを

「適切な変更の粒度」について考えることが増えたので、考えていることを流しておきます。 関連する変更がまとまってると嬉しい 1つのPRでついでにやらない、という話は以前もブログに書いた。コードレビューする側に立っても、このPRでやりたいことが何なのか、目的が達成されている (あるいは未来に達成可能である) かが明瞭だとレビューしやすい。 blog.utgw.net 自分は厳密なConventional Commitsはやってないけど、まず土台を用意して、機能を実装して、ちょっと足りないケースを修正する、みたいな感じで、すくなくともcommit単位で追ったら何がやりたいのかは分かるように気をつけているつもり。 小さければ小さいほどよい、とは限らない 1ファイルずつ、1行ずつ変更していったらそれは差分が小さくなるけど、差分が小さければ小さいほどよい、という話ではないと思う。要はバランスです。 こ

達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon レビューに参加した「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」*1をご恵贈いただきました。実物が届いたときの感想は「思ったよりも分厚い」でした。 個人的には、ベンチマーカーの書き方の付録 (章ではない！！) が、新鮮な知識が得られるという感じでよかったです。ベンチマーカーに求められる性質や、Go言語を使ったベンチマーカーの実装パターンなど、ISUCONに競技者として参加するだけではなかなか得られない知識が詰まっています。 ISUCONだけでなく、実務でWebアプリケーションのパフォーマンスチューニングをしないといけなくなったけど、どこから確認して何に手をつけたらよいか分か