ここ一ヶ月ぐらいからJavaScriptが注目されているようだ。理由は簡単で、GoogleのJavaScriptエンジンを使ったアプリケーション・サーバーであるnode.jsの性能が高いと主張されているからだ。 地味にブームになりつつあり、Ajaxのようにウェブ開発の現場に定着するかも知れない。多数のブログで紹介がされている。現状のその特徴を振り返りつつ、node.jsが普及するかを考察してみた。 1. JavaScriptは、ブラウザ発の人気スクリプト言語 JavaScriptは、LiveScriptとして1995年にNetscape Navigatorというウェブ・ブラウザに搭載されたのが始まりで、すぐに政治的な理由でJavaScriptに改名された。1996年には、その基本的な文法がECMAScriptとして、ECMA-262とISO/IEC 16262で定義されている。言語仕様が簡

2024年夏 かばんの中身記録 みんな大好きかばんの中身。 当然私も大好きで、人様のブログ記事やSNS投稿を飽きもせず読み込みまくっています。なぜこんなにも見飽きないのか… 自分も以前同じようにかばんの中身の記事を書いたんですが、気づけばもう３年前！去年くらいの気分だった、月日がたつの…

RackspaceのEric Evans氏がCassandraのメーリングリストに投稿した内容によると、Cassandra 0.8の最大の特徴は、SQLに似た問い合わせ言語のCQL（Cassandra Query Language）をはじめて搭載したこと。 また、これまで要望の多かった分散カウンターを実装し、ノード間の暗号化通信を実装したことでパブリッククラウドなどの環境でのセキュリティが高まったとしています。 CQL 1.0では、USE、SELECT、UPDATE、DELETE、TRUNCATE、DROP、BATCHなどのキーワードを備えており、SQL文のようにデータベースの内容を操作できるとのこと。Python、Java、Node.js用のドライバーが提供されています。 CQLについては、第16回Cassandra勉強会での@yukim氏の資料「CQL」が公開されています。分かりやすく

昨日に引き続き、いざ！part2なのだ。 前回では node.js と v8 の結びつきまでを書いたので、今日は Non-Blocking I/O の話を。 Non-Blocking I/O という言葉からブロックしない I/O をイメージするのはたやすい。でもこれを実現しようとなるといろいろとまあ面倒くさいんだよね。 それを解決する常套手段で言うとファイルディスクリプタ（ネットワークならソケットだね）を開いてそれをselectシステムコールの監視対象に加えておき、selectを呼び出すことで監視するっていう方法がある。こうすると何が嬉しいのかファイルディスクリプタが２つある場合で考えてみよう。 まずAとBというファイルディスクリプタを監視対象とする。 selectシステムコールを呼び出し、そのどちらかが読み出し準備完了となっていないかを確認する。 もしどっちも準備できていなかったらプロセ

期せずして久々の更新になってしまった。ブログを書く気がなくなったとかそういうのではなくてただ単に忙しかっただけ。その間、まぁ仕事が予期せぬ方向から炎上してみたり、事故をもらって愛車が全損したり（フロントガラスが全面熱線入りなんていう変なオプションなどを諸々付けていたからお気に入りだったのに）と決して良いことばかりで忙しかったわけではないけどね！ で、今回は node.js のお話。異様な盛り上がりを見せているものの、じゃぁそれっていったい何かというと「JavaScriptを用いたNon-blocking I/O環境」という非常にシンプルなものだ。 その根底には「うまくスケールできること」と「動作が速いこと」という理念が見受けられる。 まず「うまくスケールできること（多量のアクセスを捌けること）」を解決するにあたり、まずはスレッドモデルか、イベントループかという問題があった。そこで auth

サーバサイドJavaScriptにはNode.js以前にもいくつかの実装がある。ちょっと前に注目されかけたものだと、現在はAppcelerater社に買収されたAptana社が出していたJaxerなどがあるが、きちんと調べるとRingoJsやnarwhalやv8cgiなど選択肢の一つとして数えられるサーバサイドJavaScript実装がいくつかある。ただ、これらはNode.jsのように注目を浴びているわけではない。 Node.jsとこれらの既存のサーバサイドJavaScriptの違いは、他のサーバサイドJSの動作モデルが既存のサーバサイドのものと変わらないのに対して、Node.jsの場合はそうではないから。具体的には、HTTPコネクションのハンドリング戦略が違っていて、既存の動作モデルが1コネクションに対して1プロセス/スレッド消費するのに対して、Node.jsの場合は非同期I/Oを用いて

2011-05-23 09:23 追記：Mac のデフォルトの Vim では動作しないとの指摘をブコメで受け、スクリプト中の OS 判定コードを修正しました。 Vim で保存した UTF-8 エンコーディングのテキストファイルにマルチバイト文字が含まれているとき、 Quick Look を使うと“標準テキスト”と表示されるだけで中身が見えないことがあります。また、そのようなファイルはテキストエディットで開こうとしても こんなダイアログが出て編集できません。 原因は、 Quick Look やテキストエディットがファイルの拡張属性を参照してエンコーディングを判別しているためです。一般的な Mac のアプリケーションでテキストファイルを保存すると、 UTF-8 エンコーディングを表す拡張属性がファイルに付加されます。しかし Vim ではこのフラグが立てられません。そのため、ファイルに ASCI