Infrastructure as Code 再考 - Gosuke Miyashita
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す（現在 Early Relase 版や Free Chapters が入手できる）ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
Developers Summit 2014 で「サーバプロビジョニングのこれまでとこれから」という発表を行いました - Gosuke Miyashita
内容自体は基本的に、第5弾 週末ランサーズ にお邪魔した時に お話した資料 と同じなんですが、この時よりも時間が少し長かったので、多少内容を追加しているのと、当時自分の中でうまく整理できてなかったけど、今は多少クリアになった部分もあって、そういった内容を盛り込んだりしてみました。 Togetter まとめ NAMIKAWA さんによるまとめ 一点お詫びしたいのは、登壇者に質問ができる Ask the Speaker というコーナーがあって、セッションが終わった後はそちらに移動、という段取りだったのですが、裏でやっていた OSS コミッタ大集合 の方でも登壇するために終了後すぐに E 会場に向かったため、Ask the Speaker コーナーに行けませんでした。もし質問するためにいらしてくださった方がいましたら、本当に申し訳ないです。 今回デブサミに登壇させて頂いた経緯については、会場で
自分のプロダクトを海外でも認知してもらうには - Gosuke Miyashita
ブログを書くまでが YAPC、ってことなので書きます。 YAPC 懇親会で @hirose31 さんと「日本人の作ったプロダクトでとても優れていて日本では知名度抜群なのに、海外では全然知られてない、みたいの割とあるけど、どうやったら serverspec みたいに海外でも認知されるようになるんですかね」みたいな話をしました。 serverspec の海外での知名度、といっても、日本での知名度と比較すればまだまだ全然、という感じですが、たまに海外の方の tweet を見かけたり、Serverspec the New Best Way to Learn and Audit Your Infrastructure というブログエントリを書いてくださった方がいたり、Food Fight という Podcast で取り上げられたり、O'Reilly の Test-Driven Infrastruct
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
サーバエンジニアが「開発力」を持つ意味 - Gosuke Miyashita
初出: Software Design 2009年4月号（2009年3月18日発売） 宮下 剛輔 サーバエンジニアの定義 本特集では、サーバエンジニアが開発力を持つことにより、どのような力を得ることができるのか、日々の業務にどのように役立てることができるのか、具体例とともに紹介します。 本題に入る前にまずはここでのサーバエンジニアの定義を明確にし、特集全体のコンセプトについて説明します。 クライアント/サーバ型のシステムを考える場合、サーバ側は大まかに以下のようなレイヤーに区分できます。 アプリケーションレイヤー ミドルウェアレイヤー OSレイヤー ネットワークレイヤー これらのレイヤーのうち、ミドルウェアレイヤーとOSレイヤーを主担当とするエンジニアを、本特集記事でのサーバエンジニアと定義し、対象読者と想定します。その中でも特に、オープンソースソフトウェア（OSS）をメインで扱うエンジニ
Paperboy's engineer evaluation system その後 - Gosuke Miyashita
Paperboy's engineer evaluation system で書いた、ペパボの技術者評価制度、2回目の評価が完了しました。 前回は、 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、結果（通過 or 不通過）、評価ポイント、今後期待すること、を評価者が追記し、git push する。 といった流れで、今回も基本的には同じ流れなのですが、2. の部分のやり方
Paperboy's engineer evaluation system - Gosuke Miyashita
今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、本日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、結
Git リポジトリ同期ツールつくった - Gosuke Miyashita
欠勤してるのにブログを書いていて解雇された、という話があったなー、ということを思い出しながら、このエントリを書いてます。(体調悪くて会社休んだ上に、まだ回復してない。) 最近仕事で GitHub を利用してるのですが、デプロイも GitHub 経由なため、GitHub がダウンしてしまうと、緊急で直さないといけないバグが発生したりすると困るなー、とか、それ以外にも、バックアップリポジトリがあればいろいろ安心かな、ということで、Git リポジトリを同期するツールをつくってみました。 https://github.com/mizzy/gitpusher GitHub の自分のアカウント(または指定された Organization)以下のリポジトリを、すべて Bitbucket に同期する、という動作をします。 今のところ、GitHub から Bitbucket への同期しか対応してませんが、逆
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
