Humming Time

Think Big, start small...

[hummingtime]

OSGi, Hazelcast, Vert.x

가벼운 ESB. 요즘 마이크로 서비스 아키텍쳐에서 말하는 API Gateway. osgi의 동적 로딩, vertx/hazelcast로 메세징과 생산성. 예전부터 이 기술들로 한번 해보고 싶었는데 그 당시 버전에서는 라이브러리들도 osgi를 생각하지 않고 번들링이 되어있지 않아서 일일이 jar파일들을 embed 시키다가 포기. 또 vertx도 다른 노드간의 data sharing이 안된다고 매뉴얼에 떡하니 적혀있어서 포기했었는데 이번에 보니 hibernate도 bundle로 제공되고 hazelcast, vertx 도 osgi를 지원하게 되었다. vertx도 3.0에서는 클러스터간 데이터 sharing이 지원되나보다. 물론 디펜던시 중에 번들 형태가 아닌 것들이 있어서 짜증은 나지만 예전과 달리 좋은 세상이 되었다. 전에는 karaf나 virgo같은 well configured osgi container의 존재를 몰랐었는데 karaf를 사용해보니 쓸만하게 잘 만들어졌다. 현재 karaf상에서 JPA/hibernate 구동에 성공했고 단일 노드에서 vertx eventbus 클러스터링도 확인 했다. 이제 hazelcast로 global cache의 persistency만 확인되면 진행해봐야겠다.

[hummingtime]

camel, blueprint 연동시에 CNE나NCDFE가 sun.misc.Unsafe에 대해 발생하는 경우. osgi 컨테이너의 설정 파일에 아래의 내용을 설정해줘야함.

org.osgi.framework.system.packages.extra=sun.misc org.osgi.framework.bootdelegation=sun.*,com.sun.*

[hummingtime]

문제의 요

문제의 요는 다 씨부리는 거 필요없고. 나 이만큼 힘든데 아무도 몰라주는 것 같은데 나 같은 넘이 널렸다는거. 그게 정치.

[hummingtime]

AWS CloudFormation

puppet 글에서와 마찬가지로 서버 설치 관련 내용들을 형상관리 할 수 있게 된다고 보면 됨. ami는 어떤 것으로 할 것인지 하드 디스크, 네트워크 설정, Route53, EIP 설정 등등을 script로 설정할 수 있게 함. cloud-init을 활용한 cfn-init으로 초기 설치 패키지 설정이나 shell 설정등도 가능함. puppet과 함께 사용하면 인프라 형상관리가 완성되고. 인프라 설정이 자동화 됨.

[hummingtime]

puppet

chef는 안써봐서 모르겠지만 암튼 이런 류의 제품은 굳이 없어도 되지 않나 하고 생각했었는데 대박 필수. 서버에 내가 설치하는 것들과 설정하는 것들에 대한 형상관리가 가능해진다고 생각하면 될 듯. 편리성 같은 것들을 따지지 않아도 이 하나만으로도 필수. 사용하면서 느낀 유일한 단점 - 물론 익숙해지고 나서, 익숙하지 않을때는 모든 것이 단점 - 은 제공되는 module들의 소스를 까보지 않고는 선택하기가 힘들다는 정도. 이건 뭐 요즘 npm이나 docker 저장소들도 마찬가지 문제겠지만. module을 잘 까보고 class이름이 겹치는 것이 없는 지 돌려보고 선택하는게 좋음. 충돌나기 시작하면 대책이 안섬.

[hummingtime]

Visual Studio Code for mac

첫 느낌은 상당히 좋으나 sublime에 비해서 아직 많이 모자름. 그렇게 생각하는 이유는 keyboard 세팅이 아직 마우스 없이 안되는 부분들이 많고 동작이 상식적이지 않은 부분들이 보이고 sublime의 package들과 같은 이렇다할 eco system이 보이지 않음. sublime을 대체하기에는 시기 상조.

[hummingtime]

Node.js -2

서버를 node.js로 open했다.

일단 개발 단계까지는 매우 즐거웠다. eco 시스템이 맘에 들었다. npm 라이브러리들의 quality가 높아서 놀랐고 동적 타입핑과 json의 궁합, 자바스크립트는 정말 기존과 완전 다른 경험을 선사한다.

