<?xml version="1.0" encoding="UTF-8" ?><rdf:RDF 
  xmlns="http://purl.org/rss/1.0/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:atom="http://www.w3.org/2005/Atom"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xml:lang="ja">
  <channel rdf:about="http://w.atwiki.jp/uecklab/">
    <title>uecklab @ ウィキ</title>
    <link>http://w.atwiki.jp/uecklab/</link>
    <atom:link href="https://w.atwiki.jp/uecklab/rss10.xml" rel="self" type="application/rss+xml" />
    <atom:link rel="hub" href="https://pubsubhubbub.appspot.com" />
    <description>uecklab @ ウィキ</description>

    <dc:language>ja</dc:language>
    <dc:date>2011-07-07T21:53:22+09:00</dc:date>
    <utime>1310043202</utime>

    <items>
      <rdf:Seq>
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/32.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/31.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/30.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/29.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/28.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/27.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/26.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/25.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/24.html" />
                <rdf:li rdf:resource="https://w.atwiki.jp/uecklab/pages/23.html" />
              </rdf:Seq>
    </items>
	
		
    
  </channel>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/32.html">
    <title>matsu</title>
    <link>https://w.atwiki.jp/uecklab/pages/32.html</link>
    <description>
      2011-07-06の発表資料 matsu
pass:klab
http://www1.axfc.net/uploader/He/so/331113    </description>
    <dc:date>2011-07-07T21:53:22+09:00</dc:date>
    <utime>1310043202</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/31.html">
    <title>7/1haru</title>
    <link>https://w.atwiki.jp/uecklab/pages/31.html</link>
    <description>
      どのようしてチームメイトとコードをシェアするでしょうか
驚くべきことに、多くのチームはこの問題にはっきりと答えられず、かわりにただ大きく古い共有ドライブ
すべてのソースコードとそこらじゅうに横たわったその他のファイルをえるだけである。
あくとの数だけ開発者がいるーそれは単純に編集しているファイルをコードにコンパイルするー
はチームのほかのすべての開発者にすぐに影響を与える
彼らの人生は今では断続的で、うれしくない驚きでいっぱいである。

それはまさに感謝祭のキッチンの混雑に似ていて、みんな混雑の中に何かを投げていて、それは働く環境にとてつもない欲求不満をもたらしている。
このようにして多くのチームが動作を続けているあいだ、あなたは安全でより専門的な立場を得ることができるでしょう。
これは、あなたの道具やインフラに重大な影響を与えるでしょう、なので最初から右ストレートを取得する必要がある。

そこには、たった一つの基本的なルールを頭の中にとどめておいてほしい。：他の仕事はあなたの準備ができるまであなたの仕事の影響から隔離されます
そういうわけで私たちはこのサンドボックス開発と呼ぶ。すべての開発者は他の開発者の詳細なしでする彼ら自身のサンドボックス開発を持っている。

それは、簡単そうに聞こえるかもしれません、特に中期的にソースコードが隔離されているときは、しかし、実際の策略では
すべての資源があらわれることを覚えておいてほしい。：ソースコードやデータベース、インスタンス、依頼したウェブサービス等等。

あなた自身の開発の機械はあなた自身の生産に貢献するデザインにするべきである。
世界のビルドのプロセスの貢献すべきでない何か-それは、他のだれかが何かのために直接頼りにすべきではない

しかし、どのようにして他の開発者はあなたのコードを得ますか？
コードは倉庫（レポジトリ）を経由して共有されます。
レポジトリは大きな机を共有すると考えられます、しかし、それは司書によって管理されます。
その司書は、全員のバージョンのファイル（または他の資源）が彼らが必要とし、全員がお互いを追い払わずに仕事ができるように正しいか確認する
すべての開発者はソフトウェアツールをチェックインとチェックアウトし（まるで実際の図書室のように）使う、なので    </description>
    <dc:date>2011-07-01T14:54:11+09:00</dc:date>
    <utime>1309499651</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/30.html">
    <title>7/1end</title>
    <link>https://w.atwiki.jp/uecklab/pages/30.html</link>
    <description>
      多くのソフトウェア開発者は、今日フラストレーションを感じている。
