ダメプログラマの日常1
ある日の昼下がりの出来事。 はい。ダメプログラマですみません。 誰か「1万ステップのコードと100万ステップのコードで、検出された障害がどちらも100件だった場合は、どちらが品質が悪いと考えられますか？」 自分「それはそもそも粒度というか構成が異なるので議論出来ないと思います」 誰か「粒度が同じだと仮定した場合は？」 自分「それは1万ステップのコードの方が品質が悪いと見えますね(その比較自体が無意味ですが…)」 誰か「であれば、そうやってプログラムコードの品質を分析してください」 自分「。(いや、だから、粒度を同じにするという前提条件が現在のプログラム言語とアーキテクチャでは無意味ですよね)」 次に続いたような… ＃ そもそもCOBOLの時代(いや、実際には知らないけど)じゃあるまいし、 ＃ すべてが同じ粒度のOOPな構成のプログラムってどんなんだろか。 これは、(たぶん)フィクション(だ
単体テストの品質分析に関する妄想(途中)
(普段何気なくやってる事を整理しただけなので、別にたいしたことを書いている訳ではない) 単体テストで品質分析を行う場合、 プロダクトコードの検証 コードフォーマットに起因する問題分析 実施方法::CheckStyle,CPDなどを利用する(Javaの場合) 目的::読みやすいクリーンなコードを維持する事で、読み違いやミスなどを防止する。 フォーマット規約に反していないか、冗長なコードがないか、重複したコードがないかを検証する。 問題があった場合に、対象のコードに対応が必要かどうかを検討する。 プログラムコード構造に関する問題分析 実施方法::FindBugs,PMDなどを利用する。 目的::実装中の考慮漏れをコードの構成側から分析する。 構造上に潜在的に危険なコードがないか検証する。 問題があった場合は、問題の大きさを考慮して対応が必要かどうかを検討する。 ただし、これらのツールは問題の大
Step数と詳細設計書
私はStep数単位での会話が出来ない、ダメダメプログラマです。 先日、あるプロジェクトのやり方が変わって「ちゃんとやる」ようになると言われました。 「ちゃんと」というのは、その某社の定めた品質指標に従っているかどうかであり、 最初に契約した内容通りのものが期限内に作成できているかであって、 顧客の満足度とか、要求の変化を受け入れるためのコミュニケーションとか そういったものは、100万光年の彼方にあるらしいです。 まさに、これを地でいっている感じ。 個人と対話よりもプロセスやツールを重要とし、 動くソフトウェアよりも包括的なドキュメント、 顧客との協調よりも契約交渉を、 変化への対応よりも、計画に従うことを重視する 衝撃だったこの一言。 契約がすべてなんだよ 契約は大事です。はい。 しかしながら契約が「すべて」でもありませんし、契約が「いちばん」でもないと思います。 それは、発注された側の
TDD読書会#3+北陸エンジニアグループ2009振り返り会に行ってきたよ
と言うわけで、TDD読書会#3+北陸エンジニアグループ2009振り返り会に行ってきました。 って、あれ開発プロセス勉強会だったような気が…まぁいいか。 北陸エンジニアグループに関連する勉強会は今年はこれで最後になります。 なんだか色々あった気がしますが、そちらは年末に改めて振り返ってみます。 あと、最後に@yuuitiroさんに、毎度のことながらインフラ関係を感謝したく思います。 目立たないけど、一番大事な縁の下の力持ちだと思います。 さて本題。 今回はこじんまりした形式ではなく、講義形式でTDD読書会では初参加の方がたくさんいたので、 冒頭に15分ほどTDDの歴史byKanazawaProcessとして発表しました。 以下がスライドです。 で、以下は内容の一行感想 詳しくは、他のみなさんが書かれてるのでそちらに譲ります。 #1 @hikaruworld 自分なので、省略。 #2 @coe
FlexAutomationAPIに関して
FlexAutomationAPIの説明がぐだぐだになったので、悔しいのでblogで補足していきます。 FlexAutomationAPIとは FlexAutomationAPIとは、Flexフレームワークで提供されているAPIで Flexコンポーネントに対するユーザ操作をオートメーションする事が可能になります(と、解釈しました)。 ただし、このAPIはFlexBuilderProfessionalが必須に成ります。 ※standard版でも実行可能ですが、一回あたりのアクション数が30回に限定されています。 (リリースドキュメントに書いてあったんですが、探すに苦労しました…) これは、FlexAutomationAPIを利用するのに必要なライブラリ automation.swc — Flexコンポーネントの委譲クラス群 automation_dmv.swc — FlexチャーティングとA
Flex@北陸in石川に行ってきた。
Flex@北陸in石川に行ってきました。 相も変わらず、基本的には一行感想で。 「Flash Catalyst + Flash Builder 4(仮)」 アドビシステムズ 轟さん Catalystすげー、って感じですね。デザイナさんとこういうのをやってみたい。でもそれよりもARに惚れた自分がいます。 「FlexMonkey紹介」 hikaruworld うーん、失敗した。FlexAutomationAPI色々面白いと思うんだけど、説明しきれない。 Mixinに関しては多重継承の概念の一部の手法のみを許しているという考えが正解？ 「Flexで作るおされビンゴアプリ」 katzchangさん ん？いつの間にかFlexから、開発プロセスに流れている気が….bibibingo!!。これからずっと使われることになりそうｗ 「Silverlight入門」 hr_saoさん やはりFlexとSilve
GoogleMapAPI For Flashを試行中
いまさらながら、GoogleMapAPI For Flash を利用してみました 。 目的としては、逆ジオコーディング とルート検索を利用したかったのでその辺りを中心に試してみています。 とりあえず、インストールからの簡単な流れで説明をば。 なお、環境としてはFlexBuilder3 を利用してAdobeAirでサンプルを作成しています。 インストール 1. GoogleMapAPIのサイトに行き登録URLとAPIkeyを取得します。 2. GoogleMapAPI For Flash のSDKをダウンロードします。 3. SDKを展開して、FlexBuilderで作成されたAirプロジェクトのlibs以下にmap_flex_1_16.swcをコピーします。 地図を描画 メインとなる.mxmlに以下のようなコードを追記します。 urlはインストール時に登録したURL、keyはその際に取得し
開発プロセス勉強会に行ってきた(2009/05/16)
えーと、今更なんですが、一週間前wに開発プロセス勉強会に行ってきました。 現在諸事情により、平日は家ではPC禁止になっておりorz… と、とりあえず、勉強会の内容の詳しくはここに書かれています。 以下、印象的だった事を断片的に。 JUnitのテスト名は日本語!! TDDは品質管理のテストではなく、プログラムを稼働させるためのテストである。 だから、極端にreturn 10とかやってもよい。簡単に実装することが大切。 そのため、TDDのテストはそのまま品質テストとはなり得ない。 じゃあCIのテストって何よ？ 新人さんとペアプロする際に思考をトレースするのに便利そうだ。 1.JUnitのテスト名は日本語!! nagiseさんの言う通り、やっぱり自動テストは日本語!! JUnit4になって@Testのおかげでメソッド名のprefixに【test】をつけなくてよくなったし。 何十というテストを実行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
