XML/SWF Charts

간만에, SourceForge를 뒤지면서 Flash로 만든 오픈소스 차트를 찾아보다 XML/SWF Charts라는 제품을 발견하게 되었습니다. (사실은 ActionScript로 만든 애플리케이션 소스 보면서 공부해볼까하며 뒤지다가 샛길로 빠져버렸습니다. -_-;;)


 Introduction

maani.us의 XML/SWF Charts는 상당히 재미있는 제품입니다.
다른 차트들과는 다르게, charts.swf를 embed/object 태그로 삽입한 다음에, 라이브러리의 위치와 차트의 데이터를 지정하는 xml파일 위치만 지정해주면 화면에 차트를 표시해 줄 수 있는 구조입니다.

 License

기본라이센스는 몇가지 제약사항을 포함한 무료(Free License)입니다. 제약사항은 다음과 같습니다.

• XML/SWF Charts를 클릭하는 경우에, XML/SWF Charts 사이트로 이동하게됩니다.
  
• 다른 플래시 안에서 차트를 표시할 수 없습니다.
  
• 기술지원과 업데이트 정보를 얻을 수 없습니다.

유료 라이센스의 경우에도 하나의 도메인에 대한 $45짜리 라이센스와 무제한으로 사용가능한 $550짜리 두개로 나뉘어져 있습니다. (관련 링크)

 Usage

1. charts.swf를 사용할 html파일에 포함시킵니다.
2. charst.swf 사용에 필요한 라이브러리 파일과 차트의 데이타를 저장하는 xml파일의 위치를 지정합니다.

※ 차트 데이타를 저장하는 xml파일은 여러가지 파일을 담을 수 있습니다. 차트의 배경색이나, 차트타입, 카테고리값 등등등 여러가지 지정이 가능합니다.

xml파일 보기

<?xml version='1.0' encoding='UTF-8' ?>
<chart>
  <chart_data>
     <row>
        <null/>
        <string>2001</string>
        <string>2002</string>
        <string>2003</string>
        <string>2004</string>
     </row>
     <row>
        <string>Region A</string>
        <number>5</number>
        <number>10</number>
        <number>30</number>
        <number>63</number>
     </row>
     <row>
        <string>Region B</string>
        <number>100</number>
        <number>20</number>
        <number>65</number>
        <number>55</number>
     </row>
     <row>
        <string>Region C</string>
        <number>56</number>
        <number>21</number>
        <number>5</number>
        <number>90</number>
     </row>
  </chart_data>
</chart>

 Etc

사용해본 결과 색지정만 잘해준다면 상당히 만족스러운 결과를 얻을 수 있을 것 같더군요. 3D차트까지 지원이 되니깐요. 게다가, 세부 색상이나 글꼴지정부터, 이미지 삽입이나 라인차트와 컬럼차트를 함께 그릴 수 있는 등 다양한 세부항목을 지정할 수 있게 해줍니다. (세부항목 지정 프로그램만 만든다면, Office 97정도의 차트를 만들 수도??? ^^;;)

지원되는 차트 목록은 다음과 같습니다.
    * Line    * Column    * Stacked column    * Floating column    * 3D column
    * Stacked 3D column    * Parallel 3D column    * Pie    * 3D Pie    * Bar
    * Stacked bar    * Floating bar    * Area    * Stacked area    * Candlestick
    * Scatter    * Polar    * Mixed    * Composite    * Joined

출처: manni.us의 XML/SWF Charts

페이지 로딩 최적화 작업을 하면서 느낀점.

JavaScript로 작업을 하면서, 언제나 작업의 마지막으로는 '페이지 로딩이 느려요. 빠르게 고치333'이라는 요구를 많이 받게 되더군요. 해서 여러가지 실험과 함께 페이지를 빠르게 처리하기 위한 작업을 수행하였습니다.

아직 많지는 않지만, 페이지 로딩을 빠르게 처리하기 위해서는 다음의 방법이 매우 효과가 있더군요. [관련글]

1. js, css, html파일의 공백을 모두 제거하는 방법 (Minifying)
   
2. js파일을 하나로 통합해서 하나의 파일로 배포하는 방법(HTTP Request를 한번으로 줄여버리는 거죠)
   
3. 그리고, 로딩시에 생성할 필요가 없는 클래스는 늦게 로딩하는 방법(Lazy loading)
   -늦게 로딩하는 클래스에서만 사용하는 이미지나 css가 있다면, 로딩시간을 대박 줄일 수 있습니다. 저의 경우 0.4초정도 줄더군요.-
   

이 외에도 2의 방법처럼 이미지를 통합하여 Http Request를 줄이거나, 이미지의 width/height을 표기하는 방법 등을 사용하였습니다만, 1,2,3의 방법이 가장 효과가 많이 나더군요. 로컬에서 테스트할 때 2.2초정도를 줄였습니다.

이미지의 경우 통합하는 방법을 통해서 평균 70ms정도 줄더군요.(약 20개 정도의 이미지를 통합하였습니다 - 파이어폭스의 파이어버그 플러그인으로 테스트를 했을 때, 이미지 로딩은 여러 이미지를 멀티스레드로 로딩을 하는것 처럼 보이더군요.)

해서.. 결론은? 코드를 잘짜자 입니다. ^^

참고자료: 이미지 로딩의 최적화에 대한 모든 기법이 담겨있는 사이트가 있더군요 - Websiteoptimization.com

또 다른 태그 추가없이 CSS float을 지우기

CSS에 'float:left'가 설정된 경우 float속성을 추가 태그없이 clear시키는 방법에 대한 소개가 올라왔네요.

1. Floating the containing element as well.

.container-with-float {

float: left;
width: 100%;

}

width를 100%로 설정함으로서 float설정을 준 다음의 위치에 줄 바꿈(line-break)을 준 효과를 냅니다.
단점으로 a) 원하는 패딩효과가 다를 수 있습니다. b) IE6에서 아래쪽 마진(bottom margin)이 들어가는 경우가 있습니다.

2. Using overflow: hidden on the container.

.container-with-overflow {

overflow: hidden;
height: 1%;

}

container에 overflow:hidden을 추가함으로서 자동적으로 높이를 조절하고, floating된 컨텐츠를 알아서 처리해줍니다.

단점으로 a) 유동적인 높이를 원하는 경우, 원하는 동작과 다른 동작이 발생할 수 있습니다. b) IE6에서는 floating 되었음을 알리기 위해서 height:1%; 또는 zoom:1;을 사용해야 합니다.

3. Generating content using the :after  CSS pseudo-class

.container-with-generated-content {

height: 1%;

}
.container-with-generated-content:after {

content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;

}

container 뒤에 올 element에 :after(pseudo-class)의 css 속성을 추가함으로서 clear시킬 수 있습니다만 container 뒤에 element가 추가되어야 하는 문제점을 가지고 있습니다. . 단점, IE에서 :after를 지원하지 않는 가장 큰 문제점이 있습니다.

출처 : How to clear CSS floats without markup via Vitamin News

IE에서 Prototype.js라이브를 사용하여 Ajax로 통신할 때 느리다면..

prototype.js라이브러리를 사용하여 Ajax로 데이터를 전송하는데 IE에서 시간이 너무 걸리는 문제가 발생하였습니다. Firefox에서는 2초를 걸리던게, IE에서는 무려 89초가 걸리더군요.

위대한 alert()를 사용하여 시간을 측정해보았는데, 다음의 코드에서 걸리더군요.

if (typeof this.options.parameters == 'string')
    this.options.parameters = this.options.parameters.toQueryParams();

추적을해보고 이리저리 시험을 해본 결과 Ajax.Request를 사용할 때 parameter로 준 값이 문제가 되었습니다.
parameter의 값을 string타입으로 encodeURIComponent를 사용하여 encoding하고 넘겨준 경우

1. this.options.parameters.toQueryParams()를 거치면서 decoding 후,
   
2. Hash로 바꾸게 됩니다.

동일한 코드를 Firefox 및 IE에서 타지만, IE에서만 유독 decoding시에 많은 시간이 소모되더군요.
해당부분의 경우 Hash로 넘겨주게 되면(encoding안 한 상태에서) 88초 정도의 시간을 줄일 수 있었습니다.

P.S. 이문제를 해결하기 위해서 시간을 출력하는 코드를 찾아봤는데 Date 클래스의 parse()가 유용하더군요.

Date.parse(new Date().toString());

출력되는 값은 milliseconds단위로 출력되게 됩니다.

P.S.2 이자리를 빌어, 도움을 주신 J모 과장님과 L모 대리님께 감사를, 저 때문에 고생하신 개발팀원 여러분께 사과를 (__) ....

P.S.3 Ajax의 parameters로는 URL-encoded string과 Hash-compatible object를 사용할 수 있습니다.

