header image

Ryuzeeについて

mixi Twitter Twitter

携帯対応

QRコード

RING

人気ブログランキング

新着記事

2010/09/03 05:48:35 日記 none Comments

僕がやっている案件(PHP)はもともとテストコードのないレガシーなプロジェクトで、それを改善するためにずっと動作を確認するための結合レベルの自動テストを増やしてきた。
そんな中で僕のところではどうやってテスト用のfixtureを管理しているか事例として紹介したいと思う。

最初にコアとなるfixtureを用意する

みんなが沢山テストを作る前にコアとなるテスト用のfixtureは用意しておく。
さもないと、みんなが好き勝手にfixtureを作ってしまい、あっという間に混乱に陥る。
プログラム本体と同様に、DRYの原則で、同じようなテストデータを繰り返し作ってしまうようなことは避けるべきだ。
最悪なパターンは開発機や本番機のデータを引っこ抜いてきて、それをそのままテストデータとしてごっそり使う方法。流石に居ないと思いたいが、こういうことをやってしまうとテストデータの見通しが悪すぎて、テストが失敗した場合の検証が非効率だし、そもそもデータのロードに時間がかかりすぎる。

共通のfixtureとテストケースごとのfixtureを分離する

マスター系のテーブルとか、ユーザー情報のテーブルのためのfixtureはテストケースごとにバラバラに用意してはいけない。似たようなfixtureがあちこちに造られると、テストの数が増えてからの仕様変更の際にテストデータのメンテナンスだけでえらく時間が取られてしまう。
僕の場合は、共通fixture置き場に基本的なfixtureをテーブルごとに配置した上で、テストケースごとのfixtureを上書きでロードしている。
以下はPHPの場合だけど、基底クラスで、以下のようにCSVの取り込みロジックを作っておいて

protected function getDataSet()
{
    echo __FUNCTION__ . "\n";
    $dataSet = new PHPUnit_Extensions_Database_DataSet_CsvDataSet();

    if(is_array($this->fixture_path)) {
        foreach($this->fixture_path as $path) {
            echo "----" . $path . "\n";
            if ($dir = opendir($path)) {
                while (($file = readdir($dir)) !== false) {
                    if ($file != "." && $file != ".." && substr($file, -4) == ".csv") {
                        $table_name = str_replace(".csv", "", basename($file));
                        echo "===loading $file...";
                        @$dataSet->addTable($table_name, $path . "/" . $file);
                        echo " done!\n";
                    }
                }
                closedir($dir);
            }
        }
    }
    return $dataSet;
}

テストケースのコンストラクタあたりで

public function HogeTest()
{
    $this->fixture_path = array(dirname(__FILE__) . '/../fixture/',
        dirname(__FILE__) . '/./fixture/'
    );
}

なんてやって、fixtureを複数階層に分けてロードしている。
fixtureをYAMLやXMLで持ってても同じことができるんじゃないかな。

fixtureの内容をチェックするためのツールを作る

僕はPHPUnit+Seleniumで結合試験を自動化していて、fixtureはテーブルごとにCSVファイルを用意している。これらのCSVをsetUp()で読み込むようにしているんだが、fixtureのカラム数があっていないと、すぐテストが落ちてしまう。(XMLでfixtureを保持していると楽かもしれないんだけど)
開発中は、当然カラムの追加や削除はあるが、その度にどのfixtureを修正しなければならないかを考えるのは面倒で仕方ない。
なので僕は、全fixtureをDBのスキーマと照合するツールを作っている。これがあればスキーマの変更の怖さはちょっと軽減される。

fixtureを自動生成するようなツールを作る

手で整合性の取れたfixtureを作るのはなかなか大変なので、Excelでfixtureをつくるようにしている。
予め用意しておいたシートに値を入れてマクロを動作させると、fixtureが自動で生成されるかんじ。
こういうツールもプロジェクトの早い段階で用意できていると効率的だろう。

日付や時刻等で、テストの成功・失敗条件に関わるテストデータはfixtureとは切り離す

例えば最終ログインから60日たっていたらAをして、120日たっていたらBをする、というテストケースの場合、fixtureに最終ログイン日時をハードコーディングできない。ハードコーディングしてしまうと、そのテストは実行日によってテスト結果が変わってしまうテストであり、自動テストの条件を満たさない。
このような場合は、fixtureにて識別可能な適当な値を設定しておいて、別途テストの初期化メソッドで値を書き換えるような対応をする。

まぁまだまだ改善の余地はあるなぁと思うけど、大分楽になってきたのは確か。
とはいえあくまで外側の挙動が担保できるようになっただけなので、内部的なリファクタリングと、メソッドレベルのテストはこれから増やしていかないといけない。

紺屋の白袴ということで、試行錯誤中ではあるのだが、自戒を込めてまとめておく。

テスト自動化/テスト駆動開発について

  • XPのプラクティスの中で、最も単体で導入しやすいプラクティスの1つである。
  • このプラクティスのみで1冊の本が書けるくらい奥が深い
  • 基本的な方法
    • 失敗するテストを書く
    • できる限り早く、テストがパスするような最小限のコード本体を書く
    • リファクタリングをする
  • 適用範囲
    • 通常では、独立性の高いクラスやファンクションへの適用が良い。
    • GUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい。
    • 既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。従って新規プロジェクトの初期から導入することが望ましい。
  • 問題点
    • 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識するテストコードに適合していることのみが保証される。

自動化されたテストが満たすべき性質

テストは以下の条件を満たしている必要がある。

  • 簡単実行
    • テストの準備に大量の時間や人手がかかるようにしない
  • 自己検証
    • テストが成功したか、失敗したかはプログラムが判断する。(人手で判断しない)
  • 繰り返し可能
    • 何回でも繰り返し実行できること。また実行ごとに結果が変わらないこと
  • 独立性
    • 環境や外部のコンポーネントに依存しないこと
    • テストケースの実行順序に依存しないこと

