伏見稲荷の千本鳥居

GW初日は、伏見稲荷大社にピクニック。
のはずだったのですが...山回り２時間って、これはもうハイキングですね。

お稲荷様なので、明神(みょうじん)系の鳥居でした。
「カクレカラクリ」をちょっと思い出します。

人気がはけたところで、慌ててシャッター。

山の頂上近く。登るのを諦める人も多く、写真が撮りやすくなりました。
千本鳥居とよく言われますが、実際にはもっとあるようです（１万本くらい？）。

２頭のきつね様。大切な珠と巻物を咥えています。

結構、迫力のある稲荷神も。

中腹にある辻茶屋の看板メニュー。日本語／英語／中国／韓国語の４ヶ国語での表記になっています。観光事情が伺えます。

おまけ、そのいち。お昼寝の邪魔をしてしまったみたいです。ごめんなさい。でも目があちらの世界にいってますよ。

おまけ、そのに。痒いみたいです。マガモでしょうか？白黒の羽の下に、鮮やかな青の羽が隠されています。

JavaScript の Private メンバ

■問題
JavaScriptの文法上、直接オブジェクトのprivateメンバを指定することはできません。とはいえ、Douglas Crockford氏が「Private Members in JavaScript」で書かれている通り、JavaScriptで privateメンバが実現できないわけではありません。明示的に書けるようにされた方もいます。
しかし上記の方法ではオブジェクトの生成に「new」を使用しています。JavaScriptの「new」はちょっと厄介な仕組みになっていますので、出来れば使いたくありません。

■解案
同じく Douglas Crockford氏の著書「JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス」では、「new」を使用しない仕組みも紹介されています。個人的にちょっと理解し難かったので、その方法を纏めてみました。

    var function createMyObject(inInitArg){
        // 1. Create private members
        var privateVariable = inInitArg;
        var privateFunction = function(){
                    :
                    :
        };

        // 2. Create a new empty object.
        var that = {};  

        // 3. Add propery to the new objet as its public members.
        that.publicVariable = 0;
        that.publicFunction = function(inFuncArg){
                    :
                    :
            // Use Private Members
            privateVariable = inFuncArg * 2;
            var ret = privateFunction();
                    :
                    :
        };
    
        // 4. Return the obuject as MyObject
        return that;
    };

■若干の解説
createMyObject()内の処理は以下の通り。

1. privateメンバとなる変数/関数を定義する
2. まっさらのオブジェクト「that」を作成する
3. 「that」にプロパティを追加してMyObjectのインスタンスにする
4. 完成した「that」 を返却する

クロージャを利用して、createMyObject()関数内のコードからは、private メンバにアクセスできるようになっています。privateメンバの呼び出し時に、「this.」がないのがポイントです。
これで、「new」を排除することができました。(^o^)

■継承
別のオブジェクト(クラスではない！)を継承したいときは、「var that = {};」 の部分を
var that = createMyParentObject();
としてあげれば良いです。

■欠点
JavaScriptの「prototype」機能を活用出来ていません。
複数のMyObjetインスタンスを作成した場合、共通で使えるはずのpublicFunction()関数オブジェクトのインスタンスもその数分、作成されてしまいます。大量にオブジェクトを生成する場合は注意が必要です。

すてがのぐらふぃ

コンピュータを使ったステガノグラフィー(steganography)の入門編にチャレンジしてみました。下の奇妙な英詩(？)の中に、「鍵」が隠されています。

ポイントは b、d、o、p、の４文字です。これらの文字が円形の閉じられた空間を持つことを利用しました。Windowsのペイントツール(mspaint)などで、文字と同じ色で背景を塗りつぶすと、その空間だけが白く残ります。

ということで、結果は次の通りです。

鍵の絵に見ますでしょうか？

Special Thanks :

• 「冗長性から見た情報技術」青木直史(講談社 BLUE BACKS) 

遊びと無駄の境界線

曰く、無駄は排除すべきだが遊びがないとフレキシブルな対応ができなくなる、と。

では、無駄と遊びの違いは何かと言われると、よくわかりません。フレキシブルな対応を可能にするという観点で遊びを定義／分類し、無駄との境界線を考えてみました。

■定義
現実は不確実性に満ちている(事象の確率分布の偏りが大きい、エントロピーが低い)。
その不確実性に対処する方法を「遊び」とする

■分類
(1)現実のシミュレーションとしての遊び
(2)余裕、バッファーとしての遊び

(3)過剰適応防止としての遊び

(1)現実のシミュレーションとしての遊び

ままごと／ゲーム／演劇／スポーツ／小説／映画／etc...
一般的に、エンターテイメントなどと言われるものです。
これまで蓄積されてきた人類の経験や知識である程度予測や対処が可能なものも多いはずです。しかし人類全体にとってはそれほど不確実ではなくても、個々人にとってはかなり不確実なことというのは存在します。それらを効率よく学ぶことができる遊びです。

人間はよくできたもので、遊ぶことによって得られるものがなくなった時点で「飽きる」ようにできています。従って、飽きてもやり続けている場合が、無駄になります。但し遊びからなにが学べるかは、遊ぶ側の能力にも依存するということには注意が必要です(飽きたからといって全てを学べたとは限りませんし、飽きていないからと言って効率の良い学習となっているとは限りません。)。



(2)余裕、バッファーとしての遊び
車のハンドルの遊び／遊び歯車／会議の５分前集合／合流バッファー／CRC／etc...
経験と知識により予測と対処が可能とはいえ、全てを厳密に予測し対処するのは「労多くして益少なし」というケースも多いでしょう。ちょっとしたアクシデントに備えるたて、（えてして脆い）システム間の繋がりを保護したりするために、緩衝を遊びとして設けておくのはよくある手法です。

「ちょっとしたアクシデント」に備える以上の余裕は無駄です。これで間に合わない場合は、遊びではなくてちゃんと仕事として対処しましょう。


(3)過剰適応防止としての遊び

言葉遊び／冒険／基礎研究／イノベーション／etc...

現在の環境に適応すればするほど、環境変化についていくのが難しくなります。

カタストロフィーの回避には、個別には恣意的だが総体的にはランダムな探索が重要です。

ランダムである以上、無駄であることはすでに織り込み済みの遊びとも言えます。やってみなければ無駄かどうかわからない、無駄かどうかは後知恵でないとわからない、とも言えます。

環境変化を考えれば、前にやって無駄だったから今回も無駄、とも限りません。