Groovy基礎勉強会でGrailsのリクエスト制御をライブコードリーディングしてきました #GroovyBase
書籍『SQLアンチパターン』 #sqlap
献本御礼。
本書のレビューに参加できて大変光栄であります。
- 作者: Bill Karwin,和田卓人(監訳),和田省二(監訳),児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
- クリック: 365回
- この商品を含むブログ (4件) を見る
帯には『「転ばぬ先の杖」を知り、リレーショナルデータベースの進化を学ぶ！』とあって、その通りであるなぁと思いますが、個人的には「転んだ後の鞭(ムチ)」として悶絶しながら読むのが断然お勧めです。
今時のアプリケーションを開発する人はRDBMSを避けて通ることはできないはず*1。そして、今までの開発人生でどれだけのDB技術的負債を積み上げてきたことでしょう。本書では、過去のトラウマを直視させられる粒ぞろいのアンチパターンが取り上げられています。
本書におけるアンチパターンは、以下の形式で記述されています。
「アンチパターン」でトラウマを抉られて悶絶しているところに、「アンチパターンを用いてもよい場合」でフォローが入り救済される、という下げて上げる式のノンストップ・ジェットコースター的なドラマティック読書が楽しめます。
目次から章タイトルだけを並べてみます。
I部 データベース論理設計のアンチパターン
1章 ジェイウォーク（信号無視）
2章 ナイーブツリー（素朴な木）
3章 IDリクワイアド（とりあえずID）
4章 キーレスエントリ（外部キー嫌い）
5章 EAV（エンティティ・アトリビュート・バリュー）
6章 ポリモーフィック関連
7章 マルチカラムアトリビュート（複数列属性）
8章 メタデータトリブル（メタデータ大増殖）
II部 データベース物理設計のアンチパターン
9章 ラウンディングエラー（丸め誤差）
10章 サーティワンフレーバー（31のフレーバー）
11章 ファントムファイル（幻のファイル）
12章 インデックスショットガン（闇雲インデックス）
III部 クエリのアンチパターン
13章 フィア・オブ・ジ・アンノウン（恐怖のunknown）
14章 アンビギュアスグループ（曖昧なグループ）
15章 ランダムセレクション
16章 プアマンズ・サーチエンジン（貧者のサーチエンジン）
17章 スパゲッティクエリ
18章 インプリシットカラム（暗黙の列）
IV部 アプリケーション開発のアンチパターン
19章 リーダブルパスワード（読み取り可能パスワード）
20章 SQLインジェクション
21章 シュードキー・ニートフリーク（疑似キー潔癖症）
22章 シー・ノー・エビル（臭いものに蓋）
23章 ディプロマティック・イミュニティ（外交特権）
24章 マジックビーンズ（魔法の豆）
25章 砂の城
人によってトラウマポイントが当然違ってきますが、個人的には
- 「4章 キーレスエントリ（外部キー嫌い）」
- 「5章 EAV（エンティティ・アトリビュート・バリュー）」
あたりが特に悶絶度が高くて楽しめました。
あと、Grails使いとしては、「3章 IDリクワイアド（とりあえずID）」あたりも味わい深いものがありますね。Ruby on Railsの人たちも必読ではないでしょうか。
今まで読んだSQLノウハウ本の中では、以下の2つと並んでトップ3にランクインです。SQLはまだよくわからないという初学者には、まさに「転ばぬ先の杖」として素敵なガイドとなってくれることは間違いないので、安心して購入しましょう。お勧めです。
達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)
- 作者: ミック
- 出版社/メーカー: 翔泳社
- 発売日: 2008/02/07
- メディア: 単行本（ソフトカバー）
- 購入: 52人 クリック: 978回
- この商品を含むブログ (75件) を見る
- 作者: (株)スターロジック羽生章洋
- 出版社/メーカー: 翔泳社
- 発売日: 2006/04/18
- メディア: 単行本
- 購入: 69人 クリック: 903回
- この商品を含むブログ (119件) を見る
*1:そろそろ「NoSQLだけで十分だ！」と言う人も出てくるかもしれないですが
Scrum Regional Gatehering Tokyo 2013に参加してきた #sgt2013
若干タナボタ気味ではありましたが、会社のお金で参加してきました。ありがとう、会社の人。おかげさまで大変堪能できました。
というわけで、メモです。自分のためのメモなので、噓（はないとは思いたい）・大げさ・紛らわしい・理解誤り・仕様誤り・ケアレスミス・境界チェック漏れなどが含まれるかも知れませんが、あらかじめご了承ください。目に余るモノがあったら指摘していただければできるだけ対応します。
セッション概要: http://scrumgatheringtokyo.org/2013/?page_id=148
day 1
Keynote#1: Agile Management – Learning From Software Development - Jurgen Appelo
- Beyond Budgeting
- Lean Startup
- Design Thinking
- Management 3.0
- Q&A
- managerとleaderの違い
- managerはleadershipとgovernanceの両方が大事
- governance: ルールを決めてそれを遵守させる
- leadershipはいわゆる"リーダ"だけではなく、メンバ全員が持っていて良い。持っているべき
- manager(management)というロールは必要だが、managerという職種は不要（必須ではない）
- 全員でmanagementできるのが理想
- managerはleadershipとgovernanceの両方が大事
- 何をどうやっても、仕事をどうしても楽しめない。お金のためだけに働く人はどうしたらいい？
- うまくいくように手伝う
- だめなら、やめるように仕向ける（お互い納得の上で）
- スキルではなく、マインドセットで人を雇うのが重要
- スキルは伸ばせるが、マインドの変革は困難
- managerとleaderの違い
Keynote#2: Buy or Build: where did your agile come from - Jim Coplien
- ((スクラム認定制度に対する壮大なDISセッション)
- 試験パスしたから今日からあなたは今日からプロフェッショナルなスクラムマスタなの？
- 認定されたから大丈夫、ではない
- 実践し、考え続けるのが大事
- "チーム" >>>>> 優秀な人×N
- チームとして成果を出す方が大事
- knowledgeとlearning
- knowledge：脳内に閉じがち。必ずしも行動に結びつかない
- learning：行動に反映される
- Bloom's Taxonomy of Learning Domains
- http://www.nwlink.com/~donclark/hrd/bloom.html
- Cognitive Taxonomy （認知領域による分類）
- 知識→理解→応用→分析→統合
- 守 破 離
- Affective Taxonomy（情意領域による分類）
- 受け入れ→反応→価値付け→組織化→内面化
- （スクラム認定研修も含めて）Trainingで達成できるのは精々2段階ぐらい
- その先は「経験」が必要
- Scrumは訓練の道具
- 「うまくいかないことが分かった。誰だ！誰のせいだ！お前か！」
- ではない
- 失敗は"情報"である
- 情報が得られたのならカイゼンすればよい
- みんな、どのくらいEmergency Procedure使った？
- ((Emergency Procedureって何？状態だったので後から調べた)
- http://jeffsutherland.com/scrumhandbook.pdf
- If the burndown line is not tracking downwards towards completion by mid-Sprint, the team needs to execute the Scrum Emergency Procedure:
- 1. Change the approach to the work or remove impediments to increase velocity.
- 2. Get help by having someone outside the team take some of the backlog.
- 3. Reduce the scope of work.
- 4. Abort the Sprint.
- ((いわゆる"ごめんなさい"的なアレでした)
- ((Emergency Procedureって何？状態だったので後から調べた)
- "Scrumはおまえらがどんだけクソかを知るためのツール" ((※ここまで酷くは言ってない
- 「うまくいかないことが分かった。誰だ！誰のせいだ！お前か！」
- ダニング-クルーガ効果
- (( http://ogasawara.cocolog-nifty.com/ogasawara_blog/2011/06/dunning-kruger-.html
- (("「知識の少ない人間が、もっと知識の多い人々より自分の方が物事をよく知っていると思い込む」現象のこと"
- 日本人の珍しい特性
- 北米人・カナダ人：簡単なテスト→やる気UP、難しいテスト→やる気DOWN
- 日本人：簡単なテスト→やるきDOWN、難しいテスト→やる気UP
- 逆の傾向。珍しい
- つまり、問題があったらそれに取り組んでカイゼンしていく、という気質が元からある
- Autonomy(自律性), Mastery(熟練), Purpose(目的)
- Q：パターンとアジャイルは何が違う？同じ？アジャイルはなぜ成功したのか？
- 両者は同じ
- アジャイルの成功の一因は、残念なことに認定制度だと思う
- Q：だいたいどのくらいのスプリントが失敗になるもの？
- 50%(!!) そうじゃないなら、何かが間違っているか、失敗を隠しているかのどちらかだ
The secret sauce of Innovation - Laszlo Szalvay
- (メモなし)
アンチファクトリー：アジャイル／スクラムによる顧客と開発チームの至高体験 - 上田善行 Ci&T Passific
- 組織論を話します
- 全社的にScrumを100%採用している。150チームぐらい
- 来歴
- 2007 Scrumを戦略的に初採用
- 10年ぐらいかけてCMMI5を達成していて自分達のやり方でやるつもりでいたが、某Yahooから「スクラムでお願い」と言われたので
- 2008 全面導入（それ以前はRUPベース）
- たった一年で全面導入するスピード感
- 以前はRUPで380アクティビティ定義していたが、スクラム採用後はたったの32プラクティスに集約
- 2009 生産性・品質共に向上し始める
- 一時的に下がったが、この時期から明らかに以前よりも向上
- 2010 リーンで、戦略デプロイメント長期経営計画
- True North 20xx
- 方位磁針の北は真北ではない。真の北はどこか探求する ((とかだったかな
- True North 20xx
- ミッションステートメント
- To develop people who continuously use their talent to discover new ways of generating value and agility to our clients, and boldly execute as no one has done before.
- super standardlization process
- ウォータフォールは元々フィードバックループがあったけど、色々あってなしのバージョンが広がってしまった
- "Software Factory Pattern"
- 顧客の要求通り、大量リソース（＝人員）で、大量生産する
- ウォーリーを探せのウォーリのように、同じような会社ばかり増えた
- 7つの弱点
- 標準化：要求変更は不都合なだけ
- 役所手続き：ドキュメント（＝証拠）によるコミュニケーション
- 対立：Fix後の変更はエナジーを費やし、ストレスフルなだけ
- コスト：当初の要求通りにいくかどうかが一番の関心事になる
- 隠蔽：問題は報告しない。納品までに問題がどこかに消えてくれることを祈る
- 消失：知や人間関係が失われる
- リソース：人を"People"ではなく単なる"リソース"と見なす。そこに情熱・創造性・ビジョンはない
- 5つの争点
- 顧客はHappyかどうか
- チームはHappyかどうか
- 失敗の犯人捜しをしていないか
- 勝つか負けるかの2択になっていないか
- ITは顧客の価値を生み出しているか
- 顧客とチームは次の質問に答えられる？
- 何を開発するのか
- なぜそれを開発するのか
- それはどのような価値を生み出すのか
- 全てをYesにしたい
- 顧客の要求通り、大量リソース（＝人員）で、大量生産する
- どうやるか
- 組織の真北（True North）に同意する
- リーン・スクラムの4P（Purpose, Process, People, Power to the Edge(現場に権限を)）
- リーン・スクラム、だけでは会社として差別化できない
- そのぐらいの会社はたくさんある
- 真の差異
- "価値の創出"とそれを明示・論拠できること
- 安定化と利益
- 価値(Value)＝Benefit - Cost
- 同じモノでもValueは買い手によって変わる
- ストーリ単位でValueとマッピングしている
- Situation Wall
- 各PJごとに状況を壁に書き出す。可視化
- A3で全ての戦略的PDCAを表す
- 最近は、他の開発手法をしらない純粋なアジャイル世代（アジャイルエイジ）が現れている！
- 2007 Scrumを戦略的に初採用
Workshop: Beyond certification to Kaizen with ScrumKnowsy - Jim Coplien
- Scrum Knowsyを使ったグループワーク
- Scrum Knowsy（スクラムノウジー）
- http://www.scrumknowsy.com/
- 単純なゲーム
- スクラムのトピック（朝会、ふりかえり、カイゼン、等）を選び、提示されたキーワードから重要だと思う順に上位6つを並べる
- 失敗は情報
- Kaizenすれば良い
day 2
Keynote前説 - 平鍋健児
Keynote: 実践値リーダシップとアジャイル/スクラム - 野中 郁次郎
- http://www.slideshare.net/hiranabe/phronetic-leadership-and-agile-scrum-gathering-tokyo-2013
- 戦略と組織は切り離せない
- 戦略は、人が考え、組織が実行する
- 戦略マネジメント
- 知識創造 SECIプロセス
- S:共同化、E:表出化、C:連結化、I:内面化 のスパイラル
- フロネシス：共通前（Common Good）の追求・拡張
- 知ること（knowing）には、個人的なコミットメントが不可欠
- 信念と理性、アートとサイエンスのバランスが重要
- 知識創造
- ((メモ：スプリントを回し(S)で、ふりかえりをして(EC)、次のスプリントを回す(IS)、と考えると、
- ((スプリントがうまく回ることだけ最優先にするのはスパイラルのバランスが悪い
- ((ふりかえりによる過程も等価に扱って、スパイラルになっていることが重要
- ((なのかなと思った
- ((「今回のスプリントはうまくいった。まる」になりがちなので。自戒。
- 文脈（コンテキスト）
- "聞き手"が自分の頭から取り出した想定(assumption)
- 場（Ba）＝Shared Context in Motion
- 我々は生まれつき共感を覚えるようにできている
- 価値命題＝ユニークなコトを提供する
- コトのためにモノを作る
- 対象を名詞ではなく動詞で捉える
- フロネシス＝賢慮・実践知
- 個別具体の文脈で「ちょうど（Just Right）」をみつける
- "身体性を伴う"
- 「文脈に即した判断」と「適時絶妙なバランス」
- not Decision, but Judgement
- イノベーションにはおそらく政治力が必要
- 自律分散するリーダシップ（Distributed Leadership）
- 善（Common Good）を作る
- 場（Ba）を作る
- ありのままの現実を直視する
- 直感の本質を語る
- 概念を実現する政治力
- 実践知を組織化する
- コモンセンス＝常識、"共通感覚"
- シュンペータ「組織は個を殺すぞ」
- 野中「そうじゃないんじゃないか」
- 基本は徒弟制度（OJT）
- 意図的に２〜３倍の負荷を与えて育てる
- 知は内に向かうと枯渇する
- 徳の源泉は勇気ッ
- 賢慮・実践知リーダ＝フロニモス＝知的体育会系（Intellectual Muscle）
- 実践をしながらbetterを無限に追求し続けることが重要 ((そこに黄金の回転＝無限のエネルギーが生まれるッ
Panel Discussion 野中郁次郎 x 平鍋健児
特等席に座ったものの義務としてupしておく #sgt2013 twitter.com/nobeans/status…
— Yasuharu Nakanoさん (@nobeans) 1月 16, 2013- 暗黙知はコト話で伝わるか
- 暗黙知のバンド幅は思ったよりある気がしている
- ドキュメントにdetailは書き切れない
- 一緒に仕事しないと伝わりきれない
- 身体性を伴う必要有り
- スクラムで興味深いところ
- ペアプロ・ふりかえり
- スプリント中に変更がない ((メモ：共同化を推進するのかな
- Jeff Southerlandは元軍人で100回以上パイロットとして出撃している
- 「彼はすごくhumanな人」
- ソフトウェアの原材料は「言葉」と「会話」
- アレグザンダのプロセスも「対話」が重要
- 「彼もすごくhumanな人なんじゃないか」
- アレグザンダのパタンは建築家と大工のコミュニケーションのため、でもある
- アレグザンダのプロセスも「対話」が重要
- 現場・現物・現実
- 現場：actual
- 現場で汗をかく、相手の目線でとったニュアンスを含む
- 現実：real
- actualでattachしているところからdetachした状態がreal
- 現場：actual
- 本田宗一郎はSuper Product Owner
- Q：リーダ重要とのことであるが、見つけ方・育て方についてヒントを
- Common Goodの追求をどこでとめるか、という問題もある
- みんながやりきったと思えるところ
- （スコープを広げていき究極的には）"人類"として考えたとき"そうあるべきだよね"となるところ
- と考えると、"人類"としてどうなんだっけ＝歴史を学ぶことがとても重要
- 人はコラボで生きている
- Q：大人数でのスクラム・知識創造の方法について何かヒントを
- 場と場をつなぐバウンダリオブジェクトというコンセプト
- バウンダリ＝チームの境界、をつなげる
- 方法
- 各チームのリーダの人間力でつなぐ
- シンボルを使う（例：Steve Jobsの海賊旗、音楽）
- インセンティブシステム
- 時間あたりの付加価値を高めるように
- カルチャー
- 米軍「我々は仲間のために戦う」
- ヒューマニズム
- 場と場をつなぐバウンダリオブジェクトというコンセプト
- 〆の言葉
- 平鍋
- 「開発チームのHappy」から「顧客も含めたビジネスとしてのHappy」へ
- 野中
- 日本を元気にしたい
- スクラム＝西洋と東洋のインテグレーション
- 日本の資産なのではないか
- 最後はパッション、そして勇気が大事ッ（あとお酒）
- 平鍋
Product Ownership 〜 NTTデータと楽天
- 楽天 及部 @takaking22
- 自己紹介
- DevLove「私がScrumを辞めた理由」で話したり
- Agile 2012に参加したり
- 振り返ればカンバンがあった
- カンバンの数だけ歴史がある
- 今日は、エンジニア視点の話
- Scrumをはじめたが、コーチが去ったら全部元に戻った...
- ひとりカンバン（魅せる化カンバン）
- みんなつられてやりはじめた
- 深刻な壁不足
- 開発が順調に回ると、価値の張るバックログアイテムが不足してきた
- ビジネス＋開発で朝礼をはじめた
- PO、Producer、FeatureTeamの3枠含めたカンバンを使った
- 観測の結果、ビジネス→開発にValue Streamは流れなかった
- 要求はどこから来るのか？という疑問
- チーム全員でJeff PattonのPO研修に参加
- "Product Ownershipは全員が持つもの"
- 翌日Jeffが手伝いに来てくれた
- PO、リーダ「「（プロダクト開発って）ちゃんとやらなきゃね」」「えっ」
- Value Streamが流れるように「価値創造カンバン」を絶賛開発中
- まとめ
- Product Ownershipは一緒に働くことから生まれる（のでは）
- 育てる意識
- 導入すればOKではない
- 人もプロセスも育てていくつもりでやらないと続かない
- 成功するまでやり続ければ失敗じゃない
- 川口さんの一言
- Common Sence 共通理解が大事
- 相手のことが分からないながらも観察や質問をして自分事として課題を解決する
- 自己紹介
- NTT DATA 柴山 @shibao800
- アジャイル開発組織を運営
- AgileProfessionalCenter
- オンデマンドなScrum開発体制
- ScrumのProfessionalを育成
- AgileProfessionalCenter
- 登場人物
- 主人公：PO 菅原さん：新規テストソリューションのPO
- POチームメンバ
- ユーザ「悪いモノは使わない」
- 主人公の上司「Agile開発なにそれ」
- 数ヶ月かけて数ヶ月かけて要求機能一覧まで完成させたが...
- Step0 事前準備
- Jeff PattonのCSPO研修に放り込んだ
- 「返ってよく分からなくなった」
- Step1 POチームメンバを仲間に
- リーンキャンバスを繰り返し作り直した
- 最初デジタルで主人公が編集→アナログにしてチームで共有
- 主人公の意見のみ→メンバからの意見がでてきた
- メンバ「機能一覧を実現すればいいんでしょ」→「どうすればユーザにとって価値のあるモノができるか」
- リーンキャンバスを繰り返し作り直した
- Step2 ユーザを仲間に
- エクスペリエンスマップをユーザと一緒に作成
- ユーザが積極的に問題を共有してくれるようになった
- ユーザの周辺に意見を聞いてとりまとめたり
- Step3 上司を仲間に
- ペルソナを使ってユーザ増を明確に
- あらゆる人をターゲットにしすぎてぼやけていた
- 価値を届けるべき相手を明確に
- ユーザストーリーマッピング
- 誰のために、どのような機能で、どのような価値を届けるか、を時系列に並べる
- 上司に対するスコープの説明を具体的に行い、合意を取り付けられた
- ペルソナを使ってユーザ増を明確に
- 感想も上々
- "Product Ownership"
- 川口さんの一言
- 「アナログで付箋」が重要
- やってみせて、やってもらって、理解してもらう、重要
- アジャイル開発組織を運営
Agile Transformation in Big〜大組織でのアジャイル変革 谷口@agilergo
- （事例だけで発表許可もらってない）
- 中学ぐらい(?)からドイツ在住
- 海外長すぎて日本語が不自由（割と本気）
- ここ10年ぐらいAgileコーチング・コンサルティングをしている
- ((一部自重)
- 課題
- 戦略プロダクト：失敗は許されない
- プロダクト規模が大きい
- ウォータフォールでは不可能な時間のなさ
- アジャイル経験ほとんどなし
- 短期間で多くのチームを立ち上げる
- 外部の要員が多数、チームビルディング
- 等
- チームはコンポーネント毎に分けた
- チーム間のコミニュケーションが課題
- 各チームから代表を集めてVirtual Team Architectureを構築した（＝Scrum of Scrumのこと？）
- チーム間での情報共有や依存関係の整理
- ミーティング
- いつものスクラム会議体に加えて
- POデイリー＆POウィークリー
- SMデイリー＆SMウィークリー
- Scrum of Scrum
- Dependencyを見つける
- Overall Review
- 総勢200人でミッションとかやっていることの共有
- いつものスクラム会議体に加えて
- 組織構造の変革
- 課題
- 大組織、アジャイルへの道の課題
- サティア チェンジモデル
- 新しいことをすると、一時的にパフォーマンスは落ちる
- 人々が最大のテコ
- 人が重要
- マインドセット
- 支障を避けるんじゃなくて、きちんと取り除いていく
- 成功の鍵
技術トークス
- 前説：スクラムはフレームワーク。どういった技術を使っていくのかについて一人30分程度でトーク。最後にパネル。
- 「毎回ゴミができあがる。俺たちのスクラムは失敗だ」「ゴミができてることに気づいてるならそれは成功だ。さあ改善しよう」
- クラウド 玉川/Amazon
- 複雑で予測不可能なシステムを構築する
- インフラストラクチャは重荷
- 買ったら取り返しつかない
- 買うのに時間がかかる
- どれくらい買えば良いのか分からない
- キャパシティ設計？
- 「お客さんが言ってるデータ量に30%上乗せしようか、2倍くらいにしようか」
- 本番環境と同じの欲しい
- Amazon自体もインフラの調達で悩んでいた
- Amazonのトラフィック
- 昼間は61%まで、夜は落ち込む
- 年末のピークのために年間インフラを保守する無駄
- Amazonのトラフィック
- 新サービスのトラフィックを予測できる？
- ミニマムスタートだと、サービスがうまくいくとサーバが落ちる。ビジネス機会の喪失
- 「インフラがソフトウェアになりました」
- 2000万ユーザのNetflixのCTO「明日にでも日本に参入できる（インフラはクラウドだし）（コンテンツの法的な話がネック）」
- どこにデプロイするかデータセンタ単位で制御可能
- EコマースのAmazonのミッションクリティカルなサービスのために作ったので信頼性は超高い
- クラウドの使いこなしがまだまだ浸透していない
- 給与計算システムをクラウドに載せる→月末だけデプロイすればいいのに、ずっと起動しっぱなしで無駄
- 全仮想マシンに1つずつリリースする→1つリリースして自動反映できるのに
- どの企業がどれだけ使っているか（トラフィック等）がみえる
- よく使っているサービスは今伸びてるな、と分かる（インサイダ情報）
- 誰でもクラウドが手に入るので、インフラを持っていることに競争力はない
- 自力でクラウド作って開発者をそこに費やして肝心なサービスが手薄になっている企業と、既存クラウドを使ってサービスに集中している企業の競争力は明らかですよね
- CDP（Cloud Design Pattern）
- 継続的デリバリ 和智/gxp
- 趣味でときどき翻訳をしています
- 継続的デリバリー、DDDとか
- スクラム＝パッケージ/フレームワーク
- 「よし明日からスクラムをやろう！」は危険。聞いててドキドキする
- ソフトウェアパッケージを導入するとき、いきなり明日から導入しないでしょ？
- スクラム自体では未定義、何も教えてくれない
- プロダクトバックログ、どうやってつくる？
- 自分達の機能一覧と何が違うの？
- 出荷可能な成果物、どうやってつくる？
- エンドユーザにどうやって届ける？ ↑←この辺が継続的デリバリー
- といったことを、自分達で埋めていかないといけない
- プロダクトバックログ、どうやってつくる？
- CIとか重要
- クラウドなら構築しやすいんじゃないか
- フィーチャを差し込めるアプリケーションアーキテクチャを事前に準備しておく必要がある
- （実は自分はスクラムやっていません。大きなウォータフォール）
- 分割したものは結合しなければならない
- まとめ
- スクラムは自分達の文化に合わせて運用しなければならない
- カスタマイズというより、スクラムが語っていないスキマの所
- 継続的デリバリとは実装された価値をスムーズにエンドユーザに届ける手法
- 高度なガバナンスが必要
- どう分割し、どう統合するか
- フィーチャを差し込めるあー帰着茶
- バージョン管理と継続的インテグレーション
- スクラムは自分達の文化に合わせて運用しなければならない
- 趣味でときどき翻訳をしています
- アジャイルテスティング〜テストの全体像を共有する〜 細谷/スクラム道関西/XPJUG-Kansai/TFSUG
- テストの全体像をどうやって作っていくか
- テストフェーズ＝市場に不具合を流出させない最後の砦
- 目的と手段
- 目的：目標の品質を達成すること
- 手段：目標の品質であることを確認可能なテストを開発する
- 「テストを開発する」
- しっかりとテストを分析して、計画＆開発しなければならない
- テスト実装＝自動テスト or テスト仕様書（いわゆるExcel）
- 「テストを開発する」
- テストを実施し、欠陥を是正する
- テストの積み上げ
- 複雑なモノを分けて、一つずつ確認し、組合せを確認して、...という
- 品質の高い要素で全体が構成されていることが重要
- 個々の品質が低いと収拾が付かない
- 小さい粒度で品質を確保し、徐々に粒度をお菊していく
- アジャイル開発でのポイント
- いつ、どのような品質を達成するか
- a) スプリントでの成果物は出荷可能か判断することができる
- b) 出荷に必要なプロセスを経て製品を出荷する
- プロジェクトによって必要な作業量は大きく異なる
- いつ誰からフィードバックを得るか？
- PO、ユーザ：目的を果たせるか？新たな目的の気づき
- 他サブシステム・HWチーム：組み合わせてみての気づき、タイミング、I/Fの矛盾
- チーム：設計・実装からの気づき、自己評価による気づき
- フィードバック範囲 広い1ー少ない2
- リリース回数 少ないaー多いb
- 1a 市場にリリースするための作業は大きい
- 1b 市場にリリースするための作業は小さい。自動化の範囲を可能な限り広げないと実現困難
- 2a 市場にリリースするための作業は大きい
- 2b 頻繁にリリースするための自動化が必要。市場にリリースするためのプロセスの自動化が少なくても実施可能
- どのような粒度でテストするか
- いつ、どのような品質を達成するか
- 「最後の砦」の役割のテストでも、モノの品質が悪ければ、突破されたり、維持に膨大なコストがかかる
- 「最後の砦」を「日常の風景」にするために、我々に何ができるかを考え続けたい
- TDDとそのマインド 和田 @t_wada
- 月末にオライリーからSQLアンチパターンでます
- ((メモ：レビューに参加してたりします
- 今日は楽しいかも知れませんが、みなさん現場に戻ったら...
- 荒みきったコード、疲弊した現場、爆弾処理のようなリリース
- なぜこうなってしまうのか
- 複雑さへの恐れと不安
- 開発では、やらなきゃいけないことがたくさんある
- 書いてるコードの裏側で使っているコードたるや、莫大な行数になっていて把握は不可能
- 不安を克服する技術の不足
- 複雑さへの恐れと不安
- みんなスクラムの「チーム環境」（レフトウィング）だけしかみてないことないですか？
- ライトウィング：高速に石橋を叩いて渡る「開発環境」を忘れてない？
- 誰がシステムを作るのか、誰がシステムを作り続けるのか
- 恐れに対抗する技術とは？
- 技術も磨いていかないとゴールは奪えない
- （いつも語ってる）三本柱
- バージョン管理
- GitでもSubversionでお
- Git使うことが目的じゃない
- テスティング
- 名詞の「テスト」じゃない
- テストをし続けること。動詞。
- 自動化/自働化
- 人間は人間にしかできないことをやりましょう
- 人間は怠惰で疲れやすい
- 同じことを繰り返すことは苦手。あきるし
- コンピュータは融通は利かないが繰り返しは得意
- ユーザに価値を届けるまで自働化しましょう→継続的デリバリ
- インフラも自働化しましょう→クラウド
- バージョン管理
- アジャイルサムライ
- 「テスト」にまつわる混乱
- TDDの本質をとらえ損なわないように
- 誰が、何のためにで分けてみると
- Developing Testing、Customer Testing、QA Testing
- TDDって何？
- テストは目的ではなく手段
- TDDはプログラミング手法
- まずは、コードの書き方の一種ととらえた方がやや正確
- 細谷さんはどっちでもいいとはいったし、そこまで行ければ良いけど
- まずは、コードの書き方の一種ととらえた方がやや正確
- 動くコードに触れるな
- 使われてはじめて本当の要望がでてくる
- 動くコードに触れる手段がなければ、死あるのみ
- 月末にオライリーからSQLアンチパターンでます
- パネル
- Q：ドメインが大きくなってきた、モデルを変えるときに、テストを捨てる戦略は？どういうときにテストを捨てる？
- 和田
- テストが負債になる状況
- コアなドメインを変更するときとか
- そもそもそういうテストを作り出さないための考え方
- まず自動リファクタリング機能や字面置換などを使って何とか既存のコードを活かせないかも検討
- I/Fを変わっている場合は、テストが変更しなければならない
- テストの粒度を変えて、色々な粒度のテストを作っておく
- 細粒度のテストはばっさり捨てる
- 荒粒度のテストを頼りに細粒度のテストを揃え直す
- 内側を生かすか殺すかはそのときの変更次第
- コアの変更を以下に自動化できるか夢は捨ててない
- 大学との共同研究で、安心して捨てられるテストの判定をしたりしてるが、単純なケース以外はまだ成果が出ていない
- 細谷
- 作るために必要なテストと、保守/維持していくために必要なテストは目的が違う
- 作るためのテストが保守するためのテストに移行したり、その逆とか、パターン化できるんじゃないかという妄想をしている
- 和智（変更に強い設計とは？DDD？）
- クラスの中を考えているテストは壊れやすい
- モデル自体の構造を固めるテストよりも動きを固めるテストを書いた方が資産価値が高い
- 和田
- Q：製造業では、QAテストを割り込みでやらざるをえないと思うけど、スクラム的にどうやるの？
- Q：ベンダロックインを嫌うインフラエンジニアから見ると、各種クラウドサービスの共通ラップサービスがでてくるとかなるのかとか、そういう話
- 玉川
- 逆に考えるんだ
- ベンダロックインされないようにしている
- 物理サーバとあまり変わらないように、低レイヤを意識して提供している
- VM import/exportの提供
- データimport/export（HDD送ってくれたら、データ突っ込んで返すよサービスとか）
- 玉川
- Q：テストの自動化の限界
- 細谷
- 自動化は目的ではない
- 費用対効果
- UI等は手動でやらざるを得ない部分はある
- 和田
- UIを自動化することを目的にしてしまうと、テストの変更コストが、UIの変更を阻害してしまう
- ユーザビリティや色合いは自動化しない/できない
- 玉川
- 人間にしかできないテストはある
- AWSには、メカニカルタークというサービスがある
- 人間に頼むところをAPI化する
- ユーザビリティテストや誤字脱字のチェックをアウトソースするとか
- 和智
- リリースに時間がかかるとか、人がやるべきこと、必要なことなら問題ではない
- 細谷
- Q：スクラムでの開発者とWFの開発者の違いは？
- 和智
- 自分は典型的なWF開発者
- あまり本質的な違いはないんじゃないか
- 無駄なことはやらないで、必要な期間を必要なだけ取ってるだけ
- 玉川
- 万里の長城の話「石を運んでる」「お城を作ってる」の違い
- 価値を届けるためにやっているというメンタリティの違いでは
- 細谷
- プロセス的にはあまり違いはないんじゃないか
- 小さい単位で積み上げていく、ということを共有しているかどうか
- WFでは、大きなスパンで不具合密度でしかみれないとか
- スクラムでは、日々共有できるかとか
- 和田
- 咳さん「無責任領域を持たない。守備範囲を決めない」
- ここまでやったから後は知らない
- 従来と比べて積極的に守備範囲を壊していけるようになってきているのでは
- 咳さん「無責任領域を持たない。守備範囲を決めない」
- 和智
- Q：ドメインが大きくなってきた、モデルを変えるときに、テストを捨てる戦略は？どういうときにテストを捨てる？
「enumの抽象メソッドはgroovyでサポートされてない？」「Yes. でもそれだけじゃねーんだぜ」 #jggug #q
enumの抽象メソッドはgroovyでサポートされてない？ #jggug #q - 山ｐの楽しいお勉強生活 へのアンサーエントリ的な。
Long Answer (or Investigation)
以前、自分もこれにやられてenum＆メソッドならスッキリかけるところを微妙に技術的負債ライクな迂回コードを書く羽目になりました。
enum EnumSample { A { String hello() { "from A" } }, B { String hello() { "from B" } } abstract String hello() } assert EnumSample.A.hello() == "from A"
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/private/tmp/hoge.groovy: 1: Can't have an abstract method in a non-abstract class. The class 'EnumSample' must be declared abstract or the method 'java.lang.String hello()' must be implemented.
@ line 1, column 1.
enum EnumSample {
^
/private/tmp/hoge.groovy: 8: Can't have an abstract method in a non-abstract class. The class 'EnumSample' must be declared abstract or the method 'java.lang.String hello()' must not be abstract.
@ line 8, column 3.
abstract String hello()
^
2 errorsそう、abstractメソッドはGroovyのenumではまだ使えないのです。
これ、2011/01ぐらいにJIRAに報告されてるんですけど、なぜかUnresolvedのまま。
自分もVoteしてあってVoted合計12なのですが、まったく動きがありません。
ソース読んでませんが、技術的に難しいのでしょうかね。
じゃあ、abstractを取ってデフォルト実装をいれておけばいいかというと...
enum EnumSample { A { String hello() { "from A" } }, B { String hello() { "from B" } } String hello() { "DEFAULT" } } assert EnumSample.A.hello() == "from A"
これはOK.
なのですが...
enum EnumSample { A() { String hello() { "from A" } }, B() { String hello() { "from B" } } String hello() { "DEFAULT" } } assert EnumSample.A.hello() == "from A"
と、(コンストラクタはとりあえず未定義ですが)コンストラクタ呼出用の括弧を付けると...
Assertion failed:
assert EnumSample.A.hello() == "from A"
| | |
A DEFAULT falseなんと、メソッドがオーバライドされません。
なので、コンストラクタで各要素ごとの値を設定しようとしても...
enum EnumSample { A(1) { String hello() { "from A" } }, B(2) { String hello() { "from B" } } String hello() { "DEFAULT" } final int number EnumSample(int num) { this.number = num } } assert EnumSample.A.number == 1 assert EnumSample.B.number == 2 assert EnumSample.A.hello() == "from A"
Assertion failed:
assert EnumSample.A.hello() == "from A"
| | |
A DEFAULT falseNGなのです。
JIRAチケットはたぶんコレ。http://jira.codehaus.org/browse/GROOVY-5353
このenumが使いづらいのはホントにどうにかして欲しいですね。
というわけで是非Voteしましょう*1。
参考
*1:パッチ書いてくれるのが一番ありがたい
Grailsインタラクティブモードのstop-appとexitコマンドの違い
〜2.1.2まで
Grails開発者はみんな大好きなインタラクティブモードですが、開発中のWebアプリケーションの起動/停止もインタラクティブモードでやると、2回目以降が早くなって良い感じです。ときどきハマっておかしくなったら、さっくり再起動し直せばOK。Ctrl+Cして"grails"+ ENTERキー(ﾀｰﾝｯ が一番早い。
grails> run-app
でWebアプリ起動、
grails> exit
で停止。
実はこのexitコマンド、run-app中かどうかで挙動が変わります。
- run-appしてる -> Webアプリが停止、インタラクティブモードは継続
- run-appしてない -> インタラクティブモードを抜ける
慣れれば別に大丈夫なんですけど、まあ勢いつきすぎて、exit打ち過ぎてWebアプリを停止するだけのつもりがインタラクティブモードを抜けてしまうこともままありました。
で、Grails2.2.0で地味ながらこれが改善されてました。
2.2.0
Webアプリ停止専用のstop-appコマンドが追加されました。
代わりにexitはWebアプリが起動してたら停止しつつインタラクティブモードを抜ける専用コマンドになりました。
クセでうっかりexitコマンドを打つとインタラクティブモードまで抜けるから、慣れるまでしばらくめんどくさい...*1。
2.1.3系
ちなみに2.1.3では単純にexitの別名でしかない模様。
--- a/grails-bootstrap/src/main/groovy/org/codehaus/groovy/grails/cli/interactive/InteractiveMode.groovy +++ b/grails-bootstrap/src/main/groovy/org/codehaus/groovy/grails/cli/interactive/InteractiveMode.groovy @@ -118,7 +118,7 @@ class InteractiveMode { else if ("quit".equals(trimmed)) { goodbye() } - else if ("exit".equals(trimmed)) { + else if (("exit".equals(trimmed)) || ("stop-app".equals(trimmed))) { exit() } else if (scriptName.startsWith("open ")) {
Wow! コマンドの頭数だけ揃えましたという感じですね。
おまけ
InteractiveModeのログみてたら、@kiy0takaのコミットを見つけた。
2012-07-07 00:53 kiy0taka o GRAILS-9250 - fixed open command error.
kiy0takaｶｺｲｲ
*1:コマンド打っててなんか違和感を感じて調べたらこうなってたという
第1回JetBrainsユーザグループに行ってきた #jbugj
はじめに
ヒゲのイケメンが「ブログ書くまでが〜です」とか言ってたので、今をときめくミニブログ()のTwitterに報告を書いたら却下されたので、ミニじゃない方のブログで書きます。
— 山本裕介さん (@yusuke) 12月 12, 2012
IDEAはアイディアと読む
IntelliJ IDEA、と書いてるそばからつい「イデア」とココロの中で読んでしまうので、矯正する意味で、この記事の以降ではカタカナで書いておきます。
リッチなGroovyエディタ
日頃、業務的にもGrails/Groovyを書いてるのですが、Grailsサポートは有償のインテリジェイアイディア アルティメット版のみなので、会社で購入してもらって使っています。
以前、GroovyServでOSSライセンスもらってみたんですが、そのときはもらえたことに満足してろくに使っていませんでした。でそのまま期限切れで更新してません。
最近は割と使ってます。インテリジェイアイディアでプロジェクトを開いて起きつつ、VimとかSublimeとかを併用したりしてます。せっかくの有償機能であるGrailsサポートの機能はあまり使いこなしてないです。Grailsというコンテキストにおける補完機能とかは確かに便利なこともあるけどあまり活用できてない。むしろ単なるリッチなGroovyエディタとして使ってます。というか現状でGroovyエディタとしては最強だと思います。
個人的には
- 余計なことをしすぎず適度にうまいことやってくれるコードフォーマッタ
- import文の再構成
- クラスやメソッド間のジャンプ
あたりを重宝している感じ。
特にコードフォーマッタのできは素晴らしいです。Groovyのコードフォーマッタとして現状ではダントツです。Spockのパラメタライズドテストのwhereの縦棒もビシィッと揃えてくれるところなんかすごく痺れますね。
Vim、Sublime「「さすがアイディア！おれたちにできない事を平然とやってのけるッそこに(ry」」
ちなみに、リッチなGroovyエディタとして使う分には無償のコミュニティ版で十分です。
Ctrl+W : Select Word at Caret
あと、Groovy関係ないですがCtrl+Wによる拡張型範囲選択(?)がすごく便利です。
ショートカットは人によって設定が違うと通じないので、きっちり書いておくと Keymapの"Main menu > Edit > Select Word at Caret"です。
例えば
String hoge = "ほげ";
の「ほ」と「げ」の間にカーソルを置いて、Ctrl+Wをすると、まず「ほげ」だけが選択されます。
その後はCtrl+Wをおすたびに
「ほげ」 「"ほげ"」 「hoge = "ほげ"」 「String hoge = "ほげ"」 「String hoge = "ほげ";」 (行全体) (その行が含まれるスコープの内側(境界含まず)) (その行が含まれるスコープの内側(境界含む)) (以下続く)
ということでうまい感じに空気を読んで、選択範囲を広げていってくれます。
ここまでうまいこと自動的にやってくれるエディタは中々ないんじゃないでしょうか*1。
その他
- Eclipseの機能との比較で語るととっつきやすくてよい
- いまいさんのアドベントカレンダ2012がすごい
- ビールがぬるい
- 「GroovyといえばJava7の勉強会での発表が面白くて気になってました」「それって懇親会のLT?」「はい」「それ、オレオレ」「えっ」「えっ」
- 会場の本棚にGrails本とプログラミングGroovyがあった！
- 作者: 関谷和愛,上原潤二,須江信洋,中野靖治
- 出版社/メーカー: 技術評論社
- 発売日: 2011/07/06
- メディア: 単行本（ソフトカバー）
- 購入: 6人 クリック: 378回
- この商品を含むブログ (145件) を見る
おわりに
正直自分もそんなにアイディアを使いこなせてないので、今後も精進していきたいと思います。のでライセンスください。*2
今更ながらGExcelAPIでJava7サポートしました(スナップショット版)
2010年から永らく放置熟成させておいたGExcelAPIですが、ビルドに使っているGroovyのバージョンが古すぎてJava7で動かないことが判明したので対応しました。
機能面では変わっていませんが、ビルド＆テスト時の依存ライブラリ等をアップグレードしました。
- Groovy 1.7.5 -> 2.0.5
- POI 3.7 -> 3.8
- Java 6 -> 7
これによりJava6でもJava7でも動作するようになりました。
サンプルコードは、本体部分はひっそりとGExcelAPI v0.2をリリースしました - 豆無日記で紹介したままでOKですが、先頭のGrape指定の所だけ以下のように修正してください。
@GrabConfig(systemClassLoader=true) // for workaround a permgen problem with GroovyServ @GrabResolver(name="kobo-maven-repo", root="https://github.com/kobo/maven-repo/raw/master/snapshot") @Grab("org.jggug.kobo:gexcelapi:0.3-SNAPSHOT") import org.jggug.kobo.gexcelapi.* //......
GrabResolverでsnapshotリポジトリを指定してるところと、gexcelapiのバージョンが0.3-SNAPSHOTなところがポイントです。
v0.3としての正式リリースはもうちょっと様子を見てからやりますので、しばし0.3-SNAPSHOTを使ってお待ちください。
というわけで、ご報告ありがとうございました＆ご確認お願いします。> @yamap_55
