nDiki : フレームワーク

Perl WiKicker 実装 インストール 開発 認証 承認 MVC Perl 5.005_03 データベース Perl v5.6.2 Test::Harness HTML LaTeX Wiki xUnit Python DiKicker リファクタリング Web アプリケーション Ant Scheme 日記 新宿ねぎし NaneyOrgWiki Perl v5.8.0 DOM 三色方式 互換性 GNU Autotools

■ MVCと複数の変更主体

映画を観終わった後、銀座コリドー街の新宿ねぎしでご飯。 MVC関連の話など。

複数の View が編集状態にある時の、View 更新のタイミングの話とか。 フレームワークを利用したいが、フレームワークで想定していないちょっとした変則的な処理をしようとすると面倒だとか。

• [ WiKicker ] 日記機能開発開始 (2003-12-27)
• 今日のさえずり - リサ(とガスパールのリサ)って直立不動するのか (2009-12-12)
• [ DiKicker ] 関連記事表示機能を追加 (2005-02-26)
• ダ・ヴィンチ・コード一色 (2006-05-20)
• 今日のさえずり - 遠路遥々ワンちゃんが飼い主探して長旅する映画 (2010-02-25)

■ Scheme でプログラムを書く

たまにやってくる「Scheme やるぞ熱」再来。

Gauche 0.8.1 をインストール。 何を書こうかという話になるが、今回はテスト駆動開発入門で「単体テストフレームワークをテスト駆動開発で書いてみる」という例があり、新しい言語を学ぶときに良いとあったのでそれに挑戦してみることにした。 Gauche用の xUnit は既にあるようだが、トレーニングということで車輪の再発明。

フレームワーク部分を書いているのか、フレームワークの単体テストを書いているのか、単体テスト用サンプルオブジェクトを書いているのか、何だかわからなくなってくるな (オーバーラップするところもあるし)。

テスト駆動開発入門を参考にしようと思ったが、昨日会社に置いてきてしまったばかりだし。 明日続きをやるか。

• テスト駆動開発入門 (2004-08-02)
• テスト駆動開発入門読了 (2004-08-05)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• 今日のさえずり - バーコードって床屋でどのように頼むんだろう (2009-09-10)
• [ Perl ] PDL 2.4.1 から eigens が固有ベクトルを... (2004-03-05)

■ Perl でテスティングフレームワークを書いてみる

一昨日 Scheme で書き始めたのだが、やはり不慣れな言語でTDDをやってみるのも大変。

ということでPerlでやってみる。やはり最初はこちらの方が楽。 Perl では「これだ」という xUnit が無い。

• Test::Unit : メンテナンス停止中
• Test::SimpleUnit : 不明
• Test::Class : Test::Builder 系のテストフレームワークが必要

WiKicker は Test / Test::Harness を使用する標準的なテストを採用しているが、fixture の処理が面倒に感じている。 なので何か良い xUnit が欲しいのだが、テストのためだけに要求モジュールを追加するのもよろしくないので簡易的なものを自作するのも悪くないかも。

TDDはリズム感があって良いな。 まだリファクタリングフェーズでどの程度リファクタリングしてから、次のレッドフェーズにはいるかの匙加減がまた掴みきれていない。

• [ WiKicker ] 日記機能開発開始 (2003-12-27)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• WiKicker の Makefile.PL を Module::Inst... (2006-02-10)
• [ WiKicker ] 無記名時のバグ修正 (2003-09-20)

■ SCons は GNU Autotools のかわりになるか

NSIS のサイトによるとビルドに「SCons」を使うようしたらしい。

• クロスプラットフォーム
• Autoconf、Automake と同様の機能を統合
• LaTeX もビルトインサポート

と興味深いツールになっているようだ。

現在プロジェクトLaTeXベースのドキュメント生成には GNU Make を使っているのだが、UNIX、Windows の両方でビルドできるようにするには ComSpec 環境変数の有無で使用するコマンドを切り換えたり等いろいろ面倒なので、代替ツールとして使えないかなと。

基本的な機能は Make に対する改良がなされているようであるし、コピー等ファイル操作も SCons 自体がもっているのでクロスプラットフォームでビルドできるようにするのも楽そうだ。

一方 Autoconf 系の機能については、インストール済みのライブラリの検出や実装レベルのチェック等を実装しているようである。 make check や make dist、make install 等にあたるターゲットに関する機能(あるいは規約)のようなものは無い。これは非常に残念。 結局自分が Ant を使わなくなったのも GNU Autotools にあるこれらの機能に欠けているからであるし。

実は私がPerl が好きな理由の一つとして、これらサポートが充実しているという点がある。Perl では ExtUtils::MakeMaker (あるいは Module::Build)があり、ビルドからテスト、ソースパッケージのパッケージングまでフレームワークが整っている。

SCons は Python ベースで、Makefile にあたるファイルも Python スクリプトである。 SCons が影響を受けた Cons は Perl ベースであったのだが、既に2001年5月ごろから開発が止まってしまっている。残念。

