2011/03/09

アーキテクチャスタイル

システムアーキテクチャ構築の原理の読書メモ

ソフトウェアパターンの分類

一般に以下の3つに分類される

  • アーキテクチャスタイル
  • デザインパターン
  • 言語イディオム

この3つの違いはシステム上でのレイヤーの違いで、アーキテクチャスタイルはシステムレベル、
デザインパターンはソフトウェア設計、言語イディオムはもっとも具体的な言語固有の問題の解決方法を表す。

アーキテクチャパターンのメリット

デザインパターンと同様で直接の解決策だったり、土台に利用したりもできる。
また一般的なパターンであれば、作業者のシステムの理解も早くなる。

アーキテクチャスタイル

  1. パイプとフィルタ Pipes and Filters

    • メリット
      • フィルタ処理が独立化するので変更、再利用が用意
    • デメリット
      • 状態情報の共有が困難
      • フィルタ間でデータ変換のオーバーヘッドがある
      • エラー処理が難しい
  2. クライアント/サーバ Client/Server

    • メリット
      • 複雑な処理の集中化
      • 機密性
    • デメリット
      • クライアントとサーバが同一マシン上ではない場合のオーバーヘッドの高さ
  3. 階層化(ティア)コンピューティング Tiered Computing

    それぞれ段階層がクライアント/サーバの役割する

    • メリット
      • 階層ごとに関心事を分離できる
      • 階層の再利用が可能になる
    • デメリット
      • 階層間の通信のオーバーヘッド
      • システム要素数の増加による追加開発の複雑さ
  4. ピアツーピア Peer-to-Peer

    各ピア(システム要素)がクライアント/サーバとなるが、中央サーバを必要とせずピア同士で自由に通信する

    • メリット
      • スケーラビリティの高さ
    • デメリット
      • 中央ピアリストが入手できないと、ピアのネットワーク分断が起こりやすい
      • 任意の時点でのシステムからの特定の応答が保証するのが困難
      • どういうこっちゃ?
  5. レイヤ実装 Layered Implementation

    システム要素をレイヤとし、各レイヤをスタックする。
    レイヤは抽象レベルによって分割されて、スタックの一番上が特定の操作等にあたり、 スタックの下にOSのシステムライブラリが来る。

    Note
    Tiered Computingとの違いはいまいちわからないが、単体でサービスを提供するかどうか、
    レイヤは機能の垂直分割、Tiered Computingは機能の水平分割の模様。
    所謂Web ApplicationのMVCのスタイルはTiered Computingにあたるんだろうか

    • メリット
      • レイヤの再利用
      • 関心ごとの分離
      • 各レイヤの分離による保守管理の用意さ
    • デメリット
      • 実装の柔軟性の低下
      • レイヤ毎に順番に開発する必要性がある
  6. パブリッシャ/サブスクライバ Publisher/Subscriber

    • メリット
      • SubscriberをPublisherの緩やかな結合
    • デメリット
      • 実装が複雑
      • 信頼性のあるメッセージ配信が必要な場合、複雑になりがち
  7. 非同期データ複製 Asynchronous Data Replication

    Publisher/Subscriberの変種。データを同期させる必要がある場合に利用される。
    データソース、データレプリカ、レプリケータの3つの要素で構成される

    Note
    DBのレプリケーションとかがこれにあたるのか

    • メリット
      • ロジックを複雑化させることなく、データが同期できる
    • デメリット
      • ソースとレプリカの更新の間で発生するタイムラグ
      • レプリカデータストアでの更新処理に対応すると複雑化する
  8. ディストリビューションツリー Distribution Tree

    パブリッシャ、ディストリビュータ、消費者の3つのタイプのシステム要素がある。
    パブリッシャがツリーの根になって、ディストリビュータが中間ノードを作り、消費者がツリーの葉になる。

    Note
    PubSubHubbubがまさにこれのような感じがする

    • メリット
      • 小規模から大規模まで拡張可能
    • デメリット
      • ディストリビュータを挟むので更新待ち時間がある
      • ディストリビュータが蓄えるキャッシュが規模の拡大に伴って負担になる
  9. 統合ハブ Integration Hub

    多数の異なるシステム間で情報を同期させる必要がある状況に利用される。
    非同期データ複製(Asynchronous Data Replication)を拡張したもの。

    データソース、データ送付先、ハブ、アダプタの4つのシステム要素がある。
    ハブを経由してデータソースとデータ送付先がデータを同期する。その際にアダプタがデータを共通形式に変換し、自由にデータを同期させられるよう責任をもつ

    • メリット
      • 新しいデータソースや送付先の追加による影響が少ない
      • アダプタによってソース独自の詳細等を隠蔽できる
    • デメリット
      • 全部の形式をサポートするのは現実的じゃないので、共通モデルの設計が難しい
      • 変換が多く挟まるので非効率的
      • ハブの作り込みが甘いと障害点になる
  10. タプルスペース Tuple Space

    クライアント(情報を生成して処理するコンピュータ処理要素)とタプルスペースそのもの(型づけされた情報タプルまたはレコードをクライアントが読み書きする記憶空間)の二つのタイプのシステム要素がある。
    クライアントとタプルスペースはクライアント/サーバネットワーク接続で接続する。クライアント同士は接続しない

    Note
    並列処理向きの模様。
    Job Queueもこれの一種?worker, clientがクライアント要素で、daemonがタプルスペースに当たるよね?

    • メリット
      • 単純なコンピュータ処理モデルを提供
      • クライアント間の緩やかな結合
    • デメリット
      • タプルスペースのスケーラビリティの限界

