지난 토요일에 Framework 2.1이라는 행사에 다녀왔다. Framework 2.1은 웹 개발 프레임워크의 대안을 모색하기 위한 행사이고, 대안언어축제에서 파생된 행사인 듯 하다. 이번 행사는 RubyOnRails와 Django를 각각 소개하고, 그 둘을 비교하는 패널 토의를 하고, 다음번 행사에서 소개할 TurboGears와 Seaside를 간략하게 소개하는 형식으로 진행되었다.

행사장은 NCsoft에서 지원해주었는데, 참석한 인원이 꽤 많아서 행사장이 상당히 좁았다. 하지만, 이런 행사를 지원해주는 게 어딘가. 개발자들, 특히 뛰어난 개발자일 수록, 연봉이나 복지만으로 회사를 선택하지는 않는다. 치열해져가는 경쟁 속에서 뛰어난 개발자를 고용하기 해서는 이런 투자도 어느 정도 필요하다고 생각한다. NCsoft 외에도 어느 정도 업계에서 성공한 회사들이 개발자 커뮤너티를 지원해주는 문화가 앞으로는 널리 정착되었으면 좋겠다.

기조연설 – 이만용 님

기조연설은 이만용 님이 해주셨는데, 역시 연륜이 있으신만큼 (그렇게 보이시는 만큼) 언변도 좋으셔서서로 모르는 개발자들이 모인 자칫 딱딱할 수 있는 자리를 재미있고 부드럽게 만들어주셨다.

이만용님은 APM, Python CGI, Zope 등을 시도해보시다가 Django와 TurboGears들 중 최근 TurboGears를 선택했다고 하셨다. ‘Write-only code’라는 말로 웹 개발의 현주소를 표현하셨다. 애자일 프로그래밍 언어와 MVC가 필요하다는 언급을 하셨다.

RubyOnRails – 황대산

첫번째 세션은 황대산님의 RubyOnRails 세션이었다.

기본적인 튜터리얼을 진행하시고는 migrate, breakpoint, association, routing 등의 약간의 고급 기능도 설명해주셔서 재미있게 들을 수 있었다. 그 중에 migrate가 가장 흥미로웠는데, 대부분의 웹 어플리케이션들은초기에 DB 셋업이라는 벽을 뛰어넘어야하기 때문에, 대단히 사용하기가 어렵기 마련인데, migrate를 사용해 각 버전간의 변경사항에 대한 transaction을 ruby code로 기술해주는 것만으로, 초기 DB 셋업 뿐만 아니라 버전간 migration (원래의 목적으로 보이는)도 편하게 수행할 수 있었다.

breakpoint는 script를 통해서 설정된 breakpoint 시점의 환경에 접근할 수 있게 해주는 기능이고, association은 DB schema만으로 표현할 수 없는 객체간의 관계를 선언적으로 설정해주는 기능이다. association 선언에는 객체 이름 외에는 아무것도 필요하지 않기 때문에, 역시 rails의 전체를 관통하는 철학인 convention을 사용하고 있음을 알 수 있다. routing은 rails의 디폴트 URL convention에서 벗어나 이를 customize할 수 있는 방법을 제공한다.

이 외에도 기본적인 validation, javascript를 쓰지 않아도 되게 해주는 RJS, web services를 지원하기 위한 webresource와 같은 기능도 간략히 소개되었다.

질답 시간에는 웹 어플리케이션에서 자주 필요로 하는 기능 중 하나가 authentication/authorization인데, 이를 rails에서 어떤 방식으로 support하는가라는 질문을 던졌는데, rails에서는 이러한 기능이 core에 들어있진 않고 extension/plugin 수준에서 지원한다고 한다.

실제로 rails가 사용되는 곳이 어떤 곳이 있는가라는 질문이 2번씩이나 나왔는데, 미국에서는 역시 유명한 43things, basecamp, campfire, writeboard, 그리고 odeo라는 podcast directory 사이트가 있고, 한국에는 olaworks가 있다고 한다. (olaworks가 유일한 사이트?)

rails를 통해서 SQL, javascript, CSS를 쓸 필요가 없어진다고 한다. 여러가지 언어와 여러가지 환경에서 프로그래밍을 한다는 것은 생산성을 떨어뜨리는 요소중의 하나다임에 틀림없다. 하지만, SQL, javascript, CSS는 부차적인 문제다. 언제쯤이면 HTML을 쓰지 않고도 웹 어플리케이션을 만들 수 있을까? ;-)

