ジェームズ・クラーク式記法

Rubyは本格的に触ったことがない言語なんですが、
オブジェクト指向の理論を学ぶにはとてもよい言語だと思います。

プログラミング一般の知識で発見も多々あり、
るびまなどはちょいちょい見ているのですが、
0012号で、

「ジェームズ・クラーク式記法」

なんていうXMLの記述方法があるのを知りました。

これは、XML における意味論的な複雑さを回避するためである。

ものすごく納得します、その記法を使用する意図が。

昔HTMLをエディタなんかで記述している時に、
見やすいようにタグの階層ごとにインデントしていたりしましたが、
開始タグと終了タグを同じインデントで記述すると、
要素内の文字列の前後に改行とタブやら空白文字やらが入ることで、
ブラウザの表示結果が微妙に意図しないレイアウトになったりしたことがあります。
(まあこの場合、パーサが悪い、ということになるんでしょうが。)

それ以来要素内に改行文字を含むような長い文字列を記述する場合は、
開始タグを行先頭に持ってくるように書いたりしていました。
そうすることでインデントが崩れて見やすくなくなるのですが…

この記法を用いると、
通常行先頭は">"で始まることになるんでしょうね。

まぁ、見づらいっちゃぁ見づらいですけどね…
人間の見易さとコンピュータの理解しやすさの天秤で、
割とコンピュータ側に譲歩した記法でしょうか。

Google Analytics - 2005年第51週

2005年12月11日(日)～2005年12月17日(土)まで。

現状ではこの辺が限界でしょうかね…
まあ、今年末まではこんな感じで行くでしょう。
来年から真価が問われますね。

[訪問数とページビュー数]
320/441→388/486に微増。
誤差の範囲内程度ですわな。

[新規ユーザーとリピートユーザーの訪問数]
17.50→17.78%に。
これも「変わらず」ですね。
kazzya.cocolog-nifty.com にぶら下がっているblogって、
数個あるんですが、
今のところあえて相互に行き来できるようにはしていません。
来年から例えばマイリストに全blogのリンク貼ったらどうなるのか、
やってみようかな。

[地図上のデータ表示]
アメリカの西海岸と東海岸に1個ずつプロットされてますね。
プロキシ経由なのか、海外在住の日本の方なのか…

[ソース別の訪問数]
google: 26.56%→43.81%
(direct): 23.75%→22.16%
(other): 22.50%→12.11%
yahoo: 9.69%→10.57%
cocolog-nifty.com: 10.31%→8.51%
ずっとこんな感じになるんでしょうね。
この項目は感想書き続けても意味無いかも…
ということで、Google Analyticsの内容をゴソゴソしていると、
ありました。面白そうなのが。

[キーワード全体のコンバージョン]
@niftyのココログプロにもアクセス解析が付いていて、
検索ワードのランキングが出るのですが、
期間を細かく調整できないのでひとまずGoogle Analyticsだけにしますが、

1. 二段階右折
2. 列索引が無効です。
3. openoffice base
4. 列索引が無効です
5. 醤油チュルチュル

ってな具合。
多分、大体が私がやってることと同じように、
記事書く前にするような下調べとか、
仕事で詰まった時に同様の事例がないかとかなんでしょうね。

[WebLogic]接続プール名の制限事項？

現状、earのデバッグは、
データベースのみプロジェクトのテスト用サーバに載っているデータベースで、
アプリケーションサーバはWebLogic評価版を作業マシンにインストールし、
Eclipseからリモートデバッグ環境で行っています。

データベースはOracle9iですが、
データベースもローカルに持ってこれないかなぁ、
なんて思って、10gのExpress Editionをインストールしてみましたが、
環境構築まではいたらず。
別途記事書くべきでしょうけど、ざっと感想を書くと…

• インストールに1185MBいるって言われました。
• 管理は、ほぼブラウザでできるようです。(ちょいと触った感じよくできてる)
• Oracle系の資格取るために、勉強用に使うには、
  上の理由とか、制限事項に関わる部分で難しいのかも？

てな具合。

で、ローカルマシンからテストサーバのデータベースに対して、
接続プール、データソースの設定をするわけですが、
接続プール名について、日本語のプール名でも設定できるようですが、
どうも"@"を含む名前をつけると不具合が起こるようです。

