live.com은 MS에서 강력하게 밀고있는 웹 플랫폼인데요, 아직은 기나긴 베타기간인데다가 한국어 홈페이지는 아직 대부분의 서비스가 제공되지 않고 있네요.

live.com테스트할 때 기본 언어를 영문으로 해놔서 몰랐는데 최초로 개짓을 붙이는 것도 찾기 어렵게 되어있더군요; 기본으로 하나 붙여줬으면 좋으련만.

어떤 분께서 live.com에 개짓을 추가하는 방법을 물어보셔서 최초 로그인 과정부터 찍은 동영상을 올려두니 한번 따라해보시기 바랍니다.
크기가 좀 커서 숨겨둡니다.

live.com에 개짓 추가하기


에고 크기가 잘리네요. 원본 사이즈가 800x600이라서요.
http://gongdo.tistory.com/attachment/cfile27.uf@270648415878F548188F4A.avi 이걸 다운 받아서 보시길.

간단하게 순서를 정리하자면,
1. live.com에서 사용할 passport 계정 준비(MSN 메신저용 ID가 있으면 됩니다).
2. live.com의 우측 상단의 '로그인'을 클릭하고 해당 계정으로 로그인
-> 여기서 무한반복 한다고 하는 분이 계시는데 이 부분은 저도 왜 그런지 모르겠네요.
만약 잘 안된다면 messenger.msn.co.kr에 가셔서 다시 한번 로그인 해보세요.
3. 기본적으로 한국어 페이지에서는 기능이 별로 없으니 옵션에서 언어를 English(United States)로 설정하세요.
4. 그리고 왼쪽 제일 위에 동그란 윈도 마크를 클릭해보면 메뉴에 Gallery를 클릭
5. 갤러리 왼쪽의 메뉴에서 Gadgets를 클릭
6. 여기서 아무 개짓이나 고르면 되는데요 제일 찾아가기 쉬운게 왼쪽 Gadgets메뉴에서 IM and spaces를 클릭
7. 여기서 목록이 나오면 All types가 있는데 이걸 Web gadgets로 고르시고 나오는 아무 개짓이나 [Add to Live.com]을 클릭
8. 추가하겠냐고 물어보는 페이지에서 제일 아래에 [Add]
9. 그럼 live.com 초기 페이지에 해당 개짓이 붙어있는걸 확인할 수 있는데요, 다시 Options에서 언어를 한국어로 바꾸세요.
10. 아까 임시로 추가했던 개짓을 X버튼을 클릭해서 삭제하시고
11. 왼쪽 위쪽에 '콘텐츠 추가'를 눌러보시면 이것저것 나오고 제일 아래쪽에 '가젯'이 있어요.
12. 이때 오류가 발생할 수 있는데 새로고침하시면 되구요.
13. 다시 가젯에 가보면 한국어 페이지에는 아직 시계밖에 없어요. 그냥 추가하시면 됩니다.
14. 로그 아웃했다가 다시 로그인 해보시면 해당 개짓이 추가되어있는걸 볼 수 있구요, 계속해서 '콘텐츠 추가'로 뭔가 다른걸 해볼 수 있어요. 역시 언어를 영문으로 해놓는게 live.com의 이런저런 기능들을 시험해볼 수 있겠죠.

도움이 되었으려나 모르겠네요;
신고
Posted by gongdo

연휴를 맞아 개짓 개발에 매진하려고 하는데 참 힘드네요.
우선 개짓 자체가 불완전한데다가 MS 특유의 편리하게 제공되는 API도 적을 뿐더러 그나마도 숨겨놓고 공개안하는 요소도 많군요.

보통 고급 자바스크립트 기능을 쓴다 하면 대부분 prototype.js가 들어가 있어서
개짓 js 파일 내에서 외부의 자바스크립트 파일을 로딩하여 그 기능을 활용하는 테스트를 해봤습니다.

결과는 어떤 방법을 써도 외부 코드가 제대로 로드되지 않더군요.
아래는 개짓 js 파일 내에서 alert(document.documentElement.innerHTML); 코드를 통해 얻어낸 live.com상의 개짓 HTML 코드입니다.

개짓의 HTML 코드▼


눈돌아 갑니다.
엄청나게 많은 js 파일들이 알게 모르게 쓰이고 있군요. 괜히 로딩이 느린게 아니었습니다. -_-

자바 스크립트 코드 내에서 외부 자바 스크립트 코드를 로드하는 방법을 찾아 봤는데, 그냥 DOM 객체를 추가하는 것처럼 document.createElement('script');로 객체를 생성한 후 해당 객체를 원하는 엘리먼트에 appendChild()문을 통해 넣더군요.

그 방법으로 위에서 보이는 HTML 코드의 <HEAD>아래와 <BODY>아래에 넣어봤지만 분명 HTML 코드 상에는 올라가지만 어떤 이유에선지 제대로 로딩이 안되었고 외부 자바스크립트의 객체나 함수를 식별할 수 없었습니다.

또 다른 방법은 개짓 매니페스트 파일의 바인딩 <item><link></link></item>을 활용하는 건데요.
<link biding:type="js">경로.js</link>
이런식으로 넣어주면 분명 HTML코드에 로드는 되지만 역시나 개짓 js 내에서 해당 코드를 인식하지 못합니다.

뭐 이쯤 되면 두손 두발 들어야죠.

최악의 방법으로 외부에 넣을 스크립트 코드를 개짓 js 파일의 맨 아래에 몽땅 붙여넣을 수 있는데요, 이 방법으로 일단 코드가 제대로 동작하긴 합니다.
문제라면 코드 라인이 엄청나게 길어져서 디버깅 하거나 코딩할때 매우 불편해진다는 점이죠.

MS는 아예 정해진 코드 외엔 사용하지 못하게 하는 것도 아니고 본문에 넣으면 죄다 동작할 코드를 왜 외부에서 로드하지 못하게 했을까요?
뭐 외부에 링크하면 그 코드를 수정해서 뭔가 '나쁜짓'을 할 수도 있다... 이해는 가지만 꼭 이렇게 귀찮게 했어야 하는지 의문입니다.

어쨌든 지금으로선 방법이 없군요.
하루 빨리 MS에서 개짓을 VS2005의 개발 프레임웍 안에서 연동하여 쓸 수 있게 해주길 바랄 뿐이죠.

에휴.
신고
Posted by gongdo
감기에 걸려 약먹고 high해져 헤롱거리고 있습니다.
이번에도 결과물을 먼저 보죠.
티스토리 동영상 사이즈 조절이 안 되는군요. 최대 크기 제한이야 이해를 하지만 그보다 작으면 그냥 원래 사이즈로 나오게 해 줄 것이지 원-_-


part 5.에서 캐릭터가 나오고 사라질 때 fade-in/out 효과를 추가했습니다.
이것만으론 의미가 없겠죠?
내부적으로 캐릭터의 생명주기, 페이드 속도, 이동 속도를 외부 URL에 있는 XML로부터 로딩하도록 하였습니다.
즉, 외부 XML을 읽고 필요한 정보를 추출한 것이지요.

이 예제의 소스 코드는 여기.
이 예제의 매니페스트 XML 경로는 http://3m4you.co.kr/gongdo/gadgets/test05/test05.xml 입니다. 테스트 해보세요 :)

개짓에서 XML을 다루는 것은 매우 쉽게 구현되어 있습니다.
AJAX에 어느정도 익숙하신 분이야 HTTPRequest를 통하여 외부 URL의 리소스를 비동기로 가져오는 방식에 익숙하실 텐데요.

