DeNAが明かすHTML5でのソーシャルゲームの作り方【本日のスライド】 / GameBusiness.jp
スマートフォンにてソーシャルゲームを作ろうとすると、HTML5を中心にブラウザで動作するもの、もしくはネイティブアプリでの提供ということになります。モバゲータウンやグリーはその両方をサポートしています。ネイティブアプリの作り方は既に文献も多数なのですが、HTML5となるとまだ十分とは言えません。この資料は必見です。 「HTML5@iPhoneゲーム開発」はディー・エヌ・エーのスマートフォン開発グループの岸弘倫氏が「DeNA Technology Seminar #3」での講演用に作成したものになります。同社では北米のMiniNation向けにiPhone『Pirate Nation』(海賊トレジャー)をHTML、CSS、JavaScriptで開発して提供していて、そのノウハウを凝縮したものです。 『Pirate Nation』は冒頭の括りで分けるとブラウザで動作するアプリということにな
達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト | Act as Professional
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。 予期せぬバグはスケジュールに致命的な影響を与える。 手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。 達人プログラマーはどうするのか？p.241 第8章 達人のプロジェクトより 早めにテスト、何度もテスト、自動でテスト 書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。 このテストをあながた手を動かしてやっている暇はありません。 あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。 自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも
達人プログラマーに学ぶ リファクタリング | Act as Professional
ガーデニングのメタファーはソフトウェア開発の現実にかなり近いものです。あるルーチンが大きくなりすぎたり、色々なことを実現しようとしすぎている場合、2つに株分けする必要があるのです。また、計画通りうまくいかないものは雑草を抜いたり剪定してやらないといけないのです。 こういったコード記述のやり直し、再作業、再設計を総称して「リファクタリング」と呼びます。 リファクタリングのきっかけ DRYの原則に反している 直交していない設計 時代遅れの知識をつかっている パフォーマンスがわるい クラス、メソッドが長い 名前がしっくりこない 同じようなコピペコードがいくつも見られ、UIを直すとロジックを直して、DBもなおすとか。非推奨のメソッドを使っていたり。ループ分が多いし、やってることとメソッドの名前があっていないとか。みなさんも、思い当たるようなことはありませんか？ タイミングとガン細胞の切除 きっかけ
構成管理 実践入門 第3章 Subversionベストプラクティス コードライン編その１ メインライン
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その１ メインライン コードライン編その２ コードラインポリシー コードライン編その３ プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その１ リリース管理 リリース編その２ 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか？ Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
今年はWebサービスを作りたいと思っている人にお勧めのエントリーまとめ | ロプログ
明けましておめでとうございます！ 近年、個人でWebサービスを開発するのが流行っていますね。「今年こそは俺もWebサービスを作ってモテモテになるぜ！」と思っている人も多いのではないでしょうか。 そんな人のために、Webサービスを開発・運営するにあたっての心構えやノウハウ、体験談などの書かれたエントリーを集めてみました。 ▼誠 Biz.ID：田口元の「ひとりで作るネットサービス」探訪 個人でWebサービスを開発している人たちのインタビュー集。ヒットしたサービスを手がけた個人開発者達のバックグランドや考え方を垣間見ることができ、モチベーションアップにもなります。恥ずかしながら、私のインタビューも載っています。 ▼Web2.0ナビ: 個人サービスを作るコツ 個人がWebサービスを作るための、実践的な8つのコツが書かれています。 ▼個人でネットサービスを運営するための5つのコツ（momose版）:
Google Android用携帯アプリ作成のための基礎知識 （1/5） - ＠IT
“Android”って何？ 人造人間のこと？ Androidは、Googleが発表した携帯電話のプラットフォームです。発表と同時にいろいろな媒体で紹介されましたから、ご存じの方も多いことでしょう。まだ、ご存じでない方は、ニュース記事「グーグルが「アンドロイド」SDK公開——動画デモも〜エミュレータも提供〜」が参考になるでしょう。 Linux 2.6カーネルをベースとしていて、アプリケーションの開発にはJavaを使うことができます。早速、SDK（ソフトウェア開発キット）をダウンロードして試用してみました。 携帯電話アプリ向けのJava MEとの互換性がない ところで、携帯電話などで動作するアプリケーション向けのJava Platformといえば、SunのJava ME（Java Platform, Micro Edition）があるわけですが、Androidで動作するJavaアプリケーション
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
[GSC] TOC概要
TOCの概要 ＴＯＣ概論 ＴＯＣは、営利企業共通の目的である「現在から将来にわたって儲け続ける」というゴールの達成を妨げる制約条件（Constraints）に注目し、企業内共通の目標を識別し改善を進める事によって、企業業績に急速な改善をもたらします。すなわちＴＯＣとは企業収益の鍵を握る「制約条件」にフォーカスする事によって、最小の努力で最大の効果（利益）をあげる経営管理手法です。 ７０年代前半、ＴＯＣの開発者であるエリー・ゴールドラット博士は、「工場の生産性はボトルネック工程の能力以上は絶対に向上しない。」という至極当たり前の原理を提唱しました。工場の生産性を上げるためにネック工程に同期させる生産を行い、資材調達もネック工程に同期させるようにした結果、生産性が飛躍的に高まり、仕掛りや在庫が劇的に減少する事を実証し、それをＴＯＣ（制約条件の理論）として普及していったのです。 その後ＴＯＣは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
