天下一MVCフレームワーク武闘会に参加してきました
chaplin.js
- rails風
- viewとモデルはBackbone
- reuseすると早い
- ただし再利用を意識しないと死ぬ
- CollectionView
- テストがない
vue.js
- シンプル
- コンパクト
- モジュールフレンドリー
- 将来機能
- web components
- observ
riple.js
- reactiveなview
- componentファミリー
- 単機能なモジュールを組合せてアプリを作る
knockout.jsの事例
- 10万行のアプリ
- 独自タグなし
- バインドが重いので、結局自前のライブラリを使うことに
marionet.js
- backbone.jsベース
- view周りの面倒を見てくれる
marionetからractiv.js
- marionetは書くことが多い
- 一部だけ使っていたら辛くて全部移行
- あまり流行ってない
- 実は今は素のjs
- 1年沢山踏んできた
AngularDart
- Webglのプレイグラウンド
- knockoutjsとの比較
- 手軽さでは一歩落ちる
デザイナーからみたAngular.js
- エンジニアとデザイナーの共同のため
- デザイナー的には好きに動きをいじれるのがいい
- 触るところが限定されているのがかえってらく
拡張JSON SQL Injection(?)についての補足
JSON SQL Injection、PHPならJSONなしでもできるよ | 徳丸浩の日記
この記事で説明されているJSON SQL Injectionと同様の動作が非JSONのリクエストでも発生する問題ですが、正しくはjQueryによるAjaxリクエストとサーバーサイドにPHP、Ruby on Railsの組み合わせでも発生します。
jQueryはパラメーターのシリアライズにおいて、PHPやRuby on Railsと同じようにブラケットによる多次元ハッシュのシリアライズ方法を採用しています。
Ruby移植版も含めて対策は進んでいますが、リクエストヘッダーのHTTP_X_REQUESTED_WITHでアクセスをAjaxにのみ限定する方法は対策とはならないので注意が必要です。
一人でwebサービスをリリースして二年間でやったこと
Study Mailを個人で開発し、リリースして二年が経ちました。その間にやっていたことをまとめておきます。
やったこと
SESの導入
Study Mailはメールで勉強会のお知らせを配信するサービスなのですが、配信機構は最初はGoogle APPSのメールサーバーに投げてBCCに突っこんだアドレスに配信させる、という非常にプリミティブなものでした。
しかしすぐにGmailでの不達が頻発したためこれをやめ、Amazon Simple Email Service(SES)に変更しまして解消しました。
API投入前処理
キーワード抽出はYahooの重要度抽出APIとタイトルの正規表現マッチの二系統なのですが、APIの方が一時「セキュリティ」という単語に過剰反応するようになったため、「セキュリティの都合で」みたいな文章を消してから投入するようにしたのが始まりです。現在ではこの他にも「Facebookグループ」みたいなよくありがちで誤爆しやすい文章を消したり、関連勉強会と称して大量にキーワードをちりばめたり、略歴が混じって誤爆するようなケースに対応したりなどに使っています。
リストに入れた正規表現パターンを順番に適用するだけの単純な仕組みですが、後でこれがかなり汎用的なアルゴリズム*1だと気が付いたのは収穫でした。
出会い系対策
なぜかあまり知られていないのですがほとんどのイベント告知系サイトでは出会い系の告知が大量に投稿されています。数量としてはこちらの方が圧倒的に多く、IT系の勉強会とは桁が一つ違います。
元々キーワードの設定はこれに対抗する面もあったのですがそれでもすり抜けてくるものがあるため、出会い系でよく使われるキーワードをNG指定してフィルタリングしています。
ただ、この副産物としてリリースパーティの類も落としてしまっているのが現状の問題点です。
エリア・コミュニティ機能追加
これはログを見ていて気が付いた需要への対応です。こういうことがあると、作っていてよかったと思いますね。
サーバーの移転
最初はdotcloudを利用していたのですが、無料枠で独自ドメインを使ったケースを狙い打ちした料金設定をしてきたためさくらのVPSに引っ越しました。この時を機会にGitをデプロイツール兼用として導入。gitoliteをサーバー側に置いてそこにプッシュするという形でデプロイする形にしました。 サーバーの再起動やライブラリの導入にフックスクリプトを使って必要な作業を完全に自動化。ローカルのリボジトリ自体もDropboxで単純バックアップする二重体制になっています。
既読処理の変更
最初は単純に最後にチェックした日付より前のを読むという単純なものだったのですが、日付順にならんでいないものがあり取りこぼしが発生したため現在は既読リストを保存する方式に変更しました。
対応サービスの拡大
当初の対応サービスに加えてpeatix、doorkeeperに対応、またQiitaさんのハッカソンをきっかけにgithubのIDによるログインに対応しています。
特にpeatixはRSSの挙動が特殊で、なぜか編集すると内部的に別エントリーとして保存しかつそれを保存前のエントリーと一緒にRSSに放流する上にID自体は通常の連番で各エントリーごとに違うというなかなかロックな仕様になっていて、短縮URLのみ不変であると気が付くまでが大変でした。それでも公開フラグの変更は編集扱いにならないので、未だに事前に登録して決まった時間に公開するケースは取りこぼしが発生しています。
IT系以外への利用への対応
当初の想定では、利用者は私の周囲2クリックくらいにいる勉強会方面の濃い人を想定していました。ここでいう濃い人というのは例えば数年に亘ってそれなりの数の勉強会に出ていて運営側で参加する方が圧倒的に多いとか、そういうレベルです。もちろん、このレベルの人は自分なりに開催情報の入手ルートは確立しています。それでも取りこぼしがあって足りないのです。
そういう極めて限られたユーザーを想定することで開発の難易度を下げている面があったのですが、意外にもIT勉強会以外のイベントの情報収集に使っていただけるケースが増えてきていてうまく行かないところが出てきたので、簡単なルールエンジンを導入してフィルタリングしています。
キーワードの誤爆防止対策
SpringとかPlay、of(Open Framework)、GOのように一般的な単語とかぶる名前、アプリのようにそもそも一般的なケースなど前処理レベルでは対処しきれない誤爆に対してやはりルールエンジンを導入して対応しています。
これを含めて前述三つのフィルタ系統のルールはログを見ながら大体週に数回くらいの頻度で改善しています。
今後とか雑感とか
サービスは作っただけではまだスタートで、改良しつづけることが大事とはよく言われますが、実際にやると磨き上げて改善していくのはとても楽しいです。細かいところを含めれば改良すべき点は無数にあり、そこ潰していくのはプチプチに近い快感です。
ただ、まだ大きな改修ネタはあることと、Chefのように単純なルールベースでは対処できない物があること、そして何よりも勉強会自体が増えていて*2ハッカソンなどもほぼ毎週おこなわれるようになったことから今後は細かいネタの改良の頻度を下げてもうちょっと大きい改修ネタの方に労力を使いたいと考えています。
電車の運行情報と天気を一目で見れるサービスをリリースしました
「電車と天気」というサービスをリリースしました。名前の通り、鉄道の運行情報と天気を一目で見て行動を決定することができるサービスです。
どうぞご利用ください。
作った理由とかアピールポイントとか
やっぱり東京に暮らしているとダイヤが混乱すると大変ですので、それを何とかしたいなと。構想としてはもう何年も前からあったのですが、先週、三度目の大雪が平日に来るかもしれない、という予測があった時にようやく形になりました。
単体でいうと天気はもとより運行情報系のアプリも結構あるのですが、あまり表に出てなかったり、特定の鉄道会社にしか対応していない等の問題があり、複合型の天候と統合してどう動いたらいいのか決定するのを支援するアプリはありません。
また、単純に路線名ではなく駅単位での運行情報の表示をしているのも隠れたポイントだったりします。実は日本の都市部では地名とは駅名とほぼイコールである一方で路線名そのものはあまり意識されません。駅は駅であり、単純には路線名と結びつかないのです。・
APIとか技術面とか
見て分かるとおり、サーバーはheroku+PHP、マップはYahooのものを使用しています。
フロントはBackbone.jsに自作のモジュール化モジュール。CSSはNormalize.cssにズルいデザイン。アイコンはicomoonのwebフォントを使用。形式的にはいわゆるSingle Page Appなのですが、PHPの無名関数を使うことで最終的には画面単位でモジュール化しつつ必要なリソースを一括管理することができました。
APIは
- 雨量予測→YOLP(地図):気象情報API - Yahoo!デベロッパーネットワーク
- 気温→docomoの環境センサー
- 警報・注意報→aitcの気象庁XML用API(REST)
- ホテル・コンビニ検索→Yahoo ローカルサーチAPI
- 電源カフェ→モバイラーズオアシスAPI
- 運行情報→Yahooの運行情報をスクレイピング
- 駅→Heartrails Express api
APIではaitcの気象庁XML用APIが一番の難物でした。気象庁から配信されるXMLを検索可能にしているだけなので、丁寧にやろうとするときちんと気象庁のXMLを解析しないといけないのですが、これが種類があって大変なので現状最新ヘッドラインだけを表示しています。
HTML5とか勉強会に参加して来ました
- テーマはHTML5とセキュリティ
- できることが増えてきたことで、セキュリティも大事になってきた
今から始めるHTML5セキュリティ(JPCERT 松本さん)
「本当は怖いクライアントサイドキャッシュポイズニング」(吾郷さん)
- キャッシャが重要になってきた
- デバイスの貸し借り時のリスク
- キャッシュシステムも進化してきた
- Application Cacheの危険性
- ユーザーが信頼できないネットワークを使っている場合に被害が広くなる
- 継続的な監視も可能になってしまう
- ユーザーが信頼できないネットワークを使っている場合に被害が広くなる
- SSLを使っていればOK？
- 攻撃者側からすれば、最低でも通常の攻撃が可能で、より広い範囲の攻撃もできる
- コンテンツ提供者側から見れば危険が増えたわけではない
- 基本的には中間者攻撃が成立していれば危険なので、キャッシュそのものが危険ではないのでは？
- 公衆無線LANが増加して危険性が上がっている？
- キャリアの提供するAPは外から攻撃できないのか？
- 店によっては普通に触れるところにある
- 店舗の悪意にたいする耐タンパー性は?
- 汚染APをばら撒いたら？
- キャリアの提供するAPは外から攻撃できないのか？
- モバイルサイトは常にhttpsにすべき？
- HTTP2.0では暗号化はオプションに
- ブラウザは暗号化必須の方向性
- ここの無線APは安全？
Bypass SOP(はせがわようすけさん)
- HTML5の高機能化に伴って(ry
- オリジン
- スキーム ＋ ホスト ＋ ポート
- Same Origin Polycy
- その逆のCross Origine Sharingもある
- Cookie情報も含めることができる
- Access-Controll-Allow-Originにアステリスクを指定すると機密情報が漏れる可能性がある
- アステリスクにしているばあいはCookieを含めることができない(ブラウザによって挙動が違う)
- ブラウザを狙う攻撃は受動者攻撃
- サーバーに来るのはブラウザベースとは限らないので、オリジンを認証として使わないようにしましょう
- IEではHTMLでないものがHTML扱いされるので注意
- IEではJSONをVBスクリプトとして解釈させるとエラーメッセージ経由で機密情報が取得可能
- X-Content-Type-Options:nosnifをつけておくとIE以外でも結構広い範囲で守れる
- JSONPの時にはContent-Typeに気をつけましょう
- 他にも便利なヘッダあり
- ブラウザのXSS防御機能をオフにするように求めるのはやめよう
- HTTPSを強制するヘッダや、ダウンロードダイアログに「開く」ボタンを表示させないようにするものも
- 質問
- ユーザーの教育は？
- 信頼できるサイトを偽装するのは簡単。それだけでは難しい
- ユーザーの教育は？
HTML5とか勉強会に参加してきました
HTML5でサイネージは作れる
- お台場合衆国での事例
- IE対応を考えたくない程度のたっぷり技術仕様
- 要件
- クオリティの担保
- 8時間連続作動
- 縦長のコンテンツ
- 42インチの縦置きディスプレイ
- 大人の社会科見学みたいな番組
- クイズパートをインタラクティブ化
- 大人の社会科見学みたいな番組
- 動画山盛り、WebGLが背景でブラウザ泣かせ
- 何か問題があった場合はタッチでしか解決できないので、隠しコマンドで管理画面
- 今まで技術的な理由であきらめていたことがどれだけあったか実感できた
- Inka3D(MayaをWebGLに書き出すプラグイン)
- 写真撮影
- 最初に許可を取ってストリームを保持
- https化では一度許可をとればOK
- 動画再生
- 動画側に円形のマスクを適用
- ロードが失敗したら強制的に再ロード
- 動画の再生に関わる部分が極めてまれにクラッシュする
- 耐久テストが大変
- 現場で起きた不具合をその場で修正可能
- リモートでも修正可能
- Webとサイネージの相性は実は高い
