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

또다른 오픈소스 IDE: Consulo IDE

흐음… 한국에 자바 IDE 쌍벽은 아무래도 Eclipse 와 IntelliJ 일 것이다.
Netbeans 도 있긴 하지만 쓰는 사람이 드물어서…

어쨌든 간에, JetBrains 에서 .NET IDE 만든다고 한 지 2주.
근데 댓글에서 심상치 않은 IDE를 발견했다.

이름하여 Consulo IDE 이다.

Consulo는 IntelliJ IDEA Community Edition의 쉘 전신인 IDEA IDE 베이스로 만들어진 오픈소스 IDE이다.
현재 안드 공식 개발 툴인 IntelliJ IDEA 기반의 쉘 UI 프레임워크가 오픈했다라…
엉? IntelliJ에 썼던 UI가 오픈소스라고?

정말 있다. 오픈소스로. IntelliJ Community Edition

그렇다. 커뮤니티 에디션에 한해서 오픈소스로 공개하긴 했다.
게다가 Apache 2.0 라이선스다. 상업적으로 써도 문제는 물론 없다.
아니었으면 상업적으로 안드로이드 개발은 물건너 갔을테니.

어쨌든, 다시 Consulo로 돌아가자.

Consulo는 현재 C#, Javascript, Java 등을 지원하며, 모든 언어를 지원하는 하나의 IDE로 통일하겠다는 목표를 가지고 있다.
안타깝게도 안정된 버전이 아니라서 실무에 쓰기는 조금 어렵지만,
유니티 개발자들이 이 IDE를 주목하고 있다.
왜냐?
모노IDE가 좆같거든.

인텔리 기반이라 인텔리 플러그인을 지원 하기는 한다. 조금 손을 봐줘야 한다고 한다.
마이그레이션 과정을 거치는데, 아무래도 라이선스 이슈 때문이다.
불편하더라도 인텔리제이와는 분리해야 써야 하는 이유이기도 하다.

Add a plugin

JetBrains 에서 Project Rider 로 C# IDE를 꾀하고 있고.
아마 유니티 개발에서 하나의 변수로 떠오를 가능성이 큰 상황이다.
어자피 모노와 닷넷은 API가 틀리지 언어 구조와 스펙까지 틀린 건 아니니
지켜봐야 할 내용이고,

거기에 오픈소스로 강공을 펼칠 Consulo IDE에도 주목할 필요가 있다.

IDE 전쟁이 시작되는 것이다. 우오.

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

jQuery paging plugin update

jQuery paging plugin

내가 이걸 개발하고 방치한 지 3년이 지났다.
하지만 의외로 사람들이 페이징 플러그인을 찾다가 내 블로그에 들리기도 한다.
그리고 어느 블로그에서 내가 만든 페이징 플러그인을 소개하기도 했다.
그래도 돌아가긴 하나보다. 안정적으로.

그래서 오늘 오랜만에 재대로 손 좀 대봤다.
0.1.7 에서 0.2.0 으로 업데이트 했다.
기존 버전과 달라진 건 크게 없는데, append 속성이 쓸모 없어져서 제거하고, className 으로 컨테이너 관리 편의성을 높여준 업데이트이다.
나머진 기존 그대로 쓰면 되긴 하지만, 좀 더 편리하게
재호출할 때를 대비하여 일부 속성만 정의해도 기존 속성에서 정의 속성을 덮어씌워 페이징을 구성하겠끔 만들었다.
그렇다 보니 destroy 키워드가 생겼다.

아, 그리고 마지막으로 이건 문서에 안넣었는데, .paging(‘속성명’) 을 통해 속성값을 불러올 수 있다.
이는 아직 실험 단계지만, 조만간 편리하게 페이징이 처리되도록 할 생각이다.

프로젝트 페이지는 여기로 가면 되고,
bower 설치도 지원한다. bower install jquery.paging

언제까지나 유의사항은 “스타일링은 알아서 하라” 이다.