"username@sid"なんて名前を接続プール名にして、
WebLogicを再起動したところ、
コンソールにスタックトレースがボロボロと…
ear内のサーブレットの初期化処理で、
データベースのデータを引っ張ってくるようになっていて、
スタックトレースにはそれらのクラスが含まれていてそのまま書けませんが、

Caused by: java.sql.SQLException: Pool connect failed : java.sql.SQLException: Connection Pool username does not exist.

って出てます。
"@"以降がぶった切られています。

おそらく、全角で"ｕｓｅｒｎａｍｅ＠ｓｉｄ"って定義すれば、
正常に起動するんでしょうねぇ。

意地でもやりませんが。(笑)

[Eclipse]完全または圧縮されたパッケージ名の表示

私の携わるシステムでもご多分にもれず！？、
やたらとパッケージ名が長いので、
パッケージ・エクスプローラーで目的のクラスを選択するには、
今の「小さな」モニタでは画面1/3ぐらいまで枠を拡げなければ、
識別できません。

そこで、
[ウインドウ]>[設定]>[Java]>[外観]ページの、
[最終セグメントを除く、すべてのパッケージ名セグメントを圧縮]をチェックし、
圧縮パターンに「1.」などとして表示するわけですが…

逆に短すぎて識別できません！

という状況に陥っています。
そもそものパッケージ命名規則がまずいのだと思いますが、
まずいポイントを挙げると…

[最終セグメントが一意でない]
常に全体が表示されるパッケージの最終セグメントは、
実装システム内における1機能名称など、
一意となる単語を割り当てるべき。(ホント？)
今の命名規則では、beanやらconstantsやら、
概念的な分類の単語が割り当てられていて、
短縮後の表示パッケージ名を見ると、
重複が多数存在する。
多分、[1機能名称]Bean クラスとか、
[1機能名称]Constans クラスで実装すべきなんでしょうね。
現状1パッケージあたりに存在するクラスって、
平均2ぐらいになりそう。
パッケージ分類の粒度が細かすぎるんでしょうね。

[冗長な接頭辞の付加]
今のパッケージ命名規則は、
[ドメイン名].[システム名].[大機能].[中機能].[概念的分類]
のようになっているのですが、
[中機能]の命名規則が、
ぶら下がる[大機能]の先頭1文字を接頭辞として付加しています。
これを圧縮パターン「1.」とかにすると、
接頭辞だけが表示されて、[大機能].[中機能]の部分の識別ができなくなります。
じゃあ「2.」やら「3.」にすれば？と言われると、
おそらく下の理由から「それでも長すぎる」ことになります。

[パッケージ階層が深すぎる]
ドメイン名も含めて、現状最大8階層のパッケージ構成です。
数値で見るとオープンソースのプロダクトでもありそうですね。
ただ、現状少なくとも1つ、全く機能していない無駄な階層があります。
これって、皆さんEclipseとかでサクッとリファクタリングしたりされているんでしょうかね？
これと最初の理由の中に書いている対処を行えば、
2階層は整理できそうですが…

現状Eclipseの上記設定は、
最終セグメント以外のパッケージ階層は、
全て同列で扱うような仕様のため、
「それに合わせた」形にするには、
上記のようなポイントを踏まえてパッケージを決定した方がよいのかな？
と思った次第です。

P.S.
そもそも自分の希望としては、
[ドメイン名].[システム名]ぐらいの全クラス共通部分までを、
ごっそり非表示にできないものかな、
と調査していたのですが…

Apacheエンタープライズポートレット - Jetspeed 2.0 公開

Apacheエンタープライズポートレット - Jetspeed 2.0 公開

IT系のエンジニアたるもの、
自分の城を持ちたいですよね。
ここで言う「城」って、
持ち家ではなく(持ち家もそうと言えばそうですが(笑))、
インターネット上の1ノードです。
この「1ノード」という表現も微妙なところで、
単純に共有ホスティングサービスに申し込んで、
独自ドメインでWebサイト作れればいいや、から、
OSレベルから自分の選択でシステムを構築したい、やら、
サーバ自体自前、UPSもつけて…まで。

