東日本大震災のボランティア情報とニュースをメールで配信するサイト作りました

東北地方太平洋沖地震 Hack For Japan

　本日、Volunteer　Mailというサイトをリリースしました。キーワードを登録しておくと、FacebookアカウントまたはGoogleアカウントからインポートしたメールアドレスに一日一回、メールで配信するサービスです。

　どうぞご利用ください。

第一回Startup Technorogyに参加してきました

スタートアップ

スタートアップテクノロジーをはじめた理由(ひさじゅさん)

  1. スタートアップは面白い
  2. でも、よくわからないのでうまくかみ合わない人が多い
  3. 資金調達のステージ
    1. シード(一億くらいまで)
    2. ステージAで数千万から数億
    3. ステージBでそれ以上
    4. 立ち上がりで300万
    5. そのあとで数千万かけて大きくしていく
  4. スタートアップの特徴
    1. 人がいない
    2. ロジックの変化が激しい
    3. 綺麗に書くよりもアウトプットを求められる
    4. テストは技術的に負債になりがち
    5. 人の入れ代わりが激しいので学習コスト優先
    6. インフラはAWSがいい(？)
    7. メディアの露出のような一時的なアクセス増加に耐えられるように、AWSがいい
    8. 前文検索エンジンは単体型
  5. 開発の流れはシンプルに
  6. スタートアップは制約が多い
  7. でも楽しい

Titanium Mobile 〜本当にあった恐い話〜

  1. ごく普通のエンジニアからみた、Titanium Mobile
  2. Write once　Run Anywareときいて「いけるんじゃね？」と
  3. 事例も多い
    1. ネイティブに近い
  4. 同様のものも
  5. どうしてももっさりする
  6. 実際の事例
    1. 贅肉で育つペット
    2. 数字にこだわりがあるので全部画像
      1. ものすごい遅い
      2. 差分ロード
    3. アニメーションに弱い
    4. 動きかずれる
      1. 最終的にはあきらめた
    5. 実機に転送ですごい時間がかかる
  7. Androidで動かない
  8. いい点はある
    1. 熟練者が使えばよく動く
    2. 比較的スペックの高い新しい端末を使うべし
    3. JavaScriptは自由度が高すぎるので注意
    4. ツール系では使える
  9. ネイティブに切り替える勇気を持とう

実際のスタートアップ事例紹介

  1. Eyeland
    1. 位置情報サービス
    2. 現在ワールドワイドに展開中
    3. 地図の上に人を乗っける解りやすいインターフェース
    4. 位置は意図的にずらす
    5. わざとソーシャルアカウントにつなげていない
  2. 本題
    1. スタートアップでは資産は最小にする
    2. クラウドを活用しよう
  3. Pivotal　Trackerはアジャイルプロジェクト管理ツール
    1. ポストイットそのままみたいな操作感
    2. アイデアはIceBox
    3. 計画はBackogに
  4. スタートアップの敵はAppleのレビュー
  5. 迅速なリリースが必要
  6. バージョンサポート、マルチデバイス管理とか
    1. Amazonをフル活用
    2. サーバーを富豪的につかってデプロイとかしようぜ！
      1. API実装言語としてはnode.jsオススメ
    3. SchemalessDBは変化に対応する必要があるスタートアップには向いている
  7. スタートアップにテストは必要か？
    1. 開発に集中する為には必要
    2. 慣れれば効率的
    3. テストは銀の弾丸ではない
  8. 人は忘れる生き物だから、仕様はコードに落とす

Twiilio（KDDI　宋さん）

  1. Web電話サービス
  2. 元々KDDIがやっていたサービスと海外製のサービスが合流
    1. webから数行のコードで電話をかけたり、受け取ったり
  3. 使い道は色々とありますよ!

Operaはレスポンスボディが含まれているとプライベートアドレスにリダイレクトしない

Opera セキュリティ

