출처: http://blog.naver.com/kjsemiso/10132512013

127.0.0.1/redmine  의 페이지는,

redmine/app/views/layouts/base.rhtml 인 듯.

아래는 그림.

출처: Agile Web Development with Rails (3nd Edition) Beta-★4판보다 쪽수많음.pdf

활용처:

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx   process monitor 를 이용하시면 어떤 COM이 문제가 되는 지 확인할 수 있을 듯 합니다. 그러고 나면 다음 Action을 취하실 수 있을 듯. 만일, Native COM이 regisry에 등록되지 못한 것이라면, Manually 하게 등록해야 할 필요가 있을 듯 하구요.. 등록시 정상적으로 등록되지 않을 수 있습니다. 이는 Depends.exe 와 같은 Tool을 이용해서 종속된 DLL등에 문제가 없는 지도 확인하셔야 할 듯 합니다.

=============================================================

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Ruby/Rails syntax file for Textpad

출처. 이 글은 Tim Bray의 Comparing Frameworks⁴ (updated 2007/2/5) 라는 글을 번역한 것입니다. deepblue님의 웹 프레임워크 비교⁵라는 글을 통해서 원문을 소개 받았습니다.

문맥

여기서 다루는 문제는 웹 애플리케이션 개발이다. 그래서 우리는 연산 성능과 같은 일반적인 이슈를 고려하지 않을 것이다. 웹 애플리케이션은 그렇게 많은 계산을 하지 않기 때문이다. 브라우저로부터 어떤 값을 받고, 그 값을 이용해서 데이터베이스로부터 적절한 값을 가져와서 사용자에게 보고한다. 어쩌면 데이터베이스를 업데이트할지도 모른다. 기껏해야 그 정도다.

⁷⁶

확장하기

연산을 해야 한다면, 자바가 가장 빠르다는 것은 분명하다. 웹 애플리케이션을 운영하는데 있어, 최대 확장성은 아마도 거의 비슷할 것이다. 왜냐하면 웹 애플리케이션은 연산을 많이 하지 않기 때문이다. 결국 EBay는 자바로 운영되고 있고, 위키피디아나 야후! 프랑스는 PHP 기반이다. 둘 다 "충분히 잘" 확장된다는 것이 분명하다.

웹 애플리케이션의 경우라면 PHP에 가장 높은 점수를 주겠다. 왜냐하면 확장성 있는 PHP를 구축하는 것이 좀 더 쉽다고 생각하기 때문이다. 기본적으로 PHP는 아무것도 공유하지 않는 아키텍쳐를 제공한다. 말인 즉, 데이터베이스가 한계에 부딪히기 전까진 아주 손 쉽게 확장해나갈 수 있다는 뜻이다. 자바는 훨씬 더 풍부한 시스템 (richer system)이고, 여러분이 아무것도 공유하지 않는 아키텍처가 적절한지 여부를 잘 알고 있다고 가정한다. 결국 자바로 PHP와 같은 정도의 확장성을 얻어내려면, 여러분이 좀 더 똑똑해야 한다.

Rails의 경우엔, 자바나 PHP와 마찬가지로 웹 기반의 확장성 있는 애플리케이션을 구축할 수 있으리라 생각한다. 단지, 누구도 그런 일을 해낸 것을 본 적이 없다는 것이 문제이다. 이외에도 Rails에 감점을 줘야 할 이유가 있다. 대부분의 애플리케이션이 결국 약간의 연산을 하게 되기 때문이다. 이런 측면에서 Rail는 다른 대안보다 뒤처져 있다.

역자 노트

Scalability: 확장성. 사용자수의 증대에 유연하게 대응할 수 있는 정도.

개발 속도

문제는 다른 조건이 동일하다면, 얼마나 빨리 웹 애플리케이션을 개발할 수 있느냐?라는 것이다. 나는 Rails가 새로운 기준을 마련했다고 생각한다. 여러분은 몇 년이 아닌 몇 주만에, 또는 몇 달이 아닌 며칠 만에 완성된 애플리케이션에 관한 놀라운 이야기를 계속해서 들어왔을 겁니다.

이미 언급한 바 있듯이, Rails 최고의 성공작인 CRUD 지향적 개발은 매우 잘 알려져 있다. 그러나 여전히 Rails가 다른 프레임워크에게 가르쳐 줄 교훈이 많은 것처럼 보인다. Java EE가 현재 나아가는 방향은 학습이 이뤄지고 있다는 증거라고 나는 생각한다.

