Software Design 2008/4: SD流 仮想化技術フルコース【セキュリティ編】

すでに発売からしばらく時間が経過していますが、Software Design 2008/4にてSD流 仮想化技術フルコース【セキュリティ編】なる特集がありました。

この特集ではXen徹底入門でもおなじみの宮本さんがXenのsHypeについてまとめられています。

そのほか仮想マシンの運用管理についても記事がありました。仮想マシンの構築や導入についてはたくさんの記事が見つかりますが、今後の仮想化技術に対する関心は運用フェーズのノウハウにシフトしていくと思っているので興味深く、この特集は一気に読んでしまいました。

Flexアプリケーションのロード直後に関数を呼び出す

Flexアプリケーションはイベントドリブンプログラミングの方式なので、Flash Playerによりロードされると事前に定義されたオブジェクトが配置された状態で、ブラウザ内に表示されます。

もちろんこれで初期化が十分ならいいのですが、アプリケーション開始後に実際のコンテンツをほかのURLからXMLデータとしてダウンロードしたい場合など、アプリケーションの開始直後に初期化ルーチンを呼び出したいケースがあります。

このような場合にはApplicationクラスにinitializeイベントがありますので、このイベントハンドラをトリガに初期化ルーチンを起動できます。


Application.initializeイベントのハンドラとしてOnInitialize()を指定する例を以下に示します。

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

    horizontalAlign="center" verticalAlign="center" initialize="OnInitialize()">

OnInitialize()内では、そのアプリケーションの初期化処理を行います。ここではUItimer(Timerクラス)を初期化する例を示します。

private function OnInitialize(): void {

    UItimer = new Timer(100, 0);

    UItimer.addEventListener("timer", OnTimerEvent);

    UItimer.start();

}

MacOS XにFlex SDKを導入

最近ホットなAdobe Flexをいじってみたくなったので、MacOS X 10.4 (Tiger) 環境に Adobe Flex 3 SDK を導入してみました。

FlexとはAdobeのFlashベースの技術で、リッチクライアントの実装などの用途に利用できるプログラミング言語です。Flexで記述したソースコードはコンパイルするとFlashと同じswf形式になり、Flash Playerで再生できます。作る側としてはJava appletに限りなく近いのですが、Java VM上ではなくFlash Player上で動作するため、Java appletより動作が軽快でFlashの特徴を合わせ持ったプログラムを作ることができます。

まずAdobeのサイトからflex_3_sdk.zip (約78MB) をダウンロードしてきます。このアーカイブを展開すると、以下のような構造になっています。

drwx------    8 hasegaw  hasegaw    272 Apr  3 16:57 ant
drwx------    3 hasegaw  hasegaw    102 Apr  3 16:57 asdoc
drwx------   29 hasegaw  hasegaw    986 Apr  3 16:57 bin
-rwx------    1 hasegaw  hasegaw    138 Apr  3 16:57 flex-sdk-description.xml
drwx------   16 hasegaw  hasegaw    544 Mar 31 18:08 frameworks
drwx------   52 hasegaw  hasegaw   1768 Mar 31 18:08 lib
-rwx------    1 hasegaw  hasegaw  33774 Apr  3 16:57 license-adobesdk.htm
-rwx------    1 hasegaw  hasegaw  27786 Apr  3 16:57 license-mpl.htm
-rwx------    1 hasegaw  hasegaw  15261 Apr  3 16:57 readme.htm
drwx------    4 hasegaw  hasegaw    136 Mar 31 18:08 runtimes
drwx------    8 hasegaw  hasegaw    272 Mar 31 18:08 samples
drwx------    9 hasegaw  hasegaw    306 Mar 31 18:08 templates

今回はこれらを/opt/local/flex_sdk_3/に展開し、/opt/local/flex_sdkにシンボリックリンクをはりました。

% sudo mv flex_sdk_3 /opt/local/
% sudo ln -s flex_sdk_3 /opt/local/flex_sdk
% sudo chown -R root:admin /opt/local/flex_sdk_3/
% sudo chmod -R go+rx /opt/local/flex_sdk_3/
% ls -l /opt/local/
(中略)
lrwxr-xr-x     1 root  admin    11 May  3 13:59 flex_sdk -> flex_sdk_3/
drwxr-xr-x    15 root  admin   510 May  3 13:53 flex_sdk_3
(中略)

これでファイルの展開は完了です。あとはFlex SDKのコマンドであるmxmlcコマンド等を実行できるようにパスを通します。とりあえず私の場合は ~/.profile に以下の通り書いてみました。

export PATH=$PATH:/opt/local/flex_sdk/bin

mxmlcコマンドで以下の表示がなされれば、とりあえず利用できます。

mb:~/work/flex hasegaw$ mxmlc
Loading configuration file /opt/local/flex_sdk_3/frameworks/flex-config.xml
Error: a target file must be specified
Use 'mxmlc -help' for information about using the command line.
mb:~/work/flex hasegaw$

MacBook

知人から MacBook を譲っていただいたのを機に、マカーに変身してみました。まだまだヨワヨワですが、少しずつMacへのシフトを進めています。ということで、Macもブログのネタにしていきたいココロ。

