演算子オーバーロードとドメインオブジェクト
という内容でQiita書きました。
http://qiita.com/items/bf42e8accc7550ba3943
クリーンコーダーを読んだ〜プロの開発者になりないな〜
後輩へのホワイトデーのお返しに（嫌がらせ的に）進呈したクリーンコーダー、、自分用にも購入して読みました。
- 作者: Robert C. Martin,角征典
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/01/27
- メディア: 大型本
- 購入: 12人 クリック: 645回
- この商品を含むブログ (36件) を見る
CentOS5.5にPython2.7＆Mercurialをインストールしようとしたら色々とハマったので
先日、SCMBootCamp*1に参加させて頂き、Mercurialの魅力を体験できたので、業務でも使えるように自宅のCentOS5.5サーバーにもインストールしてみました。Pythonも初心者だったので、その時に色々と手間がかかったので備忘録を残しておきます。
まずはPython2.7のインストール
CentOS5.5に標準でインストールされているPythonのバージョンを確認したところ、
Python 2.4.3
でしたので、こちらのブログを参考に、最新版のPythonを公式ダウンロードページから取得し、2系で最新の2.7をインストールしました。
cd /usr/local/src/ wget http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tgz tar xzvf Python-2.7.2.tgz cd Python-2.7.2 ./configure --with-threads --enable-shared --prefix=/usr/ make make install
デフォルトだとインストール先が/usr/local/以下なのですが、pythonコマンドでデフォルトで起動するPythonを2.7にしたかったので、--prefix=/usr/ と指定。（この指定が後の問題を引き起こすとはまだ知らない）
easy_installを使えるようにしておくと楽だと聞いたので、pypiにてsetuptoolsもインストール。
cd /usr/local/src wget http://pypi.python.org/packages/source/s/setuptools/setuptools-0.6c11.tar.gz#md5=7df2a529a074f613b509fb44feefe74e tar xzvf setputools-0.6c11.tar.gz cd setuptools-0.6c11 python setup.py build python setup.py install
Mercurialをインストールで問題発生
よし、easy_installを使えるようになったぞ！ということで、easy_install mercurial にてインストールを試みたのですがここで問題が発生。
なんと、pythonに正しくbz2モジュールが組み込まれていないというエラーが発生し、インストールができない。
error: Setup script exited with Couldn't import standard bz2 (incomplete Python install).
"yum install bzip2-devle"の実行でもエラー発生
以下のようなエラーが発生しました。
There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: No module named yum Please install a package which provides this module, or verify that the module is installed correctly. It's possible that the above module doesn't match the current version of Python, which is: 2.7.2 (default, Aug 13 2011, 20:56:43) [GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] If you cannot solve this problem yourself, please go to the yum faq at: http://wiki.linux.duke.edu/YumFaq
きっとPythonのアップグレードが関係しているのだろうなー、と思い、yumのソースを見てみたら、yumはPythonスクリプトだったというわけで・・・（常識ですかね・・・）。
$ vi /usr/bin/yum #!/usr/bin/python import sys try: import yum except ImportError: print >> sys.stderr, """\ There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: %s Please install a package which provides this module, or verify that the module is installed correctly. It's possible that the above module doesn't match the current version of Python, which is: %s If you cannot solve this problem yourself, please go to the yum faq at: http://wiki.linux.duke.edu/YumFaq """ % (sys.exc_value, sys.version) sys.exit(1) sys.path.insert(0, '/usr/share/yum-cli') try: import yummain yummain.user_main(sys.argv[1:], exit_code=True) except KeyboardInterrupt, e: print >> sys.stderr, "\n\nExiting on user cancel." sys.exit(1)
おお、そうか！もしや先頭の”#!/usr/bin/python”の部分をpython2.4に向けてやれば良いのでは？ということで、先頭を"#!/usr/bin/python2.4"に書き換えてみたところ、無事yumが動くようになりました(｀・ω・´)
教訓
参考ブログでも書いてありましたように、やはりpython2.7を再度インストールするハメになり、我が家のおんぼろサーバー機では再度コンパイルするのに結構な時間がかってしまいました。
今回の教訓としては。
チケット管理システムの頂上決戦！？ - Shibuya.trac第12回勉強会に参加してきました
はじめに前置き。。。頂上は決していません。はい。
本日（<-昨日か）、6月30日 Shibuya.trac 第12回勉強会 【通常枠】(東京都)に参加してきました。
概要
チケット管理システム大決戦第二回という名前のとおり、今年のDevsumiTokyoで行われたチケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのかの続編という位置づけ。前回は45分という短い時間だったのですが、今回は2時間半の大増枠で開催されました。さらに、前回までのTrac、Redmin、JIRAに加えヌーラボさんが提供するチケット・プロジェクト管理ASPサービスのBacklogを加えた4大チケット管理システムの使い手のパネラーさんたちによるディスカッションが繰り広げられました。
◆モデレーター
[twitter:@ryuzee]氏
◆パネリスト
JIRA [twitter:@ohnuki]氏
JIRA [twitter:@yusukey]氏
Redmine [twitter:@daipresents]氏
Redmine [twitter:@takanafu]氏
Trac [twitter:@kanu_]氏
Trac [twitter:@haradakiro]氏
Backlog [twitter:@ikikko]氏
Backlog [twitter:@ikeike443]氏
チケット管理システムを使っていたりするものの、開発プロセスの中にうまく組み込めていないと感じる今日この頃なので、今回、現場で活用されているパネラーさんたちのお話とても参考になりました。（もちろん現場に活かせなければ仕方ないんだけどね♪）
ということで、相変わらず理解が浅いのですが、熱が冷めないうちに、取り急ぎ備忘録的にまとめます。（注：理解に誤りがあるかもしれませんので、もしも見られた方は他の方のブログもご参照ください）
第一部 自分たちが使っているチケット管理システムの良い所/悪い所
というテーマで各パネラーさんたちが自分たちの使っているシステムの良い所/悪い所を議論しました。今回面白かったのは、各パネラーさんたちが決まった順番で単に良い所/悪い所をしゃべっていくだけではなく（基本的に順番はあるのですが）、あるパネラーの考えるシステムの良い所に対して、モデレーターの[twitter:@ryuzee]さんが（流石）他のパネラーに対して反論はないかアジテートするという展開が随所にあり、議論が白熱していました。（良く知りませんが、ヒップホッパーさんたちの世界でいう、ラップの掛け合い・ディスりあいみたいな感じ？ｗ）また、前置きが長くなりましたが、それぞれの発表から気になった点をまとめると、以下のような論点と意見があったと思います。
導入の手軽さ
- TracはTrac Lightning（Windows環境）を使えばさくっと環境を作れる。Linux環境でTrac Kanonがいいよ。
- Redmineの場合もWindows環境ではRedmineLEを使って簡単に作れる*1。
- JIRAの場合は・・・、導入には一定のコストがかかる。しっかりと導入しようとするとインストールに丸一日くらいかかっちゃうかも。（この部分の説明で聴き逃したのですが、それを簡単にしてくれるようなツールもある、とおっしゃっていたような・・・）
- Backlogの場合、ASPなのでインストール不要！アカウントを作るだけのお手軽導入！(ただし、[title:@ryuzee]氏から、「稟議を通す時間が〜」という鋭いツッコミが入りましたww）
操作感・UI・カスタマイズ
- tracは「漢らしいとさえ言われる操作感」（会場爆笑）と、素のままだとかなり機能が貧弱との[twitter:@kanu_]さんの残念アピール。ですが、同じtrac使いの[twitter:@haradakiro]さんは素のまま使っていることのメリットを説いていましたのでここらへんは人によりけりなのかも。
- Redmine。聞き逃しました・・・orz。*2
- さすがは有償製品のJIRAの操作感・UIは優れもの。ユーザーのダッシュボードのiGoogleライクなカスタマイズや、ビジュアルに設定可能なワークフローとかは秀逸。ただし、複雑なワークフローが定義できるのは良いけど、あんまり難しいワークフロー自体がどうなのか？というような[twitter: @haradakiro]さんの意見もごもっともだなー、と感じました。
- Backlogはｶﾜ(・∀・)ｲｲ!!バーンダウンチャートもどことなくポップだし、絵文字を使えたり、ユーザーの写真を設定できたり。非エンジニアの人たち（デザイナーさんやディレクターさん達）も含めたプロジェクトメンバーのコラボレーションツールという設計思想が良く現れているようです。
複数プロジェクトの管理
第二部 どのようにチケット管理システムを開発プロセスに組み込んでいるか？
ここからがきっと私を含めオーディエンスが本当に聞きたかった部分かと思います。実際、ある程度チケット管理システムを使ったことはあっても有効に開発プロセスの改善に使えていない、と感じているのは私だけではない、、、はず。このテーマについても、分かったつもりの部分を。。
アナログとデジタルの併用
おそらくほとんどのパネラーさんが一致していたのが、チケット管理システムだけでなく付箋＆ホワイトボードのタスクボードや手書きのバーンダウンチャート等の「アナログなツール」を併用している点だったと思います。
デジタルだけで完結させずにアナログなツールを使うことのメリットとしては、紙で残っていると記憶に残る、とか、メンバー間で情報の共有がしやすい、等のメリットがあるようです。
一方で、どのパネラーさんも苦労しているのは、付箋とチケット管理システムの二重管理がどうしても発生してしまい、情報の同期に結構なコストがかかっているようです。この点はみなさん決定的な答えがないようで、きっと現場によってケースバイケースの工夫をしなければならない点なのだと思われます。
そんな中で、ボーダフォン社がJIRAで入力したチケットを即座にプリントアウトして、それをタスクボードに貼り付ける、という事例も紹介されました。
チケットの階層化について
WBS(Work Breakdown Structure)のようにタスクを階層構造に分解していくような作業にチケット管理システムを適用させる点についても議論が大きかったと思います。
たしかに、redmineやJIRA、そして意外とtracも階層構造を作れるようなのですが、意見はチケットの階層関係を作るのは意味が無い、という多数派の意見だったと思います（というかそれに対しての反論が出なかったという意味で）。1000人を超えるユーザーが使うまでにRedmineを使う文化を根付かせた[twitter:@daispresents]さんもチケットの階層関係を作っても結局管理しきれなくなるし、階層関係を意識したガントチャートを作っても結局あまり見られない、というご意見でした。
チケット管理システムで扱うタスクの粒度
[twitter:@daispresents]さんからは、チケット管理システムはあくまでメンバー間のコラボレーション促進ツールとして使う点にもっとも価値があり、個人のTODO的なタスクまで管理するのにはマッチしない、という意見がありました。一方で、同じくRedmine代表の[twitter:@takanafu]は逆に個人のTODOも含めて良いのではないか、とのご意見がありました。
この点に関しては自分もRedmineを使いながらいつもどのくらいの粒度が良いのかな〜、と模索している点で、個人的には細かすぎるタスクは管理が面倒になるので、なるべく共有に値するものを入れるようにしたほうが良いのかな〜、と思っていた点です。
チケット管理システム上での非エンジニアの方とのコミュニケーション
これは第一部の終りに、一部のテーマを無視して私が[twitter:@daispresents]さんに質問してしまったことなのですが（汗、非エンジニアの方とRedmine上の情報をどこまで共有しているのか伺いました。
この質問の意図としては、開発的な内容（例えばアーキテクチャとか設計に関すること）を管理しているプロジェクトを見ても、非エンジニア（デザイナーとかWEBディレクターさん）は意味がわからないだろうし、いったいどうしているのだろう、と気になっていました。
[twitter:@daispresents]さんの回答としては、ビューやプロジェクトを分けて管理しているとのことだったのですが、その後、ツイッター上でご本人が「これをわけないようにしたいなーと最近思います」とおっしゃっていたように、ここについても最適なやり方をみなさんまだまだ模索しているようです。
所感
各ツールの良い所悪い所については結構、お互いの「潰し合い」的な場面があって「大決戦」ぽかったのですが、開発プロセスの話になると、やはりパネラーさん達の意見はわりと近寄っていました。結局ツールは違えど、やりたい事、目指していることには大きな違いはないということなんじゃないかと思います。そして、色々な事例の中でみなさん明確で確立したやり方を必ずしももっているわけではなく、創意工夫しながらプロジェクトを作り上げているのだな、と感じました。そして、結局のところ、この手のことも聞くだけではどうしようもなく、学んだことを現場に活かさないとな〜。。
＊プログラムの詳細は後日スライドシェアでアップされるようなのでそちらをご期待ください。
*1:今回の話にはでませんでしたがLinux環境ではRedmine Cloud Hosting, Redmine Installer, Docker Container and VMなんかがall in oneかつインストールが簡単なRedmineパッケージだと思います。
*2:個人的には4つのチケット管理システムの中で一番使っているツールなのですが、素のまま使っても特に不便さを感じ無いUIとデフォルトのレポート機能だと感じています
*3:これも補足ですが、Redmineでは複数プロジェクトをまたいだロードマップを作れたり、プロジェクトの階層関係を作ったりすることが出来ます。ただし、実際にそのような使い方をすると管理が逆に複雑になる、という話もありますが
*4:自分が知っている範囲だと、検索条件をweb画面上でカスタマイズ＆保存できました
CakePHP2.0勉強会に行ってきました。
2日続けて勉強会参加となりました。今日はCakePHP2.0 勉強会@Tokyo : ATND。
CakePHP1.3も軽く触わったことがある程度だったのですが、今月初めに勉強会に参加したSymfony2や普段仕事で使っているZendFrameworkとの比較の意味も含めて参加してみました。細かくレポートする程には理解出来ていないので（途中のワークショップはほとんどついていけず・・・orz）、気になった点だけ備忘録的に軽く残してこうかと思います。
テスティングフレームワークにPHPUnitを採用
1.x系はSimpleTestが標準のテストフレームワークだったのが、2.0からはPHPUnitをベースにするようになるらしい。ZendFrameworkはずっとPHPUnitをベースにしていたから、SymfonyもCakePHPもPHPUnitに乗っかってきてくれるのはとても都合が良い♪
特にコントローラー系のテストがだいぶ充実したみたいで、セッション管理が必要な画面遷移を含むテストが出来そう、むしろその視点からCakePHPを勉強してみようかな、と思ったりしました。
クラスの動的なローディングに対応
内部的にspl_autoload_registerを使ったオートロードが可能になった模様。
ネーミングルール等に関してはCakePHP2.0のネーミングルールの記事翻訳 - cakephperの日記(CakePHP, Laravel, PHP)が参考になりそうです。
また、Modelクラスのインスタンス化にコストが係るという問題点については、LazyLoadingという考え方を採用し、実際に必要になった時以外はオブジェクトを生成しないようにすることでCakePHP1.3系よりもリソースの消費が少なくなっている模様。
スクラム道バーストに参加してきました。
先週のScrum Boot Campに参加したことをきっかけにスクラム道に（初）参加してきました。
司会進行の[twitter:@nawoto]さん曰く、「ブログを書くまでがスクラム道」とのことでしたので、今更ながらブログ始めてみました。
概要
今回のスクラム道は「スクラム道バースト」ということで、これまで行われてきたスクラム道の総まとめ（？）的な位置づけだったようで、参加人数も過去最大だったようです。（司会進行の[twitter:@nawoto]さん曰く、これまでスクラム道は秘密結社のようなものだったとかｗ）
内容としては、過去に行われた6回のスクラム道のテーマの中から、会場のオーディエンスが聞きたいモノを選んで、名乗りを上げた「選手」達がそのテーマについてディスカッションを行う、というものでした。
[テーマ]
スクラム道.01 「ふりかえり」KPT is harmful
スクラム道.02 「スプリントバーンダウン」スプリントバーンダウン虎の巻
スクラム道.03 「スプリント計画ミーティング」
スクラム道.06 「スクラムマスター」[当日のタイムテーブル]
18:30 - 18:45 テーマ決め、選手入場
18:45 - 19:15 読み手の発表
19:15 - 19:50 ディスカッション ラウンド1
19:55 - 20:30 ディスカッション ラウンド2
20:30 - 20:45 クロージング
スプリント計画ミーティング
で、今回テーマとして選ばれたのは（僕は遅刻したので投票できなかったのですが）、「スプリント計画ミーティング」*1。
スクラムを実際に経験したことのない僕にとっては何が正しいのか、という基準がないのですが、気になったことやら、書簡を列挙してみます。
タスク分割について
タスクの分割について、最小のタスクの時間と最大のタスクの時間をチームとしてどれくらいに設定しているか、という話。
会場の8割位方の方々が30分〜2時間位という意見でした。逆に、一番大きいタスクは？ということになると、大多数の方が1日（きっと8時間？）だったような。多い方で2日という方が多かったです。その他の意見としては・・・
- 細かく分割しすぎるとタスク管理が難しくなる。
- 細かいけれども、タスクとして漏れてはいけないものについては、時間を割り振らないでタスクとして挙げだす。
- タスクの最小時間はスプリントの長さによる。2週間のスプリントと、1ヶ月のスプリントではタスクの最小/最大時間は違ってくるのでは。
タスクのdoneを変えるのはどうなの？
タスクが中々完了しなかった場合に、タスクが完了しない時にdoneの定義を変えてしまうことってどうなのという議論。
結構、色々な議論が白熱していたのですが、あまりうまく議論の様子をまとめられないのであしからず。
一言で言えば、doneを変えてしまっている人と、いやいや、doneは変えちゃダメだよ、という立場がありました。
個人的には（スクラムを実践していないのですが）、「doneの定義を変えてしまうと、何が予定通りに完了できて、何が完了できなかったかが分からなくなってしまう」という意見に賛成でした。（多分[twitter:@enum]さんの）
プロダクトオーナーの不在について
明確にプロダクトオーナーが明確に存在しないということが結構あるみたいですね。
そういう場合、チームがプロダクトオーナーを兼任する、ということもスクラム的にはありだそうです。
記事プロダクトオーナはスクラムマスタを兼任できるかなんかでは否定的な意見もあるのですが、実際にはそうも行かないケースが日本では（？）まだまだ多いのかもしれませんね。
所感
スプリント計画ミーティングのディスカッションを聞いて、勉強にはなったなー、と思ったものの、やっぱり具体的に腑に落ちていない部分もあるな〜、と感じました。それは、つまり、自分が根本的に分かっていない点があって、そこが引っかかっているのかな〜、と。この手の議論はただ聞いているだけだと理解も十分にならないと思うので、今後も勉強しつつ、取り入れられる部分は仕事に活かしつつ、より理解を深めたい、と思う今日この頃。
*1:スプリント計画ミーティングとはなんぞ？という方は[twitter:@miholovesq]さんのスプリント計画ミーティングをどうぞ。
