2009年2月アーカイブ




時間すなわち時(とき)そのものは、日常および哲学においては流れとしてとらえられることが多い。


時間 - Wikipedia

時間の流れを時流と呼ぶなら、電流と電圧のアナロジーで時間の圧力: 時圧というのがあってもいいんじゃないだろうか。


まあそれが何なのかとかは花粉症に苦しむ今はネタさえおもいつかないけど。。。




まあ金ちゃんヌードルなんですが……。


f:id:Tnzk:20090215132059j:image


今日、研究室にきてみたらおいてありました(あれ?後ろに写ってはいけないものが写っていますね……お祓いしてもらったほうがいいかも)。


誰の仕業なんだろう……と思ったらホワイトボードに書置きが。


f:id:Tnzk:20090215132351j:image


うーん、もう少し来るのが早ければ……。


どなたか存じ上げませんが、ありがとうございました。美味しくいただいますね!




例年は薬でカバーできたんだけど、今年はいまいち効果がない。まあ飲みはじためたのが最近なのでそのせいかもしれないけど……。


マスクデビューも考えないとなー。




たいていのテンプレートでデフォルトでサイドバーに入ってるWayFinderは、コンテンツの階層構造をリストで再現するのではてダの「最新タイトル」のようなこと(便宜的にこういう機能をRecentEntriesと呼ぶことにする)をしようとすると微妙に使い勝手が悪い。


調べるとDittoというのを使えば狙いどおりのことができるらしい。


テンプレートの変更


まず、テンプレートのRecentEntriesを表示したい場所に次のコードを追加する:



<div class="recententry_box">
<ul>
[!Ditto? &config=`recententry` !]
</ul>
</div>

Dittoのconfigファイルを作成


上記のコードから呼ばれる設定ファイルを作成する。


assets/snippets/ditto/configsの中に、config名.config.phpというファイルを作成する。



$ cd /var/www/html/modx/assets/snippets/ditto/configs
$ su
# vi recententry.config.php

内容は次のように:



<?php
$id='recententry';
$parents='0';
$depth='4';
$display='10';
$showInMenuOnly='1';
$hideFolders='1';
$sortBy='editedon';
$tpl='recententry';
?>

表示用のチャンクを作成


Dittoからの出力時にテンプレートとして使われるチャンクを作成する。


チャンク名はrecententryとして、内容は以下。



<li><a href="[~[+id+]~]">[+pagetitle+]</a></li>

結果


以下のとおり。狙いどおりに表示できて満足。


f:id:Tnzk:20090214162645p:image


参考




とりあえずテンプレートを追加しなければ使おうという気にならない(形から入るタイプ)。


テンプレートを探す


MODx日本語版ページのテンプレートは非常にバリエーションに乏しいので、本家から探す。ときどき落ちてるので、そのときはしばらく待つ。


MODx Content Management System | Resource Listing


アーカイブのダウンロード


気に入ったテンプレートがあったら、これを/modx/assets/templatesにダウンロード。今回は本家より"Andreas_03"をインストールして、展開。



# wget 'http://modxcms.com/assets/snippets/repository/repo_download/download.php?dwnParam=YXNzZXRzL3JlcG9zaXRvcnl8MTc1OHxyZXBvX2Rjb3VudHxyZXBvLTE3NTguemlwfEFuZHJlYXNfMDNfMi4wLnppcA=='
# unzip Andreas_03_2.0.zip
# rm Andreas_03_2.0.zip

管理画面での設定



  • リソース→リソース管理→テンプレートと移動

  • 「テンプレートを作成」のクリック

  • テンプレート名: Andreas03

  • テンプレートの説明: 「@wikiで見たことあるデザイン」

  • テンプレートコード: Andreas03/Andreas03.template.htmlの内容をコピペ

  • ツール→グローバル設定→サイト→デフォルトテンプレートと移動

  • Andreas03を選択

  • 「保存」をクリック


テンプレートの修正


上記設定だとスタイルシートが適用されなかったので、テンプレートを見てみる。



<meta name="keywords" content="_your,keywords,goes,here_" />
<meta name="author" content="_your name goes here_ / Original design: Andreas Viklund - http://andreasviklund.com/" />
<link rel="stylesheet" type="text/css" href="/assets/templates/andreas03/style/andreas03.css" />
<title>[(site_name)] | [*pagetitle*]</title>
</head>
<body>