PHP가 처음 유명해진 것은 빠르고 더러운 (quick-and-dirty) 방식으로 웹 애플리케이션을 개발할 수 있다는 사실 때문이었다 카펫 바닥에 묻은 오점 하나를 없애려고 애쓰는 것은 아무런 의미도 없는 일이다. 빨리 개발된 상당수의 PHP 애플리케이션은 못 생겼기 짝이 없었다. Rails가 흥미로운 이유 중의 하나는 빠르고 깨끗하게 (quick-and-clean) 개발할 수 있다는 사실이다.

개발 도구

애플리케이션의 개발과 유지는 단거리 경주가 아니라 마라톤이다. 장기적인 관점에서의 성과는 개발 도구의 품질에 영향을 받는다. 행복한 개발자가 곧 생산적인 개발자이다.

당연한 말이지만 Java는 이 항목에서 독보적인 승자이다. Rails에는 TextMate가 있고 PHP에는 Zend 제품군이 있다. 그리고 PHP와 Ruby를 지원하려는 Eclipse 기반의 작업도 있다. 그러나 이 중 어느 것도 Java 개발자가 NetBeans나 Eclipse 또는 Idea로부터 얻는 포괄적이고, 통합되어 있으며, 잘 다듬어져 있으며 신속히 지원되는 환경과는 거리가 멀었다. 나는 최근에 Eclipse나 Idea를 사용해 본 적이 없다. 하지만 최신의 NetBeans 5.5를 살펴보면 웹 애플리케이션 개발을 위한 자동화 지원의 양이 어마어마한 것을 알 수 있다. 만약 내가 Java 대신 NetBeans를 도표에 넣었다면, 개발 속도 면에서 Java가 PHP와 동일하거나 그보다 나은 수준이지 않았을까 생각한다.

유지보수성

좋은 애플리케이션은 한번 개발되고 나면 놀라울 정도로 오랫 동안 제품 라인에 머물러 있기 마련이다. 다시 말해 오랜 기간 동안 유지보수가 이뤄져야 한다. 즉, 유지보수성이 중요하다. 유지보수성은 많은 것이 포함된 개념이다. 그러나 가장 중요한 요소는 객체지향성, MVC 아키텍처, 코드 가독성, 코드 크기(작으면 작을수록 좋다.)라고 생각한다.

물론 이것은 PHP의 아킬레스건이다. 그렇다, 깔끔하고 객체지향적이고 모듈화된 MVC 구조의 PHP 애플리케이션을 작성할 수는 있다. 그러나 대부분의 사람들은 그렇게 하지 못 한다. 내가 보아 온 대부분의 애플리케이션은 스파게티 HTML에 스파게티 SQL이 들어있고, 또 그것을 스파게티 PHP 코드가 감싸고 있었다. 뿐만 아니라, 객체지향과 MVC 그리고 유지보수성을 제대로 이해하는 많은 사람들은 오히려 Java나 Rails를 사용하고 있다.

나는 Rails의 코드가 Java보다 훨씬 짧기 때문에 Rails가 더 낫다고 본다. 코드의 유지보수 비용은 코드의 크기와 매우 연관성이 있다. 분명히, Java의 훌륭한 개발 도구는 중요하다. 그러나 여전히 이것 또한 Ruby와 Rails가 소프트웨어 산업계의 나머지 영역에 교훈을 주는 대목이라고 생각한다.

빼먹은 것들

Djang를 비롯한 Python 프레임워크와 .Net은 다루지 않았다. 유감스럽게도 나는 이 프레임워크들을 직접 다뤄본 적이 없다. 그리고 .NET은 오픈소스가 아니다. 왜 우리가 .NET을 사용해야 한단 말인가?

짜증나는 것들 (Irritants)

이미 여러 사람이 내게 화를 냈었다. 그들은 내가 PHP가 Java보다 빠르다라고 말했다고 생각하기 때문이다. (나는 그렇게 말한 적 없다.) 내가 Rails가 PHP보다 개발 속도도 빠르고 유지보수하기도 쉽다.라고 말했기 때문에 화를 내는 사람도 있다. (나는 그렇게 말했었고, 입장에는 변함이 없다.)

물론 예외적인 경우가 있다. Rails가 다른 것보다 빠르게 실행된다던가, Java 애플리케이션이 가장 빨리 개발된다던가, 어떤 종류의 애플리케이션에선 압도적으로 우수한 PHP 개발 도구가 있다던가, 아니면 미친듯이 복잡하게 아키텍처가 구성되어서 도저히 유지보수하기 어려운 Java 프레임워크 덩어리가 있을 수 있다.

