タグ

プログラミングに関するyuriapのブックマーク (5)

  • 民主党風プログラマースレ:アルファルファモザイク

    民主党風な発言を普通にするプログラマーって、結構いるよね・・・ 上司 「何故進捗50%なんて嘘をついていたんだ!!まだ30%程度じゃないか!!」 PG  「進捗率というものが、どういうものなのかよくわからない」 仕様書無しさん :2010/01/25(月) 15:44:23 上司 「おいおい、どこをどうやったらこんなバグを仕込むんだよ」 ハト 「知らない」 上司 「知らないってことないだろ!お前が打ち込んだんだよ、これは。間違いなく!」 ハト 「忘れました」 上司 「ふざけんな!もうお前には一切仕事与えんからな!!」 ハト 「信じてください!!!僕は当は優秀なんですけど、まだ試用期間中だから気じゃないんです!トラスト・ミー!」 4 仕様書無しさん :2010/01/25(月) 16:24:27 「見つからなければ、バグを直す必要はない」 「直したじゃないか。何が

  • ユメのチカラ: 開発工程を別々に担当してはいけない

    古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

  • 自動化のための nmake 入門講座 - 基本的なパターン

  • Make と Makefile の説明

    まだ完成途中です back 注意: このページの内容には、おそらく多くの間違いがあります。 リンクされているので残しておきますが、利用には注意してください。(2008年3月、新山) ここではおもに make の使い方 と Makefile の書き方について 説明しています。じつは make の種類にはいろいろあり、ここでは GNU make (gmake というコマンド名のこともある) を 対象にしています (BSD の pmake でも基的な部分は同じですが、 マクロ定義などは違うところもあるので注意してください)。 わかりにくい箇所とか、まちがってる箇所がある場合はメールください。 Contents make はどんなときに使うか Makefile を作る make の実行 Makefile の文法リファレンス 多段 make について (未完成) Makefile の例 (未完成)

  • OpenCV.jp

    Reference Manual OpenCV-2.x(svn) C: リファレンス日語訳 C++: リファレンス日語訳 OpenCVチートシート(C++)(訳) OpenCVユーザガイド(訳) Python: リファレンス日語訳 Google Test-1.6 Google Test ドキュメント日語訳 Google Mock(svn) Google Mock ドキュメント日語訳 OpenCV-2.2(r4295相当) C: リファレンス日語訳 C++: リファレンス日語訳 OpenCVチートシート(C++) (訳) Python: リファレンス日語訳 OpenCV-2.1(r2997相当) C: リファレンス日語訳 C++: リファレンス日語訳 OpenCVチートシート(C++) (訳) Python: リファレンス日語訳 OpenCV-1.1pre C/C++:

  • 1