Django – 김형용, 이정민

Django (장고, 혹은 쟁고) 는 웹 개발 프레임워크들간의 비교에서 흔히 등장하는터라 이름을 들어봤지만, 자세한 내용을 보게된 것은 처음이었다.

일단 Django는 Model과 View로 나누어지고, 여기에 template이 추가된다. 이 때 View는 Model 2의 Controller 역할, template은 View 역할이라고 보면 된다. (MFC에서도 사용되었던 Document-View pattern에 따라 모델링된 듯 하다.)

Django는 하나의 project 아래에 다수의 application을 생성하는 구조를 가지고 있다. 어느 정도 규모가 있는 어플리케이션 쪽을 노리고 만들어진 느낌이 들었다. application을 추가(startapp)할 때마다 configuration에 해당 application을 추가하지 않으면 웹에 반영되지 않는 것이라든가 Model을 변경할 때마다 syncdb를 하는 것도 그런 느낌이 들게 만들었다.

project에는 admin application이 기본적으로 생성되는데 이를 이용해서 다른 application들의 데이터에 대한 기본적인 조회나 조작이 가능했다. 이 admin application은 authentiation까지 지원되는 대단히 완성도 있는 admin application으로 웹 어플리케이션을 만들 때 필요한 어드민 페이지를 만드는 수고를 어느 정도 덜어주고 있었다.

Django의 template은 variable의 값이나 variable에 (helper에 해당하는) filter를 적용한 값을 표시할 수 있고, 조건이나 반복을 위해서 미리 정의된 tag가 존재하며 이를 확장할 수 있었는데, 이는 JSP와 거의 유사한 것이었다. Django의 View도 Struts의 Controller와 거의 유사한 모양새를 가지고 있었다. 즉, Model에서 특정한 context들을 만들어낸 후, 각각에 적당한 이름을 부여하여 template에 넘겨주는 방식이었다.

Django의 middleware는 정해진 interception point에서 동작하는 일종의 filter로 최소한의 AOP를 구현하고 있었다.

"그렇게 하는 게 좋은 건 알겠는데, 개발이 느려지잖아."

소프트웨어 프로젝트에 있어서 빠른 개발 즉, 효율성이 중요하다는 것은 누구나 공감하는 사실일 것이다. 수많은 방법론들과 도구, 라이브러리, 프레임워크들은 한결같이 ‘효율성’을 강조한다. 그렇다면 소프트웨어 제품에 있어서 효율성이란 무엇인가? 시간당 코드 라인 수? 일주일에 구현하는 기능의 수?

가장 간단하게 정의한다면, 시간당 추가되는 소프트웨어의 기능과 품질이 될 것이다.* 하지만, 많은 사람들은 이 효율성이란 기준에서 품질을 무시한다. De Marco가 Peopleware에서 언급했듯이, time-to-market 압박에 가장 먼저 희생되는 것은 기능이 아니라 소프트웨어 품질이다. 소프트웨어의 품질**은 고객이나 매니저의 눈에 띄지도 않기 때문이다.

물론, 현실적으로 기능에 대비해 품질을 희생할 수 밖에 없는 상황은 비일비재하다. 어느 날 갑자기 사장이 인터뷰를 통해서 다음달에 어떤 소프트웨어 제품이 나올 거라고 공언해놓고, ‘자 이제부터 이러이러한 소프트웨어를 만들어라’ 하면서 일감을 던져주는 것을 받아본 경험은, 소프트웨어 개발자로서의 경험이 어느 정도 있는 사람이라면 한번 정도씩은 있을 것이다. 이러한 문제가 너무나 심각해서, 어떤 사람들은 품질을 희생하는 것이 아니라 오히려 기능을 희생해야 한다고 얘기하기도 한다. 무엇이 옳든 간에, 소프트웨어의 기능과 품질을 둘 다 만족시킬 수 없는 상황에서 이 문제는 전형적인 trade-off 문제가 된다. 현재 개발자 커뮤너티의 대체적인 의견은 이러한 trade-off에 의한 품질의 희생은 불가피하며 iterative development를 통해서 극복이 가능하다고 생각하는 편이다.

