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

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. 완성하고 나면 이렇게 새로운 리포트가 추가됩니다.

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

x64에서 ADO를 사용하려다 에러가 날때는 아래와 같이 platform target을 x86으로 맞추어 주세요

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

원문 보기 파이썬 임베딩을 하면서 가장 유용하게 사용되는 함수 중에 하나가 PyErr_Print()라고 하면, 대부분 공감 하시리라 믿습니다. PyErr_Print()를 통해 우리는 파이썬 모듈을 로드하고 실행하는 중에 발생하는 모든 에러들과 예외 들에 대해 성실하고도 친절한 답변을 받게 됩니다. 그런데 가끔은  PyErr_Print()가 보여 주는 메시지들을 보지 못하는 환경에 놓일 때가 있습니다 . 예를 들자면 윈도우의 서비스 프로세스나 리눅스의 데몬 프로세스 같은 경우지요. 앞에 말한 두 종류의 프로세스들은 프로세스의 특성상 stdout 이라던지 stderr과 같은 표준 출력을 지원하지 못하도록 막아 버리는 경우가 대부분 입니다. 그리고 우리의 PyErr_Print()함수는 stderr을 통해서 메시지를 보여 주도록 되어 있는데, stderr이 막혀 있으니 어디로든지 메시지를 전달 할 수 있는 방법이 없는 것 입니다. 그럼 이런 프로세스들은 아예 볼 방법이 없는가라고 물으 실지도 모르겠습니다. 당연히 방법이 있지요. 방법이 없었으면 포스트 시작 하지도 않았습니다. 간단하고 일반적 방법으로는  stderr의 출력을 파일 출력으로 리다이렉션 하는 방법 이 있습니다. 그리고 가끔은 메시지 박스등에 출력 해주기 위해서 특정 버퍼로 출력을 원하시는 분들도 있습니다. 이 포스트에서는 첫 번째 방법에 대해서만 설명할 것입니다. 두 번째 방법에 보다 더 흥미를 느끼는 분은 ' how to get string printed by PyErr_Print( ) ?"를 추천 드립니다. 자, 이제 부터 ' PyErr_Print()의 메시지를 파일로 출력 하는 방법 '에 대해서 살펴 보도록 하겠습니다. 기본 개념은 간단 합니다.  sys.stderr에 우리가 출력하길 원하는 파일의 파일 객체를 넣어 주기만 하면 됩니다 . 그러기 위해서는 먼저 파일 객체를 만들어 주어야 하겠지요. 아래의 코드를 한번 살펴 보도록 하겠습니다 :...

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

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

보통 아래와 같이 폼이 시작되는데, Application.Run(new MainForm()); 프로그램 동작 중에 MainForm의 레퍼런스를 구하는 방법: Application을 통하여 열려진 폼들에서 첫번째 폼을 구한다. MainForm mf = (MainForm)Application.OpenForms[0]; 이걸로 끝 ㅎㅎ

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

가장 쉬운 방법은 TOW(trac on window)를 설치하는 것입니다. TOW를 설치하면 소스 저장소와 이슈 관리 시스템을 통합할 수 있습니다. 1. TOW 설치하기 아파치와 svn server가 설치됩니다. 2. install Silvercity for syntax highlighting(optional) 3. project 생성하기 소스 저장소와 이슈 관리 시스템에 같은 이름으로 프로젝트를 생성합니다. add-project [project name] ex) add-project TEST 4. 사용자 추가하기 add-user.bat [user] [password] ex) add-user.bat humkyung humkyung 5. admin 설정 trac-admin  [$ENV]  permission add  [USER_ID]  TRAC_ADMIN ex)  trac-admin TEST  permission add humkyung  TRAC_ADMIN 6. conf/trac.ini 수정하기     프로젝트 생성시 template을 이용하기 때문에 기본적으로 HelloTOW 프로젝트에 대한 값  들이 사용됩니다.     이 부분을 새로 생성한 프로젝트에 맞게 수정하는 일이 필요합니다. 7. trac 싱크 맞추기    trac의 configuration이 변경되었기 때문에 다시 싱크를 맞추어야 합니다.    trac-admin [$ENV] repository resync * 8.   trac 서비스로 실행하기 서비스 멈춤 : net stop TOW 서비스 실행 : net start TOW