アカウント名:
パスワード:
> 文字列のトリムについて
> 文字コードのルール決め
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
連投その1 (スコア:1)
ラクできた部分もあり、随分苦しんだ部分もあります。
ということで、自分自身への反省会の意味もこめて、以下コメント。
書き始めたら、相当長くなってしまったので、分割投稿で(笑)
まずは shimashima さんの日記から。
> プロパティファイルとそのアクセス方法。また必要であれば、native2asciiの実行についての考慮
このへん、設定ファイルを Unicode で書くのがあまり好きではなく
SJIS で書くことにしています。
Java 的には、ResouceBundle を使えるので、Unicode の方が便利で素直なのでしょうが、
properties を読み込ん
連投その2 (スコア:1)
> 文字列のトリムについて
念入りに仕込んでおいた結果、性能試験の時点で、ここでかなりのコストを
食っていることが判明してしまいました。
非可逆になるのを嫌って、bean の getter 側にトリムを仕掛けたのですが、
setter に比べて圧倒的に呼び出される回数が多くて、そこで性能の足を
引っ張ってたりしました。
実装的には、String クラスの replace とかを使うと思うのですが、これが
結構コスト高いです。
そこで、C言語的なバイト操作で取り除くようにコーディングすると効果が出ると
思われるのですが
全角空白文字対応とか「文中にある空白は取り除いてはいけない」とかまで
考え始めると、相当工数がかかります。
結論としては、中でどうこうするよりも、
不要なデータは、極力システムの入り口で塞ぐのがセオリーですので
まずはそこにエネルギーを注ぎましょう。
> 文字コードのルール決め
わかっちゃいながら、やはりハマりました。
特に、unicode から SJIS と MS932 とでマッピング先が違う「~\~∥-¢£¬」と、
「NEC選定IBM拡張文字」と「IBM選定拡張文字」との2箇所のマッピングがある
「はしご高」や「立て崎」については、事前に要チェックです。
OS、Java、DB など、個別に調査が必要ですが、最終的にはプロトタイピングしないと
本当に問題がないか、自信を持てない部分です。
ちょっとハナシがそれますが、データ内部にある「改行文字」「空白文字」「タブ」
や、「クォート」「ダブルクォート」「$」「#」なんかも同じ手順で確認しておく
必要があります。
> ログレベルの制定
当然、properties ファイルにログ番号とログメッセージをまとめておいたのですが、
一緒に「ログレベル」も設定ファイル化しそこなってしまったため、大失敗しました。
開発中は積極的にログを出すことに意味はありますが、ログの出しすぎは
性能面で大きく足を引っ張ります。カンタンに 30~50%くらい違っちゃいます。
で、いきおい『「ERR」以上しかださない』みたいな設定にして無理やり性能を確保しても、
障害発生時に「何かがおこった」ことはわかっても「何がおこった」かがわからなく
なってしまいます。
開発当初から、ログの緊急度を見極めながらコーディングするのは結構難しく、
かならず後で変更したくなりますので、ログレベルも必ず外出しにしておくこと。
連投その3 (スコア:1)
>例外設計
ループの終了条件として Exception を使うのはヤメましょう。
アラーム監視システムが拾っちゃって、かなり面倒なフィルタリングを
仕掛けるハメになりました。
>マスタデータの準備
現行システムから 100% 流用するのであれば問題ありませんが、
まったくの新規システム、あるいは移行元から設計変更を伴う場合は、
マスタデータを誰が用意するのか、かなり早期の段階で決めておくことを
お勧めします。
テーブル設計は開発者の仕事かもしれませんが、データの中身は
お客さんでしかわからないことが大半です。
で、テストまでにマスタが手に入らないと、テーブル設計者の意図を元に
てきとーなデータを自前で作成してテストすることになりますが、
仮にこれでテストが通ったとしても、運用間際になって、思ったように
動かなくなること間違いありません。
>マスタ以外のデータの準備
移行元のデータがあるのであれば、こちらもプロジェクトの早期の段階で、
移行ツールをつくって、動かしてしまいましょう。
個人情報等の問題がうるさくなってきたので、以前よりも注意する必要は
あるのですが、それでも「早く実データを手に入れる」というのは
かなり重要です。
例えば、細かい仕様の考慮漏れに気がついたとき、運用上の実害がなければ
無視して先に進める、というのはよくあるハナシですが、
本当に無視して大丈夫なのか、手を止めて再実装すべきか、という判断が
圧倒的にラクになります。
また、性能テストでは、実データはほぼ必須です。
理論上の数値に基づいて、大量の手作りデータを用意すのは大変です。
値の分布がちょっとでも違うと、例えば DB の index の access path が
変わったりしてしまいますので、手で作るときは相当念入りにモデリング
しなくてはいけません。つーか、不可能です、そんなこと。
次回、最終号!
連投その4 (スコア:1)
プロジェクト管理に関心があるのであれば、下準備の構想を練るのは
楽しい仕事ですが、検証作業をするところまで考えると、自分ひとりでは
時間がいくらあっても足りません。
プロジェクトの規模にもよるところですのでなんともいえませんが、
片腕となるメンバーを確保する、検証チームを立ち上げる、もしくは
自分で検証したいので、代わりのブレインを呼んでくる(笑)、など、
必ず誰かを巻き込んでいきましょう。
でないと、
私みたいに、今日も明日も出勤するハメになります(--;
メンバーのスケジューリングも重要ですが、ご自愛くださいませ。
Re:連投その2 (スコア:1)
ご自身が体験されたことをベースにしているので、とても参考になります。
その中でいくつか返信を。
文字列のトリムは、基本的にString#trimでいいはずです。なんらかの理由でString#replaceAllなどで特定の文字の置換を行う必要がある場合は、これらのStringに実装されているメソッドを用いるのではなくjava.util.regex.Patternのコンパイル済み正規表現を用いた方がパフォーマンスはいいかと思います。
Stringの実装をみていないのではずしているかもしれませんが、内部的にはPatternを毎回生成してMatcher#replaceAllを呼び出しているはずです。
置換対象が同一ならばPatternの生成を毎回行わなくてすむためインスタンス生成コストがかからないため速いはずです。
とくに何もなければWindows-31Jかな、と思っています。ただし、ins13さんの指摘のようにUTF-8からWindows-31Jへの変換で使用されるCP932にはおかしな場所があるため、個別で置換ロジックを書いて対応する必要があります。
今回、これで文字化けが発生し難儀なことになりました。