「テスト 書くべき」って検索すると玉石混交な記事がわんさか出てくるのですが、そもそもなんでこういった議論は常に紛糾するのでしょうか？ 僕個人としては、テストコードというものへの捉え方はその現場の思想に密に依存しており、その前提を明示しないまま議論を進めると、「スピード感」「技術者の習熟度」「自社開発か否か」などの様々な変数の違いによって意見が食い違い、容易に銃弾飛び交う戦場と化す、と考えています。 そのため、この議論を始めるのは下手をするとパンドラの箱をパカっと開けて、収集つかないことになるのかなーと思っています。 僕の置かれている前提ということで、流れ弾で死にたくないのでまず僕の前提を明らかにします。 個人的な趣味趣向の話まず個人的な立場を表明しておきますが、僕は書くまでは、億劫なんだけど書き始めたら割と好きで黙々と書いていたくなるタイプです。かといって、仕様がピョンピョン変わる現場での

クエリビルダーやORMを使うのは基本的に良いこと。 特に開発初期とかはレビューの時間も足りず、クソみたいなクエリを書いてしまったりするので、それを防止するためにも、ライブラリでリスクを担保してあげるのは大事なこと。てか大体は慢心によってそういうの使わないって選択すると失敗すると思う。僕は失敗する自信がある。 自分もGoで開発する時、MySQLに対してのクエリを書く場合は、以下のクエリビルダーを使っている。一部ビルダーでJOINが使えなかったり、サブクエリの書き方が特殊だったりするが、それ以外はだいぶライトな実装で満足している。 ただ、最近サービスもすくすく育ち、レビュー体制が堅実になっていく動きの中で、クエリビルダーを使うのがダルくなってきた。 なんでかというと、多分以下の2つの理由でだるい。 サービス規模に応じて諸事情を孕んだ複雑な実装が生まれるが、その複雑さをクエリが吸収してしまい、メ

Goを書いていて、実際のユースケースに遭遇するまでメリットが実感できないものとして、reflectパッケージが挙げられると思います。 実際のところ、reflectパッケージで取れる情報についてはいろんな記事でまとまっているものの、じゃあそれを使って何ができるんだ、実益があるのかという点を体感する機会は人によりけりです。 よくある説明と違和感「メタプロ的なことができるぜ」「構造体の情報を取得してあれこれできるぜ」という説明を受けることがありました。 ただ、僕的にはいまいちイメージが掴めずにいました。おまけにパフォーマンスに負の影響があるから基本的には使わないものとして認識している方が多いと思います。 lestrratさんの少し前の資料とかを見て、そんな感じのイメージでいました。 Goを学習した時に、goroutineとかは利用場面に比較的に早くから遭遇できる一方、reflectパッケージはい

いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An

今回言いたいこと・UIデザインとそれを書き起こすプログラミングの乖離は、いくらわかってるつもりでも想定より大きくなる ・工数や実装都合上、泣く泣く見た目を変えざるをえない場合のデザイナーのストレスは、スピード優先で設計がおろそかになったときのエンジニアにかかるストレスより大きいのではないか ・雑にプロトタイプを出していい時代は終わってるのでは？と思うので、デザインを勉強していくべき 「デザインを勉強したい」 学生の頃から、dribbbleやbehance、デザイナーブログをみるのが大好きで、「うわーこんなかっこいいロゴ思いつかないよ、すげー」とか、「フォントの微差によく気を使ってるんだなー」とか、「このサイトの余白は過剰だけど、こっちはいい塩梅だなー」とか、そういうのがかなり気になってしまうタイプでした。 というと聞こえがいいのですが、結果的にエンジニアの道を選んで、UIは実装しながら考え

