64bit環境への挑戦と、Adobe CS4 と FlexBuilder 3の環境で Flex Builder の更新ができないことへの対処

FlexBuilder Adobe Vista

なんかタイトル長くなった。

昨日から引き続きアプリを少しずつインストール中。ちなみに OS は Vista 64 bit。初の64bit体験。

Adobe CS 4 をインストールした後で Flex Builder 3 をインストール。
Flex Builder のデフォルトのバージョンは、Ver 3.0（ビルド 3.0.194161）
最新版の Ver 3.0.2 がリリースされているはずなので更新しなくては。

「ヘルプ」 → 「Flex Builder の更新を検索」
を選択しても何も起きない。Ver 3.0.2 自体は Download Creative Cloud apps にあるんだけど、上書きでいいのかよくわからない。

Adobe - Flex Builder 3 Release Notes
によると、 Flex Builder の更新の検索が動作しないのは、Adobe Update Manager
が自動的にインストールされていないから、とある。
CS4のAdobe Updaterは Ver 6と推測される。（ファイルの保存先が Adobe\Update6\Install だから）
環境設定を見ると、対象アプリに Flex Builder は含まれていない。
Flex Builder用に別途 Adobe Updaterが必要ということか。
上記サイトに従い、Flex Builder 3 フォルダの、\AMT\AdobeAUM5.1All.win.installer\Setup.exe を実行。

Adobe Update Manager CS3というプログラムが起動。
後から古いバージョンのアプリインストールして大丈夫かな。
インストールは完了。いざ更新！

起動したー。

完了後バージョン確認

無事 3.0.2 更新完了です。Flex SDK 3.2.0 もインストールされたようです。これで Flash Player 10、AIR 1.5 に対応となるわけですね。



最後に64bit環境に関しての現時点での感想。

まだアプリ類は入れはじめたばかりの段階ですが、32bit用のアプリもほとんど問題なく動きます。
WOW64 という機能があって、32bit 環境をエミュレートするので結構大丈夫です。注意すべきなのはデバイスドライバ類などのハードウェアと密接に関わるものくらいかもしれません。（WOW64に関しては開発者ならPart 1. 64 ビット Windows OS の基本知識 必見です。）

64bit 対応ソフトの具体例としては soft - Windows Vista Wiki がとても詳しいです。Wiki形式の強さを実感。まさに集合知。

というわけで 64 bit 環境恐るるに足らず！このまま突き進むべし。


なんていいながら少しつまずいていたりもして。あと若干の不安も列挙。
・オーディオインターフェースとしての KORG ZERO 8 は現時点で 64bit 未対応。（OS対応状況 | KORG (Japan) ）代替案考え中。
・もうすぐ発売の Cubase 5 は64bit正式対応なのだが、VSTプラグインらはほとんど32bitなのでそれが正しく動作するか。ハードウェアに近いものなので結構シビアなのではないか。そのため Cubase自体が32ビットエミュレート機能を搭載してたりするので（Cubase 5 - Windows Vista 64bit 版について）余計に不安が増す。まあ試してみないと何ともいえないけど。噂では、Stylus RMX が厳しい、とかとか。

マシン不調。Disk エラー関連

PC Vista

定期的に書かれるマシン不調ネタ。

Vista 新規インストール
↓
インストール後、再起動すると、Disk IO エラー。
↓
Vista のDisk 入れて修復
↓
修復は完了するが、再起動するとまたエラー。
↓
Windows XP、Vista 32bit、Vista 64bitで試すも同様。
↓
HDDの故障かな、ということで新たにHDD購入。
↓
Vista 64bitインストール
↓
インストール完了。とりあえず再起動。
↓
Windows を開始できませんでした。
ファイル：\Windows\system32\ntoskrnl.exe
状態：0xc00000e9
情報：カーネルが見つからないか、または壊れているため、Windowsの読み込みに失敗しました。
↓
次の画面でメモリテストが出来るみたいなのでテスト。異常なし。
↓
VistaのDisk入れて修復
↓
修復完了。しかしまた再起動後エラー。
↓
Vista の自動修復に頼るのはやめよう。修復→コマンドプロンプトから
bootrec /fixmbr
処理完了
↓
再起動、再びエラー。同様に ntoskrnl.exe が見つからないか壊れている。
←今ここ

