ORTC が切り開く SVC サイマルキャストと WebRTC NV - Block Rockin’ Codes
intro 「ORTC って WebRTC がちょっと便利になるくらいなんでしょ？」くらいに思っている人が結構いるようだったので、現時点で予想される ORTC のもつ可能性 と、現状の WebRTC の問題点、そして WebRTC がこれからどうなっていきそうかについて、自分の理解している範囲で書いてみます。 ORTC については、ほとんど実装が無く(と書いてる間に Edge に入っちゃったんですが)まだドラフトやそこにある Example、 ML での議論などの公開情報を元に書いてるだけなので、間違っているものや、将来変わるところも有ると思います。よって内容は一切保証しません。 また、何か自分の理解がおかしいところなど有った場合は、コメントなどで指摘頂けると幸いです。 低レベル API 化へ WebRTC は少なからず「ブラウザで P2P テレビ会議」をするというユースケースを中心として
HTTP/2 Push を Service Worker + Cache Aware Server Push で効率化したい話 - Block Rockin’ Codes
intro このエントリは、 http2 advent calendar の 1 日目です。 http2study の分かってる人にとっては、「casper の JS 版を作ってる」だけで伝わるかもしれませんが、そうでない場合非常に話すべきことがたくさん有る気がするので、順を追って説明します。 今回理解すべき内容は以下 http2 push の問題点 cache aware server push bloom filter と golomb coded set cache fingerprinting dispenser.js (最初は casper.js と言ってたけど、よく考えると被ってるのがあるので dispenser.js に変えました) そして結論からいうと、まだまだ想定していた挙動まではいけませんでした。。 http2 push の問題点 http2 で push することで、
Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
Service Worker で prefetch - Block Rockin’ Codes
update 2015/3/31 @hirano_y_aa さんの指摘頂き訂正しました。 response.body の clone TextDecoder の利用 intro Service Worker の「オフライン以外」の利用第二弾です。 以前、 Service Worker で XHR のモック をしましたが、今回は Prefetch を実装してみようと思います。 prefetch とは 例えば /index.html が以下のような HTML だったとします。 <!DOCTYPE html> <meta charset="utf-8"> <title>title</title> <ul> <li><a href="1.html">1</a></li> <li><a href="2.html">1</a></li> <li><a href="3.html">1</a></li>
Ajax 誕生から 10 年とこれから - Block Rockin’ Codes
Intro 誕生と言うのが正しいか微妙だけど、多分誕生でいいと思います。 というのも、「Ajax」という名前の出典は以下の記事で、この記事が書かれたのが今日からちょうど 10 年前でした。 Ajax: A New Approach to Web Applications (当時から、 URL が一回変わっている) Web 初めてまだ 10 年たって無いんで、全部見てきたってわけではないですが、個人的にはちょっと思い出深い記事だったりするので、ちょっと振り返ってみます。 Ajax: A New Approach to Web Applications 筆者の Jesse James Garrett 氏は UX のコンサルティング会社である Adaptive Path の創立メンバーの一人で、 UX エンジニアです。 この記事の趣旨は、当時既にあった Google Maps や Gmail、G
Extensible Web を支える低レベル API 群 - Block Rockin’ Codes
Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの？」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi
#HTTP2Study の軌跡 - Block Rockin’ Codes
Intro この記事は HTTP2 アドベントカレンダー 24 日目 の記事です。 HTTP2Study HTTP2 Study は、2013年8月くらいから小さく小さく活動しているコミュニティです。 HTTP2 もまだ HTTP2.0 と呼ばれていた頃で、 Draft でいうと 04 くらいですね(今は 16)。 (ちなみに、現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です。) 仕様を策定してる HTTPbis としての議論は概ね片付いて、 HTTP2 の仕様は RFC にするための次のステップに移り、もし仕様を覆すような大きな指摘が無ければ、来年の頭にはこのまま RFC として公開されるかもしれないというところまで来ました。 そして今日はこの仕様策定をずっと追いかけてきた HTTP2Study がやってきたことを、簡単にまとめて
Golang Error Handling lesson by Rob Pike - Block Rockin’ Codes
Intro この記事は Go Advent Calendar 2014 の 15 日目の記事です。 例えばネットワークのフレーム処理的なものを書いている場合、以下のようなコードがよくでてきます。 There are many codes like this, while writing a Network Frame Parser program. var type uint8 err = binary.Read(r, binary.BigEndian, &type) if err != nil { return err } var length uint32 err = binary.Read(r, binary.BigEndian, &length) if err != nil { return err } ... 関数の中では、各要素の長さ毎に読み込んで、読み込みに失敗したらエラーを
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 の実装も始まっています。(詳細は後述) しかし
Stream API がブラウザにやってくる - Block Rockin’ Codes
Intro 今日は、フロントのプログラミングスタイルに、にまた一つ大きな変化をもたらすであろう Stream という API についてです。 この仕様は現時点でまだ策定中であるため、 API は変更される恐れがある点にご注意ください。 Stream API 以前 「Node.js の Stream API で「データの流れ」を扱う方法」 という記事を書きましたが、簡単に言うとあれがブラウザにもやってくるという話です。 非同期処理おさらい もう何度も書いた話なので駆け足で。 JS はシングルスレッドでイベント駆動な世界なので、何をするにも非同期であり、コールバックを登録することで完了した結果を受け取る API が基本です。 これは、ブラウザの DOM の API でも、 Node.js でも共通しています。 概念を疑似コードで書くと以下のような感じです。 console.log('1');
「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes
ものすごく遅レスですが、LLDiver で @esehara さんの LT であった話。 forやめろ、あるいは「繰り返し」という呪縛から逃れるために 簡単に言うと、 1~10 までを出力する方法を複数考えるというもの。 for, while, 再帰, goto etc.. と出て、途中で終わっちゃったので結論はよくわかりませんでしたが、 Node ではどれも使わずにできるな、と思ったのでちょっと例を出してみます。 ちなみに、タイトルでネタバレしている通りイベントループの話です。 そしてよくある「イベントループとは何か」「なぜ止めてはいけないのか」「process.nextTick() とは何か」「setImmediate() と何が違うのか」 などを解説する良い例だったので、書いてるうちに実はそっちがメインの解説となりました。 サンプルの実行結果は Node v0.11.13 です。(書
Go のスライスでハマッたところ - Block Rockin’ Codes
intro 先日 GoのSliceもヤバイ - Qiita こんな記事をみて、別の挙動だけどスライスの内部を理解しきれていなかった頃のことを思い出した。 結構前に謎に思っていた挙動についての話。 以前この挙動を解説しようと思って、前提として書いたスライスの内部構造の記事が、 Go のスライスの内部実装 だったのですが、そっちを書き終わって満足してしまい、本題を忘れていました。 この挙動は、先のブログで説明した内容がわかっていないと、なかなか理解できないかも。わかってしまえば簡単ですが。 やりたいのは、関数側でスライスを操作したときの呼び出し側での結果。 順を追ってみてみます。 配列を関数内で変更する 関数は値渡しで、配列はそれ自体が値なので、まるっとコピーされます。 以下の例は、戻り値で返さないと、呼出側は変化しません。 package main import ( "log" ) func
Go のスライスの内部実装 - Block Rockin’ Codes
History 14/05/09: Merge2 を修正しました。http://twitter.com/jbking/status/464659353945911297 Intro Go のスライスは、いわゆる LL 系の言語が持つ可変長配列の実装と似ています。 よって LL のような手軽な扱いをすることもできますが、その内部実装を知ることでより効率の良いメモリハンドリングができ、パフォーマンスを改善や、メモリーリークの防止などに繋がる可能性があります。 この辺は SWrap というライブラリを作りながら勉強したので、今回は、この Go のスライスの内部実装を解説します。 Go の配列 スライスを知るためには、まず配列について知っておく必要があります。 Go の配列は固定長のため、以下のように長さを指定して宣言します。 var arr [4]int func main() { arr =
Node.js の Stream API で「データの流れ」を扱う方法 - Block Rockin’ Codes
追記 11/12/6 少し誤字脱字を修正、加筆 11/12/7 koichik さんにコメントで頂いたリンクと、その内容について追記 11/12/7 edvakf さんに頂いた指摘を修正 本文 この記事は、JavaScript Advent Calendar 2011 (Node.js/WebSocketsコース) の 4 日目の記事です。 Node.js には Stream という API があります。 Stream はとても重要な技術で、 「Stream を制するものは、 Node.js を制す」と言っても過言ではありません。 実際、 Stream は Node.js が得意とする I/O の部分を使いこなすために、 押さえておくべき技術なので、今回はこの Stream について紹介したいと思います。 参考 Jxck's OutPut - Node.js の Stream I/O のお
なぜ 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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