역자 노트

Irritants: 사전에는 의학 용어로써 자극제 등의 뜻을 가진다고 나와 있다. 그러나 여기서는 짜증나게 하는 것 또는 사람을 칭하는 것으로 해석해야 한다고 생각한다.

중요한 것들

Java, PHP, 그리고 Rails 중 무엇이 최고인가?는 정말 바보 같은 질문이다. 다른 기술 영역의 질문과 마찬가지로, 이에 대한 대답도 경우에 따라 다르다이다. 내 개인적인 의견은 대부분의 웹 애플리케이션의 경우에 확장성은 훌륭한 선택의 근거가 아니라는 점이다. 만약 깔끔한 아키텍처를 구현한다면 확장성도 손에 넣을 수 있다. 깔끔한 아키텍처가 없다면 확장성도 없다.

⁹⁸

최근 몇 년 동안 PHP나 Rails 등은 우리가 생각했던 것보다 개발 속도가 중요하다는 사실을 깨우쳐 주었다. Agile/XP는 기능(function)을 좀더 빨리 전달하는 것의 사업적 가치를 가장 높게 평가하는 관점 중 하나이다. 이 관점은 특성(feature) 구현을 마치기 전까진 그 특성을 제대로 이해한 것이 아니며, 따라서 특성을 빨리 구현할수록 이해도 빨라진다고 말한다.

개발 도구의 품질은 위험을 무릅쓰고서라도 무시할 수 있는 것이 아니다. 애플리케이션 개발과 유지보수는 끊임없이 연마되어야 한다. NetBeans나 Eclipse와 같은 도구를 사용해야 장기적인 관점에서 여러분의 직장 생활이 보다 행복해질 것이다.

어쩌면 내가 반백의 25년 차 베테랑이기 때문일지도 모르지만, 나는 현실 세계에서, 그리고 장기적인 관점에서 유지보수성은 아무리 강조해도 모자랄 정도로 중요한 일이라고 생각한다.

Web 2.0이라는 거친 야생의 바깥 세상에서는 어쩌면 빨리 개발하는 것이 제일 중요한 문제일지도 모른다. 일단 시장에서 승리하기만 한다면, 야후!와 같은 기업으로 투자 받은 돈으로 모든 것을 재구축하면 되기 때문이다. 그렇지만 기업 환경에서, 개발 비용의 대부분은 제품이 출시된 후부터 발생한다는 사실을 명석한 개발자와 똑똑한 관리자가 알고 있을지 조금 의심스럽다.

어쨌든 간에 애플리케이션의 종류, 비즈니스, 그리고 인력 제약 (people constraints)에 기반하여 결정을 내려야 한다. 그것은 논쟁의 여지가 없는 사실이다.

-----------------------------------------------------------------------------

good luck의 사족

역시 툴은 자바가 쵝오 인거 같습니다. ㅎㅎㅎ

루비도 사람이 많이 모이다 보면 더 좋은 툴이 자연히 만들어 지겠죠. (그러길 바랍니다..)

이런 서핑하다 발견한 TIOBE 언어 순위표.

델파이가 아직도 살아있군요...

역시 자바가 부동의 1위 !!

TIOBE Programming Community Index for February 2012

Position Feb 2012	Position Feb 2011	Delta in Position	Programming Language	Ratings Feb 2012	Delta Feb 2011	Status
1	1		Java	17.050%	-1.43%	A
2	2		C	16.523%	+1.54%	A
3	6		C#	8.653%	+1.84%	A
4	3		C++	7.853%	-0.33%	A
5	8		Objective-C	7.062%	+4.49%	A
6	5		PHP	5.641%	-1.33%	A
7	7		(Visual) Basic	4.315%	-0.61%	A
8	4		Python	3.148%	-3.89%	A
9	10		Perl	2.931%	+1.02%	A
10	9		JavaScript	2.465%	-0.09%	A
11	13		Delphi/Object Pascal	1.964%	+0.90%	A
12	11		Ruby	1.558%	-0.06%	A
13	14		Lisp	0.905%	-0.05%	A
14	26		Transact-SQL	0.846%	+0.29%	A
15	17		Pascal	0.813%	+0.08%	A
16	22		Visual Basic .NET	0.796%	+0.21%	A--
17	32		PL/SQL	0.792%	+0.38%	A
18	24		Logo	0.677%	+0.10%	B
19	16		Ada	0.632%	-0.17%	B
20	25		R	0.623%	+0.06%	B

