makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「XP祭り関西2014 ~ やってみよう!XP ~」に参加しました

2014/4/26(土) 「XP祭り関西2014 ~ やってみよう!XP ~」に参加してきました。

DoorKeeper
http://xpjug.doorkeeper.jp/events/9030

Togetter
http://togetter.com/li/659934

場所は大阪市鶴見区民センターです。
参加者は50人くらいでしょうか。



東京在住の私が2年連続で参加できたのは、ちょうどGW帰省の初日に開催されたからなのです。
朝7時くらいの品川発-新大阪着の新幹線に乗り、新大阪駅からJRと地下鉄を乗り継いで30分くらいかな?

ちなみに去年書いたブログはこちら。

「XP祭り関西2013」に参加しました
http://makopi23.blog.fc2.com/blog-entry-72.html

もう1年経ったんですねぇ。
ということで、取ったメモを自分の復習用にダラダラと書き起こしてみる。


■オープニングセッション
「わかりやすいアジャイル開発の教科書 ~ 教科書の向こうに何が見えてますか? ~」

書籍「わかりやすいアジャイル開発の教科書」の著者3名が、参加者のアジャイルに関するご質問、お悩み、課題などに答えていくセッションです。

わかりやすいアジャイル開発の教科書わかりやすいアジャイル開発の教科書
(2013/03/28)
前川 直也、西河 誠 他

商品詳細を見る

以下、個人メモ。

Q1.
  • 要件や仕様が確定しないと進めない、レビューが完了しないと先へ進めない現場がある。
  • でも、アジャイルだとそれはマイクロPDCAになってしまう。
  • がんじがらめの組織の場合にアジャイルをどう導入していけば良いか?

A1-1. 細谷さん
  • 「Doneの定義」を満たすことで「完了」にしますよ、といったように、プロセスを明確にしている。
  • ステップの管理という意味では、ステップは小さくするようにしている。
  • 今の現場は、1~2ヶ月単位で第三者検証を実施しているが、計画がミソ。
  • アジャイルの計画を立てて、それを第三者検証の担当者と合意をして、各フェーズにメトリクスを設定し1~2ヶ月単位で検証していく。
  • キモは、プロセス検証をしてる人とどう合意できるか、という点である。

A1-2. 前川さん
  • 重いことをやっている間にどんどん変わる。
  • どんどん仕様が変わっていかないと勝てない。
  • でも好きなようにやらせるとバグだらけになる。
  • なのでタイムボックスを切って、動くものを出していく。
  • 現物を見て、直すということを繰り返す。
  • QAの人にも早く入ってもらう。
  • それを経営者がそろそろ気づいている。なので現場も「やりましょうよ」と変えていかないといけない。

A1-3. 細谷さん
  • やり方を変えなきゃいけないと気づいてないケースがけっこうある。

A1-4. 西河さん
  • スマフォ開発はウォーターフォールでやってる間にOSのバージョンが上がる。
  • メーカーもそれに合わせて対応していかないといけない。
  • 各プロセスをちゃんと通らせるが、そこにどう変更プロセスを組み込むかが大事。
  • 変更プロセスを仕組みとしてちゃんと組み込むようにしている。



Q2.
  • アジャイルって少数精鋭?

A2-1. 西河さん
  • 新入社員のころからアジャイルが当たり前になるように、仕組みでアジャイルな組織にしている。

A2-2. 前川さん
  • 少数誠意なのはウォーターフォールもアジャイルも一緒では。
  • 成長していくアプローチができるのがアジャイルのいいところ。
  • 小学校や中学校が30人クラスだからといって、人が成長しないわけではない。
  • 100人で「なんちゃってスクラム」を回しているが、小さいサブユニットが複数できるのでチームは少人数になる。

A2-3. 細谷さん
  • いかに成長していくチーム作りをするかが重要。
  • 現場で実践すること。
  • 1つ1つのことをチームでしっかり見ていくこと。
  • ストーリーカードを詳細化するときには、チームで話し合う。
  • 設計はホワイトボードの前にチームで集まって話し合おう。
  • コーディングはペアプロとTDDを取り入れ、コミット時にはレビューをする。
  • 振り返りをしっかりやる。
  • 少人数は結果。1つ1つをしっかり見ていけるチームじゃないと成長できないし、品質も保てない。



