標準化に必要なのはフレームワークよりも(美女)エバンジェリストだ - レベルエンター山本大のブログ
でかいプロジェクトで開発標準を定着させるには、フレームワークやドキュメントよりも「標準化伝道師(エバンジェリスト)」を常設するほうが効果があると思う。 開発標準は、その組織の文化だといえる。文章やソースコードで文化を根付かせようとしても上手くいかない。 組織の文化とは人が言葉と行動によって伝承するものなのだ。 希望を言えば伝道師はできれば女性がいいなぁ。 エンジニアは男性が多いからやたらテンションが上がるし、女性の活躍の場も増えるので誰も損をしない。 伝道師は、新規プロジェクト立ち上げ時やフェーズの切り替わり時期に、次フェーズについての標準的手法・技法を全メンバーに伝授する役割を担う。 また、標準についての情報を管理し、プロジェクトごとの開発標準のカスタマイズに関わる。 プロジェクトでの標準化が上手く力を発揮すると品質・効率・保守性などの面で良い効果が期待できるから取り組み事態は素晴らしい
データベースのアジャイル開発を実現する8のプラクティス - レベルエンター山本大のブログ
アジャイルな開発に欠かせない割りに、あまり言及されていなかったのが データベースのアジャイル開発です。 今、私の参画しているプロジェクトで、データベースに関するアジャイルな開発の方法を模索していました。 現在実践していて効果のあるプラクティスをまとめます。 1.データベース作成ツールのVSS管理 「スキーマ定義クエリ」と、移行に必要な「初期データCSV」および「移行クエリ」、「移行プログラム」は、管理ツール（VSS）にチェックインされていて、だれでも修正が可能です。 スキーマ定義クエリだけでなく、「移行データ」についてもVSSで管理しているのがポイントです。 マスタなどのデータは、業務の設計に応じて変わるものですし、移行プログラムも実装チームやテストチームが柔軟に修正できたほうが便利です。 データは、単体テスト用データとしても利用できます。 2.データベースのデイリービルド データベースの
自動テストとデイリービルドの組み合わせは最強！ - レベルエンター山本大のブログ
自動テストとデイリービルドを組み合わせることの超絶な威力を感じてる。 しかし、開発の中に上手く自動テストを組み込めていないプロジェクトは多い。 デイリーでテストコードを流しておくと、修正による副作用を最低でも1日以内に発見することができるようになる。 影響を恐れずに修正ができるため、大胆なリファクタリングも可能だし、仕様変更にとても強くなる。 結合テスト以降は、特に強力で自分の作っていないプログラムでの修正や操作が自分のプログラムに影響を与えることがある。 それを知らせてくれる仕組みがあるということが安心感は絶大だ。 そもそもテストコードを作ると、コーディング時やデバッグ時に起動ポイントとして使える。 Web画面を起動しなくていいぶん楽にコーディング・デバッグできる。 「じゃあ、Web画面からの入力テストはどうするんだ？」とか 私も昔は思っていたけど、画面入力のテストなんかは無理に自動化し
Java with CGLIB でC#ライクなDelegateを使う。 - レベルエンター山本大のブログ
Javaの言語仕様には、C#で言うDelegateは無いが、 CGLIBでDelegateの仕組みが提供されている。 C#にインスパイアされて作ったって書いてた。 Delegateというのは、（御幣を承知で言えば） メソッドへのポインタをオブジェクトインスタンスから切り離して 参照型変数に保持して利用するというもの。 継承なしでテンプレートメソッドが利用できるので、制御の反転がより柔軟にできる。 C#ではイベント処理に使われる。 やってみよう ■CGLIBのサイト http://cglib.sourceforge.net/ とりあえず、CGLIBをダウンロードする。 ASMという別のライブラリに依存しているが、 cglib-nodep-X.X_X.jarを使えばこれ一つで動く。 僕はBetaは使わず以下のものを使った。 cglib-nodep-2.1_3.jar まずは、Delegateを
Wicketで理解する プレゼンテーション層フレームワーク革命 - レベルエンター山本大のブログ
※ ＠ITさんでボツになった記事です。。。 Javaを使った国内の企業システム開発では、Webプレゼンテーション層のアーキテクチャとして最もよく使われているのは、いまだにStrutsだそうです。しかし、Sturtsはもはや時代に合わないフレームワークだと感じているエンジニアも多いのではないでしょうか。かといって、JSFやStrutsの後継フレームワークが標準を勝ち取っていくことには「複雑さ」や「完成度の未熟さ」などの理由から疑問の声も聞かれます。とはいえフレームワークに利便性があることも事実なので、誰もJSP・Servletだけの時代に戻ることは望んではいません。そういったことから、筆者も新しい時代のWebプレゼンテーション層フレームワークを待ち望んでいました。 今回紹介するWicketが、JavaEE開発のWebプレゼンテーション層に革命を巻き起こすことを期待しています。 1. Wick
Shift_JIS→UTF-8の変換で問題になることがら - レベルエンター山本大のブログ
現場で、Shift_jis→UTF-8の変換時の懸案事項を調査していた。 以下の「Unicode標準入門」という本がとても良い！！ Web時代のエンジニアは必携と言っていい。 Unicode標準入門 作者: トニーグラハム,関口正裕,Tony Graham,乾和志,海老塚徹出版社/メーカー: 翔泳社発売日: 2001/05/30メディア: 大型本購入: 3人 クリック: 109回この商品を含むブログ (18件) を見る UNICODEについて調べて見ると知らないことばかり。 ・CJK統合漢字（またはCJKV統合漢字） 中国、日本、韓国の複数の漢字の規格を統合して作ったUnicodeの漢字ブロック群 130,000以上の漢字を27,786の文字コードに統合している ・ユニフィケーション 同じ意味・文字で字形の違う文字に1つのコードを割り当てること CJK統合漢字のブロックだけを考えても、 1
■ - レベルエンター山本大のブログ
現在、プロジェクトの基本設計フェイズに入っていますが、 後続で入ったので要件の全体像把握に手間取りました。 そういったことから基本設計フェイズでは、 「要求リスト」を活用するのが良いと感じています。 要求リストは以下のような項目として作ります。 No 分類 要件 優先度 難易度 備考 ※分類項目には、「機能要件」 Or 「UI操作性要件」を記入する。 現場で活用する場合、基本設計書の第1章として要求リストを記載しておいて 常にヒアリングセッションの傍らに置いて話を進めるという使い方をします。 このリストのメリットは ・要件に対する関係者の合意がとれ、常に認識が一致する。 ・仕様の漏れを減少することができる。 ・後続参加メンバーや、同プロジェクトの別チームへの 設計意図の伝達に利用できる。 ・見積に利用できる。 などなどです。 メリットの中でも「仕様漏れの減少」は有意義です。 仕様漏れが発生
テストケースファースト - レベルエンター山本大のブログ
テストコードを先に書くことは、一部のエンジニアにとって可能でも、 プロジェクトチーム全体で徹底させることは難しい。 テストコードは、本質的なアプリケーションのプログラミングに比べて難易度が低いわけではない上、とても煩雑だ。 また、プロジェクトチームの実装者のレベルによっては、テストコードのレベルもまちまちになる。 適切な「テスト設計」を行った上で作成するテストコードでなければ すぐさま意味を成さないテストコードとなる。またテストケースの網羅率もばらばらとなるだろう。 テストコードの再利用性は、設計されてこそ得られると考えてる。 確かにテストコードを書いていれば、メリットは得られる。 ・リファクタリングというプロセスの採用 ・再帰テストの効率化 ここまでしてテストコードを書く必要性のある部分もある、例えばフレームワークコードが代表的だ。 しかし、業務アプリケーションの業務ロジックで、 そこま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