그에 따른 개발 속도. 실제 분석/설계를 제외하고 코딩시간만으로 본다면 정말 생각하는 데로 코딩이 가능하다고 말할 수도 있을 정도로 빠르다.

문제는 만들고 난 후 발생한다. 디버깅은 정말 극악하다. 정확한 에러를 알기 어렵다. 에러가 발생해도 아주 애매하게 출력되어 나오고 error에 callstack을 채우는 것을 개발자가 알아서 해야하기 때문에 그런 것들을 신경쓰지 않은 라이브러리를 사용하게 되면 callstack이 잘려버려서 무용지물이 된다. 그나마 intellij들에서 remote debugging을 지원하기도 하고 개발 속도를 감안하면 이정도의 희생은 즐겁다.

진짜 문제는 개발 시 성능을 예측하기 어렵다는 데 있다. 이번 작업에서 개발 환경에서 테스트 할때 성능테스트를 할 만한 시간이 없었기도 했지만 워낙 node.js가 빠르다는 말만 들어서 완전 방심한 것도 이유였다.

초당 300정도의 request였기 때문에 만만하게 보고 open을 했는데 업무 로직을 올린 node.js는 300tps를 처리하기에는 버거웠다. req당 한 두번의 db작업이 있었는데 이 작업들이 callback으로 쌓여버려서 점점 더 느려지고 복구가 불가능했다. setInterval이나 setTimeout 등으로 걸어 놓은 작업들이 callback event를 다 처리하고 나서야 처리되니 4,5분의 delay가 생기는 것까지도 관찰되었다. aws를 m3.2xlarge까지 올려도 싱글로 돌아가는 node.js의 성능 개선은 미미하고. 결국 프로그램을 6개로 쪼개서 돌리는 방향으로 급전환 해서 무사히 open했다.

인터넷에서 수없이 보고 그냥 지나쳤던 node.js는 가볍게 짜야한다는 걸 뼈저리게 느꼈다.

node.js로 서버에서 다양한 작업을 처리하려고 하는 사람들은 인터넷 BMT등을 절대 믿지 않았으면 한다. node.js는 실제 환경에서는 웹서버 정도의 용도가 아니라면 절대 느리다 라고 생각하고 접근하는게 낫다.

현재는 node로 작성한 프로그램을 golang으로 옮기고 있다. 하다보니 이 방식도 맘에 든다. node.js로 POC를 하고 실제 개발은 정적인 언어로 하는 방식.

[hummingtime]

Node.js

우물에만 같혀있는 것 같아 회사를 옮겼다. 여태까지 해오던 B2B와 전혀 다른 게임쪽으로. CRUD가 주축이 아닌 다양한 트랜잭션이 발생하고 다양한 사람들과 다양한 기술들. 젊은 피가 만들어낸 빠른 기술에 대한 수렴. 놀랍다. 정말 쓰레기 같아 보이던 완숙하지 않은 기술들을 적소에 배치하여 이익을 취하고. 그 선봉에 클라우드와 nodejs가 있는 것만 같았다. 하지만 그 이면에 개발자를 바보로 만들어 버리는 단점들. 고민이 필요없고 잔머리만 굴리는 상황이 연출되고 있다.

[hummingtime]

Node.js the right way #1

File system

Watching file

const fs = require('fs'); fs.watch('target.txt', function() { console.log("File 'target.txt just changed!" + arguments); }); console.log("Now watching target.txt for changes...");

Reading command-line arguments

// node --harmony watcher.js target.txt const filename = process.argv[2]; // 0 is node, 1 is watcher.js file full path, 2 is target.txt

spawning a child process

/*jslint node: true */ "use strict"; const fs = require('fs'), spawn = require('child_process').spawn, filename = process.argv[2]; if (!filename) { throw Error('A file to watch must be specified!'); } fs.watch(filename, function() { let ls = spawn('ls', ['-lh', filename]); ls.stdout.pipe(process.stdout); }); console.log('Now watching ' + filename + ' for changes...');

capturing data from EventEmitter

