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

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"

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

近年、世間ではリモートでスピーチをする機会が増加している。人前で喋ったことがあると経験があるのではないかと思うけど、テレビ会議ごしに話をすると目線が合わない、そもそも顔が見えないなどで反応がものすごく薄い。だんだんと慣れてきた感もあるけどやっぱり喋りづらい。技術による人間の疎外、これは仕方がないことですよ。 そうであれば解決するのも技術だ、というわけで作ってみたのがこちら（マイクの権限が必要です）。ブラウザの中から誰かがこちらを見てくれていて、話にうなずいてくれる。ただそれだけ。だけど、多数に向けたスピーチの際にうなずいてくれる人間の貴重さを知っている人には、このありがたさに共感してくれるのではないだろうか。 Vnodroid pixiv/three-vrm を使って3Dアバターヒューマノイドをブラウザ上に表示し、あたかもそこで自分の話を聞いているかのように存在させている。呼吸とまばたきを

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

Scrapbox のような Wiki 的なツールでは URL にページ名が入ることが多く、URL を見るだけでどんな内容なのか想像がついてよい一方で、こういう URL を Slack や Google Docs のような別の場所に共有するとパーセントエンコーディングされた URL になってしまい意味がわからなくなる。日本語を書いていることだけが分かる状態。 マルチバイトしかないと本当にわからないね Slack がアクセスできない URL だと、プレビューも展開してくれないしね。かといってデコードした状態の URL を貼っても、変なところで途切れたりする。 ・（中黒）でリンクが途切れている 文字は難しい……。URL の解釈はものによって異なってくるのもまた困る。これはプレーンな文字列を渡しているのでこういう困難が出てくるのであって、最近はクリップボードでリッチなコンテンツを受け渡しすることが

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

社内に「来年の今年の目標は『半年早く動く』です」というエントリを書いて半年が経った。 こういう目標を立てたきっかけは、自分が変化のタイミングとして会社の会計年度（半期）を考えるようになっていたことに気づいたことだった。 同じ会社でマネージャも長いこと続けていると、部下や同僚の退職を見送る経験も多い。これは一般的に言っても、あまり楽しい体験ではない。辞める理由は人それぞれで、ひと括りにすることはできないものであるし、こう考えるのはおこがましい感じもするが、立場的には、自分が何かアクションを起こすことでまだこの会社で活躍してもらえていたんじゃないかと思うのも常だ。そして実際、そのための、たとえば環境を変えるといったことを考えて、準備もしていた場合も多かった。来期まで待っててくれればな……、という具合。 けれど、自分が制度や組織の設計を仕事の手段としてるのでそう考えていたとしても、ひとの人生はそ

この記事は、はてなエンジニア Advent Calendar 2020の21日目です。昨日は id:tarao による Scalaの依存ライブラリ更新はRenovateでもけっこうイケる でした。明日は id:Krouton です。 みなさん在宅勤務してますか？ 私もしています。 仕事も雑談も、とにかくオンラインで話すことが多いので在宅勤務中は AfterShokz という骨伝導ヘッドホンを使っている。ずっと装着してても疲れにくいので、大変いい買い物です。 いちいち外すのも面倒なのでほとんど一日中付けっぱなしにしているんだけど、これが事故を呼ぶこともある。マイクをオフにすることを忘れて離席してしまうと、オフのときの会話が筒抜けになってしまうので、同僚の前ではおとなしいのに家族の前では豹変するとか……。あとおしっこしてる音が聞こえちゃってないとか。気になりますよね。油断できない。 そういうわ

この記事は、はてなエンジニア 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をそのまま標準出力

目下新マシンの開発環境をセットアップ中なんだけど、clone しないといけないリポジトリがけっこうたくさんある。このリポジトリ群っていうのが git submodule によってモジュールを共有していて、つまり同じリポジトリを何度も fetch してくることになる。これって無駄じゃないですか？ というわけで submodule update 時にキャッシュを生成し、それを利用して以降の同コマンドを高速化するコマンドを書きました。 https://github.com/motemen/git-shared-submodule-update git submodule update の代わりに使います。 # git submodule update --init の代わりに… git shared-submodule-update --init 簡単ですね。 git submodule upd

Ethereum はブロックチェーン上でアプリケーションを動かせる（スマートコントラクト）ってので興味を惹かれて、どんなことができるのか調べてたんだけど、感じを掴むために一つ書いてみた。 やりたいことは、ウェブページに送金ボタンがあって、そこから特定のアドレスに Ether を送金し、送金が確認されたら秘密のコンテンツをページ上に表示する、てなもの。送金の確認はスマートコントラクトで行えるが、秘密の情報をブロックチェーン上に記録するわけにはいかないのでこれはウェブサーバに秘匿することになる。とすると、ウェブサーバに私はこの Ethereum アドレスです、とセキュアに伝えてやる必要がある。後で書くけど、あまりいい解法ではない。 知識ゼロの状態から分からないことを潰しつつなんとか動くところまでこれたので、ウェブアプリケーション開発者がつまづいたところをメモっとく。 デモ MetaMask W

