はてなブックマーク

大吉祥寺.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アプリケーションのパフォーマンスチューニングをしないといけなくなったけど、どこから確認して何に手をつけたらよいか分か

表題のことについて検証してみましょう。 目次 目次 前提 Webページ上で独自のフォントを読み込むには フォントファイルのサイズ フォントファイルのサイズを抑える工夫 フォントファイルを分割し、必要に応じて読み込む フォントファイルを圧縮する 前提おわり 本題 規格によると 4.5. Character range: the unicode-range descriptor 4.5.1. Using character ranges to define composite fonts 実験する 準備 実験方法 実験結果 まとめ 前提 本題に入る前に、Webフォントを配信する際の前提について説明します。分かっている方は読み飛ばしてもらって大丈夫です。 Webページ上で独自のフォントを読み込むには CSSの font-family 属性に使いたいフォント名を書くことで、Webページ上のコンテン

GitHubからPRのレビュー依頼通知が来たら、作業の手を止めてコードレビューに入る暮らしをしていた。PRがマージされるまでの時間が短くなるのはいいけど、コードレビューしすぎてしまう問題があった。自分の作業は回っているけど疲れるような、実はもっとパフォーマンスを出せるのか？ という感じ。先週ぐらいまではこういう状態だったけど今週はちょっとましになった気がする。 この問題に対してはいろいろなアクションプランがありそう。 通知にすぐ反応しない 通知を切る スヌーズする 集中タイムを作る コードレビューのコストを下げる レビューチェックリストを作って、機械的に判定してから本格的なレビューに入る CIでいろいろチェックしてコードレビューで見るべき箇所を減らす 短時間でレビューする 瞬きをしても集中は途切れないみたいなイメージ コードレビューしなくてもよい状態になる コアタイム外 (休憩時間や深夜な

いい本が出たと聞いたので買って、しばらく積んでいたのをついに読んだ。手は動かしていない……。 Reactハンズオンラーニング 第2版 ―Webアプリケーション開発のベストプラクティス 作者:Alex Banks,Eve PorcelloオライリージャパンAmazon 普段からフロントエンドアプリケーションを書いているけど、読んでみて網羅的な知識を再確認できたのでよかった。現代におけるReactコンポーネントの書き方にとどまらず、Reactの過去からSuspenseを使ったデータ取得といった実験的な技術まで教えてくれてありがたい。 Reactがどうやって動いているのか、脱糖したコードを手書きするところから始めて、このようにトランスパイルされます、と順を追って説明してくれるので、原理が気になる人も安心できるのではないか。日本語でReactに入門したいと聞かれたら最初におすすめする本だと思う。

はじめに みなさまはNext.jsで静的に生成するHTMLファイルを国際化したくありませんか? Next.jsに組み込みのi18n routingはStatic HTML Exportに対応していないので、別の手を考える必要があります。 結論から言うと、以下の記事にやり方が書いてあります。 dev.to この記事では、Next.jsでStatic HTML Exportで言語ごとのHTMLファイルを生成する方法と、ハマったところを簡単にまとめます。 手順 翻訳データを用意する public/locales/(言語)/common.json に翻訳データを用意します。ラベル→文言というJSONを置けばよいです。 { "hello": "こんにちは" } next-i18nextをインストールする Next.jsでi18next (react-i18next) を使えるようにするライブラリです

はじめに これははてなエンジニアアドベントカレンダー2021 14日目の記事です。昨日は id:Windymelt さんのFreeBSDのZFSファイルサーバ再インストールRTAはーじまーるよー - Lambdaカクテルでした。 作ったOSSライブラリ 筆者はpytest-github-actions-annotate-failuresという、GitHub Actionsで落ちたテストの行にアノテーションを出力するpytestプラグインを公開しています。2021/12/14 8:31現在、GitHubリポジトリのスター数は40ちょっとで、たまにバグ報告や機能要望のissueが立っており、これまで自作して公開したライブラリの中では一番使われていると思います。 このライブラリについて、詳しくは以前書いた記事をご覧ください。 blog.utgw.net 思うこと 作ったOSSライブラリがしばしば