2011/03/05

Sapporo.js-2011.03.05の感想と本読み、LTのメモ

感想

  • 読み合わせのある勉強会は初めてだった
    • 読んで、その部分のコードを試してみんなで疑問を試したりして進んでいった
    • Perlでやるとしたら、どの本がいいのかな
    • さらっとやるのかと思ったら、意外と深いところまで突っ込んでた
  • 札幌市民ホールの会議室は綺麗でススキノにも近い
    • でも18, 24人のサイズの後は74人とかになる

以下、作業中のメモ

本読み

  • fibonacciのメモ化
  • Object.createprototype, constructorの挙動

    Object.create = function(o) {
        // 無名関数でもいいけど、名前を付けると
        // stacktraceで出ることもある
        var F = function Child() {};
        F.prototype = o;
        return new F();
    }
    
  • 関数と変数で同じ名前を使用したら、関数定義が先に解析されるので変数が上書きする

    // OK
    Object.create function(o) {
        alert(F);
        F.prototype = o;
        function F() {};
        return new F();
    }
     
     
    // NG
    Object.create function(o) {
        alert(F);
        F.prototype = o;
        var F = function F() {};
        return new F();
    }
    
  • __proto__を使うとnewを使わないでもいける。但しもじらだけっぽい

    var c = {}, p = {};
    p.__proto__ = { hoge: 'xxx' };
    c.__proto__ = p.__proto__;
    alert(c.hoge || 'ooo'); // mozilla => xxx, IE => ooo
    

LT @bad_at_mathさん

JavaScriptの成り立ち

  • Nescapeが1995
  • Scheme, Selfからの影響
  • ECMA(ヨーロッパ)で標準化
    • ECMA 262
    • ISOとかも
  • ECMA 262 - 3rd (1999年頃)
  • ECMA 262 - 4rd (2005年頃)
    • Class, Interface
    • MS/AdobeとYahoo/Mozillaが対立
    • ぐだぐだ
  • ECMA 262 - 5th (2009年頃)
  • ECMAの特徴
    • 小さい
  • ブラウザのJavaScript
    • CORE(ECMA)
      • SpiderMonkey
      • Rhino
      • V8
      • Carakan
      • Chakra
      • Appleのなんか
      • 第2次ブラウザ戦争
    • DOM
    • E4X
    • イベント系

Node.js

  • 以前からいろいろあったけど、使われてない
  • Multi Thread
    • IOが実行時間の中で支配的
    • context switchも数が多いとすごい
    • メモリいっぱい
  • Single Thread + Non Blocking IOか
    • 省メモリ
    • Node.jsはこっち

2011/03/03

Coro::LWPのリクエスト数をCoro::SemaphoreSetで管理

Coro::LWP

use Coro::LWPをするとLWPの諸々が勝手に上書きされるので非同期リクエストが可能になる

Coro::SemaphoreSet

Coro::SemaphoreSetで同時接続数の管理を行えば、相手のサーバから怒られたりしないし、自分のリソース管理も楽になるでしょう。

scheduleについて

