あろえの備忘録: 2011/03

2011/03/24

O'reillyでEbookをまとめ買い

被災者支援キャンペーンでEbookが半額だったのでいっぱい買ってしまった！

検索と発見のためのデザイン
GDBハンドブック
Binary Hacks
Linuxシステムプログラミング
プロダクティブ・プログラマ
ソフトウェアアーキテクトが知るべき97のこと
実用Git
プログラマが知るべき97のこと
C++クックブック
イノベーションの神話
キャパシティプランニング
並行コンピューティング技法
Real World Haskell
RESTful Webサービス

2011/03/23

bashのexceとはなんぞや

発端

    #!/bin/bash
    exec 2>&1
    somecommand

というコードがあって、exec 2>&1が何をしているかはわかるけど、内部はどうなっているのか知らなかった

execってsystem callにあるよね

exec(2)は既存のプロセスのまま新しくコマンドを実行する

例えば

    $ exec ls

上記コマンドは既存のshellのプロセスのままlsを実行して終了する。実行中だったshellはexecされたら、lsになってしまうのでshellも結果として閉じる。

    $ ls

だとfork(2)して子プロセスでexec lsしているので、shellは終了しない

bashのexecはなんだよ

よくわからないからbashのsourceを読んでみる。Open Sourceに感謝する瞬間である。

Bash公式からダウンロード。tar ballを展開して、中身を改める。

ざっくり中身を見るとbuiltins/exec.defが怪しいので中をあらためる。そうするとshell_execveが見つかる。これを追いかけると以下のようになる。

builtins/exec.def
↓
shell_execve関数発見
↓
execute_cmd.cにあり
↓
int shell_execve (command, args, env)が見つかる
↓
execve (command, args, env);
↓
こいつはunistd.hで定義されているexecve(2)のようだ

眠いので限界です

次回へ続く？

2011/03/20

第1回 Movable Type勉強会 in Hokkaido 参加記録

第1回~~Facebook~~Movable Type勉強会に参加してきました。

さっくりと今回のまとめ

Facebookの「いいね！」は少なくても意外と効果がある
Facebook広告のコスパがいい。現在はセグメントをかけない方が良さげ
hootsuiteは便利
ポポポポーン
Facebookページはiframeで表示させていた
懇親会の同じテーブルでFacebookを使った新手のイジメがあった

イジメは冗談です。
あまり積極的にFacebookを活用していなかったので、いろいろと参考になる話しが多かったです。

今回はiframeで表示するFacebookページの管理はMTから行いましたが、このプラグインは来週火曜日に公開になるそうです。
個人利用は無償とのことでしたので、興味のある方はスカイアークさんのところ公開されるのを待ちましょう

2011/03/09

アーキテクチャスタイル

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

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

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

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

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

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

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

アーキテクチャスタイル

パイプとフィルタ Pipes and Filters
- メリット
  - フィルタ処理が独立化するので変更、再利用が用意
- デメリット
  - 状態情報の共有が困難
  - フィルタ間でデータ変換のオーバーヘッドがある
  - エラー処理が難しい
クライアント/サーバ Client/Server
- メリット
  - 複雑な処理の集中化
  - 機密性
- デメリット
  - クライアントとサーバが同一マシン上ではない場合のオーバーヘッドの高さ
階層化（ティア）コンピューティング Tiered Computing

それぞれ段階層がクライアント/サーバの役割する
- メリット
  - 階層ごとに関心事を分離できる
  - 階層の再利用が可能になる
- デメリット
  - 階層間の通信のオーバーヘッド
  - システム要素数の増加による追加開発の複雑さ
ピアツーピア Peer-to-Peer

各ピア（システム要素）がクライアント/サーバとなるが、中央サーバを必要とせずピア同士で自由に通信する
- メリット
  - スケーラビリティの高さ
- デメリット
  - 中央ピアリストが入手できないと、ピアのネットワーク分断が起こりやすい
  - 任意の時点でのシステムからの特定の応答が保証するのが困難
  - どういうこっちゃ？
レイヤ実装 Layered Implementation

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

Note
Tiered Computingとの違いはいまいちわからないが、単体でサービスを提供するかどうか、
レイヤは機能の垂直分割、Tiered Computingは機能の水平分割の模様。
所謂Web ApplicationのMVCのスタイルはTiered Computingにあたるんだろうか
- メリット
  - レイヤの再利用
  - 関心ごとの分離
  - 各レイヤの分離による保守管理の用意さ
- デメリット
  - 実装の柔軟性の低下
  - レイヤ毎に順番に開発する必要性がある
パブリッシャ/サブスクライバ Publisher/Subscriber
- メリット
  - SubscriberをPublisherの緩やかな結合
- デメリット
  - 実装が複雑
  - 信頼性のあるメッセージ配信が必要な場合、複雑になりがち
非同期データ複製 Asynchronous Data Replication

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

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

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

Note
PubSubHubbubがまさにこれのような感じがする
- メリット
  - 小規模から大規模まで拡張可能
- デメリット
  - ディストリビュータを挟むので更新待ち時間がある
  - ディストリビュータが蓄えるキャッシュが規模の拡大に伴って負担になる
統合ハブ Integration Hub

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

データソース、データ送付先、ハブ、アダプタの4つのシステム要素がある。
ハブを経由してデータソースとデータ送付先がデータを同期する。その際にアダプタがデータを共通形式に変換し、自由にデータを同期させられるよう責任をもつ
- メリット
  - 新しいデータソースや送付先の追加による影響が少ない
  - アダプタによってソース独自の詳細等を隠蔽できる
- デメリット
  - 全部の形式をサポートするのは現実的じゃないので、共通モデルの設計が難しい
  - 変換が多く挟まるので非効率的
  - ハブの作り込みが甘いと障害点になる
タプルスペース Tuple Space

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

Note
並列処理向きの模様。
Job Queueもこれの一種？worker, clientがクライアント要素で、daemonがタプルスペースに当たるよね？
- メリット
  - 単純なコンピュータ処理モデルを提供
  - クライアント間の緩やかな結合
- デメリット
  - タプルスペースのスケーラビリティの限界

2011/03/05

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

感想

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

以下、作業中のメモ

本読み

fibonacciのメモ化

Object.createのprototype, 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に戻してあげる必要があった

サンプルコード

登録: 投稿 (Atom)