2015年9月18日金曜日

スコープに注意しよう

スコープとは見える範囲を規定する表現だ。
スコープとは見えてはいけない領域を明確にする思想だ。

オブジェクト指向におけるスコープの規定はだいたい前者の理解が主流だと思う。
おそらく世の中に出回っている参考書やガイドブックの類はほとんどが前述のような説明をしていると思う。
もちろん間違ってはいない。 ただし、充分か? と言えば、必ずしも充分ではないように思われる。 スコープ定義のひとつの目的として不具合の囲い込みがあげられる。適切に見える範囲をコントロールすることにより、不用意に値を参照したり書き換えてしまったりしないようにすることだ。
アクセス可能な範囲を適切に縮小して狭めてやることで動作のメカニズムは安全なものとなる。正確にいうと、動作のしくみ自体が安全なのではなく、実装や検討をするにあたり考えなければならない範囲を少なくしている。つまり、ひとの頭の中の思考をなるべくシンプルにして、その結果、誤りを減らそうとする努力の表れだ。
この思考そのものは、見えるもの を制御することに軸がおかれるため、見える範囲から見えない範囲の方向に進みがちだ。したがって、観察対象の本質を見誤れば見える範囲として認識される可能性がある。
この誤りの方向は必ず見える範囲で起こる。
すなわち、ここで不用意にデータを書き換えてしまう危険性が生まれるわけだ。
実は、このスタイルの不具合というのが最も多いように思われる。と同時に、人々の仕事の最も苦しい部分を助長する要因でもあるように思われる。
見える範囲でモデリングをしている限りは必ず起こり得る問題だ。そして、この問題の本質はスコープ制御ではなく、観察対象の分類、整理に突き当たる。

では、逆のアプローチをとることが可能なのか?
可能であればその有用性は? ということについて考えてみたい。

今度は見えてはいけない範囲の考察が軸になる。
観察対象は、はじめは種々雑多なデータやコンテキストが散りばめられた状態だと思う。
ここから不要なものを取り除いてゆくわけだが、一気に分解して整理してゆくのは難しい。徐々に問題を解体しつつ段階を踏む必要がある。当然、このときに意識するスコープに不要なのか? 必要なのか? という観点で分析が進むはずだが、もうひとつ特殊な性格をもった観察対象の発見があるに違いない。
それは、ほかのスコープでも使用することが予想されるものの発見だ。
実はこの部分がキーポイントになる。さきほどあげたスコープの内側から、いわゆる共通データや共通コンテキストを、考察の対象としてスコープ内でどのように定義するべきか? という問題に答えを出すのは非常に難しい。
分類、整理におけるねじれ現象にあたるこの問題を正確に捉えるには、対象スコープの外側からしか、その合理性を考察できない。
このねじれ現象をスコープの内側からの解決手段を定義しようとすると、後程、ほかのスコープから考察した場合のことを想定するのは難しいし、また、ほかの機会に、現在のスコープの共通項目を正確に捉えるのは困難だ。

ここまでで新たな発見があったと思うが、観察対象のスコープの外側から考察した場合、たったいま考えた、ほかのスコープとの共通項目が存在した場合、あるいは、見つけた場合は、それ自体が独立したスコープを形成し得ることをここで確認しておきたい。

2015年9月16日水曜日

Node.js 4.0.0 へ

Node.js の開発チームは最新の安定版となる Node v4.0.0 をリリースしました。

主な変更点としては

・非同期のコールバックパラメータを扱えるchild_processの追加
・拡張モジュールのビルドツールnode-gypおよびパッケージ管理ツールnpmのアップデート
・timerのパフォーマンス向上 など。

なお、Node は LTSと定期サイクルのリリースを進めているが、最初の LTS を10月にリリースする模様。

2015年9月15日火曜日

Go kit

世の中のサービスが、マイクロサービスのベストプラクティスの標準化を画策する中、おもしろいムーブメントが起きるのではないか? という予感がします。

Goと「Go kit」によるマイクロサービス構築


このインタビュー記事の中で、組織の中での作業の標準化というキーワードが何度となく飛び出してきます。
これはまさに重要なことを示唆しています。
問題なのは、アーキテクチャの中にあるのではなく実装の標準化に達していない文化なのだと思います。

2015年9月14日月曜日

命名法

