1. 쉼표(Comma, ,)

• 같은 것을 나열할 때
• 동격에 사용

  We, engineers are weak in writings.

• 구분에 사용

  In steady of lunch, we had snacks.

• 반전에 활용. 이때는 앞뒤로 넣는다.

  We quit, however, Math.

• 두 개 이상 열거할 때 마지막 and 앞에 넣는다.

  11, 12, and 13

• etc. 는 앞뒤로 넣는다.

  The school teaches Math, Physics, Chemistry, etc., besides arts.

1. 쌍점(Colon, :)

• 여러 개를 나열할 때 사용한다. 나열되는 대상은 쉼표로 구분한다.

  For example as follows: cat, dog, cow, horse, and goat

1. 쌍반점(Semicolon, ;)

   영어에서 쉼표보다 강하고 마침표보다 약할 때 쓴다. 모호성이 있지만 쉼표와 마침표를 쓰지 않는 자리에 많이 쓴다.

• 독립된 두 문장을 접속사 없이 연결할 때 쓴다.

  Engineers should know the Technical Writing; What is more, they should understand the Plain English.

• 나열되는 대상이 쉼표로 구분하기에는 길 때 쓴다.

  The officers were elected as follows: J.A. Smith, president; B.K. Williams, vice-president; L.P. Donald, secretary.

     

1. 줄표(Dash, ---)

   쉼표보다 강한 쉼으로 강조를 나타낸다.

   Push buttons --- whatever the process on which a workman is engaged --- is only the job.

      

2. 붙임표(Hyphen, -)

   복합단어에 사용한다.

• 복합명사에 쓴다.

  Vice-president, secretary-general, broken-heart

• 복합형용사에 쓴다.

  Machine-cut, rock-round, first-class

• 분수나 by에 쓴다.

  Half-time, quarter-mile, by-products

• Bi, tri, semi, demi에서는 안 쓴다.

  Bimonthly, tricolor, semiannual

• 라틴 접두사 anti, inter, intra, post, sub, super에는 안 쓴다.

  International, postmodern, submission, superpower

     

1. 괄호(Parentheses, ())

• 짧은 보충설명에 쓴다. 긴 문장은 주석이나 사이드 바로 처리한다. 괄호의 사용은 되도록 자제해야 한다. 괄호의 사용은 게으름을 나타내는 것이다. 괄호 안에 괄호는 게으름의 극치이다. 괄호를 쓰는 대신에 문장을 뒤따르게 하면 된다.

  Pneumatic(forced air) shock-absorber is more effective than mechanical one in performance(The test showed 30% higher).

  => … in performance. The test showed 30% higher.

     

1. 빗금(Slash, /)

   'and'와 'or'의 뜻을 동시에 가지고 있어 모호하다. 명확한 글을 위해 빗금은 되도록 사용하지 않아야 한다.

*** 유용한 사이트

1. 쉬운 영어(Plain English) : http://www.plainlanguage.gov http://www.plainenglish.co.uk

   미국과 영국을 대표하는 쉬운영어 사이트다. 'Federal Plain Language Guidelines(2010'을 볼 수 있다.

1. 미국증권거래위원회 핸드북 : http://www.sec.gov/news/extra/handbook.htm

   금융분야에 유용한 쉬운영어쓰기 안내이다.

1. The Mayfield Handbook of Technical & Scientific Writing

   http://www.mit.edu/course/21/21.guide/home.htm

   MIT가 학생들을 위하여 과학과 기술에 관한 글쓰기의 모든 것을 모아 놓은 곳이다. 보고서의 종류별로 예문까지 나와 있다. 문법은 말할 것도 없다.

