Development/node.js2017.04.06 05:36

node.js 를 사용하면서 가장 애를 먹는 것중 하나가 설치한 모듈을 찾지 못한다는 메세지를 만날때 입니다. 환경에 따라 모듈의 설치 경로가 달라질 수 있고, node.js 가 설치된 모듈을 찾아가는 순서에 영향을 받기 때문입니다. 간단한 몇 가지 명령을 통해 node.js 가 어떤 순서로 모듈을 탐색하는지 확인하고 글로벌 모듈로 설치된 경우 이를 명시적으로 node.js 가 이용할 수 있도록 알려줌으로써 어느정도 문제를 해결할 수 있습니다.


아래와 같이 npm 에서 -g 옵션을 이용하여 모듈을 설치하면 글로벌 모듈로 설치가 됩니다. 프로젝트에 관계 없이 설치된 모듈을 이용할 수 있어야 하는 것이지요. 일부 환경에서는 sudo 명령을 이용하여 관리자 권한으로 설치를 해야 할 수도 있습니다.


$ npm install -g [#모듈이름#]


또는


$ sudo npm install -g [#모듈이름#]


이렇게 -g 옵션을 이용하여 글로벌 모듈로 설치하는 경우, 그 경로는 어떻게 될까요? 아래와 같은 명령을 이용하여 글로벌 모듈로 설치하는 경우의 Path 를 확인할 수 있습니다.


$ npm root -g

/usr/local/lib/node_modules


간혹 글로벌 옵션을 이용하여 설치한 모듈을 찾을 수 없다고 나오는 문제를 겪고 있다면, 위의 명령으로 확인한 경로를 NODE_PATH 라는 환경 변수에 저장하여 node.js 가 글로벌 모듈을 찾을 때 참조할 수 있도록 명시적인 지정을 할 수 있습니다. 반복적으로 사용해야 하는 값이기 때문에 홈 디렉토리의 .bash_profile 파일에 포함하여 터미널 실행시 셋업되도록 하면 되겠습니다. 윈도 환경에서는 시스템 환경 변수에 넣어주면 됩니다.


~/.bash_profile 에 아래와 같이 환경 변수 추가


export NODE_PATH="/usr/local/lib/node_modules"


글로벌 모듈 이외에 현재 프로젝트에서 모듈을 찾아가는 탐색 순서를 확인하려면 아래와 같이 간단한 자바스크립트 구문을 node.js 를 이용하여 실행해보면 됩니다. 아래의 경로로 모듈을 찾아본 뒤, NODE_PATH 에 지정한 경로까지 탐색하여 현재 환경에서 모듈을 찾고 이용하게 됩니다. 


$ node -e "console.log(global.module.paths)"

[ '/Users/snoh/node_modules',

  '/Users/node_modules',

  '/node_modules' ]


- NoPD -



저작자 표시 비영리
신고
Posted by 노피디
Development2016.09.29 12:47

다량의 데이터를 추출하면 필연적으로 정렬에 대한 필요성이 생깁니다. 정렬이 필요한 순간은 정말 다양하겠지만 대표적인 경우들을 들어보자면, 1) 특정한 조건에 만족하는 로그 라인의 갯수를 오름/내림 차순으로 정렬, 2) 시계열 순으로 로그가 추출되지 않은 경우, 시간 컬럼을 기준으로 로그 라인을 정렬과 같은 것이 있습니다. 1의 경우는 카운트를 위한 명령을 파이프로 연결후 쉽게 정렬할 수 있습니다.


$ cat domain.log | awk '{print $3}' | sort


위의 커맨드는 domain.log 파일을 핸들링하면서 세번째 열을 출력하고 이를 정렬하는 명령어 입니다. 여기에 파이프를 추가하여 유니크(Unique)한 이름을 발라내고, 다시 카운트된 갯수를 기준으로 정렬하려면 아래와 같은 명령을 생각할 수 있습니다.


$ cat domain.log | awk '{print $3}' | sort | uniq -c | sort -rn


그런데 특정한 컬럼을 기준으로 정렬하되 전체 데이터를 유지하려면 awk 명령으로는 왠지 좀 불편한 느낌입니다. 이때는 awk 를 이용하지 말고 sort 명령만으로 정렬하는 것이 더 유리합니다. 


$ cat domain.log | sort -k 3


