Software engineering from east direction

六本木一丁目で働くソフトウェアエンジニアのブログ

#golangtokyo Go Conference Tokyo 2019 Spring 2次会 参加レポート

golang.tokyo#24 に参加したので、聞いた内容・感想をまとめていきます。

golangtokyo.connpass.com

(※LTトークの時間でバッテリーがあれだったので感想書けず...LTトーク非常におもしろかったです!)

CLI ツールを支える技術 2019 春 by @izumin5210 さん

感想

  • CLIツールを作りたいときに一番選択肢が多いパーサー・設定関連のライブラリどれがおすすめかという話がよかったです。

Go (Ebiten) で実践モバイルゲーム開発 by @hajimehoshi

感想

  • Goでゲームを作るとてもロマンの溢れた話でした
  • Gopher Conference 2019参加チャネルで拝見してた方なのでリアルで見れて個人的な感動がありました。

Chaos Engineeringの手前の話 by @hazumirr

感想

  • chaors engineering の原則が公開されてるのは知らなかったので読んでみたい
  • 実際にやる際の検討ポイントがしれてよかった

gRPC Server with golang by @abemotion

  • gRPCの構造がmodelになる
    • (チョット感じた言葉にならない感想)
      • リクエスト・レスポンスのインターフェースとドメインモデルにそのままなるのが違和感を感じる
      • 外部のインターフェースの関心にロジック自体が影響受けるようなイメージを持ってもやっとしたが、gRPCやるとそういうものなのかな?
  • gRPCのエラー処理、独自のエラーコードが用意されてる
  • gRPCがmiddlewareを様々提供している
  • gRPCで困ったこと
    • NULL非許容

感想

  • gRPCそろそろ試して業務でやるか考えようと思っていたので実装例ありがたい...
  • レイヤ構成とかの考え方は近い感じになっていて共感みがあった
  • gRPC、多言語を挟むときに便利。

cloud.google.com/go/pubsub internal by @izumin5210

感想

  • pub/subの概要をおさらいした上で中の実装こういう事やってるっていうコード読んでいくのがおもしろかったです。
  • 人がコード読んでるのを見るの色々なテクニックが見れて面白いですね。

最後に

会場を提供してくださった freee株式会社 さんありがとうございました!

Go Conference Tokyo 2019 Spring スピーカー参加・聴講感想 #gocon

Go Conference Tokyo 2019 Spring にてスピーカー参加してきました。今回はいつものカンファレンスより準備を早めにやったこともあり、がっつり他の方のトークを聴講できました。純粋なメモ・感想を書いていきます。

発表したSession

"Design considerations for container-based Go applications"という発表をしました。

発表自体の概要や背景については所属企業のブログエントリで公開するので詳しく書きませんが、Gopher君もらえて嬉しかったです。

f:id:khigashigashi:20190518162503j:plain
Gopher君かわいい

聴講Sessions

次のセッションを聴講しました。

  • Keynote "Go Module Proxy Life of a Query"
  • Hacking Go Compiler Internals 2
  • Goによる外部プロセス起動ベストプラクティス及びtimeoutパッケージ徹底解決
  • Dive into Buildkit LLB with Go
  • CPU, Memory and Go

Keynote "Go Module Proxy Life of a Query"

Memo

Impression

Hacking Go Compiler Internals 2

Outline

Memo

  • Lexer
  • Parser
  • Annotated AST construction
  • Typechecking
    • 型チェック
    • 変数・値のみではなく
  • Varitable binding
  • Inlining
  • Escape Analysis
    • new()関数、heapにおかれる
    • 変数定義で確保、stackにおかれる
    • stackにおいたものをheapにおかなきゃという判断
  • Closure Rewriting
  • Walk
  • SSA Generation
    • Go1.7で導入
    • Go1.7以前ではできなかった最適化できる

Impression

Goによる外部プロセス起動ベストプラクティス及びtimeoutパッケージ徹底解決

Outline

Memo

  • コマンドラッパー
    • ghq・mackerel-agentなどコマンドを実行する例
  • コマンド実行
    • os/exec packageを使えば簡単に
    • io,MultiWriter
  • シグナルハンドリング
    • SIGKILL・SIGSTOPはできない
    • SIGTERMで正常終了を促すのがお作法、できなかったらSIGKILL
  • exec.CommandContextの問題は、SIGKILLで強制停止・孫プロセスを停止できない点
  • Songmu/timeout
  • timeout.c
    • SIGCONTを送ることで強制的に再開させる