思いの外悩むものが、名前の付け方だ。
変数から始まってメソッド、関数、クラス、名前空間、プロジェクト名称…
名前を付けるべきものはたくさんある。
命名とはパッケージなのだ。命名に関して思い悩む、あるいは、なかなかつけられないのは想像力が欠如しているわけではない。
分析が足りないだけだ。もしくは、名前をつけるには不適当な粒度と内容を持っているかもしれないことを検討する余地が残っているだけかもしれない。
一意の名前をつけられない原因は、対象となる変数なりクラスが、いったいどういう役割を持っているのか?という点でしっかりと確定されていないだけかもしれない。

そこで帰納法を試してみよう。
帰納法とは、特化したものから観察結果を取り出し一般的なものを導き出す手法だ。
つまり概念化して、形態や方向性など、モデルとしての本質を探る。まず、この段階で余計なファクタが取り除かれ重要なポイントだけが残ると思う。ここまでは確認段階だ。いわゆるインタフェースの抽出に似ている。

次にまったく逆のアプローチをとる。
演繹法により前提条件から結論を導き出す。ちょうど数学の公理から系統を導き出すようなイメージだ。ここでは、一般から特殊へと逆の流れをとる。
ここで、概念モデルから特殊化されたモデルが形成され、その対象を表す、もしくは、要約するべき名前が見つかれば幸いだ。
もし、この時点で要約すべき表現が見つからなければ、対象が明らかに役割過多かもしれない。

と、理屈ばかり書いたように思えるが、これは私たちがふだん行ったり来たりしているモデリング手法そのものだ。

2015年9月10日木曜日

AIによる作曲は果たして可能なのか?

この記事によると、Hello World というタイトルが付けられた実験音楽ではあるが、拍子は4/4拍子。
ただし、冒頭からピアノが4拍3連の連符を弾き、トップのバイオリンが3拍に感じられるであろうゆるやかなパッセージを奏でる。と思ったら、クラリネットがこのコンビネーションの中で旋律を前に引っ張っていくようなリズムをギミックのように表現している。なおかつ、このクラリネットのカウンターパートにバイオリンのトップノートは1小節目の最終拍で減5度で音をぶつけている。そうぶつけているのだ。
これは聞く人によっては強烈な不協感とインパクトを与えるだろう。加えてリズムのギミックはポリリズムの展開を見せ、果たしてこの音楽はどういうビート感を伴っているのか? とまどうに違いない。唯一、聞き分けが容易なのがピアノの3連符の強烈なインパクトだ。

これは、いわゆるアルゴリズムにより作られた音楽だそうだ。
作られたというより、ほぼインプロビゼーションの雰囲気に近いもののようにも思える。 音楽は、基本的に数学であり時間芸術だ。つまり、時間と周波数の高さを数理的に定義してはじめて成り立つものだ。このあたりが絵画や文学とは違った性質を持つ。そういう意味では、音楽は次元の設計に他ならず論理には極めてマッチする。
この試みは決して目新しいものではなく、かつて、ピエール・ブーレーズの音楽や、もしかしたらジョン・ケージも、そして、あのイゴール・ストラビンスキーの「春の祭典」で対数の分析から導き出された音楽たちで、その効果を追体験することが可能である。
そして、件の記事を追っていくと生活の音楽を提案している。これはまぎれもないエリック・サティの環境音楽の思想そのものだろう。 おもしろいことに音楽は一定の周期で、まるで波のように解釈や焼きなおしというムーブメントが必ず起こるが、このようなアルゴリズムが自立して紡ぎだす音楽が、今後のトレンドになるのかもしれない。

果たして、このアルゴリズムの音楽はどのような展開を見せるのか?

2015年9月9日水曜日

Prototype宣言

オブジェクトというものを考えてみます。

とはいっても、所謂オブジェクト指向言語のオブジェクトではなく、プロトタイプベースのオブジェクトを考えてみます。
その前に従来のオブジェクト指向言語のオブジェクトを簡単に振り返ってみます。
まず、システムやソフトウェアはあるシナリオによって動作します。このシナリオをできるだけ細かく分解して汎用的な部分を共通化して合理的な実装に備えます。
しかし、これではまだ不充分で、特性や性質、あるいは、本質的に何を表現するのか? という観点でさらに分解されます。
つまり、ある事象の根本的な動作の表現、それを色づけるための特性や性質に分解されることに結実するのがオブジェクトに対するアプローチだと思います。
たとえば、前者がコンテキストだったり、後者がデータだったりします。
合理的な単位で分解されたものがオブジェクトになり得る候補になります。私たちがやることは、その分析結果をクラスという概念でモデル化して、電気信号に変えられインスタンスに変化します。 これがオブジェクトです。
ここで注意したいのは、このオブジェクトは既に特性や性質を兼ね備えているということです。それらはメンバという形で自然に存在します。
なぜなら、オブジェクトとして実体になるクラスがそのように定義されているからです。