自動テストをどこまで作るべきか?

  • テストの自動化にはコストがかかるため、自動テストによるカバレージを100%にすることを目標としてはいけない
  • バグが無いソフトウェアは本当に良いソフトウェアなの?
    • 顧客のビジネス価値の実現に寄与できるのが良いソフトウェア
  • XPでは、「問題の発生しそうなところはすべてテストせよ」と言っているが、全てをテストせよ、とは言っていない。
  • カバレージ100%への最後の数%はいばらの道。残り数%のテストに、いままで作ったテストと同じだけの労力を必要とすることになる。
  • 常に品質最優先ではなく、コスト・スケジュールと照らし合わせた割り切りも必要。

テスト自動化のレガシープロジェクトへの導入

  • レガシープロジェクトとは?
    • 自動化されたテストが備わっていないプロジェクトのこと。
    • 利用している言語やフレームワークには関係ない。
  • レガシープロジェクトの問題点
    • 機能追加や改修の際に、現行機能に問題がないことを保証するためには、人力による再テストを実施するしかない。
    • 従って機能追加・改修が度重なるたびに、テストのスコープが膨れ上がり、開発コストの増大につながる。
    • 通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状態になっていないため、テストしにくく、結合度の高さ故、変更を加えにくく、予期しない箇所に影響が出やすい。
  • どうやって導入するか?
    • 結合テストレベルのテストを先に用意し、想定されるアプリケーション全体の動作をチェックできるようにする。
    • これによって内部的なロジックを変更した場合でも、アプリケーション機能が壊れていないことは担保できる。その状態で、現行モジュールの修正に際しては、可能な範囲で、ユニットテストが可能になるように作り替えていく。(詳細はレガシーコード改善ガイドを参照のこと)
    • テストモジュールについてはSelenium等を利用すると良い。
    • 新規開発のテストにおいて、SeleniumでHTTPリクエストをトレースする形でテストを作成するのは難しい(UIの変更が頻繁に起こる可能性がありテストのメンテナンスコストが高い)が、一方でUIが既に存在するアプリケーションのSeleniumでのテストは書きやすい。

レガシーコード改善ガイド (Object Oriented SELECTION)

著者/訳者:マイケル・C・フェザーズ

出版社:翔泳社( 2009-07-14 )

定価:¥ 4,410

Amazon価格:¥ 4,410

大型本 ( 472 ページ )

ISBN-10 : 4798116831

ISBN-13 : 9784798116839


ということでレガシーコードと格闘中orz

2010/08/28 03:55:14 Linux none Comments

超FAQだけど個人用メモ。

仮想OSのディスクサイズ拡張

vmware-vdiskmanager" -x 10GB hoge.vmdk

  • 作業自体は数分で終わる
  • インスタンスは停止して実行する。もし停止していても仮想OSのディレクトリに.lckファイルが残っていると作業に失敗するので、その場合は手動で削除

拡張したディスク領域を認識させる

GPartedのLive CDを使って仮想マシンを起動し、パーティション情報を修正する。
なお、GPartedはLVMには対応していないので、CentOSのように標準でLVMを使用するOSの場合は、別パーティションを作成し、そのパーティションをLVMに追加することになる。

以下GPartedの操作メモ。

GPartedのLiveCDで起動する。

キーマップの選択。何もせずOK。

キーボード配列の設定。Japaneseを選択。

表示言語は15の日本語を選択。

GUIで設定するほうが楽なので、0を入力し、Xを起動

標準でGPartedが起動される。!マークはLVMで編集できないことをさす。ここで拡張したディスクが未割り当てとして表示されているはずだ。

未割り当てのパーティションを選択して、Newをクリック。CentOSであれば通常ext3でOK。

まだ設定は反映されていないので、ツールバーのApplyボタンを押す。警告が出るので内容確認してダイアログ内のApplyボタンをクリック

反映完了。

結果として、先ほど未割り当てだった領域がsda3として新設されたことがわかる。

以上が終わったら、CDROMを取り出して、OS再起動。

LVMへの新たなパーティションの追加手順

新たに追加したパーティションはsda3なので、これをLVMに追加する。

追加したディスクパーティションをPV(物理ボリューム)として定義する

/usr/sbin/pvcreate /dev/sda3

追加したPVをVolGroup00という名前のVolume Groupに追加する

/usr/sbin/vgextend VolGroup00 /dev/sda3

論理ボリュームにディスク容量を追加する。

/usr/sbin/lvextend -L +2Gb /dev/VolGroup00/LogVol00

ファイルシステムサイズを再認識させてディスク容量の追加を反映させる。

/sbin/resize2fs /dev/VolGroup00/LogVol00

以上で完了。再起動も不要っぽい。

2010/08/27 20:10:34 日記 none Comments

自動テスト環境をWindowsからLinux環境にしたとたんに、テストが通らないものが頻発して、初めて開発者がhtmlの中に機種依存文字である波ダッシュを埋め込んでくれていたのに気づいた。。orz

以下Wikipediaから引用。

Unicodeの仕様書では、U+301C WAVE DASH(波ダッシュ)に、「JIS punctuation」(The Unicode Standard、Version 2.0より引用、「JIS約物」の意)という注釈を施しておきながら、JIS X 0208の波ダッシュの例示字形(“上がって下がる” 形「」)とは異なる形(“下がって上がる”形「」)を印刷してしまった。
このような間違いが発生した理由は、Unicodeの例示字形を検討するグループにいたメンバーの日本語に対する知識が不十分だったために、縦書きの例示字形「」を90度回転すればいいと誤って判断してしまったためである[4]。
この影響を受けて、Microsoft Windows(XP以前)ではUnicodeの波ダッシュ (U+301C, WAVE DASH) は“下がって上がる”形「」で表示される(MS 明朝、MS ゴシック、MS UI Gothicにおけるもの)。それに対し、Unicodeの全角チルダ (U+FF5E, FULLWIDTH TILDE) は“上がって下がる” 形「」で表示されるようになっており、Shift_JISの波ダッシュ (0x8160、WAVE DASH)「」と同一の文字として扱われる。
このようにWindowsは、Shift_JISの波ダッシュ (0x8160、WAVE DASH)「」を、本来割り当てるべきUnicodeの波ダッシュ (U+301C, WAVE DASH) ではなく、Unicodeの全角チルダ (U+FF5E, FULLWIDTH TILDE)「」に割り当てている。一方、Mac OSやMac OS XではShift_JISの波ダッシュ (0x8160、WAVE DASH)「」を本来のUnicodeの波ダッシュ (U+301C, WAVE DASH) に割り当てており、その字形も一般的な波ダッシュの形である“上がって下がる”形「」で表示される(Osakaフォントやヒラギノフォントにおけるもの)。このWindows独自のUnicode割り当てが産んだ非互換性により、波ダッシュ (U+301C, WAVE DASH) が環境によっては文字化けを起こす機種依存文字となってしまっている。