앞으로도 많은 성원 바란다.
감사하다.

독자: 이 미친새끼가 반말하고 지랄이야.

composite / 2016년 1월 26일 / Piss Development / 2 Comments

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

Symbol 프로그래밍?

https://en.wikipedia.org/wiki/Symbol_(programming)

심볼. 굳이 우리말을 쓰자면 기호. 기호 개발. (뭔가 어색하다?)

오늘 페북에서 ECMAScript 6 표준에 Symbol이 정의되어 누군가가 MDN에 번역해 주었다.
Symbol – Javascript | MDN
심볼. 아마 자바, 닷넷, 자스 개발자 등에게 어찌보면 생소한 개념일 수 있다.
하지만 루비 개발자나 Object-C 개발자는 이미 있기 때문에 알고 있을 것이다.
이 심볼 개발방법은 여러 스크립트 언어 등에서 채택한 개발론이다.

간단하게 설명하자면, “가장 유일한 식별자”다.
뭐?
루비(Ruby)의 심볼이란?

정의는 한 번. 더 이상 변경할 수 없는 값이다.
여기까진 상수와 비슷한 개념이다.
그렇다면 값 비교 시 “A” 와 “A”가 같다? 심볼은 그딴거 없다.
그렇다. 심볼의 값은 일종의 사람만이 식별하기 위해 존재하는 값일 뿐.
문자열 값은 리터럴을 정의할 때마다 메모리가 늘어난다. 설령 변수를 지정하던 상수를 쓰던.
간단하게 생각해보자.
“A” “BC” “DEF”… 이들은 언제 바뀌지 못하기 때문에 불명확한 메모리를 할당받으며 서 있다.
당연히 그런 만큼 메모리를 잡아먹는다.
하지만 심볼은 딱 정해진 메모리만큼만 먹는다. 바뀔 일도 없기 때문에. 확장할 일도 없고.
그러니 메모리 애끼는 효과가 있다.

그렇다면 어따가 쓰냐고?
가장 쓰임새가 많이 쓰이는 곳이 바로 “해시 값”을 다루는 데에 쓰인다.

JS에 새로 정의된 Symbol을 통해 예제 하나 뿌리겠다.
ES6 Symbol Test 예제

var obj = {};
var a = Symbol("a")

obj[a] = "a";
obj[Symbol.for("b")] = "b";
obj["c"] = "c";
obj.d = "d";

for (var i in obj) {
   console.log(i); // logs "c" and "d"
}

console.log(obj[a]); //logs "a"

심볼 “a” 란 해시 키에 “a” 값을 넣었다.
근데… 반복문에는 나타나지 않는다.
그렇다. 주소 값이니 나오지 않을 수밖에.
대신에 명시적으로 해시 키를 정의하면 가져올 수 있다.
이런 이득이 있다는 것이다.
그렇다면 이런 특징으로 얻을 수 있는 이득이 뭐가 있을까?

간단하다. hidden 키와 값을 넣을 수 있는 그런 개발이라면 모두 가능하다.
일종의 private identifier 인 셈이다.

자. 이제. 자바와 닷넷도 이런 개념이 존재하냐고 물어보는 사람이 있을 것이다.
당연히 없다. 근데 자바와 닷넷은 문자열에 한해 인터닝(Intern) 이라는 개념이 있다.

자바의 String.intern() String.intern()은 메모리를 아낄 수 있다?

  • String pool에 있는 각종 문자열에 equals해서 같은게 있다면 그 놈을 반환하고,
  • 같은게 없다면 String pool에 String object를 추가하고, 추가한 놈을 반환한다.

즉, String 객체를 리터럴로 관리하여 메모리 절약을 꽤하는 개념이다.
그렇다 보니 아래와 같은 단점이 존재한다.

  • 우선 String 객체를 하나 만들어야 한다.
  • String의 equals 메소드를 이용해서 String pool에 있는 놈을 찾아서 비교해야 한다. ( 시간이 걸림 )
  • String pool에 들어 갔으므로, 더 이상 GC(가비지컬렉션)의 대상이 될 수 없다. ( 메모리 관리 불가 )

