ちなみに

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

CircleCIの小手先による高速化手法

この記事は Money Forward Engineering Advent Calendar 2021 - Adventar の6日目の記事です。 昨日は TONY (id:galepilot) さんによる「チームで実践したKPTのボリュームを増やすコツ」でした。 ふりかえり、なんとなくやってしまうと惰性になるのでちゃんとチームで意図を理解したうえで実施するのは大切ですね。

CIを速くする意味

CIを速くする意味はなんでしょうか。

DORA(DevOps Research and Assessment) 2021年の Accelerate State of DevOps Report によると、エリートチームのリードタイムは1時間以内ということだそうです。 本当かという感じの短さですね。デプロイ頻度は変わらずオンデマンドということなのですが、1時間以内にトランクにマージされるとすると、デプロイ回数もすごいことになっていそうです。

さて、デプロイするためにトランクにコードをマージしたとすると何が起きるでしょうか。 そう CI (Continuous Integration) の実行です。

例えば仮に1日に1回デプロイするとしても、年に240回デプロイしていることになります。このときトランクでのCIの実行に30分かかったとすると120時間もの時間がCIを待っている時間に使われてしまいます。デプロイ待ちだけでもこれくらいかかるのですが、トランクにマージしているないコードを合わせると途方もない時間をCI待ちに使っていることになります。

これではリードタイムが下がってしまいますし、結果デプロイ頻度も下がります。また当然不具合があったときに修正をいれようとしても同じだけ待つ必要です。

これがCIが速くあるべき理由のひとつです。

また1エンジニアの立場からみても、CIを待っている時間とても無駄ですね。 フィードバックが遅いということはそれだけ開発のテンポが遅いということです。

少しならいいのですが、これがずーっと続くと考えるとモチベーションが低下しませんか。 これが従業員エンゲージメントの低下を招きます。

Four keys metric についてはLeanとDevOpsの科学が詳しいのでぜひご覧ください。

anchor.fm

texta.fm のLeanとDevOpsの科学の回も非常におすすめです。

推測するな計測せよ

速くすると言っても闇雲に作業するだけでは楽しいだけで意味はありません。 ちゃんと計測して効きそうなところから手を入れていきましょう。

幸いなことに CircleCI には Insights があるので、それを眺めたりするだけでもけっこうな情報が得られます。 金で殴ると速くなったりもするのですが、その辺はバランスなのでちゃんとコストも眺めておきましょう。

逐次実行をやめる

ビルドしたあとにユニットテストとE2Eテストを実行してステージングにデプロイするようなワークフローを考えてみましょう。 ここでボトルネックになっているのはE2Eにかかる時間のようです。

以下のような workflow があるとすると unit_teste2e_test のジョブは逐次実行されます。 しかし、これらは独立して実行可能だとするとユニットテストと同時にE2Eテストを実行した方が効率が良さそうです。

build_and_deploy:
  jobs:
    - build
    - unit_test:
        requires:
          - build
    - e2e_test:
        requires:
          - unit_test
    - deploy:
        requires:
          - e2e_test

これはこのように ファンアウト/ファンイン することで解決します。

build_and_deploy:
  jobs:
    - build
    - unit_test:
        requires:
          - build
    - e2e_test:
        requires:
          - build
    - deploy:
        requires:
          - unit_test
          - e2e_test

ワークスペースの保存を最適化

さてこれでE2Eテストの影響で極端に遅くなるということがなくなったようです。しかし今度はビルドの時間が気になってきました。

いくつか改善ポイントがありそうですが、実行時間を眺めてみるとどうやら persist_to_workspace しているところが遅いことが分かりました。

よくみるとリポジトリ全体を保存しているようです。

- persist_to_workspace:
  root: .
  paths:
    - ./

persist_to_workspace は対象のファイルのtarボールを作ってgzipしたものをアップロードして、それを attach_workspace で展開しています。

つまり対象のファイルが増えれば増えるほどtarボールを作ってアップロードするのも、それをダウンロードして展開するのも遅くなります。

よって必要なファイルだけを保存するようにしましょう。

- persist_to_workspace:
  root: .
  paths:
    - file1
    - file2

こういう感じ。これで build ジョブだけじゃなくて、保存されたファイルを使っていた後続のジョブも速くなりました。

これはリポジトリが太れば太るほど効果が大きいので、長年開発しているプロダクトには特におすすめです。

チェックアウトを速くする

CircleCiには checkout という組み込みのステップがあります。

これを使うと気軽のリポジトリからファイルをチェックアウト出来るのですが、実はこのステップはあんまり賢くなくてリポジトリをまるごとチェックアウトしてきてしまうので、先ほどの話にあったとおりリポジトリが太ってくるとどんどん遅くなります。

1つの回避策として .git/ をキャッシュしておくという方法が紹介されているようですが、これは結局キャッシュの出し入れにかかる時間を考えるとほとんど意味がないと思います。

諦めて自前でチェックアウトする方が速いので以下のような コマンドを定義 しておくとべんりです。

shallow_checkout:
  steps:
    - run:
      name: Checkout repository
      command: |
        git init
        git remote add origin ${CIRCLE_REPOSITORY_URL}
        GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git fetch --depth=1 origin ${CIRCLE_SHA1}
        git checkout ${CIRCLE_SHA1}

これもある程度年数の経っているリポジトリには劇的に効くのでおすすめでです。

ふつうにキャッシュする

あとは割とふつうの話なのですが、次回の実行が速くなるようにインストールしたライブラリなどをキャッシュします。

キャシュを復元するときには複数キーを指定できて、前方一致してくれるので複数のキーを使って段階的なキャッシュになるようにしておくのがポイントです。

例えば npm の場合だと以下のようにすると使い勝手が良さそうです。( nodenv などを使っていて .node-version ファイルがある前提)

- save_cache:
  key: npm-cache-v1-{{ checksum ".node-version" }}-{{ checksum "package-lock.json" }}
  paths:
    - ~/.npm

キャッシュを戻すときに以下のようにキーを指定すると、まずは package-lock.json の内容が同じかどうか確認し、違っていれば .node-version の内容を確認する。 それも違った場合は npm-cache-v1- というキーでキャッシュを探すので、何も更新がなければ最新のキャッシュが使われて、そうでなくても同じ Node.js のバージョンのキャッシュが使われるなど出来る限り現状に近いキャッシュを選択できるので、無駄が少なくなります。

- restore_cache:
  keys:
    - npm-cache-v1-{{ checksum ".node-version" }}-{{ checksum "package-lock.json" }}
    - npm-cache-v1-{{ checksum ".node-version" }}-
    - npm-cache-v1-

ちなみに node_modules/ ではなくて ~/.npm をキャッシュしているのは npm ci を使って存性の解決をスキップする代わりに node_modules/ を毎回消しているからです。

これは前方一致なキャッシュキーを扱うときにありがちなミスだけど、npm-cache-v1 ではなく npm-cache-v1- (末尾にハイフンが付いている!)にしないと、例えば npm-cache-v10 に意図せず一致してしまうような問題がある。

id:r7kamura さんから指摘いただいて修正しました。

イメージの最適化

この辺りまでやってくると削るところが減ってくるので、Executor として使っているDockerイメージにボトルネックが移動している可能性があります。その場合は不要なものを含まない適切なイメージを選択するようにしてください。

ほとんどのケースでは CircleCi の ビルド済 Docker イメージ を使うといいでしょう。

ちなみにデータベースでのファイルへの永続化が必要ない場合はメモリストレージを使ってくれる -ram バリアントを使うのがおすすめです。

テストを分割する

これらの最適化で build ジョブはだいぶ速くなったと思うので次はテスト自体をもう少しどうにかしましょう。

もちろん根本的にテストを速くするというのが最も効果的だとは思うのですが、テストを安全に改善するのはなかなか難しく、その作業は困難を極める場合もあるでしょう。

安心してください。我々には金で殴るという方法が残されています。時間を金で買うのです。

CircleCIには テストの並列実行 をするための仕組みが用意されており。これを用いると複数のサーバーでテストを同時に実行することができます。

方法がとても簡単で、ジョブの parallelism キーを指定することで並列実行されるようになります。

jobs:
  unit_test:
    parallelism: 10
    steps:
      - ...

ここで重要なのは並列実行されるジョブのどこでどのテストを実行するかです。

ふつうにやるとちょっと難しそうですが、CircleCIではcircleci tests コマンドを使ってテストを適切に分割することができます。

TESTFILES=$(circleci tests glob 'spec/**/*_spec.rb' | circleci tests split --split-by=timings)

あとは $TESTFILES に格納されたテストファイルを実行するだけです。