自分の要件を考えると、
ソフトウェア系のエンジニアなので、
開発言語の要件が一番高いんです。
PHPとかPerlとかはちょっと…
Javaが最優先、インタプリタ言語ならRuby、な人です。

そうなると、共有ホスティングで安価な部類に入るサービスでは、
ほぼアウト、Javaが使えるサービスを探すと…
結構値が張るんですよね。
別に仕事で必要ではなく、半分趣味みたいなものですから、
24時間365日連続稼動が必要なわけでもなく。
となると、固定IPサービスがあれば恐らく事足りるんですが、
今、TEPCOひかりな自分は@niftyでそのサービスが無い…
というところで悩んでいます。
(DDNSは面倒なので嫌です。贅沢なんでしょうね。)

とタイトルと何の関係も無い話をダラダラ続けましたが、
環境が整った暁には、ぜひJetspeedで遊んでみたいですね。
ちょっと遊ぶのに、LAMPとかって、不要でしょう。
特にデータベースは世にある多くのWebアプリケーションにとって、
MySQLとか、PostgreSQLとか不要なはず。
(データ量ないでしょう？)
そりゃ、データベースの良い点もいろいろあって、
ちょいと昔の時代では、
掲示板のスクリプトでファイルのロックだなんだと言ってたんですからね。

その点、JetspeedはDerbyが組み込まれているバージョンもあるようなので、
OSとJavaの環境さえあればそれでいいんですよね。
データ規模に応じてDerbyで不満ならそっくり入れ替えればいいんですから。
(と簡単に言い切れないSQLの相違とかあるんでしょうけど…)

記事読んでると、

Apache Portals Bridges projectの成果物を使用することでStruts、JSF、PHP、Perlといった技術に対するブリッジを作成することもできる。

とのこと。
あまり内容分かってませんが、これって、
例えばJetspeedの1アプリケーションとして、XOOPSとか動かせるということ？
というか、XOOPS動かすと言うことはMySQLいるんですよね？
って話ですが。(笑)

Google Analytics - 2005年第50週

2005年12月4日(日)～2005年12月10日(土)まで。
計測期間は、日曜日～土曜日までを1週とすることにします。
また、これってタイムゾーンGMTのような気がするし、
日付変更後前日分が即反映されるわけでもなさそうなので、
月曜日の15時以降に分析した方がよさそうですね。

結果は、よく頑張った、オレ。
と言う感じでしょうか。

[訪問数とページビュー数]
113/160→320/441に増加。
理由は恐らく、むやみやたらとblogを増やしたためと思われる。(笑)
まだまだ試行錯誤中なので、blogは増えたり減ったりするかと…

[新規ユーザーとリピートユーザーの訪問数]
おそらくここで見るべきはリピート訪問ユーザーなんでしょうね。
16.81%→17.50%にアップ。
これ、維持、増加させるの大変なり。
まあ、知り合いにもほとんど知らせていないし、
とりあえず見ろ、と言えば少しは増えるんでしょうが…
あまり親しいと見て欲しくないのよね、
思い切って書けないから…

[地図上のデータ表示]
まあ、日本語圏外を受入れるようなコンテンツではないので…
あえてアクセスがあるとすれば、ゲーム系のコンテンツでしょうね。

[ソース別の訪問数]
これ、グラフの色と項目のマッピングって、
常に同じじゃないですね。
cocolog-nifty.com: 30.97%→10.31%
yahoo: 16.81%→9.69%
(direct): 15.93%→23.75%
google: 14.16%→26.56%
blog.livedoor.jp: 5.31%→(other)
blog.goo.ne.jp: (other)→7.19%

cocolog-nifty.comからの数が減っちゃいました。
こまめに更新して人目に晒さないとだめですね！？
キャッチーなタイトルにスカスカの中身じゃ、
無差別エロTBと同類になってしまいますが…

青色申告決算等説明会

最寄の税務署で行われた説明会に参加してきました。

ジモティ！？ではないため、
迷いました、ハイ。
開始時刻ギリギリに到着。

事前に郵送された書類を元に説明するとのことでしたが、
入り口で追加の資料が渡されました。
主に、税制などの変更があり、
今年から対応が必要な項目、
来年から対応が必要な項目の説明など書いてありました。