Just as the Japanese, Spanish and French languages are uniquely different, programming languages also have their variations, some more popular and easier to use than others. With the recent introduction of some new ones, there is a ‘war’ of modern day languages.

What’s easier and faster to use is not always the best option.

Below we highlight three of today’s most popular programming languages. Whether you’re looking to learn PHP, grab that hot new Python class, or finally learn Ruby and conquer Rails, this infographic compares how they differentiate, who uses them, and their popularity.

Think you know who reigns? You may be surprised.

------------------------------------------------------

from: http://www.neoearly.net/2465360

자. 여기 제법 인기있는 프로그래밍 언어들에 대한 인포그래픽이 있습니다.
PHP와 파이썬(Python), 루비(Ruby)의 현황과 다양한 측면에서의 비교, 또 시장에서 어떻게 경쟁을 하고 있는지를 일목 요연하게 담고 있는데요. 일단 한번 쭈욱~ 둘러보시죠.

• 신규
• 장애와 같은 이슈가 접수된 상태
• 담당자를 할당 해야함
  

In Progress (Assigned)

• 담당
• 담당자가 할당되어 조치 작업이 진행 중인 상태
• 장애 원인 분석과 대응 작업을 수행함
  

Resolved

• 해결
• 장애 원인이 판명되고 대응 작업이 완료된 상태
• 대응 결과에 대한 검증이 필요함
  

Feedback

• 피드백
• 대응 결과 검증 과정에서 문제가 발생한 상태
• 다시 대응 작업을 수행함
  

Closed

• 종료
• 대응 결과 검증 작업이 완료되었고 대응 종료한 상태
  

Rejected

• 각하
• 사양서대로 정상 동작한 경우 확인된 것과 같이 대응을 하지 않고 종료한 상태

Tracker

• Ticket의 유형에 해당
• Ticket의 유형에 따라 수행할 Workflow가 다른 것을 별도의 Tracker로 구성하면 됨
  

Workflow

• Tracker 생성 시에 어떤 Workflow를 따를 것인지 기존 Tracker를 선택할 수 있음

Tracker, Issue Type, Workflow 의 관계

• Tracker:Issue Type:Workflow = 1:1:1

참고: http://www.redmine.org/projects/redmine/wiki/RedmineIssues

related to

• Just adds a link to the other issue
  

duplicates

• Links issues so that closing one, will close the other (e.g. closing A will close B)
• For example, if issue B duplicates A:
• closing B will leave A open
• closing A will automatically close B
  

duplicated by

• Reciprocal of duplicates
• For example, if issue A is duplicated by issue B:
• closing B will leave A open
• closing A will automatically close B

blocks

• Links issues so that closing one can be blocked by an issue which is still open
• if issue B blocks A, A can't be closed unless B is.

Blocked by

• Reciprocal of blocks

precedes

• Links issues to define an "order", where A needs to be completed x days before B can be started on
• If B follows A, you can't give B a starting date equal or less than the ending date of A.

follows

• Reciprocal of precedes
• If issue B follows A (ex A ends the 21/04 and B begins the 22/04) and you add +2 day at the ending date of A, the starting and ending dates of B will be +2 too.

bugzilla에 대해서

bugzilla는 mozilla.org에 서 개발하고 제공하는 버그 추적(bug-tracking)시스템이다. 버그 트래킹 시스템은 개인이나 그룹이 어떤 프로제트를 진행함에 있어서 어느 부분에서 언제 버그가 발생했는지, 버그가 얼마나 치명적인지, 어떤 우선순위로 해결해야 하는지, 해결되었다면 누구에 의해서 언제 어떻게 해결되었는지를 DB에 남김으로써 발생된 버그에 대해서 체계적으로 관리 할 수 있도록 도와 준다.

bugzilla를 이용한 버그 관리

버그관리의 중요성

특히 팀단위로 개발을 할 경우 서로가 서로의 버그를 발견하는 경우가 있는데, 많은 경우 구두로 이러한 과정이 이루어진다. 간단하면서도 심각한 버그라면 발견시 바로 해결하기도 하지만, 많은 버그들이 뒤로 미루거나 다른일과 겹치거나 하면서 잊혀져 버린다. 그결과 버그가 계속적으로 누적되고, 발생했던 버그가 또다시 발생하고 이 버그가 해결했던 버그인지 아닌지도 헷갈리고 해결해야 되는건지 아닌건지도 헷갈리는 최악의 상황에 도달하게 된다. 때에 따라서는 소모적인 책임공방도 벌어지게 된다.

