WSL(윈도우 서브시스템 리눅스) 에서 node.js 개발하기

오늘 좀 골때리는 경험을 했기에 글 싸지른다. 왜인지는 후에 설명한다.
이 글은 윈도우 10 레드스톤 2(크리에이터즈 업데이트) 이상에서 리눅스 서브시스템을 설치한 사용자에 해당된다.
안깔았으면 이전 글을 참고하고, 해당사항 없으면 씹기 바란다.

1. node.js 설치

먼저 apt-get 공식 리포지토리의 node 는 옛날 버전이다.
원하는 버전을 설치하고자 할 경우 리포지토리를 추가하여 설치해야 한다.
설치 버전별 목록은 여기서 볼 수 있다.
여기서는 가장 최신 버전인 7.x 버전을 설치하도록 하겠다.
별거 없다.

curl -sL https://deb.nodesource.com/setup_7.x | sudo -E bash -  
sudo apt-get install -y nodejs  

끗. 사실 윈도우에 별도로 node.js 깐 적 없다면 1번에서 끝나면 된다.
URL 끝 setup_(메이저버전).x 파일명 부분에 자신이 원하는 버전 숫자로 바꾸면 된다.
하지만 윈도우 내 개발환경에서 node.jsPython 등을 설치했을 경우 골때리는 문제가 발생할 것이다.
이제부터 들어간다.

2. 환경변수 관리

이 글을 쓰는 이유이기도 한데, 기본적으로 리눅스 서브시스템을 실행하면 윈도우 환경변수가 리눅스로 공유된다.
그래서 윈도우 PATH 변수가 먼저 들어간 뒤, 리눅스 PATH 변수 내용이 짬뽕된다.
이 때문에, 예를 들어 윈도우 내 node.js를 설치한 상태일 경우, npm 실행 시 아래 메시지가 나올 것이다.

$ npm
: not foundram Files/nodejs/npm: 3: /mnt/c/Program Files/nodejs/npm:
: not foundram Files/nodejs/npm: 5: /mnt/c/Program Files/nodejs/npm:
/mnt/c/Program Files/nodejs/npm: 6: /mnt/c/Program Files/nodejs/npm: Syntax error: word unexpected (expecting "in")

물론 환경변수 공유는 편리할 수 있으나, 대부분 독립형 운영체제라 가정하고 설계하고 개발하기 때문에
개발자 입장에서는 난처하면서도 골 안때릴 수가 없다. 몇가지 방법이 있는데 취향껏 따라하면 된다.

윈도우 환경변수 공유하지 않도록 설정

윈도우 아니랄까봐 리눅스 서브시스템 옵션을 레지스트리에 등록하고 있다.
따라서 만약 윈도우 환경변수를 리눅스로 옮기기 싫으면 아래 레지스트리 소스를 메모장 등으로 붙여넣은 후,

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss]
"AppendNtPath"=dword:00000000

참고로 레지파일은 반드시 빈 행이 하나 들어가도록 한 뒤 끝내야 한다.
원하는 파일명.reg 로 저장한 뒤 걍 실행해버리면 된다. 물론 되돌리고 싶으면 값 부분에 dword:00000001 로 바꿔 실행하면 된다.

Github Issue 출처

.bashrc 파일에 원치 않는 변수내용 삭제

윈도우 환경 변수를 포기 못할 경우에 간단한 팁이다.
PATH 환경변수에 특정 내용을 지우는 식으로 처리할 수 있다.
아래 쉘 스크립트를 ~/.bashrc 파일 내용에 추가하면 원치 않는 변수 내용을 삭제할 수 있다.