何せ個人事業主1年生なので、
どんな方々がいらっしゃるのかなぁ、と、
興味津々だったのですが、
私が参加した回は、
総勢40名弱、
男女比1:4ぐらい、
結構ご高齢の方が多かったです。
担当者の方のお話で、対象者が、
「営業の方、不動産収入のある方」
ということだったので、
後者の方が多かったのかも。
というか、私はどちらでもないような…

内容は、

• 決算の仕方(すごく概略)
• 年末調整の仕方
• 消費税の支払い方

で、決算の仕方以外は、
従業員に給与を支払っているわけでもなく、
消費税を支払うほど稼いでもいないため、
途中で退席しました。

基本的にはMCEAに書類作成の支援をお願いしているので、
必要経費の計上方法で何か役立つネタがあればと思っていました。
その中では、スクーターを通勤用に買った分について、
一括して経費に計上できるという部分だけメモメモしました。

ほぼ資料の内容をなぞっているだけなので、
毎年参加するようなものではないようです。
ただ、疑問点を相談できるような方が何名かいらっしゃっていたので、
イレギュラーな相談事項などがあれば、
参加してもよいのかもしれませんね。

YeNikkiを使ってみました

Yahoo!検索Webサービスの続きです。
Yahoo!デベロッパーネットワークで紹介されていたアプリケーションを、
ちょくちょくいじらせていただきました。
皆さんすごいですねぇ、想像力豊かで。
その中でちょっと笑ったネタをば。

Yahoo! JAPAN API を利用した自動絵日記システム YeNikki

を使わせていただきました。

使用が想定される場面としては、
blogで書いた記事のキーワードを抜き出して、
公開されていて関連のある画像を引っ張ってくるんでしょうね。

そこで、デモの文章として以下の内容を入力し、
submitを押しました！

W杯で、
キングカズが、
ロナウジーニョする！

内容は聞かないで。(笑)
一応サッカーネタでかつ微妙に関連のないキーワードを並べたつもりです。

その結果のスクリーンショットがこれ。

3枚の画像のうち左から、
カズ、ジーニョ、ナウってポップアップで出てました。

すいません、笑ってしまいました。

形態素解析の精度が上がれば便利なシステムになるんでしょうね。

画像検索の仕様を良く知りませんけど、
著作権的に問題ないような仕組みになっているんでしょうかね？
このデモの表示形式では直接リンクっぽいんですが。

いずれにせよ、皆さんのアイデアをどんどん吸収して、
何かインスパイアされて、ボロッとナニが出てくればよいのですが…

Yahoo!デベロッパーネットワーク

Yahoo!デベロッパーネットワーク

一応、無料ということで、いじってみるわけですが。

SDKをダウンロードしてみました。
SDKというよりは、ただのサンプルコードなわけですが…
Perl、PHP、JavaScriptのが提供されています。
個人的な嗜好により「現状」JavaScript一択です。

JavaScriptのサンプルコードを見る限り、
印象あまり良くないですね。
元々「検索」のAPIを提供されたところで、
自分のサイトにどう活かせるかがパッと思い浮かばないのに加えて
(これについては自分の問題なので仕方ないですが)、
サンプルコードの体裁が、見て萎えます。
(見た目から入るタイプです、スイマセン)

yj_search_api.js

line35: functionの定義のブロック、ステートメントの末尾にやたらと空白入ってるんですが、何か理由あるんでしょうか？動作結果はどうせ同じなのだから気にするな、という考えは私は嫌いです。

line64: createXmlHttpの定義中、インデントが空白とタブ文字混在しているのですが、EclipseとかのIDEで実装したんですかね？あと、ここ以外Tab2文字として実装されているようですが、ここだけTab4文字で書かれています。

line82: 完全なるおまけですが、JavaScriptのステートメントの最後尾とEOFの間に複数の改行文字があるのは個人的に嫌いです。ここの場合はfunction定義が追加されることを想定して改行文字が2個挿入されている、と解釈できるので我慢しますけど！？ファイル末尾が10行ぐらい「空行」なソースファイルもたまに見ます。
こんなこと書くのも、プログラムのソースコードではないREADME.txtですが、最終行が改行文字なしでEOFが来る書き方も嫌いだから書いたんですけどね…
README.txtのようなドキュメント系の記述慣習は逆に"(文末尾)改行文字[EOF]"で終わることがいけないのかもしれないんですけどね(よく知らないのです)。
Javaのソースコードでもよく見るんですが、ありなんですね。
どうも私が一番最初に関わったC言語のプロジェクトで、改行文字なしでソースファイル終わらせるとコンパイルエラーになる、と言われた記憶があって、それが頭にこびりついてるんですけれど。

