脱RESTful API設計の提案
3. フロントアプリ スタンドアロンゲームの構成要素(例) グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード 全ての機能はフロントアプリに実装される 4. ソーシャルゲームになって構成要素が増えた 各種 マスタリソース 追加シナリオ イベント配信 アカウント 引き継ぎ 会員登録 多端末 同時利用 運営から アカウント凍結 アプリ上データ アカウント関連機能 会員 セーブデータ データ管理機能 各種ログ管理 フレンド 登録管理 （準）課金機能 その他運営機能 連続ログイン 報酬 課金管理 アイテム ガチャ管理フレンド連携 報酬管理 報酬付与 グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード どの機能をゲームサーバに持たせる
Amazon Dash Buttonは何がヤバイのか
Amazon Dash Buttonについて、人と話す機会が何度かあったので、 いかにAmazon Dash Buttonがヤバイかを毎度説明するのだが、 「あんな電池が一年で切れるデバイスは使えない」 「商品がドラッグストアよりも高いのに買うやつはいない」 といった的外れな答えが割と帰ってきて、もんにょりすることが多いので、私が思うヤバさを解説してみようと思う。 エンジニアリング的なヤバさ Amazon Dash Buttonは、どう考えてもビジネスモデルから逆算してハードウェアを設計しているので、ハードウェアから設計して、ビジネスモデルを作ろうとしている連中は絶対に勝てない。 ビジネスモデルによってハードウェアに対する要求は大幅に変わる。 IoTデバイスはコスト、大きさの面でリソースが限られているため、限られたリソースをどこに割り振るかで、要求を満たせるかどうかが決まる。 Amazon
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
