will_paginateに移行 - ひげろぐ
will_paginateのアップデートによってインストール方法など一部の情報が古くなっています。 関連：will_paginateもgithubに行ってた この間Rails2.0に移行したときにいったん放置したwill_paginateへの移行を行ったのでメモ。 それほど手間ではなかった。 ぐーぐる先生が教えてくれたページやREADMEを読みつつ作業。 プラグインのインストール さくっと。 $ script/plugin install svn://errtheblog.com/svn/plugins/will_paginate コントローラの修正 以下のようにコードを修正。コメントアウトしたものは修正前のもの。 def list # @pages, @items = paginate(:items, :conditions => ["deleted = 0"], :order => '
ShowOffでプレゼンテーション作成をためした - ひげろぐ
schacon/showoff – GitHub なんだか今年のRubyKaigiで使っていた人が多かったらしい。と聞いて興味がわいたのでちょっといじってみた。 なんぞや テキストベースでプレゼンテーションスライドを作成できるツール。Sinatra製。 ページ遷移やリスト表示のアニメーションなどを手軽に定義することができるので、簡単にそこそこ動きがあって見栄えのするものが出来上がる。 Markdownの文書を !SLIDE という行で区切っていくとスライドができちゃいます、と言うことが理解できればShowOffの半分は制覇したと言える。たぶん。 JavaScriptやスタイルシートを埋め込むことができたり、コードのシンタックスハイライトも備えていて、プログラマ向けのプレゼンツールとしてはなかなかよさげに思える。 またテキストなので バージョン管理と相性が良い 別のプレゼンでのスライドの再利
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」に続
とりあえずのGuard::Shell - ひげろぐ
List of available Guards – GitHub を見るといろいろ増えているGuardたち。 だがその中にもまだ用途に合うGuardがないとき、またはあるけどイマイチ気に入らないとき。 そんな時に汎用的に使えるのがGuard::Shell。 guard/guard-shell – GitHub これはファイルが変更されたら任意のシェルコマンドを実行するというもの。 guard init shellでGuardfileに追記される内容を見てみると guard 'shell' do watch('(.*).txt') {|m| `tail #{m[0]}` } end Rubyで外部コマンド叩いてるだけと言うなげっぱなしの姿勢がすばらしい。 でも便利。 ちょっと前Sphinxを使っていたときは以下のようなGuardfileを作って使っていた。 guard 'shell' do
RSpecでモックとスタブ - ひげろぐ
きちんと理解してなかったのでいろんなページを参考にいじくりまわしてみた。 そのメモ。 モックとはスタブとは Martin Fowler’s Bliki in Japanese – TestDoubleの定義がわかりやすいので引用。 スタブは、テスト時の呼び出しに対して、あらかじめ用意された結果を返す。 通常、テスト用にプログラムされたところ以外には応答しない。 スタブは呼び出しの情報を記録することもある。 例えば、Eメールゲートウェイスタブは「送られた」メッセージを記録するような場合だ。 単に「送られた」メールの数を記録する場合もあるだろう。 スタブによってデータベース接続やネットワークIOなどの要素をテストから分離することができる。 また時間のかかる処理をスタブで置き換えることによってテスト時間を短縮することにも使われる。 モックは、エクスペクテーションが事前にプログラムされたものである
RubyでHTMLタグ除去 - ひげろぐ
Railsでsanitizeやstrip_tagsといったメソッドが存在するが、ビューのヘルパーとして定義されているので、どこでも使えるものではない。 これをコントローラーやモデルの中で何とかして使うこともできるようだが、同等の機能を提供するSanitizeというgemがあるのでこちらを使った方が楽だ。 導入 gemで入れる。 gem install sanitize 使い方 すべてのタグを削除する Sanitize.clean(html_string)でhtml_string内のタグを削除する。 irbで試してみる。 :001 > require 'sanitize' => true :002 > html_string = "<h1>hello clean world</h1>" => "<h1>hello clean world</h1>" :003 > Sanitize.clean
テストコードを書くコストに関する考察 - ひげろぐ
昨年お世話になっていた職場の仕事仲間と先月ランチする機会があった。 自分の関わっていたプロジェクトはペアプロやTDDを実践していたのだが、残念なことに自分が抜けた後はテストコードを書かなくなってしまったという。 理由を聞くと「テストコードを書くより、動くプロダクトコードをどんどん書きたい」ということだった。 これは心情的にはよくわかる。 納期のプレッシャーが強く、TDDに慣れていない状況では特にそうだ。 要は「テストを書いてる暇なんかない」と判断してしまうわけだ。 TDDの最初の躓きのひとつとして、テストコードを書く手間が増えただけのように感じられるというものがあると思う。 実際に手間は増えている。 しかし適切なテストの書き方がよくわからないため、余分な手間をかけすぎているということもあるだろう。 例えばゲッターやセッターのテストを逐一書いてしまう。 これは実際に無駄なことであるから、この
RailsアプリでActiveRecordを使ったバッチ処理 - ひげろぐ
定期的にAPIからデータを取得するためのバッチ処理を作成している。 まずやりたいことはActiveRecordを使うこと。 あとデータベースの情報はdatabase.ymlから取得するようにする。いろんなところに分散してしまうのは気持ち悪いので。 それで出来たのが以下のようなコード。 require 'rubygems' require 'active_record' require 'yaml' ConfigFile = File.join(File.dirname(__FILE__), "..", "config", "database.yml") ds = YAML.load(File.read(ConfigFile)) ActiveRecord::Base.establish_connection(ds["development"]) これでActiveRecordを使うことができ
Rails3でTDD環境を整えたメモ - ひげろぐ
2011/07/07追記 実はこの記事の内容よりも以下のGuardを前提にした構築がおすすめ。 Rails3+RSpec2+Spork+Guard(guard-rspec,guard-cucumber)で最速のBDD(振舞駆動開発)環境を作る | Curiosity Drives Me Guard便利すぎです。 久々にRailsでできる仕事が来たので久々に環境構築。 記事の一番最後に挙げた参考の渡り歩きつつ設定した。 Rubyのバージョンは1.9.2。Railsは3.0.5。 プロジェクトの作成 $ rails new -T hoge RSpecを使うのでUnitTestはいらないということで。 Gemfile 必要なものをBundlerでさくっと入れる。 group :development, :test do gem 'spork', '~> 0.9.0.rc' gem 'rspec-
chef-soloで作業環境構築の自動化 - ひげろぐ
さくらのVPSを契約して放置しておいたままだったので、これを機に環境構築をしてみることにした。 なお現状はユーザーakahigeの追加とsshの設定だけ済ませた状態になっている。 すべての設定はChef経由で行うこと というルールでChefで同じ環境をいくらでも作れるものを目指してみよう。 Chefサーバーのセットアップはめんどくさいのでchef-soloでがんばる所存。 Rubyのインストール とはいえChefの動く環境はChef以外で作らないといけない。 このあたりを省略するならシェルスクリプトによる自動化か、Chefが動くところまでセットアップした仮想マシンのイメージを使うほかなさそうだ。 必要なパッケージのインストール $ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.r
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
Railsでruby-debugを試したら10分で使えた - ひげろぐ
前々から名前は知っていたけど、なんだか身構えてしまっていて試していなかったもの。 試してみたらすぐに簡単に使えて激しく便利でした。もっと早くやっておいたらよかった。 これでデバッグのときに変数の内容を表示するようなデバッグコードをがんばって埋める必要がなくなりました。 インストール gemでさっくりと。 gem install ruby-debug コードにブレークポイントを仕掛ける require 'ruby-debug' とライブラリを読み込んで、ブレークポイントを仕掛けたい場所に debugger と書くだけ。 def hoge i = 1 debugger end みたいなかんじ。 動かす WEBrickを動かしてアプリをいじっているとブレークポイントを設定した箇所で実行が停止する。 WEBrickを実行したコンソールにプロンプトが出るのでそこでコマンドを打つと現在の変数の状況など
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