문제는, 효율성을 이유로 들어 소프트웨어 품질의 희생을 일상화하는 경우다. 소프트웨어 품질을 일상적으로 희생하게 되면, 소프트웨어 라이프사이클이 이어질수록 소프트웨어 효율성에 나쁜 영향을 미친다. 결국에는 그 소프트웨어를 버리거나 그냥 대충 때우는 것 외의 대안이 없는 상태가 되어버린다. 물론 모든 소프트웨어가 긴 수명을 가지지는 않는다. 학교에서의 소프트웨어 프로젝트와 같은 일시적으로 필요한 단순한 소프트웨어나, 빠르게 사용자 요구가 변화하고 사라지곤 하는 웹 어플리케이션과 같은 경우에는 품질을 희생하더라도 별 문제가 없을 수 있다. 하지만 반대로, 긴 수명을 가지는 소프트웨어도 존재한다. 그러한 소프트웨어를 매번 버리고 새로 만드는 것은 프로토타이핑의 목적이 아니라면 매우 비효율적이다. 설령 어떤 목적으로 (이를 테면, 경험이 부족한 도메인의 실험적인 프로젝트) 매번 버리고 새로 만든다 하더라도, 그럴 때마다 기존의 것을 가능한 한 재사용하는 방식을 추구해야 한다.

소프트웨어의 품질이 지속적으로 효율성에 영향을 미치는 장기적인 소프트웨어 프로젝트에서, 소프트웨어 품질의 희생을 일상적으로 받아들이는 태도는 잘못된 것이다. 마치 고급 아파트를 지을 때의 마감공사를 조립식 건물을 지을 때처럼 대충하는 것과 다를 바가 없다. 이러한 태도는 소프트웨어 품질 자체에 관해 무지하거나, 소프트웨어 프로젝트의 수명에 따라 품질에 대한 태도를 다르게 해야 한다***는 사실에 대해 무지하거나, 소프트웨어 프로젝트의 수명에 대해서 착각을 하고 있기 때문에 발생하는 것이다.

어떤 사람은 소프트웨어 품질에 대한 태도가 단지 개발자 개개인의 ‘스타일’의 문제이고 이를 받아들여야 한다고 얘기한다. 물론, 특정 도메인에서 소프트웨어 개발을 지속적으로 해온 사람은 소프트웨어 품질에 대한 특정한 태도를 내면화하여 그것을 ‘스타일’로 가질 수는 있다. 하지만, 그것이 ‘스타일’이라고 해서 합리화될 수는 없는 것이다. 소프트웨어 품질에 대한 태도는 개발자에 따라 달라지는 것이 아니라 소프트웨어 제품 또는 프로젝트에 따라 달라져야 하는 것일 뿐이다. 여기서 ‘스타일’이라고 지칭되는 것은 사실상 ‘습관’에 불과한데, 대부분의 평범한 소프트웨어 개발자들은 자신의 습관에 따라 행동하고, 때로 특정한 도메인이나 특정한 소프트웨어 프로젝트에서는 그 습관을 통해 최고의 능력을 보여줄 수도 있다. 하지만, 뛰어난 개발자들은 그러한 습관을 내면적인 규칙(discipline)을 통해 극복하고, 도메인이나 소프트웨어 프로젝트에 따라 서로 다른 적절한 태도를 취하고, 어느 곳에서나 최고의 능력을 보여줄 수 있다.

결국, 장기적인 소프트웨어 프로젝트에서 조차도, 소프트웨어 품질 희생의 일상화를, 효율성을 근거로 하여, 합리화하기를 즐기는 사람들은 대체로 자신의 습관이나 부족한 능력에 대한 변명을 하고 있을 뿐이다. 정말로 뛰어난 개발자는 거의 항상 (최고가 아니라) 적절한 – 기능과 품질 양쪽 모두에서의 – 효율성을 성취할 수 있기 때문이다.