さて、ECMAScriptの世界はどうでしょうか?
プロトタイプベースのオブジェクトは、実はそのように考えません。
オブジェクト自身は別のオブジェクトを追加することにより、新たな性質が加わります。
これがプロトタイプの考え方です。
では、そのプロトタイプベースの考え方に則りオブジェクトを生成してみます。

function Object() {}
var onj = new Object();

上のオブジェクト定義では retun がありませんが、下のステートメントで new されたときにオブジェクトインスタンスが得られます。

さらに初期化してみます。

function Object() {
    this.param = “done.”;
}
var obj = new Object();
Console.log( obj.param );
>Done. と表示されます。

今度は、このようなコードを書いてみます。
function Object() {}
Object.prototype.param = function() {
    console.log('Done.');
};
var obj = new Object ();
obj .param(); // Done. と表示される。

これでは、どうでしょう。
function Object () {
    this.param = function() {
        console.log('Done.');
   };
}
var obj = new Object ();
obj .param(); // Done.

ほぼ、同じです。
しかも同じように動作します。
しかし、大きな違いがあることがわかると思います。
後者のコードでは毎回インスタンス化されてしまうという違いがあります。 すべてのオブジェクトは prototype オブジェクトの参照を持っています。 この prototype オブジェクトに新たな特性や性質を付与することにより、細かなニュアンスの違いを表すことができます。
オブジェクト指向言語の継承に近い雰囲気を持っているように見えますが、性質が違います。
prototype に特性や性質を加えて、かつ、削除することも可能です。

ここでポイントです。
new により生成されたオブジェクトは、Object の prototype と同じ参照を持っています。
これによりオブジェクトは合理化されるわけです。

2015年9月8日火曜日

ASP.NETの吐き出すマークアップの矯正

知っている人も多いと思いますが、ASP.NET Web Forms の出力するHTMLコードがいかんともしがたい。
CheckBoxやRadioButtonListなどで顕著。
つまり、素直なHTMLツリーが出力されないのだ。

たとえば、以下のマークアップは
<asp:CheckBox ID="check" runat="server" class="myClass" />

このようなHTMLとしてレンダリングされる。
<span class="myClass"><input id="check" type="checkbox" name="check" /></span>

そう、<span></span>タグで括られてしまう。 これでは、フロントエンドでDOM解析をしたいときに非常に不便だ。と同時に input に属性を付与できないという最も大きな問題を引き 起こす。
そこでレンダリング方法をカスタマイズしてみたいと思う。

WebControlAdapterクラスを継承したクラスを作る。
using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.Adapters;

public class CheckBoxAdapter : WebControlAdapter
{
    protected override void Render(HtmlTextWriter writer)
    {
        CheckBox targetControl = this.Control as CheckBox;
        if (targetControl == null)
        {
            base.Render(writer); return;
        }
        writer.WriteBeginTag("input");
        writer.WriteAttribute("type", "checkbox");
        writer.WriteAttribute("id", targetControl.ClientID);
        if (targetControl.CssClass.Length > 0)
        {
            writer.WriteAttribute("class", targetControl.CssClass);
        }
        writer.Write(" />");
    }
}

でもって ブラウザ定義ファイルに以下のコードを追加する。
<browser refID="Default">
<controlAdapters>
                        <adapter controlType="System.Web.UI.WebControls.CheckBox" adapterType="CheckBoxAdapter" />
        </controlAdapters>
</browser>

さて、この状態で以下のようなマークアップがどのように変化するのか・・・ というと
<div> <asp:CheckBox ID="check" runat="server" CssClass="myClass" /> </div>

きれいなHTMLコードをレンダリングするようになりました。
<div> <input type="checkbox" id="check" class="myClass" /> </div>

まぁ、いまさら ASP.NET Web Forms もないだろ・・ という声も聞こえてきそうですが、画面の初期化を Web Forms で画面の更新を Web API で実行するハイブリット方針も、これはこれでなかなか生産性が高い方法でもあるのです。