　土曜日から二日間Qiitaのハッカソンに参加しました。その最中に判明したのですがOperaはリダイレクト元のレスポンスにレスポンスボディが含まれている場合、プライベートアドレス、あるいはプライベートアドレスに紐づけられたドメインに対してリダイレクトしません。
　おそらくはFirefoxがlocalhostでのcookieを受け取らないのと同様の、大変オリジナリティあふれるオレオレセキュリティと考えられます
　
　これで何が困るかといいますと、一つはOAuth、OpenIDの認証です。GitHubのようにリダイレクト時にユーザビリティの向上のためにリダイレクト中であることを表示しようとしている場合、Operaでは動作しなくなります。
　もう一つはWebアプリケーションフレームワーク開発のサイトの投稿時の動作検証です。この場合、開発環境でのみ動作しなくなる可能があります。

第35回HTML5とか勉強会

html5

Tizenの概要(暇村さん)

  1. Tizenについて間違った情報が流布している
    1. 具体的には「iPhoneを電子レンジに入れると充電できる」くらい間違っている
    2. KDDIにサーバーを借りている
  2. 一般にはLimoとMeeGoを足してHTML5を掲げたもの
      1. 実際にはMeegoの流れを汲んでいるのは車載向けTizen
      2. TizenMobileはSumsunのLinuxがベース
  3. TizenはLinux財団のプロジェクト
    1. Sumsunだけでなく色々な会社からデバイスが出てくる
  4. TizenWebAPIには独自拡張がある
  5. Linux部分にも拡張あり
  6. SDKあり
    1. まだネイティブAPIなし
    2. Windowsとubuntuでのみ開発可能
  7. TizenのHTML5スコアは462。まだちょっと足りない
  8. Tizenはネイティブアプリケーションもできる
  9. TizenIVI(車載向け)はダッシュボードひとつであれこれできるようにすることを目標にしている
  10. Sumsung系のMobileとインテル系のIVIの二系統。基本的に別物
  11. まとめ
    1. Tizen　Mbileの普及はまあないだろう
    2. IVIは来るかも？

Tizen　APIについて

  1. Tizenの系統は3種類。Web、Nativ、Hybridの三種類
    1. NativeはC++
  2. NativeのAPIについてはまだ具体的な内容がない
  3. SDKも現状Webアプリのみ
  4. 今回はWebアプリ中心に
  5. エミュレーター(i586)
    1. 再現度は高い
    2. ただし、重い
  6. Chromeで動くWebシュミレーターあり
    1. 速い
    2. Bluetoothに未対応
  7. TizenのAPI
    1. 通話、ジオロケーション、Messaging、NFC、バッテリー、電源管理etc
  8. Tizen Web App
    1. ベースはW3Cウィジット
    2. 設定ファイルはジェネレーターあり
    3. APIはUI等も
  9. Tizen Web Ui Framework
    1. jQuery Mobileベース
    2. 国際化拡張して上にテーマとウィジットをかぶせたもの

KDDIの社長さんのお話

　ありがたいお話でした。わりとぎりぎり。

Firefox OS(浅井智也さん)

  1. 2012年にFirefox
    1. アドオンは30億ダウンロード
    2. 50%高速化
    3. メモリ消費量の大幅改善
  2. HTML5アプリのためのHTML
  3. モバイルは独占プラットフォームの支配下にある
    1. 支配力が強すぎる
    2. 変更が必要
    3. 競争が損なわれている状況はユーザーにとって不幸
  4. Webベースで透明性や自由度の高いプラットフォームを作る
  5. マーケットさえもオープンに
  6. Webで色々なことができるようになっている
  7. さらにもっと自由度を高く
    1. 多くても全部覚える必要はない
    2. 調べて簡単に作れればいい
  8. FirefoxOSはWebが「ネイティブ」
  9. Gekoエンジンがカーネルに直接乗ってるので高速
    1. 最低限250メガバイトあれば起動
    2. シングルプロセス
  10. セキュリティ
    1. プライバシーに関わるものにはインストールと利用の両方でパーミッションを求める
  11. ブラジルで製品化
    1. ローエンド向けスマートフォンに搭載
  12. FirefoxOSだけがHTML5専門
  13. マーケットも自由に選べる
    1. Device。OS横断
    2. AndroidとFirefoxOSでプレビュー版が提供
  14. シュミレーターもあるよ!
  15. FirefoxがインストールされているAndroid端末ならWebViewでなくFirefoxのエンジンでアプリを動かせる
  16. アプリケーションUIのツールキットも配布されている
  17. 質問
    1. 動く端末は？
    2. いくつかのAndroid端末は独自ビルドで入れられる。有名な開発者にはDev　Phoneが送りつけられるかも

意外と便利なJSON RPC

HTML5

　このエントリーはHTML5 Advent Calendar 2012の4日目のエントリーになります。
　JSON　RPCとは文字通りJSONでRPCするプロトコルで、現行バージョンは2.0です。
　リモート環境にある関数をローカルの関数と同様に呼び出せるRPCは呼びだす機能が多かったり、複雑だったりする時に非常に便利です。またRESTと違い対象がHTTPを受け付けるサーバーである必要がないというメリットがあり、これがwebsocketやメッセージングAPI、webworkerといったHTML5 APIと非常に相性がいいのです。
　またRPCというとXML RPCが有名ですが、JSON RPCはそれにくらべて以下のような特徴を持ちます

  1. プロトコルが軽量・シンプル
  2. 名前つきパラメーター(namedparameter)
  3. バッチリクエスト

　では順番に見ていきます

プロトコルが軽量

　
　RPCに限らずXMLとJSONの比較ではなんでもそうなのですが、JSONは非常に軽量でシンプルです。
まずは呼び出しですが

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}

　これに対して例えば次のようなレスポンスが返ってきます。、

{"jsonrpc": "2.0", "result": 19, "id": 1}


　この例をみれば説明しなくても大体基本的なプロトコルは解ると思います
　具体的には

jsonrpc プロトコルのバージョンを指定します。現在は2.0固定です
method 呼び出すメソッドの名前
params メソッドの引数
id 呼び出し一つ一つに付与されたID。エラーメッセージの返却などに使う
result 結果

　ということになります。
　paramsに設定されるメソッドの引数の順番は呼び出し先の引数の順番にそのまま相当するのですが、JSON RPCにはもうひとつの引数決定方法があります。
　それが名前つき引数です

名前つき引数


リモート側で設定されている以下のような関数をローカル側から呼び出すとします。

function subtract($a,$b){

   return $a - $b ;

}

　
　これは先述のとおり、次のようなリクエストで呼び出すことができます

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 43], "id": 1}

　リモート側では引き算が計算され、返却されます(この場合は-1)。
　この呼び出し方法にはもうひとつ呼び出し方法があり、それが名前つきパラメーターとよばれる方法です。この場合、引数と値のペアをparamsに設定して呼び出します

{"jsonrpc": "2.0", "method": "subtract", "params": {"b":43, "a":42}, "id": 1}

　少し余談になりますが、この呼び出し方法は呼び出す側としては便利なのですが受け取る方の実装は大変です。Python以外の言語ではハッシュを可変引数として投げる機能はないので、実装しているライブラリのソースコードを読むと普段見ることないメタプログラミングに出会えます。
　特に本来は複雑なメタプログラミング機能のないjavascriptにおいては大変興味深く、pmrpc.jsというライブラリは以下のように解決しています。

      var fnDef = fn.toString();#定義文を取得
      var argNames = fnDef.substring(fnDef.indexOf("(")+1, fnDef.indexOf(")"));
      argNames = (argNames === "") ? [] : argNames.split(", ");
　　　var argIndexes = {};
      for (var i=0; i<argNames.length; i++) {
        argIndexes[argNames[i]] = i;
      }

　evalの逆で関数オブジェクトを文字列変換すると定義文が取得できます。そこから引数の一覧を正規表現で切り出しているわけです。この発想はありませんでした。

バッチリクエスト

　JSON RPCにはもうひとつの特徴としてバッチリクエストがあります。これは一度のリクエストで複数の関数呼び出しを行うもので、ローカル側ではリクエスト回数を減らし、サーバー側ではシステムの部品化がしやすくなります。
　以下の例では四則計算を一度に行っています。

