■
なんと先々週を最後にジゴロウが引退してしまった・・。
自分を含め大半のサクサカーはジゴロウのあの姿形というか雰囲気を好きって人が多かったとおもう。
そういう意味で本当に残念だった。
番組上ではいろいろな理由をいってたものの本当のとこは著作権がらみの大人の事情らしい。
http://www.kanalog.jp/news/local/entry_8674.html
http://www.dice-k-express.com/cocolog_comment.html
で、先週からは新キャラのヴィンセントが登場。
最初は「ん？」って感じだったもののだんだんと見てるうちに慣れてくる感じであった。
黒幕の空元気っぷりと時たま見せる自信なさげなところと、その他スタッフのサポートっぷりなど、随所でがんばってる感じが伝わってくる感じだ。
なんだかんだ個人的には今まで以上にサクサクを応援していきたいとおもう。
FLASHでチャットをつくってみる つづき
MX2004でさっそくいろいろいじってみたのだが、第１印象として「非常にわかりやすい」と思った。
VBとかを軽く使ったことがあるからかもしれないがGUIの設計とActionScriptとかのコーディングがむすびついてて、勉強すればすぐある程度はわかるんじゃないかなと思えた。
（とはいっても実際相当奥が深いのだろうけど・・）
普段eclipseでせこせことコーディングしてるのと比べるとだいぶ違うなと思った。
eclipseも非常に優れたJava開発IDEだとは思うが、それでもやっぱりJavaはそのあたりが他の言語（ASPやFLASHなど）と比べるととっつきにくい点なのかなと思ったりもした。
J2EEでWEB作る時とか全部うまく動いてじゃないと画面を見れなかったりするのでなかなかつらいところが多い。
でWEBとか参考にしてActionScriptを書いていったのだが、作ってて初めてFLASHの利点を理解した感がある。
単なるアニメーションソフトに毛が生えた程度と思っていたが、やはりリッチクライアントってのは便利だなあと痛感した。
直接的に非常に利点を感じたのは以下の点である。
- クライアント側で値を保持できる
- 画面情報を読み込みなおす場合に、変更したいとこの情報だけとりなおしてくればいい
普段Javaでのweb作成をしてる時とか、ちょっとアクロバティックな画面動作とか実現するのにJavaScriptとかで細かくいろいろやらないといけなかったりで試験も大変だしで苦労するのだが、FLASHだとクライアント側で値を保持したりしてクライアント側だけで処理できちゃうことがだいぶ増える。
あとHTMLだと画面の一情報を読み込みなおす時とか画面自体をまるまる再読み込みして再生成しなおさないといけないが、FLASHだと該当の情報だけの通信でよく、再描画もその項目だけでイイ。
これはこれからの時代来るなと感じずにはいられなかった。
サーバー側のPHPも、PHPは初体験だったがPerlを軽くいじったことがあったのと、サンプルがあったのとで比較的に楽にできた。
これも、コンパイルやらデプロイやら不要だしで楽だなぁ〜と思った。
まあ、これについては大規模な場合は当然その分J2EEのほうが性能などいろいろとメリットはあるのでそれぞれかなと思った。
最終的に細かいバグもあったがうまく作ることができた。
実コーディング量は１００ステップにも満たないだろうがほぼリアルタイムでのチャットが実現でき、HTMLだけでは表現できないような構成も実現でき、非常に満足いくものができた。
普段いろいろとがんじがらめにあってるのがFLASHだと一気に開放された感じで、変な話「夢広がる」といった感じだった。
実際業務でかかわるシステムの場合、端末にFLASHプレイヤーをいれないといけない問題やら、ライセンスの話やら、そう簡単にうまくいくものではないだろうけども、そのうち機会があれば是非業務でもやってみたいと思う。
参考にさせてもらったページ
http://ponk.jp/flash_php/index.php?page=2
FLASHでチャットをつくってみる
仕事ではないのだがwebから使えるチャットを作る機会があった。
当初は普通にレンタルのチャットを借りたりしてみたのだが、微妙に使いづらかったり、何といってもリロードしないと書き込みが最新化されず、リロードの最短も３０秒とかのためいまいちであった。
じゃ単純なCGIとかではなくappletとかのリアルタイムチャット入れてみたのだが、独自のポートを使う（？）ようで、80しか通さない環境の場合使うことができず・・・。
（Java開発してるのになんだが、appletってどうも使いづらいイメージもあって・・）
じゃあレンタルのCGIベースでリロードを３秒とかにできるように改造してみようと思い立った。
でその原型を探してみているとFLASHを利用したチャットについて書いてあるページにたどりついた。
あくまでサーバー上にあるCGI（この例ではPHP）上で行うチャットという点では普通なのだが、ローカル側がFLASHで実現されていた。
「FLASH前からやってみたかったし勉強ついでに試しに」と思いやってみることに。
当然FLASH作成環境などないのでネット上で無料の作成ソフトを探していたのだが、普通のFLASH作成だけなら「parafla」という良さそうなソフトがあったものの、今回のチャットではActionScriptというFLASH上でのプログラム言語を使うようでそれには対応していなかった。
結局ActionScriptに対応したフリーソフトはなさそうなためFLASHMX2004体験版を落としてきて使ってみることに。
続きはまた後日。
シングルトン
以前に性能で問題が出たことがあった。
調べた結果、XMLファイルの読み込み処理が時間がかかっていることが判明。
ファイルを読みにいった際に毎回IOが発生していたためだ。
特に何も考えずに作られていたため当然といえば当然であり、当時はキャッシュさせたりみたいな方法も知らなかったため、非常に困った・・。
その時は仕方なく別のとこにいる有識者の人に意見を求めたところ、「頻繁に更新が入るファイルでない（読み取り専用）のであれば読み込んでメモリ上でキャッシュさせればいい」と意見をもらった。
「なるほど」と思ったもののやり方がさっぱりわからなかった。
そのあたりも教えてもらったのだがシングルトンパターンで実現すればいいということであった。
シングルトンの実装方法などはここでは割愛しますが、教えてもらったとおりに実装してみたところ性能が格段に向上。
それまで普通にコーディングして普通に処理することしか知らなかったし考えてなかったが、それを気に若干だがクラスとインスタンスやメモリに上がってるものが何かというのを意識して処理を作るようになれた。
Cとかやってた人にとってはメモリを意識したりとか普通のことかもしれないけど、JAVAから始めた人だとメモリとか意識してないでも処理ができちゃうため、いざこういう問題にぶつかると困る人は多いんじゃないかなぁと思う。
今となってはそんなことも知らずによく開発してたなと怒られるかもしれないところである。
むしろその時性能でひっかかっておいて良かったな〜と思う。
シングルトンだけでなくデザインパターンは今後も活用していきたい。
ひさびさに
最近しばらく前回の開発が終了し無事サービス開始され落ち着いておりJAVAとは離れていた。
不思議なもので開発中は毎日のようにJAVA関連の調査とかしていたものが完了するとだいぶ変わるものである。
そういう間にも常に前進していける人ってのがやっぱり普通の人とは違うんだろうなあ。
所詮凡人かな。
いまはまた次の開発が開始し提案やらの段階。
幸い（？）その辺の直接な作業は別の人らがやってて、オブザーバ的なポジションにいるので今は結構落ち着いててのほほんとしている。
もうあと１〜２ヶ月後になるとまたじゃばじゃばした日々になるのだろう。
一応次の開発の中でやってみたいと思ってることをメモ的に適当に書いてみる。
- POI（EXCEL、WORDを操作するAPI）・・・EXCELでのファイル出力をやるかも。
- spring・・・ちょっと前から気になってはいるものの調査とかは特に進んでおらず。やはり現在利用しているEJBとの兼ね合いからうまく使えれるのかが不安。
- 開発量を減らすなんらかの方法
３つめの開発量を減らす方法というのは、うちで取り組んでるシステムは基本的に全部似た感じで、あとはいかに業務仕様をのせていくかというあたりがいつも焦点となる。
であればうまく共通化などができれば毎回そんなに作り込む必要もなくなるのではと思う。
ただ微妙にやはり業務仕様が違ってきて結局なかなかうまくいかない・・。
（まあそう簡単に同じにできるのであればそもそも同じシステムになるだろうし・・それが違うから毎回別な開発なわけで・・）
その辺がspringとかである程度うまく解決できないかなあと思ってるところ。
