nDiki : 2005年05月16日

2005年5月16日 (月)

mixi 飽きた」

「なんか mixi 飽きてきました」と言いつつ毎日巡回している同僚。

スポンサード リンク

どうみても、そのままでは失敗しそうなプロジェクト

欲しい機能と完成予定日とを考えると、どう考えても無理なプロジェクトの話が出ているようだ。

真実10. 見積もりは、上層部か、マーケティング部門が実施する場合がほとんどだ。実際にプログラムを開発したり、開発プロジェクトの直接のマネジャーが見積もることはない。結局適切な人が見積もっていないのだ。-- ソフトウエア開発 55の真実と10のウソ p.51

(Fact 10. Software estimation is usuall done by the wrong people.)

まだきちんと見積もりが行われていない。もちろんきちんと見積もるべきである。 きちんとした見積もりを見れば現状の予定は無理すぎ(というか不可能)で、期間をのばして段階的に機能を提供していくべきだということを理解してもらえるであろう。 ……理解してもらえるよね? 不可能がわかっていて無理やり走っていつか闇に葬られるよりいいよね……。

真実9. ソフトウェア開発見積もりは、プロジェクトの開発時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発 55の真実と10のウソ p.48

(Fact 9. Software estimation usually occurs at the wrong time.)


[ ソフトウェアプロジェクトマネジメント ]

自分が個人で開発したフリーソフトウェアを自社製品に組み込むとき

tito 氏より、記事「WiKicker と GNU GPL」にコメントをいただいた。

ご承知とは思いますが「本体が GNU GPL だから、配布する場合はその部分も GNU GPL を適用」というのはGPLの条件で配布を受けた人がさらに別の人に配布する場合です。著作者本人はGPLに縛られずに別の条件でライセンスできます。 MySQLではGPLとコマーシャルライセンスの二つのライセンスを顧客の要求に応じて選べるようにしています。だからWiKicker の場合どうしようか? というのが「MySQLGPL」のお話ですよね。

コメントをいただいた通りである。 WiKicker は(バグレポート等ありがたいコメントをいただだきつつも)コーディングは一人で行ってきている状態なので、幸いライセンスの設定は自由がきく状態である。

今回いろいろ気にしているのは、自分がフリーソフトウェアの作者であると同時に、(組織の一員として)利用の判断、およびもし利用したとしてそれをベースに製品開発を行う立場にあるということ。

フリーソフトウェア作者として

組織の一員として

どれにする?

Perl と同じライセンス」にして、かつ「業務時間内にフリーソフトウェア部分のメンテ作業に対する『著作権放棄声明』獲得」がベストか?

フリーソフトウェアを個人で開発しつつ、それを商用ソフトウェアに組む込んでいる他の方々はどうされているのかぜひ知りたいところ。

Perl プログラムと必要なモジュールの配布

tito 氏より、記事「WiKicker と GNU GPL」にいただいたコメントの話

別の話になりますがあるperlプログラムをGPLでもなくartisticでも無いライセンスで配布したいとして、動作にperlのモジュールが必要な場合そのモジュールと一緒に配れるか? というのは興味深い問題な気がします。

CPAN にあがっている多くのモジュールが Perl と同じライセンスを適用しているので、それを前提とすると

aggregation して配布

CD-ROM 等にモジュールのソース tarball を同梱するのは

ということで、どちらを選択してもOK (The Artistic License を選択する場合は、パッケージを自分のプロダクトだと宣伝してはいけない等の制約あり)。

combine / embeded して配布

ということで

The Artistic License を選択できる Perl モジュールを使っているだけならば、一緒に配れるんではないでしょうか。

間違えていたらご指摘ください。

PDL の bad value と計算速度

PDL は bad value を扱うことができるのだが、どの程度速度に影響がでるであろうか。 ベンチマークを取ってみた。 環境は Debian GNU/Linux sid + pdl 2.4.2-2 + 2672-PHJ

 #!/usr/bin/perl -w
 use strict;

 use PDL;
 use Benchmark;
 my $a = sequence(1000, 1000);
 my $b = sequence(1000, 1000);
 #$a->badflag(1);
 #$b->badflag(1);
 timethis(10, sub { my $c = matmult($a, $b)});

badflag(0)

 timethis 10: 203 wallclock secs
 (198.90 usr +  0.46 sys = 199.36 CPU) @  0.05/s (n=10)

badflag(1)

 timethis 10: 416 wallclock secs
 (400.87 usr +  0.92 sys = 401.79 CPU) @  0.02/s (n=10)

ほぼ半分の速度。 ちなみに bad value サポート無しで PDL をリビルドして試してみたが、bad value 無しの計算では(matmult においては)特に差がなかった。

bad value の必要がないならば、PDL をリビルドした方がいいのかと思ってみたけれど実験した範囲ではかわらないようだ。

はてなブックマーク上の最新ブックマークnDiki

自分でタグ付けできないのでどうなのかと思っていたはてなブックマークであるが、気がつけば登録したブックマークももうすぐ1500。

タグ付けできない部分は、検索機能である程度カバー。 お気に入り機能のおかげで旬のネタ収集もできる。 なんだかんだいっても、さすが「はてな」という感じ。

日々登録しているブックマークを活用したいということで RSS を利用して、nDiki に表示してみることにした。 出勤前のちょっとした時間で Perl スクリプトとしてささっと実装

  • ローカルPCで以下の作業を行うスクリプトを書く
    1. LWP::Simple を使用して RSS を取得
    2. XML::RSS で parse() したあと、items から HTMLフラグメントを生成
    3. nDiki のフッタに挿入
  • cron で1時間毎に
    1. 上記スクリプトを走らせ、フッタファイルを書き換え
    2. フッタファイルを UnisonWeb サーバアップロード

という形で実現。

  • DiKicker にはフッタファイルに別のファイルをインクルードする機能がないので、フッタを書き換えてしまえ。
  • サーバに XML::RSS を入れるのが面倒なので、ローカルPCでやってしまえ。どうせブックマークが更新されるのは、そのPCを使っている時だけだから。

という手ぬきであっさり実装

[ 5月16日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.056445s / load averages: 0.33, 0.34, 0.42
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker