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
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 を支える低レベル API 群 - Block Rockin’ Codes
Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの？」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi
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 } ... 関数の中では、各要素の長さ毎に読み込んで、読み込みに失敗したらエラーを
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
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 =
なぜ 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
ジェネレータの解説と非同期への適用 - 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 の新機能ジェ
JavaScript のパフォーマンスと Sweet Spot の甘い罠 - Block Rockin’ Codes
本文 先日 JavaScript を高速化するには、 VM を知る必要があるんだろうと思い、 以下のような発言をしてみました。 とにかく今は 「V8の最適化の恩恵を受けるための JS の書き方」や「ホットスポットを温めて C よりも速い JS を書こう」という釣りっぽいけど釣りじゃない記事を @Constellation さんや @bad_at_math さんに書いていただく必要があるということでした！ 2011-10-23 21:53:44 via Echofon しかし、釣り針が小さかったためか、誰も釣れず。。 自分で調べろってことですよね、すいません。。 と思っていたら、先日下記のエントリが話題になりました。 そのものずばり、JavaScript を最適化する話。 mraleph-The trap of the performance sweet spot 先に感想を言うと、これはい
Go1.1 の Race Detector - Block Rockin’ Codes
intro 先々週、Go 1.1 がリリースされました。 いくつか新しい機能が入ったのですが、その中の Race Detector というのが面白そうだったので、 軽く調べてみました。 Race Detector この機能は、簡単に言うと「レースコンディションが発生していないか」を調べる機能です。 といわれると、なんだかすごい機能ですね。 そもそもレースコンディションとは、マルチスレッドプログラミングなどで、単一のリソースを複数のスレッドで共有した際に、競合状態が発生して、予期しない結果を生んだりする状態です。 レースコンディションによるバグは、再現生が低かったりするので、一般的にデバッグが難しいとされています。 そうした状態が起こらないように、がっちりロックを取り合ったり、そもそもメモリを共有せずメッセージパッシングするなど、別のパラダイムで情報を共有する方法が取られます。 Go も、以
次世代規格 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 の使われ方が大きく変わり、 求められて
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とい
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 を視野に入れたあたりで、 関連プロジェクト
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
"リアルタイム Web" に関するプラクティスのアウトプット - Block Rockin’ Codes
追記 11/12/26 MLのスレッドへのリンクが間違っていたので修正。 introduction WebSocket なんかをつかって、従来のステートレスな処理以外に、コネクションを継続するステートフルな処理が可能になりました。 これを利用すると、これまで実装が難しかったリアルタイムな表現を Web に持ち込むことができます。 そして、 WebSocket を用いたプログラムを作成する上で、Node.js と Socket.IO を用いる方法について、 今年はこのブログでも何度か紹介してきました。 今日は今年一年の集大成として、自分が色々試しながら得たリアルタイム Web に関する知識、技術などを、 ここにまとめてアウトプットしたいと思います。 今回お話しするのは、 東京Node学園 3時限目 : ATND で発表した下記内容の抜粋です。 Node Academy | "About Sl
Socket.IO と Express でセッションの共有 - Block Rockin’ Codes
Socket.IO のサーバは v0.7 からスタンドアローンでも立てられるようになりましたが、 Express のサーバ上に Socket.IO のサーバを同居させる構成は多いと思います。 しかし Socket.IO は Express が HTTP で確立したセッションとは別のコネクションを確立するため、 例えば、 Socket.IO で接続したユーザが Express で認証したユーザかどうか等が判別できません。 そこで、 Socket.IO で接続を確立時に Express のセッション用の Cookie を取得して、接続を識別できるようにし、 さらに Socket.IO でのやり取りが長くなっても、その間にセッションデータが切れることが無いように、更新する必要が有ります。 Socket.IOv0.7 を用いてこれを実現する方法が、こちらで紹介されていたので、試してみました。 So
QUnitの基本的な使い方 - but hopeful
[追記] 2013/9/1 三年前の記事が未だに読まれているようなので、一応書いておきますが、あれから色々変わってもっと良いものも出ています。 QUnit でも別に問題はないですが、今から QUnit を使うよりは http://visionmedia.github.io/mocha/:title=mocha] とかの方が個人的にはお勧めです。とにかく、今は色々あるのでもっと別の選択肢調べて見ることを個人的にはおすすめします。別に QUnit は使わないほうが良いとは言いません。 JavaScriptのテスティングフレームワークはいろいろありますが、自分は今主にQUnitを使っているので、少し使い方をまとめて見たいと思います。 [追記]今回作成したソースを上げました。ninja.js QUnit とは QUnitはもともと、jQueryをテストするために開発されたJavaScript Un
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
