本日10月1日、LaunchableにPrincipal Software Engineerとして入社しました。最近日本のエンジニア界隈でも少しづつ聞かれるようになったIC(Individual Contributor)としてのキャリアです。 ご存知の方も多いとは思いますが、LaunchableはあのJenkinsを作った川口さんらが2年前に創業された、まだ若いスタートアップです。自動テストにおける、スローテストやflakyテスト等の痛みを、AIの力で解決するプロダクトを作っています。 シリーズAの調達を終え、採用にも力を入れています。現在は、サービスの肝に関わるData Scientistを一番求めているようなので、興味のある方は是非採用応募してください。 Careers: Data Scientist - US or Japan | Launchable Inc. 元々優秀なスタッフ揃

Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな

https://github.com/rakyll/statik Goのバイナリにファイルを同梱するという誰もが欲しいはずのものがなかなか決定版がなく、go-bindataがメンテを終了し、go-assetsもいまいちメンテが滞っているので、statikを使うことにしました。作者のrakyllさんも実績のある方なので大丈夫でしょう。 statikも少しpull requestの取り込みが滞っていたのですが、試しにpull requestを送ってみたらちゃんと取り込まれたので大丈夫そう。 https://github.com/rakyll/statik/pull/61 元々、ファイル単体を取得する分には問題なかったのですが、ファイルシステムとして走査しようとするとうまく辿れない問題があり、このpull requestで修正しました。ですのでより安心して使えるでしょう。 http.FileSy

まとめを先に 自分のGitHub上にtapリポジトリをサクッと作る そこにFormulaと呼ばれるファイルをコミットする maltmill というツールを使うと簡単！ 用語 Formula 各ツールのインストール手順を記述するファイル maltmill.rb であれば maltmillのインストーラー RubyのDSLで記述 tap Formulaを配置するリソースリポジトリ GitHub上に"homebrew-"プレフィクスで作成する これらは自前で簡単に作ることができます。公式リポジトリに頑張ってpull requestを送ることもできますが、個人的なものであれば気軽に自前で作ってしまうことがおすすめです。 tapリポジトリの作成 前項で書いたとおり"homebrew-"プレフィクスを付けて命名すればOKです。僕の場合homebrew-tapという名前で作っています。 https://

https://github.com/Songmu/peep なにかコマンドを実行して、思ったより時間がかかりそうな場合、終了を通知して欲しくなること、あると思います。それをしてくれるのが peep です。言うなれば、 horenso の後付版です。 使い方はめちゃくちゃ簡単で、以下のようにpidと、その後に任意のコマンドを指定します。 % peep $pid -- /peth/to/notification-script 当該 $pid のプロセスが終了したら、指定したコマンドが動くという仕組みです。なんと、リモートプロセスの終了も検知できます。 インストール go get % go get github.com/Songmu/peep/cmd/peep % go get github.com/Songmu/peep/cmd/peep-notify Homebrew % brew ins

https://github.com/Songmu/goshim プロジェクトでちょっとしたスクリプトを書いてリポジトリで共有したいとなった時に、スクリプト言語なら楽ですが、Goで書くのはやや面倒です。リポジトリを分けるようなものでもないし、わざわざ go install させるようなものでもないけど、ビルドしたバイナリをどこに置くのかなどが悩ましい問題です。macを使っている人もいればlinuxを使っている人もいるのでバイナリをリポジトリに配置するわけにもいきません。 go run でも良いかと思われるかもしれませんが、本当にちょっとしたものならよいいのですが、以下の様な問題があります。 複数ファイルになった時に go run main.go hoge.go とかやるのがダルい (% go run $(go list -f '{{join .GoFiles " "}}') [args..

少人数でサービス開発をしていると、サーバーのアカウント管理を疎かにしてしまいがちです。良くないことだとわかっていながらも、共用ユーザーのログイン情報を数人で共有していたりだとか、rootばかり使っているなんてこともあるのではないでしょうか。 それだとオペレーターが増えたり、退職者がでたりした時に困ることになるので、最初からルールと仕組みを決めておいた方がトータルで楽になります。 前提 パスワードやログイン鍵の共用、ダメ！絶対！ rootを常用するの(・A・)ｲｸﾅｲ!! パスワードやログイン鍵を共用していると、人数が増えた時に誰が作業しているのか把握するのが大変になりますし、退職者が出た時に一斉変更をせざるを得なくなって混乱してしまいます。逆に一部のスタッフを別扱いして権限を制限したユーザーをアドホックに作ったりしてしまうのも管理が煩雑になります。じゃあどうすればよいかというと、個人ごとに