CakePHP2アプリケーションをCapistranoでデプロイする
アプリケーションのデプロイを自動化すべきなのは言うまでもないことです。 一応手動でデプロイを行う場合の問題点について整理しておくと以下になります。 プロジェクトの期間中そして運用に入ってからも何度も手でデプロイするということはとてつもなく多くの時間を手作業に費やすことになるデプロイ先の環境の数が多くなればなるほど作業の時間も増える手作業で作業すると間違えやすい。特に手順が複雑だったり環境が多かったりすると確率は飛躍的にあがるもしデプロイしたアプリケーションに問題があってすぐに戻さなければならない場合に多くの時間がかかる。場合によってはビジネス上の機会損失に繋がる本来は価値を生むフィーチャーを実装することに時間をかけたいはずが、こういうことをやっているとどんどん時間がなくなっていきます。また手作業のリスクや消費される時間を恐れてデプロイの回数を減らしてしまうのは、ビジネス側からみると納得いか
チームへの期待を明らかにする
みなさんこんにちは。@ryuzeeです。 この記事は現在発売中のアジャイル同人誌Ultimate Agile Stories2に掲載させていただいたものを転載するものです。 1.はじめにアジャイルコーチという職業柄もあって今まで多くのチームを見てきた。良いチームもあれば、「うーん、これは単なる人の集団で、チームじゃないなぁ」と嘆きたくなるようなことも中にはあった。本稿では私自身がチームに期待することを明らかにしつつ、読者のチームでもこのような整理をすることをお勧めするものである。 2.1 私がチームのメンバー個人に期待すること給料をもらえるのは、自分が会社に所属しているからではなく、その先にお金を払ってくれるお客様がいるからだ、ということを理解しよう。したがって、お客様の期待に応えられるようにふるまう責任があることを理解しよう。 こんなの当たり前じゃないか！と思うかもしれない。しかし、コマ
資料公開 Agile開発ツール導入の勘所
2012年7月18日(水)に行われたAgile Conference Tokyo 2012に登壇してきました。 30分という短い時間(予定通りの長さで延長したわけではありません！)の中で駆け足でAgile開発から継続的デリバリー、継続的フィードバックやALMへの流れ、なぜテスト自動化が求められるのかといった話と、それに絡めたツール導入の方向性の話をしたつもりです。(もうちょっと笑いを誘える流れにしたかったのですが固くてスイマセン) 当日の参加者の方の多くがAgile開発未経験ということで、Agileに関して銀の弾丸を期待していたり色眼鏡で見られていたりする方もいるかもしれませんが、Agileな開発のやり方や各種ツールは目的達成のための道具でしかありません。 全てのプロジェクトをAgileでやるべきだとも思わないし、Agileでやったからといってうまくいくかの保証もない。ツールも同じで高いお
「塹壕よりScrumとXP」その後とテスト自動化順序の決め方
みなさんこんにちは。@ryuzeeです。 「塹壕よりScrumとXP」はHenrik Kniberg氏が書いた無料書籍で、日本語を含めて13ヶ国語で読まれている最も有名なスクラムとXPに関する導入事例の1つです。 日本語訳はInfoQの以下のページからダウンロード可能です。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches そのHenrik氏が、Agile Israele 2011で行ったキーノートが、非常に良いものなのでご紹介します。 資料は氏のサイトからダウンロードできます。 このスライドでは、Henrik氏がもし記事を書いた2006年に戻ったら今度は違うやり方をするであろう項目について説明しています。 項目は以下の15個です。 キューを制限するチーフプロダクトオーナーのロールを設けるバックログの項目はユーザースト
技術的負債にどのように取り組むか
みなさんこんにちは。@ryuzeeです。 定期的にSlideshareをウロウロして良い資料がないかを探しているのですが、技術的負債に関する分かりやすい資料があったのでご紹介します。 技術的負債とは、現在の進捗のために、将来のキャパシティ(ソフトウェアの開発能力)を犠牲にすることであるもうちょっと具体的に言えば、技術的負債とは、ソフトウェアの内部的な問題（見つかっているか見つかっていないかは関係はない）、要求の明確化の欠如、ダメな設計、ビジネスの要求に適していない設計、自動化できるはずの箇所の手動処理などを指す**利子の支払いは時間のムダである。**例えば欠陥を直すのに時間を取られる、要求が明確になった後に再度作りなおす、複雑なコードを理解するために余計な時間を取られる、などなど技術的負債の悲惨なサイクルがあるテストを書く時間がない、リファクタリングする時間がない、設計レビューする時間がな
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
[メモ]SWFUpload | Ryuzee.com
SWFUploadはオープンソースのファイルアップロード用ライブラリでJavaScriptとFlashで実装されている。 主な特徴は CtrlやShiftキーを使って一度に複数ファイルを選択しアップロードできる 全てのイベントでJavaScriptのコールバックが可能 アップロード開始前にファイルの情報の取得が可能 アップロードの部品もCSSで加工してある ファイルやアップロード状況をhtml上で表示 ページのリロードが不要 Flashをサポートしているプラットフォームならどんなブラウザでも動作 FlashかJavaScriptが使えない場合は、標準のアップロード機能として動作 アップロード開始前にファイルサイズで判定 指定したファイル種別のみを選択画面に表示 キューを使ったアップロードが可能で、アップロード開始前ならキューへの追加・削除が可能 んでもってCakePHPで簡単に利用できる
TracでStractisticsPluginを使ってみる | Ryuzee.com
インストールが終了すると上部のタブにStractisticsが追加される。 クリックすると状況が表示される。 現在表示されるものは下記の３つである。 過去12週間のコミット数の推移 過去30日間のチケットの状況推移 過去12週間のWikiの状況推移 サンプルは下記の通りだ。 導入に際してのオプションは下記の通りである。 repository_authors_limit コミット数の推移で上位何人のコミッターまで表示するか。デフォルトは5人まで wiki_authors_limit Wikiの状況推移で上位何人の編集者まで表示するか。デフォルトは5人まで ignored_repository_authors コミット数の推移で集計から除外するコミッターを指定する。複数指定する場合はカンマ区切り ignored_wiki_authors Wikiの状況推移で集計から除外する編集者を指定
Tracいろいろ | Ryuzee.com
大分社内への布教活動も進んでいて、さらに使いやすくするために色々いじくっているのでメモ。 なお、現在利用しているバージョンは0.10.4である。 ■チケットの担当者をプルダウン選択にする trac.iniの[ticket]セクションにあるrestrict_ownerをtrueに変えれば良い。 ■ガントチャートとカレンダーを利用する TracGanttCalendarプラグインを利用する。 但し本家サイトで作成されているものは0.11専用で0.10系では動作しない。 そこでこちらから、0.10対応のモジュールを入手する。 wget http://pw.tech-arts.co.jp/technical/src/ganttcalendar-0.0.1.tar.gz tar xvfz ganttcalendar-0.0.1.tar.gz cd ganttcalendar-0.0.1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TracをXML_RPC経由で操作する(基本編) | Ryuzee.com
TraM(Trac Multi)の導入 | Ryuzee.com
FireFox用HTML構造分析プラグイン | Ryuzee.com
Perl関連情報 | Ryuzee.com