Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
「あなたがTDDやユニットテストについて課題に感じていることがあれば、教えてください。」 - @katzchang.contexts
参加者アンケートより。 想定バグ検出件数とか、昔からなぜかある指標を打ち倒すこと やろうと思ってもなかなかできない・・・ モックのライブラリー等を使ったテストケースの書き方。すべてのテストケースの実行時間の短縮 知識のみで実際の経験がないこと。テストを書くのが難しいためテストケースを書けない場合がある。 テストを先に書く文化がなかなか根付かない→テストできないコーディングをしているorz 社内が従来のやり方に固執している為、新しい手法が試せない。 テストドリブンな手法を開発以外の分野にも適用してみたい。 マルチスレッド関連のテスト方法が分からない。 BDDなど、他のテスト技法（？）との使い分けが分からない。BDDはTDDの一部？ 他のクラスが必要で、テスト対象クラスのインスタンス化ができないやつとか、データベース使うやつのテストコードの書き方が分からないので、勉強が必要だと思う。 開発時点
SI業界人は要チェック！！Subversionでのベンダブランチの運用手順。
外部から納品物に自分たちが手を入れるような場合や、他の人が作ったパッケージ製品を改造して提供するような仕事を管理する場合に使えるパターンです。つまり、SI業界には必須ともいえるパターンなはず。 レポジトリにvendorディレクトリを切っておき、その下でベンダから受領したブツを管理する。納品毎にバージョンtagをつける。そこから枝分かれさせたものを、自分のプロジェクトのサブディレクトリとして管理していく。こうやって管理することで、ベンダからの受領物を自分のプロジェクトにマージするときに、SVN力をいかんなく発揮させることができます。 参考：http://hide.xsv.info/tips/svnmanual/merge3/ 今更な人には今更だろうけど、今更じゃない人には今更じゃないよっていうのがこのセカイですので、もう気にしてません。サンタさん、僕はオトナになったよ…。 レポジトリの構成（
概要設計工程でRedmine導入してみた事例 - T/O
やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの？ チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが
XPまつり2009、雑感 - @katzchang.contexts
自分の強みを知る上で、情報発信は重要 自分の強みは周りの世界と自分との関係から規定される。 周りの世界と自分との関係を知るには、とにかくコミュニケーション。 自分から情報発信してみて反応を観察し、伸ばしたり直したり。 TDDデスヨ。 同時に弱みも見せ付けられるので、疲れないペースで程々に。 などと考えると、細かく発信＆観察できる方が、何かといいのかもとか思ったり。 ということで、ついったーしようぜという結論になりました。何でもいいから、とにかく、思うことをぶちまけましょう。 本もらた。 Anneke Kleppeの"Software Language Engineering" http://www.amazon.co.jp/Software-Language-Engineering-Domain-Specific-Metamodels/dp/0321553454 「メタモデルを用いたDSL
肩こり対策。 - @katzchang.contexts
自分用メモ。 １．まずは、手首のぶらぶら体操１分間・ （気をつけることは力を抜くこと） ２．腕を横にぶらぶら振りましょう。振り子のように。 （これも力を抜いてね。） ３．ラジオ体操を軽くやって見よう。 ４．さあ、ウオーミングアップはこのくらいにして、５００グラムの鉄アレーで筋力トレだ。 軽いから２０回〜３０回は出来るかな？ （気をつけることは、疲れるまでやっては駄目。） 何通りかのやり方があるから、均等に筋肉を鍛えよう。 ５．さて、最後はストレッチだよ。 鍛えた筋肉を軽〜く伸ばして見よう。１５秒〜１分間 基本的に、固まってる筋肉を伸ばしてあげれば肩こりは無くなる。 でもいきなりは筋肉に無理な付加がかかるから、よく伸びないし、 逆効果になる可能性がある。ゆえに、まずは動かしてウオーミングアップ ストレッチがクールダウンだね。 http://alfalfa.livedoor.biz/archi
おされビンゴアプリ作成その1 - @katzchang.contexts
相変わらず自分用のメモです。9/12のFxUG@北陸の発表ネタ仕込み中！ というか、事前なのにネタばらしです。 書いてある以上はやらないよ（出来ないよ、とは言わないのがズルい大人のやり口）。 進め方 アジャイル風な感じで。本とか読む限り、多分こんな感じという程度。 プロダクトオーナ：俺 デザイナ：俺 開発者：俺 オンサイト顧客：俺 想定ユーザ：勉強会参加者。部屋に集った30名から50名程度…かな。 フィーチャ 抽選できること ボタンを押したら抽選した数字を画面に出す感じ 既に出た数字を画面に表示 ビンゴ申告に対するチェック機能 楽しさ もったいぶった演出 数字を出すまでにはシャッフル かっこいいデザイン 画像で表示 音とかなるといいよね リーチ申告した人が画面上に表示されるとか 申告者の数で緊張感のある演出に移行とか 普通に感想（「あった」とか「うへぇ」とか）を書けるとか プロジェクト構成
開発プロセス勉強会の話。 - @katzchang.contexts
「「開発プロセス勉強会」とか、興味ある方います？ - @katzchang.contexts」の件の続き。というかもう少し具体案。 テキスト選定と開催ペース・時間帯について、特に意見が聞きたいです。 開発プロセスを中心とした勉強会。 大目的は、この先生きのこるため。言いかえれば、システム開発を仕事として継続していくため。お金を稼ぐため。 対象はシステム開発関係者。システム屋の開発者とマネージャや営業さん、企業のシステム担当など。 持論は「[http://d.hatena.ne.jp/katzchang/20080527/p2」。開発プロセスは設計と契約に関係するため、開発プロセスを語るには設計と契約に踏み込むだろうと予想。ただ、この図のDesign - Contractは直接結合していないと考えた方がシンプルというか、直接結合しない方向で開発プロセスを作るべきというか。 ともかく、とりあえ
業務システム開発は管理稼動が7割くらいじゃね？ - @katzchang.contexts
感覚的に。 3割程度に抑えるのが理想だと思うけど、多すぎる不確定要素の中でどうにか決定していかなきゃならんっていう現実に直面すると、発注マネージャ側としては判断要素を出来るだけ集めたくなってマイクロマネジメントに走ってしまいたくなるのもわかるし（無意味だけどね！）、受注側としても根本的な問題は多すぎる不確定要素なわけだけどそんなのどうしようもないから「発注者の意向に沿いましょう。」と逃げてしまうのもわかるし（無意味だけどね！）、結果、全てのメンバがマネジメントに引きずられる形になっちゃった（引っ張ってほしいのにね！）というのが現状。 それこそ、「不確定要素を管理しましょう」なんて言いそうな勢い。自分の権限で管理できるなら、それ不確定要素じゃないしｗｗｗｗ この先もしばらくは続きそう。
リリース==稼動開始という呪縛 - @katzchang.contexts
アジャイル開発でのリリース、特に一回目のリリースは使い心地が悪いだろうし、機能的な漏れがあったりして、運用に耐えられないかもしれない。が、小さいサイクルでリリースを繰り返すことにより、運用に耐えられるレベルに達することを期待される。どの時点で実際に運用に使うかは、あくまでも顧客側の判断にゆだねられる。（…ですよね？アジャイル屋じゃないから多分に想像です。） 一方、日本のSI業界は「本稼動」を保証する契約なのが普通で、しかも、どこかの時点で稼動開始時期と金額を決めたりする。で、その条件のもとで確実に運用に耐えられるものを作らなければならない。こんな状況だと、ベンダ側にとって、全てを差し置いて最優先されるのが「確実性」となるわけです。 そう、システム開発で全てを差し置いて最優先なのが「確実性」となるわけです。 「機能性」「保守性」「使い心地」「品質」「開発効率性」、これら全てを差し置いて最優先
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルに期待すること。 - @katzchang.contexts