썰렁한 엔지니어

최근들어 사내 Subversion 커밋요건이 강화되었다. 외부에 공개되어도 괜찮을 것이라 생각하여 간단히 기술하고 그 생각을 적어보고자 한다. 2월 21일 공지 1단계는 SVN 로그 입력이 전혀 안되어 있을 경우 Commit을 불허 합니다. 즉, 로그 입력을 안하면, Commit이 실패하게 됩니다. 2단계는 SVN 로그 입력시 리뷰자가 없을시에 Commit을 불허합니다. 리뷰는 생활화하셔야 됩니다. 단순히 보여주기 위한 리뷰가 되어서는 안됩니다. 따라서 소스 코드 수정시 리뷰가 반드시 진행되어야 하고, 그 이후에 Commit이 이루어 져야 합니다. 따라서 리뷰자가 로그상에 없다면 Commit을 실패하게 됩니다. [실행 파일명][실행 파일의 버전][개발자 성명][BT:버그 번호] [RV:Review 참석자..

블로그의 가장 흔한 외부 연결은 RSS일테지만, 글쓰는 사람에게도 그 API라는 것이 있다. 나는 태터의 기본 편집기를 사용하지만, 편집기능이 wyswyg이 아니기 때문에 생기는 미려한 문서 작성이 어려운 것이 사실이다. www.writely.com 을 사용하면 워드 수준의 편집기를 제공하는 것을 볼 수 있는데, 이 사이트가 최근 google에 인수되었다. 이 의미가 독특한데, 1. network 기반 office를 위한 행보 2. 양질의 content decoration을 하나로 제공하여 api 연동을 유도 2 번에 주목하자면, 블로그나 게시판에서 따로 글을 편집하기 위한 기능을 둘 것이 아니라 전문적인 사이트에 그 내용을 두고, 원하는 블로그에 출판(publish)하면 되는 것으로 가능하게 할 수 있..

이른바 유틸리티라는 프로그램들이 있다. 이것들은 간단한 기능만을 하는 프로그램들을 말하는데, 전통적인 Unix에는 정말이지 잡다한 유틸리티들이 있다. 예를 들면, "y" 라는 프로그램은 단지 화면에 y를 한 줄에 하나씩만 출력할 따름이며, "true" 라는 프로그램은 항상 정상종료만하는 프로그램, "false"라는 프로그램은 항상 오류 종료만하는 프로그램이다. 이런 유틸리티는 처음 나올때부터 조금씩 진화에 진화를 거듭하게 되고, 때에 따라 개발자가 중도 포기하면, 다른 사람이 이어가거나 아니면 아예 명령어 구문만 같은 다른 프로그램을 만들기도 한다. 따라서, 다양한 버전의 같은 일을 하는 유틸리티가 존재하는데, 그 중 GNU에서 다시 만들어 배포하는 유틸리티들에 대한 얘기를 해보고자 한다. GNU에서 배..

HTTP: Hyper Text Transfer Protocol SMTP: Simple Mail Transfer Protocol POP3: Post Office Protocol ver 3 NNTP: Network News Transfer Protocol FTP: File Transfer Protocol HTTP는 다른 프로토콜보다 상당히 젊다. 만들어진 시기를 RFC 등록일로 조사해보니 다음과 같다. FTP: RFC 765 - 1980 SMTP: RFC 821 - 1982 POP: RFC 918 - 1984 NNTP: RFC 977 - 1986 HTTP: RFC 1945 - 1996 HTTP의 경우 RFC 1945에서도 기술된 바와 같이 1990년부터 만들어져 사용되어 왔다고 기록되어 있다. 다른 프로토콜..

많은 사이트에서 Web 2.0에 대해서 말하므로, 여기에서 Web 2.0을 말하는 것은 짧은 지식에 더 도움이 되지 않을 것이므로, 이 글을 읽는 사람들은 Web 2.0에 대해 못에 귀가 박히도록(?) 들었다 가정하고 얘기 좀 해볼까한다. Web 2.0 생존 법칙에 대한 내 생각은 많은 사람들이 오~할 만한 철학이 있느냐 이다. 철학이라는 식상한 단어를 선택한 이유는, 이보다 더 적절한 표현이 없을 것 같아서이다. 그런데 이 철학이라는 것은 내가 프로그램을 설계할 때도 무의식중에 집중하는 것이다. 내가 Web 2.0을 계속 주시하는 이유도 이때문이 아닐까한다. 성공하는 서비스에는 반드시 그만의 철학이 있다. 그것도 저혼자 잘난 철학이 아니라 인터넷 유저의 공감을 이끌어 낼 수 있는 철학이다. 철학은 남들..

최근 subversion 프로젝트에서 메인 개발자에 의한 code fork가 이루어지고 있는 것이 하나 있다. Subversion with space라는 프로젝트인데, 이 코드 포크는 단지 함수호출시 사용되는 괄호 앞에 공백을 두는 것이 좋으냐를 가지고 일어난 것인데, 이것 때문에 수많은 커미터들의 코드를 예쁘게(?) 만든뒤 새로운 코드 저장소에 수동으로 반영한다는 것이다. 아직 소스에 접근이 불가능하여 릴리즈는 된 것 같지는 않다. 아니면, 이들이 재미로 하고 있던지.. 관련 메일링리스트는 * [VOTE] space before paren policy * [FORK] Subversion-With-Space 흔히, 커미터들에게 코드 작성 규칙을 엄격히 하고, 그 규칙대로 되어 있지 않은 코드를 수정해서 ..

구글이 운영하는 거의 무제한(2GB) 메일 서비스인 gmail.com에 gtalk가 들어갔다. gtalk 는 구글의 메신저인데, 그 기반은 open source project인 jabber를 기반으로 만들어진 것으로 그들과 연동이 가능한 메신저이다. 구글의 Ajax 놀이는 끝이 없어 보이지만, gmail에 gtalk가 들어갔다는 것은 그 안에 무슨 Active X 컴포넌트를 통해 만들어진것이 아니라, 단순히 자바스크립트만으로 만들어진 것을 말한다. 워낙 gtalk가 단순하기는 하였지만, 그 단순함이 voice를 빼고는 모두 구현되어 들어갔다. 이것은 무엇을 뜻하는 것일까? JavaScript가 정상적으로 돌아가는 모든 클라이언트에 gtalk를 설치하지 않고도 친구들과 대화가 가능하다는 것인데, 상상력을 ..

2003년 5,6,7에 걸쳐 마이크로소프트웨어에 연재했던 "디버깅 다시 보기"라는 글인데, 마지막 7월에 아래와 같은 맺음말을 썼더구만, 디버깅=프로그래밍 수련 과정 이번 호에서는 서로 관련 없는 사항이긴 하나 세 가지 정도를 들어 디버깅을 하면서 내부에서 돌아가는 원리를 알게 되는 일에 중점을 두어 설명하였습니다. 디버깅은 해킹과 같은 고도의 입체적인 접근과 연결되어 있는 개발 행위(?)입니다. 따라서 디버깅은 단순한 문제 해결 관점보다는 좀더 테스트 코드를 만들어 보게 하고, 언어와 환경에 대한 깊은 이해를 돕는 프로그래밍 수련회와 같은 것이라고나 할까요? 세 번에 걸쳐 디버깅에 대한 감각이 잡히려는 사람들을 대상으로 어떤 관점을 가져야 될지 주제를 골라 나열하였습니다만, 아는 것을 말로 표현하는 것..

지식공과 숙련공 대화 관리자: "이 기능이 가능한지 알아보려하니 간단하게 작성해 주겠나?" 지식공: "네, 그 분야에 대해 알고있으니 이틀이면 가능할 것 같습니다." 숙련공: "네, 이틀이면 가능할 것 같군요." 이틀 뒤, 관리자: "어디 작성한 코드를 좀 검토해 보세나." 양공: (주저리, 주저리 설명을 한다.) 관리자: "저 부분은 에러처리가 잘 되어 있지 않군. 또한 로그를 남기는 것에 일관성이 없는 것 같애. 메모리를 할당받지 못하는 경우는 어떻게 처리할텐가" 지식공: "제가 집중한 분야는 이틀전에 말씀하신 그 기능이 제대로 동작하는가입니다. 따라서 에러처리나 로그를 남기는 것은 일관성이 없을 수 있는 것 아닌가요? 그리고, 그 부분은 최호진씨의 조언에 따라 구현이된 것입니다." 숙련공: "로직을..

디버깅을 좀 더 잘하는 법 중 하나는 디버거가 어떻게 동작할까를 상상하면서 디버깅 관련 api를 공부하는 것이다. 물론 디버깅을 잘하려면, 그 툴에 익숙해져야하겠지만 전반적인 디버거류의 행동에 대해 상상하는 것이 필요하다는 것이다. 뭐든지 상상하는 것과 그 상상을 뒷받침할 만한 기술을 습득하여 점점 구체화시키는 것이 우리네 기술자들이 하는 행위아닌가. 다만 그것이 창조적 상상이라기 보다 남이 해놓은 것을 날로 먹기에는 어려운 것에 대한 상상이라서 문제일뿐.