ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

入社して3ヶ月

前回

blog.chaspy.me

3ヶ月経って書くと過去の僕が言っているので書くが、正直この頃期待していた課題は解消できていない。また、周囲の期待を明確に話した訳でもないが、期待以下となっている。

問題は新しいことの学び方より、既存システムの理解だ。

これが満足にできていないので、雑用も、メインのタスクも、チームメンバーのPRレビューも時間がかかる。そして失敗もする。(した)

これをじっくりやるべきなのが最初の3ヶ月だったはずだが、情けない。

とある個別の(なぜか他とは違う)サービスに関しては、検証環境構築タスクを通じて、1日じっくり時間をかけたおかげで理解できた。これが早い遅いかはともかく、既存のドキュメントやコードをとにかく時間をかけさえすれば理解はできるので、他でもそうすべきである。

1ヶ月時点で振り返って、2Q(6-9月)のgoal設定を個人的にしたんだが、課題が明確に見えていなかったなぁと思う、あってはいるんだけど、ふわっとしている。

さっき一人反省会をしたが、Perfect Understanding Fridayを作って、何か1つ「完全に理解した」を作って、アウトプットする取り組みをしたい。今の課題の末端としてはタイムマネジメントで、集中タイムを意図的に作り出せていないというのもあるので、その解消も兼ねる。

そのアウトプットは個人的に作ったQuipper SRE Handbookかもしれないし、単に雑多なメモを書き下しissueかもしれない。が、アウトプットをして自分の理解内容をメンバーに見てもらうことと、他チームや今後入ってくるひとに有益なものになるようにしたい。

スペシャリティを発揮し、「お前にしかできないことは何よ?」に答えられるようになるまではもう少し時間がかかりそうで、そのためにはまず既存の理解をしっかりしたい。

次は「入社して半年」。既存のことなら任せろ、さらにこのことは俺に任せろ、となっていることを願う。

Ubuntu18.04でH2OとNginxをベンチマークする環境構築

ベンチマークした、とまで胸張って言えないのがアレなんですが。

エントリとしてまとめてないのですが、先日ISUCON8に参加しまして、見事に役に立たなかったという話がありまして。

クローズドの勉強会でISUCONってのがあるんだよーってシェアしました。

で、何で何もできなかったってそもそも性能を計測した経験ないよねとなり。

H2Oもはじめましてだったので少し興味わいたのもあって、戦わせてみるかぁ、という安易な考え。

それをMeguro.rbでLTしてきました。

特に知見らしい知見もないんですが、H2Oのほうが特にいじらずともいい感じ、という世間の感覚値とは近いと思いました。

終わった後無駄に頑張ってplaybook化したりしたんですが別にbashのままでよかったな、install script...

github.com

とはいえ、Ubuntu18.04VPSでこの2つをベンチマークしたいよーって人には割と役立つスクリプトだと思うので、何かの縁でたどり着いた方はどうぞ。

個人的には今回はまだまだ序章で、来年に向けてじっくりweb serverのパフォーマンスと向き合うための砂場づくりができてよかったーって感じです。

続編はどこで発表しようかなー。

Git squashを簡単にするコマンド「qs」v1.0.0をReleaseした

github.com

はい。もはや3回目ですね。

blog.chaspy.me

blog.chaspy.me

CHANGELOGを見るに今回はたいしたことしてない。本当に。ドキュメントとか。コメント消したりとかぐらい。

で、明日クローズドの勉強会で僕ではなく@kamontiaが発表するのだけれど、僕も何か喋ったらということで資料作りましたよということを供養するブログ記事です。

今回のOSS開発、ちゃんと最後までモチベーションを維持してできたのは、ペアでやったからこそ相談できたことも大きいけど、何より僕たち自身が欲しいツールだったことが一番大きいと思う。普通に普段から使っている。「〜の勉強のためにこれやってみようか」なんてものはなく。欲しいものを実現するために作って、+α知らない技術にも挑戦できた。(今回はGo言語)

心がけた点として、Pull RequestのReviewとMergeをできるだけ早くした点がある。これは前の記事でも書いたが、同じチームの@yuya-takeyamaさんがレビューめっちゃ早かったり、上司の@masatomoとの面談で「レビューって意外と重要度高い仕事なんですよ、誰かのブロッカーになるからね」と言われていたこともあって、特に意識した。この点はとてもよかったと思う。

というわけで今後も@kamontiaとペアでOSS活動に励もうと思います!


