웹 개발자 도구의 역사

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

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

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

그래서 내가 정리해준다.

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

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

클라이언트가 Adblock 썼는지 어떻게 아냐? Adblock 감지법.

외국에서도 구글 애드센스 등의 광고 프로그램을 이용해서 블로그나 커뮤니티, 서비스를 하면서 광고를 뿌리고 있는데

이 불여우와 크롬에서 유명한 AdBlock 때문에 고충이 만만치 않다고 한다.

우리나라도 마찬가지.

그래서 여러가지 방법을 쓰고 있는데, 그렇다고 해서 한국처럼 “애드블록 무력화 시키면서까지 광고 띄우는” 짓은 하지 않아서 서비스 공급자가 알아서 해결하기도 한다.

가장 크게 작용하는 사이트가 바로 와레즈같은 좀 불법적인 사이트들이 많은데, 이들은 애드블록 키면 스크립트로 감지해서 다운받지 못하게 하고, 그렇다고 스크립트 끄면 역시 다운시켜주지 않는 수단까지 동원하고 있다.

그 애드블록을 감지하는 스크립트가 있나? 있다.

광고 서비스는 구글 애드센스 기준, 사용하고 있는 스크립트 프레임워크는 jQuery 기준으로 정말 간단하고 명료하다.

if ($('.myTestAd').height() == 0) {
        alert('광고 막지마 시새발끼야 나도 먹고살자.');
}

애드센스 외에도 다른 광고 서비스에서도 적용할 수 있다. 왜냐면 해당 광고에 컨텐츠가 막혀서 높이값이 0이 되기 때문이다.

AdBlock의 원리는 간단하다. 필터링 대상의 사이트 또는 엘리먼트를 찾아 컨텐츠 표시를 무력화한다. 컨텐츠가 없으니 컨텐츠 공급자가 높이값에 잘 조치를 하지 않기 때문에 대체적으로 높이값은 0이 된다. 이를 이용하여 감지하는 방법 되시겠다.


근데.. 사실 한국은 그닥 쓸데없는 팁 되시겠다. 아.. 그러고보니 구글 애드센스같은 외국 광고 서비스를 제공받는다면 해당되겠으나 대부분 국내 광고 서비스를 받고 있으며, 애드블록을 회피하는 방법을 불쌍한 개발자들이 구현했기 때문에 걱정없을 것이다.


그러나 사실 불쌍한 개발자들은 아니다. 구글링 잘하는 개발자는 이미 애드블록을 무력화시켜 광고를 표시했기 때문에 당신의 블로그나 사이트에 광고 표시는 걱정일랑 안해도 될 것이다.

이미 회피하는 방법이 나와 있기 때문이다. 간단하게 소개하겠다.

  1. 광고 요소에 ad나 click이라는 단어 있으면 무조건 빼라.
  2. 광고 사이즈를 교묘히 바꿔라. (애드블록은 사이즈 필터도 있기 때문에 그걸 교묘히 바꾸면 된다. (예. 468×60 대신 470×58 등)
  3. 왠만하면 광고 제공을 로컬에서 해라. 그리고 광범위하게 (ad나 banner 키워드 쓰다 걸려서 짤리지 말고)

우리나라에는 이런 팁 안날려서 내가 날렸다. 이렇게 대놓고. 날 원망하지 마라 컨텐츠 수급자들이여..

어떤 이는 여러분에게 몰랐던 정보를 제공하기 위해 돈들여서까지 해주는데, 그 수익은 추천도 있지만 광고도 있는데,

추천도 안하고 광고도 안봐주면 공급자가 정보 제공할 맛 나겠나? 어자피 돈들이는것도 아니니까 정보가 유용하다면 추천해주고 광고도 봐주자. 광고 클릭 안해도 되고 보기만 해도 되고, 광고 막았다고 해서 아쉽다 하지말고 추천이라도 해주자.


근데 나는 광고도 없고 추천버튼도 없어. 훈스닷넷이라도 추천버튼이 있지만 추천해주는 이도 없으니 나는 아마 안될거야.


참고자료

How to block Adblock – http://thepcspy.com/read/how_to_block_adblock/

Publishers: How To Bypass Ad Blocking Software – http://www.dotsauce.com/2008/02/27/how-to-bypass-ad-block-software/



composite / 2013년 6월 17일 / 미분류 / 1 Comment

app.js 망했습니다. node-webkit 로 갈아타시길.

0.0.20 에서 개발이 진척이 안되고 있습니다.


issue 에서는 원성이 자자합니다. 버그와 호환성, 그리고 node 상위 버전 호환성 등…


개발자는 지금 개발중이긴 한데.. 커뮤니티는 빠져나가고 있고, node-webkit 로 갈아타는 개발자가 늘고 있습니다.


app.js 추천해준 제가 후회됩니다.


저도 이제 곧 node-webkit 로 갈아탑니다. 짱깨 만세!


app.js 와 달리 node-webkit 는 사운드와 3D, 하드웨어 가속이 지원됩니다. CEF 버전도 앞서가고 있고요.


 


app.js 추천해서 죄송합니다. 다움부터는 node-webkit 쓰세요. https://github.com/rogerwang/node-webkit


 


참고로 이사람은 Intel 사의 오픈소스 센터에서 일하고 있는 사람입니다. 예 맞아요. CPU 만드는 인텔사.

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