1. David A. McMurrey's Sentence-Style Problems

   http://www.io.com/~hcexres/style/index.htm

   30년간 대학에서 기술글쓰기를 가르치고, 11년간 IBM에서 신제품 매뉴얼을 담당했던 경력의 소유자가 개설한 사이트이다. 단어와 문장 차원에서 잘못된 것을 총망라하고 있다.```````lohyyh66666

      

      

출처 : 한국의 이공계는 영어쓰기가 두렵다. - 임재춘 지음

분기와 병합은 소프트웨어 구성 관리(Software Configuration Management, SCM)라는 큰 주제의 단면임

SCM의 정의?

변경하려고 하는 작업 산출물을 식별하고, 그 산출물 간의 관계를 수립하고, 적용된 변경 사항을 제어하고, 만들어진 변경 사항을 감사 및 보고하는 등의 변경을 제어하기 위해 고안된 일련의 행위

분기 - 코드를 분기하는 가장 쉬운 방법은 복사본을 만드는 것이다. 그리고 Team Foundation Server에서 여러분이 하는 작업이 바로 파일의 복사본을 만다는 것이다. Team Foundation Server에서 파일을 분기할 때, 다른 경로에 별도의 물리적인 복사본을 만든다. 그러고 나서야 이 분기에 작업할 수 있고, 병합할 준비가 되면 원본 폴더에 변경 사항을 병합할 수 있다.

병합 - 이것은 다른 모든 분기를 취하여 하나의 코드 베이스로 다시 합치는 프로세스이다.

• 정방향 통합 : 부모 분기에 만들어졌던 변경 사항을 자식 분기에 밀어 넣기 위해 부모 분기의 코드를 자식 분기에 병합하는 것
• 역방향 통합 : 자식 분기에서 만들어진 모든 변경 사항을 부모 분기로 당겨 오기 위해서 자식 분기에서 부모 분기로 코드를 병합하는 것

기본 버전이 없는 병합 - 서로에게 직접 분기되지 않은 병합 항목의 프로세스이다. 이 프로세스를 TFS 2010에서 사용할 수 있지만, 혼란스러운 많은 충돌을 야기할 수 있고, 일반적으로 좋은 사례로 여겨지지 않는다.

릴리즈 - 몇 가지 점에서, 코드를 개발 환경에서 다음 단계로 옮기기 원할 때, 품질 보증 또는 일반적인 릴리즈를 한다. 릴리즈는 품질 보증 테스트 또는 고객에게 제공 등의 특정 목적으로 코드를 배포하는 것으로 정의한다.

일반적인 분기 전략

• 분기하지 않기 : 이 전략은 같은 코드 베이스에 지속적으로 작업하고 한 번에 하나의 응용 프로그램 버전을 출시하고 지원하는 작은 팀에게 적합하다.

  분기의 주된 이점은 코드 베이스에 병렬 개발을 할 수 있다는 것이다. 1인 개발 기업일지라도 여기 언급된 다른 분기 전략들이 도움이 될 수 있다.

     

  

     

• 릴리즈별 분기 : 각각의 소프트웨어 릴리즈는 그 릴리즈만의 분기가 있다. 릴리즈별 분기는 사람들이 특정 릴리즈에 대한 소스 코드를 레이블링하는 개념에 익숙한데다 거기서 단지 한 발짝 더 나아간 것뿐이므로 이해하기 쉽다. 특정 버전이 구동되고 있는 응용 프로그램의 코드를 쉽게 얻을 수 있고, 정해진 시간에 응용 프로그램 버전이 하나 이상 운영되어야 하는 조직에 적용하면 좋다.
• 

     

• 코드 승격 분기 : 이 분기 모델은 한 번에 하나의 응용 프로그램 버전을 가지는 통제된 환경에 아주 적합하다. 이 모델은 Test 분기에서 안정화가 일어나고 있는 동안 Dev 분기에서 개발을 지속할 수 있게 해준다. 그리고 운영 환경에 옮겨진 변경 사항에 대한 아주 높은 수준의 시각화를 제공한다.

     

  

     

• 기능별 분기 : 기능별 분기는 특정 기능을 별도의 분기로 분리시키는 데 사용된다. 그렇게 함으로써 다른 기능들과 중복되는 것을 방지한다.

  

  기능별 분기는 큰 팀이 큰 코드 베이스에서 작업하기에 적합한 경향이 있다. 작은 팀과 작은 코드 베이스들에게는 기능을 구현할 때의 격리의 어려움, 특정 기능을 만들기 위한 자원의 부족, 때때로 병렬로 작업하여 얻었던 이득을 상쇄하는 코드의 병합 문제를 떠안아야 한다는 것을 의미한다.