JAVAだけの話かと思ってたが、そうじゃなかったんだな〜。

よくある質問に適当に答えるコーナー第二回?。
前提は、アジャイル開発を採用しているシステム開発の場合で、ウォーターフォールでの開発や、その他の業界なんかはまったく想定していないし、ターゲットにしていない。

質問:自分のタスクが終わったら、周りを気にせず帰ってしまう人がいて困っています。

質問:メンバーが指示がないと作業が進められないと言って、待ちになってしまい、生産性があがりません。

回答

1)自分のタスクが終われば帰ってしまう人は、どんな価値を実現しているのだろうか?

顧客の価値を実現するために行動していないよね?
こうなってしまうひとつの理由として、その担当者からお客様が見えていな い、ビジネスの価値が分かっていない、という点があげられると思う。従って、とにかくお客様のところに連れて行き、お客様が何を考えているか理解させるようにすべき。
エンジニアはモノを作るのが仕事なんじゃなくて、価値を実現するのが仕事。

そもそも自分のタスクってなんだっけ?というのもある。Scrumであれば、タスクは自分でサインアップすることになるので、チームがコミットしたゴールに向けて、残っているタスクを自分でサインアップしてこなしていかなければならない。
スクラムマスターがタスクの割り当てをしてしまうから、自分のタスクが終わったら帰ってしまうメンバーが出てきたりするのではなかろうか?
なお、付き合い残業しろ、とかいうつもりはサラサラ無い。そんなの糞だ。
あくまで、チームとして(PMが勝手にではなく)コミットしたものがあるのにも関わらず、そのチームのコミットに対して責任を持たない人をスコープにした話である。

2)チーム内のコミュニケーションを活性化させる。

帰ってしまう人がいるチームは、往々にしてチームのコミュニケーションがうまくいっていない。
個人としてではなく、チームとして成果を出すんだ!という前提のもとに全員の問題をいつでも気軽に話せるようにしなければならない。話にくい雰囲気が出来ると、隠ぺい、先延ばしが発生してリスクになる。

3)勤務評価の軸を「顧客からの満足度・信頼度」やチームメンバーからの「信頼度」においてみると良いかも。

※評価を行える人にならないと無理な方法だけど、オープンな評価軸は組織の透明性を強化し、組織力の向上につながる。

4)待ちになってしまう人への対処は、ペアプログラミングやペアレビューによる地道な教育も効果的。

待ちになってしまう人は、技術力がない、とかチームのやり方が分からない、等といった理由で待ちをしてしまうことも多い。
技術を身につけ、チームのやり方に慣れるためには、その人をひとりにせず、ペアで活動すると良い。徐々に慣れてくるだろう。
日本のほとんどの企業はOJTでは数年上の先輩1人にくっつく形だが、アジャイルなOJTでは、チーム全体で人を育成することになる。
チーム全体がメンバーの能力を向上させる責任を負っている、と考えるべきだ。

5)何をやってもダメなら。

残念ながらそういう人がいるかもしれない。チームにずっとそういう人がいるとチームの士気が低下して周りにも影響を及ぼすようになる。上長と相談してメンバーを入れ替える、といった対忚が必要になる場合もある。

いままでアジャイルコーチ稼業をしてきて、よく聞かれた質問があるんだけど、それへの答えを定期的に掲載していってみようかと思う。もし質問があったらコメントでもTwitterでも何でも良いのでいただければ、速攻でブログに私見を書いていきます。

【質問】似非アジャイルって何ですか?

回答

例として以下のようなものがあげられると思う。他にもあるだろうけど代表的なところでは

  • アジャイルの4つの価値(ツールより人と人とのコミュニケーション、包括的なドキュメントより動作するソフトウェア、契約よりも顧客との協働、計画の遵守よりも変化への対応、をそれぞれ重視する)に反している
  • 開発すべきもの、期間が決まっている。
  • 顧客への確認にきっちりした資料が必要になる。
  • スクラムマスターがPMのように振る舞い、チームメンバーに全指示を出している。それによってチームが自律的に機能しない
  • チームが顧客の価値の実現のために働いていない
  • プラクティスのつまみ食い
  • プラクティスへの形式的な準拠に終始し、改善のプロセスが働いていない
  • コミュニケーションに形式が要求される。コミュニケーションが電子媒体に偏重して行われる
  • 問題が起こったときに個人が攻撃される

Top 100 Agile Booksというテーマで、Jurgen氏が書かれていたので、どのくらいの本が日本で翻訳されてるんだっけ?という興味もあり、日本語化されているものはその旨追記してみた。

なお、Jurgen氏によれば、Amazonで、「この本を買っている人は合わせてこれも買っています」みたいな情報によって本の一覧を抽出し、ランキングについては、AmazonとGoodReadsというサイトのデータを参考にして重みづけして集計したとのこと。

