Ζザクの規格 --- 統一か柔軟か？

昨日、社内の会議で＜ガンダムに学ぶ本＞の話が出ました。（さて、いったい何の会議でしょう ^_^; ）
あいにく未読のため、どの本なのか正確にはわかりませんでしたが、おそらく「ガンダムに学ぶ経営学―宇宙世紀のマネジメント・ケーススタディ」か、「ガンダムが教えてくれたこと　一年戦争に学ぶ“勝ち残る組織”のつくり方」のどちらかでしょう。

で、「確かザクの頭をつけたガンダムがいたなぁ～」と思ってYouTubeを検索してみると、ダブルゼータにでてくるΖザクでした。ここで、ITエンジニアとして気になるのは、やはりガンダムボディとザクヘッド間のインターフェースです。少々問題があるとはいえ十分に機能したということは、連邦軍とジオン軍との間で軍事テクノロジの共通規格化が進んでいたということでしょうか。それとも、少々の規格の違いなどは柔軟に吸収可能なテクノロジが発展していたのでしょうか。現実的には前者でしょうが、後者の解釈の方が好きです。

それにしても、ダブルゼータって、合体ロボットアニメだったのですね... そんなイメージは全くなかったのですが、子供の頃の記憶はアテにならないものです。あっ、でも、ファーストガンダムも真ん中にコアファイターが収まる合体ロボットアニメでした。

リニアモータはなぜ効率が悪いのか？（未解決）

突然ですが、Wikipediaの「リニアモーター」の記事には、

リニアモーターは同規模の出力の回転型電動機と比較した場合、損失が多いため、消費電力が増える。

とあります。が、理由がちょっとわかりません。

自動車や列車は、最終的には直線運動します（つまりリニアに進みます）。回転運動を直線運動に変換する時点でエネルギのロスが発生するはずですので、最初から直線運動のエネルギを得たほうが、よさそうなものです。自動車で普通に使われていレシプロエンジンは、レシプロ運動から始まるわけで、さらに効率が悪そうです。

もっともリニアモータで車輪を回せば、直線運動 -> 回転運動 -> 直線運動 という２段階で変換ロスが発生するのでレシプロエンジンと変わらないのかもしれませんが。

• リニアモータが円運動するローレンツ力を利用しているからでしょうか？
• リニアモータで車輪を回している（円運動に変換している）からでしょうか？
• 磁気浮上式では浮上するのにもエネルギが必要だからでしょうか？

OKWaveに「鉄輪式リニアモーターカー の損失はなぜ大きい？」という質問があがっていますが、良くわかりませんね。原理(理学)上の問題ではなく、現在の技術(工学)上の問題というとでしょうかね？

専門家の方にとっては当たり前で馬鹿馬鹿しいことなのかもしれませんが、素人にとっては謎です。

参考図書：「森博嗣の TOOL BOX」森博嗣(日経BP社)

Ratio or Rate?RatioとRateの使い分け

A 'ratio' is a relationship between two numbers of the same kind, and usually used with the same unit.
On the other hand, 'rate' different.


「ratio」は同種の２数値の関係を表し、、多くは同じ単位で扱われる数値です。
対して「rate」は異なる種類と単位の数値の関係です。

たとえば「このクラスの男女比は２対３だ」という場合、「人間の数」という同種の「人」という単位を使う数値の関係なので、「ratio」を使用します。
また、「ある日の機械の稼働率が80%」というときも、24時間のうち19.2時間稼働し残りの4.8時間は停止しているということで、「ratio」になります。

対して、「１ヶ月に２件の割合でブログの記事を書く」という場合は、期間と件数の別種の数値の関係のため「rate」を使用します。
また、「1ポンド ≒ 0.4536キログラム」のような単位変換の比率も「rate」になります。


た - ぶ - ん ♪

追伸。

何故かGoogleDocsのDrawingからの直接画像取得がうまくできなくなっている。 なので、一端PNG形式に画像保存して貼りつけ。

A little bit extreme way is more stable.極端な方が安定していることもある

In many cases, a little bit extreme way is more stable than balanced one.
バランスのとれたやり方よりも、少々極端な方が安定していることががよくあります。

Balanced:

A Little Bit Extreme:

Which is more stable?
どちらの方が安定しているでしょうか？

伏見稲荷の千本鳥居

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...

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

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

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

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

省エネ奇案#01 ルーフ緑化自動車

ルーフ緑化自動販売機があるのであれば、ルーフ緑化自動車もありかと思ってお絵描きしてみました。

描き終わってからGoogleで検索したら、既に実物が...
この程度のことはみんな思いつくということですね。

Wikipedia 成層火山にみる日本語/英語の情報格差

インターネットにおける日本語と英語との情報格差についてはよく言われるところです。
英語の情報しかないという状況であれば、原文を何とかして読むという選択肢もあります。しかし日本語での情報があるように見えて実は英語版よりも情報量が少ないという場合は、なかなか気が付きにくく厄介な問題です。典型例は Wikipedia の記事でしょう。日本語でも英語でも記事はあるのですが、情報量が明らかに違うというケースがままあります。
一例として成層火山(Stratovolcano)の記事のスクリーンショット(2011/03/05現在)を比較してみました（左：英語、右：日本語）。

日本は「火山大国」などと言われますが、情報量の差は一目瞭然です。英語版の一番右上の写真は(もちろん日本の)富士山です。気候への影響として雲仙の噴火についても触れられています。
ちなみにGoogleで成層火山を検索すると、TOPでした(2011/03/05現在)。ちょっと恐ろしい日本語情報の現実です。

Link-style HTML button

CSSでボタンをリンク風に見せるコードスニペット。

  button.linkstyle{
    text-decoration: underline;
    border: none;
    color: blue;
    background-color: transparent;
  }
  button.linkstyle:hover{
    cursor: pointer;
    color : red;
  }
  <button class="linkstyle">リンクスタイルのボタン</button>

マウスポインタをのせたときは、判りやすくポインタの形とリンクの色を変える。
簡単にこのブログにスタイルシートを埋め込む方法が分からなかったので
見た目のサンプルはありません。m(__)m

フラクタルで複線的なPDCAサイクル

PDCA cycles should be fractal and multi-liner.
PDCAサイクルは単線的ではなく、フラクタルで複線的な構造をとる。あるいはとるべきである。

 フラクタルなPDCAサイクル

• 大計画中の小計画のPDCAサイクル
• 計画(P)を、実行(D)しながらうまくいっているか確認(C)し、必要に応じて是正(A)する
• 定期的な目標設定とふりかえり（日次／週次／月次／年次）

複線的なPDCAサイクル

• マルチタスクによるシナジー効果
• セレンディピティ

複数のPDCAサイクルが並行して進行し、相互に影響を与えあう。オレンジ色の矢印の具体的な起点と終点はP,D,C,Aのいずれでも良い。Cが最も学習効果の高いフェーズ(CheckをStudyに置き換えPDSAサイクルと言うこともある)であるため、ここでは「C->P」とした。

もちろん、フラクタル構造も維持する。