이렇게 하면, 세번째 컬럼 (이때는 공백으로 각 컬럼이 나뉘어진 데이터라 가정했습니다) 을 기준으로 정렬후 데이터를 출력해 주게 됩니다. 자주 쓰는 명령인데 쓸때마다 자꾸 구글링하게 되어 블로그에 기록해 둡니다!



저작자 표시 비영리
신고
Posted by 노피디
Development/python2016.09.21 04:21

여러 문서들에 따르면 Python 2 의 경우 2.7.9 이상의 버전, Python 3 의 경우 3.4 버전 이상이 설치된 경우 파이썬 패키지 매니저인 pip 가 이미 설치되어 있을 거라고 합니다. 하지만 늘 예외가 있는 법이고, 그 예외는 본인에게 해당되는 경우가 많죠. 설치된 파이썬의 버전 조건이 맞지만 pip 가 설치되어 있지 않다면 아래의 순서대로 pip 를 쉽게 설치할 수 있습니다. 맥을 쓰고 있다보니 brew 로 pip 설치를 하려고 했으나, 파이썬이 중복되어 설치될 수 있다는 경고때문에 따로 설치를 진행했습니다.


먼저, curl 을 이용해서 pip 를 설치하기 위한 파이썬 코드를 다운로드 받습니다. 뭐, 브라우저를 이용해서 소스코드를 로딩하고 파일로 따로 저장하겠다 하시면... 그리 하셔도 말리진 않겠습니다.


$ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py


소스코드가 다운로드 되었다면 실행을 해보겠습니다. 사용중인 환경에 따라 sudo 로 권한 상승을 할 필요가 있다는 점 참고하시기 바랍니다. 


$ sudo python get-pip.py

Collecting pip

  Downloading pip-8.1.2-py2.py3-none-any.whl (1.2MB)

    100% |████████████████████████████████| 1.2MB 927kB/s

Collecting wheel

  Downloading wheel-0.29.0-py2.py3-none-any.whl (66kB)

    100% |████████████████████████████████| 71kB 4.5MB/s

Installing collected packages: pip, wheel

Successfully installed pip-8.1.2 wheel-0.29.0


이제 pip 를 실행해보겠습니다. 잘 되는군요.


$ pip


Usage:

  pip <command> [options]


Commands:

  install                     Install packages.

  download                    Download packages.

  uninstall                   Uninstall packages.

  freeze                      Output installed packages in requirements format.

  list                        List installed packages.

  show                        Show information about installed packages.

  search                      Search PyPI for packages.

  wheel                       Build wheels from your requirements.

  hash                        Compute hashes of package archives.

  completion                  A helper command used for command completion

  help                        Show help for commands.



저작자 표시 비영리
신고
Posted by 노피디
Cloud & Dev. Story2016.08.03 16:43

HTTP/2 시대가 시작되면서 다양한 성능 개선을 위한 사례들을 요즘 찾아보고 있습니다. QUIC 도 그중 하나이고 TCP Fast Open 이라는 표준 역시 살펴봐야 할 사례인 것 같습니다. 공부할 건 많고 시간은 없고 머리는 안돌아가고... 그래도 일단 필요한 링크들을 모아봅니다. 먼저 공부하시는 분들이 계시다면 정리해서 공유를... 굽신...


# TCP Fast Open - TCP 의 3 way handshake 로 발생하는 RTT 및 Latency 의 한계를 극복하려는 노력 / Handshake 할때부터 컨텐츠를 담아 전달해 보자는 것이 요지.



출처 : 구글 기술문서 (아래의 링크5)



링크1 - RFC 7413 - TCP Fast Open (Experimental) : https://tools.ietf.org/html/rfc7413

링크2 - Cent OS 7 + nginx 환경에서 TCP Fast Open 활성화 하기 : https://goo.gl/pRmWZO

링크3 - TCP Fast Open 위키피디가 : https://en.wikipedia.org/wiki/TCP_Fast_Open

링크4 - curl 7.49.0 의 특정 운영체제 버전에서 옵션 제공 : https://curl.haxx.se/libcurl/c/CURLOPT_TCP_FASTOPEN.html

링크5 - 구글에서 발표된 기술 문서 : http://goo.gl/rz1sqX

링크6 - Keycdn 의 아티클 (일종의 요약) : https://www.keycdn.com/support/tcp-fast-open/


- NoPD -

저작자 표시 비영리
신고
Posted by 노피디
HTTP 2.02016.07.04 16:02