彼らは長く、厳しい時間を働くが、彼らのチームは現在のプロジェクトを終えることはできないようです。
それは、努力や意欲が無いためではない;
チームに所属する誰でもきれいにプロジェクトを仕上げたいです、しかし、誰もそのための方法を知らない。
あなたの操作で何が動作し、どのようにそれを作るのか、を見つけるために読書や実験をする時間を見つけることは、非常に難しい。
大部分の人々は、この種の研究に乗り出すには、働くのに忙しすぎる。


そこで、Ship It!　の出番である。
この本は、フィールドで、複数のプロジェクトに関して、すべてのサイズの会社で証明された、基本的な、実際的なアドバイスのコレクションである。
それは、我々が遭遇したものだ。
我々は、数週間で出たり入ったりしたコンサルタントではない;
我々は、明けても暮れても、これらの会社で働いた。
我々は、良く聞こえて、次の約束へいどうするという考えの中に落ちたりしなかった。
物事がうまくいかなかったとき、我々はそれらが倒れるのを見るためにまだそこにいた。
一方、我々も、物事が本当にうまく行った時に見ることができた。


これらの考えの一部は有名なソフトウェア方法論から露骨に持ち上げられました、そして、我々はそれが信用を与えるべきであるとした。
他の考えは、血と汗と涙から創り出されました。
我々は多くのツール、技術、最高のプラクティスで実験しました、そして、何かが働いたとき、我々はそれを保ちました。
それがパタパタしたとき、我々はそれを投げました。
あなたがここで見るほとんどは際立って独創的でない（これはいいことである）。
その代わりに、我々は、業界で最良の知性から考えを選んで、「巨人の肩の上に立っていた」と、彼らをあなたがここで見るものに変えました。

ソフトウェア・チームの50～70パーセントが今日の基本的な、有名なソフトウェアの実践（［CusO3］）を使わない。
まだしばしば、彼らがどうすべきかわからないからではなく、彼らが単に実行を現時点で始めさせる方法を知らないから、これは使われない。
よく、各々の考えに関して管理を販売する方法をあなたに教えてください、あなたを始めさせるために、実用的なステップ    </description>
    <dc:date>2011-07-01T14:53:39+09:00</dc:date>
    <utime>1309499619</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/29.html">
    <title>7/1hagi</title>
    <link>https://w.atwiki.jp/uecklab/pages/29.html</link>
    <description>
      P13
家を作りたかった2人の男(マイクとジョー)がいた。
マイクは最初に多くの時間と道具を買い使い方を学ぶ十分なお金を費やした。
ジョーは、すでに持っている道具(ハンマーとドライバー)をとって作業し始めた。
驚くほどではないが、ジョーの家は早く建ち始めた。
一方マイクはコンプレッサーとネイルガン(タッカー?)の使い方を勉強しているあいだに、ジョーはハンマーで指を打っていた。
しかし、一度マイクが曲線を勉強・会得し、建築を始めると、彼はすぐジョーに追いついた。
マイクは時間をかけて道具の使い方を勉強したため、短い時間でいい家を作ることができた。
誰もが、誰が彼らの隣の家を早く作り終えられるのか、について驚くのか?

マイクのように、私たちは、処理における多くのツールを持つ。
私たちはジョーのようになって、既知のツールを使って作り、今すぐ働く必要を隠ぺいすることができる。
しかし、このチャプターのいくつかの道具はあなたが働くショップで扱えなかった。さもなくば、あなたは貧乏な道具を使うショップで働いたかもしれない。そして、あなたの口で悪い味を回避できるかもしれない。

私たちはあなたがこのチャプターを繰り返し、毎日のルーチンでポジティブインパクトを与えないと議論したかどうかを見てほしい。
フレッドな、典型的開発者は生活で毎日を見てみましょう。
彼らのワークエクスペリエンスは環境(道具とインフラ)に影響された。

&gt;誰もフレッドが見たトラブルを知らない
フレッドが朝仕事場につくと、ウイルマが昼に書いたコードの変更のメールを確認した。
その後その変更を求め、フレッドはネットワークからコードを落としてきてた。
1時間後、彼はウイルマの仕事のコンパイルを始めた。
彼は数分間で何度も変更をチェックし、作業を行った。
その時フレッドは思い出すために昨日のノートをみた。
彼はほとんど新機能のコーディングを終えていた。
3日後、彼は昼食までに終わるだろうと示した。

