スケジュールとタスクと見積もりと

あせって招待してもらったわりに、一度もPOSTしてなかった。
ずっと前から考えていて、最近また感じたのでここに記す。

開発を仕事としていると、必ず似たようなことがあると思いますが
「〇〇が欲しいんだけど、期間とタスクを出してくれ」
というようなことをよく聞かれます。

これが私には非常に難しい。

見積もりの話なんかは結構書籍があったりするので
Manage It! 現場開発者のための達人式プロジェクトマネジメント
Manage It! 現場開発者のための達人式プロジェクトマネジメント

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ソフトウェア見積り―人月の暗黙知を解き明かす
ソフトウェア見積り―人月の暗黙知を解き明かす
あたりを読んだんですが、私にはどれも「何々がほしい、いつまでにできる?」
という会社からの問に、すぐ答えられるような方法はないという風に感じました。

過去の開発から、定量的なデータをもちいて、次のプロジェクトの予測を
立てるということもある程度はできるとは思います。そういった点から修正などは、
まだ期間の予測が立ちやすく正確性があるものが出し易い(大幅な修正とかは別だが)
とは思います。ただ、程度の差こそあれ毎回違う物を作っていて、違う技術を
使っているような場合にはほとんど役に立たないと思うわけです。

なにかしら作るものがあり、仕様みたいなものがあったりなかったり
会社によって様々だと思いますが、最初の段階でわかっていることは実は
とても少なく、プロジェクトが進行するとともに、仕様にしろ、実装にしろ
理解が進んでいくのが普通だと思うわけです。

そういった点では、唯一プロトタイプは予測するのに有効に働く気がしています。
ただ、それはコードを書いて動かしてみないとわからないということで、できたときが
リリースするときだとほぼ同じなんではないかと。

他に問題として、会社や上司がこういった事に理解がない場合があり、なんで
スケジュール守れないのかとか、なんでこんな長い期間かかるんだとか
言われる場合があるわけです。そもそも正確性なんかほとんどないものを見て。

会社は売上や利益を上げるために、適切なタイミングで商品を出す必要がある
ということは重々わかっています。そんなもんなんとなくで、あとはがんばって
間に合わせろよこのヘタレという意見もあるかと思います。
ただ怖いのです。聞かれてなんの根拠もない数字をひねり出すことが。

最初はなにも決めずに作り始めて、進むたびにスケジュールが更新され
リリースできる日の確度が高くなっていくような形にはできないものだろうか。

Web+DB Press 総集編を読んだ


買ってあったんですが、読んでなかったので読みました。どのエッセイもすばらしかったんですが、特に森田創さんはブログのほうも読んでいて、なぜか洋書を翻訳したような雰囲気がただよう感じとか、内容の濃さとか読んでいておもしろいなと思いました。

そんななか、いろんなかたのエッセイが載っているんですが、増井俊之さんが書かれたスジの良い生活というエッセイで「以前はPerlを使う人がたくさんいたものですが、RubyPythonが存在する現在、あえてPerlを使い続けるメリットはありません。」と書かれていました。確かに、RubyPythonでもPerlと同じことはできるし、書きやすさとか可読性とかで優れているのかもしれませんが、本当にPerlを使い続けるメリットはないんでしょうか。

私はYAPCとかでJesseの話やRJBSの話を聞いていると、そんなことはないんではないかなと思っています。リリースサイクルが改善されて、後方互換を保ちつつも、新しい機能を追加していくことが可能になったPerlの開発は今も進んでいるし、CPANモジュールもまだまだ増え続けています。(5.8とかのころのままだったらやばかったのかもしれない)

Perlに限らずこういった言語の今の状態は、実はそれをメインに使っていて、さらにそういった情報を追っている人にしかわからないところがあるのかなと最近思っています。メインでない言語の情報も追っている人はたくさんいると思いますが、やはり追いきれない部分がどうしてもでてきてしまうと自分でも思っています。

なので少なくとも、まだ選択肢として残っててもいいんじゃないかなと思っています。

逆に言うと私が知らなくて、Perl以外の言語で実はPythonとかRubyとかPHPとかすごい進化してて、Perlはオワコンという事になっているのかもしれませんけどねw

YAPC::Asia 2011にスピーカーとして参加してきた


※画像は偽物だというウワサがありますがたぶんhidekさん

参加は4回目で、スピーカーとして参加したのは、2009のLTしたとき以来です。会場の東工大も工事が終わっていて、綺麗になっていました。前夜祭は仕事で参加できず。この時期にリリースをするのは今後避けたいですね!一日目はひたすらセッションを聞いて回ってました。どれを聞きに行くか毎年悩むんですが2日間合わせて特に印象に残ったのはこの辺でした。


Perl5.16 and beyond
Perl5.14 For Pragmatists
hakobeさんのLT
Hacking with metacpan
Managing A Band Of Hackers
聞けなかったのはあとで録画で見たいと思います。


懇親会でも、16歳の高専生、高校生とちょっとお話できて、なんでPerl使い始めたんですかとか聞けてよかったです。なんかしっかりしてておっさんやばいと思いました。今年は芝生コンにも参加できて(誘ってくれた@kyannyさんありがとうございます)楽しかったです。

2日目の2本目、ローヤルブルーホールの最初だったんですが、朝から雨風すごくて心配してたんですが、会場の移動時間ももらえて無事発表できました。なんか時間が結構余ってしまって、あとからあれ言うの忘れたなとか思ったんですが話したい内容は話せたのでとりあえずよかったかなと思います。

ちなみに発表資料はこちらから見れます。
http://dl.dropbox.com/u/5738997/YAPCASIA2011/index.html#intro


発表した直後になんか録画うまくいってないとスタッフ(同僚)から伝えられ、まあ残念だけど生で見てくれた人もいるし、まあいいかと思ってたんですがどうやら勘違いしていたようで、前半ほんのちょっとだけ録画できてないとのことでお騒がせしました。その直後にgihyoレポートの@ytnobodyさんにレポート書きます!って力強く言われたときにうれしくて泣きそうになったのは内緒なんだぜ。

あとは毎年のことですが、コードもっと書かないとなと思いました。一時的なものにしないで継続したいですね。

今年もスタッフとして手伝ってくれた@wittroありがとう。来年はスピーカー目指したらいいよ。会場提供の東工大、スタッフ、スピーカー、ゲスト、スポンサー、JPAの方達、941さん、lestrratさん今年も楽しかったです。ありがとうございました。

Being Geek

https://lh3.googleusercontent.com/-KAN-jKvNwsk/TirE9jcaigI/AAAAAAAAAGc/epzmUo8-Z-0/s640/IMAG0100.jpg

I got a little different impression that I had expected from the book title. This book is mainly management and communication in a tech company, it doesn't almost include you are being geek for the future. I recommend to read you are a manager before you had been a engineer and if you will become manager in a tech company.

So, recently, I'm simultaneously reading a English version book and a translated version book for learning English. Even though I have had Being Geek English version, I bought the Japanese version when it was come out. I try to simultaneously read it. I'm impressd this translation is easy to read for Japanese. It seems tough that translation easy-to-read for Japanese as writing a book.

Amon2の自分用Flavorを作る

tokuhiromさん作の軽量WAF Amon2なんですがFlavorという仕組みがあって、特に指定せずamon2-setup.plするとBasicが選択され、BlueprintとjQueryを使ったテンプレートが作成されます。他にデフォルトでついてくるのはMinimumがありますがこれは文字通りなにも使ってないテンプレートが作成されます。

ただ、最近自分が使っているのがinuit.cssやBackbone.jsだったりSpine.jsだったり、underscore.jsだなんだかんだとあってプロジェクトを作成してから追加するのがめんどうくさくなってAmon2書き換えるかとなったときに、Flavorというのがあることに気づいたので作ってみました。すごい簡単です。

Amon2のソースをみればすぐわかるんですがamon2-setup.plをする際にオプションとしてfalvorが渡せるので、そこで自分の好みのテンプレートが作成されるようにできればいいわけです。

amon2-setup.pl --flavor=Ka2u MyProject

で用意しなきゃいけないのは自分のFlavorモジュールと使うCSSやJSのフレームワーク用のAssetモジュールだけです。今回はinuit.cssとSpine.jsを使うテンプレートを作成しました。

Amon2::Setup::Flavor::Ka2u

これが作成されるプロジェクトの元になっていて、ここに作成されるファイル群がすべて記述されています。Amon2::Setup::Flavor::Basicを元にして自分が変更したい部分だけ変更していくといいと思います。

Amon2::Setup::Asset::Spine

Amon2::Setup::Asset::Inuit