자바스크립트의 비동기 호출은 치명적인 약점을 가지고 있습니다.
바로, 자신을 로드한 도메인이 아니면 억세스를 할 수 없다는 것입니다.

이 문제를 해결하기 위해 웹서버 측에 프록시를 만들어 외부 리소스에 접근하는 방법을 사용하거나 아파치의 경우엔 컨피그에 접근을 허용하는 목록을 작성할 수 있는 걸로 알고 있는데요, 어느쪽이든 단순 웹 호스팅을 받고 있는 웹서버라면 접근이 불가능합니다.

사실 문제라기 보단 자바 스크립트의 엄격한 클라이언트 보안 대책이라고 해야 맞겠지요. 그래도 개발자에겐 불편하기 짝이 없는 장애물인데다가 프록시를 쓸 경우 서버의 부하도 늘어나고 반응 속도도 한참 떨어지게 됩니다.

라이브 개짓에서는 크로스 도메인 억세스가 가능한 비동기 요청 메소드를 제공하고 있습니다. 물론 이것도 내부적으로 프록시를 사용할테니 속도가 떨어진다는 점은 여전하지만 꽤 수고를 덜 수 있습니다.

개짓의 외부 리소스 요청은 Web.Network.createRequest() 메소드를 통해 이루어집니다.
자세한 사항은 레퍼런스를 참고하시면 되겠고, 여기서는 간단한 소개 정도만 하겠습니다.

createRequest는 자주 사용되는 리소스 형태에 대한 사전 정의를 세번째 파라미터를 통해 전달 할 수 있는데요, 개짓 API 가이드에서 볼 수 있는 사전 정의는 다음과 같은 종류가 있습니다.

  • RSS Proxy - {proxy:"rss", numItems:#}
    Start.Util.ParseRssResponse()라는 유틸리티 메소드를 통해 수신 받은 리소스를 RSS 피드로 파싱합니다.
    해당 메소드가 반환하는 객체는 rss.channel[index].item[num].title 과 같은 방식으로 편리하게 RSS 피드를 사용할 수 있습니다.
  • XML Generic Proxy - {proxy:"generic"}
    response.responseXML.documentElement라는 프로퍼티를 통해 수신 받은 리소스를 XML DOM으로 파싱된 document 엘리먼트를 얻을 수 있습니다.
    여느 XML DOM과 같은 방법으로 엘리먼트와 어트리뷰트에 접근할 수 있습니다.
  • Bypassing Proxy - {proxy:"none"}
    서드 파티에서는 사용할 필요가 없는 방법으로 프록시를 거치지 않고 직접 해당 리소스에 접근합니다. 하지만 위에서 밝혔듯이 자바스크립트는 자신을 로드한 도메인이 아니면 다른 도메인에 접근할 수 없으므로 의미가 없습니다.
    아마 MS 내부에서 사용하려고 만들었겠지요.
  • null - null
    수신 받은 리소스를 별도로 파싱하지 않고 그대로 반환합니다. 이것은 요청의 내용에 따라 수신 데이터가 달라지므로 모든 것은 콜백 함수에서 처리됩니다.
어쨌든 HTTPRequest보다 20배쯤 편합니다. 게다가 프록시도 제공되는 걸 감안하면 200배쯤 편하죠!

이 비동기 통신을 통해 얻은 리소스로 뭘 할 것인가는 전적으로 개발자에게 달렸습니다. :)
우선 RSS 프록시를 통해 파싱한 RSS 객체로는 손쉽게 웹상의 RSS 피드를 요리할 수 있겠고 null 프록시를 통해서 jpg와 같은 이미지 파일을 로딩할 수도 있을테고 웹 서비스를 받을 수도 있습니다.

이 예제에서 사용한 것 처럼 일반적인 XML 포맷이라면 generic 프록시를 사용하면 되는 데요, 이 부분을 좀 더 살펴보죠.

예제에서 사용된 config.xml 파일은 다음과 같이 정의 되어 있습니다.
<?xml version="1.0" encoding="utf-8"?>
<config MaxTimeouts="10">
  <GhostSpeed>3</GhostSpeed>
  <FadeSpeed>10</FadeSpeed>
</config>
root 엘리먼트인 <config>가 있고 그 하위에 <GhostSpeed>와 <FadeSpeed>엘리먼트가 있습니다.
response.responseXML.documentElement프로퍼티로 전달 받은 객체는 곧 root 엘리먼트에 대한 Node 객체가 됩니다.
var root = response.responseXML.documentElement;
위와 같은 코드로 root 엘리먼트를 받을 수 있습니다.
config.xml의 루트 엘리먼트는 <config>엘리먼트이고 이 엘리먼트 안에 있는 MaxTimeouts 어트리뷰트의 값은 root.getAttribute("MaxTimeouts");와 같은 코드로 얻을 수 있습니다.

<config> 엘리먼트의 하위 엘리먼트인 <GhostSpeed>와 <FadeSpeed>엘리먼트는 root.childNodes[#] 프로퍼티로 얻을 수 있는데요 여기서 주의할 점은 <GhostSpeed> 엘리먼트 태그 사이에 있는 3이란 값은 <GhostSpeed> 엘리먼트의 값이 아니라 하위 엘리먼트의 값이라는 점입니다. 즉, 3이란 값도 지정된 이름이 없는 하나의 엘리먼트로 취급된다는 것이죠.

따라서 3이란 값을 얻기 위해선 root.childNodes[0].nodeValue가 아니라 root.childNodes[0].childNodes[0].nodeValue처럼 한 단계 더 내려가야 합니다.

XML DOM에 익숙하신 분이라면 이 같은 실수는 안하시겠지만 XML DOM을 제대로 모르는 저는 또 몇 시간 헤맸답니다. 좀 허탈했죠. =_=


총 6회에 걸쳐 개짓 개발 시작을 해서 겪은 과정을 포스팅 했습니다.
정리해보자면,
- 개짓 개발 준비
- 기본 구성 요소 작성
- HTML DOM을 동적으로 추가
- JavaScript로 이벤트 처리
- 동적인 화면를 위한 타이머 처리
- 외부 리소스를 로딩하는 방법
입니다.


이젠 구상하고 있던 것을 어느 정도 구현할 수 있을 것 같습니다.
과연 컨테스트 마감일까지 만들 수 있을지는 의문이지만 비록 컨테스트 참여를 못하더라도 의미 있는 코드를 만들어보고 싶네요.

한 가지 덧붙이고 싶은건 진행하는 내내 디버깅이 엄청나게 불편하고 문제가 생기면 정확히 어느 시점에서 생겼는지 확인하기가 정말 힘들었습니다.
제대로 개발을 하려면 디버깅을 위한 트레이스 툴 정도는 만들어놓고 시작해야 할 것 같네요.


▒차회 예고목표▒
- 좀 더 객체 지향적인 코드를 위해 사용자 정의 클래스를 작성하여 데이터와 명령을 관리합니다.
- 원활한 디버깅을 위해 트레이스 툴을 하나 만들어봅니다.
신고
Posted by gongdo

음, 사실 이 글을 보실 분들은 제가 특별히 소스 설명할 필요가 없을 텐데 쓸데없는 짓하고 있는 듯한 기분이 들지만, 포스팅을 늘리기 위해서라도 계속 합니다. :)

구동 동영상 및 전반적인 설명은 part 1.을 참고하시고,
소스 코드 다운 로드와 코드의 초기화 및 해제 설명은 part 2.를 참고하세요.

part 3.에서는 핵심 처리인 마우스 이벤트와 타이머의 핸들러를 살펴보도록 하겠습니다.