그렇기 때문에 적재적소에 잘 관리해야 한다는 점이 있다. 그래도 같은 문자열을 객체로 정의하여 메모리 쳐묵보단 낫다.

참고로 닷넷도 아주 동일한 개념이다. String.Intern() 메소드 쓰는 건 매한가지이며 동일하기 때문에 별도의 설명은 생략하겠다.

자. 자바와 닷넷이 문자열을 관리하는 방법이 여기서 나온다. 리터럴은 자바나 닷넷이나 내부 풀을 따로 운영하여 저장한다. GC에 걸리는 걱정 없이.
(물론 new String 처럼 객체로 만들었다면 걸릴 각오는 해야 하지만.)

뭔가 삼천포로 빠진 것 같다.
하지만 메모리를 아껴서 빠르고 유연한 개발을 꾀하는 개발자는 있다.
이럴 때 필요한 것이 뭐고, 뭘 알아야 하는지는 개발자의 사명인 것이다.
그러기 위해 이 포스트를 올렸다.
그럼 이제…

끗.

composite / 2015년 11월 17일 / 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

현재 실무에서 사용 가능한 100만개 Row 지원하는 무료 그리드 라이브러리

구글 검색하다가 어떤 새끼가 블로그에 그리드들은 HTML5 표준 아니고 jQuery 장식 플러그인이 아니라는 등의 불안감을 조성하여 웹을 포기하고 응용으로 돌아가겠끔 글 싸지르고 다닌다.

그게 2011년이었다. 근데 그때도 솔루션을 이미 쓴 곳은 별 문제 없다.

하지만 지금 2014년 HTML5 표준 재정 전인데 위 이슈로 씨부리는 새끼가 아직도 있다. 무시하자.

HTML5 표준에서 뭐하러 그리드 만드냐? 그리드 외에 여러가지 컴포넌트 편리하게 표준 만드는 것만으로도 감사해야지.

어쨌든 니들이 어쩌면 이미 사용하고 있을 테고 앞으로도 필요할 것 같은 무료 그리드 라이브러리를 보라.

1. jqGrid

HTML 웹 프로젝트에서 많이 알려지고 많이 사용하고 있는 프로젝트.

3.7 부터 가상 스크롤 지원으로 100만개 행도 문제없이 출력

현재 쓰기 쉽고 가장 많이 쓰는 제이쿼리 기반 프레임워크

상용 모듈도 출시했으나 기본 jQGrid 라이브러리는 MIT에서 바뀌지 않는다고 공식 블로그에서 밝혔으므로 기업에서 문제없이 쓸 수 있다.

단점은 좀 무겁지만 어느정도 개선됨.

상용의 경우 모바일 지원 및 기술 지원을 받을 수 있음. (물론 영어)

2. SlickGrid

대량 데이터를 순식간에 뿌리는 최초의 라이브러리로 먼저 소문난 라이브러리.

의외로 가볍고 제이쿼리 기반이며 자체 성능이 우수하다.

단점은 어려운 사용법과 뜸한 버전업. 하지만 커뮤니티가 활발하기 때문에 충분히 커버된다.

MIT 라이센스이기 때문에 기업에서 문제없이 쓸 수 있다.

상용이 없으며 기술 지원을 받을 수 없다.

3. DataTables

예전에 비해 많이 성숙해지고 깔끔해졌으며 속도도 향상되고 심지어 CDN까지 지원하는 (jQGrid도 마찬가지지만) 막강한 라이브러리.

초반에 한국에서는 많이 알려져 있지 않고 지금도 이거 쓰는 곳은 찾아보기 힘들 정도로 국내는 인기가 없으나, 지금은 대적할 만 하다.

페이징 기반 그리드에 최적화되고, 그리드에 불필요한 기능은 확장으로 채울 수 있다.

