クロスブラ「ウザ」対策

こんばんは。

ウェブDBプレス vol.31やその他諸々Ajaxネタが多いので、
触発されて色々いじっているのですが…

クロスブラウザ対策、ウザ過ぎ…

というのが正直な感想ですね。
デキの悪いシステムにパッチ当ててるような感覚が、
自分的に非常に苦手です。

prototype.js とか、behavior.js とか、
それらをうまくラップするライブラリ的な JavaScript が増えてきてよいのですが…
それらも結局分裂する可能性があるわけで。

あまり JavaScript の言語仕様的な側面を掘り下げていないので、
ここの記述は言語仕様なのか、ライブラリの決め事なのかよく分からない、
ってのがよくあります。

その点、上記のウェブDBプレスのvol.31号は有益でございました。
「関数指向」な言語なんですね。

最後にちょっとメモ。

span タグの特定の class 名称がつけられた要素を、
表示段階で「ブラウザで」動的に変換する JavaScript 関数を書いたのですが、
IE と Firefox で動作するように書くのにえらい難儀しました…
(理想論からいえば CSS でやるべきなのでしょうが、
CSS3 で仕様策定中とか書いていました…)

[IE]
要素のボディ文字列へのアクセス： element.innerText
要素に子要素を追加： element.insertBefore(newChild)

[Firefox]
要素のボディ文字列へのアクセス： element.textContent
要素に子要素を追加： element.appendChild(newChild)

※IE→Firefoxの順で動作確認したので、
逆の場合、実はどちらでも動作する、
という表記があるかもしれませんが、
それはご愛嬌で！？

他のブラウザも対応、なんて言ったらやってられないです…
画面周りは基本的に自分は「完全フォロワー」ですね。
長いものに巻かれたいです。

P.S.
あ、IEのバージョンは6.0、Firefoxは1.5.0.1です。

ORA-00918: column ambiguously defined

こんにちは。
技術系のネタは超がつく久々ですね…
ネタは割とあるんですけど、
守秘義務に引っかかりそうな気がしないでもないです。

さて、現在、携わるシステムの機能追加を実装しています。
DBのカラム追加が伴う修正で、
とある時点のとある情報を保持する必要が出てきたらしく、
とあるテーブルと同じカラム名で関連するとあるテーブルにカラムを追加したんです。
(データベース的にこの対応はどうなのかというのはよく分かりません…)

このシステム、DBアクセスは割と、というか、かなりベタなJDBCでやっておりまして、直接関連する機能のアクセスクラスのSQLを修正したり、その他諸々修正してテストしていたんです。

すると、目的の機能の前画面ぐらいのところで、

ORA-00918: column ambiguously defined(列の定義が未確定です)

なんて言うエラーが出て動作確認したい画面まで到達できません。
直接関係無い機能ですが、エラーが出る以上調査しないといけません。
他人の書いたコードを辿っていきます…

まあ、このエラーコードをググッて出てくる情報の通り、JOINやら何やらしているSQLで複数テーブルに同一のカラム名が存在する場合に、このSQLではどっちのカラムのデータのことか分かりませんぜ、って時に出るんですが、パッと該当SQLを見ても、エイリアスでもなく、フルでテーブル名を先頭に記述して「大体は」記述しています。

おかしいなぁと思いながらSQL先頭から舐めるように見ていくと、ありました。
DECODE関数の第1引数に1個だけテーブル指定の無いカラムが。

今までJOINするテーブル片方にしかカラムがなかったので通っていましたが、同じカラム名でもう片方のテーブルに追加したため、エラーになっていたのでした。

えーっと、これって、ほぼ全てのSQLをチェックしないとまずいかも…
と途方にくれる午後4時半…

P.S.
後から追加するカラムはあえてどことも被らない名前にする、とか決めたりするもんなんでしょうかね？

[Log4j]設定ファイル(log4j.xml)

私が参加するシステムも一部で本稼動が始まりました。
東京ガスのシステムほど費用はかかっていないようですが、
まぁ、致命的なシステムダウンなどは今のところないようです…

そこで、今まで基本的にデバッグモードだったログ出力も、
本格的に運用が始まると、デバッグ出力は必要ありません。

そこで、Log4jの設定ファイル、log4j.xmlを見直していました。
気になった点は、rootロガーの子要素、priority要素の指定方法です。

[log4j.dtd抜粋]
<!-- If no priority element is specified, then the configurator MUST not -->
<!-- touch the priority of root. -->
<!-- The root category always exists and cannot be subclassed. -->
<!ELEMENT root (param*, (priority|level)?, appender-ref*)>

[log4j.xml抜粋]
<root>
  <priority value="trace" />
  <appender-ref ref="CONSOLE" />
