Railsでアプリを作る その6 振舞を再現する
UserテーブルのRSpecを少し書きました。
その記述した振舞を再現するようにmodelを書きます。
スペックではlengthについて書いていたので
モデルに以下の文章を追加！
validates_length_of :name, :maximum => 40 validates_length_of :mail_address, :maximum => 80 validates_length_of :skype_id, :maximum => 40
そうして動かすと・・・
ruby script/spec -cfs spec/models/user_spec.rb
こんな感じ！
User バリデーション - save success! - name length=40 save success - name length=41 save error - mail_address length=80 save success - mail_address length=81 save error - skype_id length=40 save success - skype_id length=41 save error Finished in 0.10329 seconds 7 examples, 0 failures
高専カンファレンスin長野に行ってきました。
2009-12-19 長野高専 5階なのに100番教室
カッコいい雰囲気、カッコいい機材、寒い中各地から集まったカッコいい高専生に囲まれ始まった
kosenconf-011nagano
地方開催ということで現役高専生が中心となって開催された
このカンファレンスは大成功と言っていいと思う
== はじめに ==
今回の高専カンファレンスは多くの人の協力があって成立したと思う
みんなにThank you!感謝！！
発表などのまとめはid:beat_beat さんがまとめてくれてるのでこちらを参照！
http://d.hatena.ne.jp/beat_beat/20091219/1261230270
公式Wiki
高専カンファレンス in 長野 - 高専カンファレンス Wiki
== 所感 ==
+ 校長先生のLT
スライドを作った先生は違う先生と言うが
すごく理解のある先生なんであろう
てっきり少し固めの話をするのかなと思いきや
ノリノリ・・・
素敵だ
長野高専素敵
+ 基調講演
英語ができる、できないは関係なしに絵やジェスチャーなど
苦労しながらも外国チームと交流をしている
話してもいいんじゃないかな？
面白かった！
+ 一般発表
専門的な話題と留年関連の話題
専門分野の人がやっているかどうかは分からないが
あのレベルの話を聞けるのはやはりカンファレンスの魅力
金融っていうのは意識をしないと学ばないものだと思うのですごくいい経験をした
そして本日より参加者にMacフラグが…
+ LT
レベルたけーｗ
ドラ娘さんかわいー
現役高専生の発表が多かったのがいいね！
もっと現役高専生の発表が聞きたい！聞きたい！
ドラがあんまりならなかったのが残念です。
５分で終わってしまう（＝＞故にドラが鳴る）
のは
ドラがなる前に終わらせるのではなく
ドラがなったら終わるようにするのがいいと思う！
だって、カンファレンス参加者みんなドラ娘さんのこと好きだもの。
どらぁ〜
さて、自分も発表者のひとりですがそちらの話は別の記事にて！
しゃべりで持っていける人はすごいな
あとはスライドを工夫している人もいたので
いろいろ盗んでいこうと思う！
+ 懇親会
もうすこしまとまりが欲しかった！
== おわりに ==
長野は本当に楽しかった！
みんなありがとう！
この出会いと経験を大事にしていきましょう！
そして次は１月３０日 八戸
いこうぜ！！
東京ー八戸はだいたい3時間くらいの往復３０ｋ円
以上 TwitterID mitakuがお送りしました。
LTを終えて
2009-12-19 長野
こんばんはtwitter-id mitaku です！
高専寒波れんす・・・
もとい
高専カンファレンス 長野でLTをさせていただきました。
公式
http://kosenconf.jp/011nagano
ustのムービー
http://www.ustream.tv/recorded/3244424
今回は
「Lightning Talksで○○を彩る」
というタイトルで発表！
○○には"左下"という文字が入ります
どういうことかと言うと
プレゼンテーションで同時に別のベクトルを持たせるとどうなるんだろう？
という疑問から
並列世界での発表というのは見たことがないので
スライドの左下を使って
実験をかねてやってみました。
その並列世界、別のベクトルを持たせるというのは
主題を高橋メソッドで行います
（スライド１つに対して大きな文字でシンプルに記述する）
あとはしゃべりや枚数、勢いでなんとかする（←持論）
これの良いところは
大きな文字を使うことで
遠くの席からでもスライドが”見える”点
1枚の情報量が少ないという点
それゆえにスライドを作りやすいので
固い場所でなければすごくよい手法だと思います。
今回はそのメリットの情報量が少ないというのを少し削って
左下で主題と別の話をしようかなと思いました。
具体的に何をするか…
1.スライドの補足
2.スライドの雑学的ななにか
3.ネタ
4.意味のない文字列
5.カンペ
6.伏線を張る
などなど、
工夫しだいでなんでもできそうです。
デメリットとして
左下に力を入れすぎると
主題が頭に入らない、おろそかになるという点です。
今回は実験的に左下をメインで行ったため
主題のほうはあまり印象に残ってないかと思う。
（ネタバレ：そもそも主題は中身のない話）
8割くらい左下でネタに走っていたので
会場では結構ウケていました。
結局のところ今回のLTでやったのは
終始ネタに走っていただけ
主題と合わせたり、休憩に使ったり、いろいろ試して見ましたが
だいたい相手にウケるネタならウケるという状態
高専生ならツボはある程度あるわけで
そのへんを面白おかしく言えばなんとかなるんじゃないかなと
結局今回やった手法・・・
西光メソッドと名前がつきましたが
現状だと
中身のない内容の発表を切り抜ける手法にしかなっていなくて
使いどころや方法をいろいろと考える必要があります。
また、今回はもう一つ狙っていたことがあって
「発表は終わるまで相手を掴んでいなきゃいけない」と思い
最初からあれこれやってみました。
その点でも左下はある意味有効で
短い発表よりは
長い発表でやる方が効果的なのかなとも思います。
ただ、静的なモノなので
やはり高橋メソッドのように多くのスライドと勢いでやるのがいいのかもしれませんね…
うーん、難しい！
終わった後に話を聞いてみると
「面白かった」と言っていただけたので
もう本当に幸せです。
[あとでやる]と言ってくれた人も多かったので
今後の発展が楽しみ！
ただ、人が処理できる情報量もそんなに多くないので
複数のベクトルを持たせるなら
録画などあとで参照できるのを
前提にやると幸せになれるかも！
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@igaiga555 さんよりコメント:
タカハシで真面目な話して、
でニシミツで話せない裏話をしたりとか、
使い道広そう！
@xenosanx さんよりコメント:
すごく面白かったです！
ただ左下が面白すぎて
本題に目がいかなくなってしまうので
見るのが大変でした＾＾；
@FromAtom さんよりネタ提供:
メインと左下で、漫才の様に
掛け合いをしてみたらどうでしょう？
それなら、並列進行じゃないので、
どちらも見られますしw
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
なんにせよ見てる側は両方見ようとしちゃうので
やりすぎは良くないですね
可能性は無限大！
そんなわけで個人的にLTは大成功でした。
ドラも鳴らせたし。
ドラ娘さんかわいいし←
みなさん本当にありがとうございました！
さいごに
全国の西光さんごめんなさい！←
Railsでアプリを作る その5 振舞を書く
当初とは結構構想が変わってしまいましたが、こんな感じで作ろうかなと思っています。
今日はRSpecを書いてみる
とりあえずuserモデルに書いてみよう
バリデーションなどを考えつつ・・・
describe User do
describe "バリデーション" do
before(:each) do
@user = User.new
@user.name = "test"
@user.mail_address = "test@test.com"
@user.password = "password"
@user.skype_id = "test_id"
end
it "save success!" do
@user.save.should be_true
end
it "name length=40 save success" do
@user.name = "123456789012345678901234567890123456789"
@user.save.should be_true
end
it "name length=41 save error" do
@user.name = "12345678901234567890123456789012345678901"
@user.save.should be_false
end
it "mail_address length=80 save success" do
@user.mail_address = "12345678901234567890123456789012345678901234567890123456789012345678901234567890"
@user.save.should be_true
end
it "mail_address length=81 save error" do
@user.mail_address = "123456789012345678901234567890123456789012345678901234567890123456789012345678901"
@user.save.should be_false
end
it "skype_id length=40 save success" do
@user.skype_id = "1234567890123456789012345678901234567890"
@user.save.should be_true
end
it "skype_id length=41 save error" do
@user.skype_id = "12345678901234567890123456789012345678901"
@user.save.should be_false
end
end
end
とりあえずこんな感じになった。
ruby script/spec -cfs spec/models/user_spec.rb
実行すると…
User バリデーション - save success! - name length=40 save success - name length=41 save error (FAILED - 1) - mail_address length=80 save success - mail_address length=81 save error (FAILED - 2) - skype_id length=40 save success - skype_id length=41 save error (FAILED - 3) 1) 'User バリデーション name length=41 save error' FAILED expected false, got true ./spec/models/user_spec.rb:25: script/spec:10: 2) 'User バリデーション mail_address length=81 save error' FAILED expected false, got true ./spec/models/user_spec.rb:35: script/spec:10: 3) 'User バリデーション skype_id length=41 save error' FAILED expected false, got true ./spec/models/user_spec.rb:45: script/spec:10: Finished in 0.108239 seconds 7 examples, 3 failures
ということで
この場合はこういう結果が返ってくるというのが
振舞
これが全て成功すればOK
そうすると、デグレしてないか分かるもんね！
Railsでアプリを作る その４ DB設計
最低限のDB構成
- Users
- id
- name string(varchar)
- password string(varchar)
- mail_address string(varchar)
- is_admin boolean [false]
- skype_id string(varchar)
- Orders
- date Date [ Date.today ]
- bigsize boolean [ false ]
- user_id int
[ ]内はデフォルト値
NULLは許容しない。
この設定で先日作ったmigrateファイルを編集する。
Users
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.column :name, :string, :null => :false
t.column :password, :string, :null => :false
t.column :mail_address, :string, :null => :false
t.column :is_admin, :boolean, :default => false
t.column :skype_id, :string
t.timestamps
end
end
def self.down
drop_table :users
end
end
Orders
class CreateOrders < ActiveRecord::Migration
def self.up
create_table :orders do |t|
t.column :date, :Date, :null => false
t.column :bigsize, :boolean, :null => false, :default => false
t.column :user_id, :integer, :null => false
t.timestamps
end
end
def self.down
drop_table :orders
end
end
Railsでアプリを作る その2 RSpec導入
BBD
開発手法の一種
BDD(Behaviour Driven Development)
ポリシーとして
「ベヒイビア(振る舞い）を書いて仕様を設計する。」
BDDでは必ず仕様(spec)コードを書いてから実際のコーディングを行う。
これによって仕様に沿って作られているかがわかる。
ただし、このスペックコードが間違っている場合は救いようがない。
これに関してはペアプログラミングなどで注意して行う必要がある。
RSpec
RubyのBBD用ツール
詳しくはhttp://jp.rubyist.net/magazine/?0021-Rspec:こちら
パッケージが用意されているので導入が簡単である。
RSpecの導入
gem install rspec gem install rspec-rails
プロジェクトへ追加
プロジェクトのルートディレクトリへ移動
(今回はorderという名前)
コマンド
cd order ruby script/generate rspec
実行結果
ruby script/generate rspec
exists lib/tasks
create lib/tasks/rspec.rake
create script/autospec
create script/spec
create spec
create spec/rcov.opts
create spec/spec.opts
create spec/spec_helper.rb導入終わり！
この時点でバージョンはどちらも1.2.9でした。
Windowsだと話はまた変わってくるかもしれませんね。
つづく
