이 글을 포스팅하려는데 3.0.4 업데이트가 나왔군요. ^^

firebug의 업데이트와 함께 새로운 UI의 옵션이 맨 처음에 나옵니다.
콘솔(Console), 스크립트(Script), Net 기능을 체크해야 자바스크립트와 네트워크 관련 기능을 사용할 수 있습니다.

이 중에서 콘솔은 자바스크립트 에러가 표시되는 화면입니다. 다음과 같이 표시됩니다.

여기서 에러메시지를 클릭하면 해당 소스의 자바스크립트로 이동하게 됩니다.

콘솔에는 다른 기능도 있습니다. 바로 현재 페이지의 자바스크립트를 편집해서 실행할 수 있는 영역이 있다는 것입니다. 콘솔 탭의 하단에 >>> 프롬프트 라인입니다. 여기에 자바스크립트를 넣어서 실행할 수 있습니다. 예전부터 있었는데, 안 썼습니다. 몰랐으니까요. ^^;

이렇게 실행 결과도 확인할 수 있습니다.

편집 영역을 확장할 수도 있습니다. 라인 우측의 회색 동그라미를 클릭하면 다음과 같이 넓어집니다.

Ajax 작업을 할 때 작은 프로그램도 여기에 넣어서 실행이 가능합니다. ^^;

 
해킹에 조심하셔야겠어요. 툴은 중성이죠. 사용하는 사람에 따라 선이 될 수도 악이 될 수도 있으니까요. 중요한 로직 체크는 자바스크립트로 하는 것을 피해야죠. 서버 쪽의 프로그램에서 체크하는 것은 웹개발의 기본이겠죠.

춤추러 갑니다. ^^ 스윙댄스요. ㅎㅎ


즐겨쓰는 브라우저는 오페라입니다.
어제는 일찍 자고 지금 일어나서 서핑을 하다가 즐겨사용하는 사이트인 me2day에 들어갔습니다.
뭔가 어색해서, ie6불러봤죠.(이놈은 MS가 오늘 대대적으로 업데이트 한다던데, 조용하군요.)
역시나 변한 게 있는 듯 하군요. 글과 글 사이의 CSS가 ie와 opera사이에 차이가 생긴 듯 합니다.
사용자 삽입 이미지
사용자 삽입 이미지


3자 대면시켜 봅니다. 파폭 나와요.
사용자 삽입 이미지


