Chefを試してみた - ひげろぐ
直近の仕事でそこそこの規模のインフラを構築する機会ができたこともあり、以前からちょっと気になっていたChefを試してみた。 ChefはPuppetと同じようなインフラの構成管理ツール。現行のバージョンは0.9.8。 Puppetと同じように管理対象となる各マシンにはChefのクライアントを入れ、構成を管理するために一台Chefサーバーを立てるという運用をする。 このサーバーのインストールがけっこうしんどかった。 セットアップには主に以下のページを参照。 Installation – Chef – Opscode Open Source Wiki Chefクライアントのインストール RubyとRubyGemsが入っていればgemでさくっと入る。 必要なRubyのバージョンは1.8.6以上。 $ sudo gem install chef Debian、Ubuntuならばapt-getで、Ce
CoffeeScriptでクラス変数やクラスメソッドを使う - ひげろぐ
やり方 定義の際に@を頭に付ける。 class Something someProp: "hoge" someMethod: -> ... @someClassProp: "HOGEHOGE" @someClassMethod: -> ... どうやってやるんだろうと探したらドキュメントに追記っぽくちょろっと書いてあった。 object itself (the constructor function), you can assign static properties by using @property: value, and call functions defined in parent classes: @attr ‘title’, type: ‘text’ まあドキュメント自体がちょっと解説のついたチートシートみたいな具合なので、いろいろなことがちょろっと書いてある。 Java
CapistranoでWhenever - ひげろぐ
昨日の続き。 Whenever標準でCapistranoのタスクが用意されているので、簡単に組み合わせることができる。 deploy.rbの編集 以下の行を適当な場所に挿入。例えばロールを定義している下あたりとか。 set :whenever_command, "bundle exec whenever" require "whenever/capistrano" これだけでもうcap deployすればconfig/schedule.rbの内容がCrontabに反映されるようになる。 ロールの設定 Wheneverの対象となるデフォルトのロールは:dbになっている。 必要ならば:appに変更したり、適当に:batchなどのロールを作ってdeploy.rbに書く。 set :whenever_roles, { :batch } 複数サーバーで実行されると負荷などが面倒になりそうな処理を実行
WheneverでRailsのバッチ処理 - ひげろぐ
WheneverはCronを利用して繰り返し処理を行うためのライブラリ。 シェルコマンドやRailsのRunner、RakeタスクなどのジョブをCronで実行できる。 実際のところCrontabへの登録を補助してくれるだけなのだが、そのシンプルさがかえって分かりやすい。 バッチ処理の管理にうってつけ。 タイトルではRailsとなっているがRails以外でも利用できる。 以下はRails3での使い方メモ。 導入 Gemfileに以下の行を追加してbundle install gem 'whenever', :require => false schedule.rbの編集 config/schedule.rbにスケジュール設定を書いていく。 bundle exec wheneverize . を実行するとひな形を作ってくれるので、それを元に編集していくのが吉。 スケジュールは「every」に続
Interface Builderよ、さようなら - ひげろぐ
というわけでここ数日の間に「Interface Builder使わない派」にめでたくクラスチェンジしました。 今までは「ケースバイケースでInterface Builderも有り派」という穏健な一派に属していたが、iPhone SDKの理解度が上がるにつれ必要性を感じなくなってきたと言う。 そもそもInterface Builderを使うメリットは UIのデザインがGUIベースですばやく簡単にできる というものだが、この機能で物足りなく感じていたこととして UIの動きまではわからない Xcodeとの連携がシームレスと言えるほどではない 静的なUIの設計部分はさくさく気持ちよくできるものの、動かさないと分からないと言った面もあるわけで、要するにInterface Builderの中でUI設計が完結しないところがイマイチだなあと。 またコードとの連携の簡単さに関しては10年くらい前にさわったき
RSpecの violated と pending - ひげろぐ
Test::Unitにおけるflunkと同じようなもの。 it のブロック内に内に書くとそのテストケース（Example）は必ず失敗する。 it "昨日布団の中で思いついた仕様" do violated end さっさとテスト書けよというプレッシャーが漂う。 テスト自体や実コードの実装の保留状態を示す。 it のブロック内にpendingと書くと、その行以降の処理は実行されない。 pendingメソッドを使うときには引数に必ず理由を書かなくてはならない。 it "一昨日風呂の中で思いついた仕様" do pending("やんごとなき理由") # 検証されないエクスペクテーション end またpendingにはブロックを与えることができ、その場合はそのブロック内の処理だけがペンディング扱いになる。 it "こないだバイクに乗ってて思いついた仕様" do pending("大人の事情") do
RVMとCapistranoを組み合わせて使う - ひげろぐ
デプロイ先のRubyをRVMで入れている場合、そのRubyをCapistranoが見つけてくれないのでうまくデプロイが進まない現象が起こる。 それをうまく動かすためにひと工夫。 rvm capistrano plugin Capistranoを実行するマシンとデプロイ先のマシンの両方にRVMの1.0.1以上が入っている場合は、RVMのプラグインで解決できる。これはデフォルトで入っているので特にインストールしたりする必要はない。 deploy.rbの先頭に以下のコードを追加。 set :rvm_type, :user $:.unshift(File.expand_path('./lib', ENV['rvm_path'])) require "rvm/capistrano" set :rvm_ruby_string, '1.9.2' rvm_typeはRVMをrootでインストールしている場
CapistranoでUnicornの起動と停止と再起動 - ひげろぐ
ちょっとした気まぐれでUnicornを使ってみた。 初Unicorn。 ということでUnicorn用のCapistranoのタスクをdeploy.rbに書いた。 内容はだいたい以下の受け売り。 Capistrano tasks for starting unicorn — Gist Twiwt:Blog / jugyo : Capistrano によるデプロイ時に Unicorn の再起動に失敗することがある問題への対処 namespace :deploy do task :start, :roles => :app, :except => { :no_release => true } do run "cd #{current_path} && BUNDLE_GEMFILE=#{current_path}/Gemfile bundle exec unicorn_rails -c #{cu
マイグレーション関連のRakeタスクの再確認 - ひげろぐ
Rails 2.1になってマイグレーション周りで追加されたタスクや覚えておくべきタスクについての確認。 追加された db:migrate:up db:migrate:down 覚えておいた方がよくなった db:rollback db:migrate:redo db:abort_if_pending_migrations 追加された – 各マイグレーションのupとdownを任意に実行できるように 2.1からRakeタスクに「db:migrate:up」と「db:migrate:down」が追加された。 これにより各マイグレーションのupとdownが好きなタイミングで任意に実行できるようになった。 それぞれupとdownを実行したいVERSIONを指定して実行する。14桁。めんどくさくてもちゃんと指定する。指定しなくてはならない。 $ rake db:migrate:up VERSION=20
RSpecでモックとスタブ - ひげろぐ
きちんと理解してなかったのでいろんなページを参考にいじくりまわしてみた。 そのメモ。 モックとはスタブとは Martin Fowler’s Bliki in Japanese – TestDoubleの定義がわかりやすいので引用。 スタブは、テスト時の呼び出しに対して、あらかじめ用意された結果を返す。 通常、テスト用にプログラムされたところ以外には応答しない。 スタブは呼び出しの情報を記録することもある。 例えば、Eメールゲートウェイスタブは「送られた」メッセージを記録するような場合だ。 単に「送られた」メールの数を記録する場合もあるだろう。 スタブによってデータベース接続やネットワークIOなどの要素をテストから分離することができる。 また時間のかかる処理をスタブで置き換えることによってテスト時間を短縮することにも使われる。 モックは、エクスペクテーションが事前にプログラムされたものである
RailsでAmazon Webサービス - ひげろぐ
以下のページを参考にAmazon WebサービスにRailsからアクセスしてみた。 かなり楽ちん。 RoRでAmazon Associate Web Serviceを使う : Mashupを作ろう : 記事 : MASHUPEDIA – マッシュペディア – : Web API x Mashup 前準備 まずamazon-ecsというライブラリをgemで入れる。 $ sudo gem install amazon-ecs 次にRailsのconfig/environment.rbの末尾にamazon-ecsのオプションの設定を書く。 require ‘amazon/ecs’ Amazon::Ecs.options = { :aWS_access_key_id => "hogehogehoge", :associate_tag => "stepfeed-22", :country => :j
Rails 2.3.4で追加されたseeds.rbについて - ひげろぐ
Seed Dataをマイグレーションから隔離するための仕組みが追加された。 これの一番の意図としては 「マイグレーションの中にデータをいじるコードを含めるのやめようぜ。な！」 ってことのようだ。 参考: http://github.com/rails/rails/commit/4932f7b38f72104819022abca0c952ba6f9888cb Seed Dataって？ まあなんとなくニュアンスは分かるけど、そもそもSeed Dataって何なんだという疑問。 Rail Spikes: Loading seed data Ryan’s Scraps: What’s New in Edge Rails: Database Seeding 上記を参考にすると ほとんど変更されないデータ 例: Userテーブルの管理者アカウントのような初期データ 例: アプリケーションの設定のためのデ
addEventListenerで登録した処理が複数回実行される問題 - ひげろぐ
と言うものでしばしハマったのだが、原因はTitaniumのバグではなく仕様であり、自分のプログラムのやり方だった。 原因は同じイベントに複数のコールバックを設定できるため、同じ内容でaddEventListenerを複数回実行すると同じ処理が複数回走ってしまうというもの。 ハマりついでにいろいろ検証したのでaddEventListenerとremoveEventListenerの挙動を整理してみた。 イベントに複数のコールバックを登録する 同じイベントに対してaddEventListerを複数回呼び出すと、そのイベントに対するコールバックが複数登録される。 Ti.App.addEventListener("custom_event", function(e) { return Ti.API.info("ONE"); }); Ti.App.addEventListener("custom_e
Passengerがメモリを食いすぎるとき - ひげろぐ
Passengerを動かしているサーバのメモリ使用量が突然跳ね上がってスワップをガリガリ発生させることしばしばだったので最近いろいろ調整していた。 結論としては二つ原因があった。 Railsインスタンスプロセスの立ち上がりすぎ PassengerMaxPoolSizeを適切に設定してないとそうなることがある。 PassengerMaxPoolSizeのデフォルトは6なのでRailsインスタンスが一個につき400MBのメモリを食っていたら最大で2.4GBのメモリを食うことになる。 というわけでメモリが2GBのサーバでも撃沈する。（まあ400MB消費すること自体がおかしいけど） インスタンスひとつあたりのメモリ使用量を把握するにはしばらく動かしてみるしかないと思うので（何か方法あるかな？）最初は小さめに設定しておくのが無難かもしれない。 この値が1とか2くらいでも小さなサービスでは全く問題ない
requireでTitaniumのインクルードパスの問題を解決する - ひげろぐ
Ti.includeじゃなくてrequireを使うと幸せになれるっぽい。 CommonJSでJavaScirptのモジュールを定義することになるので、Ti.includeをそのまま置き換えることはできないけど。 これで黒魔術とおさらばできるかしら。 実験 app.js var window = Ti.UI.createWindow({ url: "lib/hoge.js" }); window.open(); Ti.includeとは違うところを確認するためにlib以下のurlを指定したウィンドウを開く。 lib/hoge.js var hoge = require("lib/fuga"); hoge.foo(); lib/fuga.jsのrequireを行う。 Resourcesからの相対パスで指定できているところに注目。 Ti.includeで同じような指定をすると Ti.includ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