Q3.
  • 考え方の古い管理職をどう指導していけばいいか?
  • PO的に暖かく見守ってくれる人になってほしいが、どうすればいいか?

A3-1. 細谷さん
  • 相手がどんな価値観を持ってるかをよく理解する必要がある。
  • チームが活き活き働いて、成功して、自分が評価される、というのを嫌という人はあまりいない。
  • そこは共有できるはず。
  • でもアジャイルを提案すると「嫌」という人は、何かリスクを感じてるはず。そこを観察するのはすごく大事。
  • アジャイルをネガティブに思ってる間は、アジャイルに否定的である。でもポジティブに感じ始めると上手く回りだす。
  • 小さい成功をプロモーションするのが結構大事。
  • エンジニアはプロモーションあんまりしない。そうじゃなく、上手くいったことを伝えて、ちゃんと広げること。
  • チームメンバーのプロモーションも大事。お互いのいいところを口にだして共有すること。

A3-2. 西河さん
  • アジャイルは「やる」ものでなくて、「組織が成る」もの。
  • 「やりましょう」じゃなくて、「なりましょう」。
  • 作るものの価値を最大化することが最大の目的。
  • その価値を達成するための行動を定めているのがXPとかアジャイル。
  • 上司は説得するものではなく、なるもの。価値観を共有すること。
  • プラクティスから入るより、飴ちゃんを机に置くだけでもアジャイルは始まる。それだけでもほんわかするよね。

A3-3. 前川さん
  • オンサイト顧客でストーリーを書きましょう、というのと一緒。
  • 互いの価値を共有すること。

A3-4. 細谷さん
  • 急に変えれないことは、変えれない。
  • すぐに変えれることは、すぐにやればいい。
  • アジリティを高めていくことを際限なくやり続ける。
  • 今よりも少しだけアジリティを高め、実行して結果を出しましょう。
  • それをずっとやり続けること。


Q4.[失敗談、デメリット] 
  • なんでも変更を受け付けてきて、責任が曖昧になって地獄になることがあるが、どーすれば。

A4-1.
  • その機能ってホントに使うんですか?と踏み込むのがアジャイル。
  • やりたいことはいっぱいあるけど、機能的に、、提供時期までにホントに全部必要なのか?
  • その機能だったらリーズナブルにこの期間で届けられますよ、と導いていく。
  • お客さんの予算で最大の価値を届けるようにすること。
  • ストーリーの優先順位がシビアになることが多いが、優先順位を3つのカテゴリに分けるようにしている。
    • 1.法律違反とか、ぜったいやらないと存在しえない
    • 2.これやらないと価値がない
    • 3.その他
  • 優先度をA,B,Cと3段階に分けるのは良くない。優先度は主観が入るし、属人性がある。
  • 誰の目にも分かるように、「カテゴリ」に分類すること。
  • 優先順位を付けるのではなく、3つのカテゴリに分類してください、と持っていく。
  • カテゴリ分けをやっている間に、お客さんが優先順位に気づいてくる。
  • それを元に交渉して、プロダクトバックログに落としていく。

A4-2. 前川さん
  • 責任どーするの?と曖昧になることある。
  • 責任を取らないといけないのは、POとかマネージャ層。
  • POやマネージャに、チームメンバがひっきりなしに聞きに来るので、面倒くさい。
  • んじゃ、ドキュメントに書きゃいいじゃん。
  • 何のためにドキュメントを作るのかを書くこと。
  • アジャイルって面倒くさい。でも、メンバーが成長してくれれば良いと思う。


Q5.
  • 印税はいくらくらい?

A5.
  • 書籍の値段を下げるため、細谷さんと西河さんは印税を貰っていない。
  • 前川さんは、印税で家族を旅行に連れて行くという目的を最初に立てたので、少しだけ貰っている。
  • コンビニでバイトしたほうが儲かる。


