吹いたw　こういうの好きだなぁ。

ドラクエ３ライブ第２弾(1of3)

2, 3と、第1弾らしきものもあるよ。

リンクだけなのもなんなのでflash貼ってみる。

「ギターで弾いてみた」系はドラクエだけでも結構あって、 見てて飽きない……そしてこんな時間……。寝る。

MySQL……というかデータベースをいまいち使えてないんで 最近やっと外部キー制約を使ったオレなんだけど、 わかっておかないとあとでまたはまりそうなのでメモ。 言い回しがおかしいかも。

laboratoriesテーブルとstudentsがあったとして、 studentsが外部キーとしてlaboratoriesの属性に依存している場合、 まず次のようなことになる。

1. studentsテーブルにデータをinsertするには、外部キーで参照するlaboratoriesのデータが存在しないといけない
2. laboratoriesのデータをdeleteするには、それを参照しているstudentsがあってはいけない

なので、ActiveRecordを使ったテストでfixtureを使うときには、

class FooTest < Test::Unit::TestCase
  fixtures :laboratories, :students
  ...

と書いて、データベースにlaboratories, studentsの順で追加しないといけない。 これは1による制約。

次にBarTestというテストを書くとして、そこではlaboratoriesのfixtureしか使わないとすると

class BarTest < Test::Unit::TestCase
  fixtures :laboratories
  ...

と書きそうなものだけれど、これは場合によってはfixtureのセットアップの段階でエラーになる。 というのも、fixtureをデータベースに追加する前に、BarTest.fixturesに渡された テーブルのデータを削除する、つまり

DELETE FROM laboratories;

が行われているからで、この時もしデータベースのstudentsテーブルにデータが残っていた場合に 2の制約によりこのクエリが失敗するから。 例えばこの前でFooTestを実行していたりすると、 データベースにはstudentsのfixtureのデータが残っているのでそういうことになるぽい。

なのでstudentsのfixtureを使わないBarTestにおいても

class BarTest < Test::Unit::TestCase
  fixtures :laboratories, :students
  ...

と書く。すると

DELETE FROM students;
DELETE FROM laboratories;

となって、正常にdeleteできる。

うーん、めんどくさい。

しかしデータベースの件にしろその他技術的な件にしろ、経験値が少な過ぎて凹む。

はてブするときにおすすめタグから選ぶことって意外と多いんだけど、 その中に例えば「ユーザビリティ」と「usability」が両方あったりして 一体自分は英語とカタカナどっちのタグを使っていたかなと迷う場面がよくある。

他には、おすすめタグの中から「programing」みたいな誤植タグをつけそうになったり、 「web2.0」と「web 2.0」どっちだ！　みたいなこともあるかも。 というか最近web 2.0なんて言葉自体を見ないけども。 他には似たような意味のタグについて「どっちかな」ってのもありそう。

今まで「英語でかっこつけるんじゃなかった……カタカナで統一していれば……」とか思ったりもしたんだけど、 以前作ったおすすめタグの大文字小文字を自分のタグと合わせるgreasemonkeyを ちょっと変えて、自分が今まで使ったタグと同じやつを点々で囲むようにしたらすぐ悩みも消えた。

わーい。

おすそわけ（　´∀｀）つfixrecommendedtags.user.js

この1週間、熱のこもったRuby会議のレポをいくつか目にしたので、 ここは内容のことよりもオレの個人的なレポをこっそり書いておこう。

• 初日の朝に大雨に降られてずぶ濡れのまま東京入り。半日ずっと下半身が冷え込んでいた
• 感動するには英語がわからなすぎたので、涙までは出なかった。隣に座ってた人がすごくわかってそうだった。くやしいっ！　くやしすぎる！
• 2日間体力がもたなかった。少し寝ちゃいました。つまみ出されなくてよかった……
• Ruby会議関連の出費がその後の生活を圧迫中

ネガティブw　大きな声じゃ言えないぜ。

まあ行ってよかったのは間違いなくて、 いろんなところで働くRubyが見れたのがとても刺激になったな、と。 Railsだけじゃ狭いな、と。 みんなすげーな、と。 あと、世界は一人だけでは広がっていかないな、と。

