[B! togetter] アメリカのVTuberさんが『日本人はカスコー(Costco)のことをコストコって言うんやで 発音かわゆす』みたいなお話をなさっていた「tを読まないんか」 このブコメに「NISAも英語読みならniceのようにナイサと呼ぶべき」というものがあり、それは違うんじゃね？ と直感的には思ったものの、そんなに説明できる感覚でもないなと思ったので調べてみた。 結論としては「ニーサ」で問題はないだろうと思う。 英単語を構成する文字のうち子音をC、母音をVで表すことにする（一般的な表記のようです）。ここでは「CiCeという形で表される英単語のiにおける発音のルールが、CiCaという形式にも適用されるのか？」という疑問に否定的な回答をしたい。 そのために、 まずCiCaの形（NISA）をとる既知の英単語における "i" の発音がどのようであるか、 その後、CiCeの形（nice）

関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう 日本語版出版に際し、訳者の猪股さんにご恵贈いただきました。ありがとうございます！ すでに原著の『Domain Modeling Made Functional』を読んでいて、そのときの感想は以前に書いたとおり。そこからの差分としては、はてな社内でこの本の輪読をはじめたこと。輪読がはじまったその週に日本語版の出版が告知され嘆息する一同でしたが、日本最速で輪読を開始できたのは間違いないと思う。 この本の特徴をひとつ挙げろと言われれば、実装に使われている言語がF#であること、というのが大方の回答になるとおもうが、一方でこの本をやるのにF#を実践する必要はない、と考えている。そういうわけで今回輪読における実装言語にはGoとTypeScriptを指名しており、その後Scala勢力も増えたのだけど、進度的には実際にコ

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

ソフトウェアエンジニアリングにおいて大切なのは、人間のことをのぞけば名付けだと思っている。言葉がなければ世界は混沌としたままだけど、そこに名前をもたらすことがものごとを切り分け、ひとつの秩序をもった視点をつくる。この秩序は唯一絶対のものではなくて、なんらかの意志によって導かれたものである。ソフトウェアはあくまでも現実の抽象だから、問題をどういう視点で見るか、という軸があるわけだ。そういう意味では人間のことではある。 適切につけられた名前は、そのことによって他のものとの自然な境界を与えられていて、その他の名付けと一貫性を持っている。そういう名前は既存の名付けの体系になじむので、同じ言葉を使う人々のあいだに受けいられれて、共通のコンテキストに追加される。そして次第に暗黙のものになっていく。 たとえばユーザのフォローがあるSNSのようなウェブサービスをつくるときに、QueueとかBrokerみた

こうしてます。 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（アンドゥ）の挙動が本家と違うのがどうも身体に合わない。逆にストレスが高まっ

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

オレ定義だけど Togetter まとめ風というのはこういうやつ。 散歩で急にシロクマと会っても食べるのは肉だけにしたほうがいい「肝臓1gに含まれるビタミンAが致死量を超える」 - Togetter まとめタイトルの終わりに誰かのツイートの引用を挿入する、という形式。よくできたもので、誰かの生の声が入っているだけで、感想やハイライトを抽出し、ちょっと気を引くことができる。まあ一種の演出で、ニュースサイトがやってることもある。 タイトルでアテンションを奪い合わなければならない宿命におけるクリック最適化の手法ということだろう。今回はこれを真似してみることにする。すでに書かれた自分のブログ記事に、括弧書きでセリフっぽいものの引用を捏造して付け加えることで魅力がアップするのか、という実験だ。 こういう生成系のタスクも、とりあえず HuggingFace+Google Colaboratory でや

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

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

最近フロントエンドに限らず TypeScript を書くことが多くなって、これでそれなりの規模のサーバサイドアプリケーションを書くときどうなるんだろう、と気になって読んでみた。いわゆる普通のオブジェクト指向ではなく関数指向な書き方でいきたいとき、どうするのが好ましいのか、というような観点。 名前的にそのものずばり、という本があったので購入した。日本のウェブを検索してみてもいくらか言及があるので価値はありそうだという判断で、大人なので円安でも強行する。 Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition) 作者:Wlaschin, ScottPragmatic BookshelfAmazon 自分は PDF で読みたかったので

Stable Diffusion が来てるねってことで貧者の GPU であるところの Colaboratory でいろいろ試したいのだけどノートブック上で Python のコードをこまごまいじりながら試行錯誤するのは微妙に体験が悪い。 ちょっとしたウェブサービスとして立てて実行できるとよいけれど、なかなかクラウドサービスも帯に短し襷に長しという感じで GPU を気軽に借りられるところはなさそうだ……と思ったら、Colab 上に HTTP サーバを立てられることを知ったので、その方法でやってみることにする。 やってみたソースは以下。 GitHub - motemen/stablediffusion-server-on-colab README にあるノートブックを開いて Huggingface のトークンを埋め、GPU を選択して実行するとサーバが起動する。サーバが起動する前のセルに表示され

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

近年、普段の作業をマウスでやりたくない気持ちが高まっている（デスク周りが散らかってきたせいだという説が有力です）。メールは結局ターミナルでメールを読むことにしたため問題なく過ごせているが、その他のタスクをキーボードだけでやるには、ターミナル動くアプリケーションを作れる必要がある。それもリッチなやつだ。見た目は派手な方がいい。 この記事は Kyoto.go remote #32 LT会 で発表した 入門 Bubble Tea の増補版です。 Bubble Tea とは GitHub - charmbracelet/bubbletea: A powerful little TUI framework 🏗 Bubble Tea とは、Go でリッチなターミナルアプリケーション（TUI）を作るためのフレームワーク。Charm というプロジェクトの一部のようで、ホームページを見てもらったら分かると

よくあるフローってのは Google の API ドキュメントを読んでたらよくでてくるやつ（Calendar API の例）。つまり: 前回のアクセストークンが保存されていたらそれを使い、なかったら localhost にサーバを立て、redirect_uri をそこに設定した認可のための URL をユーザに提示し、 code を受け取ったらアクセストークンと交換し、 トークンを保存する。 みたいな一連の流れ。これまでどの部分を抽象化したらいいのかあまり感覚がわからなくて手を出してなかったんだけど、いいかげん面倒なので書いてみた次第。 oauth2util package - github.com/motemen/go-nuts/oauth2util - pkg.go.dev 使い方は簡単で import "github.com/motemen/go-nuts/oauth2util" ..

メールに対する jq みたいなやつ……というと強力すぎるけど、そういう感じにメールを入力に受け取って何かしらの処理をした上で出力してくれるツールです。ここでいうメールとは MIME 形式のメール全体。Gmail なら "Show original" で見られるようなもの。 結局ターミナルでメールを読むことにした に書いたとおり最近はターミナルでメールを読むようになりそこそこ快適なんだけど、メールとの接し方がプログラマブルになったからには楽をしたい。だいたい通知のメールのこの部分をクリックするだけ（そして承認したりコメントしたりする）、みたいなパターンが決まってるものには DWIM（do what I mean）的にキー入力一発で対応したいわけです。それをやるためのツールとして書いた。珍しく名前を気に入ってる。 GitHub - motemen/letterknife 使い方 $ cat <

そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として 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