まとめGunosyに転職したGoにコントリビュートしたDribbbleにデザイナーとして登録できた発表割と多くしたetc転職今年3月に株式会社Gunosyに転職してました。僕が職場楽しいって喧伝するってよっぽどなのでみなさん安心してきてください。 職場ではGo/SwiftのエンジニアとしてLUCRAというアプリに立ち上げ期から関わっておりました。あとは技術広報的なところとか、採用に関与してました。 内容としては、Goのサーバーサイドの認証、記事配信、PushなどのメインAPIから、リリースまでのiOSほぼ全体を作りました。

この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう

DatastoreについてみなさまGCPをお使いになっているでしょうか。 GCPにはバックエンドのDBとしてCloudSQLというRDBと、NoSQLであるDatastoreというのがあります。 周囲の事例を聞く限りは、マスターデータなど変化が少なかったり、seedデータ的なものを用意しなければならないものをのぞいて、基本的にDatastoreを利用している印象です。 また、GAEで開発する場合はinternalなAPIからDatastoreを利用できる一方、GKEなどからは、GCPの外部向けAPIを呼び出すことでデータを送受信します。 さて、自分はいつもGoでAPIを書くのがいいよ！と触れ回ってるわけですが、GCP上で開発を進める際には前述の通りDBにはDatastoreを使っています。 このDatastoreですが、そのまま使うと自前でキーを発行する必要があったり、値をキャッシュしたり

問題意識エンジニアのタイプを分けるとき、大雑把に「サービス志向」と「技術志向」みたいな分け方をすることが、僕の周りではよくあります。 個人的にはこの分け方は必ずしも良いものとは言えないと思います。少しエンジニアのことをサービスと距離のある人種として捉えてるように感じるからです。 技術志向だからってサービスのことを考えてないということではなく、「よりセキュアな技術を採用する」「効率的で安全なデプロイができるフローを構築する」などなど、技術向上を通じてユーザー体験をよくしよう、としているはずです。 ただ、デザインを良くしたり読み込みスピードを早くしたりなど、「目に見える範囲で改善する施策」を考え、実行しなければ、プロデューサー的な人からすれば「何やってんだろうな〜」と、エンジニアはブラックボックス的な人に見えてしまうこともあると思います。 じゃあ他のアプリをいじってみたりして、サービス勘みたい

概要Dockerのmulti-stage buildを試してみました。 Goだと特にメリットを感じやすいのですが、今回は そもそもmulti-stage buildとは？Goだと何が嬉しいのか実際にやってみたの3つを書きます。 そもそもmulti-stage buildとは？dockerを使うとき、イメージの設定をDockerfileに書くと思いますが、このimage生成フローをstage別（build, artifactなどなど任意の名前で）に分割できる機能です。 何を言ってるんだという感じですが、具体的にいうと、 バイナリ生成やstaticなファイル生成を行うbuild stage成果物として上記をコピーしてコンテナを立てるrunning stageみたいな感じで、ステップを分けられます。 これで何が嬉しいかというと、単純にimageのサイズが減ります。 上記でいうと、buildのため

ほんの些細な見た目の違いで、「UI良さげだな〜」という思い込みが崩れることがあります。 エンジニアは、最適なユーザー体験を実現するべく、その錯覚をローカル開発の時点から目指すべきです。 以前、自分でGo製のDBレプリケーションツールを作成して、この問題を解決しました。 ですが、最近AppEngineを触ってる自分からすると、果たしてどうやればデータをコピーできるのか、ましてやDatastoreともなるとMySQLとかと違ってインターフェースが違うのでは、困る！と思っていました。 しかし、AppEngineでDatastoreを使っている場合、これは非常に簡単に解消可能な問題でした。 事前準備Remote APIの有効化事前準備として、AppEngineのRemote APIというものに対して、アクセスする窓口を作る必要があります。API経由でDatastoreを叩くためです。 今回はGoの

