masuidrive on rails » Blog Archive » プロジェクトの始まりはTracから
そんなわけで、プロジェクトの始まりはTracから。これがないと仕事が始まりません。 Tracが一番良いわけでも無いんだけど、日本語マニュアルがあるところと、ユーザが多いことから、subversionとの連携スクリプトなどが多数公開されているところが、選択理由です。 Railsベースでも複数、プロジェクト管理ソフトが出てきているので、どれか良い物に育ってくれると嬉しいなと思っています。 さて、tracのインストール方法はwebで沢山見つかるので、それを参考にインストール。 Tracは初期設定でも十分使いやすいんですが、チケット登録で担当者をドロップダウンリストにするために設定を変更します。 tracの設定ファイル conf/trac.iniの下記の項目を変更してください。 [trac] default_charset = utf-8 # 文字コードはUTF-8で [ticket] restr
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
シゴトハック研究所：チームの状況をおおまかに把握するには？【解決編】 - ITmedia Biz.ID
チーム全員の状況をリーダーが詳細に把握するのは無理があります。「ペア・スクリプト」を作成して、それをリーダーが読むことで、短時間で効率的にチームの進捗を把握できるようになります。 チーム全体の進捗状況を把握し、メンバーに対して的確な指示を出すことはリーダーに求められる役割の1つといえます。 とはいえ、すべてのメンバーの状況を誰か1人のリーダーがすべて把握しようとするのは無理があります。そこで、「ペア・スケジューリング」（6月15日の記事参照）という相互管理システムを導入することになるわけですが、これによって管理できるのはあくまでペアのメンバー2人の進捗であって、チームの進捗をリーダーが管理することが必要な場合もあるでしょう。 メンバーに「ペア・スクリプト」を作成してもらう 前回は、自分の仕事の実績をもとに「予定表のスクリプト」を作成する、という方法をご紹介しました（6月15日の記事参照）。
社内ライブラリやフレームワークを浸透させるには、「チュートリアル」「小さなサンプル」「レビュー」が必要 | gihyo.jp
濃縮還元オレンジニュース 社内ライブラリやフレームワークを浸透させるには、「チュートリアル」「小さなサンプル」「レビュー」が必要 数年前に書いた社内ライブラリの文書が今でも改訂され参照されている、という経験をもとに社内用文書や教育のあり方について語ったブログ記事です。 書籍『Building Application Frameworks』（John Wiley & Sons Inc）では、フレームワークの文書を「サンプル」「レシピとクックブック」「契約」「デザインパターン」「概要」「リファレンス」「設計ノート」に分類しているようで、ブログ筆者はその中で最も欲しいものはサンプルである、という結論に達したようです。また、過去に作られたアプリケーションからコピー&ペーストされることが多く、質の悪いコードのまま利用されることがあるという事実により、正しいコピペ素材を提供するためライブ
反復型開発における見積もりの実際：ベースとなるのはユースケース
オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。 そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified
開発マイルストーン
プロジェクト開発などのスケジュール管理をExcelで簡単かつグラフィカルに作成するマイルストーンは一つの指標です。 プロジェクトでは、達成したい目標へ向かってまずステップごとに段階を分け、計画を立てて実施します。 その結果の検証をして、これをもって修正された新たな計画を立て再び実施を行います。 このようなサイクルでプロジェクトを進めていく上で重要な指標がマイルストーンです。 ツール「開発マイルストーン」は、システム開発などで必要なプロジェクト管理をサポートするためのツールです。 MicrosoftExcelを使用して、簡単に入力でき、かつグラフィカルに表現することができます。 無料で使える工程管理ソフト 「開発マイルストーン」は、MicrosoftExcelが利用できる環境であればどなたでも利用できます。 また、本機能以外にもExcelに備わっている豊富な機
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> `�s�U �q��U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
好きなエディタで保存と同時にFirefoxをリロードするAHKスクリプト - AUSGANG SOFT
MacでRailsを使ってる人の定番エディタというとTextMateらしい。 Railsの開発チームも使っているのだとか。 コード補完や色分けが便利そう。 WindowsでもTextMateにインスパイアされて、よく似たエディタを開発している人がいます。 Intype http://intype.info/home/index.php シェアウェアになる予定ですが、まだα版で無料で試せます。 最近のアップデートでフォントの変更が可能になり、日本語も書けるようになりました。(アンドゥ・リドゥはまだできない。) Railsのアプリを書く時に使ってみようと思い立ったのですが、ひとつ困るのは、保存した際にブラウザをオートリロードができなくなること。 最速インターフェース研究会 :: AutoHotkeyを使ってFirefoxをリロードするだけのexeファイルを作ってみた http://la.ma.
OSX+Emacsで快適なRails開発ライフを送る
Posted by masuidrive Tue, 23 May 2006 13:22:00 GMT Rails用エディタを放浪 した結果、やっと、OSX上のCarbonEmacs で、rails.el + ECB + psvn.el を使い、EmacsなのにEclipse以上の環境を作る事ができました。 この環境＋Terminal上でscreenを立ち上げ、いくつかのログを tail -f LOGFILE で表示させて、殆どのソフトを作っています。 あとは、migrationをもう少し楽にできるツールが欲しいかな。そういえば、DB管理ツールのConductorとか、クラスタ管理のGaugeはどうなったんだろう？ まず、OSXでRailsを開発する上で気になっていたのが、subversion for OSX のパッケージを使うとメッセージ類が文字化けする件。これはロケールを正しく設定してや
「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法：ITpro
上段左からティーアンドエフカンパニー 事業推進統括責任者 情報化戦略コンサルタント 西岡祐弥氏，ティーアンドエフカンパニー 代表取締役社長 佐藤裕司氏，パフ 代表取締役社長 釘崎清秀氏，下段左よりティーアンドエフカンパニー 最高技術責任者 出羽健一氏，パフ 取締役兼株式会社プロシンクワーク代表取締役社長大場京子氏，パフ 事業サポートグループ グループマネージャー 保坂光江氏 Webシステムを開発する際にはほとんどの場合，ユーザーとの打ち合わせのためにHTMLによるモックアップを作る。「このHTMLがそのまま仕様書になれば」と思ったことはないだろうか。就職情報サイトPuffの再構築プロジェクトでは，まさにモックアップをそのまま仕様書した。「十数人の開発者で，5カ月で1000画面のシステムを開発する」必要に迫られたからだ。 HTMLに仕様とメモを埋め込み，CSSで切り替え 「この未体験のスピー
Life is beautiful: SEはメニューのないレストランのウェイターか？
一昨日書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーに対して沢山の人からフィードバックをいただいた。このように情報を発信すると、逆により多くの情報が集まり自分にとっても勉強になる、というフィードバックプロセスがあるからブログは楽しくて仕方がない。 フィードバックの中に「これでSE不要論も再燃か？」などという過激なコメントから、自分自身がSEという立場の方からのものすごく真面目なフィードバックまでが集まったので、これを機会に、ここに私なりに「SE」という職業をどう解釈しているか書いてみようと思う。もちろん、私自身がSEという職業を経験したことがあるわけでなないので、間違っているかも知れないが、その場合は遠慮なく指摘していただきたい。 私の理解では、SEという職業はレストランに例えればウェイターである。それも、メニューから料理を選んでもらう通常のレストランとは異なり、「
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」：Goodpic
This shop will be powered by Are you the store owner? Log in here
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー (2007-09-07)
Open Source Web Templates レビュー MOONGIFT