ドキュメントは印刷して確認しろ

最近まで、現場のエンジニアや取引先の企業から届くドキュメントの品質の悪さに閉口する日々です。特に某社は、自社内のリビジョン管理がムチャクチャになっていて、ドラフトを平気で成果物として送付してくる始末。送られてきた Word 文書には Excel のシートが貼られていましたが、不要なセルまで含めてペーストしていたため、印刷するととても悲惨な状況になっていました。なんともお粗末です。これがまたいい歳したオッサンなので呆れて何もモノ言う気になりません。プロ意識はあるんでしょうかね？


で、タイトルで伝えたいことは書いてしまったのですが、ドキュメントを提出する際は印刷して確認しないとダメです。ドキュメントは大抵Word/Excelなどで作っていると思いますが、印刷すると、例えばこんなことに気づきます。

• ズームの設定が大きくて、１ページに収めたつもりのページが複数ページにまたがっている（Excel）



• ズームの設定が小さすぎて、印刷してみると読めないような大きさの文字(Excel)



• ヘッダ、フッタの更新漏れがある(Excel, Word)



• スクリーンショットを縮小しすぎて、読めないと困る部分が潰れてしまっている



• セルの高さ・幅がバラバラ、一部のみフォントや文字サイズが異なっているが、画面上では見分けがつかない

お友達との交換日記などであれば体裁はどうでもいいでしょうが、お客様への納品物としてのドキュメントは、先に示すようなレイアウト崩れはきちんと修正した上で出すべきですよね。これらのミスは画面上では確認できないことが多いですから、紙の無駄遣いとか考えずにきちんと紙面に出して確認しましょう。


どうしても紙面に出して確認できない場合は、PDFに変換した上で確認することをオススメします。PDFであれば実際の印刷に近いイメージを画面上で確認できますからね。

PCのハードウェア構成をラクに特定する

本職にて、コンピュータの環境設定（OSを入れ直したり、ソフトウェアをインストールしたり等々）をよく行っているのですが、コンピュータごとに構成が違うため、適合するデバイスドライバを調べて用意するのは、とても面倒で時間がかかる作業です。


昔はいわゆる「自作機」を相手にすることも非常に多かったのですが、最近はハードウェアの調達元が統一され、随分と楽になりました。とはいえ、構成がわらないコンピュータの環境設定作業を行わなければいけないシチュエーションが無くなったわけではありません。


また、調達元が統一されたとはいえ、某BTOベンダのハードウェアでは、同じモデルでもロットによっては搭載されているデバイス（ビデオ、サウンド、NIC）が違うことはしばしば。このような場合にはあたりをつけてドライバを入れてみるとか、1CD Linuxを起動してハードウェア構成を確認するといった方法をとっていましたが、いかんせん非効率的ですし、スマートとは言えません。


そこで Unknown Device Identifier のようなツールを使うと、そのコンピュータ上に存在する PCI デバイスの一覧を表示できます。システムのプロパティを見ても「不明なデバイス」としか表示されないデバイスでも、このツールの表示を見ればすぐに適合するデバイスドライバがどれか判断でき、自信を持って作業できます。


Unknown Device Identifier はインストーラ形式での配布になっていますが、インストール先ディレクトリのイメージを USB メモリなどに入れておけば、 Windows をセットアップしたばかりのコンピュータでも利用できるようです。

LWP::get()を使うコードにキャッシュ機能を付ける

RSSリーダーなブログパーツが欲しい、けど、既存のサービスを使うのは嫌なのでなんとなくフルスクラッチで書いてみることにした。


とりあえず動くようにはなったんだけど、せめてRSSのキャッシュぐらいは実装しておかないとRSSの取得先サーバにとって迷惑だ。なんかないかなぁとCPANをガサゴソしてみたらHTTP::Cache::Transparentモジュールが使えそうなので、早速試してみる。


使い方は、

1. use LWP::Simple の後にuse HTTP::Cache::Transparent する



2. HTTP::Cache::Transparent::init() に設定を渡してモジュールを初期化



3. いつも通り LWP で get() する

らしい。…簡単だー。とりあえず追加してみたコード。

$DIR_HTTPCACHE = '/home/doggie/data/rss_cache';

HTTP::Cache::Transparent::init( {
        BasePath => $DIR_HTTPCACHE,
        Verbose => 0,
        MaxAge => 12,
        NoUpdate => 30 * 60,
} );

HTTP::Cache::Transparent::init() に渡せるオプションはこれだけ。

• BasePath
  　キャッシュ領域として使用するディレクトリ



• Verbose
  　冗長出力するかしないか(1 or 0)



• MaxAge
  　キャッシュが生き続ける最大時間(単位:hour)



• NoUpdate
  　最後にキャッシュが更新されてから、実際のHTTP問い合わせを抑制する時間(単位:second)

一発スクリプトを走らせた後にキャッシュディレクトリを見てみると

doggie@elena:~$ ls -l /home/doggie/data/rss_cache/
合計 28
-rw-r--r--  1 doggie users 26387 2008-03-31 20:27 6b2b2adb261025db95ada29a0f5dd44d

おー、うまく機能している模様。