프론트엔드에게 setTimeout 함수는 단순한 함수가 아니다!!!

일단, 지금 내가 좆같이 외부망 막힌 프론트엔드 개발짓거리 하고 있는 관계로 블로그질을 잘 못하겠지만,
이런 일을 자주 겪어 존나 머리가 쌓이기만 하기에 내 메모리 릴리즈 하는 개념으로 글 씨지르겠다.

프론트엔드 개발하다 보면 이런 경우를 겪는다. 특히 화면 변경할때 말이지.
화면을 변경하다 보면 갑자기 스크립트 오류가 나거나, 원하는 화면이 안나올 때가 있다.
이것으로 머리 싸매다가, 안되겠다. 지연시켜서 뿌려야겠다는 생각으로 setTimeout 함수를 쓰면
원하는 화면변경이 이루어진다. 이상할 정도로.
더 웃긴 현싱은, 타임아웃 주기를 0으로 해도 잘된다는 것이다. 이게 대체 어떻게 된 거지?

먼저, 자바스크립트는 싱글 쓰레드라는 것. 아주 질리도록 들었을 것이다. 비동기도.

하지만 잊지 말아야 할 점은 이 싱글 쓰레드가 하필 화면을 표현하는 렌더링 시점에도 블로킹 현상이 일어나는 점을 간과해서는 안된다.
즉, 스크립트 실행중인 시점에 DOM에 어떤 변화가 찾아올 지 우린 예상할 수 없다는 것이다. 왜냐? 싱글 쓰레드로 하나씩만 진행하기 때문에.
그럼 왜 setTimeout 함수는 회피할 수 있을까? 간단하다.
위 그림을 보면 setTimeout 블록으로 등록된 timer 스레드는 그저 다음 실행 시점으로 예약만 하고 이 스레드에 도달해야 실행되기 때문이다.
그렇다면 왜 setTimeout은 분명 1초인데 1초 빨리 실행하거나 1초보다 늦게 실행하기도 하는가?
먼저, node.js 개발해본 시람은 알겠지만 거기는 setTimeout 함수는 없고 process.nextTick 함수를 사용한다. 그렇다.
원리는 비슷하다. 빠르게 tick 하면서 스크립트가 실행된다. 게임이나 영상으로 치자면 프레임 단위에 무슨 이벤트가 일어난다는 것이다.
보통 1 tick 하면 1/1백만 초다. 백만분의 1초. 하지만 setTimeout은 아무리 최소값이라도 4/1000초.
클라이언트 스크립트에서 tick 단위를 허용기엔 가뜩이나 렌더링이 스레드 예약하고 블록거는데 무슨 일이 일어날 지 검증이 안 된 상황.
자, 일단 여김가지 갔으면 이제 setTimeout 함수로 예약한 함수 루틴은 나머지 구문을 실행한 후 실행하는 것을 알 수 있다.
즉, 렌더링에 시간을 벌어주어 렌더링 후 화면 변경에 대한 정보를 불러오고 쓰는 데 정확도를 높일 수 있는 그런 트릭인 것이다.
그런 고로 화면을 변경할 때, 특히 DOM 데이터를 주고받거나 다룰 때 setTimeout 함수는 DOM 렌더링 시간을 벌어주어 원하는 사용자 처리를 도와주는 프론트엔드에게 고마운 함수인 것이다. 감사하며 쓰도록 하자.

참고: Why is setTimeout(fn, 0) sometimes useful?

composite / 2017년 1월 9일 / Piss Development / 1 Comment

Javascript 파이프라인

어찌보면 나도 간과한 일일 수도 있다.
Javascript 로 열심히 삽질하다 보면 역시 콜백 늪에 안빠져본 자스 개발자는 없을 것이다.
이런 콜백 지옥을 빠져나가기 위해 여러 패턴이 도입되었고, 그 중 대표적인 게 Promise 패턴, Generator, 그리고 async/await 이다.

마침 Play.node() 라는 컨퍼런스가 이미 진행했었고, 공개된 발표자료 중 바로 한눈에 들어온 세션이 있었는데,
그게 바로 Session 3. Pipe: 콜백지옥의 또 다른 거짓 선지자 였다.

