6月5日が誕生日なのでもうひと月以上経っている。同じ日に娘が5歳になった。 40歳は社会人の折返しとも言えるし、人生の折返しとも言えるなかなかおもしろい年齢だ。20年前が20歳だったので、それを踏まえて20年後の60歳がどうなっているかなんとなく見通しが立つ気がする。気がするだけだとは思う。 40代の挑戦を考えた時に、新型コロナで世の中が大きく動き、逆に次の動きが読めない中、僕自身は去年から既にNature社での新しい挑戦を始められていて、40代もそれでスタートを切れるというのは幸いに思う。 前職の元CTOで僕の元上司である @stanaka さんが、はてなを辞めるタイミングで「10年スパンでキャリアを考えている」みたいなことを言っていて、そのときは「そんなもんかね」と思っていたが、なんだかんだで影響を受けている。 やっと大人になった気もしてくる。自分の10代と親が40代だったころがちょう

ボツネタかつ、golintが非推奨になりそうなので、急いで書きます。 golintを守ってれば、最低限Effective Goぽいコードを書くことができるので、初心者取っ掛かりのlintとしては良いよなーと個人的には思っており、非推奨には寂しい気持ちもあります。とはいえ、Goが言語自体も変化をしていく中で妥当な判断だと思います。しかし、他言語でも見られる光景ですが、lintをメンテナンスする難しさというものを感じてしまいますね…。 本題 さて、プロジェクトに途中からgolintを導入しようとすると(もはや導入すべきなのかどうか分かりませんが)、やたら警告が出てきて心が折れてしまうことで知られています。特に、 "exported $hoge should have comment or be unexported" と言うメッセージは量も多く、対応も大変なので困りものです。 これは「publ

前のエントリでDatadogについて書いたが、実際にGoのアプリケーションがOpenMetricsを吐くようにするのはどうのようすれば良いかをもう少し解説します。 OpenMetricsとは？ 元々[Prometheus]が利用しているフォーマット。Prometheusは"Promethues exporter"と呼ばれる監視対象からメトリクスを集約する作りになっている。 Prometheus exporterは実は「単なるHTTPのエンドポイント」であり、そのレスポンスが独自のテキストフォーマットになっている。このフォーマットを標準化しようとして提唱されているのがOpenMetrics。 https://openmetrics.io/ 実際問題としては、Prometheusのドキュメントの方がまだまだ充実している。 DatadogにはOpenMetricsのインテグレーションがあり、自前

追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい

github.com/natureglobal/realip これはngx_http_realip_moduleと同様の挙動を、Goのhttpハンドラをラップするミドルウェアレイヤで実現するものです。 アプリケーションが信頼できるNginx等のproxy配下にあれば、X-Real-IP ヘッダなどをそのままクライアントIPとして採用すればよいのですが、クラウドのロードバランサー、例えばALBなどに直接Goのアプリケーションをぶら下げている場合、ALBはX-Real-IPを付けてくれないので、アプリケーション側でクライアントのIP検出をおこなう必要があります。そういったときにこのモジュールが有用です。 X-Forwarded-Forを見れば良いという話ではあるのですが、HTTPヘッダは簡単に偽装できますし、CDNを使っているなど多段になっているケースでも判別は地味に厄介です。ヘッダを付けてき

システムを運用していく以上、ライブラリは常に最新を使いたい。最近は依存ライブラリの更新を検知してくれる便利なサービスがいくつかあって、Nature社ではDependabotを使っている。 https://dependabot.com/ Renovateの方が便利そう、という話も聞くのだが、とりあえずDependabotはGitHubが買収して、privateリポジトリでも無料で使えるので利用している。 導入自体は簡単で、画面のガイドどおりに進んでいけば、良い感じに言語や依存管理ツールも自動検出してくれる。設定ファイルは特に置いていない。慣れてきたり、設定を横展開したくなった場合に置くと便利そう。 参考: Dependabotの設定ファイルを置くようにした 動作の様子 前提としてGo Modulesで依存管理をしているが、依存ライブラリの更新があると以下のようにpull requestを上げ

https://github.com/Songmu/smartcache smartcacheというGoのインメモリキャッシュライブラリを書いた。 一般的に、キャッシュを実装する場合以下のような問題が起こりがちです。 キャッシュ更新時にリクエストが殺到してしまう(いわゆるThundering Herd問題) キャッシュ生成に時間がかかる場合、キャッシュ更新時に処理がブロックしてしまう smartcacheは上記の問題を以下のアプローチで解決しています。 キャッシュ更新処理を一本化する Goの場合 golang.org/x/sync/singleflight を使えば簡単! キャッシュ期限切れ前に内部的に更新処理をおこなう いわゆるプリフェッチ的な処理 使い方 コンストラクタにキャッシュの実際の有効期限、softな有効期限、そしてキャッシュ生成関数を渡します。 // コンストラクタ ca :