웹 컨텐츠 전송을 위한 프로토콜의 대세가 h2 혹은 http/2 로 자리잡아 가면서 맥(Mac)의 쉘에서도 http/2를 테스트 해야하시는 분들이 많이 늘었을 것으로 생각됩니다. 알려진 내용에 따르면 curl 의 7.34.1 버전 이후에는 --http2 옵션을 통해 http2 로 서버와 통신을 하도록 강제할 수 있지만 환경에 따라서 안되는 경우가 많습니다. curl 은 http/2 를 지원하기 위해 nghttp2 라이브러리를 이용하고 있기 때문에 우선은 nghttp2 를 설치해야 합니다.




nghttp2 가 설치되면 이를 이용해서 curl 을 다시 build 하거나 설치해야 합니다. 홈브루(Homebrew)를 이용하면 간단하게 새로운 버전으로 빌드를 하면서 설치할 수 있으니 아래의 커맨드를 참고해서 설치를 진행하도록 합시다. 아래와 같이 설치한 후 brew info curl 명령을 통해 nghttp2 에 초록색 체크박스가 잘 들어왔다면 일단 설치는 제대로 잘 된거라 봐도 되겠습니다.





그런데 여기까지 하고나서도 curl 을 --http2 옵션으로 실행했을 때 지원하지 않는 프로토콜이라고 에러가 떨어진다면 심볼릭 링크를 한번 교체해줄 필요가 있습니다. 환경 설정에 따라, 사용자 계정에 따라 sudo 를 통해서 권한 상승을 해야 할 필요도 있으니 상황에 따라 적절한 옵션으로 심볼릭 링크를 교체해 주시면 되겠습니다. 




여기까지 해서 마무리가 잘 되었다면 curl --http2 옵션으로 http2 가 활성화된 사이트들, 예를 들어서 아카마이의 https://http2.akamai.com 이라던가 구글 메인 페이지 (https://www.google.com) 쪽으로 요청을 던져볼 수 있게 되셨을 겁니다. 일단 개인적으로 여기까지 해서 문제는 없었습니다만 다른 문제를 겪는 분이 계시다면 댓글로 남겨주시면 한번 살펴보도록 하겠습니다!



- NoPD -




저작자 표시 비영리
신고
Posted by 노피디

웹 서버의 응답은 브라우저나 프록시, CDN 등 모든 계층에 있어서 중요한 값입니다. 특히 컨텐츠가 캐시되어야 하는 경우 혹은 캐시되지 말아야 하는 경우에 대하여 정확한 지시자(Directive)를 내려주지 않으면 잘못된 정보가 캐시되고 다른 사용자들과 공유되어 보안사고나 정보 유출이 있을수도 있고, 엉뚱한 컨텐츠가 캐시되어 제대로된 서비스가 제공되지 못할 수도 있습니다. 따라서, 정확한 헤더와 적절한 지시자를 내려주는 것이 중요합니다.


공개되어 있는 완성된 제품 (예: 워드프레스) 을 이용하는 경우에는 솔루션이 적절한 헤더 값으로 응답을 합니다만 직접 모든 것을 개발한 웹 서버, 웹 서비스라면 필요한 값을 적절히 지정해주어야 합니다. 단순한듯 복잡한 HTTP 헤더의 세계이기에 어떤 값을 어떻게 써야하는지 헷갈릴때가 많은데요 이럴때 도움이 될만한 의사결정차트(?)가 있어서 공유해 봅니다. 


출처 : 구글 개발자 문서 (https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching)



no-cache 와 no-store 가 항상 헷갈렸었는데요 no-cache 의 경우 Etag 등이 추가적으로 제공되어야 하며 이를 통해 컨텐츠를 "항상" revalidate 하는 작업이 필요하다는 이야기가 있습니다. 다소 복잡하다면 캐시하면 안되는 컨텐츠는 no-store 를 쓰도록 하는 것이 마음이 편할 것 같습니다 ^^ 캐시할 컨텐츠는 Cache-Contro: max-age=xxx 를 사용하되 private, public 중 어떤 추가 디렉티브를 쓸 것인지도 고민해봐야 겠습니다! Etag 는 이 모든 걸 떠나서 가능하면 넣어주는게 CDN, Proxy 를 대비하는 방법이 되겠습니다!


  • # 구글 개발자 문서 : https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching


- NoPD -

저작자 표시 비영리
신고
Posted by 노피디
Development/node.js2016.04.04 08:58

