비주얼 스튜디오 프로젝트에서 svn 관리시

akhn svn 을 못쓸경우 직접 폴더가서 svn add 하는데, 쓸떼 없는 파일들도 선택되어 들어갑니다.

이럴땐 setting 설정의 global ignore pattern 에 아래를 추가 하면 됩니다.


*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__ *.rej *~ #*# .#* .*.swp .DS_Store

*.sdf *.obj *.pdb *.pch *.log *.idb *.sdf *.tlog *.ipch




출처 : http://blog.codinghorror.com/new-programming-jargon/

http://www.mimul.com/pebble/default/2012/09/11/1347354933116.html

 



이 포스트는 Stack Overflow에서 "New programming jargon you coined?"라는 질문을 하고 이에 답한 것들중에 투표를 통해 30개 선별된 것에 대한 설명을 정리한 것입니다.
살펴보니 재미있는 것이 많습니다. 우리나라도 한번 커뮤니티나 페이스북에서 공론화하면 좋을듯 합니다.
아래는 Stack Overflow를 기반으로 해 Coding Horror에서 정리한 포스트("Coding Horror : New Programming Jargon")를 제멋대로 의역해봤습니다. 오역이 있으면 댓글로 의견 부탁드립니다.

1. Yoda Conditions


변수와 상수를 비교할 때는 상수를 왼쪽에 변수를 오른쪽에. 스타워즈의 요다가 "The sky is blue" 대신에 "if blue is the sky" 혹은 "The man is tall" 대신에 "if tall is the man"라고 말하는 것에서 옴.

2. Pokemon Exception Handling


모든 예외는 다 잡아야 한다.

try {
}
catch (Exception ex) {
   // Gotcha!
}


3. Egyptian Brackets


줄 끝에서 중괄호를 여는 스타일. 이집트인 그림 손의 위치가 출처임.

if (a == b) {
    printf("hello");
}


4. Smug Report


시스템 디자인을 설계한 자신보다 더 많은 것을 알고 있다고 생각하는 사용자가 제출한 버그. 관련 단어로 Drug Report, Chug Report, Shrug Report.

5. A Duck


관리에 관심을 끌기 위함이 아니라, 제품의 다른 관점에서 불필요한 변화를 피해기 위해서, 특별한 이유없이 추가된 기능. 결국 그 기능은 없어지게 된다.
아티스트가 어떤 애니메이션(배틀 체스의 여왕 애니메이션) 제작에 참여했을때 변화, 즉 일한 티를 내려고 한 혁신적인 솔루션은 다른 애니메이션에 영향을 주지 않는 선에서 오리 캐릭터를 추가하는 것이었다. 그런데 결국 프로듀서가 리뷰를 하고 나서 "오리를 제거하라"고 한마디를 남겼다.

6. Refuctoring


잘 설계된 코드가 적용되었더라도 작게라도 이것 저것 뒤적거리면 나자신 이외에는 아무도 유지보수 할수 없는 코드가 된다.

7. Stringly Typed


올바른 코드 규칙(강한 타입)을 가지고 코딩을 하면 되는데, 함수의 파라미터를 적절한 타입을 사용하는 것이 아니라 문자열을 나열하는 식으로 코딩을 해, 코드는 이해할 수 없게 되고 심지어 에러를 유발하게 된다.

8. Heisenbug


버그에 대해 연구를(찾을려면) 시작하면 그 특성이 변하거나 사라지는 버그. 출처는 불확정성 원리를 만든 하이젠 베르크에서 옴.

9. Doctype Decoration


웹 디자이너가 doctype 선언문을 추가했지만 유효한 마크업을 작성하려고 신경쓰지 마라.

<!DOCTYPE html>
<BLINK>Now on sale!</BLINK>


10. Jimmy


Jimmy는 우둔한 신입 프로그래머의 이름. 잘 설계된 프레임워크 코드를 참조할 때 "Jimmy 방지"라는 용어를 언급한다.

11. Higgs-Bugson


이벤트 로그 및 모호하고 입증되지 않는 사용자의 보고에 의해 약간의 가능성에 기초한 가상 버그들이 예측한다. 그러나 개발 컴퓨터에서 재현하기가 어렵다.(힉스 입자처럼)

