ちなみに

火曜日の空は僕を押しつぶした。

新しいdocker composeで特定サービスのコンテナIDを得る

docker-composeで特定サービスのコンテナIDを得たいことがある。例えば docker attach したいときとか。

これまでなら以下のように書くと web サービスだけのIDが取得できた。

$ docker-compose ps -q web

しかし、新しい Docker Compose CLI では ps サブコマンドでサービスの絞り込みが出来ないのでちょっと工夫が必要。

$ docker compose ps --format json | jq -r '.[] | select(.Service == "web") | .ID'

突然 jq が出てきてちょっとびっくりしそう。もっと良い方法があればいいのだけれど。


$ docker-compose ps --help
List containers.

Usage: ps [options] [--] [SERVICE...]

Options:
    -q, --quiet          Only display IDs
    --services           Display services
    --filter KEY=VAL     Filter services by a property
    -a, --all            Show all stopped containers (including those created by the run command)
$ docker compose ps --help

Usage:  docker compose ps

List containers

Options:
  -a, --all             Show all stopped containers (including those created by the run command)
      --format string   Format the output. Values: [pretty | json]. (default "pretty")
  -q, --quiet           Only display IDs
      --services        Display services

M0ii0 を組み立てた

f:id:Sixeight:20210530160828j:plain

yohewi さんによる30%キーボード M0ii0 が届いたので組み立てました。予定だと6月30日発送だったのでだいぶ速い。ありがたやー。

ソケットとリセットスイッチをはんだ付けするだけなので簡単。今回は先週のキーボードニュースで取り上げられていた MMK Frog を使ったのでルブもなし。

最初はけっこう軽い音がするなあと思ったもののプレートにフォームを入れてみたらだいぶ良い感じになりました。

かわいいのが嬉しくてこだわって写真撮ってみたら #KEEB_PD で優勝してしまってめっちゃ嬉しい。

問題は常用するにはキー数が少なすぎることですね。

この記事は M0ii0 で書きました。

Acperience12 を作った

booth.pm

キーボード沼にはまってすぐくらいに右も左も分からずにGBにinしていたかっこいいマクロパッド Acperience12 が届いたので組み立てました。 予定より大幅に早く届いてありがたすぎます。

yynmt.hatenablog.com

詳しい解説は設計者の id:yynmt さんのブログにて。僕が分かることはかっこいいということだけです。

表面実装は高校以来で久しぶりだったのですが、あんまりブランクを感じさせないような感じでうまくやれました。 体が覚えているというやつでしょうか。

uni ポスカを使用して各PCBの側面を塗装します。 PCB側面の塗装にはuni ポスカがもっとも適しています。 この作業を怠るとマクロパッドとしての性能を十分に発揮できなくなるため注意してください。

ビルドガイド にはPCBのサイドを塗装しないと機能を十分発揮出来ないと書かれているのでがんばって塗っていきました。 しかし不器用すぎてうまく塗れなくて指が真っ黒に。。。

一番最初に買ってうるさすぎて使わなくなった Kailh BOX スイッチ の白をのっけてみました。 マクロパッドだったら押すごとに音のフィードバックがあっても良い感じ。

キーキャップどうするかが非常に悩ましいですね。やっぱり黒がかっこいいけどそれだと洋服のマネキン買いみたいになるし。うーん。

完成です。このままお気に入りのキーボードが並ぶ棚に飾ってもいいでしょう。しかしその前に必ず、かっこよく仕上がったAcperience12の写真を撮影してください。そしてSNSで自慢してください。この手順を省略することはできません。必ず行ってください。

キーキャップが決まらずに写真を撮れてないのでまだ完成ではありません。早く完成させたい。

make.dmm.com

ケースも注文したので届くのが楽しみです!

この記事は The Mark: 65D60 の疑似セパレートで書きました。

その後

完成した

ミュートにし忘れていることに気付くために

f:id:Sixeight:20210516190122p:plain

blog.nishimu.land

以前、Discordのマイクがオンになっていることに気付けるようにしたのですが、Zoomはマイク状態をデフォルトではメニューバーに出せないのでなんとかしないとなと思っていました。しかし、なんとかしたところで今後同じような通話アプリが出てきたときに同様の問題が起きてしまいます。

そんなとき以下のアプリを見つけました。アプリ毎じゃなくてグローバルでマイクのオンオフをホットキーで制御することが出来ます。

MuteKey

MuteKey

  • Dave Cheng
  • ユーティリティ
  • 無料
apps.apple.com

もちろんメニューバーにマイクの状態が表示されるのでBartendarでマイクが入っているときだけ表示することも可能です。

git open

f:id:Sixeight:20210510183234p:plain

いま見ているリポジトリのブランチをGitHub上で見たいときがあります。

最近だと GitHub CLI を使うのが便利なので使っているのですが、毎回 gh repo view -w みたいに書くのも面倒なので以下のような alias を設定して使っています。

open = !gh repo view -w -b $(git symbolic-ref --short HEAD)

これで git open と打つとみているブランチが GitHub で表示されます。

昔はこういう場合に gho みたいなシェルのaliasを切ったりしていましたが、だんだん頭が劣化してきて覚えられなくなってきたので、基本は省略せずに入力するようにしています。 補完が効くので別に苦じゃない。

ユニコーンはいかにしてモチベーションを生むか

