Capybaraというgemがあります。これはrspecなどと連携し、visit "/"; page.body.should have_content "あなたの予想に反して、このページが見えているでしょうか？"みたいに使うためのライブラリで、裏ではレスポンスをSeleniumやWebkitなどに渡してレンダリングしたりJavaScriptを実行するなどします。 Capybaraにはドライバという仕組みがあり、有名なものとしてはCapybaraでwebkitを使うためのgemであるcapybara-webkitがあります。poltergeistはCapybaraでPhantomJSを使うためのCapybaraドライバです。最近v1.1.0でCapybaraの2.x系のAPIに対応しました。 PhantomJSはQtWebKitを使ってheadlessでwebkitを扱うもので、公式に配布さ
先日開催された Kyoto.js #5 で LT をしてきました. crxel Emacs から Google Chrome を操作する crxel というライブラリを作っているので発表しました. 今回の発表ではこのライブラリを使ったデモとして Emacs から Google Chrome のタブを Anything で切り替える anything-chrome-tabs.el と, Emacs のカーソル下のシンボルをバックグラウンドで google 検索する google-eldoc.el を紹介しました. google-eldoc.el は全く役に立たないのですが, Emacs の操作にフックして Google Chrome を操作できると何か便利なことができそうな気がしています. Motivation Emacs には既に swank-js という Emacs から javascr
WebSocketを使ってゴニョゴニョしているのだが、handshakeの失敗時のエラーをどう扱うべきなのか、よくわからない。WebSocket Protocol の仕様と WebSocket API の仕様で書いてあることが違う。 protocol仕様を読む限り、サーバーはhandshakeを拒否する場合適切なHTTPエラーコードを返さなくてはいけない、と書いてある。が、クライアント側のウェブブラウザ上のjavascriptでそれを期待しているとエラーイベントからはHTTPエラーコードは受け取れない。WebSocketの異常終了コード1006が固定でセットされている。 そこでAPI仕様を読むと、これらを行わない理由が赤字で大きく書いてある。 オープンリダイレクタが設置されたサイトで脆弱性になるので、handshakeのレスポンスはHTTPとして扱わない。悪意あるスクリプトに攻撃の準備とし
WebSocket が、12月12日についにRFCになりました（RFC6455)。テキスト転送だけでなく、バイナリー転送もサポートされ、コネクションをキープするための ping/pongなどコントロールフレームも定義されました。rfcになる過程で様々なバージョンと、その実装系が出ていますので、そこのネゴシエーションの仕組みが入っていたり、以前は割と自由に使えそうだった subprotocolが、IANAにレジストレーションが必要になったりと、なかなかしっかりしたプロトコルに仕上がっている印象です。 さて、今年最後となる、今日のポストでは、このWebSocketにより、今後のWebはどうなっていくのかについて、僕が最近感じている妄想を書き連ねてみます。 WebSocketとは、いったい何なのか？ さて、WebSocketとは、いったい何なのでしょうか？この問に対して、一般的には、 WebでP
http://tily.no.de/telephone トップページ、部屋とニックネームを決めて開始する http://tily.no.de/telephone/sandbox 手軽に試す用 電話というか音声チャットなんだけど、Flash のマイクでとった音声を WebSocket 経由で送信して、受け取った側では Web Audio API とか Audio Data API とかで再生するというのを作った。Firefox と Chrome で動く。 はずなんだけど、no.de の SmartMachine のスペックが低いせいか、遅延のあるせいか相手側の音声がブツブツ切れて聴こえてしまう…。ローカルではちゃんと音声チャットっぽいことができているんだけど。 なんか色々他の人のコードを使ったり参考にしたりしたので書いておきます。 socket.io サンプルのチャットプログラム デザインと
また1つ、Node.jsベースのWebアプリケーションフレームワーク「SocketStream」が登場しました。6月23日にロンドンで開催されたHacker Newsのミートアップで発表されたようです（@makoto_inoueさん、情報提供ありがとうございます！）。GitHubのレポジトリにはバージョン0.1のソースコードと、何ができるかというサンプルコードを含む長大なドキュメントが公開されています。 このSocketStreamは、単にまたNode.jsでWebアプリケーションフレームワークが1つ増えたという感じではないようです。従来のものとは、設計がドラスティックに異なっています。 まず、名前から自明なように、WebSocketを基本としていて、SPA（Single Page Application）が作りやすいように設計されています。SPAとは、1ページのHTMLを読み込んだら、後
Powering realtime experiences for mobile and webBi-directional hosted APIs that are flexible, scalable and easy to use. We create and maintain complex messaging infrastructure so you can build the realtime features your users need, fast. Bi-directional hosted APIs that are flexible, scalable and easy to use. Get started today and find out what you can build with Pusher
Node におけるスケールアーキテクチャ考察(Scale 編)というエントリーを読んで、RedisはPub/Sub型通信をサポートしているという事を知りました。エントリーでも言及されているように、Pub/Subを使えば Node.js + WebSocket サーバをスケールする際に、中継サーバの役割を果たす事が出来るはずです。 そんな訳で実際に Node.js と Redis を使って Pub/Sub の実験を行なってみました。ユーザが別々のNode.jsサーバに接続していてもWebSocketを通してメッセージのやり取りを出来るようにします。 イメージとしてはこんな感じです。 下準備# Ubuntuの場合は apt-get で1発でインストールする事が出来ます。 $ sudo apt-get install redis npmでredisモジュールをインストールします。 $ npm i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluent + mongodb + node.js でwebアクセスの準リアルタイム解析 | Day After Neet