</root>

今まで深くこの設定ファイルを見たことがなく、
元々他人が設定した内容だったので、
深く考えていませんでしたが、
パッと見て私が解釈したのは、

rootロガーがアプリケーションからログ出力として受けたメッセージは、
traceプライオリティに変換してCONSOLEアペンダーに渡される。

でも、この解釈が正解ならば、ちょっとおかしなことになるはずなんです。
というのも、今まで何回かログの出力レベルを変更した時は、
アペンダーの子要素のfilter要素でLevelRangeFilterを定義していて、
そのパラメータのlevelMinをDEBUGにしたりINFOにしたりしていました。

プライオリティが変換されると、levelMinをINFOにした時は、
アプリケーションからたとえプライオリティFATALで出力がきても、
traceに変換されてしまうため、TRACE < INFOとなり、
アペンダーで出力されないことになりますが、
そうではありませんでした。

そこでWebを検索して見つけたページは、

第9回　効率的なログ出力をCommonsで実現

で、そこには、

すべてのカテゴリに対するログを設定するには、
次のように<root>要素で設定します。

<root>
  <priority value="info" />
  <appender-ref ref="STDOUT" />
  <appender-ref ref="DAILY" />
</root>

この例では、<appender>要素で定義したSTDOUTアペンダと
DAILYアペンダのすべてのカテゴリに対して
infoレベルでログを出力します。

とあります。
これを私なりに解釈すると、
やっぱりinfoレベルに変換されるように思える(思えていた)のですが、
ひょっとして、rootロガーの前にcategory要素を定義すると、
そこに対しては変換されるんでしょうか？(未確認)

Log4jってrootロガーだけで運用することは想定していない？
rootロガー単独の場合はpriority要素の設定は意味をなさない？
と疑問に思いながら、rootロガーのpriority要素の値と、
appenderのLevelRangeFilterのフィルター範囲をいじり倒して出した結論。

プライオリティ(レベル)が変換されるのではなく、フィルタされる。
※ただし、現状確認できたのはrootロガーのみの場合

例えば、rootロガーの子要素でpriorityをinfoに設定した場合、
アプリケーションからのLogger.debug("hoge")はappenderに渡らない。
よって、appenderのレベルフィルタが定義されていなくても、
ロギングされない。
(同じプライオリティのLogger.info("hoge")は渡るようです)
要は2回フィルタリングされるわけですね、
appenderでLevelRangeFilterも定義した場合は。

ということは、誰ぞが設定したpriorityのtraceって意味無いんじゃ？
(最も低い優先度でフィルタする = フィルタなし)
DTD見ても必須じゃないし…

何とか、現状の設定ファイル内容における動作結果は把握できたんですが、
@ITさんの記事の内容がまだイマイチ理解できないなぁ。
categoryを別途定義した時の動作、
同じappenderを複数のロガー(という表現でよいのか？rootとcategoryのこと)で参照した時の動作、
categoryとloggerの違い…

Log4jのこの辺の仕様を深く理解することは、
自分にとっても有用だろうなとは思うんですが、
現状機能追加を実装するにあたって、
どこぞのプロプライエタリなWebアプリケーションフレームワークの
知識の方が必要な状況がイヤだ。(笑)
こんな時代遅れのフレームワークの知識を…(省略)

ディスクの断片化

今日作業PCで「容量不足」と警告されました。
ちょっとデータ整理しないといけないなぁ、
と思いながら、ふとデフラグツールで分析した結果、

こんなんでましたけど。(笑)

まあ、作業の内容からして、
毎日数千ファイルの出入りのあることが頻繁にあるので、
こうなっていくんでしょうけど…

DVD-RAM(私はRAM大好きです…)にバックアップを取りたい、
とは考えるんですが、今のご時世、
個人持ちのポータブルDVR-RAMドライブを接続するのも、
一筋縄ではいかないもので。

この後、試しにデフラグ実行ボタン押したら、

デフラグ用に空き容量15%ぐらいいるで、ドアホ。

と怒られました。
メディアにバックアップ取らないなら、
ファイル削除するしかないんですよ、
上の通りのディスク状況なので…

開発リソースはそれ用のサーバでCVS管理されていて、
理論的には自由に戻れるっちゃあ戻れるんですが、
自分の脳内タグで構築された構造の方が、
すぐ対応できるという意識もあるもんで…

捨てる勇気って私ないんですよねぇ。
デスクトップにもアイコン一杯散らかってますし。(笑)

[LaCoocan]Movable Type 3.2 のインストール

おそらくLaCoocanで@niftyさんが、
「こう使って欲しい」というモデルケースであろう、

Movable Type 3.2をインストールして使用する