それはコンパイラがヘボイだけで、
今時のコンパイラは偉いんだよ、と言われそうですね。(笑)

OpenOffice.org Baseメモ

仕事絡みでも、趣味絡みでも、
管理しなければいけないデータが多くあります。

Microsoft Officeの最新版を持っていない私にとって、
OpenOffice.org 2.0 は神となり得ます！？

そこで、この記事はBaseのメモ。
作業環境は、
Windows XP Professional SP1
OpenOffice.org 2.0.0
※この記事は適時修正、追加、削除されます。

1. SQL表示でクエリーを作成... でSELECT文発行時、テーブル名はケースセンシティブっぽい
2. HSQLDBのディストリビューションに付属のDatabaseManagerからクエリーを発行する際、文字列をダブルクォーテーションで括るとエラーになるが、Baseでは大丈夫っぽい
3. 日本語のテーブル名も定義できた
4. テーブルデザイン画面でプライマリキーを定義しないまま保存しようとすると、
   というダイアログが出る。
   そして、テーブル内にHSQLDB独自のIDENTITY(自動入力値「はい」)型を定義していた場合に「はい」をクリックすると、
   左のようなダイアログが出る。
   ※これ、どうもHSQLDBの制約事項のようです。IDENTITYを定義すると、そのカラムのみプライマリキーとして定義可能(自動的にそう扱われる？)である模様。
5. BaseからのJDBC接続(HSQLDBで言うところのサーバモードでの接続)で、うまくカラム名を取得できない。
   クエリーの直接実行ではレコードを取得できているようだが、ウィザードを使ってクエリーやらフォームやらを作成しようとすると、
   左図のようなダイアログが出る。
6. JDBC接続で設定したBaseファイル(*.odb)にはテーブル定義情報が保存されていないためっぽい。java.sql.ResultSetMetaData などを通じて取得して欲しいですが、これは望みすぎなのだろうか？
   現状テストでローカルホストにHSQLDBサーバを起動しているので、Baseで新規にデータベースを作成した時とあまり変わりがないが、特に仕事で使う場合はこの状況はほぼありえなくて、他マシンに接続するはず。
   JDBC接続だと既存のテーブルに対するクエリーやフォームを、ウィザード形式で作成できない？
   →ODBC経由のOracleへの接続時はカラム情報がきちんと取れている。
7. Windowsマシン上でBaseを使用していて、Oracleに接続する場合、ODBC形式でないと接続できない？
8. Oracle JDBCって何？
   →JDBCとして設定しても、次設定を開くと勝手にOracle JDBCになっている。
9. OracleのJDBCドライバのロードに失敗する。jarをクラスパスに設定しても失敗する。
10. Oracleからのエラーメッセージが文字化けする。
11. なぜテキスト形式のデータソースのデータ変換 > 文字セットのリストに、Shift_JISやUTF-8が表示されないのだろう…
    「システム」(デフォルト)に設定すると、日本語を含むカラムデータが文字化けする。
    →Baseのデータソースとして定義して文字化けした*.csvをCalcにドラッグ＆ドロップすると、テキストのインポート > インポート > 文字列に適切な文字コードの一覧が表示されるのに…

P.S.
組み込まれているHSQLDBはいじりがいがありそうですね。
今、個人的にPure Javaの組み込み系データベースに注目していて、
私の選択肢的にはHSQLDBかDerbyなんですが、
「ちょっとしたデータの管理」にDerbyは向いていなさそう。
前試しに起動したら、やたらとたくさんのディレクトリ、ファイルができたので。
HSQLDBは最大5つだったかな？データファイル。

作成日時、更新日時のカラム名称

まずは、吐露しておきますが、
私、データベース理論についてはほぼ素人です。

