Head of Line Blocking - High Performance Web 2015 - Qiita
二つの head of line(HOL) blocking Web 周辺のコンテキストで (HOL blocking) と言うと、実際には二つの種類がある。 HTTP での HOL Blocking TCP での HOL Blocking この二つは違うものなので、話す場合は「どの」レイヤでの話なのかは明示したい。 HTTP の HOL Blocking HTTP/1.1 のリクエスト-レスポンスの組は、常に順番を保ち同期的に行われる必要がある。 具体的に 1 つの TCP コネクション上で、 3 つの画像(a.png, b.png, c.png) を取得する場合、 HTTP リクエストは以下のようになる。
Golang の sort パッケージ - Qiita
intro sort パッケージは slice などをソートするデフォルト実装や、独自の比較ロジックを定めるインタフェースなどが提供されています。 Go のインタフェース、継承による拡張などの考え方的にも面白いので解説メモ。 Sort function sort パッケージには Sort 関数が定義されている。 そのシグネチャは以下。 つまり、ここに sort.Interface インタフェースを満たしたものを渡すと、中で Quick Sort, Heap Sort, Insertion Sort を、条件に応じて使い分け、いい感じに並べ替えてくれる。 Sort Interface sort.Interface のインタフェースは以下。 (Go では、メソッドを持っていればインタフェースは満たされる) type Interface interface { // Len is the num
ES7.decorator で契約プログラミング(design by contract) - Qiita
D言語の契約プログラミングサポートに触発された。 http://www.kmonos.net/alang/d/dbc.html http://www.kmonos.net/alang/d/class.html#invariants Dで実際どこまでできるかはあまりわかってないが、現実的にはこんな感じだろうか。 // $ 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
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
select loop の小ネタ - Qiita
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: } } } nil channel channel の case が nil だと、そこに case が存在しないのと同じ扱いにある。 これを、 chan の読み取りをストップするなどに使うことができる。 1 秒ごとに読み出しを停止/再開する例。 func
小さく始める isomorphic module pattern - Qiita
せっかく window や node/io の標準モジュールに依存していないロジックであれば、 ブラウザでも node/io で動くようにしておくと色々嬉しい。が軽視されている感がある。 俗に isomorphic な JavaScript と呼ばれている。 それを npm と bower で公開するのであれば、問題はモジュールシステムだ。 最小の isomorphic module pattern 一番シンプルで負荷の少ない方法。 まず、ライブラリを以下のように書く。 // lib.js function Lib() { // 変数は外に出さない } Lib.prototype.foo = function(){ return "foo"; }; this.Lib = Lib; // point
最近の Web 開発者が使ってるらしいサービス - Qiita
MDN のページのヘッダ部分に、開発者が使っているサービスについてのアンケートがあったので回答してみた。 内容は、開発の上で使える様々なサービスについてだったんだけど、その選択肢が知らないのもいくつかあっておもしろかった。 MDN のアンケートの選択肢にあがるってことは、今こういうサービスがメジャーなんだなーと思ったので貼っておく。 (ただし、 Code Hosting -> Github や IaaS -> AWS みたいな分かりきってるのは省く) ちなみにサーベイは以下。 load-test Loader.io LoadImpact.com Loadstorm.com browsertest SauceLabs BrowserStack W3C validators CrossBrowserTesting Browsera security Nessus WebInspect ? Ne
手軽な HTTP/HTTPS サーバコマンド - Qiita
http や https サーバをローカルにサクッと立てたい時の便利コマンド。 Local Server local に HTTP サーバを立てたい場合、よくこんなのが使われている。 ただ、あまり気に入ってなかった。 長い python のバージョンで変わる コマンドを https に変えても https サーバにはならない content-type を変えたい 特に HTTPS サーバは、 ServiceWorker 周りをいじる時に確認とかで便利なんだけど、証明書を作ったりが面倒。 ということで作り始めたコマンドが落ち着いて来たので載せておく。 http/https コマンド http か https と叩くだけでカレントにサーバが上がる。 デフォルトポートは 3000 で第一引数で指定もできる。 https は証明書の準備もいらない。 https の証明書はコマンドがその都度、自己証
HTTP2 のフロー制御 - Qiita
この記事は HTTP2 Advent Calendar の 1 日目の記事です。 初回は、執筆時点での最新ドラフトである HTTP2-draft16 のフロー制御(Flow Control) について解説します。 余談ですが, 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です. 更新 @kazu_yamamoto さんに指摘頂いた点を反映しました。 @kiri__n さんに指摘頂いた点を反映しました。 詳細については 更新履歴 をご覧下さい。 HTTP2 では、同じホストへの複数のリクエストを、同一の TCP コネクション上にストリームという単位で多重化することができるようになりました。 フロー制御とは、例えばひとつのストリームがリソースを占有してしまうことで、他のストリームがブロックしてしまうことを防ぐ、といった目的で行われます。
npm で依存もタスクも一元化する - Qiita
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
Go の Test に対する考え方 - Qiita
Go の Test に対する考え方 この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
