QCon Tokyo 2012に行って来ました #qcontokyo

QCon Tokyo 2015 Conference｜QCon 東京 2015 カンファレンス
いつも通り遅れて（ｒｙ
基調講演2から聞きました。メモったこととか、感想とかを書いておきます。

K-2 Androidに関わるエンジニアの視点

Androidにまつわる踊らされっぷりを紹介されていて、とても楽しく聞けました。お客様怖い。

• 2007年のOpen Handset Allianceですでに踊らされ始めてたそうです、SDKが発表されて開発ブログを始めた。
• T-mobile G1発売されたけど日本語に対応していなかったので、日本語を入力するためにinJapと言うものを作り始めたそうです。自分自身がユーザなので、自分の為にもユーザビリティとかを考えていた。
• SocialIMEのAPIを発見してSimeji開発した。自分が欲しい物を開発して、そのスピード感が大事です。自分のニーズを表現して、その開発者の感性が好きでユーザが集まってくる。
• ユーザからのフィードバックを楽しむように心がける。
• 大事なのは技術力、モチベーション、ユーザフィードバック
  • 技術力はやり続ければ上がる。なんか知らないけど動くで止まってしまうと、成長も止まってしまうので、突き詰める事が必要。何で？何でそうなるの？を突き詰めよう。
  • 時には休憩も必要だし、モチベーションを上げるためにオレオレミッションを自分に課して奮い立たせる、のようなこともする。
  • 正直キツイ。お客様怖い。disコン。
• 個人でアプリを作ったりするのに必要なのはメンタルコントロール。ジョジョで学んだ。
• デザイナーと働くことは、お互いの考え方とか価値観のギャップを認め尊重することが大事。デザイナーには、理由が必要な時も、必要じゃない時（感性）も時もある
• 疲れちゃったら冬眠する。特段アウトプットせずに、まったりインプットしたり別のことしたりするのも大事。
• 完璧に終わらせるよりも、早く終わらせる。挑まなければ得られない。つまり、挑めば得られる。かも知れない。早くやることで、多くを学べる、沢山こなして学ぶ。
• 想像するよりも、経験から導かれた予測の方が良いよ。ちょっと考えて試すのサイクルを回そう。

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

S2-1 Webフロントエンド開発の最新トレンド - HTML5,モバイル,オフライン

• スクロールを使ったエフェクトが流行ってるらしい。
• モバイルでHTML5なネガティブな理由は古いIE対応しなくてよく、FlashはiOSで動かないから。
• ポジディブな理由は出来ることが増えているから。
• cache manifest使えばオフラインでも読むことが出来る。静的リソースをローカルにキャッシュするから。キャッシュしてるから早い。しかし、更新の少ないコンテンツ系は良いけど、それ以外の動的なアプリケーションはこれだけでは作れない。
• オフラインでもWrite出来る仕組みが必要です。なので、DBやFileシステムが必要です。localStorageとか、WebSQL Databaseとか、Indexed Database APIとかFileAPIとか。サーバ側とは同期エンジンを作ってそれに任せる。
  • IE10からIndexed Database APIは使えるようになったけど、正直APIが使いにくい。なので、ライブラリを作りました→jdb.js - Indexed Database APIを使いやすくするフレームワーク - IT-Walker on hatena
• FileAPIはローカルでFileが使えます。セキュリティ大丈夫？って思うけど、ユーザが選択したファイルしか読み込めません。書き込みはSandboxの仮想ファイルシステム上なので安全。
• デバイス機能へのアクセスAPIもすごく簡単です。基本的にAPIがシンプル。
• デバイス毎に使えるAPIが異なるのでチェックする。チェックはこちら→Mobile HTML5 compatibility on iPhone, Android, Windows Phone, BlackBerry, Firefox OS and other mobile devices
  • 断片化してるけど、Facebookさんがどうにかしようと頑張って、各ブラウザベンダに実装の優先順位を提案してる→ringmark
• スクリーンサイズ対応
  • レスポンシブWebデザインだけど、まずはモバイルからが良いのではないか？今まではPCからだったけど、PCからやるとモバイルの制約に引っかかることもある。コンテンツのサイズが大きくなるので万能じゃないです。
    • Appward's Field Guide to Web Apps
