git commit --author "github_id <github@registered.email>"

하면 공용계정으로 커밋할 때도 author정보를 확실히 할 수 있다. 

원본 글: Understanding node.js

*잘못된 번역이 있을 수 있습니다. 원본 글을 참고해주세요. node.js 를 위한 좋은 입문 글이라고 생각해서 번역해보았습니다.

node.js 이해하기

node.js를 소개하면, 사람들은 보통 두 가지 반응을 보인다. 기본적으로 사람들은 "이해했음" 하고 바로 말하거나, 아니면 엄청 혼란 스러운 상황에 처하고 만다.

 만약 당신이 후자의 경우라면 나는 이렇게 노드를 설명해 보겠다. 

* 이것은  command line tool  이다. 당신이 tarball(tar file)을 다운 받고 컴파일해서 설치하면 된다. 

* 노드는 당신이 'node my_appjs'라고 터미널에서 치면  자바스크립트 프로그램을 실행하도록 한다

* JS는  V8 자바스크립트 엔진(구글 크롬을 엄청 빠르게 해주는)에 의해서 실행된다. 

* 노드는 네트워크와 파일 시스템에 접근하는 자바스크립트 API를 제공한다. 

"그렇지만 나는 내가 필요한걸 루비랑, 파이선이랑, php랑 자바로 다 할 수 있어..!"

무슨 말인지 알겠다ㅇㅇ. 그리고 당신의 말이 옳다. 미안하지만 노드는 당신의 일을 대신 다 해줄 미친 유니콘이 아니다. 이것은 그냥 툴이다. 그리고 최소한 지금 버전으로는 아마도 당신이 사용하던 기존의 툴을 완벽하게 대체하지 못할 것이다. 

"그래서 본론이 뭐야!"

본론으로 들어가겠다. 노드는 기본적으로 당신이 동시에 여러가지 일을 해야할 때 무척 좋다. 코드를 짜고나서 "이게 동시에 동작하면 좋겠다" 하고  말한 적이 있는가? 노드에서는 당신의 코드만 제외하면 동시에모든 것이 동작한다. 

"Huh?"

그렇다. 모든 것은 당신의 코드만 제외하고 동시에 동작한다. 이것을 이해하기 위해서 당신의 코드가 왕이라고 생각하고 노드가 그의 시종들로 이루어진 집단이라고 생각해보라. 

 하루가 시작하면 한 시종이 와서 왕을 깨우고 왕에게 필요한 것이 있느냐고 묻는다. 왕은 자신이 해야할 업무들을 적은 리스트를 주고 조금 더 자러 꿈나라로 떠난다. 시종은 그 업무들을 그의 동료들에게 나누어준후, 각자 일을 하러 간다. 

 일단 한 명의 시종이 업무를 마치면 그는 왕의 숙소 밖에서 보고를 위해 대기한다. 왕은 한 번에 한 명의 시종만 들어오게 해서 시종의 보고를 듣는다. 어떤 경우에는 시종이 나갈 때 왕이 더 많은 업무를 주기도 한다. 

 삶은 좋은 것이라, ? 왕의 시종들은 그의 업무를 동시에 수행하지만, 왕이 집중할 수 있도록 한 번에 하나의 결과만을 보고한다.

"엄청 좋아보이기는 하는데... 이제 시덥잖은 비유는 그만하고 공돌이 답게 설명해줄래?"

물론이다. 여기에 아주 간단한 노드 프로그램이 있다.

코드

당신의 코드는 파일을 읽고 쓰는 두 작업을 노드에게 시킨 후, 자러간다. 일단 노드가작업 하나를 마치면, 그것을 위해 있었던 콜백 함수가 시작된다. 그러나 오직 하나의 콜백 함수만이 동시에 시작할 수 있다. 콜백이 실행을 마칠 때까지, 모든 다른 콜백 함수들은 줄을 서서 기다리고 있다. 거기다가 대기 중인 콜백함수들은 언제 실행될지에 대한 보장이 없다. 

"그래서 나는 코드가 같은 자료구조에 동시에 접근하는 것을 걱정할 필요가 없는건가요?"

그렇습니다! 그것이 바로 자바스크립트 싱글스레드와 이벤트루프 디자인의 아름다움의 전부인 것입니다!

"엄청 좋네요. 그런데 내가 이걸 왜 써야 하죠?"

첫번째 이유는 효율적이기 때문입니다. 웹 어플리케이션에서 당신의 주된 response time 비용은 보통 당신의 데이터베이스 쿼리를 실행하는데 걸리는 시간의 합입니다. 노드를 이용하면 당신은 모든 쿼리들을 한번에 실행할 수 있고, 가장 느린 쿼리를 실행하기 위해 걸리는 response time의  지연 시간을 줄일 수 있습니다. 

또다른 이유는 자바스크립트 입니다. 당신은 브라우저와 당신의 백엔드 사이에서 코드를 공유하기 위해 노드를 사용할 수 있습니다. 또한 자바스크립트는 무척 보편적인 언어가 되어 가고 있습니다. 당신이 과거에파이선, 루비, 자바, php....같은 것들을 했다고 하더라도, 아마 당신은 약간의 JS를 꾸준히 사용해왔을 것입니다. 그렇지 않나요?

