GoのAPIのテストにおける共通処理
GoのAPIを書くとき、参考になるユニットテストの話は非常によく見ます。Table Driven Testをしましょうとか、サブテストの実行とか、そのあたりの話はたくさん書かれています。 また、テストキャッシュなども出てきましたので、ユニットテスト周りの機能・ノウハウは充実していると感じてます。 一方で、httptestを使ってテストサーバーを立て、リクエスト/レスポンスの内容を検証する場合、単一のリクエストを検証する程度のサンプルにとどまっていたり、あまり共通でこういう処理を書いてるよ、みたいなノウハウがなく、自前で一から書くとなると非常に腰が重くなります。 事実自分はそういう経験をしました。そういった共通処理は普段internalパッケージの中の、testutilsとしてまとめる、などしています。 今回はGoで上記のようなテストを書く場合、どういう共通処理が必要となったかをテーマとして
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
mercari/datastore実戦投入
DatastoreについてみなさまGCPをお使いになっているでしょうか。 GCPにはバックエンドのDBとしてCloudSQLというRDBと、NoSQLであるDatastoreというのがあります。 周囲の事例を聞く限りは、マスターデータなど変化が少なかったり、seedデータ的なものを用意しなければならないものをのぞいて、基本的にDatastoreを利用している印象です。 また、GAEで開発する場合はinternalなAPIからDatastoreを利用できる一方、GKEなどからは、GCPの外部向けAPIを呼び出すことでデータを送受信します。 さて、自分はいつもGoでAPIを書くのがいいよ！と触れ回ってるわけですが、GCP上で開発を進める際には前述の通りDBにはDatastoreを使っています。 このDatastoreですが、そのまま使うと自前でキーを発行する必要があったり、値をキャッシュしたり
「今年は…何か大きめのOSSにコントリビュートしたいですね」
これはポエム。 先日、晴れてGoにContributeできまして、積年の目標であった「なんか大きめのOSSにコントリビュートする」を達成した。 これは前から本当にやってみたかったことで、Issueを立ててはCloseされ、をRubyやらGoやらで何度かやった末のコントリビュート。 割と一個のマイルストーンを経た感じがして、個人的には感慨がある。 OSSにコントリビュートしてみたいそもそも、プログラミング初めてからというもの、「Rubyにpull-req送ってます」とか、言語そのものへのコミットにはかなりの憧れを感じていて、社会人になる前後からというもの、3年前くらいから、何か面談とかで目標を聞かれるたびに、ずっと「技術的には…言語とか有名なソフトウェアへのコミットをしてみたいですね…」と言っていた。 とはいうものの、心理的障壁が高くて、自分のような技術力でできる気がしなかったのと、ソースを
AWSで秘密定数を外部に公開せず環境変数として定義するためのGo製ツール、「ssm2env」作った
ssm2env - Environments injection tool for AWS EC2, with SSM (EC2 Parameter Store). 詳細環境ごとに異なる秘密情報をAPIに渡す際、その管理方法は、twelve-factor appにもある通りデプロイ対象のサーバー内部の環境変数として定義するべき。 ただ、自動化されたデプロイフローでは、どういった手順で秘密情報を渡せばいいか悩むことが多い。 自分が考えた範囲では、 1. AWSのSSMにTerraform経由*1でシークレットな変数を設定 2. APIのデプロイ時にSSMから特定prefixのついたパラメーターを取得 3. パラメーターを全て環境変数として読み込ませる 4. APIが起動する際に秘密情報を定数として環境変数から読み込む*1) 正確にはCircleCIの環境変数設定に事前に入れた状態で、Circ
kazeburo/choconと、それを支えるnet/httpの実装について
【資料公開します】AWS Dev Day Tokyo 2017 にて登壇しました／choconの簡単なご紹介 - Mercari Engineering Blog こんにちは。SREの @ kazeburo です。2017年5月31日から6月2日にAWS Summit Tokyo 2017と同時に開催された「AWS Dev Day Tokyo 2017」に登壇しました。 登壇する機会をいただき、ま… 先日、というか昨日、この資料が流れてきまして、Private Networkの外部との通信を効率良く行うためのミドルウェア、choconというproxyサーバーが紹介されていました。SSL, HTTP/2を加味した上での超シンプルで高速なforward proxyサーバー実装という印象です。 使い方やAPIの叩き方は上記のリンクを参考にしていただくとして、やたらマイクロな実装でなぜこうも高速に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