• マルチプラットフォーム対応
  • jQueryMobileが良いんじゃないかな？今週ver1.1がリリースされました。
  • ネイティブっぽいしモック作成もらくらくです。
  • 事例も国内大手さんとかが結構使ってるので安心なんじゃないか？→ASCII.jp：jQuery Mobileを使った国内スマホサイトまとめ (1/3)
• とは言え、HTML5オンリーで今後も進むわけじゃなくて、ハイブリッド化へ向かっていく。

HTML5&API入門

jQuery Mobile

S3-2 クラウドデザインパターン -AWSを用いたシステム設計のベストプラクティス-

AWS-CloudDesignPattern
先日のJAWS SUMMIT 2012に行けなかったので、聞きました。興味深いし、ここまで出来るのであれば利用しない手はないと思います。
ビアパーティーで、$500分のチケット当選したので、遊び倒そうと思います。
Wikiにまとめられていますが、7月に書籍化されるようです。書籍化されたら早速ポチろうと思います。

• AWSの利用拡大、普及のためにCDP（Cloud Design Patterns）を作りました。今48個あるので、CDP48です。研究生もいるよ。
• システムのアーキテクチャ設計の問題を解決するためのものです。
• パターンとは別に、利用シナリオもあって、それに沿ったパターン構成があります。
• コンテンツ配信シナリオ
  • WebStorageパターン
    • S3を使いましょう。ファイルをアップロードすれば3箇所以上にバックアップされるし、公開設定にすればURLが割り当てられます。1GBで月に10円程度です。わざわざコンテンツ配信のし組を作るのは大変です。
  • DirectHostingパターン
    • S3でHostingさせちゃいましょう
  • Cache Distributionパターン
    • 海外展開をする事になった場合はCDNを使いましょう。海外からは、その近くのリージョンに置くのがパフォーマンス良いです。
• Eコマースシナリオ
  • お金が絡むので、なるべくシステムが落ちるのを避けたいですね、損失になるから。
  • Floating IPパターン
    • システム稼動中にバージョンアップさせたい場合は、新たに環境を構築してからIPを付け替えましょう。
  • Server Swappingパターン
    • サーバが落ちた時に早く復旧したい時にはデータだけをシンボリックリンクで差し替えましょう。
  • Multi-Serverパターン
    • そもそもサーバが落ちないようにしたい場合には冗長構成にしてロードバランサー使いましょう。
    • DBもDBサーバ立てるんじゃなくて、DBサービスを使いましょう。
    • どこが落ちても大丈夫かテストするには、Working with the Chaos Monkeyを使うと良いでしょう。
  • DB Replicationパターン
    • DBも落ちちゃ困る場合には、これでホットホット。
    • データセンターを分ければなお安心
• キャンペーンサイトシナリオ
  • CMとか流れた直後に急にアクセスが増えたりするけど落ちてもらっちゃ困るよね。
  • Scale Outパターン
    • 監視して、そろそろやべーなと思ったらサーバのコピーをしましょう。落ち着いたら落としましょう。
  • Clone Serverパターン
    • さらにデータもコピーして性能を良くするときに使いましょう。
  • NFS Sharingパターン
    • サーバ間でリアルタイムにコンテンツを共有したい場合はNFSで共有しましょう。
  • NFS Replicaパターン
    • 共有するとパフォーマンスが心配になる場合はNFSのデータをローカルにも持つようにして、書き込みはNFSにもして、読み込みはローカルにするようにしましょう。
  • URL Rewritingパターン
    • それでもダメな場合はS3にデータを置きましょう。その時にURLを書き換えるURL Rewriteが良いでしょう。
• クラウドの出現によって、システム設計を前とは変える必要に迫られています。AWSとかを見ると、今やインフラもソフトウェアの一部と言えるでしょうね。
• 原則
  • 出来るだけ既存のサービスを使いましょう
  • 机上実験よりも実証実験をしましょう
  • スモールスタートからスケールアウトさせましょう
  • 変化に対して、全レイヤで対処しましょう
  • 故障することが前提の設計をしましょう
  • 最初の開発時だけでなく周期的に改善しましょう

