モブプログラミングに向いてない私の話

新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。

日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング(ないし類似のプラクティス)に取り組んできました。

モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。

www.agilealliance.org

ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・チームにも適用できない体験というそのこと自体を共有したいと考えて書いています。

続きを読む

HTTP 100 Continue in Go

使おうとするたびに忘れて調べなおすのでメモ。

HTTP のレスポンスコード 100 は、クライアントが大きなデータを送る前に送信ヘッダレベルで リクエストの受付が可能か調べて、処理可能ならいったん返すためにある。

用途例: Authorization ヘッダによる認証, Content-Length によるサイズチェック

Go の http.Client では TransportExpectContinueTimeout を 0 以上に設定し、リクエストヘッダに Expect: 100-continue を入れれば、自動で 100 Continue を待機 してからボディを送るようになる。

http.Server は request.Body から読みだすと自動で 100 Continue 応答をクライアントに投げる。 なので 200 以外のエラーは Body から読みだす前にヘッダをチェックして返すようにすれば良い。

To mock, or not to mock, that is the question

さて、テストコードなんて書きたくなかった私ですが、世の流れには逆らえず今はせっせとテストコードを量産しています。 開発完了=試験完了=出荷可能が求められる忙しない世の中でありますから。

目下開発しているのは Kubernetes 向けのネットワークソフトウェア Coil のバージョン 2 なんですが、この開発では main 文以外はすべて自動テストする徹底ぶりです。他にも近年様々にテストコードを書いてきた過程で、以下の知見を得るに至りました。

  1. 外部依存はなるべく実物を使う
    • etcd を使うなら etcd を用意、ネットワークをいじるなら network namespace を用意、...
  2. 内部依存はなるべくインタフェースで依存注入する

多分この結論に似たことはあちこちで言われている気はするのですが、結論に至った理由が大事と思うため、以下少し書きます。 あ、以下モックと言ってる用語は専門的には stub だったり test double だったりするかもしれませんが、細かいことは気にしないでください。

続きを読む

kubebuilder v2 で webhook 開発

仕事で、データセンターのアーキテクチャを刷新するプロジェクトを進めてます。 Kubernetes を中心としているので、必然的に Kubernetes 上で動作するアプリケーションを開発する機会があります。

Kubernetes は API サーバー (kube-apiserver) にリソースを登録して、他のプログラムは API サーバー上のリソースを監視して動く Hub & Spoke アーキテクチャを特徴としています。

https://d33wubrfki0l68.cloudfront.net/518e18713c865fe67a5f23fc64260806d72b38f5/61d75/images/docs/post-ccm-arch.png

出展:https://kubernetes.io/docs/concepts/architecture/cloud-controller/

Kubernetes の動作をカスタマイズするには、API サーバーの動作に手を入れる必要があります。kube-apiserver はそのための仕組みとして、通常の API に加えて以下を提供しています。

今回のお題はこの中の Webhook 実装についてです。長くて専門的かつ TL;DR もないのでご注意ください。

続きを読む

code-server で実現する Windows 上で Linux 向けの快適な Go 開発環境

業務で Linux 向けの Go プログラムを多数開発しています。

しかしながら、開発している機材の OS は好きこのんで Windows です。 在宅から勤務するときに、Windows のリモートデスクトップが最強すぎるので手放せないのが大きな理由です。

そんなわけで、Windows の Hyper-V という機能で Ubuntu を仮想マシンとして動作させ、Emacs で長年開発していました。

しかし近年、モニタも 4K 32 インチと大きくなりましたしメモリも 32 GB 搭載されていますし、なにより Visual Studio Code のような高機能 IDE が手軽に利用できる状況でありながら、ろくにカスタマイズをしない Emacs で開発を続けるのも怠慢かなと考え、「WSL で快適な Go 開発環境を作る」という記事に書いたように Windows + WSL + Visual Studio Code という開発環境を整えました。

開発しているコードは Linux 向けですので、いくら Go がクロスコンパイルが得意といっても本当は Ubuntu 上で開発できるのにこしたことはありません。Windows にせざるを得なかったのは、Ubuntu 上で動作させる Visual Studio Code を 4K の解像度で X プロトコルで表示させるとラグが大きすぎて実用に耐えなかったためでした。

しかし先日、Visual Studio Code から Electron を取り除き、WebSocket でブラウザに画面を表示させるようにする code-server が OSS でリリースされたことにより状況は一変しました。X プロトコルよりもずっと効率的に画面操作ができるので、Chrome on Windows + Ubuntu on Hyper-V + code-server を使うことで以下が実現するのです。

  • Visual Studio Code で手軽に高度な IDE を使って開発
  • Windows のリモートデスクトップ機能で自宅からも快適に開発
  • Ubuntu 上の Go でコンパイルするので高速&クロスコンパイル不要
  • ラグなし!

環境構築手順を以下にメモしておきます。

続きを読む

Go で GitHub v4 GraphQL API を使って draft pull request を自動作成

先日 GitHub に「開発中のためまだマージするべきでない」プルリクエストを作ることができる Draft Pull Request 機能が追加されました。

今の業務では複数人でモブプロしたりする関係で、開発途中のブランチを GitHub に push してひとまずプルリクエストを作ることが良くあります。従来は、そういったプルリクエストを作る都度 "wip" ラベルをつけたり [WIP] とタイトルを変えたりとひと手間かかっていました。その手間を無くせるので、draft pull request は待望の機能です。

もうひとつ、業務ではプルリクエストは working tree から git neco review という拡張コマンドで自動作成するようにしています。いちいち画面を触る必要がなくとても便利です。自然な考えとして、git neco draft というコマンドを打てば draft pull request を自動作成したくなります。

長くなってきたので後の話を一行でまとめると、既存のいいライブラリがなかったので GitHub GraphQL API v4 を Go 言語からさくっと叩いて draft pull request を自動作成するツールを作ってめでたしめでたし、です。内容に興味がある人は続きをどうぞ。

続きを読む

WSL で快適な Go 開発環境を作る

個人的な備忘録です。

仕事上 Ubuntu をターゲットに Go のプログラム開発をする必要があるのですが、従前 Windows デスクトップに Hyper-V の Ubuntu で Emacs で開発していたところをVisual Studio Code(vscode) に開発環境を変えたいと考えました。理由は省略。

最初は Ubuntu 上に vscode を入れて X 越し(VcXsrv)で試してみたのですが大画面だと描画速度が遅すぎてストレスたまってダメでした。

仕方がないので Windows 上の vscode で WSL の Ubuntu を併用しつつネイティブ Windows 開発環境を構築することにしました。大分手順が多くなってきたのでメモとして残します。

続きを読む