SQLアンチパターン読書会 「続・IDリクワイアド」に参加してきました #sqlap

SQLアンチパターン読書会 「続・IDリクワイアド」
http://sqlap.doorkeeper.jp/events/3968

はじめに

今回は、前回の「IDリクワイアド」が終わらなかったので、その続きを行いました。
始まる前に@osa2さんが下調べをして下さったLTのお陰で後のディスカッションであまりブレずに出来たのではないかと思いました。
ありがとうございます。

ディスカッション

IDリクワイアドのアンチパターンで重要なことは「キー戦略」であることだと感じました。
@osa2さんのスライドで使われていた、達人に学ぶDB設計 徹底指南書の「第8章　論理設計のグレーノウハウ」にて代理キーを使うのはグレーノウハウであるということが紹介されていました。

USINGやJOINの使い方では、自分が普通だと思ってたことが、実はオプティマイザが進化してて別にその書き方じゃなくても大丈夫だということを知りました。
特定のプロジェクトやレガシーコードにしか携わっておらず、新しいことに触れる機会が少なくなるのは、プログラマにとっては損失ではないかと思いました。

日本特有の悪しきウォータフォールが蔓延り、実装段階でテーブルを増やしたり減らしたりすることが出来ず、設計の機会があったとしても論理設計を経ずに物理設計から始めてしまうため、こういった傾向に陥りやすいのかなと感じました。

おわりに

この勉強会は副読本があるとより実践に近いディスカッションが出来るということが実感しました。
次回の、「キーレスエントリー」は、ページ数こそ少ないですが、一般的にありがちなパターンだと思われるので、これまで紹介された本を読んでみたいと思います。

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

SQLアンチパターン読書会 「IDリクワイアド」に参加してきました #sqlap

SQLアンチパターン読書会 「IDリクワイアド」
http://sqlap.doorkeeper.jp/events/3774

はじめに

今回は、SQLアンチパターンでも言及の多かった「IDリクワイアド」でした。
個人的には、考えなしにIDつければいいやとなったことはなかったので、どのような状況になったら、このアンチパターンが発生するのかが知れたらいいなと思っていました。

ディスカッション

RDBMSに関しての様々なキーについてどのようなものがあるのかや、それぞれのキーをどのような場合に適用するのかを教えて頂きました。

また、このアンチパターンでありがちな場合は、某オフィススイートの表計算ソフトの考え方をそのまま適用してしまうためということでした。
個人的には、コードのサンプルなどでIDとしか振っていないテーブルを正しいと思い、テーブルにIDを必ず付けて使ってしまうのではないかと思いました。

画面から始めると、データの設計が蔑ろにされやすい。そのツケを長年支払うはめになる。 #sqlap
— とーますさん (@grimrose) 2013年5月9日

アプリケーションのコードよりDBのデータの方が寿命が長いので、気を配って設計しなければいけないということでした。
特に画面は変わりやすいのでそれを元に設計してしまうと、残念な意味での「継ぎ足された秘伝のソース」になってしまうのだなと学びました。

では、どんなモデリングをしたらよいか良いサンプルはなかということで、教えてもらったのがDatabase Answersです。

例えばTutorial on Beginning Data Modellingを見てみると、どのようにエンティティとリレーションが成り立っているのかが見えてきますし、Industry Data Modelsを見てみるとどこかで見たことがあるようなモデルがあります。
とても参考になるので、設計を始める前に似たようなモデルはないか探してみるのといいと思いました。

あと、IPAのデータベーススペシャリスト試験(DB)の午後2の試験についていろいろと勉強になるという話もあったので調べてみたいと思います。

おわりに

脱線は脱線でいろいろな話が聞けたのはよかったのですが、出来る限り内容に即したディスカッションが出来るといいのかなと思いました。

主催の@natsu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。

アジャイルサムライ読書会 横浜道場 「現場の状況を目に見えるようにする」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会　横浜道場　「現場の状況を目に見えるようにする」
http://yokohama-dojo.doorkeeper.jp/events/3455

はじめに

今回の通常回は、プロジェクトで使う「貼りもの」についてどのように運用したらよいかといった内容でした。

現在のプロジェクトは独りで行なっていますが、付箋を利用したストーリーボードを実施しています。
こうすることで、今日やるべきことと後どれくらいで終わるのかめどが立ちやすくなりました。

ディスカッション

壁に貼るものについて主にプロジェクトで使う言葉についてと、貼り物の真価についての内容が多かったように思えます。

特にプロジェクトで使う言葉については、間違えやすかったり、文字通りの意味を持たない場合など注意しなければならない言葉をピックアップして貼りだすのが良いのではないかなど、改善内容が多く出て来ました。

貼りものをすると顧客の目に触れる機会があると思うので、その場で分からなかったり新たに追加する内容等がすぐに反映出来るのが良い点ではないかなとも思いました。

