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 を前進させる手段である
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
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 のスライスでハマッたところ - Block Rockin’ Codes
intro 先日 GoのSliceもヤバイ - Qiita こんな記事をみて、別の挙動だけどスライスの内部を理解しきれていなかった頃のことを思い出した。 結構前に謎に思っていた挙動についての話。 以前この挙動を解説しようと思って、前提として書いたスライスの内部構造の記事が、 Go のスライスの内部実装 だったのですが、そっちを書き終わって満足してしまい、本題を忘れていました。 この挙動は、先のブログで説明した内容がわかっていないと、なかなか理解できないかも。わかってしまえば簡単ですが。 やりたいのは、関数側でスライスを操作したときの呼び出し側での結果。 順を追ってみてみます。 配列を関数内で変更する 関数は値渡しで、配列はそれ自体が値なので、まるっとコピーされます。 以下の例は、戻り値で返さないと、呼出側は変化しません。 package main import ( "log" ) func
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 のお
「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
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
次世代規格 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とい
"リアルタイム Web" に関するプラクティスのアウトプット - Block Rockin’ Codes
追記 11/12/26 MLのスレッドへのリンクが間違っていたので修正。 introduction WebSocket なんかをつかって、従来のステートレスな処理以外に、コネクションを継続するステートフルな処理が可能になりました。 これを利用すると、これまで実装が難しかったリアルタイムな表現を Web に持ち込むことができます。 そして、 WebSocket を用いたプログラムを作成する上で、Node.js と Socket.IO を用いる方法について、 今年はこのブログでも何度か紹介してきました。 今日は今年一年の集大成として、自分が色々試しながら得たリアルタイム Web に関する知識、技術などを、 ここにまとめてアウトプットしたいと思います。 今回お話しするのは、 東京Node学園 3時限目 : ATND で発表した下記内容の抜粋です。 Node Academy | "About Sl
クライアントとサーバの両方で使える JS コードの書き方 - Block Rockin’ Codes
追記 11/12/25 Bi ってそんなに一般的ではない、 Both-Sides JavaScript の方が、ということでまた変更しました。(side でなく side's') 11/12/04 Both Side JavaScript は変ということで、 BSJS=Bi-Side JavaScript に変更しました。 本文 CSJS と SSJS で両方同じ言語で処理が書けるメリットの 1 つとして、 書いた処理の共有があげられます。 (そこにメリットを感じない人もいるかも知れませんが。) 例えば Validater を共有 クライアントの状態をサーバで再現 などがあります。前者はそのままですね。 受け取った入力のバリデーションはサーバでは必須で、フィードバックを速くするためにクライアントでも同じように行う場合があります。 今まではサーバで書いたバリデーションと同等のものを JS に
node.jsのSocket IO-nodeでWebSocket - Block Rockin’ Codes
前回は、pywebsocketでのWebSocketを紹介しましたが、HTML5 hack-a-thonでは結局node.jsの実装である Socket IOとSocket IO-nodeを使いました。 こちらも備忘録。 node.js node.jsはいわゆるサーバサイドJavaScriptの一つで、最近にわかに注目を集めてる(?)技術です。 主な特徴は もちろん全てJSで書ける。 コアがGoogleのV8エンジンで速い イベント駆動I/O node.jsの概要自体は、こちらのPREZIを使ったプレゼンが簡潔で分かりやすいかと思います。 Introduction to node.js by Toshihiro Shimizu on Prezi 丁度今日、node.jsの48時間耐久Hack-a-thonが開催されていました。 その名も、Node.js Knockout。@mesoさんも参
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