追記。@kamontiaの資料。

「Docker / Kubernetes 実践コンテナ開発入門」を読んだ

Docker/Kubernetes 実践コンテナ開発入門

Docker/Kubernetes 実践コンテナ開発入門

読んだ。雑に記録。

1-3章はDockerについて。ふむふむと軽く目を通した感じ。

ところでdocker containerコマンドって今まで使ったことなかったです。

で、4章と5章がSwarm。これまで使ったことなかった。

docker in dockerで、swarmのmanagerとnodeとregistryをそれぞれdockerの上に作って、そこでいろいろ遊ぶのはすごいうまくやってるデモだなぁと思った。

でも正直作者もいうとおりswarmはkubernetesにつなぐための布石でしかなくて、一応podだとかの概念の理解の助けにはなるとはいえ、面倒な部分、本番運用に耐えない部分を、そうそれを解決するんです〜って感じで、swarmを今後の人生で使うことはないなと思った。

あと動かすのにサンプルコードがgihyoさんのサイトからDLできたり、適宜githubからcloneしたりできるんだけどこれがとってもやりづらくて。gihyoさんからダウンロードするコードはディレクトリが章節ごとに細かくわかれすぎて面倒だったし、swarmのmanagerにいちいちコード送ってやらないといけないのも面倒だった(最初からしこんでおいてくれ)

で、swarmさんと最初で最後の出会いをしたところでkubernetes編。短いボリュームでリソースの概念をささっとさらえるし、これまで動かしてきたサンプルアプリも動くしで、とても良い例だと思った。

もちろんGKEも使ったけど、Docker for Mackubernetesがちゃんと動くじゃん!っていうのを体感したので、もうminikubeじゃなくていいね、と思った。

最後8章以降はロギングとかDockerホストの運用、チューニングとか障害対応とか。軽量なDockerイメージを作るモチベーションが個人的には今あんまりない。軽いにこしたことはないけど。

10章のDockerの様々な活用方法で、CLIツールをコンテナで入れるっていうの、それ、するかなぁって思った。bashで書くならgistにおいて使いたい人が使えばいいし、そうでなければGoで書いてgo getでええやんって思ったり。開発環境の構築をDocker(docker-compose)でやるのは賛成だけどね。

で、いろんなひとが書評に書いていたようにコラムが結構いい。何がよかったかは忘れたけど、コラムが読み物として楽しいのでまずコラムだけ読むぐらいでもいいかもしれない。

で、誰におすすめかというとDockerやKubernetes名前聞いたことあるけどあんまり何が嬉しいかわかってないしどう動くかもわかってない、って人にちょうどいいと思った。僕はKubernetesまわりの操作の復習のつもりで読みました。コラムが面白かった。

でもgihyoさんこれミスが多くて3件ほどフィードバック送りました。僕が読んでる時点で正誤表も盛りだくさんだったので校閲頑張ってほしいというお気持ちです。(本を書く大変さは想像でも死ねるし、進化の早いこの分野の作者の功績は大変大きく、リスペクトはあります、その上での意見です)

で、そうこうしてる間に青山さんのコレが届くのでまたすっと読もうかなと思います。

Kubernetes完全ガイド (impress top gear)

Kubernetes完全ガイド (impress top gear)

gitで複数のコミットをまとめるコマンド「qs」のv0.2.0をReleaseした

前回

blog.chaspy.me

した。

github.com

qsのまじめな解説はOwnerの@kamontiaが書いてくれている!

qiita.com

で、gihub-changelog-generatorで生成したCHANGELOGを眺めるに、まぁ前回のリリースの時に気になっていたことは結構消化できていて、まずはMVPというか、最低限でリリースして、あとで治すというのはとっても大事だなぁと思ったのでありました。

github.com

とはいえ、Goのコードが全然イケてない上にGoのテストをかけていないので、そのへんは次のリリースに向けて細々と変えていきたいところ。

で、このコマンド何か、というと、複数のコミットをまとめる、すなわちsquash/fixupするのを楽にするツールです。

branch切って、pushして、よっしゃreview依頼をアッーーーってなって1文字ミスってるやんけってなったとき、再度コミットして、git rebase -iしてfixupにするっていうのを一瞬でできるようになります。まぁ普通に自分でもわりと使っていて、自分が欲しいツールが作れて満足しています。go getで取れるのでみなさんぜひ使ってみてください。

github.com

2018年9月