{"jsonrpc": "2.0", "method": "add", "params": {"b":43, "a":42}, "id": 1}
{"jsonrpc": "2.0", "method": "subtract", "params": {"b":43, "a":42}, "id": 1}
{"jsonrpc": "2.0", "method": "multiplication", "params": {"b":43, "a":42}, "id": 1}
{"jsonrpc": "2.0", "method": "divine", "params": {"b":43, "a":42}, "id": 1}

実装

　JSON RPCを実装しているライブラリについては、英語版wikipediaが詳しいです。
　見ての通りサーバー、クライアント共に複数の言語で実装されており、よほど特殊な言語で無い限りは問題ありません。

まとめ

　JSON RPCは軽量でかつ強力なプロトコルです。機能も豊富であり、サーバサイドの部品化、再利用化も容易です
　またJSONのテキストがサーバー側に渡ればいいという特徴から通信手法を選ばず、文字列のみでしか通信のできないHTML5 APIとの相性は抜群です。是非試してみてください

　


　
　
　


HTMLとかCSSとかAPIとか -2012秋編

HTML5 HTML.next css3 css4


　2011年最後のHTML5とか勉強会で白石さんが行ったAPI総まくりセッションの最新版とのこと。
　

  1. HTML5の勧告作業が本格化
    1. 一部で報道された対立は誤解
    2. whatwgは変化しづづける仕様(やめたのはここに専念するため)
    3. w3cはそこから切り出している
    4. エディタは十分
  2. 勧告をはやくしたいvs
  • html.next
    • html5の次
      • dialog要素
      • responsible lmage
      • 解像度やピクセル密度ごとに画像をかえる
    • inputmode
      • 仮想キーボードを制御
    • 他にもたくさん
  • css
    • css3はほぼ確定
  • 4へ
    • グラデーション
      • 接頭路つきとそうでないもので互換性がない
    • image
      • 複数画像
    • flex box
        • 色々できる柔軟なボックスモデル
        • 実装は難航中
    • セレクタ
      • 夢がひろがりんぐ
      • 親を選択
      • この内どれかを選択
      • カスタムプロパティ
      • ＄は他の変数ライクな機能の為に
    • テキストのの流し込み制御
    • グリッドライクなレイアウト
    • メデｨアクエリーの次
  • dom4
    • 効率よくdomを環視
  • dom3はほぼ確定
      • タッチイベント
  • xhr
  • file api
  • indexed database
    • pointer lock
    • fullscreen api
    • jQueryライクなセレクタ
    • webインテンツ
    • メディア関連
      • webaudio
      • カメラ
    • webコンポーネンツ
      • シャドウdom
      • html5 の下支え
    • カスタムdom
    • テンプレート
  • しばらくはカオス

基調講演

HTML5
  • 千人規模のイベント
  • このイベントは通過点
  • 一年の振り返り
    1. chrome + html5カンファレンス(去年)
    2. 月一度の勉強会
    3. タイトルだけでトレンドが解る

　ここでいったん及川さんにバトンタッチ。
　まとめるとさらっとした内容に見えますが、実際はかなり濃いセッションでした

  1. 2004年にapi への方向が決まる
    1. gdd day
    2. gears
      1. 標準への参考実装
  2. 2008年にchrome
  3. 2009年に普及開始
  4. 2010年にapple shock
  5. 2011年　デバイスapi WEB audio モダンブラウザ主流に
  6. ネイティブにあらゆる形で追い付き、追い越すのが目標
    1. 機能間の連携→webインテンツ
    2. WEBコンポーネントによる生産性強化
  7. ブラウザはクラウドと周辺機器の入り口になる
  8. 責任も重くなる
  9. それをクリアして初めて使ってもらえる

ここで白石さんにバトンタッチ

  1. コミュニティの未来
  2. 人はデスマーチを超えて強くなる(^^;)
  3. どんどん盛り上がっていく　ひろがっていく