今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う

Docker をいじって遊んでいる。 http://www.docker.io/ Docker は PaaS ベンダの DotCloud がその PaaS のバックエンドとして使っている (?) ミドルウェアを公開したもの。適当な条件の VM をポコポコ生み出してはテストや実際の運用に使うことができたりするもの。例えば「Ruby と Bundler が入っている VM」みたいなのを設定で作っておくと、後日何か Ruby でアプリケーションを動かしたいと思ったときにそのイメージをベースに VM を作ってデプロイしてやればすぐにアプリケーションが動き出す。そもそも PaaS がやっているのはそういう事で、それを汎用化したのが Docker。Travis CI のような、各言語ごとの実行環境が整った VM みたいなものに任意のコードを渡してビルドさせる、みたいなプラットフォームを作るのにも使える

また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ

で、ここからが本題なのですが、情報収集方法について幾つかの質問を作成しそれをバトンのように回していったら、気になるアルファブロガーの丸秘テクニックが!ここに明らかに!となればいいな、と思いました。 面白そうなので答えてみます。 1. RSSリーダーを使っていますか?(y/n) yes、はてなRSS。(http://r.hatena.ne.jp/naoya/) 登録数は 150 くらい。 2. アンテナを使っていますか?(y/n) yes、でも RSS に比べたら頻度は低いかな。登録数は 50 くらい。 3. ソーシャルブックマーク(SBM)を使っていますか?(y/n) yes、一番ヘビーに使ってるのはこれですね。 4. その他情報収集に使っているツールはなんですか? 昔作った RssRolling はいまでもたまに見る。メンテしてないけど。Google News を RSS に変換したやつ

ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような

結城さんのデザパタMLでも紹介されてしまった手前、さぼるわけにもいくまい、ということで「機能の階層と実装の階層を分ける」 Bridge パターンです。 使いどころはたくさんありそうでなさそうでありそうな(どっちだ)、個人的には結構好きなパターンです。プログラムを拡張するには、クラスを追加するわけですが、あらかじめ「機能」を追加するのか、「実装」を追加するのかという視点で二つの階層に分けて実装しておくことで、拡張しやすい構成にしましょうというパターンです。 +-------------+ |Hello, Japan.| +-------------+ +-------------+ |Hello, World.| +-------------+ +----------------+ |Hello, Universe.| +----------------+こんな感じの出力を作りたい場合、まず

ようやく8つめ。まだ残り 15 あります。8つめは「関連する部品を組み合わせて製品を作る」Abstract Factory パターン。複数のオブジェクトを正しい組み合わせで生成されるようにしたい、といったときに使うパターンです。 デザパタ本の題材は階層構造を持ったリンク集ページを作る、というものですね。 LinkPage * 新聞 o 朝日新聞 o 読売新聞 * サーチエンジン o Yahoo! + Yahoo! + Yahoo! Japan o Excite o Google -- 伊藤 直也こんな感じの出力を HTML で出してみましょう、というもの。 集合を扱う Tray クラスと、各個別のリンクを扱う Link クラスを用意してそのインスタンスを操作しページに相当する Page クラスに追加していくことでこの出力を作ります。ただ、出力は ul/li によるリスト構造による出力とか

7つめは、「複雑なインスタンスを組み立てる」Builder パターンです。 var Main = Class.create(); Main.prototype = { initialize : function () {}, main : function () { var builder; if (arguments[0] == 'plain') builder = new TextBuilder(); else builder = new HTMLBuilder(); director = new Director(builder); director.construct(); document.writeln(builder.getResult()); } } というクライアントがあり、その出力は引数が plain なら ============================ 『G

続きまして「コピーしてインスタンスを作る」Prototype パターンです。デザパタ本では6章にあたります。 var Main = Class.create(); Main.prototype = { initialize : function () {}, main : function() { var manager = new Manager(); var upen = new UnderlinePen('~'); var mbox = new MessageBox('*'); var sbox = new MessageBox('/'); manager.register("strong message", upen); manager.register("warning box", mbox); manager.register("slash box", sbox); docum

次は「たった1つのインスタンス」Singleton パターンです。あるクラスがあって、そのクラスのインスタンスは実行アプリケーションのライフサイクルを通じて唯一に制限したい、何回生成しても同じインスタンスである、というものです。 var Main = Class.create(); Main.prototype = { initialize : function() {}, main : function() { document.writeln('Start.<br>'); var obj1 = Singleton.getInstance(); var obj2 = Singleton.getInstance(); if (obj1 == obj2) { document.writeln('obj1 と obj2 は同じインスタンスです。<br>'); } else { document

お次は「インスタンス作成をサブクラスにまかせる」Factory Method パターン。これまた定番。 var Main = Class.create(); Main.prototype = { initialize : function() {}, main : function() { var factory = new IDCardFactory(); var cards = new Array( factory.create('Erich Gamma'), factory.create('Richard Helm'), factory.create('Ralph Johnson'), factory.create('John lissides') ); for (var i = 0; i < cards.length; i++) { cards[i].use(); } } } とい

次は「具体的な処理をサブクラスにまかせる」Template Method パターン。定番ですね。 var Main = Class.create(); Main.prototype = { initialize : function () {}, main : function () { var d1 = new CharDisplay('H'); var d2 = new StringDisplay('Hello, world.'); var d3 = new StringDisplay('Oh! JavaScript'); d1.display(); d2.display(); d3.display(); } } みたいなクライアントがあります。出力結果として、 [[HHHHH]] +-------------+ |Hello, world.| |Hello, world.| |Hel

Iterator に続きまして、「一皮かぶせて再利用」な Adapter パターンです。クライアントは var Main = Class.create(); Main.prototype = { initialize : function() {}, main : function () { var p = new PrintBanner("Hello, World"); p.printWeak(); document.writeln('<br>'); p.printStrong(); } } といった感じ。PrintBanner クラスは別のレガシーなクラスのアダプタで、インタフェースを肩代わりしてやっていると。 実行結果は (Hello, World) *Hello, World*となります。 今回もやっぱり interface に相当するものは作らずにやってみます。(Adapter

Ruby on Rails や Catalyst のプラグインなんかでは prototype.js という JavaScript のライブラリを使って、Ajax サポートを実現しています。prototype.js とフレームワークが必要な Ajax の JavaScript コードを吐き出してくれるので、Ruby プログラマや Perl プログラマは JavaScript の実装を意識しなくても Ajax なインタフェースが作れる、という風になっています。 こんな感じで prototype.js は Ajax な部分に注目が集まっていますが、ほかにも "Class-style OO" なフレームワークも内包してます。 JavaScript はプロトタイプベースのオブジェクト指向言語で、C++ や Java のようなクラスベースのオブジェクト指向言語とはちょっと実装が異なります。プロトタイプ

Vagrant 1.1 がリリースされました。 Vagrant は仮想サーバーのフロントエンドのツール、詳しくは Vagrant - naoyaのはてなダイアリー あたりを。 で、この 1.1 が 1.0 → 1.1 という割に結構大きなアップデートで新しく VM に VirtualBox 以外のものが選択できるようになった。すなわち「VirtualBox のフロントエンド = Vagrant」から「各種仮想マシンのフロントエンド = Vagrant」という風にアップデートされた。 今回の 1.1 からVMを操作するproviderがプラグイン構造となり、VirtualBoxだけならず、公式で操作できる対象が増えました。 VirtualBox VMware Fusion Amazon EC2 + VPC Rackspace Cloud VMware Fusion以外はオープンソースで公開さ

昨日は RubyMotion のもくもく会でした。 先日の RubyMotion Kaigi 2013 で 実践RubyMotion という題目で発表したのだけど、テストについてはprintデバッグ上等だ、このクソムシがとか言ってかなり適当に済ませてしまった。ので、もくもく会ではテスト周りに手をつけるぞと思い、そういえば Travis CI が RubyMotion に対応してたのも思い出し RubyMotion のテストを Travis CI で回すのを検証した。 が、手間取るかと思った Travis CI 周りはとっても簡単で、.travis.yml に language: objective-c と書くだけであっさり動いてしまった。 というわけで RubyMotion アプリの継続的インテグレーションは .travis.yml を一行書けば完了です。終わり･･･じゃあまったくブログ記

数日前に Pixate という iOS 向けミドルウェアがリリースされました。なんとiOSアプリの見た目を css で書けるという、全ウェブ開発者感涙のライブラリ。こりゃすげえ。ただし無料というわけにはいかず、18,000円くらいでこざいます。 2月9日 追記 トライアル版と、個人利用のための無料版が出たようです。 RubyMotion の teacupのように css チックな DSL で書ける、というものはありましたが Pixate はその辺とは次元が違ってて、普通に css ファイルに css を書くことができる。 button.blue { position: 60, 100; size: 200, 40; border-radius: 7px; font-family: 'Courier New'; font-size: 18pt; font-weight: bold; bord

Heroku の新機能で Heroku Button が出た。 見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。 ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。 GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。 ご満悦。 このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。 すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。 Heroku Button Heroku Button を有効にするための前提は割とシンプルで Git

昨年 ELPA で elisp を管理 - naoyaのはてなダイアリー に書いたとおり、昨今は Emacs にもパッケージ管理システムが搭載されいて、どこからか elisp をコピペしてきてその後管理できなくなる･･･みたいなことはなくなった。 ただ、じゃあ ELPA で全て解決したかというとそんなことはなくて、ELPA はパッケージのインストール自体は簡単にしてくれるけれども、それだけだった。 elisp の管理も Bundler のように入れたいパッケージ一覧を書いて bundle install すれば全部まとめて入るみたいな、そういうのが欲しい･･･と常々思っていた。 と思っていたら、Cask というのを見つけた。これがずばりそのものだった。 (source gnu) (source melpa) (source marmalade) (depends-on "ag") (dep

今年3月に入門Chef Soloを書いた時点では、Chef Solo は Environments の機能をサポートしてなかったため解説は省略しました。 その後、Chef はバージョン 11.6.0 (現在は 11.8.2) で Chef Solo での Environments をサポートし、入門Chef Solo で推薦している knife-solo も 10月末にリリースされた 0.4.0 から Environments をサポートしました。というわけで、現状 Chef と knife-solo が最新版であれば Environments を利用することができます。 たまたま今手をつけている仕事で Environments のことを調べたので備忘録的に記しておきます。 Environments とは Chef の Environments は、例えば development や pr