そろそろCSP Lv.2 nonceやろう

csp security

tl;dr

  • CSP Lv.2のnonceを使うと意外と簡単にCSPの恩恵を受けれるよ
  • Firefoxはunsafe-inlineとの挙動がおかしいので注意
  • サンプル実装としてExpressで簡単にnonce対応できるconnectプラグインを書いた（デモあり）
  • Violation Reportもブラウザによって細かい挙動の差異があるよ
続きを読む

3分で分かるFacebook Flow

flow

というか3分ぐらいの情報しかまだ出てきてないんだけど。

先月の@Scale 2014で発表されたFacebookのFlowについて、おそらく唯一のオフィシャルな情報であるこの発表動画を見て分かったことを紹介（ざっと見ただけなので間違ってたらごめんなさい）。

続きを読む

Mac/iOS Safariでバックスラッシュを円記号として表示する方法

css

Unicodeではバックスラッシュ*1と定義されているU+005Cだが、歴史的な背景によりMS系日本語フォントでは円記号が割り当てられているのはよく知られた話。

ところがMac/iOSに載っているヒラギノ角ゴシック等ではU+005Cはバックスラッシュとして表示されるし、キーボードの右上の円記号キーを打つとU+005CではなくU+00A5 Yen Signが入力される*2。

*1:いまはBACKSLASHではなくREVERSE SOLIDUSが正式名称

*2:ことえりの設定で変更は可能

続きを読む

TypeScriptで複数ファイル構成する2つの方法

typescript

TypeScriptで複数ファイル構成のプロジェクトを扱う方法について書いてみる。日本語の入門記事や試してみました系の記事で勘違いされてることがたまに見受けられるので、整理してみる。

公式のModules in TypeScriptを既に読んでおられるような御仁は回れ右していただいても結構です。

続きを読む

TypeScriptの宣言空間とその不満

typescript

最近TypeScriptの型を触っていてハマったあたりのまとめ。だいたい仕様書に書いてあるとおりなので、すでに仕様書を読破している諸兄にはこの記事は必要ないです。

宣言空間 (declaration space) とは

宣言空間というのは、同一宣言空間で同じ名前が複数存在するとエラーになるような空間のこと。 TypeScriptには大きく分けて3つの宣言空間 (declaration space) がある *1。

  1. 変数 (for variables) またはメンバー (for members)*2*3
  2. 型 (for named types)
  3. 名前空間 (for namespaces)

どういうことかというと、TypeScriptでは次のコードがエラーにならない。

var M = 0; // 変数宣言空間
interface M {} // 型宣言空間
module M {} // 名前空間宣言空間

変数とinterfaceとmoduleは別々の宣言空間に宣言されるためコンフリクトしない。

*1:詳細はSpecification 2.3 Declarationsを参照

*2:このグループは仕様書ではまとめられていない（と思う）けど、自分の理解としては型と名前空間とは違うそれ以外のJavaScript空間に存在する宣言空間としてひとまとめにした。

*3:クラスのメンバーにはinstanceメンバーとstaticメンバーがある。

続きを読む

HTML FormにPUT/DELTEは必要なのか、あるいはJSer界の分断 #桜JS

先日、都内某所で開催された#桜JSに参加したので、個人の日記レベルの感想を書いてみる。

細かいことはazuさんのまとめを見てもらうとして、個人的におもしろかったのがHTML FormのPUT/DELETEについての議論。

Jxckさんの経緯まとめを踏まえて、じゃあこれからHTML FormにPUT/DELETEを追加する必要あるの？っていう点で意見が割れた。

個人的には、この話を聞いたとき、確かに仕様としては欠けてる感じがするけど、いまさら実装されても自分はForm PUT/DELETE使うことはないだろうなと思っていた。理由は、FormでPUT/DELETEすると必然的にサーバー側で画面の遷移を考慮してリダイレクトなどを実装しないといけないから。サーバーはAPI、画面はJSでSPAっていうのに慣れてしまったこの2014年、サーバーで画面遷移の制御とかしたくないなーと。

そんな発言をした。たしかtkihiraさんも同意見だったと思う。

でもhokaccha氏はそんなことないと。RESTful APIなサーバーだけでさくっとJSレスに画面制御までできたらそれでOKってケースもあるよ。もしRailsが標準のscaffoldでそれ提供したら使うんじゃない？と。

そんな議論をしていて、フロントエンドJS勢でも主戦場によって隔たりあるなーと感じた。フロントエンドJSerの活動領域はざっくりWebサイト、Webアプリ、Webゲームの3つぐらいに分かれると思っていて、自分はほぼWebアプリのみ。tkihiraさんはWebゲーム。この2領域でJS使わない状況ってまずありえない。サーバーもクライアントも高度にモジュール化してる。のでサーバーで画面遷移は今更感が強い。

一方hokaccha氏はWebアプリだけでなくWebサイト系もやっていて、しかも案件ベースの業務形態だったりして、ものによってはForm PUT/DELETEで済ませられる現場も見てきてるんだろうな。たぶん。

他にも別の議論で、CPU/GPUパワーをWebからいかに使うかみたいな話のときは、Webゲーム勢とWebアプリ/サイト勢の間に壁あるなと感じた。

しかしなぜか特定MVCフレームワークや特定AltJSをdisるときだけは壁を越えてひとつになれるのが不思議だ。

そんなこんなで、桜も見ずに最近のJS裏表についていろいろ話せて楽しかった。 花よりJS。

JavaScript Stringでサロゲートペアを扱う

JavaScriptで強力なUnicodeを扱う方法について書きます！（嘘）

先月末に発売されたWEB+DB PRESS Vol.78で「フロントエンドの国際化」の記事を書いたのは前回書いた通り。

記事内で、JSの文字列は基本UTF-16なのでサロゲートペアがうまく扱えないっていう問題は書いたけど、じゃあどうすればいいの？っていうのは載せられなかったので書く。

続きを読む