Webコンサルタントの愚痴とアジャイル,生産性向上,Trac,オープンソースなどの与太話
過去に十二指腸潰瘍と胃潰瘍をやってるのでヤバい気配は分かる。
空腹なのに膨満、胃散過多な気配。一昨日は客先で吐きそうな感じで一時間半打ち合せ。拷問のようだった。
とりあえずセルベールでも飲むかぁ~。
仕事での打ち合わせも、議事録を取って後に関係者にメールするという流れから、ブログで情報を共有し各自考えや方向性を模索して、1つのブログ上で複数人の考えを交錯していくことでより洗練されたプランとなる。通常これらは、会議室フォーラムやメーリングリストが一般的だが、1つだけ不満があった。それは、「図やフロー」などの視覚的要素を共有するのに、従来の方法は、添付したり文中に加えていくのがヒト手間かかるのがイヤだった。そこで、実験的にブログを議事録として活用する方法。(以下略)
※PearBlogから引用
なるほど。なるほど。これ確かに良いね。
うちの会社の場合、技術情報の発信はブログでやっているんだけども、こういう使い方があったかー。
色々社内組織を横断した活動をしようとすると、情報の流通経路が普段と変わってくるし、どう活動結果を広報し、周りに理解してもらうか?ってのが大事になってくるかと思うのだけれど、これなら常に動きを参加者以外にも簡単に発信できるし、例えばアンケートとったり質問してみたり、内容にコメントつけたりなどなど簡単に出来る。早速社内に提案してみよう。
(さすがにお客さんとのやりとりを社外のネットワークにさらして共有するなんていう度胸に溢れた真似は出来ないんだけど、社内ならOK)
ちなみに、確か「はてな」ではプロジェクトの情報共有もかなりブログでやっている、と聞いたことがある。大きくない組織ならこれも良いけど、100MMとかの規模になると、一応普通にWBS切って無難にやるからなぁ。まぁこの辺は色々な事情に合わせて柔軟にやるんだろうね。
疲れた。マジ疲れた。
結構限界直前な感じ。精神的に余裕がまったくなし。はぁ。。。
iMP Downloadは、wordpress内で、ファイルダウンロードへのリンクを張っている場合のダウンロードカウンタである。
従ってソフトウェアや素材などを公開している場合は、どのくらいのダウンロード状況かが分かるため有益である。
勿論、生のアクセスログを集計すれば、自分自身ではダウンロード状況は分かるけど。
iMP Downloadの特徴は下記の通りだ。
簡単すぎるが、一応。
ちなみにこちらにあるDownload Counterは、プラグインを登録したら、なんかPHPのwarningsが一杯出力されていた。どうもレコードが無い場合の処理が怪しそうということで、品質いまいちかなぁと判断。
サンプル(トップ3を表示。表示はファイル名称、DL回数の順)
単純に関西弁にコンテンツを変換します。単なるネタでPerlのKansai.pmを参考にしてます。
仕様としては<kansai></kansai>で囲まれた文字列は、表示の際にフィルター通して予め登録しておいたパターンに変換されます。そういう意味では関西弁である必要はなくて、レギュレーションルール統一のためにも使えそうです。
もうちょっとデバッグ&精度を上げたら公開予定。
ご意見いただけたら幸いです。
<変換前>
あなた変わりはないですか?私も変わりありません。まずまず元気です。
<変換後>
あんた変わりはあらへんですか?私も変わりありまへん。ぼちぼち元気です。
こんなことをして嵌った。
で、これは何故か失敗します。ちょっと以下の通り試してみてください。
例えば、デスクトップにparent.htmlという名前で以下のようなファイルを作ります。
これを実行すると、結果はこうなります。

次にファイルシステム同士で実行してみます。(googleはローカルに配置できないので、
同じフォーム要素を持ったファイルを作ってください)
呼び出し元と呼び出し先をファイルシステム同士に配置した場合、これはうまくいきます。
さらに、今度は呼び出し元を違うサーバに配置し、呼び出し先をローカルのIIS以下に配置してみます。
これはうまくいきません。
まとめると
| 呼び出し元 | 呼び出し先 | 項目操作 できるか |
|---|---|---|
| ファイルシステム | ファイルシステム | 成功 |
| ファイルシステム | 内部サイト(http://localhost) | 失敗 |
| ファイルシステム | 外部サイト | 失敗 |
| 内部サイト(http://localhost) | ファイルシステム | 失敗 |
| 内部サイト(http://localhost) | 内部サイト(http://localhost) | 成功 |
| 内部サイト(http://localhost) | 外部サイト(http://192.168.1.54) | 失敗 |
| 外部サイト(http://192.168.1.54) | ファイルシステム | 失敗 |
| 外部サイト(http://192.168.1.54) | 内部サイト(http://localhost) | 失敗 |
| 外部サイト(http://192.168.1.54) | 外部サイト(http://192.168.1.54) | 成功 |
結論としては、
ということのようだ。なるほどねぇ。
EUC-JPのばかー。
組織の話。
多くのメンバーで仕事をするとき、階層型組織にするのが普通だと思う。
人数が少ない組織であれば階層化は情報伝達コストの増大にしかならないのでフラット型組織が良いだろう。
問題はフラット型組織から階層型組織への移行過程にある場合だ。表面的な体制図を書き替えただけで移行が完了するわけではないのは当たり前。
情報伝達ルートと各人がヘッジするべきリスク範囲・内容を変えていかねばならないだろう。管理職の立場から言えば、自分がヘッジしなければならないリスク以外は、部下にリスク委譲していくことが必要だな。
自分が管理職なのか技術者なのかをはっきりしないといけない。技術者としてのプライドと、管理職としての責任は相反する部分があり、それが俺を苦しめる。自分がどこまで何をやるのか答えがほしい今日この頃。
俺は忙しい時ほどブログを良く書くらしい。
確かに
会社のエレベータで久々に会ったM氏に言われた。鋭いねぇ。

よくみたらすごい違和感。
PerlがPealになっている。
この会社に発注して良いのでしょうか・・・。
日記 PHP オープンソース Linux Trac Perl wordpress フリーソフト Agile 自宅サーバ phpMyFaq Plugin 書評 Delphi apache プラグイン Subversion アジャイル mojavi セキュリティ Ruby Firefox Ajax/Web2.0 eclipse サーバ Zope フレームワーク CakePHP 文字化け scuttle OpenVZ 自宅 phpBB CMS 翻訳・日本語化 Excel ApacheDS 生産性向上 仮想化 hacks CodeIgniter XAMPP LDAP SBM taskfreak Ajax 修正 言語ファイル mod_security ダウンロード HTML::FillInForm 情報共有 格安 メンテナンス 移転 アンケート レンタル PhpScheduleIt 翻訳 API