Go Conference 2018 Spring & メルカリオフィスに行ってきた。

はじめに

メルカリ スカラーシップの一環で地方の学生 Gopher 代表として Gocon に参加してきました!

会場は日本橋にあるサイボウズ本社。実は去年のサマーインターンシップでサイボウズさんにお世話になっていたため、オフィス訪問自体は二回目でした。

サマーインターンに参加したときから変わった点として、エントランスが桜坂のごとく春の陽気に包まれており、Gocon Spring に相応しい会場となっていました。とても素晴らしい会場を用意していただきありがとうございます!

ここで花見ができそう(小並感)
ブラインドの向こう側の景色。あいにくの天気だけど眺めは最高
アリキリの後藤さんと井上さんもサイボウ樹パークに仲間入りしていた

気になったセッション

セッション全体については他の方がまとめてくださると信じて、私が気になったセッションについて3つピックアップします。

Go at Cybozu by ymmt

本セッションは、全社員の貸出PCのスペックを Corei7 6700, Memory 32GiB, Storage NVMe SSD 512GB にした ymmt (読み: わいえむえむてぃ) さんや ymmt さんが所属していた SRE チームが中心となって開発を進めている cybozy-go および Go のプロダクションコードをどのように管理しているかという内容でした。

先述した通り私はサイボウズのサマーインターンに参加したのですが、そのときの所属先がちょうど SRE チームで cybozu-go のとある OSS に機能追加を行いました。そのインターンではプロダクションユースのコードには触らなかったので、今回プロダクションユースの Go コードをどのように管理しているか、その概要を知る良い機会となりました。

サイボウズではプロダクション用の Go コードを管理するために次の3つの戦略をとっているそうです。

  1. Mono-repository
  2. Mirroring
  3. Frameworks

1つ目の Mono-repository は、プロダクションの Go コードを単一リポジトリで管理するというもので、こうすることでパッケージ内にベンダリングディレクトリを持つ必要がなくなりアップグレード等のメンテナンスがしやすくなります。

2つの目の Mirroring では、github.com が落ちた時やオペミスでリポジトリを削除してしまっても別の場所でミラーリングしておくことで可用性を担保することができるようになります。また、バックアップではなくミラーリングをすることでミラーリング元とミラーリング先で常に同じコードを使ってビルドすることができます。

3つ目の Frameworks は、サイボウズの SRE チームが Go のコードに求める要件は Go のプロダクトごとに共通しているので、その共通部分をライブラリとして切り出して再利用しようというものです。
例えば github.com/cybozu-go/cmd はCLIツールを作成する際に使う超便利なライブラリで、サイボウズのエンジニアが Go で CLI ツールを作る際は必ず用いているそうです。

この他にも OSS で多数の Go 製ライブラリ(特にミドルウェアが多い)を提供しているのでお時間があるときに読むと色々と学びがあると思います。

コードジェネレートとの付き合い方 by pei0804

ぺい さんが現在絶賛コントリビュート中の swaggo/swag について、OSS にコントリビュートする際の注意点や swag にコントリビュートしていたときに直面した問題とその解決方法について発表されていました。

余談ですが、ぺいさんは私が昨年 VOYAGE GROUP の Treasure でインターンをしていたときに TA としていらっしゃっていたので、今回は先生を見つめる生徒のようにしっかりと目を凝らして発表を見ていました(余談の余談ですが Go で開発ができる長期インターン Treasure は現在絶賛エントリー受付中です!)。

swag はコメントとして記述されている API 基本情報から Swagger ドキュメントを吐くツールで API 設計をする際のオトモとしての使用が期待されています。

Swagger ドキュメントをご存じない方向けに説明すると、Swagger ドキュメントとは “RESTful API documentation” のことで、すなわちドキュメントしてとして閲覧できるだけでなく、ドキュメント上で RESTful API クライアントとしても振る舞う、そんなドキュメントのことを指します。

Swagger ドキュメントを生成するには大抵 YAML か JSON 形式の Swagger Specification を手の温もりでガリガリ書きますが、swag はそれをソースコードのコメントとして記述することで自動でジェネレートしてくれる、便利なツールです。

今回のセッションでは swag の仕組み、つまりコメント記述から Swagger ドキュメントを生成するまでに必要な処理を開発する過程で苦労した点を説明して下さいました。上述の通り API ドキュメントはコメントとして記述するため、コメント自体は標準パッケージ go/ast で取得できますが、取得したコメントをパースする処理は自前で書かなければいけなかったため、そこで苦労したとのことです。説明の詳細についてはぜひ発表資料をご覧いただければなと思います。

私がこの説明で疑問に思った点をいくつか挙げておきます。

  • https://github.com/swaggo/swag/blob/master/parser.go の L91 と L121 の strings.Split(comment.Text(), "\n") は、処理をまとめることができるのでは?
    → PR 出しました(https://github.com/swaggo/swag/pull/100
    → 無事 Merge されました!
  • https://github.com/swaggo/swag/blob/master/operation.go#L94 について、正規表現で頑張ってるけど、正規表現を実行したあとの処理で何番目にどういう必須要素が来るって決め打ちしてあるから、結局 strings.Fields で区切るのと Backward Compatibility の担保レベルは変わらない気がするけど、どうなんだろう?(もういっそのこと Lexer, Parser を作ったほうがry)
  • isNotRecurringNestStruct で、過去に参照した struct の文字列を slice に溜めてループ検知を行っているが、map の方がループ検知性能が高いのでは?(時間計算量は前者がO(N)、後者がO(1))
    → 正直実用ではそこまで長いループはないと思うので、そこまでパフォーマンスに影響しないし無視して良い。

go-selfupdate-github でツールを「自己アップデート」できるようにする by ドッグ

Go CLI ツールのアップデートについて。今までのやり方は一長一短で、GitHub のリリースページから latest stable を取ってくるやり方で唯一の欠点だった手動ダウンロードの箇所を自動化すれば万事解決じゃね?というのがこの TL の趣旨でした。

デフォルトではメジャーバージョンの stable を取って来ますが、挙動を細かく変えることも可能らしいです。例えば、メジャーバージョン間の Backward Compatibility を心配してマイナーバージョンの stable にアップデートするまでに留めておきたいときに使えそうですね。

また、vgo の依存関係解決戦略 Minimum Version Selection とのバッティングをどのようにして解決するのかも今後の見所です。

セッション全体の感想

今回のカンファレンスは途中2セッションが同時に行われる機会があり、私はメイン会場である Room1 のほうにずっといようと思っていましたが、知り合い(pei0804 さん)が登壇するということで途中で Room2 のほうに移りました。見逃したセッションの中にも面白そうなものはいくつかあったのですが、後日 crash.academy さんが撮影した両部屋の録画映像が公開されるので、それまで楽しみを取っておくことにします。

セッション全体として今回は実践的な内容が多かった印象で、普段プロダクションのコードを書かない私にとって、プロダクションで使うライブラリや特殊なプロダクション環境だからこそ使う技術について知れたという面でとても実りのあるカンファレンスでした。

一方で、vgo や Goの wasm サポートなど最新の Go の動向に沿った内容が少なかったので、次回の GoCon では Go の中身の話ももっと聞きたいなぁと思いました。

メルカリのエンジニアと話してみて

メルカリ スカラーシップのおまけとしてメルカリのエンジニアとランチ会をしたりオフィス見学をしてきました。

棒立ちなのは気にしないでw

メルカリ スカラーシップ について

@tenntenn さんいわく、「応募ハードルが高く今回の応募は思ったより少なかった」とのことでした。

しかし、「採用ポイントは、Go で何かしら自分で動いている人でカンファレンスの内容を聞いて何となくでも理解できそうな人」とも話されていたので、Go に興味があってカンファレンスに行きたいけど地方からじゃ金銭的に厳しいよぉ~という方は、一通り Go を勉強して、いくつかツールなりサービスなりを作ってから応募してみると比較的採用されやすいのかなと思います(※これをやれば必ず採用されるという保証はないので、今の成果に満足せず開発を続けましょう)。

Go を勉強し始めるときは今回のセッションの内の一つ、kaneshin さんの「 How to write Go code」が参考になるかもしれませんね!

Pairs のシステムすごい

次回のメルカリ スカラーシップではもっと応募者が増えると良いですね(人事の方にはご負担をおかけ致します)。

メルカリのエンジニアの印象

私は渋谷の企業ばかりインターンに行っていたので、渋谷のエンジニアに比べるとメルカリのエンジニアは比較的落ち着いていているなぁと感じました(※どっちが良くてどっちが悪いと言っているわけではありません。それぞれに良さがあるので、最終的に就職する際は自分が働きたい雰囲気に合った会社を選べば良いと思います)。

戦利品

メルカリで売っちゃだめですよ

さいごに

GoCon を企画していただいた運営のみなさん、会場のセッティングをしていただいたサイボウズ社員のみなさん、オフィスツアーやランチ会、交通費の支給や宿泊の手配をしていただいたメルカリの社員のみなさん、そして GoCon で登壇していただいた発表者のみなさん、改めてここでお礼申し上げたいと思います。ありがとうございました!

バイトからインターンからカンファレンスまでずっと Go に生かされてきたし、来春から東京の会社で働くことになるし(卒業できれば)、いつかは私も登壇してみたいなぁ。