Yonghwan's Blog

얼마 전부터 작은 오픈소스 프로젝트를 하나 (업무로써) 진행하고 있는데^[각주:1], 공부도 할 겸, 프로젝트의 웹 부분을 Django 프레임웍을 사용하여 작성하고 있다. django는 뭐랄까... 아쉽게도 ruby on rails를 처음 접했을 때 만큼의 감동은 없는데, 나름대로 단순한 면도 있고 쓸만 하다는 느낌이다. (MVC 관점이 좀 애매하기는 하다.)

그러던 어느 날, 문제가 생겼다! 그것도 하필 중간 점검을 코앞에 두고 말이다.^[각주:2] (항상 "밀려 하는 숙제" 스타일이 문제다.) 잘 동작할 것으로 예상했던 부분이 안돌아 가는데, 곰곰히 생각해보니... nested request! 이것이 문제였다. 문제의 부분은 사용자-시스템 간의 요청 처리 내부에 시스템-시스템 간의 요청이 하나의 단계로써 포함되어 있었던 것이다. 다시 말해서, 사용자의 요청(ㄱ)을 완료하기 위해서는 내부적으로 또 하나의 웹 요청(ㄴ)이 발생하게 되는데, 그것(ㄴ)이 처리 지연에 빠지는 현상이 발생했다. 처리 지연에 빠지는 이유는 바로 앞 선 요청(ㄱ)에 의하여, 이 요청의 수행이 끝날 때 까지 웹서버의 동작이 Blocking 되어 있었던 것. 데드락이다. (ㄱ)은  (ㄴ)의 수행이 필요한데 (ㄴ)이 수행되기 위해서는 (ㄱ)이 먼저 끝나줘야 하는 것. ... 지금껏 잘 사용해오던 django의 내장 (test용) 서버가 다중 요청을 지원하지 않는 것이다. (이 부분은 좀 더 확인이 필요하다.)

사실, 처음부터 내 잘못이다. django의 문서를 보면 명시적으로, "이 기능은 실무 환경을 위한 것이 아니에요. 우린 웹 개발 프레임웍을 만드는 중이지 웹서버는 관심이 없답니다."라고 말하고 있다. 어쨌든, 다음의 연결은 이와 관련하여 django를 다른 전문 웹서버와 연결하는 방식을 설명하고 있다. (이 부분도 rails에 비해서 좀 떨어지게 느껴지는, 또는 낯설은 부분 중 하나다.)

관심있는 구성 중 하나는 경량 웹서버인 nginx를 이용하는 방법. 다음은 우분투 문서 중, byteflow blog 엔진 설치, 그 중 django(FastCGI) + nginx 구성의 설명이다.

byteflow blog engine - Ubuntu Wiki

Byteflow is a blog engine, written on Python, using Django. Why should you choose it over competitors? It has very clean codebase and developers, which are struggling to keep it so. It has a lot of cool features, which you can't get in other blog engines or will get with difficulty (consider feed by union of tags, eh?).

# Ubuntu + nginx + FastCGI installation guide on Ubuntu wiki
# Debian + apache2 + mod_python. Installation and setup guides by Oleg Leschinsky.
# lighttpd + fastcgi installation guide from Benjamin Smith
# Installing byteflow on dreamhost by William Stearns
# ByteFlow on CentOS 5 with Apache, mod_wsgi and MySQL by Michal Ludvig

django 공식 문서. 일단은 공식 문서의 apache+django(fastcgi mode) 방식을 적용하여 문제(다중 요청 처리)를 해결했다. 이렇게 단순 간단한 것을... 처음엔 원인을 떠올리지 못하고 심지어는 별도 Job Queuing 모듈까지 만들었다는...

Django’s chock-full of shortcuts to make web developer’s lives easier, but all those tools are of no use if you can’t easily deploy your sites. Since Django’s inception, ease of deployment has been a major goal. There’s a number of good ways to easily deploy Django:

교훈:

• "밀린 숙제 방법론"을 버려라
  
• "실전을 통한 학습"은 허상이다.
  
• 문서와 저자의 의도를 받아들여라.
  
• 뭔가 분명히 있다. 만들기 전에 다시 한 번.
  

프로젝트 관리 > 버전관리 > 서브버전 저장소 사본 만들기 (Repository Replication)

지금의 업무 환경이 마땅치 않아서 이기고 하고 또 한편으로는 작은 오픈소스 프로젝트를 열어보고자 하는 생각도 있고 하여, 요 얼마간 서브버전을 지원하는 공개 프로젝트 호스팅 서비스를 찾고 있었다. 실은 trac을 지원하는 무료 호스팅 서비스를 원했으나 적당한 것을 찾지 못했다. (도와주세요^[각주:1])

프로젝트 호스팅 서비스를 찾다보니 고민하게 되는 것이, 만약의 사태에 대한 대비 또는 써보니 서비스가 성에 차지 않는다든지 하여 이사하게 될 상황에 대한 대책 마련이다. (직접 운영하는 저장소는 단순히 저장소를 묶어 보관하는 것 만으로도 충분한 백업 또는 이전 대책이 서기 때문에 아직까지 이런 필요성을 느끼지는 않았었다.)

서브버전이 제공하는 기능 중에 저장소의 읽기 전용 사본을 만드는 기능이 있다. 기능의 본래 취지는 말 그대로 읽기 전용 사본을 만드는 것이지만 (대부분의 오픈소스 프로젝트를 보면, 커밋 권한을 가진 개발자에 비하여 엄청나게 많은 수의 사용자들이 읽기 전용 권한으로 소스를 받아가게 되는데, 이런 부하를 분산시킬 수 있는 또는 지역으로 미러링 할 수 있는 기능이 필요하다.) 이 기능이 나의 백업/이전 용도에도 적절히 사용될 수 있을 것 같다.