おはようございます。この記事ははてなエンジニアアドベントカレンダー2017の25日目の記事です。昨日は id:alpicola さんによる 社内で機械学習ハッカソンを開催しました でした。 サービスのデプロイをはじめとして、チーム内の開発者が共通して担当すべき業務というのはさまざまに存在し、基本的に定型化されているものですが、開発者が手元で実行するなど自動化までは行えていないような場合、以下のような点が問題になります。 作業履歴が共有されない 同様に作業中に意図しない不具合が生じた場合、エラーログが実行した環境にしか残らない それぞれ、デプロイのタイミングを Mackerel や Slack に投稿して共有する、Gist にエラー時のログを貼るなど、チームに合わせた方法が存在していることと思います。また作業環境を同一にするため、チームにデプロイサーバを用意して作業はそこで行う、という方法も

Go に限らず、公開しているプロジェクトのバージョニングは必要だけれど面倒なタスクのひとつで、プロジェクトのメンテナンスを続けていくつもりがあるのなら、ほぼ必ず通らなければならない道でしょう。ここで話題にしているのは Git などによるソースコードのバージョン管理ではなく、たとえばバージョン 3.1.4 といった、リリースされるソフトウェアの公開バージョンをどう運用するか、という話です。 バイナリとして配布する前提のプロジェクトであればソース中で var version string と宣言した変数に、ビルド時に -ldflags '-X main.Version 3.1.4' などとしてバージョンを設定するという方法もありますが、go get による配布ができるのなら、提供側としては楽ができます。たとえば gore は開発者向けということでバイナリの配布をしていませんが、リリース作業がな

Googleカレンダーで現在進行中のイベントをSlackステータスに反映させるようにしておくと、チームメンバーに、移動中や不在やミーティング中といった状況を自然に共有できるので便利ですね。そのように設定している人も多いと思います。 似たアイコンが並んでいるように見えますが一方はモザイクです 巷では Google Apps Script でこの連携を行うような方法が公開されていて、自分でも書いて使ってました。これは一度動かしてしまえば大変便利なんですが、インストールの方法はけっこう面倒で、非エンジニアをふくめ会社のみんなに薦めるには少しハードルが高い。 そこで、Google Apps Script を用いて、（初回のインストール手順を除いて）ワンクリックで Google カレンダーと Slack ステータスの連携を行えるウェブアプリを作りました。 GitHub - motemen/gas-g

この記事は、はてなディレクターアドベントカレンダー2016の17日目のエントリです。（昨日は id:daiksy の『嫌われない勇気』でした。） id:motemen です。過去には立ち上げ期の Mackerel チームのディレクターをしていましたが、当時のことは 過去の記事 にあるとおりで、あまりディレクターとしてほかに書けることもないので違う話を。 今年のはじめごろに エンジニアの専門性を伸ばすためにディレクターに気をつけてほしい3つのこと - Hatena Developer Blog という記事が書かれましたが、これはディレクターからエンジニアに向けた話だったのでこれの逆バージョンを書いてみようと思います。 先に書いておくと、ぼくは新卒ではてなに入社し、ディレクターの id:nmy さん（アドベントカレンダー最終日）や id:chris4403 さん（アドベントカレンダーのエントリ

自分も大方の人間と同じように人前で喋るのは苦手で、可能であれば避けたいと思っているけれど、一方でこの業界で生きのこる方法のひとつとして避けられないものでもあると思っている（ので苦しい）。若かりしころ手痛い失敗をしたこともあって、かなり苦手意識を持ちつづけていたが、最近はわりかし上手く付き合えるようになってきたかなとふり返って思う。 今もうまいプレゼンテーションをする方法は知らないし、それを僕から知りたいという人はいないとおもうが、プレゼンでしくじる方法なら経験から知っている。準備をしないこと。自分の経験からはそうだし、まずいプレゼンを見ていてもそうなんだろうな、と思うことはやっぱり多い。 このエントリはプレゼンがいやでいやで仕方がなかった自分のための分析であり、プレゼンのマイナスレベルをゼロまで引き上げようとする努力です。ソフトウェアエンジニアの技術者間交流のためのプレゼンというのが前提。

お題「エンジニア立ち居振舞い」 おもしろそうなお題なので乗ってみる。自分は今は技術組織のとりまとめをしているけど、会社の古めのプロダクトの面倒を見る仕事もしてきた。時を経てサービスに携わる人が変遷し、コードの歴史も重層的で一筋縄ではいかないことが多い。仕事で触れるプロジェクトが多いので、ひとつのプロジェクトに関する知識を深めづらい面もある。 属人性を減らす さまざまなタスクを通じてプロダクトに触れるうちにだんだんと自分の中に知識がついてきて、用件を聞いたときに「あ、それならあのプロジェクトのあのへんのコードだな」、というアタリがつけられるようになってくる。この地図や勘といったものは正直なところ外部化しづらく、ある程度を超えると個々人の中で養っていくしかないものだけれど、日々の仕事において、属人性を減らすように努力することはできる。 普段からやっていることは以下のようなところ。 作業ログを残