恣意的な判断で、これは5日ぐらい、という判断をするのではなく、判断の基準となる過去のデータを調べて予測すること。その参考とする過去のデータってなんなのよ?という詳しい説明は本書でなされている。範囲での見積りシングルポイントで5ヶ月です、というような見積りをするのではなく、7ヶ月から+-2ヶ月です。いうような範囲で見積りを出すようにし、プロジェクトの進行とともにその範囲が狭まっていくようにする。それぞれの見積りごとに正確性の割合を出すと良い。5ヶ月でリリースできる確立は15%ですが9ヶ月でリリースできる確立は90%です、のような感じ。上記のほかにも、ステークホルダーにどのように見積りを認めさせるのか、など交渉のヒントにも言及されている。本書を読むといくつかのすぐに使える技法を学ぶことは可能だが、だからと言って翌日からすぐに正確な見積りができるようになるわけではない。いうのも、基本的に正確な見積りを行うようになるには組織全体として取り組む必要があるので、中長期的な視野にたってそのことを煮詰めていく必要がある(過去のデータを収集するあたりなどとくに)。正確な見積りのためには開発者個々人の見積りに対する高い意識も必要とされるので、そういうのを根付かせるための材料として本書を使うこともできるなと感じた。--------------------以下、本書を読んでいないと意味不明だと思うけれど、自分的メモ用に気になった公式をいくつか抜粋。最良ケースと最悪ケースの見積りを考えるようにする。何も言わないと開発者は大体最良ケースに近い一点見積りを行う。書籍2011年7月2日土曜日LambdaExpressionで動的な検索条件を作る最近の仕事で固定の検索条件ではなく動的に検索条件を作りたいという仕様があり、それもあってExpression周りをいじくりまわしていて楽しかったので解説する。今回のサンプルコードはこちらからダウンロードできる。Treeと戯れる必要がある。Treeに変換してくれる拡張関数群が公開されているので、文字列をいじくるのを苦にしなければかなり簡単に動的な検索条件を作成することが可能だ。Entityだとそうはいかないのでちょっと込み入ったことをしなくてはならない。動的検索条件と言っても、すべての検索条件がAnd条件であるならば、単純にWhereメソッドを下記のように順々に呼び出していけばよいだろう。);※今回の解説の仕様として、等号などのオペレーターや対象プロパティは事前に決まっていてどの条件を組み合わせるかのみ動的に設定できる、という設定とする。Treeをいじる必要があるのでその解説は次回以降行う、かもしれない。Or検索が間に入ってくると話が変わってくる。前述の方法ではWhereメソッド間はAnd条件になるので動的なOr検索を行うことはできない。いうわけで、LambdaExpressionの登場だ。こいつを上手に使ってやると下記のような条件を簡単に動的に組み立てることができる。c.Name.EndsWith("城"));今回使用するモデルは下記。First4.1に全部任せている。}}前述の各条件を表すLambdaExpressionは下記になる。c.Name.EndsWith("城");このままでは各LambdaExpressionはばらばらなので一つにまとめる必要がある。その際に注意が必要なのだが、LambdaExpressionを統合するには同一の引数を使用するように変更してやらなければならない。上記の定義を見てもらえば分かると思うけれど、各LambdaExpressionにはcという引数が定義されている。Tree的にはcondition1のcとcondition2、condition3のcはまったくの別物なので、こいつらを一つにまとめる必要がある。そんな面倒なことを行う際に便利なクラスがC#4.0から提供されている。それがExpressionVisitorクラスだ。このクラスの使いどころは次のような場合だ。Expressionには多種多様なタイプが用意されている。toステートメントを表すGoToExpression、ループを表すLoopExpression、メンバーアクセスを表すMemberExpressionなどなど数十種類に及ぶ。今回は引数をいじくる必要があるのでParameterExpressionが対象になる。Treeを順々にたどっていって任意のExpressionを探すのは骨が折れる。そんなときはExpressionVisitorクラスを使用する。使い方はExpressionVisitorクラスを継承し、自分が気になるタイプのExpressionを引数としているメソッドをオーバーライドするだけだ。今回はParameterExpressionをいじくるのでVisitParameterがオーバーライドするメソッドになる。}}ParameterVisitorクラスは変更元の引数コレクションと変更先の引数コレクションを保持し、ParameterExpressionが見つかるたびに、その見つかった引数(上記で言うところのnode)が変更元の引数と同一かをチェックし、同一であれば、変更先の引数を返却している。Treeは差し替えられている。変更元の引数の数と、変更先の引数の数が異なる場合はアボンするということなので注意が必要だ。ParameterVisitorクラスのコンストラクタにそれようのチェックコードを入れるのも良いだろう。実際にParameterVisitorクラスの使用方法は下記になる。}}各メソッドともに、まずはVisitメソッドを呼び出し、二個目の引数のLambdaExpressionの引数を一個目の引数のLambdaExpressionの引数で差し替えている。その後にAndAlso、またはOrElseを呼び出しExpressionの統合を行っている。Helperクラスの使い方は下記になる。condition3);そうしてできたLambdaExpressionをWhereメソッドに渡してやれば下記と同等の記述になる。query.Where(condition);かなり冗長になるけれど、上記の方法以外にも下記のようにWhereメソッドを呼び出すこともできる。query.Provider.CreateQuery<Castle>(resultExp);今回の例では下のほうの呼び出し方をする必要はまったくないけれど、オペレーターやプロパティも含めてすべてを動的で行う場合などで、Anyやら何やらを動的に呼び出す必要がある場合は、最後に解説したような呼び出し方をしなければならない。ヤル気こそプロジェクト成功の鍵』を読んでみた。デッドラインは小説仕立てで読みやすいのは良かったけれど、たまに得心のいかない法則が出てくるときもあり「?」となる場合があったけれど、ピープルウェアはデッドラインと同じような素材を扱いながらも違う視点から切り出してあるのでデッドラインで学んだ法則の理解を補強するのに役立った。それに各章ごとに内容にそった小話的な実話がちょこちょこ挿入されているので読んでいて飽きない工夫がされているのも良かった。全6部構成で各部それぞれ下記のようなことが学べる。管理するとはやってはいけない管理方法がわかる。思考を電話などによって頻繁に中断されることがいかに頭脳労働にたいして悪影響かがわかる。オフィスのレイアウト周りの話なんかはあまり興味がないけれど、オフィス移転を考えているような人には良い参考になると思う。人材をそろえる効果的な方法や退職に伴うコストなどが解説されている。下記の企業側からみた退職のコストの考え方は意識したことも無かったので目からうろこで面白かった。生産性の高いチームを作る方法チームの効果を高める方法について、良い方法、悪い方法が解説されている。要はやる気ということで、それをどのように高めるかというお話。仕事を楽しくするには~とくに感想なし。第6部1~5部それぞれの小さな続編。手を動かすほうが好きなので管理とかにはあんまり興味がないのだけれど、後学のために『デッドライン―ソフト開発を成功に導く101の法則』を読んだので感想とか内容の覚書とか。技術系の本は読むけれど、こういうノウハウ系の本はあまり手にとったことがなかった私にとってこの本の内容は「ものすごくためになった!」とか「明日から即実践しよう!」とかそういう感動系のたぐいではなく、「あぁ管理ってこういうものなんだ、へー」という感じに曖昧模糊としていたものの理解を助けてくれたり、「あぁこういう問題が起こりえてそういうときはこういう風に対処すれば良いのね」という先駆者の知恵を授けてくれた。内容は小説仕立てで、各章の最後にその章で主人公が学んだことを法則として小説のなかから抜き出してまとめてくれるので、さくさくと読んでいけてあっという間に読み終わる。そのままにしてしまうと脳みそからすぐ抜け落ちてしまうことは確実なので、101個の法則のなかから気にいった法則を下記にまとめておいた(結構な数になったけど)。高めるTeamの結束を強め維持する変更はプロジェクト成功のために必要不可欠である人は安全が保証されないと変更を受け入れないリスクをさけるとそれに伴う利益も逃がすどれほど強く脅しても最初に割り当てた時間が足りなければ仕事は完成しない管理は、心、腹、魂、鼻でやるもの。採用には心、魂、腹、鼻すべてを使う(腹が大部分)一人でやろうとするな。二つの腹には一つの腹の2倍以上の力がある新しく採用した人材は、能力実証済みレベルのプロジェクトを任せ目標を拡大するのは次回以降とする意見をもとめよ。短期的に生産性を高める方法などない。成功を最大化するより失敗を抑えることによって全体的な成績を高めることができる失敗した作業は早く打ち切る勇気をもつチームの結束については既存のチームを探して利用したほうが楽だったりする結束力のあるチームはばらさずに維持する(本人たちが望めば)。病んだ政治=政治的な理由からくるむちゃくちゃな要求(機能はそのままで納期を半分にしろなど)いつでもクビをかける覚悟が必要であるそれでも病んだ政治の影響を受けないとは限らない病んだ政治はもっとも健全な組織にも出現する可能性があるプロジェクトの数量化すべての製品のサイズを測定せよ単位は気にするな。優れたプロセスとプロセスを絶えず改良することは立派な目標である。それらはまたごく自然な目標でもある。すぐれた技術労働者は指示があろうとなかろうとそれらに焦点をあてる形式的なプロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのためにプロジェクトが後退することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトでプロセス改良のために費やされた時間を相殺できる可能性は低い(次以降に効力を発揮する)プロセスは注意深く選んだひとつの手順改良によってその変更に投資した時間と金に報いるだけの利益を期待できることがあるプロジェクトの期間中に二つ以上の手順改良に順応することは現実には期待できない標準的なプロセスの危険な点は人々が懸命な省略を行う機会を失わせることである。管理者の怒りと侮辱は伝染する。仕様書があいまいなのはシステムの利害関係者の間で対立が解決されていないしるしである入出力の完全なリストのない仕様書は見込みなしである。開発に複数の当事者がかかわっている限り、利害の対立は避けられないシステムの構築と導入の事業にはとくに対立が多いシステム開発組織のほとんどは対立解決能力に乏しい対立は尊重すべきである全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベルで勝利条件を引き出すようにする交渉は難しいが、仲裁は簡単だ勝利条件が相容れないか、または部分的に相容れない場合でも関係者が対立解決のために仲裁に移行するようにあらかじめ準備しておくわれわれは味方同士である。敵は問題そのものだ触媒のような人格というものがある。そのような人はチームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒の役割は重要で貴重である仲裁は触媒の役割の特殊なケースである。初期に人数が多すぎるとプロジェクトは重要な設計作業を省略せざるをえない(全員に仕事を与えるため)。会議は重要ではない人物が出席しなくても心配のないように小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行しそれに厳密に従うことである罵倒などの怒りから人々を守るために手を打つ怒りは恐怖である。病んだ政治を下から治療することはできない。Engine(GAE)にC#プログラムからログインする方法を解説する。GAEで特定のUrlに対して、特定のユーザのみにアクセスを許可する場合はapp.yamlで下記のように設定をすればよい。requiredこれでGAEアプリのユーザのみが上記Urlへのアクセスが可能となる。Id)のログインページへとリダイレクトされる。そこでユーザ名とパスワードを入力してログインすれば上記のUrlへとリダイレクトバックされる。これがブラウザ上の動作であれば問題はないが、プログラム上から認証を必要とするUrlへとアクセスする場合は困る。認証を必要とするGAEアプリのUrlに対してリクエストを行う場合は下記の手順で行う必要がある。ClientLoginサービスにログインしAuthトークンを取得する取得したAuthトークンを利用しGAEアプリにログインしCookieを取得する取得したCookieとともにHttpGETやらHttpPOSTを行う各項目を順を追って説明する。auth;}まずhttp://www.google.com/accounts/ClientLoginへと必要な情報をポストする。各項目の詳細な説明は下記を参照して欲しい。Applications今回は最終的にGAEアプリへとログインしたいのでserviceはahとなる。これがカレンダーであればclなどそれぞれに対応したものへと変わる。ログインに成功するとSID、LSIDとともにAuthが返却されるのでAuthのみ取得する。cookies;}先ほど取得したAuthトークンを使用しGAEアプリへとログインする。実際にはhttp://test.appspot.comの部分をアクセスしたいGAEアプリのUrlへと変更して欲しい。ログインに成功するとACSIDというクッキーが返却されているはずだ。余談ながらGAEアプリへのログイン後、POSTではなくGETでよい場合は、下記のようにリクエストすれば指定のUrlへとリダイレクトされる。http://test.appspot.com/_ah/login?auth={0}&continue=http://test.appspot.com/do/something/ただ今回はPOSTでリクエストしたいのでAllowAutoRedirect=falseで自動リダイレクトを無効化している。reader.Close();}取得したCookieをそれ以降のリクエストと一緒に送ってやれば認証されたユーザとしてサーバサイドで認識される。※見て分かると思うけれど、上記方法は中間でトラフィックを監視している人物がいた場合に、その人物がクッキーを使いまわすだけで簡単になりすましが可能となる。そのため繊細な情報などを扱う場合はhttpsを使用するのが望ましい。httpsを使用した場合は返却されるクッキー名がSACSIDとなる。仕組みが分かれば至極単純なのが理解できたと思う。上記のコードは動作テスト用に組んだものなので例外処理などまったくの手付かずなので使用される場合は随時手を加えてもらいたい。私がこの動作テストを行ったときに正常に動作させるまで二日ほどかかってしまった。protectionに引っかかっていたせいだった。GAEの認証側の問題だと考えてそちらばかり追っかけていたので、Djangoのほうまで頭が回らなかった。気付いてしまえば単純な問題だけれど、はまるときははまる。仮にDjango-nonrelを使用する場合は忘れずにハンドラーへ@csrf_exemptを付与するようにしてほしい。下記、はまっているときにstackoverflowへ質問した内容。Engine(GAE)でガリガリと開発し始めて2週間ぐらいたったので、今回は開発の感想とか現在の開発環境とか。発端~準備チヌかかり釣りMEGAのSNS要素としてコミュニティ機能が欲しかったので、どうせデータのスケーリングを視野にいれるならGAEでやってみんべ、と思い立って始めたのが3月末。以前からPythonには興味があったのでついでに勉強しようとPythonを言語として選択。3という大変すばらしい資料がネットに転がっていたのでそれでPython的なものを理解した。Pythonは3と2で言語仕様の互換性が途絶しているため実際にGAEで開発するときはそこらへんを考慮しなくてはいけなかった(まぁ今までのところほとんど意識することはなかったのだけれども)。Pythonをぼんやりと理解したので次いで背景も含めたGAEの理解に努めた。datastoreもすべて目を通した。Dataの出だし数ページには目を通しておいたほうが良いと感じた。GAEのページにEclipse用のプラグインがあるのでそれを使えば簡単に開発環境が構築できる。GAEそのままで開発を始めるとすぐに不便なことに突き当たる。GAEはDjangoのテンプレート機能を標準でサポートしてくれているが、それ以外の機能はない(それ以外にももしかしたらあるのかもしれないけれど知らない)。Idが用意されている)だったり、管理者機能、セッション機能なんかも当然ない。セッション機能とかはGAE用にgae-sessionsなどを開発してくれている人がいるけれどもどうせならここらへんの機能はフレームワークとして用意されているほうが好ましい。生のGAEで困ったのがフォームの検証機能なんかも全然サポートされていない。いうことでGAE上でDjangoを使用できるようにポートしてくれているDjango-nonrelを使用することにした。Django-nonrelを使うことでModelFormやUser機能などDjangoの恩恵をすべて享受しているのに、さらにGAEのデータストアをラップしてくれているModel機能のお陰でBigtableも意識せずに使えちゃうというヘブン状態に突入できた。当たり前なのだけれどもデータのjoinができないなどのGAEのデータ特性はそのままなのでそこらへんは注意しなければならない。環境とかDjango-nonrelはほとんど素のDjangoと変わらずに開発できる(素のDjangoを触ったことがないので実際には分からないけど)のでストレスなくサクサク開発できるようになった。そこで更なる開発効率を達成するために下記のプラグインやらフレームワークやらを導入した。3これを入れるとPyDevが手に入り、さらにEclipse用のDjangoプラグインが手に入る。Editorも手に入るのでマストゲットな一品。Development用のテストフレームワーク。C#用のMSpecとかよりも断然開発しやすい。MSpecが駄目というよりもDjango自体が自動テストで開発するのに向いてる環境だと実感した。Seleniumブラウザの挙動をそのままトレースできるツール。かなりのポテンシャルを感じるけれど、Lettuceとの相性がいまいちなのでいまいち把握していない。複雑なUIをぐりぐり作り始めたらちゃんと調査するつもり。3.6PyDevDjango-nonrelLettuce感想GAEで開発しているという感じはほぼなく、Djangoで開発していると感じる。それと環境をしっかりと整えればかなり開発しやすいと感じた。Transaction周りなど、Django-nonrelがどのようにラップしているか正確に把握していないので手探りしながらなのは否めないけれど、大枠問題がない。あとPythonでの開発は楽しい。コンパイラが無いのはうっとうしいけれど、その分しっかりとテストコードを書いておけばいいのだし、もっとしっかりやるならコードカバレッジも併用すればよいんでしょ(まだ使ったことないけど)。7Djangoアプリ用にBDDスタイルのテストフレームワークを探していたらLettuceがよさげだったのでインストールしてみた。その際に色々苦労したので今後のためのメモ。pipをインストールする。windows?ついでLettuce。このTutorialどおりにpipを使ってのインストールから最初のテスト実行までを行う。Lettuceを実行してみると表示がおかしい。本文以外に変な文字がたくさん出力される。Outputを参照のこと。Windows上記の方法を適用すると下記のように正しく表示される。ここまででやっとスタートラインに立てた。Djangoと統合したり、Django-nonrelと一緒に使ってみたり、splinterも評価してみようかなーとか思ってるので道半ば。Python2011年4月28日木曜日Action、RenderAction、Partial、RenderPartialの違いAction、RenderAction、Partial、RenderPartialの違いをよく忘れるので覚書。