Impression

  • 本筋ではないですが作ってるライブラリの量がすごい、見習ってがんがん公開していきたいと思いました
  • 今回発表いただいた資料を見ながら公開されているライブラリを読むと更に勉強になりそう。ありがたく勉強させていただきます...!

Dive into Buildkit LLB with Go

Memo

  • Docker18.0.9で正式機能として利用できるBuildKit
  • BuildKitが提供するもの
    • buildctl・buildkidt
  • BuidKitはGoで書かれている
  • BuildKitもurlfave/cli 使ってるんだへぇ
  • LLB
    • BuidKitのコア
    • BuildKit では LLB(low-level builder) に一度変換する。 LLB は DAG 構造
    • grpcで通信・protocol bufferを使っている
  • Opertaionの依存はinputsに定義
  • 。DOT 言語に変換することで GraphViz で可視化できるツールとして llb2dot を作った
  • BuildKitはマルチステージビルドの並列化だけではなく、RUNレベルの1ステップ単位でも共通化できる。
  • Dockerfile2LLB
  • Dockerfileのlinterを作ったりできる

Impression

  • Dockerfileのlinterを作ったりできる、たとえば、「Dockerfile内で環境変数を与えていないか」みたいなlinterを作ることも可能。 僕のトーク内容触れていただいたからには帰って試さなければ…!
  • @po3rin さんのトーク、BuildKit・LLB概要レベルくらいしか知らない僕でも、実際に手を動かせる手ほどきになっていて、めちゃめちゃありがたかった...!
  • コードハイライトどうやってるんだろう?

CPU, Memory and Go

  • sonatard さんの発表

Impression

  • CPU, Memory and Go”のトーク、Goが何をしているかに関してわかりやすく解説いただいていてすごくよかった、後で資料公開頂いたら読み直したい...!
    • 公開いただいた読み返しまくる
  • 大盛況で立ち見勢だったのでメモは取れず

さいごに

Goの様々知見が聞けてめちゃめちゃ良かったです!運営の方々このような素晴らしい場をありがとうございました!

GoLandでgoldenファイルを用いたユニットテストを書く #golang

TL;DR

  • GoLandでgoldenファイルを任意のファイルタイプで認識できるようにする
  • それによって、goldenファイル作成時にGoLandの補完能力を失わないようにする

goldenファイルとは

Go言語でのユニットテスト作成時、JSONHTMLといった用に別ファイルをテストの引数や期待値に必要とするケースがあります。これに対して、.golden拡張子をつけたファイルとして別定義する手段があります。これは、Goの標準ライブラリのテストコード内でも使用されている方法です。

たとえば、TestDiff()というテスト関数内で次のようにJSON文字列を必要するケースを想像してください。

func TestDiff(t *testing.T) {

    want := `
{
  "string": "A",
  "integer": 1
}
`
    // 以降のテストコード
}

そのままテスト関数内に定義してしまうとそのテスト関数の見通しが悪くなってしまうかもしれません。これに対して、goldenファイルを使用する場合は、testdata ディレクトリ配下に.golden拡張子をつけたファイルを配置して使用します。

testdataディレクトリを配置すると、そのディレクトリはパッケージとしてみなされないため、テスト時のみに必要なファイルとしてプロジェクトに配置することができます。

https://golang.org/cmd/go/#hdr-Test_packages

The go tool will ignore a directory named "testdata", making it available to hold ancillary data needed by the tests.

今回はJSON形式のファイルなので、want.json.goldenという名前でJSONファイルを保存します。

{
  "string": "A",
  "integer": 1
}

このように配置することで先程直接JSON文字列を書いていたテストコードは次のようになります。

func TestDiff(t *testing.T) {

    want := getStringByFile(t, "testdata/want.json.golden")

    // 以降のテストコード
}

func getStringByFile(t *testing.T, path string) string {
    t.Helper()

    bs, err := ioutil.ReadFile(path)
    if err != nil {
        t.Fatalf("ioutil.ReadAll(%s) got unexpected error %#v", path, err)
    }
    return string(bs)
}

GoLandでのgoldenファイルに対する設定をする

goldenファイルを用いたテストはこのような比較的に大きくなりがちなファイル形式の際に重宝しているのですが、golden拡張子だとPlain Textとしてのファイルタイプ認識になることにフラストレーションを感じました。そのため筆者は、goldenファイルの命名とGoLandのFile Typesの設定を合わせることで任意のファイルタイプを認識できるように設定しています。

具体的には、*.json.goldenであれば、JSONファイルとして認識するというような設定をしています。実際に、設定方法を見ていきましょう。

まず、GoLandの設定画面を開きましょう。Macであれば、Command + , というショートカットで開きます。そこで、Editor/File Typesの画面へ遷移します。

f:id:khigashigashi:20190427143822p:plain
Editor > File Typesの設定画面

この画面では、ファイル名に対してどのファイルタイプで認識するか設定できます。*.json.goldenJSONファイルだと認識させたいので、JSONの設定に行きます。

f:id:khigashigashi:20190427145750p:plain
File Types: JSON

この拡張子パターンに、*.json.goldenを追加します。

f:id:khigashigashi:20190427145857p:plain
*.json.goldenを追加

この設定によって、JSON形式の文字列を格納するためのgoldenファイルを認識できるようになりました。その他のファイルタイプについても同様です。

まとめ

goldenファイルを使用することでテストの可読性の向上が見込めますが、エディターの力を借りることでテスト作成コストも下げることができます。GoLandを使用している方はひとつ試してみていただけると幸いです。

golangtokyo#23 参加レポート

golang.tokyo #23 参加レポート

TL;DR

  • golang.tokyo #23に参加
  • tenntenn さんのポインタの話がわかりやすかった
  • まだまだGoのポインタわかってなかった。

golang.tokyo #23

平成最後のgolang.tokyoに参加してきました。LT枠で落選してしまったのですが、LT枠は落選しても参加できるとのことでお邪魔しました。

golangtokyo.connpass.com

絶対に分かるポインタ / tenntenn

docs.google.com

Memo

  • 変数
    • メモリ上で管理されている値を保持する領域
  • ポインタ
    • 変数の格納先を表す値、どこにしまってあるか
  • 型の表現方法
  • リテラルのポイント型
    • ex. *struct{N int}
  • ポインタのポインタ
    • **int: *int型のポインタ
  • ポインタ演算
    • &: ポインタ値取得
    • *: ポインタが指す先取得
  • ポインタが必要な理由
    • 代入
  • 内部にポインタ
    • slice, map, channel
  • go help test

Goをはじめるにあたって知っておいてほしいツールやテスト/mom0tomo, micchiebear

Memo

-> % go env GOROOT
/usr/local/opt/go/libexec

Delveを用いたデバッグ & pprofを用いたプロファイリング / 渡邉 光

Memo

感想

tenntennさんのポインタの話がわかっているつもりでもいざ質問されるとしっかり間違えたので、まだまだ基礎を抑え直さないといけないなと反省しました。あと、ベースターズビールがおいしかったです!

PHPerKaigi 2019 の「PHPでJVMに入門する」を聞いて

TL;DR

  • PHPerKaigiでのめもりーさんの「PHPJVMに入門する」がおもしろかった
  • 自分の知らなかったことを調べて残しておく

トークPHPJVMに入門する」

fortee.jp

@m3m0r7さんのPHPJVMに入門するという内容がおもしろかった。PHPJavaを動かすという力強いトーク

自分のトーク時間がちょうど裏で当日現場にて聞けなったので、YouTubeで公開されている動画を拝聴しました。

www.youtube.com

PHPバイトコードを読む方法など、いろいろPHPのことを知らなかったので、今回知らなかったことを調べてみます。

個人的な調べごと

PHPのfloat・doubleについて

トーク内で、PHPのfloat・doubleについて一瞬だけ触れていらっしゃたのあらためて調べてみる。

とりあえず、PHPの公式ドキュメント「浮動小数点数」をこちらに。

www.php.net

このページには、「浮動小数点数の精度」という警告があるんですね。

浮動小数点数の精度は有限です。 システムに依存しますが、PHP は通常 IEEE 754 倍精度フォーマットを使います。 この形式は、1.11e-16 のオーダーでの丸め処理で誤差が発生します。 複雑な算術演算をすると、誤差はさらに大きくなるでしょう。そしてもちろん、 いくつかの演算を組み合わせる場合にも誤差を考慮しなければなりません。

あぁ、よく聞くこのトラップって公式の警告としても掲載されているんですね。

IEEE 754 倍精度フォーマットは、IEEE Standard for Floating-Point Arithmetic、直訳すると「浮動小数点数算術標準」で、浮動小数点の計算で広く採用されている標準規格ですね。

