激安HDMIキャプチャーボードを買ってから、ときどきゲームプレイの録画・配信をしている。OBS Studioというソフトウェアがデファクトらしく、自分もこれを使っている。 便利なことにOBSにはWebSocketで操作できるインタフェースがあり、JavaScriptやPythonからかなり自由に操作することができる。となればソフトウェアエンジニアとしてはプレイログを構造化して残したいわけ。 WebSocket経由でスクリーンショットも随時取得できるので、画像を分析することでたとえばシーン判定はできるが、さらに詳細な情報を取ろうとするとテキスト情報もほしい。クラウドサービスなどに金をかけずに手軽にやるならTessaract一択となるが、素晴らしいソフトウェアではあるものの期待する精度を出すには工夫がいりそう。具体的には、ポケモンの名前は日本語だけでなく中国語の場合もある（左下の「古劍豹」）。

こうしてます。 git for-each-ref --merged HEAD --no-contains HEAD 'refs/heads/**' --format '%(refname)' \ | while read s; do echo "$s $(git rev-parse "$s")"; git update-ref -d "$s"; done git branch を使ったやり方が一般的なようだが（Google調べ）、配管（Plumbing）コマンドを使って厳密にやるならこうでしょう。 git for-each-ref はリポジトリのrefを一覧するコマンド。refs/heads/** はいわゆるローカルブランチにマッチするパターン。--merged HEAD で現在のブランチであるHEADにマージ済みのブランチを、--no-contains HEAD でそのうちHEADを除い

Go言語でテストを書く際のベストプラクティスとして、テーブル駆動テスト（Table dirven tests） というのが推奨されている。ようはデータとふるまいを分離しましょうという話で、正直わざわざ名前をつけるようなものでもなかろうという気持ちもないではないが、まあ話がはやくていいね。 けどみんなほんとにこれで満足してるの？ と疑問に思うところはある。テストが落ちたときに表示される行番号がテストケースによらず一定で、どのテストが落ちたのかを探すのに一手間かかってしまう。 たとえば以下のコードをテストする際、 package eg import "testing" func TestExample(t *testing.T) { testcases := []struct { name string a, b int sum int }{ {"1+1", 1, 1, 99}, {"2+2"

まだ汚れを知らない若者だったころに「プログラムはね、これを使って書くんだよ」と言われて以来Vimは友達だと思ってずっと（15年くらい）使ってきたが、最近は、とくに新しく何かを書くときにはVSCodeを使うようになってきた。コードを書く間隔が広がってきたせいか、新しい技術や言語に対応することができておらず、なんか最初からいい感じになってるエディタを重宝する。歳を取ってきたからなんだろうな、と素直に思うけれど、自分向けになにかをカスタマイズすることにあまり熱を感じなくなっていて、すでにあるよいと分かっているものに自分を調整していくことを選ぶようになってきた。 とはいえ身体はVimに慣れきってるのでVSCodeを使い始めたときはVSCodeVimを使っている……いた、というのが今回の話。よくできてるとは思うが、とにかくu（アンドゥ）の挙動が本家と違うのがどうも身体に合わない。逆にストレスが高まっ

meishi2キーボードを作ったのち2年ほどかけてErgoDashを完成させたのだけど、使ってみるとめちゃくちゃ使いづらく、Column Staggeredなレイアウトは自分に合わないということがわかった。検分してみるとQを薬指で打っていたりと、指使いの癖があるらしい。わざわざ矯正しようという気は起きないので、やっぱり使い慣れたHappy Hacking Keyboardに近い配列で、あらためて分割キーボードを作ってみることにした。分割キーボードは肩こり予防への祈りである。 HHKBに配列を寄せている自作キーボードのキットは世の中にいくつかあるようだけど、ここでは7sProを組み立てることにした。なぜならビルドガイドがはてなブログに書かれており、信頼できると感じたからだ。ページが長くて初心者としては圧倒されるが、実際にやるべきことは思ったより少なくて非常に組み立てやすかった。キースイッチも

ハッピーホリデー！ これははてなエンジニアアドベントカレンダー2022の 25 日目の記事です。昨日は id:yutailang0119 の WEB+DB PRESS Vol.132 特集2 「iOS 16最前線」に寄稿しました #wdpress でした。海賊スタイル、いい命名ですね。 さて掲題の通り、2022 年は毎週ブログを書くぞ、と年初にゆるく決意していたのだけど、これがだいたい達成できたようなのでふり返ってみる。だいたい、というのは本当にだいたいで、風邪をひいていた週、登壇した週、あと肉体的にめちゃくちゃ疲れていた週は普通に休んでしまっている。それ以外にサボりはなかったので自分の中では毎週です。 なんで毎週書くことにしたのかはもう覚えていないけれど、会社ではエンジニアのみんなに「オープンネスを大切にしよう。知識や経験を周囲に共有していこう」という話をしている割に、自分が実践できてい

低レイヤを知りたい人のためのCコンパイラ作成入門 まさに低レイヤのことが分かっておらず、以前から気になっていたこの本。取り掛かってみたところ思いのほかスイスイ進められて、勢いに乗ってセルフホスト（自分が書いたコンパイラで自分自身をコンパイルするところ）までいけたので記念に書いておく。正確には C コンパイラのサブセットです。 GitHub - motemen/mocc 全体的な進め方は、 上記の本の通りに進めていく。 それ以降は自作の 8queen が普通に書けるように機能を強化。 それ以降はセルフホストを目標に進める。 プリプロセッサやリンカは作らず、C からアセンブリまで。 という感じ。自分は手を動かさないと進んでる気がしないので、まずは書いてみつつわからない所があれば調べる、というスタンスでいく。 あと、せっかくなので RISC-V の勉強もしたかったのでこれ向けに書く。なので実行は

いろいろ工夫した結果、最近 Chrome さばきが良くなってきた気がするので、やっていることを書いておく。 タブが必要になる時刻でグループ化しておく 忙しい一日の予定を立てる際に、あらかじめ必要な資料・会場をタブで開いて時刻を打っておくと便利。終わったらまとめて閉じることもできる。 Chromeのタブを必要になる時刻でグループ化しておくライフハック pic.twitter.com/P8RQLy7h9K— 美顔器 (@motemen) 2022年8月22日 ページのブックマークタイトルを自分用に変更する ブラウザのブックマークはあまり有効活用してなかったけど、タイトルを自分用につけておくとロケーションバーからの検索に便利なことを体感している。<プレフィクス> | <検索用ワード>, ... という感じでタイトルを設定していて、プレフィクスは ミーティングの議事録など会場: mtg 1on1

あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト

世はまさにハイパーメディア時代。何をするにも視覚的なキャッチがないとやっていけない時代です。ブラウザのスクリーンショットを撮ることも多いでしょう。しかしプライベートな内容もそこに映り込んでしまうこともありがち。かといって画像をいちいち加工するのも面倒……というわけで、DOM操作によってテキストを隠す拡張を作りました。 GitHub - motemen/webextension-obfuscate-texts 2022-07-20 追記: Chrome Web Store に出ました Obfuscate texts - Chrome ウェブストア Manifest V3 で作ったせいでほかのブラウザは未対応。 スクリーンキャスト Chrome extension: Obfuscate texts - YouTube ページ内の要素を選択し、「Obfuscate」することで▗​▝​▌​▏​▇​

全部キーボードで済ませたいシリーズです。 多忙な現代人の一日はその日の予定チェックから始まるわけです。普段であれば定期的な間隔で組まれたミーティングのリズムに身を委ねればいいわけですが、そこに非定型的なミーティングが紛れ込んでくる。これは採用面接など外部との機会であることが多く、そのぶん重要です。事前に入れてあるものを避けて予定を組もうとすると、参加者の数に応じて困難さが増していくので、ある程度は既存のものに被せて予定に招待してもらうことにしていると、いつの間にかダブルブッキングの嵐になっている。直前になって慌てて一方のミーティングに参加しないことを告げる……みたいなことを繰り返していてはいけませんね。 そういうわけで事前にカレンダーの重複を確認して、必要に応じて辞退したり再調整したりしたい。だけどそれを Google カレンダーのウェブ UI からマウスでポチポチやるのは非常につらい……

そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make

緊急新人エンジニア応援企画！ ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb

社内ではドキュメントの共有に Scrapbox が活発に使われており、するといきおい UserCSS や UserScript もさかんである。具体的には、/customize という共有のプロジェクトがあってみんなの自慢の装飾やカスタマイズが共有されている。これを個々人で import して使うんである。 こんな感じ。 自分の場合は /motemen/UserCSS/common に常に適用したいスタイルを書いておいて各プロジェクトから読み込んでいる。このページからさらに、共有プロジェクトや他人の個人プロジェクトページからよさそうな設定を import している次第。 つまりは多段インポート。こういうことを続けていると、だんだんと読み込みの遅さが気になってくる。こういうのはバンドルすればいいのだけど、巷のツールを普通に使うことはできない。インポートしてるリソースに認証がかかっているからだ

新春ツール入れ替えシリーズです。macOS における Spotlight 的なランチャーツールとして Alfred を長いこと使ってきたが、最近 Raycast を使ってみてこれがよかったので、以来ずっと使い続けている。 Raycast - Supercharged productivity 開発者のための便利ツールという売り文句のようで、そういう点がまさに気に入った。 カレンダーの次の予定が表示される まずこれがいい。これだけで十分使える。ランチャーを起動したときにカレンダーの次の予定を表示してくれる。Enter でそのまま Meet や Zoom を開いてくれるのでキーボードから手を離す必要がない。 もともとカレンダーの確認には Dato を使っていたし今も使ってるが、これでミーティングへのアクセスがかなりよくなった。 コミュニティベースの Store で機能を追加できる https:

このときのHHKBずっと使ってたんだけど、昨日ついに壊れた https://t.co/dwvoxapmsN— 美顔器 (@motemen) 2021年7月7日 新卒のころから使っていた Happy Hacking Keyboard が壊れた（アンチポップさんにもらったやつ。ありがとうございます）。とくにメンテもせずに、もう10年以上使えていたので感謝の気持ちとともに新しいキーボードに買い換えることにする。Macbook Pro の内蔵キーボードはチャタリングするんでちょっとしんどい。 少し悩んで、せっかくなので自作キーボードに挑戦してみることにした。はんだ付けは小学生のときに工作教室でほんのちょっと触ったか？ くらいである。「自作キーボード 入門」で検索して出てきたこれを買うことにする。見た目のかわいい ErgoDash。工具セットも買った。 で、届いたんだけど、どうも圧倒されてしまう感覚

この記事は、はてなエンジニア Advent Calendar 2019の12日目の記事です。 任意のテキストを画面に流していきたいことってありませんか？ ぼくはあります。定期的にエンジニアみんなの前でスライドを映しつつ話す機会があって、そんなとき Slack で実況的に反応がなされることがあるんだけど、Slack 映しっぱなしにするわけにもいかず、話し終わってあとからコメントに気づく……ってこともまあまあある。そんなとき、画面のスライドに重ねてコメントが流れてくれると自分も聞き手も共有できてうれしい。わけです。 それを達成するための1ステップとして、任意のテキストを画面に次々流してくれるアプリをElectronで作りました。 GitHub - motemen/TextCast じつは過去のこのエントリたちも、「Slack の発言をリアルタイムにデスクトップに流したい」という欲望からうまれた

Slackはそのクライアントがそれなりに、かなりよくできていて、これでほとんど困ることはないんだけど、そうは言ってももうちょっとプログラマブルに取り扱いたいこともある。 そういう場合にもよいAPIが用意されていて、Real Time Messaging API ってのがある。こいつはWebSocketでSlackの発言をはじめ、あらゆるイベントのJSONを送りつけてくれるやつ。ひとまずこれを標準出力に流すことができれば、あとは好きに料理できるはずだ。 というわけで作ったのがこちら。書いたことなかったのでRustです。ちょうどいいネタだった。 GitHub - motemen/slack-stream-json slack-stream-json というバイナリが、SLACK_TOKEN 環境変数を設定した上で起動してやると、RTM APIによって得られたイベントのJSONをそのまま標準出力