« 2005年10月 | メイン | 2005年12月 »
2005年11月28日
windowsのログイン画面をFlashに！
他とひと味違ったデスクトップカスタマイズを行いたい方に朗報です！
windows のログイン画面を Flash にすることが可能なツールをご紹介。
最初は半信半疑でおそるおそる使ってみたのですが、ログイン画面がFlashアニメーションで動くわ動くわ。
このツールでは５種類のログインFlash画面が用意されています。
swf -> fla -> swf という技術を持っている人ならオリジナルログイン画面も作れてしまいます。
もちろんその場合動作保証なんてされませんけど、私のところではフォント変えたりうさぎのアニメーションを入れてもきちんと動作しております。
ツールのダウンロードは下記のサイトからどうぞ。
http://cowscorpion.com/Desktop/FrontMotionLogin.html
投稿者 すなうさぎ : 02:09 | コメント (0) | トラックバック
2005年11月06日
YAMAHAのHPがFlexな件について
久しぶりにYAHAMAのホームページに訪れてみた。
2年前 YAMAHAのページにインスパイア(※1)され、いつか自分もこのようなページが作れたら良いなと思っていたが、ソースファイルをみるとなんかFlexの香りが・・・。
個人でFlexなんて買えるかいっ！
年内に私が運営している浪漫屋ぽぽたんとこのページを統合しリニューアルを図ろうとしているのだが、さてFlash + XML でどこまで近づけられるか・・・。
※1 インスパイア (Inspire : 気持ち｛きもち｝を強く動かす)
意訳として「物まねする、盗作する」といったニュアンスがある。しかしながら真似するでは響きが悪いのでインスパイアを使う場合が大人の世界ではたまにある。
この記事を書いた後で友人とよくよくソースをみてみたらJavaScriptが２重で読み込まれており、その中でindex.swfが記述されていました。
Flexじゃなかったよ。とほほ。
投稿者 すなうさぎ : 06:28 | コメント (1) | トラックバック
2005年11月01日
続 JavaBeans
以前の記事でJavaBeansは情報のカプセル化を行うクラスだという記事を書いたが、偉い人の話によると、ただ情報をまとめるだけにJavaBeansを作成するのはソフトウェアの保守性と可読性の観点からやってはいけないことらしい。
JavaBeansは業務ロジック単位で考え、JSPが扱う情報をまとめておくようにすることで保守性の向上見込まれる。
さて、今処理 Z を考えたときに必要なデータを ZBean にすることを考える。
まず、DAO (Data Access Object)に注目すると返値として XBean , YBean を持つメソッドはある。
ここで XBean , YBean から ZBean へデータ引き渡す事によってその場しのぎのバータリーな処理を行うことが出来るが、もし機能拡張や複雑な処理に変更しようとしたときにソースコードが少しずつ改悪されていくに違いない。
なぜなら仕様変更によって処理 X , 処理Yが更新された場合、処理Zに影響を及ぼしてしまうからである。
なので、 ZBeans は XBeans , YBeans と同じ情報が入ったとしても Beans から Beans の受け渡しを行ったりしないほうが保守性に優れる。
DAO においても同様のことがいえる。同じ情報が必要だからと行って、同じメソッドの使い回しを使い回すのではなく、業務ロジック単位で考えた方が保守性に優れるだろう。
可読性の低下についていえば、処理Zを行うためにXBeansとYBeansを展開したり、セッションを2つにすることによりソースコードを追いづらくなったり、そもそも必要な情報を2つの器(うつわ)から流し込むよりも、一つの器にまとまっている方が理解しやすいということか。
投稿者 すなうさぎ : 03:19 | コメント (0) | トラックバック
POJO
偉い人が POJO という単語を口にしていたので調べてみた。
正式名称 : Plain Old Java Object
Javabeansと同義(?)
答えっぽい記事みつけました。
英語ですが・・・・
http://martinfowler.com/bliki/POJO.html
内容は、ビジネスロジックをJavaオブジェクトに入れたほうが、Entity Bean を使うよりもメリットがたくさんあるらしい。
で、ビジネスロジックをいれたBeanをPOJOと呼ぼうじゃないか。
と、いう感じでしょうか。(逆かもしれません)
POJOがしめすアプリケーションの形
http://www.arclamp.jp/blog/archives/000474.html
引用
POJOを、もう少し詳しく定義するなら、「自分がするべきことに対して最低限しか知らないオブジェクト」、さらに「実行環境やフレームワークのことは一切知らないオブジェクト」といえるのではないか。
他のオブジェクトへの依存性を極力無くしてあげている。ということはモジュール強度が低い？
最近Beanのなかに違うクラスのBeanを突っ込んだりする作業をして気持ち悪さを感じているのだが、さてどうしたものか。
結局POJOはよくわかりませんでした。まだまだ精進が足りないようで・・・