/*--------------------------------------
|   MouseMoveBG
|   백그라운드에서 마우스가 움직일 때 이벤트
---------------------------------------*/
function MouseMoveBG()
{
    var nPosX = 0, nPosY = 0;
    nPosX = event.x;
    nPosY = event.y;

       m_nPrevPosX = m_nPosX;
       m_nPrevPosY = m_nPosY;
    m_nPosX = nPosX;
    m_nPosY = nPosY;
    //m_divBG.innerHTML = "Cur X : " + nPosX + ", Cur Y : " + nPosY + "<BR>"
    //m_divBG.innerHTML = m_divBG.innerHTML + "X : " + m_nPosX + ", Y : " + m_nPosY + " / " + m_nTimeouts;

       m_nTimeouts = 0;    // 타이머 타임아웃 카운트 초기화

       // 캐릭터 보여줌
       ShowGhost();
}   // function MouseMoveBG()

초기화 코드에서 m_divBG의 MouseMove 이벤트를 MouseMoveBG()에 매핑했었습니다.
MouseMove 이벤트에서 제일 중요한 것은? 바로 커서의 현재 위치겠지요.
이벤트 핸들링은 event라는 키워드로 처리할 수 있고 event에서 얻을 수 있는 프로퍼티는 레퍼런스를 참조해야 합니다.

코드에서는 event.xevent.y로 현재 커서의 x, y 위치를 얻고 클래스 멤버 변수에 저장을 해둡니다.
사실 캐릭터 이동의 가속도도 적용하려고 커서의 이전 위치도 저장하긴 하는데 시간 관계상-귀찮아서- 사용되진 않습니다. ^^;

백그라운드에 마우스가 움직였다는 것은 어떤 상황이든 캐릭터가 보여야 하고 사용자 조작이 있었으므로 캐릭터가 사라지기까지의 시간을 초기화 해야 한다는 것을 말합니다.

캐릭터를 보여주는 코드는 메인 프로시저에 들어갈 수도 있겠지만 여기에서는 캐릭터가 보이는 조건이 MouseMove밖에 없으므로 해당 프로시저에서 처리했습니다.
만약 조건이 둘 이상이라면 별도의 멤버 변수에 캐릭터를 보여줘야 한다는 플래그를 설정하고 메인 프로시저에서 해당 플래그가 설정되어 있으면 캐릭터를 보이도록 처리하는 것이 더 효율적일 것입니다.

코드 설명하다 보니 엉성한 점이 하나둘씩 나타나는군요 흐흐...

/*--------------------------------------
|   ShowGhost
|   현재 커서 위치에 따라 적당한 고스트를 보여줌
---------------------------------------*/
function ShowGhost()
{
    //m_divBG.innerHTML = "Xpos : " + m_nPosX + " ImgX : " + m_imgGhost[0].style.left + " ImgY : " + m_imgGhost[0].style.top;
       var nPosX = 0;
       nPosX = parseInt(m_imgGhost[0].style.left);
if (m_nPosX < nPosX)
{
     if (m_imgGhost[0].style.visibility != "visible")
     {
         m_imgGhost[0].style.visibility = "visible";
         m_imgGhost[1].style.visibility = "hidden";
           }
}
else
{
     if (m_imgGhost[1].style.visibility != "visible")
     {
         m_imgGhost[0].style.visibility = "hidden";
         m_imgGhost[1].style.visibility = "visible";
           }
}
}   // function ShowGhost()

커서의 현재 위치를 기준으로 캐릭터 위치가 커서 위치보다 작으면 오른쪽을 봐야 하고, 그렇지 않으면 왼쪽을 봐야합니다.

여기서 주의할 점은 어떤 엘리먼트(객체)의 프로퍼티를 읽는 것은 빠르게 처리되지만 화면에 보여지는 상태가 변경되는 프로퍼티를 설정하거나 메소드를 호출하는 경우는 생각보다 많은 시간이 소모된다는 점인데요,
if (m_imgGhost[0].style.visibility != "visible")
와 같이 확인하는 코드를 넣어 상태를 변경할 필요가 없으면 최대한 변경하지 말아야 합니다.
만약 위의 코드 없이 왼쪽/오른쪽만 판단하여 마우스 이벤트가 발생할 때마다 이미지를 보이고 숨기면 엄청나게 버벅거리는 걸 느낄 수 있습니다.

이 점은 눈에 보이는 모든 요소에 해당하는 것으로 항상 화면 업데이트가 필요한 코드는 한곳에서 관리하는 것이 좋습니다. 그런 점에서 이 예제 코드는 썩 좋지가 않죠? (하하...)

멤버 변수 m_nTimeouts는 아무런 마우스 움직임이 없을 때 캐릭터가 사라질 때까지의 카운팅을 위한 것으로 자세한 것은 메인 프로시저 설명에서...

/*--------------------------------------
|   MainProcedure
|   메인 프로시저
---------------------------------------*/
function MainProcedure()
{
    clearTimeout(m_tmrMain); // 타이머 제거
    // MouseMove로부터 Timeout된 회수 체크하여 캐릭터를 숨길지 여부 확인
    if (m_nTimeouts < m_nMaxTimeouts)
    {
        // 타임아웃되기 전까지 캐릭터를 마우스 포지션까지 이동
        //m_divBG.innerHTML = "Timeup : " + m_nTimeouts;
        var nImgX = 0, nImgY = 0;
        nImgX = parseInt(m_imgGhost[0].style.left);
        nImgY = parseInt(m_imgGhost[0].style.top);
       
        if (m_nPosX < (nImgX - m_nGhostSpeed))
        {
            // 왼쪽 보고 있는 경우
            m_imgGhost[0].style.left = (nImgX - m_nGhostSpeed);
            m_imgGhost[1].style.left = (nImgX - m_nGhostSpeed);
        }
        else if (m_nPosX > (nImgX + m_nGhostSpeed))
        {
            // 오른쪽 보고 있는 경우
            m_imgGhost[0].style.left = (nImgX + m_nGhostSpeed);
            m_imgGhost[1].style.left = (nImgX + m_nGhostSpeed);
        }
       
        // 어느쪽이든 Y 위치 조정
        if (m_nPosY < (nImgY - m_nGhostSpeed))
        {
            m_imgGhost[0].style.top = (nImgY - m_nGhostSpeed);
            m_imgGhost[1].style.top = (nImgY - m_nGhostSpeed);
        }
        else if (m_nPosY > (nImgY + m_nGhostSpeed))
        {
            m_imgGhost[0].style.top = (nImgY + m_nGhostSpeed);
            m_imgGhost[1].style.top = (nImgY + m_nGhostSpeed);
        }

        m_nTimeouts = m_nTimeouts + 1;
    }
    else
    {
        // 시간 초과되면 숨김
        for(i=0;i<2;i++)
        {
            m_imgGhost[i].style.visibility = "hidden";
        }
        //m_divBG.innerHTML = "Cleanup"
    }
    m_tmrMain = setTimeout(MainProcedure, m_nInterval);
}   // function MainProcedure()

별것도 아닌 게 괜히 라인 수만 많네요.
여기서 눈여겨 볼 부분은 프로시저를 시작하자 마자 타이머를 클리어하고 모든 처리가 완료된 후 타이머를 다시 세팅한다는 점입니다.

만약 이러한 조치가 없이 타이머가 무작정 작동한다면, 메인 프로시저 내부의 코드가 어떤 이유로 지연이 걸려서 타이머의 주기보다 더 오랜 시간이 소요되었을 때 메인 프로시저의 코드가 미처 완료되기 전에 다시 메인 프로시저가 실행되게 되고 이는 심각한 버그로 나타나게 될 것입니다.