--split-by=timings を使うと並列実行されるそれぞれのテストがだいたい同じくらいの時間で完了するように分割してくれます。

これには実行結果のデータが必要なので store_test_results のようにテスト結果を保存するのを忘れないでください。

- store_test_results:
  path: /path/to/test-results

あとはどのくらい分割すると効率良くテストを回せるかを実験しながら見つけましょう。当然ですが分割数を増やすほどの消費するクレジットの数も増えるのでお金がかかります。

最後に

小手先で出来る技を紹介してきましたが、なんとここに書かれたことの大半が公式のブログに掲載されています。 みなさん時間を無駄にしましたね。

circleci.com

まずは一次情報を当たりましょうという教訓を得られましたね。


Money Forward Engineering Advent Calendar 2021 - Adventar 、明日は maya akahane さんです。社のSlackにいるDeepLボットにはとてもお世話になっているので気になります。


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

機材がなくてもなんとかなるキーボードの手抜き撮影

こんにちは。 id:Sixeight です。この記事は KEEB_PD Advent Calendar 2021 - Adventar の6日目の記事です。 昨日は たねやつ (id:ibuquicallig) さんによる「初めて作ったtada68とエピソード」でした。 最初の自作キーボードということでとてもエモいですね。

写真

KBDFans Mountain Ergo (C³ TANGERINE SWITCH / EnjoyPBT ModernJA)
KBDFans Mountain Ergo (C³ TANGERINE SWITCH / EnjoyPBT ModernJA)

別のアドベントカレンダー用に撮影した Mountain Ergo です。記事の中には出てこないキーボードとして撮影したこだわりの一枚。

blog.nishimu.land

ゆるふわ解説

KBDFans でGBをしていた Mountain Ergo。 シュッとした見た目と一体感のあるリストレストに一目惚れしたキーボードです。 残念なことに一体感のあるはずのリストレストは若干ズレていて、レンダリングほど一体感はなかったのですが、写真では中央が揃うように撮影したので手前をみるとズレているのが分かります。

薄い色のケースを買いがちな自分にしては珍しく黒のケースにしていたらしく、ちょうど買っていた EnjoyPBT ModernJA を乗っけてモノクロにしました。 かなり引き締まった感じになっていてこの構成は気に入っています。

スイッチは C³ TANGERINE SWITCH の Light Green stem を使っています。 このスイッチはキーボード沼にハマってからずっと欲しかったスイッチなのですが、手に入れて満足してしまってしまい込んでいたものを引っ張り出してきました。 潤滑はしていないのですがだいぶ滑らかな打鍵感でよいですね。思ったより軽かったのでもうちょっと重いと嬉しいんですが、Dark Green stem だと重すぎてもどかしい。

直前に macOS Monterey に上げた結果、うまくストレージとして認識してくれなくなってしまって、ファームの書き込みが普段の環境で出来なくてめんどくさい感じになってしまいました。 結果的にキーマップが納得いってなくて常用出来ていないので、そのうちちゃんとして使ってやりたいなと思っています。

撮影

機材は iPhone のみで、撮りっぱなしで現像もしていません。 もちろん、機材にこだわって撮影されていたり、現像をしっかりされた写真には敵わないものの、まあまあマシな感じにはなっているかなと自己満足しています。

ポイントは2点で、必ず自然光で撮影するのと、ポートレートモードを使うことです。

自然光で撮影することで iPhone でもだいぶマシな写真になるうえに、ポートレートモードで撮影することで良い感じボケてくれるのでそれっぽくなります。 ポートレートモードではずっと「離れてください」って出てますが無視して撮っています

もちろん三脚なんで使ってなくて手持ちです。

我が家で自然光が入る位置がベットになってしまうのですが、布がピシッとしてないので使ってないデスクマットを敷いてます。

ということで私がハードルを下げていくのでみなさんも気軽に撮っていいましょう。

参加履歴


KEEB_PD Advent Calendar 2021 - Adventar 明日は k4m1tsuki さんです。 「my best keyboard」ということでエンドゲームにたどり着かれた可能性に期待が止みません。

adventar.org


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

リモートワークのために買って良かったもの10選

この記事は Money Forward 関西拠点 Advent Calendar 2021 - Adventar の1日目の記事です。 株式会社マネーフォワード関西拠点 に所属するメンバーのテーマ自由なアドベントカレンダーです。