よって、複雑な演算をすると誤差が大きくなる例として、こんな感じですね。

<?php

$iv = 0;
$fv = 0.0;

for ($i = 0; $i < 4000000; $i++) {
    $r = mt_rand(1, 1000);
    $iv += $r;
    $fv += $r / 10;
}
var_dump($iv);
var_dump($fv);
// int(2001061191)
// float(200106119.09999)
// ちょっと値がずれてる

さらに、十進数では正確な小数で表せる有理数、たとえば 0.1 や 0.7 は、 二進数の浮動小数点数としては正確に表現できません。 これは、仮数部をいくら大きくしても同じです。 したがって、それを内部的な二進数表現に変換する際には、どうしても多少精度が落ちてしまいます。

公式ドキュメント内の例を借りるとこういうことですね。

<?php

// 0.1 + 0.7 = 0.8 に見える
var_dump((0.1+0.7)*10);

// 0.1 + 0.7 = 7.9999999999999991118...
// これを切り捨てると7になる
var_dump(floor((0.1+0.7)*10));

精度の高い計算が必要な場合は、任意数学関数: BC Math関数gmp関数を使用するとのこと。トーク内でもgmp関数は紹介されていましたね。

きっと、トーク内で言及されていたfloat・doubleの問題点はもっと深いところにあるかもしれませんが、基礎的なところを抑え直してみました。

refs

バイナリリーディング

トーク中のスライドでバイナリを表示する際のコマンドに xxd を使っていて、「それなんだっけ」って思ったので基礎的なことだろうなと自分を恥じつつ調べます。

www.tutorialspoint.com

16進数dumpするlinuxコマンドですね。

$ man xdd
NAME
       xxd - make a hexdump or do the reverse.

SYNOPSIS
       xxd -h[elp]
       xxd [options] [infile [outfile]]
       xxd -r[evert] [options] [infile [outfile]]

雑に手元にあるGoファイルをxxdでdumpしてみます。