그리고 마지막 이유는 빠른 속도 때문입니다. V8은 지구상에서 가장 빠른 동적 언어 interpreter 중 하나로서 꾸준히 선두를 이끌고 있습니다. 나는 다른 언어가 지금의 자바스크립트만큼 공격적으로 이 성장 속도를 이끌어갈 수 있을 것이라고 생각하지 않습니다. 또한, 노드의 I/O 구조들은 정말 가벼워서 당신을 당신의 시스템의 모든 I/O 허용치를 가능한 한 충분히 사용할 수 있도록 도울 것입니다. 

"그러니까 당신 말은 앞으로 내가 모든 앱을 만들 때 노드를 써야 한다는 건가요?"

그에 대한 대답은 예, 그리고 아니오 입니다. 일단 당신이 노드 망치를 휘두르기 시작하면 분명 모든 것이  못으로 보이기 시작할 것입니다. 그러나 당신이 데드라인을 가지고 일하고 있다면 당신은 당신의 결정을 어떠한 기준 위에 두고 싶어할 것입니다. (But if you're working on something with a deadline, you might want to base your decision on:)

- 짧은 response time/ 높은 동시 실행이 중요합니까? 그렇다면 노드는 그에 무척 적합할 것입니다.

 프로젝트가 얼마나 큰가요? 작은 프로젝트는 괜찮습니다. 그러나 큰 프로젝트는 반드시 주의해서 판단해야합니다. (사용 가능한 라이브러리, 버그를 잡기 위한 자원들이나 two upstream 등)

"노드는 윈도우에서도 돌아가나요?"

아니요. 만약 당신이 윈도우를 사용하고 있다면 당신은 리눅스를 사용하는 가상머신(VirtualBox를 추천합니다)을 돌려야 합니다. 윈도우에서 노드를 지원하는 것이 예정되어 있긴 하지만 당신이 unless you want to help with the port 앞으로 몇달 동안 숨을 참지 마세요.

"노드에서 DOM에 접근할 수 있나요?"

"Can I access the DOM in node?"

좋은 질문입니다! 아니오. 돔은 브라우저 거시기한 것이라서(browser thingy), 그리고 노드의 JS엔진(V8) 은 고맙게도 완벽하게 이 모든 엉망진창인 것으로부터 떨어져 있기 때문입니다. 그러나 유닛 테스트를 하는  클라이언트 쪽의 코드와 같은 무척 흥미로운 가능성이 열려 있는 등, DOM을 노드의 모듈로 사용할 수 있는 길이 있긴합니다. 

Excellent question! No, the DOM is a browser thingy, and node's JS engine (V8) is thankfully totally separate from all that mess. However, there are people working on implementing the DOM as a node module, which may open very exciting possibilities such as unit testing client-side code.

"이벤트 드리븐 프로그래밍은 진짜 어렵지 않나요?"

Either way, test driven development can really help you to come up with maintainable designs.

그것은 당신에게 달려있습니다. 만약 당신이 이미  AJAX call을 어떻게 다루는지, 그리고 브라우저에서 유저 이벤트를 어떻게 다루는지 알고 있다면 노드에 적응하는 것은 아무 문제가 되지 않습니다. 마찬가지로 , test driven development 는 당신을 지속 가능한 디자인을 할 수 있도록 도울 것입니다. 

"이런건 누가 쓰고 있나요?"

노드 위키에 보면 아직 완성되지 않은 적은 수의 리스트가 있습니다("Companies Using Node"로 스크롤 하세요). 야후 는 YUI를 위해서 노드를 가지고 실험 중이고 Plurk는 많은 양의 comet을 위해 사용 중이며, Paul Bakaus(jQuery UI 의 유명인사) 는 백엔드에서 노드를 일부 이용해서 엄청나게 재미있는 게임 엔진을 만들고 있습니다. Joyent 는 Ryan Dahl(노드의 창시자)를 고용해서 개발을 힘껏 돕고 있습니다. 

아, 그리고 Heroku 역시 (실험적으로나마) 주도적으로 node.js를 돕겠다고 공언했습니다.

"나는 이제 어디에서 더 배울 수 있죠?"

Tim Caswell은 How To Node라는 아주 좋은 블로그를 운영하고 있습니다. 트위터에서 #nodejs를 팔로잉 하세요 .그 메일링 리스트를 구독하세요. 그리고 IRC 채널의  #node.js(네. 저 점도 이름 안에 포함되어 있는 겁니다)에 와서 둘러보세요. 우리는 이제 200 lurker-mark 를 곧 찍을 예정입니다 :) .

그리고 나는 이 debuggable.com에도 꾸준히 글을 쓸 예정입니다. 

지금으로써는 이 정도가 다네요. 질문이 있다면 댓글을 달아주세요.

--fg

*: 위에 나온 비유는 엄청 단순화한 것입니다. 그렇지만 논블라킹의 개념을 현실세계에서 딱 떨어지게 맞는 것을 찾기가 어려웠네요. 

0.0.0.0 을 뽑아내고 싶어서 

했는데 일단 assert는 패스하지만 내가 원하는 패턴만 뽑히지 않는다. ㅠㅠㅠ

으로도 중복해서 걸리고 있음...ㅠ