따라서 메인 프로시저는 반드시 타이머에 의해서만 구동되고 메인 프로시저 내에서는 우선 타이머를 끄고 자신의 임무를 모두 수행한 후에 다시 타이머를 가동하여 그 다음 턴의 처리를 수행해야 합니다.

메인 프로시저는 캐릭터가 사라져야 하는지 여부를 항상 체크합니다.

m_nTimeouts가 체크 회수보다 작다면 캐릭터가 아직 사라질 시점이 아니므로 m_nTimeouts를 계속 증가시키고 동시에 현재 커서 위치 방향으로 캐릭터를 지정된 픽셀만큼 이동시킵니다.

만약 사용자가 마우스를 움직이지 않고 가만히 있으면 m_nTimeouts를 0으로 초기화하는 MouseMoveBG()가 호출되지 않으며 메인 프로시저 내에서 m_nTimeouts는 계속 증가합니다.
이렇게 증가하다가 m_nMaxTimeouts에 다다르면 즉, 캐릭터가 나타난 이후로 사용자의 입력이 (m_nMaxTimeouts * 메인 프로시저 인터벌 시간)만큼 지났다면 캐릭터를 숨깁니다.

이 코드들이 무한히 반복되면서 part 1.에서 보는 것과 같은 사용자 움직임에 반응하는 캐릭터의 애니메이션 효과를 줄 수 있는 것이지요.


처음으로 좀 제대로 된 예제를 만들어서 설명을 길게 했습니다.
사용자 반응 처리를 위한 가장 기본적인 사항과 애니메이션에 대한 처리 아이디어는 이 예제로 충분히 이해할 수 있을 것입니다.

다음번엔 좀 더 개짓의 취지에 맞는 XML 비동기 통신... AJAX 기법을 활용한 개짓을 만들어볼 예정입니다.
개짓은 비동기 통신을 위한 메소드를 제공하는데요, 이것을 적극 활용하여 외부 XML으로부터 데이터를 수신하고 파싱하여 개짓 내에서 활용하는 기법을 알아보는 것이죠.


여담입니다만, 개짓 컨테스트를 준비하고 있는 다른 분들은 다들 숨어서 혼자서 개발하시는지 블로그나 게시판을 찾을 수가 없더군요.
단편적인 소개를 하는 곳은 몇몇 있는데 커뮤니티화 된 곳은 못찼겠더라구요.
혹시 다들 영어는 기본이라 외국 포럼에서 활동하시는거라면 낭패, 절망. OTL

개짓 개발자분들 정보 공유좀 하자구요! =3=

신고
Posted by gongdo

프로그램 개요는 part 1.을 참조하세요.
XML 코드는 뭐 볼 것 없이 넘기고 우선 스크립트의 풀 소스를 리스팅합니다.
XML을 포함한 모든 코드 다운은 여기.

more..