本が売れないから邦訳が出るのを時間をかけてまっても仕方ないという気もするので、この本翻訳まだー?みたいな人は英語で読んでしまうと良いのではないかと思う。

  1. Agile Estimating and Planning

  2. Clean Code: A Handbook of Agile Software Craftsmanship

    • Robert C. Martin
    • 2008
    • Clean Code
    • Clean Code アジャイルソフトウェア達人の技

      著者/訳者:Robert C. Martin

      出版社:アスキー・メディアワークス( 2009-05-28 )

      定価:¥ 5,040

      Amazon価格:¥ 5,040

      大型本 ( 528 ページ )

      ISBN-10 : 4048676881

      ISBN-13 : 9784048676885


  3. Working Effectively with Legacy Code

    • Michael Feathers
    • 2004
    • レガシーコード改善ガイド
    • レガシーコード改善ガイド (Object Oriented SELECTION)

      著者/訳者:マイケル・C・フェザーズ

      出版社:翔泳社( 2009-07-14 )

      定価:¥ 4,410

      Amazon価格:¥ 4,410

      大型本 ( 472 ページ )

      ISBN-10 : 4798116831

      ISBN-13 : 9784798116839


  4. Refactoring: Improving the Design of Existing Code

  5. The Art of Unit Testing: With Examples in .Net

    • Roy Osherove
    • 2009
  6. Agile Software Development, Principles, Patterns, and Practices

  7. The Pragmatic Programmer: From Journeyman to Master

    • Andrew Hunt, David Thomas
    • 1999
    • 達人プログラマー―システム開発の職人から名匠への道
    • 達人プログラマー―システム開発の職人から名匠への道

      著者/訳者:アンドリュー ハント デビッド トーマス

      出版社:ピアソンエデュケーション( 2000-11 )

      定価:¥ 3,990

      Amazon価格:¥ 3,990

      単行本 ( 333 ページ )

      ISBN-10 : 4894712741

      ISBN-13 : 9784894712744


  8. Kanban: Successful Evolutionary Change for Your Technology Business

    • David J. Anderson
    • 2010
  9. Succeeding with Agile: Software Development Using Scrum

    • Mike Cohn
    • 2009
  10. Growing Object-Oriented Software, Guided by Tests

    • Steve Freeman, Nat Pryce
    • 2009
  11. User Stories Applied: For Agile Software Development

    • Mike Cohn
    • 2004
  12. Lean Software Development: An Agile Toolkit

    • Mary Poppendieck, Tom Poppendieck
    • 2003
    • リーンソフトウエア開発~アジャイル開発を実践する22の方法
    • リーンソフトウエア開発~アジャイル開発を実践する22の方法~

      著者/訳者:メアリー・ポッペンディーク トム・ポッペンディーク

      出版社:日経BP社( 2004-07-23 )

      定価:¥ 2,520

      単行本 ( 307 ページ )

      ISBN-10 : 4822281930

      ISBN-13 : 9784822281939


  13. Domain-Driven Design: Tackling Complexity in the Heart of Software

    • Eric Evans
    • 2003
  14. The Art of Agile Development

  15. Making Things Happen: Mastering Project Management

  16. Agile Principles, Patterns, and Practices in C#

    • Robert C. Martin, Micah Martin
    • 2006
  17. Agile Testing: A Practical Guide for Testers and Agile Teams

  18. Practices of an Agile Developer: Working in the Real World

    • Venkat Subramaniam, Andy Hunt
    • 2005
    • アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
    • アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

      著者/訳者:Venkat Subramaniam Andy Hunt

      出版社:オーム社( 2007-12-22 )

      定価:¥ 2,520

      Amazon価格:¥ 2,520

      単行本(ソフトカバー) ( 220 ページ )

      ISBN-10 : 4274066940

      ISBN-13 : 9784274066948


  19. Behind Closed Doors

    • Johanna Rothman, Esther Derby
    • 2005
  20. Applied Software Project Management

    • Andrew Stellman, Jennifer Greene
    • 2005
  21. Agile Project Management: Creating Innovative Products (1st+2nd Edition)

  22. xUnit Test Patterns: Refactoring Test Code

    • Gerard Meszaros
    • 2007
  23. Scrum and XP from the Trenches

    • Henrik Kniberg
    • 2007
  24. Implementing Lean Software Development: From Concept to Cash

    • Mary Poppendieck, Tom Poppendieck
    • 2006
    • リーン開発の本質 ソフトウエア開発に活かす7つの原則
    • リーン開発の本質 ソフトウエア開発に活かす7つの原則

      著者/訳者:メアリー・ポッペンディーク トム・ポッペンディーク

      出版社:日経BP社( 2008-02-07 )

      定価:¥ 2,520

      Amazon価格:¥ 2,520

      単行本(ソフトカバー) ( 336 ページ )

      ISBN-10 : 482228350X

      ISBN-13 : 9784822283506


  25. Agile and Iterative Development: A Manager’s Guide

  26. Writing Effective Use Cases

    • Alistair Cockburn
    • 2000
    • ユースケース実践ガイド―効果的なユースケースの書き方
    • ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)

      著者/訳者:アリスター コーバーン Alistair Cockburn ウルシステムズ株式会社 山岸 耕二 矢崎 博英 水谷 雅宏 篠原 明子

      出版社:翔泳社( 2001-11 )

      定価:¥ 3,990

      Amazon価格:¥ 3,990

      単行本 ( 330 ページ )

      ISBN-10 : 4798101273

      ISBN-13 : 9784798101279


  27. Refactoring to Patterns

  28. Agile Coaching

    • Rachel Davies, Liz Sedley
    • 2009
  29. Agile Retrospectives: Making Good Teams Great

  30. Agile Adoption Patterns: A Roadmap to Organizational Succes

    • Amr Elssamadisy
    • 2008
  31. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects

    • Johanna Rothman
    • 2009
  32. The Principles of Product Development Flow: Second Generation Lean Product Development

    • Donald G. Reinertsen
    • 2009
  33. Scaling Software Agility: Best Practices for Large Enterprises

  34. Crystal Clear: A Human-Powered Methodology for Small Teams

    • Alistair Cockburn
    • 2004
  35. Requirements by Collaboration

    • Ellen Gottesdiener
    • 2002
  36. Agile Software Development with Scrum

  37. The Productive Programmer

  38. Organizational Patterns of Agile Software Development

    • James O. Coplien, Neil B. Harrison
    • 2004
  39. Agile Project Management with Scrum

    • Ken Schwaber
    • 2004
  40. Extreme Programming Explained: Embrace Change (1st+2nd Edition)

    • Kent Beck, Cynthia Andres
    • 1999
    • XPエクストリーム・プログラミング入門―変化を受け入れる
    • XPエクストリーム・プログラミング入門―変化を受け入れる

      著者/訳者:ケント ベック

      出版社:ピアソンエデュケーション( 2005-12 )

      定価:¥ 2,415

      Amazon価格:¥ 2,415

      単行本 ( 189 ページ )

      ISBN-10 : 4894716852

      ISBN-13 : 9784894716858


  41. Managing the Design Factory

    • Donald G. Reinertsen
    • 1997
  42. Manage It!: Your Guide to Modern, Pragmatic Project Management

  43. Leading Lean Software Development: Results Are not the Point

    • Mary Poppendieck, Tom Poppendieck
    • 2009
  44. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

    • Craig Larman, Bas Vodde
    • 2009
  45. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

    • Craig Larman, Bas Vodde
    • 2008
  46. Agile Software Development: The Cooperative Game (1st+2nd Edition)

    • Alistair Cockburn
    • 2001
    • アジャイルソフトウェア開発
    • アジャイルソフトウェア開発 (The Agile Software Development Series)

      著者/訳者:アリスター・コーバーン Alistair Cockburn

      出版社:ピアソン・エデュケーション( 2002-08-30 )

      定価:¥ 3,360

      Amazon価格:¥ 3,360

      単行本 ( 400 ページ )

      ISBN-10 : 4894715791

      ISBN-13 : 9784894715790


  47. Test Driven Development: By Example

    • Kent Beck
    • 2002
    • テスト駆動開発入門
    • テスト駆動開発入門

      著者/訳者:ケント ベック

      出版社:ピアソンエデュケーション( 2003-09 )

      定価:¥ 3,150

      Amazon価格:¥ 3,150

      単行本 ( 217 ページ )

      ISBN-10 : 4894717115

      ISBN-13 : 9784894717114


  48. Continuous Integration: Improving Software Quality and Reducing Risk

    • Paul M. Duvall, Steve Matyas, Andrew Glover
    • 2007
    • 継続的インテグレーション入門 開発プロセスを自動化する47の作法
    • 継続的インテグレーション入門 開発プロセスを自動化する47の作法

      著者/訳者:ポール・M・デュバル スティーブ・M・マティアス アンドリュー・グローバー

      出版社:日経BP社( 2009-08-06 )

      定価:¥ 3,360

      Amazon価格:¥ 3,360

      単行本(ソフトカバー) ( 304 ページ )

      ISBN-10 : 482228395X

      ISBN-13 : 9784822283957


  49. Collaboration Explained: Facilitation Skills for Software Project Leaders

    • Jean Tabaka
    • 2006
  50. Changing Software Development: Learning to Become Agile

  51. Ship it! A Practical Guide to Successful Software Projects

    • Jared Richardson, William A. Gwaltney
    • 2005
    • Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック
    • Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

      著者/訳者:Jared Richardson William Gwaltney Jr. でびあんぐる

      出版社:オーム社( 2006-08-26 )

      定価:¥ 2,730

      Amazon価格:¥ 2,730

      単行本(ソフトカバー) ( 224 ページ )

      ISBN-10 : 4274066568

      ISBN-13 : 9784274066566


  52. Agility and Discipline Made Easy: Practices from OpenUP and RUP

  53. Refactoring Databases: Evolutionary Database Design

    • Scott W. Ambler, Pramodkumar J. Sadalage
    • 2006
    • データベース・リファクタリング
    • データベース・リファクタリング

      著者/訳者:スコット W アンブラー ピラモド・サダラージ

      出版社:ピアソンエデュケーション( 2008-03-26 )

      定価:¥ 3,780

      Amazon価格:¥ 3,780

      単行本 ( 330 ページ )

      ISBN-10 : 4894715007

      ISBN-13 : 9784894715004


  54. Managing Agile Projects

    • Kevin J. Aguanno
    • 2005
  55. Beyond Software Architecture: Creating and Sustaining Winning Solutions

    • Luke Hohmann
    • 2003
  56. Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders

    • Andrew Stellman, Jennifer Greene
    • 2009
  57. Beautiful Testing: Leading Professionals Reveal How They Improve Software

    • Adam Goucher, Tim Riley
    • 2009
  58. Managing Agile Projects

    • Sanjiv Augustine
    • 2005
  59. Lean-Agile Software Development: Achieving Enterprise Agility

    • Alan Shalloway, Guy Beaver, James R. Trott
    • 2009
  60. Agile Product Management with Scrum: Creating Products that Customers Love

    • Roman Pichler
    • 2010
  61. Implementation Patterns

    • Kent Beck
    • 2006
    • 実装パターン
    • 実装パターン

      著者/訳者:ケント・ベック Kent Beck

      出版社:ピアソンエデュケーション( 2008-12-22 )

      定価:¥ 2,310

      Amazon価格:¥ 2,310

      単行本(ソフトカバー) ( 208 ページ )

      ISBN-10 : 4894712873

      ISBN-13 : 9784894712874


  62. Extreme Programming Installed

    • Ron Jeffries, Ann Anderson, Chet Hendrickson
    • 2000
    • XPエクストリーム・プログラミング導入編 ― XP実践の手引き
    • XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

      著者/訳者:ロン・ジェフリーズ アン・アンダーソン チェット・ヘンドリクソン

      出版社:ピアソン・エデュケーション( 2001-08-10 )

      定価:¥ 2,520

      Amazon価格:¥ 2,520

      単行本(ソフトカバー) ( 348 ページ )

      ISBN-10 : 4894714914

      ISBN-13 : 9784894714915


  63. Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams

    • Greg Cohen
    • 2010
  64. Balancing Agility and Discipline: A Guide for the Perplexed

    • Barry Boehm, Richard Turner
    • 2003
  65. Effective Project Management: Traditional, Agile, Extreme

    • Robert K. Wysocki
    • 2003
  66. Emergent Design: The Evolutionary Nature of Professional Software Development

    • Scott L. Bain
    • 2008
  67. Fearless Change: Patterns for Introducing New Ideas

    • Mary Lynn Manns, Linda Rising
    • 2004
  68. Stand Back and Deliver: Accelerating Business Agility

    • Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent McDonald
    • 2009
  69. A Tale of Two Systems: Lean and Agile Software Development for Business Leaders

    • Michael K. Levine
    • 2009
  70. Just Enough Requirements Management: Where Software Development Meets Marketing

    • Alan Mark Davis
    • 2005
  71. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition

    • Lyssa Adkins
    • 2010
  72. Growing Software: Proven Strategies for Managing Software Engineers

    • Louis Testa
    • 2009
  73. Becoming Agile: …in an Imperfect World

    • Greg Smith, Ahmed Sidky
    • 2008
  74. Agile Game Development with Scrum

    • Clinton Keith
    • 2010
  75. Test Driven: TDD and Acceptance TDD for Java Developers

    • Lasse Koskela
    • 2007
  76. The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation

    • David F. Rico, Hasan H. Sayani, Saya Sone
    • 2009
  77. A Practical Guide to Distributed Scrum

    • Elizabeth Woodward, Steffan Surdek, Matthew Ganis
    • 2010
  78. Principles of Software Development Leadership: Applying Project Management Principles to Agile Software Development

    • Ken Whitaker
    • 2009
  79. Patterns of Agile Practice Adoption

    • Amr Elssamadisy
    • 2007
  80. Innovation Games: Creating Breakthrough Products Through Collaborative Play

    • Luke Hohmann
    • 2006
  81. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results

    • David J. Anderson
    • 2003
    • アジャイルソフトウェアマネジメント
    • アジャイルソフトウェアマネジメント

      著者/訳者:David J. Anderson

      出版社:日刊工業新聞社( 2006-03 )

      定価:¥ 4,410

      Amazon価格:¥ 4,410

      単行本 ( 385 ページ )

      ISBN-10 : 4526056162

      ISBN-13 : 9784526056161


  82. Project Management the Agile Way: Making It Work in the Enterprise

    • John C. Goodpasture
    • 2009
  83. The Software Project Manager’s Bridge to Agility

    • Michele Sliger, Stacia Broderick
    • 2008
  84. Business Agility: Sustainable Prosperity in a Relentlessly Competitive World

    • Michael H. Hugos
    • 2009
  85. The Enterprise Unified Process: Extending the Rational Unified Process

    • Scott W. Ambler, John Nalbone, Michael J. Vizdos
    • 2005
    • エンタープライズ統一プロセス
    • エンタープライズ統一プロセス (Object Oriented SELECTION)

      著者/訳者:John Nalbone Michael J. Vizdos 藤井 拓

      出版社:翔泳社( 2006-07-11 )

      定価:¥ 4,725

      Amazon価格:¥ 4,725

      大型本 ( 400 ページ )

      ISBN-10 : 4798109347

      ISBN-13 : 9784798109343


  86. Kanban and Scrum – Making the Most of Both

    • Henrik Kniberg, Mattias Skarin
    • 2010
  87. Agile Software Development: Best Practices for Large Software Development Projects

    • Thomas Stober, Uwe Hansmann
    • 2009
  88. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

    • Gojko Adzic
    • 2009
  89. Software Endgames: Eliminating Defects, Controlling Change, And The Countdown To On-time Delivery

    • Robert Galen
    • 2004
  90. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process

  91. Agile Software Development Ecosystems

  92. Software by Numbers: Low-Risk, High-Return Development

    • Mark Denne, Jane Cleland-Huang
    • 2003
  93. Scrumban – Essays on Kanban Systems for Lean Software Development

    • Corey Ladas
    • 2008
  94. The Enterprise and Scrum

    • Ken Schwaber
    • 2007
  95. Test-Driven Development: A Practical Guide

    • David Astels
    • 2003
  96. Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed

    • Mario E. Moreira
    • 2009
  97. Testing Extreme Programming

    • Lisa Crispin, Tip House
    • 2002
  98. Patterns for Effective Use Cases

    • Steve Adolph, Paul Bramble
    • 2002
  99. Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development

    • Bruce Powel Douglass
    • 2009
  100. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems

    • Jim Highsmith
    • 1999