なんか元気が出てきたからか急に忙しくなってきた予感がするので何するんだっけ何したいんだっけ本当にできるんだっけって感じでいったん書いて落ち着くということをしようと思う。

先月

8月、なんか元気が出てきたので目標達成ってことにしよう。

blog.chaspy.me

8月は特に目標を立てずにいこうと思う。まずは、通常営業、いつものペースを取り戻す。

イベントごと

  • 9/7-8 Builderscon 2018参加、フル参加はせず6,7割聴こうかなって感じ。

builderscon.io

  • 9/4〜18 とある翻訳書の翻訳レビューボランティア。刊行が決まったあとぐらいにあらためて何か書きます。SRE的にとっても関係のある内容なので、純粋に読める+翻訳に貢献できる/翻訳の難しさを体験できるので、win-winな感じ。

  • 9/16 isucon2018参加。社内で募集していて、こんな学びのチャンスはないと思いエイヤで挙手。楽しみだ。

isucon.net

ちなみにペアは9月に入社された @ujihisaと、同じく現職の@sat0yu。とても優秀なwevdev2人と一緒にできて幸せでしかない。SREとして強みを発揮しないといけないコンテストなので、何かしら貢献できるといいな。。。

  • 9/20 主催のクローズド勉強会でISUCONネタでLT
  • 同じく一緒に作ってるkamontia/qsについて@kamontiaが発表するので、その資料レビューと、あとv1.0.0のrelease。その前に9/7(今日だ!)にv0.2.0のrelease。

  • 9/27 弊社開催のMeguro.rbでLT。GitHubのアクティビティを振り返るために、簡単にレポートを生成するツールをRubyで作る予定。

絶対間に合わないけど読みたい本。

kubernetes復習。ささっと終えたい。

Docker/Kubernetes 実践コンテナ開発入門

Docker/Kubernetes 実践コンテナ開発入門

読み終えたけどまとめてないやつ。

CAREER SKILLS ソフトウェア開発者の完全キャリアガイド

CAREER SKILLS ソフトウェア開発者の完全キャリアガイド

なんかアーキテクチャ的なやつ。絶対読めないな。。。

進化的アーキテクチャ ―絶え間ない変化を支える

進化的アーキテクチャ ―絶え間ない変化を支える

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

手を動かしていこ。

複数のコミットをsquashするコマンド「qs(quick squash)」を作った

前回書いたこれ、がv0.1.0 releaseされた。

blog.chaspy.me

コマンド自体のまじめな解説は作者の@kamontiaが書いてくれてる。

qiita.com

このエントリではどちらかというとこのOSS作りで感じたことを中心に綴りたいと思う。

OSSを作ってリリースすること

実は、はじめてだ。今回も、collaboratorとして参加していて、自分1人で作ったわけでもない。

ただ散々OSSを利用しておいて、供給側にまわっていないということは、この業界にいながら罪悪感に近い引っかかりを得ていた。別のこのOSSがまだ誰かに使われたわけでもないが、大きな一歩だと思った。

モチベーションと作ったもの

github.com

はなから2人で作ろう、としてはじめたものなので、organizationのnamespaceでやってもよかったが、なんだか中途半端な格好になることを前回別の(挫折した)アプリで感じたので、今回はkamontia以下のnamespaceで作った。別にそこにこだわりは僕としてはない。

基本的にラフにpushして、CI通るまで細かくなおして、通ったらcommitをまとめてforce pushする、という開発スタイルでやることが多いので、わりとsquashする機会は多い。

自分が本当に欲しいものを作ることこそがOSS活動だと思うので、今回欲しいもの、作りたいテーマがうまく見つかったのが一番の幸運であり、リリースまでこぎつけた成功要因だと思う。

ちなみにまあ、普通に使える。

使用例

適当に1ファイル追加するコミットが4つあったとして、それをまとめたい。

$ qs -n 2 -d -m "squashed"
WARN[0000] [ 3] pickup -> pickup  9e94b2d fileA
WARN[0000] [ 2] pickup -> pickup  262207a fileB
WARN[0000] [ 1] pickup -> squash  a4bede9 fixup! fileB
WARN[0000] [ 0] pickup -> squash  fcdda5f fixup! fileB
Do you squash the above commits?(y/n)

-n 2はHEAD..HEAD~2をまとめるという意味だ。-dはdebug option。-mはsquashed commitのメッセージだ。-mがない場合まとめ先の262207aのメッセージが使われるようになる。