코드 컬러링해서 HTML로 export 하는 툴이나 공개 소스가 어딘가 있을 것 같은데... 그냥 MS Word에 넣었다가 붙여넣었습니다. 로딩이 좀 느리더라도 이해해 주세요. :(

   // user private member variables
   var m_divBG = null;             // <div>    : 백그라운드
   m_imgGhost = new Array(2),      // <img>    : 메인 캐릭터
   m_sBaseUrl = "http://www.3m4you.co.kr/gongdo/gadgets/Test04/";  // 개짓이 위치하는 URL

   m_nGhostSpeed = 3;              // 캐릭터의 속도
   m_nPosX = 0,                    // 메인 캐릭터의 X,Y 위치
   m_nPosY = 0,
   m_nPrevPosX = 0,                // 메인 캐릭터의 이전 X,Y 위치
   m_nPrevPosY = 0,

   m_nInterval = 30,               // 메인 프로시져의 처리 주기
   m_nTimeouts = 0,                // MouseMove 이후 타이머 회수 체크
   m_nMaxTimeouts = 40,            // 캐릭터의 생명 주기
   m_tmrMain = null;               // 메인 타이머

개짓 클래스의 내부에서 사용할 멤버 변수들을 선언하고 초기화 합니다.
가장 중요한 객체는 백그라운드 DIV와 IMAGE를 저장할 배열이고, 캐릭터의 이동 속도 및 현재 커서 위치, 메인 프로시저 구동 인터벌 등이 보이네요. 주석을 참고하시길.

이 멤버 변수들은 개짓 클래스 내에서 전역적으로 작동하며 모든 프로시저(함수)에서 공통으로 사용될 수 있는 요소입니다.

개짓 클래스의 컨스터럭터, this.initialize에서는 CreateObject()를 호출하여 필요한 초기화를 수행하고 디스트럭터, this.dispose에서는 DestroyObject()를 호출하여 자원 해제를 수행합니다.

/*--------------------------------------
|   CreateObjects
|   필요한 모든 객체를 생성하고 이벤트를 바인딩
---------------------------------------*/
function CreateObjects()
{
    // 메인 백그라운드 <div>
    var objTmp = null;
    objTmp = document.createElement("div");
    objTmp.id = "divBG";
    objTmp.style.pixelWidth = 300; // 최소 사이즈 결정
    objTmp.style.pixelHeight = 200;
    objTmp.style.backgroundColor = "#FF6633";
    m_divBG = m_el.appendChild(objTmp);
   
    // 메인 캐릭터 이미지 <img>
    for (i=0;i<2;i++)
    {
        objTmp = document.createElement("img");
        objTmp.id = "imgGhost";
        objTmp.src = m_sBaseUrl + "images/ghost_ani0" + (i+1) + ".gif";
        objTmp.style.position = "absolute";
        objTmp.style.left = 50;
        objTmp.style.top = 50;
        objTmp.style.visibility = "hidden";
        m_imgGhost[i] = m_el.appendChild(objTmp);
       }

       // 이벤트 매핑
       AttachEvent(m_divBG, "mousemove", MouseMoveBG);
      
       // 타이머 시작
       m_tmrMain = setTimeout(MainProcedure, m_nInterval);

       objTmp = null;
}   // function CreateObjects()

CreateObjects()에서 DIV와 IMAGE엘리먼트를 생성하는데 특히 IMAGE는 개짓에서 앞으로 사용될 모든 이미지를 메모리로 미리 로드를 해야 합니다.
다음으로 백그라운드 DIV의 MouseEvent를 매핑하는데요, AttachEvent()와 DetachEvent()라는 일종의 매크로를 만들어뒀습니다. 코드는 단순히 주어진 엘리먼트의 onXXXX라는 이벤트를 마지막 인자로 주어진 핸들러(함수)에 매핑한다는 거죠.

즉, AttachEvent(m_divBG, "mousemove", MouseMoveBG); 라고 하면
m_divBG 엘리먼트의 onmousemove 이벤트를 MouseMoveBG 핸들러에 매핑한다. 가 되겠습니다. 이후 m_divBG에서 mousemove 이벤트가 발생한 경우 MouseMoveBG 함수가 호출되겠죠?

다음으로 setTimer() 함수를 이용하여 메인 프로시저 구동을 위한 타이머를 활성화 합니다.
m_tmrMain = setTimeout(MainProcedure, m_nInterval);
이 타이머 객체는 클래스 지역 변수로 보관을 합니다.

마지막으로 함수 내부에서 사용한 임시 객체를 null로 해제해줍니다.
objTmp = null;
중요한건 어떤 객체건 더 이상 사용되지 않는 시점에서는 명시적으로 null로 설정하여 메모리를 해제해주어야 합니다. 물론 자바스크립트는 개비지컬렉션을 자동으로 수행하지만 프로그래머의 실수를 방지하는 차원에서라도 명시적인 메모리 해제는 중요합니다!
제 경우는 어떤 객체를 new나 createXXX등으로 생성하는 코드를 작성하면 바로 아랫줄에 null로 세팅하는 코드를 넣고 그 사이에 필요한 코드를 삽입하는 습관을 들였습니다.
이게 메모리 릭 관련 실수를 줄이는데 의외로 꽤 도움이 되더군요.

DestroyObjects()에서는 반대로 매핑된 이벤트를 제거하고 타이머를 중지시키며 사용된 객체들의 메모리를 해제합니다.

/*--------------------------------------
|   DestroyObjects
|   모든 이벤트를 해제하고 생성한 객체를 파괴
---------------------------------------*/
function DestroyObjects()
{
    DetachEvent(m_divBG, "mousemove", MouseMoveBG);
   
    clearTimeout(m_tmrMain); // 타이머 제거
    m_tmrMain = null;

    m_divBG = null;
    m_imgGhost = null;
}   // function DestroyObjects()

DestroyObjects()와 같이 정리하는 코드에서 주의할 점은 객체의 라이프 사이클에 따라 해제하는 순서에 영향을 받을 수 있다는 점입니다.

이 예제의 경우에 이벤트 매핑을 먼저 해제하고 타이머를 중지시킨 후 비로소 다른 객체들을 해제했습니다.
만약 객체들을 해제하고 이벤트 매핑이나 타이머 중지 코드를 사용한다면 당연하게도 '객체를 찾을 수 없습니다.'라는 스크립트 오류 메시지를 만나게 되겠죠?
또한 타이머를 사용하는 코드라면 타이머를 해제하지 않고 다른 객체들을 해제한다면 타이머가 미처 해제되지 않은 상태에서 이미 해제된 객체를 사용하려고 하는 상태를 만날 수도 있습니다. 뭐, 자바스크립트에서 그런 상황이 쉽게 나올 것 같진 않지만요.
어쨌든 기본에 충실해야겠죠.

위의 예제에서도 잘못된 부분이 눈에 띄는게 가급적이면 m_divBG보다 m_imgGhost를 먼저 해제했어야 합니다.
왜냐면 m_imgGhost는 논리적으로 m_divBG의 자식 엘리먼트이기 때문인데요, 객체의 해제 순서는 항상 최하위 자식에서 최상위 부모의 순으로 해주는 것이 맞겠습니다.


휴우, 별 내용도 없는 설명은 2회로 끝낼려고 했는데 코드까지 붙이다 보니 너무 길어진 것 같습니다. 나머지 핵심 처리는 part 3.으로...

신고
Posted by gongdo

이번에는 결과물 부터 시작합니다!
아래는 live.com에 오늘 다룰 예제를 테스트해 본 것입니다.
그간 정지 화면 캡쳐만 했는데 움직이는 예제이니 만큼 무려 동영상 캡쳐를 했습니다!


모처럼 동영상 업로드 기능도 있는 티스토리를 활용하기 위해 동영상으로도 다시 한번 우려먹고!

이번 회에는 좀 더 유용한 기능을 추가해봤습니다.
위의 결과물에서 보이는 것처럼 배경 DIV 위에 캐릭터 이미지가 있고 MouseMove 이벤트를 통하여 캐릭터가 마우스를 쫒아갑니다. 또 MouseMove 이벤트가 발생하지 않으면 즉, 커서가 멈춰있거나 화면 밖으로 나가고 일정 시간이 지나면 캐릭터가 -유령처럼- 사라집니다. 다시 커서가 움직여서 MouseMove가 발생하면 다시 커서를 쫒아갑니다.

뭐, 내용만 놓고 보면 아무짝에도 쓸모 없는 개짓이죠?
하지만 이벤트 핸들링과 타이머, 그리고 애니메이션의 기초를 시작하기엔 참 좋은 예제가 될 것입니다.
저는 현업 웹프로그래머가 아니라 이걸 만드는데만 해도 몇 시간 동안의 디버깅 스트레스에 시달렸다구요 :(
(웹 디버깅 너무 귀찮습니다. ㅠ.ㅜ)


작성에 필요한 요소들을 하나씩 짚어보죠.

1. 배경 DIV
개짓의 최소 사이즈를 보호하면서 배경 색상을 가지고 있어 일종의 stage 역할을 합니다.
또한 MouseMove 이벤트는 이 공간 안에서만 발생하면 되겠지요.

2. 캐릭터 애니메이션
마우스를 쫒아다니는 캐릭터로 보통때엔 숨겨져 있다가 배경에 커서가 올라오면 커서를 쫒아다닙니다.

만약 캐릭터가 한쪽 방향만 보고 움직이지도 않는다면 커서를 쫒아올때도 생동감이 없을 것입니다.


위와 같이 좌/우를 바라보고 있어야 커서의 위치에 따라 조금 더 자연스러운 움직임을 보여주겠고 2 프레임의 단순한 움직임이지만 단순한 위치 이동에도 어떤 동작을 하고 있는 것처럼 보이는 효과를 얻을 수 있습니다.

또 하나 생각해 볼 것은 어떤 구간 동안 일정한 동작을 무한히 혹은 비교적 짧은 시간동안 반복하는 애니메이션이라면 그걸 시간에 따라 스위칭되는 프로그래밍을 할게 아니라 GIF로 만들어 버리면 간단하다는 점입니다.

만약 왼쪽을 보고 있는 캐릭터 이미지 2장, 오른쪽을 보고 있는 캐릭터 이미지 2장 이렇게 만들고 내부 타이머로 각 이미지를 교차시킨다면 정말 쓸데없는 코드 낭비 아니겠어요? :)

3. 이벤트 핸들러
배경 DIV에서 발생하는 MouseMove 이벤트를 코드로 전달해야 하는 데요, JavaScript/DOM에서는 이벤트 핸들러를 해당 객체에 직접 바인딩 하는 방법을 사용합니다.
JavaScript가 편리한 점 중에 하나가 함수도 객체로 취급할 수 있다는 것 같습니다. (물론 다른 많은 객체 지향언어도 가능합니다.)

이벤트 핸들러의 바인딩은,
object.onMouseMove = fnEventHandler;
와 같은 문법으로 아주 쉽게 처리할 수 있습니다.
object에서 MouseMove라는 이벤트가 발생(on)하면 fnEventHandler라는 함수가 자동으로 호출이 되고 발생된 이벤트의 추가 정보는 핸들러 함수 내에서 event 라는 키워드로 접근할 수 있습니다.

또 C와는 다르게 클래스 내부의 멤버 함수도 별도의 처리 없이 그냥 함수 이름으로만 바인딩이 가능하니 쉬울 수 밖에요.

4. 타이머를 통한 프로시저 처리
위의 세가지 요소만으로도 커서를 따라오는 -따라온다기 보단 커서에 붙어다니는- 캐릭터를 만들 수 있습니다. 그렇게만 만들면 재미가 없고 좀 더 나은 동작을 위해 커서가 멈춰도 일정 시간동안 커서를 계속 쫒아오도록 했습니다.

데스크탑 애플리케이션을 만들때야 스레드 하나 추가해주면 간단하게 해결될 일이지만 스레드가 없는 환경에서는 두 가지 방법을 선택할 수 있습니다.

메인 프로시저에서 무한히 루프를 돌면서 모든 종류의 이벤트와 정보를 프레임 단위로 처리하는 방법과 짧은 인터벌의 타이머를 통해 메인 루틴을 처리하는 방법인데요, 이 시나리오에서는 타이머를 선택하였습니다.

전자의 경우 프로세싱에 관한 모든 사항을 메인에서 꽉 잡고 있고 루프가 최대속도로 동작하므로 비교적 빠르게 처리가 가능한 반면 무한루프이기 때문에 아무 처리가 없을 때에도 CPU 자원을 소비하는 단점이 있습니다. 주로 CPU의 자원을 몽땅 투자해야 하는 수준의 게임을 만들때 사용합니다.

후자의 경우 타이머의 주기별로 프로세싱을 하므로 CPU 부담이 거의 없고 객체위주로 처리를 수행하게 됩니다. 단점은 아무래도 전반적인 프로세싱 속도는 메인 루프에 비해 느리고 객체 중심 처리를 하다 보면 코드가 여기저기 흩어지게 되는데 디버깅할 때 상당히 애먹습니다.

타이머 방식을 선택한 이유는 개짓이 혼자서 리소스를 다 먹어야 할 이유도 없고 그래서도 안되기 때문입니다. 지금 만들고 있는 것은 어느정도 인터랙티브한 요소가 있어서 프로세싱이 상당히 많이 들어가긴 하지만 굳이 메인 루프가 꽉 잡아야 할 정도로 버겁진 않죠.

또 다른 이유는, 객체를 중심으로 하는 코드를 만들어 보고 싶기 때문입니다.
이 예제의 세부 코드들은 그런 객체지향과는 거리가 좀 있지만 차차 고쳐나갈 테니까요.


너무 하나마나 한 소리만 한 감이 있네요;
게다가 저는 웹 프로그래머도 게임 프로그래머도 아닌데 잘 알지도 못하면서 주절거린 것 같기도 하고...
제 설명에 문제가 있다면 가차 없이 지적해 주세요!!

글이 길어져서 예제 코드 설명은 다음 파트로 넘깁니다~ :)