메일로 발견된 버그를 보고하면 그나마 좀 낳긴 하지만 임시방편일 뿐이라는건 사용해본 사람은 안다.

결국 프로젝트는 이런저런 자잘한 버그들 때문에 문제가 계속되고 어찌어찌해서 급하게 출시를 하더라도 완성도가 떨어지는 제품을 고객에게 내놓게 된다.

이런 문제를 해결하기 위해서 전문제품을 구입하거나, 팀이나 회사차원에서 나름대로 고심해서 시스템을 구축하기도 하는데, 솔직히 왠만한 규모의 개념있는 회사가 아닌다음에야 이런건 신경도 쓰지 않는다. 다행히도 공개되었으면서도 사용하기 편하고 강력한 버그트래킹 시스템이 있으니 바로 bugzilla다.

bugzilla의 설치

bugzilla는 영어권에서 개발된 프로그램이라서 모든 메시지가 영어로 되어있다. 그러나 한글화된 버젼이 있으니 이걸 받아서 설치하면 된다. bugzilla 한국어 프로젝트를 방문해서 최신버젼을 다운받도록 한다. 여기에서는 2.16.3 한글 버젼을 기준으로 설치하도록 하겠다.

다음은 bugzilla설치를 위한 기본 환경이다.

1. bugzilla는 웹기반 프로그램으로 Apache(12)나 IIS서버가 설치되어 있어야 한다.
   
2. Perl(12) CGI(12)프로그램이다. 반드시 Perl이 설치되어 있어야 한다.
   
3. 버그관련 정보를 DB에 저장하기 위해서 Mysql을 이용한다.
   
   

웹서버설치와 Mysql(12)설치는 여기에서 다루지 않을 것이다. 이와 관련되어서는 다른 사이트들을 참고하기 바란다.

Perl 모듈 설치

bugzilla는 상당히 방대한 시스템이며, 대부분이 perl로 이루어져 있기 때문에 perl 내부적으로 많은 모듈을 사용한다. 이런 이유로 제대로 bugzilla를 설치하기 위해서는 다음과 같은 모듈이 필수 적으로 설치되어 있어야 한다. 물론 Perl은 당연히 설치되어 있어야 하며 5.6.1 이상을 권장한다. 대부분 5.8이상이 설치되어 있으니 perl이 문제되는 경우는 없을 것이다.

1. Template(2.07)
   
2. AppConfig(1.52)
   
3. Text::Wrap(2001.0131)
   
4. Data::Dumper
   
5. DBD::mysql(1.2209)
   
6. DBI(1.13)
   
7. Date::Parse
   
8. CGI::Carp
   

다음은 반드시 필요하진 않지만 부가적인 기능을 위한 옵션 모듈들이다.

1. GD(1.10) 버그 차트기능
   
2. Chart::Base(0.99c) 버그 차트기능
   
3. XML::Parser Xml
   
4. MIME::Parser email기능
   
   

위의 모든 모듈들은 CPAN에서 구할 수 있다. 모듈을 일일이 다운받아서 컴파일하고 설치해도 되겠지만 다음과 같이 자동으로 설치할 수도 있으니 활용해보기 바란다.(필자는 그냥 일일이 받아서 설치했다)

# perl -MCPAN -e 'install "Bundle::Bugzilla"' 
 

위의 방법을 이용하더라도 GD, Chart::Base, MIME:Parser은설치가 되지 않는다.

bugzilla 설치

bugzilla를 다운받아서 웹서버의 cgi(12)디렉토리에 압축을 풀도록 한다.

그다음 checksetup.pl을 실행해서 bugzilla의 환경을 설정한다. mysql계정등의 정보를 설정하게 되는데, 간단하게 설정을 마칠 수 있을 것이다.

# ./checksetup.pl 
 

이제 버그질라 페이지에 접근하도록 한다. 만약 에러메시지를 출력한다면 서버에서 직접 ./index.cgi를 실행시켜서 제대로 작동이 되는지 확인해보자. 문제없이 작동하는데도 에러가 떨어진다면 파일권한 문제인 경우가 대부분이다. cgi파일들이 실행권한으로 되어 있는지, 각 디렉토리가 nobody권한으로 읽을 수 있도록 되어있는지 확인해 보자.