그리고 콜백 지옥을 빠져나갈 수 있다는 여러 선지자들, 그리고 세션 발표자가 이를 개선하기 위해 만든 또다른 선지자를 소개하는 시간이었다.
필자는 여기에 참여하지 못해 이 세션의 처음과 끝이 어땠는지는 잘 모르겠지만, 자스 개발자들은 뭔가 너무 차별화된 형식으로 접근하려는 시각이 눈에 띄었다.

그렇다. 너무 차별화되어 다르게 보일 수 있지만 결국 똑같은 패턴.

그게 바로 작업 흐름 관리이다. 영어로 Task flow management.
이를 관리하기 위해 보통 제공되어 사용하는 패턴이 바로 Pipeline pattern 이다.
작업 단위 간 통신을 위해 꼬리를 물고 무는 패턴.

자바스크립트는 싱글 쓰레드다. 그렇기 때문에 얻을 수 있는 이점이 있지만 이를 위해 잃은 많은 것들이 있다.
얻을 수 있는 이점이 바로 비동기 이다. 자스는 비동기에 능하다. 어떤 작업 흐름을 미꾸라지처럼 빠져 나가는 재주를 지녔다.

다른 언어에서도 이런 미꾸라지같이 작업 흐름을 마칠 수 있는 이점을 수용하려 하고 있었고, 이렇게 생겨난 것이
자바의 Future<T> 와 닷넷의 Task<T> 이다. 그리고 닷넷 4.5 에는 asyncawait 문법으로 비동기 작업 흐름 관리에 종지부를 찍을 것 같았다.
자스에서도 이런 종지부를 받아들여 ES7에 들어올 예정이긴 하지만… 언제 들어올지는 아직 모른다. 그렇기에 기대에 부응하지 못하고 오늘도 자스는 작업 흐름을 관리하고 있다.

동시성과 비동시성을 합쳐서 여러 케이스로 작업 흐름을 관리하는 업무는 의외로 많다.
하지만 많은 개발자들은 이를 동기적으로 처리하려고 한다. 왜냐, 그게 편하고 순서있고 보기도 편하기 때문에.

하지만 위 소개된 세션을 통해 이런 자스의 고충을 이해할 수밖에 없는 이유가 있다. 아니. 이해해야 할 수밖에 없다.
바로 자스는 아까 말했듯 싱글 스레드이다. 아까 말했듯이 자스는 어찌보면 너무 많은 것을 잃은 것만 같다.
쓰레드를 여러 개 사용할 수 있는 자바나 닷넷 등이 아니다 보니 쓰레드 단위로 Pipeline 을 갖는다는 것은 매우 어려운 일이다.
그래서 위 세션처럼 비동기 방식의 장점을 살려 바로 이벤트를 통해 작업 흐름을 관리하는 파이프라인을 구현한 것이다.
여기서 가장 핵심 공통점은 바로 작업 간 데이터를 주고받아야 한다. 그리고 이 때문에 구현한 것이다.
자스는 작업 흐름 관리를 위해 콜백 간에 데이터를 주고받아야 하는 일이 많다. 그렇다 보니 전통적인 방법으로는 콜백 지옥이 발생하는 것이다.

그렇다. 자스도 결국 파이프라인 패턴 써야 한다. 작업끼리 물고 물고 늘어진다. 이건 어느 언어나 업무 흐름에 피할 수 없는 숙명인 것이다.
자스는 작업을 관리하는 방식이 다를 뿐, 결국 작업은 파이프라인인 것이다. 어쩌면 동시에 해야 할 수 있고, 그리고 동시에 모두 끝나야 대기탔던 작업 해야 하고.

WE ARE THE HELLO WORLD.

참고자료

Play.node() 발표자료 http://d2.naver.com/news/2602887
자바 : 파이프 스트림과 쓰레드간 데이터 교환 http://javacan.tistory.com/entry/72
닷넷 : C# 쓰레드 이야기: 11. 이벤트(Event) http://www.hanbit.co.kr/network/view.html?bi_id=360

콜백지옥의 또 다른 거짓 선지자 관련 또다른 참고자료

Node.js Flow (part 1) – Callback Hell vs. Async vs. Highland http://blog.vullum.io/javascript-flow-callback-hell-vs-async-vs-highland/
Node.js Flow (part 2) – Fibers and Generators http://blog.vullum.io/nodejs-javascript-flow-fibers-generators/
yortus/asyncawait – Callback heaven for Node.js with async/await https://github.com/yortus/asyncawait

