2013/8/24(土) JJUG ハンズオン祭り 「Java EE 7ハンズオン」に参加してきました。
DoorKeeper
http://jjug.doorkeeper.jp/events/5380JJUGハンズオン祭り
http://www.java-users.jp/?p=618場所は日本オラクルです。
参加者は50人弱くらいでしょうか。
私、普段はJavaでお仕事してますが、Struts1ベースの自社フレームワークを使うことが大半です。
なのでJava EEをほとんど触ったことがありませんでした。
というわけで、大変興味深く参加させていただきました。
この日は講義とハンズオンの2本立て！
■１．講義資料は以下のGithubに公開されています。
Java EE 7 ハンズオン「Java EE概要編」https://github.com/making/javaee7-first-tutorial/blob/master/JavaEE7Study.pdf?raw=true 講師は @making さんです。
ハンズオンに入る前に、Java EEの一通りの技術を解説くださるのは助かりますね。
各技術の位置付けが分かるので。
あと、各技術の説明スライドに対し説明を深く掘り下げた「WebLogic Server 勉強会」のスライドへのリンクがあるのもGoodでした。
個人的にはJPAとJSFに興味がありました。
JPAは、
SQLアンチパターン読書会とかでO/Rマッパーの話になるとよく登場してたので。
JSFは、普段使ってるStruts1とどんな違いがあるのかに興味がありました。
他にもJAX-RSとかCDIも興味深いですね～。
あと、Java EE 7で入ってくるJBatch。バッチ開発にどのくらい使えるのか。これも勉強したいなぁ。
■２．ハンズオン充実のハンズオン資料！たぶん2日コースくらいでちょうどいいｗ
DBアクセス層はJPA、業務ロジック層はEJB、プレゼンテーション層はJSFを使って簡単なWebアプリを作りました。
今回はSIerが多いことを考慮して、DDLからテーブル作って、エンティティをリバースエンジニアリングする方式でJPAを使うようにしたとのこと。
あと、JAX-RSを使ってWebサービスとして公開する部分もちょびっと。
講義で学んだ内容を実際にハンズオンで実践することで、学びの深さも数倍です。
あと、NetBeansを初めて使ったんですが、DBやAPサーバを簡単に操作できたりと、かなり便利に感じました。
普段はEclipseばっかりなので、Javaで違うIDEを触るのは新鮮です。
ハンズオンで範囲だった箇所は一通り開発できたので、Githubに成果物をアップしておく。
https://github.com/makopi23/todo最後に日本オラクルの寺田佳央氏から一言、締めのお言葉。
今日のハンズオンは基本的な内容であったが、これよりもう一歩、先に行った場合にJava EEの威力や恩恵が感じられるようになる。
そこまで行くと、Strutsとかより、かなり楽になる。
Strutsだと、今日のハンズオンより先まで行こうとすると、逆に限界が見えてくる。
今回のハンズオンは、簡単なアプリをあえて堅く作っているので、Java EEの威力を出すまで行けてない。
Java EEは構成要素が凄く多いので、それを聞くだけでいっぱいいっぱいという人がいるかもしれない。
でも、Java EEの一連の流れがイメージが付くようになりだすと、そこからはすごく早い。
DBを参照するアプリケーションとかが、10分、15分でできるようになる。
Java EEは、一通りの流れがわかれば、疎（素？）で開発ができるところが大きい。
また、開発規模に応じてJava EEの個別技術の専門集団を作って開発することも可能になる。 |
大体こんなことをおっしゃっていたかと思います。（間違ってたらゴメンナサイ。。。）
大変勉強になりました。
★感想：素晴らしいイベントですね。
講義＋ハンズオン構成で体系的に学べましたし、サポートのTAさんも充実してたし、しかもこれで無料だし。
Java EEが標準でこれだけの機能をサポートしてるならば、Java EEだけでもエンプラのシステム開発、十分行けそう。
・・・なのに、StrutsやらSpringやらOSSフレームワーク達にJava EEが押されているイメージがあります。
私も以前は、Java EEって難しそうだなぁ、というイメージを持ってました。
このヘンの考えは、かなり払拭されましたね。
またこーゆうハンズオンイベントを是非やってほしいです。
あと、この日のイベントのスライドやソースは以下に纏まっているようです。
https://github.com/making/javaee7-first-tutorial私、復習する機会を持つためにブログ書いているようなもんですが、大変ありがたいです。
講師の @making さん、JJUGスタッフさん、日本オラクルさん、皆様ありがとうございました。
2013/8/24(土) "勉強会「HerokuではじめるRailsプログラミング入門 （テキスト輪読）」 第5章 モデルとテーブル" に参加してきました。
告知URL
http://www.groupy.jp/study_groups/1/study_group_schedules/3以下の書籍をターゲットとした読書会なのです。
参加者は6人かな。
場所は新宿の
マルチメディアスクールWAVEです。会場の無料提供、感謝！
私、この勉強会が初のRailsです。
なんでRailsを始めようかと思ったのかというと、
SQLアンチパターン読書会でO/Rマッパーの話がよく出てきて、
Railsのマイグレーションの仕組みとかに興味を持ったからです。
あと、
Rails独特の「設定より規約」というフレームワークの仕組みにも興味ありました。
ちなみに私が仕事で使ってる主なフレームワークはJavaのStruts1です。それと比較したいという思いもありました。
そんなわけでRailsの初心者向け勉強会が無いかなぁ、となんとなく探してたら見つかったのがこの勉強会だったのです。
この日のターゲットは5章「モデルとテーブル」です。さっそくマイグレーションですね。
写経で作成したアプリとソース一式は以下にアップしました。
■第3章： Railsアプリケーションを作ってみよう・Herokuにデプロイしたアプリ：
http://makopi23-rails-chapter03.herokuapp.com/・ソース一式（Github）：
https://github.com/makopi23/Rails_Programming_Using_Heroku/tree/master/chapter03/myapp■第4章： コントローラーとビューをマスターしよう・Herokuにデプロイしたアプリ：
http://makopi23-rails-chapter04.herokuapp.com/sample/index・ソース一式（Github）：
https://github.com/makopi23/Rails_Programming_Using_Heroku/tree/master/chapter04/myapp■第5章： モデルとテーブル・Herokuにデプロイしたアプリ：
http://makopi23-rails-chapter05.herokuapp.com/sample/index・ソース一式（Github）：
https://github.com/makopi23/Rails_Programming_Using_Heroku/tree/master/chapter05/myapp
あと、参加者の吉村さんがアジェンダ資料を作成し説明してくださいました。
資料は以下に公開されています。
http://sasoonware.com/file/heroku_rails_05.pdfhttp://sasoonware.com/file/heroku_rails_05.pptx 今回、環境面と書籍の誤植によりかなりハマったので、以下メモを残しておく。
■Railsのバージョン不一致により、Heroku上での実行時にエラー発生書籍の1章（P.16）でRailsをインストールする説明があり、以下のように記載されています。
このままだと現状ではRails 4がインストールされています。
Rails 4だと、アプリをHerokuにデプロイしてもエラーになってしまいます。
なので、Rails 4をアンインストールし、Railsをバージョン指定でインストールしなおす必要がありました。
Rails 4をアンインストール。
gem uninstall rails
gem uninstall railties -v '4.00' |
Rails 3.2.13をインストール。（バージョンを指定する必要がある）
gem install rails -v 3.2.13 |
■4-4節以降の、パーシャル使用時のパス指定が間違っている4-4節で、P.177の最終行に以下の記述があります。
今回のサンプルでは「layouts」フォルダの中に、新たに「partials」というフォルダを作成することにしましょう。
そして、_myheader.html.erbと_myfooter.html.erbをこのフォルダ内に移動してください。このフォルダ構成にした場合、リスト4-24以降のrenderのパス指定が間違っている。
■リスト4-24（P.179）【誤】<%= render "partials/myheader" %>
【正】<%= render "layouts/partials/myfooter" %> |
"layouts/"がこれ以降、すべて抜けているので注意。
読書会で質問させていただいて、無事解決しました。
他にも誤植がチラホラと。。。
★感想：Railsのマイグレーションを初めて使ったわけなんですが、独特ですね～。
SQLを一切使わずにDBとやり取りすることができるということで、こんな仕組みもあるんだなぁ、と。
あと、全テーブルに"ID"というカラムが付与されますが、これはまさしくSQLアンチパターンの3章に出てきた「IDリクワイアド」！
RailsのID自動付与パターンは、「アンチパターンを使ってもいい場合」として紹介されていましたが、なるほどなぁ、と実感してみたり。
次の6章のタイトルは「モデルをさらに使いこなそう」ということで、Railsのマイグレーション機能に更に深入りできそうで楽しみです。
参加者の皆様、会場を無料提供してくださった
マルチメディアスクールWAVEさま、ありがとうございました。
2013/8/1(木)「Developers Summit 2013 Summer」に参加してきました。
・公式サイト
http://event.shoeisha.jp/devsumi/20130801/・講演関連資料のまとめ
http://codezine.jp/article/detail/7305昨日、基調講演についてブログ書きました。
今日はその続き。手元のメモをダラダラを書き起こしてみる。
■【A1】基礎からわかるDevOps吉羽龍太郎 氏
セッション概要：
http://event.shoeisha.jp/detail/46/session/84/Togetter：
http://togetter.com/li/541311 メモを取ったファイルがどっかいっちゃったので省略・・・
吉羽さんの講演スライド、充実してるのでそちらで。。。
■【A2】DevOps × Enterprise長沢智治 氏
セッション概要：
http://event.shoeisha.jp/detail/46/session/87/Togetter：
http://togetter.com/li/541323 ■戦略的なITがビジネスの成功を左右する時代へ（P.5/42～）・DevOpsはビジネスからの要請である。
・ビジネスアジリティに対応するのにITの力が必要である。
・IT自身もアジリティを意識しないといけない。
・それでビジネスに変化を与えないといけない。
■ビジネスモデル（P.8/42）・今は、ITの力を使ってビジネスを立ち上げる時代。
■意思決定（P.9/42）・昔は、IT部門はコストセンターだった。
・今の時代は経営者は当たり前に絡んでいる。ビジネスの相手の動向に応じて状況が変わる時代。
・今はIT部門だけの領域ではない。
■エンタープライズアプリの進化（P.12/42）・アプリの進化について見ていくと、「基礎体力的なIT」と「攻めのIT」の2種類がある。
・前者（基礎体力的なIT）はパッケージカスタマイズが代表例。
→ これは他社もやっている。長い人月のサイクルでコンテンツを蓄積していくタイプ。
→ 今は「基礎体力的なIT」だけでは勝てない。
→ 競合他社に勝つビジネス、やったことないビジネスにチャレンジする必要がある。
・欧米では、他社に勝つために投資している。それをカスタムアプリケーションと呼んでいる。（攻めのIT）
■エンタープライズのITのユーザー（P.13/42）・ユーザはコンシューマだけじゃなく、従業員も入る。
・より最適な形でコミュニケーション、コラボレーションして事業を推進しなくてはならない。
・「それってスタートアップでやってる事だよね」とか「エンタープライズだと適用できないよね」という声が必ず挙がる。
・でも、それが段々スタンダードになる。
・エンプラでもDevOpsやらないと勝てないよね、という事例が増えている。
■ムーブメントはすでにエンタープライズに（P.14/42）・エンプラのITは、インフラの自動化は進んでいる。
・仮想化するだけじゃなく、上手く使っていくとこまで来ている。
・パブリッククラウドとプライベートクラウドをシームレスに連携させている。
・インフラは整っている前提で、アプリでどう価値を生むかを考えていく段階。
■DevOps（P.16/42）・Microsoftは2011/6からDevOpsを使い始めている。
・継続価値のデリバリーを提供している。
・継続的フィードバックのコンセプト。
■Ops（P.18/2）・システムの自動管理はもうできている。
・運用は長期戦。SLAとかが絡んだり、いかに継続するかが重要となる。
・最近は、クラウドとか自動バックアップが充実してるので、ディスクが壊れたとかは気にしなくなってきた。
・それよりも気にするのは、「アプリが使えなくなった」。アプリが動かない、というのはなかなか治らない。
・Opsから見ると、自動管理の中にアプリが乗り切れてない。
■Dev（P.19/42）・「開発ってブラックボックスだよね」、「出てきたものは使われないものだよね」となってしまいがち。
・でも、ビジネすにはアプリが必須。重要なのは、変化に如何に対応するか。
・作って終わり、というものはない。ビジネスモデルが変化する時代なので、アプリも変わり続ける必要がある。
■P.20/42・DevとOpsの立ち位置にはギャップがあるので、それを理解することが大事。
・共通のゴールを持つこと、自動化や共同所有が大事。
■P.22/42・DevOpsには課題がたくさんある
・私はDev側だからOpsは関係ない、という姿勢はダメ。
■Operations readiness（P.24/42）・品質を作り込んでおかないと、運用にしわ寄せが行く。
・サイクルタイムの期間が長すぎたら、使われなくなる。
・定期的かつ短い期間で提供する。アジャイルのプラクティスが参考になる。
■Mean Time To Repair - MTTR （P.26/42）・できるだけ本番環境にしわよせこないようにしたい。
・開発の段階で、本番に近い状況で回ってる状況にしたい。
■【B3】DevとCustomersの協業を目指すサステイナブルSIの進め方鈴木雄介 氏
セッション概要：
http://event.shoeisha.jp/detail/46/session/91/Togetter：
http://togetter.com/li/541339 ■DevOpsと最近のトレンド（P.7/44）・運用と開発が協力しあうムーブメント。
・小さなリリースをたくさんしていく、というアジャイルのメソッドを使った開発・運用の仕方。
■リーンスタートアップ（P.10/44）・ITを企画する部門も、指標化して評価して、フィードバックしていくことが現在の流れ。
■IT系トレンド概要（P.11/44）・企画・開発・運用の３つのトレンドがまわるのが昨今のトレンド。
・グロースハッカーは真ん中。
グロースハッカー（Growth Hacker）とは？・プロダクトやサービスのGrowth（＝成長）をhackする人たちを指すらしい。
・「ユーザー獲得担当エンジニア」などとも呼ばれているらしい。
・参考文献： IT自分戦略研究所
http://jibun.atmarkit.co.jp/lcareer01/special/gh/01/01.html■まとめ（P.12/44）・DevOpsは個別のプラクティスがどうこう、じゃなくて全体で考える。
・流れの原点はアジャイルだと思っている。
・アジャイルを全体にぐるぐる回していきましょう、があるのかな、と思っている。。
・アジリティが大きなテーマ設定。
■アジリティを支えるツール群（P.13/44～）・ツールをなんで使うのか？を考える上で、セグメントが３つ（企画/開発/運用）に分かれているのがポイント。
・３つのセグメントで、それぞれ立場の違うメンバがフィードバックを求める。
・その結果をバックログとして管理するのにツールが大事になってくる。
■Atlassian製品の紹介（P.18/44～）・（省略）
■エンタープライズはどうなんだ？（P.30/44）・ITサービスのアジリティを出して行く時に、エンタープライズでどうやっていくのか。
■エンタープライズ業界（P.32/44）・ITだけで完結しない業務がある。
■エンジニアの配置（P.33/44）・IPAの調査結果： 日本は米国と違って、ユーザ企業側にエンジニアが少ない。
→ なので、受託しないといけない。
■SIerの役割（P.32/44）・でも、受託は利益相反になる。
■エンプラでのアジリティ（P.35/44）・顧客をフィードバックループに巻き込むのことが大事。
・でも、めんどくさいじゃん。
■取り組み(3)（P.39/44）・CIはお客さんにとって価値じゃないので、きちんと継続的リリースするところまで持っていくことが重要。
■組織パターン（P.41/44）・4.2.6節「顧客たちを巻き込め」
・Q&A表をExcelで送りつけるようだと上手く行かない、と書いている。
・自由なコミュニケーションが大事。
■まとめ（P.42/44）・SIerが変えていこうと思わないとエンタープライズは変わらない。
■【B4】国産業務PaaSを担いで稼ぐ方法 ～SIerの生き残る道の1つとなるか？ ～吉田雄哉 氏/林哲也 氏/安立雄亮 氏
セッション概要：
http://event.shoeisha.jp/detail/46/session/94/Togetter：
http://togetter.com/li/541343 ■パブリッククラウド（P.7/43）・日本でのクラウドはキャズムを超えて、Early Majorityを超えてピークに差し掛かっているくらい。
■顧客は何を求めてる？（P.9/42）・顧客は、業務知識を持ってるエンジニアを求める。
■事例紹介省略
■まとめ・クラウドベンダーを見ると、似たようなものが横にある状態。
→ 差がよくわからない。
→ でもアピール側からすると、できることをいろいろ言わないと、まな板の上に乗れない。
→ なのでユーザがきちんと選ぶ必要がある。いろいろあって、「選べること」が重要と認識する。
■【A5】黒帯デベロッパーたちにきく！「DevOpsって本当のところどうなのよ？」大石良 氏/宍倉功一 氏/伊藤直也 氏
セッション概要：
http://event.shoeisha.jp/detail/46/session/96/Togetter：
http://togetter.com/li/541332 ■今日の見所・スーツ派が勝つか、ギーク派が勝つか。
■宍倉さんのDevOps（P.12/40）・10名チームのうち、インフラ担当は1名。
・最初は手作業でデプロイをしていた。
・Eightをリリースする際に、インフラをすべてAWSに移行した。
・運用側と開発側で何ができるかを話したところ、以下のような話が出た。
- EC2インスタンスを自動で構築したい
- デプロイを簡略化したい
→ 3週間で運用の仕組みを考えた。大石さんのところに相談した。
・Chefとかを連携させた。そこがスタート。
・開発側と運用側が同じツールを見るようにしている。
→ お互い有用な情報を出す自前のツールを作って、シンプルに見せれるようにした。
■伊藤直也さんのDevOps（P.14/40）・はてなで、二人か三人でサーバ1,000台を担当。
・最初は手作業でやってたが、追いつかなくなった。
・開発の要望に運用が答えられなくなって、DevとOpsに距離ができた。
・データセンターに繋げばOSのインストールとか自動でやってくれるツールを導入してから、楽になった。
・インフラを自動化することをやって当たり前の考えになった。
・はてなCTOの田中さんがpuppetに着目した。
・「テスト駆動インフラ構築」は宮下さんが2007年に公演してて、2009年のFlickerの発表より前からあった。
■DevOpsの定義（P.15/40）・DevとOpsがくっついて、アプリの文脈を取り入れてやっていきましょう。
・DevとOpsの溝をなくして、同じ方向を向いて走りましょう。
・今は、Chefとかpuppetとかを使ってやっていきましょう、という狭い話が多い。
・今はクラウドが当たり前になって、サーバの上げ下げや手動構築が大変になった。
・サーバの構築機会が劇的に増えた。なのでDevOpsを意識する場面が増えた。
■宍倉さんにとってのDevOpsのメリット・開発に対しての品質とかスピードにメリットがある。
・短期間の間にリリースしてフィードバックを得て次に活かすか、が重要。
・DevとOpsで、互いにツールを理解する文化ができて、スピードが加速することができるところがメリット。
・工夫としては、DevとOpsの席を物理的に近くするようにした。
・あと、仕様会議もDevとOpsが話しあって進めるようにした。
■問題提起（P.19/40）・DevOpsが良いのはわかったけど、使われないのには理由があるはず。
・現実として、開発と運用って契約が分かれてたりするので、そこがネックとか。
■「DevOpsってハードル高すぎない？」という意見に対する、宍倉さんの考え（P.21/40）・大丈夫です。
・お互いの教育が必要。
・Infrastructure as Codeと言われるが、これまでインフラ担当はプログラミングはしなかった。
・でも、今はWebとかに情報が多い。
・DevとOpsでペアプロとかやれば、Opsがプログラミングを勉強できる。
■P.20の②③に対する、伊藤さんの考え（P.22/40）・③は誤解。考え方が逆になっている。
・運用担当者の頭にしかなかった暗黙知や手順書をコードで表現する。
・コードをリポジトリに入れてシェアすれば、見える化した状態で保存できる。
・新しい人が入ってきてもそれを流せば同じことができる。属人性を省く処方箋となる。
・②についてだが、DevOpsはアジャイルの文脈と近い。
・なんでもアジャイルやればいいわけではない。
・DevOpsも同じ。契約上、運用と開発が分かれているのにDevOpsを無理にはやらない。
・でも、やれるならやればいい。
・DevOpsはキーワードが独り歩きしている。
・アジャイルが今響かなくなってきているから、DevOpsというキーワードが出てきた。
・既存のやり方にストレスを感じているのをなんか変えていきたい。その１つがDevOpsである。
・Webサービスとか自分たちで見てて、リリース後も見ていく状況では、DevOpsはやったほうがいい。
・AWSとか使うんだったら、仮想化でハードがソフトになったので、既存のやり方を疑ったほうがいい。
・今はソフトになって、ハードの制約がなくなったのに、従来とやり方を変えてないのはおかしいんじゃないか。
■Biz側からツッコミ（P.26/40）・DevとかOpsとか、企画営業からみたらどーでもいい。なんかメリットあるのか？
■宍倉さんの回答・早くアウトプットしてフィードバックを受けるにはDevOpsが必要となる。
■Biz側からのツッコミ（P.28/40）①予算が開発と運用で分かれていた時どーする？
②DevOpsってサービス開発にしか使えないんじゃ？
■伊藤さんの回答・①はそのとおり。
・アプリ開発とインフラ構築運用には差がある。そーゆう組織にする努力は必要。
・結局は何をゴールにしたいか。
・Ops側が自動化して楽にしたいというのもアリだが、ビジネスのスピードを上げたいのでアジャイルは常識。
・ゴールはそこ。そこはマネジメントの問題。
・DevとOpsが同じゴールを向いて走れるようにする。DevとOpsの間を埋めるのはマネジメント。
・②は、必ずしもそうではない。
・これから継続的開発はあたりまえになる。
・DevOpsの使えるところからやっていく。
■SIにDevOpsを導入するには？（P.32/40）●宍倉さん
①小さなところからやる
②自分のまわりから、お互いが連携できるところはなんだろう、と１つ１つ会話してやっていく。
●伊藤さん
・最近、クライアントからAWSを使って欲しい、アジャイルやってほしい、といったようなリクエスト増えた。
・それは、期待に答えて欲しい、というメッセージ。それ自体が目的ではない。
・どうやるかより、そもそも何がしたいのかを決めないとダメ。
・プロセスだけ効率化しても意味はない。
・そこから定義していくことが大事。
★感想：DevOpsについて、いろんな方からいろんな観点でお話を聞くことができました。
DevとOpsが共通のメトリクスで判断をしていく話とか、Infrastructures as Codeの話とか、できるところからやっていけたらいいかな、と思ってます。
少なくとも弊社の現状では、コード書ける人ばっかじゃないので、すべてDevOpsやるのは難しいかなぁ、と。
でも、インフラ屋さんもDevOpsの概念くらいはまず理解してほしいと思う。
・・・と、いろいろ悩むのであった。
デブサミの皆様、有意義なお時間を提供いただきありがとーございました。
2013/8/1(木)「Developers Summit 2013 Summer」に参加してきました。
・公式サイト
http://event.shoeisha.jp/devsumi/20130801/・講演関連資料のまとめ
http://codezine.jp/article/detail/7305場所は渋谷の「ベルサール渋谷ファースト」さんです。
ここ、他の勉強会で行った事あったので道はすぐにわかったけど、なんの勉強会だったっけな。。。
暑すぎて、到着までに全身汗だく。。。
参加者ですが、申し込みの時点で1000人を超えていたとのこと。
大イベントです。
ちなみにテーマはDevOps！
私、自社でDevOps関係のワーキンググループにメンバーとしてちょうど放り込まれたところだったので、今回のイベントはまさしく、渡りに船！
あと、1週間くらいまえに横浜道場で行われた長沢さんによるDevOpsの講演も聴講してきたところでした。
そんとき書いたブログはコチラ。
ちなみにこのデブサミには、会社の業務の一環として参加しました。
なので会社への簡単な報告のために聴講メモを書かないといけません。
そんなわけで今更感がありますが、ついでにブログにメモを書くことにした。
あと個人的な復習も兼ねて。
いつもどおり人が読むことは想定せず、自分の復習用にダラダラと書き連ねることとするのであった。。。
講演は丸一日で量が多いので何回かに分けて書きます。今日は「～其の１～ 基調講演」
スライドにない口頭部分を中心に、メモ。
基調講演DevOpsを実践されている5名のエンジニアによる基調講演です。
■【S1】DevOpsは開発現場とビジネスの間に何を生むか？・講演者： 新野淳一 氏/長沢智治 氏/浦底博幸 氏/山本正喜 氏/藤井智弘 氏
・URL：
http://event.shoeisha.jp/detail/46/session/83/■新野淳一 氏 ■DevOps、国内での盛り上がり（P.3/24～P.4/24）・国内でDevOpsというキーワードが出始めたのは2010年くらい。
■DevOpsの始まりと広がり（P.4/24）・DevOpsが登場したのは、2009年にオライリーがVelocityというイベントをやった時。
・この時がDevOpsのキーワードの原点。
・Flickerの講演で「1日に10回もデプロイしている」という話があり、当時、DevOpsは驚きをもって迎えられた。
・それはイイね、ということで次に「DevOps Days」というイベントをやった。これがDevOpsを広める原動力になった。
■最初は相手にされなかったDevOps（P.6/24）・ここ数年、開発と運用が協力する、という考えはアジャイル系カンファレンスでも相手にしてもらえなかった。
・でも、「DevOps」というキーワードが出てきたことが大事。
■DevOpsの原点を再訪（P.7/24～P.）・DevOpsの大事なことは、原点である。
→ 原点とは、Flickerの2009年の講演スライド「10 deploys per day dev & ops cooperation at Flicker」。
→ ここに大事なことはだいたい書いてある。
■DevOpsの原点（P.8/24～P.9/24）・ビジネスは変化を要求してくる。
・でも、変化はリスクを伴う。「動いているシステムに手を入れるな！」という声がある。
・そこで、変化のリスクを下げるために、
ツールとカルチャーを使うんだ。
・変化を要求されていないビジネスにはDevOpsを使う必要はないかもしれない。
・
ツールだけでもなく
カルチャーだけでもない。両方使うんだ。
■カルチャーとは？（P.10/24）・DevとOpsは仲良く物事を進めていきましょう、という考え。
■ツールとは？（P.11/24）・ツールを使って以下を実現する。
１．インフラを自動化する。
２．エンジニアの間でソースコードの共有をして、バージョン管理をする。
３．ボタン１つで、バージョン管理されているソースをビルドして、デプロイまでワンステップでできるようにする。
・DevOpsの原点は、カルチャーとしての運用者と開発者の協力と、ツール。
■DevとOpsの言い分（P.12/24）・両者の言い分はよくわかれる。それぞれ「俺たちがビジネスを支えているんだ」という言い分。
■DevとOpsの協力関係のあり方（P.13）・カルチャーとツールを使って、互いに協力していきましょう。
■で、うまくいってるの？（P.14/24）(1) Dev： 継続的デプロイメント ・ツールとして典型的に使われているのは継続的デプロイメント。
・これをしなきゃいけないわけではないが、よく言われているツールと方法論。
(2) Ops： Infrastructures as Code ・インフラをコード/ソフトウェアとして捉える。
-----
・大事なのは、ビジネスの側にとって、それが上手く行っているかどうか。
・DevとOpsが仲良くても、ビジネスが前進してなきゃDevOpsをやる意義は低くなる。
・DevとOpsだけじゃなく、Biz(Bisiness)から見ても上手く回らないといけない。
■メトリクスで判断しよう（P.15/24）・運用側から出てくるログを解析して、メトリクスを取り出す。
・あらかじめメトリクスを決めておく。
・ログを見て「滞留時間が長くなってるね」とか「バスケットに入れたものがちゃんと購入までいってるね」とか、DevとOpsがメトリクスを共有して判断に役立てること。
■メトリクスはすりあわせが肝心（P.16/24）・メトリクスを予めDev/Ops/Bizですり合わせておくのが大事。
・「このシステムでは、このメトリクスを向上させるために協力するんだ」という考えを互いにすりあわせる。
・このシステムのログからどんな情報が取り出せるのか、あらかじめ考えておかないといけない。
・必ずしもシステムでログから取り出せる情報だけで評価できるとは限らない。
・メトリクス以外で評価すべきことはあるかも考える。
■エンタープライズでの課題 -日本のSIビジネスにDevOpsは適用できるのか？-（P.17/24）・DevOpsはFlickerから始まった。オンラインサービスとかスタートアップに近い。
・DevOpsをエンタープライズのSIビジネスにも適用できるのかというと、いくつか課題がある。
・サービスはDev/Ops/Bizの3者が協力しやすいが、SIerだと組織が違ったりとハードルがある。
・でも肝心なのは、ビジネスを前進させることが本質。
・ならば、ビジネス側の人が「DevOpsが大事」だと認識しないといけない。
・DevもOpsも、Biz側に情報を提供しないといけない。
■エンタープライズでの課題 -BizとDev/OpsはDevOpsのメトリクスを握れるのか？-（P.18/24）・エンジニアがビジネスの要件を把握して、対話して、１つのメトリクスを共有する必要がある。
・エンタープライズは、社内の社員が客かもしれない。
・なので「ログからメトリクスを取り出せるのか」という問題がでてくる。
→ ログ以外のメトリクスを考える必要がある。
■エンタープライズでの課題 -どのプロジェクトをDevOpsで進めるか、選べるのか？-（P.19/24）・ある程度フォーカスを絞ってプロジェクトを選択する。
・コストとメリットのバランスを考慮して考えていく。
■エンタープライズでの課題 -そもそもアジャイルやクラウドの採用にハードルがあるのではないか？（P.19/24）・そもそもアジャイルとかをエンタープライズに採用するのに抵抗がある組織が少なくない。
・カルチャーは作れるが、ツールをどうやって説得して採用していくかのハードルがある。
・答えはない。
・こういう課題があることを認識したうえで、乗り越えて行かないといけない。
・このあとのリレートークで議論できればいい。
■山本正喜 氏 ■自己紹介（P.2/21）・ChatWork株式会社は、Webのベンチャー。従業員は30人くらい。
■チャットワークのコンセプト（P.3/21）・左にチャット、右にタスク管理の画面。
・会話しながらタスクを洗い出して残すことができる。
■DevOps？（P.8/21）・Dev:どんどん機能追加したい vs Ops:安定運用したい
・この構図は、我々はピンとこなかった。というのも、社内でDevとOpsはあまり衝突してない。
・社内で自然にDevOpsをやっていた。
■CahtWorkにおけるDevOpsの考え方「極力"運用"しない」（P.10/21）・Dev: １１人
・Ops: ２人
・実質、一人弱で運用してる。
人が少ないとコミュニケーションコスト下がる。
■大規模チャットシステムにおける運用の勘所（P.11/21）①データベース：
・書き込みが多い。Write-heavy
②ファイルサーバ：
・果てしなく容量が増えるので、どうスケールアウトさせるか。
③リアルタイム通信：
・すぐ発言を相手に届ける必要があるので、ポーリングじゃダメ。
・でも繋ぎっ放しにするとc10k問題に直面する。
→ マネージドサービス（PasSとかSasS）をフル活用している。
■Leanなサーバアーキテクチャ移行（P.15/21）・プロダクトの成長がある。
・PasSから、それじゃ合わないのでPasS + IasSにした。
・成長にともないIaaSの比率を上げていく。
■障害発生時のフロー（P.16/21）・基本的に自動復旧
・気づいた人がOpsチームに連絡
→ 自動復旧できたか確認
■ChatWorkにおけるDevOpsの考え方２「DevOps + Biz」（P.17/21～P.19/21）・ビジネス部門との協力が不可欠。
・全社的に見る必要がある。
■ChatWorkl社で取り組んでいること（実践）（P.20/21）①ほとんどのコミュニケーションはチャットで。
・メールしない。全部チャット。
・隣にいる人にもチャットで。
・チャットだと全部記録に残る。口頭での「言った/言ってない」が無くなる。
・全員在宅勤務でもいける。エンジニアの集中を妨げない。
②プロジェクトごとにグループチャットを作成し、関係者を全員入れる。
・グループチャットに必要な人を全員いれる。Dev/Ops/Biz問わず。
③タスクの生まれる背景を共有する。
・推測せざるを得ない状況をなくす。
・背景の段階から共有する。それがコツなんじゃないか。
■長沢智治 氏 ■ビジネスニーズと戦略的なIT（P.2/22～P.5/22）・エンタープライズでは、ビジネスニーズからDevOpsがきている。
・ビジネスがITの力を必要としてきている。ITの活躍できる場所は多い。
→ ビジネスを考える上で戦略的なITを考えざるを得ない。ビジネスとITを融合させる。
■エンタープライズでのITの"ユーザ"とは？（P.6/22）・エンタープライズでのDevOpsでは、ユーザが誰になるかを押さえることが重要。
・コンシューマだけじゃなく自社の従業員のこともある。
■エンタープライズアプリケーションの進化（P.7/22）・「基礎体力作りをするIT」と「攻めのIT」は別として考えないといけないこともある。
・従来はERPのカスタマイズが中心だったが、これからはブランド力をもって競合他社に勝ち続けるモデルを作る必要がある。
・どこの部分をDevOpsでやるべきなのか見極める必要がある。
■ビジネスにフォーカスした戦略的なIT？（P.9/22～P.15/22）・課題は「インフラにのせるアプリ」。でも開発の中身がよく見えない。
・ひとつのアプリの状況に合わせるのは難しい。
・DevとOpsが対立構造になることが多い。
■共通ゴール（P.16/22）・サイクルタイムとMTTRを短くすること。
①サイクルタイム ＝ 企画からリリースまでの時間。 ・サイクルタイムの「定期的」という概念は大事。ビジネスパーソンが分かるペースが大事。
②MTTR ＝ 障害が発生したときに普及させる時間。Mean Time To Repair。 ・これからは壊れることを前提にしないといけない。いかに早く治すか。
・サイクルタイムとMTTRは両方とも、DevとOpsに関わる。
・ITに近いメトリクスとしては、この２つが手っ取り早い。
・測るには、成果物を共同所有しておくことがポイント。
■DevOpsへの主な課題のポイント（P.17/22）・昔に比べ、ソリューションは格段に増えた。
・それらをどう使っていくかを考える必要がある。
■MicrosoftとDevOps（P.20/22）・マイクロソフトでは継続的デリバリをやっている。
・今は３週間単位で作っている。
・DevOpsはパッケージ開発まで波及してきている。
・今まで適用できないと思っていたところでもDevOpsの考えは適用することができるようになった。
■浦底博幸 氏■Opscode Chef・単なる自動化ツールではない。
・インフラの姿をコードで定義可能。
・インフラをモデル化してしまおう。
■インフラをコードで定義することで・コードの共有はチームに閉じない。様々な企業間で共有して、業界全体の品質が上がる。
・TDDが可能になる。
・作業手順でなく、状態を定義する。
■Code Can...・Opscodeのコンセプトは「CODE CAN」
・コードによって可能性が広がる。戦略性、革新性、可用性、一貫性、堅牢性、etc
■Coded Business・コードをベースとした文化によって、ビジネスも変わっていける。
■Dev + Ops = Change・changeを受け入れられるかどうかで日本とアメリカは違う。
■デモ（省略）
■Q&A・Chefには3種類ある。
・今回のデモで使ったのはHosted Chef。
・まずはChefを入れて動かしてみましょう。
・ChefはRubyやってると取っ付きやすい。
■藤井智弘 氏 ■自己紹介（P.2/24）・日本ヒューレット・パッカード所属。日本だと運用系のツールが高い評価を戴いている。
・「ディシプリンド・アジャイル・デリバリー」という書籍を最近訳した。
■"エンタープライズ","DevOps"？（P.3/24）・以下2種類がある。
(1) サンドボックスタイプ
・「新規ビジネスをやります」ということでプロトタイプ作ってやるタイプ。
・リーンスタートアップに近いやり方。
(2) BETAタイプ
・べたなエンタープライズ。
■"BETA"なエンタープライズの特質（P.4/24）①しがらみがある。
・他システムとの連携のしがらみだったり。
・運用一筋何十年という人もいたり。
②スキル
・エンタープライズだとテスターさえプログラム書けないのが当たり前だったり。
③別にそんなに頻繁に"リリース"しない
・なので、エンタープライズにDevOpsっていらないんじゃ？
■ギャップは、"BETA"なればこそ（P.5/24）・体制が確立されているべたなエンタープライズこそ、DevOpsのギャップが出る。
・図で、左のDevOpsは「開発側視点」、右のOpsDevは「運用側視点」。
・DevOpsは頻繁リリースが注目されるが、そこがビジネスの中心でない。
・P.6のプロセス成熟度の話はあとでブログに載せる。
■リリース・プロセスの効率化（P.8/24～）・今まではビルドとかリグレッションテストとか、図の枠１つ１つを自動化していた。
・DevOpsではそれじゃダメ。
・ステージがある。
・リリースプロセスに対して、リリースのステージングで適切なタイミングで適切なテストを行う。
・ステージが違うということはインフラが違う。
・テストを自動化しても、インフラのミスマッチで無駄なテストが出る。
・我々がやりたいのは、リリースプロセスの効率化ではなく成熟化。
・アジャイルだろうがなんだろうが関係ない。
■サンドボックスから開放せよ（P.22/24）・DevOpsをサンドボックスから開放して、エンタープライズに持って行きたい。
★感想：基調講演だけでお腹いっぱいになるくらい充実した講演でした。
特に響いたのが「Infrastructures as Code」という用語ですね。
この日ここで初めて聞きましたが「インフラをコード/ソフトウェアとして捉える」という概念は斬新ですね。
Gradleとか、まさしくこれが当てはまる気がします。
明日以降、基調講演以外もブログ書く予定です。
どうせ会社に聴講報告せにゃならんし、自分の復習にもなるし。
講演者のみなさま、ありがとうございました。
2013/8/8(木) SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/5065以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、アルティネットさんです。
参加者は9人かな。
今回は7章「マルチカラムアトリビュート（複数列属性）」が範囲でした。
■模造紙＆付箋いつもと同じく、ディスカッションしたいネタをみんなで最初に書き出しました。
あと、今回のアジェンダスライドは @naopi さんが作成して説明してくださいました。感謝！
以下、写経＆読書会のメモ。
写経用に用意したSQLはコチラ：
20130808_sqlap_Multi-Column.txt特に、興味深い以下3点を中心に写経してみました。
(1) [7.2.2節] DBMSの違いによるadd-tag.sql挙動調査 (MySQL, ORACLE, HiRDBの3種類)
(2) Array型カラム
(3) [7.5節] 解決策：従属テーブル方式への具体的な移行方法順に書いてみる。
■[7.2.2節] DBMSの違いによるadd-tag.sql挙動調査
(MySQL, ORACLE, HiRDBの3種類)今回、写経をしてきた @tonyuchi さんから面白い報告がありました。
7.2.2節の add-tag.sql の挙動が、ORACLEだと書籍どおりにならないとのこと。
■7.2.2節 [add-tag.sql]UPDATE Bugs
SET tag1 = CASE
WHEN 'performance' IN (tag2, tag3) THEN tag1
ELSE COALESCE(tag1, 'performance') END,
tag2 = CASE
WHEN 'performance' IN (tag1, tag3) THEN tag2
ELSE COALESCE(tag2, 'performance') END,
tag3 = CASE
WHEN 'performance' IN (tag1, tag2) THEN tag3
ELSE COALESCE(tag3, 'performance') END
WHERE bug_id = 3456; |
これは面白そうだ！ということで、私も以下3種類のDBMSを使って、試してみることにしました。
(1) MySQL 5.1.37
(2) Oracle Database Express Edition 11g Release 2
(3) HiRDB Server Version 9 (09-00-T1)
---
(1) MySQL 5.1.37①SQL実行前tag1, tag2, tag3にNullをセットしておく。
②SQL実行後
tag1のみ、'performance'が代入されました。これは
書籍どおりの挙動ですね。
(2) Oracle Database Express Edition 11g Release 2①SQL実行前tag1, tag2, tag3にNullをセットしておく。
②SQL実行後
おお！ @tonyuchi さんが言っていたとおり、
tag1～tag3が全部、performanceになりました。これは
書籍とは異なる挙動ですね。
(3) HiRDB Server Version 9 (09-00-T1)①SQL実行前tag1, tag2, tag3にNullをセットしておく。
②SQL実行後
ありゃ、エラー・・・
エラーメッセージID "KFPA11417-E" でマニュアルを見てみると、
IN述語の左側のオペランドに定数はダメとのことｗｗｗ
HiRDB、氏ねよｗｗｗ
読書会でもP.83の search-two-tags.sql で「IN述語ってこんな使い方もできるんだねー」と話題になってたんですが、
どうやらこれはMySQLとOracleはOKで、HiRDBだとNGらしい。SQL標準じゃないのかな？
---
原因は、トランザクション分離レベル？HiRDBはさておき、和田さん曰く、MySQLとORACLEで挙動が異なる原因としては「トランザクション分離レベル」の差異が怪しいとのこと。
トランザクション分離レベルは4種類あります。IPAのデータベーススペシャリスト試験でよく出題される奴ですね。
・SERIALIZABLE ( 直列化可能 )
・REPEATABLE READ ( 読み取り対象のデータを常に読み取る )
・READ COMMITTED ( 確定した最新データを常に読み取る )
・READ UNCOMMITTED ( 確定していないデータまで読み取る )
トランザクション分離レベルについて詳しく書かれているORACLEのマニュアルはこちら。
http://docs.oracle.com/cd/E16338_01/server.112/b56306/consist.htmこれについてはちょと調査に時間かかりそうなので、ここではいったん保留する。
なんかわかったら後で追記するかも。
■Array型カラムマルチカラムアトリビュートって第１正規形だよね～、とかディスカッションしてる最中にふと思い出したのが、Array型カラムです。
そういやHiRDB(笑)にあったなぁと。あとで付箋を追加した件です。
なので試してみる。
■Array型カラムを持つテーブルの作成こんなカンジでArray型カラムを作れます。tag1,tag2,tag3ではなく、tag Array[3]。
■Array型カラムへのInsertこんなカンジでInsertできます。
■Array型カラムのSelectこんなカンジでSelectできます。
HiRDBのArray型カラムのマニュアルはこちら。
http://www.hitachi.co.jp/Prod/comp/soft1/manual/pc/d645140/W4510057.HTMちなみに配列（ARRAY)型はSQL99でサポートされているそうです。
■オブジェクト指向、Javaを取り入れた新しい業界標準「SQL99」詳細解説 第二章 柔軟さを増したデータ構造（1）
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_2a.htmlHiRDBとPostgreSQLではサポートされていることを確認しましたが、
MySQLとORACLEはサポートしてないみたい。
■[7.5節] 解決策：従属テーブル方式への具体的な移行方法書籍の7.5節に書いてある解決策ですが、具体的な手順までは書いてません。
なので、ディスカッション時のネタとして付箋に書いておいたら、和田さんにご教示いただけました。
今回の考え方としては、横縦変換をする、というイメージですかね。
基本は書籍「データベースリファクタリング」に書いてある手順がベースです。
実際にやってみた。
■手順１：移行用テーブルの準備まず、Bugsテーブルの移行先として、Bugs_NewテーブルとTags_Newテーブルの２つを用意する。
CREATE TABLE Bugs_New (
bug_id SERIAL PRIMARY KEY,
description VARCHAR(1000)
);
CREATE Table Tags_New (
bug_id BIGINT UNSIGNED NOT NULL,
tag VARCHAR(20),
PRIMARY KEY (bug_id, tag),
FOREIGN KEY (bug_id) REFERENCES Bugs_New(bug_id)
); |
■手順２：移行用テーブル Bugs_New に、BugsテーブルのBugデータのみ移行次に、用意した移行用テーブル Bugs_New に、
BugsテーブルのBugデータのみ移行する。
INSERT INTO Bugs_New (bug_id, description)
(SELECT bug_id, description FROM Bugs_anti); |
確認してみると、Bugsテーブルのバグ情報だけがちゃんと移行できているのがわかります。
■手順３：移行用テーブル Tags_New に、BugsテーブルのTagデータのみ移行次に、移行用テーブル Tags_New に、
BugsテーブルのTagデータのみ移行する。
INSERT INTO Tags_New (bug_id, tag)
SELECT bug_id, tag1 FROM Bugs_anti WHERE tag1 IS NOT Null
UNION
SELECT bug_id, tag2 FROM Bugs_anti WHERE tag2 IS NOT Null
UNION
SELECT bug_id, tag3 FROM Bugs_anti WHERE tag3 IS NOT Null
ORDER BY bug_id; |
UNIONを使うのと、Null以外のタグを取ってくるようにするのがポイントです。確認してみると、Bugsテーブルのタグ情報だけがちゃんとTags_Newテーブルに移行できているのがわかります。
Bugs_NewテーブルとTags_Newテーブルはまだ誰も使ってないので、堂々とINSERTできます。
■手順４：移行期間中の対処最後に「移行期間」を設け、その期間はBugs, Bugs_New, Tags_Newの3テーブルを共存させます。
んで、移行期間中にアプリ側の改修を行います。（Bugsではなく、Bugs_NewとTags_Newを使うように改修）
移行期間中も移行元のBugsテーブルへは当然アクセスがあります。
なのでBugsテーブルのデータが更新されたら、それをBugs_NewテーブルとTags_Newテーブルに反映させるための仕組みを用意します。
「データベースリファクタリング」で紹介されている手順のうち、トリガー等を使うことで実現できそうです。
■ディスカッションのメモディスカッション時に出たお話のメモ。
■なぜマルチカラムアトリビュートのような設計になるのか・RDBを、Excelのような表計算ソフトの２次元と同じように捉えている。
→ 横に長く表示されてるから、そのままDBに格納してしまえ。
・RDBは集合論、という認識が無い。
■正規化・マルチカラムアトリビュートをやってしまう他の原因としては、正規化理論を理解していない点が挙げられる。
・まずは正規化すべき。
・正規化理論は付録Aに書いてある。第1正規形の例としてマルチカラムアトリビュートも紹介されている。
■COBOLとマルチカラムアトリビュート・COBOLのレガシーシステムを横展開してもってくるとマルチカラムアトリビュートになる。
・というのも、ホストコンピュータの世界はCOBOLが多く、データを固定長で扱うことが多かった。
→ カラムを後から足せない、という制約があった。
→ じゃあ「予め拡張用の幅を事前に持たせておこう」ということで、予備カラムを事前に用意する設計にする。
→ この思想をオープン系にそのまま持ってくるとマルチカラムアトリビュート。。。
■マルチカラムとカラム名・書籍のBugsテーブルの例だと、tag1とtag2を入れ替えてもシステム的に影響ない。それはtagたちが平等だから。
・タグ付けするという問題と、ユーザを3人紐付ける、という問題は若干違う。
・後者の悪い例としては、user1, user2, user3のようなカラム設計をした場合。
→ 3人のUserの関係性を示すものがカラム名にないので、設計ドキュメントで示すしかない。
→ そうじゃなく、せめて関係性を示すカラム名をつけましょう。
・書籍P.xxiiのBugsテーブルは、reported_by, assigned_to, verified_byと3名の関係を示すカラム名にしている。
・このように3カラムにそれぞれ別名を付けられるなら、各カラムには同じ種類のデータが入ることがわかる。
・user1, user2, user3のように順序性に意味を持たせる設計はダメ。
→ 全部のレコードが各カラムで同じ意味をもつなら、上記のBugsテーブルのように、カラムに意味を持たせましょう。
・レコードによってマルチカラムの各カラムの使い方が変わる場合は、5章のEAVで紹介されていた解決策（テーブル継承）を使いましょう。
■マルチカラムアトリビュートと性能・DBの設計の基本は、まず正規化。
・でもマルチカラムアトリビュートを正規化すると、SELECT時にJOINが必要になるので性能が落ちるのでは？
→ 今はそうではない。性能が悪いなら非正規化しろ、というのは昭和の発想（笑
・非正規化で性能を出したいくらいなら、RDBではなくキーバリューストアとかのNoSQLを使用すべき。
・非正規化しよう、というのはRDBを知らなかった時代の発想。
・MySQL 5.4ではJOINの性能改善が実施されている。
■SQLに改行を入れておき、ログを見やすくする・・・？・ログを見やすくするためにSQLに改行を埋めておく、というエンジニアがいた。。。
・SQLに改行を入れてしまうと、デバッグや運用時にログが拾いにくくなる。
→ ログをGrepしても、SQLの断片しかヒットしなくなり、使い勝手が著しく落ちる。
→ ログは１情報を１行で出力しましょう。
■マルチカラムに１つだけは必ずデータを入れさせたい場合は・・・？・マルチカラムのうち、1個だけ必須（Not Null）にしたい場合がある。
→ Null不可とNull可の用途で、カラムを分ける？
・それはダメ。Null不可とNull可で、それぞれテーブルを分けるべき。
★そういや今気づいたが、従属テーブルを導入すると、バグに１つ以上のタグを必ず入れさせたい場合の制約が掛けられなくなる・・・？
■ORM・ORMを使うと、更新時は全カラム更新が基本らしい。オブジェクトの方が偉い、という思想に基づくらしい。
・S2JDBCは全カラム更新と部分更新が選べるらしい。
・ORMは内部的にLEFT JOINしてくれる。
・やってはいけないのが、「N+1問題」。
→ 発行されるSQLがN+1回になって、パフォーマンスが凄い事になる。。。
■P.84のremove-tag.sql・このSQLはイキナリ感があるが、要するに'performance'タグが付いているカラムをNULLに設定するSQL。
・'performance'タグを外したいときに使う。
・どのカラムにperformanceタグが入っているか知らなくても消せるのが利点。
■交差テーブルか従属テーブルかの選択・7.5節では、解決策として「従属テーブル」を上げている。
→ 従属テーブルは交差テーブルと違い、異なるbug_idに対して似たようなtagがたくさんできる。
→ 複数のbug_idに紐づく同じtagの名称を書き換えたい場合、手動で複数個を修正する必要がある。
・従属テーブルでなく交差テーブルにした場合、Tagsテーブルはカラムとしてtag_idとtag_nameを持つ。
→ tag_nameを書き換えると、そのtag_idに紐づくバグのタグ名がすべて書き換わる。
・タグ名をかえると全部変わるようにするか（＝ 交差テーブル）、ぜんぶ手動で変更しないといけないようにするか（＝ 従属テーブル）は、用途に合わせ設計で決める。
■あえてマルチカラムアトリビュートにする場面・「タグは絶対に3個までなんだ！」という個数情報をカラム数で示したいために、あえて正規化しない判断もあるのでは。
・要するに、あえてマルチカラムアトリビュートにして、カラム数を物理的に制限したい場合とか。
→ カラム数で制限することが有効に働くドメインにあるか、きちんと考えることが重要。
★感想：今回も大変勉強になりました。
特に、写経の結果がいろいろ面白かったです。
CASE文の結果やIN句の使い方が、DBMSにより実行結果に差が出たりとか、個人的にArray句を試してみたりとか、実際に7.5節の解決策を手順に落としてやってみたりとか。
マルチカラムアトリビュートは経験者が多いということもあり、ディスカッションも盛り上がりました。
まさしく！
みなさま、ありがとうございました～
2013/7/27(土) 「TDD Boot Camp Tokyo 2013-07」に参加してきました。
DoorKeeper
http://tddbc.doorkeeper.jp/events/4663Togetter
http://togetter.com/li/539759場所は品川シーサイド楽天タワーです。
私、自宅から自転車で行きました。お財布に優しい距離なのです
参加者は40名くらいでしょうか。
申し込み開始初日でMAXまで達したような。。。毎度恐るべしTDDBC！
しかし素晴らしいイベントだった！
地球防衛軍４で連日忙しく 日が空いてしまいましたが、今更ながら復習のためブログ書く。
■基調講演 by 和田さん
今回のTDDBCのスライドは公開していないとのことなので、手元の個人メモから書き起こしてみる。
復習の際は、
TDDBC福岡のスライドを参考にさせていただきました。
http://www.slideshare.net/t_wada/tddbc-fukuoka-day1■和田卓人のTDD講座・gihyo.jpで連載していた。
http://gihyo.jp/dev/serial/01/tdd・ニコニコ動画でも全20回、解説付きで見れる。
http://www.nicovideo.jp/mylist/4805036■Boot Campとは・アメリカ海兵隊の新兵の短期間修練
■TDD・不安を克服する術が、TDD。
・ケント・ベックの「テスト駆動開発入門」からTDDは始まった。
・偉大な本は偉大な書き出しから始まる。「動作する綺麗なコードは、あらゆる理由で価値がある」
■動作する、きれいなコードへ
（出典：
http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）
●上側のオレンジ線・これまでは、「良い設計をして、次に実装をすることで、きれないシステムが出来上がる」と言われてきた。
・図で言うと、上側のオレンジの道。でも、上側の道には罠がある。
・上側の線は、「きれいで動かない」という状態から抜けられない。
→ つまり、「きれいな設計にしたい」という欲求から抜けられない。まさに沼地状態。
・システム開発にはスケジュールがある。コードを書き始めると、いろいろ分かり始める。
→ 「ここまで設計する必要は無かった」とか「きれいな設計だけど遅すぎて使えない」とかが分かり始める。
・なぜか？それは、ソフトウェア開発の歴史が未熟だから。
・ソフトウェア開発は登場人物が多すぎるので、予測が立ちにくい。
→ 手を動かしてみて初めてわかる。
●下側の青線・設計はいいから早くコード書こうぜ、というのが下側の青線の方。
・動くけど汚いシステムが出来上がる。
●両者の比較・上は、完璧心の呪い。
・下は、堕落沼。
・下にハマっていてもいけない。
・動くものでも、きれいにする意志を忘れてはいけない。
・上と下はそれぞれ難しさがある。
・でも、縦線を超える（動かない→動く）ことが大事。それを教えてくれたのがTDD。
■TDDのサイクル・TDDでは、テストコードとプロダクトコードを交互に書きながら進めていく。
・TDDとは、サイクル。
・まず、「やることリスト」を作る。
・そこから１つだけ、やりたいことをピックアップする。
・そのテストコードを書く。
・テストコードを動かすと、プロダクトコードを実装してないので絶対に失敗する。（赤色になる）
・目的のコードを書く。テストを通すことを第一に考える。
・さっき書いたテストが成功する。（緑色になる）
・目標を満たす状態になったので、今度はコードの方をきれいに直すフェーズになる。それがリファクタリング。
・テスト駆動開発のサイクル自身は非常に単純
■TDDと黄金の回転
（出典：
http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）
１．テストを書く
２．リファクタリング
３．次のテストを書く
・回転にはチカラが宿る（by ジョジョの奇妙な冒険）
・どれも矢印で示せるのが大事。矢印は分岐しない。ひとつのアクティビティとして扱える。
・アジャイルの「帽子をかぶり分ける」と一緒。
・一番大事なのは、堕落沼（4象限の下側の青い線）から抜け出すため、リファクタリングを行うこと。
・リファクタリングには「意思」が必要。
・１個１個のアクティビティの中に「片付けフェーズ」を設けている。それが上手くリファクタリングをやるコツ。
■TDDをどうやるか？・良い書籍がある。
・1冊目は、マーチン・ファウラーの「リファクタリング」
・2冊目は、「リーダブルコード。少ないページで読みやすく書いてある。
■TDDの精神・テスト駆動開発は「回転」である。回転には力が宿る。(ジョジョ）
■TDDのこころ以下の●印。
●１つずつ、少しずつ。段を小さく・噛み砕いてテストに書ける段階まで分解していくのが大事。
・そこが難しいところでもあり、慣れが必要になる。
・タスクに分解するスキルがまず最初に大事になる。
●ひとりずつ仕留める・複数を相手にせず、ひとりずつ対処する。
・宮本武蔵の「五輪書」にも、複数の敵に囲まれたときにどうすればよいかが書いてある。
→ 「1対多」を、「1対1の連続」にする。
●すばやくまわす・テスト駆動開発における回転は、「フィードバックサイクル」。
・速く回れば回るほど、テスト駆動開発はうまく機能する。
・レッド→グリーン→リファクタリングを早く回す。
●自分が最初のユーザ・テストから書く、ということは、自分がこれから実装するコードの最初のユーザは、自分が書くテストコードになる。
・自分が書いたコードが使いやすいかどうかは、自分が使ってみないとわからない。
・実装を考える前に、必ず自分が使う側に回る。
・そうすると、「作るのが楽なもの」と「使うのが楽なもの」が違うことがわかる。
・「ドックフードを食う」という表現があるが、つまり、自分が作るものを自分で使い始める。
●不安をテストに・テスト駆動開発をやってると、どのくらいテストを書けばいいか、何をテストに書けばいいか、という疑問が出てくる。
・答えは、「不安をテストにしよう」。
・テスト駆動開発の目的は、自分たちの不安を解消しながら前に進んでいくこと。
・回転を妨げるのは、不安。
・裏を返すと、不安じゃないところはテストしなくてよい。
・getterやsetterには不安はないはず。なので、そこはテストしなくていいはず。
・自分のコードにはムラがある。そこをテスト書いていきましょう。
・テストがセーフティーネットになり、命綱になる。バンジージャンプする直前に綱を編み始めるのでは遅すぎる。
■なぜTDDをするのか・TDDには数値的なメリットはあるが、最大の理由は心理的なもの。
・即座にフィードバックを得るため。自分が今書いたコードが、動くか動かないか、すぐわかる。
・その積み重ねが膨大なテストケースになる。
・TDDをやってれば、見落としがない部分に関しては自信を持てる。
■TDDの真の目的・テストは「目的」ではなく「手段」。
・真の目的とは、「健康であること」。
・なんの健康か、というと、コード。無駄の無いコード。
・変化に対応するのは健康体のコード。
・テストを書いて、リファクタリングを続けて、無駄が無く、重複が無く、良い名前がついたコードにすることができる。
・変更に対応するのは健康体のチーム。TDDで爆弾処理のようなことはしなくて済む。
・TDDで大きなトラブルは置きにくくなる。 → 定時で帰る。
・不安を克服し、健康を維持する。
・これがTDDの真の目的。
■事例・TDDの効果に関する研究論文から２つ紹介する。
●MS/IBMの事例
（出典：
http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）
・MSではWindow Vistaの開発でTDDが一部導入されたらしい。あとMSNの開発にも。
・上の図から傾向が読み取れる。
①不具合は軽減する方向に効果が出た。
②コードの実装時間は増えている。
・実装時間は2割増えて、欠陥が7割くらい減る。
・お客様へTDDの効果を説明するのに使える図。
●エリクソンの事例
（出典：
http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）
・TDD被験者にアンケートを取っている。
・「TDDはテストから先に書くので、矛盾点とかに気づきやすい。」
→ つまり、要求が洗練された。
・「実装工数が増えたのに、工数は減った」と5割の人が答えた。
→ 実装が増えたのに工数が減ったなら、何かが減ってるはず。
→ 減ったのは「デバッグの時間」。TDDで「デバッグ時間」が減る。
・デバッグの時間は読めないし時間がかかる。TDDをやると、ここの時間を減らせる。
■応用●テストの無いコードが既にたくさんある。どうすればいいか。 → レガシーコード改善ガイドを読む。
・言語が何でかかれていようが、テストがないコードはレガシーコード。
・現場に1冊おいておくべき本。
●既にデータの入ったデータベースがある。どうすればいいか。 → データベースリファクタリングを読む。
・DBのリファクタリングは、コードのリファクタリングよりも時間と慎重さが必要になる。
●テストが脆い・Fragile Testsとは、壊れやすいテスト、内部に深く立ち入りすぎたテストのこと。
→ 開発の足手まといになる。
・Slow Testsは、黄金の回転が遅くなる。つまり、フィードバックサイクルが回らなくなる。
→ スローテスト問題。
・これらの問題をどう改善していけばいいか。
→ 「xUnit Test Patterns」を読む。
・この書籍は翻訳されていない。
・副題に「Refactoring Test Code」とある。
・壊れやすいテストコードをどうメンテしていくかについて言及している。
・900ページもある、鈍器。膨大な本。
・ほぼWikiの内容を書籍化した本なので、インターネット上で読める。
●どこまでテストすればよいのか。 → テスト技法の分野から1冊を選ぶとすれば、「ソフトウェアテスト技法ドリル」
・テスト設計について初歩から応用まで教えてくれる本。
●現実のシステムはもっと複雑だが、どうすればいいか。 → 「実践テスト駆動開発」を読む。
・テスト駆動開発の2冊目のバイブル。
・テストを書きながらシステムを育てていくという思想。
■まとめ・応用編として5冊の本を上げた。
・今日は「黄金の回転」を覚えて帰って欲しい。
・本を辿ること。
・TDDはスキルです。才能の世界ではない。練習すれば覚えられるし上手くなる。
・迷ったら写経をする。やり方は以下。
・TDDの出会いは、「リファクタリング」の原著のレビューを読んだこと。そこで写経した。
・グリーンバンドを考えたのは、ボブ・マーティン。通称：ボブおじさん。
→ 左手を見るとグリーンバンドがある。それで「プロなんだからテストかかなきゃ」と思う。一種の戒め。
■Steve Freeman氏による講演この日のスーパー飛び入りゲスト、Steve Freeman氏による講演！
ちなみに和田さんの講演の中に出てきた書籍「実践テスト駆動開発」（通称：GOOS本）の著者です。
私の英語力が無いのが悔やまれる。。。
んでも、 @yattom さんがTwitterでリアルタイム翻訳を流してくださいました。
冒頭のTogetterから追えます。
あと、Steveが来る事をTwitterで事前情報をキャッチしてたので、私もGOOS本を持参しました。
もちろん狙うは、書籍への直筆サイン！休憩時間に無事いただくことができました。
■ペアプロ大会午後からペアプロ大会です。お題「飲み物自動販売機 Ver 2.0」の詳細はこちら。
私は @megascus さんとペアで、Javaにて取り組みました。
確かステップ４かステップ５まで行けてたハズ。
コードはGithubに上げておきます。
https://github.com/makopi23/TDDBC_Tokyo_201307@megascus さんからの有意義なアドバイスを戴きながらのTDDペアプロ、大変勉強になりました。
あと、Steveもペアプロに挑戦＆生コードを交えた解説タイムがありました。凄すぎてワロタｗ
★感想：ホント素晴らしいイベントでした！
基調講演も、飛び入りSteveも、ペアプロも、質疑応答も、TAも、何もかもが素晴らしい。
過去のTDDBCの参加者もおっしゃっていたんですが、今回は神回では無かろうか。。。
TDDBCに参加したことがない人は、是非参加をおススメしたいですね。TDDの真髄が1日に詰まっている。
ちょっとブログ書くまで日が空いてしまいましたが、これは書かざるを得ない、と思って今更ながら、復習の意味も兼ねて書きました。
関係者の皆様、ホント有意義なお時間ありがとうございました。
-->