대량 데이터를 위한 가상 스크롤 또한 확장으로 사용 가능하며 기본 다국어가 지원된다.

MIT 라이센스로 기업에서도 쓸 수 있으며, 활발한 커뮤니티로 문제 해결을 할 수 있다.

테이블 태그로 초기화하기 때문에 Fallback 에 능하다. 근데 국내 정서에 필요한 확장 다 깔면 좀 느리다.

특히 가상 스크롤에서 조금 느린 성능을 나타낸다.

기술 지원을 받을 수 있다 (영어지만)

composite / 2015년 1월 30일 / 미분류 / 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

웹 개발자 도구의 역사

웹디자인의 역사는 뭐 웹디자인 관련 블로그만 검색해도 질리게 나온다.

하지만 웹 디자인을 발전시키게 해준 초석인 웹 개발자 환경의 역사는 구글링을 해봐도 잘 안나왔다.

이 얼마나 슬픈 일인가 개발자들이여!

그래서 내가 정리해준다.

1. 넷스케이프에도 개발자 도구는 있었다.

이 글 보는사람들 중 넷스케이프에 신경쓴 개발자가 몇 있을지는 나도 모르겠지만, 때는 1998년이다.

솔직히 넷스케이프 시절에 필자는 초딩이였다. 그때는 모뎀 인터넷 시절이었고, 인터넷이 종량제이며, 인터넷을 할려면 전화를 못받는다는 단점 때문에 상당히 제한적이었지만, 그래도 나름 문화컬쳐였다. 

그런 초딩 시절에 넷스케이프 4 에 자바스크립트 디버거가 있었는데, John Bandhauer 가 개발한 자바스크립트 디버거는 그때당시 자바스크립트는 그저 옵션에 불과했지만, 자바스크립트 개발하는데 있어서 생산성을 촉진시킨 하나의 유물인 것은 확실하다.


2. Venkman Javascript Debugger.

Venkman Debugger

이 기술을 넷스케이프가 모질라로 올인하면서 디버깅 기술까지 전수받았는데, 2001년 출시한 모질라 기반 자바스크립트 디버거를 Venkman Javascript Debugger 라 불렀다.

이녀석의 강점은 모질라 기반임에도 불구하고 크로스 플랫폼에서도 디버깅 환경을 제공하고자 하는 노력이었다,

그래서 Ajax 가 뜰 때 당시에 이 역사가 재조명되었지만, 다른 개발자 도구가 워낙에 좋아서 거기서 그치는 비운의 도구였다.

debugger; 키워드를 ECMA 표준으로 등재시킨 툴이였고, 별도의 프로세스로 돌아갔어도 불여우가 역시 개발자를 위한 브라우저구나 하는 무릎 탁 치게 하는 기원이였다고 해도 과언이 아니었다.

자세한 내용은 링크를 참고하라. : https://developer.mozilla.org/ko/docs/Venkman

3. DOM 시각화.

당신의 웹 어플리케이션에 동적으로 컨텐츠를 넣었다가 갑자기 레이아웃이 깨졌다면, 어떻게 모니터링하고 대처했을까?

분명 테이블이 잘 만들어진것 같은데 테이블이 무너져 보인다면, 소스를 다시 보면서 캐치해야 하니..

하지만 기존 웹브라우저는 잡아내는 방법이 너무나 제한적이었다. 소스 보기를 해도 원 소스를 보여주지 동적으로 추가된 곳까지 신경써주지는 않았으니까. 어찌나 불편했을까? 뭐.. 한국은 액티브엑스가 동적 컨텐츠를 제공하는데 아주 잘 활용해서 말이 통할려나 모르겠지만.

이것을 해냈다. 해냈어. 불여우가해냈어!

View Source Chart

DOM Inspector. 우리말로는 DOM 검사기.

DOM 검사기는 DOM 구조를 트리 구조로 시각화해서 눈으로 보여주는 아주 획기적인 도구였다.