* 소프트웨어의 특성을 기능과 품질로 양분한 것은 논의의 간결함을 위한 것이다. 소프트웨어는 그 복잡성만큼이나 요구되는 특성들이 많다.
** 이 때, 소프트웨어의 품질이란, 소프트웨어라는 제품이 가지는 특성으로서의 품질이 아니라, 소프트웨어 자체의 품질, 굳이 예로 들자면 코드의 품질과 같은 내부적인 특성을 얘기한다.
*** 소프트웨어의 수명만이 소프트웨어 품질에 대해 요구되는 태도를 결정짓는 것은 아니다. 다양한 비즈니스적인 요구나 도메인에 대한 개발자의 지식 등 여러 가지 요소들이 모두 영향을 미칠 수 있다.

Yahoo! Content group의 engineering manager인 Tim Converse가 Crawler trap과 redirection에 대해서 언급하고 있다.

Excerpted from An Interview with Tim Converse, part 2 (emphasis made by me):

http://lastmind.net/beta/sliding_gallery/

팀 분위기도 어수선하고, 심심하고 해서, Kevin Le의 Ajax-ready sliding gallery library를 이용해서 잡질을 약간 해보았습니다. Flickr (Flickr는 오늘도 다운타임이군요. 쯧쯧.)의 제 공개된 사진들을 연동하는 것이었는데요. 일단은 sliding gallery library를 활성화하고 데이터(즉, 사진들의 URL) 를 집어넣는, 그러니까 사용하는 js 파일을 생성하는 방식으로 만들어두었습니다. Flickr에서 데이터를 가져오는 부분은 Flickr.rb를 사용했습니다. (물론 ruby 라이브러리입니다.) 웹디자인은 그냥 라이브러리의 데모 페이지를 긁어왔으니 놀라시지는 않으시길 바랍니다.

동적으로 Flickr와 연동해주는 것이 최선이겠지만, 아직은 그럴 필요까지는 못 느끼고 있고, 귀찮은 면도 있어서, 적당히 돌아가는 것을 확인하는 정도로 그만두었습니다. 좀 더 public한 demo를 만들려면 물론 사용자 아이디를 입력받아주는 것이 좋겠지만, sliding gallery library 자체에도 몇가지 문제가 보이고 해서 일단은 hold하기로 했습니다. 당장 제 눈에 띈 library의 문제들은 다음과 같습니다.

• 스크롤 크기가 static하게 정해져있어서, 사진 단위로 스크롤 되지 않는다.
• Thumbnail 이미지들이 한꺼번에 로딩되서 수가 많아지면 페이지를 로딩하는데 한참 걸린다.
• 처음 나올 큰 이미지가 html에 코딩되어있고, 적절한 Trigger를 발생시킬 지점이 없다. (전 직접 javascript로 코딩해넣었습니다.)
• 클릭 이벤트 외에 스크롤 이벤트에 반응하도록 하는 콜백이 없다. (스크롤할 때 선택 이미지를 전환한다든가 하는 효과를 줄 수 없죠.)
• 몇가지 버그들.

시간이 나면 제작자에게 컨택해서 얘기해보거나 직접 고쳐볼 요량입니다만, 귀찮아서 말이죠.

최근 들어 javascript 언어 기반의 라이브러리나 프레임워크들이 상당히 많아지고 성숙되고 있는 듯 하군요. Sliding Gallery library 같은 경우도 아직은 순수하게 따로 제작된 것들이나 상용 솔루션들보다는 못하지만, 조금만 더 다듬으면 재사용이 쉽다는 이익을 통해 그런 것들을 넘어서는 것도 시간 문제인 것 같습니다.

Bjarne Stroustrup의 글 A Brief Look at C++0x에서는 C++ 프로그래밍 언어의 다음번 표준안인 C++0x에 대해서 소개하고 있다. C++0x에서의 변경사항에 대한 기본 원칙들을 먼저 설명하고, 언어상의 변화, 그리고 라이브러리상의 변화 순으로 내용을 전개하고 있으므로, C++0x에 관심이 있는 사람이라면 반드시 한번 읽어봐야할 글이다.

C++0x에 들어갈 라이브러리상의 변화에 대해서는 이 블로그에 여러번 적었기 때문에 이 글에서는 언급하지 않기로 하고, 다만 언어상의 흥미로운 변경사항들에 대해서 간략하게 적어보기로 한다.

Template alias (a.k.a. template typedefs)