신고
Posted by gongdo

퇴근후 밥을 후다닥 해치우고 간만에 열혈 모드로 개짓(^^)을 하고 있었습니다.
http://gotapi.com에서 엘레멘트들의 레퍼런스 뒤지다가 문득 표준에는 정의되지 않은 이벤트가 IE에서는 작동한다는 사실을 깨닫고 테스트 겸 불여우를 깔았습니다.

아뿔싸! 어느 정도 차이가 날 줄은 알았지만 이 정도 일 줄은...
위쪽이 IE, 아래쪽이 불여우입니다. 당연히 똑같은 개짓이구요.


여러 부분에서 차이가 납니다.
우선 가장 치명적인 부분은 개짓내의 iframe의 스크롤바가 자동으로 없어지지 않습니다!!
게다가 이 iframe은 live.com에서 생성되며 개짓은 이 iframe내에 로드되므로 개짓에서는 접근할 수 없고 설령 접근할 방법이 있다고 해도 그것을 수정하는 것은 프레임워크의 설계상 해서는 안될 일입니다.

기본적으로 레이아웃들도 미묘하게 차이가 나고 폰트 크기도 최대한 비슷하게 조정을 했는데도 차이가 납니다.

당연히 엘리멘트들의 어트리뷰트 지원도 차이가 있어서 IE에서는 style.position 및 style.offsetX, offsetY가 적용되어 이미지가 떨어져 표시되는데 불여우에서는 그냥 뒤에 붙어서 나오는군요.

사용자 입장에서는 별다른 노력 없이 보너스 효과를 얻을 수 있는 IE를 마냥 욕할 수만은 없는 노릇이죠. 특히나 IE에서 사용할 수 있는 다양한 이벤트 핸들러들은 개발자에게 한줄이라도 코드를 줄여주는 고마운 존재이기도 하구요.

하지만 MS는 라이브 개짓을 정식으로 서비스 하려면 최소한 프레임워크 자체는 타 브라우저를 고려하여 작성해야 할 것입니다.
왜냐면, 웹은 표준이잖아요!
제아무리 좋은 기능이래도 플랫폼에 따라 멋대로 달라진다면 무슨 의미가 있겠습니까.
애초에 웹이란 거대한 망에 MS를 비롯한 많은 회사들이 들러붙어 있는 것 아니겠어요? 이런 웹을 이용하여 서비스하는 이상 최소한의 규약을 지켜야 한다고 생각합니다.

Atlas에는 브라우저별 차이를 고려한 코드가 들어가 있다고 알고 있는데 혹시 몇몇 핵심 메소드 처리만 그렇게 되어 있고 UI는 전혀 고려하지 않은게 아닐지 걱정되네요.

휴우, 한참 텐션이 올라 두다다 코드짜고 있었는데 이런 잡생각에 빠지게 되었네요.
뭐 제 주장이야 IE는 표준을 준수하라! 준수하라! 준수하라!이지만, 개발은 몸이 편한대로 해야겠습니다. =_=
늘상 얘기하는 거지만 MS는 정말로 개발자를 MS의 틀 안에 묶어두는 힘이 강한 것 같아요. 한번 익숙해지면 참 발을 빼기가 어렵죠.
당장 onmoveend 같은 이벤트 구현만 해도 onmousemove와 타이머를 이용해서 객체별로 구동 시키려면 골치아파지네요.
이런 마약같은 MS같으니!

어쨌든, MS는 IE의 유용한 부분을 강력하게 표준으로 밀어붙이던지 아니면 다른 브라우저랑 사이좋게 지내든지 했으면 좋겠습니다.
IE, 불여우 이제 좀 사이좋게 지내면 안되겠니? 응?
신고
Posted by gongdo
겨우 Hello World 하나 해보고 일주일도 넘게 진도를 못나가고 있었습니다.
반성.

두번째 테스트 프로젝트로 그 유명한 Javascript Gamelib를 개짓에 올려보도록 하겠습니다.
Gamelib는 이쪽 : http://www.sean.co.uk/a/webdesign/javascript_gamelib/javascript_gamelib.shtm

Gamelib에 보면 Sprite example(4)에 적당한 게임이 들어있는데요 이걸 페이지 통째로 올리는겁니다.

처음엔 .js 파일에 어떻게든 통합을 해보려고 했는데 생각처럼 잘 안되더군요. live.com에 올려놓았을 때 에러 메시지에서 디버깅 힌트를 얻을 수 없어 디버깅은 포기하고 다른 방법을 사용했습니다.

개짓 개발자 가이드에서도 있는 외부 HTML파일을 통째로 올리는 방법인데요, 간단하게 iframe 개체를 하나 만들어서 개짓에 올리는 겁니다.
개발자 가이드에도 잘 나와 있으니 상세 코드는 생략하구요, live.com에 올라간 모습만 캡쳐.


네 Gamelib에 들어있는 전통적인 스프라이트 기반의 게임의 구동 화면입니다.
움직이지 않으니 모르시겠지만 화면 가운데에 줄줄이 늘어서 있는 캐릭터들이 키보드에 반응하여 이리저리 움직이는 게임이죠.

혹시 테스트 해보고 싶으신 분은 http://www.umax.co.kr/gongdo/gadgets/test02/test02.xml
이 매니페스트를 가져다 로딩해 보세요. 수상한 코드는 없으니 안심하시구요 :)

이 방법은 기존의 웹페이지에서 개발 되었던 컨텐츠를 거의 아무런 노력 없이 개짓 서비스로 올릴 수 있다는 엄청난 장점이 있습니다.

반면 단점이라면 서드파티 개짓 자체가 iframe위에 올라가는데 그 안에 또 iframe을 올린 꼴이라 페이지 부하가 상당합니다.
저 게임을 그냥 웹페이지에서 직접 로딩하면 끊김이 거의 안느껴지는데 개짓 안에서 로딩하면 프레임 레이트가 상당히 낮아지는 것을 느낄 수 있습니다.
저런 간단한 게임에 CPU 점유율도 상당했구요.

