🏭 Docker を Production 投入するメリットを考える 仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導... portalshit.net Kaizen Platform 時代は Naoya Ito さんの以下の記事にあるような感じで deploy してた。 Slack 上で hubot に話しかけると deploy 用の Pull Request が作られていい感じに deploy フローが始まる。 GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー 少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそ

プログラマーの種類、いろいろあると思う。 ハッカー プログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。 OSS プログラマー 1 と似てるけど、 OSS が楽しくてコードを書いてる人。カンファレンスで登壇したり、技術ブログを熱心に書いたりする。 プロダクト指向プログラマー 開発だけでなく事業の方向性にも口を出したい人。社長が死んだらいつだって代替ができる、というような気概の人。 サラリーマンプログラマー プログラミングは仕事のためと割り切っていて、余暇には一切コードを書かない人。 1 〜 4 のどれか一つに綺麗に分類できるというものではなく、 1 かつ 3 とか、 3 かつ 4 とか、複数にまたがる人もいる。 職業プログラマーになりたての頃、サラリーマンプログラマーしかいない環境で働いて早くそこを抜け出したいと思っていた。プログラマーは会社の最下層で、プロジェクトマネー

Podcast を聞くのには Marco Arment の Overcast を使ってたんだけど、最近「 Internet Connection を確認しろ」みたいなメッセージが出てエピソードの一覧を取得できないことが何度かあってストレスに感じたので Castro に変えてみた。 Overcast は独自のサーバーサイドアプリケーションがあってそこと通信してるので、 overcast.fm の調子が悪くなると新しいエピソードをダウンロードできなくなる。 Castro や Apple の Podcast アプリだと iTunes から直接ダウンロードしてるので iTunes のサーバーがダウンしない限りエピソード一覧を取得できないということは起こらない。 エピソードの再生クオリティに関してはやはり Overcast の方がすばらしい。無音部分のカットや賢い倍速再生はやはり Overcast

Vim で Markdown を編集するとき、 vim-quickrun を使って Marked でプレビューするようにしてる。これが便利で体に染みついてるので、 Deckset で表示する用の Markdown スライドを Vim で編集しているときに一発で Deckset を開いてプレビューできたら便利だなと思ったので以下のようにしてみた。 ファイルのパスに slides が含まれていたら filetype を markdown.slide にする そんで ft=markdown.slide のときは vim-quickrun で Deckset にファイルをプレビューできるようにする こんな感じ。 au Bufread,BufNewFile /*/slides/*.markdown set filetype=markdown.slide let g:quickrun_config['

Kaizen Chat とは Kaizen Platform 内でユーザー同士がコミュニケーションを取ることができるサービス。 Kaizen Platform のユーザー カスタマー Kaizen Platform と契約し、 A/B テストツールや Growth Hacker によるサイト改善のデザイン案を募集 Growth Hacker 募集に応じてカスタマーサイトのデザインを改善するデザイン案を投稿 Kaizen Platform 社員 カスタマーと Growth Hacker の間の調整役 Kaizen Platform 内のユーザーが外部のツールや電話を利用して行っていた伝言ゲーム的なコミュニケーションを置き換えて、直接コミュニケーションを取ってもらうようになることが目標。 サーバーサイド 2.5 人、フロントエンド 2 人で 2 ヶ月くらいで作った。 構成 数多く存在しているマ

今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。 良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。 技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかも

転職してリモートワーク始めて 5 ヶ月たった。 Basecamp （旧 37 Signals ）の本で読んで夢にまで見てたリモートワークだけど、始めてみると理想と現実は違った。 良かったところは？ リモートワークだと通勤時間がないとかがよくあげられる。しかし自分の場合は福岡に拠点がある東京の会社に雇われていてそこで一人で仕事してるので通勤時間ゼロにはなってない。家で仕事する日もあるけど大体毎日片道40分くらいかけて通勤してる。必要なミーティングさえ外さなければ病院行ったりとか子どもの面倒見たりとかできるのはよい。あと午前中家で仕事して、昼間の空いてる電車に乗って座って仕事しながら出社できるのも良い。ただ仕事に時間の区切りがなかったり家で仕事できるということは、気になる仕事を夜や休みの日に家でやってしまって、フルタイムの社畜に成り下がってしまうリスクを伴うので注意が必要。 さみしいのか？ さ

memolist.vim のデフォルトのテンプレートが挿入する YAML Frontmatter なんか変わってて、 Jekyll のと違った。 Markdown のプレビューは Marked 2 で見るようにしてるんだけど、 Marked 2 は memolist の特殊 YAML Frontmatter を正しく処理してくれない。 YAML Frontmatter はメタ情報なのでプレビュー時には表示して欲しくない（ Marked 2 には YAML Frontmatter を表示しないオプションがある）んだけど必ず表示されてしまう。具体的にはこうなる。 調べてみたら memolist には標準のテンプレート以外に自分の好きなテンプレートを設定できる機能あったので、 ~/.vim/template/memolist/ に markdown.txt というファイル置いて以下のようにしてお

会社を辞めた。3年半在籍してた。 ペパボに入る前は凄いブラック企業で働いてて、 Subversion やめて Git 使いたいと言ったら会社辞めろと言われたりしてた。そんなときに蜘蛛の糸のように目の前に垂らされたのが Dazaifu プロジェクトの求人で、藁にもすがる思いで応募し入社したのだった。この辺は過去のエントリに適当に書いてあるので読みたい人は読んで下さい。 前働いていた会社の思い出と近況 いまの会社は労働環境よいんだけど、前働いていた会社がとてもつらかった。どのくらいつらかったかというと、もう辞めてしばらく経つのに、いまだに前の会社にいたころの夢を見てうなされて夜中に目が覚めるく... portalshit.net ペパボは働きやすくて、毎日18時になったらみんなさっと帰るし、21時過ぎに会社出ると最終退出者であることもしばしばだった。家庭の事情にも理解があって、育児休業をさせて

Ruby で動くソフトウェアは常に何でも最新を追っかけるのが吉な気がする。好きで使ってる earthquake.gem が最近新規インストール時に動かなくなった。バージョンを固定してないジェム（ eventmachine など）のバージョンが上がって死ぬようになったっぽい。そのジェム自身には変更がなくても、 Ruby のエコシステムはどんどん新しくなっている。止まっているのはそれだけでバグ生んでるのと一緒だと思う。なのでジェムを使ったり作ったりしたら、なるべく最新の環境で動くように気を配らないといけないし、いつも使ってるジェムに動かないところ見つけたらなるべく Pull Request 送っていかないといけないなぁと思った。そのことが最終的に自分のためにもなる。 earthquake.gem が動くようになる Pull Request 送ろう。 人生も一緒かなぁ。止まっているだけだとバグ生