Archive for the 'ソフト開発' Category

svn/TortoiseSVNがコミットエラー

Posted by ゆのじ on 10月 5th, 2008

ちょっと特殊な環境でしか起こりえないと思う問題なのだが、fixに思いの外手間がかかったのでメモ。

symfonyの開発中で、クライアントがWindowsXP(SP3)、サーバはクライアントのWindowsにインストールしたVMWareの中でFedora9を動かしている環境。Fedora9は現在最新版のsamba()をインストールしていて、WindowsからUNCパス(\\servername\hogeという指定)でプロジェクトごとe-texteditorで開いて作業している。subversionはサーバ側が1.4系列、クライアント側はTortoiseSVNの1.5系列、https/WebDAVを使っていて、サーバは手元とは別の場所にある。

このような環境下で、場合により「コミットには成功しましたが続けて他のエラーが生じました」「次のパスを処理する際にクリーンアップに失敗しました」というようなエラーがでる。だが、このエラーメッセージをgoogleで調べても、TortoiseSVNの言語ファイルのソースばかり出てきてエラーにはたどり着くことが出来ない。

そこで、その言語ファイルの訳語元「Commit succeeded, but other errors follow」や、「」を調べていて、やっとこさそれっぽい記事にたどり着いた。このMLのスレッドでは、解決策として「samba使うのを止めるか」または「最新のsambaに入れ直せ」、ということになっている。調べてみると、その記事の書かれたとき(2008/09/15)のsambaの最新版は3.2.3。その3日後に3.2.4が出ている。手元の環境は3.2.3-0.20.fc9。このドキュメントを信用する限り問題はないはず。

だが、その環境で問題が起こっているので、念には念をということで3.2.4をfedora-updates-testing-newkeyリポジトリから拾ってみた。インストールされたバージョンは3.2.4-0.21.fc9。だが、やはり問題は再現したのであった。

その後、Eclipse+PDT+Subclipse1.4.xの環境でも同じ問題が発生したこともあり、どうもTortoiseSVNが原因ではない模様。ついったでしばらく文句垂れていたのは冤罪だったようだ。ほんとごめん>TSVN

このまま調べるのをやめてしまうと、また問題が起きるたびにフォローアップ作業をしなければならない。それは悔しいのでもう少し調べてみると、こんな記事を見つけた。曰く、共有フォルダごとの設定に、create maskやらの設定を追加するとちゃんと動くようになるよ! とのこと。うちではこんな風に書き換えてみた。下線部分が追記分。

[homes]
        comment = Home Directories
        browseable = no
        writable = yes
        create mask = 0644
        force create mode = 0600
        security mask = 0555
        force security mode = 0600

試してみると、これがなんとエラーが発生しなくなるではないか・・。

原因が良く説明できないが、症状がなくなったことは大変めでたい。もし正確な原因がわかる方がいればコメントいただければ幸い。

BTSと運用

Posted by ゆのじ on 9月 10th, 2008

BTS(Bug Tracking System)のお話。うちの場合はクライアントにもBTSを使わせたりする都合上、一般的なシステム屋ともどこともちょっとずれているかもしれないが、存在しない銀の玉に近づくべく比較検討をしている。今回はそんな話。

BTS色々

BTSは色々あるが、昔「影舞」を使ってあまりの遅さに悶絶(その頃のPCは遅かった・・)し、Tracを使って管理の煩雑さに力尽き(対象顧客ごとにユーザ作ったり権限作ったり・・・)した。そして今はredMineに統合して一応一段落を見ているのだが、まだかなり不満がある。

redMineに手を加えてなおしたい

redMineのユーザ管理機能、プロジェクト管理機能は非常に良くできていて実はここにはほとんど文句がない。完璧だと言っても良さそうだ。だが、ワークフロー管理となるとこれが微妙。redMineのワークフローは、ワークフローといいつつ結局遷移先を制限するだけの機能しか無い。社内やわかっている人だけで使うのならばいいが、クライアントまで巻き込むうちのやり方だとこれはちょっと(ちょっとどころではなく)いただけない。客は「新規」のチケットを作り、「完了」のチケットを目視確認して「フィードバック」ないし「終了」へ落とすことだけやって欲しい。作る側は「新規」のチケットの担当者を自分にかえて、作業して、コミット時に"fixes #10"とか書いたら作業が終わるように(つまり勝手にチケットステータスが「完了」になってオーナーが起票者に変わるように)して欲しいのに、これが出来ない。ここはsvnとの連係機能に関わる部分で、ちょっとパッチを書けばどうにかなりそうな気もしている。追々いじる予定。