역시나 따로 노는 오페라인 듯 합니다. 얘가 좀 예민합니다.
불여우랑 친한 개똥벌레(http://www.getfirebug.com/)를 불러다가 진상조사를 시켰습니다.
사용자 삽입 이미지

빨간색으로 표기된 부분이 1.5em 으로 마진을 잡았는데, 오페라에서 다르게 해석한 것 같습니다.

여하튼 어색해요. 어색해요.
꽤 오랜 동안 제 웹 생활의 중심은 오페라가 되어 왔습니다. 지난 번 올블로그 3주년 행사에서 만난 하늘이님 블로그에 올린 글을 보고 9.2부터 사용하기 시작했습니다. 기능이나 이미지 렌더링이나 irc 채팅지원, RSS 뉴스리더 등의 특징을 잘 활용하고 있습니다.

하지만, 자바스크립트 해석이 달라서 오작동하거나 아예 동작을 하지 않거나, 혹은 원어데이 같은 사이트는 CPU 100%으로 가게 만들더군요.

다음 사이트의 경우입니다. daum 블로그는 읽기가 상당히 난해합니다. 스크린 캡쳐를 잡으면 이렇습니다. 글 우측에 보이는 스크롤바와 그 스크롤바가 가리는 글씨들... 음...
사용자 삽입 이미지

ie, ff에서는 잘 보입니다. 이케요. 브라우저 우측의 스크롤바 보이시죠.
사용자 삽입 이미지
contents from: http://blog.daum.net/miriya

그리고 최근 베타 오픈한 다음 검색쇼를 오페라에서 시도하다가 OTL 했습니다. 1단계에서 2단계로 잘 넘어갑니다. 하지만, 2단계 페이지에 있는 3단계 버튼을 아무리 클릭해도 꼼짝하지 않습니다.
사용자 삽입 이미지

저 다음 단계 버튼을 아무리 클릭해도 꿈쩍을 하지 않는다는 것이죠. 개똥벌래(firebug) 출동시켜서 코드를 비교해봤습니다. href="javascript:..." 와 같은 식으로 코딩을 하면 오페라에서 동작되지 않는 것을 알게 되었습니다. onclick 으로 수정하면 될 듯 합니다.
이 코드는 1단계에서 2단계로 넘어가는데 사용된 코드입니다. onclick 을 사용했습니다.
사용자 삽입 이미지

아래는 문제의 코드입니다.
사용자 삽입 이미지
href="javascript:..." 보이시죠.

브라우저가 많아지는데, 일일이 대응하기 힘들다는 것은 웹프로그래머인 저도 잘 알고 있습니다. 하지만 명품이냐 아니냐는 그 디테일이 어떠하냐로 구분되어집니다. 브라우저를 만드는 벤더나 오픈소스 그룹은 표준을 지키기 위해서 고군분투중입니다. 점차로 브라우저 특화된 함수보다는 웹표준에 입각한 빠른 성능의 브라우저를 만들고 있기 때문에 함수 사용만 웹표준에서 지정하는 방식으로 코딩을 하면 모든 브라우저에서 동작하는 잇점을 취할 수 있을 것입니다.

여튼 마이너 그룹에 속해서 투정 한 번 부려봅니다.
firebug CSS Layout
firebug css layout tab

firebug css layout tab


간만에 올리는 firebug 관련 글입니다. 우측의 Style , Layout , DOM 에서 Layout 으로 했을 경우 좌측 html 태그 선택에 따라서 상단 view 영역의 색상이 표시가 됩니다. 그리고 pixel 단위의 화면 자(screen ruler)도 보이고, 마진margin은 노란색으로 패딩padding은 보라색으로 표시됩니다.
Layout 에 해당 숫자는 변경할 수 있고, 라이브로 위에 변경내용이 보입니다. 물론 서버에서 돌아가는 코드는 여기서 얻어진 수치를 바탕으로 직접 수정해야겠죠. ^^;

조사하면 다 나와 버튼 아시죠. 개똥벌레(firebug) 이미지 옆에 Inspect , 이거 클릭하고 상단에 마우스를 움직일 때마다 해당영역의 코드와 Layout을 볼 수 있습니다.

간만에 UI 작업하면서 짧게 포스팅합니다. 
브라우저 하단에 위치한 debug 패널을 창으로 띄워서 사용할 수 있습니다.
control + F12(Mac은 command + F12) 단축키를 이용하면 바로 새로운 창으로 띄울 수 있습니다.
모니터를 두 개 사용하는 경우 좋은 효과를 볼 수 있습니다. ^^;(하나 지르고 싶다.)

하단에서 창으로 띄우는 방법은 검색칸 옆의 꺽쇠 아이콘을 클릭해도 됩니다.
open firebug in new window

open firebug in new window


related: http://www.getfirebug.com/using.html



devnight의 여파로 barcamp에서는 간신히 me2질만 했습니다. ^^; 간신히 찍은 오프닝 동영상입니다.

http://me2day.net/promo/barcamp

첨부한 파일은 Firebug에 관한 제 발표자료입니다. 새로고침 횟수를 획기적으로 줄일 수 있는 벌레잡이 농약 플러그인입니다. firefox에서만 동작을 하는 아쉬움이 있지만, 다른 브라우저들도 이것을 모델로 좋은 디버깅 툴이 나오리라 기대해봅니다.

barcamp는 barcamp대로 devnight은 devnight대로 멋있는 분들을 만날 수 있어서 좋았습니다.

모두 행복하시고, 열심히 사시고, 다음 공유의 자리에서 또 뵙기를 바랍니다.
모토는 정말 아름다웠습니다. 정진호님이 찍은 사진 하나 가져옵니다.


웹개발을 하면서 데이터의 전달은 중요한 디버깅 요소입니다.
어떤 데이터들이 전달이 되었는지 firebug에서도 확인할 수 있습니다.

firebug 에서 parameter확인

firebug 에서 parameter확인


버그를 기준으로 하단 회색줄의 Net 탭을 클릭합니다. 상단의 메뉴들이 변하는데, 요약하면 다음과 같습니다.
All: 모두 나옵니다.
HTML: 이미지, CSS, JS 다 빼고 html 만 목록에 보입니다.
CSS: CSS 파일목록만 보입니다.
JS: JavaScript 파일들만 보입니다.
XHR: XmlHttpRequest 의 줄임인데, Ajax의 중심이죠. Ajax호출정보만 따로 모았습니다.
Images: 이미지 목록만 나타납니다. 아래 목록에서 썸네일을 볼 수 있죠.
Flash: 현대 웹에서 중요한 자리를 꿰찬 swf 목록이 주르륵.

목록을 클릭하면 탭이 또 보입니다. 이노무 탭 세상. 다 탭이래요. 탭댄스라도.. 또깍따그닥.
파라미터가 있는 주소면 Params 탭이 보입니다. Post방식일 때는 post라고 나옵니다.
아래 정리된 파라미터 이름과 그 옆에 값들이 보일 겁니다.

멋진 살충제입니다.
아, 살충제를 개발한 Joe Hewitt님이 Yahoo UI 팀에 fulltime firebug개발자로 이직하신다고 하네요.
n모사의 nzeo님 생각나네요. ㅎㅎ 그런 직장에 들어가기 전에는 side-job으로 firebug를 개발하셨는데, 아주 잘 되었네요. 돈 받으면서 자기가 키운 프로그램을 계속 키운다는 행복한 개발자의 이야기였습니다.
디버그(debug)는 쉽지 않은 작업입니다. 벌레 잡는 일이 프로그램에서 가장 정성이 많이 들어가는 작업이기도 합니다.
  1. 디버그의 기본
  2. 자바스크립트 디버그
  3. Java debugging
  4. JSP debugging
이 네 가지에 대해서 글을 써보려고 합니다.
디버그의 기원은 초기 계전기 사이에 있는 죽어있는 나방이 컴퓨터의 오작동을 일으켰고, 그 나방을 제거하자 정상 작동한 것에서 유래를 찾고 있습니다. 말 그대로 de+bug 입니다. ㅎㅎ

프로그래밍을 할 때 정상적인 데이터가 들어왔을 때를 기준으로 설계를 합니다. 하지만 프로그램을 실행할 때 발생하는 예상하지 못했던 경우로 인해 버그가 발생합니다. 숫자입력을 기대했는데, 문자가 들어오는 경우나 자료실을 운영하는데 서버의 하드디스크가 꽉 차는 경우를 예로 들 수 있습니다.

전자의 경우는 프로그램 수정을 통해서 디버그 하기 용이합니다. 후자의 경우는 하드디스크 공간 확장 내지는 불필요한 파일 삭제 등의 조치가 필요한데, 제가 설명하려는 영역에서 제외합니다.

프로그램을 디버깅하기 위해서는 버그를 발생시키는 코드와 그 때 사용된 테스트 값이 필요합니다. 버그를 재현할 수 있다면 프로그램의 약점을 파악한 것입니다. 따라서 디버깅이 쉽게 됩니다. 가장 어려운 경우는 간헐적으로 발생하는 버그입니다. 어떤 이유로 발생하는지 파악하기 어렵기 때문에 디버깅이 아주 어렵습니다. 범인 집 앞에 잠복해 있는 형사의 심정이라고 할까요.
디버깅을 의학에 비유한다면 내시경과 같습니다. 전신마취하지 않고 내시경 받아보셨나요. 아주 죽습니다. 디버깅도 프로그램을 한줄씩 살펴보는 작업이 동반되는데, 아주 고된 작업이 되기 쉽습니다.


debugging에서 알아야 할 용어들을 먼저 소개합니다.
  • breakpoint : 중단지점입니다. 실행 모드가 아닌 디버그 모드에서 프로그램을 중지하게 되는 지점의 표시입니다.
    보통 ide에서 소스 라인 맨 앞 여백을 더블클릭하면 생깁니다. 다시 더블클릭하면 없어집니다. resume을 실행하면 다음 중단점을 만날 때까지 실행됩니다.
  • step over : 한줄을 실행합니다. 함수가 있어도 실행 후 다음으로 넘어갑니다.
  • step into : 함수 내부로 들어갑니다.
  • step out : 함수를 끝까지 실행시키고 호출시킨 곳으로 되돌아 갑니다.
  • resume : 디버그로 한 줄 한 줄 실행시키는 트레이스 모드를 그만두고 실행모드로 전환합니다.

일단 기본적인 용어는 이상과 같습니다. 디버거의 종류에 따라 확장된 기능들이 있지만 기능이 소개될 때 같이 언급하겠습니다.
다음은 자바스크립트 디버깅을 설명하기 위한 소스입니다.

소스 : debug1.html (UTF-8)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>javascript debug</title>
<script type="text/javascript">
    // 전역변수 count
    var count = 0;
    /**
     * count값을 #place div에 출력하는 함수
     */
    function doPrint() {
        var place = document.getElementById("place");
        count++;
        place.innerHTML = count;
    }
</script>

</head>
<body>
<input type="button" value="trigger" onclick="doPrint()">
<div id="place"></div>
</body>
</html>

간단히 자바스크립트를 테스트할 수 있는 html과 javascript 코드입니다. input버튼을 클릭하면 doPrint() 자바스크립트 함수를 호출합니다.
디버깅을 위해서는 디버깅 도구가 필요합니다. firefox의 플러그인 firebug를 사용해보겠습니다.

소스1 debug1.html 파일을 만들고 firefox로 엽니다. 우측 하단의 firebug플러그인 활성화 영역을 클릭하여 그림1과 같이 firebug영역을 활성화합니다. 여러 개의 탭 중에서 Script 탭을 열면 HTML 소스와 함께 Script 소스들이 보입니다.

그림1 firebug script tab그림1 firebug script tab


디버깅은 쉽습니다. 그림2와 같이 JavaScript 함수의 내부인 14라인에서 앞쪽의 회색부분을 클릭하면 브레이크 포인트가 걸립니다. 디버그 준비 끝입니다.

그림2 JavaScript Debug Breakpoint그림2 JavaScript Debug Breakpoint

 
브라우저에서 버튼을 클릭하면 이 함수가 호출되는 소스인데 한 번 눌러보시면 화면에 브라우저 내의 객체들과 변수들이 그림3과 같이 firebug의 우측 패널에 나타납니다. 아울러 브레이크 포인트가 찍힌 곳에 화살표가 나타나면서 JavaScript의 실행이 중단 됩니다.

그림3 Debug start그림3 Debug start


id가 place인 element의 속성들을 확인할 수 있습니다. 여기서 디버깅을 계속하기 위해서 다음 아이콘들을 사용할 수 있습니다.

그림4 debug icons그림4 debug icons


하늘색 아이콘은 continue (F8) 입니다. resume 이라고 앞 서 설명드린 기능인데 다음 브레이크포인트를 만날 때까지 실행하게 됩니다. 만약 다음 브레이크포인트가 없다면 "기냥 고"가 되겠죠. ^^; 그 옆 아래로 향하는 아이콘은 Step Over (F10) 입니다. 한 줄 실행하고 대기하게 됩니다. 그 옆의 오른쪽으로 향하는 아이콘은 Step Into (F11), 라인에서 함수를 만나면 그 함수 안으로 비집고 들어가는 기능입니다. 그렇다면 나머지 한 개의 아이콘은 말 안해도 되죠? ㅎㅎ. 기냥 고?
삐질까봐 말씀드립니다. Step Out (F12) 인데 비집고 들어갔던 함수에 볼 게 없다면 나와야죠. 함수에서 밖으로 빠져나오게 됩니다.
흠... Step Over 를 실행해보죠. F10 키를 눌러도 됩니다. count 변수는 어디 숨었을까요? 함수 바깥에 있는 전역변수이기 때문에 this 안에 있습니다. 그림5를 참고하세요.

그림5 debug step over그림5 debug step over


to be continued...


+ Recent posts