2013-01-30

Angular.jsでvalue="初期値"を使いたいときは、ng-initを使いましょう

タイトル通り。。。
http://docs.angularjs.org/api/ng.directive:ngInit

マニュアル良く読もうね！！俺。。。orz

<input type="text" name="name" ng-model="name" value="<?- param ?>" ng-maxlength="5" required />

とかして、あれー。。。なんでー？？テンプレートエンジン使ってるから？とか意味もなく、悩んでました。

正解は、

<input type="text" name="name" ng-model="name" ng-init="name='<?- param ?>'" ng-maxlength="5" required />

ってすれば、テンプレートエンジンと組み合わせても全く問題ないですね！！

2013-01-22

bitbucketクローンのrhodecodeをアップグレードした記録

前に導入したrhodecodeは1.4.4だったんですが、
いろいろ機能追加されているので、1.5.2にアップグレードしたので、その時のメモ。

rhodecodeさんは、マニュアルがしっかり整備されているので、色々助かります。。。
基本は、ココ参照すると、なにも困りませんが。。。

まずは、rhodecodeのサービスを止めます。DBのバックアップも取っておくほうがいいかも。

/etc/init.d/paste-serve-rhodecode stop

iniファイルのバックアップ

su - paste
cp /var/www/rhodecode-venv/production.ini /var/www/rhodecode-venv/production.ini.yyyy.mm.dd

pip freeze するらしいけど、やってない。(あんまり意味わかってない）

# マニュアルに書いてるけど、ヤリマセンデシタ。。。
# pip-python freeze

sourceは、前回で、bashrcに記載しているから、触ってないです。
んで、rhodecodeをアップグレードしてiniを作成

su - paste
/var/www/rhodecode-venv/bin/pip install --upgrade rhodecode
/var/www/rhodecode-venv/bin/paster make-config RhodeCode /var/www/rhodecode-venv/production.ini
# 上書き確認されるので、y

iniの設定をする。diff取って、項目的に追加がほとんどだったので、前と同じ内容の改変を施す。

#vim /var/www/rhodecode-venv/production.ini

[DEFAULT]
email_to = rhodecode@localhost # コメントを外して環境に合わる
error_email_from = paste_error@localhost　# コメントを外して環境に合わる
app_email_from = rhodecode-noreply@localhost # コメントを外して環境に合わる

smtp_server = localhost

[server:main]
host = 0.0.0.0 # 127.0.0.1からすべて受付に変更

#########################################################
### DB CONFIGS - EACH DB WILL HAVE IT'S OWN CONFIG    ###
#########################################################

# SQLITE [default]
#sqlalchemy.db1.url = sqlite:///%(here)s/rhodecode.db # コメントにして

# POSTGRESQL
# 本来はuser:pass@ですが(ローカルだからと甘えて、trustで動かしてるので、パスワード設定なし）
sqlalchemy.db1.url = postgresql://rhodecode@localhost/rhodecode 

# MySQL
# sqlalchemy.db1.url = mysql://user:pass@localhost/rhodecode

# see sqlalchemy docs for others

・・・

DBのアップグレード

/var/www/rhodecode-venv/bin/paster upgrade-db production.ini

で、サービスを起動すると完了！！

/etc/init.d/paste-serve-rhodecode start

無事、完了しました。ﾜｰｲヽ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾉﾜｰｲ

2013-01-17

async.jsで有名なcaolanさんのNode.js: Style and structureを対訳を掲載してみました。

Node.js

前回async.jsで有名な、caolanさんのNode.js: Style and structureを日本語訳をしました。コメントに原文も引用符みたいに対訳を載せてもらえるというありがたい意見を頂いたので、のっけてみます。

相変わらずのレベルの低さですが、おかしな部分がありましたら、指摘頂けますと幸いです。m(_ _)m

Node.js: Style and structure

Node.jsのスタイルと構造

This may seem like quibbling over coding style, but in Node.js it's an important way of keeping your functions easily composable and reusable.
This is not a style guide in the usual sense; I'm assuming you already have your opinions on JavaScript indentation and all the other religious standpoints, so I'm going to focus on some Node specifics I find essential.
私は新たなチームでNode.jsのプロジェクトを開始しようとしていました。これはNodeでの作業でいくつかのヒントをまとめる良い機会かもしれないと思ったのが始まりです。これは、通常の意味でのスタイルガイドではありません。あなたが既にJavaScriptのインデントおよび他のすべての宗教の立場で自分の意見を持っていると仮定し、私が本質的ないくつかのNodeの仕様をフォーカスするつもりです。

If you're looking to define a more complete style-guide, including where to put those pesky curly braces, I recommend reading some of the following:
厄介な中かっこを配置する場所を含む、より完全なスタイルガイドの定義を探しているなら、次のいくつかを読むことをお勧めします

1. Avoid this and new

1. thisとnewを避ける

This may seem like quibbling over coding style, but in Node.js it's an important way of keeping your functions easily composable and reusable.
これはコーディングスタイルの上言い逃れのように思えるかもしれませんが、Node.jsで、関数が簡単に作成でき、再利用するための重要な手段です。

Because Node.js involves passing around many callbacks and using a lot of higher-level functions to manage control flow; you should make sure functions are easy to move around without having to bind to a specific context.
Node.jsは多くのコールバックを渡すと、制御フローを管理する為、高レベル関数を使用するため、関数が特定のコンテキストにバインドすることなく、移動が簡単に確認できなければなりません。クロージャオブジェクトのメソッドを好むし、クロージャで明示的な引数を好みます。

// contrived example using prototypes and 'this'
// prototypeの 'this'を使用した不自然な例

function DB(url) {
    this.url = url;
}

DB.prototype.info = function (callback) {
    http.get(this.url + '/info', callback);
};

async.parallel([
    function (cb) {
        new DB('http://foo').info(cb);
    },
    function (cb) {
        new DB('http://bar').info(cb);
    }
], ...);

// // similar example using closures
// クロージャを使った同様の例

function DB(url) {
    return { info: async.apply(http.get, url + '/info') };
}

async.parallel([
    DB('http://foo').info,
    DB('http://bar').info
], ...);

// making all arguments explicit
// すべての引数を明示的にすること

var dbInfo = function (url, callback) {
    http.get(url + '/info', callback);
};

async.map(['http://foo', 'http://bar'], dbInfo, ...);

The final style, with all arguments made explicit, allows us to easily pass in an arbitrary list of URLs and perform the same operation on them all.
Using a more functional style will make your life significantly easier when it comes to combining functionality in this way.
すべての引数が明示された最終的なスタイルは、簡単にURLの任意のリストを渡し、それらすべてに同じオペレーションを実行することができます。関数的なスタイルを使用すると、このように関数を組み合わせることになり、とても簡単になります。

Of course, there are cases where making all arguments explicit would be undesirable, and cases where using constructors and prototypes are more efficient.
I simply recommend you prefer the latter styles over the former and justify your use of these features when necessary.
もちろん、全ての引数を明示的に作ることが望ましくないケースもあり、その場合、コンストラクタとプロトタイプを使用すると、より効率的です。私は単に前者より後者のスタイルを好むし、必要に応じてこれらの機能の使用を正当化することをお勧めします。

2. More, smaller functions

2. 小さな関数を多くする

Before you even start looking into control flow libraries like async >, you can tame much of the "callback hell" by simply breaking up your functions into smaller components.
asyncのような制御フローライブラリ探しをはじめる前に、単に小さなコンポーネントに関数を分割することによって「コールバック地獄」の多くを飼いならすことができます。

// a deeply-nested function including four asynchronous operations
// 4つの非同期操作を含む深くネストされた関数

function convertJsonToCsv(filename, target, callback) {
    readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }
        parseJson(content, function (err, data) {
            if (err) {
                return callback(err);
            }
            convertToCsv(data, function (err, csv) {
                if (err) {
                    return callback(err);
                }
                writeFile(target, csv, callback);
            });
        });
    });
}