というわけで、疲れた。もともと、HDD買い換え前のDisk IOエラーって、ハード的な障害ではない可能性の方が高いので、HDDを買い換えるという策が正しかったとは思わないが、ここまで嵌るともう訳が分からない。

C# で高階関数的な、関数ポインタみたいな（Func でメソッドを切り替える）

C#

ひさしぶり。


こういうことってよくあると思います。

　　前処理 hoge
　　処理 A
　　後処理 fuga

　　前処理 hoge
　　処理 B
　　後処理 fuga

　　前処理 hoge
　　処理 B
　　後処理 fuga

それぞれ前処理と後処理は同じことをやっている、というものです。プログラミングの基本として、共通する部分は関数としてまとめる、というのがありますが、この場合処理の中身が異なるのでそういうわけにもいきません。

関数型言語に高階関数というのがあります。（高階関数 - Wikipedia） まさしくやりたいのはこういうこと。関数型言語では引数に関数を渡すことが簡単にできると。
C言語の例が載っています。関数ポインタで実現させているんですね。

C# で関数を引数とする、で思いつくのがデリゲート。これを使えば実現できそうです。
でも個人的にはデリゲートだと宣言の部分などが冗長という印象があって、そこまでやること無いか、と日和ってしまいます。


そこで、C# 3.0 の　Func というのを使います。

使用前

    static void Main(string[] args)
    {
        Console.WriteLine("前処理");
        Console.WriteLine("{0}", add(2, 3));
        Console.WriteLine("後処理");

        Console.WriteLine("前処理");
        Console.WriteLine("{0}", mul(2, 3));
        Console.WriteLine("後処理");
    }

    private static int add(int x, int y)
    {
        return x + y;
    }

    private static int mul(int x, int y)
    {
        return x * y;
    }

使用後

    static void Main(string[] args)
    {
        process(add);
        process(mul);
    }

    private static int add(int x, int y)
    {
        return x + y;
    }

    private static int mul(int x, int y)
    {
        return x * y;
    }

    private static void process(Func<int, int, int> calc)
    {
        Console.WriteLine("前処理");
        Console.WriteLine(calc(2, 3));
        Console.WriteLine("後処理");
    }

新たに、process というメソッドを追加しました。これは、
1. 前処理を行う
2. 引数で指定させたメソッドを実行する
3. 後処理を行う
ことを行います。使用前のソースでは2カ所に分散していた前処理と後処理をまとめたことで、もし前処理、または後処理に変更が生じても一カ所の修正ですむのでミスも減ります。
一番大事なのが、 2の「引数で指定されたメソッドを実行する」です。calc(2, 3) とありますが、これでadd、mulが実行されるのです、あら不思議。process メソッドの宣言部を見てみましょう。

    Func<int, int, int> calc

MSDN によると Func とは、
1 つのパラメータを受け取って TResult パラメータに指定された型の値を返すメソッドをカプセル化します。

    public delegate TResult Func<T, TResult>(T arg)

とのことで、これだけだと何のことやらですが。

つまり、Func calc は、
「int 型の引数を2つ受け取って、戻り値が int 型であるというメソッド calc の宣言を宣言する。」となります。
Func の後に int が3つ並んでいますが、最後の int がTResult、すなわち戻り値を意味しています。
あとは、main の部分から、

        process(add);
        process(mul);

と、切り替えたいメソッド（add、mul）を渡してあげることで見事に切り替わってくれる、と。