お題
  • 書籍に「Smiling Adventure」という章がある。これは前川さんの案で書いた。
  • 「お客様は誰?」、「誰のために作ってるの?」という問いに、結構即答できないことがある。
  • 第一歩は「お客様は誰か」を把握すること。
  • 次に「そのお客様にとっての最大の価値は何か」を考える。
  • 何からアジャイルを始めたら良いかを考える際は、この2つの議論をチームで話すことから始めたらいいのでは。
  • お客さんのhappyを考えてそれを実現したら、あなたはどう思いますか?
  • そこまで考えるようになると、チームのモチベーションが変わってくる。

Q6.
  • 書籍を書いて良かったことは?

A6-1. 前川さん
  • 普段思っていたことを書けたこと。「読んでください」と言えるのが良い。

A6-2. 細谷さん
  • 「Fealess Change」という書籍に「モノを渡すことが大事だよ」という、「トークン」というパターンがある。
  • なので、形になってるのは偉大だと思った。

A6-. 西河さん
  • 日本のアジャイルってやっぱあると感じる。
  • そういうものを考えて、本に纏めるために深く考えることができたのが良かった。

---
Q&Aの一場面はこんなカンジ。

20140426_xpjugkansai1.jpg


■アジャイル和室

お昼休みに、別室に設けられている「アジャイル和室」にも行ってきました。
参加者の皆さんが「アジャイルかるた」なるものをやってました。

20140426_xpjugkansai2.jpg

読み上げるカードには「Redmine」といった単語と、その説明が書いてあります。
それを読み上げて、「R」のカードを参加者が探して取る、といった具合です。

20140426_xpjugkansai3.jpg


そういや去年は「アジャイル双六」でしたねぇ。
あと、コンセントを借りてPCの充電をさせていただきました。

こっから午後セッション。だらだらメモを書き起こしてみる。

■講演1 今日から始めようXP

稲田信平さん

■ そもそも、グローバルに働くとは?
  • 英語が出来ることではない!
  • 「どこでも通用できる働き方がグローバルな働き方」だと自分で定義している。

■ これからXPを始める方へ
  • 肩の力を抜く
    • IT業界のエンジニアって、みんな真面目で頑張っちゃう人が多い。
    • なので「それ以上はやらないで」と止めるようにしている。
    • やらないでいいことをやりすぎると、本来やらないといけないことができなくなる。
  • 常にアラートを出すようにしてもらう。
    • アラートを出さない人には怒るようにしている。
  • 教科書どおりにやらない
  • でも知識として知っておく必要がある。

■ ビジネスモデルの作成
  • ビジネスモデルを書いて、クライアントと方針を決めた。
  • ビジネスモデルはどんな立場でも書ける。
  • ビジネスモデルは、誰がどういうことをするかを掴みやすくする図。
  • 仕様変更って、プログラマの立場からするとピンポイントで来る。
  • それをピンポイントに修正しだすと、コードベースがぐちゃぐちゃになってしまう。
  • その仕様変更が正しいかどうかを判断するために、ビジネスモデルのどこに埋め込むのが正しいかを判断する必要がある。


■ 取り入れたXPのプラクティス
  • リファクタリング
    • ソースコードをチームで共有するためには、ソースを綺麗に保つ必要があった。
  • ペアプロ
    • ペアプロを応用して、リーダーと設計者で「ペア詳細設計」をやった。
    • プログラミング以外でもコミュニケーションをとって仕事をしてくれるようになった。
  • 朝会
    • 朝会でアラートを出してもらう。
    • デスマになる時は、独りで仕事や悩みを抱え込むことが多い。
    •  なので、アラートを出すタイミングは「朝会」の場であると指示していた。

■ 機能ごと設計・開発(ぜんぶ作らない)
  • まずゴールがあって、それまでにどんだけ作らないといけないかがある。
  • これを考慮しないと、一方だけ高機能で、もう一方が低機能、みたいになってしまう。
  • 必要なものから作る。