$ xxd main.go
00000000: 7061 636b 6167 6520 6d61 696e 0a0a 696d  package main..im
00000010: 706f 7274 2028 0a09 2267 6974 6875 622e  port (.."github.

バイナリレベルでの調査をしたいときに便利そうだなとおもいました。エミューレータ自作を試みたらこういうシーンに出会うのでしょうか。

refs

vld extension

PHPJavaを読むことで、PHPの中間コードが理解しやすくなるという話がありました。vld extensionの気持ちになれるということなんですが、「なるほど、vld extensionな(知らない)」という自分でしたので調べます。Vulcan Logic Disassemblerの略でvldとのことで、PECLで配布されています。

pecl.php.net

Provides functionality to dump the internal representation of PHP scripts

PHPスクリプトの内部表現をダンプする機能を提供してくれる拡張ということですね。

オペコードを覗いてみる記事で、@syossan27さんが、入門記事を書いてくださっていたので、ありがたく引用させていただきます。

<?php
    echo "Hello, PHP.";

の場合は、こんな感じでオペコードをダンプできるようですね。

$ php -d vld.active=1 -d vld.execute=0 test.php

Finding entry points
Branch analysis from position: 0
Jump found. Position 1 = -2
filename:       /Users/bps/test-php/test.php
function name:  (null)
number of ops:  2
compiled vars:  none
line     #* E I O op                           fetch          ext  return  operands
-------------------------------------------------------------------------------------
   2     0  E >   ECHO                                                     'Hello%2C+PHP.'
   3     1      > RETURN                                                   1

branch: #  0; line:     2-    3; sop:     0; eop:     1; out1:  -2
path #1: 0,

refs

JVM Specification

JVM Specificatonについて言及されていました。JVMの気持ちになった経験がなかったので、少し読みに行ってみます。

docs.oracle.com

Chapter 1 Introductionの歴史の話がエモい気持ちになってよかったです(小並感のある感想)。

https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-1.html#jvms-1.1

感想まとめ

PHPわかっていなかった」という気持ちになったのでたいへん刺激になるトークでした。トーク内の実装紹介スライドにて、「constant pool countは歴史的理由で-1する」という話があって、歴史的理由を調べてみたものの見つけられなかった...。でも、そもそもこの実装の背景を理解できているかというと正直理解できていないので、精進します。

golang.tokyoの「文Go」に「費用対効果の高いユニットテストを実現するためのGoの基礎技法」を寄稿しました #技術書典

TL;DR

  • 技術書典6のgolang.tokyoサークルが出ます。
  • 「費用対効果の高いユニットテストを実現するためのGoの基礎技法」を寄稿しました。

技術書典6に出版する書籍に寄稿

この度、2019年4月14日に開催する技術書典6に参加するgolang.tokyoの新刊に「費用対効果の高いユニットテストを実現するためのGoの基礎技法」というタイトルで寄稿しました。

techbookfest.org

golang.tokyo「文Go」

f:id:khigashigashi:20190411220059p:plain
文Go

Go界隈の方であれば一度は目にしたことのある方々がそれぞれめちゃめちゃ濃い内容を書いてます。(このラインナップに自分がいるのが恐縮すぎるw)

計136ページの大作になっているのでぜひ当日「け27」にお越しください!(レビューしていて勉強になりまくった内容なのですごくおすすめです)

寄稿内容「費用対効果の高いユニットテストを実現するためのGoの基礎技法」

私が寄稿した内容は、ユニットテストの考え方とGoの基礎についてです。私は、ユニットテストに関心があり、所属企業のブログにもGoのAPI開発現場におけるユニットテストTipsにて、ユニットテストに関する現場の実践を共有したりしてます。最近は、基礎となる考え方に興味があり、PHPerKaigi 2019というカンファレンスでは「質」のいいユニットテストを書くためのプラクティスという内容で、ユニットテストの考え方について発表していました。今回寄稿した内容も、そのような考え方とアプローチに着目したものです。
Goは、アサーションが提供されていない点など、他の言語と比較して特徴的な点がいくつかあります。しかし、「Goが何を考えてそうしているのか」・「その考え方は現場でのユニットテストにどのような利点をもたらすのか」という基礎的な点を抑えると、応用的な取り組みも一貫した考えをもって実践できると考えています。

まとめ

ぜひ、「け27 golang.tokyo」まで!

techbookfest.org

(リアルタイム更新中)2019年の目標達成確認と振り返り

超絶フライングで振り返り続けるエントリー、目標に対する進捗・振り返りが更新されていきます。

khigashigashi.hatenablog.com

年初立てた目標の達成状況

目標 現在 備考
PHP系カンファレンスでのロングセッション登壇 Clear PHPerKaigi2019にて30分(longer)
Go系カンファレンスでのセッション登壇 Clear Go Conference Tokyo 2019 Springで20分
合計発表時間300分 170分
OSSを3個以上公開する 1

(2019/3/31時点更新)

登壇記録

count: 13

日付 イベント名 タイトル Type
2019/5/28 CircleCI ユーザーコミュニティミートアップ #4 CircleCI Go Code Inspection LT(5min)
2019/5/27 Go(Un)Conference(Goあんこ)LT大会 6kg Go API Validation error handling LT(10min)
2019/5/18 Go Conference Tokyo 2019 Spring Design considerations for Container based Go application Session(20min)
2019/5/8 表参道Web勉強会 3 TypeScriptで入門するGenerics LT(5min)
2019/4/25 突撃!!隣のアーキテクチャ GoでのAPI開発現場のアーキテクチャ実装事例 LT(5min)
2019/3/29 PHPer Kaigi 2019 「質」のいいユニットテストを書くためのプラクティス Session(30min)
2019/3/27 Docker Meetup Tokyo #29 (Docker Bday #6) Container based application Design Real Practices Session(15min)
2019/3/20 【書籍発売記念】Connehito Marché vol.5 〜PHP市〜 xUnit Test Patternsから学ぶテストアンチパターン LT(10min)
2019/3/1 Mackerel Meetup #13 Health endpoint pattern as application monitoring LT(5min)
2019/2/27 第135回 PHP勉強会@東京 ユニットテスト初心者を脱するために身につけたいN個のこと LT(5min)
2019/2/26 Docker Meetup Tokyo #28 Container-based Application Design Reference and Practice LT(10min)
2019/1/30 第134回 PHP勉強会@東京 Steadily developing CakePHP 4.0 Session(20min)
2019/1/26 PHPカンファレンス仙台2019 テストが辛いを解決するテスト駆動開発のアプローチ Session(30min)

OSS

Contributing

細かいのは省いて主要なところだけ

日付 OSS 内容
2019/1/18 cakephp/doc 3.7移行ガイドページの翻訳

Creating

released repository 内容
2019/4/28 hgsgtk/jsoncmp JSON値の比較ライブラリ、OSSとしての体裁を整えた最初のrepository

技術書執筆

出版日 カテゴリ 内容
2019/4/14 技術書典6 golang.tokyoの「文Go」に「費用対効果の高いユニットテストを実現するためのGoの基礎技法」を寄稿しました #技術書典

公開ブログエントリ

※ イベントレポートは除く

所属企業寄稿

公開日 カテゴリ タイトル
2019/5/22 登壇 Go Conference Tokyo 2019 Spring にて行った発表内容の作り方 #gocon
2019/3/6 監視 アプリケーション監視のパターン「Health エンドポイントパターン」を実践する | 書籍『入門 監視 ―モダンなモニタリングのためのデザインパターン』を読んで
2019/1/16 AWS ECS(Fargate)でコンテナアプリケーションを動かすための設定情報の扱い方

エントリ

公開日 カテゴリ タイトル
2019/4/27 Go GoLandでgoldenファイルを用いたユニットテストを書く #golang
2019/4/17 PHP PHPerKaigi 2019 の「PHPでJVMに入門する」を聞いて
2019/3/21 Unit Test xUnit Test Patternsから学ぶユニットテストについて目指すべき6つのゴール on Qiita
2019/3/17 Unit Test xUnit Test Patternsから学ぶ12個のユニットテストの原則 on Qiita

小ネタ

公開日 カテゴリ タイトル
2019/3/9 Go Goのテーブル駆動テストをちょっと見やすくする on Medium
2019/3/8 PHP PHPの空配列をJSONの空オブジェクトとしてエンコードしたい時 on Qiita

各Q振り返り

2Q (2019/4~2019/6)

golangtokyo への寄稿という形で人生初の技術書執筆デビューできました。今年中に技術書典などで技術同人誌を書きたいと目標としていたので達成感です。PHPerKaigiの登壇から間髪入れずに締め切りが来た形なので相当しんどかったんですが、相当自分の中の言語化が進んだので非常にいい機会でした。また、尊敬しているGopherの方々と技術書執筆という形で協働できたのが非常にエキサイティングな時間でした。もっとこういう楽しい時間を増やしたいのでOSS活動に本腰入れて取り組みます。 また、今年目標にしてたGo Conferenceでのセッション登壇も達成できたので良かったです。しかし、まだまだGopherとしてまだまだなので引き続き精進です。

1Q (2019/1~2019/3)

仕事は昨年リリースしたサービスの運用基盤系の整備・機能拡張についての目標を無事達成でき成果の出せた3ヶ月になったはず。

それ以外の関心事の中心は、3ヶ月間ずっと、PHPer Kaigi 2019トーク「質」のいいユニットテストを書くためのプラクティス』の論理をどうやって頭の中で整理・構成するかに集中していました。普段、現場で言葉として発せられる「テストの質」について「その本質・意味はなんなんだ」というなにやら壮大なテーマをモヤモヤ考えていました。途中のいくつかのカンファレンス・勉強会・ブログでのアウトプットを通じて少しずつ考えを整理していって、今回の着地点に落ち着いたことに達成感を感じています。
ただし、同時に多大なる挫折感も感じていて、まだまだ自分では言語化できていないことが今回の30分の発表で入れた内容の何百倍もある状態です。この分野はまだまだやっていかないといけないことが多いですね。

そのほか、達成感を感じているのはDocker界隈など少しずつ下のレイヤでのアウトプットができるようになってきたことです。Container based application Design Real Practicesという発表を、Docker Meetup Tokyo #29 (Docker Bday #6)にお邪魔してさせていただいたりと、一介のサーバーサイドエンジニアの視点を入り口としてでも、自分が見える世界を少し広げられたことは嬉しく思います。

また、個人的にとってチャレンジングだったことは、アメリカ・サンディエゴで開催されるGopher Conference 2019や、今年日本で開催されるCakeFestへのセッショントーク応募ですね。英語ぺらぺらで自信があるわけでもないですが思い切って25分/30分のセッション応募したのは勇気がいりましたが行動してよかったと今では思っています。Gopher Conferenceのほうは残念ながら落選でしたので現在LT応募を量産しています。

しかし、マネージャー氏に高々と宣言した「今年はOSS作っていきます!」という言葉は今Q虚しくも「有言不実行」に終わってしまったので、来Qはやっていきします。

総括して、今Qも後悔なく生ききれたなという満足感です。