GoogleVisualr A Ruby Library for the Google Visualization API. Write Ruby code. Generate Javascript. Display a Google Visualization. Overview The Google Visualization API enables you to create interactive charts and graphs easily, something that's ever so useful for any dashboard design. Just write some JavaScript, and you will be able to embed a visualization in your web page. This Ruby library,

前から気になっていた Heroku + MongoHQ を試してみた。HerokuはRubyアプリケーションを走らせるホスティングサービスで、MongoHQはMongoDBのホスティングサービスだ。この二つを組み合わせることで、MongoDBを使ったRubyアプリケーションを一瞬で運用開始することができる。 あまりにも簡単に使えてあまり書くこともないんだけどメモ。 まず、両方とも最低限の環境は無料で使用できる(ただしHerokuからMongoHQを使うためにはクレジットカードの登録は必要っぽい)。 今回は Ruby on Rails 3 + Mongoid で作ったアプリを置いてみた。 手順 1. まず、普通に RoR + Mongoid のアプリケーションを作る 2. Herokuにアカウントを作りアプリケーションを登録する (http://docs.heroku.com/quickst

前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。 前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。 ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！ client vs node Chef Client Nodes ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。 client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて clien

ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。 Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。 基本的な仕組 これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。 rubyな設定ファイル Puppetは基本的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので

githubには個人でも会社でもお世話になってるので新しくできたJobボードに載せてみた。もちろん求人自体は本物なので興味ある人は応募してください。勤務地は東京です。 https://jobs.github.com/positions/a9bc8e26-a6d5-11df-8cf1-63a2a0cb612b 載せるのはとても簡単。Webフォームに求人内容を書いて、クレジットカード情報を入力して完了。プレビュー含めインターフェースがよくできてるのはさすが。載せると修正用のURLが送られてくるのでtypoとかにビビリ過ぎなくても大丈夫(自分は知らなかったのでかなりビビった)。 どのくらい応募があるのか楽しみ。 この求人についてちょっと補足すると、海外に興味はあるけど、いきなりは海外は自信ないとかの人の練習にちょうどいいと思います。技術があれば英語はこれからでも大丈夫です。日本オフィスにも英語な

(2010-08-30: Rails 3.0.0がリリースされたのでそれにあわせて更新。generator関連が少し変わってる) 前回 の続き。 主に FactoryGirl と MongoMapper の話。基本的に何も考えなくてもそのまま使えるのだけど。 まず、設定。 spec_helper.rb で、 config.use_transactional_fixtures = true を config.use_transactional_fixtures = false にする。そうしないと、ActiveRecord::TestFixtures が呼ばれてしまうのだが、ActiveRecordを入れてないので落ちる。 そもそもMongoDBにはトランザクションとかないのでfalseでいい。 後は、ActiveRecordで使う場合と同じように、FactoryGirlの定義の読み込みを

(2010-08-30: Rails 3.0.0がリリースされたのでそれにあわせて更新。generator関連が少し変わってる) 会社用の、小物Webアプリを作ろうかと思い、せっかくなのでRuby on Rails 3でmongoDB使ってみようかな、と思い、とりあえず環境を作るところまでのメモ。 Rails 3 のインストール とりあえず Rails 3 のインストール。Bundlerで入れる。Bundler自体のバージョンが1.0以上でないとダメみたいなんで、もしそれ未満しか入っていない場合にはBundlerのインストールからする。 プロジェクトのトップディレクトリとなるところを作成し、そこにGemfileを作る。 $ mkdir ~/workspace/hoge_prj $ cd ~/workspace/hoge_prj Gemfile source 'http://rubygems

とてもいい本だったので紹介してみる。 Metaprogramming Ruby: Program Like the Ruby Pros by Paolo Perrotta この本を読み始めてすぐに、自分がこの本に対してタイトルから想像していた内容と違うことに気付いた。 自分が想像していたのは、「こういうケースでは、こういうメタプログラミングをするといいよ」「こういうメタプログラミングのパターンもあるよ」というRubyでするメタプログラミングの実践編の本かと思っていた。でも、これは間違いで、この本はRubyでメタプログラミングができるようになるためのRubyの基礎知識が書いてある本だった(基礎、と言っても初心者向けというわけではなくて、Rubyのベース部分という意味で)。 想像とは違っていたのだけど、結果的に、ちょうど今自分が読むべき本だった。 自分は、この本を読むまで半年ちょっとRails

resqueシリーズ。 前回 も resque-scheduler について少し触れたのだけど。resque-schedulerのメインであるcron的に使う機能について書いてなかったのでメモ。deployについても書いた。 cronと比較して *nix系のシステムだと、伝統的に、何かを定期的に実行したいcronを使うのだけど、アプリケーションからcronを使う場合、いくつかの使いづらい点がある。 アプリケーション本体から離れた場所でcronの動きを管理しないといけない。通常、/etc/crontab 等をメンテナンスしないといけないのだけど、そこはアプリケーションの外側なので、メンテナンスするときにアプリケーション側で使っている方法を使いづらい(SCMもそうだし、deployとかも別で考えないといけない)。 cronから起動する場合、起動する環境について考えないといけない。環境変数が代表

ここを見てもらってる人に、「MongoDBって何がいいの？」と改めて聞かれてしまって、ああ、そっか、そういうこと書いてなかったな、と思ったので、なぜ自分がMongoDBに興味を持っているのか、ということを書いてみた。いざ自分の思いを書いてみたらRails中心の話になってしまったけど、モダンなフレームワークならそんなに話は変わらないのかな、と思っている。 そもそものきっかけは、ここ半年間くらいRuby on Rails(以下RoR)で開発していることにある。 ここ半年弱ほどRoRで開発をして、それなりに満足しているのだけど、ActiveRecordに関しては色々とひっかかるところがあった。 「ActiveRecordがRoRの素晴らしいところそのものだ」と評価している人もいるが、自分の中では逆で、ActiveRecordはRoRの中でもかなりいまいちな部分。 いや、ActiveRecordと

本の紹介第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*だけ*を書いてシステムを作っているときのモヤモヤ感

これとこれの続き。この後、もう少し調査して、Resqueを実際のシステムの一部で使い始めてみたのでその感想とメモ。 前回までのあらすじ Resqueはバックグラウンドでジョブの実行をするもので、かなりの大規模サイトでかつ更新系の処理が多そうなシステムであるGithubで開発され使われている。よくある使い方としては、「Web UIを軽く見せるため、処理の依頼だけを受け付け、実際の処理はバックグラウンドで実行」「バッチ処理などで、大量のJobをQueueに突っ込んでおいて、(複数の)workerで並列で効率よく処理」などがある。 不安なところ Resqueの大きな特徴は、QueueをRDBMSではなくRedis上に作るところにある。Redisは、Memcacheのようにシンプルに使え、すべてのデータはメモリ上に展開されるのでとても速く、データはディスク上にも永続化されるので、何かあったときにも

たまには読んだ本の感想。ちょっと前の本だし、有名どころだけどお世話になったので感謝の気持ちを込めて。 プログラミング言語などの新しい技術を習得するとき、最初の数日〜数週間は本を集中して読むことにしている。Web+検索エンジンは知りたいことがわかっている場合には便利だけど、何も知らない状態ではやはりまだ本に分がある。ある程度の知識を得てからはWebに頼り、一通りわかるようになった後で再度本を漁るという感じが多い。今のところこれが最速学習法だと思っている。 重い腰を上げ、Rubyを本格的に始めたのが半年ほど前。そのときに読んだ本の中の一冊がこれ。何冊か目に開いた本だが、今思えば最初に読むべきだったと強く思う。 この本は、他の言語をそれなりに知っている人がRubyを初めて学ぶ、ということに完全にフォーカスしている点が本当に素晴らしい。「入門〜」「はじめての〜」「〜日で覚える〜」系の本は、簡単過ぎ

前々回、前回に引き続き、もうちょっとResqueの練習。試しに、このブログの更新情報をTwitterに流す仕組を作ってみた。twitterfeed的なことをする感じで、ブログに投稿したら、Twitterにリンクをポスト、またN時間後にポスト、という感じで。うざそうなので実際には使わないかも。 追記: resque-schdulerのcron的な使い方について別のエントリで書いた。 このN時間後に投稿の部分にresque-schedulerを使ってみた。 Twitterへ投稿するライブラリは、grackleを使ってみた。特に深い理由はない。単純にポストするだけだから何でもいいかな、という感じで、簡単そうに使えそうなのを選んだ。 とりあえずインストール。 gem install grackle gem install resque gem install resque-scheduler Tw

前回 の続き(だがあんまり書くことなかった） Railsとの話の前に、前回書き忘れてしまったのだけど、resqueには、1日1回実行する、と言ったスケジューリングの機能はない。スケジュール機能は別のそういう機能を持ったソフトウェアに任せる(代表例: cron)か、自分で作る必要がある。また、resque-scheduler といresqueのプラグインタイプの物もある。現在どの方法が良さそうかか評価中なのでそのうち書く。 さて、Railsとの連携だが、resque自体がそもそもGitHubのRailsシステム用に作られたという経緯から、もちろん非常に親和性が高い。たとえば、worker毎にRailsのEnvironmentが一回ロードされるだけなので余計な資源を食わなかったり、RailsアプリのWeb UIから非同期な処理の扱いなども簡単にできる。 さて、インストール ./script/p

そこそこの規模のWebシステムになってくるとバックグランド処理(batch処理)は欠かせないものになってくる。メールの送信、データの日次、月次、年次処理、削除(フラグ)データのpurgeやバックアップ、等々いろいろな物が出てくる。 現在はBackgrounDRbを使っているが、いろいろといまいちなので今回Resqueを評価してみた。ちょっと触った段階での第一印象をメモ。 まず、バッチ処理系で評価のポイントになってくる部分はなんだろうかと考えてみると、なんと言っても見通しのよさと異常系の処理だと思う。画面系と違い、バッチ処理は「見えにくい」ところで実行されるので、その二つが特に大事になってくる。「知らないうちに止まっていました」では困るのがバッチ処理。 たとえば、 異常時の処理無視?管理者に通知?リトライ? 復旧処理タスクの削除(問題を修復後)リトライ 状態の監視いくつのJobが残っているか

すっかりEvernoteブログになってるなー。 最初のエントリでも書いたように、このブログはEvernoteで書いてる(この文章自体も)。 APIキーの取得については以前書いたのでそちらを参照ください。 Evernoteからブログへのデータ取り込み部分のソースを出しておく。クラス構造とか設定ファイルとかは端折って、実際に動くところのみ。Evernote公式のrubyライブラリはいまいち使いにくい。もうちょっとrubyっぽいサードパーティのwrapperとかあってもよさそうだけど、今のところなさそうだし作るのもだるい。 処理の流れとしては、 自分のアカウントで認証 "blog"というタグが含まれている全ノートを抽出 ノートを一つずつ舐めて、自分のWebアプリにデータ取り込み 認証 とりあえず、関連するライブラリをrequireしてから認証処理。この辺はサンプルのまま。 require "th

いつものようにEvernoteを検索してて気づいた。Evernoteって画像内の文字認識をするみたい。公式の説明どこかにあるんだろうけど見逃してた。PDFが検索できるのは知ってたんだけど。 これは、とあるミーティング後のホワイトボードをiPhoneで撮ってEvernoteに突っ込んであったもの。calendarという（汚い）字を認識して検索してる。赤枠とちょっとモザイクかけた以外の加工はしてない。検索してヒットした文字の部分が強調して表示される。 さらに、APIで画像の中に入っている単語とその場所の一覧、も取れることを確認した。なんか遊べそうだなー。 rubyでのコード例 filter = Evernote::EDAM::NoteStore::NoteFilter.new # calendar で検索 filter.words = "calendar" res = noteStore.fi