アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
太陽超小型装置 (スコア:1)
サーバーサイドだと結構メジャーになってきたようだし
Re:太陽超小型装置 (スコア:2, 興味深い)
捺印ナビリティって奴ですかね。
JavaServletのコンテナ(の繁雑さと、たとえばRubyのWEBrick[*]の簡単さとの、あまりにも凄い格差)とか、
EJBとか、を思うと、やっぱり「Javaはウンコ」だと思うんですが、
それでも使いたいと思う人…ってゆーか企業…は多いんでしょうね。
[*]
WEBrickをJavaに移植するといいんじゃないかな。
その簡単さの全てが移植できるとは(言語の構造の違いから)言えないけど、
部分的には出来るんじゃないのかな。
コンテナじゃなく単なるライブラリにしちゃうのが味噌ね。設定ファイル捨て捨て。WEBrickにはmountメソッドとかが有るのが素晴ら
Re:太陽超小型装置 (スコア:2, 興味深い)
とまれJavaとはどこにも書いていなかったので言語の宗教戦争をしてもしょうがありませんが、EnterpriseといえばCobolでしょう。(笑
Enterpriseの世界は決してWebアプリだけではありません。WEBrickがいくら素晴らしくてもP言語でバッチを書く気にはあまりなれないと思います。
バッチで一番必要なのはトランザクションや、2フェーズコミットや、何より実行速度だったりします。
これをCobol以外でかろうじてまともに実行できるのはJavaだけで
Re:太陽超小型装置 (スコア:0)
> 何より実行速度だったりします。これをCobol以外でかろうじてまともに
> 実行できるのはJavaだけではないでしょうか。
トランザクションや 2フェーズコミットなんて DB にまかせるもんじゃ
ないの? COBOL って COBOL がその辺面倒見るの?
実行速度については Java だってどうかと思うけどねぇ。
COBOL は知らないけど、Pro*C と Java と Perl でバッチ組んだ経験にからすると、
perl でバッチ処理を行うメリットは以下の通り。
- 当然トランザクションなんて DB まかせ
- CSV→DB や DB→CSV など、文字列処理が絡んでくるとメモリ管理を
perl まかせにできるのでとても楽。
- さらに CSV と DB のマッピングファイルを作っておいて、それを元に
動的に SQL 作ったりできるので、プログラムがすごくシンプルになる。
例えば 100種類のテーブルに INSERT しなきゃならない場合でも、
INSERT 文生成はマッピング処理エンジンに一つだけ書いておけばすむ。
- DB からデータを引っ張って、ユーザにメール送信なんかする場合は、
テンプレート関連のモジュールが役に立つ。
- 速度はそれほど速くないけど、マスタ内容をハッシュに突っ込んだり、
prepare_cached で一度だけ SQL をコンパイルするようにしたり、
それほど苦労せずにある程度の高速化が可能。
マッピングについては、例えば CSV 解析部分は
<record name="なんとかレコード" recordid="01" length="121">
<column name="項目A" length="2" />
<column name="項目B" length="4" />
なんて定義ファイルを用意しておけばハッシュに全部突っ込まれる
ようにしておく。そしてハッシュから DB へのマッピングは、
%map = (
tablename => '格納対象テーブル',
colmap => {
# テーブルの項目← CSV の項目
'項目A' => '項目A'
'項目B' => sub { substr(項目B, 1, 2) },
...
なんて書いておくと。
一番 perl のメリットが感じられないのは、DB から読み込んで、計算して、
特定の項目を UPDATE するようなバッチかな。単純な処理なら Pro*C の
方がやっぱり速い。