■ ハイブリッド
  • 全体計画はウォーターフォールで、どこをゴールとするかを決める。
  • 細かく計画、開発を繰り返す。
  • アジャイルとウォーターフォールの良いトコ取りをすると良いものができる。

■ WBSは無視する
  • WBSの順番でやって絶対できないことがでる。
  • 重要なのは問題点を洗い出して共有すること
  • まずシンプルに設計段階で切って回す。

■ XPをやってみた気づき
  • ペアプロは人によることが大きい。理解度とか教育とかでいろいろある。
  • いろいろな形態があり、それに合わせることが可能。
  • 捨てることが重要。
  • はまりすぎないこと。WBSがあったら、この期間中にやらないと!って背負っちゃう。
  • できないことはできない、やらないことはやらない、という勇気が必要。

■ コツ
  • 目標を立てて仕事しよう
  • 短期的な目標でもいい。
  • 早く帰りたい、休みたい、色んな仕事をしたい、etc
  • それをよりよくしようとそれを目的にしちゃうとそこにハマってしまう
  • XPのプラクティスを完全ゴールにしちゃうと良くない
  • 経験の積み重ねが重要。

■ グローバルって?
  • 何処に行っても通用すること。
  • 何処に行ってもパフォーマンスが発揮できること。
  • XPは、言語依存じゃない、国依存じゃない。
  • どこでも使える、その根底がXP。

■ 結論
  • グローバルにはXPは最高のプラクティス。

■ おまけ
  • 趣味を持ちましょう。
  • 人を作るのは仕事だけではない。


■講演2 ビジネスモデル・キャンバス入門

山中美智子さん

■ビジネスモデルって何?
  • どのように価値を創造し、顧客に届けるかを論理的に書いたもの
  • ビジネスモデルは営利企業とか以外でも、家庭とかでも使える。
  • 収益を上げ、体制を維持、発展させる活動を行うことに変わりはない。

■ ビジネスモデルを書く狙い
  • 見える化できる
  • 鳥瞰できる
  • 現在のビジネスモデルの分析と、新しいビジネスモデルの構築がしやすくなる

■ ビジネスモデルキャンバスとは
  • ビジネスモデルに必要な要素を1枚の絵に纏めたもの
  • 9つのセグメントに分かれている。
    • 1.顧客セグメント
    • 2.価値提案
    • 3.チャネル
    • 4.顧客との関係
    • 5.収益の流れ
    • 6.リソース
    • 7.主要活動
    • 8.パートナー
    • 9.コスト構造

そういや、アジャイルサムライ横浜道場の特別編でビジネスモデルキャンバスを書いたことがあったなぁ。
そんとき書いたブログはこちら。

横浜道場 特別編 「現場で役立つ(かもしれない)ビジネスモデル・キャンバスのワークショップ」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-106.html


■講演3 XP入門と導入の壁についての話

平田大作さん

■ ソフトウェア開発は設計
  • 「リーンソフトウェア開発」という書籍に、「ソフトウェア開発は試行錯誤を含む学習プロセス」と書いてある。
  • この言葉は衝撃的だった。
  • ソフトウェア開発は、完璧に計画可能な「製造プロセス」ではない。

■ ソフトウェア開発は複雑で難しい
  • ソフトウェアの構成要素は言語である。
  • 言葉は物理的制約を受けない。この制約の無さが捉えどころの無い複雑さを生んでいるのでは。
  • 逆に、建築とかは物理的な制約を受ける。
  • ソフトウェア開発は測定できない。
  • 建築だと材料力学とかあって、性質とかは実験して測定できる。
  • モノは決まった性質しか示さないが、ソフトウェア開発はそういうところがない。
  • WFでもXPでも、難しいものが簡単になるのではない。アプローチが変わるだけ。
  • 難しいものを相手にしていることを忘れないようにしよう。

■XPとは?
  • 5つの価値と12のプラクティスから成る。最近は12から拡張して19のプラクティスと言われる。
  • 5つの価値は、迷ったときの判断基準になる。
  • 何かに迷ったり複数の選択肢があった場合は、この5つの価値に照らして活動を選択する
  • 陥りがちな5つの価値
    • 1.ルール重視、ドキュメント重視
    • 2.機能を詰め込めばいい
    • 3.動くものは触るな
    • 4.波風を立てない
    • 5.権威

