PRです。妻が書いた「めんどくさがりやの自分の機嫌を取る暮らし」が本日発売されました。 めんどくさがりやの自分の機嫌を取る暮らし (BAMBOO ESSAY SELECTION) 作者:てらい まき竹書房Amazon 僕から見ても、妻はめんどくさがりやなのに「こんな生活がしたい！」という理想は高い性格に見えています。そういう性格を満たすために色々工夫をしているのですが、その工夫がコミックエッセイになりました。目次をピックアップすると、こういう話題を取り上げています。 髪の毛のケアがめんどくさい…でも、ツヤツヤ髪になりたい! 文字だけの本を読むのがむいてない…でも、いろんな知識を身に付けたい! 果物の皮をむくのがめんどくさい…でも、フルーツたくさん食べたい! お湯を沸かすのがめんどくさい…でも、お白湯生活始めたい! 眉毛を描くのがめんどくさい…でも、似合う眉毛を手に入れたい! 花を育てる才能

6月の第二子の出産に伴い、1歳9ヶ月 + 0歳という子供の構成になった。これは絶対に大変だろうということで、出産と同時に4ヶ月の半育休(僕の場合は育休を取りながら週1日働く)を取ることにした。今回は育休の振り返りを書いてみる。 どんな形態の育休を取ったか 第二子出産翌日から、4ヶ月半程度の育休を取得した(6月後半〜10月いっぱいまで) 毎週火曜だけ、10:00-16:30の勤務をした。16:30に帰っているのは第一子を保育園に迎えに行くため 最初に言いたいこと まず最初にこれだけは言いたいことがある。それは半育休を取るのではなく、可能なら完全育休をとるべきだったということだ。第一子ならまだしも、第二子の出産なら完全育休にするべきであった。 多少仕事を見れたという良い面はあったが、それよりも疲れや焦りを感じる辛さの方が上回った。また疲れなどの理由で、出社はしているけど結局ほぼ仕事は出来ない状

はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs

「Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版」でAWSサーバ構築とCloudFormationに入門した - $shibayu36->blog;で、サーバ構築を1ファイルで行い、CloudFormationの1スタックでネットワーク設定もWebサーバ設定もDBサーバ設定も書いていた。しかし考えてみると ネットワーク設定はほぼ変わらないのであまり触りたくないはずだけど、Webサーバはぽこぽこ新しいのを作りたくなりそう 全ての設定が1ファイル1スタックで行われているのは、管理が大変そう と思った。 調べてみるとクロススタック参照というのを利用すると、スタックを分けて設定できるようだった。そこで、これを利用し、ネットワーク設定とWebサーバ設定を分けるようにしてみた。 スタック設定の分割を行う 参考になったのは AWS CloudFormation の更

最近子どもが産まれて、しかもありがたいことに2ヶ月間育休を取れることになった。育休を取り始めて今2週間くらいなのだけど、育休で得られるのは育児のサポート(サポートという表現は適切じゃないかもしれないけど...)を行うことだけじゃないなと思ったので考えを書いておく。 自分が育休を取ると、妻と一緒に育児を行うことができ、育児の負担を二人で分担することができる。しかし、それだけじゃなく、育休を取ることで以下のメリットを得られると感じた。 育児の大変さを知ることができる 育児のやり方の認識を一致させ、自分一人で全て出来るようになる 育児の大変さを知ることができる 育休を取ってみて、「一日中」育児をするということは非常に大変であるということが分かった。これは当たり前のことだと思うけど、実際に仕事をしていて夜だけ育児をするだけだとなかなか実感できないことだった。 例えば一日中育児をしていると、子どもを

田中圭一さんの「うつヌケ」というコミックエッセイを読んだ。とにかくむちゃくちゃ良かった。 うつヌケ　うつトンネルを抜けた人たち　【電子書籍限定　フルカラーバージョン】 (角川書店単行本) 作者:田中 圭一KADOKAWAAmazon いろんな人にインタビューしていて、それぞれごとに「なぜうつ病になったか」「うつ病になってどうなったか」「どうやってうつ病から脱出できたか」が語られる。そのため、うつ病になっている人がどうやって戻ればいいかとか、うつ病になりそうなのをどう止めるかなどを知ることができる。ちなみに自分はうつ病経験者で、2か月ほど休職もしているので、全ての事例であるある集を眺めている感じだった。 今まさにうつ病に苦しんでいる人も参考になると思うけど、個人的には次のようなうつ病になりやすそうな人にこそ読んでして欲しいと思った。 劣等感を感じやすい人 責任感の強い人 ちょっとしたことで不

