テストコードとスピードのトレードオフ。加えてGoのAPIのテストについて。
「テスト 書くべき」って検索すると玉石混交な記事がわんさか出てくるのですが、そもそもなんでこういった議論は常に紛糾するのでしょうか？ 僕個人としては、テストコードというものへの捉え方はその現場の思想に密に依存しており、その前提を明示しないまま議論を進めると、「スピード感」「技術者の習熟度」「自社開発か否か」などの様々な変数の違いによって意見が食い違い、容易に銃弾飛び交う戦場と化す、と考えています。 そのため、この議論を始めるのは下手をするとパンドラの箱をパカっと開けて、収集つかないことになるのかなーと思っています。 僕の置かれている前提ということで、流れ弾で死にたくないのでまず僕の前提を明らかにします。 個人的な趣味趣向の話まず個人的な立場を表明しておきますが、僕は書くまでは、億劫なんだけど書き始めたら割と好きで黙々と書いていたくなるタイプです。かといって、仕様がピョンピョン変わる現場での
最近、クエリビルダーを使うのがだるい
クエリビルダーやORMを使うのは基本的に良いこと。 特に開発初期とかはレビューの時間も足りず、クソみたいなクエリを書いてしまったりするので、それを防止するためにも、ライブラリでリスクを担保してあげるのは大事なこと。てか大体は慢心によってそういうの使わないって選択すると失敗すると思う。僕は失敗する自信がある。 自分もGoで開発する時、MySQLに対してのクエリを書く場合は、以下のクエリビルダーを使っている。一部ビルダーでJOINが使えなかったり、サブクエリの書き方が特殊だったりするが、それ以外はだいぶライトな実装で満足している。 ただ、最近サービスもすくすく育ち、レビュー体制が堅実になっていく動きの中で、クエリビルダーを使うのがダルくなってきた。 なんでかというと、多分以下の2つの理由でだるい。 サービス規模に応じて諸事情を孕んだ複雑な実装が生まれるが、その複雑さをクエリが吸収してしまい、メ
Goのreflectパッケージはいつ使うのか
Goを書いていて、実際のユースケースに遭遇するまでメリットが実感できないものとして、reflectパッケージが挙げられると思います。 実際のところ、reflectパッケージで取れる情報についてはいろんな記事でまとまっているものの、じゃあそれを使って何ができるんだ、実益があるのかという点を体感する機会は人によりけりです。 よくある説明と違和感「メタプロ的なことができるぜ」「構造体の情報を取得してあれこれできるぜ」という説明を受けることがありました。 ただ、僕的にはいまいちイメージが掴めずにいました。おまけにパフォーマンスに負の影響があるから基本的には使わないものとして認識している方が多いと思います。 lestrratさんの少し前の資料とかを見て、そんな感じのイメージでいました。 Goを学習した時に、goroutineとかは利用場面に比較的に早くから遭遇できる一方、reflectパッケージはい
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
プログラミングとUIデザインの境界、およびデザインの環境設定について
今回言いたいこと・UIデザインとそれを書き起こすプログラミングの乖離は、いくらわかってるつもりでも想定より大きくなる ・工数や実装都合上、泣く泣く見た目を変えざるをえない場合のデザイナーのストレスは、スピード優先で設計がおろそかになったときのエンジニアにかかるストレスより大きいのではないか ・雑にプロトタイプを出していい時代は終わってるのでは？と思うので、デザインを勉強していくべき 「デザインを勉強したい」 学生の頃から、dribbbleやbehance、デザイナーブログをみるのが大好きで、「うわーこんなかっこいいロゴ思いつかないよ、すげー」とか、「フォントの微差によく気を使ってるんだなー」とか、「このサイトの余白は過剰だけど、こっちはいい塩梅だなー」とか、そういうのがかなり気になってしまうタイプでした。 というと聞こえがいいのですが、結果的にエンジニアの道を選んで、UIは実装しながら考え
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ですが、そのまま使うと自前でキーを発行する必要があったり、値をキャッシュしたり
エンジニアはどのように他のアプリのUXを参考にすべきか
問題意識エンジニアのタイプを分けるとき、大雑把に「サービス志向」と「技術志向」みたいな分け方をすることが、僕の周りではよくあります。 個人的にはこの分け方は必ずしも良いものとは言えないと思います。少しエンジニアのことをサービスと距離のある人種として捉えてるように感じるからです。 技術志向だからってサービスのことを考えてないということではなく、「よりセキュアな技術を採用する」「効率的で安全なデプロイができるフローを構築する」などなど、技術向上を通じてユーザー体験をよくしよう、としているはずです。 ただ、デザインを良くしたり読み込みスピードを早くしたりなど、「目に見える範囲で改善する施策」を考え、実行しなければ、プロデューサー的な人からすれば「何やってんだろうな〜」と、エンジニアはブラックボックス的な人に見えてしまうこともあると思います。 じゃあ他のアプリをいじってみたりして、サービス勘みたい
Goでサーバーレス動画変換
概要よくGoogle App Engineに関する記事を書くのですが、今回はAWSです。 APIサーバーでGoを使うことももちろんありますが、他にもgo-apexでLambdaファンクションを書く場面というのもあると思います。 以前go-apexのdeployについての記事を書いたので、それは下記を別途ご覧ください。 今回はElastic Transcoder(動画のエンコーダ)を例にサーバーレスにGoが役立つ実例を紹介します。 やりたいことS3に動画をアップロードするアップロードの通知を元にlambdaが呼ばれるElasticTranscoderを呼ぶエンコード結果をS3に保存するというフローです。今回扱うのは、3の部分です。1,2,4の部分は別途AWSの設定が必要で、個人的にはterraformでやるべきだと思っています。 go-apexでのエンコード処理まずlambdaの中で真っ先に
GAEでプロジェクト間 or ローカルにDatastoreのデータをコピーする
ほんの些細な見た目の違いで、「UI良さげだな〜」という思い込みが崩れることがあります。 エンジニアは、最適なユーザー体験を実現するべく、その錯覚をローカル開発の時点から目指すべきです。 以前、自分でGo製のDBレプリケーションツールを作成して、この問題を解決しました。 ですが、最近AppEngineを触ってる自分からすると、果たしてどうやればデータをコピーできるのか、ましてやDatastoreともなるとMySQLとかと違ってインターフェースが違うのでは、困る！と思っていました。 しかし、AppEngineでDatastoreを使っている場合、これは非常に簡単に解消可能な問題でした。 事前準備Remote APIの有効化事前準備として、AppEngineのRemote APIというものに対して、アクセスする窓口を作る必要があります。API経由でDatastoreを叩くためです。 今回はGoの
ARアプリについての雑感
概要2017iOS11になったのでARアプリをちょくちょくインストールしているが大変楽しい。 出たてなのもあってまだ母数は少ないけど、どれを触ってもダメだなーというのはなく新鮮さに溢れてる。 個人的な興味もそうだけど、自分が今身を置いてる部署も新規事業について考えるところなので、触っておくに越したことはない。 今回ストアにフィーチャーされてないがそれなりに有名なアプリも含めて、アプリの傾向なり体験の問題とかを感じたので、いずれ誰かと話す時用にメモを残す。 個人的な分類既存のアプリは大まかに分類して、 空間計測空間ペイント規定モデルの設置と鑑賞単純なモデル設置だけでない箱庭の設置などの用途でアプリが使用できる。 空間計測AirMeasureとかがこれ。
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の叩き方は上記のリンクを参考にしていただくとして、やたらマイクロな実装でなぜこうも高速に
Goで作るDBレプリケーションツール
gopli - DB replication tool to synchronize data with multi environments written in Golang. ツールの名前はgopli (go replication)で、意図どおりの名前ですね。 これは何tomlで書いた、ssh/db接続用の設定ファイルを元に、特定の環境間でデータを同期させるツールです。今の所MySQLのみ対応で、postgresqlに対応しろと言われたものの、なかなか手が回っていない状況です。 使い方は簡単で、 まず以下のように、 sshでのサーバーへの接続と、MySQLへの接続設定をtomlで書きます。 [database] [database.local] host = "localhost" management_system = "mysql" name = "app_developmen
『みんなのGo言語【現場で使える実践テクニック】』読み終わったが、良かったです。
みんなのGo言語読み終わりました。 各位、最近レビュー書いている方は著者の方から献本されているが、僕はそんなことはなく普通に購入した。 なんか先行販売してるところが少なからずあるらしい、という情報が上記のツイートから得られた。 このツイート見たときたまたま池袋にいて、「池袋のジュンク堂ならあるのでは？」と考えて行ったら、あった。 ブックファーストにはなかった。僕は本が好きで、しょっちゅうジュンク堂行ってたがやはり素晴らしい店だとわかる。 Go言語、コミュニティに暖かさが見られ、言語としてもとっつきやすいので好きなのだけれど、いまいち実際のプロジェクトに応用されてる際のコード例とかが見れなくて悶々としてたので、「こういうライブラリ使ってますよ」みたいな話が多かったのが好印象だった。入門しつつ、痒いところを一通り掻いてもらった感がある。 もっと欲しい情報としては、「〜〜の言語から来た人にとって
人がやるべきではない仕事。一人のエンジニアとして。
Medium開き。はてなで自分用のブログを持っているけど、urlとかidとかがおかしいし、直したいのに直せないので、こっちに移ることにした。 僕がやるべきではないと思った仕事まず断りを入れておくと、仕事と言っても、職場の話ではない。 GoとかReduxとかReactとか、NodeとかRailsとか、OSSで見ておかなきゃなーと思った公式リポジトリをフォローした時の話。 僕は割とOSSにバンバンコミットするぜ、みたいなことに憧れつつも、なかなか自分だけのソフトウェアを作ってしまう性格で、それを治したいと思っていた。 とりあえず手始めに、各リポジトリをフォローして、各言語やソフトウェアがどんな課題を感じているのか、調べることにしようと思った。 その時に問題が発生して、なんとスパムのようにNotifyメールが来る。どれくらい凄いかというと、特にReduxなんだけど、日本時間で深夜３時くらいに、３
やっぱブロックチェーンダメっぽい
デジタル台帳「ブロックチェーン」が支える仮想通貨ビットコインを何百万人にも紹介したステファン・トーマス氏は、心変わりした。 この記事、最初見たとき釣りかと思ったけど、釣りではなく「まあそうだよね」と言う意見だった。 ここで言われてるのは 金融機関の政治問題合意形成コストの２つが課題でブロックチェーンが実戦に不向き的なこと。 １個目は人の問題なので置いとくとして、２個目が散々。 計算にマシンパワーが必要なのと、その結果を全ノードに等しく伝えるのに何日もかかる & その過程で生じた履歴がもし採用されなかったら破棄される可能性もある。 これらの点から「速くて、堅牢な、低コストの取引台帳」なんてものはないの明らかなので、登壇テーマとして用いた身なのを棚に上げながら言うと、すぐさまこの界隈は沈静化してほしい。 ハッシュ値を最も早く生成し、その結果その解答者以外の履歴はあっていようが間違っていようが場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
