Continuous Integration -001-

「 継続的インテグレーション」の翻訳版が2009年(USでは2007年)に発刊され、昨年は「継続的デリバリー」も発刊された。クライアントの中でも、本で記述された内容まではいかないが、ビルド、デプロイの自動化をスクラッチで実装する事例がでてきた。
今年の目標はRQM + RTCの連携検証にJenkinsを絡めて、トータルな継続的デリバリーの基盤を構築したい。とかく、開発者としての興味がある範囲なので、面白いということが先行するが、目指すところは、ムダの排除だと思っている。ビルドミス、リグレッションテストミス、デプロイミスといったビジネスと関係ないところのミスを最大限低減することである。

FAH-GL Tuning Memo

・　初期化パラメータの調整
・　統計情報の最適化（特に初期実行時）
・　「会計の作成」のパラレル化(CPUスレッド数を意識）、アドオン・コンカレントマネージャの作成。
・  「会計のプログラム」のプロセッサ数、一回あたりの処理単位の調整（自環境でのベンチマーク実施は必須）
・　バッチ処理実施時における「XLA_EVENTS」の未処理データの扱い。標準プログラムのSQLが未処理データを常に参照する為、本当に必要な範囲で「XLA_EVENTS」に取り込む。取り込み時はバルクAPIを使えるならば、使ったほうがよい。
・　各コンカレントマネージャのポーリング時間の調整。
・　アドオンの取込の際にFAHのテーブルを見てチェックロジックを入れる場合は、アプリケーションIDとイベント区分を必ず入れること。FAHのテーブルは、その2つでパーティション化されている為。

Clean Coder (Chapter6. Practice)

この本に限ってではないけど、西洋の人達は、「型」とか「乱取り」とか、「サムライ」とか「禅」というコトバが、いつでも好きだな。際限の無い目的思考から離れ、その日常の生活の中での繰り返し（ミニマム）を大事にする。逆に目的をきちんと考えずに説明資料を作成したり、行動を実施する日本人は、西洋人のプレゼン・スタイル、説明スタイルを見習っているのに。。

日本人の自分としては、「Practice」というコトバが好きだ。際限の無い「Practice」を継続的に続けることが、プロフェッショナルとしての1つのルールだと思う。

Clean Coder (Chapter5. TDD)

Clean CoderのTDDの3原則はくどく感じたので、自分なりの解釈を記述してみる。

• ソースコードを記述する前に失敗する単体テストケースを記述すること。ソースコｰﾄﾞが完成する直前には、自動化されたテストケースが完成している。(Coverage 90%以上）
• 単体テストケースを記述することは、モジュールの疎結合を目指すことになる。（テストが実施できるソースを開発するようになる為）
• ソースコード完成時に、数分以内に完了するリグレッション・テストが用意可能になる。（変更に対する恐れがなくなる。自動化された単体、受入テストケースが無い場合、結局は大丈夫だと思って実施しないテストケースがでてくるが、その内容が自動化されたテストケースに含まれることになり、より堅牢になる）