Sourceforge.jpで公開しているAgilo日本語版ですが、Trac 0.11.6およびTrac 0.11.7でインストールに失敗する件について対応を行ないました。

入手は以下から。
http://sourceforge.jp/projects/shibuya-trac/wiki/plugins/Agilo_ja

なお、インストール後にプロダクトバックログ画面で、UnicodeDecodeErrorが表示される場合は、http://www.ryuzee.com/contents/blog/941を参照して、sitecustomize.pyを作成してください。

Agiloって何という方は以下のスライドを参照ください。

重厚長大なドキュメントなんて、動かないし嘘書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで著しく否定的なんだけど、とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみる。

なお、個人的には、ドキュメントレビューするよりソースをレビューしろ!、という主張。

とはいえドキュメントレビューで肝心なのは、

  • ドキュメントレビューやるなら、その投資に見合う何を得るのか?を決めておく必要がある。
  • 本当にそのドキュメントは必要か?をよく考える(会社のルールだから!という理由は考えていない答えだ)

だと思う。

1. 体裁をレビューするのではなく、中身をレビューする

ひどい現場だと、文書のインデントやフォントのサイズ、誤字脱字ばかりを重箱の隅をつつくようにチェックしているケースがあるようだが、そうではなく中身をレビューする。(ただしあまりに体裁がひどい場合は、往々にして中身もひどかったりするのだが・・・)
中身が分からないから体裁をレビューする、というのもあるようだが、そのレビューの結果は、どんな利益を生んでいるのかよく考えるべきだ。
なお、レビューワーはレビュー前に資料を確認しておくべきであることは言うまでもない。いきなり初見の資料を見てレビューできる項目はたかがしれている。