f:id:Sixeight:20211107122328j:plain

こんにちは。マネーフォワード関西拠点の 西村 (id:Sixeight) です。

マネーフォワードでは現在、コミュニケーションのために週一回の出社を推奨していますが、それ以外はリモートワークを選択することが可能です。 私も今年1月の入社以降、基本的にはリモートワークで自宅から勤務しています。

今回はリモートワークをするにあたって買って良かったものを紹介したいと思います。 みなさんのリモートワークをより快適にするための参考になれば幸いです。

第10位 HHKB Professional HYBRID Type-S

happyhackingkb.com

みなさんが大好きなHHKB、私もリモートワークのために新たに購入しました。

これまで自宅での仕事には Kinesis Advantage2 というエルゴノミクスキーボードを使っていたのですが、ふと思い立って新しいHHKBを購入しました。 Bluetooth接続が出来る点と、静音な点に興味を惹かれたのですが、これは大正解で場所も取らずにとても快適にタイピングが出来るようになりました。 HHKB自体は Professional2 をオフィスで使っていたのですが、これと比べてもだいぶ静かで強めにタイプしても心地良い音でした。

HHKBは東プレの静電容量無接点方式のスイッチを使っていて、心地よいタクタイル感が好みです。 タクタイル感というのはキーを押したときの押した感のことで、軽いひっかかりを感じたあとにふっと軽くなって押し込まれる感じです。

現在はキーキャップを EC HHKB PBT BLANK D&G KEYCAPS に換装して以下のような感じで使っています。

第9位 Keyboardio Atreus

Keyboardio Atreus (Automatic discount at checkout)shop.keyboard.io

しばらくHHKBに満足していたのですが、 Kinesis を使っていたところから HHKB に移ったために若干の物足りなさも感じていました。

選択肢としてメカニカルキーボードというのがあるということは知っていたのですが、自作のイメージが強くてはんだ付けしたりするのは難しそうだなと思っていました。 そんなとき id:takkan_m さんからはんだ付け不要なキットを紹介してもらうという幸運に恵まれました。

takkanm.hateblo.jp

Twitterで雑につぶやいたところ記事にまでしてもらって、これはもう買うしかとなって購入したのが Atreus でした。

スイッチについては何の知見もなくて選ぶ基準が分からなかったので、 遊舎工房 さんでスイッチテスターを購入して実際に触ってみることにしました。

スイッチテスター人気スイッチ詰め合わせ 18個セットshop.yushakobo.jp

いろいろ触って思い切り悩んだ末、メカニカルキーボードと言えばメカニカルな音が良いでしょとクリッキーの Kailh BOX スイッチ 白軸 を選びました。

届いて組み立てているところです。

普段はキーが横にずれているロウスタッガードのキーボードを使っているので、とつぜん縦にずれているカラムスタッガードのキーボードになると全く入力出来ずにだいぶ苦戦しました。さらに思っていたよりもクリッキースイッチが普段使いには音も打鍵感もうるさすぎてちょっと微妙でした。

いったん諦めかけたのですが、試しにリニアスチッチの Alpaca スイッチ に交換してみたところ、これが大当たりで私の中のキーボード観がひっくり返ってしまいました。

rebuild.fm

ちなみにこのキーボードは miyagawa さんが使われているものと同じものです。

第8位 KBD67 Lite

KBD67 Lite R3 Mechanical Keyboard DIY KITkbdfans.com

リニアスイッチこそ至高と気付いてしまったので、慣れているロウスタッガードのキーボードも欲しくなってきました。 そこで id:takkan_m さんが記事に書いてくださっていた KBD67 Lite を購入してみることにしました。

初めての光るキーボードで喜んでいるところです。この頃は写真の撮り方もだいぶひどい。今もよくはなっていないです。

talpkeyboard.net

スイッチは新しいのを試そうと DUROCK L2、キーキャップは Pitta Studio DSA Bluebird Keycaps Set を付けています。

現在は DROP + MITO GMK LASER CUSTOM KEYCAP SET を付けて、スイッチも Cobalt POM Linears に変更してこういう感じになっています。

キーの配列を変更したり、レイヤを使った入力の快適さを知ったのもこのキーボードで、このキーボードを買ってさえいなければこんなことにはならなかったと言える。 今はちょうど R3 をやっているのでみんな買いましょう。

第7位 Drop + OLKB Planck

drop.com