// the same functionality broken into smaller parts
// 同じ機能をより小さなパーツに分割

function convertJsonToCsv(filename, target, callback) {
    readJsonFile(filename, function (err, data) {
        if (err) {
            return callback(err);
        }
        writeCsvFile(target, data, callback);
    });
}

function readJsonFile(filename, callback) {
    readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }
        parseJson(content, callback);
    });
}

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            return callback(err);
        }
        writeFile(target, csv, callback);
    });
}

I'd recommend you try and keep your functions down to two asynchronous operations at a time, as in the above example, or to one iteration over a list (using async.map or similar).
Having more, smaller functions also makes it easier to recombine them in new ways later on.
上記の例のように、一度に2つの非同期のオペレーションをする機能を抑える、またはリストを1度イテレーション（async.mapまたは類似の使用）することをお勧めします。より小さな関数を有することで後で容易に新しい方法で再結合することができます。

Of course, you can further clean up your code using an asynchronous control flow library.
But this is the first step in getting things readable again.
もちろん、さらに非同期制御フロー·ライブラリを使用してコードをクリーンアップすることができます。しかし、これは可読性をあげるための最初のステップです。

3. Consistently asynchronous APIs

3. 一貫した非同期API

In order to keep your code predictable, a function should be either always asynchronous, or always synchronous.
コードを予測可能にしておくために、関数は、常に非同期、または常に同期している必要があります。次の点を考慮します。

var CACHE = {};

function getRecord(id, callback) {
    if (CACHE[id]) {
        return CACHE[id];
    }
    http.get('http://foo/' + id, callback);
}