仕事の開始を熱望して、フレッドはコードエディタを立ち上げたが、彼の変更は消えていた。
悪い予感が彼をよぎった。
3日の仕事が30秒で消えて、元に戻せなかった。
「そんな…！」とフレッドはおもった。
「最初は起こらなかったのに、終わらないのか…仕事での危険だな。」    </description>
    <dc:date>2011-07-01T14:51:55+09:00</dc:date>
    <utime>1309499515</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/28.html">
    <title>7/1matsu</title>
    <link>https://w.atwiki.jp/uecklab/pages/28.html</link>
    <description>
      // 2-2 Manage Assets 資産を管理しろ
ほとんどの会社は、資産を管理することに打ち込む、大きなシステムやスタッフをもつ
それらは会社の価値ある物理的な資産のすべてを保持する
会社の価値ある物理的な資産ーコンピュータ、車、建物、オフィスでの成果物、など
ソフトウェアプロジェクトでは、あなたはいくつかのシンプルなタスクをもつ
シンプルなタスク：あなたが保持する必要があるすべてのものは、ファイルである
しかし、あなたはすべてのバージョンのビルドに用いる、すべてのファイルを保持する必要がある、プロジェクトが前進するはじめからの

この恐ろしいタスクのために、あなたはソース・コード・マネジメント（SCM）システムを必要とする
これはまた、バージョン・コントロール（VC）システムとも呼ばれる
これらのシステムは有能な司書として動作し、保管場所（またはデータベース）にあるあなたの資産（ファイル）を保持したり、あなたのファイルへの安全なアクセスをコーディネートしたりする
これらシステムはあなたのソースコードの貯蔵はもちろん行う、しかも、他のすべてのサポートファイルも保管する。
すべてのサポートファイル：全員がリリースする、グラフィック、ビルドスクリプト、XMLドロッピング、ドキュメンテーション、小さな（しかし重要な）パールスクリプト

きちんとセットアップしたSCMシステムと、あなたができること
・あなたのチームにプロジェクト全体にわたるアンドゥボタンを与える
：ファイナルはない。間違いは簡単にロールバックされる。
・ひとりより多くの人が与えられたファイルを同時に編集する（または編集したい）ときは、そのぶつかり合いに対処する
・複数のバージョンのあなたのソフトウェアに跡をつける
：他の人が古いリリースのバグを修正している間に、あなたは次のリリースへの特徴を追加することができる
・どのファイルが（いつ、誰によって）変更されたのか記録しなさい。
・歴史的ピークを取り出す
：あなたは任意の与えられた日にちからあなたの仕事をとりだせる

もし、あなたの開発ショップの全体が炎に焼かれても、あなたはあなたの保管場所のバックアップから、ただリカバリーすることができるはずだ
あなたはあなたが製品全体でビルドに必要なすべてのものを持    </description>
    <dc:date>2011-07-01T14:49:08+09:00</dc:date>
    <utime>1309499348</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/27.html">
    <title>7/1yas</title>
    <link>https://w.atwiki.jp/uecklab/pages/27.html</link>
    <description>
      ○Process -プロセス-

(No book on ...)
　ソフトウェア開発において、筆者のお気に入りの開発の方法論のプレゼンテーションなしに完成出来る本はなく、それは異なっていない。
（So we humbly ...）
　なので、私たちは謙遜して、トレーサーバレットディベロップメントと私たちが呼んでいるもののためにプラグを追加する。
（When you use ...）
　トレーサーバレットディベロップメントを使う時、あなたは、始めから終わりまで働くシステムを作り、それは大抵もみ消される。そしてその時、それを現実のものにするための失われた部分を埋めるのである。
（It&#039;s good for ...）
　それは、大きなプロジェクトの部署の分割と、チームに部分的な仕事を並行的にさせることには良い。そしてそれはまた、自動化されたテストを自身が適切に援助する。


○Common Problems and How to Fix Team -一般的な問題と、チームの決め方-