全てのキーが格子状に並んでいるオーソリニアという配列があるということを知って購入してみました。

キーキャップは NP PBT Crayon KEYCAPS SET、スイッチは DUROCK L2 で組んでいます。

実際にオーソリニアを触ってみるとこれもだいぶ慣れなくて苦戦しました。いまだに慣れてないのですが見た目がいいので時折引っ張り出しては練習しています。

現在は TALP KEYBOARD さんで買った名前を忘れたキーキャップに変更してこういう感じの装いになています。 長方形でキーとキーの間が綺麗に整列しているので、もらったステッカーを立てる台としても活躍しています。

スイッチとプレートの相性が悪いのか、なかなか外れなくて無理やり外したところトップハウジングが外れてばらばらになってしまった事件から、スイッチの分解に抵抗がなくなって Lube に踏み出せたのも Planck のおかげです。

第6位 D65 E-COATING GRAY

D65 E-Coating Gray Mechanical Keyboard KITkbdfans.com

重たものが欲しくなって購入したキーボード。HHKBと配列が近いので親近感もあります。

これはかなり手に馴染んだのもあってしばらく常用していたのですが、スイッチをいろいろ試せたのも良かったです。

現在はこういう感じになっていてキャップは WINMIX Cherry Profile 9009 KEYCAPS SETEverglide Aqua King キースイッチ で落ち着いています。一時期は Aqua King こそエンドゲームスイッチだと思っていたのですが、沼はまだまだ深かった。

第5位 The Mark: 65

boardsource.xyz

なんだかんだでサブキーボードとして常用している65%キーボード。見た目よりは軽い。

シルバーのケースに GMK HENNESSEY をのせていて、飽きがこない見た目なのも気に入っています。

スイッチはD65と同様に Aqua King をのせていて、なぜかというと以下のように疑似セパレートで使っていたから。

この使わない縦ラインが現在はアルチザンキーキャップ置き場になっています。

第4位 Casasagi O-ring mount

5z6p.com

ガレージセールで放出されたものを購入しました。

Casasagi は日本の自作キーボードコミュニティで設計されているキーボードで、その基板に3Dプリントのケースを付けたキットです。オーソリニアかつセパレートでO-ringマウントというのがおもしろい。

始めてスイッチをはんだ付けしたキーボードで思い入れがあります。(マクロパッドはあったけど)

ビルドログはこういう感じです。

blog.nishimu.land

真っ黒なケースに GMK WoB を乗せてオタクブラックをキメています。 真っ黒なくせにスイッチは透明で綺麗な色の Everglide Tourmaline Blue Cyan を選んでいるのもポイント。 いま出回っているのは V2.5 でハウジングの色が透明じゃなくなったので少し残念。

第3位 Acperience12

booth.pm

初めてのマクロパッド。とにかく見た目がかっこういいA12です。

blog.nishimu.land

リモートワークではよくZoomなんかでミーティングするわけですが、マウスでクリックしてミュートしたり解除したりするの面倒ですよね。 そういうときにはこういったマクロパッドを使って、ボタン一発で操作できるととってもべんりです。 ここに来てやっとリモートワークに役に立つキーボードが紹介できました。

最初に買った Kailh BOX スイッチ 白軸 を使っています。こういうマクロパッドだとクリッキーも合う気がします。このあと 3Dプリントのケース も付けて完全体になりました。

第2位 M0ii0 / +十

booth.pm

booth.pm

かわいい。とにかくかわいい M0ii0 と +十 です。+十 がマクロパッドの方。

キーの数が極端に少ないので僕には常用は無理なのですが、机に飾っていていつも目の保養になっています。 どちらも実用はしていないものの、スイッチは MMK Frog KeySwitch、キーキャップはPBT Notion で統一しているのがお気に入りポイントです。

ありがたいことに #KEEB_PD でも1位をゲットしました。このとき Something Comforting を聴いていたので名前がよく分からない感じに。 (Spotifyで聴いている曲を表示名にするスクリプトを動かしているため。)

+十 はいまはマクロパッドとしては使っていないのですが、手の届くところに置いてあって考え事をしているときなどにカチャカチャやっています。

第1位 Cornelius

[GB] Corneliusshop.yushakobo.jp

圧倒的な一位は Corne Cherry を開発した id:foostan さんの新作であるところの Cornelius

www.youtube.com

