canvasのgetImageData(), toDataURL()などにおけるCORSについて - 愛と勇気と缶ビール
僕のcanvas力はいまだ中学生男子並みなので、そもそもcanvasの一部のAPIにSame Origin Policy的なものが適用されることすら今日まで知らなかったのですが、どうやら 違う生成元がsrcに指定されているimgをputImageData -> その描画領域をgetImageDataしようとするとDOM Exception という感じに、普通に怒られちゃうみたいですね。知らんかった。 http://www.w3.org/TR/cors/#use-cases ↑のあたりに書いてあるのをみると、taintedなcanvas、というのですかね。getImageDataで同じ生成元から読み込んだimgの描画部分を指定しても怒られないけど、違う生成元の画像を描画した部分に少しでもかかっていると怒られるので、canvasってピクセルごとに "taintedか、そうでないか" を管理して
Maintainable JavaScriptにみる、コンテキストとアプリケーションロジックの分離 - 愛と勇気と缶ビール
個人的なこと 読書はいわゆる自己投資？にあたるものなのでケチるもんじゃないよなあ、とは思いつつも可能なら安い値段でより大きなリターンを得たいよねー、ということで最近はOreillyの半額セールに目を光らせるようになりました。英語は「拾い読み」がし辛いという欠点があるのですが、まぁ、安いし、全ての本にちゃんと訳が出るわけでもないので、ええかなぁと。 そんなわけで "Maintainable JavaScript" という本を読んでいたのですが、その中のEvent Handlingについての章が「おお、これこれ」という感じだったのでちょっと紹介。 Maintainable Event Handling jQuery覚えたぜ！って感じの人がとりあえずコードを書くと、だいたいこんな感じになりますね。ちなみに、これは別にjQueryがどうとかいう話ではなくて、本質的には生DOMでも他のライブラリでも
ES5 features on iOS/Android's default browser - 愛と勇気と缶ビール
iOS, Androidのめぼしいバージョンのデフォルトブラウザについて、ECMAScript 5 compatibility table を使ってES5の対応度合いを調べました。既にありそうだなーと思いつつパッと見当たらなかったので。 どれもエミュレータで調べたものですし、特にAndroidについてはメーカーが手を入れてヘンテコリンなことになっている可能性も結構あるので、目安程度に。 全てのiOSデバイスが6.0以上、Androidデバイスが4.1以上になればstrict mode含めてやりたい放題（かも？）、ということが分かりますね。いつになることやら。 feature/os version ios-4.3.2 ios-5.0 ios-5.1 ios-6.0 android-1.6 android-2.1 android-2.3.3 android-3.0 android-4.0.2
Content Security Policy (CSP) についてちょっと調べたことのメモ - 愛と勇気と缶ビール
http://blog.monoweb.info/article/2012031523.html しばらく前に↑のblogで記事になった、Content Security Policy(以下CSP)についてのメモ。 ちなみにCSP自体の仕様については、 W3Cのdraft (https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html) MDNのIntroduction（https://developer.mozilla.org/ja/Introducing_Content_Security_Policy) などを参照。下のは仕様というよりmozillaにおける実装かな。 CSPでできること ざっくりとだけCSPで可能なことを示すと デフォルト機能 href="javascrip
メッセージングでまあまあ捗るかもしれない話 - 愛と勇気と缶ビール
この記事はJavaScript Advent Calendar(オレ標準コース)の13日めのエントリイになります。 ちなみに家に帰った瞬間、マシンの時計がずれて12/14になってて、大分一人で焦りました。てへぺろ。ぺろぺろ。 この記事の題材はJavaScriptにおけるメッセージング（もどき）です。 で、メッセージングって何やねんと JavaScriptで！メッセージング！というとその筋の人はwindow.postMessageを思い出すのかも知れませんが、 この記事では「メッセージング」という言葉をもっと広い意味に捉えて使っています。 だいたい、「あるオブジェクトがメッセージを受け取るオブジェクトを直接には知らなくても、特定の目的を持ったメッセージを投げて処理をさせることができるような仕組み」のことを「メッセージング」と呼んでいます。 すごい！すごい分かりにくい！ (ちなみにいわゆるプロ
本当はそれなりに面倒くさいJavaScriptとhistoryとAjaxのお話 - 愛と勇気と缶ビール
口上 historyとAjaxといえば、JavaScriptからある程度任意でhistoryのエントリをpushできるhistory.pushStateとか、history.replaceStateは既に大分有名になった感がある。 素晴らしい未来では、全てのブラウザにpushStateが乗っていて「location.hashを使ったAjax遷移が許されるのは10年前のブラウザまでだよねー」というハッピーな世界が実現するのだろう。が、今現在ではまだpushStateに対応していないブラウザのシェアも多く、Ajaxによる擬似画面遷移をモリモリ行うようなサイトではpushStateのある環境、ない環境の両方を考慮してやる必要がある。 (ちなみに、要件によっては「pushStateがないブラウザは通常の遷移で我慢しろ！」という割り切りも全然ありだと思う) 先に言っておくと、この記事は長いです。 環
JavaScriptが100ms以上実行されてると怒られるようにする - 愛と勇気と缶ビール
http://www.slideshare.net/nzakas/high-performance-javascript-2011 わかりやすいスライドだなー、と思いつつ。 1つのJavaScript job（わかりにくい表現だけど、event handlerとかtimerからキックされるJS code）の実行は目安として100ms以下に抑えましょう、って他のどこかでも見たことがある。要は、ユーザが何もできない && ユーザアクションが何も反映されない時間を100ms以下に抑えましょう、ということだろう。 でも50msとか100msとか数字で言われてもよくわかんないよねー、ということで。 大体の場合JS codeのキックはelementにくっつけたevent handlerか、timerのどっちかだよねー、ってことで、いささか無理くりながら50ms or 100ms以上JSが実行されてると
なぜGoogle Closure LibraryがDOMContentLoaded相当を待つための機能を提供してないかっていう話 - 愛と勇気と缶ビール
あれ、これ前に書いたっけ。 http://groups.google.com/group/closure-library-discuss/browse_thread/thread/1beecbb5d6afcb41?pli=1 http://stackoverflow.com/questions/2024018/using-domcontentready-considered-anti-pattern-by-google/2024101#2024101 この議論をするにあたっての前提知識については一々説明しません。 stackoverflowの、best answer?みたいなやつに書かれているGoogle式inline scriptの良い所、悪い所を超訳すると いいところ 1. DOM elementがユーザに表示されたほぼ直後からJavaScriptによって付加された機能が使えるようにな
JavaScriptのテストについて本気出して考えてみた(3) - 愛と勇気と缶ビール
テストにおけるxhrのハンドリングについて 今までの記事は、「ブラウザで動くJavaScriptのテストを難しくしているのはDOMとxhrである」と最初にのたまった割にはDOMのことしか書いてないじゃないか、と鋭い人はちゃんと思ったのではないかと思う。 なのでJavaScriptにおける外部リソース操作の双璧をなすところのxhrについてもちょっと書く。 xhrによる外部リソースの操作を含むアプリのテストを（本物のサーバサイドアプリを使わずに）行う場合の方法は主に二つあると思っていて、 1. テストフレームワークの側で、xhrに対してレスポンスを返すようなモックcontroller(?)を書けるようにしておく 2. xhrそのものをモックオブジェクトにしちゃう 1. はつまり、pushによる自動化を行うようなフレームワークだと何らかの形でWebサーバを起動しているはずなので、その中でxhrか
JavaScriptのテストについて本気出して考えてみた(2) - 愛と勇気と缶ビール
前回からの続きで。 DOMエミュレーションの戦略 一方で、本物のブラウザを使わずに何らかのJavaScript実行環境でDOMをエミュレートして、その上でテストを走らせよう、という戦略もある。 この分野の大御所はEnv.js(http://www.envjs.com/)ということになっているのだけど、Env.jsのイヤンなところは導入がめんどくさい所である。何がめんどくさいって、antでビルドしなくちゃいけない。テストのためにどの程度の環境構築コストをかけられるかは状況において違うだろうが、例えばJSをメインでやっているエンジニアが「ちょっとテスト環境整えたい」っていう時にantから入れて頑張るだろうか？Javaの経験や、こういうビルドツールの導入/利用の流れに慣れている人だと全然問題ないレベルなんだけど。 というわけで、Env.jsは結構力を入れて開発されたものではあるのだろうけど、僕に
githubのアレ(history.replaceStateとかhistory.pushStateの話) - 愛と勇気と缶ビール
会社で下の記事についてリマインドしてもらって、なんとなく気になっていたことを調べたメモ。 http://webtech-walker.com/archive/2010/12/06160539.html 記事を読んで、history.replaceState(null, "title", "/new.html") とかやると遷移なしでページのcontentも勝手に置き換わるのかなー、だったらあのアニメーションはどこで発火してんだ？とか考えていたがそもそもreplaceStateの動作について勘違いしていた。 要は、次のようなhtml書いてボタンをクリックしても、historyの先頭が置き換わるだけでページ自体には何も起こらない。(ただしlocation.hrefは置き換わっており、reloadすると/replace.htmlにいく) <!DOCTYPE HTML> <html lang="e
Vimのplugin管理ツールつくった - 愛と勇気と缶ビール
いつかやろうやろう、と思いつつ、.vim以下の整理がなかなかできていなかった。なので、整理しようと思ったんだけど、どうせこういったパッケージ的なものを整理するなら何らかのパッケージマネージャで一元的にinstall/remove/upgradeしたいと思うのが人情。 Vimのplugin管理ツールといえば少し前からVimanaというツールがあって、これはとても便利なツールなのだけれど、ソースの中に固定値で"3000"とか書かれていてそれをvim.orgの検索のパラメータにしているために新しめのplugin(current_func_info.vimとか)が検索してもひっかからないとか微妙に使いにくいところがあった。 そこで、せっかくgithubにvim.orgのplugin群もミラーされたことだし、githubをリモートリポジトリとしてsearch/installしちまえばめんどくさいファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