（Finally, we present ...）
　最後に、私たちは、道具や、技術や、そして本書の残りで記述しているプロセスを用いてどのように解決するかのアドバイスを提供し、発生しうる一般的な問題（そして、危険な信号）を述べる。
（A lot of ...）
　私たちが自身で遭遇したこれらの問題の多くは、年間に渡っている。
（Some we solved ...）
　いくつかは解決され、その他はどのようにこの事実（結局、20/20が後知恵である、）の後、どのように解決するかを理解した。
（We hope our ...）
　我々の経験が、あなたを、私たちが昔犯したものと同じ間違いから救ってくれるであろうと願っています。



○What&#039;s Missing? -何を失ったか？-
（People and requirements ...）
　人々と要求を集めることは、私たちが含んでいない二つの領域である。
（Good people trump ...）
　優れた人々は、道具や、技術や、そして最も重要なプロジェクトの一部分としてのプロセスといった切り札を出す。すなわち、しかしながら、巨大なチームを招集したり維持することは、自身の本の主    </description>
    <dc:date>2011-07-01T14:45:45+09:00</dc:date>
    <utime>1309499145</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/26.html">
    <title>7/1mishi</title>
    <link>https://w.atwiki.jp/uecklab/pages/26.html</link>
    <description>
      Build Automatically
自動的にビルド

無人のビルドは自動的なものである。
しかしながら、自動的にビルドが実装できる前に、あなたはシングルコマンドに伴った実行を出来る場所のなかのマニュアルビルドシステムを持っていいなければならない。
もしあなたがそれを持たない時、26ページのPractice３のScriptYourBuildへ戻りなさい。

あなたは存在しないプロセスを自動化することが出来ない。
一度あなたはあなたのプロダクトを自動的にビルドすることが出来き、どのくらいの頻度でこのような操作を行う必要がありますか？　
理想的に、あなたはコードを変化させる時いつでもリビルドできるでしょう。
このシステムのためのスモークテストのライトウェイトセットを追加し、あなたも同様に機能的な保険の基本的なレベルを得ます。
このシステムのタイプはContinuous Integration（連続したインテグレーション（統合））と呼ばれています。

Citoolはクリーンな位置づけで、非開発者BOX（ビルドマシーン）といつも誰かにリビルドされたあなたのプロジェクトはコードをコミットします。
それぞれの時間でリビルドされているコードはその問題が起こるやいなやコンパイルエラーがキャッチされることによってあなたのコードベースクリーンを維持します。
それはまた機能的なエラーを得るためにあなたのテストスイートを実行します。
私たちはCruiseControlと呼ばれるCItool　オープンソースを使用します。何故ならそれは、とてもよくサポートされ、よくスケールされ、無料だからです。
残念なことに、多くの開発ショップ（70％近く）は面倒な毎日のビルド、ましてCIシステムを苦にしません。
CIシステムを持つこれらのショップは一貫して投入された良いコードとより安定した製品と最高のひとつである
あなたはこの技術のタイプを導入する可能性が最も高いお店は主張するかもしれないことはかなり高度で、よりよいコードを判別する
私たちは同意しない。
私たちは殆どすぐにコミットする悪いコードをキャッチする定数“仮想ビルドモニター”を持つ事によって利益が来ると信じています。
それは常にコンパイルされないコードにフラグを立てます。
また、あなたが変更された既存    </description>
    <dc:date>2011-07-01T14:45:07+09:00</dc:date>
    <utime>1309499107</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/25.html">
    <title>7/1mik</title>
    <link>https://w.atwiki.jp/uecklab/pages/25.html</link>
    <description>
      A build converts source code into a runnable program. Depending on the computer language and environment, this may mean you’re compiling source code and/ or bundling images and other resources together as needed. The scripts, programs, and technologies used by your compile and resource bundling are all combined to create the build system.
ビルドは実行可能プログラムにソースコードを変換します。コンピュータの言語（プログラミ具言語）と環境によって、これはソースコードのコンパイル及び又は必要に応じて複数の画像や他のリソースをバンドルすることを意味します。
バンドル：束ねる、まとめる
スクリプト、プログラム、およびコンパイルやリソースバンドルで使用される技術は、ビルドシステムを作成するためにすべて結合されています。
リソースバンドル：ロケールに応じてリソースが自動的に決定される仕組み