이 도구 덕분에 테이블 등에 엉뚱한 태그가 들어가서 테이블 구조가 깨지는 문제를 손쉽게 해결할 수 있었고,

동적으로 컨텐츠가 들어갔어도 바로 볼 수 있었다.

XML에 비해 HTML은 엄격하지 않아서 물론 잘못 코딩해도 보이긴 하지만, 레이아웃 깨졌거나 뭐 엉뚱한 글자가 페이지여 보여서 컴플레인 들어오면 이젠 두렵지 않은 도구가 되었다.

하지만 한국은 이때도 액티브엑스 전성기라서 우리나라 웹 페이지는 저 구조에 크게 신경쓰지 않았거나,

테이블 기반 구조로 저게 필요한 상황을 만들었음에도 깨지기만 하면 정말 고치기 힘든 웹 사이트 구조를 만들어냈다.

그래도 저게 있어서 한국의 지랄같이 테이블 의존성 구조에서 어느정도 벗어날 수 있었지만, 그 은혜를 모른다.

정말 테이블 태그로 만든 레이아웃은 미관엔 좋았지만.. 개발과 유지보수가 어려운 단점은 피할 수 없었다.

그게 왜냐면, 디자이너들이 나모 웹에디터같은 위지윅 개발도구에 의지하고, 개발자조차도 거기에 의지한 탓이다.

그나마 테이블은 미리보기에도 그대로 볼 수 있었기 때문이었고, CSS 표현력이 제한적이라서 div 기반의 레이아웃에서 잘 보여준다는 보장이 없었으니까.

그래서 이때 웹 개발 비용이 부담된건 사실이다. 아무리 편해도 그게 한계가 있다는 것을 여실히 보여준 트랜드였던 것이다.

쪽팔리게 개발자가 나모웹에디터나 쓰고.. 으이구..

이제 Ajax 이후 하드코딩의 시대가 도래했는데, 이 DOM 검사기 도구는 하늘이 내려준 선물임은 확실하다.

4. Web Developer for Firefox.

불여우가 왜 웹 개발자를 위한 브라우저인지 다시한번 마음에 새기는 혁신(?)이 왔는데, 

하나의 작은 툴바에서부터 시작됐다. Chris Pederick 이 만든 Web Devloper toolbar 였는데, 웹 개발자를 위한 편의성 도구들을 제공하여 웹 개발에 도움을 주게 만든 일등공신이었다.

이 툴바의 강점은 Disable CSS와 Disable Javascript 기능인데, 이는 크로스 플랫폼, 크로스 브라우징 보기, 그리고 CSS가 적용되지 않은 경우와, 자바스크립트가 비활성화된 브라우저의 경우, 그리고 시맨틱과 웹 접근성 개발에 도움을 주는 기능들이 한자리에 모여서 웹 개발자들에게는 없어서는 안될 도구로 성장했다.

2003년 첫 릴리즈 이후 계속 버전업 해가면서 기능과 성능 최적화가 되고, 처음엔 미약했지만 끝은 비대한 웹개발자에겐 모르면 간첩인 도구가 됐다.

근데 한국의 경우 웹접근성이 주목받은 때가 2010년이다. 외국에 비해 7~8년 늦은 접근성이다. 비즈니스와 편의성에만 추구한 나머지 웹취약계층과 접근성은 개나 줘버렸었다. 가뜩이나 IE에만 신경썼는데 오죽했을까? 인종차별 인종차별 소리지르면서 정적 한국이 내가 보기엔 존나 차별하는것 같다.

그렇다고.

5. 개발자 도구의 시작, Firebug.

불여우가 왜 괜히 웹 개발자를 위한 브라우저일까? 애초부터 그렇게 시작한 거다.

한국에 IE와 불여우, 크롬 3대장이 웹 시장을 주름잡기 시작했는데, 불여우가 일반인에게 쓰기 어려운 브라우저인 이유가 바로 이런 개발자 환경에 신경쓴 환경이기도 하다.

