初めてのGo製CLIツール作成、初めてのOSS公開に込められた物語

この記事はGMOペパボエンジニア Advent Calendar 2021の15日目の記事です。

昨日はToshifumi Tsutsumiさんの入社から一年、ペパボはどうですか？に答えるでした。
ペパボにいるとインプット、アウトプットが出来てる方々の集まりで本当に刺激的ですよね。…そして、評価資料がんばりましょう。

さて、今回、記事にするのは掲題の2つの「初めて」についてと、作成したGo製CLIツールの紹介です。
2つの「初めて」とは、1つ目はGo製CLIツールを自分で作成したこと、2つ目はそれをOSSとして公開したことです。

What is takolabel

まず、そのGo製CLIツールについて紹介します。

tnagatomi/takolabel
https://github.com/tnagatomi/takolabel

名前はtakolabelと言って、GitHubのマスコットであるOctocatがタコとネコの合体であることから（割と安易に）takoを、ラベルを操作するツールなのでlabelを取って、takolabelと名付けました。
後になって英語圏の人に伝わりにくいかもと少し後悔していたりもしますが、Kubernetesなんて名前のソフトウェアがあるぐらいなので良いかなと思ったりしています。

このツールが何をやってくれるか短く言うと、「複数のGitHubリポジトリに渡ってのラベル操作」です。
例えば、A、B、Cというリポジトリがあって、X、Y、Zというラベルをそれぞれのリポジトリに一括で作成したい、といった時にそれを実現してくれるというものです。YAMLにリポジトリとラベルを指定して操作します。GitHub Enterprise Serverにも対応しています。

ここでは、なぜそのようなツールが必要になったかについて説明します。

ツールが生まれたきっかけ

このツールが生まれたきっかけとしては、私が所属しているGMOペパボ ホスティング事業部 ISR (Internal System Reliability) チームにて、運用業務のコスト可視化というタスクがありました。
前提として、GMOペパボ ホスティング事業部では全パートナーが割り当てたタスクをGitHub Issues上で議論や過程を記録しながら進行させるのが基本になっています。そういうことから、コストを可視化するためにはIssue上で分類や消費時間を記録すれば計測できるのではないかとチームで話し合われました。
その結果、サービスや用途ごとに異なる複数のリポジトリにGitHub Issuesに計測用の分類、消費時間を表すラベルを貼った上で、Google Sheetsにエクスポート、それをさらにGoogle Data Studioに取り込みレポートを作成するという仕組みを実現しました（こちらについては別に改めて紹介できたらなと思っています）。
その過程の、GitHub Issuesにラベルを貼るという作業を手動で行うのは大変なので、それを自動化するために生まれたものです。
最終的には、思った通りにラベルを複数のリポジトリに一括で作成することができ、ツールとしての役目を無事果たすことができました。

Goについて

なぜこのツールにGoを選んだかということについては色々とありますが、ホスティング事業部として今後バックエンドを中心に採用していく言語であること、実行ファイルがシングルバイナリであることからCLIツールとして適していること、個人的に学んでみたい言語のリストに入っていたこと、が挙げられます。

結果として、ツールの作成を通じてDXとして非常に満足のいくものがありました。
まずは言語の売りである簡潔性がとにかく素晴らしいです。学習にかかる時間がかなり少なかったですし、覚えることが少ない分、コードも読みやすく仕上げることができます。
良く言及されるエラーハンドリングも個人的には何も苦ではない感じです。
IDEとの親和性も高く、ツールチェインについてもシンプルで、言語としての完成度の高さを嫌というほど実感しています。

そういうわけで、これから自分で書いていくプログラムで採用していくことも増えていくだろうなと思っています。CLIツール以外でも使ってみたいですね。
色んな言語を使ったり学んできて、使う言語にこだわりのない方なのですが、この言語については惚れてしまいました。

あとはGoルーチンを使った並行処理の強みについてはまだ活かせていないので、その辺りも勉強していきたいと思っています。

OSSとして

2つ目の初であるOSSとしてですが、こちらは主に2人の会社の先輩に助力をいただきました。

まずは、Fukuoka.go#17での発表でも触れましたが、CIフレンドリーなDBドキュメントツールであるtblsを代表プロダクトに持つk1lowに、環境変数の命名や設定ファイルの書き方といった点を中心に、様々なアドバイスをいただけました。このプロダクトを社内Slackで公開した時に、「え、めちゃいい！」と言っていただけたこと、非常に嬉しかったです。