その素人の疑問です。
データベースのテーブル設計において、
作成日時と更新日時をカラムとしてほぼ無条件で付加しているのですが、
これは「一般的な」テーブル設計として妥当でしょうか？
今の参加プロジェクトのテーブルは、
マスタ系、トランザクション系に関わらず、
全てのテーブルについてそれらカラムが定義されています。
どこかでそういう日時をカラムとして保持することの是非の議論を見たような気がするのですが…
まあ、結論的には「ケースバイケース」なんでしょうけど。

あと、良い悪いは別にして、
いざ設けることになった場合、
カラム名称として適当なものはあるのでしょうか？

ちなみに、見たことある名称は、
作成日時：CREATE_DATETIME、CREATION_DATE
更新日時：UPDATE_DATETIME、MODIFIED_DATE
などです。

命名ポリシーとしては、何となく、

• 第三者が見てカラム内容が分かりやすい
• 長ったらしくない

すなわち、明瞭、簡潔であるようにすべきだ、と思います。
上記の例を見て、二点ほど議論のポイントがあるように思います。

'_'の前後でそれぞれポイントを挙げると、
「作成」「更新」という語を英語に訳す時に適当な語は何なのか？
というのが1点。
後は、DATETIMEとDATEで異なるニュアンスを意図的に伝えている場合があるのでは？
ということです。

前者については、英語圏の人が見ても同じ意味に取れるなら、
日本人が理解しやすい語を当てるのが妥当なんでしょうね。
私が例を見て感じるのは、作成日時、更新日時とも、
先に挙げられたほうが日本人定義、後の方が英語圏の人定義、に感じますね。
もっと単純に行くと、CREATEもINSERTに代えたいぐらい？
INSERT文の時に挿入されるカラムだからそれでいいんだよ、てな具合。
データ操作の総称を「CRUD」と言うらしいですが、
それを知っていると、CREATEもINSERTも一緒ちゃう？と感じるかもしれないですね。

後者は、結構根が深そう。
例えば、JavaのSunコーディング規約、みたいな、
(Oracle社の！？)カラム名の命名規約があればぜひ知りたいのですが、
あらかじめ規約を決めて定義しないとよろしくないですね。

実際あった話では、元々日付に関連するカラムを全てhoge_DATEとしていたが、
カラムの中には明示的に時分秒まで保持するカラムと、
日付のみしか保持しないカラムが存在するため、
同じカラム名の接尾辞だと混乱する、
よって日付のみのカラムはhoge_DATE、
時分秒まで保持するのはhoge_DATETIMEにする、
というのがありました。

確かOracleの仕様でDATE型で定義しても時分秒を保持するためだったと思います。

ど素人の私なんかが意見するなら、
データ型およびカラム名称はSQL標準に合わせて定義してください、
と思ってしまうんですが、
データベースエンジニアの方からすると、
絶対嫌(あるいは無理？)だったりするんでしょうね…
上記の例だと、(SQL標準自体よく知らないのですが…)
DATETIME→TIMESTAMPとか？

すごく奥が深すぎて、
簡単に意見できないのがこのデータベース関連の領域なんですよね…

Google Analytics - 2005年第49週

激しく右肩下がりなのが笑えますね。

明らかに自分のblogパターンを反映しております。

ほぼ週末は放置プレイなので、週末はアクセス数がた落ちです。

週が明けると週末のネタを頑張って書くので相対的に見ると一番高い。

まだ、blog界では底辺の底辺です、ってこった。

来年のテーマだな、こりゃ。

「高値安定」させるのが。

確定申告会

私が今所属している組合から、
確定申告会の参加予約受付けの知らせが来ました。

何せ確定申告自体初めてなもので、
何も分からないため、とりあえず予約Go !ってな感じで、
サイトにアクセスしたんですが…

受付け開始時刻13時を過ぎても予約できませんよ？
ひょっとして、帳簿データアップロードしないと予約できないとか…
帳簿の締め切りは1/15って書いているのに。
もしそうなら、参加予約受付期限の12/15が、
実質の帳簿データ締め切りではございませんか。
ほとんど手がつけられてないんですが、帳簿！？
一旦空のデータ送って予約できるかどうか確認、
なんてやらしいことは1年生なのでやめておきます…

空席の数が若干減ってるってことは、
予約完了された方がいらっしゃるようなんですが、
いきなり新参者に痛い洗礼が…