というのをやってみました。

インストールの手順は、
前回のtDiaryのインストールと違って、
@niftyの「肝入り」であるMovable Typeなので、
こんな使い方として提供されるマニュアルに従ってやれば、
特に何の問題もないですね。

Movable TypeとココログのTypePadの具体的な違いは詳しく知らないのですが、
根っこは同じところだろうな、というのはインタフェースの類似性から感じます。
ココログの方は初心者向けにカスタマイズされているんでしょうか？
ちょっと今まで使ってみて物足りない部分があっていじりたいのですが、
あくまでWebブラウザを通じて提供されているカスタマイズだけしかできません。
でも、Movable Typeはスクリプトが自分で追えるので、いじり甲斐がありそうです。
難点はPerlであることですが…(あとライセンスもちょっとよく分かりません)

自分的には、不覚ながら、カテゴリの親子関係が定義できるMovable Typeに感動してしまいました。(笑)

ココログプロって確か容量10GBあったと思うのですが、
2GBのLaCoocanと入れ替えたいぐらいです…

[LaCoocan]SQLiteのバージョン

月末まで試用期間があるということで、
とりあえず登録して色々いじってみているところなのですが…

「Ruby on RailsをLaCoocanで試してみたい」

という欲求は、満たすことが難しいことが分かりました。
Railsってただのフレームワークライブラリ程度かと思っていたのですが、
どちらかと言うとアプリケーションサーバに近い感じなんですね。
1つサーバプロセスを常駐させるような感じのこと書いてありますし、
LaCoocanではtelnet接続できないので、
自分のスキルでは…(笑)
telnet.cgiも使用は規約違反と書いてありますし、
今自分の前には大きな山が聳え立っています。
(そびえたつってこんな漢字書くのか…)

もう一つの関心事であるデータベースのSQLiteですが、
簡単な操作には成功しました。
Rubyからの接続には、Ruby/DBIを使用すると簡単なようですね。

SELECT sqlite_version()

を発行したところ、2.8.17と返って来ました。
以前確かPHP5にSQLiteが同梱されるというので、
いじった時も2.xだった気がします。
3.xの方がいいなぁと思った記憶があるのですが、
理由は忘れました…
文字コード関係だった気がしますが、
もし日本語関係がうまく扱えない場合致命的ですね…

あと、特にデータベース不要なtDiaryもインストールしてみて、
何となく動いているようです。
かなり設定ファイルをいじり倒した気がします…

他の皆さんのLaCoocanネタを拝見してから最終決断しようと思いますが、
最悪登録解除するかもしれません。

P.S.
LaCoocanのサーバはLinuxのようですね。
ディストリビューションまでは分かりませんが…

LaCoocan(ラクーカン)

以前、インターネットに自分の城たる1ノードが欲しい、
という記事を書きましたが、
私がお世話になっているプロバイダの@niftyで、
LaCoocan(ラクーカン)なんて言うサービスが始まるらしいですね。

自分的な条件としては、
Java or Rubyが使えること(メチャクチャ妥協してPHP)と、
データベースが使用できることなのですが、
以前@niftyのホスティング系のサービスを調べた時は、
適当なものがありませんでした。
でも、これならRuby使えるということなので、
最低限クリアできますね。

え？データベースですか？

パッと見た感じ、データベース使えねぇのかよ、
なんてWebページを見ていたら、
ちょこっと書いていました、SQLiteが使えることを。

SQLiteと言えばPHPって印象がありますが、
RubyにもSQLite/Rubyというライブラリがあるようですね。

これだけ使えれば、
ちょこっとRuby on Railsで遊んでみることができるのでは？
ということで興味津々です。

引き続き調査を続けます。

頚動脈が締め付けられて…落ちた！(OutOfMemoryError)

2006年初ぼやきで書いたように、
細々と数千ファイル／日吐かれる通信ログをAntで操作する件ですが、
きちんと処理されているか巡回中、
どうも操作結果が中途半端なサーバを発見しました。

よくよく調べてみると、
アーカイブするファイル数が多すぎて、
OutOfMemoryErrorで落ちている模様。
Antのログを見る限り、
60分ぐらいはガリガリがんばっていたみたいです…

対象はWindowsサーバで、毎日朝方リブートされる設定になっていて、
タスクスケジューラで起動時にAntスクリプトが実行されるようにしていたのですが、
起動して早々にOutOfMemoryErrorで落ちるような処理走ったら、
何のためにリブートしてるか分かんないですね…

