rAdioのブックマーク - はてなブックマーク

Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー

Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル

rAdio 2013/05/25

サーバ構築が「IT土方仕事」じゃなくなるのはいいけど、自分的には、ヒーヒー言いつつ泥縄なやり方で何とか「自分の仕事」にしたら、凄い人たちにまた雲の上に持っていかれた、という感じ。キャッチアップで死ねる。

リンク

開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー

開発メモ#6 です。前回から少し間があいてしまいました。開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリーで書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。この

rAdio 2013/02/19

確かにとてもとても便利っぽいけど、「ミドルウェア入れたら勝手にロギングしてくれてた（ので、必要になってから探す）」レベルにコモディティ化しないと、底辺エンジニアでは使いこなせない…。

リンク

エンジニアだからなんとか - naoyaのはてなダイアリー

昔から「エンジニアは営業が苦手」とか「エンジニアはデザインが苦手」とか、あるいは「エンジニアはコミュニケーションが苦手」というような言われ方が嫌いだった。実際、営業が苦手なエンジニアというのはいると思う。でもそれはエンジニアだから苦手なのではなくて、単にその人が営業が苦手なだけだ。同じように、デザインに関してもコミュニケーションに関してもそうだ。おおまかにそういう傾向があるということまでは否定はしない。例えばプログラミングのカンファレンスに行くとそこでは男性率が非常に高いし、全体としては、まあなんというかリア充とはちょっと違う雰囲気を醸し出している･･･というようなところがあってそれは誰もが感じることだろう。集団を集めて一般化してみるとそういう何かしらの傾向が現れる、ということまでは否定はしない。でもやっぱり、その「エンジニアだから○○」という型にはめたような話を自分自身にあてがって

rAdio 2013/01/17

さすが血液型トークでブチ切れるだけはある。

Exactly

リンク

「Web開発者のための大規模サービス技術入門」という本を書きました - naoyaのはてなダイアリー

自分が作ったWebサービス、将来大きくなってもシステムは大丈夫なんだろうか? そんな不安を抱きながらWebサービス開発に携わっている方も多いでしょう。あるいは、毎日毎日システムが悲鳴を上げる、どうしたらこの状況を看破できるんだろう? 成長したWebサービスを前に、困っている技術者の方もいるかもしれません。筆者も、まったく同じ経験をしてきました。月間1,500万人が訪れる、はてなというサイト。その大規模システムの開発と運用に、筆者らは取り組んでいます。1,000台のホストが、その負荷を捌きます。100万人以上のユーザによってブログやソーシャルブックマークに投稿され続けるデータは日々大きくなっていき、サーバリソースを逼迫させます。ギガバイト、テラバイト単位のデータ量が技術者たちを悩ませます。それでもトラフィックの波は収まることを知りません。 (中略) どうしたらこの怪物、大規模サービスを抑

rAdio 2010/07/01

CGM系サービスをやると、大して体制が整ってなくても、「規模」と向き合わざるを得なくなるからなぁ。しんどい。それもまた楽しいが、報酬が少ない。

リンク

naoyaのはてなダイアリー - Hatena ID Auto-Discovery の仕様

前回のエントリーではたくさんのコメント、トラックバックをいただき、ページの中にはてなアカウント名を埋め込む仕様が徐々に固まりつつあります。FOAF を使う、microformats 的解決手段を使う、PI を使うなどいろんな方法があるんだなあと勉強になりました。それから rel="payment" なんて話が海外ではあがっているという事も知りました。それでどれを採用しようか、というところですが、投げ銭以外の目的でもそのページを書いている人の ID が取得できると将来的に拡がりがありそうだと思い、汎用的な Dublin Core を使った表現方法を試してみています。 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /> <link rel="DC.creator" title="id:naoya" href="ht