シンプルですし、実務的にも役立つ場面あるのではないかと。

後書き

実行したいメソッドを切り替えたい、という意味ではデザインパターンのStrategyパターンがふとよぎったり。
あれは継承（またはインターフェース）によって実現させていますが、C# 3.0ではFuncを使うというのもありなのかな、とか。（いや、やんないけど。）
Generics によって、intの引数を2つ持ち、戻り値が int であればなんでもcalcに渡せるわけで、インターフェース継承などよりもより柔軟なことができるんだな−、など今さら Generics の力を思い知る。

map、reduce、リスト内包表記

python

「言語は思考を規定する」とはよく言ったもので、特定のプログラミング言語ばかり使っていると、いつのまにかその枠内でしか考えられなくなってしまう。異なる言語に触れることで違う方向からの視点みたいなものがあることに気づいたりする。

今回 Python を少し触ってみた。

配列のそれぞれの要素に対して何か処理を行う場合、普通は for や foreach などでぐるぐるループするのが当然と思っていたが、Pythonによってその固定観念が覆された。


1〜10までの値を持つ配列に対し、それぞれの値を2倍にする。

>>> map(lambda x: x * 2, range(1, 11))
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]　　← これ結果

map という命令で第二引数の配列に対し、第一引数の関数を適用する。なんと１行で書けてしまう。lambda を使うことより適用する関数（この場合2倍にするという内容）を宣言なしで入れ込むことで短くなった。

さらに、配列の要素を走査して何らかの結果を求めたい場合は reduce という命令を用いる。
１〜10の合計値を求める。

>>>reduce(lambda a, b: a + b, range(1, 11))
55  ← これ結果

という具合。


さらに、リスト内包表記というのがあって、配列定義時に条件式を用いることができるというものなのだが、これを使うとさらに短くなる。


1〜10までの値を持つ配列に対し、それぞれの値を2倍にする。

>>> [x * 2 for x in range(1, 11)]
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]  ← これ結果


Python なかなかやるじゃん、と見直しました。



※参考ページ
http://www.python.jp/doc/release/tut/
Python の map, filter, reduce とリスト内包表記 | すぐに忘れる脳みそのためのメモ

アルシャードff リプレイ 時計仕掛けの破壊神

本 TRPG

私はたぶん物語が好きである。
TRPG（テーブルトークRPG）というジャンルのゲームがある。複数人で紙と鉛筆とサイコロを使って行う卓上ゲーム。GM（ゲームマスター）と呼ばれる人が物語を作成し、その他のプレイヤーはその物語上の役割を演じながら冒険を繰り広げる。細かい解説は テーブルトークRPG - Wikipedia にまかせるが。

TRPGなんてもう10数年やっていないのだが、当時はひたすらGM役をやらされた。自分で作ったストーリーが受けるとそれはそれで嬉しくて、一時期かなりはまっていた。


本屋で本書が目にとまり、そういえば最近のTRPGってどうよ的な興味から購入。

アルシャードff リプレイ 時計仕掛けの破壊神 (ログインテーブルトークRPGシリーズ)

アルシャードff リプレイ 時計仕掛けの破壊神 (ログインテーブルトークRPGシリーズ)

本書はTRPGの「リプレイ」と呼ばれるものである。実際にTRPGをプレイしている様子を実況中継風に文字に起こしたものである。ゲームをプレイしている様子が本になるという摩訶不思議な文学ジャンルではある。


TRPGには物語の原形が残されていると思う。シンプルが故に純粋なのか。プロットが頭の中で図式化されて実に気持ちよい。
・主人公の出自の謎
・依頼者から任務の依頼
・出発
・移動
・仲間を得る
・格闘、勝利
・帰還
みたいな。なんかドラクエから桃太郎まで使えそうな構成ですが。言い換えれば、物語というのは多かれ少なかれ共通した基盤を持つということです。もっと言えば人間はこのような構成を物語として認識するというか。


