タグ

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

  • 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

  • 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

    Ajax 誕生から 10 年とこれから - Block Rockin’ Codes
  • Extensible Web を支える低レベル API 群 - Block Rockin’ Codes

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

  • ServiceWorker を使った XHR のモックテスト - Block Rockin’ Codes

    Intro 似た話は既出なのでご提案にはならないけど、PoC として一応ライブラリっぽくしてみた。 タイトルの通り XHR のリクエストに対して、任意のレスポンスを返すことによって、 再現の面倒なエラー処理などのテストを、 Local Proxy 無しで実現する方法のメモ。 というか、これ自体がブラウザ上の JS だけで完結する Local Proxy と言えるかもしれません。 ざざっと書いただけなので、API というか使い方もまだ適当というかどうしようか考えてるところです。 今これが使えるブラウザ自体がそんなにないので、 SW の実装が普及するまでにもう少しまともにしておきます。 Jxck/response-injection · GitHub 色々踏んだので、 Service Worker 使う際の参考になればと。 モチベーション Service Worker(SW) には色々な機能が

  • 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 } ... 関数の中では、各要素の長さ毎に読み込んで、読み込みに失敗したらエラーを

    Golang Error Handling lesson by Rob Pike - Block Rockin’ Codes
  • 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 の実装も始まっています。(詳細は後述) しかし

  • 「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
  • 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,佐々木大輔,横路隆,加来純一,山伶,大平武志,米川健一,坂登史文,若原祥正,和久田龍,平栗遵宜,伊藤直也,佐藤太一,高橋俊幸,海野弘

    Web+DB Press vol.82 で Go の特集を書かせて頂きました #wdpress - Block Rockin’ Codes
  • Go のスライスでハマッたところ - Block Rockin’ Codes

    intro 先日 GoのSliceもヤバイ - Qiita こんな記事をみて、別の挙動だけどスライスの内部を理解しきれていなかった頃のことを思い出した。 結構前に謎に思っていた挙動についての話。 以前この挙動を解説しようと思って、前提として書いたスライスの内部構造の記事が、 Go のスライスの内部実装 だったのですが、そっちを書き終わって満足してしまい、題を忘れていました。 この挙動は、先のブログで説明した内容がわかっていないと、なかなか理解できないかも。わかってしまえば簡単ですが。 やりたいのは、関数側でスライスを操作したときの呼び出し側での結果。 順を追ってみてみます。 配列を関数内で変更する 関数は値渡しで、配列はそれ自体が値なので、まるっとコピーされます。 以下の例は、戻り値で返さないと、呼出側は変化しません。 package main import ( "log" ) func

  • 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
  • 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 =

  • そうだ、と思い立って京都で Go のハンズオンしてきました。 #gokyoto - Block Rockin’ Codes

    Intro 東京であったとある勉強会で、 @shokiri さんに「京都に来てください」と言われたので、「高倉二条連れてってくれるならいいです」 と二つ返事で引き受けたので、タイトルの通り京都にいって Go のハンズ・オンしてきました。 Go勉強会 そうだ京都、行こう ハンズオン資料 想定レベルは、他の言語経験はあるけど Go は初心者であること。 前提としては、環境構築済みで Tour Of Go の演習以外をひと通りやってること。 として、資料を作成しました。 基的には、各言語仕様を細かく見るというより、とにかく手を動かして動くものを作っていくパターンです。 その方がやってて面白いしね。 テーマはタスク管理ですが、それはおまけで、 Go の言語仕様と標準モジュールをガンガン触りながら、イディオムや考え方を解説していきました。 黙々と課題をこなしている。 #gokyoto pic.tw

    そうだ、と思い立って京都で Go のハンズオンしてきました。 #gokyoto - Block Rockin’ Codes
  • Go の Generator を channel と closure で速度比較(または Go でのアトミック処理イディオム) - Block Rockin’ Codes

    追記 この記事は元々 Go のイディオムとして、いわゆるジェネレータの実装がどうできるのかを軽い気持ちで書いただけで、速いから「Closure を使いましょう」などと一言も言ってなかったのですが、一方が channel であったため原子性についての言及がいくつかありました。 自分としては、ローカルのちょっとしたツール(shell の代わりくらい) の中で使ってただけなので、並行性には言及するつもりがそもそも無かったのですが、自分もそうした前提を書いていなかったのにも原因があります。 例えばこの記事が「グローバルシーケンス」の実装例として参考にされ Web アプリにでもコピペされて、バグの原因になったりでもしたらマズイので大幅に追記します。 (正直ロックを使った排他制御はあまり得意では無いですが。。) Intro 無限に連番を生成するロジックをジェネレータとして組むときに、 Go の場合は二

  • ジェネレータの解説と非同期への適用 - 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
  • 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
  • これからの 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 の破壊」などという想定外に振り切った音に見て取れるかと思

    これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2014) - Block Rockin’ Codes
    clavier
    clavier 2013/12/12
  • Go でベンチマーク - Block Rockin’ Codes

    Intro Go にはベンチマークを取る仕組みが標準で備わっています。 テストを書く仕組みも標準で備わっており、 testing モジュールと go test コマンドで行いますが、 ベンチも同じような形で実行することができます。 今回は簡単なベンチ取り方を紹介します。 テストについては、そのうちちゃんと触れます。 参考ソースとして、こちらを使います。 https://github.com/Jxck/swrap 対象のコード 例えば以下のようなコードがあって、そのベンチを取るとします。 // swrap.go type SWrap []byte func (sw *SWrap) Add(a byte) { *sw = append(*sw, a) } func (sw *SWrap) Len() int { return len(*sw) } Slice にメソッドを生やしただけです。 ベ

    Go でベンチマーク - Block Rockin’ Codes
  • Chrome Socket API で WebSocket - Block Rockin’ Codes

    intro Chrome Canary で Socket API が listen() をサポートしたってことで、 ブラウザ上にサーバを立てるという矛盾した行為が、 にわかに流行っているようです。 HTTP Server on Chrome Socket API で、以下のようにするとサーバが立てられて。 クライアントからアクセスすると HTTP が配信されたりします。 Chrome Socket API Server しかし、 何故か accept() が一回しかリクエストを処理できず、 現状一回処理したら立ち上げ直す(= Chrom 再起動?) しかないので、 仕方なく accept() をその都度行わないといけない状況です。 (多分そのうち改善されるんだろうと思います。) WebSocket Server on Chrome Socket API ということで、動くか確かめて見たくな

    Chrome Socket API で WebSocket - 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
  • 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