ということで Make の代替には使えそうであるが、GNU Autotools と同じようなことをするにはいろいろ手をかけないといけないといった印象。

• Module::Build でソースパッケージング (2005-08-24)
• Windows 向けソフトウェア開発者はソースパッケージを作る習慣がない (2007-07-31)
• 私的10大ニュース2004 [ comp ] (2004-12-31)
• ActivePerl で Ming (2005-02-23)
• NSIS 2.22 は Linux でビルドできず (2006-12-20)

■ Docutils の reStructuredText から LaTeX への Writer は継承しづらい

この間やっつけでPerl で コンバータをちょっと書いたのだが、やはりここは正攻法で Docutils の Writer として書いておきたい。

Docutils に含まれている LaTeX2e Writer (docutils.writers.latex2e) のクラスを継承してカスタマイズ版を作ればいいかなと着手。 この Writer の生成する TeX ファイルがちょっと好みではないので、継承して自分好みの Writer を書いた上で、それを継承してドメイン毎の Writer を書く事にする。

Python でコードを書いたことはほとんどないのだがそれほど迷う点はない。 素直な言語なのかな。$ とか @ が出てこないのはちょっと寂しい。ブロックをインデントで示すので「閉じ」がなく、ちょっと「スースー」する。 わかる? この気持ち。

Docutils はパースした結果 DOM ライクなツリーができて、これに対して visit / depart 式の visitor を使って処理をしていけるようになっている。 そのあたりはフレームワークがあるし、典型的なパターンなので楽ではある。

ただし、docutils.writers.latex2e のクラスが継承されることを意識されている感じがしないので、メソッドをコピーして書き換えてオーバーライドといった事が必要になる箇所が思ったよりあるのがちょっと気になる。 今後バージョンアップした時に内部も変わる可能性があるだろうし、最終的にはごっそり Writer を作ってしまう方が良さそうだ。

• Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
• reStructuredText いいんじゃない? (2005-11-22)
• SCons は GNU Autotools のかわりになるか (2005-04-20)
• 早速 reStructuredText から LaTeX へのコンバータを書く (2005-11-24)
• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)

■ 成功するビジネスプラン

新しいアイデアをもとに新しいソフトウェアを開発・販売あるいはサービス提供を行おう。

開発についてはいろいろ学んでいるけれど、もっと大きな視点でどう事業化していくかという点についてはほとんど理解していない。 どういったビジネスシステムでそれを実現していけばいいのかわからない。 どのようにプランニングし、提案していけばいいのか正直よくわからない。

何を分析して、何を考え、何を書けばよいのか。

まずは入門書にあたろう。ということでまずは「成功するビジネスプラン 日経文庫」を読んでみた。

本書は、事業や顧客の分析といったビジネスプランを立てる上でのフレームワークから、具体的な事業計画書の書き方、財務計画の立て方までを解説。-- (表紙裏 [POINT] より)。

新書サイズということで深くはないものの、ビジネスプランを作成する上で必要な分析のフレームワークが一通り紹介されているので、どんな事を考えなければならないのかが分かってきた。

さらにビジネスプランの構成が説明されているので、まずはこれに従ったアウトラインで書きはじめることができる。

三色方式で線を引きながらでも1日で読めてしまうので、急にソフトウェア製品/サービス企画を具体化する必要がでてきた時に、慌てて読むのになかなかよい1冊である。 で、書きながら詳細を知りたくなった点を他の書籍で補っていけばよいだろう。

ただ財務計画についてやはり別途基礎知識がないと駄目だな。

[ 書評 ]

• Evernote 使用開始 (2009-03-03)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• PLANNING に違う期待をしてしまった「PLANNING HACKS!」 (2007-07-12)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)

■ Intercepting Filter パターンとレスポンスの順次送信

WiKicker にセッション管理/認証/承認機能をどのように形で組み込むか思案中。

セッション管理部分は CGI::Session モジュールで実装し、認証・承認部分はドライバはまずは Apache::Htpasswd モジュール等を使い上位部分を自前で実装という形にすることにしようと考えている。

さて、これをどうやって組み込むか。 認証・承認機能は、運用によってバックエンドがファイルだったりデータベースだったりする(したい)ので、結構な柔軟性を持たせておきたい。

Servlet のフィルタのように Intercepting Filter パターンにするのが柔軟性が高いかなと思ってコードを書き始めてみた。 リクエスト側のフィルタリングは問題なかったのだが、レスポンス側のフィルタリングではたと困った。

WiKicker では view についてはクライアントを待たせないように、構築したところから順次送信している。 効率を落とさず、拡張可能なフィルタを適用するのが難しそう。

実装したい機能に対してオーバースペックなフレームワークに膨れ上がりそうなのでヤメ。 普通にそれぞれの機能を差し替え可能にしておいて、使わない場合は何もしない処理クラスを設定するという無難な構成にしよう。