Amazon Web Services ガイドブック クラウドでWebサービスを作ろう!

S2-3 モバイルファーストの時代へ

人間中心設計。ユーザが居て、コンテンツがあって、文脈がある。
伝わる仕組みをデザインする。

• 利用者視点でのモバイルファースト。スマホ対応と言う意味ではない。
  • 例えば？
    • AppStore：iPhone → Mac
    • ホーム画面のインタフェース：iPhone → Macランチャー
    • タッチジェスチャー：iPhone → Mac MagicTrackpad
    • メトロUI：WindowsPhone → Windows8
• GoogleもAdobeもFacebookもモバイルから作り始めているようなことを言っている
• ポイントは３つで、端末の普及、制約、新しい技術
• 端末の普及
  • 2011年から2012年くらいでPCの端末数をモバイルの端末数が上回っている
  • コミュニケーション分野、ソーシャルの世界では利用者の端末は圧倒的にモバイルになってきている
    • Twitterも実はモバイルWebを使っている人が多い。アプリをダウンロードして、インストールするのは敷居が高い。
  • 3.11もあって、個人の私物端末を利用することが許されてきている。
• 制約
  • つまり、画面サイズ。PC画面では何でも突っ込めたので、特に優先順位付けされずにアレもコレも詰め込んだ。
  • モバイルでは画面サイズの制約があるので、ユーザにとって（提供者側の都合ではなく）重要な情報だけを表現するようになる。この結果として、ユーザが目的を探しやすくなる。その結果をPCに反映する。
  • レスポンシブルWebデザインでは、端末間でのコンテンツの差が出しにくい。全てのサイズのデータをダウンロードしなければならない。
    • なので、テキストベースなニュースサイトとかには向いてる
    • 買い方が違うとか、見せたいものが違う場合には向いていない
  • 利用のコンテキスト、いつどこでどんな状況でを考えた設計にする必要がある。
  • readitlaterのピーク時間の例
    • PC：帰宅後の時間帯
    • iPhone：早朝、出勤時間帯、帰宅時間帯、就寝前
    • iPad：就寝前
    • 同じサービスでも、時間帯によって利用のされる端末、され方が違う
  • マルチチャンネル：同じコンテンツをどの端末でも利用出来るようにする
  • クロスチャンネル：モバイルで入力して、PCで確認してみたいな端末をまたがって1つのサービスを利用する
• 新しい技術
  • 位置情報、ビジュアル入力（バーコードスキャン等）、端末の向きによって異なる表現、ジェスチャーインタフェース、音声入力など、新しい技術によって、新しいデザインが生まれる。
  • ナビゲーションなどは、今までのPC利用のインタフェースの都合だっただけで、別にユーザがそのナビゲーションの---順序を辿りたいわけではない。目的はコンテンツ自身にあるので、一発で目的に辿りつけるのが良い。
    • 例えば、Siriとか。
• まとめ？
  • モバイルファーストは、つまり、コンテンツファースト
  • 見せ方や、使い方の一つの切り口

IA100 ?ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

デザイニング・ウェブナビゲーション ―最適なユーザーエクスペリエンスの設計

S2-4 最新Android動向と将来予想(ADK, NFC など)

• 今はAndroid2.3が60％だけど、2.3普及までリリースから1年とか1年半とかかかった。4.0のICSも今年の夏から普及するでしょう。docomoは7月にアップデートラッシュがあるのが発表されてる。honeycombはなかった事にする。
• honeycombでは色々と増えたけど、ICSではワクワクするような仕組みの導入は少ない。
• ICS以前の端末でもcompatibly packageを使えば使えるよ。使えないものもあるよ。
• フラグメント
  • 新しい基本要素です、必須です。テストに出るので覚えておくように。

Activityに書いていた沢山のロジックがいくつかのFragmentに分割することが出来ます。ActivityではそのFragmentの制御をするコードを書くことになる。

