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 することで、
「次世代 Web カンファレンス」を開催します #nextwebconf
Intro 2015/10/18(日) に、「次世代 Web カンファレンス」を開催します。 名称: 次世代 Web カンファレンス 日時: 2015/10/18(日) 場所: 法政大学 hash: #nextwebconf 公式: connpass 参加費: 無料 Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか？」と「これからどうなっていくのか？」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあって
HTTP2 の RFC7540 が公開されました - Block Rockin’ Codes
Intro 今朝、ついにずっと策定作業が行われていた HTTP/1.1 の後継仕様である HTTP2 と、 関連仕様である HPACK が、 RFC として公開されました。 ついに HTTP2 RFC 7540 出た！！ #http2study / “rfc7540.txt” http://t.co/CuaVul98l3— Jxck (@Jxck_) 2015, 5月 14 それぞれ番号は 7540 と 7541 になります。 RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) RFC7541 - HPACK: Header Compression for HTTP/2 ちなみに HTTP/2.0 ではなく HTTP/2 が正式名称です。(マイナーバージョンアップでの HTTP/2.1 などはありません) 二年半 HTTP2 の
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
Extensible Web の夜明けと開発者が得た可能性の話 - Block Rockin’ Codes
Web based on Standards Web は誰のものでもありません。 だれかプロダクトオーナーがいてその人が意思決定するとか、そういうのとは真逆の成り立ちをしています。 標準的な仕様を決めて、その仕様に則って Web の世界は成り立っている。 政府が作るサイトも、 Twitter も、学生が作ったブログも、全部同じルールで作られている。だから繋がる。 これって結構凄いことだと、自分は思っています。 Standarization このルールの決め方にもルールがあって、ちょっと敷居は高いかもしれないけど、誰でも自由に参加して、自由に意見を述べることができる場があります。 標準化団体ってやつですね。 なんか一部の人たちが勝手にやっているように思えるかもしれないけど、それは選挙に行かない人の理論と同じです。 あなたが仕様について意見を持ってて、それが妥当であるならば、その発言は仕様を根
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 の実装も始まっています。(詳細は後述) しかし
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Web+DB Press vol.82 で Go の特集を書かせて頂きました #wdpress - Block Rockin’ Codes
update 2015/4/20: 技術評論社さんのおかげで、 無料で公開されることになりました！ intro タイトルのとおり、 Web+DB Press の vol.82 に 「はじめての Go」 というタイトルで特集記事を書かせていただきました。 Web+DB press vol.82 届いた。特集で「はじめての Go」を担当させていただきました。 初見ももちろん、「Tour of Go の次」を探していた方の参考になれば幸いです！ #wdpress #golangjp pic.twitter.com/UbUue18wlp— Jxck (@Jxck_) August 20, 2014 WEB+DB PRESS Vol.82 作者: 山口徹,Jxck,佐々木大輔,横路隆,加来純一,山本伶,大平武志,米川健一,坂本登史文,若原祥正,和久田龍,平栗遵宜,伊藤直也,佐藤太一,高橋俊幸,海野弘
ハイパフォーマンス ブラウザネットワーキング書評 - 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
これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2014) - Block Rockin’ Codes
Update 2014-01-19 振り返り CROSS2014 が無事終了しました。 以下ログです。ビデオは前のセッションとかぶっているので 35 分くらいからが本セッションです。 USTREAM: cross-a (35:00~) Togetter: 次世代 Web セッション #cross2014 Slideshare: next generation web talk cross2014 去年に引き続き、今年もなかなか密度の高い内容になったんじゃないかと思います。 プロトコル編では、普段なかなか表に出てこない方を中心にお呼びして、2013 年から今日までの流れを踏まえつつ、今起こっているプロトコル的な変化を浮き彫りにし、今後の HTTP2.0 の展望や QUIC の持つ意義などを話し合いました。 象徴的なのは「TCP/IP の破壊」などという想定外に振り切った本音に見て取れるかと思
次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes
intro 少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、 draft-ietf-httpbis-http2-00 が、IETF の httpbis ワーキンググループで公開されました。 このドラフトは Google から提案された仕様である SPDY が採用されています。 HTTP1.1 からのアップデート HTTP1.1 の RFC が提出されたのは 1999 年で、 13 年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、 HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。 これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、 そしてなによりも、 Web の使われ方が大きく変わり、 求められて
markdown のリアルタイムレンダリングツール markup をリリースしました - Block Rockin’ Codes
intro 最近は Readme やら執筆原稿などで markdown を使うことが結構多かったりします。 markdown をレンダリングするツールは色々あるんですが、 エディタは好きなものを使いたいので、自分でレンダリングして、 ブラウザで確認できる何かがあればいいなぁと思ってました。 そんな時、 Github が markdown のレンダリングを API としてやっていたことを知りました。 Markdown | GitHub API しかも、サーバから叩くぶんには認証などもなく、 5000 回/時も叩けるということで、 それを使ってリアルタイムにレンダリングするツールを作りました。 使い方 インストールは $ npm install markup $ markup readme.md [3000]これだけです。 流行りに乗っかって?、ググラビリティの低い名前でリリースしてます。 m
WebSocket サーバの実装とプロトコル解説 - Block Rockin’ Codes
intro なんだかんだ WebSocket を使ってるのに、 WebSocket サーバを自分で書いたことが無かったので、RFC も落ち着いてきたここらで、仕様を読みながら実装してみようと思いました。 "WebSocket サーバ 実装" とかでググると、 Socket.IO とか pywebsocket で WebSocket アプリ作って、「WebSocket サーバを実装」みたいなタイトルになってることが多いみたいですが、 (Apache に PHP で HelloWorld して、「HTTP サーバ実装しました」とは言わないよね。) この記事では、 WebSocket プロトコルをしゃべるサーバ自体を実装します。 といっても、全部やるのはちょっと大変だったので、基本的なテキストメッセージのやりとりの部分だけやって、エコーサーバができるところまでやりました。 完成版のソースは以下で
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 の環境管理ツール nodebrew - Block Rockin’ Codes
intro nodebrew は バージョンアップの速い node.js を、複数バージョン管理するためのツールです。 ruby の rvm や、 python の virtualenv、 perl の perlbrew などの node.js 版と思ってもらえれば良いです。 自分はこれまで nvm を使っていたんですが、今年初めあたりから全てのマシンで nodebrew に乗り換えました。 今日はこの nodebrew を紹介します。 既存の node.js の環境管理 既存の、ものとしては nvm nave n nodeenv などがありました。 それぞれにあった問題については、過去に愚痴を書いています。 簡単にまとめると以下です。 nvm bash向けに書かれてて、zshなどと相性が悪い場合がある。 nave node へのパスを通した子shellを起動するタイプで、子shellとい
"リアルタイム Web" に関するプラクティスのアウトプット - Block Rockin’ Codes
追記 11/12/26 MLのスレッドへのリンクが間違っていたので修正。 introduction WebSocket なんかをつかって、従来のステートレスな処理以外に、コネクションを継続するステートフルな処理が可能になりました。 これを利用すると、これまで実装が難しかったリアルタイムな表現を Web に持ち込むことができます。 そして、 WebSocket を用いたプログラムを作成する上で、Node.js と Socket.IO を用いる方法について、 今年はこのブログでも何度か紹介してきました。 今日は今年一年の集大成として、自分が色々試しながら得たリアルタイム Web に関する知識、技術などを、 ここにまとめてアウトプットしたいと思います。 今回お話しするのは、 東京Node学園 3時限目 : ATND で発表した下記内容の抜粋です。 Node Academy | "About Sl
PhantomJS で HTML のスライドを PDF にし SlideShare にあげる方法 - Block Rockin’ Codes
本文 最近は HTML 形式のプレゼンテーションツールも多くなってきました。 しかし、そうしたツールで作ったスライドはそのままでは SlideShare にあげることが出来ません。 もちろん HTML なのでサーバに上げて URL を共有することもできますが、 やはり、「終わったら SlideShare で共有」ってのは割と恒例になってるし、一元管理できるし、色々便利です。 方法としては、 HTML を PDF とかに直せれば良いのですが、 「見た目そのまま」で PDF 化するのは結構難しいです。 一番実直な方法は一枚づつスクリーンキャプチャを取る方法ですが、面倒です。 自分も色々試したんですが、なかなかうまくいかず。 しかし、 @t_wada さんが同じことに取り組んでおり、ヒントをもらったところ、成功したので紹介します。 今回使った方法は PhantomJS を使ってキャプチャ取得を自
node.js の modules wiki を見るときの便利ブックマークレット - Block Rockin’ Codes
表題の通り、Modules · joyent/node Wiki · GitHub を見るときに、便利(主に自分が) になるブックマークレットを書いてみました。 本文 Node.js のモジュールを探す方法としては大きく二つあって、 Modules · joyent/node Wiki · GitHub から探す npm から探す の二つがあります。(ローカルの npm コマンドでも見れるけど) 後者は npm に登録されているモジュールが検索できるので良いのですが、 Node.js の本家の Wiki にあるだけあって未だに前者のページもよく参照される気がします。 しかし、ここはあくまでも Wiki なので誰でも自分で作ったモジュールを好きに登録する事が出来ます。 そして自分で消しでもしない限り、基本はずっと残ります。 一方で、このページを見てわかる通り一応カテゴライズされていて、同じカ
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 のお
Socket.IO API 解説 - Block Rockin’ Codes
追記 11/7/31 Socket.IO v0.7 解説を最初に途中までで出す。 11/8/1 だいたい全部新機能なので '(新機能)' って書くのやめた。 11/8/4 オプションの設定周りを追記 11/8/6 認証周りを追記 11/8/12 スタンドアローンのサンプルを追記 11/9/27 Socket.IO v0.8 対応について追記 11/9/27 タイトルを Socket.IO API 解説に変更 11/9/27 翻訳サイトリンク追加 公式マニュアル翻訳サイト そういえば公式サイトの翻訳をフォークしたリポジトリで、それなりの更新頻度でやってます。 リポジトリの wiki も地味に訳しててこっちは結構役に立ちます。本記事と合わせてどうぞ。 本家 http://socket.io/ 翻訳ページ http://jxck.github.com/socket.io wiki https:/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