次に、チームの先輩である、お手軽にTLS証明書の情報を引けるcertを作ったgenkiroidには設計のアドバイスをいただきました。現在のコードの状態を見て、自分ならこうするという例を提示していただき、責務の分離や構造体の定義、関数とメソッドの使い分けといったことを教えていただきました。仕事上でもいつも的確な意見をいただけていて、私の中でロールモデルな存在です。

お2人とも貴重なプライベートの時間を使ってプロダクトを見ていただいた上で助言をいただけて、最高の福利厚生だなと思っています。いや〜ほんとありがたいです。この場を借りてお礼させていただきます。

takolabelのこれから

そんなtakolabelですが、現在のところ必要ドリブンで、ラベルの作成、削除、空にする、という3つの操作ができるにとどまっています。これからも操作を拡張したり、使いやすくしたり、リファクタリングしていけたらと思っています。

もちろんPull Requestsもお待ちしております！

まとめ

この記事を通じて、1つの小さなプロダクトにも、物語があるのだということを感じ取っていただけたらなと思います。
そして、Goで書くことも、自身のOSSを持つことも、自分次第でなんとでもなることだと分かり、挑戦して良かったなと思っています。こうしてAdvent Calendarのネタにもなっていることですしね。

Who's next?

さて、明日のGMOペパボエンジニア Advent Calendar 2021の16日目の担当はAkihito Ikedaです。
彼はISUCON11でISUCONに初参加した時の盟友です。何を書いてくれるんでしょうね。楽しみです。

2021年冬季休暇にやりたいこととか近況とか

ここのところ仕事もプライベートも忙しくてなかなかプライベートな時間でスキルアップをできていない。ただ1年中突っ走る生活もしたくないので、プライベートなスキルアップは余裕のある時でいいかなと思っている。仕事を通じて十分スキルアップさせてもらっているということもあり。
人生で何を大事にするかなんて問いも浮かんだりしている。その辺については前にも少し書いた。

それはさておき、少し気が早いが冬季休暇にやりたいことをNotionページに書き出していっている。
まずやりたいこととしてはGatsby Starter Blogほぼデフォルトのこのブログをもっと充実させたいのが一つ。そして、開発しているGo製OSS takolabelを改善すること。あとは密かに狙っているghへのコントリビュート。そして遊びでは今のMicrosoftが出してRTS界の重鎮Relicが開発したということで興味を持って購入したAge of Empires IVをプレイすること。
休みって毎回あっという間に終わってやりたいことの20%もできずに終わるのだけど、無為に過ごすよりはある程度目標を立てておいた方が有意義に過ごせるだろうなと。

2021年もカウントダウンが始まってきた。このままいい年にしたいものである。

Vimを始めとして環境を見直してみた

僕は開発環境にはJetBrains IDEsを使って、その他のテキスト編集にはVimを使ったりVisual Studio Codeを使ったりといったことをやっているのだけど、ふと使う道具を少なくしようとVisual Studio Codeは使わずに、がっつりした開発以外のテキスト編集やスクリプト作成などにはVimを使おうと思い立った。高機能なVisual Studio Codeを単なるテキストエディターとしか使えておらず、Vimはカスタマイズや操作を組み立てるのが楽しかったり、ターミナルから抜け出さなくて良いというのが理由。

それでまずは6年前に読んだ実践Vim（の英語改訂版）を読み返した。プラグインの機能はほとんど使用せずに様々な操作が可能なことを教えてくれるこの本はVim wayを知る上で本当にいい本だと思う。新たな学びもあったけど、ふとした時に出てくる自信のない操作も多い（マクロとか）。

あとはVimを使った開発の動画を観たりした。良かったのはこの2本: tmuxとvimによる開発作業フロー (動画) | 週休７日で働きたい、 【解説】開発ライブ実況 #1 (Vim / Go) 編 by メルペイ Architect チーム Backend エンジニア #mercari_codecast | メルカリエンジニアリング。特にメルカリの方のやつは作業が速すぎてRTSのプロゲーマーを観ているようだった。

