GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Amr Elssamadisy , 翻訳者 金森 諭 投稿日 2009年7月29日
Gordon Pask賞
Gordon Pask賞は、アジャイルプラクティスへの貢献をおこない、アジャイルを実践する他の人々が見習うべき2名を委員会の選出により表彰するものです。各受賞者は、人々が見習らうことができるよう2つの大陸地域の2つの適切なカンファレンスへ赴くための資金提供をAgile Allianceから受けられます。受賞者は、アジャイルな考えをもった次世代リーダの育成の目的のため、主要な実践者としてまだ名声が広まってないなどの理由によりカンファレンスの常連となってない人が対象となります。
あなたにとってのメンター(助言者)
私たちは次のGordon Pask賞の受賞者を選ぶためにみなさんの協力を求めています。みなさんが推薦する人について、氏名・emailアドレス・200語以内の推薦理由を書いてpask-nominations@agilealliance.orgまで送ってください。
Gordon Pask氏の精神(下記)の基づき、みなさんが直接対面して学ぶことがあった人の推薦を望みます。ご自身以外の人にも推薦に連名してもらうのもいいかもしれません。連名する人の数は必ずしも重視されるわけではありませんが、推薦された人について私たちがより多くの人にヒアリングできることになります。Agile Allianceのサイトでは以前の受賞者を見ることができます。この賞の設立者であるBrian Marick氏は、選考過程がいつも難しいものである、と次のようにコメントしています。「明確な基準がないことに私たちはいつも頭を悩ませています。・・・プログラミングの賞の性格が強すぎる、マネジメントの賞としては十分でない、といったもっともな意見を多く受け取っています」。推薦者の中には毎回、委員会が「この人は私たちの支援が本当に必要なのだろうか」と考えた時にあてはまらない人が多く含まれています。
推薦は2009年8月1日まで受け付けています。
Gordon Pask賞について
2006年の受賞者であるLaurent Bossayit氏はこう語っています。「アジャイルコミュニティの優れた特色のひとつは、新しい声に耳を傾け、独創的な寄与をおこなうためのスペースが用意されていることです」。このコミュニティは対面して話し合うことで理解を広げられるという考えを大いに受け入れています。このコミュニティは思慮深い批評家でも新しいファンでも出来ることがあると信じています。会話を重視するのはGordon Pask氏や他のサイバネティック主義者の業績に影響を受けているところがあります。この人たちは、実際的に「影響をあたえなかった。そして引退して死んだ。それはある種の終わりだった。次の波を生むのに成功しなかった人たちの最初の波だった」とBrian Marick氏が語る人々です。この賞に対するAgile Allianceのサポートはアジャイルの分野における成長と発見を育む強いコミットメントの表れであり、James Shore氏(2005年受賞者)が言うように現在のところ「アジャイルコミュニティが与える唯一の賞」であるということからもその重要性が表われています。
アジャイルは社会的現象 このコミュニティは職人たちの集まりです。お互いに刺激を受け合い継続してスキルを磨いています。Bossavit氏はこう語ります。「私はアジャイルの"オフィシャル"創始者の一人という肩書きから多くの利益を得ています。多くはマニフェストに調印した人たちです。・・・(しかし)XPであれ、Scrumであれ、どんなことであれ、本や論文を読んで学べたことはありませんでした。理解を深めることができたのは、いくつものコミュニティに対話的に参加する機会からでした。それにはWard Cunnigham氏(WikiやXPの創始者)のWikiおよびXPのメーリングリストのようなオンラインのコミュニティや、ヨーロッパXP200*カンファレンスやXP Daysのようなリアルライフでの集まりなどがあります。Jerry(Gerald) Weinberg氏とは"ピープルソフトウェア"に情熱をもった人たちのコミュニティを育てることや、ソフトウェアの人間的、社会的、心理的な面についてかなり議論をしました」
アジャイリストは働くこと、学ぶこと、そして教えることについてより良い方法を見出そうとしています。2005年の受賞者James Shore氏は「試してそれが有効かを見る」ことで学んだと言いますが、それだけではありません。彼は地域のアジャイルユーザーグループに関わることからも多くの知見を得ました。「私の問題を持ち込んでそれについて語り、私が「それはうまくいかないんじゃないか」と言い、それを試してみた後にグループへ戻ってきて「ええと、なんというか・・・うまくいったよ。ぼくがしたのはコレコレなんだけどこういう新しい問題も出てきた」と言うのです。もっと多くの人がこういう経験をしてほしいものです」。実際にすることで学ぶことについてはこう言います。「トレーニングが役立つこともあります。・・・本からそういうことを取り出すのです。・・・(しかし)そういうことを以前にしたことがあるリーダーによると、そのようなことを自分でおこなうことが早く活用する上で断然に一番の方法だと言います」。レクチャー形式のトレーニングをする代わりに「ストーリーを伝えることが理解の助けになる」と2005年受賞者のJ.B.Rainsberger氏は述べています。もしみなさんがどこかのアジャイルカンファレンスに行くと、そこではコミュニケーションを向上させることに重点をおいたゲームやワークショップ、討論、その他魅了されるインタラクティブな催しがされていることを目にするでしょう。さらに、ユーザーグループやカンファレンスだけが活き活きとしているわけではありません。「アジャイルはソフトウェア開発に自由とクリエイティビティとイノベーションを取り戻させます。アジャイルはソフトウェア職人たちが人生をより簡単に楽しめるようにします。私はこのようなムーブメントの中にいることを嬉しく思います」と2007年受賞者のNaresh Jain氏は語っています。
Gordon Pask氏の考え方 ― 話すことで理解を深める
Gordon Pask賞はアジャイルコミュニティに特別なメッセージを刻んでいます。「多くの著名人がアジャイルに対する独断的で堅苦しい見方を発表しています。しかし私の経験からすればアジャイルはそのようなものではありません」とNaresh Jain氏は語ります。"著名人"たちによる大衆への発信による問題点は、Gordon Pask氏の観点からすると、共同学習を失うことにあります。アジャイルについて厳密な見方をすることが間違っているというのではありません。James Shore氏はこう述べています。「アジャイルのこのやり方はできない、という言い方はできません。そう言うと、「別の方法で問題を解決するにはどうすればいいか」と自問しないで「そんなに厳しいのか。アジャイルのその部分だけが問題だと思っているわけではないのに」という人たちがいます」。氏は新しく来た人によって「型にはまらずに良い方法を探すことでより良くなる」ことを説明しています。ルールの条文に従おうとすることは、アジャイルによって約束される生産性を得ることにはつながらないのです。「2週間のスプリントを実践できているからえらいのではありません。コミュニケーションを増やしていく、同時進行で働くことが素晴らしいのです。いくつかの状況が同時に進行することもまたコミュニケーションを増やす手段です。コミュニケーションが増えれば、あとは野となれ山となれ、という精神状況に陥らなくてもすむのです。」
Kent Beck氏は自然界の自己相似性、つまりさまざまなサイズや環境において複製される有効価値のあるデザインパターンについて語っています。コミュニケーションが仕事の効率を向上させ助けになるという事実(仕事だけでなくアジャイルコミュニティも同様ですが)も、2008年の受賞者である平鍋健児氏が極めた自己相似パターンです。氏は、自分が受賞したのでなく日本におけるコミュニティの強さによって賞がもたらされたのだと言います。この個人でなくコミュニティがもつ明らかな価値は、日本でのカンファレンス開催の営業活動にも表れています。「私たちは"ペア割引"という料金を設定し、上司やクライアントと一緒に参加することを強く推奨しました。結果、75%の人がペアでやってきたのです!このことは、エンジニアと経営者とクライアントがお互いに話をするようになった兆しであり、それによりソフトウェア開発の世界がよくなっていくと信じています・・・。これまでアジャイルが日本に浸透する中で、人が集まり素晴らしいコミュニティが形成されました」
今度はみなさんの番です。みなさんを助けた人を推薦しましょう。できれば、何人かの仲間と直接集まって推薦する人を決めてみましょう。それにかかる時間はこの記事を読む時間より短くてすむはずですから!
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信