- Audio(url)
- Audio(arraybuffer)
- Audio(blob)
- WebAudio(arraybuffer)
- WebAudio(blob)
- 本文の文字サイズは十分に大きいか?各デバイスのサイズに合った一行の文字数の範囲に収まるようになっているか?
- 行間に十分なスペースが確保されているか?
- ページの端や他のデザイン要素との間に十分な間隔をとっているか?
- 背景色と文字色に十分なコントラストがあるか?
- 段落と段落の間に十分な間隔があるか?
- 見出しなど本文以外の文字は本文と違うか?
- 長い文章を切り分けるために序列なしリストやボールドなどを使っているか?
- 本文に読みやすいフォントを使っているか?
以下の snippet を Chrome の DevTools で使うと、ページ内に仕掛けられた全てのEventListenersの設定元の一覧をダンプし、コードの位置を辿ることや、<scoped>
な Closure Object(スコープ内の変数等) を参照することができます。
(ა✘﹏✘)ა イベントリスナーが沢山あってもう何がなんだかわからないんですー
な、状況や、パフォーマンス・チューニングで泣きつかれた時に、
(ε・◇・)з o O ( なるほど… お困りのご様子…
(ε・◇・)з o O ( では、ちょっとキーボードをお借りしますね…
と、華麗に console にタイプするのが、以下のコードになります。
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil
The final result: require() any module on npm in your browser console with browserify
This article is written to explain how the above gif works in the chrome (and other) browser consoles. A quick disclaimer: this whole thing is a huge hack, it shouldn't be used for anything seriously, and there are probably much better ways of accomplishing the same.
Update: There are much better ways of accomplishing the same, and the script has been updated to use a much simpler method pulling directly from browserify-cdn. See this thread for details: mathisonian/requirify#5
"use strict"; | |
// MIT License | |
// author: Tetsuharu OHZEKI | |
/* | |
* Parse from HTML text to DOM subtree which does not have scripting items. | |
* | |
* @param {string} aText | |
* @return {DocumentFragment} |
試験は twada/battlefield-sourcemaps で行っている
- SourceMap 対応が入った espower 0.9.0 を使う
- espower(ast, options) の第二引数 options に
sourceMap
というキーで上流の SourceMap オブジェクトを入れる
最近、社内で私が「何者で何をしているのか見えないので可視化して欲しい」という案件が出ているらしいので、ヘコヘコと徒然なるままに書いていきたいと思うのであります。
社内向けというだけでなく社外の人にも発信出来る内容に、との仕様も要求され、社外向けには出来るだけ旬なネタで、かつ、社内向けにはそれを理解する上で必要な関連する技術を個々に触れながら基礎知識が無くても理解出来るように、との追加仕様も提示されております。
で、何をネタにしてどのように書けばいいのか迷った訳ですが、自分が実際にやって来た内容である CoreOS であればそこそこ旬であるし、それをおさらいしつつ、関連技術も Docker、Omaha、systemd、BtrFS、Golang、etcd、Kubernetes 等々多岐にわたるので、それらに関して私見も含めてわかりやすく書ければいいかなぁと、とりあえず書き始めようとしている次第であります。
// ==Taberareloo== | |
// { | |
// "name" : "Add a shortcut key for KeyConfig:Taberareloo.general" | |
// , "description" : "Add a shortcut key for KeyConfig:Taberareloo.general" | |
// , "include" : ["background", "content"] | |
// , "match" : ["*://*/*"] | |
// , "version" : "0.1.1" | |
// , "downloadURL" : "https://gist.github.com/YungSang/9cd4ff8d5e46921a68d2/raw/patch.shortcutkey.contextual.post.tbrl.js" | |
// } | |
// ==/Taberareloo== |
# 実行すると1秒後に実行回数をprintするPromise化された関数 | |
cnt = 0 | |
f = -> new Promise (done) -> | |
setTimeout (-> | |
console.log 'done', cnt++ | |
done() | |
), 1000 | |
# fを直列に4回実行する | |
promises = [f, f, f, f] |