上記のような運用形態なので、
一発目の操作は放置されていた期間分のログファイルが溜まっていて、
ウン十万ファイルレベルの操作になっていたんでしょう…
一発目終われば後はせいぜい数千ファイルずつだから頑張れ！
と思っていたのですが、ダメでした。(笑)
今日手動でちょっとずつ削除しました。
エクスプローラでログ出力ディレクトリ閲覧するのも、
やたらと時間がかかって大変なんですよね。

P.S.
リモートデスクトップで「タスクの実行」した後、
終了前にログオフすると、
コマンドプロンプト系だけかどうかは分かりませんが、
プロセス無くなるみたいですね…

秀丸の正規表現検索機能

私は今、エディタは秀丸エディタを使用しているのですが、
今日はエディタ絡みで1ネタありました。

先ほどの記事のぼやきで書いた絡みなんですが、
どうもここ数日の通信応答時間が長いとクレームが入りました。

そこで、原因の切り分けのために、
その通信ログに出力されている処理時間を検索しようとしました。
例えば、次のように出力されているとします。

処理時間： 12345 ミリ秒

そこで、秀丸の正規表現を用いたgrepをしようと、

処理時間： [0-9]{5} ミリ秒
※今までの処理時間と桁が違うほど時間がかかっているのを抽出

などと言うパターンを書いて検索しても、
1つも引っかかりません。
えぇぇ、繰り返しって使えないの？と思って秀丸エディタのWebサイトを覗くと、

強力な正規表現検索機能

ということで、Ver5.00では使えるんですね。
私の使用しているのはVer3.10でした。

使うのと使わないのでは効率が桁違いなんです…
何せ数千ファイルの内ほとんどが正常なログなんですから…

2006年初ぼやき

明けましておめでとうございます。
このblogは2006年初エントリーですね。

前にも書いたのかなぁ、
今携わっているシステムでずーっと気になっているのですが、
とある通信ログが6000ファイル弱／日出ています。
出力部はシステム全体が使用しているCommons Loggingのメソッドを使用していなくて、
直接FileWriterなどを使用して実装されているようです。
こんなの明らかな規約違反なんですが、
今の今まで放置されていますし、
実装者はすでにこのプロジェクトにいません。
要は修正するなら私がやらざるを得ないんですね…
保守するの大変ですから。
(もちろん吐いたら吐きっぱなしです)

年末年始も健気に(笑)出力し続け、
テスト時期から残っているログを見ると、26万ファイルとかありました。
Windowsの仕様とかで、
1フォルダ以下のファイル数の上限とかあるんでしょうかね？

問題は、出力部をコメントアウトするなりして、
「吐かない様にする」のが手っ取り早くていいのですが、
今この辺の問題で不具合が頻発していて、
ログ必須なんです。
作業者みんなこの形式に慣れてしまっていて、
1ファイルに追記していく形にもそう簡単にできず…

また、Commons Loggingの仕組みに組み込むことで、
今までのログファイルの内容に「加えて」通信ログが出力されることになるわけで…
えぇ、Commons Loggingの下はLog4jを使用していて、
loggerをうまく定義してやれば、
今までのログファイルと修正した通信ログの出力先は分けられるんでしょうけど、
今root loggerだけ定義されてるんですよね。

現状Antで定期的にファイルをアーカイブし、
基準の日数過ぎたら削除ってやってるんですが、
どうしたもんかなぁと思い悩む日が続きそうです。

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

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年生なのでやめておきます…

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

パスワード文字数の制限

最近はネタになるような技術的なハプニングがないkazzyaです。

さて、最近は銀行のATMにカメラが仕掛けられたり、
情報セキュリティの関心が高いですよね。

ネットを使っていると、
色んなところでIDとパスワードを入力することになります。
やがて、どこがどのID！？ってなことに…

多くの人が、自分的にはある程度変更しても記憶から辿れるという、
ID、パスワード(特にパスワードですね)のフレーズがあると思うのですが、
それが、向こうのシステムの仕様で、使えなかったことありませんか？
あれ、困りますよね。
特に、文字数の下限で引っかかるならまだしも、
上限で引っかかると萎えますね。

不特定多数の方が使用するシステムを設計する場合、
パスワードの上限は限りなく大きく取りたいと考える次第です。

Google Analytics、キタコレ

設置して1週間弱でしょうか、ようやくレポートが反映されていました。
視覚的にこれだけ見せられると説得力あるというか何というか…
まあ、無料ですし、モルモットになっているのでしょうが、
よろこんでなりますね、これは。

アンケートにお答えいただいた方の中から
抽選でn名様に図書券を差し上げます。
発表は発送をもって…
なんていうのにはあまりそそられないのですがね。
くじ運ないもんで。(笑)

色々見て回りながらこの記事書いていますが、
皆さんお使いになられているのでしょうね、
やたらと応答に時間がかかりますね…
文句言えませんワナ、タダですから。