어쨌든, 개발자 도구의 표준안을 마련한 도구, Firebug다.

Firebug HTML Tree

하지만 Firebug가 처음부터 표준안을 선도한 것은 아니었다. 버전 0.2 에서는 자바스크립트 콘솔과 CSS 구조, 선택한 DOM의 속성을 제공한 게 전부였다.

0.3 에서는 DOM 기능에 충실하게 출시해서 DOM 이벤트와 속성, 해당 적용된 DOM의 CSS 속성들도 볼 수 있게 됐다.

그리고 혁신을 이루어낸 것은 버전 0.4 부터인데,

0.3을 기점으로 자체 DOM 검사기를 포함하는 것으로 시작해서, 자바스크립트에 표준 바람을 불게 만든 console 객체를 출시했다. 비록 Firebug 밖에 되지 않았지만, 혁신을 이루게 한 건 사실이다. 귀찮게 로그성 데이터를 DOM에 뿌릴 필요 없었고, 정보도 바로바로 볼 수 있었던 덕에 많은 웹 개발자에게 Firebug는 이제 없어선 안될 도구가 되고, console 객체 또한 조금 늦지만 ECMA 표준에 등재된 쾌거를 이루었다.

그리고 이 주목받은 기능을 등에 업고 1.0을 출시했을 때는 상용 도구로 개발될 예정이었으나, 불여우에 왠 뜬금없는 상용 툴? 뚝.

아 미안. 그냥 공짜임. 콜! 오픈소스다. BSD로. 아주 좋소!

어쨌든, 지금의 Firebug 화면과 유사하게 나온다. 콘솔과 DOM 검사기, CSS와 스크립트 디버거, 그리고 DOM 객체 구조와 네트워크 타이밍까지. 웹 개발에 있어서 제공하는 모든 것들을 제공했다.

현재는 쿠키와 프로파일러, 설정 등 다양한 기능들이 커뮤니티를 통해 제공했다.

그리고 웹 사이트 성능 측정 도구인 YSlow. 웹 개발자라면 다 아는 도구다. 야후까지 가세해서 Firebug는 웹 개발자가 모르면 간첩.

그리고 이에 힘입어 Firebug Lite 까지 출시했는데, Firebug를 다른 브라우저에서 돌리고 웹개발에 편의성을 주도록 개발한 녀석이다.

그래서 오페라 브라우저에 신경쓰는 웹 개발자에겐 가뭄에 비같은 도구로 잘 활용했었다. 지금은 오페라도 자체 개발자 도구 제공해서 상관은 없지만.

IE에게는 가뭄에 산성비같은 도구였다. Firebug가 느리기 때문인데, 이는 Firebug 문제가 아니라 JScript 엔진이 병신같아서 그런 거다. 엔진 자체가 느려 터졌다고.

하지만 IE 8부터 자체 개발자 도구가 생겼으니 굳이 고민을 할 필요는 없어보인다.

현재는 불여우에 자체 개발자 도구로 제공하고, Firebug 보다 더 빠른 성능을 제공해 주지만, 아직도 많은 불여우 기반 웹 개발자는 Firebug를 쓰고 있다.

여담으로, Firebug 또한 한국에서 최고의 개발자 도구로 주목받았을 땐 한글화해준 고마운 사람이 있었다, 하지만 그는 누군지 모르고, 게다가 현재는 Firebug 한글화가 진행되지 않고 있다.

그래서 현재 Firebug 는 받으면 영어로 나오며, Firebug 공식 홈페이지에 한글화 번역자는 등재되지 않고 있다.

왜죠?

6. 개발자 도구의 반격, Internet Explorer.

한국인이야 알다시피 IE는 웹 환경의 혁신(?)을 불러일으킨 브라우저다. 하지만 너무 자체적으로 표준으로만 만들었다 보니 다른 브라우저에서 안되고, 액티브엑스 때문에 갈라파고스화를 만들어낸 주범이었다.

