この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい

facebookやTwitterでは思っていたよりたくさんのお祝いの言葉を頂き、本当にありがとうございました。この場でお返事とさせていただきます。 6月5日に35歳になりました。よく言われるプログラマ定年説カッコワライっていうやつです。 日付を同じくして、子供が生まれました。自分でも驚きです。 プログラマ定年の日に第一子を授かりました。 — songmu (@songmu) 2015, 6月 5 奥さんは僕の誕生日に合わせて産みたかったみたいなので特に喜んでいます。なんか色々あってここまできたなーという感じです。産まれて本当に良かった。出産にも立ち会えた。会社の皆様のバックアップにも感謝です。 前日入院したときに、同室の隣の妊婦さんが出産前で、ものすごくつらそうなうめき声を上げながら分娩室に移動していたのですが、自分の奥さんがこうなったらいたたまれなくて精神的にキツイだろうなーとか(普段奥

最近特にシュークリームは話題ではありませんが、シュークリームです。 シュークリームは作るのも食べるのも好きなので年に何回か作ります。「シュークリームが作れるとか女子力()高くてモテそう！」とか思うかもしれませんが、上手く作れるようになってくるとシュークリームは科学であることに気づき、薀蓄を語りたくなってしまうのでモテません。 ちなみにこれから書く内容は、ムシューイガシの以下の動画内で語られている内容とほとんど同じです。ムシューイガシの動画は全部面白いので料理好きは見ると良いと思います。 完全なるシュークリーム シュークリームはシュー皮が失敗しやすく難易度が高いと言われています。失敗しないためにはまずはシュー皮が膨らむメカニズムを知ることが肝要です。メカニズムと言っても、そんなに難しいものではありません。 シュー生地が加熱されると、生地の中の水分が水蒸気となり膨張し生地を膨らませ空洞を作りま

fluetndのBufferedOutput系プラグインは、書き込みを適当なchunkにまとめて処理をしつつ書き込みに失敗したらよしなにリトライしてくれる便利なやつです。ただ実際にBufferedOutputプラグインを自分が書くとなった時に挙動をちゃんと理解していなかったのでまとめ。 まとめを先に書くと以下。 書き込み処理であるwriteに失敗した場合は例外を投げる 正しくリトライ処理を行うため 書き込みの処理内容はatomicである必要がある 中途半端に書き込まれたりして結果としてデータが重複したりしないように 一度に書き込めるサイズを調整するためにbuffer_chunk_limit等を調整する Bufferedプラグインのリトライ処理に関してはBufferプラグインの概要に以下のように書かれています。 もしチャンクの書き出しに失敗した場合、チャンクはキューに残され、Fluentdは

go vetは失敗時に終了ステータスがnon zeroなんだけど、golintは指摘項目があっても終了ステータスが0なのでエラー扱いにならない。golintはコーディング規約的な推奨事項なのでエラー扱いじゃないのは妥当そう。 ただ、細かい指摘し合いで消耗したくないのでgolintで警告が出たらCIがコケるようにしたかった。以下のようにして無理やりエラーを出すようにした。 #/bin/sh golint ./... | tee .golint.txt test ! -s .golint.txt 標準出力になんか出てたら失敗になるようにという感じ。出力ちゃんと見たいからteeかましてる。 更にいうと、golintは$GOOSを見てくれているので$GOOSを切り替えながら回せばビルド対象毎の警告も網羅できる。 #/bin/sh rm -f .golint.txt for os in "linux

あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ

本日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日本語の会社じゃねーか！」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう

デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー