Rhio.Kim's Blog - drawing Laputa Web -

Design by Design Pattern정의


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

목적 및 장점 :

조건 :


제약 :

단점 :


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

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

             이미지 출처 : 고뉴스

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

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

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


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

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

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

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

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

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

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

Stoyan Stefanov씨는 Yahoo 엔지니어로 좀더 나은 예시를 찾기 위해 일해왔습니다.
그리고 새로운 결과를 아래 자료로 발표하였습니다.

그는 웹 페이지의 성능향상을 위한 14가지 기존 룰에 20가지 새로운 규칙을 찾아냈습니다.
우리는 다음 정보에 대해서 분류화 최적화를 하였습니다. :  서버, 컨텐츠, 쿠키, 자바스크립트, CSS, 이미지 그리고 모바일

아래의 새로운 목록입니다.  그리고 좀더 상세한 정보는 곧 발표할 예정입니다.

1. Flush the buffer early	[server]
2. Use GET for AJAX requests	[server]
3. Post-load components	[content]
4. Preload components	[content]
5. Reduce the number of DOM elements	[content]
6. Split components across domains	[content]
7. Minimize the number of iframes	[content]
8. No 404s	[content]
9. Reduce cookie size	[cookie]
10. Use cookie-free domains for components	[cookie]
11. Minimize DOM access	[javascript]
12. Develop smart event handlers	[javascript]
13. Choose <link> over @import	[css]
14. Avoid filters	[css]
15. Optimize images	[images]
16. Optimize CSS sprites	[images]
17. Don’t scale images in HTML	[images]
18. Make favicon.ico small and cacheable	[images]
19. Keep components under 25K	[mobile]
20. Pack components into a multipart document	[mobile]

Is it just me, or is performance getting a LOT of attention these days?

Firecookie는 Firebug의 extension으로 브라우저에서 쿠키를 관리하고 확인 할 수 있습니다.
관리측면이나 사용자측면에서 모든 쿠키를 별개로 이용할 수 있습니다.  이것은 Firebug 확장용으로 만들어져서
웹 개발자들에게는 친숙한 Firebug 유저 인터페이스를 따릅니다.
Firecookie가 성공적으로 설치되면 위에서 보듯아 YSlow 옆에 Cookies 탭이 생성되면서 cookie를 효과적으로 관리 할 수 있게 됩니다.


목록에 있는 모든 쿠키 정보를 클릭하면 확장되면서 상세한 정보까지 볼 수 있습니다.
 특정 쿠키 정보만 필터링을 하고 싶으면 Firebug의 search 창에서 필터링 할 이름을 적어놓으면 동적으로 필터링하여 처리해줍니다.

또한 Firecookie를 통해서 새로운 쿠키를 삭제하거나 생성가 가능하고  페이지의 권한 또한 관리할 수 있습니다.(이 말은 무슨말이죠??)


페이지에서 어떤 쿠키에 대한 변화가 생길때에 console 탭에 계속해서 변화에 대한 정보를 trace해 줍니다
쿠키에 대한 관리 능력이 뛰어납니다.  일단 개발자들에게 친숙한 Firebug UI를 따랐다는 것에 큰 점수를 주고 싶네요.

사용도 간편하고 뭐 필요에 따라서는 역시 쿠키 컨트롤이 쉬워져서
페이지 쿠키 정책에 매우 심사숙고하여 개발해야겠네요.

깔았으니 몇 군데 사이트 테스트 해봐야곘죠?

원본 : http://www.softwareishard.com/blog/?page_id=5

IE 8의 대응이 시작된 듯 합니다.  하지만 여전히 브라우저계의 미운새끼 오리라고 여겨지는 이유가 뭘까요??
몇가지 변화에 대한 소개입니다.

Ajax 향상
  1. Ajax Navigation :
   

  2. DOM Storage

아무튼 이 기능은 좋은 기능이기는 하나 각 브라우저마다의 메커니즘이 조금씩 틀리다면 이 역시 크로스 브라우징을 신경 써야하는 UI 개발자들에게는 무용지물 이라는 것!!


  3. Connectivity events

  4. Six connetions per host

 5. XHR Enhancements

이 부분 XHR을 사용하는 개발자라면 한번쯤 깊이 고민해볼 부분이 있습니다.
XHR은 아시다시피 비동기 통신으로 네트워크 상태에 따라 Response가 늦게 오는 경우가 발생합니다.
이때 사용자는 그런걸 모른체 UI에서 계속적인 요청을 하게 됩니다.

