634の適当日記

ヤフー(4689)株のはなし

うししし。
10株くらい買っておけばよかったねー。

通信簿のはなし

ブログ通信簿サービス

こういう単純なサービスほど、すばらしいと思います。
速度的に結果キャッシュしてないのかねー。と一瞬おもったけどそんなわけないか。

がんばってJavaでトレーダーを目指したいと思います。

IPO運試しのはなし

ベンチャーリパブリック応募。あたれーあたれー

仕事のはなし

ここ数ヶ月はサブシステムごとに作った会社が違うシステムのメンテナンス・機能拡張をずーっとしてて、今日は中国にオフショアしてコスト削減している会社が作ったとこに突入。
変数名のスペルミス、規約違反、超適当なコードフォーマット、ひどすぎるクラス設計、あとなんだろう。とにかくいいところがひとつも見つかりません。大まかなリファクタリングも不可能なので、泣く泣くがんばるしかありません。
で、今日は、午後3時くらいに燃え尽きました。ちーん。

ゆうがたのはなし

わーなんだこれ、昼じゃん！

ヤフー株のはなし

今日の午後、ヤフーの株買った気がする。ちょっと記憶があいまいだけど。

追記
やっぱ買ってた。37,250円約定。1株！！！！
1株て…ヘタレすぎる。どうでもよすぎ。
選んで買うなら買い時かもねー。選んでる時間ないけど。

IPOのはなし

ちくしょーまた落ちた。IPOてどうやったら当選すんだ。

mojaviからsymfonyへ…のはなし

WEBアプリケーションフレームワークのMojaviが好きだ。
Strutsのように、すっかり古典的なフレームワークとなってしまったけれど、メンテナンスもしやすいし、アプリケーションロジックの部分は何にも依存していないのもとてもいい感じ。

mojaviといえば、公式サイトが度重なるサーバダウンで壊滅状態になった後にMojavi4（次バージョン）の開発中リリースと共に復活を遂げたと思ったら、そのままサイトが放置状態になって今はなにもなくなってしまった。という、いかにもへなちょこな歴史がとても懐かしい。

踏ん切りのつかないまま、Mojaviの開発がまた始まることを祈りつつ、Railsの波に乗って華麗に登場したSymfonyを「仕方なく」使い始めたのだけれど…なんか似てるとおもったら！！
うおー　symfonyてば　mojaviの派生じゃないか！！！！
そういうことは、ハヤク言え。

というわけでsymfonyにぞっこんになったので、mojaviとモデル生成アプリは2年間の過酷な労働を終え、おいらにポイっと捨てられたのでした。

ポイっとすてられたはちょっと違うか。安めのレンタルサーバーだと割とphp4が標準なので、もう少しがんばってください。しんふぉにーが動かないので。

ファニーメイとフレディーマックのはなし

市場はFRBによるフレディーマックとファニーメイの救済策の話題で持ちきりですが、今日の日経平均は終値-29.53(-0.23%)と続落して終了。
なんじゃこりゃ。

複雑なSQLのはなし

150行くらいの割と複雑なSQLに50行くらい新たに追加しました。とても疲れました。

最近の若いモンはSQLもロクに書けん！と熟練さんは言います。まぁ大体同意なんだけれども、うちくらいのたかが利用者1,000人くらいのチンケなスケールのシステムで複雑なSQLを修正してあんなに神経使うのなら、単純にゴソっと取ってきてロジックでまわしてもいーんじゃないかと思う。

でも気合入れて書いたSQLは、やっぱり高速なので困ってしまいます。

今週の株のはなし

日本の株価ボラリティ高すぎて全然ついていけません。というか、ついていく気もないんだけど…売買しないのもちょっとタイクツです。
なんてったって、現金保有率８０％だからね。どこのヘタレ老人だ。

土曜日のはなしー

子だくさん！

nissen(8248)のIRのはなし

今日のニッセンホールディングス(8248)の業績予想、純利益予想が「０円から１２億円」って…こんなIR出していいんだっけ？初めて見た。

株といえば、最近は日経平均９連敗くらいのときに買い参戦して次の日早々にロスカットしたくらいで、今はポジションなしに等しいので最近の市場観察はとても楽しいです。

今日の格言
気をつけろ、あなたが売った、そこが底。

メンテナンスの現場のはなし

今の時代にメンテナンス目的で現場に入ると、稼動してから５〜１０年くらいのシステムに出会うことが大半です。これくらいの時代に構築されたシステムだと、ほとんど共通しているのは…
・ログが出ない。
・フレームワークが中途半端
・自動テストがない
・コーディングスタイルがバラバラ
・データベースアクセスクラスは自前で実装
・共通クラスは共通化されていない

あと、ほとんどじゃないけれどよくあるパターンは…
・ドキュメントがない。または適当。

たいてい最初にやるのは、フレームワークとデータベース管理クラスのクラス図を紙に書くこと。それが終わったら、処理の入り口の部分にクラス名を出力するログを書きます。処理の入り口が統一されていない（strutsでいえばすべてのアクションクラスの継承もとが、純粋なActionクラスになっている）場合は、この時点で統一化しておきたいです（同じくstrutsの場合だと、アクション実装クラスとActionクラスの間に独自のActionクラスを挟む）が、後述の理由によりできないことも多々あります。ロギングシステムがない場合は、この時点で導入しておきます。早ければ早いほどよし。

log.debug("実行クラス：" + this.getClass().getName());

これで、「アクション一覧」のようなめんどくさい外部リソースをいちいち探す必要がなくなります。動いているアクションクラスを知りたい場合は、動かしてeclipseのコンソールで確認します。

続いて、共通クラスを”本当に”共通化させたり、コーディング基準を設けて標準化したり、ソースコードコメントをきっちり書いたり…したいのだけれど、メンテナンス段階になると、ソースコード修正にはっきりとした費用対効果を示さないと上の人（？）からOKが出ないので、たいていは不可能です。費用対効果、費用対効果、費用対効果。何度も言われる台詞です。
そこで、何かしらの修正に乗じて全体的に統一化したり、ついでに修正したりします。修正対象になったソースコードに対しては、Eclipseでフォーマットかけた後に、FindBugsとcheckstyleを実行して、警告を全て解決して初めてリポジトリにコミットします。

メンテナンスをしたことのない開発者が思い浮かべている保守性・可変性というのは、ちょっとずれているように感じます。

インディージョーンズ大ヒット！のはなし

今日は仕事はお休み。
インディージョーンズの新作、クリスタル・スカルの王国を見ました。
あのベタベタで突っ込みどころ満載のアクションがサイコー！
すげー楽しくってニヤニヤニヤニヤしながら映画見てました。