프로그래밍을 일상 생활속으로

원문보기 아래 그림과 같이 따라합니다. 속성에서 bugtraq 항목을 아래와 같이 생성합니다.  bugtraq:url   (%URL_TRAC_ENV%) /ticket/%BUGID%  bugtraq:logregex  (?:ticket: *|#)(\d+) *(?:, *(\d+))*  bugtraq:label  Ticket 위의 (%URL_TRAC_ENV%)은 실제 주소로 대체해야 합니다. (Ex: http://localhost:8000/site/testdb) 이렇게 설정한 후 커밋 메세지에 ticket:1 혹은 #1을 입력하면 이 부분이 강조되어 나타나게 됩니다.

원문보기 5명이 하는 작은 프로젝트니까 메일 연동 필요없겠지... 했는데 아무래도 있어야 될거 같다 -_- (전날 누가 뭘했고 어떤 티켓이 발급되었는지 알길이 없다!) trac.ini를 적당히 수정하면 되는데, 메일서버 구축까지도 필요없다. 다만 보내는 사람은 smtp 서비스가 되는 메일 계정이 있어야 하는데, gmail이 가장 무난할듯 싶다. [notification] smtp_always_cc = 받을 사람의 메일 주소를 적고, 복수일 경우는 쉼표로 구분한다 smtp_default_domain = gmail.com smtp_enabled = true smtp_from = 보내는 사람의 메일 주소 smtp_password = 보내는 사람의 메일 주소 비밀번호 smtp_replyto = 보내진 메일에 대해 reply를 보냈을 때 받을 메일 주소 smtp_server = smtp.gmail.com smtp_user = smtp server의 실 사용자 use_tls = ture 오.. 잘 된다. 그런데 trac+svn server의 ID와 보고자의 ID가 틀려서 좀 문제가 있다 -_-; 다음에 할땐 메일 서버를 구축해야겠다 -_-; /// gmail은 잘되는데 왜 회사 메일 서버는 되지 않을까^^;;

trac에서 제공하는 기본 리포트말고 사용자가 직접 리포트를 만들 수 있습니다. 예를 들어 설명하겠습니다. 1. 새로운 Ticket Type을 생성합니다. 2. "티켓들 보기"에서 "새로운 리포트 만들기" 버튼을 클릭합니다. 3. 여기서 리포트의 이름과 설명 , SQL 쿼리문을 작성하면 완성입니다.     SQL 쿼리 문이 좀 어렵습니다.     예로 새로 추가한 Ticket Type만 보여주는 쿼리문을 작성해 보겠습니다. SELECT p.value AS __color__,    id AS ticket, summary, component, version, t.type AS type,     (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,    time AS created,    changetime AS _changetime, description AS _description,    reporter AS _reporter   FROM ticket t   LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'   WHERE t.type IN ('기능점검')    ORDER BY p.value, t.type, time 4. 완성하고 나면 이렇게 새로운 리포트가 추가됩니다.

아래는 회사 내부에 메일을 보내려고 적었던 글입니다. 소스 저장소 및 이슈 트래커의 활용도가 높지않습니다 이러한 프로젝트가 모두 진행중인데 마지막으로 커밋한 시기가 몇주 전입니다 이것만 보면 프로젝트가 완료된 상태이거나 유지보수 상태 또는 잠정 중단된 상태로 보입니다 아니라구요? 눈에 보이는 것은 그렇습니다 뭐 처음부터 높을거라 기대하지 않았습니다 모든 사물에는 관성이 있듯이 사람의 행동에도 관성이 있습니다 자기가 이제껏 해왔던대로 무의식적으로 행동하게 됩니다 이 행동을 약간이라도 수정하려고 하면 힘이 들게되니 이전의 편한대로 행동하게 됩니다 하지만 우리가 하려고하는것은 새로운거나 힘든 것이 아닙니다 개발하는 회사는 어디나 가지고 있는 있어야만 하는 시스템입니다 이러한 시스템을 활용하지 못한다는것은 스스로가 부끄러워해야만 합니다 몇몇 프로젝트별로 개인별로 소스저장소를 운영해 왔던걸로 알고있습니다 하지만 활용법이 단지 소스를 백업하는 것밖에 없는 이상한 방식이었습니다 그리고 왜 소스를 개인별로 관리를 합니까? 소스는 회사내부에 공개가 되어야만 합니다(회사의 재산이라는 이유만은 아닙니다) 또 이런 시스템을 활용함으로써 자기가 얼마나 열심히 일하는지, 처리해야할 일이 얼마나 남아 있는지, 프로젝트 진행상태가 어떤지를 공개해야 합니다 이렇게 공개함으로써 프로젝트에 대해 조언이나 대안을 얻을 수도 있습니다 자기가 현재 뭐를 하는지 아무도 모르는 그러한 개발자가 되지 마십시요 그리고 마지막으로 비밀 프로젝트가 아닌 이상 회사 내부에서 공개는 기본입니다.

우리는 지금 회사에 소스 저장소, 프로젝트 관리 시스템을 구축하려 노력하고 있습니다 하지만 중요한 것은 이러한 시스템이 아니라 사람 즉 여러분 각자가 중요한 것입니다 어떤 회사가 직원의 근태를 얼마나 많은 커밋을 하느냐로 평가하기로 했습니다 그랬더니 나타난 현상이 하루에도 수십번을 커밋하는 일이 발생했습니다 단지 글자 한자 수정하거나 주석을 달고나서 커밋을 하는 일이 발생한 거죠 그래서 회사는 이슈 하나에 커밋 한번으로 제한하기로 했습니다 (이게 가장 올바른 일이라고 일반적으로 이야기 합니다) 그랬더니 이번엔 직원들이 고의로 이슈를 만들어 버립니다 문제가 있어 보이는 코드를 수정하지 않고 커밋해 버리는 겁니다 그러면 필연적으로 그 코드는 새로운 이슈를 발생시키게 되고 직원은 커밋 할 기회를 더 많이 가지게 된다는 겁니다 고의로 문제를 만들어 버리는 거죠 사람을 대하는 일이 어렵고도 중요한 일인 것 같습니다

최근 ClickOnce라는 .NET의 기능을 알게되었습니다 한마디로 단 한번의 클릭으로 배포를 가능하게 하자는 건데 설치 파일을 배포 서버에 올려두면 사용자가 프로그램을 시작할때 배포 서버에 접속해서 업데이트 버전이 있는지 확인하여 있으면 업데이트 시킨다는 겁니다 이전 회사에서는 업데이트 버젼이 나오면 사용자들에게 메일로 링크를 보내어 업데이트 하도록했는데 이것 보다는 훨씬 편리한것 같습니다. 업데이트 버전이 나왔는데 깜빡 잊고 메일을 보내지 못하는 경우가 종종 있었거던요 이것과 유사하게 개발자들은 개발자 머신에서 단 한번의 클릭만으로 설치 파일을 만들어 배포 서버에 올릴수 있어야만 합니다 뭐 여기에 새로운 기술을 배우거나 할 필요는 없습니다 간단한 배치 스크립트로 이러한 일을 수행할 수 있습니다 제가 유지보수해던 프로그램 중에 4개의 모듈과 3개의 라이브러리로 이루어진 것이 있었는데 7개의 솔류션 파일을 열어 컴파일하고 또 설치 스크립트를 열어 설치 파일을 만들어 배포 서버에 올리는 작업을 스크립트 파일 하나로 처리했었습니다 만일 배포 작업을 단 한번의 클릭으로 처리하지 않고 일일이 손품을 팔고 있는 당신을 본다면 얼른 일련의 작업을 자동화 시키시기 바랍니다 개발 자 스스로 편리하게 작업을 해야 합니다 우리는 능히 그렇게 할 수가 있습니다

이슈 관리 시스템(trac , mantis)에 대해서는 많이들 들어봤을 겁니다. 저도 프로젝트 당시 적용시켜 보았는데 제대로 활용은 하지 못했지만 효과는 있었던것 같았습니다. 고객들로 부터 이슈를 받게되는 경로는 대부분 메일이나 전화인것 같습니다 이처럼 이슈를 통보받게 되면 여러분은 어떻게 처리를 하십니까? 적극 대처하기 위해 바로 해당 부분을 디버깅하시나요? 보통 하나의 이슈를 처리하는데에는 몇시간에서 혹은 몇일이 걸릴수 있습니다 이럴때 전화로 통보받았을 경우는 통보받은 이슈에 대한 기억이 희미해질수가 있습니다 메일로 받았을 경우는 이슈를 처리하는데 몇일이 걸릴 경우 이슈 내용을 확인하기위해 메일을 확인해야하고 또한 하루에도 수십통오는 메일로 중요한 이슈메일은 어느듯 스크롤해서 찾아야하는 처지에 이르게 됩니다. 아~~ 물론 이슈관련  메일 보관함을 따로 만들어두면 되지 않느냐구요? 음... 그래도 되겠네요(하지만 전 그래도 뭔가 찜찜함을 지울수 없습니다) 잠시 생각을 돌려 여러분은 고객이 통보하는 이슈가 얼마나 정확하다고 생각하시나요? 아마도 "이것 누르니까 뭐가 안되는데요 혹은 이렇게하니 프로그램이 죽어요" 이런식이 아닐까요? 아닌가요? 상세한 이슈를 통보해주는 고객을 가졌다면 여러분은 행복한겁니다 누구보다 개발자 여러분이 프로젝트에 관해 잘 알고 있으니 증상에 대한 원인을 빨리 그리고 보다 정확하게 진단할 수 있을 겁니다. 따라서 고객이 통보한 이슈를 다시 재정리할 필요가 있는 겁입니다. 개발자의 관점에서 말이죠 또한 이슈를 고객들로부터 통보 받기도 하지만 개발자 스스로도 프로그램 버그나 기능향상을 찾을 수 있습니다. 머리속의 그러한 내용들이 사라지기 전에 얼른 이슈를 등록하세요. 개발에 몰두하게 되면 여러분의 머리속에 번쩍했던 칼같이 빛나던 생각들이 어느듯 사라지게 되고 나중에서야 그게 뭐였지하고 머리를 쥐어짜게 될겁니다 이슈 관리 시스템을 사용하면 프로젝트에 ...

몇년 전 "조엘 온 소프트웨어" 라는 책이 화제를 불러 모은 적이 있었습니다 조엘 이라는 사람이 불로그에 적은 글들인데 사람들의 반응이 좋자 책으로 출판한 것입니다 그 책에 보면 개발회사의 등급을 매기는 12가지(기억이 정확하지 않습니다) 기준을 제시한 부분이 있습니다 이 부분을 보고 개발자들이 자기 회사의 등급을 댓글로 올렸는데 대부분이 1~2 단계를 벗어나지 못하더군요(3단계 이상을 넘어가는 회사는 손에 꼽을만 합니다) 1. 당신의 회사는 소스관리 시스템을 사용하고 계신가요? 첫 번째 항목이었습니다. 조그마한 회사는 이 1단계도 통과하지 못한 곳이 많았습니다. 저의 경험을 이야기하자면 10년전 처음 회사에 들어갔을때 무작정 코딩만 했었습니다. '소스관리'가 뭔지도 몰랐고 제대로 백업도 조차 하지 않았습니다. 폴드를 압축하여 날짜로 파일 이름을 만드는 데 1~2분 밖에 걸리지 않는데도 이 마저도 쉽지가 않았습니다. 사장님이 열을 내며 일주일에 한번씩 꼭 하라고 하면 꼭 그때 한번 뿐이었습니다 한 달에 한번 씩 소스를 모아 CD를 구으라고도 했는데 이것도 제대로 했겠습니까? 말할때 뿐이었습니다. 지금 생각해보면 그렇게 하지 못한 것은 효용성이 없어서 그랬던 것 같습니다 날짜 별로 압축되어 있는 파일을 언제 열어보겠습니까? 하드디스크가 망가졌다거나 저 처럼 술마시고 하드를 포맷하지 않는 이상... 그렇게 리누스 토발즈가 말했던 것처럼 '남자라면 백업하지 않는다' 라는 말을 충실히 수행히 따르며 프로젝트를 수행했었습니다 뭐 솔직히 별 문제없었습니다. 거의 2명이서 프록젝트를 수행했었는데 전 모듈을 개발하고 다른 사람은 UI쪽을 개발하니 자기쪽 소스만 관리(?)했으면 되었습니다 그때는 몰랐습니다 제가 리누스 토발즈 같은 개발자가 아니라는 것을... 그러다가 한 프로젝트를 하게 되었는데 여전히 개발자는 2명(예전과 다른 사람) 이었지만 같은 소스를 건드릴수 밖에 없는 상황이었습니다 ...

Creating Windows Start Menu shortcuts To create folders and shortcuts in the Windows Start Menu , right-click on File System on Target Machine , and select Add Special Folder and then Custom . VSI will create a new sub-folder called NEWFOLDER . Rename this folder in ProgramMenuFolder . Write folder name exactly as shown. This is a Windows Installer constant, used to identify that particular folder. This new folder is the Program Files folder in the Start Menu . Now, you can add a new sub-folder under ProgramMenuFolder and name it as you like, adding here shortcuts as shown before.

프로그램에 락을 걸 일이 생겨났다. 하드웨어 락을 걸면 쉬울텐데 그 정도는 아니고 프로그램의 실행 날짜를 제한 해 달라고 한다. 그래서 파일(license.lic)을 가지고 락을 걸리고 결정을 했다. 요구 사항은 아래와 같다. 1. license.lic 파일이 없으면 프로그램을 실행 할수 없게 한다. 2. 지정한 날짜를 넘어서는 프로그램을 실행 할수 없게 한다. 3. 사용자가 시스템 날짜를 되돌렸을때 인식하여 프로그램을 실행 할수 없게 한다. 음.... 1.번 문제는 사용자가 프로그램을 실행하기 위해서 license.lic 파일을 받아야만 한다. license.lic 파일에는 최근 실행 날짜/종료날짜 이런식으로 적도록 한다.(물론 내용은 암호화 한다.) 최근 실행날짜는 프로그램이 실행때마다 업데이트 하도록 하고 시스템 날짜와 비교하여 시스템 날짜가 최근 실행 날짜보다 이전의 날짜면 시스템 날짜를 되돌렸다고 인식하도록 한다.(3.번 문제 해결) 시스템 날짜와 종료 날짜를 비교하여 시스템 날짜가 종료 날짜를 넘으면 프로그램을 실행 할수 없도록 한다.(2.번 문제 해결)

소프트웨어 개발 프로젝트의 실용주의 선언.doc 품질 좋은 소프트웨어 개발에 전념할 수 있는 개발 프로세스를 갖추고 있습니다.doc

연역적으로 설계하고 납적으로 검증하라. 구글쪽으로 옮겨가야 할까봐요 구글쪽이 훨씬 편하네요ㅜㅜ

dusttin's Notes | dusttin http://dusttin.blog.me/10715315 배치파일 작성 명령어 9인방 배 치 파일은 파일 안에 기록되어 있는 명령의 순서대로 실행됩니다.가장 대표적인 것이 부팅에 이용되며, 컴퓨터의 루트 디렉토리에 위치하고 있는 Autoexec.bat 파일입니다. 그런데 만약 배치 파일의 실행의 순서를 순차적이 아닌멀티부팅용 Autoexec.bat 처럼 사용자 마음대로 정하고 싶다면 배치파일에 제공되는배치명령어의 용도를 알고 있어야 합니다. 1. CALL 현재 실행중인 배치 파일을 종료하지 않고 필요한 다른 배치파일을 호출하여 실행한 다음 원래의 배치파일로 다시 돌아오려고 할 때 사용됩니다. ◇ 사용법 : Call [drive:]\[경로]\<배치파일명>[.BAT] ◇ 예 : Call c:\bats\sample.bat 어떤 배치 파일을 실행하는 도중에 경로 C:\bats 에 있는 sample.bat 파일을 실행한 다음 다시 원래의 배치파일로 돌아옵니다. 2. CHOICE 배치 프로그램 내에서 사용자의 선택을 묻기 위해 사용됩니다. 배치 파일 제작자가 설정한 물음을 출력하면서 지정된 키 입력을 기다립니다. 이 명령은 배치파일 내에서만 사용 가능합니다. ◇ 사용법 :choice [/C[:]문자열][/N][/S][/T[:]기본키,대기시간][메세지] ◇ 옵션 - /C[:]문자열 : 사용자가 선택할 수 있는 키목록을 [] 괄호 내에 ', ' 로 구분하여 출력하고 /C 스위치를 사용하지 않으면 기본적으로 YN이 사용됩니다. - /N : 프롬프트를 출력하지 않도록 합니다. - /S : 사용자의 입력에서 소문자, 대문자를 구분하도록 합니다. - /T[:]기...

이번 작업을 하면서 등고선 그리는 일이 필요하게 되었습니다. 며칠동안 인터넷을 뒤져 가면서 등고선 그리는 루틴( 소스이면 좋겠다고 생각 함)을 찾아봤지만  이거다 싶은 것을 발견하지 못했습니다. 그나마 겨우 찾아낸것이 Kriging 알고리즘으로 등고선을 그린다는 것이었습니다. Kriging 알고리즘은 그리 복잡하지 않은 몇개의 식으로 표현되어 있었는데 이것을 어떻게 프로그래밍해야 할지 알수가 없었습니다. 다시 인터넷을 뒤지던 중 나의 상황에 맞는 루틴을 코드구루에서 찾을 수 있었습니다. 이것은 아주 단순했습니다. 저의 경우는 1mm 간격으로 놓여 있는 그리드의 측정점(x , y , z)들을 미리 알고 있는 상태였습니다. 아래 이미지는 측정 데이터들의 일부분을 캡쳐한 것입니다. TOP에서 봤을때 ISO로 봤을때 이 측정점들로 삼각망들을 형성할 수 있습니다. min z ~ max z의 간격을 7등분하였고 각 등분된 간격에 무지개 색상을 각각 할당하였습니다. 등분된 간격에 들어가는 삼각망을 할당된 색상으로 칠하기만 하면 되는 것입니다. 좀더 자세히 생각해 보면, 최초의 삼각망은 LEVEL( min z ~ max z를 등분하는 값)에 의해 분할이 일어나게 됩니다. 이렇게 분할이 일어날때 삼각망은 2개의 다각형으로 분할되는데 이 다각형을 다시 삼각형으로 나누어줍니다. $N$개의 정점을 가지는 다각형은 $N-2$개의 삼각형으로 나눌 수 있습니다. $N-1,i,i+1$의 3개의 정점을 가지고 삼각형을 생성한다고 생각하면 됩니다. $(i = 0,...,N-3)$ 이러한 작업은 모든 삼각망에 대해 모든 LEVEL에 걸쳐 수행하게 됩니다. 결과로 생기는 모든 삼각망들은 모든 LEVEL에 의해 나누어지게 됩니다. 삼각망들을 2D로 내려 할당된 색상으로 칠해주면 됩니다. 여담으로 소스포지에 보면 FMesh라는 프로그램이 있는데 이 프로그램을 분석해보면 3D 좌표를 가지고 먼저 삼각망을 구성하고 나서 앞서 이야기한 내용대로...

The Joel Test: 나은 코딩을 위한 12단계   -   06/07/27 14:00 글 : Joel Spolsky 번역 : B.K. Chung 정봉겸 감수 : Jang Han Goo 구장한 2000년 8월 9일 SEMA 에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다. The Joel Test                    Source Control(소스 컨트롤)을 사용하십니까? 한번에 빌드를 만들어낼 수 있습니까? daily build(일별 빌드)를 만드십니까? 버그 데이타베이스를 가지고 있습니까? 새로운 코드를 작성하기 전에 버그들을 잡습니까? up-to-date(최신) 스케줄을 가지고 있습니까? spec(설계서)를 가지고 있습니까? 프로그래머들이 조용한 작업환경을 가지고 있습니까? ...

++ 숙련공에서 마스터로   -   06/07/27 13:40 " 쉬운 정답 같은 것은 없다. 도구든, 언어든, 운영체제든, 프레임워크든, 방법론이든 상관없이 최고의 해결방안 같은 것도 없다. 오직 특정한 환경 조건의 집합마다 각 집합에 가장 적절한 시스템들이 있을 뿐이다." - 앤드류 헌트, 데이비스 토머스 XX 회사의 프로그래머 P모씨, 그는 경력 5년차의 숙련공이다. 볼것, 못볼것 가리지 않고 봤으며, 해보지 않은 노가다가 없다. 이제는 어떤 노가다라도 아무생각없이 뚝딱뚝딱 해치울 수 있는 경지에 올랐다. 그러든 어느날, 수년간 동고동락하면서 노가다를 했던 사수 M모씨가 진급하면서 "안뇽! 나 이젠 개발 안해" 라는 말을 남기고 관리자의 세계로 차원이동해 버렸다. 혼자 남겨진 P모씨, 3년차와 신입 직원을 데리고 개발을 책임져야 하는 상태다. 고민하던 P모씨가 내린 결론은 개발 프로세스를 정립하는 것이다. 그러나 도무지 어디서부터, 무엇을, 어떻게 시작해야하는지 막막하다. 주위엔 천상 노가다꾼들이라 조언을 해줄 사람도 없다. 결국 why? 라는 물음에 답할 수 없다면, 시작도 할 수 없다는 사실을 깨닫는다. 프로젝트에 가장 잘 아는 사람은 P모씨 자신이며, why? 라는 물음에 답할 수 있는 사람도 P모씨 밖에 없다는 것을 안 것이다. 다행이 P모씨는 답을 할 수 있었다. 이는 몇달전에 일어난 악몽같은 사건에서 시작한다. 몇 달전, XX회사의 YY제품은 다수의 플랫폼에 포팅을 진행하면서 안정성을 획득하였다. 출시 및 배포한 이후에 6개월 이상 이상없이 작동중이다. 비록 고객의 잦은 요구사항 변경으로 코드가 조금 꼬인점은 있지만, 더이상 고객은 기능에 대해선 불평하지는 않는다. 그러던 중, 윗선에서 C8플랫폼에 제품을 포팅하라는 지시가 떨어진다. C8플랫폼은 ...