Rhio.Kim's Blog - drawing Laputa Web -

Ajax/Rich UI 개발 방법론 - CRUD Pattern

Rhio.kim — Tue, 19 Aug 2008 22:36:39 +0900

CRUD(create read update delete) Pattern정의

이번 패턴을 정리하면서 어떤 이름을 지어볼까 매우 고민 스러웠습니다.
마땅한 이름도 생각이 나질 않고...

CRUD pattern 이라고 명명 했지만 처음 이름은 XHR pattern 이였는데..
문서의 흐름과 맞지 않는 것 같기도 하고...(혼자만의 가비지...)

자세한 사항은 첨부 파일을 예제소스는 example.js 파일을..
prototype.js 를 자주 활용하다보니 예제 또한...

모티브 :
웹 페이지에서 일어나는 사용자의 단일 액션에 대응하는 일련의 프로세스를 하나의 클래스에서 구현한다. 일련의 프로세스는 사용자가 서버에 요청을 하기 위해서 클릭을 한다거나 입력을 하고 요청을 하고 그에 따른 서버 측에서 처리가 이루어지고 처리 결과를 다시 사용자의 브라우저에 통보를 하고 브라우저는 결과를 통해 사용자에게 결과를 인식 시키는 일련의 작업을 말합니다.

목적 및 장점 :
1. CRUD(Create, Read, Update, Delete) 인터랙션에 대한 처리와 시스템 장애에 대한 빠른 문제 파악과 대응

조건 :
1. XHR Wrapped클래스가 존재하여야 한다. (prototype.js, dojo, jQuery, etc)
2. XHR 오브젝트를 이용한 데이터 처리가 있어야 한다.
3. 요청을 위한 단계와 응답에 대한 처리 단계가 간단하고 명료해야 한다.

제약 :
1. 복잡한 UI 처리 및 CRUD이외의 처리가 다소 병행되어 진다면 클래스 혹은 객체가 무거워질 수 있다.

단점 :
1. 특정한 인터랙션 위한 패턴으로 확장(extend) 및 소스 재사용 면에서 용이하지 못함

CRUD_pattern.pdf

example.js

중략...

요약

Ajax을 통한 개발에 있어서 사용자의 경험(user experience)은 매우 중요해졌습니다. 그만큼 사용자의 액션도 다양해졌고 매우 고급스럽게 바뀌어 가고 있습니다. 간단하게 인디케이터만 봐도 그렇습니다. 예전 Web1.0 방식에서는 웹 서버의 부하로 페이지가 열리지 않을 때 사용자는 단지 White Background 즉 아무것도 없는 하얀 백지 상태의 화면만 주시하고 있었어야 했습니다.

하지만 현재에는 인디케이터를 통해 사용자의 요청에 대한 진행 상황을 유연하게 표현함으로써 사용자의 경험을 존중해 줍니다.

이렇게 복잡해진 부분도 있지만 사용자 요청에 대한 대부분은 서버로부터 데이터를 요청하거나 입력, 갱신, 삭제에 대한 경우입니다. 요청에 대한 응답에 있어서 그 처리가 간단하고 명료한 시스템이라면 CRUD 패턴을 이용해서 하나의 요청과 하나의 응답에 대한 처리를 하나의 클래스에서 처리한다면 시스템의 장애가 발생 시 어떤 부분 즉 어떤 사용자 액션에서 발생했는지 쉽게 파악하고 대응할 수 있게 됩니다.

하지만 설계 면에 있어서 향후 시스템의 확장이 있을 경우나 사용자의 액션에 대한 처리가 복잡해지게 되면 대응하더라도 설계 구조 자체를 뒤바꿔 할 여지가 다분해 보입니다.

실제로 저는 BBS나 콘텐트의 댓글 시스템에 이전에 포스팅 한 Design by Design Pattern 과 함께 CRUD Pattern을 이용하여 개발을 했습니다. 유지 보수가 발생하지 않아서 효율 및 실무에 적용할 만한 패턴인지 증명되지는 않았습니다.

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다. 또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

Ajax 개발 시 HTML Design

Rhio.kim — Mon, 18 Aug 2008 15:59:15 +0900

<< 일반적인 디자인 패턴 >>

이 그림을 보고 과연 어떤 팁일까?
이해하지 못하시는 분들도 이해하시더라도 보잘것 없어 보일 수도 있겠습니다.
하지만 좀더 깊게 생각해보면 다양한 이점이 숨어있습니다.

위의 그림을 구현하는 것은 매우 간단해 보입니다.
하나의 영역에 로그인 화면과 로그아웃 화면에 함께 표출 되도록 디자인을 하고 display 값을 통해서 로그인 상태, 로그아웃 상태를 볼 수 있음을 의미합니다.

만약 서버 사이드 개발자라면 이런 경우 if문을 통해서 사용자가 로그인한 경우라면 로그인 된 상태의 HTML 소스를 표시하고 그렇지 않는 경우 로그인 할 수 있는 화면 소스를 표시할 것입니다.

그리고 디자이너라면 로그인 된 HTML 파일, 로그인 되지 않는 HTML 파일로 각각 디자인을 처리하는 경우가 많을 것입니다. (꼭 그렇지 않는 경우도 있습니다.)

이런 방식은 Web1.0 방식의 전형적인 방식으로 Ajax 개발 시에는 좀더 웹 표준을 준수하고 사용자의 경험을 존중해줄 수 있는 HTML Design 설계를 해야할 것입니다.

그에 있어 위의 그림은 기본적인 화면 설계 방법중에 하나일 것입니다.

요약해보면 크게 아래와 같은 이점이 있습니다.

첫째 디자이너와 개발자 모두 하나의 페이지에서 다양한 액션을 프로토타입핑 손쉽게 해볼 수 있습니다.

둘째 하나의 페이지에서 일어나는 액션과 사용자 경험에 대한 것을 모두 담고 있기 때문에 관리할 페이지가 줄어듭니다. (예를 들어 여러 페이지에 적용되어있던 css가 변경되어질 경우가 불 필요한 작업량이 줄어든다.)