• • ViewがないFragmentを作れる。メリットはライフサイクルのあるライブラリを作ることが出来ること。今まではActivityのどのメソッドでどの処理をしなければいけないなど制約が多かった。Fragmentならユーザはそこまで考えなくても良くなってステキ。
  • Fragmentの差し替えで画面遷移になる。バックスタックに入れておけば戻るボタンで前の画面に戻れる。
  • ライフサイクルでは、onAttachとonCreateViewをよく使うので覚えておくように。
• アクションバー
  • ハードキーのメニューボタンが3.0以降は無くなっていきます。ユーザはとりあえずメニューボタンを押して何が出来るかを判断してたけど、画面上に出るようになったから分かりやすくなったはずだよね？
  • 基本は画面上部に出るけど、大きい端末だと指が届かなかったりするので、SplitActionBarで下部に配置出来ますよ。
• ローダー
  • AsyncTaskを良くしたものなイメージで、処理結果をキャッシュしてくれる。
  • ただ、置き換えれば良いのではなく、使い分けが大事ですよ。Loaderはデータの更新通知を受け取りたい場合に使います。AsyncTaskは頻繁に更新される場合とか、キャッシュする意味があまりないものや、毎回実行されないと困るような場合に使いましょう。
• GamePad, JoyPad
  • ActivityでGenericMotionEventが取れるようになったので、コントローラのイベントを取れます。
  • キーコンフィグを設定するのもあり
• USB Host
  • 今まではデバイス側としてのみだったけど、Host側になれます。
• ADK
  • ハードウェアを作れる人には面白いかも。
  • 対応アプリがインストールされていない場合には、指定のURLに飛ばせる。例えば、Google Playのアプリページに飛ばしたりとか。
• アクションプロバイダー
  • ActionBar用のライブラリだけど、使いどころがイマイチわかんないので、ここでいいアイデアが思いつけば有名人になれるかもね！
• wifi Direct
  • 端末同士でWifi接続出来る。セキュアで早くて簡単。モンハンみたいな通信が出来る。AdHockではない。
  • Wifi接続なので、インターネットのパーミッションが要求されてしまう。
  • API、フレームワークが使えない。すぐ落ちたりで不安定。2.3時代のNFCみたいに、次のバージョンでは洗練されるかも。
• Android Beam
  • NFCで端末と端末とで通信する。転送速度は遅いので、1KB以下の容量でやるのが良い。
  • 相手のどのアプリに向けて通信するとかを指定出来る。

Android UI Cookbook for 4.0 ICS（Ice Cream Sandwich）アプリ開発術

S1-5 現場で使えるドメイン駆動設計

cassandraの中の人のエリック・エバンスとは別人です。

• DDD本（洋書）が出たのが2003年で、だいたいWebが成熟してきたかな位の時期。
• DDDの開発で大事な事は、顧客の業務がわかっていて、顧客の言葉で話せること。そこからモデルを作ってコミニケーションをする。それに必要なのがユビキタス言語とモデル駆動設計。
• SIの現場でどう活かすのか？
  • 闇雲のDDDを導入すると躓く。実装方式と設計思想が大事である。
  • UIやDBは良いとして、ロジックをどう作るのか？の問題。
  • エンタープライズアーキテクチャパターンでは、トランザクションスクリプトとドメインモデル（とテーブルモジュール）がある。トランザクションスクリプトは手続き型で、ドメインモデルはドメイン設計をもとにオブジェクト指向でやる。
  • 単純なシステムであればトランザクションスクリプトの方が良いが、複雑なシステムではドメインモデルの方が良い。その分岐点はどこなのか？ファウラーたんに言わせれば、それは「経験豊富な人に判断任せたほうがイイね！」
• どう使い分けるか？
  • 手続き型とは、入力チェックして、DBアクセスして、必要があれば演算して、表示などの為にデータを編集することと言って良い。論理データモデルを見て、ドメインモデルとして過不足ないようなシステム。つまり業務までよくわかるような場合には、トランザクションスクリプトで良い。ロジックはつまり、SQLになる。
  • 論理データモデルで表現しきれない場合、つまり、制約（業務的な制約。業務ルール）、業務がワークフローのようにプロセスを踏む、ルールの組み合わせがある場合などはドメインモデルがいいね。