2. 標準化ではなく、顧客や案件ごとに最適化できるような自由度をチームに与える

必要なドキュメントは顧客毎、システム毎に異なる。
常に自社の標準に無理やり押し込めようとするのではなく、案件特性や顧客特性を踏また上で、どのようなドキュメントが必要なのかは最初に考えよう。
そしてドキュメントも常時リファクタリングできるように。

3. レビューの目的を明確にする

レビューは実施することに意義があるのではなく、そこで問題となりそうなことを早期に検出し、将来のリスクを軽減することに意味がある。
レビューワーの時間、参加者の時間を投資するわけだから、その投資に見合うリターンを生むようにしなければならない。

4. 大がかりなレビューを少ない回数実施するのではなく、こまめな小規模レビューを繰り返す

アジャイルなレビュー。
大量に作ってしまった問題あるドキュメントを修正するのは簡単なことではない。
リスクを早期に検出しクリアにするためには早期レビューと繰り返しが必須である。
次の工程に入る前にとってつけたようなレビューをして、条件付きで承認をする、といったやり方をするチームもあるようだが非効率で、問題の先送りである。

5. レビューでの指摘事項をすべて対応しなければならないとは限らない。チームにとって労力をかけるだけのメリットがあるものから優先順位付けをして実施する

レビューワーは気づいた点を大小問わずすべて指摘するだろうが、それを全て修正する必要が必ずしもあるわけではない。修正にかけるコストと効果を勘案し、優先順位をつけて対応すれば良い。