셋째 Ajax/Rich UI 개발자들에게는 엘리먼트의 CSS class name 통해서 원하는 처리를 손쉽게 할 수 있다.

즉 디자이너에게도 Ajax/Rich UI 개발을 위한 기술적인 이해와 사용자 경험(User Experience)에 대한 요구 사항을 디자인 단계에서 부터 적용시켜야 한다는 것입니다.

<< 사용자 경험과 Ajax/Rich UI를 위한 디자인 패턴 >>

로그인 UI에 관한 부분을 위에서 설명한 부분을 추가해 다시 한번 그려 보았습니다.

네모단 박스는 모두 div이고 로그인 실패 알림 영역과 인디케이터 부분까지 표시를 한다는 것
기획자와 디자이너, 퍼블리셔, 디벨로퍼까지 모든 부분에서 사용자 경험(user experience)에 대한 부분에 관심을 갖고 기획하고 디자인을 하고 퍼블리싱을 하고 개발을 해야하지 않을까 생각해봅니다.

각 분야에서 자기만의 업무 분야도 중요하지만... 하나의 본질은 웹 서비스를 사용하는 사용자에게 장애없이 원한할한 서비스로서 만족감을 느끼게 하기 위함이니 늘 서로가 고민해야할 부분인것 같습니다.

리앙쿠르 암초(Liancourt Rocks) 독도는 일본땅!? 그렇담 일본은 한국섬

Rhio.kim — Mon, 14 Jul 2008 16:05:55 +0900

네이트온 긴급 속보가 띄길레 찾아본 독도에 대한 정보들을 모아봤습니다.
독도 과연 누구의 땅일까?

17세기의 역사때부터 한국의 땅임을 증명해주고 있는 자료들이 많은데
또 다시 2차 세계대전에 패배한 일본인들은 독도가 일본의 땅이다라고 명시되지도 않는 국제법을
언급하면서 독도는 일본의 땅이라고 교과서에까지 실는다니..

과연 누구의 땅일까? 누구의 땅인가요?
라고 물을때 일본인들은 대부분이 샌프란시스코 조약에 대한 이야기를 언급할 것이고 한국인들은 반대로
대부분이 당연히 울릉도의 행정구역으로 되어있기 때문에 혹은 동요에 나오니까!!

어떤 막연한 대답밖에 못할 것이다. 하지만 일본인들은 확실히 다르다. 국제법을 두둔하며 다케시마는 니뽄 땅이다라는 설득력있는 주장을 펼칠것이다. 이에 대응할만한 자료를 모으려 생각나는 참에 공부도 할겸 구글맵에 "Korea Dokdo" 라고 검색했더니

아무튼 대한민국이라고 뜨긴 하는데..

그 다음에 위키에 실린 글을 보면 역시 국내 자료 매우 자세히 독도에 대해서 설명해 주고 있습니다.

초기에 프랑스의 포경선 리앙쿠르 호가 독도를 발견하고 리앙쿠르 암초(Liancourt Rocks)라는 이름을
붙인 이레 늘 한국 땅이라고만 여겼는데..

일본은 역사를 되집어 가며 잃어버린(?) 자기네 땅이라 호소하고 있다.

위키 참조 내용
----------------
그중 하나인 1946년 1월 29일 2차 세계대전에서 패배한 일본을 통치하던 연합군 최고 사령부는 일본에게
약간의 주변지역을 정치상, 행정상 일본으로부터 분리하는 것에 관한 각서를 다음과 같이 지정하고 있다.

For the purpose of this directive, Japan is defined to include the four main islands of Japan (Hokkaido, Honshu, Kyushu and Shikoku) and the approximately 1,000 smaller adjacent islands, including the Tsushima Islands and the Ryukyu (Nansei) Islands north of 30° North Latitude (excluding Kuchinoshima Island); and excluding (a) Utsuryo (Ullung) Island, Liancourt Rocks (Take Island) and Kuelpart (saishu or Cheju) Island, (b) the Ryukyu (nansei) Islands south of 30° North Latitude (including Kuchinoshima Island), the Izu, Kanpo, Sonin (Ogasawara) and Volcano (Kazan or Iwo) Island Groups, and all other outlying Pacific Islands including the Daito (Ohigashi or Gagari) Islands Group, and Parace Vela (Okino-tori), Kercus (Kinami-tori) and Canges (Nakano-tori) Islands, and (c) the Kurile (Ohishima) Islands, the Habomai (Hapomazo) Islands Group (including Suisho, Yuri, ?ki-yuri, ?hibotsu and Taraku Islands) and ?oikotan Island.

좀더 자세한 사항은 위키를 참고하길 바랍니다.
------------------

좀더 결론적으로 다가가 보자..

1454년(세종 36년)에 편찬된 세종실록 지리지의 50쪽 셋째줄에는 무릉과 우산의 두섬이 언급되어 있고 1530년에 조선에 펴낸 팔도총도에는 우산도가 지금의 독도 위치와 반대인 서쪽에 그려져 있고 또한 이 지도에 대마도는 조선땅으로 표기되어 있다.

아래의 기사에서 좀더 섬세한 문제점 분석과 해결점을 제시해줄 수 있으리라 판단됩니다.
더 많은 기사들이 있겠지만 아래의 글을 보고 나면 좀더 현재의 독도 문제의 해결점을 빨리 찾을 수 있을 것
같다는 생각을 해봅니다.

위키(독도)
http://ko.wikipedia.org/wiki/%EB%8F%85%EB%8F%84

샌프란 시스코 조약 원문
http://www.taiwandocuments.org/sanfrancisco01.htm

미국은 독도문제 해결에 성의를 보여라!
http://www.pressian.com/scripts/section/article.asp?article_num=40050228094952&s_menu=%EC%84%B8%EA%B3%84

독도를 뒷거래한 美-日 샌프란시스코 조약
http://blog.empas.com/chltnrhkd/read.html?a=20104360