When someone attempts to use this function, it's very easy to miss out the cached case and have code that never completes:
誰かがこの関数を使用する場合、完了しないコードがあり、キャッシュされたケースを非常に簡単に見落とします。

function getMyRecord(user, callback) {
    getRecord('record-' + user.id, callback);
}

The first time you call getMyRecord it will complete successfully, the second time it will never call the callback (because getRecord returns immediately with the cached result). This might halt execution of the request.
getMyRecord を初めて呼び出す時は、正常に完了しますが、 2度目はコールバックが呼ばれれることはありません。(GetRecordは、キャッシュされた結果を直ちに返しているため)これは、リクエストの実行を停止することがあります。

Another concern with the getRecord function is execution order:
もう一つの懸案が getRecord 関数の実行順です。

function getMyRecord(user, callback) {
    var r = getRecord('record-' + user.id, function (err, record) {
        if (record) {
            record.got = true;
        }
        return callback(err, record);
    });
    if (r) {
        r.got = true;
    }
    return r;
}

Code like this is just too difficult to reason about. In order to implement it reliably you'd have to duplicate code inside the getRecord callback, and after it (in case it's synchronous). You then have to do the same thing any time you call the getMyRecord function too. This very quickly becomes messy and confusing.
このようなコードの理由は信じられない程難しいです。 getRecord コールバック中、それ以後(同期である場合)に重複したコードを確実に実装する必要があります。 getMyRecord 関数を呼び出すたびに同じことを行う必要があります。これは、非常に早く、乱雑になり、混乱を招くことになります。

The correct way to handle this is to use process.nextTick to make getRecord asynchronous even when returning a cached result:
これに対処する正しい方法は、 process.nextTick を使用し、キャッシュされた結果を返すときに getRecord を非同期にします。

var CACHE = {};

function getRecord(id, callback) {
    if (CACHE[id]) {
        return process.nextTick(function () {
            return callback(null, CACHE[id]);
        });
    }
    http.get('http://foo/' + id, callback);
}

Now we need only consider the asynchronous case and our code becomes much more predictable.
非同期の場合を考慮することで、コードは非常に予測しやすくなります。

4. Always check for errors in callbacks

4. 常にコールバックでエラーをチェックする

Missing an error check inside a callback is a common cause of confusion in debugging.
The problem is that the program execution will continue and the failure may manifest itself elsewhere in the code and give you a different error message.
You then have to trace it back to the original location.
コールバック内でエラーチェックが不足していることが、デバッグで混乱する一般的な原因です。問題は、プログラムは実行が継続され、障害がコードの他の場所で発生し、別のエラーメッセージを与えることです。その後、元の場所に戻ってそれをトレースする必要があります。

Failing to explicitly check for errors inside a callback should be considered a bug.
I highly recommend you build this step into your code review process because it can be so easy to miss.
明示的に、コールバック内のエラーチェックで失敗するバグを考慮しなければなりません。コードレビュープロセスにこのステップを構築することで、簡単に見落とさないようなるので、お勧めします。

// wrong!
// 誤っている!

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        writeFile(target, csv, callback);
    });
}

// right
// 正しい

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            return callback(err);
        }
        writeFile(target, csv, callback);
    });
}

If you want to reduce the extra code, you can do a one-line if statement when checking for the error: if (err) return callback(err);. Whichever style you choose, I recommend you are consistent, because this piece of code should be easy to spot and easy to notice when it's missing.
余分なコードを削減したい場合は、if文1行でエラーかどうかをチェックすることができます。 if (err) return callback(err);. どちらのスタイルを選択しても、コードのこの部分は、それが不足していると容易に気付き、簡単に見つからなければならないので、一貫していることをお勧めします。

5. Return on callbacks

5. コールバックの戻り値

Usually, you call a callback as the last thing you do inside a function. You might consider it synonymous with return, only JavaScript does not halt function execution when it hits it. It can be easy to accidentally let execution continue after calling a callback, when you really expected it to end. In order to make this easy to spot, and make sure execution stops in the way you expect, I recommend returning the callback function call.
通常、関数内の最後にコールバックを呼び出します。 return と同じ意味で考えるかもしれませんがJavaScriptでは、callbackは関数の実行を停止しません。終了すると思っていても、誤ってコールバックを呼び出し、実行を継続させてしまうことは容易にあり得ます。実行の停止が期待どおりかを簡単に見つける方法として、コールバック関数の呼び出しをreturnすることをお勧めします。

// wrong!
// 誤っている!

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            callback(err); // oops!no return
        }
        // この行が呼び出されると、theres an error
        writeFile(target, csv, callback);
    });
}

// right
// 正しい

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            return callback(err); // 実行はここで停止します。
        }
        writeFile(target, csv, callback);
    });
}

6. Only throw in synchronous functions

6. 同期関数だけをスローする