bugzilla를 설치하기 전에 간단하게 테스트해보고 싶다면 joinc bugzilla에서 테스트해보기 바란다.

bugzilla 상태 정보

버그를 관리하고 감시하기 위해서 버그질라는 발생된 버그에 대해서 심각도와 우선순위등을 할당하게 된다. 다음은 이들 버그의 상태정보에 대한 정보들이다. 아래의 용어들에 대해서 명확히 이해를 하고 있어야 버그관리가 제대로 이루어질 수 있을 것이다.

버그 심각도 (serverity)

• Blocker : 개발 혹은 테스트 작업을 진행할 수 없게 만듦
  
• Critical : 프로그램이 깨지거나, 데이터 손상및 메모리 누수가 발생함
  
• Major : 기능상의 중요한 결점이 발견됨
  
• Normal : 일반적인 문제로 반드시 고쳐야할 버그
  
• Minor : 기능상 그리 중요하지 않은 결점, 혹은 쉽게 해결할 수 있는 문제
  
• Trivial : 오탈자, 텍스트 정렬문제와 같은 외형적 문제
  
• Enhancement : 기능 및 성능개선 관련 사항
  
  

버그 처리 우선순위 (Priority)

수정해야할 버그들의 중요도와 순서를 기술한다. 프로그래머 혹은 엔지니어가 자신들이 해야할 일에 대한 우선순위를 결정할 수 있도록 정보를 제공한다.

• 즉시(P1) : 가장 먼저 처리해야함
  
• 긴급(P2)
  
• 보통(P3)
  
• 낮음(P4)
  
• 없음(P5) : 가장 나중에 처리해도 됨
  
  

버그 상태정보(Status)

  +-----------+       +-------------+        +------+       +-------------+ 
  | 버그 발생 | ----> | UNCONFIRMED | -----> | NEW  | ----> | ASSIGNED    |  
  +-----------+       +-------------+        +------+       +-------------+ 
                            |                   |                | | | 
                            |                   |                | | | 
        +-------------+     |                   |                | | | 
        | RESOLVED    | <---+                   |                | | | 
        |             | <-----------------------+                | | | 
   +----|             | <----------------------------------------+ | | 
   |    |             | <---------------------------------+        | | 
   |    |             | <---+                             |        | | 
   |    +-------------+     |                             |        | | 
   |                        |                             |        | | 
   |    +-------------+     |                             |        | | 
   +--->| VERIFIED    | ----+                             |        | | 
   +----|             | ----------------->>---------------|--------+ | 
   |    +-------------+                                   |          | 
   |                                                      |          | 
   |                                                      |          | 
   |    +-------------+             +----------+          |          | 
   +--->| CLOSE       | ----------> | REOPENED | ---------+          | 
        |             |             |          | ------------>>------+   
        +-------------+             +----------+  
 

버그의 상태를 나타낸다.

• UNCONFIRMED(승인되지 않음)
  
  최근에 데이터베이스에 등록된 버그로, 아무도 이 버그에 대해서 확인을 해보지 않았다. 즉 아직 버그인지 아닌지도 검증이 되지 않은 상태다. 등록된버그를 Confirm할수 있는 사용자는 이 버그를 승인할 수 있으며, New(새로운버그)로 하거나 해결될 경우 (RESOVED)등의 상태로 변경이 가능하다.
  
• NEW(신규버그)
  
  이 버그는 최근에 버그를 할당받은 담당자에 의해서 버그로 인정되었으며, 이에 대한 처리가 이루어져야 한다. 이 상태의 버그는 수락(accept)될 수 있으며, 필요한 경우 다른 사람에게 전달될 수(ASSIGNED) 있다. 만약 다음 단계로 더 이상 진행이 안된다면 계속 NEW상태로 남아 있을 것이고, 문제가 해결된다면 RESOLVED 상태로 전이될 수도 있을 것이다.
  
• ASSIGNED(할당됨)
  
  이 버그는 아직 해결되지 않았지만, 버그를 처리할 수 있는 적합한 사람에게 할당되어져 있음을 의미한다.
  
• REOPENED(다시 오픈됨)
  
  이전에 해결(CLOSED) 되었던 버그라고 하더라도 다시 재현될 수 있고, 혹은 담당자가 봤을때 버그처리가 명확하게 되어있지 않음을 인지할 수도 있을 것이다. 이경우 REOPENED 상태가 될수 있을 것이다. 이상태의 버그들은 ASSIGNED 혹은 RESOLVED 상태로 전이될 수 있다.
  