/*jslint node: true */ "use strict"; const fs = require('fs'), spawn = require('child_process').spawn, filename = process.argv[2]; if (!filename) { throw Error('A file to watch must be specified!'); } fs.watch(filename, function() { let ls = spawn('ls', ['-lh', filename]), output = ''; ls.stdout.on('data', function(chunk) { //chunk is Buffer. output += chunk.toString(); //toString decodes blob to String }); ls.on('close', function() { /*After a child process has exited and all its streams have been flushed. it emits a close event */ let parts = output.split(/\s+/); console.dir([parts[0], parts[4], parts[8]]); }); });

reading and writing files Asynchronously

read

/* jslint node: true*/ 'use strict'; const fs = require('fs'); fs.readFile('target.txt', function(err, data) { //data is Buffer if (err) { throw err; } console.log(data.toString()); });

write

/* jslint node: true */ 'use strict'; const fs = require('fs'); fs.writeFile('target.txt', 'a witty message', function(err) { if (err) { throw err; } console.log('File saved!'); });

creating read and write Streams

#!/usr/bin/env node --harmony require('fs').createReadStream(process.argv[2]).pipe(process.stdout);

save as cat.js

chmod +x cat.js

./cat.js target.txt

/*jslint node: true*/ 'use strict'; const fs = require('fs'), stream = fs.createReadStream(process.argv[2]); stream.on('data', function(chunk) { process.stdout.write(chunk); }); stream.on('error', function(err) { process.stderr.write('Error: ' + err.message + '\n'); });

blocking the event loop with Synchronous file access

const fs = require('fs'), data = fs.readFileSync('target.txt'); process.stdout.write(data.toString());

[hummingtime]

Cloud storage services

맥에 iCloud가 본격 가동되긴 했지만 맥이나 아이폰 등에서 지들 맘대로 사용하다가 배터질지 모른다는 불안감으로 사용 못하고 있는지라 다른 Cloud storage 서비스들에 대한 개인적인 경험담을 적어본다.

DropBox, OneDrive, Copy, Box, DaumCloud 들을 사용해 보았고 사용하고 있다. NDrive도 가끔 사용하지만 성격이 전혀 다르므로 패스.

일단 DropBox는 가장 적은 용량을 주지만 가장 많은 활용도가 있는 서비스.많은 App들의 공유/백업 용도의 지원을 받고 있다. 주로 설정 파일등 작은 파일이지만 중요한 파일들을 공유할때 사용한다. Dropbox로 emacs, vim, sublime text, eclipse, shell 설정 파일이나 이력서 등 중요한 파일들의 공유 용도 위주로 사용한다.

DaumCloud는 가장 큰 저장 공간을 지원해주기 때문에 pdf 파일이나 스크랩 파일등으로 가득 채우고 있다. 현재 30G 정도 사용하는데 새 컴에 세팅하면 동기화 하는데 몇일 걸린다.

One Drive는 속도나 용량에 대한 호평이 많아 사용해보았지만 파일 크기나 파일명등으로 까다롭게 굴어서 그냥 윈도에서 쓸일 생기겠거니 하고만 있음.

Copy의 경우는 개발 관련 소스 등을 공유하는 용도로 사용하고 있음. 나름 다목적으로 사용가능

Box는 무료 버전일 경우 파일 크기도 제약이 있고 속도도 좀 느린듯 하고 그다지 맘에는 안들지만 웹으로 문서를 본다거나 Dropbox처럼 지원하는 App들이 있기 때문에 설치해두고 있음.

Google Drive의 경우는 Google Docs의 파일들이 마구 넘치고 있어서 정리하기 귀찮아서 그냥 두고 있음

항상 Desktop에 동기화를 켜놓는 녀석은 Dropbox와 Copy 가끔 켜보는 녀석은 DaumCloud 나머지는 필요한 경우에만 사용한다.

Copy가 나름 쓸만한 줄 알았는데 많은 파일을 한번에 동기화 해보니 속도도 안나오고 문제는 sync가 다 되지도 않았는데 sync complete이라고 놀고 있다. Mega도 시도해봤지만 One drive 처럼 sync 불가능한 파일들이 발생해서 포기. 그냥 Box로...

[hummingtime]

Google Inbox

잠시 사용해보니 구글이 Gmail에 GTD 쪽으로 방점을 찍어 내놓은 서비스이다. 이름도 아마 GTD의 Inbox에서 따온 것이겠다.

Inbox에는 실제로 진행해야 하는 일이나 중요한 것들만 존재하고 Inbox를 비우는 것을 목표로 한다. Done 처리를 한다던지 나중에 다시 보이도록 Snooze를 하는 것이 간단하게 되어있고 메일로 오지 않았더라도 Reminder 기능으로 할 일을 추가할 수 있고 중요한 항목은 Pinning으로 고정할 수 있다.

이미 Gmail로 GTD를 수행하는 방법이 있지만 라벨을 만들고 매번 이동시키고 하던 것이 사실 조금 불편하기도 하고 애매한 뭔가가 생기도 해서 Inbox에 메일이 쌓이기도 하고 그랬는데 그런 불편함을 해소한 서비스라 보면 되겠다.

Inbox에 메일(할 일)이 생기면 

Pinning으로 고정하여 해결

Snooze로 연기

Done으로 해결된 것으로 표시

Done처리가 이미 된 것도 pinning으로 다시 inbox로 옮기는 것도 가능

전에는 메일로 온 것만 처리할 수 있어서 다른 GTD 툴을 이용해서 메일로 온것을 다시 분류하고 GTD 툴로 이동해서 정리하곤 했었는데 Reminder 기능으로 별도의 GTD 툴을 사용하지 않아도 되는 부분도 굉장히 마음에 든다.

Done 의 경우 All mail 메일함과 다르게 수신 날짜로 정렬되는 것이 아니라 Done 처리한 날 기준으로 정렬되어 보여준다. 확실히 GTD에 적용하기 편하게 구성되었다.

살짝 원하는 것은 All mail과 같이 수신 날짜순으로 보이는 기능도 있으면 좋겠다. 그리고 mac의 Reminder와도 연동되면 좋겠고..^^

[hummingtime]

Webstorm

정말 javascript 자동완성은 Webstorm이 진리...

emacs, sublime text 에 tern이나 뭔 플러긴, 모듈… 별짓 다해도 Webstorm 만큼 안됨. 

[hummingtime]

맥에서 exfat 디스크가 mount 안되는 경우

윈도우로 부팅이 가능하면 윈도우 부팅 후 chkdsk /F d: (d가 드라이브 alias)

맥에서 diskutil list 로 해당 디스크 id를 확인 후 sudo fsck_exfat -d /dev/디스크id

[hummingtime]

OS X 방화벽 허용 안먹히는 App

sudo codesign --force --sign - /Applications/앱명.app/

비번 입력후 실행하면 다시 물어보는데 한번 허용해 주면 다음부터 묻지 않음.

[hummingtime]

OneDrive 파일명 제한

iMac과 MBP 간에 개발 환경을 맞추려고 여러 설정과 repository들을 클라우드서비스에 올리던 중. 설정파일 같은 것들은 dropbox에 e-book류는 daum cloud에 문서는 google에 개발 환경은 OneDrive에 올리는데….

OneDrive만 그런건지 윈도우 환경용이라 그런지 파일명이나 폴더 깊이 등으로 딴지를 걸어대서 하루 종일 동기화. 뭐… 그랬다고...

[hummingtime]

처음에 그들은 공산주의자들을 잡아갔습니다. 그러나 나는 침묵하였습니다. 왜냐하면 나는 공산주의자가 아니었기 때문이지요. 그리고 그들은 유태인들을 잡아갔습니다. 그러나 나는 침묵했습니다. 왜냐하면 나는 유태인이 아니었기 때문입니다.   그리고 그 다음엔 노동운동가들을 잡아갔습니다. 나는 이때도 역시 침묵하였습니다. 왜냐하면 나는 노동운동가가 아니었기 때문입니다. 그리고 이제는 카톨릭 교도들을 잡아갔습니다. 그러나 나는 침묵하였습니다. 왜냐하면 나는 기독교인이었기 때문입니다. 그러던 어느 날 그들은 나를 잡으러 왔습니다. 하지만 이미 내 주위에는 나를 위해  이야기해 줄 사람이 아무도 남아 있지 않았습니다. - 마틴 니묄러

[hummingtime]

sublime text 3 의 solarized dark의 selection highlight color

기본으로 사용할 수 있는 solarized dark 테마의 경우 select등의 highlight color를 눈으로 구분하기 어렵다. 

단순한 해결방법으로 package control에서 solarized 테마 검색해서 설치하면 된다.

기본 solarized에 비해 배경색이 약간 밝고 highlight가 확실히 구분됨.