Ajax/Rich UI 개발 방법론 - Design by Design Pattern

Rhio.kim — Tue, 1 Jul 2008 14:27:26 +0900

Design by Design Pattern정의

Design_by_design_pattern.pdf

모티브 :
HTML 디자인을 개발자에 의해서 동적으로 생성되도록 처리하려면 개발자에 의해서 디자인을 javascript의 정해진 변수에 넣고 프로세서에 맞춰 필요한 디자인을 Document에 렌더링을 해야합니다. 유지보수 시 디자인적인 추가 요소가 발생할 경우 개발자가 디자인을 수정하거나 편집해야 하는 일이 발생한다.

목적 및 장점 :

1. HTML로 구성되어진 레이아웃을 ( HTML 파일 자체를) 개발자에 의해서 추가되거나 수정되지 않는데 목적을 둡니다. 즉 디자인과 개발의 완벽한 분리를 꾀하는데 목적을 둠
2. 유지보수에 있어 디자인과 개발의 업무량을 최소화 하기 위함
3. 초기 접속 시 불필요한 동적 렌더링을 피할 수 있다.

조건 :

1. 디자인 시 거의 모든 부분이 Div 구조로 디자인 되어야 한다. Table과 같이 다른 특성을 가지고 있는 영역끼리 하나의 Layout으로 연관되어 질 경우 개발자에 의해서 처리되는 로직이 매우 복잡해진다.
2. 디자인 시 특징이 다른 Div Element에는 유니크 한 ID를 부여할 수 있어야 한다.
3. 개발자가 ID를 부여할 경우에 개발 설계에 의한 최소한의 ID만 부여해야 한다.
4. 부분적으로 Table 을 사용해야 할 경우 개발자의 협의가 필요할 수도 있다.

제약 :

1. 개발자뿐만 아니라 디자이너도 DOM 에 대한 기술적 이해가 필요하다.

단점 :

1. HTML의 구조가 변경되면 구조에 맞게 javascript개발 부분도 변경되어야 한다.
즉 HTML 버전관리와 Javascript 버전관리가 함께 이뤄져야 합니다.
2. 페이지 접속 시 디자인 레이아웃의 흐트러짐 현상이 있을 수 있다.

좀더 자세한 패턴에 대한 설명은 PDF 문서에 담았습니다.

이 내용은Ajax/Rich UI의 특정한 개발을 위한 방법론에 가깝다고 봐도 무방합니다. 또한 개인적인 경험에 의한 정리이며 일반적인 시스템 설계에서 말하는 패턴의 정의와는 상이하거나 다른 의미를 갖을 수 있습니다.

적어도 현재보다는 약 1% 이상 국가의 폭력적 성향은 증가할꺼라 본다.

Rhio.kim — Tue, 1 Jul 2008 09:20:31 +0900

도대체 언제까지...
왜 창과 방패를 들고 날뛰는 그들 앞에는 지위와 지시를 하는 리더는 없는 것일까?

군이라는 집단은 계급 체계로 선임과 후임으로 나눠 명령에 의해 행동하는 곳이라 알고 있건만
도대체 저들은 어떠한 명령을 받았길레... 창과 방패를 휘두르며 그들의 폭력성을 키워나가는지...

그들이 날뛰는게 답답한게 아니라 아무런 생각없이 폭력성을 극대화 시켜 단지 혈을 보기 위한,
분노로 가득찬 날뜀으로 밖에는 안봐지는 이유...

그들이 사회에 나와 도대체 그런 경험을 토대로 사회생활에 얼마나 잘 적응할지..
그리고 그들의 미래에 얼마나 작은 혹은 큰 영향을 주어질지...

2MB 정권은 쇠고기 파동이라는 국난과 함께 향후 또 다른 큰 문제를 야기할 원인을 생산해 내고
있는지도 모르겠다.

그들이 향후 2년후 모두 제대해서 작은 시비를 가누는 말다툼 앞에 과연 얼마나 폭력성을
억누를 수 있을지 모르겠다.

적어도 현재보다는 약 1% 이상 국가의 폭력적 성향은 증가할꺼라 본다.

제발 미래의 내 동려와 친구와 혹은 제자가 될지 모르는 그들의 탓을 하고 싶지는 않다.

제발 지금 저렇게 창과 방패를 감정에 의해 휘두르는 그들 앞에 리더가 나와 시위대에게 폭력을 써야한다면 "폭력 진압 하라" 라고 외쳐 주기를 바란다.
그게 아니라면 그들의 폭력성을 진정시켜 국가의 안위를 위한 진압을 해주길 부탁한다.

시위대가 보이지 않는 폭력진압 현장의 가장 뒷선에서 뒷짐을 지고 명령하는 그런 모습은 제발
보이지 말았으면 한다.

당하는 시위대

당하는 전/의경

아침부터 그리고 블로그 성격에 맞지 않는 정치적 사회적 글을 기재하지 않고 싶었지만 답답한 마음이 가시질 않는다.

객체지향 이야기 - JYP 엔터테인먼트 박진영 대표의 객체지향 음악?

Rhio.kim — Thu, 26 Jun 2008 18:16:04 +0900

들으면 들을수록 중독되는 so Hot!

이미지 출처 : 고뉴스

과연 음악이 어떻게 만들어 졌을까요? 이런 곡에서도 어떤 객체지향이라는 느낌을 받게 하네요.
실 세계의 사물을 단순화해 놓은 객체들의 유기적인 조합은 so Hot이라는 음악과 같이 한 시대를 풍미하는 좋은 문화로 자리 남고 IT세계에서는 서비스나 좋은 소프트웨어로 남을 수 있다라는 생각을 해봅니다. 또한 후배들에게 물려줄 좋은 자산이 되리라 생각해봅니다.

박진영 대표는 객체지향 음악을 설계하는 패턴과 제작과정에 대한 상세한 설명을 알려주었습니다.

