3 日坊主日記 - 6NFかわいいよ6NF
新着記事 2006-12-29 SQL Designer ThunderBird 送信済みトレイでフィルタを実行してしまったとき 2006-12-27 高知出張 Rails 勉強会＠関西第6回 (2) 2006-12-26 cocoa surround.vim 2006-12-24 聖剣1 2006-12-18 rakeがエラー 2006-12-17 Temporal Data on Rails: #1 Collection Item の生成 2006-12-15 WEB+DB PRESS Vol.36 2006-12-11 Rails 勉強会＠関西第6回 2006-12-10 トランザクション処理, 読書について 2006-12-06 6NFかわいいよ6NF 2006-12-01 UnSpun by Amazon 最近のツッコミ rkyntggejp (06-19) カテゴリ Apach
ABD飲み会参加 - yojikのlog
Railsな人々、Seasarな人々に挟まれて、無所属系で人見知りの僕は大変緊張いたしました。 ちょっと面白かったのは飲み会前の妙に緊張した雰囲気。全員が沈黙して資料読んでる風景がすごかった。店員がちょっとびっくりしてたね。 僕は、宴会初期はid:habuakihiroさんの隣の位置という好ポジションにつけながら、なぜかABDの話をほとんどしてなかったり。(だめじゃん) ちょっと話していたのはUIの話。ちょっと話題になったのは、例えばMSOfficeのようなGUIアプリのデザイナはどんな仕事をしているんだろうという話。なんとなくオフィスアプリの「デザイナ」がHTML相当の画面系のコード(WPFみたいな)に触ることが無いような気がする。今のWeb系プログラマの常識がどこまで常識なのか? あとWindowsPowerShellカッコイイという話。 そのあと他の人とABDやワークフローの話などな
Railsの人がABDに興味がある理由がわからない - recompile.net
RailsにはDB設計技法がないから、Railsの人たちがABDに興味あるってそれ本当？ 実はRailsがやろうとしてないことをRailsに押し込めようとしてるから無理がでてきたってだけじゃないの？ なんてね。おれ、RubyとかRails大好きだからさ、Java系の人がRailsに騙されて一瞬右往左往しちゃったみたいに、Rails系の人が騙されて右往左往すんのは見たくないのよ。（騙されてっていうのは比喩ですからね！ ここで騙す方とされてる側に騙す意図はありませんですよ。それこそ騙すのは話題にでてたああいう雑誌ですよ！） さて、うまく言語化できるかどうかはわからんけど、つらつらと書いてみる。あと、私はBuriとかABDとか詳しく知らないので、嘘書いてるかもしれません。先に謝っておきます。ごめんなさい。 まず、なんでABDの話なのにBuriってのがでてきたのかってことを考えなきゃいけないはず。
ABD飲み会 - recompile.net
行ってきました。いえい！ 幹事の方、ありがとうございました。そうそう、初めてyuguiさんをidentifyしたんだけど、びっくりだ！ 二度も紹介されてた！！ 俺、駄目すぎ！！！ もうちょっと、なんかあってもよかったとおもうんですよー！ 「ファクトってのはなあ、イミュータブルなんだよおお！」「ステートを持たないオジェクトなんてオブジェクトじゃねー！！」みたいな乱闘とか。「プッ今時フロントコントローラパタンかよｗｗｗｗｗ」「ステートレスにこだわるなんて、OOPがわかんねーだけじゃないのｗｗｗｗｗｗｗ」みたいな乱闘とか。 うん、俺はどっちも使いますけどね。 あ、今気付いた。モーニング娘は安倍と飯田の敗者復活物語で、飯田がリーダーになるっていう勝利によって第二部完であとはハロプロに興味もてねーんですよって話を一方的にまくしたてた相手が舞波の中の人か！！ もっとまともな話すりゃあよかった。もったい
has_one :through 経過報告(1) - 世界線航跡蔵
has_one :throughを作ってて、一応、基本的な使いかたに関しては動くようになったと思う。本家のRevision 5642から分岐したリポジトリを <URL:http://svn.yugui.jp/svn/has_one_through/trunk/> に置いてある。(注: 2007-07-12現在サーバー停止中) has_one :throughな関連をEager loadingしたときの望ましい挙動がよくわからない。 Polymorphic Relationshipとの絡みは適当。こんな仕様でよいのかな。 瀧内さんが書いてくれた Unsaved Object のところはまだ取り込んでない。これが次のタスクかな。 残りの仕様が固まって、それを実装したら本家にパッチを投げる。 現時点でのpatch
ABD飲み会 - http://nxfhqh.com/
@@ -1 +1,94 @@ -qxOrcqGl +2006年12月3日に、Activity Based Datamodel飲み +会を開催します。ABD提唱者の羽生章洋さんをお招きしてデータ +ベースモデリングについて語る集いです。 + +'''（このウィキは遅くとも2011年には管理されなくなっています）''' + +! 概要 +ABD(Activity Based Datamodel)は羽生章洋さんが提唱するデータベー +ス設計技法です。羽生さんのホームグラウンドであるSeasarコ +ミュニティは勿論のこと、そのアジャイル開発との親和性からRuby on +Railsコミュニティにおいても注目を集めています。 + +ABDについては2006年Developers SummitやSeasar +Conference 2006 Springにおける羽生さんの講演が唯一の情報源であ +り
エンティティの見出し方・属性の割り振り方 - 伝統的設計・T字形ER手法・ABD - 極北データモデリング
非正規形の表が与えられたときに、その表を出力できるDBをどうやって設計するか。 伝統的DB設計法・T字形ER手法・ABDのやり方を並べて書いてみる。 伝統的DB設計法 伝統的なDB設計では、非正規形の表を正規化する過程で、エンティティを切り出していく。 また正規化しながら、関数従属性に従って属性を割り振っていく。 データ項目の意味は考えず、データ項目の重複が最小になるように分解するので、m:nの関係の時以外は交差エンティティは発生せず、「社員マスタに所属部門コードがある」といった結果になる。 T字形ER手法 上記を問題視したのがT字形ER手法。 T字形ER データベース設計技法 P-26 ER手法が大きく勘違いされた点は、データを正規化してから、ER手法を使ってデータ構造を表現する、という点にある。 つまり、ER手法が表現手段に成り下がってしまったのである。ER手法は、思考手段(解析手法)
極北データモデリング■[RDB]タグ
削除フラグ(というか「論理削除を削除フラグだけで実装すること」)批判は何度も見てきたが PostgreSQLアンチパターン これ見るともはや論理削除自体が闇扱いになってしまったようだ。 闇だろうと何だろうと論理削除(というドリルが提供する穴)は要件の実装に必要なので、このへんの議論はあまりまじめに追ってこなかった。 いつだったか「削除フラグはバグの温床だからやめろ」という主張を読んでおぉなるほどと思い、ではどうやって論理削除を実装するのかなと思って続きを読むと「『ほんとに削除したデータが必要ですか?』とユーザに確認して、物理削除に変えさせてもらう」と書いてあってズコーとなったことがあるが、要件削っていいなら実装上のどんな問題も消えるわけで、何かもう別世界の議論で自分の仕事には関係ないと思っていた。 が、これだけ繰り返し批判されているからには、論理削除を正しく使う方法なり条件なりを明らかに
![極北データモデリング■[RDB]タグ](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
ABDの感想 - 世界線航跡蔵
ここまで、RailsでABDもどきをやってきたところから、 ABD (Activity Based Modeling) の体系を想像する(1) の「謎と課題」に回答してみる。 resource の中に Relationship(外部キー)が混在していることのおかしさ おかしくはない。はぶさん曰くIREを前提に考える方がよりRDBの背景理論の素朴な実装ではあるらしいけれども、素朴な実装でIREが沢山発生してしまうことによる結合コストを減らすための最適化テクニックとして混在させるというのはそう変な話じゃないのだと思う。 ただ、損得で考えればあとで書いてらっしゃる「各業務専用のデータアクセス」がやりづらくなるし、それで私は原点回帰にしてeXtremeなABDは面白いと思ってる。 業務ごとにオブジェクトのチェーンを手繰りまくる必要 なんか、書いてみるとSQLで済んじゃうんだよね。だからオブジェクト
Rails勉強会@東京 第9回 - 世界線航跡蔵
形式は前半・後半に時間を区切って オープンスペース 形式。要 ポジション・ペーパー というのも変わらず。 この形式はいいんじゃないかなと思ってる。最初、秋葉原でやっていた頃、参加者全員が集まって座れる場所を確保できなかった故に 角谷さん の発案でオープンスペースになったそうだけれど( 第0回 )、これによって、最多で10人程度に分かれるから参加者のコミュニケーションが促進されてる。Listen Only Memberを発生しにくい仕組みになってるんじゃないかと思う。 反面、少数であるが故に全員が受け身だとひたすら沈黙になってしまうのは確か。一時期、そういう感じでいつまで経ってもセッション案が出なかったりしたけれど。でも、 もろはし さんの提言で事前にセッション案を十分に出しておくというのが復活して、そういう難点は解消されつつある。 ポジション・ペーパーについてはこれはよい作用をしているのは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スタロジカンファレンスやります！
http://d.hatena.ne.jp/habuakihiro/20061205
もっと激しい煽り愛が必要だとおもうよ (recompile.net)
ルーツ本 - 今年も僅かだはぶにっき
http://d.hatena.ne.jp/habuakihiro/20061012
ABD（はぶにっき 2006/9/30)
not found
http://d.hatena.ne.jp/habuakihiro/20060828
http://d.hatena.ne.jp/habuakihiro/20060824
not found