● 初笑い

なっち姉さんなぜ…

● 01.白いTOKYO/全員

いきなり名曲キタ。反則。舞美、キャプ、のオリメンですやん。キッズ優遇な紺を印象付けさせる選曲。

● 02.Mr.Moonlight〜愛のビッグバンド〜 /全員(れいな猫耳)

出だしの高音ソロは愛理。愛理は声量ないけど上手いから(*1)、こういう部分がピッタリだね。れいにゃの猫耳はキャワ。吉澤のシャウトもよい。

(*1) 特に高音の澄んだ声がいい

● 03.桜チラリ/℃-ute

新曲キタ。ギャグ100の桃子を彷彿とさせるようなのっけから続く愛理ソロ。後列マニアとしてはメンバー全員への均等なパート割が好みなのだが、完全に愛理1トップになってる℃-uteの現状の縮図とも言える。人気2位の舞美は歌唱力的に若干不安が残るし。もし、キルヒアイスが生きていたなら。誰もがそう思わずにはいられない。でも、僕は過去や仮定に固執することなく、この1トップの現実を受け入れようとしている。てゆか、よく考えたら僕、愛理ヲタだし。

● 04.タイムカプセル/℃-ute

いい曲だし好きなんですが、手持ちの枠数が限られている以上、ここはまっさらを期待したかった。(児玉清)

● 05.雪/愛×あなた≧好き/高橋愛 With MC GAKI

● 06.バラライカ/月島きらり starring 久住小春（モーニング娘。） （エッグ）

そろそろ秋田＞コサック

● 07.やる気！IT'S EASY/田中

ちなこ、れいな、熊井さんの並びが綺麗だった。ユニット組んで下さい。是非。

れいなwithでっかいW