원더걸스의 이전 앨범의 텔미는 반주를 오브젝트를 먼저 만들고 거기에 멜로디라는 오브젝트는 붙인 경우이고 이번 앨범의 so Hot 은 멜로디를 먼저 만들고 반주를 붙이는 패턴을 적용하였다고 합니다.

1.    Kick (loop)구성 - drum
2.    Clap 구성

3.    Hihat 구성
4.    Percussion 구성

5.    Main synth – 기본 테마
6.    Base 구성

7.    Lead 구성

이렇게 7가지의 단계를 통하여 so Hot이라는 곡이 탄생하게 되었네요. 거기에 비쥬얼한 원더걸스라는 UI가 씌워졌고 테스트와 연습을 거쳐 최고의 음악으로 음악 방송을 통해 많은 팬들에게 서비스하게 되었습니다.

미얀마에 따뜻한 마음을 전달해요.

Rhio.kim — Sat, 21 Jun 2008 00:33:51 +0900

풀무원에서 좋은 일을 시작했네요.

이런 좋은 일은 옷장수님 블로그에서 맨날 퍼온답니다. ^-^
그런데 옷장수님도 늘 다른 블로그에서 얻는거 같아요.
촛불도 그랬드라구요.

블로그에 배너를 하나 달면 풀무원에서 2,000원씩 적립하여 500만원을 모아서 한국국제기아대책기구에
전달한다고 합니다.

우리에겐 단돈 2,000원이 스타벅스 커피 한잔 값도 안되지만 미얀마 친구들에게는 매우 큰 사랑입니다.

작은 정성이지만 블로거 분들이 많이 도와주시면 좋겠네요.
http://blog.pulmuone.com/116 에 가시면 다양한 베너를 퍼갈 수 있도록 되어있어요.

Javascript Optional pattern(pre-configured Pattern) 옵셔널 패턴

Rhio.kim — Fri, 20 Jun 2008 20:52:08 +0900

Javascript Optional pattern

디자인 패턴에 이미 있나? 패턴에 대한 심도 있는 연구를 해본 적이 없지만 javascript 개발을 하다 보니 자주 사용하게 되는 패턴이라 정리해봅니다. (이미 GoF 나 POSA 에 일부분에 적용되어져 있을 수도 있습니다.)

간단하면서 이미 많은 개발자들이 이런 방식으로 개발하고 있을지 모른다고 생각한다. 외국 라이브러리 역시 이런 방식으로 개발된 라이브러리가 꾀나 있다. 거론하자니 생각이 나지 않네요. Javascript Lib 카테고리 가면 몇몇 링크가 있는데 그들 중에도 있었다.

의도 :
하나의 클래스를 통하여 다양한 표현할 수 있다.

동기 :
컴포넌트, 위젯 형태의 개발에 좀더 사용자 설정을 강화하여 다양한 형태의 결과를 표현하고 싶을 때, 이로 개발된 산물은 pre-config 에 대한 이해를 통해 디자이너도 쉽게 접근할 수 있도록 해보자.

sample code

위 소스에서도 알 수 있듯이 사용자는 Hash형 Object 타입으로서 pre-config를 설정하여 해당 클래스가 new 키워드로 인스턴스화 되어질 때 해당 객체의 초기 설정값에 의해 동작한거나 config의 설정된 Option을 참고하여 객체가 동작되게 됩니다.

foo 클래스는 new 키워드에 의해 인스턴스화 될때 options 이라는 파라미터를 받아서 내부의 설정값으로 동작하게 됩니다. 컴포넌트의 Positioning, Sizing, Target Element 등을 생성할때 마다 다른 형태의 결과물을 볼 수 있습니다.

간단하게 생성한 객체들의 getXY 메서드를 수행했을 때 다른 결과 즉
Foo1 의 x, y 포지션은 생성시 아무런 파라미터도 주지 않았기 때문에 [100, 200]이 출력되었고
Foo2 의 x, y 포지션은 생성시 Hash 형태의 Object에 { x:300, y:300 } 을 넘겼기 때문에 생성시 넘겼던 옵션값을 그대로 취하게 됩니다.

이는 위젯 방식의 컴포넌트 개발 시에 매우 유용하며 javascript를 이용한 Rich UI, Application 개발 시 기획에 의도를 다양하게(?) 받아들일 수 있다.

또한 디자이너나 개발자들도 pre-config에 대한 이해만 있다면 값의 설정을 통해서 쉽게 원하는 결과물을 얻을 수 있다.

레거시 코드 이야기와 javascript 개발(Rich UI)의 현재?

Rhio.kim — Thu, 19 Jun 2008 00:57:24 +0900

개발자들끼리 통하는 한가지!.
소스 코드로서 시스템을 설명하고 이해할 수 있다라는 것이 아닐까 싶다.

2003년 학교를 졸업하고 들어가게된 직장에서 나는 이전 개발자의 철학과 프로그래밍 스킬의 정도 회사에 대한 충성심을 느낄 수 있었다.

그 개발자의 의해서 생산(?)된 코드의 일부를 생각나는데로 기재해본다.

델파이 소스 중 일부입니다. 변수명에서 느껴지는 회사에 대한 충성심?
procedure TForm1.Button1Click(Sender: TObject);
var
i : integer;
cipal, zot : integer;
begin
//do something
end;

변수명에서 느껴지는 프로그래밍 스킬(전역 변수를 위해 Label Component를 사용)
procedure TForm1.Button1Click(Sender: TObject);
var
i : integer;
begin
result := 1 + 2;
TLabel1.caption := i;
//do something
end;

procedure TForm1.Button2Click(Sender: TObject);
var
i : integer;
begin
ShowMessage(TLabel1.caption);
//do something
end;

이 개발자의 본성이 그대로 들어나는 레거시한 코드 델파이라 와닿지 않을 수 있지만 저런 코드가 다량의 unit 파일에 내제되 있었고 그의 철학을 느끼며 재개발에 들어갔었다.

과연 저 개발자는 어떤 생각을 가지고 변수에 cipal 과 zot를 남발하였을까? ^-^

