코드레이스(팀 단위 “실시간” 프로그래밍 경진 대회) 라는 타이틀에 걸 맞게 대회 진행 중에 요구사항을 추가하기도 하고(자신의 팀에게 유리한 요구사항으로 다른 팀을 공격(?) 한다), 관중을 대상으로 바둑이나 스포츠 중계와 같이 해설자를 둔 특이한 진행방식으로 관심을 갖았던 공개 SW 개발자 경진대회가 지난 11월 26일 열렸습니다.
대회 전에는 과연 이런 진행방식이 비록 흥미롭긴 하지만 실제로 적용될 수 있을까하는 의구심이 들었습니다만 해설자로 참가한 OpenLook의 장혜식님의 후기를 보니 재미있었을 것 같다는 생각이 듭니다. 관람하지 않은게 후회되는 군요.

특이한 것은 장혜식님의 말데로 동적언어들(루비에 기대를 많이 했었습니다만) 이 1위 C++, 2위 C#에 밀렸다는 것인데 아무래도 참가팀 수가 적어서가 아닐까 하는 생각을 해봅니다.

개인적으로 아쉬운 점은 각 팀에서 (다른 팀 공격을 위해) 내 놓은 요구사항들이 그다지 공격적이지 않아 보인 점, 개발 환경이 리눅스만으로 한정되어 있어 윈도우에만 익숙한 많은 수의 개발자들이 참여하긴 힘들지 않았나 하는 생각을 해봤습니다.

대회가 자리를 잡아 폭넓은 개발자 층의 참여와 관심을 갖을 수 있는 대회가 되길 바랍니다.

InMemoryDatabase (by Martin Fowler)

데스크탑 어플리케이션에서 비교적 많은 양의 데이터를 저장하고 복잡한 질의를 수행하는 일은 데이터 구조 및 접근 알고리즘, 캐싱, 인덱싱등 다량의 코드를 고안해 내야하는 힘든 일입니다.
이 때 IMDB(In-Memory DB)를 이용한 구현 방식은 현명한 선택일 수 있습니다. 특히 최근 PC의 메모리 가격 하락과 CPU 성능 향상은 데스크탑 어플리케이션에서 IMDB의 사용 가능성을 높이고 있습니다.

Ruby on Rails 홈페이지에는 Ruby on Rails를 소개하기 위해 Ruby on Rails를 사용하여 15분만에(헉!) 블로그 엔진을 만드는 화면을 캡쳐한 동영상으로 된 소개자료를 제공합니다. Ruby on Rails이 어떤 식으로 작성되는지 한번에 알 수 있게 해줄 뿐만 아니라 꼭 해봐야 겠다는 생각을 갖게 할 정도로 환상적입니다.

테스트 주도 개발의 부록 CD에는 역자가 본문의 내용 데로 직접 이클립스를 띄워 페어 프로그래밍하는 동영상이 포함되어 있습니다. 이 동영상에는 책 본문에 수 많은 페이지에 걸쳐 작성되있는 내용을 수십분의 동영상으로 간단히 보여줍니다. 조악하게 제작된 동영상이지만 활자로 읽는 것 보다 동영상으로 보는 것이 훨씬 더 쉽게 오랫동안 몰입할 수 있고 더 빠르게 이해할 수 있었습니다. (주의: 동영상이 책의 내용을 읽은 혹은 읽을 것을 가정하기 때문에 책 내용을 완전히 포함하고 있지는 않습니다. 동영상만 봐서는 안됩니다.)

코딩하는 과정을 활자로 나타내기 위해 수십 페이지에 걸쳐 장황하게 늘어 놓은 책 또는 인터넷 문서들을 많이 접하게 됩니다. 이런 경우 쉽게 몰입하지 못하거나 그 분량에 질려 자세히 읽지 않고 훌터만 보게 되는 경우가 많습니다. 이런 경우 간단하게 제작된 동영상을 같이 제공하면 어떨까요? 저자(역자)들이 한번쯤 심각히 고려해 줬으면 합니다.

Exploring the C++ Unit Testing Framework Jungle (via Trax’s Mind)

C++ 개발에서 사용할 수 있는 유닛 테스팅 프래임웍 6종(CppUnit, Boost.Test, CppUnitLite, NanoCppUnit, Unit++, CxxTest) 를 7가지 기준으로 서로 비교했습니다.
매우 자세히 장단점을 기술해 놓았으므로 C++ 테스팅 프래임웍을 선택하기 전에 참고하면 많은 도움을 받을 수 있을 것입니다.

닷넷 프래임웍 1.1 또는 1.0으로 만들어진 소스를 2.0으로 컴파일하는 경우, 빈도수는 적지만 API의 signature가 변경되어 컴파일 오류를 발생하거나 API의 구현이 변경되어 오동작을 일으킬 가능성이 있습니다.
이 문서, Breaking Changes in .NET Framework 2.0 (via Brad Adams) 는 닷넷 프래임웍 2.0으로 마이그래이션 할 때 이런 오류를 발생시킬 수 있는 닷넷 2.0의 변경내용을 기록하고 있습니다.
Signature가 변경되어 컴파일 오류가 발생하는 경우라면 쉽게 수정해 낼 수 있겠지만 API 구현 변경으로 인해 오동작하는 경우에는 쉽게 알아채기 어려운 문제가 될 수 있습니다. 1.0 또는 1.1로 작성된 코드를 2.0으로 마이그레이션하기 전에 한번쯤 봐둬야 할 듯합니다.