Unfortunately, you can't use try-catch blocks around asynchronous code.
That means any exceptions you throw will not be caught and bubble up to the top.
This can kill your entire server process if you don't have an uncaughtException handler set up.
Even in cases where you do, the error probably no longer has any meaningful context and you can't appropriately respond to a http request, for example.
残念ながら、非同期コードに try/catch ブロックを使用することはできません。それは、投げた例外がキャッチされ、トップに浮上することがないことを意味します。uncaughtExceptionハンドラが設定されていない場合、全体のサーバプロセスをkillすることができます。この場合、エラーは、恐らく意味のある、コンテキストを有しておらず、例えば、httpリクエストに適切にレスポンスすることはできません。

Always, always, always pass errors back to the callback in asynchronous functions.
As long as you're following the "Always check for errors in callbacks" rule the errors will be handled in the appropriate place.
常に、常に、常に非同期コールバック関数にエラーを戻します。"エラーコールバックを常にチェック" のルールに従っている限り、エラーは適切な場所で処理されます。

// wrong!
// 誤っている

function getRecord(id, callback) {
    http.get('http://foo/' + id, function (err, doc) {
        if (err) {
            return callback(err);
        }
        if (doc.deleted) {
            // getRecord関数の呼び出しで捕まらないでしょう
            throw new Error('Record has been deleted');
        }
        return callback(null, doc);
    });
}

// right
// 正しい 

function getRecord(id, callback) {
    http.get('http://foo/' + id, function (err, doc) {
        if (err) {
            return callback(err);
        }
        if (doc.deleted) {
            return callback(new Error('Record has been deleted'));
        }
        return callback(null, doc);
    });
}

7. Catch errors in sync calls

7. 同期呼び出しでエラーをキャッチ

This is essentially the same as the previous rule. If you're calling a synchronous function that might throw an exception, inside your asynchronous code, then calling your asynchronous code might also result in an exception.
これは本質的には以前のルールと同じです。例外をスローする可能性があり、同期関数を呼び出しているのであれば、非同期コードの内部には,非同期コードを呼び出すと、例外が発生する場合があります。

For example:
例えば、次のように

// wrong!
// 誤っている

function readJson(filename, callback) {
    fs.readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }
        // uh-oh! this line might throw an exception if the content
        // is not valid JSON
        // おっと！コンテンツがある場合は、この行は、例外がスローされる可能性が
        // 有効なJSONではない
        var data = JSON.parse(content.toString());

        return callback(null, data);
    });
}

// right
// 正しい

function readJson(filename, callback) {
    fs.readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }
        try {
            var data = JSON.parse(content.toString());
        }
        catch (e) {
            return callback(e);
        }
        return callback(null, data);
    });
}

8. Stick to the callback convention

8. コールバック慣例に固執する

There is a vocal minority on the Node.js mailing list and elsewhere which promotes the use of other strategies for handling asynchronous code. Some of them even providing "blocking-style" APIs. While they are interesting, and you might happily use promises or fibers inside your team, please consider sticking to the Node-style callbacks; where the callback is the last argument to an async function and the first argument to the callback is an error (if one occurred).
非同期コードを取り扱うための他の戦略の使用を促進する少数派の声が、Node.jsメーリングリストとどこか他の所にいます。中には、 "ブロッキングスタイル"のAPIを提供もしてくれます。興味深いものですし、チーム内でpromiseやfiberを使用する可能性があると思いますが、Nodeのコールバックスタイルにこだわった上で検討してください。コールバックは、非同期関数の最後の引数であり、コールバックへの最初の引数はエラーになります。（発生した場合）

The vast majority of Node developers follow this style, there is consensus on this. If you expect Node developers outside of your team to use your modules then you'll have a much easier time sticking to convention.
大多数の Node 開発者の大半はこのスタイルとコンセンサスに従っています。チーム外部の Node 開発者がモジュールを使用する場合、慣例に固執しているくらいの方が楽になるでしょう。

Wrap up

結論

While most of this is probably common-sense, I hope some of you find these rules useful.
これのほとんどは、おそらく常識的ですが、私はこれらのルールが役に立つことを願っています。

2013-01-12

async.jsで有名なcaolanさんのNode.js: Style and structureを訳してみました。

Node.js

