2010-01-26

デジタルハリネズミ



一言で片付けてしまえばデジタルトイカメラなのですが、取れる画像がなんかレトロ感があるいい感じのものが取れるようなのでキニナルのです。
性能ははっきりいって低いのですがいい味のために必要なスペックな感じでキニナルのです。

詳細は以下を見てください。
http://www.superheadz.com/digi2/index.php
時刻: 0 件のコメント:

Rails2.3でActiveRecordのセッションを削除する


を今、読んでいるのですがそこでActiveRecordでsessionを管理している際のsession削除の方法として
CGI::Session::ActiveRecordStore::Session.delete_all(["sessions.updated_at < ?",3.days.ago])
を実行すると紹介していたのですが、Rails2.3では
CGI::Session::ActiveRecordStore
が
ActiveRecord::SessionStore
に変更されたようです。
なので
ActiveRecord::SessionStore::Session.delete_all(["sessions.updated_at < ?",3.days.ago])
とする必要があるようです。
時刻: 0 件のコメント:

2010-01-22

rcovの結果をブラウザで確認する

rcovはrubyのテストのカバー率を集計してくれるツールです。

railsを使うなら、テストをちゃんとやってこそ意味があると思っているのですが、
なかなかテストを書くモチベーションは上がりにくいものです。

しかしなんらかの指標があれば、テストを書くモチベーションも上がります。
rcovはそんな指標を提供してくれるわけです。

インストール方法や使い方は、簡単に調べられるわけなのでとくに書きません。

rcovを実行するとrailsの場合、
RAILS_ROOT/coverage
に結果をいい感じのhtmlで結果レポートを作成してくれます。

windowsで開発しているならばディレクトリ内のindex.htmlをブラウザで見ればよいわけですが、linux環境に対してsshでログインして開発しているとそういうわけにもいきません。

そこで最初は
publicにcoverageディレクトリをコピーして
./script/server
としてブラウザから
http://x.x.x.x:3000/coverage
で確認したところ、私の環境ではなぜかcssなどがうまく読み込まれず、がっかりな表示なりました。

それを解決してくれたのが、以下のページです。
http://d.hatena.ne.jp/babie/20071101/1193908806

script/rcov-server
という以下のようなスクリプトを用意します。
#!/usr/bin/env ruby
require "webrick"

__DIR__ = File.dirname(__FILE__)
s = WEBrick::HTTPServer.new(:Port => 8000, :DocumentRoot => "#{__DIR__}/../coverage")
trap('INT'){ s.shutdown }
s.start

rcovの結果を確認したいときは、
script/rcov-server
を実行して
ブラウザから
http://x.x.x.x:8000/coverage
を確認するとステキな結果が確認できるというわけです。
時刻: 0 件のコメント:

2010-01-19

rspecにファイルアップロードのテストを書く

Railsさんアプリでファイルアップロードのテストの書き方です。

以下のようなアップロードしたファイルを/tmpの下に保存するコントローラーがあるとします。
class TestController < ApplicationController
  def index
  end

  def upload
    file=params[:file]['csv']
    @filename = params[:file]['csv'].original_filename
    File.open("/tmp/#{@filename}","wb"){ |f| f.write(file.read) }
  end
end
このコントローラー用のviewを以下のような感じで用意します。 
<% form_tag({:action => 'upload'},{:class=>'form',:multipart=>true}) do %>
<%= file_field "file","csv" %>
<%= submit_tag("upload") %>
<% end %>
specファイルは以下のような感じになります。 
describe TestController do
  describe "fileをポストする" do
    before(:each) do
      @file = fixture_file_upload "test.csv", "text/comma-separated-values"
      post 'upload',:file => {"csv"=>@file}
    end
    after(:each) do
      File.delete("/tmp/test.csv")
    end
    it "/tmpにファイルが保存される" do
      FileTest.exist?("/tmp/test.csv").should be_true
    end
  end
end
ファイルアップロードのテストにはfixture_file_uploadを使うようです。
fixture_file_uploadで指定するファイルは
spec/fixtures/
にあると見なされるようです。
viewで
file_field "file","csv"
とした部分は
post 'upload',:file => {"csv"=>@file}
と指定すればよいようです。
時刻: 0 件のコメント:

2010-01-13