MODxがDocumentRootにインストールされていることを想定している様子。/modxに入っているので、assetsの前のスラッシュを削除して保存。


完了


f:id:Tnzk:20090211202211p:image


参考




Now Where Was I? Gmail Labs Adds Location to Signatures


話題になってるっぽいので試してみた。IPからメールの送信場所を割り出し、署名に追記する機能。手順は次のとおり。



  • 署名が無効の場合は署名を有効化

  • 言語設定が日本語になっている場合はEnglish(US)に変更

  • LabsからLocation in SignetureをEnable

  • Generalから「Append your location to the signature.」にチェック。


で、メールの新規作成をしてみたものの、いつもどおりの署名しか追加されない。たぶん合衆国内しか対応してない。


まあできたとして何ら便利そうな気がしないんだけど……どんな用途があるんだろ。



Maybe you want to highlight your jetsetting lifestyle. Maybe you want to remind the recipient that you're in a different time zone


Now Where Was I? Gmail Labs Adds Location to Signatures

うーん、嫌味ったらしいというか、いやらしいというか……(・ω・`




今のところ/trac以降すべて同じ.htpasswdで認証しているので、プロジェクトごとにアクセスを制御することができない。


trac.confでは、



<locationMatch "/trac/[[:alnum:]]+/login">
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/trac/.htpasswd
Require valid-user
</locationMatch>

となっていて、:alnum:?がプロジェクト名になることが想定されてる。


タグつき正規表現が使えたら



<locationMatch "/trac/([[:alnum:]]+)/login">
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/trac/$1/.htpasswd
Require valid-user
</locationMatch>

って感じでいいと思ったんだけど、どうやら使えないっぽい。


どーしようかなー。


2009/2/11 14:40 追記


とりあえずプロジェクト名決め打ちで対処。そのうちどうにかしたいなー。



<locationMatch "/trac/portal/login">
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/trac/portal/.htpasswd
Require valid-user
</locationMatch>



昨日の時点でも気づいてたんだけど、MODx管理ページへのログインのため http://example.com/modx/managerにアクセス、ログインしようとすると、その直後にBasic認証させられた。Tracへログインしてくださいとのこと。


最初はmodxが../trac/*なファイルにアクセスしようとしてるのかと思ったんだけど、冷静に考えたら少しおかしいので調べてみる。


原因は昨日書いたtrac.confにあった。



<locationMatch "/[[:alnum:]]+/login">
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/.htpasswd
Require valid-user
</locationMatch>

:alnum:?は正規表現で英数字を意味するので、/英数字/loginなURLへのアクセスにはすべてこの認証を通ることが要求される。たぶん/modx/loginみたいなファイルがあったのかなー。


というわけで次のように書き換え。



<locationMatch "/trac/[[:alnum:]]+/login">
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/trac/.htpasswd
Require valid-user
</locationMatch>

で、.htpasswdの場所もあわせてあげる。



# cd /var/www
# mv .htpasswd trac/

解決。




以前学校のサーバの自分のホームに作ったリポジトリを他のメンバーと共有しようとして、かなり強引な手を使った覚えがあるので、今回は行儀よくいこうとapache経由で利用できるようにする。


yumを使ってみたりapacheを再起動したりするため、rootになれる環境でないと以下の手順は使えないです。


Apacheの設定


Apacheは既に入っているので、Subversion向けWebDAVモジュール(mod_dav_svn)だけインストールする。


それからリポジトリの作成、apacheを所有者に設定、と作業。



$ su
# yum install subversion mod_dav_svn
# mkdir /var/www/svn
# svnadmin create /var/www/svn/funnybunny
# htpasswd -c /var/www/.htpasswd tnzk
# chown -R apache.apache /var/www/svn

それから/etc/httpd/conf.d/subversion.confを編集。以下のようなセクションがコメントアウトされているので、コメントを外して、Location, SVNParentPath, AuthUserFileを書き換える。



<Location /svn>
DAV svn
SVNParentPath /var/www/svn

# Limit write permission to list of valid users.
<LimitExcept GET PROPFIND OPTIONS REPORT>
# Require SSL connection for password protection.
# SSLRequireSSL

AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /var/www/.htpasswd
Require valid-user
</LimitExcept>
</Location>

で、Apacheを再起動。



# /etc/rc.d/init.d/httpd restart

http://example.com/svn/funnybunnyにアクセスできれば成功。Powerd by SubversionとかRevisionとかなんとか表示されるはず。


Tracのインストール


こちらはソースからインストール。まずはtracのインストールと動作に使われるpythonがらみのモジュールをyumからインストール。



# yum -y install python python-setuptools mod_python

次にwget http://www.i-act.co.jp/project/products/downloads/Trac-0.11.1.ja1.zipしようと思ったら404 NOT FOUND。


インタアクト株式会社--ニーズに対応した柔軟なシステム開発を目指してにアクセスして確認してみると、今のURLはhttp://www.i-act.co.jp/project/products/downloads/Trac-0.11.2.1.ja1.zipになってるらしい。バージョンごとに削除されてるようなので、このエントリを参考にする人はご注意くださいな。


気をとりなおして、wgetして展開→インストールを行う。



# wget http://www.i-act.co.jp/project/products/downloads/Trac-0.11.2.1.ja1.zip
# unzip Trac-0.11.2.ja1.zip
# cd Trac-0.11.2.ja1
# python setup.py install

インストールスクリプトの動作中、やけにhttp://cheeseshop.python.org/pypi/Genshi/へのアクセスに時間がかかっているようだったのでイヤな予感がしたものの、無事インストール終了。


次に、apacheからアクセスするディレクトリと設定ファイルの作成。



# mkdir /var/www/trac
# chown -R apache.apache /var/www/trac
# vi /etc/httpd/conf.d/trac.conf

僕の場合trac.confは新規作成になった。以下のような感じで書く。



<Location /trac>
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /var/www/trac/
#PythonOption TracUriRoot /trac

SetEnv PYTHON_EGG_CACHE /var/www/.egg-cache
</Location>

<locationMatch "/[[:alnum:]]+/login">
AuthType Basic
AuthName "trac"
AuthUserFile /var/www/.htpasswd
Require valid-user
</locationMatch>

で、apacheをもう一度再起動したあと、http://example.com/tracにアクセスできれば成功。プロジェクト一覧とでかでかと表示された。


というわけであっさり完了。


参考




昨日に引き続きサーバの設定。sshのポートを標準(22)から変更したのを忘れてsvn+sshでcheckoutできなかった。


設定ファイルである~/.subversion/configを開き、[tunnels]セクションを探してその直後に利用したい「トンネル名=ssh -p 利用したいポート」と記述。以下のようになる。



[tunnels]
mytunnel=ssh -p 123456

実際に利用するときは、



$ svn co svn+mytunnel://username@example.com/path/to/your/repos

といった感じで。


参考: Subversionを使い任意のポート番号でsvn+sshする方法 - mahata_dev




id:rosylillyにおすすめのCMSを尋ねたら「MODxがいいよ」とのことだったので、試そうとしてみる。


アーカイブの入手と展開


まずはアーカイブのダウンロード。URLに特殊文字が含まれているのでエスケープしてwget。



# wget 'http://modxcms.com/assets/snippets/filedownload/download.php?path=YnVpbGRz&fileName=modx-0.9.6.3.tar.gz&utm_source=0963&utm_medium=web&utm_campaign=download'

で、その場で展開しようと思ったら、何かブラウザ経由でアクセスしてインストールするとのことなので、apacheから見える場所に移動。それから展開。



# mv modx-0.9.6.3.tar.gz /var/www/modx.tar.gz
# tar -xvzf modx.tar.gz
# mv modx-0.9.6.3/ modx

パーミッションの設定


前述のとおりブラウザからのアクセスでインストールするため、一部ファイルのパーミッションを変更する必要がある。



# cd manager/includes/
# mv config.inc.php.blank config.inc.php
# chmod 666 config.inc.php
# cd ../../assets/
# chmod 777 cache/ export/ images/
# cd cache/
# chmod 666 siteCache.idx.php sitePublishing.idx.php

ブラウザからインストール


http://example.net/modx/install/へアクセス!


と思ったら404 Not Found。なんでかなーと思って/etc/httpd/conf/httpd.confを見ると、DocumentRootが/var/www/htmlになってた。以前id:WaroeがUbuntu Serverをいじってたとき、デフォが/var/wwwだった覚えがあったのでwwwに置いてたのが問題だったっぽい。/var/www/htmlへ移動。



# cd /var/www
# mv modx html/modx

今渡こそ、http://example.net/modx/install/へアクセス。なかなかカッコいいインストール画面が表示される。


前置き


  • Choose Language: japanese

  • インストールの選択: 新規インストール


データベース設定


  • Tableプリフィクス: modx_

  • 接続時の文字セットの扱い: SET_CHARACTER_SET

  • 照合順序: utf8_general_ci

  • DBホストとの接続テストの結果: 接続できます

  • データベースとのマッチング: 問題ありません


インストールオプションの選択

初心者かつチキンなのですべて選択


インストール中...


完了するまで結構時間がかかるので、しばらくお茶でも飲みながら待つ。といっても3分くらいで完了。


後片付け


ブラウザからアクセスしていろいろできてあぶないので、パーミッションをもどしておく!


具体的には、



  • installディレクトリを削除

  • config.inc.phpを644に戻す



# pwd
/var/www/html/modx
#rm -rf install/
# chmod 644 manager/includes/config.inc.php

インストール完了!


http://example.net/modx/managerにアクセスして好きなようにする。Ajaxでロボットみたいにがしょがしょ動いてカッコいいぞ!


参考




OpenVZで動くサーバに触る機会があって、そのときに日本語が化けたのでしばらく悩む。



$ svnadmin
svnadmin: warning: cannot set LC_CTYPE locale
svnadmin: warning: environment variable LANG is ja_JP.UTF-8
svnadmin: warning: please check that your locale name is correct
Type 'svnadmin help' for usage.

とのこと。ロケールに問題があるっぽいので、ちゃんと設定されてるかどうか確認。



$ locale -a|grep ja
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory

あれ、日本語のロケールがまったくないぞ・・・(・ω・`


試しに全部表示。



$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
POSIX

ありゃ、ほんとに日本語ロケールなかったのね...。


いまいちUnixのロケールっていう仕組みがよくわからないので、適当にググって対処法を探す。


tkoshima.net



# localedef -f UTF-8 -i ja_JP ja_JP.utf8
# localedef -f UTF-8 -i ja_JP ja_JP
# localedef -f EUC-JP -i ja_JP ja_JP.eucjp

設定。たぶん-fからしてファイルからの読み込み元の指定なんだろうけど、日本語として使えるデータがあるのに設定されてないってこともあるのか。ちょっとロケールについては調べておかないとだめだなー。


で、確認。



$ svnadmin
使用方法を知りたいときは 'svnadmin help' と打ってください。

ちゃんと日本語。




株式会社OPTiMさんが、全国の高専を巡って講演を行なっているらしい。id:hush_inの学校にやってきたという話を聞いてしばらくした頃、*1ウチにもやってくることを知った。1月の末、レポートを提出した先生が参加窓口を担当されていたので、彼から聞いたのだった。


というわけで2月7日、株式会社OPTiMさんによる鳥羽商船高専での講演を聞きにいってきました。テーマは『仕事×プログラミング』で、業務での開発がどのようなものかということを、プログラミングについての解説を交えながら、現役高専生にエールを送るというものだった。


事前に発表されていたスケジュールには、プロジェクトマネジメントについての内容が含まれることが紹介されていた。ここ最近、とても興味を持っていることなので楽しみにしていた。


当日の大まかな流れは次のとおり。



  1. OPTiM会社紹介, 講演者紹介

  2. 大規模プロジェクトでの開発について

  3. プログラミング演習(WinAPI/GDI, Lua)

  4. デバッグの理論と実践

  5. バージョン管理システム


プロジェクトマネジメントについての演目がないように見えるが、実際にはすべての演目の根本にそれが据えられていたので、とても得るものは大きかった。


演習後の2演目が特に印象に残ったので、その辺りをまとめたいと思います。


ええと、各演目の内容を網羅的に書いちゃうと、まだ聞いてない高専の人的にはネタバレっぽくなっちゃうかもなので、個人的にメモしてたっぽい内容について書くつもり。


アウトライン



  • 「ゆとりのあるスケジュールは非現実的」

  • バグは熱い内に打つべきか?

  • 他のレイヤを疑うべきではない

  • サンプルコードをあたる

  • 喋ってりゃ直るよ

  • ノウハウは自分たちで育てていくもの

  • Tracでガントチャート

  • 利用メンバーの固定化

  • 新人はテスタ・デバッグで育てる


「"ゆとりのあるスケジュール"というのは非現実的」


炎上するプロジェクトの多くは、スケジュール的にかなりきわどい状態になっていることが多い。そのため、余裕のあるスケジューリングを行なうことが必要だと言われることが多い。


しかし、スケジュールに余裕を持たせることは現実的ではない。"ゆとりのあるスケジュール"は"無駄を含んだスケジュール"であることも意味する。そもそも開発の期限が決まっていないことは有り得ず、他社との競合や顧客の要望を考慮すれば、初期の段階から不要な余裕は削っておく必要がある。


といっても頭からかつかつのスケジュールは少しの遅延で破綻する。プロジェクトの規模と相談しながら、セーフティネットとなるクッション期間を設けておくべき。僕の現在のプロジェクトはちょっと前にこれに救われたところです(´・ω・`)


クッションとなる期間は設けておく傍らで、バグの発生を抑える、つまり成果物の品質の向上を見込んでスケジュールにゆとりを持たせるのはナンセンス、という話。


バグは熱い内に打つべきか?


プログラマとテスタが別の人間である前提で。


バグを見つけたテスタがすべきことは、下記5項目の記録:



  1. バグの事象

  2. バグの再現手順・環境の確立

  3. 再現確率の記録


これを如何に導くかがテスタとしての腕前。


「バグを熱い内に打つ」というのは比喩で、プロジェクトの規模が大きくなればバグ修正に絡む範囲を広くなるから、なるべく早めにバグを修正すべきだという考え方。


これ自体はとても正しいけど、だからといって「簡単そうなバグだしさっさと修正してもらおう」とすぐにプログラマを呼ぶのは良くない。



  • プログラマの集中力を途切れさせてしまう

  • そもそも表面的に簡単そうに見えるだけで、実は根深いバグであるおそれがある


上記のような理由に加え、ああでもないこうでもないとしている内にバグの実体がぼやけてしまい、再現方法がわからないまま結局解決されずに終わってしまうのが危険。


テスタでも(ソースコードレベルで)原因がわかる程度の簡単な問題でなければ、まずは再現手法の確立こそが必要。


他のレイヤを疑うべきではない


ソフトウェアを開発していると、「別のモジュールの問題ではないか?」と思うことがたびたびある。


別のモジュールというのは、OSのシステムコールやプロセッサなどの別のレイヤであったり、同じプロジェクトの別のメンバーが担当しているプログラムだったりする。


自分のプログラムが正しくても、依存している別のモジュールが問題を抱えていて、それが原因で最終的なアプリケーションである自分のプログラムが意図どおりに動作しない、という経験は開発者なら誰でもあると思う。誰でもあるからこそ「今回もそうじゃないか」と思ってしまう。でもほとんどの場合、こう直感したときは自分のほうに問題がある。


僕の場合は以前、マイコンの動作する回路の設計に問題があり、意図どおりの挙動を示さなかったことがあった。このときは回路の問題だとは思わなかったのでかなりの時間調査をして、最終的に回路設計者と話して問題が解決したことがある。


厄介なことに、似たような問題がもう一度発生した。そのときにすぐに回路設計を疑ってしまったが、今回は僕のプログラムに問題があって、逆にそれに気づくまでに時間を要してしまった。


それからなるべく他のレイヤを疑うのは避けている。


ただし疑ってかかるのは危険だとしても、関連するレイヤの担当者に相談するのは悪くない。悪くないどころか、奨励すべきことだと考えている。問題がこちら側にあったとしても、解決の糸口を得られる見込みは大きい。


あと、OPTiMさん内部の事例からの教訓として「OSがバグを持っていたとしてもすぐにfixされることはない」ということがあった。他のレイヤに問題があったら、その上のレイヤでカバーせざるを得ない。ハードの問題はソフトでカバーだ。


サンプルコードをあたる


不必要に長時間詰まらないためには、初心に戻ってサンプルコードや、他人のやり方を参考にするのが正しい。そのための知識ベースとして、以下のサービスが便利。



喋ってりゃ直るよ


問題が発生したとき、ひとりで考え込んで頑張るのも大切だけど、他の人に相談することで解決の糸口が見つかることが多い。


ひとりでPCに向かって根を詰めると、どうしてもソースコード上でできることを手当たり次第にやってしまいがち。場合よっては一度試したことを何度も試みたりしていることもあって、実はかなり効率が悪いのだと思う。


そうなる理由は、コードを書きながらだと問題の整理ができないから。そのせいで漠然とした理解のまま手数だけを増やすことになって、ほとんど解決に近づけない、という状態に陥ることが少なくない。


自分が今直面している問題を誰かに話す。それは少なくとも、論理的に説明できる程度には、現状を把握できていないとできないことだ。「自分は論理性に欠けるとよく言われるから」といたって、実際のところ最悪でも時系列の整理くらいにはなる。


相談の相手は自分よりレベルの高い人でもいいけど、そのとき周りにいなければ全然技術的な理解のない人でもいい。


相手のレベルが高ければそもそも同じ問題の経験があるかもしれないし、そうでなくても解決へのアタリを付けられることも多いだろう。たくさんの助言が得られるだろうから、確実に問題解決への距離を詰められる。


まったく技術に明るくない人が相手ならそれはそれでいい。その人でもどういう問題が起きているか理解できるレベルまで噛み砕いて説明する必要があるから、自分の中でもどういう問題が起きているのかハッキリさせられる。そもそも目的は「相談しにいく」ことであって、「解答を見にいく」ことではないのだ。


その場に自分しかいなかったら、相談の相手は自分でもいい。一度PCの前を離れて、ひとりで静かに自問自答するだけでも、問題は整理されることが多い。禅である(ぇ...


ノウハウは自分たちで育てていくもの


OPTiMでは、デバッグの際にテスト項目をチェックリスト化して確認漏れがないようにしているという。こういった形式化は、組織の成熟に従ってできあがってくることだ。


講演後、組織が若い内はどうしてたのか訊いてみると、こんな回答が。


「そもそもチェックリストは突然表れたわけではなくて、あるときはもう少し短かったり長かったり、内容も変化を続けて現在の状態になった。ノウハウはどこかから借りてくるべきではない。それぞれの組織が自分たちのやり方にあわせて、少しずつ丁度いいスタイルを育てていくことが大切」


というわけで、いきなりXPだの考えてもダメなわけで、その辺りが2年前の僕の大失敗の原因だと考えている。


当然ながら今も完全ではない。OPTiMさんのスタイルもおそらくそうだろう。これからも成長を続けていく余地があるから、それは楽しいのだ。諸行無常である(ぇ...


Tracでガントチャート


Tracでガントチャートを表示できるようにしているとのことだったので、使っているプラグインを聞いてみたところ、TracGanttCalendarを使ってるとのこと。


テクノロジックアート技術者のブログ: [Trac] TracGanttCalendarプラグイン for Trac-0.10(trac-ja)


これは便利そうなので、使ってみたいと思う。


利用メンバーの固定化


Wikiやグループウェア、Tracなどのシステムは、不思議なことに使っている内に利用しているメンバーが固定化してくることが多い。僕は今のところ関わったほとんどのプロジェクトでその状態に直面していて、唯一の例外はメンバーが3人だったときで、それは最初から固定化されても残るタイプの人間ばかりだっただと考えている。


この問題に対してのOPTiMさんの対処を聞いてみると、意外と同じような状態らしい。


そもそもTracの導入を提言したのが講演者のふたりで、



  • タスク管理をTracで行なうことを徹底

  • チケット発行時のテンプレートの作成


など固定化を避けようと努力しているのだが、それでもある程度の固定化は起きているとのこと。


第一線の開発者を集めた企業でもこうなのだから、学生が集まるとなると尚更難しいのかもしれない。これについては継続して考える必要がある。


新人はテスタ・デバッグで育てる


OPTiMさんでは、新人はたいていの場合テスタを担当することが多いらしい。これ自体はさらっと流れた発言だったんだけど、個人的には最初から最後までときどき思い出して色々考えることがあった。


2年前にSCTを立ち上げたとき、チュートリアルとはいえいきなり開発をはじめさせて、かなりの数の挫折者が出るのを見た。何を作るのかも詳細に把握できない状態で、1から製作をはじめるのは難しい。


最初は動作のテストやデバッグを担当してもらって、現在プログラムがどういう状態にあるかを少しずつ把握してもらうほうが良いのかもしれない。デバッグくらいなら1から書くよりも楽だろうし、バージョン管理をちゃんとしてればそのコードが壊れても何ら問題ない。開発者として参加するのはそれからでも遅くないのではないだろうか?


言い訳しておくと、2年前のそれの場合、その時点でそれなりにコード書けるのが2/10だったので、仕方なかったといえば仕方ないのですが……まあこの辺は言い訳にしかなりませんね(´・ω・`)


まとめ


念のため: OPTiMさんの講演のまとめではなく僕の考えたことのまとめです、、、



  • 大きな壁があったら誰かに相談してみる

  • プロジェクト管理の手法はまだまだ考える必要がある

  • ルーキーをテスタ兼デバッガで育てるのは試してみる価値あり


というわけで個人的にはかなり実りある講演でした!講演者のおふたり(学校がらみなので名前出して良いのか良くないか迷ったのでとりあえず伏せておきます)はありがとうございました!




*1:2009/2/8削除: 僕の勘違いだったようです




ここのところ付きっきりだったプロジェクトでの開発が一段落ついたので、ひさびさにブログ。


プロジェクトは5人のチームで進めていて、美術担当1人とデバイス担当2人、ソフト担当2人(僕とid:Waroe)という分担。といってもそれほどきっぱり分かれているわけではなく、できそうなところをできそうな人がやる、といった感じ。プロトタイプの開発だけではなく、資料作成や量産用の回路の簡素化などもやらないといけないので、みんなにぎゅうぎゅうに分担するのは危険だなと思ってユルく(よく言えば柔軟に、悪く言えば適当に)動くことにしている。


そういうわけでソフト担当だった僕もここしばらくはファームを書いている。2年ぶりにPICに触ることができたし、今回は回路から自分たちで作ったので、困難は絶えなかったがそれと同時にわくわくした。おそらく三大欲とは別であろうこういった快感は、僕やみんなのような人種にとっては代え難いものなのだろう。


困難といえば、同じ問題で最も長く行き詰った期間は4日間で、PIC18F2550のUSBターゲット機能が有効に働かないというものだった(詳しくは近いうちにまとめるが、VUSB-GND間のコンデンサを省いていたのが問題だった)。


4日間。長いだろうか?短いだろうか?


個人的には、ある程度の規模のシステムを開発していたら、何らかの問題で数日悩みっぱなしになるのは毎度のことなので、さほど長いとは思わなかった。むしろ「4日で済んでよかった」とすら思ったくらいだ。半月近く行き詰ったままだったこともあった。それから考えれば全然順調に進んでいるなー、と考えていて、実際これまで経験したどのプロジェクトよりも円滑にゴールに向かっている。局面ごとの判断ミスはまだまだあるものの、大局的にみればメンバーそれぞれの持つ背景を折り合いをうまく付けられていると思う。


4日間悩み抜いた課題を解決したあと、気分転換の散歩に出た。開発のため使わせてもらっている部屋のゴミ箱が一杯だったのに気づいた美術担当のメンバーがゴミ出しに行くというので、それに同行しながらの散歩にする。


世間話の種もなくなってきたので、今後の動きについて話す。「ここまでで試作に必要な技術は出揃ったから、近いうちにプロトタイプが完成する。それからコストダウンや量産の計画と並行して営業活動をはじめるので、作ってもらった資料が主役になるよ」というような内容。


そのときの彼の反応に、自分でも意外なくらい驚いた。


「おおー、もうダメかと思ったw」


ジョーク的な側面も含んでたのだろうけど、4日間も悩んでいるっていうのは、周りからは本人以上に困難にぶつかっているように見えるらしい。


実際には暗中模索ながら一歩一歩進んでいるので、本人としては手がかりが見えていてそこまで苦しんではいない。むしろその事実があるからこそ、やたらに周囲に「悩んでますよ」的なオーラを振りまいてしまうのかもしれない。特に僕はその傾向が強いように思う。そのせいで無闇に周りを不安にしてしまう。直したいクセだ。


同じ4日間といっても、問題に直面している本人とそれ以外、同様の経験があるかどうかで感じ方は全然異なってくる。当たり前のことだけど、こうやって実際に起きてみるとやはり戸惑う。


今年はプロジェクトマネジメントの見識・経験を得たいと考えている。マネージャにとって、メンバーの不安というのは最も恐ろしい敵だ。解消するのはまだ難しいので、今はせめて自分がその不安の種を作らないようにしたいものだなー。


このアーカイブについて

このページには、2009年2月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2009年1月です。

次のアーカイブは2009年3月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

ウェブページ

Powered by Movable Type 4.32-ja