여름으로 가는 문

OctoberSkyJs 세 번째 모임 후기

doortts — Sun, 13 May 2012 21:23:42 +0900

어제(5.12.토)는 node.js 학습커뮤니티인 OctoberSkyJs의 세 번재 오프라인 모임이 있었습니다.

사전 안내페이지

http://www.facebook.com/octoberskyjs/posts/424422624252307

장소는 남산 커피쉬라는 곳을 추천받아서 진행했는데요 처음 가 보는 곳이라 조금 걱정했습니다만, 다행히 괜찮았습니다. 명동역에서 내려서 가는 길에 살짝 헤맸습니다만, 무리없이 도착은 했습니다. (다른 분도 한 분 장소를 못찾아서 조금 헤매셨습니다)

저희는 2층을 통째로 빌려서 오전 11시부터 6시까지 먹고 놀면서 있었습니다. : )

이런 분위기입니다. 바닥도 좋고 분위기도 좋았습니다. 일하시는 분도 참 친절하게 대해 주셔서 좋았습니다. : )

다만 좌식이라 시간이 지나자 허리가 아프다고 호소하시는 분들이 조금 계셨어서 안타까웠습니다.

공유 발표주제는

- Node.js Happy Hacking, 박난하 님

- 노드 불신 자바 개발자의 노드 개발 및 삽질 이야기, 박성철 님

- Flow Control in Node.js, 송형주 님

- Javascript Web Application 개발 경험기, 이병주 님

난하님의 경우 소개때 몇몇 분들이 '다른 분들은 실명으로 자기 소개했는데 저분은 닉네임(나나)으로 소개하시는군요'라고 오해를 하셨습니다. 하하하! 원래 오해 많이 받으신다네요.

편하게 오시라고 이야기드렸음에도 전체적으로 다들 너무 준비를 잘하셨어서, 심지어 몇 몇 분들은 '이건 웬만한 컨퍼런스세션 이상의 발표였다'며 놀라움과 감탄을 표시 하셨습니다. 제 생각도 그러했고요.

- 난하님은 직접 만드신 nodeman과 node.js black edition을 예로 사용하셔서 inside node.js에 대해 재밌는 짤방과 함께 높은 이해도의 지식으로 전달해 주셨습니다. 아마 국내 어디 다른데서는 들어 볼 데가 없을 유니크한 발표였습니다.

- 그리고 전날 술을 먹어서 밤에 그냥 대충 준비해서 부족해도 봐달라고 하신 형주님의 경우에도 '술을 안먹었으면 그럼 대체 어떤 수준으로 발표자료가 나올뻔 한거냐?'라며 사람들이 놀릴 정도였습니다.

- 성철님도 뭔가 '준비 작업하다 망했다'고 이야기 하셨지만 vert.x를 이용한 참신/놀라운 결과물에 가장 많은 질문을 받은 인기발표가 되었습니다.

- 병주님은 병특이 끝나가는 young & handsome guy이신데요, javscript mv* 프레임워크중 하나인 backbone.js, requireJs 를 이용해서 사이트를 구축한 경험담을 공유해 주셨습니다. backbone.js를 사용한 국내 서비스가 어디 또 다른 데가 있을까 싶습니다.

예상보다 열띈 진행에 무려 한시간을 넘게 예정시간을 넘겼던 점은 조금 아쉽습니다만, 끝나고도 거의 한 시간넘게 node.js에 대해 토론을 하고 헤어졌습니다.

마무리

5월의 토요일이란 것이 참 개인희생이 없으면 만들기 어려운 시간일 수 있습니다. 그럼에도 많은 분들이 기술에 대한 열정과 관심, 그리고 지식을 함께 나누고 배우는 것에 대한 열린 마음으로 함께 하셨습니다.

적지 않은 분들이 이렇게 이야기 하셨었습니다.

'이 기술, 나 혼자만 하거나 주변에 하는 사람이 없는 줄 알았는데 이렇게 모여보니 이곳 저곳에서 많은 시도가 이루어지고 있고 하시는 분들을 알게 되어서 용기가 되었다'

커뮤니티란 의미에 맞게, 서로 도우며 함께 성장하고, 그 안에서 각자의 가치(value)를 키워갈 수 있는 좋은 기회가 계속 이어졌으면 좋겠습니다. 저도 부족하나마 앞으로도 열심히 노력해야 겠다는 생각을 하게 되었습니다. 그리고 오신 분들 모두 고생 많으셨고요, 아마 이런 열정이라면 다들 어디서 무얼 하시든 멋지게 잘 하실것 겁니다. (제가 회사 사장님이면 상줬을 것 같습니다. ㅎㅎ)

감사합니다. : )

이하 당일 사진입니다.

남자들이 너무 많다! 라고 하자 바로 살사모임을 안내해 주신 대완님이 전 참 좋았습니다. ㅎㅎㅎ 성격도 넘 좋으시고.

이 사진을 보고는 누군가는 '난민들..?'이라고 하셨습니다. (...)

이 사진은 제가 '이거 무슨 세미나나 모임이 아니라 언듯보면 직장인 회식자리 같네요.하하!'라고 했더니, 사진에 계신 분 중 한분이신 관계자(!!)분께서 맛있는 맥주를 쏘셨습니다!! (^_^)/ 덕분에 국내 최초 음주 세미나가 되었습니다!!

ps. 함께 이야기 나누고 들어주시고 맛있는 맥주도 무제한으로 제공해 주신 '윤종석'님 감사합니다.: )

'node.js (OctoberSkyJs)' 카테고리의 다른 글

OctoberSkyJs 세 번째 모임 후기 (0)	21:23:42
OctoberSkyJs 근황 및 모임 안내, 향후 계획 등등의 이야기 (2)	2012/04/19
이쁜 자식 매 하나 더 준다는 심정으로 쓰는 node.js 이야기 (0)	2012/04/13
node.js를 학습하는 사람이라면 꼭 봐둬야 할 Node.js 소개 동영상 해설 (0)	2012/03/10
[node.js] 토요일밤에 node.js 동영상 함께 보기 이벤트! (2)	2012/03/02
[node.js] Connect 2.0 소개 (0)	2012/02/29

OctoberSkyJs 근황 및 모임 안내, 향후 계획 등등의 이야기

doortts — Thu, 19 Apr 2012 15:09:50 +0900

안녕하세요?

한동안 node.js 모임인 OctoberSkyJs 모임 근황이야기 드립니다. 공식 페북페이지 www.facebook.com/octoberskyjs 에는 먼저 살짝 이야기 드렸던 내용입니다.

#1. node.js 공식사이트에 한국 커뮤니티로 등재

별건 아니지만 OctoberSkyJs 모임이 node.js 공식사이트의 로컬커뮤니티 사이트로 등재되었습니다. :)

뭐, 특별한 의미보다는 좀 더 많은 분들이 한글 자료를 보다 쉽게 접근 할 수 있도록 준비한 내용 중 하나입니다.

#2. 단축 도메인 nodejskr.org

그리고 nodejs.org에 커뮤니티로 등록할 때 핑계김에 한 페이지 짜리 학습용 가이드 페이지를 접근하기 쉽도록 도메인도 하나 연결했습니다.

앞으로 기억 안나실때는 nodejskr.org 로 접근하시면 됩니다. 공식사이트의 이름 nodejs 뒤에 kr만 붙였습니다. 그리고 단체를 나타내는 꼬리단어로 org를 붙였고요.

#3. 세 번째 모임 안내.

세 번째 5월 12일 토요일에 진행될 예정입니다.

현재 장소 섭외는 마쳤고요, 짧은 발표를 하실 분들을 먼저 섭외중에 있습니다. 세미나라기 보다는 함께 이야기 하고 나누면서 한나절 보내는 시간을 생각하고 있습니다. 발표자에 대한 자격같은건 없으니까 공유하고 싶은 내용 있으신 분들은 알려주세요. 회비(약 2만원) 감면 및 우선등록 해 드리겠습니다. 자신의 생각이나 아이디어, 지식이 맞는지도 확인해 보고 논의해 볼 수 있는 좋은 자리이니까 부끄러워 마시고 알려주세요.

공유 발표 신청은 octoberskyjs@gmail.com으로 보내주세요. 내용 겹치지 않도록 조율정도만 할 예정입니다.

#4. OcotberSkyJs 모임의 향후 계획

올해의 전반적인 계획은 node.js를 더 쉽고 편하게 많은 분들이 사용할 수 있도록 돕는 겁니다. 그러기 위해서

- 가이드 페이지의 자료를 늘리기

- 가이드 페이지 contribution으로 참여하실 분들 늘리기.

- OctoberskyJs 모임 활동 늘리기

- 가이드 페이지의 링크가 깨져서 읽기 어려운 일을 막기 위해 snapshot을 pdf 등으로 만들어 제공하기

등등의 활동을 하려고 합니다.

#5. 몇 가지 도움 요청 및 안내

- 활동에 도움주실 분은 페북페이지 http://www.facebook.com/octoberskyjs에 남겨주시거나 메일주세요.

특히 snapshot을 pdf 같은 ebook으로 만들어 놓은 부분은 도움이 많이 필요합니다. 예를들면, 컨텐츠 pdf로 넣는데 확인 받는 메일 주고받기, 간략하나마 book형태로 pdf로 만들기 위해 기본적인 편집작업 등등..

- 아! 그리고 혹시 이미 node.js 모임이나 커뮤니티 활동을 하고 계신분들, 혹은 추천할 만한 모임등을 알려주시면 가이드 페이지에 링크 달아 놓도록 하겠습니다.

- 마지막으로, node.js 기반으로 서비스를 하고 계시거나 준비중이신 분이 계시면 메일이나 댓글 주세요.

업무로 하시는 분들이 서로 교류하실 수 있는 자리를 따로 만들어 보도록 하겠습니다. 필요로 하시는 분들에게는 소개도 시켜드리고요. : )

'node.js (OctoberSkyJs)' 카테고리의 다른 글

OctoberSkyJs 세 번째 모임 후기 (0)	21:23:42
OctoberSkyJs 근황 및 모임 안내, 향후 계획 등등의 이야기 (2)	2012/04/19
이쁜 자식 매 하나 더 준다는 심정으로 쓰는 node.js 이야기 (0)	2012/04/13
node.js를 학습하는 사람이라면 꼭 봐둬야 할 Node.js 소개 동영상 해설 (0)	2012/03/10
[node.js] 토요일밤에 node.js 동영상 함께 보기 이벤트! (2)	2012/03/02
[node.js] Connect 2.0 소개 (0)	2012/02/29

불신풍조 만연 프로그래밍 vs 너님 잘못임 프로그래밍

doortts — Wed, 18 Apr 2012 20:36:27 +0900

얼마전에 있어던 모 서비스의 장애에 대한 이야기입니다.

어느날 갑자기 svn 서버가 정상적으로 동작하지 않는 사건이 발생했습니다. 현상을 조사해 봤더니 서버 인증파일을 읽어들일때 파싱(parsing)이 실패해서 계정 정보를 읽어들어야 하는 SVN이 정상동작하지 않는 것이었습니다.

인증파일을 조사해 봤지만 처음엔 별다른 이상한 점이 보이지 않았습니다. 그런데 가만 살펴보니 파싱 문제가 생긴 부분 윗줄에 적혀있는 계정 ID의 맨 앞에 공백이 하나 살짝 붙어 있는 걸 발견했습니다.

'이것때문이었나?'

vi로 계정파일을 직접 열어서 ID앞에 붙어있는 공백을 지워봤습니다.

- I'll FIX IT!!

그러자 서비스가 다시 정상적으로 동작하기 시작했습니다.

'아! 이런! 이거였군!'

첫 글자가 공백인 unix id가 존재한다는 건 말이 안되고, 더더군다나 계정파일에 들어가는, 발생할 수 없는 (발생해선 안되는?) 상황이 발생한 것이었습니다.

그래서 당연한 수순으로 SVN에서 사용하는 계정 정보의 생성시점에 대해 알아보았습니다. 그 결과 계정정보는 해당 서비스에서 직접 만드는 것이 아니고, 연계서비스에서 일정 시간마다 배치로 넘겨받아서 파일에 작성하는 식이라는 걸 알게 되었습니다.

그러는 사이 또 얼마간의 시간이 지났고, 다시 서비스가 다시 동작하지 않게 되었습니다. 파일을 열어보니 문제를 일으킨 ID에 다시 공백이 붙어 있는걸 볼 수 있었습니다. 계정정보를 새로 넘겨받아서 인증 파일이 다시 갱신되어버린 겁니다.

'다시 배치가 돌았군. cron job을 살펴봐서 주기가 얼마인지 확인해보자'

15 * * * * batchxxx

15분 간격(Every 15 Minutes)

'이제부턴 앞으로 15분 간격으로 파일을 열어서 공백을 계속 없애야겠군.... 이 아니라 이런식이라면 앞으로 15분 이내에 대책을 세우지 않으면 또 서비스가 멈춰버리고 말아!!'

...

우선은 옆자리 대리님을 시켜서 코드를 임시로 고치게 만들고 다시 고민에 들어갔습니다.

"서.. 설마, 연계 쪽 서비스에서 가입시에 아이디 앞에 공백을 붙여 가입할 수 있었던 건가?"

만약 정보를 저희쪽으로 넘겨준 쪽에서 서비스 가입시에 정말 그런 일이 일어난다면, 그건 예사로운 문제가 아니었습니다.

"음.. 하지만, 예전엔 없던 현상인데 갑자기 왜 이런일이? 최근 그 쪽(?)에서 뭔가 코드를 변경하면서 이런 일이 발생한걸까?"

연락을 해서 그 쪽(.. 자꾸 그 쪽이라고 쓰려니 어색+귀찮군요. ... 여튼)에 실제 DB에 저장된 정보를 확인해 달라고 요청했습니다. 공백이 들어간 ID가 있는지 여부를 말입니다.

확인결과는 "공백이 ID 앞에 들어가 있는 ID는 없음. 그것뿐 아니라 중간이나 뒤에 들어가 있는 경우도 없음. 즉, 우리쪽 문제는 아님"으로 연락을 받았습니다.

하지만 저희쪽은 계정정보 자체를 생성하지 않기 때문에, 곤란한 상황에 빠졌습니다.

넘겨주는 쪽과 넘겨 받는 쪽

저희 입장에서는 소위 말하는 spec에 맞춰 넘겨받는 걸 기대했기 때문에 spec에 맞춰있지 않은 데이터를 가정하고 있지가 않았습니다. 그런데 보내주는 쪽에선 '우린 문제없다'인 상황이니...

더더더 코드를 파고 들어가서 살펴보면 원인을 알아낼 수 있었겠지만, 그럴만한 여력이나 인력이 없었기에 쉬운 방법을 택했습니다. 저희쪽 코드를 수정해서 넘겨받은 데이터에 공백이 있을 경우 trim을 하는 것으로 말입니다. 우선 현상적인 문제는 해결되었습니다만, 석연친 않은 엔딩인거죠.

물론, 경험이 많으신 분들이 곧잘 이렇게 말하십니다.

"당연히 이런저런 검사를 했어야지! 스팩? 절대 믿으면 안되아! 넘겨주는 데이터를 어떻게 믿남? 방어형(defensive) 프로그래밍 몰라?"

방어형 프로그래밍

에.. 그러니까... 모르진 않습니다만...

한때 저도 방어형 프로그래밍의 중요성을 이야기 했었고 열심히 터렛코드(turret code)를 작성했었습니다. 하지만 결국 만들어진 코드를 보면 로직은 얼마안되는데 방어 코드들만 잔뜩인 어지러운 모양이 되곤 했었습니다. 시간이 지날수록, 그리고 문제 생길때마다 if 조건이 하나씩 더 붙게 됩니다.

문득 문득 이런 생각이 들곤 했었습니다.

"이럴거면 스펙을 왜 만드나? 넘겨받은 데이터를 활용하는 건 넘겨준 쪽 모듈에 대한 신뢰를 기반으로 이루어져야 하는거 아닌가?"

그래서 한 번은 새로운 코드를 작성할 때, 눈 딱 감고 방어형 코드들을 전.혀. 작성하지 않았습니다. 네트워크 자체의 신뢰성 의문에 대한 코드를 제외한 모든 방어코드를 뺐습니다. 처음엔 그래도 별 문제 없는 것 같았는데, 때때로 null 넘어오기 시작하고 공백 들어오고 있어야 하는 필드값 없고~ 이런 저런 문제가 생기더군요. 그리고 야단도 맞았습니다. 프로그램의 기초가 안되어 있다며 말입니다. 사실 지금 생각해보면 안되어 있긴 했었죠. ㅎㅎ

뭐, 여튼 그 상황에서 저의 대응은 이랬습니다.

"고쳐주세요. 값 넘기기 전에 검사해서.. 음.. 넘겨주세요."

넘겨주는 모듈을 만든쪽도 사실 100% 과실없음은 아니다 보니 뭐라뭐라 하면서 고쳐줍디다. 그리고 저도

"고치자. 값 넘기기 전에 검사하고 넘기자"

로 응대했습니다.

믿는 사회 밝은 사회

즉, 넘겨주는 모듈을 작성하는 쪽에 그렇게 요청했고, 저도 넘겨주기 전에 발생할 수 있는 예상외 상황에 대한 검사코드를 작성했습니다. 이런식으로 작업을 한 부분이 많은 건 아니었지만 (원체 타격이 커서..-,- 여하튼) 나름 꽤 괜찮았습니다. 코드, 함수, 메소드 시작지점에서 각종 if문이 사라졌고, 로직이 끝난 다음 필요하다 생각되는 정도로만 신뢰코드를 넣었습니다. 대표적으로 trim 코드라던가 null 대신 null object를 넘긴다던가 하는 식으로 말입니다.

그리고 보통 신뢰코드를 작성하는 것이 방어코드를 작성하는 것 보다 덜 지저분 하고 비용이 덜 듭니다. 왜냐하면 받는 쪽에서는 작성자가 아니면 해당 데이터가 어떤 방식으로 가공되어 넘어오는지 예측하기가 훨씬 힘들기 때문에 이것저것 찔러보듯 다양한 경우를 가정하고 방어하게 됩니다. (열 경찰이 도둑 하나 못 잡는다 격언대로죠)

여튼 작은 방식의 변화로 불신풍조 만세~! 를 벗어나는 상황을 만드는 노력을 했습니다. '믿지 말자. 너님 잘못!'에서 '남탓하지 말자. 내가 잘하자. 넘겨주는 데이터를 믿을 수 있도록 신뢰를 주자!'로 말입니다.

별것 아닐 수 있지만, 이것 또한 저에게 많은 인사이트를 주었습니다. 이건 언어자체가 DbC를 지원하고 안하고의 기술적인 문제가 아니라, 사람과 조직에 대한 신뢰 문제의 하나라는 걸 느끼게 되었습니다.

역사는 반복된다더라더라더라

여튼 다시 최근의 장애 상황으로 돌아가 보겠습니다.

현재 해당 서비스는 땜빵코드로도 잘 돌아가고 있습니다. 특별히 건드리는 일이 없다면 앞으로 새로운 버그가 생기기 전까지는 문제없이 돌아갈 겁니다. 하지만 이런 히스토리가 있다는 걸 뒤에 오는 사람들은 모르겠죠. (부끄러워서 알려주기도 싫어!) 그리고 공백이 있는지 검사하는 코드와 트림코드를 볼 겁니다. 그리고 그와 비슷한 친구들 수준의 코드들을 볼겁니다. 그리고는 제가 기존 코드 선배님들아!의 코드들을 봤을 때와 같은 대사들을 또 할 겁니다.

"아... 이건 완.전. (쓰)레거시인데~~ 척 보기에도 위.. 위험해 보여. 최대한 건들지 말아야겠어..."

라고 말입니다. 그럴때 부디 혹여라도 Hall of un-fame(이라고 읽고 주석이라고 불리는 곳)에서 저와 제 옆 자리 대리의 이름을 보게 되는 일은 생기지 않길 바랄뿐입니다.

이미지출처: http://me2day.net/rainygirl/2012/02/06/pyamvg6-3j9

'Better SW Development' 카테고리의 다른 글

불신풍조 만연 프로그래밍 vs 너님 잘못임 프로그래밍 (2)	2012/04/18
[뭘, 이런걸 다?] 크롬 브라우저 콘솔 폰트 크기 바꾸기 (0)	2012/02/10
[dW Review] 기술 동향 설문 IBM Tech Trends 2011 (0)	2011/12/31
[dW Review] Reverse Ajax, Part 3: 웹 서버와 Socket.IO (0)	2011/12/31
[dW Review] 함수형 사고: 결합 및 컴포지션, Part 1 (0)	2011/12/31
[dW Review] 이클립스는 어떻게 배워야 할까? (0)	2011/11/30

이쁜 자식 매 하나 더 준다는 심정으로 쓰는 node.js 이야기

doortts — Fri, 13 Apr 2012 02:36:12 +0900

이쁜 자식 매하나 더 준다는 심정으로 글을 적습니다.

그냥 밤에 쓰는 거고 생각나는 대로 쓰는거니 그냥 그려려니 하고 읽어주세요.

아침에 읽으면 전날쓴 연애편지 같은 느낌 나겠죠. 흠흠..

전 node.js 좋아해요. :)

하.지.만..

node.js를 본격! 서버스택으로 사용하는 데는 현재 아쉬운 점들이 있습니다. (그리고 계속 더더더 나오고 있고요.)

우선 node.js가 네트워크 라이브러리 스택인지라 서버로 사용하기엔 편의성이 많이 부족하고요, 옵션도 뭐 거의 없다 시피합니다. apache나 niginx보다가 node.js 보면, 이건 뭔가 싶을 정도..

그리고 필요한건 process.ENV로 넣으라는데... 차라리 json으로 configuration 파일을 만들겠습니다. (아.. 이건 아닌가...)

결국 웹앱 만들려면 express, meteor, batman 같은걸 써야 하는데 한마디로 춘추전국시대입니다. but 해당 사이트엔 부도 수표같은 부실 문서들이 잔뜩! 아무리 오픈소스라 코드가 보인다지만 코드 읽으며 작성자의 SF미드 pilot 드라마 같은 정신세계를 추측하고 있노라면 어느새 한숨이..

return function errorHandler(err, req, res, next){

res.statusCode = 500; // 에러 핸들러 넘겼더니 떡 하니 무조껀 500 internal로 하드코딩해서 처리! 야~야~!!

if (dumpExceptions) console.error(err.stack);

...

[ connect middleware 중에서]

해보지 않으면 알 수 없는 중학교 영어 학습법 같은 실험들(try and repeat, again, again, again, again~)

이를테면, 다음 a, b 둘 중 어느걸 써야 할까요?

buffer.slice(start, end).toString(encoding)

buffer.toString(encoding, start, end)

a 가 b보다 10배쯤 느립니다. 왜이런가 하고 찾아봤더니...

http://geochap.wordpress.com/2011/05/03/node-buffers/

뭐. 이런 시리즈가 또 주르륵...

때때로 기원을 알 수 없는 google v8엔진.

V8은 공식사이트에서 ES5 스펙대로 구현했다고 말해놓고

http://code.google.com/p/v8/ "V8 implements ECMAScript as specified in ECMA-262, 5th edition..."

어디 듣도보도 못한 것들도 막 지원..

http://kangax.github.com/es5-compat-table/non-standard/

var buf = new ArrayBuffer(32);

if (buffer.byteLength == 16) {

console.log("Yes, it's 16 bytes.");

} else {

console.log("Oh no, it's the wrong size!");

}

IE의 JScript 생각이 살짝 날 정도..

거기다 이걸 잘했다 해야 할지 어떨지 모르겠지만, 각종 data 타입도 v8은 '내가 제일 잘나가!'식으로..

이를테면 자바스크립트의 number는 내가 알기론 분명 range가 64bit 부동소수점,즉 정수로는 +-2^53 (-9007199254740992~9007199254740992)인데 크롬은 떡~하니 2^1024까지 자체 지원!

node.js도 v8기반이니 그걸 따라가는데..

이걸.. 좋아해야 하나... 이봐들.. 스.. 스펙을 쫌!!!!!

v8엔진도 서버용으로 만들어진것이 아닌지라 메모리관리에 한계가 있습니다. 현재 v8은 얼마까지 가능?

http://code.google.com/p/v8/issues/detail?id=847

역시.. 응용 애플리케이션 서버용으로 쓰려면 요령이...

좋아! 그럼 난 v8을 넘어서서 raw memory에 쓰겠어!라고 마음을 먹고 buffer를 쓴다 해도 bug 님이 기다리시고.

c에서 heap 다루듯 다루니 position 계산 잘못하면 garbage data와 말 그대로의 buffer-overflow님을 만날 수 있음.

java의 collection은 23세기 기술쯤처럼 보이기 시작하네요.

거기다가 buffer쓰는 이유가 뻔할텐데 binary encoding 타입으론 쓰지 말라는 알수 없는 공식문서의 멘트

"'binary' - .... This encoding method is deprecated and should be avoided in favor of Buffer objects where possible. This encoding will be removed in future versions of Node."

http://nodejs.org/api/buffer.html#buffer_buffer

ascii를 쓰면 1bit가 짤리고 base64를 쓰면 30%가 늘고, hex를 쓰니 배가되는데...

그리고 v8은 어쨌든 VM이기 때문에 GC(Garbage Collection)가 일어납니다. 아마 머지않아 이 문제는 좀더 크게 다뤄지게 될겁니다.

jvm쓰면서 eden이 어떻고 old가 어떻고 하던 시절을 또 만나게 되겠죠. 결국 골방에 앉아서는 이따구 https://developers.google.com/v8/embed 같은걸 머리 쥐어뜯으며 읽는 사람(여기 한명요!)들이 생기게 되겠죠.

윈도우 개발자는 여차하면 바보가 됨.

npm된지 이제 몇 달 안되었고, 아직도 기본모듈에서 버그들이 수두룩..

fs.read fs.unlink도 제대로 안되던게 쪼~금 해결된게 불과 며칠전..

http://blog.nodejs.org/2012/04/09/version-0-6-15-stable/

OS별 path separator는 아예 만들어 놓지도 않아서 기본 모듈 사용할때도 아래와 같은 코드 작성해서 끼워넣어야 함

var PATH_SEPERATOR = PATH_SEPERATOR || (process.platform == 'win32' ? '\\' : '/');

'윈도우즈 환경은 이런 뭐..! 안할래염~' 하는 마음이 여차하면 듬

'윈도우즈도 중요한 플랫폼이다. 적극 지원할 계획이다'고 ryan은 말했지만 정작 joyent 정규직 직원 두 명 중 한 명 인 ryan은 windows는 쓰지도 않는 골수 POSIX 유저. (다른 한 명인 isaac은 말할 것도 없음... 심지어 npm 도움말을 man page로 만들고 그 다음에 웹으로 포팅해 놓았을 정도. 기본 정신세계부터가 windows쪽과는 거리가 멈. http://blog.doortts.com/225 중에서 'npm'이 약어라면, 왜 대문자로 표시하지 않죠? 항목참조)

그리고 npm install xxx 했더니 make 찾길래 gcc 설치했더니 이젠 python 깔라고 하는건 대체...

OS를 전.혀. 고려하고 있지 않은 다채로운 모듈들! (어디다 좀 써놓으삼!)

msysgit에 unix util로는 당췌 해결이 안됩니다.

20년전 개발환경으로 컴백.. (아니.. 30년전인가...)

92년도에도 터미널에서 printf로 찍으며 개발했던것 같은데, 3년뒤면 타임머신 자동차로 하늘을 날아야 할 것 같은 2012년에 vi로 파일 열고 console.log 명령으로 변수 찍고 있는 자신을 발견..

자리에 일어나서 때때로 복고춤이라도 한번씩 추어야 할까요..

거기다 디.버.깅..

댄니 발달된 debugging 환경이란게 겨우 크롬브라우저..https://github.com/dannycoates/node-inspector 딴에는 잘 해보겠다고 eclipse도 띄워봤는데 https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Applications-Debugger 여전히 에디팅은 sublime text 씁니다. 상용 IDE인 intellij도 써봤는데 debugging할때 object inspect가 안되서 당황하며 포기. (update: 최근 버전에서는 object inspect 지원된다고 적혀있네요.)

개발자 ryan은 어떻게 하나 봤더니 gdb를 쓰세요 드립! 아.. 맞다.. 얘는 POSIX 매니아였지...

아...

이크! 시간이! 이제 자야겠네요.

잘 아는양 주절주절 써댔지만, 사실 자바스크립트 + node.js 시작한지가 그닥 오래되지 않아서, 여전히 모르는게 많고 어색어색합니다.

에.. 또 기타 다른 이야기는 또 할게요. :)

ps. 아.그리고... 아침이 일어나서 회사가서 봤더니 이 글이 부끄러워지면 지울지도 몰라요. ㅎㅎㅎ

-- 아침에 추가 --

생각보다 많이 부끄럽진 않네요. ㅎㅎ

update

ES5 strict mode는 2011년 8월이후 버전(크롬13)이후 부터 지원함. 따라서 node도 현재는 strict mode를 지원합니다.

'node.js (OctoberSkyJs)' 카테고리의 다른 글

OctoberSkyJs 세 번째 모임 후기 (0)	21:23:42
OctoberSkyJs 근황 및 모임 안내, 향후 계획 등등의 이야기 (2)	2012/04/19
이쁜 자식 매 하나 더 준다는 심정으로 쓰는 node.js 이야기 (0)	2012/04/13
node.js를 학습하는 사람이라면 꼭 봐둬야 할 Node.js 소개 동영상 해설 (0)	2012/03/10
[node.js] 토요일밤에 node.js 동영상 함께 보기 이벤트! (2)	2012/03/02
[node.js] Connect 2.0 소개 (0)	2012/02/29

누가 로저 래빗을 모함했나? (개발생산성을 높이라구요? #2)

doortts — Fri, 23 Mar 2012 16:54:33 +0900

[Who Framed Roger Rabbit (1988)]

[관련글] 개발 생산성(productivity)을 높이라구요?
http://blog.doortts.com/182

무언가 일을 하는데 있어서 '잘' 하는 것은 참 중요합니다.

그냥 빨리 하는 것이 중요할 때도 있지만, 기본적으로는 무언가 일을 할때 제대로, 잘 하는 것이 중요합니다. 적지 않은 기간동안 많은 비용을 치루고, 또 치루는 것을 보면서, 때로는 치루지 않고 잘 넘어가는 것을 보면서 느낀 점입니다.

제가 이렇게 말할 수 있는 데는 제가 하는 일과도 연관되어 있습니다. 저는 개인이나 조직이 일을 진행할때 어떻게 하면 '잘' 할 수 있는 지를 찾아내서 알리는 일을 하고 있기 때문입니다. : )

저는 뛰어난 개인 이나 조직의 특성을 연구하고 관찰하고, 그 안의 DNA를 발췌해서 전달한 다음 다시 관찰하고 다시 수정해서 반영하는 일을 합니다. 그러다보니 중간 중간 뽑혀져 외부로 나온 것이 Agile이고 TDD이고 Play Framework이었고 MongoDB였었습니다.

그런데 그건 외부로 드러난 현상에 가깝고, 실제로는 앞서 말했듯이 '잘' 하는 방법을 찾고 그걸 막는 문제(blocker)를 찾아서 사람과 조직을 좀 더 유연하고 우수하게 만드는 것이 제가 하는 일의 기본방향입니다. 그리고 실제로 그렇게 해서 절대 '생산량'이 아닌 상대 '생산성'을 높인 사례들을 만들어가기도 하고 때로는 제대로 하지 못해 혹독한 비용을 치루기도 하면서 자연스레 '잘' 하는 것이 '참' 중요하구나 라고 더더 느끼게 되었습니다.

그런데, 왜 잘하는 것이 중요할까요?

너무 뻔한 질문 처럼 들리기도 합니다만, 어쨌든 요즘 같은 급변하는 세상속에서는 '속도'가 훨씬 중요한것 아닐까요?

속도를 부정하는 건 아닙니다만, '잘'한다는 것은 기본적으로 '지속성'과 연관이 깊습니다. 한번 불타오르고 사그라들어 재가 되어버리면 '지속'가능하지 못한 방법일 뿐더라 부작용도 큽니다. 그래서 무언가 장기적으로 일을 할 때에는 당장의 효과에 앞서 '지속성'에 관심을 기울여야 합니다. 예를 들자면,

- 일을 많이 빨리 하는데만 집중한 조직은 '조직 이름'은 오래 갈 수 있어도 조직 구성원은 오래 남아 있기 어렵습니다. (물리적인 것 뿐아니라 정신적인 면까지 포함해서 말입니다. :)

- 또 프로그램의 작성법만 배워서 무조껀 열심히 프로그램을 짜면 결국 돌이킬 수 없는 기술적 빚더미(technical debt)위에 올라서서 현재를 버리고 새롭게 재개발 해야 하는 상황이 발생합니다. 대부분의 재개발은 원래 개발만큼의 비용이 들지만, 보통 그렇다고 기존보다 2배 더 많은 기능이 생기거나 2배 더 편해지진 않습니다.

- 이건 스포츠 경기와도 비슷한 데요, 축구의 경우 무조껀 열심히, 빨리 운동장을 뛴다고 결과적으로 좋은 경기가 되고 좋은 선수가 되지 않는 것과도 유사합니다. 물론, 경기 뒤에 고생했다면 등을 두드려주는 심정적인 위안은 될 수 있겠죠.

그런데 사실 여기엔 한 가지 결정적인 갈등적인 요소가 있는데요, 바로 '잘' 하려면 시간과 돈이 든다는 점입니다. 그리고 최초의 마찰력을 이겨내고 움직이는데까지는 시간과 돈 뿐 아니라 '좋은 자질'의 사람들도 함께 필요한데요, 마찬가지로 가속도가 생기기 전까진 계속 비용 투자가 필요합니다. 정지상태에 남으려는 관성을 이겨내서 계속 속도를 높여 앞으로 나갈 있게 되려면 개개인에게 속칭 Do Things Right DNA가 생겨야 합니다.

그걸 바탕으로 기술, 도구, 프로세스가 함께 발전되고 전달되어 세대를 거쳐 꾸준히 계속 계승되어야 비로서 그 사람의, 그 조직의, 그 회사 만의 고유한 DNA로 남게 됩니다. 한때의 유행이나 바람이 안되고 말입니다.

[....??]

여러모로 이런저런 생각을 해 봐도, 현재 일을 보다 '잘' 하기 위해 노력하는 일은 그냥 그대로 따르는 것에 비해 쉬운 일이 아니고 또한 그런 분위기와 문화가 조직의 DNA로 남는 데는 비용이 많이 드는 일인 건 맞습니다 : )

그러다보니 종종 비용논리, 시장논리, 효율논리로 무시되곤 합니다. 생산성보다는 생산량이 더 중요해지고 눈에 보이는 숫자들과 그래프등의 지표가 무기가 되어 공격을 받곤 하죠. 그리고 이런 숫자나 지표에 집중하게 되는데, 사실 이런 것들은 상대적으로 측정하기 쉽고 개선이 용의합니다. 즉, 어려운 환경에서 선택하는 손쉬운 방법 1번이 되는 거죠. 흔히 '측정할 수 없으면 개선할 수 없다'란 말이 정설처럼 받아들여지는 분야들이 있습니다만, 그렇다고 측정할 수 없는 것들은 중요하지 않다는 것은 아니란 걸 잊으면 곤란합니다.

그리고 한편으론 이렇듯 측정하기 쉬운 것을 목표로 삼는 건 매우 위험한 일이 되기도 합니다. 특히나 '조직'측면에선 더더욱 그런 위험이 큽니다.

이를테면 다음 중 어느것이 더 측정하기 쉬울까요?

"2배의 비용을 들여서 2배 많은 물건을 만드는 것이 유리한가, 2배 더 감동적인 혹은 2배 편리한 물건을 만드는 것이 유리한가?"

[이미지출처: how-to-spark-employee-engagement-and-business-productivity]

당연히 2배 더 많은 물건을 만드는 것이 더 측정하기 쉽고 접근하기 쉬울겁니다만, 결국 조직을 가치 있는 조직을 만들고 더 멀리 더 오랫 동안 나아가게 만드는 건 제가 본 경우엔 측정하기 쉬운 쪽이 아니었습니다.

사실, 이런저런 이야기 계속해야 진부한 이야기이고요, 제가 하려는 이야기는 이렇습니다. : )

혹시라도 '잘'하는 것 보다 '많이 하는 것'에 시달리고 계시다면, 그리고 뭔가 석연치 않다고 느끼고 계시다면 기운내세요.

우리의 선배의 선배의 선배들이 이미 많은 비용을 치루고 그 댓가로 우리에게 전달해 준 이야기들은 그들이 우리에게 준 선물이고 가치 매기기 어려운 가치 있는 이야기들 입니다. 때로는 그게 'SW공학'이라는 이름으로 우리에게 전달 되기도 하고 엔지니어링 테크닉으로, 때로는 Agile이나 Entrepreneur 같은 가치와 단어로 전달되기도 합니다.

그리고 좋은 점은 마치 오랜 속담을 듣는데 돈을 내진 않지만, 값진 교훈을 주는 것 처럼 원한다면 언제든 자신에게 큰 가치를 주는 것이 될 수 있다는 점입니다.

: )

'이생각 저생각' 카테고리의 다른 글

어떤 일을 오래 할 수 있는 어떤 방법 (2)	2012/04/14
누가 로저 래빗을 모함했나? (개발생산성을 높이라구요? #2) (0)	2012/03/23
좋다는 그 기술이 안 좋게 느껴지는 이유 (7)	2012/02/22
NHN 신입사원 교육 후기 (TDD교육과 팀 프로젝트) (5)	2012/02/21
2011 개인 SNS글 중 기억하고 싶은 생각, 그리고 나누고 싶은 메모 (3)	2012/01/01
<행사안내> NHN 공개 개발자 교육 "레거시 코드에서 작업하기 with TDD, 젠킨스 워크샵" (0)	2011/12/19

node.js를 학습하는 사람이라면 꼭 봐둬야 할 Node.js 소개 동영상 해설

doortts — Sat, 10 Mar 2012 00:31:32 +0900

지난 토요일(3월3일)에 node.js 기간한정 학습공유 모임인 OctoberSky.js의 동영상 함께 보기 이벤트를 가졌었습니다.

[토요일밤에 node.js 동영상 함께 보기 이벤트!]

정리도 할겸해서 해설문서를 만들어 보았습니다.

Ryan Dahl이 2010년 JSconf에서 발표한 동영상입니다. 라이언 달의 초기 발표라 그런지 엄청 떨면서 이야기를 하는데다가 말도 어버버~ 하는 경우가 많습니다만, Node.js를 본격적으로 학습해 볼 생각이 있으시다면 한 번 꼭 보시길 권장하는 동영상입니다. 동영상 보실 때 도움이 될 수 있도록 라이언의 발표 문장에 주석과 해석을 담았습니다. 따라서 동영상과 함께 보시길 강력히 권장합니다. 번역과 주석이 섞여있고 개인적인 의견도 다수 들어있습니다. 너그럽게 봐주세요. : )

pdf 직접 다운로드:
node-js-introduction-doortts.pdf

Ryan Dahl의 Node.js 소개 동영상 해설 by doortts

'node.js (OctoberSkyJs)' 카테고리의 다른 글

OctoberSkyJs 근황 및 모임 안내, 향후 계획 등등의 이야기 (2)	2012/04/19
이쁜 자식 매 하나 더 준다는 심정으로 쓰는 node.js 이야기 (0)	2012/04/13
node.js를 학습하는 사람이라면 꼭 봐둬야 할 Node.js 소개 동영상 해설 (0)	2012/03/10
[node.js] 토요일밤에 node.js 동영상 함께 보기 이벤트! (2)	2012/03/02
[node.js] Connect 2.0 소개 (0)	2012/02/29
[node.js 따라배우기 07] 노드 라이브러리 버전들, 제이드 트릭, 에러페이지 (Node Library Versions, Jade Tricks, Error Pages) (0)	2012/01/10

[node.js] 토요일밤에 node.js 동영상 함께 보기 이벤트!

doortts — Fri, 02 Mar 2012 15:05:24 +0900

미루고 미뤄왔던 octoberskyjs 모임의 node.js 동영상 함께 보기 두 번째 이벤트입니다.

라이언 달이 야후에서 발표한 자료이고요, 지난번에 봤던 PHP 그룹에 발표했던 내용보다 좀 더 깊이있게 들어가는 내용(설계원칙, 실행스택에 대한 설명등)이 나옵니다. 물론 이전과 겹치는 부분도 좀 있습니다만 들을만 합니다. : )

그럼 토요일 밤에 모여서 재잘대며 함께 공부해 볼까요?
(참가의사 댓글 완소환영!!!)

동영상
Ryan Dahl: Introduction to Node.js

동영상에서 사용한 슬라이드
http://nodejs.org/cinco_de_node.pdf

시간
내일 토요일(3월3일) 밤 11시

장소
octoberskyjs 채팅방 (작년말에 joyent에 띄워 놓은게 아직 살아있네요! ㅎㅎ)
octobersky.no.de

기타참고자료

2010 jsconf 봄 자료
http://nodejs.org/jsconf2010.pdf

2010 jsconf 가을 자료
9 Challenges in Node.js

'node.js (OctoberSkyJs)' 카테고리의 다른 글

이쁜 자식 매 하나 더 준다는 심정으로 쓰는 node.js 이야기 (0)	2012/04/13
node.js를 학습하는 사람이라면 꼭 봐둬야 할 Node.js 소개 동영상 해설 (0)	2012/03/10
[node.js] 토요일밤에 node.js 동영상 함께 보기 이벤트! (2)	2012/03/02
[node.js] Connect 2.0 소개 (0)	2012/02/29
[node.js 따라배우기 07] 노드 라이브러리 버전들, 제이드 트릭, 에러페이지 (Node Library Versions, Jade Tricks, Error Pages) (0)	2012/01/10
[node.js 따라배우기 06] 인터페이스 기본 (Interface Basics) (0)	2011/12/08

[node.js] Connect 2.0 소개

doortts — Wed, 29 Feb 2012 10:50:18 +0900

우리의 미치광이 개발자 TJ Holowaychuk가 Connect 2.0 을 공개하였습니다. Express의 근간이 되는 모듈이죠. 곧 Express 3.0이 나올예정인데요, Express 사용자라면 한번쯤 봐두면 도움이 될 겁니다. : )

Connect 2.0

새로운 코어 미들웨어와 여러가지 개선사항, 그리고 새로운 문서들(docs)과 함께 하는 Connect 2.0입니다.

var app = connect()
  .use(connect.logger('dev'))
  .use(connect.static('public'))
  .use(function(req, res){
    res.end('hello world\n');
  })

 app.listen(3000);

HTTP and HTTPS

기존 connect.Server는 노드의 코어인 net.Server를 상속했는데요, HTTP와 HTTPS를 모두 제공하기가 어려웠습니다. 이전에는 connect.createServer()였습니다만 이제 새로운 connect() 는 간단한 자바스크립트 함수입니다. 따라서 이젠 아래와 같은 식으로 app.listen()호출을 생략하고 app을 노드의 net.Server로 간단히 넘길 수 있습니다.

var connect = require('connect')
  , http = require('http')
  , https = require('https');

var app = connect()
  .use(connect.logger('dev'))
  .use(connect.static('public'))
  .use(function(req, res){
    res.end('hello world\n');
  })

http.createServer(app).listen(80);
https.createServer(tlsOptions, app).listen(443);

Body parsers

bodyParser() 미들웨어는 이제 단순히 json(), multipart(), 그리고 urlencoded() 를 추가하는데 쓰는 축약표현에 불과합니다. 해당 함수들은 파싱된 값들을 req.body 에 담습니다. 그리고 multipart()는 업로드를 위해 req.body와 req.files를 제공합니다.

== bodyParser 소스코드 ==
exports = module.exports = function bodyParser(options){ var _urlencoded = urlencoded(options) , _multipart = multipart(options) , _json = json(options); return function bodyParser(req, res, next) { _json(req, res, function(err){ if (err) return next(err); _urlencoded(req, res, function(err){ if (err) return next(err); _multipart(req, res, next); }); }); } };

Core compression

Node 0.6.0에서 빠른 네이티브 압축능력들을 제공하는 관계로, 이제 우리도 gzip과 deflate를 지원하는 compress() 미들웨어를 갖게 되었습니다.

Cookie parser

cookieParser() 미들웨어는 이제 싸인된 쿠키들(signed cookies)과 secret을 받아들입니다. 해당 기능은 session({ secret: string })을 session()미들웨어로 넘길 필요성을 교체하였습니다. 싸인된 쿠키들은 req.signedCookies를 통해서, 그리고 싸인되지 않은 쿠키들은 req.cookies를 통해 사용가능합니다.

Error delegation

이전의 몇몇 코어 미들웨어는 에러 상황들에 직접 응답해야 했었습니다.. 해당 사항들은 단순히 next(err) 를 함게 쓰는 걸로 변경되었습니다. 이렇게 변경함으로써 에러 핸들링 미들웨어를 추가함으로써 커스터마이즈된 행동들을 지정하는 것이 가능해졌습니다.

app.use(function(err, req, res, next){
  if (4 == err.status / 100) {
    // render a client-error page
  } else {
    // render a server-error page
  }
});

Session

앞서 언급했던 것처럼 session()은 더이상 secret을 필요로 하지 않습니다. .maxAge 쿠키는 null이 기본값이었는데요, 브라우저 세션쿠키가 된다는 뜻이고요, 방문자가 브라우저를 닫으면 만료됩니다.

Third-party middleware

서드파티 미들웨어는 완벽하게 동작 합니다만 이번 Connect 릴리즈는 Express 2.x 와 호환되지 않습니다. 곧 Express 3.0 이 나올예정입니다.

Changelog

공개된 API에 영향을 주지않는 것들을 포함해서 다음과 같은 중요한 변경이 이루어졌습니다. 마찬가지로 Mocha를 사용해서 테스트를 다시 다 작성했습니다.

쿠기만으로 동작하는 세션을 위한 cookieSession() 미들웨어 추가
gzip/deflate 지원을 위한 compress() 미들웨어 추가middleware for gzip / deflate support
X-Forwarded-Proto 인증을 위한 session() “proxy” 세팅 추가
"application/json" 파싱용 json() 미들웨어 추가
"application/x-www-form-urlencoded" 파싱을 위한 urlencoded() 미들웨어 추가
"multipart/form-data" 파싱을 위한 multipart() 미들웨어 추가
cookieParser(secret) 지원. 이 미들웨어를 통하면 싸인된 쿠기에 접근할 수 있음
cookieParser()가 싸인된 쿠키를 지원함
cookieParser()가 직렬화된 JSON 쿠키를 지원함
Connect의 기본 엔드포인트(default end-point)에서 err.status를 지원함
staticCache()에 X-Cache MISS / HIT가 추가됨
퍼블릭 res.headerSent에 res._headerSent 노드를 먼저 체크하는 것이 추가됨
basicAuth()는 req.remoteUser에서 req.user로 변경됨
Changed: session() 기본값이 브라우저 세션 쿠키로 변경됨
Changed: 소문자 쿠키이름을 더이상 지원하지 않음
Changed: bodyParser()가 json(), urlencoded(), multipart()를 이용함
Changed: errorHandler()는 이제부터는 개발시 모드 전용 미들웨어가 됨
Changed: 미들웨어에서 에러가 발생할 수 있으면 next()를 이용해서 애플리케이션이 로깅과 핸들링을 단일화 할 수 있음
http[s].Server 의 상속관계를 제거함. 이제부터는 그냥 함수니까 http, https 둘 다 제공하는 앱을 만드는게 더 쉬어짐
Removed: .createServer() 제거됨 (connect() 사용하삼)
Removed: session()에서 secret 옵션을 제거함 cookieParser(secret) 사용하삼
Removed: connect.session.ignore 배열지원 제거
Removed: router() 미들웨어 제거
Fixed: set-cookie only once for browser-session cookies
Fixed FQDN support 수정됨. 앞에 “/” 붙이지 마세요
Fixed 404 XSS attack vector. Closes #473
Fixed HEAD 가 Connect 의 엔드포인트에 의해 생성된 404s 와 500s 를 지원하도록 변경됨

'node.js (OctoberSkyJs)' 카테고리의 다른 글

node.js를 학습하는 사람이라면 꼭 봐둬야 할 Node.js 소개 동영상 해설 (0)	2012/03/10
[node.js] 토요일밤에 node.js 동영상 함께 보기 이벤트! (2)	2012/03/02
[node.js] Connect 2.0 소개 (0)	2012/02/29
[node.js 따라배우기 07] 노드 라이브러리 버전들, 제이드 트릭, 에러페이지 (Node Library Versions, Jade Tricks, Error Pages) (0)	2012/01/10
[node.js 따라배우기 06] 인터페이스 기본 (Interface Basics) (0)	2011/12/08
[node.js 따라배우기 05] 인증과 세션, 접근제어 미들웨어 (0)	2011/12/06

좋다는 그 기술이 안 좋게 느껴지는 이유

doortts — Wed, 22 Feb 2012 08:10:00 +0900

흔히 사람들이 쓰기 어려워 하거나 곧 잘 실수하거나 문제를 만들곤 하는 제품이나 라이브러리, 프로그래밍 언어들이 있다. 이런 경우 해당 분야 전문가나 경험자들은 종종 '잘 쓰면 전혀 문제없다'고 말한다. 틀린 이야기는 아니다.

그런데 다소 비평적으로 들리긴 하겠지만 사실 '잘 사용해도 안 좋은 기술'은 거의 없다. 그보다는 '많은 주의를 기울일 필요 없이 쉽게 써도 문제가 없어야' 좋은 기술이라고 난 생각한다.

열심히 공부해도 잘 안되는 건 안되는 거다. 많은 사람들이 어려워 하면 어려운거다. 어느 정도 인정은 했으면 좋겠다.

물론 '좋은 기술'이라는 말 자체가 상당히 모호하고 상황 의존적인 표현이지만, 좀 더 대중적으로 구분할 필요가 있다.

원래 쉬운 거랑 익숙해 져서 쉬운 걸 말이다.
그리고 원래 좋은 거랑 잘 써야 좋은 걸 말이다.

ps.
이 글을 읽으시는 분 중에서 혹시 그런 제품/경험/기술이 있다면 어떤 것이 있으세요?

'이생각 저생각' 카테고리의 다른 글

어떤 일을 오래 할 수 있는 어떤 방법 (2)	2012/04/14
누가 로저 래빗을 모함했나? (개발생산성을 높이라구요? #2) (0)	2012/03/23
좋다는 그 기술이 안 좋게 느껴지는 이유 (7)	2012/02/22
NHN 신입사원 교육 후기 (TDD교육과 팀 프로젝트) (5)	2012/02/21
2011 개인 SNS글 중 기억하고 싶은 생각, 그리고 나누고 싶은 메모 (3)	2012/01/01
<행사안내> NHN 공개 개발자 교육 "레거시 코드에서 작업하기 with TDD, 젠킨스 워크샵" (0)	2011/12/19

NHN 신입사원 교육 후기 (TDD교육과 팀 프로젝트)

doortts — Tue, 21 Feb 2012 14:44:24 +0900

NHN도 신입사원 교육을 합니다. 꽤 적지 않은 기간 교육을 시키죠. 이번 신입사원 차수의 경우에는 작년 하반기에 인턴으로 이미 일을 했던 신입들입니다. 처근 저는 후반기 SW엔지니어링 교육 과정들 중에서 테스트주도개발(TDD)과정과 팀 과제 지도 강사로 참여했습니다. 어제 과제 발표를 마지막으로 이번 차 수에서의 제 역할은 끝났습니다.

간단한 후기를 남겨 봅니다.

- 27명, 한 반 이었고 여자는 1명이었습니다. (남고 분위기?)
- 역시 신입은 신입이라 그런지 풋풋합니다. (예외는 있음. 미안~ㅋ)
- 무엇보다 놀라점은 TDD로 만들어낸 팀 프로젝트의 단위 테스트 케이스 수준이 전반적으로 굉장히 우수합니다.
(제가 잘 가르쳐서 그런거라고 믿고 싶어요.ㅎㅎ) 기존 선배들은 긴장 좀 해야 할 것 같습니다.
- 소감 발표때 TDD가 도움이 되고 참 좋다는 걸 알게되었다는 이야기가 많았습니다.
- 그리고 마음이 급해지니까 어렵다는 이야기도 많았고요.
- 교육 끝나고 '차장님, 감사합니다'라고 보낸 어느 신입의 문자에 저도 고마운 마음이 들었습니다.

추가로, 팀 과제 진행 환경을 살짝 이야기 하면

- UI는 없이 엔진만 개발
- 설계 방식과 개발 방식은 가이드를 해줌
- 요구사항을 제공하고 기능목록부터 작성하도록 함
- 적지 않은 스트레스 환경과 시간압박 상황하에서의 대처능력을 요구했음
- Hudson CI 서버를 구축해서 복잡도와 테스트 케이스 깨짐에 대해서 지속적으로 모니터링 하도록 유도함
- 개발환경은 이클립스, Maven, EclEmma, CheckStyle, Subversion (subclipse, subversive는 알아선 선택)

[팀 과제 결과 발표하는 모습]

(본인들은 정작 잘 모르겠지만) 이번 신입들은 제 기준으로 봤을 때 가장 발전되고 적지않은 기간동안 연마된 TDD Best Practice들을 배웠습니다. 살짝 부연설명을 하자면, 제가 TDD실천법과 도구라는 책을 출간한 것이 2010년 6월입니다. 그리고 그 책을 쓰기 위해 1년여의 시간을 들였기 때문에 실제적으로는 지금으로부터 2~3년전의 '저의 지식'을 담고 있습니다. TDD라는 것이 특별히 유행을 타거나 최신기법이 필요로 하는 부분은 아닙니다만, 시간은 흘렀고 저도 경험이 늘었고 그 당시에 비해 추가적으로 생각이 살짝 바뀐 부분들, 그리고 새로 배운 좀 더 우아한 방법들, 실패하지 않기 위한 기법들 등등이 있습니다.

언제 그런 부분들을 책으로 정리할까, 아니면 오프라인 강의를 할까 고민중입니다만, 우선은 기회가 있을 때 그 때 그 때 전달하고는 있습니다. (책으로 전달하기에는 또 분량이 책을 쓸 만큼은 안되는 것 같고요)

이번 신입교육에도 그랬고요. 너무 신입이라는 점이 조금 아쉽습니다만, 반면에 기존 선배들 보다는 흡수력이 더 빠른 장점은 있죠

물론 한정된 시간이고, 신입의 수준이 있기 때문에 전부를 전달 해 줄 수는 없었습니다만, 가능한 범위내에서 해당 내용들을 전달해 최대한 전달해 주었습니다. 아마, 중간에 포기하지만 않는다면 기존 선배들보다 훨씬 짧은 기간동안에 훨씬 잘 할 수 있는 기초는 배운 셈입니다.

교육 이라는 것은 '모르는 걸 배우는 것'도 있지만 '시행착오를 줄이고 경험을 전달받아 특정 레벨에 도달하는 시간을 줄이는 것'도 있습니다. 그런면에서 이번 신입들은 본인들은 잘 모르겠지만 소중한 것들을 많이 배웠습니다. (아. 정확히는 그랬어야 합니다.ㅎㅎ)

작년에는 신입교육을 하지 않았었는데 2년 만에 다시 신입 교육을 했더니, 풋풋한 신입을 보며 또 저도 많이 배웁니다.

ps.
'이바닥에서 일 한지 올해가 햇수로 13년째입니다.'라고 이야기를 했더니 다들 절 살아있는 유물 보는듯한 표정을 짓더군요. -,-); 신입들이 경력 20년 넘으신 분을 보면 산삼보듯 할까요?

'이생각 저생각' 카테고리의 다른 글

누가 로저 래빗을 모함했나? (개발생산성을 높이라구요? #2) (0)	2012/03/23
좋다는 그 기술이 안 좋게 느껴지는 이유 (7)	2012/02/22
NHN 신입사원 교육 후기 (TDD교육과 팀 프로젝트) (5)	2012/02/21
2011 개인 SNS글 중 기억하고 싶은 생각, 그리고 나누고 싶은 메모 (3)	2012/01/01
<행사안내> NHN 공개 개발자 교육 "레거시 코드에서 작업하기 with TDD, 젠킨스 워크샵" (0)	2011/12/19
새 프로젝트(nFORGE)에 합류 그리고 첫 번째 회고 (2)	2011/12/15