2012/8/30(木)「DBリファクタリング読書会 第三回」に参加してきました。
Atnd（告知ページ）
http://atnd.org/events/31517以下の書籍をターゲットとした読書会なのです。
ただ読書会といっても、みんなで集まって本を読むのがメインではなく、DBリファクタリングに関する発表や座談会が中心です。私は第１回から参加してますが、今日が第３回の開催でした。
会場は日本オラクル青山センターです。
３回目の参加なのに今日初めて知ったんですが、オラクルの真ん前に神宮球場あったんですね。。。
ちょうどヤクルト戦が開催されてて、ラッキー７のイニング合間だったのかどうかよくわかりませんが、球場の近くから花火が盛大に上がってて、それをみんなでオラクル13Fから眺めてました。
あと当日の様子のブログは、他の方が既に数名、詳細に書いてくださっていますので、そちらが参考になるかと思います。
私も自分への覚書として、当日とったメモを元に、感じたことを思いつくまま書いてみようと思います。
自分なりに後で纏めてみる事、情報の整理や知識の定着の観点から、きっと大事。
開会の挨拶 （
@do_aki さん）
「PHP Apocalypse」というイベントが、この読書会を始めるキッカケだったそうです。
ググってみたら、
Atndの告知サイトとか見つかりました。なるほど、こんなイベントだったんですねー
実際に読書会を立ち上げた行動力は、ともて素晴らしいです。おかげで今日の読書会に参加できるわけだし！
スポンサーセッション （
@yokatsuki さん）
いつも素晴らしい環境を提供してくださる@yokatsukiさんからのご挨拶です。以下メモ。
■Oracleで研修講師を担当されているとのこと。
■研修を受講する人は、一部の限られた人である。またOracle製品ありき、で受講しに来る。
■そういうのではなく、もっとオープンに技術力を育成する機会が作れないか？と考えた。
■アイデアとして、せっかく自分がOracleに所属しているのだから、その特典としてOracleのフロアを使用することを考えた。
■技術力を高める活動に今後もかかわっていきたい。
■良いアプリを使って良いサービスを提供していく取り組みに参加していきたい。
---
素晴らしいですね。いつもマジ感謝です！
講演 （
@daisuke_m さん）
@daisuke_mさんがOSSとして開発しているデータベース設計・リファクタリングサポートツール「Jiemamy」の講演です。
ちなみに私、入社以来かれこれ「日経ソフトウェア」という雑誌を8年くらい定期購読してて、毎号読んでます。んで、@daisuke_mさんの連載や記事が、日経ソフトウェアによく掲載されているんですよねー。かなり読みやすい内容に纏まっていて、いつも読んでました。
以下、講演のメモです。
---
■「データベースの進化的設計」に関する記事を2008/9に@ITに書いたとのこと。（ググってみると、↓がヒットしました）
Jiemamy作者が考える “データベースの進化的設計” データベースもアジャイル開発に対応したい！■データベースの進化的設計
ちなみに、↑に出てきた「データベースの進化的設計」ですが、
原文は英語です。
なお今日の出席者でもある
@t_wada さんが日本語に訳されています。
コチラ （ ちなみに、この読書会の初回の講演者は @t_wada さんでした。そこでもお話ありましたね）
■「データベースの進化的設計」をサポートするツール、
Jiemamy（じーまみー）をOSSとして開発していた。
（ただ、対象範囲を広げすぎて回らなくなったそうです。１年くらい何もしてない状況とのこと）
■Jiemamyの設計思想
(1) Smart Model ： DB構成情報を１つに集約する。
(2) Smart Version Control ： データファイルをVCS(Version Control System）で管理する。
(3) Smart Build ： ビルドフェーズでDBを整備する。
以下、詳細に見ていく。
■(1) Smart Model
① DBの構成情報を知っている唯一の存在を作る。
② この情報を元に、DDLとかを自動生成する。
■(2) Smart Version Control
① 開発現場では、ソースはSubversionとかで管理しているのに、SQLはなぜかファイルサーバとかで管理されてることが多い。。。
② SQLとか、他の定義情報もバージョン管理する必要がある。
■(3) Smart build
① Mavenプラグイン
■(4) Smart deploy （現在考えている、やってみたいこと）
① デプロイ時に、自動的にDBを変更する。（alter table文の発行）
② ちょっと怖い。。。どうすれば良いか。。。
■Jiemamyの設計にあたって
① データファイルはVCSにコミットして、diff/mergeできるべき
② データファイルからDB環境を自動で構築できるべき
③ スキーマだけでなくテストデータも管理できるべき
④ 多くのRDBMSで使えるべき
⑤ 外部システムからJiemamyを使えるAPIを提供すべき
⑥ DB変更内容を検知してAlter文などにマッピングできるべき
⑦ データアクセスコードもリファクタリングに追従すべき
■↑で実現できたこと／できてないこと
① データファイルはVCSにコミットして、diff/mergeできるべき
→ できた。diff比較するにはバイナリ不可。XMLにして、EclipseでもXMLタグ補完できるようにしたい。
⑤ 外部システムからJiemamyを使えるAPIを提供すべき
→ できた。
⑦ データアクセスコードもリファクタリングに追従すべき
→ 実現できそうで手が届かない。２つのDB状態をcompare/diffするアルゴリズムが大変そう。
→ DB変更モデルを作るのが、できそうでできてない。
■困難なこと
① 保存形式互換の維持
バージョンアップでXMLの保存形式を変えると、前のバージョンのデータが死ぬ。。。
② マルチDB対応
ムズい。。。各々のDBMSのSQL文法がフリーダム過ぎ。NUMBER型とか、何だよ！
③ 自動変換追尾
テーブル分割などの破壊的変更時に対応できない。。。
④ 変更管理場所
DBのスナップショットを取るタイミングが難しい。。。
どの状態がコミットされた状態なのか、判断が難しい。
■Jiemamyの開発が止まった理由
① 静的型付きへの追従
→ エラーはコンパイル時に全部発見してやろう、みたいな。。。
② OO（Object Oriented: オブジェクト指向）による再利用の幻想
③ クライアントアプリはWebアプリとは違う
→ ドメイン駆動設計（DDD）を適用した。が、Repositoryパターンは無理。。。
休憩時間中のLT （
@hayamiz さん）
■データベースの歴史を記した本を作って、コミケで売ってみた。１時間半で70部が完売した。
The Database Times vol.1■今日の読書会でも10部を販売 → 完売！
■東京大学の博士課程で、DBについて研究しているとのこと。（すげー）
---
こーいうネタでコミケに参加するという発想は斬新で、驚くと共にマジ関心しました。
いやー、コミケという場でも、こういうOutputの手段があったのかー。。。
座談会座談会でネタにしたい内容を各自がポストイットに書き込み、ホワイトボードに貼りました。こっからスタートです。
■DBAってPJに存在しているか？
→ アプリ開発する人がDB触っちゃうことが多い。
→ 大きいPJだと、基盤チームとかがあって、そこがDBを管理することが多い。（ウチの会社のPJも、大半がそう）
■早く止めるアプリやサービスに、DBリファクタリングは必要ない。
■アメー○ピグは、MongoDBを使っているらしい。
■「不吉な臭い」（前回の2章ネタでもある）があったとしても、DBのリファクタリングを始めるかは別の話。
■システム障害が発生してDBをリファクタリングした経験がある参加者さんがいらっしゃった。
(1) 障害背景
NOT NULL制約を付けておくべきカラムにNULLを許した設計にしてしまい、インデックスが効かずに性能劣化。。。
(2) テストはというと。。。
テスト段階ではデータ件数が少なかったので、性能問題は顕著化しなかった。（いわゆる潜在バグの状態）
■迅速な経営判断を可能にするために必要な情報を整備する必要があり、経営層がトップダウンでDBリファクタリングを推進した事例がある。（ただしこのような事例は稀）
■DBMSのMは、ManagementのM。本来、DBの管理情報はDBMS自身が保持し、DBMS自体がDB構造をManagementできるべき。
→ Jiemamyが第三者としてDBMSの管理情報を持つ時点で、DRY（Don't Repeat Yourself）の原則が崩れているのでは？
→ SQLの海面下で各DBMSが管理しなければならない現状がある。
→ DBMS自体にスキーマのログを持たせることも可能。
ただ、DB自身が保持している情報にアクセスするインタフェースが無い。
■DBの構成情報を見たからといって、DBを前の時点に戻せるとは限らない。
→ 例えばOracleにはフラッシュバック・データベースという機能があり、時間の単位でDBを元に戻せる。
ただし、その時点から発生したデータは消えてしまう。
（cf. フラッシュバック・データベース：
http://www.oracle.co.jp/2shin/ora79/16_17.html）
■本質は、スキーマとデータは密接に関連している。分けるべきではないのでは？
■テーブルを統合した後、分離して戻そうとした時に、データを元どおりに分けられずハマった。
→ データレベルで見分けがつくようにしておくことが大切。
■リファクタリングでは、「いつでも元に戻せる」ことが重要。少しずつリファクタリングする。
ただ、「開発効率」と「実行効率」は違う点に注意が必要。
(1) 開発効率：
開発では少しずつリファクタリングして進めるべし。（Small Step）
そうしないと何してるかわからなくなって、死ぬ。。。
(2) 実行効率：
少しずつリファクタリング、では時間がかかる。
プロダクションに細かくマイグレーションするのは、実際は難しい。
プロダクションへ適用前にマイグレーションをsquash（※）すると良い。
（※）
squashという単語、恥ずかしながら今回始めて聞きました。ちょと調べた限りではGit用語のようで、
「ブランチの修正した内容すべての変更を取り込む」ことをするときに使うようです。
(いつもはSubversion使ってるので、Gitはgit cloneくらいしか使ったこと無い。。。）
■データベースリファクタリングの移行期間は、ビュー（View）を緩衝材として使うことで解決することが多い。
・参照系テーブルなら大体いける。
・更新系テーブルだと、難しい。。。
■本番と同じサンドボックス環境を持っているPJって、これまでありましたか？
→ 誰もいない。。。
→ 最近ではクラウド環境を用意することで、ハードを購入せずとも本番と同じサンドボックス環境を
一時的に持つことは可能になった。（金で解決できる時代になった）
■データベースリファクタリングの移行期間に、開発が終了したようなほとんど使われていないアプリから、移行前のテーブルにアクセスしてくることがないかを見極める必要がある。
→ DBリファクタリングでは、メンテされてないアプリやDBの存在が問題となる。
そもそもメンテされてない場合は管理者がおらず、話す相手がいないので調整さえできない。。。
■Oracleの場合、データベースを統合するとライセンスが安くなる。これがDBリファクタリングのキッカケになることもある。
懇親会同じ場所で、引き続き懇親会です。
とはいっても、今日は読書会開始の最初からピザとビールが来て飲み食いしながらの進行でしたので、改めて懇親会が最後にあったというよりも、座談会に引き続き参加者さんと交流する時間が取られたイメージでした。
私も数名の方々とお話させていただいたのですが、@t_wadaさんと@daisuke_mさんと直接会話する時間が持てなかったのが少し残念でした。（恐れ多かった、というのもある。。。）次回以降にとっとこう。
今回も大変有意義な時間を過ごすことができました。
主催者様、運営者様、会場提供様、発表者様、皆様いつもありがとうございます。
次回も楽しみにしてます。
以下、ツイート一覧です。
2012/8/19(日) 「第3回 スタートHaskell2」に参加してきました。
PARTAKE
http://partake.in/events/b531758c-3fed-43fb-a71f-6edbc2cbb9b4以下の書籍をテキストとした、セミナー形式と演習形式を組み合わせた勉強会なのです。
夏休みで１１日（土）から大阪の実家に帰省してたんですが、今日の朝、新大阪駅発の新幹線で東京に戻ってきて、そのまま直行です。
あ、ちなみに私、新幹線は必ず窓側の席を取るようにして、ずっと外眺めてます。
夏の日差しの中、いろんな町の風景を新幹線の中から眺めていると、すごく旅してる気分になれるのです。
窓側の席に空席が無い場合は、出発時刻を多少遅らせてでも窓側を取ります。
でも、長距離移動後に長時間の勉強会は、さすがに疲れました。。。 荷物は重いし、座りすぎでマジ肩凝ったわ～
---
さて、今日は第６章と第７章が対象範囲です。
前半２時間がセミナー形式で上記２章分の発表、そして約２０分の休憩後、約２時間半の演習＋ＬＴ発表がありました。
● 第６章「モジュール」第６章「モジュール」の発表の担当は
@aomoriringo さんです。
@aomoriringo さんとは、別の勉強会で一度会話したことあったはず。。。多分。
たしかそんときは、ルービックキューブの会話をした覚えがあるんだけど、違ったかな。。。？
自分への覚書のため、６章で気になったフレーズを羅列してみます。
■ :m - でインポートを解除できる。（例： ghci> :m - Data.List）
■ Haskellのモジュールを調べるのに、
Hayoo!というものがある。
（HackageとHoogleは知ってたが、Hayoo!は知らなかった。検索エンジンのGoogleとYahooを意識したネーミングですね。。。）
■ Hoogleは標準モジュールだけ検索できる。Hayoo!だと標準モジュール以外も検索できる。
■ C言語とかだとcharは１バイトだが、HaskellのCharはUnicodeなので４バイトらしい。
■ import Foo () みたいな書き方はインスタンス宣言だけをimportするときに使う。
■ foldl'でも第一引数の関数が遅延評価するとき、スタックオーバーフローとなることがある。
■ module構文でエクスポートする関数を明記することが推奨されている。なぜなら、GHCが最適化して速くなることがあるから。
■ 複数のMainが定義できるように、Mainモジュールのみファイル名と一致しなくてもよい。
モジュール名を省略した場合はMainモジュールと見なされる。
■ import文が多いコードは、1モジュールに機能を詰め込みすぎな臭いがする。分割してimport文を減らすのが良い。
● 第７章「型や型クラスを自分で作ろう」次の第７章「型や型クラスを自分で作ろう」の発表担当は
@a_hisame さんです。
@a_hisameさんは前回の
TaPL読書会終了後の飲みで、向かいの席でした。
そのときの会話で、出身大学がお互い近くであることがわかったこともあり、親近感がありますね。
今日の発表は図を駆使して、わかりやすく説明しようという姿勢が随所に見られ、とてもわかりやすかったです。
@a_hisameさん曰く、
「型って癒されますね！」 自分への覚書のため、７章で気になったフレーズを羅列してみます。
■ 型引数Eitherで、Rightは「右」と「正しい」の両方の意味を兼ねている。
モナドを学ぶと、この定義が上手くできていることが良くわかる。
■ Bool, Maybe, Eitherは、
左が「間違い」で
右が「正しい」という定義になっている。
・data Bool =
False |
True deriving (Ord)
・data Maybe a =
Nothing |
Just a ・data Either a b =
Left a |
Right b deriving (Eq, Ord, Read, Show)
前半２時間の発表が終わり、２０分の休憩後は演習＆LTの時間です。
● LTその１ 「再帰の俯瞰図」最初のLTは
@kazu_yamamoto さんの「再帰の俯瞰図」です。
↑ クリックすると発表資料（PDF）に飛びます ↑
自分への覚書のため、このLTで気になったフレーズを羅列してみます。
■ 再帰には「末尾再帰」と「一般的な再帰」の２種類がある。
■ 末尾再帰の場合、= のすぐ右に自分自身の関数が来る。（例：gcd a b
= gcd b (a ‘mod‘ b)）
■ 末尾再帰はループと同じ力を持つ。（ループで書けるものは末尾再帰で書ける）
■ ループはスタックを消費しないので、末尾再帰もスタックを消費しない。
■ ループで書けるようなコードなのに一般的な再帰になっている場合は、
引数を増やすことで末尾再帰にできる。
■
一つ前ができたとしたら次はどうする？と考えることが再帰のポイント。
■ 面接に出る一般的な再帰！
・コインの両替問題
・二分木のパターン数 (カタラン数)
→ 両方とも知らなかったので、この機会に調べておこう。。。
■ なるべく力の弱いものを使うべき。 （↓の力関係がある。右ほど弱い）
再帰 ＞ 畳み込み(foldr/foldl) ＞ 単純な高階関数(map/filter)
● LTその２ 「Haskell 学習者の FAQ」もう一つのLTは
@igrep さんです。
@igrep さんがが壇上でHaskellに関する質問を発表し、それを上級Haskellerに答えていただく、という企画で、
名づけて
「Haskell 学習者の FAQ」です。
こちら →
http://wiki.haskell.jp/Workshop/StartHaskell2/FAQLTの結果を踏まえ、上記に正規表現ライブラリやCabalに関する質問と、
@kazu_yamamoto さんによる回答が纏められています。
---
LTの他に、今回は演習問題を解く時間が2時間ほど確保されました。
● 演習問題１． 前述の、@a_hisame さんの7章の発表スライドP.46から「木の最大の深さを求める関数の実装」
２． 初代「スタートHaskell」の演習「再帰の練習問題」
https://github.com/yuzutechnology/Community-StartHaskell2011/blob/master/exercises/recursion/recursion-ja.lhs３．リストの要素で、自身と自身のひとつ前の要素が与えられた条件を満たすものだけを 返す関数の実装（問題２）
https://github.com/yuzutechnology/Community-StartHaskell2011/blob/master/homework/homework02/Homework02-ja.md---
１．は、すんなり解けませんでした。解答を見ると、あぁなるほどなぁー、と思うんですが、パッと実装できない。。。
２．は、前回のLTの文芸的プログラミングを使用したTDDベースの演習問題です。私は、12個か13個くらいの問題をといたところでタイムアップとなりました。
３．は、演習時間内にやれる余裕がなかったので、時間があれば今度見ておこう。
---
今日の勉強会も大変有意義でした。
主催者さん、運営者さん、いつもありがとうございます。
次回も楽しみにしてますー
当日のツイートまとめです。
8/9(木) "ギークのターニングポイント ～『踏み出す』すべを、彼らに学ぶ～"に参加してきました。
Atnd
http://atnd.org/events/30788今日の勉強会は、
「3名のギークな著名エンジニアの方々のパネルディスカッションを通して、エンジニアのキャリアを考える勉強会」という位置づけだそうです。
ちなみにwikipediaによると、
ギーク (geek) とは「卓越した知識があるということを指す」そうです。
会場は
渋谷ヒカリエの21Fセミナールームです。JR渋谷駅から2F通路で直結とは、なんと立地の良いことか。
建物もキレイで、しかも高層！
出席者は、180名程でしょうか。セミナールームも大きくて、投影スライドが３つもありました。
登壇くださった3名のギークなエンジニアは、以下の方々です。
各エンジニアさんの紹介は、
Atndに詳しいのが掲載されています。各エンジニアさん、相当ご活躍されてるようですねー
最初に、3名の登壇者がそれぞれギーク年表をベースに自己紹介を行いました。
3名のギーク年表は、とても興味ありました。ギークに踏み出した一歩はどのタイミングだったのか、
踏み出したキッカケはなんだったのか、そこが今日知りたいポイントの１つでした。
その次は、パネルディスカッションです。いくつか事前に用意されたテーマから、A,C,Cの3種のテーマをメインにディスカッションが行われました。
登壇者の発言を
@town_bさんが随時ツイートし、togetterに纏めてくださっています。
こちら以下にも貼り付けておきます。読み直してみても、心に響く言葉が非常に多いです。
自分への覚書を込めて、以下に気になったフレーズを羅列してみます。
■A. 踏み出したエピソード・
ワクワク感が踏み出させる源泉。
心は嘘をつかない。
・
ワクワク感を感じた時が踏み出すタイミング。
・職場に行きたい、と感じたら、ハマっている証拠
・飽きとワクワクのバランスをどうとるか？
→ 好きなことをやってれば、飽きっぽくても飽きない
・モヤモヤは自分の中にある。解消するためには、行動が必要。（行動に半歩近づける）
・
迷ったらやってみる。 → 自分の選択で失敗したなら納得できる。
・
迷ったら危険な道を選べ！ by 岡本太郎（芸術家）
・
年齢に関係なく、チャレンジする。・今やらなきゃ後悔する、と未来の自分が語りかけた。
・たとえ年をとっていても、
若い人が学ぶ以上に早く学べば先に行ける。・過去の成功をどう否定して先に進むかが重要。
■C. 仕事術について・仕事を取るのは、人脈がモノをいってる。
・自分がやりたいコトがあっても、日々のルーティンワークを続けると、自分のやりたいコトが薄れていく。。。
→ 後で振り返って、ハッと気づく。
・
面白いコトが社内で聞こえてきたら、自分から聞きに行く。自分から情報を取りに行く。・人脈を持ってる人に図々しく近づくと、人脈が広がる。
・気になった人には声をかけちゃう。
■D. スキルアップについて・興味があれば、実際にやってみる。
→
読んだだけで学んだ気になるのはダメ。
・忙しいと、短い隙間時間の集中力がすごく増す。
→ 時間をうまく使う気持ちが強くなる。
パネルディスカッションの後は15分ほど質疑応答の時間がとられ、21時でいったん終了となりました。
んで、21時からは同じ場所で引き続き懇親会です。
ビールと軽食が提供され、立食パーティー形式でお酒と軽食をつまみながら登壇者や来場者同士で交流する時間なのです。
私も何名かの方と名刺交換をして、いろいろお話をしてきました。
やはり社外のエンジニアさんの話を聞く時間というのは非常に貴重で有意義ですねー
登壇者の武部さんと白石さんとも名刺交換して直接会話する機会がありました。とても刺激になります。
吉岡さんとは直接会話する時間が取れなかったのが少し残念でしたが、また次の機会にとっとこう。
---
私のブログ初日にも書いた「チャレンジに年齢は関係ない」というフレーズ、登壇者も同じくおっしゃっていたことが、とても印象深かったです。
私も、夢中になれる何かを見つけ、一歩を踏み出したいと強く思う一日でした。
2012/8/1(水) 「TaPL読書会 第2回」に参加してきました。
PARTAKE
http://partake.in/events/b780846c-bfd0-412a-bd1e-3f9afd02fab3読書の対象書籍は「Types and Programming Languages」です。ハードカバーで全623ページ。すごく、重たいです。。。
場所は
前回と同じく、株式会社ワークスアプリケーションズの1Fラウンジです。
今回は、3章の演習問題を参加者が発表するセッションと、5章の内容を
rf0444 さんが発表するセッションの、2本立て構成です。
私も、3章の演習問題としてExercise3.5.10の発表を担当しました。
実は、Exercise3.5.10って3章の演習問題の中で、一番簡単なんですよね。。。
参加者さんがそれぞれ発表・解説した内容は以下で公開されています。
http://wiki.haskell.jp/Workshop/tapl/2うむぅ、Exercise難しいです。。。復習しなきゃ。。。
今回はExercise3.5.13の解説までで1時間経過しましたので、3章の残りのExerciseは次回に回すことになりました。
んで残り1時間は5章の発表に当てることになりました。5章の発表者は
rf0444 さんです。
5章はλ計算が出てきます。まず5章で最初に躓くトコは、Church Booleanではないでしょうか？
tru = λt.λf.t;
fls = λt.λf.f;なぜそもそもBooleanをこのように定義すべきなのか、最初は本読んでてサッパリでした。。。
truは2つの引数を受け取って1引数目を返す関数であり、flsは2つの引数を受け取って2引数目を返す関数、という定義ですよね。
なぜこの定義が真偽値を表せるのか？について、今日の発表でも議論がありました。
それによると、真偽値の定義は、これ以外にも有り得るとのことでした。（ただしこの定義が一番シンプルみたい）
また、AndやORの論理演算を実際に手を動かして計算してみることが、この定義を理解するのには有効とのことです。
・・・ふむふむ、ナルホド～。
やはり有識者さんからこーゆうコメントをいただけるトコが非常に有意義ですね。
自分の理解が曖昧だったトコを解決できるチャンスがあるというのは、素晴らしい！
んで、この日はP.60のChurch Booleanまででタイムアップとなりました。
次回はChurch Numeralsから引き続き進むことになります。
読書会の終了後、今回は懇親会にも参加してきました。
懇親会といっても、平日なので近くの中華料理店に軽くご飯を食べにいくようなカンジです。
出席者は主催者さん3名くらいと、参加者4名くらいの、計7人くらいだったかな？
餃子とチャーハン、おいしかったです。あとビール！これだけ暑いとおいしいですね～。
あと、やっぱ社外のエンジニアさんといろいろ話ができる機会というのは貴重です。
ちなみに、私の隣の方は、学生さん（大学院生で来年から社会人とのこと）でした。
これまた新鮮ですねー。学生の頃から勉強会に参加するとは、なんと志の高いことか！こちらも大変刺激になります。
11時過ぎくらいまで楽しんで、明日も平日なのでお開きになりました。
今回も非常に有意義な時間でした。是非
次回（8/29)も参加したいと思います。
主催者と出席者の皆様、ありがとうございました。次回も楽しみにしてます。