그렇게 되면 Request는 계속 쌓이게 되고 쌓였던 Request는 네트워크 상황에 따라 모두 Abort 날 수도 혹은 병목이 풀리면서 수천 수만건의 Request가 집중되는 현상이 발생합니다. 

이때 XHR Management를 해 주어야 하는데 이에 timeout 메커니즘이 포함된다니 좋습니다.

그 다음 XHR 에서 가장 이슈가 되었던 크로스 도메인 XHR인데요..  어떻게 처리 될 것인지 궁금하네요.
아시다 시피 Firefox 3에서는 이미 적용되어 있습니다. 이에 IE 8에서도 좋은 기능으로 내놓았네요.
브라우저의 기능이 아닌 HTTP Spec을 적용시켰다고 봐야겠군요..

Cross-domain Request(XDR) 이 가능해 졌고.
HTML 5 Spect 에 있는
Cross-Document Messaging(XDM) 기능도 추가 되었나 봅니다.

이 녀석의 브라우저 메모리 관리에 대해서는 어떻게 할꺼야.... 라고 생각하는 찰나.. 가장 밑에 부분에...

And we also have other features such as less memory leaks!

이렇게 남겨져 있네요..  여기서 다운로드 받은 PDF.. 메모리 릭 마이그레이션 전략 -_-;;
결론은 뭐 개발자들이 잘 개발해야죠 뭐... 킁.

오늘 愛人과 함께 백화점에 들렸습니다.
부모님 건강 식품도 알아보고 강아지 사료도 좀 보고 옷 구경도 하고 눈팅만 잔뜩하고 왔습니다.
(이거 Tech 카테고리에 "패턴 이야기" 맞는거야?)

참 연말이라 그런지 분주했습니다. 수 많은 객채들이 또다른 객채를 사기 위해 객채를 지불하고
그 대가로 객채를 받아 어느 객채에 담아서 거대한 객채를 돌아다니다 다른 객채와 대화를 나누고
객채를 한번 걸쳐보고 객채를 신어보고 객채에 상세 정보를 보고 그냥 지나가고 멀리서
다른 객채들을 처다보고 있습니다.

Javascript 백화점을 구현하시오!
200분의 시간을 드리겠습니다.

백화점엘 가면 이상하게 수면제가 있습니다. 1시간이 넘어가기도 전부터 잠이 쏟아집니다.
아무리 호화스러운 제품 신기한 제품이 있더라도 눈에 들어오지 않습니다.

수면제라는 객체는 무의식중에 생기는 객체입니다.  피로라는 객체도 함께 동반합니다.
연말에는 백화점에 혼자오는 객채는 없습니다.
이 큰 객채에서 객체들을 총 구매한 액수가 200,000원이 넘으면 50,000원 이하의 랜덤한 객체를 사은품으로
증정합니다.

이 거대한 객체는 총 100,000명의 객체를 수용할 수 있습니다.
이 객체의 매출액은 하루 68억원입니다.
(지금 무슨 소리하는 건지....) 

백화점에 가서 이런 생각을 했습니다. 과연 연말에 미x 생각이 아닐까 합니다.
이건 서론입니다.

본론으로 들어갑니다. ^-^*

실은 이이야기를 하고 싶었습니다.
화장실에 갔습니다. 늘 느끼는 거 였지만 자크를 내리기도 전에 센서가 작동하여 물이 나옵니다.
(참고로 남자 변기를 대상으로 설명합니다.)

가끔 사용자들은 자크를 내리는 속도가 느릴 수 있습니다.
그런데 미리 물은 나오고 볼일이 끝나고 사용자가 센서 앞에서 사라지면 다시 한번 물이 나옵니다.

센서 앞에서 사라지면 나오는 물은 아깝지 않습니다.
하지만 볼일을 보기도 전에 센서가 작동해서 물이 쏴하고 나옵니다.

이걸 좀더 현재 상황에 맞는 디자인 패턴에 맞춘다면 물도 아끼고 소변기의 청결 상태도 유지할 수 있을텐데
라는 생각이 들었습니다.

왜 자크를 내리기도 전에 센서에 의해서 물이 내려와야 하는지...
그전 사람이 떠날때 분명 청소가 이루어졌을텐데 말이죠..

변기 만드는 사람과 센서를 만드는 사람들이 서로의 업무 서로의 전공에 관여하지 말아야 합니다.
단 한가지의 인터페이스만 존재합니다.  센서에 의해서 소변기가 물을 틀어야 하는 것

그 왜에는 서로의 업무에 관여하면 안되겠죠.
그렇지 않고서는 지금의 방법이 최선일까요???
연초부터 이상한 생각을 했네요..

디자인 패턴은...
어느 개발자나 디자인 패턴에 맞춰 개발할 필요는 없습니다. 또한 거기에 연연할 필요도 없습니다.
그것을 나의 것으로 만들기 위해 학습은 하되 줄줄 외우려고 학습할 필요는 없습니다.
디자인 패턴이란 소프트웨어 설계에 있어 공통된 문제들에 대한 표준적인 해법과 작명법입니다.(위키 참조)

간혹 고수들의 대화를 지켜보면 이 프로젝트에는 이부분은 A패턴으로 저 부분은 B패턴으로 추가되는 부분은 C나 D패턴으로 하되 E패턴으로 변형 가능하도록 해야합니다. 모든걸 알고 있는 고수들의 패턴 대화는 알아듣기 조차 힙듭니다.

하지만 꼭 알아 들을려고 하지마시고 학습은 하세요.  열심히 코딩하고 리팩토링 작업을 거치다보면 어느새 코딩에는 패턴이 적용되 있고 누군가가 당신의 소스를 볼때 어느 패턴을 적용되었다라고 느끼게 될것입니다.

getElementsByClassName 가 native 가 되었다.
여담 : 저는 이런 Webkit, Mozilla 의 새로운 이슈되는 기사를 볼때마다 MS와 비교가 됩니다.
         발빠른 HTML 5 스펙, ECMA Script 4의 적용, Gears 등등 새로운 웹 기반의 패러다임을 만들기 위해서
         불철주야 새로운 이슈를 내놓는데 도대체가 MS는 IE 차기 버젼의 이름은 IE8 이다 라는
         이슈를 봤는데 그게 뭐 어쨋따는 건지... 이그.. 윈도우만 아니였으면 벌써 IE는 쇠퇴해 갔을텐데...


위 그래프는 getElementsByClassName 를 10,000번 수행한 결과 입니다.
상당히 아니 너무나 대조적입니다.  이게 왠말인가.. native 의 수행속도가 이렇게 확연히 차이가 나는 이유는
무엇일까요?

그 속내가 더욱 궁금합니다. 저런 수행 능력이라면 대부분의 것들을 native로 등록해서 쓸 수 있도록 하면 더욱 좋을텐데 말이죠.

이 메서드는 HTML 5 스펙이 추가되었습니다.
또한 파이어폭스와 오페라의 최신의 새버젼에서 지원합니다.


Javascript native method 의 명확한 이점!!

1. 추가적인 javascript 라이브러리 파일을 필요로 하지 않는 다는 것!!
2. 명확한 명세와 일관된 속성을 제공한다는 것
3. 눈부신 속도


밴치마킹 테스트 페이지 : http://webkit.org/blog-files/gebcnspeedtest.html(사파리)
출처 : http://webkit.org/blog/153/webkit-gets-native-getelementsbyclassname/

YSlow 0.9.2 릴리즈 소식입니다.

참 좋은 녀석입니다.  크게 2가지의 기능이 추가 되었습니다.
Components 부분에 기존에 없던 Ajax Request 정보와 Image beacon과 같은 DOM Object가 아닌 것들도
정보를 볼 수 있습니다.

개발자에게는 좀더 강력한 Web 2.0 개발의 디버깅 및 테스트 보안에 좀더 보완할 수 있게 되었습니다.

그리고 하나는 페이지 내의 느릿느릿한 iframe 나 frame 의 컨텐츠를 분석할 수 있도록 되었습니다.
국내에서는 iframe 이나 frame을 거의 쓰지 않기 때문에 설명은 하지 않습니다.

또 여러가지 버그가 수정되었고 다른 몇몇 기능 중 404 not found 강조, CSS 구문의 접근, Javascript 최소화
YSlow 판넬에 검색기능이 포함되었습니다.

이번 릴리즈로 고 성능의 Web2.0 어플리케이션 개발을 위한 더 강력하게 바뀌였네요.

좀더 정확한 릴리즈 정보는 여기서