　　　　☆从从从　　　　　　 ノノハヽ☆
　　　　 从´∇｀从 ノノハヽo (＾∇＾*川
　　　　　（　⊃¶つ从 ´ ヮ｀)⊂、_¶と .）
　　　　　 |　|　|　　（つ¶と）　 　|　|　|
　　　　　 (＿)_)　　 (＿)_)　　　(__(＿)

● 08.晴れ 雨 のち スキ/辻・岡田・夏焼・須藤・菅谷・矢島・三好

● 09.かっちょええ/嗣永・清水・鈴木・岡井・中島・萩原

まさかのかっちょええ！この曲はスイッチョンの印象が強くて舞波を想い出しちゃうけど、愛理とnkskちゃんのかっちょええが見れて幸せです。キャプテンの「いきますよ」＋「煽り」入りバージョンだったのもグッド。

● 10.香水 /石川・新垣・道重・亀井

亀井さんは今回かなり可愛いかった気がします。

● 11.大きな愛でもてなして /Berryz工房、℃-ute

キッズ全員で大もてとか。おーいえーおーいえー。感激です。

● 12.友情 純情 oh 青春/Berryz工房、℃-ute

ベリのソロ紺並の盛り上がり。おいおい言ってタオルを投げて大満足。ベリヲタならこれだけで元が取れる。

● 13.I KNOW/全員

あややのカップリング曲らしい。

● 14.寒いから冬だもん！〜どうもこうもないっすよミキティー〜/藤本・萩原・岡井

「次の曲は℃-uteの萩原舞、岡井千聖・・・」この瞬間、キューティーガールズを100%確信してた自分が可愛い。

● 15.コタツの歌〜jyuken story〜/吉澤・亀井・新垣

● 16.胸さわぎスカーレット/Berryz工房

この曲のよさは理解できない。まったく耳障りだ。コンサートでも何をすればよいかわらないこの曲は騒音でしかない。しかし、この曲の最後の雅ちゃんの裏声の部分は泣ける。

● 17.ファイティングポーズはダテじゃない/Berryz工房

このファイポに納得しているベリヲタは一人もいない。ここはなん恋が正解。マジで。せめて、スッペかジリリ。

● 18.スッピンと涙/辻希美、℃-ute

● 19.愛すクリ〜ムとMyプリン/美勇伝

正直、どうしていいかわからなかった。でも、それで正解のようだ。

一人で行くワンダコンスレ ４回目

503 ：名無し募集中。。。：2007/01/03(水) 01:34:06.42 O
    肩身の狭い美誘電ヲタだけど
    アイスは未だに乗り方が分からないわサビでフウフウって入れるしかできない
    ヒッパレとか唇とか乗れる曲あるんだが

● 20.まごころの道/美勇伝

一人で行くワンダコンスレ ４回目

688 ：名無し募集中。。。 ：2007/01/03(水) 02:42:36.86 0
    バニーでバラードとか悲しすぎて泣けたよな

696 ：名無し募集中。。。 ：2007/01/03(水) 02:45:09.90 0
    >>688
    あれは不覚にも吹いてしまった
    たそがれて座るような衣装じゃないだろｗ

● 21.Ambitious！野心的でいいじゃん/モーニング娘。

野心はいいね。知ってる曲に出会えてほっとする。

● 22.Do it! Now/モーニング娘。

ちょっと古めの曲なら知ってる。

● 23.踊れ！モーニングカレー/モーニング娘。

カレーが食べたくなった。

● 24.愛の園〜Touch My Heart!〜/モーニング娘。以外

名曲キター。でも、れいにゃがいないのは去年の本体スッペ並に悔しい。他コンでやるのはいいけど、本人が会場にいるときは本人にやってもらいたいよ派。

● 25.Say yeah!〜もっとミラクルナイト〜/全員(セリフ：重ピンクと、こはっピンク)

名曲キター。かもなふぁいやー！これも盛り上がるやね。「夢を夢としないで」とかやっぱ良歌詞すぎるよ。この頃の寺田さん戻ってきて。

● 26.歩いてる/全員

これがラストなのは納得。24時間テレビの最後もサライでなくて来年からはこれでいいよ。

● まとめ

スッペもなん恋もまっさらもわっきゃないもないから、絶対アンコール要員だろうと思ってたのだが、会場に電気がついていきなり終わって焦った。合同コンってアンコールないんだっけ？あと、全体DDは少数だし、非推しグループはお互い辛いので、もう少しだけ細分化して欲しい。特に今回はキッズ偏重気味だったので、キッズヲタは大満足だが、本体ヲタは出番が削られた感が大で消化不良だったと思う。そこでワンダ紺スレでは3分割が提案されていた。

うん、これがベストだね。各ヲタもみんな納得していたので、夏の合同コンからはこれでお願いします。でも悲しいかな、どこのグループも美勇伝の受け入れを拒否してたのには苦笑。

● 参考

• [2ch] 一人で行くワンダコンスレ ４回目 http://ex11.2ch.net/test/read.cgi/morningcoffee/1167732233/

● [熊井ちゃん] 論考に足りないもの

熊井ちゃん、ヴィトたんが言うには

論考 １

世界は成立していることがらの総体である

なんだって。

• 「熊井ちゃんの身長は174cmである」
• 「りしゃこは13メートルしか泳げない」
• 「愛理のパパはプロゴルファーである」

といった現実世界の色んな「事実」を集めて、それらの事実の論理的な「像」を考えることが世界を「思考」することなんだって。でもね、「否定」は「事実」には含まれないって言うんだ。本当かなぁ？その理由は「否定の絵」を描けないことからもわかるんだって。例えば、「テーブルの上に熊が居ない」という絵を頑張って描こうとしても

となってしまって、結局、「否定形の像」は描くことができない。だから、「否定」は「事実」ではありえないでしょ、だってさ。確かに、カントもゲーデルも歴史上のどんな天才だって描けないかもしれないけど、世界で一人だけそんな絵をかける人物を僕達は知ってるよね。

富永一郎先生

　　　,ｒｎ　　　┌──────────┐　　　
　　r「l l h　　 │お笑いマンガ道場　　 　│　　　
　　|　、. !j　　 └──────────┘　　　
　　ゝ　.f　　　　　　　　　＿
　　|　　|　　　　　　 ,r'⌒　 ⌒ヽ、　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 ,」　　L_　　　　　f ,,r'￣￣ヾ.　ヽ.　│　
　ヾー‐'　|　　　　　ゞ‐=H:=‐fー)r、）　 |　 ２コマでっ！！
　 |　　　じ、　　　　 ゛iー'・・ー'　i.トソ 　 |　
　 ＼　　　 ＼. 　 　 l、 r==i　,;　|'　　.人＿＿＿＿＿＿＿＿＿＿＿＿
　　　＼　　　ノリ^ー-＞==__,..-‐ヘ＿＿＿
　　　　 ＼　　┌───────┐　　/＼
　　　　　　＼ │　∞∞┌┐── │　/　　|.　　
　　　　　　　　│　ΘΘ││　　 〆χ 　　 |　　
　　　　　　　　│　ξ〆┴┴─ ∈　彳 　/　
　─────┴────── τソ＿/

鈴木義司！！

　|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　|.　　　 〉/ _　　　　　　　　　　　＿_　 　　　　　　　　　　　　　　　　　 　 　 　　　　　 　 .|
　|.　　　-乙　ヽ( ・)○)⌒v⌒)　 |　 |＿＿＿＿＿＿＿＿＿＿＿＿＿|￣|.　　　　　 　　|
　|.　 ヽ<　2　 　　/ 　 　 |　 〈　..|　 |　　　　　　　　　　　　　　　　 　 　|　 |　 　 ( i^.　　　|
　|.　 ーi　彳_　 / 　　ヽ　`　 |　 |　 |　　　　　　　　　　　　　　　　 　 　|　 |　　　 〉〉　）　.|
　|.　　/]　　 廴,　 　　　ー'　 |＿|　 |　　　　　　　　　　　　　　　　 　 　|　 |＿＿//　/　 .|
　|.　〜┤　　　 <＿'k　ー- '　　 |　 |　　　　　　　　　　　　　　　　 　 　|　 |＿＿/　〈　　 |
　|.　　　 >-　　　　,y ―――― |　 |　　　　　　　　　　　　　　　　 　 　|　 |　　　　　 ）　 .|
　|.　　　　「`-!　T〈 `　　 　 　 　.|　 |　　　　　　　　　　　　　　　　 　 　|　 |￣　^ー　　　.|
　|.　　　　　　　　　　　　　　　　 |＿|―――――――――――――|＿|　　　　　　　　|
　|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|

鈴木義司の否定！！

　|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　|.　　　　　　　　　　　　　　　　＿_　 　　　　　　　　　　　　　　　　　 　 　 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|　 |＿＿＿＿＿＿＿＿＿＿＿＿＿|￣| 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|　 |　　　　　　　　　　　　　　　　 　 　|　 | 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|　 |　　　　　　　　　　　　　　　　 　 　|　 | 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|　 |　　　　　　　　　　　　　　　　 　 　|　 | 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|　 |　　　　　　　　　　　　　　　　 　 　|　 | 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|　 |　　　　　　　　　　　　　　　　 　 　|　 | 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|　 |　　　　　　　　　　　　　　　　 　 　|　 | 　　　　　　　　|
　|.　　　　　　　　　　　　　　　　|＿|―――――――――――――|＿| 　　　　　　　　|
　|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|

熊井ちゃん、２コマだよ。

● 参考

• ウィトゲンシュタイン『論理哲学論考』を読む http://www.amazon.co.jp/o/ASIN/4480089810
• [2ch] 富永一郎VS鈴木義司　〜仁義なき戦い〜 http://aa.2ch.net/aastory/kako/1045/10455/1045563008.html

● [熊井ちゃん][Rails] テーブル設計

熊井ちゃん、DQMJのモンスターの生息エリアってどう管理してる？

「モンスター」と「エリア」をエンティティ(リソース)と見做せば、関係テーブルが必要になるのはいいとして、これは運用上変更されない静的な関係だから、このテーブルにIDを導入する必要性は感じないよね。

てことで、テーブルはこんな感じになるんだけど、これって Rails でどう表現すればいいの？n:mなら habtm がピッタリだけど、生息エリアが1箇所のみ(n:1)とすると、 やっぱり habto が欲しいよね。実装はどうしよう？またあの地獄の ActiveRecord::Associations に頑張って追加するの？1.1 と 1.2 で結構違ってるし、そんな体力はないよ。

● habtm で代用

熊井ちゃん、大は小を兼ねるって言うから、そのまま habtm 使ってみる？

app/models/monster.rb

class Monster < ActiveRecord::Base
  has_and_belongs_to_many :areas
end

slime = Monster.find(1)
=> #<Monster:0xb7093c6c @attributes={"name"=>"スライム", "id"=>"1", "rank"=>"F"}

novice = Area.find(1)
=> #<Area:0xb70858d8 @attributes={"name"=>"ノビス島", "id"=>"1"}>

slime.areas = [novice]
=> [#<Area:0xb70858d8 @attributes={"name"=>"ノビス島", "id"=>"1"}>]

Monster.find(1).areas[0]
=> #<Area:0xb7079768 @attributes={"name"=>"ノビス島", "monster_id"=>"1", "id"=>"1", "area_id"=>"1"}>

うーん、動くんだけど、配列の表記が不細工だし、empty のケアも面倒だよね。

● has_and_belongs_to_one

じゃあ、habtm へのAPIを作ればいいんじゃない？habto て habtm の第一要素へのラッパでいいんじゃない？

confiv/environment.rb

ActiveRecord::Base.instance_eval do
  def has_and_belongs_to_one(name, options = {})
    habtm = name.to_s.pluralize
    has_and_belongs_to_many(habtm.intern, options)
    define_method(name){ send(habtm).first }
    define_method("#{name}="){|*records| send "#{habtm}=", records.compact}
  end
end

app/models/monster.rb

class Monster < ActiveRecord::Base
  has_and_belongs_to_one :area
end

Monster.find(1)
=> #<Monster:0xb70943d8 @attributes={"name"=>"スライム", "id"=>"1", "rank"=>"F"}>

Monster.find(1).area
=> #<Area:0xb70888f8 @attributes={"name"=>"ノビス島", "monster_id"=>"1", "id"=>"1", "area_id"=>"1"}>

Monster.find(1).area = Area.find(2)
=> #<Area:0xb7075c94 @attributes={"name"=>"デオドラン島", "id"=>"2"}>

Monster.find(1).area
=> #<Area:0xb706be74 @attributes={"name"=>"デオドラン島", "monster_id"=>"1", "id"=>"2", "area_id"=>"2"}>

エリア→モンスターは普通に habtm で。

app/models/area.rb

class Area < ActiveRecord::Base
  has_and_belongs_to_many :monsters
end

>> Area.find(2).monsters.map(&:name)
=> ["バブルスライム", "スライムつむり", "エンゼルスライム", "はぐれメタル", "メタルキング", "スライム"]

● n:m への仕様変更

habto は内部的には habtm なので、もしモンスターが複数のエリアに出現するような仕様変更があったとしても、そのまま habtm としてアクセスするだけでよいし。(プログラムには全く修正の必要がない)

Monster.find(1).areas = Area.find(:all, :limit=>3)
=> [#<Area:0xb737f228 @attributes={"name"=>"ノビス島", "id"=>"1"}>, #<Area:0xb737f0d4 @attributes={"name"=>"デオドラン島", "id"=>"2"}>, #<Area:0xb737ef94 @attributes={"name"=>"サンドロ島", "id"=>"3"}>]

Monster.find(1).areas.map(&:name)
=> ["デオドラン島", "ノビス島", "サンドロ島"]

熊井ちゃん、これ意外とCPよくない？また手紙書くね、熊井ちゃん。

舞波。

● [熊井ちゃん] has_one / has_many

熊井ちゃん、考えれば考えるほどテーブル設計がわかんなくなってきたよ。なんとかしてー。リソースエンティティは絶対に FK を持たないようにして、関係は全て関係テーブルに追い出したらダメなの？そう考えたら、has_one とか has_many とか何なの？そんなのどこで使うの？なんとかしてー。そんな風に関係テーブルを1つ追加すべきかどうかに関して、必死にテーブル設計を行う一方で、

RDB制約1

属性値が多値の場合は別テーブルにするべき

という大人の願望の押し付けには、縛られたくない！詰め将棋を必死に考えつつも、無駄な持久の手を指すような矛盾というか。なんとかしてー。もう怖くてテーブルが作れなくなったよ、熊井ちゃん。

● 究極的な属性の追い出し

関係テーブルへの追い出しを敷衍して分解能を最大にすれば、究極的にはリソースの属性なんて全て別テーブルに追い出せるんじゃない？なんとなれば、対象の固体(エンティティ)を捉えるという行為において、殆どの属性が外的な性質なのだから。熊井ちゃんの存在にとって「名前」を持つことは必要条件じゃないから、熊井ちゃんテーブルに名前があること自体ナンセンスだよね。You、名前属性テーブルに追い出しちゃいなよ！つまり、全ての(外的性質な)属性は、その属性を値に持つだけのテーブルへと解体されてゆき、最後に残るのは、

• 固体の存在を表す「リソース存在テーブル」(*1)
• それらの外的性質を切り出した各「(リソースの)属性テーブル」
• それらを関連付ける「関係テーブル」(*2)

だけになる。それがロックだ！

モンスター(存在) id 1	名前関係ケーブル monster_id monster_name_id 1 101	名前属性 id name 101 熊井ちゃん
	ランク関係ケーブル monster_id monster_rank_id 1 201	ランク属性 id rank 201 S

これだと、あの耐え難い「RDB制約1」からも自動的に解放されている。

モンスター(存在) id 1

名前関係ケーブル monster_id monster_name_id 1 101 1 102

名前属性 id name 101 熊井ちゃん 102 くまいちょー

(*1) 内的な性質である属性は存在テーブルに入れることはできるが、多くの場合主キー(サロゲートキー)のみとなる
(*2) 各エントリは独立した固体(エンティティ)ではないため、関係テーブルは交差エンティティとは呼べない

● 「属性テーブル」と「関係テーブル」の融合

上で気になるのは、属性テーブルのエントリは、(*2) で補足した通り本質的にはリソース(存在テーブル)に依存しているという点。つまり、ある属性エントリが、現在所属している存在エントリとは別のエントリから参照(関係付け)されることはないため、交差エンティティが目指すような独立した事象の関連付けという大げさな手段をとる必要がないことがわかる。(図で言えば、右から左への関係従属性が常に存在する)。

また、その関係テーブル自体に直接属性値を持たせたとしても、意味的にも機能的にも問題は発生しないので、テーブル数の無駄な増加を防ぐためにも両者を融合させるべきであろう。最終的には、以下の構造を得る。

モンスター(存在) id 1

名前属性付関係ケーブル monster_id name 1 熊井ちゃん

熊井ちゃん、これってなんて has_one / has_many？orz (いまここ)

● メガマック食べて見たい

107 ：名無し募集中。。。 ： ：2007/01/13(土) 18:32:05.19 0

　　(　⌒　)
　　　l | /
　　〆⌒ヽ
⊂（#‘д‘）
　/　　　ノ∪
　し―-J　|l| |　　　
　　　　　＠ノハ＠ -=3　ペシッ!!

(「メガマックの感想」スレ http://ex19.2ch.net/test/read.cgi/morningcoffee/1168676815/107 より)

● String#scrape

どうせお前らはあれだろ、scrAPI は強力だし、これこそ自分がまさに待望してた道具、使いこなすぜ！と意気込んでるんだけど、どれだけ決意してもあの複雑な引数に毎回挫折しちゃって、挫折つーかちょっと使いたいだけなのにパーザ(Scrape)用のクラスを定義するのが面倒なんだよね、みたいな言い訳を毎回自分にしつつ、結局使いこなせてない脳内ゆとり世代のお前らなんだけど、まぁ実際引数に無駄に色んな機能を詰め込み過ぎてる感は否めないし、というかextractorのsrcとdstはどう見ても直感的に逆だろ、grepみたいに使わせろよ使えない1だな、みたいな愚痴をこぼしてたら、むしろCSS3なgrepとして使えるだけでいい事に気付いて、You、Stringクラスに入れちゃいなYO！

String#scrape の定義

require 'scrapi'

class String
  def scrape(pattern, options = {}, &block)
    options = {:extract=>options} unless options.is_a?(Hash)
    options[:parser_options] = {:char_encoding=>'utf8'}.merge(options[:parser_options]||{})
    extract = options.delete(:extract) || block && :element || :text
    scraped = Scraper.define do
      process pattern, "matches[]"=>extract
      result :matches
    end.scrape(self, options) || []
    block ? scraped.map{|i| block.call(i)} : scraped
  end
end

(※ 以下、$KCODE = 'u' を前提)

● 使用例

HTMLテキストデータ

...
<tr>
  <td class="style_td">スライム</td>
  <td class="style_td">基本のスライム</td>
  ...
</tr>
<tr>
  <td class="style_td">バブルスライム</td>
  <td class="style_td">緑の溶けてる奴</td>
  ...

grep のように使う

html.scrape("tr td")
=> ["スライム", " 基本のスライム", ..., "バブルス ライム", "緑の溶けてる奴", ...]

CSS3をエンジョイ

html.scrape("tr td:nth-child(1)")
=> ["スライム", "バブルスライム", ...]

● 朝日COMのRSS代わり

主要ニュースのタイトルを取得

require 'open-uri'
html = NKF.nkf('-w', open("http://www.asahi.com/").read)
html.scrape("#con1 li a:nth-child(1)")
=>
["暖冬で原油価格が下落　日本は灯油在庫が過剰",
 "三菱電機、エアコンのリサイクル料金値下げ",
 "１万２千羽の焼却始まる　宮崎の鳥インフルエンザ",
 "顧客の３０００万円詐取　容疑の公認会計士を逮捕",
 "楽天新人の田中投手、合同自主トレでブルペン投球"]

● 属性値へのアクセス

第二引数に extractor (専門用語)を指定することができる。extractor の書式では"@" プレフィクスが属性値を意味するので、リンクを取得する場合は "@href" を指定する。

リンク先を抽出

html.scrape("#con1 li a:nth-child(1)", "@href")
=>
["/life/update/0115/014.html",
 "/life/update/0115/013.html",
 "/national/update/0115/SEB200701150016.html",
 "/national/update/0115/TKY200701150337.html",
 "/sports/update/0115/207.html"]

● element への直接アクセス

String#scrape は戻り値に文字列の配列を返すが、scrAPI 自体は内部では HTML 要素クラスで管理している。その element オブジェクトを直接操作した場合は、ブロック引数を利用する。

elementクラスの確認

html.scrape("#con1 li a:nth-child(1)"){|e| e.class}
=> [HTML::Tag, HTML::Tag, HTML::Tag, HTML::Tag, HTML::Tag]

element は親と子の全ての参照を持つため、"{|e| e}" とかやるのは表示が大変なことになるので危険。(= 一度やって体で覚えるのもあり)。実際の用途としては、「リンク名とリンク先を配列に入れる」場合などに便利。

scrAPIのelementを直接参照

html.scrape("#con1 li a:nth-child(1)"){|e| [e["href"], Scraper::Base.text(e)]}
=>
[["/life/update/0115/014.html",
  "暖冬で原油価格が下落　日本は灯油在庫が過剰"],
 ["/life/update/0115/013.html",
  "三菱電機、エアコンのリサイクル料金値下げ"],
 ["/national/update/0115/SEB200701150016.html",
  "１万２千羽の焼却始まる　宮崎の鳥インフルエンザ"],
 ["/national/update/0115/TKY200701150337.html",
  "顧客の３０００万円詐取　容疑の公認会計士を逮捕"],
 ["/sports/update/0115/207.html",
  "楽天新人の田中投手、合同自主トレでブルペン投球"]]

element がどういうアクセサメソッドを理解するかについて興味があれば、scrAPI のドキュメント or ソースを参考に。でも、Scraper::Base.text は便利なので、もう HTML::Tag に持たせておくのもよいかも。

textは便利なので定義しちゃう

class HTML::Tag
  def text() Scraper::Base.text(self) end
end

さっきのコード(リンク名とリンク先を取得)

html.scrape("#con1 li a:nth-child(1)"){|e| [e["href"], e.text]}

● 参考

• 正しい使い方 http://d.hatena.ne.jp/secondlife/20060922/
• [公式] http://blog.labnotes.org/category/scrapi/
• [公式] Cheat Sheet http://labnotes.org/svn/public/ruby/scrapi/cheat/scrapi.html
• CSS セレクタに関するおさらい 2 http://hyper-text.org/archives/2007/01/css_electors_reference_2.shtml
• DQMJ 攻略サイトまとめwiki http://dqmjwiki.fuff.info/

● [Berryz]「B.L.T.より パート9」シリーズ

このシリーズはヤバイ。全員可愛いなんてファイポ以来じゃね？特にももちなりしゃヤバイ。

(画像はハムろだより)

● 追記

• 20070118 キャプテンを追加。ごめんね佐紀ちゃんごめんね

● [熊井ちゃん] 第1回Rails Chatブレスト大会

熊井ちゃん、Rails Chat の人たちとブレスト(オフ会)してきたよ。内容は主にテーブル設計について。簡単に1NFのおさらいをした後、2NF,3NFとか一気に飛ばしていきなり7NFの話に。なんとなれば、その途中は誰も正確には理解していないから。そんな中途半端な技術者達が4人。4時間強の冬冬合宿へ！久々に脳がオーバーヒート。お陰で色々悩んでた部分が一気に氷解＆整理できたけど、急速に得たものはそれが失われていくのもまた早い、って彩子さんが言ってたから忘れないうちにメモっておくね、熊井ちゃん。

● 7NF

1NFでドメインの原子性とタプルの集合性を保障した熊井ちゃん。2〜3NFで関係従属を、4〜5NFで結合従属を解消した熊井ちゃんは、6NFでドメイン間の独立性を保障することに成功した。そして遂に熊井ちゃんはリソースを「存在」と「ドメイン属性関係」へと分解する7NFへ到達した。

● 存在

7NFでは、思考対象であるリソースをまず「存在」として捉える。

● リソース

リソースとは、実世界を構成している対象(事実としての固体)である。正確に言えば、実在するものだけでなく、概念的なモデルも含まれる。その粒度もまちまちであり、設計者が「思考の対象として捉えるもの」は全てリソースになりえる。この意味では独我的である。

● 属性

リソースを構成するものは「存在」と「属性」である。必須要素である「存在」は内的性質を表し、外的な性質は全て「属性」として追い出される。

リソース { 存在, 属性 }
存在 { 内的性質 }
属性 { 外的性質 }

● リソースの独立性

リソースはそれだけで独立して存在するものであるため、他者との関係に関する情報は持ちえない。従って、この(実)世界にFKは存在しないことになる。だって、FK(福田花音)は天使だから。

● 天上界理論

天使たるFKは地上には存在しないが、FKだけが住む楽園がある。これが天上界である。逆に言えば、天上界には実体を持つ者が踏み入れることはできない。全てのドメインが天使である関係を「リソース間の関係」と定義する。天上界にはこの関係テーブルしか存在せず、タプルを構成する値は全てリソースへのFKである。

● メタ天上界

では、天上界にある「リソース」間を繋ぐ関係というものは存在しないのか？もし存在すれば、それを管理するメタな関係テーブルは、天上界のさらに上位に存在することになる。つまり、今まで天上界だと思っていたものが実はまだカリン塔なのではないかという疑惑が生じる。これに対して熊井ちゃんは明確な答えを出していないが、そのメタ関係テーブルは、突き詰めるとそれらが指す関係テーブルのさらに先にある具象リソースへのポインタであるため、それらの実体(リソース)を直接指すようにすることで、従来の天上界の関係テーブルへと解消することが可能だと述べている。この天上界の概念は、リソースをノード、関係をエッジとしたグラフ理論でも表現できるため、その意味においても、線同士を結ぶ概念は考慮しなくてよいと思ってる熊井ちゃん。

● ORM依存主義からの脱却

ORMは対象が1タプルである場合に最大の生産性を発揮するが、RDBMのモデルであるリレーショナルモデルは本来集合論であり、集合演算操作を簡単に行うための道具である。その長所を活かす集合演算を行うパターン(仮にActiveMaskと命名)を構築し、両者を適材適所で利用することで、RDBMの能力を最大限に利用できると考える熊井ちゃん。

存在レベルまで解体された7NFは集合演算との親和性が高く、複雑化しやすい条件節(where区)を INNER JOIN の集合演算へと解きほぐすことを実現する。具体的には、あるリソースの存在集合 RE、そのリソースのステータス集合 RS、そして論理削除集合 RD という関係変数を用いれば、あるステータスを持つ削除されていないリソースの取得を、熊井ちゃんは以下のように記述する。

7NF + AR + AM

class Member < ActiveRecord::Base
end
class MemberStatus < ActiveMask::Status
end
class MemberDeleted < ActiveMask::Mask
end

(Member * MemerStatus[1] * MemberDeleted.not).find(:all)

● [Rails] 第 6 回 Rails 勉強会＠関西

講師としてお呼ばれ。参加者、関係者の皆さんお疲れ様でした。内容は省略。（えー！）。というのも、東京と関西で勉強会の形態や雰囲気が全く違うのが一番印象的だったので、その辺の違いを率直な感想で綴る方が、歴史的に見れば1勉強会の内容よりも遥かに有益な情報になるだろうから。(両方に参加経験がある人はそんなに多くないと思うので)。深く考察する時間はないので、とりあえず、漠然とした感想を徒然と。

● 東西勉強会の違い

(*1) 表現は両者の相対性に基づくもので、さらに敷居を高めようとするものではない。(東京でも毎回のように Kanta さんが初心者向けセッションを開いてくれています。Kanta乙)

● Rails東京の特徴

東京では個々のRails技術者が参加し、興味のある話題に応じてセッション参加者の集合が決定される。複数の候補からセッションを選ぶことができるため、目的の健全性が満たされやすい。特に自分が知りたい内容に関して、それに興味を持つ人々とブレストを行う場があるのは非常に有益であり、何か新しいアイディアが生まれる可能性が高い。参加者は、知識を深めることができるが、恐らく、知識を広げることはできない。

● Rails関西の特徴

一方関西では、まず「関西」というコミュニティがある。スタッフが事前に全てを準備し、参加者は教えてもらえばよい。一見受身のようだが、食わず嫌いの情報から新たな知見を得ることもあるし、グループ作業ではわからない分野であるためにお互いが協力するという構図が生まれやすく、さらなるコミュニティを形成していくメリットがある。参加者はゆっくりとだが知識を広げ、人脈も広げていき、そこから新しいビジネスが生まれる可能性が高い。しかし、スタッフへの依存度が増すと、それらが固定化し代替が効かない状況を生み、特定のスタッフや発表者に負荷が集中する可能性がある。

● 7NF に見る二次会出席率

例えるなら、東京の参加者は7NFのエンティティである。単体で火星に行くこともできるほど個々は独立した存在であり、「興味」という関係(タグ)によってセッションが紐付けされるだけの疎結合である。セッションが終わればバラバラになり、二次会への参加率も低く、他の勉強会にも参加しない。一方関西にはコミュニティがあり、参加者はそのFKを持っている(従属している)。これは勉強会後の二次会への参加率の異様な高さ(東京比)に繋がり、また、コミュニティが主催するその他の勉強会(Ruby勉強会等)への参加メンバーとの積集合は、東京のそれと比較するとかなり高いであろうことは容易に推測でき、恐らく当たっている可能性が高い。

● まとめ

もちろん両者は一長一短であるし、どちらがよいと言うわけでもなく、というよりむしろ、東京が道を開拓し、関西が高速道路へと舗装する、というミラクルな役割分担が自然に実現されており、お互いのこの絶妙なバランスがRailsの普及につながっている、と好意的に(恣意的に)解釈したい、と熊井ちゃんは表明している。

● メモ

• 新神戸駅の二階から外に出ちゃうと途方にくれる
• 神戸牛のおいしい店の名前はひらがな三文字 (鳥頭)
• ブログにはRSSを付けるのがWeb2.0
• 国際化対応を考えると郵便番号のコード化は破綻する
• 6NF のおっさんが有効期限を入れたテーブル設計をしている (面白そう)
• yu-yan が起業していた (偉い!コミュニティをフルに利用してがんばれ!)
• yu-yan の彼女がモデルのようだった (MVCではなく美人の意味で)
• かずひこさんはビザ待ち状態。早ければ2月、遅ければ4月
• moriq さんも7NFと似た方向のテーブル設計に向かっている
• cuzic さんの家に泊まった (夜中のどうでもいい話が楽しかった)

● 参考

• 発表資料： http://rails.wota.jp/kansai2007/
• 追加資料(7NF): http://rails.wota.jp/kansai2007/7NF.html
• お持ち帰りセット: http://rails.wota.jp/kansai2007/kansai2007.tar.gz

● [Rails] Rails勉強会＠東京第14回

そろそろインフルエンザが流行る季節のせいか、体調不良で欠席者多数。セッションが不足気味になったので7NFについて話す。7NFは多値絡みのインピーダンスミスマッチに対するアンチテーゼとして極論レベルまで無茶したモデル化で、すぐに破綻するだろうと思ってたからこそそんな大そうな名前を名乗っていたのだが、これが意外と明確には否定できずに、いつも「なくはない」という結論ばかりだ。この辺で勉強会でYuguiたんにバッサリと切り捨てて欲しいなぁと思っていたが、残念ながら不参加だったために、7NFは今日も生き残ってしまいました。死に場所を求めた終わりのない旅がまだ続くのかと思っていたら、遅刻してきた高橋会長が見るなり一言で切り捨ててくれた。

高橋会長語録

ヴィトゲンシュタインとか言い出す奴は電波系

● ヴィトゲンシュタイン

そんな我等が電波系の父であらせられるヴィトたんに興味がある人にはこれがお勧め。

「ウィトゲンシュタイン『論理哲学論考』を読む」

野矢 茂樹 (著) 
文庫: 382ページ
出版社: 筑摩書房 (2006/04)
ISBN-13: 978-4480089816

Amazon http://www.amazon.co.jp/dp/4480089810

前期の論考についてですが、全体的に平易な記述がわかりやすく、現在の問題意識を確かめつつ用心深く話を進めていくので、道に迷うこともありません。普通に読み物としても楽しめます。

● メモ

• 瀧内式TDD三種の神器(ZenTest, RedGreen)
• has_one :through の habto 的実装はありえるかも
• script/rename は意外と難しい
• あれが今年もある

● 参考

• Rails勉強会＠東京第14回 http://wiki.fdiary.net/rails/?RailsMeetingTokyo-0014
• ZenTestのautotestがとても快適 http://rails.office.drecom.jp/takiuchi/archive/96

● プログラマの最終兵器

これが欲しい。凄く欲しい。

「電動式寝ながらワークステーション」

http://japanese.engadget.com/2007/01/22/ergopod-500/

どう見ても航空写真です。時代は「介護ベッド」か「電動式寝ながらワークステーション」の二択だ。これでプログラムを書きながら息絶えたい。

● クリックし易いハイパーリンク

どうせお前らはあれだろ、HTML のハイパーリンクはクリック範囲が文字列長に依存するから、短い文字列の場合はクリックが面倒で困っていて、特に Table による表組みの場合とかは TD レベルでリンクさせてくれよと思いつつも、そのためだけに JavaScript を使うのも負け組だ、みたいな妙なポリシーのせいで今日も悶々とするお前らなんだけど、Chatでおさかなさんに「Aタグを block 要素にすればいいじゃん」と教えてもらって目から鱗が落ちちゃうんだろう？

● Aタグblock作戦

CSS

a.block { display : block; }

ソース

<div style="background-color: #cccccc;">
<a href="http://www.asahi.com/" class="block">朝日新聞</a>
</div>

実行結果

● Aタグblock作戦 (hover 入り)

CSS

.clickable {
  color            : black;
  background-color : #eeeeff;
}

.clickable a{
  display          : block;
  color            : black;
  background-color : #eeeeff;
  text-decoration  : none;
  width            : 100px;
}

.clickable a:hover{
  background-color : #ccccdd;
}

.clickable td {
  border : 1px solid #666;
}

ソース

<table class="clickable">
<tr>
  <td><a href='#'>舞波</a></td>
  <td><a href='#'>マイハマン</a></td>
  <td>備考</td>
</tr>
<tr>
  <td><a href='#'>桃子</a></td>
  <td><a href='#'>ツグナガ星人</a></td>
  <td>備考</td>
</tr>
</table>

実行結果

舞波	マイハマン	備考
桃子	ツグナガ星人	備考

幅は固定になっちゃうけど、表組みの場合はデザイン的にも大概固定長なのでＯＫだよね、熊井ちゃん。おさかなマンありがとう！

● [Game] 三国志大戦DS

世界樹の迷宮はゲット失敗したためこちらは即日ゲット。早速プレイするも、バトル開始と同時に敵がワラワラと攻めてきて、何をしていいのかわからないまま撤退に追い込まれちゃうのが流行。というか、一騎打ちで勝てない。張飛がいきなり黄巾賊に打たれるとか。一騎打ちは音ゲーのようにタイミングを5回合わせてクリックするんだけど、何度やっても全ミスなのよね。一騎打ちとかいうレベルじゃねーぞ。ちなみにアーケードは未経験。

どっちにしろ最初は何やっていいかわからないので、仕方なくやり続けるんだけど、それでも10回くらいやってたらようやくタイミングが掴めてきた。クリックから判定までのタイムラグがある気がするので、最初は塊の真ん中を狙って打つのがよさそう。パネルの左右はどちらでもＯＫ。戦闘を重ねると負けても武将カードがゲットできるので、デッキ組むのが楽しくなってくる。序盤はとりあえずバトル回数を増やすのがよさそうだ。ストーリーモードは蜀で始めて魏延あたりで挫折。CPU戦は激まで行けたけど、9,10戦目が無理。あの呂布、馬超、張飛とかのオールスター軍の絶望的な突撃ってどうやって止めるのさ、熊井ちゃん。

今のデッキ

(データは「三国志大戦のなにか」様より)

● 参考

• 三国志大戦DS@2chまとめ http://www25.atwiki.jp/sangokushi-taisen_ds/pages/1.html
• 三国志大戦のなにか http://lv.skr.jp/san/

● こなぁ〜ゆきぃ〜〜〜！

サビわろす。「くるぞ」がお気に入り。

http://www.nicovideo.jp/watch?v=utJaJxsAiyb5Y

● [Rails] グランドリファクタリング

会社で1年前に凍結されたプロジェクトが再始動したのだが、この業界で1年前の技術は既に過去であることを実感した。

1. Rails自体の問題 (1.0 時代は機能的に貧弱。Cascaed Eager も RJS もないとか)
2. プラグイン環境の充実 (便利なプラグインが現れ日々便利になっている)
3. テーブル設計の問題 (7NFとか考えてると has_many 連発はありえない)

3 は個人的な問題に寄る所であるが、当時はまだ道具(Rails)的に他に選択肢がなかったのも大きい。

● 修正項目

ということで、1年前の Rails アプリを見て手直ししたくなる項目ベスト5。

1. テーブル設計
2. 権限管理

1はやはり流行りの三テーブル構造で。関係テーブルをどんどん挟んでエンティティを疎な関係に保ちたい。テーブル数は多くなるけど気にしない。というか、既に100個以上はあるから200になっても気にならない。

2はプラグイン絡みだけど、権限を全部 boolean で管理してるテーブルを今見ると吐き気がした。少なくとも概念上は吐いた。

146権限のカラムとか。オワットル。こんなのが一杯あって耐えられない。当時は仕方ないとして、じゃあ、今ならどうするか？やはり acts_as_bits。

とかわーわーありましてどうにも耐えられないので、上司を説得して1週間の大リファクタリング大会期間を頂きました。これから半年1年これと付き合うとすれば、1週間なんてきっと易いもんでつよ。楽勝でペイできるよね、熊井ちゃん。

● stats

ちなみに現状はこんな感じ。テストは generator の副産物だけで全く書いてません。はい。

rake stats

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Helpers              |  3161 |  2666 |      10 |     427 |  42 |     4 |
| Controllers          | 16703 | 13933 |     128 |    1634 |  12 |     6 |
| APIs                 |     0 |     0 |       0 |       0 |   0 |     0 |
| Components           |     0 |     0 |       0 |       0 |   0 |     0 |
|   Functional tests   |  6654 |  4764 |     156 |     759 |   4 |     4 |
| Models               |  1459 |  1236 |     101 |     125 |   1 |     7 |
|   Unit tests         |   380 |   266 |      38 |      38 |   1 |     5 |
| Libraries            |   570 |   463 |      10 |      34 |   3 |    11 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                | 28927 | 23328 |     443 |    3017 |   6 |     5 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 18298     Test LOC: 5030     Code to Test Ratio: 1:0.3

● plugins

最近よく使うプラギンベスト10

● 追記

• 2007.2.2 諸葛亮曰く「acts_as_authenticated と acts_as_attachment-1.1.6 は別物です」(thanks to goto30)

● [Berryz] 俺俺ハロプロ楽曲大賞2006

そろそろ1月が終わりそう。だからこそ今、ハロプロ楽曲大賞2006だ。

[楽曲部門]

[PV部門]

総合1位はまっさらで確定。そして、As ONE は名曲。つんくの力の入れ方が露骨に℃-uteな1年だったことよ。

● 参考

• 第5回ハロプロ楽曲大賞2006 http://www.k2.dion.ne.jp/~prse/hpma/2006/

● [Berryz] ピチレゲット大作戦

ブツ ＜ あのね、今度りしゃこがピチレでモデルデビューするやん

ハゲ ＜ そうやな。めでたいな

ブツ ＜ めでたいことあらへんがな。最近それで困ってるちゅーねん

ハゲ ＜ なんでや、ええことやないか

ブツ ＜ デビュー自体はええわ。本をどないして買うねん、ちゅー話や

ハゲ ＜ そんなもんお前、普通にコンビニで買うたらええやねんか

ブツ ＜ ああ、普通にな。。。でもなぁ、、、店員さんが
　　　　「お客様、ピチレでよろしかったですか？」
　　　　て確認して来たらどないするんや

ハゲ ＜ ファミレスちゃうやろ、何の心配してんねん
　　　　じゃあ「いつものピチレ下さい」言いながら買えよ

ブツ ＜ ああ、常連のようにな。。。でもなぁ、、、店員さんに
　　　　「うわぁ、ええ歳したおっさんが女子小学生が読む雑誌を定期購読してはる」
　　　　て思われたら嫌やし

ハゲ ＜ ほんなやったら、何か別の真面目な本と一緒にさりげなく買えや！
　　　　それこそお前の好きなビトゲンシュタインに挟んで持って行けばええやろ！

ブツ ＜ お前、論考と探求とピチレ売ってるコンビニがどこにあんねん！

ハゲ ＜ ほいじゃ買うときに領収書を貰えや！
　　　　そしたら会社で使う資料か何かだと思うやろがい！

ブツ ＜ 何で顔バレした上に会社名まで白状せなあかんねん

ハゲ ＜ 素性ばれたくないんなら、はなからネット通販で買えや！
　　　　Amazonとかで注文したらええやろ

ブツ ＜ お前、それでピチレゲットできてもな、
　　　　数日後に「小学6年生」とか「ちゃお」とか提案されたらヘコむやろ
　　　　Amazonの購入履歴からの商品お勧め力を見くびんなよ！

ハゲ ＜ 何で怒られてるねん

ブツ ＜ もうええ。お前に相談したのが間違いやったわ

ハゲ ＜ どないすんねん

ブツ ＜ いつものスレで熊井ちゃんに報告してくるわ

● 参考

• [公式] ピチモ http://www.pichilemon.net/pichimo/p_sugaya.html
• [2ch]『ピチレモン』を自然に買う方法 http://ex19.2ch.net/test/read.cgi/morningcoffee/1170079694/l50
• [2ch] 熊井ちゃんにいろいろ報告するスレ１３ http://ex19.2ch.net/test/read.cgi/morningcoffee/1169611552/l50