Our client - tailspin Toys...

- Small brick & mortar hobby shop that sells model airplanes

- Want an online store front to supplement in-store sales

: Define the solution's boundaries

: Identify Who will impacted by the solution

: Discover what valuable activities will be automated 

: Uncover constraints that will limit the solution

: Kick-start the requirements gathering process

- Warnings

: Not standard UML

: More in common with mind-mapping techniques

-Tip

: Limit workshops to about 1hour each

: Always start with a vision of solution (context)

: Clearly identify who lives inside and outside the system(Scope)

: Describe goals from users' point of view(business value)

: Generate lots of ideas and capture everything

Tips

- Think of actors as roles, not job titles

- Use business domain terminology

- Focus on actor's goals, not implementation details

- Use strong, active verbs in the names

- Focus on only one "feature area" in a single diagram

- Stack cases in diagrams to show relative order

- Use color and notes to document important details

Domain Modeling Tips

- Use Friendly name (spaces, no abbreviations)

- Show just those classes needed in descriptions of the requirements

- Focus on names and simple relationship(associations)

    : Don't worry about aggregation or composition - that comes later in detailed design

- Capture multiplicities to clarify the relationships

- Add attributes, and types only if they needed to clarify a requirement

    : Stick with standard primitives for attribute types : Boolean, Integer, String

    : Add domain specific types if they add clarity (Temperature: Celcius , Duration: Weeks)

- Stay implementation - independent

    : Don't assign visibilities - that's comes later in detailed design

    : Avoid modeling keys or IDs - they are an implementation detail

    : Avoid modeling verbs/actions/operation/functions

Activity Diagram

- Next generation flow charts

- Used to show processes

    : business processes

    : work flows

    : algorithms

- Complementary to use cases

    : Show task flow instead of structure

Tips

- Use Tem to capture and validate business processes

- think in terms of users' actions

- Focus on actions that are visible from outside the system

- Use to show flow of actions that span multiple use cases

- Best diagram for showing parallel operations

- Focus on only one "activity" in each diagram

http://blogs.msdn.com/vsarch
http://www.notsotrivial.net

 [Reference Book]
1.Brain Storming
Managing Software Requirements
the Rational Unified Process Made Easy
user Stories applied

2.Use Case Modeling
Use Case Modeling
Use Case : patterns and Blueprints
UML 2 and the Unified Process

3.Domain Model
Domain Driven Design
Use Case Driven Object Modeling with UML

4.Capturing Business Workflow
UML 2 and the Unified Process
UML Distilled
Use Case Modeling

5.architecting an application Using A layer Diagram
Microsoft application Architecture Guide - 2nd edition
Architecting Applications for the Enterprise
Domain Driven Design

6.Component Modeling
The unified Modeling Language User Guide - 2nd Edtion
UML Distilled - 3rd Edtion
the Elements of UML 2.0 Style

7.Sequance Diagram Modeling
UML 2 and the Unified Process
elements of UML 2.0 Style
Use Case Modeling

8.Class Modeling
UML 2 and the Unified Process
elements of UML 2.0 Style
Use Case Drive Object Modeling with UML

9.Organize models
Domain Driven Design
Patterns of Enterprise application Architecture
Architecting Applications for the Enterprise

default:
  # Outgoing emails configuration (see examples above)
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
     
      address: ip를 넣는다.

      port: 25
      domain: domain을 넣는다.
      authentication: :none <= ":"를 넣음에 주의

옵션 설명

-p 각 커밋에 적용된 패치를 보여준다.
--stat 각 커밋에서 수정된 파일의 통계정보를 보여준다.
--shortstat `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다.
--name-only 커밋 정보중에서 수정된 파일의 목록만 보여준다.
--name-status 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것
인지도 보여준다.
--abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.
--relative-date 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다.
--graph 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다.
--pretty 지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format
은 원하는 형식으로 출력하고자 할 때 사용한다.

조회 제한 조건

-(n) 최근 n 개의 커밋만 조회한다.
--since, --after 명시한 날짜 이후의 커밋만 검색한다.
--until, --before 명시한 날짜 이전의 커밋만 조회한다.
--author 입력한 저자의 커밋만 보여준다.
--committer 입력한 커미터의 커밋만 보여준다.

세 가지 상태
Git은 파일을 Commited, Modified, Staged 이렇게 세 가지 상태로 관리한다.

Commited : 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.

Modified  : 수정한 파일을 아직 로컬 데이터베이스에 Commit 하지 않은 것을 말한다.

Staged    : 현재 수정 한 파일을 곧 Commit 할 것이라고 표시한 상태를 의미한다. 

 Git Directory, Working Directory, Staging Area

Git Directory : Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳 , Git의 핵심이다.

다른 컴퓨터에 있는 저장소를 Clone 할 때 Git Directory가 만들어진다.

Working Directory :  프로젝트의 특정 버전을 Checkout 한 것이다. Git Directory는 지금 작
업하는 디스크에 있고 그 Directory에 압축된 데이터베이스에서 파일을 가져와서 Working  Directory를 만든다.

Staging Area :  Git Directory에 있다. 단순한 파일이고 곧 Commit 할 파일에 대한 정보를 저장한다

$ git status
# On branch master
nothing to commit (working directory clean)

$ git add README
git status 명령을 다시 실행하면 README 파일이 Tracked 상태이면서 Staged 상태라는 것
을 확인할 수 있다:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#

$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#

$ vim benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#

$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end
+ run_code(x, 'commits 1') do
+ git.commits.size
+ end
+
run_code(x, 'commits 2') do
log = git.commits('master', 15)
log.size

$ git diff --cached
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README2
@@ -0,0 +1,5 @@
+grit

$ git add benchmarks.rb
$ echo '# test line' >> benchmarks.rb
$ git status
# On branch master
#
# Changes to be committed:
#
# modified: benchmarks.rb
#
# Changed but not updated:
#
# modified: benchmarks.rb
#

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index e445e28..86b2f7c 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -127,3 +127,4 @@ end
main()
##pp Grit::GitRuby.cache_client.stats
+# test line

$ git diff --cached
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..e445e28 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]

$ git commit

$ git commit -m "Story 182: Fix benchmarks for speed"
[master]: created 463dc4f: "Fix benchmarks for speed"
2 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 README

$ git status
# On branch master
#
# Changed but not updated:
#
# modified: benchmarks.rb
#
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
1 files changed, 5 insertions(+), 0 deletions(-)