■ 計画ゲームと小規模リリース
  • イテレーションに盛り込むものを計画ゲームで決める。ここがキモだと思っている。
  • 試行錯誤と学習の機会を与えてくれる。

■ 小規模リリース
  • 2週間は、難しくても制御可能な期間である。タイムボックスを切る。
  • 計画ゲームが重要。
  • 計画ゲームはあまりしっくり来てなかったが、やってみると腑に落ちる。
  • 例えば前のバグの積み残しが後のイテレーションを圧迫すると、大変な開発になる。
  • こういったときに、イテレーションの前に計画ゲームを実施し、どれを入れるかをちゃんと決める必要がある。
  • 計画ゲームで負荷を制御する。
  • XPが「学習プロセス」というのは、イテレーションを繰り返すことによってどのくらいの難しさでどのくらいでできそうか、が段々わかってくる点にある。

■ テスト駆動開発
  • インタフェースを決めたらテストコードを書く。
  • テスト先に書くことで使い方の理解を得られる。
  • テスト駆動開発の注意点
    • テストコードの粒度を細かくしていると変更コストが増大する。
    • テストコードはインタフェース=Public Methodに対して書く。

■ ペアプログラミング、共同所有権
(1) 利点
  • リアルタイムレビュー、強制的コミュニケーション
  • 品質、実力の底上げ
  • ばらつきが減る
  • シンクロ率アップ
  • 人の流動に対してフレキシブルになる。
(2) 注意点
  • かなりの労力が必要。
  • 向き不向き結構ある。

■ その他の話題
  • 開発全体の計画は必要。
  • ドキュメントは考えたことを伝える手段として必要。文書化の手間はかかるので、wikiでも充分。
  • 保守用ドキュメントは別途作成が必要。 

■ 導入の壁
  • 「人の壁」の対策
    • 新人教育からXPを教える組織として変えていくのはこれがいいかなと思っている。
    • XPJUGに入ってもらう




■講演4 KPTによるプロセス改善~あなたはPDCAを回したことがありますか?

KPTによるプロセス改善~あなたはPDCAを回したことがありますか? from akipii Oga
  • KPTはCAPDから回すべし。
  • 自分の考えを共有するよりも、自分以外の人間に景色がどう見えているのかを認識することが重要。
  • コンフリクトが起きたらKPTを実施して、意識して「雨降って地固まる」プロセスを通過させよう。


今回の講演について、あきぴーさんがブログに書いてます。





■ライトニング・トークス

3名の方によるLTです。

■ @sakaba37 さん
リーダー諸君!アジャイル開発を学び未来への道を切り開こう(XP祭り関西LT) from Makoto SAKAI

5分の枠が、まさかの3分半で終了。
残り1分30秒あまりを埋めるのに苦労するさかばさん。。。


■ @Chuki さん
  • 「わんくま同盟」で活動中。
  • 「コタツモデル」というのが出てきた。


■ 開原さん
XP祭り関西2014 LT やってみよう!スクラ○ from Takahiro Kaihara
  • スクラムを社内に取り入れるためのノウハウに関するLT~


★感想:
去年に引き続き今年も東京から参加したんですが、東京と大阪のノリの違いとか随所に感じられて楽しかったです。
参加者にカメラ役を任せたりとか、最後のクロージングの西さんの振る舞いとか、関西なんやな~とw
いや、私も実家が大阪腑箕面市なんですけどね。。。

来年も参加できるといいなぁ。
スタッフ、参加者の皆様、ありがとーございました。

スポンサーサイト

SQLアンチパターン読書会 「インプリシットカラム」に参加しました

2014/4/25(金) SQLアンチパターン読書会 「インプリシットカラム」に参加してきました。

DoorKeeper
http://sqlap.doorkeeper.jp/events/10832

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。

参加者は13人かな。全員おなじみの方ばっかです。
この日は18章「インプリシットカラム」がターゲットでした。