template을 많이 활용하기 시작하면서 가장 먼저 느끼게 되는 불편함 중의 하나가 특정 template의 특정specialization을 반복해서 사용해야하는 경우가 잦아진다는 것이다. C/C++ 프로그래머가 이 때 떠올리는 것은 typedef 시스템이다. 즉, template의 specialization은 typedef로 재정의할 수 없을까? C++0x에서는 typedef 키워드를 사용하지는 않았지만, using 키워드를 사용해서 이러한 요구를 반영하고 있다.

template parameter의 끝에 달라붙는 >가 반복될 경우에 space가 더이상 필요하지 않아진 것도 눈여겨볼 만한 점이다.

Sequence constructor

n1711문서를 소개하는 글에서도 언급을 했지만, array나 struct 뿐만 아니라 일반적인 user-defined type도 initializer list를 사용한 construction이 가능해졌다. 이를 통해서 array를 써야하는 경우는 거의 없어지고, vector 등 container들의 활용 가치는 훨씬 높아지리라고 예상된다.

Concepts

최근 부각되고 C#, D 등의 언어에서는 이미 활용되고 있는 programming constructs 중 하나인 concepts는 C++의 커다란 특징 중 하나인 template의 강점을 더욱더 강하게 만들어주는 특징이 될 것이다. C++ standard library나 체계적으로 만들어진 C++ 라이브러리들에서는 이미 concepts의 개념이 항상 문서화되어왔었고, C++0x에서는 다만 그것을 프로그램 상에서도 명시 그리고 강제를 할 수 있게 해준 것이다. 이를 통해서 프로그래머가 생각하는 바를 좀 더 명확하게 표현할 수 있고 오류에도 무엇이 문제인지 좀 더 명확하게 표현될 수 있을 것이다.

Automatic type deduction

static typing을 사용하는 언어라고 해서 불필요하게 변수의 타입을 선언해야하는 것은 아니다. 주어진 context에서 컴파일러는 타입을 deduce해낼 수 있기 때문이다. auto라는 키워드가 그리 마음에 들지는 않지만, 당연해 보이는 루프 변수의 타입 따위를 기억해내는 데 노력을 들일 필요가 없어진다는 것은 마음에 쏙 든다.

More Information

그동안 C++0x의 라이브러리상의 변화에만 관심을 기울여서 언어상의 변화에는 소홀했었는데, 여러가지 고무적인 변화가 많은 언어상의 변화쪽에 흥미가 생기기 시작했다. Draft와 Issue 리스트를 살펴봐야할 듯 하다.

• ISO/IEC JTC1/SC22/WG21 – The C++ Standards Committee
• C++ Standard Core Language Issues List
• ISO/IEC 14882: Programming Language C++ Draft
• Highlights of the April 2006 ISO C++ meeting

Vim 7을 설치하더라도 기존 버전과 달라진 점을 쉽게 깨닫기는 힘들다. First look at Vim 7이라는 글을 참고하여 Vim 7의 새로운 기능을 쓰는 방법을 간단하게(?) 정리해보았다.

Spellcheck

:help spell

Spellcheck 기능에 대한 도움말.

:set spell spelllang=en_us

Spellcheck 기능 켜기.

zg

cursor 위치의 단어를 good word로 취급. (zug로 undo)

zw

cursor 위치의 단어를 wrong word로 취급. (zuw로 undo)

z=

cursor 위치의 단어를 대체하는 추천 단어를 리스팅.

Undo branches

특정 시간이나 변경수를 이용하여 undo/redo가 가능해진 기능. 자주 쓸모가 있을 것 같지는 않다.

:help undo-branches

Undo branches 기능에 대한 도움말.

:undolist

undo. 기존의 u와 동일.

g-

undo. 기존의 u와 동일.

g+

redo. 기존의 Ctrl-r과 동일.

earlier 3

3번의 변경 이전으로 undo.

later 3

3번의 변경 이후로 redo.

earlier 3s

3초 이전으로 undo.

later 3h

3시간 이후로 redo.

Tabs

탭기능.

:tabnew

새로운 탭 추가.

gt

다음 탭으로 이동.

:tabdo %s/oldvariable/newvariable/g

모든 탭에 특정 명령(replace) 수행.

Etc.

Ctrl-x Ctrl-o

code completion. html element 같은 경우에는 잘 동작하지만, 프로그래밍 언어에서는 어떻게 동작하는지 잘 모르겠다.

:sort

라인들을 알파벳순으로 정렬.