退職 | おそらくはそれさえも平凡な日々
12月末でLaunchableを退職します。実際には11月30日が業務最終日で12月は求職活動をしていました。幸い12月中に転職先を決めることができ、1月から次の会社で働きます。次の会社は年明けにお知らせします。 求職活動中は多くの方や会社から連絡をいただき本当にありがたかったです。全てにお返事をすることができず申し訳ありませんが、直接お知らせできなかった方にはこちらでお知らせとなることをご了承ください。 以上でお知らせは終わりで、以降は単なる中年男性のしょうもない独白です。 退職は非常に残念で、Launchableでまだまだやりたいことはあり、これからというところでもあったのですが、言ってしまえば西海岸外資の洗礼を受けたということです。 今回の僕の挑戦はあっけなく終りを迎え、ほろ苦い体験となりました。とはいえ間違いなく良い経験にはなりました。Launchableの事業は引き続き応援してい
雌伏の時 | おそらくはそれさえも平凡な日々
カッコつけたタイトルを付けてしまった。中二っぽい。 強がりと言うか、自分に言い聞かせている部分もあるのだと思う。 有り体に言うと、新しい環境にまだ苦しんでいて、上手く動けていない。こんなことを書くと同僚に心配されてしまいそうだが、同僚には現状を伝えていて、その上で信頼してくれているとも感じている。会社に不満があるわけではなくて満足している。 少し精神的に参っていたので、今週前半は少し休ませてもらった。これは休んだほうが良いな、と思ってyoshioriさんに相談したところ、こちらから休みについては何も言わずとも「休んだほうが良いよ」と言ってくれた。話が早くてありがたかった。 現状意識していることや感じていることについて書き留めておく。 成果を完璧に出せてはいないが淡々とやる 現状、社内では成果目標を定めて、達成度を振り返るというのを毎月やっているが、1月に関しては100%をつけることができた
41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日本でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果
Nature Remo作ってる会社のCTOになったのでみんな買ってくれよな！ | おそらくはそれさえも平凡な日々
6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに本日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社
Makefileを自己文書化する `make2help` | おそらくはそれさえも平凡な日々
近年「タスクランナー」という言葉をよく耳にするようになりました。近年のWeb開発では、開発環境のセットアップ、依存ライブラリの管理、テストの実行、開発サーバーの起動、ビルド、デプロイ等等、とにかく気にしないといけないことが多いため、そういったタスクを一元管理してくれるタスクランナーは便利なやつです。 新しくプロジェクトに参加した際に、タスクランナーを見れば何をやれば良いのかだいたい分かるようになっているのが理想的だと思っています。 タスクランナーという言葉は主にJS界隈で使われており、そもそもタスクランナーなのかビルドツールなのかという話はありますが、ここでは便宜上それらをひっくるめてタスクランナーと呼ぶことにします。 gulp も本質的にはビルドツールですし。 Goの開発においては、タスクランナーとして、古き良きビルドツールであるところの make が主に使われます。 make も使って
fluentdのBufferedOutputプラグインを書くときの注意点とか | おそらくはそれさえも平凡な日々
fluetndのBufferedOutput系プラグインは、書き込みを適当なchunkにまとめて処理をしつつ書き込みに失敗したらよしなにリトライしてくれる便利なやつです。ただ実際にBufferedOutputプラグインを自分が書くとなった時に挙動をちゃんと理解していなかったのでまとめ。 まとめを先に書くと以下。 書き込み処理であるwriteに失敗した場合は例外を投げる 正しくリトライ処理を行うため 書き込みの処理内容はatomicである必要がある 中途半端に書き込まれたりして結果としてデータが重複したりしないように 一度に書き込めるサイズを調整するためにbuffer_chunk_limit等を調整する Bufferedプラグインのリトライ処理に関してはBufferプラグインの概要に以下のように書かれています。 もしチャンクの書き出しに失敗した場合、チャンクはキューに残され、Fluentdは
おそらくはそれさえも平凡な日々: PerlのIdiomをCPANモジュールを使って可読性を高くしてみる
今年からKayac技術部では以前以上にPerlを推進する方向で進めています。そんな中でこれまでPerlを書いたことのないエンジニアにもPerlを書いてもらうことも多くなってきたのですが、PerlのIdiomがやはりわかりづらいんだなぁということを感じています。 割りとサクッとやっつけでコードを書くことが出来るのもPerlの良い点ですが、まあ分かりづらいよね...、と言うことで最近はPerlに慣れない人に対しても可読性が高くなるように多少心がけています。 てことで、PerlのIdiomとそれを読みやすくしたものを幾つか。 ファイル一気読み こんな感じで書いてしまうことが多いと思います。 use autodie; も併用することが多いので、or dieとかも書かない感じ。 my $content = do {local $/; open my $fh,'<:utf8',$file_name;<
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