■アジェンダ
今回は @setoazusa さんが発表担当でした。
Sqlアンチパターン読書会 インプリシットカラム from Hiroyuki Ohnaka



■ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。
20140425_sqlap1.jpg

以下、復習用の個人メモ。
---

■ 運用上がりのエンジニアとインプリシットカラム
  • オペレータとか運用担当者は、GUIのSQLコンソールでSELECT *を実行することに慣れている。
    • 最近のツールだと、Excelのようなスプレッドシートっぽく結果が表示される。
    • しかも、カラム数が多くてもGUIの右にスクロールすれば見れるし、レスポンスが遅ければ途中打ち切りもできる。
    • これに慣れた運用あがりのエンジニアさんは、アプリでもSELECT * としてしまう人が多いように感じる。
  • でも、SELECT * だと遅いということで、運用でも使わない派もある。
  • このへんは文化かもしれない。


■ RailsのActiveRecord
  • Rubyはメタプログラミングが強い。RailsのActiveRecordはSELECT発行時にSQLが2回走る。
  • 1回目はテーブル定義のメタデータを取得する。カラム名はメソッド名となり、メソッドを生やす。
  • 2回目に実際のデータをDBから取得する。
  • Rubyは動的型付け。DBにないデータもconcat関数やave関数を使えば作れるが、型がずれる。


■ カラム名と予約語
  • カラム名にcountと付けたらエラーになった・・・
  • あとは、classとかcontinueとかの予約語がカラム名に入っていて死んだことがある。
  • Cake PHPとかはSQLに予約語が入ってても、エスケープして発行してくれたりする。


■ Viewで逃げる
  • Alter Tableでカラムの追加や順番の入れ替えをした場合は、Viewを旧テーブル名で残す。
  • 表の構造を変更したのを知っているアプリは、新表にアクセスさせる。
  • 昔のアプリは旧表名のViewへアクセスさせる。
  • こうすることで、旧アプリがSELECT * でアクセスしていても、旧定義のViewに逃がすことで不整合を回避できる。


■ 仕様と実装の差異
  • JOINでカラムが重複してたときに、JDBCの仕様は先勝ちなのに、ドライバの実装によっては後勝ちだったりと異なる。
  • 大文字と小文字が混在している場合、SQL標準は大文字側に倒す仕様となっている。
  • ところが、PostgreSQLは小文字側に倒す仕様だし、MySQLは大文字と小文字の混在はそのまま扱う。
  • ちなみに昔、MySQLは擬似データベースとして呼ばれていた。仕様と異なるところ多いし。


■ 複数テーブル間でのカラム名の重複
  • 複数テーブルでカラム名は重複していても良い。
    • 今回の例だと、BooksテーブルとAuthorテーブルにtitleカラムがあるような設計はOK。
  • JOINを指定しつつSELECT * する場合は、ネームスペースが被っているんだからカラムが重複するのは当たり前である!
  • それはフレームワーク開発者が受け入れるしかない。
  • カラム名が重複してもSQLとしてはエラーにならず実行されてしまう点が手強い・・・
  • ORMはインプリシットカラムを自動で回避してくれる。
  • インプリシットカラムでハマるのは、ORMを使わずに手でコードを書く場合が多い。


■ カラム名による指定と、カラム番号による指定
  • SQLでカラム番号を指定してデータにアクセスするような場面はほとんど見ない。
  • アプリでは、カラム番号を指定してデータにアクセスすることはある。
  • JDBCはアクセス速度の都合上、カラム番号でデータを取得することを推奨している。名前解決が省略される分、高速。


■ PostgreSQL vs MySQL
(1) PostgreSQL
  • OSSのDBで、SQL標準の準拠率が最も高い。
  • Javaとの親和性が高い。
  • SQLは動的型付け言語であるが、PostgreSQLは強い型付け機構を持つ。
  • MySQLより高速。JoinはMySQLよりかなり速い。
  • 堅い運用に向く。疑わしきはエラーに倒す。
  • 透過フェイルオーバーが出来ない。クラスタ構成でサーバ側がコケるとロールバックできずに死ぬ・・・

