2015/2/26(木) 「横浜道場スプリント！(仮) 第2回」に参加してきました。
DoorKeeper
https://yokohama-dojo.doorkeeper.jp/events/20095以下の書籍をターゲットとした勉強会（？）なのです。
場所はいつもの横浜市西公会堂です。
参加者は6名＋スタッフ2名かな。
前回から始まった、アジャイル開発実践の場。前回のブログはこちら。
- 「横浜道場スプリント！(仮) 第1回」に参加しました
前回1/22の時点で、うちのチームはPOを入れて4名。
前回の道場から今回2/26の開催までの間に、チーム4名で一度、Skypeによる打ち合わせを実施しました。
2/16(月)の23時から。そこでアーキテクチャの議論をしたり、スターマップを作成したり。
顧客との接客飲みの場から一時離席して、スマホのSkypeで参加してきた強者もいましたｗ
Skype打ち合わせの最後、2/26のスプリントで以下3点を決めましょう、と合意をして解散しました。
- アーキテクチャの案を2/26に持ち寄る。（イメージできるサンプルコードとか動作するものがあると良い）
- インセプションデッキを作る。
- 完了の定義を決める。
そして迎えた当日2/26、チーム「HotPans」に新規メンバーがお一人増えました～
■チーム「HotPans」(1) プロダクトの説明(2) プロダクトオーナー(3) 開発チーム- とがちゃん
- かめちゃん
- ななさん （新規 参戦！）
- まこぴ
新しい風が入るのは良いですね～。チームらしくなってきました。
あと、もう一つのチーム「わくわくルンルン横浜道場」の方も新規の方が1名増えました。
ただ、あちらのチームはこの日もPOが不在ということで、なかなか大変そうな一面も・・・
HotPansはこの日、Skype打ち合わせの最後に決めた3点について順に取り組んでいきました。
■１．アーキテクチャを考える先日のDevelopers Summit 2015でモバイルアプリ開発のハンズオンに参加してきたので、まこぴからはその共有をしました。
- 「Developers Summit 2015」に参加してきました - 其の弐 - 「モバイルアプリ開発系」
HotPansの開発ですが、クライアントサイドはHTML5（Javascript + CSS3)ベースとし、フレームワークは Apache Cordova（PhoneGap） と AngularJS を使うことを考えてます。
サーバ側は未定ですが、クライアントとサーバをRESTで繋ぐアーキテクチャを考えています。
この日は、デブサミのハンズオンでやったことを、ツールやフレームワークを使って実際にやってみせました。
概ね反応は良かったようで、ひとまずこのアーキでスタート切りそう。サーバサイドはもうちょっと考える・・・
■２．インセプションデッキを作るPOのたくぼんさんが作った叩き台の１枚、「我われはなぜこここにいるのか」。
この叩き台を元に、「我われはなぜこここにいるのか」をチームで考えてみました。
下半分は「学習」の要素が強い付箋、上半分は「実益」の要素が強い付箋が集まってます。
両者の間を、★マークが付いた付箋
「身近で役立つ目に見えるサービス開発」が繋いでいるイメージかな。
チームで書きだして整理することで、各人の思いや目的など、いろいろなことが見えてきました。
■３．完了の定義を決めるプロダクトを開発するのに必要な作業を時系列に書き出してみて、そこから、どの作業がどうなったら完了と見なすのか、定義を議論しました。
いったん時系列で作業を書き出してみる、というたくぼんさんの提案を聞いて、こーゆうやりかたもあるのだな～、と勉強になりました。
いったん書き出してみて、ストーリーレベルとスプリントレベルで完了の定義を考えていきました。
そんなこんなしてる間にこの日はタイムアップ。
終了後はみんなで飲みに行きました。
（各種写真の提供： とがちゃん at "HotPansのFacebook"）
★感想：少人数で始まった活動ですが、Skype打ち合わせとか、Facebookでの議論とか、この日の集まりとか、みなさん積極的に参加してくださってて、とても活気があります。
あとは、アーキテクチャとフレームワークがパチッと合って、開発が軌道に乗ってくれるといいんだけど。。。
これはちょっと試行錯誤がもうちょと必要そうです。
ちょっとサンプルとか作ってチームで共有したりとか。
ということで、試行錯誤から得られる副産物にも期待！
次回の横浜道場スプリント第3回は3/26(木)の予定だそうで、これに向けてまた準備していきたいと思います。
みなさん、ありがとーございました。
2015/2/19(木)～2/20(金) 「Developers Summit 2015」に参加してきました。
公式サイト
http://event.shoeisha.jp/devsumi/20150219先日、デブサミの感想ブログとして一発目を書きました。
- 「Developers Summit 2015」に参加してきました - 其の壱 - 「ドメイン駆動設計再入門」
今回は二発目として引き続き、私が参加したセッションについて書こうと思います。
テーマは、
モバイルアプリ開発です。
■ 【20-F-1】 《第1回》実践！ クロス プラットフォーム モバイル アプリ開発セッション紹介：
http://event.shoeisha.jp/devsumi/20150219/session/835/ 今回のデブサミで、私が最も
目から鱗 なセッション！
というのも私、
アジャイルサムライ横浜道場 というコミュニティで、ちょうどモバイルアプリを開発しようとしてて、いろいろ調べていた矢先だったのです。
詳細は以下のブログ参照。
- 「横浜道場スプリント！(仮) 第1回」に参加しました
４人の寄せ集めチームなのですが、全員モバイル開発の経験が無く、フレームワークを調べたりアーキテクチャを考えたりしている真っ最中なのでした。
そんな私にとって、このハンズオンは正に
渡りに船 だったのです。
ハンズオンの前日、 Windows7(x64)マシンに Visual Studio Community をインストールし、当日の環境構築で「Monaca for Visual Studio」というプラグインをインストールしました。
ビビったのは、恐ろしく素早く簡単に、モバイルアプリをAndroidの実機で動かすところまで持っていけたところですね。
ハンズオンは１時間５０分と短いのですが、講義 ＋ 環境構築 ＋ 開発 ＋ ビルド ＋ 実機転送、というのを一通り学ぶことができました。
自分で開発したアプリをAndroid端末上で実際に動かすという体験は、簡単なハンズオンながら、ワクワクしましたね～
Android上で撮ったスクリーンショットをぺたり。ハンズオンで作ったおみくじアプリの画面です。
あと、このハンズオンで学んだ内容が、ほぼすべてオープンな技術でカバーされているという点も魅力的です。
ベースはHTML5（Javascript + CSS3)で、Apache Cordova（PhoneGap）やAngularJSといったメジャーなフレームワークも合わせて使います。
ちょうど仕事の関係でAngularJSを学ぶ必要に迫られていた自分にとって、ちょうどよい機会なのでした。
ハンズオンの最後には書籍まで戴けて、至れり尽くせりです。
ちょうど今、この書籍を読みながら写経したりしてます。
このハンズオンと書籍、モバイルアプリを初めて体験するエンジニアにはとてもオススメな題材だと思います。
■ 【19-D-3】 AngularJSの今とこれから - フロントエンドエンジニア座談会セッション紹介：
http://event.shoeisha.jp/devsumi/20150219/session/660/ ハンズオンでも少し出てきたAngularJSですが、単独のセッションがあったのでこちらも聴講してきました。
満席で、立ち見でした・・・
このセッションについては以下のブログがよく纏まってそうなので、そちらに委ねます。
AngularJSもそろそろ枯れた技術になってきたとのことで、そろそろ私も学び始めたいなぁと思うのでした。
（最近はAngularJSのdisりとか対抗馬もずいぶん増えてきましたが）
あと、私は聴講できなかったのですが、以下のセッションのスライドも参考になりました。
■ 【19-C-L】 エンタープライズ要件に対応する高品質なCordovaアプリ開発のポイントセッション紹介：
http://event.shoeisha.jp/devsumi/20150219/session/651/ ハンズオンでも使用した Apache Cordova に関するセッションですね。
とてもよく纏まった資料だと思います。
この資料とハンズオン資料は、
次回2/26の横浜道場スプリントでチームメンバに共有したいと思います。
★感想：やっぱハンズオンやって、戴いた書籍を写経して動かしてみて、モバイルアプリ開発って楽しいなー
一気に身近に感じるようになりました。
横浜道場スプリントでのモバイルアプリ開発にも十分使えそうで、学習のモチベーションも上がります。
つーか、これまでPCで動作するアプリしか作ったことのないまこぴにとって、すげーワクワクする！
なにか、モバイルアプリ開発というまだ見ぬ世界にこの上ない可能性を感じるというかｗ
引き続き、私が参加した残りのセッションについてブログに書いていこうと思います。
2015/2/19(木)～2/20(金) 「Developers Summit 2015」に参加してきました。
公式サイト
http://event.shoeisha.jp/devsumi/20150219 場所は目黒雅叙園です。
参加者は数百人規模・・・何人くらいなんだろ？
今年もなんとか仕事を調整し、2/19(木)は午後から、2/20(金)は朝から丸１日、参加してきました。
おかげさまで、ここ数年は毎年参加できてます。
会場受付付近にある翔泳社＆オライリーの書籍ブースの写真１枚。
やっぱ、こーゆー場にくるとエンジニアとしてワクワクしますねー
さて、いつもどおり復習のブログを書くにあたり、まずは以下セッションの聴講メモを最初に書くことにしました。
というのも明日2/22(日)にDDD読書会があるのですが、主催の @naopi さんから軽く紹介をお願いされたのです。
■ 【20-C-3】 ドメイン駆動設計再入門 和智 右桂 氏〔グロースエクスパートナーズ〕
和智さんのDDDに関する講演は他でも何回か聞いたことあります。
以前、書籍に和智さんのサインも戴きました。
今回も、いつもの丁寧で謙虚な姿勢、そして笑顔、健在でございました。
以下、自分の復習用に、個人メモ。
---
■ モデルとは （P.7～） - 「モデル」とは何か、あなたは後輩に説明できますか？
- 「モデル」という用語をいろんな人がいろんな意味で使っている。
- DDDを読む前提だと、1979年のTrygve Reenskaugの言葉を借りると、「モデルとは知識の表象である」。
- でも、この説明は現在のMVCのモデルと若干違う気がしませんか？
- それは、「メンタルモデルを写し取るもの」という考え方。
- MVCは「ビューとモデルを分けましょう」と理解されているが、当時は、「頭の中をコンピュータに写し取る」というものだった。
- 人は自分の業務に対してイメージを持っていて、その頭の中に持っているイメージが「メンタルモデル」である。
■ MVCからDCIへ （P.10～） ■ 第１部「ドメインモデルを機能させる」 （P.12） - 書籍は４部構成となっている。
- 第１部は５００ページ中、９０ページくらいで、けっこう薄い。
- 第１部だけでもぜひ読んでください。DDD本が高いと思ったら、９０ページだけでも立ち読みを・・・ｗ
■ モデルの基本的な用法 （P.13）
１．モデルと設計の核心の相互作用 - モデルと設計・実装を結びつける
- 分析フェーズでコンサルが難しいパワポを書いて、その後に去っていく、というのは良くない。
- ちゃんと作ったモデルはコードの中まで持ち込みましょう。
２．コミュニケーションの基盤 - モデルは実装、設計のためだけではなく、これってどういう業務なのか、という話を客と話すベースになるもの。
- 「ユビキタス言語」は、チーム全員やお客さんが使う用語を統一した共通言語。
３．蒸留された知識 - 業務が詳しい人の知識を表現すること。
- モデルはソフトウェアの中核なので、モデルをソフトウェアの中に持ってこよう、というのが基本的な考え方。
- モデルはソフトウェアの中核となり、ビジネスパーソンと開発者をつなぐ。
■ 第２部： モデル駆動設計の構成要素 （P.16～）
- 第２部がけっこう鬼門。急激に実装寄りの話になるので、読むのが止まりやすい。
- モデルをソフトウェアの中に持ってこよう、ということを具体的に書いている。
- １．レイヤー化アーキテクチャ
- ２．ドメインレイヤ内でモデルを実装する
- ざっくり言うと、「ドメイン層とは、モデルが息づく場所」のこと。
- UIとDBの間にレイヤーを切って、そこにオブジェクトを置きましょう。
- P.18のアーキテクチャを作るにはどうすればいいか？のパターンがいくつか書いてある。
■ 第３部： より深い洞察へ向かうリファクタリング （P.19～） - 第３部は、個人的に非常に面白いと思っている。第２部は飛ばしても、第３部は読んで欲しい。
- DDD本を読む順番は、「第１部の次は第３部へ行け」と著者も薦めている。
- 個人的には 第１部 ⇒ 第３部 ⇒ 第４部 ⇒ 第２部 の順で読むのがオススメ。
■ モデルの深化 （P.20～）
１．時間をかけてモデルは深まっていく - モデルは作って終わりじゃない。時間をかけて深化していく。継続学習。
- モデリングは「発見のプロセス」である。
- 開発者が拾いきれていないだけでなく、ドメインエキスパートさえも、開発者に説明してモデル化していくと「あれ？おかしいね・・・」と気づくことがある。
- 開発者とドメインエキスパート双方にとって、モデリングは発展のプロセスである。
- モデリングを進めると、ある時、まったく違うモデルに気づいてガラッと変えることがある。それがブレイクスルー。
２．深いモデルを作るためのテクニック - 「暗黙的な概念の明示化」とは、普通に考えていると出てきにくいものをオブジェクトにすること。
- しなやかな設計、先達からの学習、デザインパターン、などが紹介されている。
- 第３部までは、１つのシステムに閉じた話になっている。第４部から、その趣が変わる。
■ 第４部： 戦略的設計 （P.21～） - モデリングのスケールアップ
- 第３部までは、１つのシステムや業務をターゲットとしていた。
- エンタープライズシステムでは、いろんなシステムが連携して動くことになる。それにどうしたらいいか、が書いてあるのが第４部。
１．モデルの整合性をとる - モデルの境界設計の話で、他システムとの境界をどうしたらよいかが書いてある。
２．蒸留 - フラットなモデルにおいて、大事なトコとそうでないトコがある。モデルから本質を抽出する話が書いてある。
３．大規模な構造 - 巨大なシステムをレイヤー化して俯瞰するためにどうすればいいかの話が書いてある。
■ 後に続く本 （P.23～） モデルを核にしたシステム観を継承している２冊を紹介する。
１．GOOS (2009) - オブジェクト指向のシステムを作るには、成長させるには、どうすれば良いかが書いてある。
２．DSL (2010) - DSLを作るにはどうすればいいかが書いてある。
- 根底にあるモデル観、システム観はDDDによるところが大きい。
- DSLは抽象的なモデルを作った上で、モデルを操作する言語を提供する。
- DDDでも宣言的な設計を突き詰めると、そうなるんじゃないか。
- 何が言いたいかというと、モデルを取り巻く考えが重要視されているのでは、ということ。
■ DDDの魅力 （P.25～） - プログラマーにもプロジェクトマネージャにも、DDDは魅力あるんじゃないか。
- というのも、DDDはテクニカルにどうするかというより、業務をちゃんと分析しましょう、という話なので、プログラマーやプロジェクトマネージャ、全エンジニアに共通のテーマだから。
■ ある抽象度でのモデリングは絶対に必要 - システムを俯瞰して考えるときに第４部の話は重要になってくる。
■ソフトウェアの本筋 ■ SIの現場での福音 - ここから怪しい・・・
- プログラマの時に、いいやり方をいろいろ探していてDDDに初めて出会った。
- コードを書くのは好きだったが、DDDはとても魅力だった。
- その時、閉塞感があった。
■サイロ - 会社の縦割り、横割り構造。
- 何かを主張しようとしても、サイロのために上の人に阻まれたり、横にも届かなかったり・・・
■ 滝 ウォーターフォールは絶対に必要なプロセスだが、中の人にとっては、必ずしも楽しいものではない。
■ 規律 - 上から言われたとおりに作る。何を作るかというと、「トランザクションスクリプト」・・・
---
そういうことのツマラナサを感じる際、お客さんと会話しながら、変化に対応しながら進んでいくというDDDの思考が魅力的だった。
■ バランスが大切 （P.36～） - DDDって、それぞれのレイヤーにいる方にとって、アピールするものがある。
- でも、それを全体に取り込む時に、全員が幸せになるように「DDDで作ろう！」とすると不幸が始まる。
- バランス大事。
■ モデルをどこまで保つべきか？ （P.38～）- この絵は、アリスター・コーバーンのユースケースの本からの借用した図。
- 要求を海面まで落とす人と、海面から下へ実装に落とす人に分かれる。
- 業務サイドとエンジニアサイドが共感しあえる場所が、海面。
- それを、海面下に何も考えずに落とそうとすると、不幸が起きる。
■ ドメインレイヤの外側 （P.40～） - ドメイン層の外側には以下がある。
- ユーザインタフェース層
- 永続化層
- 他システムとの統合層
- DDD、ドメイン層だけに着目していると、上記のような他層の設計から離れてしまい、おろそかになりがち。
- ドメイン層の動きと平行して、他の層と最後に統合しないといけない。これが大変。
- この話は、DDD本にはやりかたが書いてないので、自分たちでちゃんと考えないといけない。
■ すべてを統合する （P.41～） - すべての機能は複雑なのか？
- マーチン・ファウラーのPofEAA（エンタープライズ アプリケーションアーキテクチャパターン）に、ロジックの構成方針として２つが紹介されている。
- １．トランザクションスクリプト （ユーザの要求を満たす手続き）
- ２．ドメインモデル （複雑なロジックをオブジェクト思考で解決する）
■ 損益分岐点を見極める （P.44～）- P.44は、この２つの損益分岐点を表した図。縦軸が「機能追加のコスト」で、横軸が「ロジックの複雑度」を表す。
- この図を見ると、ドメインモデルの線の上がり方は緩やかである。
- 図の右の方だけ見ると「ドメインモデルを採用すればいい」という話になるが、図の一番左に、トランザクションスクリプトの方がドメインモデルよりコストが少ない箇所がある点を忘れてはいけない。
- その割り切りが必要。ロジックが簡単ならトランザクションスクリプトもアリなはず。
■ 複雑さは囲い込む （P.45～）- 複雑さは囲い込んで、複雑じゃない箇所はSQLで処理すればいいじゃないか。
- では、複雑なやつとそうでないやつの見極めは、どうやれば？
- 「慣れた人に任せるしかないよね」 byマーチン・ファウラー
- 私も、SQLでさらっとできるならトランザクションスクリプトでやればいいのでは？と個人的には考えている。
■ 何を対象とするのか？ （P.47～） - 下に落とし込むときに、どこまで落とし込むのか？モデリングの対象ってなににするのか？
■ デザインするのはメンタルモデルだけでいいのか？ （P.48～）- ドメインモデリングに注力し過ぎると、画面遷移や業務フローにびっくりするくらい考えなくなるようになる・・・。
- システムの外側で起きることへの配慮が、システムの中ばっかり考えていると、すごく抜ける。
- システムの外側まで考えないと、システムの中ばかり作れても、システムとしては動かない。
- 大事なのは、お客さんと同じものを見ること。
- ユーザさんが何を考えて動いているのか、ユーザが見てる世界を一緒に見ないと上手くいかない。
■ 成長するのはモデルだけなのか？ （P.51～）- システムを取り巻く流れはいっぱいある。企業のビジネスだったり、社会の状況だったり。
- これらをきちんと考えないといけない。
- モデルが精緻に深まっていくだけでなく、システム全体として成長していくことが大事。
- システムをどう育てていくかまで考えてフィードバックループを設計しないといけない。
- システムだけでなく開発チームも成長していく。両方を合わせて考えていかないといけない。
■ まとめ （P.56～）- 今日はドメインモデリングの内側と外側について話した。これはDDD本には書かれていない。
- でも、なぜDDD本に書いてないのか、というのは筋違い。
- DDDは素晴らしい構想。
- ただ、DDDの内側で考えていても、システム開発の観点からだと上手く行かないので、システム全体で考えよう。
- DDDは難易度が高いものに対して何をやればいいかを教えてくれるもの。
■ さいごに （P.58～） - 世界に対するエンジニアの貢献はコードの優劣では決まらない。
- 業務ロジックを書くというのは比較的地味。
- でも、ちゃんと分析して、ユーザと創り上げるのは価値があるし、やりがいがある。
- 業務エンジニアに対する応援として１つ言えるのは、「コードを見るだけでは優劣は決まらない」ということ。
- トランザクションスクリプトだからダメ、ということはない。
- エンジニアが社会に貢献するのは「システムが何を達成できているか」であって、「中のコードの優劣や難易度」ではない。
- システムを通じて社会に貢献することが大事。
★感想：和智さん、やっぱ紳士というか真摯だなぁ、と。
物腰も柔らかく、話は明快でポイントが押さえられており、自分の主張もきちんと入ってて、エモい話で締める。
この講演を聞いて、も一回、１からDDD本を読み直したくなりました。
ちょうど週末、DDD本の読書会もあります。そこの貴方、ご一緒にいかがっすか～
残りの講演についても、自分の復習のためブログにメモ書いていこうと思います。
続きは後日～
2015/2/13(金) 「外部キー Night」に参加してきました。
connpass
http://connpass.com/event/11463/場所は千駄ヶ谷（代々木）のピクシブ株式会社さんです。
参加者は60人くらいでしょうか。
・・・この勉強会のタイトル！そしてピンポイントなテーマｗ
惹きつけられずにはいられない！
そんな私も、SQLアンチパターン読書会で4章「キーレスエントリ」の紹介を担当したということもあり、外部キーには少し思い入れがある一人なのです。
以下、個人メモ。
■ 外部キー制約に伴うロックの小話 @ichirin2501さん
外部キー制約に起因するデッドロック発生のメカニズムがいくつか紹介されていて、実に興味深い。
ということで、実際にやってみないと気がすまないタチなので実機で試してみた。
環境はWindows7(x64)のMySQL5.1.37(InnoDB)です。
■ P.8 「外部キー制約によるロック（基本編）」の再現ちなみに上がトランザクションA（user1)、下がトランザクションB(user2)です。
(1)
トランザクションA(user1)とトランザクションB(user2)を開始させる。
(2)
次に、トランザクションA(user1)側で player_item テーブルにINSERTを実行する。
これで外部キー制約される親側の player.id(100) と item.id(2000) に対して共有ロックが獲得されたはず。
(3)
次に、トランザクションB(user2)側で player.id(100) をキーに指定して、SELECTで排他ロックを獲得しようとする。
すると、(2)でplyaer.id(100)に共有ロックが取られているため、トランザクションB(user2)側のSELECTが確かに待たされる・・・
(4)
トランザクションA(user1)側でUpdateを実行しようとすると、デッドロック発生！
即座にトランザクションB(user2)側が自動的にロールバックされ、トランザクションA(user1)側のUpdateが成功します。
ちなみに自動でロールバックされたこの現象ですが、InnoDBはデッドロック検知機構が搭載されているらしく、デッドロックが発生した場合はどれかのトランザクションが安全にロールバックされるそうです。
今回は確かにトランザクションB(user2)側が即座にロールバックされましたね。
■ P.13 「外部キー制約によるロック（シャドーロック編）」の再現シャドーロックも実際に試してみる。
■ case1： item -> player の順でindex定義(1)
player_itemテーブルのcreate時に、インデックスを item -> player の順で作成する。
(2)
トランザクションA(user1)とトランザクションB(user2)を開始させる。
次に、トランザクションA(user1)側で player.id(100) の排他ロックを取る。
(3)
次に、トランザクションB(user2)側でplayerテーブルにiNSERT文を発行する。
すると、(2)で player.id(100)に排他ロックが取られているため、待たされる。
この時、シャドーロックにより item.id(2000)に対しても共有ロックが獲得済みとなる。
(4)
トランザクションA(user1)側で item.id(2000) の排他ロックを取ろうとすると、(3)のシャドーロックにより item.id(2000)の共有ロックが先に取られているため待たされる。
⇒ デッドロック発生！
即座にトランザクションA(user1)が自動でロールバックされ、トランザクションB(user2)側で待たされていたInsertが実行されました。
インデックスの定義順序が原因でデッドロックになってしまうのですね～・・・
■ P.22 「補足： ロックは食いつく」 ＆ 「INSERTでDuplicateEntryになったとき」の再現(1)
Uniq制限のあるテーブル player_token を作成する。
インデックスは id -> token -> itemの順とする。
(2)
トランザクションA(user1)で、player_tokenテーブルにINSERTし、排他ロックを獲得する。
(3)
トランザクションB(user2)側でもplayer_tokenテーブルにINSERTしようとするが、(2)の排他ロックにより待たされる。
(4)
トランザクションA(user1)側をコミットして排他ロックを開放すると、トランザクションB(user2)側で待たされていたINSERT文を実行しようとする。
しかし、カラムtokenのUNIQUE制限にひっかかり、DuplicateEntryのエラーになる。
ここで注意すべきなのは、DuplicateEntryになったものの、トランザクションは継続しているという点。
更に、インデックス定義が id->tokenの順のため、シャドーロックによりplayer.id(200)の共有ロックは獲得されたままになっている。
(5)
トランザクションA(user1)側でplayer.id(200)の排他ロックを取ろうとすると、(4)のシャドーロック（共有ロック）が獲得済みのため、待たされる・・・
MySQLのロック機構、実に興味深い挙動です。
上記の写経で使ったSQLもついでにアップしておきます。
20150213_fknight_sql1.txt---
■ 我々(主語が大きい)は何故MySQLで外部キーを使わないのか @songmuさん
【↑をクリックするとスライドに飛びます。】
外部キーを使わない理由をいくつか紹介されてます。
外部キー制約を使うとパーティショニングができない、という話はSQLアンチパターン読書会の４章「キーレスエントリ」について議論しているときにも出てきましたね。
冒頭の私のツイート先のブログにもチラッと書いてあります。
あと、外部キーを定義すると自動的にインデックスが貼られる点についても言及されてます。
インデックス肥大を避けるために外部キーを使わない、という判断もありえるとのこと。
外部キー制約を使わないんだったら、その代わり、整合性を担保したテストデータを生成するような仕組みをきちんと用意する必要がある、という点も、なるほど～ですね。
外部キーを使わない理由って、けっこーあるもんですねー。勉強になりました。
■ 我々は何故RDBMSを使うのか @kamipoさん
【↑をクリックするとスライドに飛びます。】
SQLアンチパターン読書会で @t_wada さんから何回か @kamipo さんの話題が出たことがあるので、お名前は知ってましたが、この日が初見。
スマートで、イケメンで、茶髪混じりの今風の若者といった感じ。裏山氏。
ですが話を聞いてみると知見が深く、天才肌、というイメージのエンジニアですね。
そんな@kamipo 氏から「SQLアンチパターンを読め」的な発言が飛び出し、その発言がTLにいくつか流れて・・・
MySQLは即時制約しか対応してないらしく、ステートメント毎にチェックが走ってしまうそうです。
遅延制約が使えないとなると、テストデータの投入とか大変そうですな。
全件舐めるSQLに対する皮肉、カスケード削除による大量件数の物理削除を裏でDBMSにやらせる案、レビューおじさんの話など、ユニークでユーモアある内容でした。
とても勉強になるスライドです。
■ LT３人の講演のあと、２人のLTがありました。
１件目は@karupaneruraさんによる「FKアンチパターン (LT)」、こちらはスライドはまだ公開されてないっぽいですね。
２件目は以下です。
■ 深い親子関係を、整合性を保ったまま非正規化したい (LT) @yubaさん
深い階層構造によるJOIN地獄を避けるための工夫が紹介されています。
複合の主キーにするのではなく、複合のユニークキーにして単一性を持たせ、複合ユニークキーに参照制約を付与するという案。
これはよく考えましたね。SQLにすると、こんな感じですかね。
create table user (
id BIGINT UNSIGNED PRIMARY KEY,
text varchar(20)
);
create table blog (
id BIGINT UNSIGNED PRIMARY KEY,
id_user BIGINT UNSIGNED,
text varchar(20),
unique(id, id_user),
foreign key (id_user) references user(id)
);
create table article (
id BIGINT UNSIGNED PRIMARY KEY,
id_blog BIGINT UNSIGNED,
id_user BIGINT UNSIGNED,
text varchar(20),
unique(id, id_blog, id_user),
foreign key (id_blog, id_user) references blog(id, id_user)
);
create table comment (
id BIGINT UNSIGNED PRIMARY KEY,
id_article BIGINT UNSIGNED,
id_blog BIGINT UNSIGNED,
id_user BIGINT UNSIGNED,
text varchar(20),
unique(id_article, id_blog, id_user),
foreign key (id_article, id_blog, id_user) references article(id, id_blog, id_user)
);
|
これはいつか使えるかもしれない・・・
★感想：MySQLに特化した内容が多かったなぁ、と思うのと同時に、DBMSの違いでこうもいろいろ意識せにゃならんのか、と驚かされた。
あと、家に帰っていろいろスライド見返してようやく理解できた内容が多かったです。
知らない単語も多かったし、そもそもMySQLの知識も経験も足りない・・・
写経してみてようやく腑に落ちたというか。
参加者のみなさん、聴いてその場ですぐ理解できてたのかな・・・？そうなら凄いなぁ。
SQLアンチパターンの「キーレスエントリ」を読んで私は完全に「外部キー付ける派」だったんですが、この日の話をいろいろ聞いて、外部キーを付けない、という判断も現実には結構あるんだなぁ、と知った。
外部キーという狭いテーマなのに、いろんなテーマに話題が波及してて、外部キー奥深し。
皆様、ありがとーございました。
2015/2/10(火) 「RESTful#とは勉強会4」に参加してきました。
Doorkeeper
http://rubychildren.doorkeeper.jp/events/20247Togetter
http://togetter.com/li/781514以下の書籍をターゲットとした勉強会なのです。
場所は高円寺の株式会社ヴァル研究所さんです。
参加者は25人くらいかな？
私は第2回から、3回連続の参加です。前2回のブログはこちら。
この日はお仕事の都合で、30分ほど遅れての参加です。
今回は「7章 HTTPメソッド」がターゲットでした。
開始に先立ち、今回の第7章で注目して読んでほしいポイントが@tkawa さんから示されました。
勉強会終了後、ポイントに対し解説が追記されました。
以下、テーブルでのディスカッションや質疑応答での個人メモ。
■ PUTでリソースの上書きを避けるためにクライアントで事前にURIの存在をチェックする （P.95）- どうすればチェックできるか？
- クライアントからHEADメソッドでURIの存在をチェックし、リソースが存在しないことを確認してからPUTを投げるとしても、その短い隙に他の誰かがPUTでリソースを作成してしまう可能性は避けられないのでは？
- DBの世界ならトランザクション制御で回避できそうだけど、Webの世界ではどうするの？
- 楽観排他を使えばいけそうな気がするが、でもトランザクションにより直前検索と更新を1トランザクションに含めないとダメな気がする・・・
- @tkawa さんによると、「16章」のP.290あたりにやり方が書いてあるそうな。
■ PATCHメソッド- 表7.1にHTTPメソッドが８つ紹介されているが、PATCHメソッドがない・・・
- PATCHメソッドはHTTP仕様に載っているわけではなく、他の標準になっている。
- PATCHメソッドで「差」の表現をリクエストで送ると、それに応じて部分的に変更してくれる。
- JSON PATCHというのを使えば差分表現ができる。
- PATCHメソッドはリソースの部分的な変更を行うのに対し、PUTはリソースをすべて置き換える。
- PUTは効率が悪いので部分更新がしたい、という場合にPATCHを使えば良い。
■ POSTによるリソースの追加- 7.4節は「POSTでリソース追加」、7.5節は「PUTでリソース更新」となっているが、POSTは追加じゃなくて更新なのでは？
- ⇒ 「更新」と考えて良い。ただし、PUTは全体を丸ごと更新するのに対し、POSTは部分更新となる。
- POSTの部分更新は、PATCHでも良い。
■ 「HTMLのフォームで指定できるメソッドがGETとPOSTだけ」なのは何故か？■ 「7.12節 メソッドの誤用」の例- OPTIONSメソッドでyahoo.comにリクエストを投げると、普通にトップページ返ってくる・・・
- OPTIONSメソッドでgoogleにリクエストを投げると、ちゃんと「405 Method Not Allowed」が返ってくる。
- でも、「501 Not Implement」でサーバーのエラーとした方が「ごめん、実装してない」と伝わって紳士的かも。
- OPTIONSメソッドでヴァル研究所のサイトにリクエストを投げると、サポートされているメソッド一覧が返ってくる。
- でも、書籍に「OPTIONS自体はAllowヘッダに含めない」と書いてあるのに、なぜか含まれている・・・
- Yahoo!は、OPTIONSをプロキシで通してない可能性ある。
- OPTIONSに対してトップページを返す挙動はメソッドの誤用なので、本来は返すべきではない。
- どうやってOPTIONメソッドのリクエストを飛ばしたのか？何かツールを使ったのか？
■HTTPie- HTTPieコマンドを使うと簡単にリクエストを送ることができるのでオススメ。
- 使い方は簡単だし、色が付いて見やすい。
- 昔はtelnetでリクエスト送ってたこともあるが、けっこう大変だった・・・
- でもhttpはテキストのやりとりなので、ちゃんと書けばtelnetでもリクエストを送れる。
■ HTTPieによるOPTIONSメソッドの実験Windows7(x64)にHTTPieをインストールし、前述したYahoo!、Google、ヴァル研究所、それぞれのサイトにOPTIONSメソッドでリクエストを送ってみる。
(1) HTTPieをWindows7(x64)にインストール HTTPieのGitHubにある手順に沿って、pipコマンドでインストールしてみた。
ちなみに私のPCにはもともとPythonがインストールしてあったので、そのままpipが使えたのである。
すんなりインストール完了。
(2) ヴァル研究所のサイトへOPTIONSメソッドでリクエストを投げてみる
お、サポートしているメソッドがちゃんと返ってきた。
GET, HEAD, POST, OPTIONS がサポートされているようです。
書籍には「OPTIONS自体はAllowヘッダに含めない」と書いてあるのに、たしかにOPTIONSが含まれている・・・
(3) GoogleのサイトへOPTIONSメソッドでリクエストを投げてみる
勉強会で言及されていたとおり、「405 Method Not Allowed」が返ってきました。
レスポンスのボディにはHTMLが入っていますね。
(4) Yahoo!のサイトへOPTIONSメソッドでリクエストを投げてみる
ホントにTOPページのHTMLがまるごと返ってきました・・・
ちなみにレスポンスが長すぎて1ページに収まらないので、パイプで more コマンドに渡して表示してます。
OPTIONSメソッドが想定している挙動と異なりますね。これは誤用と言えるのかな？
以上、HTTPieによる実験でした。このツールはすごく便利だなぁ・・・
■ 擬似REST- 7.9節で紹介されている「_methodパラメータ」は、Railsでは「擬似REST」と呼ばれているらしい。
- 最近のフレームワークは、擬似RESTとして主流の「_method」と「GData」の両方をサポートしていることが多いらしい。
- RailsもGDataは使えるらしい。
■ OPTIONSって何に使うの？- CORS(Cross-Origin Resource Sharing)で使う。
- Ajaxでブラウザ内から違うドメインへAjaxリクエスト飛ばすときに、ブラウザがプリフライトリクエストとして自動的にOPTIONSを投げるとのこと。
- プリフライトリクエストは開発者が実装するんじゃなくて、ブラウザが自動的に行う。
- OPTIONSの使い道は、これくらいしかないかもしれない。
■ 次回の勉強会
★感想：本に書いてあること以外のノウハウをたくさん学べてとても有意義でした。
HTTPieはとても便利ですねー
今、以下の書籍のコードを写経して動作確認したりしてるんだけど、それにも使えそう。
各サイトのOPTIONSメソッドの挙動が異なる点も面白いですね。
やっぱ手を動かして、自分の目で確認するのは楽しいです。
帰りの電車で、Jxckさんのブログ「
なぜ html の form は PUT / DELETE をサポートしないのか？」もじっくり読みました。
とても参考になるまとめですねー
参加者の皆様、ありがとーございました。
2015/2/7(土) 「Yokohama.groovy #29」に参加してきました。
connpass
http://connpass.com/event/11265/主催の@grimroseさんが今回から「プログラミングGroovy」の読書会をやるということで、今回から初参加です。
場所は横浜のタネマキさんです。JUnitの読書会でお世話になった場所です。
参加者は7名かな。
Groovyは私、初経験なのです。
つーかこの日まで、PCにGroovyさえインストールしてないし・・・
書籍「達人プログラマー」の有名な格言
「毎年少なくとも一つの言語を学習する」は、私の毎年の目標なのです。
そんなわけで、この読書会はちょうど良い機会だと思い、参加することに。
あと、私が最も使用する言語であるJavaと親和性が高いこと、制御スクリプトとしてもかなり使えそうであることも、学習を後押しした一因です。
この日は書籍の1章から3.6節「クロージャ」まで、黙読とディスカッションと写経を織り交ぜて進めました。
環境ですが、私はWindows7にGroovyをインストールし、書籍巻末にあるEclipseのPluginを入れました。
コード補完が微妙な部分もありますが、概ねスムーズにコーディング＆実行できます。
勉強会にノートPC持っていってコーディングしたのは久々。
私のノートPC、デカくて熱がけっこう凄いので、空冷ファンを持っていかないといけないのです・・・
しかもキーボード上部の数字キーの効きが悪いので、この日はUSBテンキーまで持参した・・・
というわけで @t_wada 氏の教え通り、3.6節までのコードをほぼ全て写経して、実行もしてみました。
写経したコードはGitHubへ一応up。
https://github.com/makopi23/ProgrammingGroovyちょとハマった点を1つ挙げておく。
P.78のリスト3.46。
実行結果はこんなカンジ。
(3)で、assertに指定している
(1..10).grep{ it % 2 == 0 } をprintlnに渡したのが(1)なんですが、(1)の実行結果は
[2, 4, 6, 8, 10]になると思いきや、以外なことに
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]になってしまうのです・・・
[2, 4, 6, 8, 10]と表示させるには、(2)のように全体を丸括弧で囲まないといけません・・・
★感想：Groovyを触ったの今日がほぼ初なんですが、いろいろ便利な機能がありますねー
クロージャもそうだし、あとスラッシュでリテラル囲むとバックスラッシュがエスケープされる機能とか、地味に便利。
GStringのプレースホルダーも良いですね～
この本が終わったらGradleとかもやってくらしいので、そちらも楽しみです。
惜しむらくは、タネマキに常備してあるジョジョを読む時間がほとんど取れなかったこと・・・ orz
参加の皆様、ありがとーございました。
2015/1/27(火) SQLアンチパターン読書会 「砂の城」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/19944以下の書籍をターゲットとした読書会なのです。
場所は品川シーサイドの株式会社マーベラスさんです。
参加者は１６名かな？
この読書会が始まって２年余り、遂に最終章ということで、この章を寄稿された奥野幹也さんが来てくださいました。
奥野さんの講演は、データベースリファクタリング読書会やCLUB DB2などで何度かお聞きしたことがあります。
毎度、熱くDBについて語られるので、データベースのことがホント好きなんだなぁ、とｗ
この日はまず奥野さんに２５章「砂の城」について説明いただいたあと、いつもどおりディスカッション形式となりました。
■ ２５章「砂の城」 By 奥野氏 「ベンチマークの測定結果なく性能を語るのは不毛！」というお言葉、グサッと来ました・・・。
奥野さんが２５章に載せ忘れた「セキュリティ関係」、「キャパシティプランニング」、「論理的なデータ破壊」という３テーマについても資料で言及されていたりと、超有り難い内容に纏まっています。
あと、奥野さんの新著が出るそうな。
目次とか紹介していただいたんですが、これは是非読んでみたいと思った次第。
読書会とかあるといいな～
■ ディスカッションいつものように、ディスカッションしたい内容を付箋に書き出しました。
以下、個人メモ。
■ ベンチマーク- DBだけのベンチマークだけじゃなく、アプリに対するベンチマークも取らないと役に立たない。
- 大事なのはアプリの性能なので、アプリ性能が落ちていないことを確認すること。
- 実際の測定結果無しに性能問題を語るのは不毛。
- 想定や予想で議論し合う前に、まず測定せよ。そしてその数字で議論せよ。
■ デカいテストデータをどうDBに突っ込むか？- でかいと、データをDBから取ってくるのも、DBに入れるのも大変・・・
- MySQLだとレプリケーションでコピーしてこれば、デカいデータでもすごく楽にやりとりできる。
- Cookpadは、プロダクション環境とステージング環境が、データのマスク込みで同期している。
■ テストデータの増幅- 自作ツールによる増幅だとデータに偏りが出たりして、正しく性能が取れないことがある。
- テスト用のデータとして、本番環境などからデータを取得させてもらうことをお客さんとの契約に含んでおくべき。
- データの扱い方について契約に盛り込んでおく。
■ テスト環境- テストが無いと、怖くてイジれない。テストが無いとリスクになり、踏み込んでいけなくなる。
- 本番環境で性能測定などをするのはリスクがある。なら、本番環境と同等のテスト環境を用意すべし。
- 性能は、CPUやメモリのスペックを換算比較しても意味が無い。性能劣化はそれでは気づけない。
- 低スペックマシンでも、メモリを潤沢に積めば、低スペックながらも結構イケたりする。データがキャッシュに載ったりして
■ テスト環境としてのクラウド- 本番環境と同等のテスト環境を用意するのは難しいが、最近はクラウドベースのアーキテクチャが増えてだいぶ改善された。
- ただ、クラウド環境はネットワークの向こう側にあるので、細かくいじれないことが多い。
- チューニングでディスク分散、といった職人芸がまったく使えなくなることがある。
- インターネット経由なので、ボトルネックが発生することがある。
- クラウドはオートスケールとか自動バックアップを備えているので、それに助けられることが結構ある。
■ セキュリティ- なかなかセキュリティ対策の重要性を上に理解してもらえない・・・
- IPAがセキュリティ事故事例の統計を出している。
- セキュリティ事故でどのくらいの損害を出したかの概算金額も出ている。
- それを用いて説明すると上を説得しやすいかも。数字で議論するの大事。
- 最近話題になった徳丸さんネタも使えるかも。
- JR北海道が、セキュリティ強化のために顧客データを全く持たない、という記事が日経コンピュータで紹介されていた。
■ バックアップ- バックアップは取るだけじゃなく、リストアのリハーサルのテストもちゃんとやっておかないといけない。
- バックアップ取ってたのにリストアが出来ませんでした、という事例がよくある。
- バックアップの取り方も工夫しないと、データ破壊した後のデータを上書きバックアップしてしまった、ということになりかねない。
- 遅延レプリケーションという仕組みがあり、その場合は同期遅延された直前のデータは助かる。
■ データベース関連の書籍- 奥野さんの新しい書籍、読書会とかやりたいねー
- データベース関連の書籍って、初心者向けかハードコア向けかの両極端だった。
- 最近はミックさんの本とか、中間層向けの書籍が出てきた。
■ データベースのノウハウ- SQLチューニングはデータの内容によってやり方が変わるので、ノウハウを一般化することは難しい。
- 昔のデータベース運用ノウハウが、「今は全然役に立たない」とか「むしろ逆効果」とかいうことがよくある。
- 自分が獲得したノウハウのいくらかは、自分から積極的に捨てていく覚悟が必要。
- 実装は変えられるので、実装のノウハウは寿命が短い。
■ 急激な高負荷に対する対処- ワールドビジネスサテライトやニュースやCMで紹介されたことでWebページが落ちることがよくある。
- それに対する対処事例がいくつか紹介されている。 → ググってみた。
- キャッシュを利かして、リクエストをサーバまで到達させないとかの対処はよくする。
■ 想定外な事象への対処- バックグラウンドが違うエンジニアが集まったチームだと、いろんな案が出て良かった。
- 失敗事例を学ぶことが大事。SQLアンチパターンとか。
- AWSは定期的に故意に障害を発生させ、動作確認をしている。Netflixとかは最先端を行っている。
★感想：最後の章だけに話題は多岐に渡り、ディスカッションもいろんなネタが満載でした。
そして遂に、全25章を完走！
私、この勉強会が始まって2年あまり、実は
皆勤なのです。
しかも私だけｗ
これもひとえに、参加者皆様一同のおかげです。
アットホームな雰囲気、濃いディスカッション、勉強会後の飲み会などなど、ほんとこの読書会はお気に入りなのでした。
主催の山本さん、和田さんをはじめ、皆様ありがとーございました。
幻の章として「論理削除」をテーマにあと1回読書会やる、という話もあるとかないとか・・・
そちらも楽しみです。
あと、奥野さんから25章のページにサイン戴きました。感謝！
■おまけ：過去の「SQLアンチパターン読書会」ブログ1章：SQLアンチパターン読書会 「ジェイウォーク」に参加しました
http://makopi23.blog.fc2.com/blog-entry-65.html2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-70.html3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
http://makopi23.blog.fc2.com/blog-entry-73.html3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-77.html4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-84.html5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-90.html6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-94.html7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
http://makopi23.blog.fc2.com/blog-entry-97.html8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-105.html9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-109.html10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-115.html11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
http://makopi23.blog.fc2.com/blog-entry-118.html12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-121.html13章：SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-128.html14章：SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-130.html15章：SQLアンチパターン読書会 「ランダムセレクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-133.html16章：SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-134.html17章：SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
http://makopi23.blog.fc2.com/blog-entry-136.html18章：SQLアンチパターン読書会 「インプリシットカラム」に参加しました
http://makopi23.blog.fc2.com/blog-entry-138.html19章：SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
http://makopi23.blog.fc2.com/blog-entry-140.html20章：SQLアンチパターン読書会 「SQLインジェクション」に参加しました
http://makopi23.blog.fc2.com/blog-entry-144.html21章：SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-147.html22章：SQLアンチパターン読書会 「シー・ノー・エビル(臭いものに蓋)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-151.html23章：SQLアンチパターン読書会 「ディプロマティック・イミュニティ(外交特権)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-152.html24章：SQLアンチパターン読書会 「マジックビーンズ(魔法の豆)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-153.html
-->