졸은 몇명?

요즘 출퇴근 시간에 '김운희 교수의 삼국지 바로읽기'를 보고 있습니다.

오늘 출근시간에 『22. 전쟁의 발견 _더멀리  더세게: 무기의 발달』장을 읽고 있었는데 졸에 대한 이야기가 나오더군요.

물론 당시의 군사제도를 구체적으로 알기는 어렵지만 『주례』(周禮) 사도편에 따르면 병사 다섯 명을 오(伍)라고하고 5오를 1량(兩), 4량을 1졸(卒), 5졸을 1려(旅)라고 했습니다. 5려를 1사(師)라고하고 5사를 군(軍)이라 불렀습니다. 따라서 1량=25명, 1졸=100명, 1려=500명, 1사=2,500명, 1군=1만2,500명이 되지요.

1졸이 100명이라는 얘기가 되는군요. 문득 든 생각이 장기에서 그 졸이 이졸이라면.. 졸을 버린다는 의미는 100명의 사람을 버린다는 얘기가 되는데 섬뜩한 생각이 들더군요. -_-;;;; (예비군도 빨리끝나야지 원~)

P.S. 네이버 사전에서 검색해보니 100사람이라는 단어가 있군요. 쿨헉~

출처:

김운희 교수의 삼국지 바로읽기
네이버 한자사전 : 卒
이미지 출처: Outdoor Furniture:Checkmate에 나와있는 체스의 졸입니다.

'연합함대' 그 출범에서 침몰까지

연합함대
남창훈.박재석 지음 / 가람기획
나의 점수 : ★★★

'연합함대 그 출범에서 침몰까지'는 국내서적으로는 드물게 2차세계 대전의 일본해군을 다룬서적입니다. 연합함대의 형성과 진주만 공습을 시작으로 연합함대의 최후까지를 다루고 있습니다.

이 책에 관심을 가지게 된 이유는 '지팡구'를 보다가 가진 궁금증 때문입니다.
아시는 분은 아시겠지만 '지팡구'는 미라이라는 일본의 이지스함이 1942년 미드웨이 해전 때로 시간을 건너띄게되고 그와 관련된 이야기들을 다루고 있습니다.


어찌보면, 단순하게 가상의 역사소설이라고도 볼 수 있습니다만, 저의 생각으로는 좀 다르게 생각되더군요.
역사란 이긴자의 역사라고 알고 있지만, 그렇지 않은 경우도 있습니다. 대표적인 경우가 '삼국지'도 들어갑니다.

일 본이 끊임없이 가상의 역사 소설을 내보이면서 시도를 하고 있는 것은 일본의 침략전쟁을 일으킨 장본인들(육군) 보다는, '야마모토 이소로쿠'를 비롯한 해군을 선택함으로서 또 다른 의미의 '삼국지'를 쓰고 있는 것은 아닐까? 하는 생각을요.


이런 것을 알기 위해서는 무엇이 일어났고 어떠한 결과가 발생했나를 살펴보고 싶었습니다.
책자체는 볼만은 합니다. (저는 재미있게 봤지만, 다른 분들은 재미가 없을 가능성이 높습니다.)
그리고, 상당히 많은 양의 자료들을 사용한 것으로 생각되는데, 참고목록이라던가 인용한 부분에 대해서는 아무런 언급도 없다는 점도 아십게 생각되네요.

Apple TV에 Mac을?

점심 때 RSS피드를 읽다가 눈에 띄는 기사를 봤습니다.

Get a full blown Mac for $299?

어떤 분이 Apple TV를 해킹해서 Mac OS X를 얹었다는군요. 단돈 $299라면... 끌리는걸요 ^^ 후후후
그런 고마운분이 있을 줄이야~~

출처 : ZDNet의 Get a full blown Mac for $299?
이미지 출처: Apple의 AppleTV의 Technical Specifications

한국의 FTA체결 현황

오늘의 대화 이슈는 역시 FTA더군요. 얘기도중에 어느나라와 FTA협상을 했는가에 대해서 얘기를 나눴는데, 얘기가 사람마다 달라서 검색해보았습니다.

FTA 체결 국가

칠레, 싱가포르, ASEAN, EFTA, 미국

FTA 협상 중 국가

멕시코, 인도, 캐나다, 일본

FTA 검토중 국가

호주, EU, 중국, MERCOSUR

• ASEAN : 필리핀, 말레이시아, 싱가포르, 인도네시아, 타이, 브루나이, 베트남, 라오스, 미얀마, 캄보디아
• EFTA : 스위스, 노르웨이, 아이슬란드, 리히텐슈타인
• MERCOSUR : 브라질, 아르헨티나, 우르과이, 파라과이

출처: 국제무역연구원 - 한국 FTA추진현황

P.S. 미국은, 포스팅 중에 뉴스를 봐서 올렸습니다.
P.S.2. 오늘의 포스팅을 간단하게 이걸로 때우는 옷군..^^

Five Common Ajax Anti-Patterns

Ajax Pattern에 이어서 Ajax Anti-Pattern도 나왔군요. (빠르기도해라.. -_-;;)

1. 타이머가 필요 없음에도 불구하고 폴링을 위해서 타이머를 사용하는 경우
 - Polling on a timer when you don't need to.
타이머는 지정한 시간 단위마다 호출되는 기능을 가지고 있습니다. 이러한 기능들을 이용하여 애니메이션을 보여주는 기능에 사용할 수 있습니다.

그러나, 이러한 만들어진 목적을 벗어나서 많은 곳에 사용할 경우, 타이머의 기능이 원하는 시간에 호출되지 못할 수도 있습니다. (자바스크립트는 단일 스레드를 사용하기 때문입니다.)

1. XMLHttpRequest를 보낸 후 응답을 받기 위해서 타이머를 사용 - onreadystatechange의 callback 메카니즘을 사용
   
2. 사용자 입력단어에 따른 검색 결과(Auto-Complete)를 보여주기 위해서 타이머를 - onkeyup의 callback 메카니즘을 사용

2. Callback을 받을 때, 리턴 결과를 확인하지 않는 경우
 - Not inspecting the return results in the callback.
XMLHTTPRequest를 사용해서 응답을 받는 경우 (onreadystatechange의 callback으로 메소드가 호출될 때) readyState나 status를 확인해보지 않고 사용을 하는 경우, 응답이 전부 도착하지 않는 경우라도 계속하여 state가 변화되고, 따라서, onreadystatechange의 callback이 호출되게 됩니다.

따라서, 불완전한 데이터를 전송 받게되어서 에러가 발생할 수 있게 되는 것이죠.

1. readyState와 status 체크함으로 해결할 수 있습니다. (req는 request입니다.)
   if (req.readyState == 4 && req.status == 200 ) {
   

   }

3. HTML만으로 될 일을 복잡한 XML로 하는 경우
 - Passing complex XML when HTML would be better.
서버사이드의 부하를 줄이기 위해서 클라이언트로 부하를 덜어오는 것 자체는 나쁘지 않습니다. 그러나, 클라이언트가 복잡해진다는 말은 많은 양의 자바스크립트(브라우져 호환성도 생각해야죠.)가 사용되어야 하는 의미이므로 항상 좋은 것은 아닙니다.

서버와 클라이언트 사이에서 잘 균형이 잡혀야되지 한 쪽에 부하를 주어서는 안됩니다. (정렬하거나 검색하거나,  추가, 삭제같은 동적인 작업이 필요하다면, 더 복잡한 클라이언트라도 괜찮습니다. 그러나, 단순하게 보여주는 즉, HTML로 대체될 수 있는 작업이라면 HTML로 작성하세요.)

4. JavaScript(JSON)를 사용하지 않고 XML 데이터를 주고 받는 경우
-  Passing XML when you should pass JavaScript code.
JSON을 쓰게되면,

1. 코드를 쉽게 짤 수 있습니다.
   
2. 전송하는 데이타의 양이 작아집니다. (실험한 데이터로는 52%까지 줄였다고 하네요.)
   
3. 데이터를 읽어들이는 속도가 빠릅니다. (실험했을 때는 9%정도 줄였다고 합니다만 정확하게는 데이터의 종류에 따라 달라질 수 있습니다. 복잡한 데이터의 경우는 XML이 더 빠릅니다.)

5. 서버에서 너무 많은 일을 하는 경우
 - Doing too much on the server
한 페이지의 테이블을 정렬하는 작업같은 경우는 서버에서 수행하는 것보다 JavaScript에서 처리하는게 더 빠르고 효율적입니다.

가장 중요한것은 치우치지 않는 균형감각이 아닐까 싶네요. ^^

출처 :

InfoQ의 Five Common Ajax Anti-Patterns와 원본기사인 IBM의 Ajax and XML의 Five Ajax anti-patterns