物語とは、ということに興味を持ったのならこの本なんかお薦め

ストーリーメーカー 創作のための物語論 (アスキー新書 84)

ストーリーメーカー 創作のための物語論 (アスキー新書 84)

大塚英志は何冊も物語論、キャラクター論関係の本を出していますが、本書が最新だけあってもっとも洗練されています。いくつかの質問に答えるだけで自動的に物語ができあがる、というHow To本となっていますが、ちゃんと読めば、物語の構成要素に関しての理論的な本だと分かるでしょう。


ああ、物語っていくつかのパターンから成り立っているんだな、とさらに興味を持った方は古典的名著
昔話の形態学 (叢書 記号学的実践) まで手を伸ばしてみてはいかがでしょう。1920年代に書かれた本です。古今東西の神話、民話が似ているのはなぜだろう。という疑問に端を発し、物語は31の構成要素を組み合わせることで作られるという理論を提唱した本書。物語論を語る上では外せません。


最近の物語論の本で気になっているのは、

可能世界・人工知能・物語理論 (叢書 記号学的実践)

可能世界・人工知能・物語理論 (叢書 記号学的実践)

難しくてなかなか読み進めていないのですが、なぜSF、ファンタジーのような架空の話が成立するのか、ということを「可能世界」と考え方のもとに考察しているっぽい。序盤から論理学の本を読んでいるようで辛いのだけど、図が多いのでいろいろ刺激になります。いいこと書いている予感はするので読み進めていきたい。


てな感じでどうやら自分は物語が好きらしい。

LINQ to SQL と Entity Frameworkの今後

.net LINQ

Linq to SQLが死滅するようです。って当然じゃん。 - ものがたり(旧)
とか
http://www.isisaka.com/blog/archives/2008/11/linq_to_sql.html
を見て一瞬愕然としてしまったが、落ち着いて考えると当然の帰結なのかもしれない。そういえば
LINQ to SQLをオープンソースにする必要性
の時点で気づくべきで。


個人的には、あ、そうですか、て感じで興味の対象を Entity Frameworkの方に振り向けるのに何のためらいもないのですが、Entity Framework自体どうなのよ、という先入観があって。なんかあれができない、これができない、と言われると、「それは v2で対応します。」的なことを言われたり。そうなると現在のv1を触る意欲がなくなってきて。でもこういう状況なら、もう一度がんばってみる。


個人の問題はどうとでもなるからいいんです。ここ一年くらい、周囲に、LINQはいいよ、LINQ to SQL はすごいお手軽だよ。みたいに布教活動してきたんですが正直なかなか広まらなくて。かろうじてLINQ to SQLでのシンプルなコーディングに反応してくれる人がいるくらいで。これが Entity Framework となるとさらにハードルは上がるわけで。

「えー、Entity Frameworkというのは、つまりマーチン・ファウラー氏のPOfEAA言うところのドメインモデルに相当するものでありまして･･･」
駄目だー。どん引きの聴衆の姿が目に浮かぶ−。

将来を見越せば、ドメイン中心、モデル中心的な考え方は大事なはずで。それを実現する Entity Framework は必要な技術でしょう。ただその思想をプログラマ全員に浸透させる自信が自分には無いです。


そんな風に悩んでいると、
ORマッパーとか | 眠る開発屋blog
のような意見にも「そうだよな、SQL直打ちすればいいじゃん。SQLそんなに難しいものではないし」とか180度逆になびいたりもして。


そんな風に落ち込んでいると、Amazonからおすすめメールがやってきて、なんと

Programming the Microsoft® ADO.NET Entity Framework (PRO-Developer)

Programming the Microsoft® ADO.NET Entity Framework (PRO-Developer)

ですよ。何というタイミング。いわゆる衝動買いです。ポチりました。発売来月だけど。


とりあえず現状の Entity Framework でどこまでできるのか触ってみることにする。