おわりに

懇親会では、似た境遇の方に今までやってきたことなどを伝えることが出来たので、とても有意義な時間でした。

次回はの特別編は、新しい試みをするそうなので、楽しみです。

参加者の皆さん、横浜道場のスタッフの方々、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまた、よろしくお願いします。

『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加してきました #junitbook

『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編)
http://connpass.com/event/2270/

2013/05/12 『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) #junitbook
http://togetter.com/li/490112

はじめに

前回の写経・実践会のレポートはこちら→『JUnit実践入門』写経・実践会 in 横浜 #5 に参加してきました #junitbook
今回は、@irofさんの「テスト駆動開発を継続する」と、著者の@shuji_w6eさんのJUnit実践入門には含まれなかった幻の章についての講演とハンズオンでした。

テスト駆動開発を継続する

テスト駆動開発を継続する from irof N

テストの価値は失敗することにあるというのは、現在の状況と目的が一致している状態から変化があったことを分かりやすくしたものだと思いました。
アサーションを分かりやすく一つづつ実施することで、どの状態が意図している目的で、どうして目的に合致しなかったのか見つけやすくなるのかなと思います。
大きなオブジェクトの状態を確認しようとするとアサーションの行が増えますし、本当に確認したいことが埋もれてしまっては、元も子もないと思います。
設計を見なおしたり、リファクタリングをする際に、目的の状態になっていることを確認するためのテストを書き、その状態を維持しつつ小さく分かりやすいテストにしていくことが重要なことだと感じました。
そういった小さいテストを継続的に積み上げることで、ひとつの変更が影響する範囲を視覚的に捉えることが可能になるのではないかなと、思います。
小さいテストであれば、わざと目的通りのRedにした場合でも、意図している動作であるか確認しやすいのではと思いました。

ハンズオン

後半は、@shuji_w6eさんの「受け入れテストの自動化とユースケース駆動開発 -Pre Cucumber Boot Camp-」と「cucumber + selenium」による受け入れテストのハンズオンでした。

元々はmavenとeclipseを対象にしたプロジェクトでしたが、IntelliJ IDEAとGradleでやってみようと思い、前日にGradle 1.6のBuild Setup Pluginを利用してbuild.gradleを作っておきました。



無事、IntelliJ IDEAでもcucumberを使えるようになりました。
また、h2databaseやjettyについてもtaskを追加しておいたお陰で、コマンドを実行するだけで起動や初期化が出来るようになりました。

途中でフィーチャファイルの補完が効いてないのかなと思いました。

#junitbook 日本語だとあまり補完が効かないのかな… Cucumber jetbrains.com/idea/webhelp/c…
— とーますさん (@grimrose) 2013年5月12日

が、IntelliJ IDEAを12.1.2から12.1.3に上げて見たところ、シンタックスハイライトとコードジャンプも出来るようになりました。
さすがJetBrains様です。

なんとか、ハンズオンの進行に付いていくことが出来ましたし、seleniumの残念な箇所も体験することが出来ました。
前回のBDDにてイマイチ使い所が分からなかったcucumberも、seleniumと組み合わせることでどうやって使ったら良いのか体験することが出来たのは良かったと思いました。

おわりに

懇親会では、@enumさんも参加して下さり、とても楽しい充実した時間でした。

今回のハンズオンは、プレと冠していましたがとても実践的でスタートラインまで連れて行ってもらえる内容でした。
今後は、どうやってシナリオを書いて行ったら良いのかなど、教えていただいた書籍を参考にやってみようと思います。

また、GroovyではGebがあるので、これとSpockを組み合わせることで、seleniumの残念な箇所をカバーしてくれて、なおかつシナリオもコードで書けるようになるので、同じ課題を挑戦してみたいと思います。

講師の@irofさん、著者の@shuji_w6eさん、主催の@shinyaa31さん、参加者の皆さん、会場の横浜タネマキさん、ありがとうございました。

残りの章も少なくなって来ましたが、次回もよろしくお願いします。

ゆとりを持って行動するには #yutori_history

はじめに

これは、ゆとり Advent Calendarの8日目のエントリーです。
7日目は@backpaper0さんのStateful Session BeanはたぶんSerializableをimplementsしなくて良いと思うような気がしなくもないでした。

初めてお会いしたのは、確かTDDBC横浜の初回だったと思います。
懇親会で同じテーブルで話してたのを覚えてます。

ゆとりをもって行動する

ゆとりとは、「物事に余裕があり窮屈でないこと」だそうです。
普段のスケジュールを立てる場合、交通事情だったり、生活リズムや癖を予め考慮している方がほとんどだと思います。
また設計や開発にのスケジュールでは、バッファーを積んで見積もりを出したりすることが多いと思われます。
で、よく聞かれるのが、「パーキンソンの法則」ですね。いわゆる、時間ギリギリまで使いきってしまうというアレです。
詳しい内容はググっていただくとして。