composite / 2016년 1월 6일 / Piss Development / 0 Comments

[JS] String.prototype.replace() 문자열 함수 대체를 허하노라!

제목은 좀 거창하겠지만 그냥 String.prototype.replace 메소드의 함수 사용법 정리다.

먼저 콜백 함수 구조는 아래와 같다.

function(match, p1, [p2... p9, offset, string){
    // insert your code here.
}

인자는 이렇게 알면 된다.

  • match: RegExp.prototype.match() 메소드 실행 후 나오는 배열의 첫자리[0]에서 정규식에 매치된 문자열 전체를 불러온다. 그걸 가져다 쓴다. ($0)
  • p1, p2... p9: 정규식의 그룹 매치 ($1 ~ $9) 인자이다. 그룹 매치는 최대 9개 불러올 수 있으며, 늘어날수록 두번째 기준 인자에서 늘어난다.
  • offset: 정규식이 매치된 원래 문자열 대비 위치이다. 예를 들어 abcd 에서 bcd 매치가 될 경우 offset 값은 1이 된다. 당연히 0부터 시작이다.
  • string: 정규식을 검색하기 위해 사용된 문자열 전체를 불러온다.

여기서 주의해야 할 점은 p1, p2... 인자인데, 이들 때문에 offset이 몇번째 인자인지를 가늠할 수 없다. 당신이 그룹 매치를 몇번 하냐에 따라 인자 위치가 달라지기 때문이다.

이제 거청하지도 않은 설명 끝났으니 예제를 통해 사용해보도록 하겠다.
간단한 템플릿 치환 예제이다.

var tmpl = '내 이름은 [[name]] 이며 나이는 [[age]] 이다.',
    binding = {name: '홍길동', age: 20},
    regex = /\[\[(\w+)\]\]/g,
    callback = function(match, name, offset, string){
        return binding[name] || '그딴거없다';
    };

console.log(tmpl.replace(regex, callback));
//결과: "내 이름은 홍길동 이며 나이는 20 이다."

간단하지 아니한가?

여담:

String.prototype.replace 메소드는 원체 느리다. 가장 빠른 방법이 일반 문자열 replace이다. 어자피 한번만 갈아 끼우기 때문에 빠를 수밖에 없다.
이는 문자열 대체냐 함수 대체나 상관없이 비슷한 성능을 내준다.
그러니 업무상 템플릿 엔진에 성능 신경쓸 시간에 걍 체념하고 이거 쓰거나 어떤 이가 만들어준 템플릿 엔진을 쓰자.

ECMAScript 6 의 새로운 문법인 템플릿 문자열이 있다. 사용법은 아래와 같다.

var binding = {name: '홍길동', age: 20},
    tmpl = `내 이름은 ${binding.name} 이며 나이는 ${binding.age} 이다.`;

console.log(tmpl);

PHP 쓰거나 .NET 4.6 쓴 사람에겐 익숙한 문법이긴 하지만 역따옴표(`)를 쓴다는 게 특이점이라 하겠다.
ES6 트랜스파일러인 Babel.js 는 위 문법을 쓰면 아래와 같이 변환한다.

'use strict';

var binding = { name: '홍길동', age: 20 },
    tmpl = '내 이름은 ' + binding.name + ' 이며 나이는 ' + binding.age + ' 이다.';

console.log(tmpl);

그렇다. 문자열 합치기(string concatenation)를 사용하여 간단하고 성능 좋게 해석했다.
아직은 이 기능이 네이티브로 들어간 모습은 못봤다. 그래서
트랜스파일링 시간과 표현 시간이 합쳐져서 아직까지 성능은 느리게 나온다.
직접 테스트하고 싶으면 http://jsperf.com/es6-string-literals-vs-string-concatenation 가면 된다.

그럼 이만.

composite / 2015년 12월 23일 / Piss Development / 0 Comments

프록시 자동설정 원리

Weblock 이라는 아이폰 앱이 있다.
이 앱은 광고 사이트나 패턴을 정리해서 프록시 자동설정 파일 (Proxy Auto-config, PAC)을
만들어 적용하여 사파리 등의 웹 브라우저에서 짜증나는 광고를 안띄워주는
고마운 프로그램이다.

필자의 경우 이 Weblock 을 무료일 때 다운받았는데, 이 앱 덕분에 쾌적한 브라우징을 할 수 있었다.
그렇다면 이 원리는 무엇인가?

해답은 바로 Weblock 을 사용하면서 URL을 보면 js URL을 복사하는 부분에서 찾을 수 있다.
이 url 복사 후 붙여넣으면 js 소스가 뜨는데 이게 바로 PAC에서 사용하는 JS다.

운이 좋게도 이 PAC 스크립트를 작성하는 가이드를 한글로 제공한 고마운 분이 있으니,
미꾸라지 PAC (Proxy auto-config) 문법 링크를 참조하라.
이 글에서는 간단한 작성법만 나열하므로 PAC에 대한 전체적인 레퍼런스를 보고 싶으면 위 링크로 가도록.

먼저, 이 스크립트를 처음 작성한다면 먼저 JS에 대한 기초 지식이 요구되며, 단 3가지 문법만 기억하면 된다.

//1. 첫번째 프록시 접속 후 실패 시 두번째 프록시 접속. 세미콜론(;)으로 구분하여 작성하면 된다.
var PROXY_URL = "PROXY proxy1.example.com:8080; PROXY proxy2.example.com:8080";
//2. 프록시를 사용하지 않고 직접 접속하는 키워드이다. 
var DIRECT = "DIRECT";
//3. 이제 적용하기 위해 함수를 작성하는데, 함수명은 FindProxyForURL 이 되시겠다.
//   콘솔 프로그램의 main 함수와 같은 역할을 하는 프록시의 주 실행 함수이다.
function FindProxyForURL(url, host){
    // example.com 및 그 하위 도메인은 직접 접속하도록 한다.
    if (shExpMatch(host, "*.example.com"))
    {
        return "DIRECT";
    }

    // 임의 도메인을 접속 시 아래 지정된 IP와 마스크로 접속했을 경우
    // fastproxy.example.com 포트 8080 이라는 프록시로 접속하도록 한다.
    if (isInNet(host, "10.0.0.0", "255.255.248.0"))
    {
        return "PROXY fastproxy.example.com:8080";
    }

    // 그리고 마지막으로 모든 접속을 proxy.example.com 포트 8080 으로 접속한다.
    // 만약 프록시 응답이 없을 경우 할 수 없이 다이렉트로 접속한다.
    return "PROXY proxy.example.com:8080; DIRECT";
}

끝이다. 어때요. 쉽죠?
위 파일을 js로 저장 후, 각 브라우저에서 프록시 설정에서 자동 프록시 설정할 때 저 스크립트를 작성한 URL을 지정하면 된다.
아이폰이나 안드로이드 같은 모바일 환경에서는 Wi-Fi 연결 시 프록시에서 자동 선택 후, URL을 입력하면 된다.

자. 이제 이 PAC을 응용하여 간단한 Ad-block 스크립트를 작성하도록 하겠다.


//직접 접속 키워드 var PROXY_DIRECT = "DIRECT"; //차단 키워드 //Dummy Proxy로 차단한다. 해당 IP는 구글 DNS IP이다. //즉, 실제 프록시도 아니고 어자피 응답 실패하는 거 알지만 //이걸 이용해서 광고 사이트를 무조건 실패하는 프록시로 강제 접속하는 //마법의 키워드이다. var BLACK = "PROXY 8.8.8.8:53"; function FindProxyForURL(url, host) { var u = url.toLowerCase(); var h = host.toLowerCase(); //광고 호스트 중 하나인 onclickads.net 호스트이거나, 페북에서 사용하는 광고 이미지를 더미 프록시로 차단한다. if (dnsDomainIs(h, "onclickads.net") || shExpMatch(u, "*/fb*akamaihd.net/*image.php*facebook.com*ads*image*")) { return BLACK; } //나머지는 직접 접속으로 정상 접속하도록. return PROXY_DIRECT; }

그리고 이걸 당신의 웹호스팅이다 Github Page에 넣고 자동 프록시 설정 주소에 넣으면 광고차단 효과가 있을 것이다.
이게 끝인가? 맞다. 끝이다.

마지막으로 PAC 스크립트 작성시 주의점을 알려주겠다.

  • 몇몇 브라우저는 PAC 스크립트 파일의 인코딩을 시스템 인코딩에 따른다. 예를 들면 IE는 UTF-8을 인식할 수 없다. 특히 한글 입력은 왠만하면 하지 말자.
  • 크로스 플랫폼 PAC 스크립트를 작성 시 가능하면 옛날식 JScript 시절 표준을 따르는 것이 좋다. 각 브라우저나 OS 자바스크립트 엔진을 따르기 때문이다.

참고자료

composite / 2015년 7월 15일 / Piss Development / 0 Comments

ECMAScript 6 Harmony 를 네 브라우저에 돌려봐라!

나 참.. 기분 존나 나쁘네.

뭐? CoffeeScript? TypeScript? 어쩌고 저째? 자바스크립트가 죽을 거라고?

난 동의 안한다. 제아무리 자바스크립트를 편하게 만들어도 오리지날이다. 결국 그들도 자스로 움직인다. 제아무리 편해도.

스칼라가 결국 자바에서 돌아가기 위해 자바 코드로 생성해서 컴파일 하는 것처럼 말이다.

튜닝의 끝은 순정이란 말이 괜히 나오는게 아니지.

그래서 소개한다. 니 브라우저에 직접 ECMA 6 을 적용할 기회를 내가 선사해 주겠다. 2가지 프로젝트가 있다.

1. Traceur

구글신은 미쳤다. 이번에 소개할 피로젝트는 자바 2명 타요가 아닌 외계인 2명 타요 해서 ECMA 6을 몸소 체험할 수 있는

Traceur 를 소개한다.

프로젝트 페이지는 https://github.com/google/traceur-compiler

이 스크립트 컴파일러는 ES6 을 당신 브라우저에 돌릴 수 있게 한다.

일단 IE 8은 안된다. 쳇. 최소한 8이라도 지원해주지.

크롬과 불여우는 일단 된다. 올ㅋ

Traceur 가 지원하는 ECMA 6 기능이다.

일단 여태 나오고 알려진 것들을 지원한다.

하지만 이 ES6 하모니를 쓸 때 몇가지 주의할 점이 있다.

알다시피 ES6은 확정된 표준이 아니다. 특히 클래스와 모듈이 그 대표적인데, 이들이 어떻게 바뀔지는 장담을 못하겠다.

제발 안바뀌길 바래라.

뭐.. 그래봐야 기반 스크립트 (타입스크립트 등) 또한 아직까지 안정화된 버전을 내놓지 못하고 있기 때문에

물론 커피스크립트는 상당히 안정화 되고 쓰는 사람 많은거 안다.

근데 뭐가 좋다 말을 못하겠지만, 그래도 그런 스크립트는 표준에 넣지 못할 것이다.

난 커피스크립트가 자바의 스칼라처럼 생각하지만, 그래도 스칼라도 많이 쓰지 않는가? 물론 갈라파고스 한국은 빼고.

난 표준을 만들고 따르는 주의자긴 하지. 자바스크립트는 아직까지는 강력하기 때문에. 단지 좀 귀찮고 짱나서 그렇지.

어쨌든, ES6 을 직접 체험해보고자 한다면, 이 컴파일러를 이용해 제작된 ES6Fiddle 을 사용하라.

http://www.es6fiddle.net/

ECMAScript 6 이 어떻게 돌아가는지 알 수 있을 것이다.

2. continuum 

그에 비해 이 ES6 컴파일러는 커뮤니티의 참여로 만들어졌다. 그다음 낫고, IE 8부터 지원해주기 때문에 우왕굳.

프로젝트 사이트는 https://github.com/Benvie/continuum

체험 사이트는 http://benvie.github.io/continuum/

현재 구현된 기능들이다.

  • 통합 할당 및 인자
  • 가변 처리자 및 배열 초기자
  • 가변 인자
  • 클래스와 상속
  • 화살표식 함수(람다식) (.NET 의 람다식과 동일한 형식)
  • 블록 단위 변수
  • 새로운 Math 함수
  • 새로운 Object 함수
  • 새로운 String 함수
  • concise methods in object literals
  • 열거 및 삭제 가능한 프로토타입
  • Map, Set, 그리고 WeakMap (가비지 컬렉션이 현실화되지는 않았음)
  • 열거자와 for…of 반복문
  • 템플릿
  • 모듈과 imports, exports
  • 내장 ‘@std’ 모듈 module std = [email protected]' 또는 import call from [email protected]'
  • 생성기
  • 프록시와 리플렉션
  • Symbols with syntactic @name support
  • 형식화된 배열Typed Arrays
  • Object.observe (es-next/es7)
  • 인자 기본값
  • 꼬리물기 호출 최적화
  • 배열 초기화 식 (부분 지원)

아래 기능은 아직 구현이 안되어 있으며 추후 지원될 예정이라 한다.

  • 생성기 식
  • 이진 데이터 api (structs, etc.)
  • 프로미즈 (내가 Feature request 했음.)

물론 프로미즈같은 경우 promisejs 또는 q 로 해결은 가능하기 때문에 커버는 해줄만 하다.

ECMA 6 기능에 목이 말랐다면 지금 바로 체험하라.

아참, 마지막으로 ES6의 새로운 기능을 한글로 잘 정리한 위키 페이지가 있어 이걸 소개하고 쿨하게 끝내겠다.

http://wiki.codekin.com/index.php/ECMAScript_%ED%95%98%EB%AA%A8%EB%8B%88

끝이다.

추신 업데이트 사항 : Traceur 외에 나머지 ES6 컴파일러는 몇달동안 활동이 없다. 그냥 Traceur 써라. 진자끝.

composite / 2014년 2월 25일 / 미분류 / 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

어도비에서 만든 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.js 이전 추억이 되버린 자바스크립트 서버단…

1. Classic ASP

ASP에 자스 지원하는거 아는사람이 얼마나 있을까? ASP 개발자들 대부분 비베 썼을텐데.

하지만 자바스크립트 또한 지원했다. 윈도우 스크립팅 엔진에 비베와 자바스크립트 둘 다 들어가 있다보니.

물론 그때당시 Javascript 란 단어가 상표권이 있어서 JScript 라고 명명하긴 했지만 요즘은 좆망 엔진.

지금 자스 말고 마소에 내장된 자스 엔진 말하는거다. 자스 개발자인 내가 왜 자스를 욕하나?

일단 자바스크립트만 알면 접근성이 용이하다는게 장점이고, C언어처럼의 코딩 스타일로도 제격이다.

예를 들어보자.

<%

Dim myVar

myVar = “내가 니 앱이다.”

Response.Write myVar

%>

추억 새록새록하지 않는가? 아.. 지금도 ASP 쓰는데 있지. 아무래도 기존 프로젝트가 있다보니.

지금도 ASP로 HTML5 라던가 DB 접근성은 별 달라진 거 없이 그냥 쓰면 된다. 확장성이 개같은거만 빼고는.

그리고 요즘 많이 사용하는 JSON도 쓸 수 있으며, JSON2.js 를 ASP 스크립트에 그대로 첨부하여 JSON.stringify 같이 직렬화 병렬화도 지원되 Ajax 기술 쓰는데 지장이 없을 정도로 꽤나 강력하다.

<%

var myVar = “내가 니 앱이다.”;

Response.Write(myVar);

%>

하지만 아무래도 불편해서 잘 안쓰는 이유가 바로.. 대소문자 구분이다. 비베에 익숙한 ASP 개발자라면.

예를 들면, 비베는 이렇게 해도 동작한다.

response.write “뭐”

RESPONSE.WRITE “왜”

ReSpOnSe.WrItE “어”

하지만 자스는 대소문자를 가리기 때문에 당연히 지켜야 하며, 모든 API는 카멜케이스로 대문자부터 시작한다.

Response.Write(“뭐”);

이렇게 안된다.

response.write(“왜”); //오류남.

또한 ASP API 가 비베에 맞춰져 있다 보니 자스를 어떻게 잘 쓰기도 불편할 것이다.

지랄, 노력하면 ASP 를 js 코딩하는데 존나 편하다. Ajax 할때 자스 짱짱맨이다. 실제 2009년 모업체 고객불편센터 프로젝트에 그렇게 썼고 Ajax 기술을 아무렇지도 않게 잘 소화해냈다. DB가 오라클인건 비밀.

아, 유지보수는 이게 시발 이딴 코딩이 다있냐며 나 존나 욕하겠지만 ㅋ

2. Jaxer

Ajax 기술이 뜨면서 Web 2.0 이 아주 질리도록 듣는 시절, 웹표준 지키는 코딩은 개발자들 사이에서 단연 이슈였다.

물론 어자피 IE만 쓰니 IE 중심 코딩 하라는 나이 똥꾸먹으로 쳐먹은 개발자도 있긴 하다.

그 중에 Aptana. 신개념 웹 환경에 목마른 개발자라면 알 것이다. 마의 자바스크립트 IDE 아니던가? 그것도 유료 프로그램..

그들이 내놓은 서버단 솔루션을 개발했는데. 이름하여 Jaxer. 서버단 자바스크립트 되겠다.

 이녀석이 쓰는 거 좀 재밌다. 하이브리드고, Javascript 다.

<script runat=”server”>

//..서버단 자스. 클라이언트에서는 안보임

</script>

<script>

//..클아이언트단 자스

</script>

<script runat=”both”>

//..서버도 인식하고 클라이언트에서도 돌아가도록 남김.

</script>

따라서 jQuery 를 서버와 클라이언트단 동시에 돌리는 위엄을 토한다.

<script type=”text/javascript” src=”jquery.js” runat=”both”></script>

<script>

$(function(){

    $(‘#hello’).html(‘world’);

});

</script>

<script runat=”server”>

$.each(dbFetch, function(){

    // fetch data…

});

</script>

하지만 기대는 컸으나 실망이 더 컸다. 나도 이거 쓰려다 말았고, 못해먹겠다.

그 이유는…

  1. 아파치 종속모듈. 뭐.. 그건 이해하지만 제약이 꽤나 많았다.

  2. JSP의 스크립틀릿 같은 개념이 없다. <%=myVar%> 클래식 개발자에겐 낮은 접근성. (그렇다고 확장성도 별로..)

  3. API가 독자적이면서 많고, 어려우며 동기적이다.

<

p>

큰 단점 : 버그 존나 많고 성능 개같고.. 낮은 접근성까지.

node.js 반만 닮아갔어도 아마 명맥을 유지할 지도 모른다.

그리고 Jaxer 는 더이상 명맥을 유지하지 못하고 어느 네크로맨서 개발자가 다시 부활시켜 Github 에 오픈소스로 고이 모셔뒀다.

그리고 Aptana 는 자바스크립트로 네이티브 앱을 만드는 솔루션을 가진 Titanium 에 흡수되어 Titanium Studio 를 개발중에 있다.

그리고 Aptana 는 아예 오픈소스로 무료로 공개했지만, 지금도 기능은 막강하다. 자바 개발자에겐 웹개발에 신세계를 줄 것이다.

왜냐? 이클립스 플러그인으로도 깔 수 있으니까. 기회되면 한번 깔아보고 해봐. 이렇게될거야.

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

IE 7,8 의 onbeforeunload 버그

방금 업무전에 황당한 일을 옆 직원이 겪었다.

“a 버튼을 클릭했을 뿐인데 onbeforeunload 가 동작한다.”

…?????

엉?

“페이지 바뀌나?”

“안바뀐다.”

엉??????????

갑자기 눈앞이 캄캄해지고. “일단 좀 더 수정해보겠다” 는 말을 듣고 검색해봤다..

살다살다 이런 버그도 있었다.

구글 검색 결과,

<a href="javascript:void(0)" onclick="javascript:alert('Hi');">Do Something </a>

그리고 onbeforeunload 이벤트 핸들러 내용

window.onbeforeunload = function() {
    return 'before?';
}

<

p>이 코드를 직접 IE 7이나 8에 돌려본다.

javascript 같은 타 프로토콜이고 뭐고 페이지가 안바뀌는데 onbeforeunload가 작동된다.

최신 브라우저는 페이지가 바뀌는 루틴이 감지되면 작동하는데, 이녀석은 프로토콜을 감지해서 루틴을 작동시키는건가?

거짓말같이 Hi 나온 뒤 before? 메시지가 들어왔다.

이렇게 수정하라.

<a href="#" onclick="javascript:alert('Hi');">Do Something </a> 

즉, onbeforeunload 이벤트가 있다면, a 태그에 href 안에 자스던 멜주소던 넣지 않는게 최선이다. 그리고 돌리면 된다.

Hi 만 뜨고 말 것이다.

오늘 어이없는 버그를 보고 내가 해결해주고 IE 개발자한테 이 짤을 던지고 끝내겠다.

A2vdf7PCAAAmcOe.jpg:large (474×245)

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