• RESOLVED(처리됨)
  
  처리가 되었으며, QA(품질보증)담당자의 검증을 기다린다. 이 상태의 버그들은 REOPEND, VERIFIED 상태로 혹은 CLOSED 상태로 전이될 수 있다.
  
• VERIFIED(검증)
  
  QA담당자가 버그와 처리결과를 보고 적절하게 처리가 완료되었는지를 검증하게 된다.
  
• CLOSED(닫힘)
  
  버그가 완전히 사라졌다고 간주되는 상태다. 그러나 불행히도 다시 살아나는 경우가 발생할 수 있는데, 이때는 REOPENED 상태가되어야 한다.
  
  

버그 처리결과

버그에 어떤 일이 발생했는지를 나타낸다.

• FIXED(해결됨)
  
  테스트가 완료되었으며 버그트리에 해결되었다고 표시된다.
  
• INVALID(버그아님)
  
  기술된 문제는 버그가 아니였음
  
• WONTFIX(해결불가)
  
  기술된 문제는 해결될 수 없는 버그이다.
  
• LATER(나중에)
  
  기술된 문제는 본 제품에서는 수정될 수 없다. 차후 제품에 수정이 가능할 수 있다.
  
• REMIND(기억할 것)
  
  기술된 문제는 본 제품의 현재 버젼에서는 수정할 수 없는 버그이지만, 앞으로 계속 영향을 끼칠 것으로 예상된다.
  
• DUPLICATE(중복됨)
  
  기술된 문제는 기존의 버그와 중복되었다(혹은 유사한 버그가 이미 존재함). 버그를 중복되었다고 표시하기 위해서는 기존버그 번호를 필요로 한다.
  
• WORKSFORME(파악할 수 없음)
  
  버그를 재연해 보려고 많은 노력을 기울였지만 실패했으며, 생성된 코드를 분석해봐도 왜 보고된 문제가 발생했는지를 파악할 수 없는 상태이다. 이 문제를 해결하기 위해서는 추가적인 정보가 필요하고, 그럴경우 이 버그는 다시 할당될 수 있다. 혹은 문제를 파악할 수 있을 만한 다른 개발자에게 할당할 수 있을 것이다.
  
  

플랫폼

버그가 보고된 대상 하드웨어 플랫폼 정보를 기록

OS

버그가 보고된 대상 운영체제 정보를 기록한다.

버그 등록하기

이제 버그를 등록해야될 차례다. 그런데 버그를 등록한다고 해서 바로 등록되는게 아니다. 버그를 관리해야할 제품(Products)와 구성되는 컴포넌트(Component)를 먼저 만들어야 한다. (하나의 제품은 여러개의 컴포넌트로 구성되어 있고, 각 컴포넌트 별로 버그를 관리할 필요가 있기 때문이다.)

Products메뉴를 이용해서 Products를 생성할 수 있으며, Products가 생성이 되었다면, Component를 입력할 수 있다. Component까지 만들어졌다면 버그관리를 위한 기본적인 환경이 만들어 졌다고 볼 수 있다.

이제 발생한 버그들을 그때 그때 기록하고 관리하기만 하면 된다.

• STL은 전문가가 만들어서 테스트를 거친 검증된 라이브러리
• STL은 객체 지향 기법과 일반화 프로그래밍 기법을 적용하여서 만들어졌으므로 어떤 자료형에 대해서도 적용
• STL을 사용하면 개발 기간을 단축할 수 있고 버그가 없는 프로그램

• 자료를 순차적으로 저장
• 벡터(vector) : 동적 배열처럼 동작한다. 뒤에서 자료들이 추가된다.
• 데크(deque) : 벡터와 유사하지만 앞에서도 자료들이 추가될 수 있다.
• 리스트(list) : 벡터와 유사하지만 중간에서 자료를 추가하는 연산이 효율적이다.

연관 컨테이너

컨테이너 어댑터

반복자

• 현재 처리하고 있는 자료의 위치를 기억하는 객체
• 포인터와 유사
• * 연산자 사용 가능
• ++연산자 사용 가능

Timer-Resolution.docx

Timers, Timer Resolution, and Development of Efficient Code

Updated: June 16, 2010

File name: Timer-Resolution.docx
130 KB
Microsoft Word file
Get Office File Viewers