물론 이것도 마소가 독점하려고 일부러 그렇게 만든건 맞다. 하지만 IE의 보안성 부재와 불여우의 선전, 그리고 구글까지 웹 브라우저를 만들고 나서려고 하니 마소에게 똥줄타지 않을 수가 없다보니…

IE 7을 출시했다. 사용자 측면에서는 탭 브라우징이 끝이다. 시발. 장난하냐?

그리고 IE 7의 실패를 맛본 마소는 이번엔 IE 8 을 출시했다. 물론 욕나오는 브라우저긴 하다. 버그 작렬과 쳐진 성능. 즉, IE 6에 익숙했던 똥컴에게 IE8은 지랄같은 존재였던 것이다.

하지만 마소가 이제 점점 웹표준 수순을 밟고 가려는 의도가 점점 보이고 있는 웹브라우저였고,

마소도 몇몇 기술을 웹 표준에 등록했는데, 대표적인 기술이 localStorage 다.querySelector 도 있긴 한데 제한적이니…

참고로 Ajax를 만들어게 이룩한건 IE의 ActiveX 였지만, 모질라의 XMLHttpRequest가 채택되고, IE에서는 XMLDOM 액티브엑스의 래퍼(Wrapper)로 쓰였다.

그리고 IE 8에서 F12를 누르면 개발자 도구가 나오는데, 혁신을 이루게 만든 하나의 기능이 있었는데 바로 “프로파일러”다.

자바스크립트 프로파일러는, 수집하는 동안 사용자가 브라우징하는 동안에 이벤트와 속성, 함수 호출 내역을 기록하는 기능인데, 사실 이걸 재대로 쓰는 개발자는 많지 않지만, 동적 UI 편의성 모니터링과 개선에 이만한 기능이 없다.

그리고 자바스크립트 디버거 성능이 장난이 아니었다. 비주얼 스튜디오로 나태한 디버거를 만들어낸 마소 답게, 비주얼 스튜디오 좀 만졌다면 IE 자스 디버거는 이보다 편할 수 없을 것이다. 굳이 안만져봤다 해도 상당히 좋은 기능으로 자리매김하였다.

하지만 IE 개발자 도구의 단점이 이런 장점을 덮어버렸는데,

DOM 검사기를 제공한 건 잘한 일이지만 동적이지 못한 단점이 있다. 즉, DOM 변경에 대응을 하지 않았다는 것이다. 수동으로 새로고침을 해야지 그 결과를 볼 수 있다. 상당히 불편한 기능이다.

그리고 자바스크립트 콘솔을 제공하는데, Firebug 가 다른 콘솔은 객체만 치면 객체의 대략적인 속성이나 constructor 가 뭔지 알 수라도 있는데, IE에서는 그저 [object] 로 나온다. 시발 어쩌라고.

그리고 네트워크 탭이 없었다. 물론 Fiddler 가 그 역할을 대신해주긴 했지만, Ajax나 동적 스크립트, 그리고 누락된 리소스 알아내는데 Fiddler 켜야 하니 불편하지 않을 수 없었다.

그리하여 IE 9에는 네트워크 탭이 생겼는데, 이녀석인 프로파일러처럼 개발자가 키면 수집하고 안키면 수집 안하는 식이다.

이는 어찌보면 편하기도 하고 불편하기도 한데, 내가 쓴 바로는 그닥 불편하지 않고, 필요한 경우에만 켰다가 필요없는 경우에 끄는 기능도 괜찮다고 생각한다. 키고 끄는게 가능하지만 조금 불편한 감이 있는 Firebug와, 아예 수집만 주구장촹 하는 웹키트 기반에 비해서 IE는 IE만의 특징이 있다고 보면 된다.

IE 10까지 별다른 진척 없다가 IE 11에서 개발자 도구가 플랫 UI를 안고 탈바꿈 하였는데, IE 11의 DOM 검사기는 이제 수동으로 새로고침 안해도 변경되면 반영하게 됐다. 그 외 나머진 별 다를거 없고.

그리고 UI 응답성 테스트가 생겼는데. 그냥 YSlow 비슷하다 보면 된다. 일종의 프로파일러다. UI가 렌더링된 시간을 기록하여 시각적 결과를 제공해준다. 이건 잘만든 기능이다.

이렇게 IE의 개발자 도구도 강력해지긴 했는데, 아직도 고질적인 문제는 IE는 각 버전마다 렌더링이.. 시발.. 아주그냥.. 시발..

7. Webkit, 개발자 도구로 대동단결.

맥으로 웹개발하는 사람이라면 알겠지만, 사파리나 크롬이나 개발자 도구는 똑같이 생겼다. 그 이유인 즉슨, 둘 다 사용하는 엔진인 웹키트가 개발자 도구를 대동단결했으니까. (웹키트 엔진에 번들로 제공한다고.)

웹키트의 개발자 도구는 조금 늦은 감이 있다. 웹키트 자체 DOM 검사기가 2006년에 소개됐으니까.

하지만 초기에 기능이 워낙 강력해서 Firebug 보다 나았던 시절도 있었다는 것.

왜냐면 이녀석은 시각적 효과가 화려하게 제공되고, 자바스크립트 콘솔이 강력했다. 자동완성을 먼저 지원했기 때문이다.

사실 IE 8과 비슷한 시기에 웹키트 기반 개발자 도구가 대중에 공개됐는데, Firebug 에 비해 이녀석은 아예 그냥 모든 사이트라면 F12 만 누르면 죄다 수집하고 분석하고 기록한다.

어찌보면 편하기도 하지만, 프레임으로 지속적으로 불러오는 웹 사이트 구조라면 계속 수집해서 목록이 늘어날수록 성능이 떨어지는 단점이 있다. 이는 어쩔 수 없다.

그래서 조금은 불편한 감이 있기도 하다. 왜냐면 Firebug 와는 달리 특정 기능만 키고 끌 수가 없으니까.

그래도 나름 웹키트 다운 면모가 있다.

그리고 사파리와 크롬은 결국 개발자 도구도 다른 길로 걷게 되는데, 사파리는 웹키트의 주를 이루니 웹키트 흘러가는대로 가지만, 크롬은 웹키트 변형 엔진인 블링크를 만들어 쓰기 시작해서 지금도 비슷하게 생겼지만 점점 달라지고 있다는거.

8. 마치며.

사실 각 플랫폼별로 나열했기 때문에 누가 먼저 하고 그다음 누가 했는지 햇갈릴 것이다. 그건 필자도 인정한다.

한가지 분명한 사실은, 넷스케이프에서 가장 먼저 개발자 도구를 만들기 시작했고, 그 전신을 이어받은 모질라가 먼저 개발자 도구를 만들고 선도한 것은 틀림없는 사실이다.

불여우가 웹 개발자를 위한 브라우저라고 누차 강조한 이유가 그 역사를 달고 태어났기 때문이라고 나는 자신있게 말한다.

어쨌든, 이렇게 개발자 도구가 서로 경쟁하고 선도하고 발전하면서, 웹 개발이 이렇게 발전할 수 있었던게 아닐까 싶다.

웹 디자인도, 웹 개발에 초석이 되지 않았다면, 가뜩이나 웹 디자인에 가장 많은 의존을 하는 CSS 개발도 어려웠을 것이다.

생산성도 향상되고 디자인도 여러가지로 화려해졌지만, 그렇다고 단가가 낮아진 건 아니다.

클라이언트가 요구하는 건 점점 더 다양해지고, 이를 수용할 수 있는 웹 디자이너와 개발자는 그만한 가치가 있기 때문이다.

이렇듯 웹 개발자 도구는, 절대 무시해선 안될 도구다. 특히 웹 개발자는 더. 액티브엑스? 몰라. 그딴거.

개발자 도구. 고맙게 쓰자.

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