async.jsで有名な、caolanさんのNode.js: Style and structureを日本語訳してみました。
( http://caolanmcmahon.com/posts/nodejs_style_and_structure/)

相変わらずのレベルの低さですが、おかしな部分がありましたら、指摘頂けますと幸いです。m(_ _)m
(OmegaTで訳したので、後で、bitbucketかgithubにあれば嬉しい人がいたり要望があれば、対応します）

出来る人には当たり前なのかもしれませんが、かなりイイ勉強になりました。

追記：コメント頂いた部分を修正しました。

Node.jsのスタイルと構造

私は新たなチームでNode.jsのプロジェクトを開始しようとしていました。これはNodeでの作業でいくつかのヒントをまとめる良い機会かもしれないと思ったのが始まりです。これは、通常の意味でのスタイルガイドではありません。あなたが既にJavaScriptのインデントおよび他のすべての宗教の立場で自分の意見を持っていると仮定し、私が本質的ないくつかのNodeの仕様をフォーカスするつもりです。

厄介な中かっこを配置する場所を含む、より完全なスタイルガイドの定義を探しているなら、次のいくつかを読むことをお勧めします

1. thisとnewを避ける

これはコーディングスタイルの上言い逃れのように思えるかもしれませんが、Node.jsで、関数が簡単に作成でき、再利用するための重要な手段です。

Node.jsは多くのコールバックを渡すと、制御フローを管理する為、高レベル関数を使用するため、関数が特定のコンテキストにバインドすることなく、移動が簡単に確認できなければなりません。クロージャオブジェクトのメソッドを好むし、クロージャで明示的な引数を好みます。

// prototypeの 'this'を使用した不自然な例

function DB(url) {
    this.url = url;
}

DB.prototype.info = function (callback) {
    http.get(this.url + '/info', callback);
};

async.parallel([
    function (cb) {
        new DB('http://foo').info(cb);
    },
    function (cb) {
        new DB('http://bar').info(cb);
    }
], ...);

// クロージャを使った同様の例

function DB(url) {
    return { info: async.apply(http.get, url + '/info') };
}

async.parallel([
    DB('http://foo').info,
    DB('http://bar').info
], ...);


// すべての引数を明示的にすること

var dbInfo = function (url, callback) {
    http.get(url + '/info', callback);
};

async.map(['http://foo', 'http://bar'], dbInfo, ...);

すべての引数が明示された最終的なスタイルは、簡単にURLの任意のリストを渡し、それらすべてに同じオペレーションを実行することができます。関数的なスタイルを使用すると、このように関数を組み合わせることになり、とても簡単になります。

もちろん、全ての引数を明示的に作ることが望ましくないケースもあり、その場合、コンストラクタとプロトタイプを使用すると、より効率的です。私は単に前者より後者のスタイルを好むし、必要に応じてこれらの機能の使用を正当化することをお勧めします。

2. 小さな関数を多くする

asyncのような制御フローライブラリ探しをはじめる前に、単に小さなコンポーネントに関数を分割することによって「コールバック地獄」の多くを飼いならすことができます。

// 4つの非同期操作を含む深くネストされた関数

function convertJsonToCsv(filename, target, callback) {
    readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }
        parseJson(content, function (err, data) {
            if (err) {
                return callback(err);
            }
            convertToCsv(data, function (err, csv) {
                if (err) {
                    return callback(err);
                }
                writeFile(target, csv, callback);
            });
        });
    });
}

// 同じ機能をより小さなパーツに分割

function convertJsonToCsv(filename, target, callback) {
    readJsonFile(filename, function (err, data) {
        if (err) {
            return callback(err);
        }
        writeCsvFile(target, data, callback);
    });
}

function readJsonFile(filename, callback) {
    readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }
        parseJson(content, callback);
    });
}

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            return callback(err);
        }
        writeFile(target, csv, callback);
    });
}

上記の例のように、一度に2つの非同期のオペレーションをする機能を抑える、またはリストを1度イテレーション（async.mapまたは類似の使用）することをお勧めします。より小さな関数を有することで後で容易に新しい方法で再結合することができます。

もちろん、さらに非同期制御フロー·ライブラリを使用してコードをクリーンアップすることができます。しかし、これは可読性をあげるための最初のステップです。

3. 一貫した非同期API

コードを予測可能にしておくために、関数は、常に非同期、または常に同期している必要があります。次の点を考慮します。

var CACHE = {};

function getRecord(id, callback) {
    if (CACHE[id]) {
        return CACHE[id];
    }
    http.get('http://foo/' + id, callback);
}

誰かがこの関数を使用する場合、完了しないコードがあり、キャッシュされたケースを非常に簡単に見落とします。

function getMyRecord(user, callback) {
    getRecord('record-' + user.id, callback);
}

getMyRecord を初めて呼び出す時は、正常に完了しますが、 2度目はコールバックが呼ばれれることはありません。(GetRecordは、キャッシュされた結果を直ちに返しているため)これは、リクエストの実行を停止することがあります。

もう一つの懸案が getRecord 関数の実行順です。

function getMyRecord(user, callback) {
    var r = getRecord('record-' + user.id, function (err, record) {
        if (record) {
            record.got = true;
        }
        return callback(err, record);
    });
    if (r) {
        r.got = true;
    }
    return r;
}

このようなコードの理由は信じられない程難しいです。 getRecord コールバック中、それ以後(同期である場合)に重複したコードを確実に実装する必要があります。 getMyRecord 関数を呼び出すたびに同じことを行う必要があります。これは、非常に早く、乱雑になり、混乱を招くことになります。