RailsでRead OnlyなModelをいっぱい作る

RailsでRead OnlyなModelを使うには
acts_as_readonlyable
というプラグインを使うという方法があるようですが、2.3.4では動かない気配です。
こちらを改造して使うには、
http://hisme.net/~masaki/blog/article/show/41
が参考になります。

プラグインを使わない方法として
http://lunatear.net/archives/001089.html
という方法もあります。

2.3.4を使っていてプラグインに手を入れるのがちょっと面倒でさらにいっぱいRead OnlyなModelを使いたいと思ったのでプラグインを使わない方法を参考にさせていただき以下のような感じでやってみました。

app/models/read_only.rb
を以下のような感じで作ります。
class ReadOnly < ActiveRecord::Base
  abstract_class = true

  def readonly?
    true
  end

  def before_destroy
    raise ActiveRecord::ReadOnlyRecord
  end

  def self.delete(id)
    raise ActiveRecord::ReadOnlyRecord
  end

  def self.delete_all(conditions)
    raise ActiveRecord::ReadOnlyRecord
  end

  def self.destroy_all(conditions)
    raise ActiveRecord::ReadOnlyRecord
  end

end
そしてRead Onlyにしたいモデルを以下のように書きます。 
class Test < ReadOnly
end

ReadOnlyクラスに
abstract_class = true
をつけるのがポイントでした。
時刻: 0 件のコメント:

2010-01-03

DjangoとRailsの個人的感想

最近、DjangoとRailsをそれぞれ軽く触っています。

完全に個人的な意見で参考にならないとは思いますが
両方使った上での個人的な感想は
本当ならばDjangoだけを利用したいけど仕事で使うならばRailsかなぁ
といった感じです。

個人的にはDjangoの方がしっくりくるものがあります。

Djnagoのいいと思っているところをあげてみると
・言語的にPythonの方がRubyの方が好き
　完全に個人的な趣味です
　どちらも優れた言語だと思っているのですが、
　誰が書いても似たようなコードになるような言語仕様であるPython
　多様性は善ということで同じコトをいろいろ表現できるRuby
　とそれぞれのポリシーのうちPythonのポリシーの方が個人的に好きという感じです。
・フレームワークとしてすっきりまとまっている気がする
　RailsはActiveRecordなどちょっと書くだけでいろいろ動いちゃうのがちょっとなじめないので
　書かなければならない量がDjangoの方が個人的感覚にはあっている感じです。
・Google App Engineで使える
　Railsも使えるみたいですが、Ruby on Rails on JAVAで動くということなので
　ちょっとonし過ぎな印象を持っています。

Railsのいいと思うところは
・Migration
　個人的には、Migration仕組みはとてもステキだと思っています。
　DjangoにもsouthというMigrationのような機能をもつツールもあるようですが、
　Migrationよりかはちょっと面倒な印象です。（使っていないで言っています。）
　southについては
　http://nakagami.blog.so-net.ne.jp/2009-12-10
　が参考になります。
・テスト関連がすっきりしている気がする
　modelやcontrollerを書いたらテストをどこにテストを書くのかとかがDjangoに比べて明確な印象です。
　テストをしっかりやりなさい！という意思が感じられるのがステキな気がします。
　またrspecの存在もステキな気がします。
　pythonにもpyspecというのもあるのですが、rspecに一日の長がある感じがします。
　pyspecについては
　http://pyspec.codeplex.com/wikipage?title=Home_jp&referringTitle=Home
　が参考になります。
・情報量が多い
　DjangoよりもRailsの方が情報が多いです。Railsの方が調べた時の見つけやすさ気がします。

ということで
個人的にはGoogle App Engineを使いたいのでDjangoが本当はいいのだけど
Migrationによるスキーマ管理からテストまでの開発の全体を通した開発のしやすさと情報の多さから仕事ではRails使った方がいいかなぁと思ったわけです。

逆にMigration相当の便利なツールがあれば
仕事でもDjangoを使ってもよいのかなぁとか思ったりしています。

完全に個人的な感想でした。

ちなみに

はDjangoのことを知る上ではすごく参考になりました。
ネットでちょっとDjangoのことを調べてから読むと全体像がすごく分かりやすく把握できました。
そしてそんな機能もあったのねと関心もしてみました。

　
時刻: 0 件のコメント: