프론트엔드에게 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

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 = '@std' 또는 import call from '@function'
  • 생성기
  • 프록시와 리플렉션
  • 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

어도비에서 만든 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

지연된 객체 (Deferred Object) 만들기 – 오리지날 JS편

오랜만에 골때리게 한번 팁을 날려보겠습니다.

jQuery 1.5 에서 획기적이지만 잘 안쓰는 게 있죠.

바로 지연된 객체(Deferred Object) 입니다.

이 객체의 위력을 정말 느껴본사람 빼고는 잘 안쓰죠.

이놈의 패턴이 어떻냐..

$.get(‘/serv/get.php’,null,function(){

     alert(‘뭘 받아온듯.’);

});

이 기존 패턴과

$.get(‘/serv/get.php’)

    .success(function(){

        alert(‘뭘 받아온듯.’);

    });

이 제이쿼리에서 제안한 패턴과 똑같은 효과를 줍니다.

뭐.. 느낌상 패턴은 당연히 틀리죠.

분명 Ajax는 비동기 스크립트입니다. 하지만 동기한 것 처럼 뭔가 착각을 불러일으키기도 하고.

바로 비동기 스크립트를 이렇게 눈에 보기 좋게 꾸며 놓는다는 장점이 있습니다.

node.js 개발하다보면 이벤트 중점적이다 보니 종종 비동기 쓸때 이런 패턴이 발생합니다.

var mongodb = require(‘mongodb’),

Db = mongodb.Db;

var db = new Db(‘test_db’, new Server(process.env[“MONGODB_HOST”], process.env[“MONGODB_PORT”], {}));

db.open(function(err, db) {

     db.collection(“test_collection”, function(err, collection) {

          collection.find({“cmd”:cmd}, {“sort”:”order”}, function(err, cursor) {

               cursor.each(function(err, item) {

                   if (item != null) {

                       // Do something

                   }

                   if (item != null) {} // 반복문 끝

                });

           db.close();

           });

  });

});

오우 쉣. 함수안에 함수안에.. 너무 지저분합니다.

하지만 제이쿼리가 제안한 지연된 객체 패턴으로 간다면 저걸?

db.open()

.collection(‘test_collection’)

.find({“cmd”:cmd}, {“sort”:”order”})

.fetch(function(err,cursor){

cursor.each(function(err, item) {

if (item != null) {

// Do something

}

if (item != null) {} // 반복문 끝

});

})

.close();

이런 식으로 비동기 스크립팅에 제이쿼리의 최강무기 메서드 체이닝을 구사할 수 있다는 겁니다.

물론 저런 패턴 제공하는 놈은 아직까지 없으니 그대로 따라하지 마시길. 그냥 예를 든거니까요.

그럼 어떤 원리로 하는건지 오늘 골때리게 설명해 드리도록 하겠습니다.

일단 먼저, 동적 클래스의 개념과 클로저 개념을 이해하고 있어야 합니다.

저는 그 이해를 하고 있는 분으로 간주하고 팁을 씁니다. 모르면 문학이님이 떡하니 강좌 올려놨으니 보시길.

..라고 무섭게 얘기했는데. 어렵지 않습니다. 먼저 동적 클래스를 만들 함수를 하나 짜주세요.

fuynction MyDefferd(){

this.fn={};

//초기화 할거 있음 하덩가.

}

그리고 지연된 객체에서 체이닝에 사용할 프로토타입 함수 하나 만들겠습니다.

MyDefferd.prototype.done=function(func){

this.fn.done=func;

};

뭐.. 준비 끝입니다.

그리고 이제 지연된 객체를 리턴할 함수를 하나 만들겠습니다.

그리고 이 함수는 비동기 작업을 할 겁니다. 간단하게 setTimeout 을 쓰겠습니다.

function Deffer(delay){

var deff=new MyDefferd();//아까 만든 지연객체를 동적으로 하나 불러와 주시고.

alert(‘작업 시작!’);

setTimeout(function(){

if(typeof(deff.fn.done)==’function’)

deff.fn.done();//done 함수를 끌어다 씁니다.

},delay*1000);//몇초 후에? 님이 쓴 초 후에.

return deff;//반드시 동적 지연 객체를 반환해줘야 합니다!

}

이것으로 지연객체 패턴을 사용할 수 있는 함수를 쓸 준비가 끝났습니다. 참 쉽죠?

어떻게 쓰냐? 간단합니다. 예를 들어 3초 후에 작업 끝 메시지가 나오도록 꾸며보겠습니다.

Deffer(3).done(function(){

alert(‘작업 끝!’);

});

그럼 처음에 작업 시작이란 경고창이 뜬 다음, 3초 후에 작업 끝이란 경고창이 뜰겁니다.

그렇게 나오면 성공!

어때요. 참 쉽죠?

동적 클래스는 함수 종료 후 클로저 때문에 메모리 다시 반납해 하는걸 개나 줘버라는는 성질 덕분에 deff 함수에서 언제든지 저렇게 동적 클래스 안에 있는 데이터를 잃지 않고 갖다 쓸 수 있습니다.

이걸 이용해서 지연된 객체를 통해 비동기 스크립트 패턴을 동기 스크립트 패턴같이 꾸밀 수가 있는 것이죠.

이런 지연 객체를 응용해서 Ajax는 물론, node.js 에서 할 수 있는 대부분의 비동기 작업에서 여러분의 눈을 정화시키는 패턴을 만들 수 있을 것입니다.

그리고 쿨하게 오늘의 골때리는 팁을 마치겠습니다.

링크 #1은 지연된 객체 패턴을 이용한 동적 스크립트 불러오는 함수입니다.

링크 #2는 이 강좌 예제입니다. 바로 실행되고 또 하고싶음 run 버튼 누르셈.

라이센스 : 해당 강좌에 사용한 기술은 죽써도 밥써도 상관없는 Public Domain. 강좌 자체는 크리에이티브 커먼즈 라이선스

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

생성자.prototype 와 생성자.constructor.prototype 의 차이점

예전에 어떤분이 좋은 질문을 올려주셔서 제가 냅다 답변한 글이 있습니다.

이걸 팁으로 올림으로써 자스 프로그래밍 하면서 답답했던 부분이 해소되기 바랍니다.

Q)

자바스립트는 모든 함수에 대해서 prototype과 constructor이라는 속성을 지원한다고 합니다.  그런데 교재에 몇 가지 혼동되는 표현이 있어서 질문드립니다.

생성자.prototype

생성자.constructor.prototype

이 둘이 뭐가 다른가요?  prototype은 클래스 외부에서 아직 개체가 되지 않은 것의 this를 나태내고.
constructor는 객체의 prototype를 만든 함수를 반환하는 것으로 알고 있습니다.  그러면 첫 번째의 것은 생성자의
this를 나타낼 것이고, 생성자.constructor.prototype은 뭐죠?  도무지 알 수가 없네요.  이거 너무
헷갈립니다.

A)

네. 다릅니다.

constructor 속성은 일종의 상속 개체를 반환한다고 보면 되는데

예를 들어 function A(){} 라고 A 클래스를 만들었을 때,

A.prototype 는 당연히 A 자신을 나타내지만

A.constructor.prototype 는 A를 창조한 부모가 함수 구문이기 때문에 Function 객체에 대한 prototype 를 반환합니다.

따라서

A.prototype 의 this 는 A가 되겠으며

A.constructor.prototype 는 A를 창조한 Function 객체가 this 로 반환되겠습니다.

이 때 햇갈리는 부분이 바로 개체 생성 후 this 에 대한 참조인데요.

A.prototype.b=function(){

    console.log(this.prototype);

    console.log(this.constructor.prototype);

};

일 경우에는 둘 다 같은 결과가 나오지만 이 때 주의해야 할 점!

this!=this.constructor

this 는 생성한 객체를 참조하기 때문에 a 가 되겠으며, this.constructor 는 생성자를 참조하기 때문에 A 가 되겠습니다.

composite / 2013년 1월 22일 / 미분류 / 0 Comments