タグ

ソフトウェア開発に関するfield_combatのブックマーク (5)

  • でらうま倶楽部 : ゲームを作ろうと思ったらライブラリを作ってはいけない

    2012年05月27日17:32 カテゴリプログラム雑記 ゲームを作ろうと思ったらライブラリを作ってはいけない さいきん告知ばっかりだったので(それも一年くらい!)、久々に思う事を思うように。 ここ数年、専門学校に教えに行ってるのですが、プログラミング初心者~中級者は、やっぱみんなハマるんだよね… ライブラリ症候群 ワシ的には「自作ライブラリで環境整備」「後々ほかのプロジェクトで使いまわせるようにコードを書く」のにはまったく積極的じゃないので、今回はそれについて書いてみるす。ゲームを作る事について書いてますが、ほかもだいたい同じだと思う。 みんなを見てると、まあだいたいこんな感じの流れ。 ゲームをつくるぜ!そのまえに、ライブラリなるものを作って環境を整えよう頓挫みたいな。最初の心意気はよかったものの、結果として何も完成しませんでした…という感じ。 なんでだろね。 コレ、途中から「ゲームを完

    field_combat
    field_combat 2012/05/28
    作っちゃったYo! そして出来上がった感を強く感じて本編を作る気が起きない・・・
  • 2061:Maxオデッセイ » Blog Archive » iPhoneアプリケーション開発講座がスタート

    Max/MSP/Jitterの総合解説書「2061:Maxオデッセイ」のサポート・サイト。書籍の概要説明、情報交換用ブログ、サンプル・パッチのダウンロード、関連情報へのリンク集など。今日からIAMASでiPhoneアプリケーション開発講座が始まりました。ってか始めました。世界初じゃないとしても、日ではまだ珍しいんじゃないかな? Maxなら、この読んでおいてね〜で済んじゃうんですが、さすがにObjective-C/Cocoa Touchはそうは行かないので、簡単なナビゲーションをしている次第。 初回となる今回は開発環境の概要説明から始めて、サンプル・コードのビルド、実行、デバッグなどの開発手順を一通り追いかけるスタイルで進行。以下に資料をリンクしておきますが、これまでの情報を軽くまとめたものです。目新しい情報やクリティカルな情報はありません(それは口頭で〜笑)ので、このサイトをご覧の方に

  • HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方

    HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,

  • ウノウラボ Unoh Labs: オープンソース戦略により、無償で使えるようになった負荷テストツール

    こんにちは! やまもと@テスト番長です。 ウノウラボのコメント欄まで熟読されている慧眼な方は既にお気づきかもしれませんが、WebLOADという商用の負荷テストツールがオープンソース化され、無料で利用出来るようになりました。 http://www.webload.org/ 以前自分が書いた WEBアプリのテストに必須なツール7種のエントリにsaltysonicさんがコメントで教えてくださいました。ありがとうございました! souceforge.net を探してみたところ、見つかりました。 WebLOAD 早速触ってみていますが、さすがに元商用だけあって多機能なようです。 関連記事も探してみたところ、以下のものが見つかりました。 http://news.earthweb.com/ent-news/article.php/3670176 http://www.testingreflec

  • デモではものができあがっているように見せない

    Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには・・・彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも

  • 1