今回は、JavaCCの構文定義の文法です。
前回はビルド方法だったので、今回からが本番です。
JavaCCでスクリプト言語を作成する 第2回 文法定義の基本的な構文
Seasar批判
まあ、Seasar Conferenceに行ったことだし、久しぶりに見てみようかとホームページを見てみた。
感想。
わかりにくい。
あえて批判的に書いてみる。ほかに書きそうな人もいないし。
中身がいいことは知ってるんだけど。
1.ホームページがわかりにくい。
たとえばプロダクトの説明はトップページにないのに、メーリングリストやSorcefogeへのリンクがかなりの場所をとっている。
情報の優先順位付けなんかの、ホームページの設計がうまく行われていない感じ。
あと、ドキュメントとダウンロードが同じページにあるからといって、同じリンクにまとめてしまうと、ドキュメントもダウンロードしないと見れないのかと思ってしまいます。
2.名前がわかりにくい。
名前にはいろいろなこだわりがあるので良し悪しの問題ではないけど「Kijimuna」よりも「S2Eclipse Plugin」の方が何をするものかわかりやすいというのは事実。
凝った名前を付けるのは楽しいだろうけど、ユーザーにとってわかりやすい名前をつけるというのも大切かと。
3.ドキュメントがわかりにくい。
象徴的なのは、プレゼンテーションに7つのプロダクトがあるのに、動作結果としてブラウザ画面のキャプチャがあるのはS2Flexの1点だけというところです。
4.仕様がわかりにくい。
ルールにより設定不要というのは、知識を増やしてコーディング量を減らすということです。全体的にそういう傾向があるようです。そのため、使う前に全体的なルールを覚えておく必要があります。
わかりやすいドキュメントの書き方
ドキュメントもソフトウェアなので、ソフトウェアの開発手法がそのまま適用できます。
つまり
・要求定義
・ユースケースの分析、つまり、誰がなんのために見るかを想定
・利用者のワークフローを分析
・説明する対象の構造を分析
・優先度やワークフローにしたがって構造を設計
・設計にしたがって実装
・テスト
という流れ。
成果物をJavaのコードで書くか日本語で書くかの違いでしかありません。
わかりにくいドキュメントというのは、説明する対象をその構造だけにしたがって書いている傾向があると思います。
それは、システムで例えればデータベースをそのまま見せて、あとはSQLで勝手に操作してねというもの。
たしかにデータは全て整っているけど、何も知らない人が使えるものではないシステム。
つまり、仕様の羅列になっていて、ユーザーインタフェースが噛んでいないドキュメント。