雑記帳 2006年 3月第1週

• Project junmix
• 雑記帳
• 2006年
• 3月第1週

2006/03/01 Wed.

2016/01/09 追記
消そうかなーとも思ったんだけど、基本給が変わらない会社の存在を周知するためにも残しておきます。

2月24日振り込み分の給料明細。4月で給料上がるのかこれ？どう見ても糞会社です。本当にありがとうございました。
文言が1月29日の雑記の出だしと同じっぽい感じもするけど、ここは気にしない方向で。ってか、控除額って多すぎだろ。
自分はまだ生命保険入ってないんだけど、加入したらしたでさらに月額8,000円くらいの出費が増えてしまうワケだよな。
月あたりの出費が1月も2月も大体7万円程度だけど、実際はこれよりもう少し多いかも。メモってないのもありそうだし。
ってことは、一ヶ月で貯金できる金額がちょっと少なく見積もって12万ってとこか。ありゃ、それって年間で240万？
どう見ても今の貯金額と釣り合ってないな。給料に大した変動は無いし、3年間も年間240万ずつ貯めてたら720万だぞ。
30歳までに1,000万くらいを貯められればいいと考えているけど、途中で家を出たりするのもあるだろうし無理っぽい。
ああ、そうだ。一昨年も去年もボーナスが皆無同然だったんだよな。そりゃ貯金ペースも変わってくるはずだわな。
ってか、冷静に考えてみると、ボーナスが出たとしてもカス同然の金額である以上、貯金のペースは結局変わらないか。

2006/03/02 Thu.

どう見ても自分は数学どころか算数すらできていないようだ。何で月あたり12万の貯金で年間貯金額が240万になるんだ。
さすがは数学の最高偏差値が25なだけあるな。公立高校の入試の数学で大問1以外は解けない事実が証明されてしまう。
年間144万ってことは、3年間で432万か。1,000万貯めるには7年ってとこか。30歳までにはギリギリ達成可能なペース？
でもそれって給料に変更が無い上に、家を出ることもないという前提での話だよな。まぁ、どうなるかはわかりませんが。

さて、2月15日の雑記で書いてる性能改善の話。今日になってあれが超大嘘だったことに気付いた。ってか凡ミスだし。

//    「~」区切りでトークンを生成
StringTokenizer stk = new StringTokenizer(request.getParameter("SaveParameter"), "~");

この時にパラメータの文字列長が多いとインスタンスの生成が遅くなるって書いたけど、どう見ても手抜き文章だった。

//    「~」区切りでトークンを生成
String str = request.getParameter("SaveParameter");
StringTokenizer stk = new StringTokenizer(convertToken(str, "~"), "~");

public String convertToken(String sText, String sSplit) throws Exception {
    String sOutText = new String();
    String sTmpText = new String();
    String sTmpTextPrev = sSplit;
    int iLength = sText.length();
    try {
        for (int i = 0; i < iLength(); i++) {
            sTmpText = sText.substring(i, i + 1);
            if (sTmpTextPrev.equals(sSplit) && sTmpText.equals(sSplit)) {
                sTmpText = " " + sSplit;
                sTmpTextPrev = sSplit;
            } else {
                sTmpTextPrev = sTmpText;
            }
            sOutText = sOutText + sTmpText;
        }
        return sOutText;
    } catch (Exception e) {
        return null;
    }
}

正確にはこのconvertToken()というメソッドを通した文字列をStringTokenizerのコンストラクタの引数に指定してる。
StringTokenizerのコンストラクタの第二引数に指定する区切り文字に関する処理を行うメソッドって感じか。
区切り文字が連続した文字列は、StringTokenizerはトークンとして見なしてくれない。そこで使うのがこのメソッド。
トークンの数が一定として処理を行う場合、StringTokenizerは一歩間違えるとNoSuchElementExceptionを引き起こす。
これを回避するために、区切り文字が連続している部分の間に半角スペースを入れてトークンと認識させるワケです。
で、このconvertToken()に渡す文字列長が多いと時間がかかってしまっていたワケ。当然ながら、Javaに罪は無いな。
しかもタチが悪いことに、渡す文字列長によっては処理にかかる時間が指数関数的に増加する。パフォーマンス最悪。
渡す文字列長が20KBくらいなら数秒で終わるのだが、600KBとかの文字列を渡してみると40分くらいかかる。アホかと。
そんなワケで、このメソッドを使わないように修正。NoSuchElementExceptionが起きないように予め対策を講じる。
一切改善を行っていなかった一連の処理では46分13秒くらいかかっていた処理が、今度は2分40秒にまで改善できた。
これは2つのJSPの処理の合計時間だが、肝心のconvertToken()修正をした方だけ見ると、43分が13秒にまで速くできた。
43分を13秒で割ると、今回のケースでの性能改善率は19,800%になった。簡単に言うと198倍速。俺もアホだったんだな。
このメソッド内で文字列を連結している「sOutText = sOutText + sTmpText;」の部分をconcat()にすれば速くなるか？
Stringの文字列連結には色々方法があるけど、一般的に使われている「+=」の性能は相当悪いということもわかった。
「文字列を連結させるには何が適切か！」というページでも言われているけど、やはりStringBufferを使うのが賢い選択か。

2006/03/03 Fri.

性能改善の目処も立ったし、今度はそれに関連して変更になるJSPの動作を詳細設計仕様書にまとめなきゃならん。
次のリリースが3月27日くらいだった気がするので、時間的には余裕がありまくる。一応簡単にまとめておきますかね。
んで、何が嫌かって他の機能の修正で人手が欲しいらしい。どう見ても自分以外に目を付けられる対象がいない。
もちろん週末が近い金曜日なんかにやる気が出るはずもないので、適当に仕事をしている振りをして過ごすことに。
そもそも睡眠時間が足りてないから、今日は頭が回りません。昨夜は遅くまで色々なPV見てて、気がつけば3時過ぎ。
今まであんな方法やこんな方法でPVを手に入れてきたけど、今じゃFlashでPV見る時代になってきたんですかね。
ちなみに昨夜遅くまで世話になっていたのは「YouTube」というサイト。PVだけじゃなく色々な動画をFlashで配信してる。
もちろん法的なモノなんか知ったこっちゃない系のサイトなんだろうけど、こっちとしてはPV見られればそれでいいんです。
問題はこのサイト自体が非常に重くて、Flashの再生中にもデータの同期が取れずに音が途切れまくったりすること。
「LUNA SEA」のかなり古いライブ映像とかがあったのには感動。EXTASY SUMMITとかはもう忘れられかけてるんだろうな。
「BELIEVE」「TRUE BLUE」「ROSIER」「DESIRE」「IN SILENCE」「STORM」「gravity」のPVとか延々と視聴してたね。
やはりRYUICHIこと河村隆一が一番格好いいと思った時期は「TRUE BLUE」「ROSIER」のあたりかな。ってか若いですよ。
「IN SILENCE」ではエレアコが全編通して弾かれてるけど、思えば自分がエレアコ買ったのはこの曲が引き金だった。
そのエレアコ弾いてるのは当然INORANさんだけど、「SHINE」のPVの一番最後の部分のINORANさんが格好良すぎだ。
やっぱりPV見てるとまたギター始めたくなるな。今じゃストラトもエレアコも酷い状態になってそう。新しいの買うか？

2006/03/04 Sat.

Vodafone、ソフトバンクへの日本法人売却交渉を認める

色々調べてるんですが、「NTT DoCoMo」のSHARP製の携帯でおすすめの機種がありましたら、是非教えて下さい。