한가지의 사물을 보고 단순화 하는 작업에 있어서 개발자마다의 특징이 있고 오브젝트화 하는 작업이 제 각각 틀릴 것이다. 이렇게 다양한 스타일의 레거시한 코드 덕분에 개발자들은 좀더 나은 코드를 위해, 좀더 좋은 서비스/소프트웨어를 개발하기 위해 노력할 수 있는 시간이 줄어든다.

오늘도 레거시한 코드를 살펴보며 이런 저런 고민끝에 역시 재 개발
이미 내가 생각하는 객체화의 영역에서 심하게(?) 벗었났다.

레거시 코드를 관리하는 내 능력의 한계일까 레거시 코드의 문제일까?

라는 질문을 던져보며 또 한가지의 다른 걱정 한번 해봤다.

오지랖인가 싶지만...

javascript 를 이용한 Rich UI, Ajax UI 개발이 조금씩 자리를 만들어 가면서 기존 ASP, PHP, JSP 로 만들때 보다. 개발에 필요한 요소가 더 복잡해졌다라고 하겠다.

디자이너가 해주던 HTML에 서버사이드 언어와 DB Query만 알면 왠만한 사이트 개발은 해치울 수 있다.
(이것도 그다지 간단한 일은 아니지만...)

하지만 javascript를 이용한 Rich UI, Ajax UI 개발시에는 알아야 할 표준만도 DOM, CSS, HTML, JSON, XML, ECMAS 2-262, Cross-Browsing 정도는 기술적 Base로 알아야 한다. 이미 Rich UI, Ajax UI 개발자라면 언급한 7가지의 접근법은 다양하고 많은 경험을 했을 것이라 본다.

(아직도 국내에서는 자바스크립트는 프로그래밍 언어로 보지 않는 개발자들이 아직도 많이 있다는 것)

하지만 국내의 Rich UI 개발자들의 실상은 그다지...
이미 생산성에 맞춘 RIA 개발에 포커싱되어있지 않을까?
이러한 실정을 토대로 이 분야를 선도하는 포털 사이트와 거대 사이트 들에서 자리잡혀 버린다면 최근 강조되고 있는 웹 표준에 대응하면서 생기는 다양한 문제점 보다 더욱 큰 문제를 또 한번 겪게 될지도 모른다.

또한 한가지 절대적으로 Rich UI, Ajax UI Tech guru로 활동하는 개발자들도 그리 많지 않다라는 것이다.
(숨어있는 고수님들의 노하우 좀 공유 부탁드려요. ^-^)

국외 다양한 자바스크립트 프레임웍을 보고 있자면 그들에게는 위에서 언급한 기술적 Base에 대한 발전된 모습을 느낄 수 있다. 그런 기술을 빠르게 습득하는 것도 우리 개발자들의 문제이겠지만 국내의 기술적인 모티브를 제공하고 외국의 프레임웍처럼 기술적 표본을 잘 정립해야하지 않을까 라는 걱정을 해봅니다.

과연 javascript에서 var foo = { }; 라는 코드가 어떻게 동작하고 각 자바스크립트의 엔진마다 메모리는 얼만큼 사용하고 어떤 차이가 있는지 그로 하여금 각 브라우저에서 구동될 Application에는 어떠한 영향을 미치는지?

1 + 1 = 2 라는 증명은 매우 간단해 보이지만 러셀의 1 + 1 = 2 에 대한 증명을 보면 그렇지 않다.
참고 : http://k.daum.net/qna/view.html?qid=3Sp2R

내가 짠 코드가 남에게 도움이 될 수 있다면....

이하 영상은 레거시 코드 관리에 대한 영상 및 자료입니다.

출처 : http://ecs.gseshop.co.kr/blog/359

WorkingEffectivelyWithLegacyCode.pdf

ExtJS Component Inheritance(ExtJS 컴포넌트 상속)

Rhio.kim — Thu, 22 May 2008 02:55:18 +0900

ExtJS 의 구조적 이해를 하고자 정리해 봅니다.

component 상속관계 in ExtJS.pdf

ExtJS 기본 이해하기 - I

Rhio.kim — Wed, 7 May 2008 10:35:36 +0900

ExtJS의 기본 이해하기 ( Component Class의 inheritance 구현 및 계층 구조의 이해 )

Ext.data.Connection 는 ExtJS의 Rmote server에 XHR Request를 위한 class이자 namespace 입니다.

ExtJS의 모든 Class는 Ext의 하위 패키지 그 안의 서브 클래스들로 구성되어 집니다. 이때 위 처럼 클래스들이 생성되어서 동작하기 위해서 기본적으로 하는 처리가 있습니다.

위의 소스를 간단하게 보겠습니다.
Ext.data.Connection 는 function 을 갖습니다. 첫번째 인자료 config 라는 Hash 형태의 오브젝트를 갖습니다.

Hash 형태의 오브젝트란?
{ key : value }의 형태를 말하고 이해를 돕기 위해 Hash형 오브젝트라 칭합니다.
Hash형 오브젝트 타입은 value에는 다양한 type의 값이 올 수 있습니다.

이는 사용 시 new 연산자를 이용하여 인스턴스화 되게 됩니다.
즉 Ext.data.Connection은 function으로의 기능이 아닌 instance 화 되어 사용되게 됩니다.

그러면 인스턴스가 생성될 때 수행되는 컨텍스트를 봅니다.

Ext.apply(this, config); 는 아래의 Ext의 맴버로서 수행되어집니다.

위의 apply에 의해서 this에 config로 넘겨준 값이 모두 overwrite 되게 됩니다. this가 가지고 있던 속성 및 메서드까지 모두 config가 가지고 있던 값으로 치환되어집니다.

이때 apply 에 첫번째 인자로 주는 config 는 ExtJS에서는 해당 클래스가 갖는 속성의 의미와도 같습니다.

좀더 쉽게 풀이해서 쓴다면 ExtJS의 하나의 클래스가 인스턴스화 되어질 때 기본적으로 갖게 되는 속성 그리고 상속구조가 형성되면서 override 되는 속성과 메서드들의 기본 설정을 합니다.