Node 의 새로운 버전이 릴리즈 되었습니다. Node 는 새로운 버전이 발표될 때마다 LTS (Long Term Support) 버전과 Stable 버전으로 나누어 공개하곤 합니다. 이번에 발표된 버전은 v4.4.2 (LTS) 버전과 v5.10.0 (Stable) 버전입니다. 아시는 분들은 아시겠습니다만 Stable 버전의 경우 이름의 뜻과는 달리 실험적인 기능들을 비롯한 덜 안정적인 기능들이 많이 들어간 버전이며 LTS 버전이 안정적인 버전이라고 생각하시면 되겠습니다.


Node 의 버전을 업데이트 하는 방법은 여러가지 있겠습니다만 개인적으로 추천드리는 방법은 n 을 이용하여 업데이트 하는 방법입니다. n 을 설치하고 사용하는 방법인 예전 포스팅에서 찾아보실 수 있습니다 (관련글 : http://ondemand.tistory.com/220) . n 은 여느 Node 패키지와 마찬가지로 NPM 을 이용하여 설치할 수 있습니다. 




간만에 또 한번 싱가폴에서 열심히 놀고 있는 서버에 접속을 했습니다. 업데이트를 하기 전 n 을 이용하여 현재 설치되어 있는 버전을 확인해 보았습니다. n 명령을 실행하면 현재 설치되어 있는 버전이 열거되며 활성화 되어 있는 버전은 특별히 밝은 색상과 o 표시가 되어 있어 식별이 쉽습니다. 




현재 설치되어 있는 버전이 두가지 이고 활성화된 버전은 4.2.4 로 확인됩니다. 새로 출시된 버전이 4.4.2 버전이니 n 명령을 이용해서 새로운 버전의 LTS 버전을 다운로드 받아 활성화 해보도록 하겠습니다. 명령은 무척 간단해서 n 뒤에 파라메터로 버전명을 기술해 주면 됩니다. 






약간의 시간동안 다운로드를 받고 설치하는 과정이 끝나면 준비 완료입니다. 다시 한번 n 명령을 이용해서 버전을 확인해보면 새로운 버전이 추가된 것을 확인할 수 있고 활성화까지 된것을 볼 수 있습니다. 느낌이 오셨겠지만 n 을 이용하면 현재 머신에서 어떤 버전을 활성화 해서 사용할 것인지도 쉽게 선택할 수 있습니다. 설치된 버전 목록에서 버전 넘버를 확인한 후, 다시 한번 n 명령 뒤에 해당 버전을 기술해 주면 됩니다. 저는 0.10.28 버전으로 다시한번 전환해 봤습니다.




네, 참 쉽습니다 ;-) 


Nodejs.org 공식 웹사이트에서 새로운 릴리즈 확인해보기 [바로가기]






저작자 표시 비영리
신고
Posted by 노피디
Development2016.03.29 16:04

2017.5.4 추가) 혹시 JSON 에서 주석을 어떻게든 써야겠다고 생각되시면 JSON5 규격에 대해서 살펴보시기 바랍니다 [바로가기]


고난이도의 알고리즘을 이용하여 프로그램을 만들다가도 가끔 멍~한 질문에 당황할 때가 있습니다. API 의 사용이 대중화되고 그 중요성이 커지면서 API 좀 다루어 보지 않은 엔지니어를 찾아보기 힘든게 요즈음입니다. API 는 초기에 SOAP 과 같은 오버헤드가 큰 방식들이 사용되다가 요즘은 JSON 형태의 경량화된 포맷이 사실상의 표준 처럼 사용되고 있습니다. 아, 물론 단순한 스트링과 델리미터로 값을 전달하는 경우도 여전히 있습니다만 가독성이나 주고받는 자료의 가독성, 관리 용이성 등의 관점에서 별로 좋은 접근은 아닙니다.


JSON 이 대중화되어 사용되다 보니 API 를 통해 리턴 받은 데이터이든 API 를 향해 던지는 데이터이든 습관적으로 JSON 포맷을 머릿속에서 이해하고 사용하고 있습니다. 그런데 오늘 문득... 그런 생각이 들었습니다. JSON 포맷에는 주석 혹은 코멘트(Comment)를 위한 표준이 정의되어 있는 걸까요? 만약 정의되어 있다면 어떤 형태로 사용해야 하는 걸까요? 이런 고민과 논란이 2012년 즈음에 있었던 것 같습니다. JSON 표준의 창시자로 알려진 더글라스 크록포드(Douglas Crockford)가 구글 플러스에 올렸던 업데이트를 인용해봤습니다.




