{main.places}.js maps.gstatic.com
Error:プロパティ<map>に無効な値:[object HTMLDivElement]
特殊な例かもしれないけど、こんなエラーが出てChromeだと表示されるのに、SafariだとGoogle Mapsがうまく表示されない。
原因：Google Mapsを表示するdivのid属性名をmapにしていたため。これを、areaに変更したらSafariでも問題なく表示された。
他にやりたいこともあって、理由まで調べてないけれどブラウザによって処理を切り分けたりしているんだろうか。
さて、６/２２に京都アジャイル勉強会第６回を行いました。
この辺りが、結構不安だった。
ワークショプが完成してもしなくても、自分たちがアジャイラーとして出荷可能となる為に選んだストーリーの知識・経験・気づきを得られるワークショップを考えるということは、それだけそのストーリーについて考え・知る必要があり、ワークショップを考えるワークショップを行うことで実は既に、知識・経験・気づきが得られているのではないかと感じた。（メタワークショップになっていた感じ）
３チーム中２チームがワークショップが出来たので、実際にやってみたり、やってもらったりしたけれどかなり楽しめたし、気づきが得られた。
今回考えたワークショプもブラッシュアップして行きつつ、ワークショップを考えるワークショップは引続き行って行きたい。
次回は、第７回
隔週で行っている甲斐あってか大分リズムが感じられるようになってきた。
出荷可能な製品が出来上がっている感じがして面白い！
今回は、完全に反省。
正直開催前から一抹の不安はあったのですが、それを解消できないまま開催してしまいました。
反省点。
主催者MTGで@Posauneともう少し当日の絵の擦り合わせが出来ていれば良かったのですが、それができないままだったことに深く反省。
勉強会の前提として、アジャイルサムライに書かれてあるプラクティス（主にインセプションデッキ）をもう一度やり直そうというのが大きくあり、アジャイルサムライ読書会のときにはインセプションデッキの内容を続きで行えなかったので今回はインセプションデッキ〜実際に物をつくるところまでを通しでやってみようという続き物に途中から変わっていきました。
それはそれで問題ないのだけれど、そうなった段階で読書会から参加して頂いているほぼ運営メンバーと呼べる人たちだけを参加者として行えば良かった。
一般参加を募っているいじょう今回の進め方は完全に身内話に巻き込んでしまった感が否めませんでした。
インセプションデッキしているのに、バスに乗っていない人が多数いるみたいな。
既に第４回の募集を行っているので、今回の反省を生かしつつ全員バスに乗って出発できる勉強会にしていきたいと思います。
UnitテストでMockitoを使用していて、Abstractメソッドの実メソッドを呼び出す方法が分からなかったのでその方法をメモ。
すっごく簡単で、mockオブジェクトを生成する際の引数にMockito.CALLS_REAL_METHODSをつけるだけで生成されたAbstractのmockオブジェクトの実メソッドが呼ばれるようになる。
@Test
public void test_OK_リクエストのリモートユーザにログインユーザIDがセットされていること() {
try {
AbstractXXXXAction action = mock(AbstractXXXXAction.class, Mockito.CALLS_REAL_METHODS);
...
// 認証OKになること
Assert.assertEquals(true, action.verifyUserIdIfOkSetSession(req)); ←ここで実メソッドを呼び出してテストしている
...
} catch(Exception e) {
e.printStackTrace();
Assert.fail("予期しないExceptionがスローされました");
}
}
開発環境でBasic認証を使用するために、久しぶりに設定したら場所が全然思い出せなかったのでメモ。
使用したバージョンは
JBoss ：5.1.0(ここで取得：http://www.jboss.org/jbossas/downloads/)
<security-constraint>
<web-resource-collection>
<web-resource-name>プロジェクトリソース名</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>プロジェクトロール名</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method> ←BASIC認証用
</login-config>
<security-role>
<role-name>プロジェクトロール名</role-name>
</security-role>
定義する順番があるので、それを守らないとEclipse上でエラーが出る。
定義の順番まで覚えていないので、よくエラーが出て怒られてしまう。
<jboss-web>
<security-domain>java:/jaas/プロジェクトレルム名</security-domain>
….
</jboss-web>
プロジェクトレルム名は、login-config.xmlを記載する際にも使用する
下記の記載をプロジェクト用に追加する。
<application-policy name=”プロジェクトレルム名”>
<authentication>
<login-module code=”org.jboss.security.auth.spi.UsersRolesLoginModule” flag=”required”>
<module-option name=”usersProperties”>props/hoge-users.properties</module-option>
<module-option name=”rolesProperties”>props/hoge-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
上記で記載したプロパティファイルを下記のディレクトリに作成し、中身をプロジェクト内で使用するBasic認証用に記載する。
ユーザ名=プロジェクトロール名
プロジェクトロール名は、web.xmlで記載したロール名を記載する
ユーザ名=パスワード
後は、HttpServletRequestのgetRemoteUser()から認証に成功したユーザ名が取得できる
基本的には下記コマンドで一発OKなはず。
brew install tomcat
なんですが、
インストール時に下記エラーが出たら
curl: (22) The requested URL returned error: 404
Error: Download failed: http://www.apache.org/dyn/closer.cgi?path=tomcat/tomcat-7/v7.0.23/bin/apache-tomcat-7.0.23.tar.gz
(tomcatのバージョンは違うかもしれません）
対象のバージョンが既に提供されていないかもしれないので、
ブラウザで下記のURLに遷移して
http://www.apache.org/dyn/closer.cgi?path=tomcat
提供されているバージョンで取得したいバージョンを確認して、ターミナルから下記コマンドでFormulaを書き換える
brew edit tomcat
(viが起動する。他のエディタで修正する場合は、ファイルの実態はここ /usr/local/Library/Formula/tomcat.rb)
書き換える場所は、url のバージョン部分。
でもう一回
brew install tomcat
でインストールできるはず。
それで、もし下記のエラーが出たら
Error: MD5 mismatch
もう一度Formulaを開いて
md5の部分をエラー時に指摘されたExpectedの値にかえたらinstallできました（多分これで良いはず）。
岸良さんがAgile Japan 2012で行ったWorkshopを社内で行ってみました。
普段一緒に開発しているチームに岸良さんのプレゼン資料を元に
全体最適と部分最適の話、マルチタスクとシングルタスクの話を行いました。
全体最適と部分最適の話については、一同納得といった感じでした。
常駐派遣でのソフトウェア開発の場合、Command&Controlになりがちで、各人がリスクを背負いたくないというのもあって、プロジェクトマネジメントをしているリーダーに許可や確認を行い後は、各自が自分のベストを尽くすというスタイルが多いように思う（実際それを求められていた）。
プロジェクトがうまく進んでいるときはそれでも問題ないが、プロジェクトがうまく行かなくなったとたんになぜ遅れているのかをマネジメントを行っている人たちが考え、その結果を現場の人に説明して改善するという一方通行的な改善が行われる場合が多い気がする。
その場合、人に着目せずにやり方やプロセスが間違っているという改善案が多く(そういう時もあるんだけれど)、アプローチにしても全体の速度を一気にあげるような改善案を試している。
管理社：「改善案を考えました！これできましょう！」
開発者：「・・・」
実際は、開発者同士がコミュニケーションをとることで現場が考える問題点を洗い出してマネージャーは開発者が考えた改善案を実施するために必要な権限を与えたり環境を整えるだけで開発速度は増すのではないかと思う。
その手段として、チームで協力し開発速度が遅くなりがちな人や工程を皆でカバーすることで改善を行う。
こうすることで、チームがどんどん改善を行うためのコミュニケーションをとり始め、自分たちで開発しているというやる気が起こり、開発が面白くなっていくと思う。
遅れている原因がなんであれ、マネジメント層だけで考えるのは避けたい。
次にマルチタスクとシングルタスクについての話
「１〜の数字」、「A〜 のアルファベット」と「○、△、◇の記号」を３０ぐらい？縦に記載して行きマルチタスクとシングルタスクを実践するというワークを行いました。
最初に自分がどれくらいで終わるかの見積もりを行ってもらいました。
１回目は、数字→アルファベット→記号→数字・・・と記載する。
２回目は、数字３０個→アルファベット３０個→記号３０個と記載する。
１回目は、全員見積もりをかなりオーバー（終わらなさすぎて途中で打ち切った）しました。
そして2回目。全員ほぼ見積もりに近い時間で終わった。
見積もりした時は、前提条件として一つのタスクに”集中”出来た場合これくらいで終わりますという見積もりに成っているということ。
実際の開発ではそんなことはあり得なくて、何らかのコミュニケーションを取ったり、確認作業が発生するためタイプしていた時間は見積もりに近い値かもしれないが、作業開始から完了までの時間は見積もり時間をオーバーする。
マルチタスクとシングルタスクをお手軽に認識するためにはとてもよいワークショップだと思う。
これを気に見積もりについて皆で話し合うときのコンテキストの一つをチームで揃えられました。
#xpfes12
TDDとスクラムの事例がお目当てでXP祭り関西に参加してきました。
システムインテグレーター 梅田弘之氏
概要は、アジャイルでもプロジェクトマネジメントは必要だという話。
ご自身が取締役社長ということで経営者からみてアジャイル開発がどう見えているのかという内容でした。
ウォーターフォールを敵視するな
基幹業務などでは、ステークホルダも多く色々な調整を行ったりしていれば、要件定義に３ヶ月かかってしまうこともあるわけで、その辺りを理解する必要がある
たしかに、基幹業務などでは億単位の金額が扱われたり関係する部署がとても多かったりでヒヤリングするのにも結構時間がかかると思う。実際、中には色々な人がいて（そもそも利用者が物理的に遠かったり）すんなりヒヤリングできるわけでもなかったりするし。
ただ、要求を決めるためにかかった３ヶ月がどういった内容かにもよるかなとも思いました。
一度に要求を決めようとすると要求を決める関係者それぞれが少しずつ返信が遅くなるだけで結構な待ち時間ができて、それが積もるとそれなりの時間になり結果的に要求の決定が遅れるという事態の原因の一つになるのかなと。
ウォーターフォールの場合、フェーズ毎に作業が進んでいくため後工程になればなるほど手戻りの発生する箇所が増える。
それを意識するあまり、仕様の決定が遅れかつ、納期がまだまだ先なため決めきれないというのがあると思う。
そこに、タイムボックスを適用することで要求を決める人も全ての要求を要求定義のフェーズで決めきらないと駄目だと思っていたのが、この機能についてだけ決めてくださいに変わるので、要求分析やヒヤリング対象が絞られて要求が決めやすいのではないかと思う。
ただ、適用が難しいかなと感じるのは、実際のリリースはずいぶん先なのに１イテレーション（スプリント）の終わりを本当のリリースと同じように扱えるかというところ。
要求を決める人が今回はスクラムを行うと同意している場合は協力的になってもらえる（もらえないと困る）と思うが、要求を決める人が加えられずにスクラムを行う際のリスクはこのタイムボックス内に要求を確定してもらえないというところかなと思う（アンチパターンだけど）。
ウォーターフォールは、売れる物を作るのが苦手
梅田さんのところでは、パッケージ製品の開発が主な開発でその際パッケージ作成とそのパッケージをお客さんに導入する開発は別と仰っていた。
パッケージ作成は、内部の開発だからハンドリングがすべて会社でできるためアジャイル開発向き
ウォーターフォールは売れる物を作るのが苦手
たしかに自社製品を作るのに、ウォーターフォールでは作れない。
お客さん向けの仕事にどうアジャイルを取り入れるかが最大の課題でありチャレンジ
アジャイルでやっても作るものによって犠牲にすることが異なる。
プロダクト開発は、スコープを犠牲にできる。
請負開発は、コストを犠牲にするしかない
請負開発とプロダクト開発で犠牲にするものの違いは全くその通りだと思う。
この違いは、
プロダクト開発はスコープを犠牲に出来るけれど、犠牲にしたスコープによって製品が売れるかどうかのリスクを自社で追う必要がある。
逆に請負開発はコストを犠牲にするけれど製品が売れるかどうかへのリスクは自社で追う必要はない（発注側で仕様を決めてしまうから。作った物は売れてほしいけれど）。
どのリスクをどちらが負うかによって、犠牲に出来る物と出来ない物が変わってくる。
請負の際にいつも確認するのは
「納期は最大どこまでのばせますか？」
ここを聞いておかないと仕様変更・追加に対してコストをかけたとしても残業や休出、過剰なメンバ追加しかコストをかける時間がとれなくなってしまうため、プロジェクトが遅れ始めるとひどい生活が始まってしまう。
請負開発では、コストを犠牲にするしかないけど生活は犠牲にしたくないというのを、死守できるかどうかは納期が最大どこまで延ばせるかにかかっていると思う。ここで見積もりも合わず、納期も絶対延ばせない案件だと受けないか最悪工数ベースの契約に持って行く場合が多い。
@irof氏
irofさんのセッションに参加するのは初めてで今回一番楽しみにしていた。
最初にしっかり「京都アジャイル勉強会」の告知もして頂いた。ありがとうございます。
以前アジャイルサムライ読書会in京都の懇親会で、テスト版９７のこと（あのときはこっちが本編だったな）を教えて頂いてそれ以来自分の中でのTDDへの最初の壁が取り払われた。それから、テストと並走してプログラミングする毎日を送ってます。
前後のテーブルと会話する形式だったので、メモしきれなかったのだけれど残ったポイントは
変化しつづけるものは変化に強い
テストと合わせてjenkinsを使っているとこの言葉は自分的には納得。実際救われたことは何度もある。
思った通りにうごくコードをかく技術がTDD
通常は、書いた通りに動く。だけど、思った通りにうごくを実現するためには、テストが必要。
リファクタリングの終わりどころは次のRedが一つになったら終わり
仮に一つ修正加えたらRedになる箇所が、複数ある場合はまだリファクタリングできるとのこと。
どれも禅問答のような言葉だけど、話を聞いているとストンときます。
きっと自分で気づかないと意味がないから自分で気づきやすいように考えてもらって結果を共有して、自分の意見を述べるというセッションにしたのかなと思った。
例え悪いかもしれないけれど、倒幕するときにも草の根運動のようにこのような議論の場が持たれて最後は大きな仕事に結びついたように感じた。
なので、チームへの啓蒙の第一歩は、自分がテストを書き続けて周りにその良さを広めることでしか実現できない（もしくはirofさんのセッションを受ける!?）と思うので、やっぱり自分が書き続けて周りにTDDの良さを感染させるしかないのかなと思いました。
田口 昌宏氏
大規模なゲーム開発で実際にスクラムを取り入た際の事例紹介でした。
面白さを見積もり時に組み込むことは難しい
スクラムに取り組んだ際の動機だったと思う。
午前の梅田さんのお話ともリンクするのだけれど、試行錯誤する開発についてはスクラムはとても適用しやすい。
１スプリント２週間で隔週水曜日にスプリントプランニング
火曜日にレビュー、お菓子付きショーケース
懇親会に参加できなかったので、聞けなかったのだけど水曜日にスプリントプランニングを設定したのはなぜか聞きたかった。
田口さんのお話を聞いていて一貫して思ったのが、まずやってみる。
それで問題が出たら、その問題を解決するために対処する。それがスクラムのツールでカバーできるところはツールを導入し、その導入もただ入れてみるのではなく実際にチームに適用するように随所に工夫が施されていた。
（コミュニケーションに問題出たので朝会導入。ただし２チームで朝会の開始時間をずらして実施。それぞれの朝会の内容を共有できるようにしたなど）
スライドの写真を見ていて思ったのは、参加している皆が本当に楽しそうにやっているところ。
朝会やタスクボードでかしこまったミーティングがなくなった。
確かに、かしこまったミーティングがあるところは日常的にコミュニケーションに問題がある。
プロジェクトが遅延してくるとミーティング多くなるのはこのせいかなと感じる。日頃からコミュニケーションがとれていれば、遅延してきたからといってミーティングを増やす必要はないはず。
３〜４時間のプランニングで制度の高いものが出来る
これは、プランニングポーカーしているととてもよく思う。自分はそこででた意見を実際に見積もりや開発時のチェック項目としてあげたりしている。
京都アジャイル勉強会でもプランニングポーカーをしていると、自分が考えていなかった意見がぽんぽん出てくるのですごく参考になる。
10名超えると朝会で話す内容が薄くなったので、チームを分割。スクラムマスタも２名に導入
壁は情報発信継続力がすごいし、壁は解像度が高い
ショーケース時の品質は、落ちたらアウトぐらいにしている。全テストを通らないと駄目とかではない
などなど。
参考になることばかりだし、すぐに自分も取りいれて自社ではどうなったのかを共有したいと思うことばかりでした。
もっと色々聞きたかったのだけれど、懇親会には参加できなかったのでまたどこかでぜひお話を聞きたい。
スクラム開発を取り入れている人の話を聞いていると、「巻き込み力」とでもいうのか回りの人をその気にさせるのがとてもうまいなと感じた。
スクラムに限らずだけど、知→無知への提案はなぜか上→下のような関係になりやすい気がする。普段からの関係性がとても良好なので提案しても上→下の関係にならず対等に論じあえるのだと思う。
日頃から傾聴することが大事だとつくづく感じた。
アジャイルサムライ読書会in京都が終わり、引続きアジャイル導入を考える方達（自分も含め）のための勉強会を京都で行うということで、そのまま「京都アジャイル勉強会」という名前で、人も内容もほぼそのままに始まりました第一回。
アジャイルサムライは読んで終わりでなく、実践して経験値を積むときの指南書となる本だと思うので「京都アジャイル勉強会」では、アジャイルサムライにでてくる数々の手法を本番前に何度も経験し失敗し、本当に身体で覚えるまでやって本番は楽に乗り切ろうという試みのもと行っています。
もちろん既に本番をやっているけれど、経験値を積みたいという方も大歓迎(実際に数名参加されています）。
第一回となる今回は、「色々試そうプランニングポーカー」と題してプランニングポーカーで色んなことを試して、試した結果を皆で考え共有しようということで行われました。
参加者が、１１名だったため、５名、６名の２チームに分かれて各藩で、プランニングポーカーの見積もり対象となるシステムを決めてそのユースケース出しから入りました。
私の藩は、「オンライン上の年賀状作成ソフト」です。
そこから、１０こ程度のユースケースを考えて、そのユースケースに対して見積もりを行いました。
最初に手持ちのカードは、１、３、５、？の４枚。
３を基準値として「仕様が大きくぶれにくく規模が大きくも小さくもないユースケースを３としました」。
その後、それ以外のユースケースの見積もりを皆で行いました。
４枚で見積もりした内容を今度は、１、２、３、５、８、？の６枚にして行い枚数が増えることによって、結果や思考がどう変わるのかを試そうという試みでした。
実際は、１回目の見積もりの内容が本当にシステムを作るかのように議論が熱くなり２回目の見積もりは駆け足となってしまったため詳細に比べることが出来なかったのですが、１回目で見積もりできたユースケースに対してのみ２回目の見積もりを行ったとところ面白い結果になりました。
１人は、２が入ったことで１よりは大きいけど３よりは小さいから３を出していたのが、２が出来たことで２に変わる
もう１人は、８が入ったことにより３よりは大きいけど５よりは小さいが５をだすとそれ以上大きい値がなくなるため３としていたけれど、８が入ったことにより５に変わる。
ということを考えていました。
だしたカードが同じだからといって同じ判断でそのカードを選んだとは限らないということが分かる。
ということは、見積もり時のユースケースの粒度によってはカードの枚数を６枚程度で行いあえて意見が割れるようにしてみることで、チーム内の意見を引き出し安いと感じた。
あと面白かったのは、説明しているうちに意見が変わってしまうことが多々あったこと。
実際の見積もりだと見積もりが合わない場合に、各機能についてどうしてこんなにかかるのかということを延々と話し合い結果数人日とかひどいときには数時間の削減を迫られたりするのだけれど、実際数ヶ月前に数人日や数時間の想定をしたところでいざ作業に着手したとたんに、あれが必要これが必要とかであっという間に数人日オーバーになっていく。
相対見積もりだと議論になる箇所が、見積もり工数ではなく仕様や前提条件になるため不毛な工数削減に合いにくくそもそも、詳細ではないくせに詳細な話になることが防げるということを改めて実感した。
また、今回ユースケースについてはあまり時間をかけずに作成したため、内容についての前提条件が確定していなかったこともあり、実際にカードを出し合ってからの議論が長くなった。
見積もりを行う前に、ユースケースの前提条件や理解度を合わせておいた方が工数の決まっている本番では良いと感じた。
CSMの研修でプランニングポーカーを行った際も、仕様について１５分ほど話し合う時間がさかれたと思う。
ただ、その時面白かったのは出された仕様をチームで検討する時間を与えるので、仕事を受けるかどうか答えてくれというもので、検討後チームの代表が前に言って講師に仕様を受けるかどうかを聞かれた際にチームの代表の仕様についての質問はいっさい受けずに、とにかくYesと言わせようとしていたこと。
で、あまりの講師の圧力になし崩し的に大半がYesと答えてしまっていた。
ここでは、絶対に圧力に屈しては駄目で即席の見積もりや、安請け合いは結局交渉の条件に使われてしまうという教訓だったと思う。詳しくは「リスバーガー」で検索すると分かる。
次回も引続き「色々試そうプランニングポーカー」をやります。
Agile Japan 2012に参加！ #1に引続き午後のセッション２
「アジャイルをも活用した新しいビジネスモデル」に参加
受託開発をやっている身としては、
発表されたときからすごく気になっていたビジネスモデル。
永和システムマネジメントさんの「価値創造契約」について
詳細はこちら
http://www.esm.co.jp/new-agile-contracts-service.html
気になっていたポイントは、
お客様にどうメリットとして受け取ってもらうのだろうか？
というところ。
チケットという単位でサービスを作ってもらうことで、
今までよりお客様にとって何が良いのか？
聞いた内容や質問した内容をまとめると
参加者から「チケットという概念がお客様にとって理解しがたいのでは？」という質問があり、
ピボータルトラッカーにやりたことを追加していってもらい１チケットの分量や内容を状況に応じてお客様とすりあわせている。
チケットプランは、目安であって当てはまらない場合は柔軟に対応している。
とのことだった。
肝心の気になったポイントの明確な回答は得られなかったけれど、お客様の評価が良いということが何よりうまく言っている証拠だと感じた。
自分が実際に提案するなら、信頼貯金がたまっているお客様へは提案して受け入れてもらえそうな気がするし、気に入ってもらえそうだと思う。
また、早いサイクルで動く物が手に入りかつ、着手前なら優先度も変更できるわけだから一度価値創造契約を体験したお客様は元の受託契約には戻らないのではとも思った。
難関は、信頼貯金がないor新規のお客様へどう説明するか。
これは、Agile開発をお客様に提案することと同意かな。
ソニックガーデンさんの「ソフトウェアパートナーシップモデル」について
詳細はこちら
http://kuranuki.sonicgarden.jp/2011/09/post-50.html
聞きながらなので、かなり端折ってしまうけれど
「価値創造契約」のチケットという概念について聞かれて、
チケット性を導入してしまうと、１チケットでどこまでできるという見積もりが発生してしまうから取り入れなかったと言われていた。
開発にあたるメンバーには、かなりのスキルが必要とされるため人材育成が大変なのでは？という質問に対しては、
徒弟制で行っている。
また、格安で研修生が行うことを選ぶことも可能で、その品質は師匠が担保する。
新人はそれで育って行き、雑用の用なことはさせない。
中途を採用する場合でも、週１ぐらいで半年ぐらいの面談を行って見極める。
とのこと。
聞いててため息が出るくらい、徹底している。
ここまで徹底するためには、新しい会社でなくては駄目なのも納得。
ただ、あこがれても既存の会社をここまで徹底したものに仕上げる労力を費やすぐらいなら(不可能に近い)転職転社した方が、本当にやりたい事をすぐ出来るのだろうなと感じた。
全体を聞き終わって感じたことは、
永和システムマネジメントさんの「価値創造契約」は、既存の会社でAgile開発に適応した契約形態を考えた場合に生み出された契約形態だと思った。現実→理想という思考かな。
ソニックガーデンさんの「ソフトウェアパートナーシップモデル」は、理想の契約形態を想像した上で、現実の受託開発に落とし込んだ結果生み出された契約形態だと思った。理想→現実という思考かな。
今の職場がどちらに近いかで考えると「価値創造契約」に近い契約形態を生み出さないと顧客を巻き込んでのAgile開発は難しい。
もしくは、 カンパニー制などであれば、完全に仮想プロダクトオーナーをたてるというのもありな気がする。