私自身、怠惰で、時間にルーズな面があるので昔からゆとりをもって行動しろと言われてきました。

今でもまだやらかしたりするのですが、昔に比べて楽になったなと一番感じるのは、アラームを複数持ち運べるということです。
スマホであれば、アラームアプリを複数インストール出来ますし、サービスを利用することで何かしらネット経由でActionを起こすことが出来るようになりました。
あとは、タイムアタックの感覚でどこまで縮めることが出来るのかチャレンジするのも、楽しいと思えるようになりました。

銃夢のゲルダが、ありのままの現状を受け入れ、自分の位置を確保することが大切だ。みたいな事を言ってたと思うので、時間に限らず、現在の状況と目的までのギャップを認識出来るかが、ゆとりを持つ鍵なのではないかなと思っています。

お金でゆとりを持つのは、いろいろと難しい面もあると思いますが、時間であればお金よりも能動的にコントロールしやすいのではないかなと考えているので、他にいい方法とかあれば、取り入れてみたいですね。

おわりに

アルコールが入った状態で何かしらポチるのは、止めたほうがいいですね。イベント参加ボタンとかAmazonとか。

#ゆとりさんおめでとうございます twitpic.com/cma6a6
— とーますさん (@grimrose) 2013年4月27日

転職おめでとうございます。新しい職場で一歩でも前に進んでください。

9日目は@y_uuk1さんのゆとりbotで学ぶ転職の極意 #yutori_historyです。
よろしくお願いします。

SQLアンチパターン読書会 「ナイーブツリー」 に参加してきました #sqlap

SQLアンチパターン読書会 「ナイーブツリー」
http://sqlap.doorkeeper.jp/events/3682

はじめに

前回のレポートはこちら→SQLアンチパターン読書会 「ジェイウォーク」 に参加してきました #sqlap
今回は、「ナイーブツリー」ということで自分自身経験した内容が話せればいいなと思い、参加いたしました。
ツリー構造に馴染み深い掲示板に関する事を自己紹介と併せて話しましたが、ニフティサーブから近年のSNSまで幅広く、世代というものを実感しました。

ディスカッション

アンチパターンを使っても良いとして上げられたCTE(共通テーブル式)が使えるDBであれば、シンプルでテーブルも少なくて済むということでした。
今回の解決策として上げられた3つのパターンについてですが、経路列挙モデルの場合、DBによっては型が用意されていたりして人間にも扱いやすいのですが、デメリットとして前回のジェイウォークに当てはまってしまうので、アプリケーション側で制約を守るようにしなければならないことです。
次に入れ子集合モデルでは、データの変更より参照が多い場合に使われることが多く、ORMによってはプラグイン等でサポートしているものもあるそうです。
デメリットとしては、ツリー構造の欠損等が発生した場合、人間で修正するのがとても難しいということです。
閉包テーブルモデルでは、入れ子集合と同様に変更より参照が多い場合に利用する場合が多く、2つテーブルを利用することがメリットでありデメリットでもあるということでした。
ツリー構造のスケールによってどのモデルを採用するかを検証し、コストに見合ったものを選ぶのが望ましいのではないかと思いました。

私の場合、組織階層を表現する方法として経路列挙モデルを採用しました。対象となる組織の階層も深くなく、横の広がりもそれほど大きいものでは無かったためです。
経路列挙のデメリットとしてはジェイウォークと同様にインデックスが使えないことです。ですが組織の数そのものが少ないため、デメリットがそれほど目立ちません。
もし今後階層がもっと深くなったり、横に広がるような場合は、残りのモデルやCTEを検討する必要が出てくるかもしれません。


今回のツリー構造をRDBMSでどのようにしたらよいのかについて、@t_wadaさんからJOE CELKO氏が書かれた本を紹介して頂きました。
1冊まるごとツリー構造について書かれた本らしいので、もう少し巨大なツリー構造に立ち向かう前に読んでみたいと思いました。

#sqlap プログラマのためのSQL 第4版 ジョー・セルコ amazon.co.jp/dp/4798128023/… @amazonjpさんから
— とーますさん (@grimrose) 2013年4月25日

同じくJOE CELKO氏が書かれた本として上記の本があるそうなので、こちらの本も取り寄せたいと思います。

#sqlap 監訳注SQLアタマアカデミー：第6回　SQLで木構造を扱う～入れ子区間モデル　（1）もしも無限の資源があったなら#gihyojp bit.ly/LI82s0
— とーますさん (@grimrose) 2013年4月25日

入れ子集合の監訳注にあった入れ子区間モデルは、ここが参考になると思います。

おわりに

次回の「IDリクワイアド」は、ORMとの関係でいろいろと物議を醸した章なので、楽しみです。

主催の@natstu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。