これに対処する正しい方法は、 process.nextTick を使用し、キャッシュされた結果を返すときに getRecord を非同期にします。

var CACHE = {};

function getRecord(id, callback) {
    if (CACHE[id]) {
        return process.nextTick(function () {
            return callback(null, CACHE[id]);
        });
    }
    http.get('http://foo/' + id, callback);
}

非同期の場合を考慮することで、コードは非常に予測しやすくなります。

4. 常にコールバックでエラーをチェックする

コールバック内でエラーチェックが不足していることが、デバッグで混乱する一般的な原因です。問題は、プログラムは実行が継続され、障害がコードの他の場所で発生し、別のエラーメッセージを与えることです。その後、元の場所に戻ってそれをトレースする必要があります。

明示的に、コールバック内のエラーチェックで失敗するバグを考慮しなければなりません。コードレビュープロセスにこのステップを構築することで、簡単に見落とさないようなるので、お勧めします。

// 誤っている!

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        writeFile(target, csv, callback);
    });
}

// 正しい

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            return callback(err);
        }
        writeFile(target, csv, callback);
    });
}

余分なコードを削減したい場合は、if文1行でエラーかどうかをチェックすることができます。 if (err) return callback(err);. どちらのスタイルを選択しても、コードのこの部分は、それが不足していると容易に気付き、簡単に見つからなければならないので、一貫していることをお勧めします。

5. コールバックの戻り値

通常、関数内の最後にコールバックを呼び出します。 return と同じ意味で考えるかもしれませんがJavaScriptでは、callbackは関数の実行を停止しません。終了すると思っていても、誤ってコールバックを呼び出し、実行を継続させてしまうことは容易にあり得ます。実行の停止が期待どおりかを簡単に見つける方法として、コールバック関数の呼び出しをreturnすることをお勧めします。

// 誤っている!

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            callback(err); // oops!no return
        }
        // この行が呼び出されると、theres an error
        writeFile(target, csv, callback);
    });
}

// 正しい

function writeCsvFile(target, data, callback) {
    convertToCsv(data, function (err, csv) {
        if (err) {
            return callback(err); // 実行はここで停止します。
        }
        writeFile(target, csv, callback);
    });
}

6. 同期関数だけをスローする

残念ながら、非同期コードに try/catch ブロックを使用することはできません。それは、投げた例外がキャッチされ、トップに浮上することがないことを意味します。uncaughtExceptionハンドラが設定されていない場合、全体のサーバプロセスをkillすることができます。この場合、エラーは、恐らく意味のある、コンテキストを有しておらず、例えば、httpリクエストに適切にレスポンスすることはできません。

常に、常に、常に非同期コールバック関数にエラーを戻します。"エラーコールバックを常にチェック" のルールに従っている限り、エラーは適切な場所で処理されます。

// 誤っている

function getRecord(id, callback) {
    http.get('http://foo/' + id, function (err, doc) {
        if (err) {
            return callback(err);
        }
        if (doc.deleted) {
            // getRecord関数の呼び出しで捕まらないでしょう
            throw new Error('Record has been deleted');
        }
        return callback(null, doc);
    });
}

// 正しい 

function getRecord(id, callback) {
    http.get('http://foo/' + id, function (err, doc) {
        if (err) {
            return callback(err);
        }
        if (doc.deleted) {
            return callback(new Error('Record has been deleted'));
        }
        return callback(null, doc);
    });
}

7. 同期呼び出しでエラーをキャッチ

これは本質的には以前のルールと同じです。例外をスローする可能性があり、同期関数を呼び出しているのであれば、非同期コードの内部には,非同期コードを呼び出すと、例外が発生する場合があります。

例えば、次のように

// 誤っている

function readJson(filename, callback) {
    fs.readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }

        // おっと！コンテンツがある場合は、この行は、例外がスローされる可能性が
        // 有効なJSONではない
        var data = JSON.parse(content.toString());

        return callback(null, data);
    });
}

// 正しい

function readJson(filename, callback) {
    fs.readFile(filename, function (err, content) {
        if (err) {
            return callback(err);
        }
        try {
            var data = JSON.parse(content.toString());
        }
        catch (e) {
            return callback(e);
        }
        return callback(null, data);
    });
}

8. コールバック慣例に固執する

非同期コードを取り扱うための他の戦略の使用を促進する少数派の声が、Node.jsメーリングリストとどこか他の所にいます。中には、 "ブロッキングスタイル"のAPIを提供もしてくれます。興味深いものですし、チーム内でpromiseやfiberを使用する可能性があると思いますが、Nodeのコールバックスタイルにこだわった上で検討してください。コールバックは、非同期関数の最後の引数であり、コールバックへの最初の引数はエラーになります。（発生した場合）