join呼んだ方がいいのかは知らないけど、scheduleでやってみたかった
joinを使う場合はこんな感じ.

my @coros;
for ( 1 .. 10 ) {
    push @coros, async { ... };
}
$_->join for @coros;

scheduleを実行した場合、main threadに制御が帰ってこないので、semaphoreの値をチェックして、$Coro::main->readyでmain threadに戻してあげる必要があった

サンプルコード

2011/02/28

HTML::Shakanで文字化けしない方法

VERSION

関連モジュールのVERSIONは以下の通り
HTML::Shakan 0.09
Formvalidator::Lite 0.23

対処方法

先に現状での対処方法を書きます

HTML::ShakanのField定義はbinary stringsで行う

但し、この対処方法では以下の状態になる

  • $form->get_error_messagesはtext strings
  • $form->renderはbinary strings
  • use utf8しない状態なのが気持ち悪い

文字化けの原因

Shakanで使用するField定義データにtext stringsを使用すると、HTML生成時にbinary stringsと結合されるため文字化けが発生する

各モジュールの文字列の扱い

FormValidator::Lite

  • FV::L::Message::jaはuse utf8しているのでtext strings

HTML::Shakan

  • 内部でencode, decodeはしない
  • HTML生成時はbinary stringsとField定義データ、requestデータとの結合

希望の動作

  • Field定義はtext stringsで行いたい
  • $form->renderはtext stringsを返す
  • $form->get_error_messagesもtext stringsを返す

2011/02/27

perlbrewでinstallしたperlをquickrun.vimで使用する方法

解決 2011-11-05 16:58

再度調べたらさっくりと解決したので追記

shellにzshを使っているなら、.zshenvにperlbrewのsourceを設定するとよい

source $HOME/perl5/perlbrew/etc/bashrc


誰か教えてください!

とりあえず~/.vimrcに↓を書いてしのぐ
let g:quickrun_config={'perl': {'command': '/Users/yourname/perl5/perlbrew/perls/perl-5.12.2/bin/perl'}}

2011/02/26

[修正済み] Plack::Request + HTML::Shakan 0.08 or 0.09 + FormValidator::Lite 0.23の組み合わせで空のFileFieldを扱うとdieする

追記 2011/03/01
pull requestを送ったところmergeして頂きました。ありがとうございます!
FormValidator::Lite 0.24で修正されています
近いうちにCPANにもアップされるんじゃないでしょうか。


追記 2011/02/28
forkして治したけど、まだpull requestは送ってない
git://github.com/ysasaki/formvalidator-lite-perl.git



今日は眠いので明日に治すかもしれない

多分、以下の条件の場合にdieする

  1. FILE_*をconstraitに指定している
  2. Plack::Request使用
  3. FormValidator::Liteが0.23


Plack::RequestのparamまわりとFormValidator::Liteのファイル関連のconstraintのチェックタイミング、HTML::Shakanのuploadsの挙動あたりの問題っぽい。
Shakanだけ変更しても直せないかもしれない。

再現コード

2011/02/20

Hokkaido.pm #4のスライドと感想

Hokkaido.pm #4に参加しました。 参加者、ゲストのyusukebeさん、スタッフの皆様お疲れ様でした。

まずは今回の発表したスライドを貼っておきます。
CPAN/便利モジュール


View more presentations from aloelight.

反省会や懇親会等で聞いたこと等を忘れる前に書いておきます。

  • 会計は誤差がほとんどなかった
  • 反省会はスタッフっぽい人だけでなく、他の人も参加すべきではないか
  • 懇親会は終わった後そのままなだれ込める店が望ましい
    • #1はそうだった
    • 今の会場だと17時で閉まるので、やってる店が近くにない
    • 会場を移すべきか?
    • 金曜の夜にやるのも手(東京ではこれが多いらしい)
  • ハンズオンは思ったよりも人がくる
    • 高校生の彼はまたやって欲しいとか言ってた
    • ライブコーディングが見たい
    • 準備が大変なので何をやるか予め希望を取るとかしたほうがいいかも
  • 次回はスピーカーをやってくれそうな人がいる
  • 地元の人がそろそろ40分枠でやってみてもいいんじゃないか
  • 呼んでみたいゲストはまだまだ模様
    • JPAのゲストの派遣支援はかなり嬉しい
  • ustがピンクだった