Amon2::Setup::Asset::jQueryやA::S::A::BlueprintをみるとAssetの中身はほとんど、使うJSやCSSの中身が文字列としてそのまま帰るような形で作られています。当初同様の形で作成していたんですが、inuit.cssの更新が結構頻繁にあり、モジュールにしたてるのがめんどくさくなってしまい、cssとかJSのファイルをそのまま含んでしまいslurpして吐き出すようにしてしまいました。なんかファイルコピーしてもいいかも。

あとはAmon2::Setup::Flavor::Ka2uのなかでAssetを使ってファイルを作成するように書き換えて、最初に作成されるテンプレートでincludeされるようにすれば作成した段階で自分の好みのプロジェクトがセットアップできます。さらに、毎回書いているような定型的な部分も含んでしまえばもっと楽になりそうです。実際のコードはgithubに置いてあるので詳細はそっちを見てください。

ググッてみるとAmon2::Setup::Flavor::Tengとか作っている人もいるので、みなさんも自分用のFlavor作ってみてはいかがでしょうか。


作ったFlavor
https://github.com/ka2u/Amon2-Setup-Flavor-Ka2u
Amon2::Setup::Flavor::Teng
http://d.hatena.ne.jp/akiym/20110428/p1

dotcloudにinviteされてから

どうも、コンフィうまそうですね。お元気ですか?

おとなしく、いい子でまっていたらdotcloudさんからbetaのinviteが送られてきたので試してみました。ただ、お試しエントリはすでにかなり上がっているので、普段python使っていない人がdotcloud使うのにpythonのモダンな環境をつくるところから始めるということで書きたいと思います。

注:筆者は普段python使っていません。一応動くとこまでできましたが全然モダンじゃねーよという可能性があります。もっといい方法がある場合はぜひ教えてください。

最初に書いておくと、今回pythonbrewは使いませんでした。個人的にまだメジャーではなさそうということが一番の理由です。なので使いたい人は使ってもいいんではないでしょうか。

ちなみに以降の内容はMac Book Airで行いました。Linuxとかでも同じ手順でいけると思います。

まずsetuptoolsをインストールします。私の環境ではすでに最新版がインストールされていたので必要ありませんでしたがもしインストールされていない、または古い場合はダウンロードしてください。

tar zxvf setuptools-x.x.x.tar.gz
mv setuptools-x.x.x
python ez_setup.py

次にpipを入れます。

easy_install pip

そしたらvirtualenvとvirtualenvwrapper。これはシステムと切り離されたpythonが使える環境を手軽に用意できます。

pip install virtualenv
pip install virtualenvwrapper

シェルで使えるように(.zshrcなどに)追記。追記したらsourceコマンドなどで有効にしましょう。

source /path/to/virtualenvwrapper.sh #たぶん/usr/local/bin/virtualenvwrapper.sh
export WORKON_HOME=${HOME}/path/to/venvs
export PIP_DOWNLOAD_CACHE=${HOME}/.pip_cache #download cache for pip
export PIP_RESPECT_VIRTUALENV=true #packages install for virtualenv
export PIP_REQUIRE_VIRTUALENV=true #require virtualenv

さてこれで環境が作れるようになったので作ってみます。

mkvirtualenv newproject

これ以降は参考にしたtokuhiromさんの記事の手順と同じです。今回はAmon2を使いますが、フレームワークはいろんなのが使えるんで好きなの使ったらいいと思います。dotcloud pushはvirtualenvの環境にworkonしてね。

amon2-setup.pl Demo
cd Demo
perl Makefile.PL
ln -s htdocs/static static
git init
git add .
git add -f 'inc/'
git commit
dotcloud push ka2u.demo .

以上です。


http://demo.ka2u.dotcloud.com/
ここで腕を空に掲げて叫びましょう Victorrrrrrrrry!!!!
※dotcloudのドキュメント参照


参考にしたサイト
http://docs.dotcloud.com/tutorials/firststeps/
http://blog.mitsukuni.org/2010/10/25/python-development-environment
http://mt.endeworks.jp/d-6/2011/04/dotcloud-psgi-hello-world.html
http://d.hatena.ne.jp/tokuhirom/20110501/1304234959

あと気になっているのがサービス(ka2u.demo)の削除なんですがどうやればいいんですかね?
追記:サービスの削除コメント欄で教えていただきました。ありがとうございます!

また本読んだ

ebookで半額で買った。訳がちょっと読みにくい。
技術系の会社の管理者層とかも読んだほうがいいんでは。

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)