この動画の音を聴いて僕の求めていたものはこれだと確信して争奪戦を勝ち抜きゲットしました。

コルネリ、とにかく打鍵感と音の良さが圧倒的で新しいキーボードを買うモチベーションが下がってしまっているくらいです。

常用するためにいろいろ試してみたのですが、トップハウジングとステムがUHMWPEでものすごく滑らかな打鍵感の Diamond Linear スイッチ とMGプロファイルのキーキャップで落ち着いています。背が高めのキーキャップが音が良くて気に入っています。

よく見るとファンクション列だけでなくて数字列もなくなっているのですが、レイヤを組み合わせることで全く困ることなく常用できています。 逆に数字列があるキーボードに戻ると数字を入力するのが遠くてもどかしく感じるほどに。

Alfred で主要アプリのトグルにショートカットを追加して、レイヤ3に各種ショートカットキーを当てることでマクロパッドすら捨てられて、もうこのキーボードなしでは仕事するのが億劫です。

今のキーマップは こういう感じ です。


2021年は完全にキーボード沼に沈められた年で、おかげさまでリモートワークがとても快適でした。 買ったけど届いていないキーボードやキーキャップがまだまだあるので来年も楽しみです。

本記事を読んでキーボードに興味を持っていただいた方は是非以下の記事や本も読んでみてください。

salicylic-acid3.hatenablog.com keys.recompile.net

あと大好きな :3ildcat さんの YouTube も観てください。

www.youtube.com

残念ながらGroup Buyで販売されていたものは、すでに新品では手に入らないのですがエクストラやR2の可能性もあるので是非探してみてください。


Money Forward 関西拠点 Advent Calendar 2021 - Adventar 、明日は akaneppi🐱採用広報 さんです。採用広報の話楽しみですね。

株式会社マネーフォワード 関西拠点では仲間を募集中です。 いまは転職を考えていないという人でも少しでも興味を持ってもらえたらカジュアル面談で実際にどういう感じなのかを紹介出来るので気軽に連絡ください。

社内用の Slack には #keyboard_playground というチャネルがあり日々キーボードについての情報が垂れ流されているのでキーボードが好きな人の応募もお待ちしております。


この記事は Cornelius (Diamond Linear Switch GPL205g0 lubed / MelGeek MG Ember) で書きました。

Ruby / Ruby on Rails のつまずきポイントを募集しています

さいきんは仕事で Ruby on Rails を使った開発をしているのですが、チームに新しくきてくれた人たちで初めて Ruby on Rails に触れるという人が増えている印象です。 そういった人たちが最初にバリューが出せずに苦悩されているのを見ていて、なんとかキャッチアップの助けになれればと思っています。

どこに何があって、どう調べていいかが分かれば自学習が出来るようになると思っているのですが、それまではサポートがあった方が速そうです。 しかし、自分自信もまだまだ学ぶべきことが多く、どういったポイントを押さえると自学習を後押し出来るのかを的確に示せません。

そこで、初学者の方がどこにつまずくのか、学んでいくなかでどういったポイントが難しかったのかといった話を募集しております。 もしくは有識者の方からのこういった教材が有益だという情報もお待ちしています。

事例を集めて、初学者の人が Ruby / Ruby on Rails を自学習出来るようになるサポートが出来る何かを提供出来るのがゴールです。

コミュニティと飽き性

kyotorb.doorkeeper.jp

今年に入ってからほぼ毎月、月初の日曜日に Kyoto.rb の集まりをやっていて、今日も11月の分を開催した。 最初は id:onk さんと2人だったので、この会を今度どうしますけねみたいな話をしたりしていたが、あとから人が増えて雑談に花が咲いて良い感じになっていた。

Kyoto.rb はもともと Spporo RubyKaigi 2012 に 参加して何かをやりたい気持ちが溢れてしまった僕が作ったコミュニティなんだけれど、頑張りすぎて息切れしてしまって他の人に運用を任せるようになっていった。 その後だんだんぶっちゃけ飽きてきてしまって、はてなに転職してRubyを仕事で触らなくなったの期に完全に離れてしまった。

2つ問題があって、頑張ってやるにはモチベーションが足りなくて継続出来なかったこと。そもそも自分が飽き性でその時々でやりたいことが変わってしまうこと。

