Railsのdatabase.ymlにはRubyのコードを埋め込める - ひげろぐ
今回のネタはRailsレシピより。 database.ymlはYAMLとしてパースされる前にERBで前処理されるので、ビューのテンプレートと同じようにRubyスクリプトをファイル内に埋め込むことが可能。 なのでdatabase.ymlの内容を以下のように動的に定義することができる。 < % socket = ["/tmp/mysqld.sock", "/tmp/mysql.sock", "/var/run/mysqld/mysqld.sock", "/var/lib/mysql/mysql.sock"].detect{|socket| File.exist?(socket)} %> development: adapter: mysql database: hoge_dev username: hogetarou password: password host: localhost soc
Rubyのクラスに動的にクラスメソッドを追加する - ひげろぐ
クラスの特異クラスにメソッドを追加すればクラスメソッドを追加できる。 class Hoge class << self ["method_a", "method_b"].each do |method_name| define_method method_name do |param| "#{param} was passed to #{method_name}" end end end end クラス定義外で以下のようにしても同じ。 class << Hoge ["method_a", "method_b"].each do |method_name| define_method method_name do |param| "#{param} was passed to #{method_name}" end end end 理屈としては クラスメソッドはクラスの特異メソッドである 特
RSpecの violated と pending - ひげろぐ
Test::Unitにおけるflunkと同じようなもの。 it のブロック内に内に書くとそのテストケース（Example）は必ず失敗する。 it "昨日布団の中で思いついた仕様" do violated end さっさとテスト書けよというプレッシャーが漂う。 テスト自体や実コードの実装の保留状態を示す。 it のブロック内にpendingと書くと、その行以降の処理は実行されない。 pendingメソッドを使うときには引数に必ず理由を書かなくてはならない。 it "一昨日風呂の中で思いついた仕様" do pending("やんごとなき理由") # 検証されないエクスペクテーション end またpendingにはブロックを与えることができ、その場合はそのブロック内の処理だけがペンディング扱いになる。 it "こないだバイクに乗ってて思いついた仕様" do pending("大人の事情") do
Knife Sousを使って複数サーバーでChef Solo - ひげろぐ
複数サーバーでChef Soloを使うのにCapistranoとchef-soloを組み合わせてやっていたけど、最近モダンなやり方を勉強しようと思っていろいろ調べていたら、Knifeのプラグインとして動くKnife Sousなるものを見つけた。 少し触ってみただけだけど、まあいいかんじ。 RakeライクなDSLで環境ごとのネームスペースを設けてノードを管理できる、と言うのがKnife Sousの特徴。 加えて特定のネームスペースに属する複数ホストへのknife soloを一気に実行できる。 設定ファイルを書いた上で以下のように使う。 $ knife sous bootstrap production $ knife sous bootstrap production web1 # 一つだけ実行も可能 $ knife sous prepare vagrant $ knife sous coo
Titanium MobileとRubyMotionの比較 - ひげろぐ
双方とも脱Objective-Cを実現してくれるプロダクトだけど性格はけっこう違う。 共通で興味を持っている人が多そうなので思うところをとりとめもなく書いてみる。 取っつきやすさ iOS SDK開発未経験者がとっつきやすいのはTitanium。おそらくRuby経験者でも。 逆にiOS SDK経験者ならばRubyMotionの方が入って行きやすいかもしれない。 RubyMotionはiOS SDKのAPIをタイトになぞっているためにiOS SDKのAPIに関する知識が必要だが、iOS SDKのAPIには直感的じゃない部分が多々あって、それに馴染むまでけっこう時間がかかる。その学習コストがけっこう高い。 TitaniumのAPIはTitanium独自のものだが整理されていて扱いやすい。学習コストは皆無ではないがiOS SDKに比べればずっと楽。 またObjective-Cよりマシとは言えRub
Capistranoとchef-soloを組み合わせて使う - ひげろぐ
たくさんのホストをChef設定したいけどChefサーバー立てるのめんどくさいし！ でもコマンド一発ですべてのホストが更新されて欲しいし！ というわけでこの組み合わせです。 Capistranoはインストール済みでsshのログインに必要な鍵も各ホストに配ってあるものとする。 加えてChefのクックブックなどはすでに定義済みで以下のパスにある前提で。 /home/akahige/chef-repo Chefに関してはここでは深くつっこまないので、よかったら以前書いたものをどうぞ。 chef-soloで作業環境構築の自動化 | ひげろぐ Chefを試してみた | ひげろぐ sudoの設定 chef-soloはsudo経由（root権限）で実行する必要がある。 そしてCapistranoでsudoを実行するにはパスワードなしでコマンドを実行できる必要がある。 そういう事情なのですべてのホストにてs
Jasmine用のVimスニペット - ひげろぐ
Jasmineを一通り使えるようにした後で「毎回 describe(“ほげほげ”, function() {〜とかいちいち書くのって実用的に無理じゃね？」と思い、やっぱり使うのやめようかと考えたりした。 が、そこでVimのスニペットの存在を思い出し踏みとどまった。 ~/.vim/snippets/javascript.snippetsに以下を追記。 # describe for jasmine snippet d describe("${1:comment}", function() { beforeEach(function() { }); }); # it for jasmine snippet it it("${1:comment}", function() { }); スニペット激しく便利すなあ。 2011/01/10追記 プラグインあった。 Jasmine snippets (f
Node.jsとJasmineでJavaScriptのBDD環境 - ひげろぐ
Jasmineでスペックを書いていく環境を整えるのにJasmine Toolなるものを試してみた。 なお最近なんだかJasmine押しですが、Jasmineしか試してないだけであり他意はありません。 2011/01/12追記 Jasmine Toolはブラウザを介するもので、普通のJasmineとやってることは変わらない。 Node.jsを使って動かすのであって、Node.jsのソースをテストするのではない。ややこしいけど。 Node.jsのモジュールのテストにはjasmine-nodeやvowsが向いていそう。 両方試してみてjasmine-nodeについては書いた。 Jasmine Tool そもそもこれはなんぞや Jasmine ToolはNode.jsで動くコマンドラインのツール。 簡単に言うとrubygemsのjasmineのNode.js版。 rubygems版との違いはRub
Titanium Mobileを二ヶ月くらいさわってみた感想。 - ひげろぐ
今年に入ってからほぼ毎日触ってました。でもほとんどiPhone開発しかしてない感想。 主観的なところをだらだらと書いてみましょう。 とりあえず気に入っているところイマイチと思うところを挙げてみたい。 合わせて総評など。 気に入っているところ さくさく開発できる Objective-Cとは段違いの開発効率。 冗長なメソッド名とメモリ管理の煩わしさからの解放がうれしい。 ちょっとしたモックアップ程度ならさくっと作れてしまう。 そこから開発者が作り込みに注力できる環境が見事にできあがっているのではないかと。 JavaScriptはくせもあるけどおおむね使いやすい言語。 CoffeeScriptとの組み合わせでさらにいいかんじ。 TDDできる Jasmineで気持ちよくTDD出来ている点が非常にポイント高い。 おかげでTitaniumラブですよ。 Objective-CでもTDD可能だけど、OCU
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ページを開く