これからどうなっていくかなRuby。あとオレ。

よく使うタグなのに数百のタグの中から選ぶのは世の中間違ってる。 タグのオートコンプリートもいいけど、日本語のタグだとめんどくさかったりして。

（去年とってるはずの）授業の準備に時間がかかってムシャクシャしてたのもあって、 こんな時間だけどショートカットタグを表示するグリモン作ってみた。 さっきうまく動くようになったばかりでバグがありそうだけど、 エントリ書かないと寝ちゃいけないような気がするので急いで書く。

眠い…（；＾ω＾）つshortcuttags.user.js

「edit」をクリック。

最近ではpromptは逆に新しい。

こうなる。このタグはブラウザに保存されて、次回以降も表示される。

これで容赦なく「これはひどい」タグをつけられるようになった。

基礎からのデータベース設計 第2版

posted with amazlet on 07.06.19

高橋 栄司 飯室 美紀
ソフトバンク クリエイティブ (2007/03/21)
売り上げランキング: 267821

おすすめ度の平均:

実務面とわかりやすさのバランスに優れるデータベースの入門書

Amazon.co.jp で詳細を見る

生協に積まれてたので買ってぱらぱらと読んだ。

データベースの設計は今まで勘でやってたので入門してみたわけだけど、 うーん、データベース触り始めたころに読みたかったかなぁ。

さて、生活費の前借りもできたしw、なんとか生活できそうだ（ノ∀｀）

Railsのテスト振る舞いwをRSpecで書き始めたんだけど、 複数のdescribeで共通してる部分(fixturesとかbeforeとか)をDRYにしたかったので、 RSpecにおけるコンテキストをまたぐ共通部分を 激しく参考にさせてもらって、こうしてみた。

spec/spec_helper.rbに以下のように書く。

def common_description(klass, name = nil, &blk)
  name ||= klass.to_s.underscore
  Kernel.class_eval do
    define_method "_describe_#{name}" do |comment, prok|
      describe klass, comment do
        instance_eval &blk
        instance_eval &prok
      end
    end

    eval <<-DEF
      def describe_#{name}(comment, &blk)
        _describe_#{name}(comment, blk)
      end
    DEF
  end
end

で、*_spec.rbではこんな感じ。

require File.dirname(__FILE__) + '/../spec_helper'

common_description FooController do
  fixtures ...

  before do
    ...
  end
  ...
end

describe_foo_controller '#edit' do
  it ...
    ...
  end
end

describe_foo_controller '#create' do
  ...
end

common_descriptionのところでFooControllerクラスの各describeの共通部分を書く。 するとdescribe_foo_controllerが定義されるのでdescribeの代わりにそれを使う。

describe_foo_controller以外の名前を付けたいとか、別に作りたいときには

common_description FooController, 'foo_controller2' do
  ...
end

とすればdescribe_foo_controller2という名前になる。

参考もとのコードからinstance_evalが消せて少しDRYな気分。でもメソッド名がダメな気がする。 あとブロック引数にブロックをとれるときれいになるのになぁ。

何よりみんなはどうやってるんだか気になる。

見落としてた。

RSpec on RailsでfixturesをDRYに指定する方法がspec/spec_helper.rbに書いてあった。

  # Alternatively, if you prefer to declare them only once, you can
  # do so here, like so ...
  #
  #   config.global_fixtures = :table_a, :table_b
  #
  # If you declare global fixtures, be aware that they will be declared
  # for all of your examples, even those that don't use them.

まーでもこれはやりすぎかも……。遅くなりそう。

借りて読んだ。プログラマが取り残されないようにするにはどうするか、みたいな話。意外と面白かった。 オフショアの話を抜きにしてもいろいろと示唆に富む。

これは働き始めて何年かしてからまた読むと良さそうだな。今学生だしな。

My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド

posted with amazlet on 07.06.27

Chad Fowler でびあんぐる
オーム社 (2006/09/26)
売り上げランキング: 36271

おすすめ度の平均:

実は技術者心得帳
プログラマ必読

Amazon.co.jp で詳細を見る