んでそのままの勢いに実践Vimと同じ著者が書いたVim 8とNeovimについてのModern Vimを買って読んだ。といっても "Craft Your Development Environment" と副題がついているように、開発環境向けの機能やプラグインの紹介が多く、僕の利用目的とは合わない感じだったのでそういうプラグインもあるんだな、Neovimにはそういう機能があるのねー、程度にざっと読んだ。

動画を観た影響もあり、Vimで開発もやってしまったらかっこいいなーと思いつつ、カスタマイズや操作の修練も行き過ぎるとけっこうダルいなと思ってしまったし、JetBrainsのAll Products Packにお金を納めたばかりだったので一本化はやめることにした。

そして出来上がったVimの環境なのだけど、とりあえずNeovimにcoc.nvimを入れてLSPによる恩恵に預かることにはしたのだけど、コンフィグやプラグインはかなりミニマルな構成にした。昔入れたプラグインやキーバインドも使ってないものはごっそり捨てた（dotfilesはこちら）。

あとはtmuxについてtmux 2を読み返したけどそんなに発見が無くて十分使いこなせてる感を感じたあと、Tao of tmuxをざっと読んだり、fzfを使った便利なコマンド無いかなーと探したり（結局使いたいと思うものは増えなかった）といったことをやっていた。

とりあえずVimの環境はスタートラインに立てたので、あとは必要に応じてカスタマイズしたり習熟していきたいと思う。というこの記事をNeovimで書いたのであった。

ISUCON11でISUCONに初参加した

ISUCON11に同僚の @akht_ikd と2人チーム「team”渇き”」として出場した。
結果としては58450点の58位で予選落ちだった。

詳細なレポートは @akht_ikd がブログに書いてくれたので個人としての感想などを。

まず、過去問などをやったり他の人がやったことを調べるにつれて、自分の思っていた以上に幅広く深い知識が要求されるコンテストだということが明らかになっていき、まだまだ知ることが無数にあるのだなということを痛感した。
また、近年は学生で上位に入る方々も多く、世の中には本当に優秀な人々がいるのだなぁということも知れた。

チームの面でいうと、ISUCONに出てみないかと声をかけたところ、即座にのってくれた @akht_ikd には本当に感謝している。
スクリプトを作ってくれたり、やることリストをまとめてくれたり、競技中の改善にしろ、かなり頼りっきりだった。今回楽しめるレベルで参加できたのは彼によるところが非常に大きい。本当にありがとうございます。

大会前は過去問をビデオ通話を繋ぎながら一日かけて一緒に解いたりして、部活みたいな面白さがあって良かった。
まだまだ自分自身のスキルは足りないが、こうやって一緒に行動を共にできる仲間がいることに感謝。

大会が終わった後の大会公式Discordでの感想戦の話なども分からないことが多かった。個人としては自分の足りなさをさらに実感する初参加となった。チームメイトに頼りっきりになってしまったことも反省している。
分からないことがドサッと来ると頭や手が動かなくなる癖があるので、物事を分解して各個撃破できるスキルをもっと身につけなければと思う。

渇きが増した大会だった。実力を今よりもっとつけて、来年もまた参加したい。

将来の生活の質より毎日の生活の質

この連休中、ずっと料理との付き合い方に向き合っていた。

去年の10月に初めての一人暮らしを始めて、最初の頃は楽しかった料理も、だんだんと面倒なものに思えてきて、特に夜の料理は仕事終わりで疲れている中、コードを書いたり勉強したりする気力や時間を奪う邪魔者になってしまっていた。
ついには料理を放棄して、朝シリアル、昼レトルト丼、夜冷凍弁当という全く料理をしない生活を数週間ほど続けていた。結果的に、因果関係は定かではないが、調子があまり良くない状態になっていた。

このままではまずいと思い、夜に料理をせずに栄養があって美味しいものを食べるということをテーマに、ホットクックをレンタルしてみたりと色々と策を練った。週末に副菜を作り置きして、朝にホットクックで夜に出来上がる予約調理をするという方法を考えたが、大量の作り置きがかえって負担となりあまり良いとは思えず、これといった解は出せずに時間だけが過ぎていった。

そんな時ふと、夜は勉強せずに料理をして、くつろぐだけの時間にしたらどうだろうか、という案が思い浮かんだ。それならば料理は邪魔者ではなく、むしろ楽しむものとして付き合うことができる。

そう考えるとなんだか途端に気が楽になった。更にそこから派生して、毎日の生活の質を落としてまでスキルアップに勤しんだ結果、将来にそれだけの価値のある生活が待っていると言えるのだろうか、と思えてきた。

僕はふと思い立って極端なことをやりがちな癖がある。自分を追い込めば何者かになれるのではないかと、他は捨て去って一本に集中してしまいたいと発作的に思うことがあるのだ。しかし結局それは持続可能なものでなく、調子をくずしたりして頓挫して続かないことが多い。 以前に一流エンジニアなんて目指さなくていいのかもなんて記事を書いたことがあるが、その時も疲弊してしまったあとに書いたものだ。

将来の生活の質なんて約束されていないのだから、毎日の生活を思う存分楽しんで、毎日の生活の質を高めたほうがいいのではないか。そんな気持ちになってきた。

だからといって全くスキルアップの時間を無くすのではない。朝をスキルアップの時間にするのだ。毎晩早く寝て毎朝早く起きて、ベースの練習をして、運動して、無理のない範囲でスキルアップをやっていく。なんだかこれを書いているだけで、明日からが楽しみになってきた。

さて、連休が終わる。今夜は早速豚キムチを作って食べた。なかなか美味しかった。
明日からは同僚氏と朝活をやっていく予定だ。早起きしていいスタートを切っていきたい。毎日の生活の質を高めていくのだ。

個人Webアプリ作成という荒野に立った

const writeWebAppWithStrongWill = true; で宣言したとおり、Webアプリ作りに着手している。

技術スタックは所属するペパボ ホスティング事業部でこれから使っていくものに沿っていく方針。ひとまずTypeScriptとNext.jsを使うことは確定している。

アプリの肝となるノードを描画するUIが必要なので色々と検討した結果、https://github.com/wbkd/react-flow を使うことに決めた。この辺のライブラリー、ドキュメントがあまり充実していないので使いながら覚えていくしかなさそう。

ノードUIライブラリも決まったので、ひとまず npx create-next-app したあと、ESLintとPrettierを導入したところまで進めた。ルール多すぎてどう設定したらいいか分からん状態だったけど、そのことをTwitterでつぶやいたらアドバイスいただけて、ESLintとPrettierの共存方法が分かり、ESLintはrecommendedを使ってルールはあとから追加していく形で良さそうと分かった。

次はMaterial-UIを導入しようとしているのだけど、Next.jsのCustom AppやらCustom Documentが分からん、むしろNext.js何も分からん状態になっている。 ReactとNext.jsは半年ほど前に1回チュートリアルをやったのだけど、完全に忘れてしまっているのでもう1周しようと思い、ひとまずReactのチュートリアルを終えた。
モダンなReactの書き方を教えてくれるヘルシンキ大学の Full stack open もまた1周するか迷っているところ。

学習しながら作るの、体系的に学ぶ癖のある僕にはさじ加減が難しいのだけど、最初から全部を把握することは諦めたほうがいいだろうし、あまりチュートリアル煉獄には陥りたくないので、つまみ食いしながらアプリを作っていきたいと思う。

やってくぞー。

const writeWebAppWithStrongWill = true;

同僚たちと毎週夜にCode Completeの読書会をやっているのだけど、本編自体は早めに終わったあと、僕の「雑談いいですか？」という一言から、仕事とプライベートでやっていることについて色んな話をした。

その中で、GoやらTypeScriptやらLinuxやらサーバー運用やら、やりたいことがありすぎて何をやっていくべきか見失っているみたいな話をした時に、ずっと温めていたあるWebアプリの話をしたら、「それいいじゃないですか」と言ってもらえた。

自分でもなかなかのアイデアだとは思っていたけど、客観的にアイデアの段階で評価してもらえたので、これはやっていくしかないという気持ちになった。

作るとすればTypeScript + Next.jsで作ろうと思っているのだけど、業務の中でもTypeScriptはこれからやっていく必要がありそうだし、まずはこのWebアプリ作りにフォーカスして、必要ドリブンで学習しながら作っていこうと思う。

常時リモートワークの中で人と話す機会が少なくなっている中、人と話す中で自分の中に眠っているものを発見できたりと、やはり人と話すというのはいいものだなと思った。

毎日時間を作ってこの温めてきたWebアプリを作り上げていこうと思う。やり遂げるのだ。