• 現実的には？
  • ユースケース的なもので業務の境界を定義しましょう。境界で分けられた単位で、トランザクションスクリプトが良いか、ドメインモデルが良いかを判断しましょう。パッケージが使えるなら使ってもよいでしょう。
    • この境界って言うのは、多分DDD的にコンテキストマップの事なのだと思う。
• 基本はトランザクションスクリプト
  • 基本設計書が書きやすいし、SQLわかりやすいし、スケール（人的リソース的な意味で）しやすい。ウォーターフォールがやりやすい。そもそも単純なところだから、予測しやすいのでウォーターフォールに向いてる。もちろん、プロジェクトによってケースバイケースではあるよ。
• 複雑なドメインにはそれなりの戦術が必要
  • 基本設計書が書きにくい（それはつまりテキストで複雑すぎる、補足資料的なものに頼らないといけない箇所）。手続き的なドキュメントが書きにくい。なので、ウォーターフォールやりにくい。
  • こんな場面では、イテレーティブ、インクリメンタル。シナリオ（時間的な観点）とモデル（通時的な観点）で設計して実装してみる。
  • でも、難しいですよ、実際
• DAKARA
  • メンバーの力量や期間と相談しなければならない
  • その判断をするのは、アーキテクトの責任である
• まとめ
  • 業務を理解しよう
  • ドメインを分割しよう
  • 適切なプロセスを割り当てよう

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

S3-6 ソーシャルゲームにおけるAWS／MongoDB利用事例

• MongoDBって？
  • ドキュメント指向で、BSON（バイナリJSON）のデータ形式で、スキーマレスなNoSQLなDBです。
  • FullIndexSupportなので、どんな属性にもインデックス張れます。
  • Replication
    • 3台一組で、1つがプライマリ、ほか二つがセカンダリ、プライマリが落ちたら自動的にセカンダリがプライマリに昇格し、落ちたものが復旧したら自動的にセカンダリに割り当てられる
  • Auto-Sharding
    • ShardKeyを指定することで、水平分割出来ます。その範囲をチャンクと言います。データ量によって、自動的に行われます。mongosがどこにあるか把握しているので、クライアントは意識せずにmongosにアクセスすれば良いです。どこに何があるのかを知っているのはmongocでコンフィグ情報を持っています、mongosはmongocに問い合せてから実際にアクセスしに行きます。
• Animal Landって？
  • FacebookのSocialゲームのアプリです。
  • AWS上で動いています
• AWS関連で
  • 環境毎にリージョンを分けた方が良いです。
  • EC2は同じ構成でもサーバによってパフォーマンスが違う場合があるので、多めに立ち上げて、チェックしてから必要な分だけ使うのが良いです。
  • AWS側のメンテでいついつに再起動されますと案内があるけど、予め再起動しておけば大丈夫なことが多いです。
  • ELBはEC2のインスタンスを全て切り離してしまうと起動に時間がかかるので、予めソーリーページのあるサーバだけにつないでから、他を切り離すのが良いです。
  • CloudFrontはキャッシュのクリアが難しいので、少しの修正でもバージョンを上げるのが良いです。URLにバージョンを含めておく感じです。
• MongoDBポイント
  • データが複雑な場合（多様性がある場合）はRDBでは厳しいです。
  • 1ユーザで1つのデータが良いです。ただし、詰め込み過ぎるとNGです。BSONのパースに時間がかかります。プロパティを増やしすぎないような工夫が必要です。
  • MongoDBに合わない部分、トランザクション制御が求められるとかの場合は、その部分を別の仕組み（RDB）を利用すると割り切った方が良いです。
  • メモリに乗り切る範囲で分割をしましょう。
  • ロールバックはしない前提で、ユーザに不利にならないように設計しましょう。
• インフラ
  • 検証を繰り返しました。Replication Set、Shradの構成をかんがえましょう。
  • なるべくメモリを詰める構成でやりましょう。
  • ジャーナリングを利用しよう
  • MongoDBの新しいコレクションは必ずプライマリに作られちゃうので、一度に沢山のコレクションを作るとプライマリに集中してしまいます。

Scaling MongoDB