Chefを最速で使いこなすためのいくつかのポイント - Masatomo Nakano Blog
前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。 前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。 ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！ client vs node Chef Client Nodes ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。 client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて clien
さようならPuppet、こんにちはChef - Masatomo Nakano Blog
ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。 Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。 基本的な仕組 これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。 rubyな設定ファイル Puppetは基本的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので
TDDを真面目にやってみて気付いたこと - Masatomo Nakano Blog
何を今更、なことかもしれないないのだけど、もしかしたらこれを知ることでTDD(Test-driven development)をやることのハードルが一気に下がる人がいるかな、と思ってメモ。 特に、ある程度プログラマとして経験があるけど、どうもTDDは慣れないという人向き。 “TDDとは、TDD以前に脳内や機上でやっていたことをコードに落とすことに過ぎない” このことが解ってから、TDDをするのが一気に苦痛ではなくなり、むしろ楽しくなった。 TDDでなくても、コーディングをするとき、temporaryなテストコードを書いたり、目視でのチェックはしたりするものだろう。たとえば、一時的に変数の値をハードコードして挙動を変えてみて、それを目視で確認したり、printデバッグとかもその一部だ。 つまり、このtemporaryなコードや目視している部分をpermanentにするのがTDDで書くテストコ
Rubyを「知ってるつもり」の人にお勧めな「Metaprogramming Ruby」本 - Masatomo Nakano Blog
とてもいい本だったので紹介してみる。 Metaprogramming Ruby: Program Like the Ruby Pros by Paolo Perrotta この本を読み始めてすぐに、自分がこの本に対してタイトルから想像していた内容と違うことに気付いた。 自分が想像していたのは、「こういうケースでは、こういうメタプログラミングをするといいよ」「こういうメタプログラミングのパターンもあるよ」というRubyでするメタプログラミングの実践編の本かと思っていた。でも、これは間違いで、この本はRubyでメタプログラミングができるようになるためのRubyの基礎知識が書いてある本だった(基礎、と言っても初心者向けというわけではなくて、Rubyのベース部分という意味で)。 想像とは違っていたのだけど、結果的に、ちょうど今自分が読むべき本だった。 自分は、この本を読むまで半年ちょっとRails
「MongoDBをプロダクション環境で使ってみて」 - Masatomo Nakano Blog
8ヶ月間、MongoDBをプロダクションで使っている人のブログ記事が面白かったので、興味深いところだけまとめてみた。 原文はこちら 。 8ヶ月間使ってデータベースの規模は、Collections (tables): 17,810Indexes: 43,175Documents (rows): 664,158,090 master/slaveのマニュアルでのフェイルオーバ環境で運用してきた。masterは72GBのRAMslaveは別のデータセンタ ディスク的にきつくなってきたので、手動でShardingをし4つのDB(Master 2つ / Slave 2つ)に分けることにした。 namespaceの限界があるので、データを3つのMongoDB( これは物理的なサーバではなくてMongoDBのデータベースの単位)に分割している。現在のnamespaceの数は、 db.system.name
なぜMongoDBなのか - Masatomo Nakano Blog
ここを見てもらってる人に、「MongoDBって何がいいの？」と改めて聞かれてしまって、ああ、そっか、そういうこと書いてなかったな、と思ったので、なぜ自分がMongoDBに興味を持っているのか、ということを書いてみた。いざ自分の思いを書いてみたらRails中心の話になってしまったけど、モダンなフレームワークならそんなに話は変わらないのかな、と思っている。 そもそものきっかけは、ここ半年間くらいRuby on Rails(以下RoR)で開発していることにある。 ここ半年弱ほどRoRで開発をして、それなりに満足しているのだけど、ActiveRecordに関しては色々とひっかかるところがあった。 「ActiveRecordがRoRの素晴らしいところそのものだ」と評価している人もいるが、自分の中では逆で、ActiveRecordはRoRの中でもかなりいまいちな部分。 いや、ActiveRecordと
MongoDBを今日から始めるためのドキュメント - Masatomo Nakano Blog
追記: 最新情報はこちらです。 MongoDBが流行ってきてる風なので、これだけ読んでおけばMongoDBの雰囲気がわかるだろうってところを、日本語訳が終わっているところから集めてみた。 なるべく順に読めるように並べたつもりだけど、前後してるところもあると思うので、とりあえず読み進めるのをお勧め。 まず、何はなくとも、 コレクション (Collections) 次にコレクションを触るためのシェル。MongoDBのシェルというのは、RDBMSでいうとSQLを直接叩くところで、PostgreSQLのpsqlコマンド, MySQLのmysqlコマンドみたいなもの。 実際にMongoDBを使って開発する場合、直接MongoDBを操作するよりも、各言語(PHPとかRubyとかJavaとか)のマッパー経由で使うことが多いとは思う。しかし、SQLを知らないとO/Rマッパーを使いこなすのが難しいように、シ
RspecとCucumberでTDD/BDDを極める (The Rspec Bookの紹介) - Masatomo Nakano Blog
本の紹介第2弾。少し前、Twitter上でTDD/BDDについて盛り上がっていたので、この本を紹介してみたくなった。 「The Rspec Book: Behaviour Driven Development With Rspec, Cucumber, and Friends」という本。 この本は、RspecとCucumberを使い、どう考え、どうシステムを作っていくか、というをチュートリアルを交えながら紹介する構成になっている。 ただUnit Testを紹介するだけではなく、Unit TestツールであるRspecに、BDDツールであるCucumberを組み合わせて使うことで、Unit Testでカバーできない部分をCucumberで補い開発をする、というところがこの本の肝になっている。 この本を読み、実践することで、Unit Test*だけ*を書いてシステムを作っているときのモヤモヤ感
Sinatra+mongoDB - Masatomo Nakano Blog
このブログシステムは Sinatra とKVS(とりあえず最初は mongoDB )で遊ぶために作った。 ここ数カ月、RoRを使って開発してみてるけど(その前はphp)、やっぱり色々と重厚すぎるので、ちょっとしたWebアプリには向いてない気がしている。 で、Sinatraを試してみたんだけどなかなかいい感じ。後発だけあってRoRをかなり意識した上で無駄を削ぎ落した感じ。「無駄」というと怒られるか。 今回はSinatraとMongoDBの繋ぎの部分に MongoMapper を使ってみた。ruby + mongoDBで、rubyからmongoDBを使う場合、まだまだ「デファクト」と呼べるような物はないみたい。いくつか同じような物が開発中のよう。その中からMongoMapperを選んだのは最低限の機能ありそう＋開発が活発ってぐらい。ただ、最近twitterでmongoidってのがあるというのを
システム開発するときに気を付けてること - Masatomo Nakano Blog - Web開発を極める
昨日に続いて普段心がけていることや、周りの人に期待してることを垂れ流してみる。誰かが言ってたり書いてたりしたものパクってるのもある。当然なことばかりだけど意外とできなかったりすることだと思ってる。 ツールはツールでしかない 新しい管理ツールやコーディングのためのツールを導入したらバラ色だと思う勘違い。ツールはツールでしかないんで、なぜそのツールを使うのかという本質を理解しないで導入しても、導入コストだけかかって意味がない。 開発手法は開発手法でしかない 上と同じ。新しい開発手法を取り入れたら生産性が必ず上がると思う勘違い。 フレームワークはフレームワークでしかない 上と同じ。 コーディングの早さはハマってる時間の短さ ハマることは必ずしも悪いことではないし、早ければいいわけではないが、ハマってることを意識することは大事。また、同じようなことでハマることが続くならなら、基礎的なことを先にまと
アジャイル開発をやってみて - Masatomo Nakano Blog
注：まだよくわかってない。 (前職含め)普通のウォーターフォールな開発の経験はそれなりにあり、その大変さは知ってるつもり。もちろん！、デスマーチの経験もあり。ただアジャイルの経験はほとんどなし。こんな自分が今さらながらアジャイル開発を初めてやってみた感想をメモ。 やってみることになった経緯。現在の会社では、小さい会社ということもあり、今まで部分的にウォーターフォールな感じで、残りは力技で開発してきた。今まではそれでなんとかなっていたんだけど、そろそろそれもまずいよね、という感じになってきたので、小さめのプロジェクトでアジャイルっぽい開発をやってみた。Webのアプリケーションで画面数的には(結果的に)大小含め11ぐらいの規模のプロジェクト。 プロジェクトメンバーは、開発側はプロジェクトマネージャを入れて４人。プロジェクトマネージャ（兼コンテンツ担当）とデザイナー、フロントエンドエンジニア的な
CouchDBとMongoDBを比較してみた - Masatomo Nakano Blog
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