のがもはや半年前だけど記録として書いておく。結論を書くと、ecs-deployからecspressoに乗り換えるのはすぐできるし、タスク定義が管理しやすくなるのでおすすめです。 https://github.com/kayac/ecspresso もともとNature社では僕が入社する前からecs-deployが使われていた。これは、コンテナイメージをすげ替えてdeployするだけであればシンプルでわかりやすい。ただ、以下のような課題があった。 タスク定義自体を変更したい時にecs-deployだけでは対応できない ソースがbashスクリプトで年々複雑になっており(僕には)読みづらい 実際度々メンテナンスが滞ったりforkがいくつかあったりする jqやawsコマンドに依存している それに対して、ecspressoは以下のような利点があった。 タスク定義ごとリポジトリ管理できる Goなので(

https://github.com/Songmu/flextime flextimeはテストコードの中で現在時刻を切り替えるためのライブラリです。Sleep時に実際に時間を止めずに時間が経過したように見せかける機能もあります。 つまり、PerlのTest::MockTimeやRubyのtimecop的なことをしたいわけですが、Goだとグローバルに関数の挙動を切り替えるといったことはできないため、利用にあたってはtimeパッケージで使っている関数を、flextimeパッケージに切り替える必要があります。 具体的には、flextimeはtimeパッケージと同様のインターフェースを備える以下の9つの関数を提供しています。 now := flextime.Now() flextime.Sleep() d := flextime.Until(date) d := flextime.Since(da

tl;dr スプリントに名前がついていると便利 2週間スプリントの場合二十四節気をスプリント名につけると捗る ズレは適宜調整しましょう 二十四節気スプリントシステムとは 今年から、Nature社でもスクラムっぽくスプリントを回し始めたのですが、前職のチームでも採用していた二十四節気スプリントシステムを導入しました。 二十四節気スプリントシステムというと大げさですが、これは単に、各2週間スプリントの名前に二十四節気を割り当てるものです。二十四節気のWikipediaのリンクを以下に載せておきますが、最近はGoogle検索の結果にも出てくるので驚きです。 二十四節気 - Wikipedia ちなみに、これは、Mackerelチームでスクラムを採用し始めた頃に、当時のスクラムマスターであったid:motemenが発案したものです。 参考: はてなMackerelチームの開発フロー（スクラム、リモ

https://github.com/motemen/ghq/releases/tag/v1.0.0 年末にアナウンスしていた通り、先程ghq v1.0.0をリリースしました。変更点は以下のエントリでお知らせしていたとおりです。その他Subversion周りの対応を無駄に頑張って強化したりしました。 https://songmu.jp/riji/entry/2019-12-28-ghq.html 是非ご利用ください。 年末年始休暇中にドキュメントを書いていたのですが、思ったよりもしっかりとした分量になったので、思い立って電子書籍にして販売してみることにしました。 https://leanpub.com/ghq-handbook 日本語で20ページほどです。値段は$1.99くらいにしたかったのですが、Leanpubで収益を上げる場合には$4.99が下限のようなので、その額に設定させてもらいま

2019年は転職がやはり一番大きな転機。Nature Remo Eをなんとか年内にリリースできたのでかろうじて及第点というところ。 Nature Remo Eはこれから電力事業に舵を切る上で非常に大事で、野心的な商品です。会社として非常に面白いフェーズなので興味があれば採用にご応募ください。 https://nature.global/jp/careers 去年は一瞬で過ぎた。ライフイベント含めて色々あった。近年は、毎年去年より激動だな、と思っているのでこれは今年もきっとそうなるのだろう。 入門監視 付録C執筆 YAPC::Tokyoでベストスピーカー 娘の幼稚園入園 ghqメンテナ 認定スクラムマスター 個人事業開業 退職と転職 ISUCONシングル参加で惨敗 みんなのGo言語 改訂2版 Go Conference'19 Summer in Fukuoka 結婚10周年 父の死 個人事業

2020年1月5日追記: v1リリースしました https://songmu.jp/riji/entry/2020-01-05-ghq-v1.html https://github.com/motemen/ghq 最近のghqの状況と、v1リリースに向けた非互換変更などのアナウンスです。現状の最新のv0.17.4を前提に書きます。 ghq.<url>.root 設定により細やかにclone先を設定可能に 例えば、gitconfig上に以下のように設定すれば、デフォルトでは"~/src/hobby" に、仕事用は"~/src/work"にcloneされます。 [ghq] root = ~/src/hobby [ghq "https://github.com/myorg"] root = ~/src/work [ghq "https://myvcs.example.com"] root = ~

RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_

6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに本日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社

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/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per

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

前提として、/bin/sh は、デフォルトでは、RHEL系の場合bashシェル、Debian系の場合dashシェルへのsymlinkになっています。この2つのシェルの挙動は細かいところで結構異なります。そもそもの思想として、dashシェルはPOSIX互換を目指す軽量なシェルであり、bashは拡張された高機能なシェル。なのでbash前提で書かれたシェルスクリプトがdashでは動かない、みたいなことはよくあります。そういう感じで困ることがままありますが今回もそういう話。 例えば % sh -c "sleep 100" のようなコマンドを実行した場合、呼び出し元の子プロセスが sh になり、その更に子プロセスが sleep になると直感的には思うでしょう。つまり以下のような具合。 . \_ sh -c sleep 100 \_ sleep 100 しかし、 sh の実体が bash である場合な