6. レビューで人格を非難しない

ついついレビューワーは上から目線で、「こんなことも出来ないのか!」みたいなトーンで指摘してしまいがちである。そういうことをしていると、レビューを受ける側は、レビューを通りさえすれば何でもいいや、と思うか、レビューを受けることすら嫌がるようになる。
レビューをする側も、顧客へ届ける製品の品質の一旦を担っていると考えられるので、同じ土俵の上で純粋に同じゴールに向かってレビューしよう。

7. レビューの順番もレビュー効果が高いものから実施すること

同じフェーズの設計書でも、システム内での機能の重要度には差があるはずだ。全部が重要な機能である、というシステムはいまだかつて見たことはない。限られた時間の中で最大の効果を出すためには、アジャイルで構築するフィーチャーに優先順位をつけるのと同様に、レビューする範囲にも優先順位をつけること。
レビューでは100%のレビューカバレージを取ることが目的なのではなく、問題を早期に検出し、将来にリスクを顕在化させないようにするためのものである。

8. 機械的に検証可能なドキュメントのレビューは自動化すること

体裁にこだわっても仕方ないが、字面しか見ないようなチェックであれば、perlのスクリプトなんかでも十分チェックできる。それこそソースコードをコミットする際に、自動でCode Snifferかけるようなもので良い。

9. レビューワーも技術もしくは顧客の業務をしっていること

技術を知らないとアーキテクチャの妥当性や注意すべきポイントの指摘ができない。
業務を知らないと仕様の妥当性が理解できない。
どっちも知らない人がレビューしても字面チェックしかできないので時間の無駄である。

10. レビュー結果はチーム内外含めて共有すること

レビューの結果の中で有意義なものがあれば、チームの中で最大限活用すれば良い。指摘項目の中で簡単に自動チェックできるようなものがあれば自動化も検討すること。

なお、ソースコードのレビューもほぼ同じことが言えるとは思う。

2010/08/07 06:39:33 日記 none Comments

1. kalturaとは

http://www.kaltura.org/

日本語の機能説明は http://www.kaltura.jp/technology/technology.html

kalturaは、PHPで作成された動画配信プラットフオームで、有償版のバージョンと、CEと呼ばれるオープンソースバージョンが存在する。
動作にはApache, PHP, MySQL が必要だが、要求されるバージョンが比較的細かいのでサーバ構築は少々手間である。最新のバージョンはKalturaCE 2.0.2

kalturaの特徴は、あくまで、「動画配信のためのシステム」である、ということが挙げられる。
Youtubeやニコニコ動画のようなユーザーインターフェイスの部分ではなく、配信基盤に重きをおいており、kalturaに保管した動画のプレイヤーを他のサイトに埋め込むという使い方が前提になっている(ように思える)
例えば、kalturaでは、オープンソースのブログエンジンであるwordpressからkalturaの存在を意識せず動画をアップロードできるようなプラグインや、教育用CMSであるmoodleに講義の動画等をシームレスに登録できるプラグイン等、多くの外部連携モジュールが用意されている。

2. インストール

最初にSnow Leopardにインストールしようとしたが、PHPやMySQLのバージョン要求が細かくて挫折したので、CentOS5.5をVirtualBoxにクリーンインストールした。
なお、以下のモジュールとバージョンが要求されるので、rpmだけで何とかしようというのは若干厳しい。
Apache >= 2.2
モジュールとしては
mod_rewrite
mod_headers
mod_expires
mod_filter
mod_deflate
mod_file_cache
mod_env,
mod_proxy
PHP = 5.2.x
MySQL >= 5.1.37

CentOS5.5系のPHPは標準では5.1系なのだが、kalturaはPHP5.2系を要求する(PHP5.3も標準では動作しない)ので、デフォルトでインストールされることが多いapacheとPHPとMySQLは利用せず、XAMPP for Linuxを利用した。
詳細については http://www.kaltura.org/kaltura-ce-setting-prerequisites-centos-55-wxampp に記載があるので、その通りやれば良い。

XAMPP 1.7.1のインストール

wget http://cdnbakmi.kaltura.com/content/files/xampp-linux-1.7.1.patched.tar.gz
tar xvfz xampp-linux-1.7.1.patched.tar.gz –C /opt

MySQLの設定

/opt/lampp/etc/my.confに以下を追記

lower_case_table_names = 1
thread_stack = 262144

シンボリックリンクを作成

既にapacheやPHPが導入済みの場合は、一旦apacheを停止した上で

mv /usr/bin/php /usr/bin/php_org
mv /usr/bin/mysql /usr/bin/mysql_org

としてリネームした上で、以下のようにシンボリックリンクを作成する

