これはなに？ 入社エントリー＆会社紹介です。表題の通りで、10月をもってメルカリ/メルペイを退職し、11月からドクターズプライムという会社で働いています。 なにやってるの？ Backend Engineerとして、救急車のたらい回しをなくすためのプロダクトを開発しています。救急車のたらい回しが発生する理由としては以下のスライドに書いてある通りなのですが、これを解決するのがDr.'s Primeという医師の採用サービスになります。 自分も子供を持つ親なので何度か病院のお世話になったことはあるし、子供が救急車で運ばれて手術＆入院したこともあるので、救急医療に関しては一当事者として良くしていきたいという思いがありました。ドクターズプライムは救急車の搬送を断らないための仕組みを採用サービスとして第三者の立場から提供していて、素直にいいソリューションだなと思っています。 入社の経緯 今年に入ってから

O'ReillyのOnline Learning(旧O'Reilly Safari Books Online)は月額$49でオライリーの本や動画などが見放題になるエンジニア向けのサブスクを提供している。以前は英語の本しか読めなかったが、いつからか日本語の本も読めるようになっていたのでメモ。 www.oreilly.com Sign Inして、左のメニューのSettingsをクリックするとLanguage Preferencesがあるので、ここでJapaneseにチェックを入れて下のUpdate Preferencesをクリックして保存する。 これでHomeに行き、例えばGraphQLで検索すると検索結果の画面でBooksのタブがあるのでこれを選択する。そうするとLanguageの選択ができるので、ここでJapaneseを選ぶと日本語の本だけに絞ることができる。(手っ取り早く検索結果を表示し

はじめに GoでHTTP Serverを作ろうとすると、標準ライブラリを使う場合以下のようなコードをよく書くと思う。 package main import ( "fmt" "log" "net/http" ) func main() { mux := http.NewServeMux() mux.Handle("/hello", http.HandlerFunc(hello)) log.Fatal(http.ListenAndServe(":8080", mux)) } func hello(w http.ResponseWriter, _ *http.Request) { w.WriteHeader(http.StatusOK) fmt.Fprintf(w, "Hello World") } このコードの登場人物としては以下になるが、それぞれなんだっけ？というのをいっつも忘れてしまうの

これはGo Advent Calendar 2016の18日目の記事です。今回はGoでE2Eテストを行うためのライブラリagoutiについて書きます。 GoでE2Eテストを書く理由 WebアプリケーションのサーバーサイドをGoで書いている場合、GoでE2Eテストを書くメリットとして JavaScriptが得意ではないエンジニア(自分)でもE2Eテストがガリガリかける E2Eテスト実行時のカバレッジが取れる＝サーバーのコードのどこを通ったかがわかる があると思っている。特に2番めの理由が大事で、「E2Eテストを全部回した結果、サーバーのこの部分のコードは通っている」とわかるのはけっこう大きなメリットなのではないかと。どこがテストされている・いないを把握することで、「ここはE2Eテストだと難しいからユニットテストでカバーしよう」というような戦法が取りやすいと思う。 じゃあ具体的にGoでどうやっ

よくある「開発スピードを優先させるか技術的負債をなるべく発生させないようにするか」という議論、ケースバイケースだとは思うけど、ことプロダクトの立ち上げ段階では、悩んだら「開発スピード」を優先させるようにするべきだと自分は思ってる。 理由は 市場は待ってくれないから。どんなにいいプロダクトでもユーザーに使われなくては意味がないのと、プロダクトを取り巻く外部の環境(競合プロダクトや市場でのニーズ)は自分ではコントロールできないものなのに対して、技術的負債については適切に管理されていればコントロールしながら返済できるから。もちろんバランスも重要だとは思うので、どんな技術的負債も生み出していいかと言われるとそうではないけど。 というわけで自分は「ああこれクソコードだけど機能は満たしてるからそのままリリースしたいなぁ」というのはだいたいクソコードのままリリースしています。(こうやって免罪符を作ってい

新年明けましておめでとうございます。2014年内に書き上げるはずの記事がずっと下書きのまま眠ってしまっていた... 2014年は細かいものを含めるといろいろ新しいものを使い始めたのでそのまとめ。 Ansible Chefがあまり好きではないのでAnsibleを今やっているプロジェクトで入れてみた。 DSLを覚えなくてはいけないのはどちらも一緒 Ansibleの方が仕組みがシンプルでPlaybookに書いた順に実行されるのでわかりやすい Dynamic Inventory便利 AnsibleはYAMLなのでロジックをゴリゴリ書くのには向いていない Chefはその点Rubyのコードなのでなんでもできる という感じでどっちもどっちだなという印象。個人的にはChefのようにコードが実行される方がフレキシブルでいいと思っているので、Fabric + Cuisineも試してみたい。 Packer Va