### remove unnecessary Win PATHs
# This can prevent extension-less commands from bleeding into BASH.
# (eg. "ng" would execute the Win bin if "@angular/cli" wasn't installed on Linux.)
#
function path_remove {
  # Delete path by parts so we can never accidentally remove sub paths
  PATH=${PATH//":$1:"/":"} # delete any instances in the middle
  PATH=${PATH/#"$1:"/} # delete any instance at the beginning
  PATH=${PATH/%":$1"/} # delete any instance in the at the end
}

path_remove '/mnt/c/Users/me/AppData/Roaming/npm'
path_remove '/mnt/c/Users/me/AppData/Local/Yarn/bin'
path_remove '/mnt/c/Program Files (x86)/Yarn/bin'
path_remove '/mnt/c/Program Files/Git'
path_remove '/mnt/c/Program Files/Git/cmd'
path_remove '/mnt/c/Program Files/nodejs'
path_remove '/mnt/c/OpenSSL-Win32/bin'
path_remove '/mnt/c/Program Files (x86)/Python27'

이후 bash를 빠져나가고 다시 bash 실행하면 원치 않는 명령어 실행을 방지하여 조금은 더 깨끗한 환경에서 개발할 수 있을 것이다.
Github Issue 출처

composite / 2017년 8월 24일 / Piss Development / 1 Comment

nw.js 한국어 활동을 중단하다.

다들 Electron 쓰는 거 안다. 그래서 단도직입적으로 말하겠다. nw.js 활동 관뒀다.
시간에 쫓기고 관련 프로젝트도, 수요도 없으며, nw.js 쓰던 개발자들도 모두 Electron으로 옮긴 데는 이유가 있다.
뭐, 어찌보면 나의 변명을 싸지르는 글이기도 하다. 일단 나열하겠다.

미미한 수요

현재 많은 개발자들은 데스크탑 앱을 간편하게 제작하는 데 Electron 으로 개발하고 있을 것이고, nw.js 라는 놈이 있었나 하는 사람들은 깊게 파기 시작하다보면 아하 할 것이다.
당연하겠지만, Electron은 개발자 친화적인 프레임워크를 구축하였기에 더 많이 채택된 것이다. 즉, 이런 이유로 Electron을 선택한 것이다.

  • node.js 에 익숙한 개발자들의 익숙한 개발환경 구축 용이
  • ASAR 패키징을 통한 기본적으로 손쉬운 패키징
  • 많은 사용자 커뮤니티 층과 Issues
  • 성능과 기술 수용속도가 유리
  • 견고하고 안정적인 업데이트 주기

당연하겠지만 첫번째 이유가 가장 큰 이유 되시겠다.
물론 nw.js도 나름대로 장점이 있다.

  • node.js 에 익숙하지 않아도 구축 가능한 개발 환경
  • 자바스크립트 소스코드 보호를 위한 nwjc 제공

둘 다 오픈소스다. 그리고 하나는 Github, 하나는 Intel 이 주도한다.
결국 nw.js 의 업데이트 속도와 Issue는 느려졌고, Intel의 보수적 개발 덕분에
수요자들을 충족시키지 못했다. 자연스레 Electron의 압승으로 현재 진행중이다.

여기서 Electron을 선택할 수밖에 없는 수요층이 있는데, 바로 실시간 처리를 하는 업자들이다.
대표적인 예로 메신저, 화상 회의나 채팅 등이 있다. 그리고 여러분이 많이 쓰는 Slack이 대표적 업체다.
개발하던 패턴대로 개발하면 되기 때문이다. node.js 관련된 여러 기술들을 그대로 가져다 쓸 수 있다.
물론 네이티브로 갈 땐 얘기가 달라지지만.

기술적으로 Electron은 nw.js에 비해 프론트엔드와 백엔드 컨텍스트가 완전히 분리되어 있다.
이 때문에 명확한 컨텍스트 관리라는 평가를 받고 있기도 하다.

랜섬웨어 프레임워크???

파일을 무작정 암호화 하고 파일을 인질삼아 금품을 요구하는 랜섬웨어.
이 프로그램을 만드는 데스크탑 프레임워크의 쌍벽이 있는데,
하나는 .NET WinForm이고, 또 하나는 nw.js 다.
그래서 보안개발자들 입장에서는 nw.js 는 비트코인처럼 혐오하는 프레임워크일 지도 모른다.
당연하겠지만 node.js 에 익숙하지 않은 개발자들에게 nw.js는 접근성이 용이하다.
왜냐면 그냥 웹 페이지만 띄우고 package.json 쓰고 실행만 하면 땡이기에.
그래서 어느 백신은 nw.js 들어가기만 해도 걸러내는 오진을 선보이기도 했다.
결국 nw.js 는 Electron 개발자 중 아는 개발자들에게 웃음거리가 됐고 불명예스러운 프레임워크가 됐다.

Github의 윈윈전략

Electron은 Github의 주요 기술이다. Atom Editor는 그 기술을 통해 제공하는 컨텐츠일 뿐이다.
거리낌없이 Electron을 오픈했고, 기업들은 이를 선택했다. MS도 거리낌없이 선택했다.
이리하여 Github은 거대한 플랫폼 시장을 형성하는 데 성공했고, 이제 Github 종속된 대기업이 많아졌으며,
세계적 브랜드 네이밍을 어마어마하게 키운 업체가 되었다. 한국 직원이 아직도 없다는 건 무시하자.
(참고로 중국과 일본은 있는데 한국은 없다는 점에 카타르시스를 느끼는 병신이 본인이다. Github Enterprise는 중국과 일본에 현지 서비스가 가능하지만 한국은 없다고 한다. 지금도.)

그에 반해 nw.js 도 많은 노력을 기울였고 Electron을 탄생시킨 프로젝트였지만,
이제 말하는데 nw.js 프로젝트를 인텔이 이끄는 걸 아는 사람도 별로 없더라. 허..

브랜드 파워는 이런 단순한 곳에서 출발하여 거대한 시장을 이끌어내고 있다.

나 이제 뭐하냐…

일단 Electron 에반젤리스트들은 한국에도 꽤 많아졌다. 물 들어올 때 노 저어 이름 석자 알린 사람도 꽤 있다.
그런 면에서 나는 비주류에 노를 젓다 썰물 다 가 고립된 상태인 것이다.
지금 내 꼬라지를 짤방으로 마무리하며 시간상 여기까지 싸지르도록 하겠다.

둠가이

composite / 2017년 7월 11일 / Dog's bullshit, Piss Development / 0 Comments

From node-webkit to Electron 1.0

이 글은 Github 소속 Electron의 메인 개발자인 Cheng Zhao(@zcbenz)의 기고글을 번역한 글이다.
원문: From node-webkit to Electron 1.0
시간에 쫓기고 작성하다 보니 오역이 있을 수 있다. 오역 교정 환영한다.

아니 프리랜서가 시간관리도 못하고 왜 시간에 쫓겨다녀?

한국 프리랜서는 용병이 아니라 그냥 사업자를 빙자한 근로자거든요 ㅋ


이 글을 통해 내가 node-webkit를 재구성하다가 Electron 프로젝트를 시작하게 된 내역을 기고한다. 내역을 좋아하는 애들을 위해 커밋 내역과 관련 링크를 달아주었다.

DOM에서 node.js 모듈 불러오기

모든 것의 시작은 2011년 @rogerwang 이 만든 마법의 모듈 node-webkit이었다.
이 node.js 모듈은 웹킷으로 하나의 브라우저 창을 띄워주는 것도 모자라, node.js 모듈까지 사용하는 마술까지 부렸다.

Node.js 코드 단은 이랬고,

var nwebkit = require('nwebkit')
nwebkit.init({'url' : 'index.html'}, function () {
  nwebkit.context.runScript('')
})

그리고 index.html 내용은 이랬다.

<html><body>
<p id="output"></p>
<script>
require('fs').readdir('.', function (err, files) {
  var result = ''
  files.forEach(function (filename) { result += filename + '<br/>' } )
  document.getElementById('output').innerHTML = result
});
</script>
</body></html>

이 데모로는 아직 시판하기엔 부족한 점이 많았지만, 충분히 성공 가능성이 있었다.

크롬 임베디드 엔진을 사용하다.

그 당시 node-webkit 에서 가장 큰 문제였던 게 있는데, 웹킷 라이브러리 기능을 리눅스 외에 사용하기엔 너무나 버거웠다.
그래서 @rogerwang 은 이 모듈을 웹킷에서 크로미움을 애플리케이션에 넣는 인터페이스를 제공하는 크롬 임베디드 프레임워크로 바꿔 해결했다.

당신은 그 CEF를 사용하여 개발한 node-webkit 코드를 볼 수 있다. node.js 비동기 기능을 수행하도록 만들기 위해, 거기에는 크로미움 메시지를 node.js 입출력 라이브러리인 libuv로 대체하는 패치가 있었다. 그러나 이제 그 패치는 더이상 찾을 수 없었다. 왜냐하면 NW.js 의 Chromium fork 저장소가 이미 오래전에 rebase 해버렸기 때문에. 이제 그 당시 커밋 내역으로 돌아갈 수 없게 됐다.

인턴으로 취직

당신은 @rogerwang 오랫동안 오픈 소스를 지원했던 인텔에 일하고 있다는 사실을 알고 있는가? 놀랍게도 인텔이 오픈소스를 위한 인턴을 구했다. 이보다 더 좋은 인턴쉽이 있었던가?

Intel OTC

2012년 여름, 나는 한참 졸업을 앞둔 대학생이었을 때 여름 인턴쉽을 찾으러 다녔다. 그 때 바로 인텔의 구인란이 눈에 보였는데, 인텔은 node.js의 오픈소스 프로젝트 node-webkit 개발자가 필요하다고 했다. 나는 이때다 싶어서 지원했고 운좋게 붙었다.

그리하여 나는 그 node-webkit 를 개발하기 시작했다.

컨텐트 쉘

첫번째로 내가 했던 업무는 node-webkit의 CEF 브랜치 개선이었다. 그리고 개발하면서 정말 어렵게 해냈다.
node.js가 V8 API를 직접 호출하면서 CEF는 크로미움의 컨텐트 모듈을 입히는 자체 API를 연동한다.
당신이 크로미움과 node.js를 연동하고 싶다면 중간에 CEF를 엮이지 않게 달아야 할 것이다.

그래서 기존 코드를 향상시키는 대신 아예 컨텐트 쉘을 재구성하는 쪽을 택했다. 크로미움을 최소한으로 사용한 가벼운 브라우저를 구현하기 위해.

결과는 꽤 좋았고 node.js 통합이 가능한 작은 브라우저를 획득했다. 그리고 난 그 node-webkit 0.2.1 버전으로 릴리스를 배포했다.

node-webkit를 프레임워크로

node-webkit는 node.js 모듈이기 이전 독립적인 브라우저였었다. 왜 여태까지 이 프레임워크로 HTML과 자바스크립트로 데스크탑 앱을 만들지 않았지? 나는 그 때 몇 개월간 그 아이디어를 행동에 옮겼다.

먼저 나는 node-webkit의 패키징 시스템을 추가했다. 아이디어는 게임 프레임워크인 LÖVE framework 를 슬쩍했다. 그 아이디어는 앱을 ZIP 아카이브로 만들고 node-webkit 실행 파일을 합치면, node-webkit 실행 시 그 아카이브를 풀고 아카이브에 포함된 앱을 실행하는 식이었다.

Packaging node-webkit

몇가지 구현 항목이 있다면, package.json 에 윈도우 속성을 넣거나, DOM 요소 확장, 브라우저 보안 모델 삭제, DOM 요소에 네이티브 파일시스템 도입, 그리고 끝없는 버그 수정 등이다.

한가지 재밌는게 가장 어려운 도전이 있다면 아무래도 node.js 네이티브 모듈 도입이었다. 나는 V8에 OpenSSL을 도입하기 위해 따로 기호(Symbols)를 추가해 크로미움에 패치하고, NSS와 OpenSSL 사이에 충돌이 일어나는 node.js 기호도 수정해 패치했다. 이렇게 윈도우용 원시 코드 node.lib 커스텀 패치를 제공하여 node-webkit에 네이티브 모듈이 돌아가도록 했다.

이리하여 node-webkit v0.2.5 배포 후, 왠지 안정된 느낌을 받았다.

자체 API 추가

이번엔 API 제공하는 데 DOM을 여전히 격리되고 있고, DOM 제공이 너무 제한적인 부분인 현실에 내 생각을 말해본다.
예를 들면 네이티브 메뉴와 여타 텍스트가 들어간 메시지박스 등.

그때 나는 자체 API를 제공하는 제공할 수 있는 걸 생각해 냈다. 바로 require('nw.gui') 같은 빌트인 모듈. NW.js 써봤다면 알 것이다. 그때 나는 메뉴를 생성하거나, 트레이, 메시지 창 등을 API에 넣었다. 지금 NW.js의 원형인 셈이다.

내가 새 릴리스를 배포할 때마다 이런 아이디어를 유지했고, node-webkit v0.3.6 버전으로 피날레를 장식했다.

다른 GUI 프레임워크와는 달리 크로미움의 특별한 점 하나가 있는데, 바로 멀티 프로세스 아키텍쳐라는 점이다. 크로미움 브라우저는 웹 페이지를 실행하고 GUI를 띄우면서 응답해야 하기에 웹 페이지에 GUI 모듈 제공은 너무나 힘들었다.

이렇게 해서 웹 페이지 내에 브라우저 처리를 하기 위한 내 첫번째 시도는 이랬다.
먼저 크로미움을 싱글 프로세스로 돌린다. 허나 이건 너무나도 불안정하게 돌아간다.
이번엔 그냥 네이티브 GUI API를 렌더러 프로세스에 호출하도록 해봤다.
하지만 몇몇 플랫폼에서 GUI 요소와 프로세스를 직접 핸들링할 수가 없었다.
그래서 찾은 마지막 방법은 IPC 메시지를 통해 GUI 모듈을 node-webkit에 입혔다.
이렇게 해서 렌더러 프로세스 중에도 상시 행동이 가능했고,
브라우저 프로세스 간이나 주어진 일을 완료하면 메시지를 보낼 수 있게 됐다.

node-webkit 홍보

node-webkit 같은 프레임워크는 사용자가 가장 중요하다. 많은 사용자를 가지고 만드는 데 있어서 가장 중요한 것들도.

그래서 내가 node-webkit를 개발하는 동안 최대한 홍보도 해왔다. node.js 메일링 리스트에 소개글도 올렸고, 답글도 달아줬다.
node-webkit 게시들을 달며 node-webkit 발표도 했고, node-webkit 샘플 앱도 제작했다.
이렇게 나는 전 세계에 내 힘으로 node-webkit를 알리는 계기를 만들었다.

그리고 node-webkit 개발을 중단하기 전에 Github 별을 천여개 씩이나 받았다. Github에 상위 C++ 프로젝트 10위 안에도 들었다.

첫 사용자

내게 node-webkit 첫 사용자는 정말 중요한 순간이었다. @ibdknoxLight Table editor 을 node-webkit 를 통한 웹 기술로 다시 탄생시켰다. 이후 많은 이들이 node-webkit 에 주목받고 많은 도움이 들어왔다. 이렇게 기쁜 순간을 만들어준 @ibdknox 에게 감사의 말을 전한다.

그 다음 해에 Light Table는 node-webkit 에서 Electron 으로 자리를 옮겼다. 왠지 오랜 친구가 돌아온 것 같았다.

GitHub으로 이동

어느날 Github 에서 비밀리에 Atom 에디터를 시작하면서, @nathansobo 가 node.js로 데스크탑 앱을 개발하는 사람을 구하고 있었다.
나는 Atom을 node-webkit에 마이그레이션하기 위해 필요할 때마다 node-webkit를 개선하는 조건으로 그와 계약했다.

이렇게 반년동안 node-webkit를 개발하다가 인텔 인턴쉽은 이렇게 끝났다. 바로 나는 Github 고객지원부로 일하기 시작했다. 그리고 동시에 node-webkit 개발을 중지하고 뒷일은 @rogerwang 이 모두 맡게 됐다.

Contribution Graph

왜 이렇게 뜨거운 감자인 node-webkit 개발을 중단했을까? 어자피 내가 Github으로 이동하는데 전혀 영향도 없었고, 누가 프로젝트를 운영하는데 나는 상관이 없으니까.

아시다시피, 난 인텔에서 다른 사람의 프로젝트를 진행하고, 프로젝트의 결정권을 가질 수도 없었다. 아무렴 어떤가.
그냥 난 누구의 방해도 없이 node-webkit을 재구성할 수 있고 기능을 추가하면서 장난감 조립하듯이 일하는 게 좋았으니까.
어느날 node-webkit 오픈 소스 규모 커지기 시작했고 말 나오기 무섭게 나의 node-webkit의 권한은 상실됐다.
새 버전을 배포하는 데 있어서 책임이 상급 엔지니어에게 이관되어
내가 일할 수 있는 범위가 사실상 줄어들었고, 내가 좋아하는 기능을 넣을 수 없었다.

비난할 이유가 없다. 인텔 말고도 다른 회사도 그러니. 하지만 단도직입적으로, 더이상 참을 수 없었다.

더 나은 데스크탑 프레임워크 제작

내가 Atom 개발에 참여했을 때, Atom은 CEF에 파일시스템을 운영하기 위한 자바스크립트 바인딩으로 이루어져 있었다. 이게 Atom이 node-webkit로 마이그레이션한 계기가 됐지만, node-webkit가 그때당시 결함이 많다 보니 앞길이 순탄치 않았다.

그래서 난 결국 자체 네이티브 쉘을 만들어 해결하기로 했다. 새로운 쉘은 node-webkit를 개선하는 대신 몇가지 근본적 구조를 바꾸는 방향으로 재구성했다.

이리하여 이 쉘에게 atom-shell 이라고 이름 지었다.

node-webkit 에서 Electron 1.0 까지

그 이후 Electron과 NW.js 에 무슨 일이 일어났는지 내역을 정리했다. Atom과 Atom-shell 은 오픈 소스로 배포했고 그 atom-shell은 Electron으로 개명했고, node-webkit는 NW.js 로 이름을 바꿨다.

그리고 저번 주말에 드디어 Electron 1.0 을 배포했다.

Contribution Graph

Electron은 NW.js의 파생인가?

아마 내가 받은 질문 중 가장 많이 받은 질문이고, 내가 이 글을 쓴 이유이기도 하다. 기술적으로는 Electron은 node-webkit 0.3.6을 재구성했다. 내가 마지막으로 배포한 버전이고 이걸 끝으로 node-webkit 개발을 중단했으니. 그러고 보니 Electron은 원래 node-webkit와 아주 다른 노선을 밟았다.

그러니까 재대로 얘기 좀 하자면, NW.js는 내가 node-webkit 개발한 걸로 시작했고, Electron은 내가 다시한번 node-webkit에 파고든 작품이다.


복터진 개발자네. 군기잡힌 인턴 개발자에서 Electon 메인 개발자가 되기까지…

composite / 2016년 5월 25일 / Piss Development, Waldo Translation / 2 Comments

node.js의 웹 기반 데스크탑 앱 프레임워크 비교

nw.js

내가 많이 사용해봐서 잘 안다.

뭐래 병신이…

장점

  • 초보자에게도 쉬운 접근성
  • 크롬 확장 및 API 지원
  • nwjc를 통해 지적 재산권 보호 기능 지원 (소스 코드 보호해준다고.)
  • 키오스크, 항상 위, 트레이, 메뉴, 투명화 등 기본적으로 앱에 필요한 기능 지원
  • 웹 컨텍스트 기준으로 프론트엔드 개발에 능하다.

단점

  • 존나 무겁다. 크롬의 대부분 기능을 담았기 때문에.
  • 자체적으로 앱 패키징이 없기 때문에 타 모듈 등을 사용해야 한다. (근데 맥은 존나 편함 ㄳ)
  • 소스코드 보호기능은 당연하지만 성능이 30% 이상 하락하므로 필요한 곳만 사용.
  • node.js 확장 중 네이티브 확장 지원이 그지같다. node-gyp로 가져온다 해도 다시 nw-gyp 써야 함.
    업데이트: 0.13부터 이제 nw-gyp 안써도 됨. (윈도우는 개발자에 한해 한가지 뭐 해야함 아 귀찮.)
  • 피드백 속도가 좀 느리다 (Github Issue 피드백이 평균 7일이라고 함. 참고로 같은 Issue 트래킹에 Electron은 평균 1일.)

Electron

한국에서 가장 많이 알려지고 애용하는 프레임워크.

내가 nw.js 홍보했더니 구려 터졌다고 꺼지라더라.

장점

  • 가볍다. 크롬의 핵심 기능만 넣었기 때문에.
  • 앱의 Hang 및 Crash 처리를 자체적으로 지원.
  • HTML5 및 ECMAScript 6 등 가장 최신 기술을 가장 빠르게 지원
  • 자체적으로 쉽게 사용 가능한 앱 패키징 및 업데이트 모듈 지원
  • 항상 위, 트레이, 메뉴, 투명화 등 기본적으로 앱에 필요한 기능 지원
  • 절약 모드를 무력화하는 API 및 웹 표준 DRM 등 더 다양한 기능 지원

단점

  • 크롬 확장 미지원
  • 소스 보호 기능이 없어 타 모듈(enclose.js 등)을 사용해야 함.
    (Electron 메인 개발자인 Cheng Zhao(@zcbenz)는 퍼포먼스를 위해 이를 지원하지 않겠다고 못박음)
  • Electron은 컨텍스트 구분이 nw.js에 비해 뚜렷함.
    이런 이유로 nw.js에서 쉽게 jQuery 지원했던게 Electron에서 쉽게 안되는 이유이기도 함.
    자세한 내용은 해당 FAQ 참고.
  • node.js 확장 중 네이티브 확장 지원이 그지같다. node-gyp로 가져온다 해도 다시 electron-gyp 써야 함.

node-thrust

앤 또 뭐냐…

몰라 시발.

장점

  • node.js 뿐만 아니라 Go, Python, Ruby 등의 언어 지원
  • 자체 IPC 원격 통신 제공
  • 저장 경로 사용자화 및 다른 방식의 쿠키 저장소 지원
  • 자체 프록시 기능 지원

단점

  • 데스크탑 앱의 모든 기능을 지원하지 않음. (다행히도 투명화는 지원)
  • file:// 프로토콜 미지원 (node-thrust에 자체 웹 서버가 있는 이유)
  • 프론트엔드와 백엔드 사이 연동 미지원 (예: 프론트엔드에서 node.js 모듈 바로 못씀)
  • 뜨고는 있지만 아직 부족한 문서

내가 뭐 부가설명 쓰려 했는데 까먹은 관계로 여기까지.

composite / 2016년 5월 18일 / Piss Development / 0 Comments

비즈니스를 위한 node-webkit 데모를 지금 공개한다!

비즈니스에 node-webkit 를 관심가져야 하는 이유를 글 올렸었다.

하지만 아직도 망설이거나 개소리라고 하는 인간들 있을거다. 내가 다 안다.

그래서 준비했다. 나는 결과물을 통해 주장을 증명하고, 근거를 제시한다.

더이상 긴 말 안하겠다. 프로젝트 가서 설치법 및 실행법 보고 체험하라.

https://github.com/composite/NodePlatform

XPlatform 같은 비즈니스 CRUD를 순수 웹과 node-webkit 로 구현했다.

끝.

윈도우 사용자를 내가 열심히 배려했다. 단일실행파일 배포한다.

http://www.solidfiles.com/d/c5df88cb09/

다운받고 실행만 하면 된다. 소스? 프로젝트 사이트 가라니까 좀.

다른 운영체제? 미안하지만 회사컴에 맥이나 리눅스가 없어서.

composite / 2014년 1월 15일 / 미분류 / 2 Comments

임베디드 JSON 기반 Document DB – EJDB

아마 모바일에서 아는 사람은 쓸 것이다. 모바일에 딱좋은 저장소가 딱히 없는데, 이녀석이 딱좋거든. JSON 짱짱맨.

http://ejdb.org/

MongoDB 같은 임베디드 DB를 지향한다고 한다. 그래서 그런지 BSON 표준을 사용하고 있다.

Tokyo Cabinet 소스를 사용해서 만들었다.

도쿄캐비넷이 뭐냐고? 고전적인 NoSQL DB이다. 한국에서는 잠잠했다가 NoSQL 이 뜨면서 쁑 튀어나온 게 한국이 왜 DB를 SQL에만 의존하는지 보여주는 대목 되겠다. 뭐.. 리눅스에서 빌드해서 써야 하는 귀차니즘도 한몫 했지만.

됐고. 이걸 왜 소개하냐? 모바일이야 뭐 쓴사람은 안다. 우왕ㅋ굳ㅋ.

그렇다면 이걸 당신의 앱에 접목한다면 어떨까? 당! 신! 앱!

EJDB는 아래 언어에 바인딩 되어 있다.

나온 순서대로 기록하니 해당되는 언어에 쓰면 되겠다.

원래 C언어이기 때문에 유의해서 쓰도록 한다.

커뮤니티 참여이지만 공식 패키지이기 때문에 믿고 쓰도록 하자.

EJDB나 토쿄 캐비넷이 수동으로 빌드해야 한다고 윈도우 유저들이여 서운해 마라. 윈도우 프리빌드 패키지가 있다.

참고로 node.js 모듈이 기본이기 때문에 node.js 개발자는 걍 써!

닷넷과 자바 개발자의 경우 메모리 걱정으로 임시 저장소나 캐시 등이 걱정된다면 이 솔루션을 고려해 보는것도 좋다.

근데 닷넷은 4 이상이 요구된다. 자바는 1.6 이상이다. 닷넷개발자들 ASP.NET MVC 3 이상이 아니면 “아아 울고싶어라…”

composite / 2014년 1월 13일 / 미분류 / 0 Comments

데스크탑 앱의 홀릭, Brackets-shell 빌드하기 자료 소개.

뭐.. 내컴이 윈도우라 지랄같을 뿐이다.

일단 Brackets-shell 로 데스크탑 앱 개발하기 위해 고군분투를 할 것이다.

어도비에서 직접 지원을 하고 있고, 크로미움 기반이며, 소스가 MIT이기 때문이다.

Node-webkit 는 네이티브 플러그인 지원 측면에서 차별화된 양상을 보이지만,

bracket-shell 은 기존 node 네이티브 플러그인을 갖다 쓰거나 당신의 씨뿔뿔로 만든 라이브러리를 같이 쳐넣을 수 있기 때문에 더 주목을 받지 않은가 싶다.

이 링크를 참고하면 내가 왜 이리 씨뿔뿔부렸는지 알 것이다. 물론 영문이다.

http://clintberry.com/2013/native-desktop-javascript/

https://github.com/joelrbrandt/brackets-simple-node (이건 예제)

게다가 기본이 크롬리스 윈도우(테두리 없다고)이고, API가 안정적으로 제공되고 있는 측면이 힘을 발휘한 듯 하다.

어찌됐던 간에. Brackets-shell 을 빌드하여 커스텀 앱을 만드는 여러가지 팁이 있으니 소개해 보겠다.

나는 윈도우 기준으로 빌드를 할 거기 때문이고, 그리고 그렇게 할 것이기에, 윈도우 빌드방법 및 후기를 내가 직접 겪어봐서 올리도록 하겠다.

지금 나온 팁들은 죄다 맥 기준이다. 어도비는 맥에서 짱먹었으니.

http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/ (영문)

http://steamboatlabs.com/blog/brackets-native-desktop-apps-with-html-js-css/ (영문)

http://uiandwe.tistory.com/891 (한글 용자 등장, 물론 맥.)

어느 프레임워크를 선택할 지는 당신 마음이지만, 응용 프로그램의 다양성과 웹의 생산성 둘을 합친 비즈니스 앱의 강점은 내 블로그에 잘 설명되 있으니 보도록.

http://blog.hazard.kr/117

데스크탑 앱 만들기. 조또 없다.

근데 시발 Windows SDK가 안깔려…

composite / 2014년 1월 10일 / 미분류 / 0 Comments

어도비에서 만든 Brackets 를 까보았다.

한국에서도 잘만든 웹 개발 환경이라는데 나도 한번 써봤다.

흐음.. 기본은 한다. 일단 아무래도 많은 이들을 설레게 한 기능이 바로 “Live preview” 가 아닌가 싶다.

크롬에서 그냥 수정만 해도 결과물을 바로바로 볼 수 있다는 매력이 있다.

물론 Live Preview 지원하는 애들은 이거 말고도 있지만, 그래도 이녀석은 Live Preview 지원하는 놈 중 “공짜” 라는 것이다.

오픈소스라서 그렇긴 하지만, 그 외에 JetBrains 의 WebStorm 과, Live Preview 를 IDE 로 접목시키는 CodeRocket 도 있다.

근데 내가 소개한건 유료니 알아서 보도록.

참고로 Live Preview 는 크롬에서만 지원하고 있고, CodeRocket 만 유일하게 다른 브라우저도 지원한다. 뷁.

어쨌든, 이렇게 괜찮게 만들어진 앱이 오픈소스라서 역시 까보지 않으면 내가 아니다.

까봤다. https://github.com/adobe/brackets

근데..

엉?

뭐여..

언어가..

자바스크립트와 CSS, 그리고 쉘이 끝이다.

읭?

어떻게 된거지?

하지만 grunt가 눈에 띄었다.

읭?

node.js 를 쓰는거구나.

그렇다면,

그 앱 코어는 어디서 담당을 하지?

app.js 에서? 아니면 node-webkit 에서?

그러나 개발 종속성이나 일반 종속성에 그런 단어는 눈꼽만큼도 없었다.

그렇다면 한가지 결론밖에 없다. “자체 제작”

역시나.. “자체 제작” 이었다.

https://github.com/adobe/brackets-shell

node-webkit 와 같이 크롬 임베디드로 제작했고, 임베디드 버전은 3이다.

뭐 어때. 잘만되면 되지.

어쨌든, 여기서 내가 가장 주목하는 점은, 아무래도 “확장 지원” 과 “개발 환경에 맞춘 앱 코어” 가 아닐까 싶다.

물론 그러려면 그런 시스템으로 이루어졌는지 “더 까봐야 안다”.

그렇다면 이녀석의 라이센스는? 근데 라이센스 파일이 따로 없지만, Brackets 의 일부이니 아무래도 MIT가 아닐까 싶다.

그렇다면 이 brackets-shell 로 다른 데스크탑 앱을 만들 수 있을까?

일단 node-webkit 처럼 바이너리 형태로 배포하지 않고 소스만 공개해서 알아서 빌드해야 한다.

그런 다음에 어떻게 쓰는지 한번 분석해 볼 필요가 있다.

조만간 결과 나오면 블로그로 따로 적어보도록 하겠다.

이제 node.js 로 데스크탑 앱을 만드는 3대장이 생겼다.

app.js 는 죽었지만 대신 deskshell 이 명맥을 유지하고 있으니 deskshell,

그리고 데스크탑 앱 개발의 유망주인 node-webkit

마지막으로 brackets 의 앱 담당 코어인 brackets-shell 이다.

그래봐야 엔진은 크롬내장엔진이라서.. 공통점이 그렇다.ㅋ

이거 참 재밌어지는데?

웹으로 응용 프로그램 만드는거. 어렵지? 않↘아↗요.

일단은 그냥 node-webkit 쓰셈.

deskshell 은 방향이 삐뚤어지고 있고,

brackets-shell 은 brakets 를 위한 앱 코어니까.

composite / 2014년 1월 8일 / 미분류 / 0 Comments

app.js 가 다시 부활했다? 아니. 난 다르다 – DeskShell

app.js 가 죽은 지 몇달 후. node.js 개발자들은 아마 node-webkit 의 신세계에 푹 빠져있을 것이다.

물론 나도 그랬다.

하지만 app.js 의 기대와 아쉬움이 남아 다시 github 에서 app.js 프로젝트를 갔다.

이번엔 app.js 기반으로 다른 프로젝트로 활동한다는 정보가 입수됐다. 들어갔다.

이름은 deskshell 이라는 녀석이다. github 프로젝트 : https://github.com/sihorton/appjs-deskshell

Deskshell 은 하나의 SDK 라고 생각하면 된다고 한다. 그것도 백그라운드 쉘에 크로미움 프론트엔드로 무장한.

뭐.. node-webkit 가 아직까지는 막강하다.

그리고 이 프로젝트의 차별화는 아무래도 자체 웹 서버를 돌려 웹으로 할 수 있는 모든 것들을 수행하는 것에 중점을 맞추고 있다.

그리고 그 차별화를 증명했는데. 바로 PHP 스크립트를 돌려 어플리케이션에 뿌려주는 기능을 구현했다고 한다…

응? PHP?

그렇다. PHP이다. 나도 벙찌게 만드는 문구였다.

but then allows full backend functionality written in popular server scripting languages that anyone can pick up like node or php (more choices coming soon).

<

p>

이렇게 나온다면 어자피 자바스크립트 기반이겠지만, ruby 나 파이썬 같은 것들과 통합하여 앱을 돌리는 거에 중점을 둘 수 있다는 거다.

이것은 확실히 node-webkit 와 차별화된 전략이다.

그리고 돌려봤다. 어자피 앱 테스트니 포터블 버전 받아서 실행했다.

잘된다. app.js 추억이 되살아났다.

하지만 뭔가 부족하다. 뭔가.

여기서 나오는 큰 버그가 둘 발견했는데,

  • 앱을 실행하자마자 페이지에 접속할 수 없다고 뜬다. 그런데 새로고침하면 잘 뜬다. 아마 웹 서버와 프론트앤드가 따로 노는 듯 하다. 차라리 백그라운드에 이벤트 걸어서 서버가 동작을 시작하면 앱 화면을 띄우는 환경이 제공되면 더 좋겠다.
  • 닫기 버튼을 자바스크립트로 구현했긴 하는데. 좀 느리다. 누르고 1초 뒤에 사라졌다. app.js 조차도 이러진 않았는데. 이건 좀 시급한 문제일 듯 싶다.
그 외에는 app.js 기존 기능하고 별 다를 게 없다. 그리고 더 재밌는 것은, 크로미움 엔진을 아예 갖다 썼다는 것이다.
완전히 브라우저가 된 것이다. 크롬 메뉴와 기능들이 다 나온다. 심지어는 한글 메뉴가 나오고,
브라우저 창 열고 크롬 정보를 확인하면 크롬 30이라고 뜬다. 크로미움 기반이지만 안타깝게도 업데이트는 안되지만.
흐음.. 크롬의 프로토타입을 곧대로 대입한 듯 하다. 이렇게 되면 크롬의 장단점을 안고 가는 수밖에 없겠지만…
하지만 어쩌면 이 부분에 유리한 앱이 나올 수는 있을 듯 하다.
잠시 의심했다. 내컴에는 크롬 카나리가 깔렸는데, 설마 이 프로세스를 빌려쓰지 않을까?
작업관리자를 봤지만 서로 달랐다. 다행히도 아니었고, 버전도 달라서 아예 독립 프로세스로 작동한다.
이녀석은 node-webkit 의 package.json 하고 다른 독자적 JSON 매니페스트 포멧을 가졌는데, 바로 .desk 파일이다.
뭐.. 매니페스트야 JSON 형식이니 패스.
과연 이 앱에 크롬이 내장되어 있었을까?
결론은 아니었다.
그 이유로, portable 버전 압축을 풀고 deskshell/bin/win 폴더에 들어가봤는데, PortableAppz 에서 제공하는 크롬 포터블을 래핑(Wrapped)한 것이었다.
어쩐지 브라우저 창이 뜨더라..
왜 확장성을 강조했는지 알 만 하다.
하지만 node.js 를 통해 무한한 확장성과 가능성을 제시해 준 방법을 제시한 것임은 틀림없다.

좀 더 지켜봐야 하겠지만, 어떻게 구조를 잡을지는 말이지.

과면 app.js 의 고질적인 문제점, 그리고 node-webkit 와의 차별화로 경쟁상대가 될 수 있을까?

글쎄.. deskshell 의 행보를 지켜보는 수밖에 없다.

끝이다.

composite / 2014년 1월 3일 / 미분류 / 0 Comments

비즈니스에서 node-webkit 에 관심가져야 하는 5가지 이유!

자바개발자던 닷넷개발자던 어자피 웹개발자라면 자바스크립트 쓸 줄은 아니 딴소리 마시고 읽어보고 판단하시길.

https://github.com/rogerwang/node-webkit

node-webkit 가 한국에서 점점 많이 알려진 점에 대해 기쁘게 생각한다.

프로젝트에도 쓰고 있고, 게다가 이미 공식 페이지에서 입증된 기술이다.

게다가 구글의 크롬 엔진이다. 크롬 엔진은 이미 웹에 앞서나간다는 업체라면 익히 알고 연구하거나 개발할 것이다.

그렇다면 무슨 말이 필요있겠는가? 이제 그런 강점에 촉진제를 넣어주도록 하겠다.

  1. 웹개발은 그대로 하면 된다.

기존 웹개발자가 갑자기 데스크탑 앱 만들라고 하면 시발 이게 무슨 소리여 할 것이다.

하지만 node-webkit 는 그딴거 신경쓸 필요 없다. 기존대로 웹개발만 하면 된다.

현재 개발자 중에 가장 많이 차지하는 게 웹개발자고, 그담 모바일앱 개발자다. 응용은 수가 적다. 물론 그만큼 희소가치가 있겠지만 웹이 더 싸게 먹히는게 웃지못할 정석이다.

node.js 개발이 별도로 필요하다고? 아니다. node.js 에서 그냥 님 웹페이지 띄울 수만 있으면 된다.

그 이상 신경 안써도 된다. 고급 기술을 채용하고 싶다면 그냥 node.js 개발자 뽑으면 된다. 아니면 님이 배우던가.

  1. 배포가 쉽다.

node-webkit 는 배포가 졸랭 쉽다. 소스 파일을 zip 압축해서 nw 로 바꿔 nw.exe 에 배치파일 걸어 실행해도 되고, love2d 처럼 nw.exe 내장시켜 단일 응용 프로그램으로도 배포 가능하다. 전혀 어려울 것 없다.

근데 그러면 어자피 소스가 다 까일텐데 걱정이 태산일 것이다. 웹 프로젝트 할건데 node-webkit 에다가 뭘 집어넣게?

굳이 해야 한다면 암호화/복호화 API 지원되니 그걸 쓰덩가. 데스크탑에 수행해야 하는 게 없지 않는 이상 크롬에 지원되는것들 다 지원되므로 걱정 붙들어 매기 바란다.

알리미 API? 그건 조금 아쉽긴 하지만 크롬처럼은 아직 지원이 어렵고 대신 구현은 가능하다. 링크 누르고 보고 따라하면 된다.

그정도면 비즈니스 앱 만드는데 불만은 없을 것이다. 이제 직원들에게 파일 하나만 딸랑 배포만 하면 되니까.

데스크탑에서 탭이라던가 그런것들 구현하고 싶다면 그냥 웹 그대로 하라. node-webkit 에서 해야할 일은 웹 페이지를 띄우는 것 뿐이다.

자동 업데이트? 님 응용 만드삼? 웹이잖아 웹. 웹 업뎃하면 그게 자동 업뎃이지 뭐야?

  1. 크로스 브라우징이 필요없다.

존나 고생하는거 안다. 시발 IE 조까튼 개새끼인거 안다. 이제 해방하라. 크롬 위주의 코딩을 해도 웹표준 그대로 따라간다.

W3C 에서 신기술 제의하는 대표적 기업이 구글, 모질라는 비영리단체고, 마소 등의 브라우저 만드는 기업이 포함되어 있으며, 표준안을 제시하며 그걸 그대로 따라간다. 따라서 카나리같은 개발자 전용 기능을 쓰지 않는 이상 HTML5/CSS3/Javascript 1.7 이상 표준 그대로 따라가도 된다. 쫄지마.

당신이 크롬 위주로 코딩한 95% 이상은 불여우와 IE 11 에서도 돌아가니 쫄지말고 코딩하라.

  1. 비즈니스 보안성이 향상된다.

비록 크롬 내장형 엔진이지만, 더이상 외부에 노출할 염려는 하지 말자. 물론 사내IP만 필터링 하면 되겠지만, 외부직원의 업무는 SSLVPN도 있고 하고. 하지만 문제는 아무래도 보안이다.

그런 면에서 액티브엑스 달린 웹은 보안성과 성능을 둘 다 씹고 똥컴 만드는 주범이다.

만약 보안성에 신경써야 한다면, 웹개발자는 웹에만 신경쓰게 냅두고, node.js 관련 보안 개발자를 통해 보안 모듈을 이식할 수 있다. 브라우저에 UUID 개념을 만들고 관리하여 인가된 사용자만 허용하게 할 수 있으며, 브라우저 헤더에 쳐넣을 수 있다. 아까도 말했듯이 암/복호화 API 제공하니 그거 써도 되고, 자체 보안 기술 가지고 있으면 C++ 확장 만들 수 있다.

사슬 edge.js 를 통해 .NET 코드도 돌릴 수 있긴 한데 문제는 .NET 4.5 이상이 요구되고 (윈도우 8 이상은 기본설치됨)

자바의 경우 node-java 가 있긴 한데 edge.js 에 비해 안정성 보장이 불확실한 점이 있다.

그러므로 응용 -> 웹 으로 이동하는건 문제가 아닌데 보안땜에 엑티브엑스 써야한다면 액티브엑스 개발자에게 node.js 모듈을 제안하던가 아니면 웹 보안에 맡기는 게 좋을 수 있다.

하지만 한가지 확실항 점은 바로 사용자 컴퓨터는 제어할 수는 없지만 node-webkit 프로그램을 쉽게 제어할 수는 있다는 것이다.

컴퓨터까지 통제해야 한다면 그건 그 업체 보안사항에 의한 별개의 문제고, 이 프로그램 연동과 상관 없으므로 알아서 생각하도록 하라.

그래도 쌩판 브라우저에서 실행되는 것보다는 보안성이 좋다. 브라우저를 제어하는건 불가능하지만 이 node-webkit 제어하는건 가능하기 때문이다.

  1. 많은 업체와 프로젝트를 통해 입증되었다.

node-webkit 의 개발자는 CPU 만드는 인텔 계열사인 오픈소스 업체의 사람이다. 인텔이 설마 신경 안썼겠는가?

게다가 많은 프로젝트와 업체가 생겼다. 개발자가 중국인이라(대만인가?) 중국업체가 대거 끼어들긴 했지만.

직접 눈으로 보려면 https://github.com/rogerwang/node-webkit/wiki/List-of-apps-and-companies-using-node-webkit

응용처럼 실행되지만 이것들이 모두 웹으로 만들었다. 믿겨지겠는가?

웹처럼 개발하고 응용처럼 실행되는 이상적인 환경에 이미 많은 프로젝트를 통해 입증했다.

아 피곤해. 당장 도입하겠다는 생각보다는 아무래도 고민이 앞설 것이다.

하지만 크롬은 크롬 앱을 통해 데스크탑 앱 시장에 손을 대고 있고, 웹으로 개발하고 응용처럼 사용하는 시대가 바짝 다가온만큼 비즈니스에서도 기존처럼 IE밖에 모르는 응용처럼 만들고 웹처럼 쓰는 고비용 저효율 자태 그만 뽐내고 이런 새로운 시대에 대응하는데에 고민을 하고 초첨을 맞추기 바란다.

composite / 2013년 12월 9일 / 미분류 / 0 Comments