フリーランスになって1年が経った - Gosuke Miyashita
4月からクックパッドで仕事してます というエントリを書いてからちょうど1年経ったので振り返ってみる。 フリーランスになった経緯 そもそも最初からフリーランスになるぞ、と思ってなったわけではなく、なんとなく流れにしたがってたらフリーランスになってた。 もう少し詳しい経緯。色々あって2014年3月に無職（有給消化中のファッション無職じゃなくガチ無職）になって、普通に正社員として次の会社を探していて、知り合いに声をかけて話を聞いて回っていた。その中でクックパッドに決めたのは、セコンさん や mirakui さん の、これからクックパッドの技術やインフラをこうして行きたい、という思いや考えに共感し、そこに自分が価値を提供できるイメージが具体的に沸いたから。 ただ、事情があって最初から正社員ではなく、お互い様子見ということで、正社員になる前提で半年間業務委託契約という形で仕事してみましょう、というこ
「Serverspec」という本が出ます - Gosuke Miyashita
ここ半年ほど取り組んでいた Serverspec に関する本が出ます。2015年1月17日発売予定です。 O'Reilly Japan - Serverspec Amazon.co.jp： Serverspec: 宮下 剛輔: 本 どんな内容か、というのは、サイトの紹介文や目次を見ればわかるので、ここでは、なぜこの鳥が表紙に選ばれたのか、といったことでも書こうかな、と思ったんですが、こういうのは明かさない方がおもしろいので、やっぱり書かないことにします。おそらく、何という名前の鳥なのかすらわからない方が大半かと思いますが、あえて伏せておきます。名前や生態は最後のページに載っていますので、知りたい方は買うなり、店頭で確認するなりしてみてください（妻が Facebook に名前を書いちゃってるけど）。 本書は、開発者である自分にしか書けないことをできる限り盛り込み、自分以外の人でも書けるような
Gosuke Miyashita
Terraform State Refreshの高速化手法と実装 TerraformのState TerraformのStateとは、Terraformで管理しているリソースの状態をJSONで記述したものであり、ファイルとして永続化されている。 Stateが何のためにあるのか、についてはオフィシャルな解説があるので詳しく説明はしないが、Stateには主に以下の目的がある。 Mapping to the Real World Metadata Performance Syncing このエントリでは、Performanceに着目する。 State Refresh Terraformは、plan/applyを実行する際に、どのような変更を行う必要があるのかを決定するために、リソースの最新の状態を知る必要がある。 デフォルトの動作では、plan/applyを実行するたびに、すべてのリソースの最新
Dockerコンテナに入るなら SSH より nsinit が良さそう - Gosuke Miyashita
追記 はてブでつっこみもらいました が、実行するカレントディレクトリは /var/lib/docker/execdriver/native/$id を使うのが正しいようです。（情報読み違えてた。）こちらには container.json があるので、ソースツリーからコピーしてくる必要ないですね。 また、コンテナ ID 取得は、docker ps -q --no-trunc の方が良い、とも教えていただきました。 つっこみにしたがって、最後の方の説明とシェル関数書き換えました。 つっこみありがとうございます！ tl; dr タイトルまま 経緯 Docker でつくったコンテナの中に入って状態を確認するために、コンテナ内で sshd を立ち上げてアクセスする、ってなことを以前やってたんですが、コンテナ内で sshd を立ち上げる、というやり方がいまいちだし、そもそもコンテナの仕組みから考えれば
4月からクックパッドで仕事してます - Gosuke Miyashita
株式会社はてなに入社しました。 — Gosuke Miyashita (@gosukenator) March 31, 2014 ↑はエイプリルフールネタですが。 色々あって、3月に無職になって、4月からクックパッドで仕事してます。 基本的にはフルタイムコミットなんですが、諸事情により業務委託契約なので、実質フリーランスですね。 この機会に色々な可能性を模索したいので、何か面白そうな仕事があったら Twitter とか Facebook とか メール などでご連絡ください。 特に以下のような仕事は自分の価値を活かせるんじゃないかと思ってます。 Chef, Puppet, Ansible といったサーバ構成管理ツールの導入支援 serverspecをベースとしたテスト駆動インフラやインフラCIの導入支援 要件に合わせた serverspec のカスタマイズ（serverspec 本体や、テス
configspec という Immutable Infrastructure 用 Configuration Management Tool をつくってみた - Gosuke Miyashita
Immutable Infrastructure の有用性 - Togetter の流れの勢いで、インフラ系技術の流れ とか Rebuild: 25: Immutable Infrastructure (Naoya Ito, Gosuke Miyashita) とかで言ってたような、冪等性とか依存関係とかを考慮しないシンプルな Configuratin Management Tool である configspec をつくってみました。rubygems.org にもアップしてます。 この手のツールに自分が望む要件は以下の様な感じ。 冪等性とかどうでもいい まっさらな状態からのセットアップでしか使わない 依存関係とかどうでもいい ファイル名順、上から書いた順で実行してく 対象サーバに余分なものをインストールしたくない 対象サーバに SSH さえできれば OK シェルスクリプトよりは抽象度を高め
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
ペパボでの GitHub の使い方 - Gosuke Miyashita
必殺！Github導入に向けて上司を説得する時に使える資料まとめ - DQNEO起業日記 でペパボも取り上げて頂いたので、ペパボでの GitHub の使い方について、少し詳しく書いてみます。 開発での利用 これは普通の使い方ですね。なので省略。 GitHub Enterprise は利用していない 金額的な面で GitHub Enterprise の利用は厳しいため、GitHub Enterprise ではなく、ノーマル（？）な GitHub を利用しています。（GitHub Enterprise にすると、現在のコストの 8 〜 9 倍ぐらいになってしまう。） ここはセキュリティ面とのバランスが難しいところではありますが… とはいえ、GitHub に何かあってソースコードが流出した場合に影響の大きさが懸念されるサービスについては、GitHub を利用しない、といった判断もしています。（で
37歳で大学生になりました - Gosuke Miyashita
この4月に、帝京大学理工学部情報科学科 通信教育課程の第2学年に編入学しました。通信教育課程なんで、仕事は続けたままです。 今日は、なぜこの歳（37歳）で大学に入ろうと思ったのかについて書いてみようと思います。 自分の現在の立ち位置は、ソフトウェアエンジニアだと思っているんですが、出身は経済学部経営学科です。それが悪いとは思ってないですし、そういう人は身近にたくさんいるんですが、情報工学や計算機科学なんかの学位を持ってない、といったことに、ほんの微か、あるかないかぐらいの、引け目なんだかコンプレックスだかなんだかわからないけど、そんなようなものをずっと持ち続けています。 それはあまり意味のないことで、別にそんな感情持つ必要ないじゃん、と思いつつも、ずっとひっかかりはあって、この感情ってこの先ずっと残るのかな、とか思ってたわけですが、だったら学位取っちゃえば、そんなつまらないこと考えずに済む
Paperboy's engineer evaluation system - Gosuke Miyashita
今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、本日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書に提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
