Intro Service Worker は、その立ち位置が非常に特殊なため、仕様を策定する上でも「どう振る舞うべきか？」を決定するのが難しい場合がある。 時には、開発者は「どう振る舞うだろう」と考えるか、感覚的な部分についてアンケートを行い、フィードバックを得ることが過去にもあった。 今回は、 Service Worker が絡んだ場合の BaseURI について、同様のアンケートが行われているので紹介する。ぜひ考えてみてほしい。
Service Worker における BaseURI の振舞いについての議論 - Qiita
Intro Service Worker は、その立ち位置が非常に特殊なため、仕様を策定する上でも「どう振る舞うべきか？」を決定するのが難しい場合がある。 時には、開発者は「どう振る舞うだろう」と考えるか、感覚的な部分についてアンケートを行い、フィードバックを得ることが過去にもあった。 今回は、 Service Worker が絡んだ場合の BaseURI について、同様のアンケートが行われているので紹介する。ぜひ考えてみてほしい。
es7.decorator でプロパティ validation やるとこんな感じなのだろうか - Qiita
仕様: https://github.com/wycats/javascript-decorators プロパティ自体に decorator は付か無いので、しかたなく setter を作ったけど、なんかうまくできないだろうか。 (この使い方自体が筋悪な気もするが、 decorator でやりたいのってこういうのな気がする。) // $ 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) {
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
小さく始める 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
コマンドパスを自動で通し npm install -g しない - Qiita
追記 @hokaccha さんの指摘反映 npm install -g cosidered harmful 何かコマンドラインツールなどが必要なために npm install -g を強要するリポジトリがたまにある。 もっと面倒なのは、依存するツールがあるくせに README とかに書いてない場合だ。リポジトリにある設定ファイルからこちらが察して入れてやらないといけない。 グローバルに入れるツールは package.json の管理外なので、そこのバージョンは指定できない。 入れれば済むなら良いけれど、同じコマンドを他のリポジトリでも使っているような場合、求められるバージョンが違ったりすると面倒だ。
IE10 以下を切る場合の JavaScript チェックリスト - Qiita
この投稿は、 JavaScript Advent Calendar 18日目の記事です。 更新履歴 こちら をご覧下さい JavaScript の書き方をアップデートする JavaScript Good Parts で書かれているような JS の書き方は、古くなりつつある部分も多いです。 正直なところ、自分はあの本が「今でも」良書だとは思っていません。 初学者に勧めることもしません。まんべんなさと普遍性と客観性から「パーフェクト JavaScript」 を勧めています。 その頃と比べると、 JavaScript をとりまく環境は変わりました JavaScript の進化に合わせて書き方もアップデートしていくべきなので、今回は分かりやすいしきい値として 「IE10 以下を切れるとしたら」 という前提で、列挙してみます。 たとえば XHR2 や File API に依存したサービスをやる場合な
#mozaicfm ep4 セキュリティ(プロトコル編) - Qiita
Security(protocol編) CCS Injection Vulnerability を発見・報告した lepidum の @lef さん、菊池さんのお二人をゲストにお招きし、自分がやっている次世代 Web Podcast Mozaic.fm にて「セキュリティ(プロトコル編)」を明日(6/6 21:00 ~)録音します。 本当は、もう少し先で録音する予定だったのですが、今回の件をうけ急遽録音させていただくことになりました。(お二人とも本当にありがとうございます。) そして、今回はお二人の許可のもと質問を募集してみます。 質問募集 このエントリは、普段 mozaic.fm を録音する前に、出演者の方と事前に限定共有しているラフノートです。(あくまで参考で、この通り進める台本というわけではありません。) 今回は先にこれを一般公開し、内容についてゲストのお二人への質問を募集してみたい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
graphite, grafana, sitespeed.io, diamond で継続パフォーマンスモニタリング - Qiita