頑張ってしまうことについてはだんだん学んできたので最近は何事も出来るだけ省力でやって継続を優先するようにしている。 1月からまた仕事で Ruby を書くようになったので、急にモチベーションが復活して停滞していた Kyoto.rb の復活させた。 そこからは出来るだけ継続することを目標に、毎月もくもく会をやってきて、たまに元気があるときは特別会をやるという運用にしている。 一番の難関はイベントサイトを作ることで、これもコピペで作っているので簡単なはずなんだけれど、なんだかサボりがち。

飽き性なのはこれは仕方なくてもう変えられないとは思っている。飽き性というより興味が移ろい易すぎるんだよなあ。 一番盛り上がるのは何かを決めるまでで、決まったあとは興味を失ってしまうことも多々ある。 最近もあることを手伝うことにしていろいろ調整して方針を決めたら、その途端に正直興味を失ってしまって気が重くなっていたりする。 興味が移ろうことを前提に動いていきたい。

そういう感じでコミュニティを作った本人の性格が出てしまっているのか、 Kyoto.rb もなんども姿を変えては失速してを繰り返している。 コミュニティというはそういう有機的なもので、その時々の姿があっていいとは思うのだけれど、まあなんか続いては欲しいですね。

飽き性のせいにしたけど、自分が内向的で人間関係を閉じがちなのもコミュニティに向いていないところなのかもしれない。

次回は 12月5日(日) です。忘年会LT的なものも計画中。

kyotorb.doorkeeper.jp

京都市内で会議室として使える古民家・寺情報

仕事で必要になって聞いてみたところたくさん情報をいただきました。 良さそうなところばかりなのでしばらく合宿先には困らなさそう。 ありがたや。

細かくリリースする

合計すると7ヶ月分くらいのブランチをビッグバンリリースするという経験をしました。 サービスのリリース時以外だといままでで一番長く生存したブランチかも。

当初の想定だとシュッとリリース出来るつもりで少数で作っていたのが、どんどん膨らんで全員が関わることになって、結果的にこういう感じになったのだけれど、最初から細かくリリース出来るように意識していれば途中でもリリースしてしまうことが出来たはずなので悔やむことが多い。

いまのチームでは、機能単位でブランチを切っておいて、そこにいったん全ての変更を溜めてからまとめて master にマージする風習がある。 変更を確実にテストしてから、masterにマージしたいのでこういうことをしているのだけれど、デメリットも多い気がしている。 ここでいうテストは結合テストと、POによるレビューを指していて、手順に従って人間がポチポチしている。もちろんユニットテストなどの自動テストは書いた上で。

では、実際にどういうデメリットがあるのだろうか。

  • 確認に使う時間の無駄
    • 見る範囲が莫大になるので見落とさないようにするのは至難のわざ
    • プルリクで一度見ているはずなのにまた全体で確認している無駄
  • 問題が起きたときの原因調査にかかる時間の無駄
    • 各プルリクを細かくリリースしていたら、壊れる前にリリースしたものが原因とすぐに分かる
    • 7ヶ月分のブランチをリリースしても、どの差分が問題だったのかぱっと分からない
  • ブランチ管理の無駄
    • 当然、7ヶ月もあればmasterはどんどん進んでいく
    • たびたびコンフリクトするブランチを直すてまが無駄
    • しかもどんどん難易度は上がっていく
  • 開発時のオーバーヘッドの増加
    • ブランチ管理と近いけれど、masterと乖離しまくっているブランチに切り替えるのは大変
    • 今回は特に開発環境への変更が入ったりしていたのでブランチを切り替える毎に環境の再構築が必要だった
    • いくらDocker化していても毎回やるのはつらい
    • コンテキストスイッチも大変になる

こういう悲劇を起こさないように、フィーチャートグルなんかが使えるのだけれど、なかなか導入が進まない。 一因としてはフィーチャトグルを導入することでの、開発の複雑さが増加するのではという漠然とした不安をチームがもっていることが挙げられる。 複雑さが増すことで、開発速度が落ちたり、分岐を間違えて見せてはいけないものが見えてしまうことへの恐怖がありそう。

しかし、よく考えてみると我々は7ヶ月分の巨大なブランチをリリースしたのだ。 この(不要な)偉業を越える難しさはそうそうないのではないだろうか。

巨大なブランチを扱う方が複雑だし、結局リリースまでに起きた問題の対処や、これから起きる不具合への対応を考えると開発速度も遅くなってないだろうか。

いまこそこまめなリリースに取り組むべき時ではないだろうか。