좀더 쉬운 예를 들어보면 하나의 widget이 생성되어 브라우저에 띄울 때 그 widget의 기본 사이즈, 드래그 앤 드랍 등을 할 수 있는 설정을 이 config에 Hash 오브젝트로 넘겨주는 초기 설정값과도 같습니다.

이 코드는 이벤트 리스너를 설정하게 됩니다. 최근에 릴리즈한 자바스크립트 프레임웍에는 Custom Event가 모두 지원하고 있습니다.

ExtJS에서도 이를 지원하는데요. 이는 Observable class에 있습니다.
위의 코드는 이 Ext.data.Connection 이 인스턴스화 될 때 사용하게 될 기본적인 이벤트 리스너에 해당하는 것들입니다.

위에 잠깐 예시를 들었던 widget 에서는 기본적으로 widget을 움직일 수 있고 최소화 시킬 수 있는 기능을 기본적으로 갖게 됩니다. 경우에 따라서는 숨길 수 있는 기능이나 최대화 기능도 부여할 수 있습니다. 이처럼 this.addEvent를 통해서 Ext.data.Connection 이 갖는 기본적인 이벤트 리스너를 등록하게 됩니다.

XMLHttpRequest 를 통해서 서버측 데이터를 받아올 때 혹은 받을때 받고나서 등등 다양한 상황에 맞는 이벤트 리스너를 사용하기에 앞서 Connection 클래스가 기본적으로 갖게되는 이벤트 리스너를 설정해 주게 됩니다. 위의 경우 ‘beforerequest’, ‘requestcomplete’, ‘requestexception’ 3가지의 리스너를 설정하게 됩니다.

이렇게 설정된 리스너는 fireEvent 메서드 즉 핸들러를 수행하게 됩니다.

마지막 구문

Ext.data.Connection.superclass.constructor.call(this);

상당히 길게 나열된 구조입니다. ExtJS의 가장 중요한 부분이라고 해도 과언이 아닙니다. 어떻게 해서 저렇게 긴 메서드가 생성되었을까요 간단하게 풀이해서 보도록 합니다.
Ext.data.Connection 이것은 굳이 Ext.data.Connection 이라고 하지 않고 this라고 해도 무방했을텐데 왜 그랬는지 살짝 궁금해집니다.

this를 쓰지 않았던(?) 못했던(?) 이유... 2008.05.18 추가

more..

그 다음에 오는 superclass 는 단연 계층 구조에 있어서 최상위 클래스, 부모 클래스를 나타낼 텐데요. superclass.constructor 입니다. 즉 superclass 가 아닌 superclass의 constructor를 나타냅니다. 이는 인스턴스화 되지 않는 부모 클래스의 생성자를 참조하고 있습니다.

그런데 과연 superclass 라는 것은 원래 있는 것인지? 아니면 ExtJS에서 기본적으로 제공하는 것인지 의문이 듭니다. 이는 Ext.extend 맴버에 의해서 Ext.data.Connection 에 부여됩니다.

Ext.extend(Ext.data.Connection, Ext.util.Observable, { … });

잠시 extend 메서드에 대한 설명을 간단하게 하고 넘어갑니다.
extend 메서드는 YUI의 구조와 동일합니다. 첫번째 인자로 넘어간 오브젝트에 superclass 속성을 부여하여 두번째 인자의 prototype을 superclass 가 레퍼런스하도록 합니다.

즉 Ext.data.Connection.superclass는 Ext.util.Observable.prototype을 레퍼런스하게 됩니다. 곧 Ext.util.Observable 의 constructor를 call 메서드를 통하여 호출하게 됩니다. 메서드를 Ext.data.Connection Scope에서 수행하게 됩니다.

이는 생성되면서 addEvent 를 통해서 생성된 이벤트 리스너의 동작을 켭니다. 이 말은 addEvent를 통해서 추가된 리스너들은 단지 ExtJS의 이벤트 class에 이벤트 이름만 등록하고 실제로 Ext.data.Connection 이 인스턴스화 될 때 비로소 리스너가 작동이 가능하게 됩니다.

언제나 그렇듯 말로만 보면 쉽게 이런 구조가 이해되지 않아서 간략하게 나마 그림으로 표현해 봅니다.

어차피 그림 조차도 설명이네요. ^^;

Prorotype in javascript (ECMAS 262-2 spec)

Rhio.kim — Tue, 29 Apr 2008 01:02:31 +0900

부제 : Javascript의 prototype은 어떤 의미를 갖는가?

MDC defined
Prototype is a property of various Javascript Objects
Prototype은 다양한 자바스크립트 오브젝트의 프로퍼티이다.

그럼 오브젝트는 무엇일까요?

object

An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function. A function stored in a property of an object is called a method.

Object는 Object의 타입^type의 맴버입니다. 그것은 기본적인 값^value이나 오브젝트^object나, 함수^function 각각 프로퍼티의 무질서한 컬렉션입니다.

오브젝트의 속성에 지정된 함수는 메서드^method라 불린다.

다시 MDC 에서 정의한 프로토타입에 대한 설명입니다.

프로토타입^prototype은 ECMAScript에서 구조^structure, 상태^status, 습성^behavior 를 구현하기 위해 사용하는 오브젝트^object입니다.

생성자^constructor는 오브젝트를 생성할 때 그 오브젝트에 프로퍼티 레퍼런스를 가리킬 목적으로 생성자^constructor의 연관된 프로토타입^prototype 을 참조하게 됩니다.

생성자^constructor와 연관된 프로토타입^prototype은 constructor.prototype과 같이 프로그램^program적인 표현^expression 으로 참조 될 수 있고 native Object의 프로토타입^prototype에 추가되어진 프로퍼티^properties가 공유^shared되어 집니다.

Constructor

생성자^constructor는 생성^create하고 초기화^initialize하는 함수 오브젝트입니다. 각각의 생성자는 상속구현과 공유 프로퍼티 사용을 위해 연관된 프로토타입^prototype 오브젝트를 갖습니다.

prototype 이라는 것은
javascript의 표준인 ECMAScript의 오브젝트 중 하나입니다.

이렇게 정의를 하고 계속해서 좀더 상세히 알아보도록 합니다.

ECMAScript는 C++, Smalltalk, Java 처럼 클래스의 개념이 존재하지 않지만 오히려 오브젝트를 위해 스토리지를 할당하고 그들의 프로퍼티에 초기값 할당을 통해 그것들의 일부 혹은 모든것을 초기화하는 실행 코드로 오브젝트를 만드는 생성자를 제공합니다.

생성자를 포함하는 모든 함수들은 오브젝트이지만 모든 오브젝트가 생성자가 되는 것은 아닙니다.

각각의 생성자^constructor는 프로토타입 기반^{prototype-based} 상속^inheritance과 공유^shared 프로퍼티^properties를 구현하기 위하여 프로토타입 프로퍼티 갖습니다.

오브젝트는 new 연산자에 생성자를 사용하여 생성되어짐 : 예를 들어 new String(“A String”)는 새로운 string 오브젝트를 생성합니다.

new를 사용하지 않고 생성자를 적용하는 것은 생성자에 따른 결과를 갖습니다.

예를 들어 String(“A String”) 는 초기 문자열이 만들어집니다. 하지만 오브젝트는 아닙니다.

ECMAScript는 프로토타입 기반^{prototype-based} 상속^inheritance을 지원합니다.

모든 생성자는 연관된 프로토타입을 가집니다. 그리고 생성자에 의해 생성되어진 모든 오브젝트는 생성자와 연관된 프로토타입(Object’s prototype 이라 불리우는)에 절대적인 레퍼런스를 갖습니다.

더욱이 프로토타입^prototype은 null이 아닌 원형^prototype에 절대적인 레퍼런스를 갖습니다. 그래서 이것을 프로토타입 체인^{prototype
chain} 이라고 부릅니다.

오브젝트에서 레퍼런스^reference가 프로퍼티^property에 만들어 질 때 저 이름의 프로퍼티를 포함하는 프로토타입 체인^chain의 첫번째 오브젝트에 저 이름으로 프로퍼티를 갖는다.

바꿔 말하면,

첫번째는 오브젝트가 직접 언급했던 프로퍼티가 있는지 없는지 조사(검토)하는 것입니다. 만약 오브젝트가 정해진 프로퍼티를 포함한다면 그 레퍼런스가 참조하는 프로퍼티입니다. 만약 그렇지 않다면 오브젝트는 찾기 위해서 다음 프로토타입^prototype으로 넘어간다.

즉 위의 예제 소스를 예로 설명하자면 마지막에 childObject.name.toString(); 를 호출했습니다.
최초 childObject가 가지고 있는 name을 참조합니다. childObject에는 name 프로퍼티를 가지고 있기 때문에 toString()을 수행하게 됩니다. 만약 name 프로퍼티가 존재하지 않는다면 fatherObject -> grandFather -> Object 까지 찾아가게 되겠죠.

아무튼 name 프로퍼티가 존재하므로 childObject에는 toString()이라는 메서드를 수행하게 됩니다. 하지만 childObject 에는 toString() 이라는 메서드가 존재하지 않기 때문에 Object.prototype.toString()을 수행하게 됩니다. 만약 Object.prototype.toString 메서드가 존재하지 않는다면 당연히 (fireBug)toString is not a function 이라는 메세지를 보게되겠죠.

그래서 클래스 기반^class-based 객체 지향 언어는 일반적으로 인스턴스^instance에 의해 이동된 상태, 클래스에 의해서 이동된 메서드 그리고 상속은 구조와 습성의 유일함이다.

ECMAScript에서 상태와 메서드들은 오브젝트에 의해서 이동되어 집니다. 그리고 구조, 습성, 상태는 모두 상속되어 집니다.

직접 그것들의 프로토타입^prototype이 포함하는 특별한 프로퍼티^property를 포함하지 않는 모든 오브젝트들은 저 프로퍼티와 그 값^value을 공유한다.

아래 다이어그램을 참조

CF는 생성자 입니다(그리고 또한 오브젝트 입니다.).

다섯개의 오브젝트는 new 연산자를 통해 생성 : CF1, CF2, CF3, CF4, CF5

각각의 오브젝트는 q1, q2의 프로퍼티를 포함합니다. 점선 라인은 절대적인^implicit 프로토타입^prototype 관계; 예를 들어 CF3의 프로토타입은 CFp입니다.

그 생성자 CF는 자체적으로 CFp, CF1, CF2, CF3, CF4, CF5에 보이지 않는 2개의 프로퍼티를 갖습니다.

CFp 안에 CFp1 프로퍼티는 q1, q2 혹은 CFp1라 지정되지 않는 CFp의 절대적인 프로토타입 체인에서 발견되어지는 어떤 프로퍼티들 처럼 CF1, CF2, CF3, CF4, CF5에 의해서 공유되어 집니다.

CFp와 CF 사이에 절대적인 프로토타입 링크가 없다는 것을 알아야 합니다.

클래스 기반 언어들과는 달라 프로퍼티들은 값을 할당하는 것으로 오브젝트에 동적으로 추가될 수 있습니다.

즉 생성자는 생성되어진 오브젝트의 프로퍼티 일부분 혹은 전체에 이름과 값의 할당하는 것을 요구하지 않습니다.

위의 다이어그램에서, 한가지 CFp에 프로퍼티에 새로운 값을 할당하는 것에 의해 CF1, CF2, CF3, CF4, CF5를 위한 새로운 공유된 프로퍼티를 추가할 수 있다.

모두 ECMAScript 262-2 Spec 자료입니다.
중간에 번역의 이해를 돕고자 이미지화 하였습니다. 혹 이미지화 한 것이 혼동을 잃으킬 수도 있습니다. ^-^;
오역이 있을 수 있지만 최대한 번역에 대한 점검을 하였습니다. (외국에 살다온 직장 동료에게 검증을 받았습니다. ^^;;)

Ari Balogh - Web 2.0 Expo Keynote

Rhio.kim — Tue, 29 Apr 2008 00:06:57 +0900

YAHOO 의 CTO Ari Balogh 의 강연입니다.
- Open Social Networking -

원본(YDN영화관) : http://developer.yahoo.net/blogs/theater/

누간 먼저 시작하려나?
준비 시작!

Adobe AIR 와 Google Gears에 대한 기술 요약

Rhio.kim — Sat, 26 Apr 2008 00:33:49 +0900

Adobe 사의 Ryan Stewart 씨와 Ajaxian의 java 커뮤니티 담당자인 Dion Almaer는 아래와 같은 슬라이드를 공유했네요.

Ajax Application 개발에 관심이 있다면 꼭 AIR에 대한 기술도 연마하시기를 권장합니다.

Adobe의 AIR와 Google의 Gears 의 발전 방향은 서로 비슷합니다.
온라인의 기능을 오프라인의 데스크탑 어플리케이션으로 만들 수 있는 방법을 제시하고 있습니다.

아래의 슬라이드 자료는 Ryan Stewart 씨의 AIR에 대한 개요를 제시하였고 이에 맞서 Dion Almaer씨가
Google의 Gears에 대한 개요를 제시하였습니다.

두 사람은 웹의 발전에 흥분하는 이유를 논의했고 또한 AIR과 Gears의 상호 보완할 수 있는 것들 또한
찾을 수 있었습니다.

처음 슬라이드를 볼때와는 달리 대화가 끝나고 슬라이드를 봤을때는 어려움이 없었다.
재미있는 연습을 통해 아래의 슬라이드 자료를 본다면 많은 도움이 될것 같습니다.

| View | Upload your own

Ajax 개발 시 자주 발생하는 순환참조 메모리 테스트 결과

Rhio.kim — Tue, 15 Apr 2008 01:19:20 +0900

몇 일전 가비지 컬랙션에 대해서 포스팅할때 함께 기재할 메모리 테스트 부분에 대한 결과입니다.
이미지 첨부할게 너무 많아 PDF로 만들어서 첨부합니다.

도움이 될련지는 모르겠습니다.

테스트 코드 역시 첨부합니다.
테스트 코드는 IE 8의 순환참조에 대한 메모리 누수 마이그레이션 팁에 대한 내용을 실제로 구현 테스트 해 본것입니다. 실제로 테스트 코드와 같은 패턴의 사용은 메모리 IE에서 메모리 누수의 심각성을 보여줍니다.

IE Circular-Memory-leak Magration

Circular-Memory-Leak Mitigation.pdf

메모리 누수 테스트 결과

메모리누스 그래프.pdf

테스트 코드

TLeak.zip

도움이 얼마나 될른지는 모르겠습니다. ^^
순환참조에 대한 경각심 정도는 불러 일으킬 수 있지 않을까 싶기도 하네요.

javascript 책 소개

Rhio.kim — Mon, 14 Apr 2008 23:51:34 +0900

Pro Javascript Techniques 상세보기

Resig, John 지음 | Springer 펴냄

Provides information on using JavaScript to develop Web sites.

Apress 에서 간만에(?) 좋은 책을 출간한듯 합니다.
조금 되긴했지만요.. ^^

요즘 출퇴근 시간에 어디 오갈때 보고 있는 책입니다.
사실 구매는 하지 않았고 에디나양이 재본을 해줘서 잘 보고 있습니다.

javascript에 대한 기술적인 소개와 DOM 과의 연동에 있어서 이슈가 될만한 사항들
jQuery 창시자이니 만큼 그에 관련된 기술적인 노하우도 조금씩 섞여있는 듯 합니다.

또한 내용들은 Ajax 어플리케이션 개발에 많은 도움을 주는 듯합니다.
또한 Framework에 대한 이해도도 좀더 빨라지지 않을까 라는 생각을 해봅니다.

아직 읽기 시작한지 얼마 되지 않았지만 상당히 좋은 내용이 많았습니다.
Javascript를 통한 DOM 처리 부분, Javascript의 특징, OOP가 가능하게되는 것들 다양한 기술적으로
접하지 못하는 부분들까지 조목조목 잘 집어주는 듯 합니다.

또한 국내에서는 그다지 javascript에 대한 프로그래밍 언어로서의 교재는 턱없이 부족한데 이 책의
번역서가 나온다면 참 좋은 레퍼런스가 되지 않을까 생각해봅니다.

Pro JavaScript Design Patterns 상세보기

Harmes, Ross/ Diaz, Dustin 지음 | Springer 펴냄

Pro javascript technical 에 더불어 Design patterns 책인데요. 다른 디자인 패턴 책들과 내용은 유사합니다.
다만 Javascript의 디자인 패턴이라는 것!!

기회가 된다면 이 책도 함께 읽어보면 좋을 것같습니다.
Java나 다른 객체지향을 했던 분들이 javascript의 패턴 책을 본다면 몹시도 혼돈스럽지 않을까도 생각이 듭니다. 그 흐름은 같지만 예제가 그다지 와닫지 않을 수 있다라는 생각을 했었습니다.

사실 제가 요즘 부쩍 판도라에 대한 포스팅을 자주 하는데요.

블로그 성격 이탈 현상을 보이지 않았나 생각해봅니다.

하지만 아직 몇가지 더 해야합니다. 핵심이 남아있기 때문입니다.
판도라 티비의 서비스의 Ajax 구현 Work Flow에 대해서 포스팅 할 계획입니다.
또한 멀티 랭귀지 지원과 Full Ajax 구현, Ajax 보안, 글로벌 서비스를 위한 Ajax의 선택,
Ajax Framework의 선택, Full Ajax의 문제점 등

Full Ajax Application 을 개발하면서 발생할 수 있는 이슈에 대한 전반적인
사항을 볼 계획입니다.