squashといいつつ、内部実装的にはfixupでまとめてからメッセージ変更をする擬似的なsqaushになっている。

結果はこうなる。

$ git log --oneline
0cbbd9d (HEAD -> master) squashed
262207a fileB
9e94b2d fileA

gitはまぁ使いはじめて長いが、いまだにrebase時の順番とlogの順番が逆なのは結構気にくわないし毎回混乱している。慣れない。

複数人開発

とはいっても2人だけど。

開発はissueとPRベースで進めた。別にissueはなくてもいいが、あとあとlabelとかで整理する意味であったほうがいい気がしたのであえて採用した。わりとこれいるんじゃない?と思いつくと、slackに発言してpin、気づいたひとがissueを立てる。(備忘をかねている)そしてPRでrefarenceして実装、review、mergeという流れだ。まぁ、きっと一般的な開発フローだと思う。

現職で上司との1on1で「レビューって案外重要なんですよね、他の人のブロッカーになるから」ということを聞いて、確かにそうだなぁと思った。今回、2人だからこそ意識的にPRのレビューは素早くすることを心がけた。だいたい1日に2回はチェックする時間を作って、うまくいけば半日以内にmergeできるサイクル感を目指した。

プロダクトとしても、個人としても、停滞はモチベーション下がるじゃない?initial commitは14days agoになっている。そこから100 commit、29のPRをまわせたのはなかなかよかったのではないかと思う、実際結構稼働はかけたけどね。それでも1日1h〜2hぐらいだし、夏休みで触ってない日もあるし。

反省点としては、初期で結構デカいfeatureを実装しているときに、テストの変更をしてしまって、そのケアに時間がかかってしまったことが悔やまれる。テストやるならやるで最初に同期して作ってしまってやる、ということをすべきだったなと思う。立ち上げからinitial commitまでリモートペアプロでやったのはよかったけど、そこからしばらくはパラレルにやらず、assignはするけど順番にやったほうがよかったのかなぁと思った

テスト

今回はgitという外部コマンドと連携するプロダクトなので、UnitTest(は、まだない)というよりはE2Eテスト的なものが必要だ。今回はそれをbashで実装した。

github.com

最初はひどいもんだったけど、release前にリファクタをして、マシにしたって感じ。

テスト1回ごとにディレクトリを作成し、git initからサンプルコミットを作って、qsコマンドを実行して、期待値と比較する、ことを繰り返す。テストフレームワークを自前で実装した感じ。このへんはrspecを普段はよく使うのでそのへんの印象で作っている。

テストの数は少ないが、これがあるとないとではかなり違う。最初の頃はそれこそ手作業でテスト用のgit履歴を作っていたから、はやめに取り掛かってよかったと思う。もちろん大好きで大嫌いなCircleCIを使っている。

Go言語

正直、雰囲気で選択したし、まぁ書いたが、Tour of GOを半端にやったぐらいで、何も身についたとは言えない。実際、今のコードはbashでできることを3倍ぐらいの行数をかけてGoで実装したようなもんで、Go言語である必要性はまったく活かせていない(し別に理解もしていない)状況だ。

ただ、便利なCLI toolのためのframework、codegangsta/cliには助かったし、go getで配れるのは本当に楽だよなぁと思うので、今のところ享受しているメリットはそのあたり。

今回v0.1.0はとりあえず動くものをリリース、次でリファクタの予定なので、しっかりGoを学んで「なんだこのクソコード」と思えるようになってからリファクタしたい。

おわりに

2週間で動く、(自分にとって)有用なコマンドを作れたのは、なかなかない成功体験だと思う。今回の成功要因はこんなところか。

  • プロジェクトのinitializeをリモペアで合意し、同期的にやれたこと
  • PR -> mergeサイクルを可能な限り高速化したこと
  • 作りたいものが決して技術の学習用、とかではなく、本当に自分たちが欲しいものであったこと

特に一番最後がもっとも大切なことだと思った。技術は、解決したい課題に対する、手段である、どこまでも。

ペアを組んだのは本当に気のおけない友人であることももちろん大きい。ありがとう。

feedback

わりと破壊的な変更をするコマンドなので、慎重に、といいつつ、まぁまぁ使えるんじゃないかなあと思うので、実際に使ってみて、feedbackをissueにくれるとうれしい。GitHubのissueでもtwitterのリプ/DMでも構いません。よろしくお願いします。

github.com

twitter.com