ln –s /opt/lampp/bin/mysql /usr/bin/mysql
ln –s /opt/lampp/bin/php /usr/bin/php

XAMPPを起動する

起動スクリプトは、/opt/lampp/lamppにあるので

cp /opt/lampp/lampp /etc/rc.d/init.d/lampp
/sbin/chkconfig --level 2345 lampp on
/etc/rc.d/init.d/lampp start

以上ができたら、XAMPPのインストール結果をブラウザで確認する

Curlのインストール

アプリケーション内で外部コンテンツを取得するのにcurlを利用しているので、curlをインストールする

yum install curl

memcachedのインストール

キャッシュのために、memcachedを利用している。無くても動作するが以下の手順でインストールする

rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
yum install memcached
/sbin/chkconfig --level 2345 memcached on
/etc/init.d/memcached start

メールサーバ(SMTP)の設定

kalturaはアカウント登録時にパスワードをメールで送信するので、メールサーバは必須。
CentOS5.5であれば標準のpostfixをそのまま利用すれば良い。
※評価の際にどうしてもメールの送信ができない場合は、何も設定せず、リターンメールを頑張って読めばOK

JREのインストール

リコメンデーションあたりで、JAVAのBIライブラリを利用しているのでjdkのインストールが必要だ。
Oracleが提供するもので問題ないが、openjdkでも動く。バージョンはいずれの場合も1.6以上。

yum install java-1.6.0-openjdk

Pentahoのインストール

BIツールらしい。初めてしった。

mkdir /usr/local/pentaho
cd /usr/local/pentaho
wget http://sourceforge.net/projects/pentaho/files/Data%20Integration/3.2.0-stable/pdi-ce-3.2.0-stable.tar.gz/download
tar xvfz pdi-ce-3.2.0-stable.tar.gz -C /usr/local/pentaho
mv data-integration pdi

必要なユーザーの作成

sudo useradd etl –d /home/etl
cd /home/
sudo chown etl:etl etl

SeLinuxを無効化する

/etc/sysconfig/selinux を開き、

SELINUX=disabled

とする

稼働状況の監視用にxymonを導入する

wget http://cdnbakmi.kaltura.com/content/files/centos5.i386/xymon/perl-rrdtool-1.2.18-1.rhel5.i386.rpm
wget http://cdnbakmi.kaltura.com/content/files/centos5.i386/xymon/librrdtool2-1.2.18-1.rhel5.i386.rpm
wget http://cdnbakmi.kaltura.com/content/files/centos5.i386/xymon/rrdtool-1.2.18-1.rhel5.i386.rpm
wget http://cdnbakmi.kaltura.com/content/files/centos5.i386/xymon/xymon-4.2.3-1.rhel5.i386.rpm
wget http://cdnbakmi.kaltura.com/content/files/centos5.i386/xymon/xymon-client-4.2.3-1.rhel5.i386.rpm
rpm -Uvh ./*.rpm

xymonの設定をapacheに追加

/opt/lampp/etc/httpd.confを開き、以下の1行を追加

Include /etc/httpd/conf.d/hobbit-apache.conf


lamppを再起動

/etc/rc.d/init.d/lampp restart

xymonの設定

/etc/sysconfig/xymon-client1を開き、

HOBBITSERVERS="localhost"

としてサーバ名を設定
自動起動の設定を行い、xymonを起動する

/sbin/chkconfig --level 2345 xymon on
/sbin/chkconfig --level 2345 xymon-client on
/etc/rc.d/init.d/xymon restart
/etc/rc.d/init.d/xymon-client restart

バーチャルホストの設定

kalturaは標準のインストーラーによるインストールでは、バーチャルホストでの動作を想定している。
そのため、ローカル端末での評価の場合は、hostsに適当なホスト名を設定するか、またはDNSの設定を行うことが望ましい。※一応設定せずに、インストーラで動作URLに127.0.0.1を設定しても動作はした。

インストールパッケージの入手

kalturaのサイトにアクセスしてユーザー登録を行って最新のインストーラーをダウンロードする( http://www.kaltura.org/project/community_edition_video_platform )か、またはsubversionで取得する。
今回はSubversionで以下のように取得した。

svn checkout http://www.kaltura.org/kalorg/kalturaCE/trunk

インストーラーの起動

上記で入手が終わったら

php install.php

としてインストーラーを実行すれば良い。あとは指示に従えばインストールは完了する。

3.ちょっと使ってみる

インストール完了後はhttp://(host名)にアクセスすると、以下のようなスタート画面が表示される。

新たな動画投稿者の作成

標準では動画投稿権限をもつユーザーはいないので、スタート画面に表示されている「Add New Publisher」をクリックしてログインし、投稿者を作成する。
なお、作成した段階でKMCにログインするためのパスワードが登録したメールアドレス宛に通知される。

Kaltura Management Consoleへのログイン

startページからKaltura Management Console(KMC)にログインする。
動画の掲載や、プレイリストの作成、埋め込み用のタグの取得はすべて、このKMCの中で行うことになる。(API連携しない場合)

デフォルトでいくつかサンプル動画が入っている。

コンテンツをクリックすると、プレビューと埋め込み用のタグが表示される。

あとは試しに、適当なhtmlページを作ってタグを埋め込んでみればよい。

4. Wordpressとの連携


Wordpressからkalturaをシームレスに扱うことができるプラグインが提供されている。
All in one Video pack プラグイン をWordpressにインストールしてあげれば良い。
※Wordpressとの連携の設定をする際に、特にkaltura側の認証がなく自動でkaltura側に新たなユーザーが作成されるように見えるが、だとすると誰でも公開されているkalturaを利用できることになってしまい問題がある。kaltura側で外部連携に関する何らかの制限がかけられると思うのだが、現在のところやり方がわからない。

5. ということで。。。

まだまだ色々触ってみないと分からないんだけど、動画配信用のプラットフォームをさくっと作りたい、という場合には良いのではないだろうか。
引き続き、携帯対応のあたりと、アクセスコントロール、APIの仕様について調べていこうかと思う。

 

日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有


ads

読まなきゃモグリ