あの アジャイルサムライ のジョナサン・ラスマセンの新作。角谷さんの翻訳で間違いないのが出ました。 社のブログ向けに今のチームとの対比を絡めて書こうともがいてますが、ひとまず感情だけを先に書き殴ります。 (こうやって読者の反応を見ずにブログマーケットフィットを想像して推敲に推敲を重ねているのがまさにエンタープライズ人間っぽいのでこっちは一切推敲していない)

この本はいまや音楽ストリーミングのデファクトとなったSpotifyがすさまじい勢いで成長していたころの著者の体験を元に書かれている。 インターネットには少し批判的なようすが出てきていたスクワッドやトライブなどの実際の様子や、全体の方向を統一しつつも速度を出すためにやってきたこと、そのための文化の話などが書かれている。

残炎ながら、これを読んで明日から真似しようと思って手に取って人には向いていません。 方法論の本ではなくて、俺たちにはこのやり方がうまくいったという例が書かれている本で、ちりばめられたヒントから自分達はどうなんだろうと考えるための本だと思います。 エンタープライズ企業でも当たり前にアジャイルな開発をするようになって久しくであったりとか、ユニコーン企業はスクラムなんてやっていないなどと強い言葉も書かれているが、方法論の本だと思って真に受けてスクラム止めますなんていうことは推奨されてないので注意が必要。

目につくのは「自立、信頼、権限」という言葉だけれど、僕はこの本はモチベーションの本だと思って読みました。

強いプレッシャーと不確実性の中で素早くプロダクトマーケットフィットを見いだすには、短いイテレーションで改善を続けるアジャイルな開発は前提条件であって、その速度と品質をさらに上げるのがモチベーションだと。 内発的なモチベーションをもってプロダクト開発に関わるチームは自立して前に進めるし、そんなチームを上層部は信頼して、権限を譲渡出来る。そうするとチームのモチベーションはより上がっていく。 本ではまずは信頼して権限を与える。と書いてあるけど鶏卵になっていて我々開発チームとしてはまずは内発的なモチベーションを得るところから始めるのが良いのではないかと思います。

そのために方法として、やはり「目的」というのが重要で、本ではカンパニーベッドというものを使って1つの目的にフォーカスする方法が書かれている。 会社やプロダクトの目的に心から賛同出来る場合は自然とモチベーションというのは沸いてくる。これはOSSと同じでプロダクトを作ることに関わること自体が目的に出来ている。 つまり自分からそのプロダクトを作りたくなるのだ。そりゃあアウトカムも出てくる。 アウトカムが出てきたらフィードバックを得られるので、さらに改善していける。次のカンパニーベッドをよりうまく決められるのだ。

プロダクトがよくなってくると次の段階が訪れる。 プロダクトを作っている自分達の環境をもっとよくしたいというモチベーションにつながる。 これが生産性の話につながってきて、さらに開発速度は上がっていく。 (これは逆のループもあって開発速度を上げるとフィードバックが早くなってチームの信頼も獲得して権限を得て、会社はフォーカスする方向を決められるようになる。これは明日から出来る!!!会社が変わるのを待っている暇があるなら手を動かそう。)

それも楽しくてやっているのだ!!!

こういった一連の流れを文化として定着させることで組織として強くなっていく。 ハードだけれど楽しい職場で、そして結果もついてくるような環境は最高だと思いませんか。 そこを目指すためにどうやったらいいのか考えるきっかけとしてこの本はとてもいい石を僕の中に投げ込んでくれたと思います。

こうやって本を読むことで内発的なモチベーションを得られるのだけれど、これは正直すぐに消える。 モチベーションが消えないようにどうすればいいのか。「近道はない。やるしかないんだ。」の精神で何かをやってみるしかないのだ。

フィーチャフラグを使いたい

今のチームでは GitHub ワークフローを使っていて、フィーチャブランチを育てている。 この方法はまあまあうまくいっていて、ふだんは何の問題もない。

しかし、ある機能の開発に時間がかかると問題が生じる。特に複数のブランチがそういう状態になると目も当てられない。 すばやいデリバリーのための施策が逆に速度を落とすための足かせになってしまう。

  • masterと乖離してしまいマージの難易度が上がる
  • どのブランチに入った機能なの分からなくなる
  • 頻繁なブランチ切り替えが発生してそのたびに環境を作り直す
  • リリースするときにマージするのでいわゆるビッグバンリリースになってしまう

こういった問題を回避するにはフィーチャフラグというテクニックがあって、コードはメインブランチにどんどんマージしてリリースするんだけれど機能としては伏せておくみたいなやりかた。 どんどんマージしてリリースしちゃうので上のような問題は起きない。

別の問題はあってフィーチャフラグの仕組み自体が技術的負債になってしまったり、うまく運用しないと開発中の機能が公開されてしまったり既存の機能に悪影響を起こしてしまったりする。 こういうのはチームの練度にもよりそうなのでやっていくしかないと思うのだけれどけっこう不安が大きい。

新規追加ならやりやすいのだけれど、既存機能に手を入れる場合はうまく新旧のコードを管理する必要があって難しそうだし、速度が落ちそうで心配。

しかし、よく考えるとブランチの運用コストや、リリースして失敗したときのやり直しなどを考えると、ただただ分岐を書くだけなので実は速度は上がるはず。 既存コードに手を入れるときもまあきっとうまくやれば良い感じで出来ると思う。

フィーチャフラグでうまくいくことはすでに多くのチームが成果を出していることで証明されているが自分でやるとなると勇気が必要ですね。