フリーランス2年目だけど家を建てることにした 其の1 - Gosuke Miyashita
フリーランスのソフトウェアエンジニアでしかも（確定申告的な意味での）実績が1年しかない人間が、ローンを組んで家を建てることになったので、その辺についてシリーズで書いていくことにしようかと。 フリーランスのエンジニアで家を建てた人の話としては、@a_matsuda さんの Hacking (My) Home という素晴らしいスライドがあったり、フリーランスではないけど、同業種のエンジニアが家を建てた話としては、元同僚の @morygonzalez さんの 2000 ブクマを超えるエントリ などもあったりするので、併せてどうぞ。 今回は、元々家を持つつもりは一切なくて、一生賃貸でいいや、というか、今後の家族構成の変化（子供が自立して出て行くなど）を考えると、断然賃貸の方がいいだろう、と思っていた人間が、なぜ家を建てることになったのか、そのきっかけになった出来事について。 ゴールデンウィーク中に
Paperboy's engineer evaluation system - Gosuke Miyashita
今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、本日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、結
Dockerコンテナに入るなら SSH より nsinit が良さそう - Gosuke Miyashita
追記 はてブでつっこみもらいました が、実行するカレントディレクトリは /var/lib/docker/execdriver/native/$id を使うのが正しいようです。（情報読み違えてた。）こちらには container.json があるので、ソースツリーからコピーしてくる必要ないですね。 また、コンテナ ID 取得は、docker ps -q --no-trunc の方が良い、とも教えていただきました。 つっこみにしたがって、最後の方の説明とシェル関数書き換えました。 つっこみありがとうございます！ tl; dr タイトルまま 経緯 Docker でつくったコンテナの中に入って状態を確認するために、コンテナ内で sshd を立ち上げてアクセスする、ってなことを以前やってたんですが、コンテナ内で sshd を立ち上げる、というやり方がいまいちだし、そもそもコンテナの仕組みから考えれば
ChefConf 2014 に来てます - Gosuke Miyashita
今日は最終日で、昨日は Serverspec: The Simplest Server Testing Tool Ever というタイトルでプレゼンしてきました。海外でははじめての serverspec プレゼンなので、もっと基本的な、具体的な使い方とかデモといった内容にした方がいいのかなー、と思いつつも、そういうのはオフィシャルサイトとか見れば割と十分だし、自分以外の人でも話せる内容なので、開発者ならではの、開発をはじめたきっかけとか、開発する上での哲学とか、今後どうしていきたいのか、みたいな話をしました。(大体いい感じになるKeynoteテンプレート「Azusa」 を使わせてもらいました。ありがとうございます。あと、mirakui さんの真似して entypo や fontawesome も使ってみました。) 英語台本棒読みだし、Splunk の方から質問された内容が、なんかテストカバ
4月からクックパッドで仕事してます - Gosuke Miyashita
株式会社はてなに入社しました。 — Gosuke Miyashita (@gosukenator) March 31, 2014 ↑はエイプリルフールネタですが。 色々あって、3月に無職になって、4月からクックパッドで仕事してます。 基本的にはフルタイムコミットなんですが、諸事情により業務委託契約なので、実質フリーランスですね。 この機会に色々な可能性を模索したいので、何か面白そうな仕事があったら Twitter とか Facebook とか メール などでご連絡ください。 特に以下のような仕事は自分の価値を活かせるんじゃないかと思ってます。 Chef, Puppet, Ansible といったサーバ構成管理ツールの導入支援 serverspecをベースとしたテスト駆動インフラやインフラCIの導入支援 要件に合わせた serverspec のカスタマイズ（serverspec 本体や、テス
Developers Summit 2014 で「サーバプロビジョニングのこれまでとこれから」という発表を行いました - Gosuke Miyashita
内容自体は基本的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、本当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で
octorelease という gem をつくった - Gosuke Miyashita
serverspec とか specinfra の Changes を手で書くのがだるくなってきたので、自動化するために octorelease という gem をつくりました。 rubygems.org にもあげてあるので、gem install で入ります。 Rakefile の中に require "bundler/gem_tasks" require "octorelease" みたいに書いて、 $ rake octorelease すると、 こんな感じになります。 何をしてるかというと、rake release した後に、前のバージョンとリリースするバージョンの間に含まれるプルリクエストをgit logで拾って、各プルリクエストに Released as vX.X.X. とコメントをつけ、GitHub 上にリリースを作成し、リリースの本文にはプルリクエストへリンクを張る、ってなこ
2013年の振り返り - Gosuke Miyashita
2012年はターニングポイント的な年だったし、自分自身注目を浴びることも多く、エンジニアとしてピークで後は落ちていくだけなんじゃないかと思ったので、珍しく振り返りエントリ を書いてみたわけですが、どうやらピークは今年だったようなので、また振り返りエントリを書いてみます。 3分で常松 2013年に自分が生み出した最大の成果がこの言葉ですね。残念ながら流行語大賞にはノミネートすらされませんでしたが、一部ではとても高い評価を頂いているようです。 この言葉が生まれたのは2013/2/20でした。 3分で常松 — Gosuke Miyashita (@gosukenator) February 20, 2013 言葉の由来は、一度飲み会で限られた人に話した以外は、長らくベールにつつまれたままだったのですが、先日ついに公表しました。 #3分で常松 の由来は、mirakuiさんの「3分でイナフ」と「俺の
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
構築済みサーバを RSpec でテストする serverspec という gem をつくった - Gosuke Miyashita
Puppet や Chef で構築したサーバを RSpec でテストする で書いた仕組みを使いやすくするために serverspec という名前で gem 化してみた。 rubygems.org にも登録してあるので、gem install でインストールできる。 $ gem install serverspec インストールしたら、適当なディレクトリで serverspec-init を実行。すると、雛形となるディレクトリやファイルを生成する。 $ serverspec-init + spec/ + spec/www.example.jp/ + spec/www.example.jp/httpd_spec.rb + spec/spec_helper.rb + Rakefile spec/www.example.jp/httpd_spec.rb がサンプルテストコードで、こんな感じになって
Puppet や Chef で構築したサーバを RSpec でテストする - Gosuke Miyashita
追記 ここに書いてあることを実現する serverspec という gem をつくりました。詳しくはこちらのエントリで。 Puppet マニフェストをリファクタリングするからテスト書くぞ、ってことで、 puppet-lxc-test-box に書いたように、テストするためのシステムコンテナを簡単に作る仕組みをつくったので、今度は実際にテストコードを書くためのベースをつくってみた。 rspec-lxc-test-box こんな感じでテストが書ける。 require 'container_spec_helper' describe 'nrpe' do it { should be_installed } it { should be_enabled } it { should be_running } end describe 'nagios-plugins-all' do it { shou
最小手順の Vagrant base box の作り方 - Gosuke Miyashita
Vagrant の base box をつくるためのツールとして VeeWee があって、これはこれで素晴らしいツールなんだけど、VeeWee は裏で ISO イメージをダウンロードしたり、インストーラを走らせたりで、時間もかかるし大げさな感じがするので、もっと簡略化できないか、ってことでやってみた。 最小手順のVMイメージの作り方 で紹介したシェルスクリプトで作成した VM イメージに対して、以下のようにコマンドを実行するだけで、package.box ができあがる。 # VBoxManage convertfromraw --format vmdk /tmp/sl63.img /tmp/sl63.vmdk # VBoxManage createvm --name SL6.3-x86_64 --register # VBoxManage modifyvm SL6.3-x86_64 --m
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
serverspec の論文公開します - Gosuke Miyashita