以前このブログで、漫画のアシスタントをして感じたこと - $shibayu36->blog; という記事を書きましたが、その時に手伝った「きょうも京都で京づくし」という本が出版されました。 きょうも京都で京づくし (地球の歩き方コミックエッセイ) 作者:てらい まきダイヤモンド・ビッグ社Amazon この本は生まれてからずっと京都に住んでいる著者が、正月から大晦日までの一年をとおして、家族でどのように京都を楽しんでいるかをコミック形式で書いた本です。京都の伝統行事・地元のグルメ・穴場スポットなど、地元民だからこそ知っている情報が多く載っています。 京都のメジャーな観光名所は載っていませんが、京都をさらに楽しむための情報が盛りだくさんの本になっているので、京都を数回観光したけど他に面白い所ないかなあとかという人におすすめです。他にも京都に数年住んでいて、観光できるところやごはんが美味しいお店

最近、簡単な漫画(フィクションではなくコミックエッセイ)のアシスタントをやった。僕自身は絵は全く描けないので、やったこととしては単に肌の色塗り、単調な服の色塗り・トーン貼り、髪の色塗りなどを手伝った。 これまで漫画には読み手という立場でしか関わったことはなく、書き手として初めて関わり、新鮮な体験を得られたので、感じたことを書いてみる。 手間がかかる まず一番最初に感じたのが、とにかく手間がかかっているということ。僕がやったところは、本当に単調で一番時間がかからないところだったけれど、それでも100ページくらい担当すると大体丸二日くらい時間がかかった。やった作業としてはおそらく全体の2~3%くらいしかなく、これとは別にネーム、ペン入れとか、トーンや色で絵の技術が必要なところとか全部やろうとすると、どれだけ時間がかかるのだろうかと思った。週刊連載で毎週16ページくらい書かれているのは本当に大変

最近cronの実行にはhorenso というツールを使って、実行エラーがあればSlackに通知するなどといったことをしている。今回はcronの実行時間をmackerelのサービスメトリックに自動で記録するということをやったのでメモ。 やりたいこと crontabに以下の形式でスクリプトを登録すれば、自動でサービスメトリックに記録される horenso --tag (tag名) --reporter=elapsed-time-to-mackerel-reporter.pl -- (実行したいコマンド) 記録は秒数で、小数3桁まで記録する horensoの動き horensoではreporterとして適当なスクリプトを指定することが出来て、そのスクリプトには標準入力に実行のログ等が渡ってくるようになってくる。例えば $ horenso --reporter=test-reporter.pl -

ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。

最近文字コード周りでハマった時に、文字コードというものをそもそもちゃんと分かってないと気づいた。そこで「プログラマのための文字コード技術入門」を読んで勉強してみた。 プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ) 作者:矢野 啓介技術評論社Amazon この本はコンピュータにおける文字について体系的にまとめてくれている。ASCIIやLatin1、UTF-8やUnicodeについて、どういう分類で何のために使われているかを知ることができる。また、歴史も合わせて教えてくれるので、今現状起こっている問題(円マークとバックスラッシュ問題とか)がどういう経緯で起こってしまったのかなどを理解できる。 簡単な文章で書かれているので、一度でも文字コードに関係することでハマったことのある人なら、どんどん読めると思う。ただ、符号化文

以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot

メールを送るアプリケーションを作成していると、使われていないメールアドレスで登録された時や、携帯のメールアドレス変更によって登録されているメールアドレスが使えない状態になって、メール送信時にバウンスメールとして返ってくることがある。この時バウンスメールとして返ってくるメールアドレスをアプリケーション側で無効にするなどしておかないと、メール送信の無駄が発生する。また、AWS SESを使っている場合、バウンス率が高くなった場合、規制されることもある( https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/e-faq-bn.html )。 今回は、AWSを利用してバウンスメールとして返ってきたメールアドレスを自動的にハンドリングするというのをやってみたので、それを書いてみる。 前提 今回はAWS SESを利用して、メールを送信して

最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく

今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi