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

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

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

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

전 node.js 좋아해요. :)

.

.

.

하.지.만..

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

1. 

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

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

2. 

결국 웹앱 만들려면 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 중에서]

3. 

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

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

    a. 

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

    

    b. 

    buffer.toString(encoding, start, end)

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

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

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

4.

 때때로 기원을 알 수 없는 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기반이니 그걸 따라가는데.. 

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

5. 

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

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

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

6. 

좋아! 그럼 난 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를 쓰니 배가되는데...

7. 

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

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

8. 

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

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로는 당췌 해결이 안됩니다.

9. 

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를 지원합니다.