Now remember we&#039;re not talking about compiling/ building within your IDE. For the most part, you do not want to use your personal developer IDE to compile the project, even if you‘re the only one using it (see Practice 1, Develop in a Sandbox, on page 17 if this sounds odd to you). We’re talking about a build on your own machine that parallels the “ofﬁcial” build on the build machine. Here’s a little story to explain why.
今    </description>
    <dc:date>2011-07-01T14:44:25+09:00</dc:date>
    <utime>1309499065</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/24.html">
    <title>割当</title>
    <link>https://w.atwiki.jp/uecklab/pages/24.html</link>
    <description>
      end chapter1 最初 ～ 1.3 Techniques
mid&#039;k&#039; 1.3Process ～ p11 Joe Asks..まで
hagi chapter2最初 ～p16まで
haru p17-p19
matsu p20-25
mik p26-p30
mishi p31-p35

end p36-p40 It&#039;s Not a Bug, It&#039;s a Feature! まで
mid&#039;k&#039; p40　Track Features ～ p44
hagi p45～p50
haru p51～p54
matsu p55～p59 Tip14の上まで
mik p59 How Should I Use The List～p66 Targetedの上まで
mishi P66 Targeted～p71 The Responsibilities...の上まで

end p71 The Responsibilities of Tech Lead～p74
mid&#039;k&#039; p75～p79 Reinventing the Wheel の上まで
hagi p79 Reinventing the Wheel ～ p84 How ti Get Startedの上まで
haru p84 How to Get Started～p88 Pair Programmingまで
matsu p88 Review All Code～p92 Refactoringまで
mik p92 Never use this ～ p98 Informatin Radiatorsまで
mishi p98 Send Code Change Notifications ～ p102

end p103 ～ p106
mid&#039;k&#039; p107 ～ p110
hagi p111 ～ p114 Tip20の上まで
haru p114 Write the Interface Stubs ～p118 Fill In the ...の上まで
matsu p118 Fill In The Stubs with Functional Code ～ p121 A Brief Exampleの前まで
mik p121 A Brief Example ～ p124 Selling Tracer B    </description>
    <dc:date>2011-07-01T14:44:48+09:00</dc:date>
    <utime>1309499088</utime>
  </item>
    <item rdf:about="https://w.atwiki.jp/uecklab/pages/23.html">
    <title>サーバー</title>
    <link>https://w.atwiki.jp/uecklab/pages/23.html</link>
    <description>
      *&amp;bold(){サーバーの情報はここへ}

-mishi発言
BBS&amp;1;ユーザー名&amp;1;文の内容
例： action=BBS&amp;username=346yuki&amp;contents=これはBBSのテストです
QandA
QA&amp;1;ユーザー名&amp;1;Subject&amp;1;&lt;Q|A質問ID&gt;&amp;1;文章
例： action=QA&amp;subject=題名テスト&amp;qora=question|answer1&amp;contents=これはQorAのテストです
タスク
TASK&amp;1;&lt;N|タスクID&gt;&amp;1;UserName&amp;1;taskName&amp;1;進捗率の数字
例： action=TASK&amp;taskchk=New|taskid1&amp;username=346yuki&amp;taskname=タスクテスト&amp;prograte=50.0

↑こんな感じにしたいんだけどどうかね？
あと＜N｜タスクID＞のNって何？


-mik
送信側
掲示板
BBS&amp;1;ユーザー名&amp;1;文の内容

QandA
QA&amp;1;ユーザー名&amp;1;Subject&amp;1;&lt;Q|A質問ID&gt;&amp;1;文章

タスク
TASK&amp;1;&lt;N|タスクID&gt;&amp;1;UserName&amp;1;taskName&amp;1;進捗率の数字

受信側
BBS&amp;1;[C要求レス数|D日付エポック]
	return一覧
	[レスID&amp;1;日時&amp;1;ユーザー名&amp;1;文の内容[&amp;0;...]]
QandA&amp;1;[C要求質問数|D日付エポック]
	return一覧
	[&lt;A|質問ID&gt;&amp;1;日時&amp;1;ユーザー名&amp;1;文の内容[&amp;0;...]]
タスク
TASK&amp;1;[C要求タスク数|D日付エポック]
	return一覧
	[タスクID&amp;1;日時&amp;1;UserName&amp;1;taskName&amp;1;進捗率の数字[&amp;0;...]]    </description>
    <dc:date>2011-07-04T15:32:58+09:00</dc:date>
    <utime>1309761178</utime>
  </item>
  </rdf:RDF>
