Intro Service Worker は、その立ち位置が非常に特殊なため、仕様を策定する上でも「どう振る舞うべきか？」を決定するのが難しい場合がある。 時には、開発者は「どう振る舞うだろう」と考えるか、感覚的な部分についてアンケートを行い、フィードバックを得ることが過去にもあった。 今回は、 Service Worker が絡んだ場合の BaseURI について、同様のアンケートが行われているので紹介する。ぜひ考えてみてほしい。
Service Worker における BaseURI の振舞いについての議論 - Qiita
Intro Service Worker は、その立ち位置が非常に特殊なため、仕様を策定する上でも「どう振る舞うべきか？」を決定するのが難しい場合がある。 時には、開発者は「どう振る舞うだろう」と考えるか、感覚的な部分についてアンケートを行い、フィードバックを得ることが過去にもあった。 今回は、 Service Worker が絡んだ場合の BaseURI について、同様のアンケートが行われているので紹介する。ぜひ考えてみてほしい。
フレームワークに見る Web セキュリティ対策 - Qiita
セキュキャン 2015 高レイヤートラック(Jxck) 本資料は、セキュキャン 2015 高レイヤートラックの講義資料です。 セキュキャン参加者であるセキュリティエンジニアの卵を対象に、 Web のセキュリティの知見が、実際どのように Web アプリ開発に反映されているか、もしくはどう反映すべきかを、フレームワークの視点から解説することを目的としています。 将来、 Web のセキュリティに興味を持ったエンジニアが、その知見を多くの開発者に啓蒙する手段として、フレームワークに反映するというのは非常に有効な方法です。 ここではその実例として Rails を例にとり、 Rails がこれまでに積み上げてきたセキュリティに関する知見を振り返るとともに、フレームワークとしてそれをどう取り入れているかを解説します。 Intro Web アプリケーションを開発する場合、 Web アプリケーションフレーム
graphite, grafana, sitespeed.io, diamond で継続 Web パフォーマンスモニタリング - Qiita
graphite, grafana, sitespeed.io, diamond で継続 Web パフォーマンスモニタリングgraphitegrafanadiamondperformancesitespeed.io Web のパフォーマンス継続モニタリング環境 intro Web の健康状態を把握するためには、きちんとしたモニタリング環境を整える必要がある。 正しくメトリクスが測定できていないと、正しくボトルネックの把握ができないし、チューニングの副作用も正しく把握できない、アプリの変更の影響もわからないし、負荷対策もできない。 単にパフォーマンスチューニングだけのためではない。が、パフォーマンスチューニングには必須、という関係。 そして、メトリクスは一回適当に取っただけでは正確とは言えず、やっぱり定期的な取得が必要になる。 この辺のノウハウは、サーバサイドではかなり成熟している。 しかし
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
小さく始める JavaScript のテスト - Qiita
書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 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(); あとは普通にこのスクリプトを node/io
コマンドパスを自動で通し npm install -g しない - Qiita
追記 @hokaccha さんの指摘反映 npm install -g cosidered harmful 何かコマンドラインツールなどが必要なために npm install -g を強要するリポジトリがたまにある。 もっと面倒なのは、依存するツールがあるくせに README とかに書いてない場合だ。リポジトリにある設定ファイルからこちらが察して入れてやらないといけない。 グローバルに入れるツールは package.json の管理外なので、そこのバージョンは指定できない。 入れれば済むなら良いけれど、同じコマンドを他のリポジトリでも使っているような場合、求められるバージョンが違ったりすると面倒だ。
手軽な 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 との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
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
Go のクロスコンパイル環境構築 - Qiita
Go でクロスコンパイル Go の特徴であるクロスコンパイルの便利さと、その方法はよく語られますが、意外に「そのための準備工程」が知られてない気がしたので、ここで再度クロスコンパイル自体の便利さと、クロスコンパイル方法、そしてその準備方法を書いておきます。 クロスコンパイルの旨味 Go は、 1 つのソースコードから様々な OS 向けのバイナリを生成するクロスコンパイルをサポートしています。しかも、対象の OS が無いとビルドできないわけではなく、例えば Mac で Windows 用、 Linux 用、 Plan9 用のバイナリを一気に生成するといったことができます。 しかも、 32bit マシンで 64bit 用のバイナリを生成することもできます。 "Write Once Run Anywhere" でお馴染みの Java との違いは、 Java の場合は Class ファイルという形
Go の Test に対する考え方 - Qiita
この記事は Go Advent Calendar 2013 の 9 日目の投稿です。 今回は、 Go の testing というパッケージの使い方を解説しようと思ったのですが、 それだとつまらなすぎるので、合わせて Go が test というか assert についてどういうスタンスをとっているかを書いてみます。 Go でテスト さて、「テストのないコードはレガシーコード」などと言われて久しく、様々な言語が test (主に Unittest) について言語レベルでサポートしたり、デファクトなライブラリが確立したりといった状況が、今日では至って普通のこととなっています。 そんな言語や環境で、息をするようにテストを書いてきたみなさんが、はじめて Go でコードを書く時に見るべきは testing パッケージです。 http://golang.org/pkg/testing/ 命名規則 では、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