글씨가 좀 작아서 잘 안보이시는 분들을 위해 본문만 다시 한번 인용해 봤습니다. 절대 블로그 포스팅 분량을 늘리기 위한 행동을 아닙니.......


I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. 


Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.


결론적으로 JSON 에는 주석 혹은 코멘트가 들어가지 않는것이 맞다고 창시자는 이야기하고 있습니다. 상호 호환성과 같은 시스템 간의 연동, 이종 시스템들간의 이해를 방해하지 않게 하겠다는 것이 의도인데요, 꼭 필요한 경우라면 코멘트를 사용하되 최종적으로 JSON 파서들은 코멘트가 제거된 데이터를 핸들링 할 수 있게 하는 것을 이야기하고 있습니다. 실제로 시장에 유통되고 있는 일부 JSON 파서 혹은 구현체에서는 JSON 코멘트를 허용하되 더글라스가 언급한 것처럼 최종적으로는 제거하는 케이스들도 있는 것으로 보입니다.


JSON 을 사용한다면, 조금은 아쉽지만, 주석 / 코멘트를 사용하지 않는 것이 미덕이겠습니다. 꼭 필요하면 내부적으로만 사용하시되 외부와 연동하는 단계에서는 꼭~ 제거하는 센스가 필요하겠네요! 




저작자 표시 비영리
신고
Posted by 노피디
Development2016.03.28 17:38

터미널에서 대량의 로그 데이터를 다루는데 무척 유용한 명령이 awk 입니다. awk 는 기본적으로 파일 내의 컬럼 구분자가 공백이라는 가정하게 동작합니다. 데이터를 추출하려는 원본 로그 파일이 공백을 구분자로 이용하는 경우 문제가 없지만 CSV (Comma Seperated Value) 형태 혹은 파이프와 같은 구분자로 컬럼을 식별하는 경우에는 구분자가 어떤 문자인지 awk 에게 전달해 주어야 합니다.


[ 예시 로그 파일 ]

$ cat domain.log

2016-03-28, 09:00:00, www.samsung.com

2016-03-28, 09:00:00, www.naver.com

2016-03-28, 09:00:00, www.apple.com

...


위와 같이 사용자들이 접근한 도메인에 대한 이력을 정리한 로그파일이 있다고 가정해 보겠습니다. 각 도메인별로 사용자의 요청 횟수를 카운트 하고 싶다면 아래와 같은 명령이 머릿속에 떠오르실 겁니다. 


$ cat domain.log | awk '{print $3}' | sort | uniq -c | sort -rn


하지만 위의 명령은 awk 의 기본 구분자인 공백을 사용하기 때문에 원하는 결과가 제대로 나오지 않게 됩니다. 로그 파일이 콤마를 명시적인 구분자로 사용하고 있기 때문에 아래와 같이 awk 의 파라메터로 구분자를 알려주어야 합니다. 


$ cat domain.log | awk -F ',' '{print $4}' | sort | uniq -c | sort -rn


자주 사용하지만 자꾸만 잊어버리는 명령어들 시리즈였습니다 ;-)


저작자 표시 비영리
신고
Posted by 노피디
Development2016.03.17 17:07

터미널에서 다량의 로그, 텍스트 파일을 핸들링 할때 awk 명령을 파이프로 연결하여 작업하는 경우가 많습니다. 예를 들어 텍스트 파일의 첫번째 컬럼이 "A" 인 행의 세번째 필드를 출력하는 방법은 대략 아래와 같을겁니다.


$ cat sample.txt | awk '$1=="A" {print $3}'


그런데 가끔은 특정한 조건을 만족하는 행의 모든 내용을 출력하고 싶을 때가 있습니다. 컬럼이 몇 개 안된다고 하면 print 명령으로 모든 컬럼을 지정하면 되겠지만 컬럼이 많다면 쉽지 않습니다. 이때는 print 의 파라메터로 $0 을 넘기면 모든 컬럼이 출력되게 됩니다.


$ cat sample.txt | awk '$1=="A" {print $0}'


자주 사용하지 않으면 잊어버리기 때문에 기억을 위해 남겨둡니다.


- NoPD -

저작자 표시 비영리
신고
Posted by 노피디

티스토리 툴바