여기까지 해놓고 좀 고민됩니다.
사실 개짓으로 개발하기엔 넘어야할 산이 너무 많습니다.
우선 제가 웹 개발자가 아닌 탓도 있겠지만 개짓 코드에서는 디버깅도 어렵고 무엇보다 귀찮은 과정이 많지요.
하지만 기존의 HTML(+CSS+JavaScritp)라면 좀 쉽게 접근이 가능하고 Gamelib 같이 훌륭한!! 라이브러리도 그대로 쓸 수 있으니까요.
게다가 서드파티 개짓은 live.com의 리소스, 서비스 및 다른 개짓에 접근을 못하는데 그래서야 어렵게 개발한 이득이 전혀 없습니다.

지금 구상하는건 굳이 Gamelib 전체를 쓸 만큼 복잡한건 아니니까 가급적 개짓 코드내에 넣고 싶은데 어떻게 할지는 개짓도 Gamelib도 좀더 가지고 놀아보고 결정해야겠습니다.

음지에 숨어있는 다른 개짓 개발자분들은 진행이 어떻게 되시는지 궁금하네요 :)
신고
Posted by gongdo
이전 포스트에서 개짓 개발환경을 갖추다가 Cassini 웹서버의 문제로 난관에 부딪쳤습니다;

Cassini 웹서버는 기본적으로 C:\Cassini에 설치가 되는데요, Read Me를 보면 .Net 프레임웍과 csc.exe 그리고 gacutil.exe 파일이 필요한 것을 알 수 있습니다.
역시 Read me는 꼭 읽어봐야겠죠. 안 읽어보고 엄한데서 계속 삽질하고 있었습니다. :(

일단 Cassini 웹서버를 대충 설치해놓고, Cassini 웹서버 컴파일에 필요한 환경을 구성해야 합니다. 우선 .Net 프레임웍 런타임과 SDK를 설치합니다. 1.0도 되는 듯 하지만 굳이 1.0을 설치할 이유는 없겠죠. 2.0을 기준으로 합니다.
주소는 이쪽->http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=FE6F2099-B7B4-4F47-A244-C96D69C35DEC

닷넷 프레임웍이 정상적으로 설치되었다면,
C:\WINDOWS(또는 WinNT)\Microsoft.NET\Framework 아래에 설치된 닷넷의 런타임 버전별 폴더가 있습니다.

마지막으로 설치된 버전의 폴더에 보면 csc.exe파일이 있으며 이 경로를 시스템 환경변수에 등록합니다.
노파심에서 과정을 첨부합니다. OS별로 약간씩 구성이 다르긴하지만 찾는데 큰 문제는 없을 것입니다.
[내 컴퓨터]->[등록 정보(속성)]->[고급]->[환경 변수]->[시스템 변수]에서 Path를 찾고 Path에 csc.exe가 위치하는 경로를 ';'로 구분하여 추가

more..


또한 gacutil.exe는 비주얼 스튜디오 express 를 설치한 폴더 아래 SDK\v2.0\Bin 폴더에 위치해 있습니다. (제 경우는 D:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin)
이 경로도 위와 마찬가지 방법으로 시스템 환경 변수에 넣어줍니다.

그 후 Cassini 웹서버가 설치된 폴더에서 build.bat를 실행하면 자동으로 재컴파일하고 CassiniWebServer.exe를 사용할 수 있게 됩니다.

그런데...
이 웹서버, localhost에서만 테스트가 되는군요. ㄱ-
제가 세팅을 잘못했는지는 잘 모르겠지만 외부에서 접근시 응답을 안합니다.
단순히 세팅의 잘못이라고 해도 가장 큰 문제라면 외부에서 접근할 수 있는 도메인이나 계정이 없다는 문제. OTL

왜냐면, MS의 라이브 개짓은 live.com에서 직접 로드하는 방식이기 때문에 결국 외부에서 접근할 수 있는 계정이 필요하다는 거죠.
참 IIS 깔기 싫어서 여러번 삽을 펐는데 결정탑니다.

휴우...
끝까지 IIS나 Apachi 깔기 싫어서 그냥 친구의 계정에 당분간 기생하기로 했습니다. =_=


여기서 잠깐 야후! 위젯 엔진과 비교를 안할 수가 없는데요, 여담이니까 숨겨 놓습니다.

more..


Cassini든, IIS든, Apachi든 뭐든간에 일단 live.com에서 http로 접근할 수 있는 서버를 마련해야 원활한 테스트가 가능하다. 가 결론이 되겠습니다.

자 Gadget을 호스팅할 웹서버가 마련되었다면 Gadget을 위한 공간을 만들어주고 Gadget 샘플을 다운받아 호스트에 올려놓습니다. 링크에 자세한 설명을 참고하세요.

만만한 Hello World를 live.com에서 로딩해보겠습니다.
처음에 어디서 개짓을 테스트할 수 있는지 몰라서 한참 헤맸는데 혹시나 해서 제가 했던 과정을 그대로 올립니다.
live.com에서 Passport(MSN 메신저 계정) 로긴후, [Add Stuff]->[Advanced options]에서 URL을 통한 개짓 추가를 합니다. 이때 URL의 대상은 개짓 매니페스트(개짓 메인 xml)파일이어야 합니다.
해당 URL에 접근이 가능하다면 위와 같은 동의 화면이 나옵니다. 브라우저의 설정에 따라 몇가지 보안 경고 및 컨펌 창이 나올 수 있습니다. 개발할 땐 귀찮으니까 위와 같이 '신뢰할 수 있는 사이트'에 live.com과 start.com을 추가하는 게 좋습니다.
정상적인 경우라면 위와 같은 심플한! 개짓이 표시되어야 합니다.
URL 접근에 문제가 있다면 뭔가 다른 메시지가 나올 것입니다.

휴우...
어렵사리 외부에서 접근할 수 있는 계정을 준비하고 샘플 개짓을 띄워봤습니다.
다음엔 몇 가지 관심있는 코드를 구현해보고 테스트 해보겠습니다.

참고로 이 연재는 개짓에서 사용되는 코드에 대해 하나하나 설명하지는 않습니다.
왜냐면 필요한 사항은 이미 개발자 가이드와 API 레퍼런스로 모두 제공되기에 굳이 같은 내용을 제가 반복할 필요는 없기 때문입니다.
다만, 사용하면서 느끼는 어려운 점이나 유용한 팁 등을 중심으로 전개할 예정입니다.

혹시 개짓 컨테스트를 목표로 개발하시는 분이 이 포스트를 보신다면...
경험담이나 의견을 나눴으면 합니다.
개짓... 어차피 소스는 다 까발려지는 것 아니겠어요? 이왕 공개할거 미리미리 의견을 나누는게 훨씬 도움이 될거라고 생각합니다. :D
신고
Posted by gongdo
MS에서 제공되는 [개짓 개발자 가이드]입니다.
야후 위젯 엔진에 비해 좋은 점이라면 역시 주요 국가에 대한 지역화된 문서랄까요.
당연히 더 많은 정보는 영문 블로그 및 포럼에 있지만 일단 시작하는데 전혀 부족함이 없습니다.

시작하기 전에 [개짓 개발자 FAQ]를 주의 깊게 읽어보시는게 좋습니다.

위의 두 문서를 읽어보면 다 알수 있는 내용이지만, 스스로를 위해서라도 정리해둡니다.
적어도 제가 구상하고 있는 개짓의 가이드가 되겠습니다.

  • 작아야 한다.
    개짓은 혼자서 페이지를 다 사용하는게 아니다. 필요한 공간을 효율적으로 최소화 하자.
  • 가벼워야 한다.
    개짓은 작은 애플리케이션으로 사용자의 요구에 가능한 빠르게 응답해야 한다. 이미지, 사운드 등의 리소스는 초기화시 미리 로딩하고 지연이 생기는 시점엔 반드시 사용자가 자연스럽게 대기할 수 있도록 해야 한다.
  • 단순해야 한다.
    개짓은 자신의 동작 목적을 뚜렷하게 정의하고 있어야 한다. 쓸데 없는 욕심을 버리자. 주 목적외의 추가 기능이 필요하다면 그것은 다른 개짓이 제공해 줄 것이다.
  • 직관적이고 쉬운 동작을 해야 한다.
    개짓은 매뉴얼로 설명해야 할 정도로 복잡해서는 안된다. 누구나 이해할 수 있을 만한 조작과 그에 대한 동작을 할 수 있도록 하자. 개짓 내부 구성을 변경하는 환경 설정도 설명이 필요할 정도라면 과감하게 없애는 것이 낫다.
  • 유려한 그래픽 인터페이스!
    어쩌면 가장 핵심적인 내용이다. 완전히 똑같은 개짓-가령 계산기나 시계-이 있다면 사용자는 더 예쁜, 더 멋진 디자인의 개짓을 선택할 것이다. 잊지말라! 개짓은 단순하고 소스는 열려있다.
네 모두 말할 것도 없이 당연한 내용들입니다.
개짓 개발자 가이드에 따라 필요한 리소스들을 다운 받고 설치해봤습니다.
(모두 개발자 가이드에 있는 내용입니다. 문서에 직접 링크되어 있으니 문서를 보시는게 좋습니다.)

[개발 환경]
- .Net Framework(1.0 이상이면 되지만 2.0을 설치하시는게 좋습니다.)
- Visual Web Developer 2005 Express
- IIS 또는 Cassini 웹서버

비주얼 스튜디오 2005가 출시되면서 가장 반가웠던 것은 상당히 제한적이긴 하지만 무료로 쓸 수 있는 Express 제품군이 등장했다는 점입니다.
게다가 얼마전엔 30일이었던 Express군의 라이센스를 영구히 풀어버렸죠.(그렇게 알고 있는데 아니면 말고;)
사실 MS는 OS보단 SDK나 IDE를 훨씬 더 잘만든다는 건 개발자 사이에 잘 알려진 사실아니겠어요? :)