概要2017iOS11になったのでARアプリをちょくちょくインストールしているが大変楽しい。 出たてなのもあってまだ母数は少ないけど、どれを触ってもダメだなーというのはなく新鮮さに溢れてる。 個人的な興味もそうだけど、自分が今身を置いてる部署も新規事業について考えるところなので、触っておくに越したことはない。 今回ストアにフィーチャーされてないがそれなりに有名なアプリも含めて、アプリの傾向なり体験の問題とかを感じたので、いずれ誰かと話す時用にメモを残す。 個人的な分類既存のアプリは大まかに分類して、 空間計測空間ペイント規定モデルの設置と鑑賞単純なモデル設置だけでない箱庭の設置などの用途でアプリが使用できる。 空間計測AirMeasureとかがこれ。

最近GKEを触る機会がありまして、それまでGAEしか触ったことのなかったため、Datastoreへの接続方法について戸惑ったため、備忘録として作業ログを残します。 概要GAEを使った方はわかると思うのですが、GAEは内部で持ってくれているクレデンシャルを元に、よしなにDataStoreへ接続することができます。 しかし、GKEだとそうはいかず、Google Cloud PlatformのAPI経由でアクセスする必要がありまして、そのためには権限設定やクライアントパッケージが標準のものしかなかったりして、手順や使い勝手が微妙に複雑です。 今回はその手順と作成したクライアントライブラリについてのメモです。 DataStore APIを有効にするまず、そもそもDataStoreをインスタンスから叩くことができなかったら何もできません。 GCPのコンソールに入って、左メニューの「データストア」から

これはポエム。 先日、晴れてGoにContributeできまして、積年の目標であった「なんか大きめのOSSにコントリビュートする」を達成した。 これは前から本当にやってみたかったことで、Issueを立ててはCloseされ、をRubyやらGoやらで何度かやった末のコントリビュート。 割と一個のマイルストーンを経た感じがして、個人的には感慨がある。 OSSにコントリビュートしてみたいそもそも、プログラミング初めてからというもの、「Rubyにpull-req送ってます」とか、言語そのものへのコミットにはかなりの憧れを感じていて、社会人になる前後からというもの、3年前くらいから、何か面談とかで目標を聞かれるたびに、ずっと「技術的には…言語とか有名なソフトウェアへのコミットをしてみたいですね…」と言っていた。 とはいうものの、心理的障壁が高くて、自分のような技術力でできる気がしなかったのと、ソースを

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

他のビルドツールで既にあった、ビルドパイプラインと考えればわかりやすいと思います。 これを導入すると何が嬉しいかというと、 ビルドの実行フェーズを複数に分けることで、どこでFailしたかなどが視覚的に掴みやすい並列にjobを実行させることで通常の同期的なビルドフローよりも効率良く回せる具体的にはbundle installとかnpm installとかを並列に回して、共有ディレクトリに結果を入れたりできる色々並列にjobを回したあと、それを待ち受けて最終的な結果を同期的に受け取ることもできるbranchや言語のバージョンによって別々でテストを回したい時などに別個かつ並列にビルドを行える外部APIにつなぎにいく時にfailした場合などでは、Rerun from failedができるので、ケースによっては全工程をなぞる必要がなくなるなどのメリットがあります。 早速自分のこれまでのcircle.

概要Docker + Ansible + ServerSpec + CircleCI 2.0でTDDなCIビルドを行う話です。 今僕が在籍している企業では、プロビジョニング周りはAWS OpsWorksで管理されており、Chefのカスタマイズレシピが適用されて、ポンっと環境が構築されます。 個人的にはChefとItamaeの運用はしたことがありますが、OpsWorksを除けばAnsibleの方がStar数も多く活発に使われていそうなのと、どうせならDockerとServerSpecを使ってポータブルなテスト環境を作ってみよう、それをCircleCI2.0で効率的に回そう、と思い立って、やってみました。 ディレクトリ構成. ├── Dockerfile ├── README.md ├── ansible │ ├── ansible.cfg │ ├── ci.yml │ ├── circlec

【資料公開します】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の叩き方は上記のリンクを参考にしていただくとして、やたらマイクロな実装でなぜこうも高速に