(2) MySQL
  • だいぶ型付けが弱い。
  • 性善説で、曖昧なSQLをなんとか解釈して動作しようと頑張る・・・
  • 文字と数値が混在している場合は、文字っぽい箇所をDoubleにキャストするような変な挙動になる・・・
  • MySQL はスレッドモデルだが、PostgreSQLはプロセスモデル。
  • ちなみに初期のWindowsはCeeate Processが遅かった。プロセスモデルはプロセス生成のコストが重い。


■ SQLと正規表現
  • SELECT句にアスタリスクが使えるなら、SELECT句に正規表現が使えるようにしても良かったのでは?
  • いや、SQLに正規表現が導入されたのはだいぶ遅かった。
  • 正規表現がSQL標準に入ってから、SQLの文法が凄くデカくなって、パーサーを書くのが大変になった。
  • そんなで、SELECT句に正規表現は使えない。Drop table *とか出来たらヤバいよね・・・


■ DBのメタデータ
  • MySQL以外のDBMSは、メタデータをテーブルに保持している。
  • MySQLはメタデータを取得しようとすると、DB全体を舐め始める、なので監視してないと遅くなる。


■ JavadocのResultSetの説明は教育的?
  • JavadocのResultSetの説明に、列名が重複した場合について言及している。
  • java1.4は「列名を使用する場合、実際に目的の列を指すことを保証する方法がプログラマにはありません。」と書いてある。
  • Java1.4はツンな表現であるが、Java6は「一意にしたければAsを使え」と教育を始めている。


■ インプリシットカラムの解決策
  • インプリシットカラムはSQLの限界なので、他でカバーするしかない。「不要な列以外のすべての列」とか指定できないし。
  • 18.5節の「解決策」は、元々の目的であった「タイプ数を減らす」の解決になってない。
  • 列名を全部列挙したら、タイプ数って減らせない・・・。でも、これはSQLの限界なので、「そういうもの」として諦める。
  • SELECT句に列名をきちんと書かないといけないと、面倒くさいのでサボるようになり、本当に必要なカラムしか指定しなくなる。
  • これがパフォーマンスに好影響に傾く。(アスタリスクで全部取ってくるより、ネットワークの帯域とか減らせるし)



■終了後のお食事会
お食事会というか、今回はガチな飲み屋へ。
今回も木村さんのトークが炸裂して、みんなずっと大爆笑w








締めのお茶漬けにて。


これも皆でワロタw

★感想:
Select * の弊害について書いた章で、とてもシンプルです。
列の追加削除にアプリ側がついていけなくなり不整合を起こす問題と、パフォーマンスが悪化する問題と、弊害の観点は2つある点がポイントですかね。
とくに前者は、ズレに気づかずにアプリがたまたま動作しちゃったりすると悲惨です。。。
あと後者は、カラムの途中にLOB型があったりするとレスポンスが返ってこなかったり。。。
たぶん、参加者のみなさんもインプリシットカラムは一度は目にしたことあるんじゃないでしょうかね~
ということで、とても馴染みあるネタで付箋の数も多かったです。

今回で第Ⅲ部が終わり、次回の19章から第Ⅳ部に入ります。これも楽しみだ。
皆様、ありがとうございました。



■おまけ:過去の「SQLアンチパターン読書会」ブログ

1章:SQLアンチパターン読書会 「ジェイウォーク」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-65.html

2章:SQLアンチパターン読書会 「ナイーブツリー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-70.html

3章:SQLアンチパターン読書会 「IDリクワイアド」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-73.html

3章:SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-77.html

4章;SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-84.html

5章:SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-90.html

6章:SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-94.html

7章:SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-97.html

8章:SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-105.html

9章:SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-109.html

10章:SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-115.html

11章:SQLアンチパターン読書会 「ファントムファイル」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-118.html

12章:SQLアンチパターン読書会 「インデックスショットガン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-121.html

13章:SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-128.html

14章:SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-130.html

15章:SQLアンチパターン読書会 「ランダムセレクション」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-133.html

16章:SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-134.html

17章:SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-136.html

FC2Ad