タグ

ブックマーク / jxck.hatenablog.com (30)

  • Extensible Web を支える低レベル API 群 - Block Rockin’ Codes

    Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの?」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi

    yuiseki
    yuiseki 2015/02/10
  • Fetch API 解説、または Web において "Fetch する" とは何か? - Block Rockin’ Codes

    Update [14/11/11]: Chromium での実装が M40 からあるそうなので、末尾に引用追記させていただきました。 [14/11/12]: この記事を書くにあたって、色々なかたにレビューや助言を頂いたのですが、謝辞などが一切抜けてました、当にすいません。追記しました、ご協力頂いた方々当にありがとうございました。 WHATGW Fetch Spec WHATWG のメンテナンスするドラフトに Fetch Spec が追加されました。 もうすでに日語訳もあります、すばらしい。Fetch Standard 日語訳 この仕様には二つのことが定義されています。 "Fetching": Fetch するとは何か? の定義 "Fetch API": fetch() の定義 後者の定義に基づく fetch() という DOM API の実装も始まっています。(詳細は後述) しかし

    yuiseki
    yuiseki 2014/11/12
  • Stream API がブラウザにやってくる - Block Rockin’ Codes

    Intro 今日は、フロントのプログラミングスタイルに、にまた一つ大きな変化をもたらすであろう Stream という API についてです。 この仕様は現時点でまだ策定中であるため、 API は変更される恐れがある点にご注意ください。 Stream API 以前 「Node.js の Stream API で「データの流れ」を扱う方法」 という記事を書きましたが、簡単に言うとあれがブラウザにもやってくるという話です。 非同期処理おさらい もう何度も書いた話なので駆け足で。 JS はシングルスレッドでイベント駆動な世界なので、何をするにも非同期であり、コールバックを登録することで完了した結果を受け取る API が基です。 これは、ブラウザの DOM の API でも、 Node.js でも共通しています。 概念を疑似コードで書くと以下のような感じです。 console.log('1');

    Stream API がブラウザにやってくる - Block Rockin’ Codes
    yuiseki
    yuiseki 2014/11/01
  • 「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes

    ものすごく遅レスですが、LLDiver で @esehara さんの LT であった話。 forやめろ、あるいは「繰り返し」という呪縛から逃れるために 簡単に言うと、 1~10 までを出力する方法を複数考えるというもの。 for, while, 再帰, goto etc.. と出て、途中で終わっちゃったので結論はよくわかりませんでしたが、 Node ではどれも使わずにできるな、と思ったのでちょっと例を出してみます。 ちなみに、タイトルでネタバレしている通りイベントループの話です。 そしてよくある「イベントループとは何か」「なぜ止めてはいけないのか」「process.nextTick() とは何か」「setImmediate() と何が違うのか」 などを解説する良い例だったので、書いてるうちに実はそっちがメインの解説となりました。 サンプルの実行結果は Node v0.11.13 です。(書

    「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes
    yuiseki
    yuiseki 2014/09/13
  • Advanced Go Concurrency 3 つのパターン - Block Rockin’ Codes

    intro ちょっと時間が経ってしまいましたが、 Go研 vol.03 では、 Google I/O 2013 で行われてた Go のセッションの 1 つである下記をテーマに研究しました。 Advanced Go Concurrency Patterns 資料は以下です。 https://github.com/goken/goken/blob/master/goken03/goken03.md また、ここから順に実装しながら解説をしますが、その完成品はこちらにあります。 (commit 履歴も、記事にある程度沿っています。) https://gist.github.com/Jxck/5831269 スライドにそってやったのですが、セッションの内容は結構重ためだったので、 2 時間の Go 研だとちょっと消化不良ぎみだったのが反省点です。 そこで、このセッションの要である、並行処理に関する

    Advanced Go Concurrency 3 つのパターン - Block Rockin’ Codes
    yuiseki
    yuiseki 2014/07/13
  • ハイパフォーマンス ブラウザネットワーキング書評 - Block Rockin’ Codes

    Intro 執筆段階から、 Web で無料閲覧できた High Performance Browser Networking が、紙のとして出版され、その翻訳が完成したということで、献を頂きました。 原著には当にお世話になったし、 HTML5Experts.jp で書いた Make the Web Faster の連載でもよく参考にしたなので、日語で読めるようになったのは非常にありがたいですね。 当はレビュアの依頼を頂いたのですが、色々あって他の方に振ったりしてしまったので、せめて全力で書評させていただきます。 やっと献頂いたイリヤゆっくり読める。日語で読めるのは素晴らしい。 #http2study pic.twitter.com/Zy00OOy6ve— Jxck (@Jxck_) 2014, 5月 11 Make the Web Faster ところで、 Google

    ハイパフォーマンス ブラウザネットワーキング書評 - Block Rockin’ Codes
    yuiseki
    yuiseki 2014/05/19
  • なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin’ Codes

    注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか?」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT

    yuiseki
    yuiseki 2014/03/29
  • ジェネレータの解説と非同期への適用 - Block Rockin’ Codes

    update 2014-01-16 ご指摘頂いたので修正しました。ありがとうございます! @Jxck_ 動画すごくわかりやすかった!一個、重箱の隅っこなんだけど、convert関数のapplyしてるところ、fn.apply(fn, args) になってるけど fn.apply(this, args) が正しい気がしました!— Kazuhito Hokamura (@hokaccha) 2014, 1月 13 https://gist.github.com/Jxck/8380852 は修正済みです。動画の取り直しは勘弁して下さい(汗 - fn.apply(fn, args); + fn.apply(this, args); intro あけましておめでとうございます。 今年からはてなブログへ移行しました。 去年末くらいから流行っている Express の後継 Koa では JS の新機能ジェ

    ジェネレータの解説と非同期への適用 - Block Rockin’ Codes
    yuiseki
    yuiseki 2014/01/13
  • Go の並行処理 - Block Rockin’ Codes

    intro 先日の Go のカンファレンス GoCon で、 Go の並行処理周りについて発表させて頂きました。 Go Conference 2013 spring - connpass 具体的には Goroutine や Channel の話ですが、これらの機能は結構面白くて、いじって遊んでるだけでもわくわくします。 Go の並行処理は、設計方針がわりと特殊だと思うのですが、設計がシンプルなので分かるとそこまで難しくはないです。 (使いこなすのは、経験が必要そうですが) 今回話すにあたって色々調べましたが、発表時間の都合上省いたものもあるし、質疑応答で聞かれて応えられなかったこともあるので、 ここでまとめて置こうと思います。 発表資料 今回の発表資料はこちらです。 このブログの内容は、これをベースにします。 http://jxck.node-ninja.com/slides/gocon-

    Go の並行処理 - Block Rockin’ Codes
  • JSON - を node の Stream で整形する - Block Rockin’ Codes

    intro ちょっと反応が遅れてしまいましたが。 404 Blog Not Found:JSON - をnodeで整形する こちらの記事は Stream 厨として見逃す訳にはいきませんでした。 motivation JSONはJavaScriptから生じたものだからどうせならJavaScriptでやりたいし まあ、 JSON ですしね。 そのJavaScriptに今や標準搭載のJSON.stringify()は実はpretty printできるし 確かに stringify でできますね。(昔こちらにも書きました。) どうせなら標準入力だけではなくURIやファイル名で直アクセスしたいし 同意です。 しかし、実装を見てみると、、 (以下、主要な部分の抜粋) // stdout stdin.on("data", voorhees); // http http.get(req, functi

    JSON - を node の Stream で整形する - Block Rockin’ Codes
    yuiseki
    yuiseki 2013/11/14
  • LTSV の Stream Parser を Stream2 で書いてみた - Block Rockin’ Codes

    Update 2013/02/12 JSON => JSON Object に(JSON string でないものは)修正 LTSV LTSV が流行っていたんですが、完全に乗り遅れて Node も Go も実装は出てしまいました。 Node の方は sasaplus1 さんのものが こちら にあるんですが、パーサ関数のみで Stream ではなかったので、 Stream 実装を書いてみました。 ltsv-stream Jxck/ltsv-stream · GitHub npm でインストールできます。 npm install ltsv-stream Stream2 Node での Stream の重要性は、このブログでも何度か書いてきたと思いますが、この Stream は Stream2 という新しい実装に変わりつつある (Stability: 2 - Unstable, v0.9 以降

    LTSV の Stream Parser を Stream2 で書いてみた - Block Rockin’ Codes
    yuiseki
    yuiseki 2013/11/14
  • Stream.IO というものを作ってます。 - Block Rockin’ Codes

    追記 12/5/5 Stream, EventEmitter などを移植して chat サンプル動きました。Jxck's OutPut - Stream.io の example として Stream だけの Chat #nodejs_jp 文 この記事は、JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース) とは関係ありませんw ただ、前回そのアドベントカレンダーで書いた Node.js の Stream API で「データの流れ」を扱う方法 - Block Rockin’ Codes で扱った Node.js の Stream API について、そこからも色々考える機会がありました。 その結果、思ってたアイデアがあったので、形にしてみようと思い、ごそごそやり始めました。 (お前、そんなことやってる場合か?という異論は、う、、受

    Stream.IO というものを作ってます。 - Block Rockin’ Codes
  • Node.js の起動オプション、環境変数、npm start の話 - Block Rockin’ Codes

    Node は起動時に色々オプションをつけることができます。 面白いもの、有益なものあるんですが、あまり言及されてないので、 ちょっと紹介してみようかと思ってます。 最後の npm start の話は、それ単体で書いても良いかと思っていたんですが、 関連するし良い機会なので書きます。 そして、オプション周り興味がない方も、Node やってる方は最後の npm start の話だけでも、 読んでいただけるとと思ったりします。(知らない方が多いようなので) ここで紹介している Node のバージョンは v0.7.7 です。しかし v0.6.x あたりでは、 v8 のバージョンが古く、オプションが微妙に違います。そこは v0.6.12 での結果を載せている場合もあります。 -h まあ、とりあえず全ては -h から始まる。ということで、実行すると以下が出ます。 Usage: node [option

    Node.js の起動オプション、環境変数、npm start の話 - Block Rockin’ Codes
    yuiseki
    yuiseki 2013/05/31
  • Go の interface 設計 - Block Rockin’ Codes

    history 13/3/31 Tag について追加 intro Go を触ってて interface を用いた設計がまだまだよくわかってなかったので、一旦まとめることにしました。 Go には明示的な継承の機能は無く、 interface も例えば Java のそれとはかなり毛色が違うので、(Class ではなく) Struct の設計に結構癖があると感じます。 Go の interface は言語設計的にもかなり尖っていて、 Go という言語を強く特徴付けていると同時に、 Go 言語自体の開発者たちもこの機能をかなり重要視しています。 例えば、 Go の開発者の一人である Russ Cox 氏によれば Go's interfaces―static, checked at compile time, dynamic when asked for―are, for me, the most

    Go の interface 設計 - Block Rockin’ Codes
    yuiseki
    yuiseki 2013/04/14
  • Engine.IO からみる Socket.IO の今後 - Block Rockin’ Codes

    intro この記事は 東京Node学園祭2012 アドベントカレンダー : ATND の 24 日目の記事です。 Socket.IO の 1.0 が、出る出るといって全然出ないので、 やきもきしている方も多いと思います。 しかし、その裏では Engin.IO という、割りと良い感じの ファミリープロジェクトができていて、 ちょうど先日 RealtimeConf でもその話がありました。 これは Socket.IO にも繋がるはなしなので、 今日はその Engine.IO の話をします。 参考はこのへん、 https://github.com/LearnBoost/engine.io https://vimeo.com/52496621 Engine.IO と Socket.IO (と WebSocket.IO) Socket.IO は、 1.0 を視野に入れたあたりで、 関連プロジェクト

    Engine.IO からみる Socket.IO の今後 - Block Rockin’ Codes
    yuiseki
    yuiseki 2012/11/08
  • markdown のリアルタイムレンダリングツール markup をリリースしました - Block Rockin’ Codes

    intro 最近は Readme やら執筆原稿などで markdown を使うことが結構多かったりします。 markdown をレンダリングするツールは色々あるんですが、 エディタは好きなものを使いたいので、自分でレンダリングして、 ブラウザで確認できる何かがあればいいなぁと思ってました。 そんな時、 Githubmarkdown のレンダリングを API としてやっていたことを知りました。 Markdown | GitHub API しかも、サーバから叩くぶんには認証などもなく、 5000 回/時も叩けるということで、 それを使ってリアルタイムにレンダリングするツールを作りました。 使い方 インストールは $ npm install markup $ markup readme.md [3000]これだけです。 流行りに乗っかって?、ググラビリティの低い名前でリリースしてます。 m

    markdown のリアルタイムレンダリングツール markup をリリースしました - Block Rockin’ Codes
    yuiseki
    yuiseki 2012/08/26
  • WebSocket サーバの実装とプロトコル解説 - Block Rockin’ Codes

    intro なんだかんだ WebSocket を使ってるのに、 WebSocket サーバを自分で書いたことが無かったので、RFC も落ち着いてきたここらで、仕様を読みながら実装してみようと思いました。 "WebSocket サーバ 実装" とかでググると、 Socket.IO とか pywebsocket で WebSocket アプリ作って、「WebSocket サーバを実装」みたいなタイトルになってることが多いみたいですが、 (Apache に PHP で HelloWorld して、「HTTP サーバ実装しました」とは言わないよね。) この記事では、 WebSocket プロトコルをしゃべるサーバ自体を実装します。 といっても、全部やるのはちょっと大変だったので、基的なテキストメッセージのやりとりの部分だけやって、エコーサーバができるところまでやりました。 完成版のソースは以下で

    WebSocket サーバの実装とプロトコル解説 - Block Rockin’ Codes
  • Trigger と Stream ベースの Reactive スタイルについて考える - Block Rockin’ Codes

    intro 先日 Meteor について調べて発表するにあたり色々調べたり、そのあと何人かの方々とお話させて頂いた中で、 思うところが出てきたので、アウトプットしたいと思います。 Meteor について発表してきました。 - Block Rockin’ Codes Meteor 以前からも思っていたところもありますが、ちょうどいいので Meteor も対比に出しながら書いてみます。 Reactive Programming @naoya_ito さんも書いてたように、やはり一番大きいのはここだと思います。 Meteor.js - naoyaのはてなダイアリー 簡単に説明すると、 よく Excel に例えられますが、あるセルに他のセルの値を用いた計算式を埋めておくと、 その参照先のデータが変わった時に、式を埋め込んだセルの値も連動して変わるようなあれです。 プログラミングで見るなら、 例えば

    Trigger と Stream ベースの Reactive スタイルについて考える - Block Rockin’ Codes
    yuiseki
    yuiseki 2012/05/13
  • dotCloud で WebSocket - Block Rockin’ Codes

    dotCloud が WebSocket に対応したという発表がありました。 dotCloud Announces Native Support for WebSockets | dotCloud Blog dotCloud は多くの言語やミドルウエアに対応していて、 CLI からアプリがデプロイできる PaaS サービスといった感じです。 (Heroku なんかをイメージしてもらうとわかりやすいかも。) 早速、 Node.js + Socket.IO でどんなもんか試してみました。 アカウントは自分は結構前にとったんですが、今ならすぐ取得できるっぽいです。 CLI のインストール 専用の CLI があるのでそれをインストールするところから始めます。 http://docs.dotcloud.com/firststeps/install/ にある通り、 Python の pip で入れます

    dotCloud で WebSocket - Block Rockin’ Codes
  • Socket.IO or WebSocket を AmazonELB でバランスする検証 - Block Rockin’ Codes

    追記 12/2/29 検証コードと環境は後にしてとりあえず結果だけ書く 12/3/5 Socket.IO の RedisStore を使えばスケール可能なことがわかったので追加 12/3/11 検証コード追加 caution この検証は 東京Node学園 4時限目 - connpass でやった結果です。しかしその時の環境やソースが手元に無いので今再現ソースと環境を作っています。 2/28 現在分かってる結論だけ先に出しておきます。ソースは後で追って掲載します。その時点でもし結論が変わったりした場合は追記します。 また、この検証内容については一切責任は取りませんので、プロダクション等で使う場合はきちんと検証して下さい。 特に ELB の仕様が変わったら結果が変わると思います。結果が変わったことに気がついた方は教えて頂けると助かります。 code 検証コードを公開しました。 https://

    Socket.IO or WebSocket を AmazonELB でバランスする検証 - Block Rockin’ Codes
    yuiseki
    yuiseki 2012/03/05