neu.Node リリースのお知らせ
去年の暮れから準備を進めて来た neu.Node だが、ようやく今日、オープンソース・プロジェクトとして github に公開することができたので報告する。 https://github.com/snakajima/neunode 詳しくは README.md ファイルに書いたが、neu.Node は iOS 上で Node.js の API を使って作った マイクロ・サーバーを走らせる仕組みである。iTunes ストアで配布する iOS アプリに組み込んでも良いし、自分や仲間だけで楽しむ「手作りアプリ」に組み込んでいただいても良い。ライセンスは MIT で、ライセンス料フリーで、非営利・商用、無料・有料の区別なく使える。 neu.Node が目指すのは、新しい形の分散コンピューティングである。「モバイル・デバイスはクライアント、サーバーはウェブ・サービス」という垣根をとっぱらい、全てのモ
node.js モジュール ajmax の公開
東京Node学園祭2012 アドベントカレンダー １４日目の記事です。イベントの告知の意味も含めて、毎日だれかが１つづつ node.js についてブログで書く、という企画だそうです。 そこで本題ですが、github に ajmax という node.js モジュールを公開しました。npm にも登録してあるので、"npm install ajmax" でインストールが可能です。 詳しくは readme ファイルに書いてありますが、英語なので簡単に解説すると、AJAX（eye candy 的な AJAX ではなくて、実際に非同期にデータをサーバーから取得してページの一部をアップデートするタイプの AJAX） を活用した one-page web application を作るための micro MVC framework です。 これまでいくつか AJAX を駆使したアプリを作って来ましたが、
非同期APIと例外処理（node.js の domain について）
node.js のような非同期APIを使ったプログラミングに拒絶反応を示すエンジニアが多い理由の一つが、非同期APIと例外処理の相性の悪さだ。 Javascript の場合、例外処理はこんな感じに記述する。 function f(i) { try { throw new Error('an error #'+ i); } catch(e) { console.log('Error caught:', e.message); } } ところが、これに非同期APIが絡むと、とたんに分かりにくくなる。例えば下の例。 function f(i) { try { setTimeout(function() { throw new Error('an error #'+ i); }, 1000); } catch(e) { console.log('Error caught:', e.message)
node.js と thread hog の話（１）
ここ数日、 node.js で色々と作りはじめているのだが（node.js が一番力を発揮するのは、xmpp server や、push notification server のようにソケットを開きっぱなしにして非同期通信をするケースだと思うのだが、それについては来週のメルマガで詳しく解説する）、これで思い出すのが Microsoft 時代の「"thread hog" 退治」だ。 "thread hog" とは私が作った造語で、"memory hog" （メモリをやたらと使うプログラムのこと）と同じように、thread を不必要に作るプログラムのこと。 最初に出会った thread hog は、Microsoft が作っていた proxy server だった。コネクションが１０００を超すとやたらと遅くなり、しまいには落ちてしまうという欠点を持っていたため、一時は「出荷出来ないところか、
node.js と thread hog の話（３）
[前回までの話へのリンク] ・node.js と thread hog の話（１） ・node.js と thread hog の話（２） では、なぜ今頃になって HTTP Server の c10k 問題（もしくは、thread hog 問題）が顕在化したのだろう。 当時（９０年代の終わり頃）と比べて、もっとも大きく変わったのはCPUの性能である。クロック数は、数百MHzから数GHzへと一桁増えたし、マルチコア化もしている。CPU 性能だけ見れば、当時の数十倍の能力が出てしかるべきである。 しかし、実際の人生はそう簡単ではない。サーバーのパフォーマンスはCPU性能だけが決めるわけではないからだ。そこで、ボトルネックの一つとして注目されはじめたのが、thread の数なのである。 前回述べた様に、thread 一つあたり 2MB～8MB のスタック領域を仮想メモリ空間に確保しなければならな
Python入門：デコレータとは
前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
「戦略的OS」の開発がことごとく失敗している点に関する一考察
９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