• WiKicker 0.39 リリース - 添付ファイルの削除機能を実装 (2006-10-17)
• WiKicker 0.38 リリース - 認証・承認用コードの実装 (2006-09-14)
• DBIx::Class + SQLite で Wiki 用認証/承認データベース (2006-06-18)
• WiKicker 0.30 リリース - トップページのページ名を変更でき... (2006-05-22)
• WiKicker へのセッション管理/認証/承認機能追加開始 (2006-03-02)

■ WiKicker 0.38 リリース - 認証・承認用コードの実装

朝一で WiKicker 0.38 をリリース。 昨晩コードを完成させておいたものを Perl 5.005_03 上でテストしたら、ExtUtils::MM が 5.005_03 にはないことに気がついた。 調べると標準で入っているのは Perl v5.6.2 / Perl v5.8.0 から。

ということで急拠 ExtUtils::MM を使っているツールは今回のリリースから除外してパッケージング。

今回のリリースでは認証・承認フレームワークの実装が含まれるようになったのが中心で、基本的な機能には特に変更なし。

• WiKicker 0.39 リリース - 添付ファイルの削除機能を実装 (2006-10-17)
• Intercepting Filter パターンとレスポンスの順次送信 (2006-02-28)
• テスト。More。 (2005-03-13)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• Time::Local::gmtime の範囲チェック (2003-12-23)

■ WiKicker 0.39 リリース - 添付ファイルの削除機能を実装

ようやく添付ファイルの削除機能を実装。

後は主に認証・承認関連まわりのコード追加。 フレームワークとして認証処理と承認処理は分離してあり、それぞれ運用に合わせてドライバクラスを書いて使うようになっている。

しかし実際のところ認証も承認も同じデータベースを使うことが多いか、やっぱり。 特に中～小規模では。 実際自分がある運用用に書いてみているドライバもそう。

そうすると分離していることが逆に厄介。データベース処理が分かれてしまうので、データベースのオープンとかトランザクション処理とかをまとめにくい。

そのあたりうまく下位部分を一緒にできる仕組みを入れてあげる必要あり。

• Intercepting Filter パターンとレスポンスの順次送信 (2006-02-28)
• WiKicker 0.38 リリース - 認証・承認用コードの実装 (2006-09-14)
• DBIx::Class + SQLite で Wiki 用認証/承認データベース (2006-06-18)
• WiKicker 0.30 リリース - トップページのページ名を変更でき... (2006-05-22)
• DBIx::Class はあきらめて素の DBI + DBD::SQLit... (2006-09-12)

■ WiKicker に JSON でのページ出力機能を追加

最近は DiKicker ばかりに手を入れていたが、久しぶりに WiKicker の改良も行っている。 しばらく前から実装を始めていた JSON 形式での出力機能が今日完成。

今までは WikiPage について

• HTML 形式による出力
• Wiki 文法で書かれている生テキスト形式による出力

という2つの出力形式を持っていたので、JSON が加わることで3つめとなる。

@ サーバ側で WikiPage の構文解析まではやる

クライアントサイドの JavaScript でページの内容に合わせて様々な処理をできるように、サーバ側で構文解析まではしてあげるというのが主な目的。

JavaScript でまたパーサを書いてメンテしていくのも大変なので、その部分はサーバでやってしまおうかと。 構文解析した結果の解析木を JSON 形式で返して、JavaScript 側であとはお好きにという形。

@ CPAN にある JSON モジュールを使用

サーバ側の Perl プログラムには、構文解析をして解析木を作れるようになっている。 この解析木から Visitor パターンで JSON 形式を生成していく。

依存モジュールを増やすことを避けるべく、最初は自前で JSON 形式に変換していこうと思ったのだがやっぱり面倒だった。 ということで CPAN にあるモジュールをチョイス。

JSON 関連では JSON、JSON::Syck、JSON::PC などがあるが今回はインストールのしやすさを考えて pure Perl モジュールとして実装されている JSON を採用することにした。

Visitor クラスで解析木を無名ハッシュ/無名配列のツリーに変換して、JSON モジュールに流しこめば OK。

 use JSON;
 my $json = JSON->new(pretty => 1);
 my $js = $json->objToJson($tree);

WiKicker のフレームワークにはフォーマット別に出力を切り換える機構があるので、これに JSON を追加して application/json で送るようにして完成。

ちなみに残念ながら JSON 1.07 は Perl 5.005_03 では make test が fail するので、NaneyOrgWiki では使えない。

• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
• WiKicker の Makefile.PL を Module::Inst... (2006-02-10)
• [ WiKicker ] 「最近のアクセスログ」処理思案 (2004-01-17)
• [ WiKicker ] hell mode - HTMLタグ付けブロックの導入 (2005-09-13)
• www.naney.org をさくらのレンタルサーバへ移転 (2009-12-23)