早くやることで、多くを学べる、沢山こなして学ぶ。想像するよりも、経験から導かれた予測の方が良いよ。考えて試すのサイクルを回そう。HTML5,モバイル,オフラインスクロールを使ったエフェクトが流行ってるらしい。モバイルでHTML5なネガティブな理由は古いIE対応しなくてよく、FlashはiOSで動かないから。ポジディブな理由は出来ることが増えているから。manifest使えばオフラインでも読むことが出来る。静的リソースをローカルにキャッシュするから。キャッシュしてるから早い。更新の少ないコンテンツ系は良いけど、それ以外の動的なアプリケーションはこれだけでは作れない。オフラインでもWrite出来る仕組みが必要です。DBやFileシステムが必要です。APIとかFileAPIとか。サーバ側とは同期エンジンを作ってそれに任せる。APIは使えるようになったけど、正直APIが使いにくい。hatenaFileAPIはローカルでFileが使えます。セキュリティ大丈夫?って思うけど、ユーザが選択したファイルしか読み込めません。書き込みはSandboxの仮想ファイルシステム上なので安全。デバイス機能へのアクセスAPIもすごく簡単です。基本的にAPIがシンプル。デバイス毎に使えるAPIが異なるのでチェックする。devices断片化してるけど、Facebookさんがどうにかしようと頑張って、各ブラウザベンダに実装の優先順位を提案してる→ringmarkスクリーンサイズ対応レスポンシブWebデザインだけど、まずはモバイルからが良いのではないか?今まではPCからだったけど、PCからやるとモバイルの制約に引っかかることもある。コンテンツのサイズが大きくなるので万能じゃないです。Appsマルチプラットフォーム対応jQueryMobileが良いんじゃないかな?今週ver1.1がリリースされました。ネイティブっぽいしモック作成もらくらくです。(1/3)とは言え、HTML5オンリーで今後も進むわけじゃなくて、ハイブリッド化へ向かっていく。2012に行けなかったので、聞きました。興味深いし、ここまで出来るのであれば利用しない手はないと思います。ビアパーティーで、$500分のチケット当選したので、遊び倒そうと思います。Wikiにまとめられていますが、7月に書籍化されるようです。書籍化されたら早速ポチろうと思います。Patterns)を作りました。今48個あるので、CDP48です。システムのアーキテクチャ設計の問題を解決するためのものです。パターンとは別に、利用シナリオもあって、それに沿ったパターン構成があります。コンテンツ配信シナリオWebStorageパターンS3を使いましょう。ファイルをアップロードすれば3箇所以上にバックアップされるし、公開設定にすればURLが割り当てられます。1GBで月に10円程度です。コンテンツ配信のし組を作るのは大変です。Distributionパターン海外展開をする事になった場合はCDNを使いましょう。海外からは、その近くのリージョンに置くのがパフォーマンス良いです。Eコマースシナリオお金が絡むので、なるべくシステムが落ちるのを避けたいですね、損失になるから。IPパターンシステム稼動中にバージョンアップさせたい場合は、新たに環境を構築してからIPを付け替えましょう。Swappingパターンサーバが落ちた時に早く復旧したい時にはデータだけをシンボリックリンクで差し替えましょう。Multi-Serverパターンそもそもサーバが落ちないようにしたい場合には冗長構成にしてロードバランサー使いましょう。DBもDBサーバ立てるんじゃなくて、DBサービスを使いましょう。Monkeyを使うと良いでしょう。ReplicationパターンDBも落ちちゃ困る場合には、これでホットホット。データセンターを分ければなお安心キャンペーンサイトシナリオCMとか流れた直後に急にアクセスが増えたりするけど落ちてもらっちゃ困るよね。Outパターン監視して、そろそろやべーなと思ったらサーバのコピーをしましょう。落ち着いたら落としましょう。Serverパターンさらにデータもコピーして性能を良くするときに使いましょう。Sharingパターンサーバ間でリアルタイムにコンテンツを共有したい場合はNFSで共有しましょう。Replicaパターン共有するとパフォーマンスが心配になる場合はNFSのデータをローカルにも持つようにして、書き込みはNFSにもして、読み込みはローカルにするようにしましょう。Rewritingパターンそれでもダメな場合はS3にデータを置きましょう。Rewriteが良いでしょう。クラウドの出現によって、システム設計を前とは変える必要に迫られています。AWSとかを見ると、今やインフラもソフトウェアの一部と言えるでしょうね。モバイルファーストの時代へ人間中心設計。ユーザが居て、コンテンツがあって、文脈がある。伝わる仕組みをデザインする。利用者視点でのモバイルファースト。スマホ対応と言う意味ではない。端末の普及2011年から2012年くらいでPCの端末数をモバイルの端末数が上回っているコミュニケーション分野、ソーシャルの世界では利用者の端末は圧倒的にモバイルになってきているTwitterも実はモバイルWebを使っている人が多い。アプリをダウンロードして、インストールするのは敷居が高い。3.11もあって、個人の私物端末を利用することが許されてきている。制約つまり、画面サイズ。PC画面では何でも突っ込めたので、特に優先順位付けされずにアレもコレも詰め込んだ。モバイルでは画面サイズの制約があるので、ユーザにとって(提供者側の都合ではなく)重要な情報だけを表現するようになる。この結果として、ユーザが目的を探しやすくなる。その結果をPCに反映する。レスポンシブルWebデザインでは、端末間でのコンテンツの差が出しにくい。全てのサイズのデータをダウンロードしなければならない。テキストベースなニュースサイトとかには向いてる買い方が違うとか、見せたいものが違う場合には向いていない利用のコンテキスト、いつどこでどんな状況でを考えた設計にする必要がある。位置情報、ビジュアル入力(バーコードスキャン等)、端末の向きによって異なる表現、ジェスチャーインタフェース、音声入力など、新しい技術によって、新しいデザインが生まれる。ナビゲーションなどは、今までのPC利用のインタフェースの都合だっただけで、別にユーザがそのナビゲーションの---順序を辿りたいわけではない。目的はコンテンツ自身にあるので、一発で目的に辿りつけるのが良い。)今はAndroid2.3が60%だけど、2.3普及までリリースから1年とか1年半とかかかった。4.0のICSも今年の夏から普及するでしょう。docomoは7月にアップデートラッシュがあるのが発表されてる。honeycombはなかった事にする。honeycombでは色々と増えたけど、ICSではワクワクするような仕組みの導入は少ない。packageを使えば使えるよ。使えないものもあるよ。フラグメント新しい基本要素です、必須です。テストに出るので覚えておくように。Activityに書いていた沢山のロジックがいくつかのFragmentに分割することが出来ます。ActivityではそのFragmentの制御をするコードを書くことになる。ViewがないFragmentを作れる。メリットはライフサイクルのあるライブラリを作ることが出来ること。今まではActivityのどのメソッドでどの処理をしなければいけないなど制約が多かった。Fragmentならユーザはそこまで考えなくても良くなってステキ。Fragmentの差し替えで画面遷移になる。バックスタックに入れておけば戻るボタンで前の画面に戻れる。ライフサイクルでは、onAttachとonCreateViewをよく使うので覚えておくように。アクションバーハードキーのメニューボタンが3.0以降は無くなっていきます。ユーザはとりあえずメニューボタンを押して何が出来るかを判断してたけど、画面上に出るようになったから分かりやすくなったはずだよね?基本は画面上部に出るけど、大きい端末だと指が届かなかったりするので、SplitActionBarで下部に配置出来ますよ。ローダーAsyncTaskを良くしたものなイメージで、処理結果をキャッシュしてくれる。置き換えれば良いのではなく、使い分けが大事ですよ。Loaderはデータの更新通知を受け取りたい場合に使います。AsyncTaskは頻繁に更新される場合とか、キャッシュする意味があまりないものや、毎回実行されないと困るような場合に使いましょう。JoyPadActivityでGenericMotionEventが取れるようになったので、コントローラのイベントを取れます。Host今まではデバイス側としてのみだったけど、Host側になれます。ADKハードウェアを作れる人には面白いかも。対応アプリがインストールされていない場合には、指定のURLに飛ばせる。Playのアプリページに飛ばしたりとか。Direct端末同士でWifi接続出来る。セキュアで早くて簡単。モンハンみたいな通信が出来る。AdHockではない。Wifi接続なので、インターネットのパーミッションが要求されてしまう。API、フレームワークが使えない。2.3時代のNFCみたいに、次のバージョンでは洗練されるかも。BeamNFCで端末と端末とで通信する。転送速度は遅いので、1KB以下の容量でやるのが良い。相手のどのアプリに向けて通信するとかを指定出来る。現場で使えるドメイン駆動設計cassandraの中の人のエリック・エバンスとは別人です。DDD本(洋書)が出たのが2003年で、だいたいWebが成熟してきたかな位の時期。DDDの開発で大事な事は、顧客の業務がわかっていて、顧客の言葉で話せること。そこからモデルを作ってコミニケーションをする。それに必要なのがユビキタス言語とモデル駆動設計。SIの現場でどう活かすのか?闇雲のDDDを導入すると躓く。実装方式と設計思想が大事である。UIやDBは良いとして、ロジックをどう作るのか?の問題。エンタープライズアーキテクチャパターンでは、トランザクションスクリプトとドメインモデル(とテーブルモジュール)がある。トランザクションスクリプトは手続き型で、ドメインモデルはドメイン設計をもとにオブジェクト指向でやる。単純なシステムであればトランザクションスクリプトの方が良いが、複雑なシステムではドメインモデルの方が良い。その分岐点はどこなのか?ファウラーたんに言わせれば、それは「経験豊富な人に判断任せたほうがイイね!」どう使い分けるか?手続き型とは、入力チェックして、DBアクセスして、必要があれば演算して、表示などの為にデータを編集することと言って良い。論理データモデルを見て、ドメインモデルとして過不足ないようなシステム。業務までよくわかるような場合には、トランザクションスクリプトで良い。ロジックはつまり、SQLになる。論理データモデルで表現しきれない場合、つまり、制約(業務的な制約。業務ルール)、業務がワークフローのようにプロセスを踏む、ルールの組み合わせがある場合などはドメインモデルがいいね。現実的には?ユースケース的なもので業務の境界を定義しましょう。境界で分けられた単位で、トランザクションスクリプトが良いか、ドメインモデルが良いかを判断しましょう。パッケージが使えるなら使ってもよいでしょう。この境界って言うのは、多分DDD的にコンテキストマップの事なのだと思う。基本はトランザクションスクリプト基本設計書が書きやすいし、SQLわかりやすいし、スケール(人的リソース的な意味で)しやすい。ウォーターフォールがやりやすい。そもそも単純なところだから、予測しやすいのでウォーターフォールに向いてる。プロジェクトによってケースバイケースではあるよ。基本設計書が書きにくい(それはつまりテキストで複雑すぎる、補足資料的なものに頼らないといけない箇所)。手続き的なドキュメントが書きにくい。ウォーターフォールやりにくい。こんな場面では、イテレーティブ、インクリメンタル。シナリオ(時間的な観点)とモデル(通時的な観点)で設計して実装してみる。ソーシャルゲームにおけるAWS/MongoDB利用事例MongoDBって?ドキュメント指向で、BSON(バイナリJSON)のデータ形式で、スキーマレスなNoSQLなDBです。FullIndexSupportなので、どんな属性にもインデックス張れます。Replication3台一組で、1つがプライマリ、ほか二つがセカンダリ、プライマリが落ちたら自動的にセカンダリがプライマリに昇格し、落ちたものが復旧したら自動的にセカンダリに割り当てられるAuto-ShardingShardKeyを指定することで、水平分割出来ます。その範囲をチャンクと言います。データ量によって、自動的に行われます。mongosがどこにあるか把握しているので、クライアントは意識せずにmongosにアクセスすれば良いです。どこに何があるのかを知っているのはmongocでコンフィグ情報を持っています、mongosはmongocに問い合せてから実際にアクセスしに行きます。Landって?FacebookのSocialゲームのアプリです。AWS上で動いていますAWS関連で環境毎にリージョンを分けた方が良いです。EC2は同じ構成でもサーバによってパフォーマンスが違う場合があるので、多めに立ち上げて、チェックしてから必要な分だけ使うのが良いです。AWS側のメンテでいついつに再起動されますと案内があるけど、予め再起動しておけば大丈夫なことが多いです。ELBはEC2のインスタンスを全て切り離してしまうと起動に時間がかかるので、予めソーリーページのあるサーバだけにつないでから、他を切り離すのが良いです。CloudFrontはキャッシュのクリアが難しいので、少しの修正でもバージョンを上げるのが良いです。URLにバージョンを含めておく感じです。MongoDBポイントデータが複雑な場合(多様性がある場合)はRDBでは厳しいです。1ユーザで1つのデータが良いです。詰め込み過ぎるとNGです。BSONのパースに時間がかかります。プロパティを増やしすぎないような工夫が必要です。MongoDBに合わない部分、トランザクション制御が求められるとかの場合は、その部分を別の仕組み(RDB)を利用すると割り切った方が良いです。メモリに乗り切る範囲で分割をしましょう。ロールバックはしない前提で、ユーザに不利にならないように設計しましょう。インフラ検証を繰り返しました。Set、Shradの構成をかんがえましょう。メモリを詰める構成でやりましょう。ジャーナリングを利用しようMongoDBの新しいコレクションは必ずプライマリに作られちゃうので、一度に沢山のコレクションを作るとプライマリに集中してしまいます。はてなブログProフリーでプロのグラマーしています。パターン別構築・運用ガイドを読みました。夫婦で人間ドックに行ってきたLifeLogをシェアしてみた。フットボールライフ・ログサービススターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。