だが一番困っているのは、大量チケットの投下の煩雑さと、チケットの入れ子構造(大項目/中項目/小項目とか)の構造化ができない点。ちゃんとした理想的なアジャイルだのXPだの、機能単位モジュール単位できれいに運用出来ているプロジェクトであればいいのかもしれない。だが、うちは顧客から出てくる細かいバグの管理もしないといけないし、そういう煩雑なモノはredMineさんに全部処理して欲しい。ニーズは単純で、Excelで作るようなよくある「進捗確認表」的なものをシステム化してくれればわりとそれで事足りる。100個のチケットを投下したいときに、チケットを書くコスト以上のコストは極力かけさせないでほしい、ということ。もうこの辺は作っている思想が違いすぎるのかもしれない。

作る側と使う側の架け橋になるようなBTSが欲しい

ぶっちゃけてしまえば、正直プログラム開発手法はどうでもいい。もちろん興味を持ってずっと知識を取り込み続けている分野ではあるが、それと実務とは話が別だ。だからそういう手法に基づいたBTSというものはどうも体になじまない。それよりは、こっちが作っているものの状況が使う側にきちんと伝わって、使う側で出た問題がきちんとフィードバックされること、それをなおしたらきちんと確認してもらえること、そういうコミュニケーションツールとしてのBTSが欲しいと思う。

この業界、無いものは作れと言う。redMineをなんとか使えるように自分やクライアントを教育して、それでも駄目なら作るしかないのかもしれない。

symfony(というかpropel)でのmysql関数処理バグ

Posted by ゆのじ on 5月 22nd, 2008

結構根が深くていやになったのだが、表題の問題。symfonyの(というかPropelの問題なので以降Propelの)Criteriaの記述で、集約関数を書きたくて調べていたのだが、addSelectColumnという関数で下記のように定義してやればいいっぽい。

$c->addSelectColumn('SUM('.TablePeer::TARGET_COLUMN.')');

このとき、これだけなら問題はあるもののひとまずエラーにはならない(後述)。だが、たとえば時刻の差分(秒)の合計をとりたい場合、SUM(UNIX_TIMESTAMP(col1) – UNIX_TIMESTAMP(col2))のようにしたくなる。それを書いてみたのが下記。

$c->addSelectColumn('SUM(UNIX_TIMESTAMP('.TablePeer::FINISHED_AT.')-'.
  
                        'UNIX_TIMESTAMP('.TablePeer::STARTED_AT.'))');

これが見事に刺さる。

調べてみると、見事にPropelのBUGで、#425 (Bug in BasePeer::createSelectSql) – Propel – TracによればPropel本体としては既にfixedというステータス。これがsymfony側には反映されていなくて刺さるということのようだ。回避策は今のところこのTracに記述されているworkaroundをそのまま実行するしかない。念のため書き写しておくとこうなる。

577 $selectClause[] = $columnName; // the full column name: e.g. MAX(books.price)
578
579 $parenPos = strrpos($columnName, '(');
580 $dotPos = strpos($columnName, '.', ($parenPos !== false) ? $parenPos : 0);

下線部が追加部分。strRposにするのと、その下の行を追加する。これでひとまずエラーはなくなる。

エラーは無くなるのだが、addSelectColumnを使ったクエリ、明示的にクリアしていないにもかかわらず選択カラムがリセットされてしまって、addSelectColumnで追加したカラムのみになってしまうという問題がある。これが仕様なのかはともかく、doSelectしたときにhydrateできなくて刺さったり、いろいろと問題がある。この辺の本当の意味での正しいクエリの投げ方、どうすればいいんだろう?

追記:とりあえずメソッドを眺めていたら、TablePeer::addSelectColumns(Criteria $c)というメソッドを見つけた。とりあえず、addSelectColumnの先頭でaddSelectColumns($c)とかやってやると一通り追加される模様。