Download

About This Download

This paper provides information about high-resolution timers and periodic timers for Windows operating systems. It provides guidelines for developers to use timers efficiently with platform power management. It assumes that the reader is familiar with concepts of periodic activity and scheduled timers.

This information applies to the following operating systems:
Windows Server 2008 R2
Windows 7

-------------------------------------

The system timer resolution determines how frequently Windows performs two main actions:

·         Update the timer tick count if a full tick has elapsed.

·         Check whether a scheduled timer object has expired.

A timer tick is a notion of elapsed time that Windows uses to track the time of day and thread quantum times. By default, the clock interrupt and timer tick are the same, but Windows or an application can change the clock interrupt period.

The default timer resolution on Windows 7 is 15.6 milliseconds (ms). Some applications reduce this to 1 ms, which reduces the battery run time on mobile systems by as much as 25 percent.

Such a dramatic reduction in battery life is not desirable, yet the effect of changing timer resolution on desktop or server systems can be equally problematic. Decreased battery life on a mobile system makes increased power consumption visible. A system that is running on AC power incurs the same increased power usage, which may not be as simple to detect. The cost increase to a facility that has several thousand systems is significant.

TimerResolution is an application to change the resolution of the default windows timer. The standard timer on Windows XP can vary between 10 and 25 milliseconds. Therefore if your code uses a timer or sleep value less than the timer resolution on your system you won’t be getting the results you expect.

The timer resolution will be globally changed while the application is running and will revert to the previous value when it is closed.

Timer Resolution	Version 1.2	Version 2.0
OS Support	Windows XP 32-bit	Windows XP 32-bit, Vista 32-bit, Vista 64-bit, Windows7 32-bit, Windows7 64-bit
Maximum Resolution	~1.0ms (depends on OS and Hardware)	~0.5ms (depends on OS and Hardware)
Command Line Functions	None	TimerResolution [-max] [-hide] -max : Sets timer period to the maximum (fastest) value -hide : Hides the GUI window
Price	Free	AUD$10.00
Download	TimerResolution.zip (7 kb)

[Download] TimerResolution.zip (7Kb) Limited Free Version 1.2

How did this application get created?

I had a need for a program to run every 5 milliseconds but I found that no matter what I did the best I could get was 12ms. I tried different values for my timer and found that a value above 12ms would also produce results with jitter up to 12ms. What was so special about 12ms? I tried a different computer and found that the magic value was 15ms… what was windows doing? Time to Google the answer.

I left the program running to see if the value changed with time or CPU load. Suddenly the program started to produce 5ms results with very little jitter! By trial and error I found that if I loaded a particular web page the program worked as expected. What was so special about this page? It turns out that it had a Flash based advertisement on it so I had my next clue. As a guess I closed the web page and started Media Player and got the same result. It seems that when an application requests a high resolution timer for multimedia purposes it changes the resolution of the timer for the entire system.

So now I had a solution but it required linking to the winmm.lib which as a programmer didn’t sit well with me since my application had nothing to do with multimedia. A little more research and I was onto the undocumented native API. Now I had the lightweight solution I was looking for. I hope you find that the program answers some questions for you. I’ve found that it can improve the performance and responsiveness of all sorts of applications.

Chromium Project uses Timer Resolution to debug battery life issue
Lag Free Counter Strike?
Nokia uses TimerResolution for LTE Network Tuning

Useful Links on the Windows Timers
MSDN – Windows Multimedia SDK Obtaining and Setting Timer Resolution
The Code Project – Timers tutorial – System

Note: This page was located at http://users.tpg.com.au/lucash/ until October 2007 when it moved to its new home here

https://code.google.com/p/chromium/issues/detail?id=46531
http://www.shoot-em.com/forum/viewtopic.php?t=3981
http://forums.guru3d.com/showthread.php?t=332395#2
http://forums.guru3d.com/showthread.php?t=327922
http://forums.steampowered.com/forums/showthread.php?t=1315790
http://forums.guru3d.com/showthread.php?p=3812261#post3812261
http://forums.guru3d.com/showthread.php?p=3770113#post3770113
http://forums.electronicarts.co.uk/battlefield-bad-company-2-pc/1273328-performance-tweaks-6.html#post18878023
http://forums.electronicarts.co.uk/battlefield-bad-company-2-pc/1273328-performance-tweaks.html
http://forums.steampowered.com/forums/showthread.php?p=19491040#post19491040