과정은 다음과 같다.

$ mkdir /svn-mirror
$ svnadmin create /svn-mirror/my-project
$ cd /svn-mirror/my-project/hooks
$ cp pre-revprop-change.tmpl pre-revprop-change
$ vi pre-revprop-change
$ chmod 755 pre-revprop-change
$ svnsync init file:///svn-mirror/my-project svn+ssh://repository/var/svn/my-project
sio4@repository's password: 
리비전 0의 복사된 속성
$ svnsync sync  file:///svn-mirror/my-project
sio4@repository's password: 
커밋된 리비전 1.
리비전 1의 복사된 속성
$ svn log file:///svn-mirror/my-project
------------------------------------------------------------------------
r1 | sio4 | 2008-04-08 23:02:46 +0900 (화, 08  4월 2008) | 2 lines

prepare project repository.

------------------------------------------------------------------------
$

1. 먼저 미러를 보관하기 위한 디렉토리를 만들고 그 안에 빈 저장소를 만든다. (저장소를 복사하는 것이 아니라 변경점을 동기화하는 것이 이 사본 만들기 기능의 방식이기 때문에 저장소 생성은 별도의 작업으로 진행된다.)
2. 만들어진 빈 저장소에 pre-revprop-change 후크를 설정해준다.
3. 프로젝트의 주 저장소와 연결하기 위하여 `svnsync init` 명령을 수행한다.
4. 연결된 사본을 `svnsync sync` 명령을 수행하여 동기화한다.
   

이상의 간단한 단계를 거쳐 이제 로컬에 저장된, 그리고 주 저장소와 동일한 복사본을 얻었다. 물론 읽기 전용 사본으로써 활용하기 위해서는 보다 정교한 설정이 필요하겠지만 나의 용도인 저장소 백업을 위해서는 이 정도면 충분하리라고 생각한다. 음... 글쎄... 정말 이사갈 일이 생기면 방 빼는 건 쉬웠는데... 다시 들여놓는 것도 그렇게 간단할까?

한참 전에 글을 시작했다가 덮어두고, 이제야 다시 써본다.

남에게 일을 맡겼다. 언제 검수해야 하는가?

요 근래 나를 눈코 뜰 새 없이 바쁘게 만들었던 이 프로젝트의 상당 부분이 다른 회사에 의하여 개발되고 있다. 그 중에는 자사 솔루션의 고객화 버전 제공 형식의 것도 있고 고객 요구사항에 의한 전면 개발 형식의 것도 있다. 괭장히 급한 일정으로 진행되었던 프로젝트였고, 초기 작업의 상당부분을 날림으로 또는 생략해버린 프로젝트였기에 시작부터 걱정이 태산이었던... 정말 슬픈 프로젝트였지만 프로젝트의 핵심 부분 중 하나를 맡은 그 회사는 그 시작부터 남 달리 믿음직한 인상을 줬었기에, 슬픈 프로젝트의 일부분이나마 믿음직한 구석이 있어서 다행스럽게 생각했었다.

오... 그런데 이게 왠 일인가! 믿던 도끼에 발등을 찍혔다. 나름대로 요구사항 분석부터 설계 문서 작성 등등... 나름의 형식과 절차에 맞는 초기 작업과 그 유명세까지 더해서 믿음을 줬던 그들이 왜 그런 결과물을 만들어낸 것일까...

결론은 하나! 내가 나쁜 놈이다. 더 꼼꼼해야 했고 더 의심했어야 했고 더 부지런했어야 했다. 그리고 시작부터 끝까지! 쉴 새 없이 확인했어야 했다. 프로토타입 단계에서의 느슨함도, 구조의 작은 미흡함도 시험용 코드라고 눈감아주고 결과물은 아니라고 양보해서는 안되는 것이었다.

이제와 후회하면 무엇하리... 검수는 머리 끝에서 발 끝까지, 시작부터 끝까지!

코드리뷰에 대한 좋은 글이 있어서 인용한다. 그런데, 한 문장도 빼놓기가 아까운게... 잔뜩 인용해버렸다. :-)

BSBlog » Blog Archive » The Power of Code Review

For the most part, reviewers are not responsible for ensuring correct code function: unit tests are much better suited to that task. What reviewers are responsible for is much more “social”, and typically does not require a detailed line-by-line analysis of the code to perform a review. In many cases, important parts of the review process should happen before a coder starts working on a patch, or after APIs are designed but before implementation.

There are some important side effects of the review process that are also beneficial:

• More than one person knows every piece of code. Many Mozilla modules have grown a buddy system where two people know the code intimately. This is very helpful because it means that a single person going on vacation doesn’t imperil a release or schedule.
• Reviewing is mentoring. New hackers who are not familiar with a project can be guided and improved through code review. Initiall, this requires additional effort and patience from the reviewer. Code from inexperienced hackers deserves a much more detailed review.
• A public review log is a great historical resource for new and experienced hackers alike. Following CVS blame and log back to bug numbers can give lots of valuable historical information.

There can’t really be general guidelines on how much time to spend reviewing. Some experienced hackers may spend up to 50% of their time doing reviews (I typically spend two days a week doing design and code reviews and various planning tasks). This can be hard, because coding feels much more productive than reviewing.

나의 지론, 휴가 가고싶으면 잘 하란 말이다.