어쨌든, 비주얼 스튜디오의 강력한-이라고 쓰고 편리한이라고 읽는- 개발 환경과 친절한 MSDN의 지원을 합법적으로 공짜로 얻을 수 있다니... 이래서 오래살고 볼 일이라는 거죠.

현재 진행중인 윈도즈 라이브는 아직 갈길이 멀고 개발툴들도 베타라고 할 수 있습니다. 그래서 개발하다보면 이런저런 문제점이 눈에 띄는데 세미나에서 강성재 과장님이 말씀하셨듯이, '이 정도 에러는 괜찮습니다. 윈도가 안 뻗는 것만 해도 어딥니까.'
:D

아쉽게도, 제 환경에서 Cassini 웹서버가 동작하지 않네요.
실제 테스트는 다음으로 넘겨야 할 것 같습니다.
정 안되면 IIS든 Apachi든 깔아야 할지도요. :(
신고
Posted by gongdo
[Windows Live Gadget contest를 위한 MSDN 세미나]에 다녀왔습니다.
참고 : http://gadget-contest.spaces.live.com/

전체적으로 전에 AJAX와 Atlas 세미나에 비해 훨씬 더 준비가 잘 된 느낌입니다.
진행도 매끄러웠고 무엇보다 경품도 -_-b

세미나에서 가장 크게 느낀것은 MS가 Win32API 이후에 거의 바뀐게 없다고 해도 과언이 아닌 윈도 기반을 갈아 엎을 준비를 해나간다는 점이었습니다.
또 웹 2.0에 대한 MS의 해답도 슬슬 제시가 되고 있구요.
아직은 베타에 불과하지만 MS 특유의 견고한 SDK와 MSDN으로 빠르게 적응해나갈 수 있을 것 같습니다.

하지만, MS는 윈도라는 틀을 깰 생각은 추호도 없어 보입니다. 당연하다면 당연하겠죠. MS가 좀더 개방적이고 표준화된 플랫폼을 제시하고 다른 모든 개발자들을 리드할 수 있길 바랬는데 WinFX, .Net 3.0... 아무리 획기적인 환경을 제시하더라도 결국 윈도의 틀안에서 벗어날 수 없습니다.
개방적이고 표준화된 플랫폼... 뜬구름 잡는 얘기같지만 지금의 Java script나 XML도 충분히 그러한 플랫폼을 제공하고 있습니다.
다만 이들은 자신을 표현하는데 기존 브라우저라는 다소 비효율적인 방법에 의존해야하기 때문에 한계도 많습니다. 이런 한계를 깨는 방법에 좀 더 노력할 가치가 있지 않을까요.

뭐, 제가 뭐라고 해봐야 헛소리일 뿐이죠.
어쨌든.
개발자로서 흥미있는 기술들이 계속해서 발표될 예정에 있고 Live.com도 점점 진화하고 있습니다.
Live.com은 기존 웹 브라우징 환경에서의 웹 2.0 구현을 보여주고 있고 윈도 비스타의 사이드 바를 비롯한 Windows Live 연동은 데스크 탑과 웹의 경계를 초월할 수 있는 가능성을 보여주고 있습니다.

Gadget, 한국 MS에서는 가젯이라고 부르고 있지만 발음이 어려운 것도 아니고 그냥 개짓이라고 부르겠습니다.(실제 말할때는 섞어서 발음하게 되더군요^^; )

개짓은 Windows Live에 속한 서비스의 한 부분으로써 작고 가벼우며 특정 기능에 특화된 어플리케이션이라고 할 수 있겠습니다.
Live에서 개짓은 웹과 데스크탑과 하드웨어 디바이스 상에서 각각 라이브 개짓, 사이드바 개짓, 사이드쇼 개짓이라고 불리는 형태로 구현되며 사이드쇼 개짓은 임베디드 플랫폼의 특성상 조금 제한이 있을 수 있지만 어쨌든 라이브 개짓과 사이드바 개짓은 최대한 호환이 되는 형태가 될 것 같습니다.

저는 데스크 탑에서 구동되는 사이드바 개짓에 좀 더 관심이 많았는데 이번 컨테스트는 순수하게 라이브 개짓만을 대상으로 합니다.
또한 Live의 다양한 서비스를 개짓에서 연동하여 사용하는 것도 아직은 무리가 있어 보입니다.

여기서 작은 정보 하나!
MS 내부에서는 11월 중에 라이브 서비스와 관련된 SDK들의 업데이트를 준비하고 있는 것 같습니다. 아직 확정된 바는 없다고 하지만 그 때 쯤이면 라이브 개짓과 특히 사이드바 개짓의 개발도 좀 더 방향성을 갖게 될 것으로 예상됩니다.

MS가 야심차게 조용히 그리고 묵직하게 준비하는 윈도 라이브와 개짓.
윈도 비스타와 더불어 잘 지켜봐야할 것 같습니다.


p.s.
개짓 컨테스트는 10월 9일 까지 접수 마감인데요.
휴우... 아무리 간단한 코딩이라고 해도 생업과 동시에 생각하는걸 구현할 수 있을지는 자신이 없네요.
상품이 좀 빵빵한 편이라 슬쩍 욕심이 납니다.
당분간 야후 위젯엔진은 접고 이쪽을 건드려보기로 했습니다.^^
신고
Posted by gongdo


티스토리 툴바