12. Nopping


NOP는 어셈블리의 no operation의미로, 실제 아무 의미없는 명령이지만, 아무것도 안하는 것은 아니다.(NOP

13. Unicorny


초기 계획 단계이기 때문에, 마치 공상하는 상태처럼 설명되지 않는 기능.

14. Baklava Code


터키의 얇은층이 많은 과자. 너무 많은 레이어를 가진 코드.

15. Hindenbug


Hindenbug호 폭발 사고의 비극인 데이터 손실로 인한 버그(데이터 레이어에서 발생하는 버그). Counterbug와 Bloombug가 관련 있음.

16. Fear Driven Development


몇몇을 해고하거나 일정을 앞당기거나, 자원을 빼는 등이 관리자가 압력으로 행사하는 것.

17. Hydra Code


불사신의 히드라처럼 고칠 수없는 코드. 하나 버그를 고치면 새로운 2개의 버그가 발생한다. 고쳐도 고쳐도 새로운 문제가 나온다. 

18. Common Law Feature


잘못하고 있는 것에도 불구하고, 사양의 일부가 되어 버린 버그.

19. Loch Ness Monster Bug


재현 가능성이 없고, 목격자가 1명 밖에 없는 정체 불명의 버그.

20. Ninja Comments


보이지 않는 댓글, 비밀 댓글이나 의견이 없는 것. 즉, 코멘트가 없다.

21. Smurf Naming Convention


모든 클래스에 동일한 프리픽스가 붙어있다. 예로 사용자가 버튼을 클릭하면 SmurfAccountView가 SmurfAccountDTO를 SmurfAccountController에게 전달한다.

22. Protoduction


프로토타입인 채로 세상에 나온 것.

23. Rubber Ducking


문제를 해결하기 위해서 누군가에게 가서 대화와 듣기를 통해 해답을 얻을 수 있다는 생각에 해결책을 찾기 위해 오리 장난감에게 말을 건내는 것.

24. Banana Banana Banana


나중에 채워넣기 위해 임시적으로 적어 놓는 문구. IDE의 경고를 피하기 위해 우선 임시로 적는다.

/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate()

25. Bicrement


변수에 1을 더하는 대신 2를 더한다.

26. Reality 101 Failure


요구하는대로 움직이고 있지만, 배포될 때 문제가 오해로 밝혀져 쓸모 없는 코드가 되는 것.

27. Mad Girlfriend Bug


분명 이상한 일이 일어나고 있는데도 불구하고 소프트웨어는 문제없다라는 메세지만 남긴다.

28. Megamoth


MEGA MOnolithic meTHod(2천라인 이상의 코드). 두개의 화면에 걸쳐 있는 거대한 객체(소스).

29. Hooker Code


애플리케이션 다운 등을 종종 유발하는 코드.

30. Jenga Code


한 블록 변경하면 전체가 붕괴 할 것 같은 코드. 

출처 : http://geniusduck.tistory.com/28



Class 및 Class instance 의 기본 표기 형식 


Class 표기형식 

UML Diagram 중에서 가장 기본적인 표현 단위인 클래스의 표기형식을 알아보자.


Class 표기형식

+  :  public
-  :  private 
#  :  protected


*  variables, methods 는 생략이 가능하나 class 이름은 반드시 명시해주어야 한다.

위의 class 를 소스코드로 표현하면 아래와 같다.

Person Class



Class instance 객체의 표기형식 


Class instance 객체의 표기형식



Relationships( 관계 표현 )

서로 의미있는 클래스들의 관계에는 크게 4가지 종류가 있다.

일반적인 의미의 연결 관계인 연관( association ) 관계, 전체와 부분을 나타내는 

집합( aggregation )  관계, 다른 클래스의 재산을 물려받는 상속( inheritance ) 관계

그리고 한 클래스가 다른 클래스에 영향을 미치는 의존( dependency ) 관계가 있다.


이 중에서도 association  과 aggregation, composition 이 세가지 관계가 가장 헷갈릴 수 

있는데 간략하게 정리를 해보자면 아래의 그림과 같다. 회색 부분이 각각의 관계를 구분짓는 

기준이 된다고 볼 수 있다.


사용자 삽입 이미지


association 과 dependency 를 구분짓는 가장 큰 기준은 ' 참조하는 클래스 인스턴스의 

레퍼런스를 계속 유지하고 있느냐, 아니냐 ' 이다. 아래의 소스 코드들을 보면서 이해해보자.


[ 소스 코드 1 ] dependency


사용자 삽입 이미지



[ UML ] dependency ( A ----> B )


사용자 삽입 이미지




[ 소스 코드 2 ] association
 

사용자 삽입 이미지


[ UML ] association ( A - > B )


사용자 삽입 이미지




◆ dependency( 의존 관계 )

클래스가 연관, 상속, 집합 관계로 엮여 있는 것은 아니지만, 한 곳이 변경되면 그것을 사용하는
 
다른 곳도 같이 변경해줘야 하는 관계를 표현할 때 주로 사용한다. 단, 주의해야 할 점은 

association 과 달리 dependency 의 경우에는 클래스 인스턴스의 레퍼런스를 유지하고 

있지 않다는 점이다. 레퍼런스를 계속적으로 유지하게 되면 이는 association 으로 표현해야 

한다.

주로 다음과 같은 세 가지 경우에 의존 관계로 표현한다.

1. 한 클래스의 메소드가 다른 클래스의 객체를 인자로 받아 그 메소드를 사용한다.
  ( 가장 일반적 ) 

2. 한 클래새의 메소드가 또 다른 클래스의 객체를 반환한다.

3. 다른 클래스의 메소드가 또 다른 클래스의 객체를 반환한다. 이때 이 메소드를 호출하여
   반환되는 객체의 메소드를 사용한다.





◆ association( 연관 관계 )


한 객체가 다른 객체와 연결되어 있음을 나타낼 때 그들을 연관관계로 지칭한다. 이러한 

연관관계에서 중요하게 볼 점은 ' 연관 관계의 방향( navigability ) 과 멀티플리시티

( multiplicity ) 이다.

사용자 삽입 이미지



양방향 연관 관계 : 연결된 클래스들이 서로의 존재를 알고 있다는 의미이다.

위의 UML 을 해석하자면 House 와 Person 클래스는 서로의 존재를 알고 있으며, 반드시 

한 사람 이상이 House에 속해야 한다는 것을 뜻한다. 

사용자 삽입 이미지


단방향 연관 관계 : House 클래스는 Person 클래스의 존재를 알고 있지만, Person 은 

House 클래스의 존재를 모르고 있다고 이해하면 된다. 이와 같은 경우는 House 클래스만 

Person 클래스에 대한 참조값을 가지고 있고, Person 은 House 에 대한 어떠한 참조값도 

가지고 있지 않는다.  


관계 표현을 나타낸 그림에서 보면 일반 연관과 특수 연관이라고 나뉘어 지는데, 

특수 연관이라는 것은 임의로 만든 단어이다.  일반 연관이란 앞에서 살펴본 association 을 

나타내며,  association 중에서도 ' 부분과 전체 ' 로 나눌 수 있는 관계를 aggregation 과 

composition 으로 묶어서 분류한 것이다.

aggregation 과 composition 은 모두 association 의 한 특별한 형태로 각각을 구분하는 

기준은  ' life cycle 이 같느냐, 같지 않느냐 ' 이다. life cycle 이란 클래스 인스턴스의 

생명 주기를 말하는 것으로 생성에서 소멸까지의 과정을 말한다. 즉, life cycle 이 같다는 것은
 
관계된 클래스 혹은 그 인스턴스의 생성과 소멸이 동시에 이루어진다는 것을 뜻한다.

쉽게 예를 들어 표현하자면 모자와 안경을 쓴 사람을 놓고 보자. 현재 이 사람을 구성하고 있는 

요소에는 눈, 팔, 다리와 같이 사람이 죽으면 같이 없어지는 요소들이 있고, 안경 모자와 같이 

바꿔 사용할 수 있는 요소들이 있다. 즉, 눈, 팔, 다리는 사람과 life cycle 이 같은
 
composition 관계 이고, 안경이나 모자는 aggregation 관계인 것이다. 이러면 이해가 좀 쉽게 

갈라나? ^-^ 


[ 소스 코드 1 ] aggregation 

사용자 삽입 이미지


[ UML ] aggregation

사용자 삽입 이미지



[ 소스 코드 2 ] composition

사용자 삽입 이미지


[ UML ] composition

사용자 삽입 이미지



◆ 상속 관계 ( inheritance ) 

[ 소스 코드 ] 

사용자 삽입 이미지


[ UML ] inheritance

사용자 삽입 이미지



 interface

[ 소스 코드 ] 

사용자 삽입 이미지

[ UML ] 

사용자 삽입 이미지


'프로그램 설계' 카테고리의 다른 글

Subversion 패턴 무시  (0) 2014.08.10
New Programming Jargon  (0) 2014.07.14
Web에서 그릴 수 있는 (Sequence Diagram) 툴  (0) 2013.04.16
Visual Svn post-commit 에 관해서  (0) 2012.07.31
마인드 맵을 활용하자  (0) 2007.11.11

http://www.websequencediagrams.com/


출처 : http://www.mimul.com/pebble/default/2010/12/18/1292676840000.html

뭔가 굉장한...


. 개요
 - ROSE 등의 툴로 시퀀스 다이어그램보다 작성 속도 몇배 빠름, 간략하게 작성해서 개발자들끼리 리뷰하는 데 도움 됨
 - 한글 지원
 - 시퀀스에 있는 기본적인 것들 도식화 할 수 있음
 - 사용법이 간략해서 도식화하기 쉬움

2. 샘플 사용 예

A->B: 인증 요청
note left of B: 패스워드 검증
B->A: 인증 응답
B->C: 쿠키 검증
C->D: redirect
note over C,D: 인증 요청 서비스로 이동
note left of C: 3rd 쿠키 검증

3. 시퀀스 다이어그램 결과

SVN을 좀 비주얼 하게 관리 하게 하는게 Visual SVN.

실제로 현재 울 회사의 소스 관리도 visual svn에 맡긴 상태입니다.

 

하지만 굳이 소스관리만 하라는 용도는 아니고....

 

울 회사에서 게임 패치 서버를 만들려고 하는데, 보통은 CDN업체에 맡깁니다..

(파일 분산 다운로드 라던가.. 뭐 그런 문제로...)

하지만, 외국 회사의 경우 그런걸 할 처지가 안되는 관계로 (몇몇 국가에선 CDN이 없다고 바이어가 박박 우깁니다....)

약간의 편법을 쓴게 svn을 이용한 패치 서버 입니다.

 

우선, 패치 파일들을 넣을 svn 서버를 설치하고

svn의 repositories 안에 파일을 넣습니다.

 

그리고 이것을 IIS6 or 7에서 관리하는 http or ftp의 주소가 링크된 폴더랑 파일 싱크를 맞추면

업데이트 파일을 commit 시키는것으로 자동으로 cdn이든 사설 IDC든 파일이 다운로드가 가능해집니다.

 

문제는... commit 을 시킬때 이것이 링크된 폴더랑 자동 싱크를 맞추는 것인데, visual svn 안에 post-commit 기능이 있더군요.

 

우선...

 VisualSVN 안의 레파토리에서 모든작업 -> Manage Hooks 를 선택합니다.

 

 

안에 보시면 Post-Commit hook 이 있습니다.

이건.. 만약 이 레파토리에 commit이 들어오면 그 뒤에 자동으로 뭔가 실행시켜주는 난입니다.

배치파일 양식으로 해주시면되고요. 

 

내용은

@echo on
"C:\Program Files (x86)\VisualSVN Server\bin\svn.exe" export [SVN의URL주소] [싱크시킬 폴더] --username [유저이름] --password [암호] --force

이외에 여러 응요이 가능하다고 보여지네요.

 

 

 

참고 사이트 http://sway.tistory.com/715

+ Recent posts