12月末でLaunchableを退職します。実際には11月30日が業務最終日で12月は求職活動をしていました。幸い12月中に転職先を決めることができ、1月から次の会社で働きます。次の会社は年明けにお知らせします。 求職活動中は多くの方や会社から連絡をいただき本当にありがたかったです。全てにお返事をすることができず申し訳ありませんが、直接お知らせできなかった方にはこちらでお知らせとなることをご了承ください。 以上でお知らせは終わりで、以降は単なる中年男性のしょうもない独白です。 退職は非常に残念で、Launchableでまだまだやりたいことはあり、これからというところでもあったのですが、言ってしまえば西海岸外資の洗礼を受けたということです。 今回の僕の挑戦はあっけなく終りを迎え、ほろ苦い体験となりました。とはいえ間違いなく良い経験にはなりました。Launchableの事業は引き続き応援してい

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

家を買うつもりはあまりなかったが、ライフステージの変更に伴い買った、という良くある話です。2016年までの昔話です。 一応今の住所はあまり積極的にはネット上では公開していません。ただ、分かる人にはどのあたりか分かってしまいそうなので、その場合はそっとしてもらえると嬉しいです。 二子新地時代の購入未遂事件 結婚当初は僕は持ち家志向は強くなく、妻の方が比較的強かった。ただ、当時住んでいた二子新地が非常に気に入っていたこともあり、一度、近くの不動産屋に行ったことがあった。2011年頃の話。 確か二子玉の再開発絡みで周辺にマンションや建売住宅が建ちはじめていて、その中で当時の近所に建設中の分譲住宅が悪くない金額で売りに出されていたことがあった。それをふらっと内見させてもらい、それが良かったため、興奮した妻に連れられて不動産屋にまでも行くことになった。 「あーこれは買わされる流れかもな」と思っていた

「Android7.1以前でLet's Encrypt証明書のサイトが見られなくなる」の続き。 色々動きがあって猶予もできて助かった形だけど、来年9月29日以降の対応をどうするか考えないといけない状況なのは当然変わっていません。先にまとめると以下。 何もせずとも来年の1月11日までは猶予が伸びた 証明書を発行する側の場合、各クライアントで --preferred-chain "DST Root CA X3" のようにオプション設定することで、来年の9/29まで先延ばしが可能 独自ドメインに対して自動でSSL証明書を発行してくれるサービスを利用している場合はサービスが声明を出していないか調べ、出してない場合は問い合わせると良いでしょう 前回以降の動き go-acme/legoに--preferred-chainオプションのpull requestを取り込んでもらいました デフォルトRoot証

追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST

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

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周年 父の死 個人事業

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

前提として、/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 である場合な

ISUCON7開催決定 めでたいですね。開催されるかどうかハラハラしていたので、開催が決まって良かったです。 考えてみたら、昨年のISUCONに関して個人ブログの方に何も書いてなかったので書いてみます。書いたら「とにかく辛かった」みたいな話ばかり出てきそうなので、それが影響して今年の問題作成に名乗りを上げる人がいなかったら困るなと思って、書くのを躊躇していた部分もあります。 問題作成することになったきっかけ 2015年末当時の話になりますが、過去3回優勝させてもらっていたので、そろそろお鉢が回ってくるんじゃないかとは思っていました。過去のISUCON優勝者、もしくは上位入賞者を擁する企業の中で、はてなはまだ問題作成をしていなかったからです。 回ってきたら困るな、と思っていたのも事実です。過去の問題作成者に比べると、僕は明らかにエンジニアとしての実力が見劣りするからです。過去の優勝もチームメ