大多数の Node 開発者の大半はこのスタイルとコンセンサスに従っています。チーム外部の Node 開発者がモジュールを使用する場合、慣例に固執しているくらいの方が楽になるでしょう。

結論

これのほとんどは、おそらく常識的ですが、私はこれらのルールが役に立つことを願っています。

2013-01-11

OmegaTが起動時に日本語が豆腐（文字化け）になっているのをなおした

Linux OmegaT

OmegaTをLinuxでダウンロードしてくると、以下の用になっていることがあります。

日本語が豆腐になっていますね。。。orz

Javaでは有名？な豆腐問題らしいです。fallback fontを設定すれば改善されると言われたので、そのメモです。

環境は、FC16で、JRE付きではないものを使用している前提です。（起動スクリプト変更すればいいと思います）
JRE付きで、JRE内に同じような処理をすれば、なおるかもしれません。（試してない）

jvm内は、リンクばかりなので、環境に合わせて確認ください。
今回のフォントの指定は、VLゴシックを使用しました。

# mkdir -p /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/lib/fonts/fallback
# cd /usr/lib/jvm/java-1.7.0-openjdk.x86_64/lib/fonts/fallback/
# ln -s /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf ./
# ln -s /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf ./

で、フォルダ内の起動スクリプトのOmegaTをクリックすると。。。

おぉーーーー。なおったぁー　ﾜｰｲヽ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾉﾜｰｲ

他のJavaアプリで化けてるのもこれが利くかもですね。

2013-01-09

NetworkManagerを使用しながらブリッジするinitscript書いた。

Linux Network KVM

ノートPCなんか特にそうですが、無線とか、VPNの設定あると、NetworkManagerはかなり便利です。
で、やっぱりブリッジはしたいことが多いので、initscript書きました。結構便利になるかと思います。
テストは、FC16です。Deb系等他のディストリがわかってないんで、汎用かどうかは不明。。。
(openvpnのスクリプトを流用ですが。。。）

tunctlとbrctlが使える状況にしておいてください。Redhat系だと

yum install -y tunctl bridge-utils

だったかと。。。

適宜環境に合わせて、networkとインターフェースを変更してください。
(うちの環境だと、IntelNic増設してるので、p7p1ってのを使ってます。）

んで中身です。なんかおかしいとことか、こうしたほうがっていうのがあれば、ご指摘下さいm(_ _)m

#!/bin/sh

# bridge       This shell script takes care of starting and stopping
#               RedHat or other chkconfig-based system.
#
# chkconfig: - 23 76
#
# processname: bridge
# description: bridge create script.
# 
#
#
#
# author: dai_yamashita

### BEGIN INIT INFO
# Provides:             bridge
# Required-Start:       $remote_fs $syslog
# Required-Stop:        $remote_fs $syslog
# Default-Start:        2 3 4 5
# Default-Stop:
# Short-Description:    Bridge create script
### END INIT INFO

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="p7p1"

# Get physical ethernet interface IP address.
PROG="/sbin/ifconfig"
IPKEY="addr:"

PATTERN_IPV4="[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\$"

ifconfig_output=`$PROG $eth 2> /dev/null`

for check in $ifconfig_output; do
  check=`echo $check | egrep $PATTERN_IPV4`
  if [ -n "$check" ]; then
    ipaddr="$check"
    break
  fi
done

ipaddr=`echo $ipaddr | sed s/"$IPKEY"//gi`

#echo $ipaddr

eth_ip="${ipaddr}"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.xxx.255"
gw="192.168.xxx.1"
t=$eth_ip

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils tunctl
#################################

start_bridge() {

  tunctl
  for t in $tap; do
    ifconfig $t
  done

  brctl addbr $br
  brctl addif $br $eth

  for t in $tap; do
    brctl addif $br $t
  done

  for t in $tap; do
    ifconfig $t 0.0.0.0 promisc up
  done

  sleep 1

  ifconfig $eth 0.0.0.0 promisc up

  sleep 1

  ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast up

  route add default gw $gw $br
}

####################################
# Tear Down Ethernet bridge on Linux
####################################

stop_bridge(){

  ifconfig $br down
  brctl delbr $br

  for t in $tap; do
    tunctl -d $t
  done

  ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast up

  route add default gw $gw
}

####################################
# OPTIONS
####################################
case "$1" in
        start)
          echo -n "Starting Bridge"
          start_bridge
          ;;
        stop)
          echo -n "Stopping Bridge"
          stop_bridge
          ;;
        restart)
          stop_bridge
          sleep 2
          start_bridge
          ;;
        *)
          echo "Usage: $0 {start|stop|restart}"
          exit 1
          ;;
esac

2012-12-29

PostgreSQL 9.2にredis_fdwをインストールした記録

PostgreSQL

相変わらず、DBのインストールは以下のポリシーでやってます。
あ、あとソースコンパイル導入系は、Pacoを使って管理してます。

