はてなブックマーク

Intro WebRTC 関係で、 NAT 越えの際に必ずお世話になる STUN について。 STUN まず STUN 関連の RFC では大きく 2 つある(7350 は除く) https://tools.ietf.org/html/rfc3489 https://tools.ietf.org/html/rfc5389 後者が前者の更新版なので、前者を旧仕様、後者を新仕様と呼ぶことにする。 新旧どちらの仕様も STUN であり、 NAT 越えに使うという雑な説明の上では同じなのだが、 この二つは更新とはいえかなり違うものになっている。 旧仕様の範囲 まず、旧仕様では STUN は以下の略だった。 Simple Traversal of UDP Through NATs つまり、 UDP で NAT を超えるためのプロトコルとして定義されており、 実際にそのための方法が定義されている。 具

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? セキュキャン 2015 高レイヤートラック(Jxck) 本資料は、セキュキャン 2015 高レイヤートラックの講義資料です。 セキュキャン参加者であるセキュリティエンジニアの卵を対象に、 Web のセキュリティの知見が、実際どのように Web アプリ開発に反映されているか、もしくはどう反映すべきかを、フレームワークの視点から解説することを目的としています。 将来、 Web のセキュリティに興味を持ったエンジニアが、その知見を多くの開発者に啓蒙する手段として、フレームワークに反映するというのは非常に有効な方法です。 ここではその実例として

DNS HTTP のリクエストも実際は、サーバとの TCP 接続の確立が必要になる。 そのためには、ホストを DNS で名前解決しないといけない。 この DNS もチューニングが進んでいくと気になる存在になる。 特にクライアントが DNS を設定している場合は、それ自体を速くするみたいなことはしにくい。みんなが 8.8.8.8 にしているとも限らないし、Web アプリというレイヤで見ると手を入れにくい部分だった。 DNS Prefetch 最近のブラウザは、例えばページにリンクが埋め込まれていれば、そのリンクのドメインを先に解決しておいてくれる。つまり、リンクをクリックした時点では、すでに名前解決が行われている状態にできる訳だ。 ドメインの解決は、パケットが飛ぶ訳だけどそのペイロードは Web の中で言えば結構小さい部類だし、結果は TTL の間はキャッシュされるのですぐ次のページで使われ

Web のパフォーマンスの今 自分の持っている Web のパフォーマンスに関する知識を、一旦全部吐き出してまとめたいと思っていたので、それをやってみようと思う。 予定 この辺が頭にはある。 Metrics TCP TLS Rendering Prebrowsing Async/Defer Cache Priority HTTP2 QUIC とりえず、思いついた順に書いて後で整理する。 スタンス まずは知識のダンプを目的としたい。 デモとか実際の計測細かく作ると時間がかかるので、まず書くだけ書いて、やるとしても後でやる。 あといつも、自分で書き溜めて、見直して、書き直して、、、とやっていて気がつくと飽きて出さずに終わることが結構多いので、 今回はとにかく出して、追記や修正は後からがんがん更新していく感じにしたい。 更新履歴は Qiita で勝手に残るので、そこに任せる。 書いたものリスト こ

// $ babel-node --optional es7.decorators index.js class Assert { private(target, name, descriptor) { let value; descriptor.set = (val) => { value = val; } descriptor.get = () => { return value; } } required(target, name, descriptor) { let original = descriptor.set; descriptor.set = (val) => { console.assert(val !== undefined, `${name} is required`); original(val); } } validate(target, name, descr

// $ babel-node --optional es7.decorators index.js class Counter { constructor(initial = 0) { this.current = initial; } @contract up(i) { this.current += i; return this.current; } } function contract(tar, name, desc) { // 事前条件 function before(i) { console.assert(i > 0, `arg for ${name} should be positive value`); } // 事後条件 function after(result) { console.assert(result > 0, `result of ${name} shou

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Web のパフォーマンス継続モニタリング環境 intro Web の健康状態を把握するためには、きちんとしたモニタリング環境を整える必要がある。 正しくメトリクスが測定できていないと、正しくボトルネックの把握ができないし、チューニングの副作用も正しく把握できない、アプリの変更の影響もわからないし、負荷対策もできない。 単にパフォーマンスチューニングだけのためではない。が、パフォーマンスチューニングには必須、という関係。 そして、メトリクスは一回適当に取っただけでは正確とは言えず、やっぱり定期的な取得が必要になる。 この辺のノウハウは、サ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

Go では FILE や LINE はありません。 これは、プリプロセッサを省いてコンパイルスピードを早めたいかららしいです。 しかし、 Go 標準の log モジュールは 以下のようにフラグでこれらを出力できます。 package main import "log" func main() { // どちらかを指定 log.setFlags(log.Llongfile) // full file name and line number: /a/b/c/d.go:23 log.setFlags(log.Lshortfile) // final file name element and line number: d.go:23. overrides Llongfile log.Println("debug log") }

Go の select loop で Chan を扱うときの小ネタ。 擬似乱数的な case は上から評価されるけど、その結果実行可能な case が複数ある場合は、そのどれかが選ばれる。 どちらが選ばれるかは実行環境依存。 func main() { c := make(chan int) go func() { for { select { case i := <-c: print(i) // 0, 1 のどちらかがランダムで表示される } } }() for { select { case c <- 0: case c <- 1: } } }

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

JavaScript のテスト 書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通に

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この投稿は、 JavaScript Advent Calendar 18日目の記事です。 更新履歴 こちら をご覧下さい JavaScript の書き方をアップデートする JavaScript Good Parts で書かれているような JS の書き方は、古くなりつつある部分も多いです。 正直なところ、自分はあの本が「今でも」良書だとは思っていません。 初学者に勧めることもしません。まんべんなさと普遍性と客観性から「パーフェクト JavaScript」 を勧めています。 その頃と比べると、 JavaScript をとりまく環境は変わりました JavaScript の進化に合わせて書き方もアップデートしていくべきなので、今回は分かりやすいしきい値として 「IE10 以下を切れるとしたら」 という前提で、列挙してみます。 たとえば XHR2 や File API に依存したサービスをやる場合な

余談 余談ですが, 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です. プライオリティ制御 この記事は HTTP2 Advent Calendar の 13 日目の記事です。 初回は、執筆時点での最新ドラフトである HTTP2-draft16 のプライオリティ制御(Priority Control) について解説します。 プライオリティとは HTTP2 における Priority = 優先度の制御とは、 Stream に対して優先度をつけることによって、ブラウザなどが先に欲しいリソースを、サーバに先に通知する仕組みです。 以下のような制限があります。 プライオリティはクライアントがサーバに送る サーバは優先度を無視しても構わない(必須ではない) 優先度は配分であり、実際にはフロー制御によるリソース消費の割合を指定するようなイメージ。

<form id="fileUpload" name="fileUpload" method="post" action="/server"> <input type="text" name="fileName" value="memo.txt"> <input type="file" name="file"> <input type="submit"> </form> <script> var fileUpload = document.getElementById('fileUpload'); fileUpload.addEventListener('submit', function(e) { e.preventDefault(); var xhr = new XMLHttpRequest(); xhr.open('POST', '/'); xhr.send(new FormData

HTTP2 のフロー制御 この記事は HTTP2 Advent Calendar の 1 日目の記事です。 初回は、執筆時点での最新ドラフトである HTTP2-draft16 のフロー制御(Flow Control) について解説します。 余談ですが, 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です. 更新 @kazu_yamamoto さんに指摘頂いた点を反映しました。 @kiri__n さんに指摘頂いた点を反映しました。 詳細については 更新履歴 をご覧下さい。 フロー制御 HTTP2 では、同じホストへの複数のリクエストを、同一の TCP コネクション上にストリームという単位で多重化することができるようになりました。 フロー制御とは、例えばひとつのストリームがリソースを占有してしまうことで、他のストリームがブロックしてしまう

タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、

HPBN at #mozaicfm 11/4(火) に Google で開催される "ハイパフォーマンスブラウザネットワーキング ミートアップ" では、著者である Google Developer Advocate の Ilya Grigorik を迎え、キーノートとトークセッションをお願いする予定です。 HPBN は、 Web に関わるネットワークの技術を十分に網羅しており、専門性も高く内容が濃い書籍で、この書籍をテーマとした輪読会も各所で開催されています。 今回は、このトークセッションを mozaic.fm の公開収録の形で実施させていただき、いつもの様に、彼自身の話や、書籍 HPBN の話、最近のブラウザネットワーキング事情についてのアップデートを聞くとともに、みなさんから事前に募集した質問を紹介したいと思います。 そこで、今回もここで Ilya への質問を募集します。 (録音の状態

Go でクロスコンパイル Go の特徴であるクロスコンパイルの便利さと、その方法はよく語られますが、意外に「そのための準備工程」が知られてない気がしたので、ここで再度クロスコンパイル自体の便利さと、クロスコンパイル方法、そしてその準備方法を書いておきます。 クロスコンパイルの旨味 Go は、 1 つのソースコードから様々な OS 向けのバイナリを生成するクロスコンパイルをサポートしています。しかも、対象の OS が無いとビルドできないわけではなく、例えば Mac で Windows 用、 Linux 用、 Plan9 用のバイナリを一気に生成するといったことができます。 しかも、 32bit マシンで 64bit 用のバイナリを生成することもできます。 "Write Once Run Anywhere" でお馴染みの Java との違いは、 Java の場合は Class ファイルという形