Mensagem enviada por Yuichi Saotome

五月女です.

>/usr/local/etc/apache22/envvars.d に path.env というファイル名で
>PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
>と記載し,portsからインストールされるバイナリのパスをapacheの環境変数へ
>追加しました.
>このことでしょうか?

はい.結局それだけで動作しました.
最初,ファイルが生成されたものの,Moodle上で表示されなかったのは別の問題でした.恥ずかしい
五月女です.

報告が遅くなりましたが,その後無事動作しました.
奥村先生のご指摘の通り,apacheからtexのパスが分からない状態だった様です.
他のサーバで試した所,上記のapacheにパスを教えてあげる操作だけで動作いたしました.

大変助かりました.
感謝です.
五月女です.

たしかに今でもfindとgrepを組み合わせて探す事も多いですね.
xrefの一番の使いどころは他人にMoodleのコードを説明する時だったりします笑顔私の周りはMoodle本体の開発をする人は少ないのですが(というか私だけ?),Moodleの周りで開発してる人は多いので,Moodle内部の仕組みについての質問とかに,「こんな関数使えますよ?」「ここにライブラリあります」といった感じでリンク付きで返信したりしています.

PHPXrefやPHPDocumentor形式のコメントについては,私も基本的には見よう見まねで書いてます.まとまって説明されているのはPHPDocumentorのページのマニュアルくらいしか知りません.
http://manual.phpdoc.org/HTMLframesConverter/default/
申し訳ありません...
たしかに日本語の情報少ないですよね.

私も,tracはリポジトリとコメント履歴ブラウザになっています.昔からpukiwiki好きなので,結局ドキュメントはpukwikiで書いてしまうんですよね.
ただ,リポジトリとコメントの履歴ブラウズだけでもtracを使う価値があると思っています.過去の変更履歴を思い出す時に大活躍します.



全然関係ありませんが,教員からの要望と半ば趣味で,Moodle用にPukiwiki記法フィルター(PEAR::Text_PukiWikiを組み込んだ物)とgeshi(シンタックスハイライター)フィルターを作ったんですが,一般的にこんなのって需要ありますかね...?複雑な
五月女です.

既にご存じかもしれませんが,参考までに.

>HTTP のやりとりを再現してくれるような function test tool とかあればいいのですが…。
jMeterというhttpのやりとりを記録して再現してくれる便利なテストツールがあります.
クッキーや認証処理も再現出来るので,負荷テストや主要なテストの自動実行に便利に使っています.
http://www.jajakarta.org/jmeter/

>PHP なので、関数を追いかけていけばいいですし。
これはxrefというツールを使うとかなり楽になります.
Moodle本家でも使っています.
http://xref.moodle.org/
うちは改造箇所もあるので,マージした際に自動的にxrefも再構成する様にしています.

また,逆引きにはphpDocumenterが便利です.
http://phpdocs.moodle.org/
ただ,MoodleのソースはphpDocumenter形式に沿っていない箇所も多いので,あてにならない時もあります.

Média das avaliações: 有益(Useful) (1)
五月女です.

参考になるか分かりませんが,うちはこんな感じです.
  1. 前期までは,1.8系をベースに改造したもの,後期からは1.9系をベースに改造した物です.改造については,奥村先生や白井先生など先人の知恵を参考に,主に学内の要望に対応するための改造を行っています.うちは学部毎や組織毎に別々のMoodleを30個ほど運用しており,重複がありますが,計1万人程度が登録されています.(2008年度前期は483コースが利用され,延べ利用者数は2万人くらいでした)
  2. 頻度はまちまちですが,本家のCHANGESを見ながら,必要そうな修正があったときにアップデートしています.
  3. うちのMoodleは,本家CVS版をベースに改造を行っており,毎晩本家CVS版を自前のSVNリポジトリへ同期させて,テストサーバ上でうちのMoodleとのマージ処理を行います.そして,アップデートを行いたいと思った時にテストサーバ上でコンフリクトを解消して,簡単なテスト後,コミットします.本番環境へのデプロイはsvn updateで完了です.ここらへんはスクリプトを組んでなるべく自動化し,省力化を行っています.手間がかかると飽きてやらなくなってしまうので.
  4. 日頃のアップデートは特に告知はしません.アップデート操作は,なるべく利用者の少ない時間を狙っています,ただ,24時間アクセスがとぎれないので,5時くらいに「えいやー」とやってしまいます.サーバを止める様な場合は,ポータルサイトに1週間程度前には告知を出す様にしています.(サーバを止めるのは,緊急対応が必要な場合が多いのであまり守れてませんが恥ずかしい
  5. そもそも,運用・開発兼サポートが2人(兼任教員と学生),サポートが2人(パートタイム)でサービスをしているので,ちゃんとした検証は行えてないのが現状です.一応これまでのユーザ利用ログから,よく行われる動作をリストアップしており,大きな変更が有る際はそれらを試してから投入する様にしています.
サービスは全てFreeBSDなサーバで行っており,ミドルウエアの更新はportsのアップデート頼りです.

こんな感じです.
欲しい機能の要求やバグの修正依頼はたくさん出ていますが,対応しきれていないのが現状です.(悲しい...