mercari.go #2 参加メモ #mercarigo - My External Storage
所感 今回はQAやインフラよりの部分でGoがどのように使われているか、使うことができるかの紹介が多かった。 サービス自体のコードだけでなく、開発の効率化にもしっかりと開発工数をあけて問題解決に取り組んでいるのを聞くことができてさすがだなという感じだった。 インフラまわりのミドルウェアやツールでもGoの1バイナリになる成果物、高い平行性などの特徴を活かして課題解決を行なっているということだった。 開発中にある日常的な悩みをGoでどんどん解決できているのは羨ましい（と言っていないで自分もやらないといけない）。 また、GraphQLの発表もあり、実装で考慮すべき点など非常にわかりやすかった。 GraphQLを遊ぶにはGitHub API v4 APIのExplorerがインタラクティブな補完・仕様の参照ができて良いらしい。これはGraphQLに限らずAPI仕様を公開するときはこのようなUXを提供
テストコードとスピードのトレードオフ。加えてGoのAPIのテストについて。
「テスト 書くべき」って検索すると玉石混交な記事がわんさか出てくるのですが、そもそもなんでこういった議論は常に紛糾するのでしょうか？ 僕個人としては、テストコードというものへの捉え方はその現場の思想に密に依存しており、その前提を明示しないまま議論を進めると、「スピード感」「技術者の習熟度」「自社開発か否か」などの様々な変数の違いによって意見が食い違い、容易に銃弾飛び交う戦場と化す、と考えています。 そのため、この議論を始めるのは下手をするとパンドラの箱をパカっと開けて、収集つかないことになるのかなーと思っています。 僕の置かれている前提ということで、流れ弾で死にたくないのでまず僕の前提を明らかにします。 個人的な趣味趣向の話まず個人的な立場を表明しておきますが、僕は書くまでは、億劫なんだけど書き始めたら割と好きで黙々と書いていたくなるタイプです。かといって、仕様がピョンピョン変わる現場での
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