インストール:
/usr/local/pgsql/${pgsql_version}/

データベースクラスタ:
/home/postgres/${pgsql_version}/data

今回は、SL6.3のPostgreSQL 9.2.0で試してます。事前に、redis_fdwはhiredisが必要なので、インストールしておきます。

yum install -y hiredis-devel

で、FDW入れるなら、pgxnclient使うと簡単に入るわけですが、実際は、こんな感じ。。。

# pgxnclient install redis_fdw
INFO: best version: redis_fdw 1.0.0
INFO: saving /tmp/tmpjdIyEI/redis_fdw-1.0.0.zip
INFO: unpacking: /tmp/tmpjdIyEI/redis_fdw-1.0.0.zip
INFO: building extension
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fpic -I. -I. -I/usr/local/pgsql/9.2.0/include/server -I/usr/local/pgsql/9.2.0/include/internal -D_GNU_SOURCE   -c -o redis_fdw.o redis_fdw.c
redis_fdw.c:103: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
redis_fdw.c: In function ‘redis_fdw_handler’:
redis_fdw.c:130: error: ‘FdwRoutine’ has no member named ‘PlanForeignScan’
redis_fdw.c:130: error: ‘redisPlanForeignScan’ undeclared (first use in this function)
redis_fdw.c:130: error: (Each undeclared identifier is reported only once
redis_fdw.c:130: error: for each function it appears in.)
redis_fdw.c: トップレベル:
redis_fdw.c:321: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
redis_fdw.c: In function ‘redisBeginForeignScan’:
redis_fdw.c:480: 警告: implicit declaration of function ‘RelationGetRelid’
redis_fdw.c:544: error: 不完全型のポインタへの間接参照
redis_fdw.c:581: error: 不完全型のポインタへの間接参照
make: *** [redis_fdw.o] エラー 1
ERROR: command returned 2: make PG_CONFIG=/usr/local/pgsql/9.2.0/bin/pg_config all

だけど、ソースコンパイルしたら、うまく導入できたので、その記録。

まずは、環境変数を設定。（最初からやっとけよって？？複数環境とか別バージョン入れるとミスると痛いので。。。）

export PATH=$PATH:/usr/local/pgsql/9.2.0/bin
export PG_CONFIG=/usr/local/pgsql/9.2.0/bin/pg_config
export USE_PGXS=1

んで、ソースをcloneして持ってくると。

git clone https://github.com/dpage/redis_fdw.git

でcloneしたソースのブランチを見てみると、

git branch
   rREL9_2_STABLE
*  master

おー。。。9.2のstableあるじゃん！！ということで、切り替えて

git checkout REL9_2_STABLE

後は、makeしてインストール（Paco使ってるので、Pacoでインストール管理）

make install USE_PGXS=1
paco -D make install

んで、CREATE EXTENSIONをする。

su - postgres -c '/usr/local/pgsql/9.2.0/bin/psql -c "CREATE EXTENSION redis_fdw;"'
CREATE EXTENSION

/usr/local/pgsql/9.2.0/bin/psql 
psql (9.2.0)
Type "help" for help.

確認っと。

postgres=# \dx
                            List of installed extensions
   Name    | Version |   Schema   |                   Description                    
-----------+---------+------------+--------------------------------------------------
 plpgsql   | 1.0     | pg_catalog | PL/pgSQL procedural language
 redis_fdw | 1.0     | public     | Foreign data wrapper for querying a Redis server
(2 rows)

入ってる、入ってる。。。

あ、外部からの問い合わせの場合は、redis.confの

bind 127.0.0.1

は、

#bind 127.0.0.1
か
bind 0.0.0.0

に変更して下さい。

あとは、PostgreSQLさんに接続先を教えてあげて問い合わせ。

postgres=# CREATE SERVER redis_server
postgres-# FOREIGN DATA WRAPPER redis_fdw
postgres-# OPTIONS (address '192.168.xxx.xxx', port '6379');
CREATE SERVER
postgres=#
postgres=# CREATE FOREIGN TABLE redis_db0 (key text, value text)
postgres-# SERVER redis_server
postgres-# OPTIONS (database '0');
CREATE FOREIGN TABLE
postgres=# CREATE USER MAPPING FOR PUBLIC
postgres-# SERVER redis_server
postgres-# OPTIONS (password '');
CREATE USER MAPPING

postgres=# SELECT * FROM redis_db0 WHERE key = 'bid_price_hallname_1/123';
NOTICE:  Got qual key = bid_price_hallname_1/123
NOTICE:  Executed: KEYS bid_price_hallname_1/123
           key            |                                     value                                  
    
--------------------------+----------------------------------------------------------------------------
----
price | {"price":5000000000,"id":"xxx","session_id":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}
(1 row)

でも、

There is currently no support for non-scalar datatypes in Redis　such as lists.

リスト型使いたい。。。(ToT)