최근에 프로젝트에 ExtJS를 비록하여 몇가지 JavaScript 프레임워크를 검토한 적이 있다.
내부적으로 ExtJS를 사용하고 있지만, 결코 주변의 다른 프로젝트를 진행하고 있는 사람들에게는 적극적으로 권하지 않는다. 왜냐하면, 한국은 HTML, CCS 그리고 JavaScript를 웹 프로그램의 한 부분으로 생각하지 않고 있을 뿐더러, 그렇다고 디자이너의 역할 중의 하나라고도 생각하지 않는다. 그렇게 때문에 HTML, CSS 그리고 JavaScript의 전문가를 찾아 보기가 쉽지 않다.

ExtJS를 권하지 않는 이유는 처음 이를 사용할 때는 Windows에서나 제공할 수 있었던 많은 기능들이 컴포넌트화 되어 있어서, 사용하기 편할거라는 생각을 하는데, 이를 응용한 새로운 컴포넌트를 만들거나 제대로 기능을 사용하려면, 약 2달정도의 학습시간이 필요하기 때문이다. 개발 초기에 이를 감안한다면, 사용하는 것은 별 문제 없지만, 기존의 HTML과 CSS만을 이용할 때보다는 전체 개발시간이 늘어날 거라고 반드시 예상하고 개발 플랜을 잡아야 할 것이다.

최근에 기존에 개발되어 있던 기능을 살펴볼 일이 있었다.
개발자가 ExtJS의 코드를 그대로 가져다 써서 인지 사소한 버그가 있었다. ExtJS의 버그나 잘못은 아니라고 생각한다. Ajax와 ExtJS의 그리드 컴포넌트를 이용하였는데, 마지막 페이지에 있던 Rows를 모두 삭제하면 이전 페이지로 이동해야 하는데, 마지막 페이지 그대로를 표시하는 것이었다.

그래서, 몇가지 자료를 찾아보았더니, 관련된 예제는 아래와 같은 Link에 있었다.
그리드에 데이터 목록을 가져오고, 목록에 추가/수정/삭제에 대한 예제가 있다.

예제: Tutorial:Using Ext grid form dialog to achieve paging list, create, edit, delete function 

이중에서 delete에 대한 예제는 아래와 같았다. (아래 Delete Function 예제 참조)

 Delete function

Delete function will get the selected id(s) and create JSON data and send JSON data to Java server-side for handle.

/************************************************************
    * Action - delete
    *   start to handle delete function
    *   need confirm to delete
    ************************************************************/	
    function doDel(){
        var m = grid.getSelections();
        if(m.length > 0)
        {
        	Ext.MessageBox.confirm('Message', 'Do you really want to delete it?' , doDel2);	
        }
        else
        {
        	Ext.MessageBox.alert('Message', 'Please select at least one item to delete');
        }
    }     
 
    function doDel2(btn)
	{
       if(btn == 'yes')
       {	
			var m = grid.getSelections();
			var jsonData = "[";
	        for(var i = 0, len = m.length; i < len; i++){        		
				var ss = "{\"id\":\"" + m[i].get("id") + "\"}";
				//alert(ss);
				if(i==0)
	           		jsonData = jsonData + ss ;
			   	else
					jsonData = jsonData + "," + ss;	
				ds.remove(m[i]);								
	        }	
			jsonData = jsonData + "]";
			ds.load({params:{start:0, limit:myPageSize, delData:jsonData}});		
		}
	}

And delete parameter to server side with JSON data like this: delData=[{"id":"5"},{"id":"6"}]


위 예제를 보면, 서버로 데이터를 요청할 때, 파라메터로 start 값과 limit값을 보내줌을 알수 있다.
상기 예제 소수의 하단을 보면,    ds.load({params:{start:0, limit:myPageSize, delData:jsonData}});
라는 코드가 눈에 들어올 것이다. 이를 이용하여, 서버에서 DB에 쿼리를 수행해서 현재 페이지에서 필요로 하는 첫 번째 인텐스 값과 현재 페이지에서 표시할 수 있는 데이터의 갯수를 가져오는 것인데, 위 예제는 기본적으로 "0"번 인덱스를 서버로 보내서 매번 1페이지만 가져오는 것이다.

만약 이를 해결하려면, 두가지 방법이 있는데

첫번째는 위에서 사용했던 함수 ds.load({params:{start:0, limit:myPageSize, delData:jsonData}});
의 start 파라메터에 이전 페이지의 첫번째 인덱스를 넣어주는 것이다. 이를 위해서는 전체 Total Counter를 이용하여 총 페이지 수와 인덱스를 찾는 로직이 필요한데, 이미 많이 사용되는 코드라 쉽게 찾고, 만들수 있을 거라 생각된다.

두번째는 페이지 네이션을 모두 서버에서 담당하는 것이다. 이 경우는 동시에 사용자들이 수정 추가 삭제에 대해 부분도 충분히 고려되어 질 수 있다. 이에 필요한 계산 로직은 위의 첫번째 방법과 별로 다르지는 않고 단지 책임에 대한 부분만 책임을 지면된다. 이때는 서버에 현재 페이지의 첫번째 인덱스 번호를 서버로 보내주는 것이 바람직하다.
이를 이용하여 서버에서는 전제 개수와 페이지를 계산하고 마지막 페이지가 존재하지 않는 경우 이전 페이지의 목록을 보내주면 되기 때문이다.
 

Posted by 행복상자
기본적으로 RIA라는 말은 "Rich Internet Application"이라는 full name에서와 같이 Rich라는 말에 주목하게된다.
이는 기존의 인터넷 환경과 Resouce를 사용할 수 있는 환경이 좋지 않았다는 이유를 반증하기도 한다.

인터넷상에서 우리가 사용할 수 있는 Application은 C/S Aplication 즉 Client & Server 기반의 애플리케이션과는 구분이 된다. 기본적으로 웹 브라우져를 사용한 다는 전제가 깔려 있기 때문이다. 하지만 이것 또한 과거의 빈약한 네트워크 환경과 인터넷 환경에서의 이야기 이다.

현재의 대한민국의 인터넷 환경은 과거 10년전과 비교하면 엄청난 변화가 있다.
10년 전의 인터넷은 기업체와 대학에서 사용하던 상용 인터넷 서비스를 제외하고는 PC방에서만 체감할 수 있을 만한 빠를 속도를 경험 할 수 있었다. 그리고는 ADSL이 나오면서 일반적인 가정에서 이를 경험할 수 있었다.
지금의 인터넷 서비스는 집집마다 광으로 직접 연결되어 있다. 그리고 무선 인터넷 역시 많은 변화가 있었는데, 무선 인터넷의 빈약한 환경속에서 WAP으로 구현하거나 이와 유사한 형태로 데이터를 모바일 브라우져를 통해서 보았었는데, 어느샌가 우리는 WAP이외의 다른 브라우져을 더 많이 사용하고 있다.

이러한 변화는 단지 네트워크 기술의 발전에 의해서만은 아니다. 하드웨어 기술적인 발전과 관련 소프트웨어와 사용자의 제품에 대한 관심들 많은 요소들이 복합적으로 변화되고 진보해 왔기 때문이다.

과거의 RIA와 현재의 RIA를 바라보는 관점도 이에 맞추어서 달라져야 할 것 같다.
과거의 제한적인 환경들이 현재에는 많은 부분 해결되었고, 이를 위해 기술적으로도 많이 발전했기 때문이다.
하지만 우리가 Internet Application을 개발한다고 하면, 이는 곧 웹 브라우져를 기반으로 한 웹 프로그램을 개발한다는 말로 인식하기 때문에, 이는 기존의 방식과 별반 차이가 없어 보인다. 그러나 해결해야할 문제로 떠오르고 있는 것이 있다. 이전에는 우리의 인터넷 환경은 단지 마이크로 소프트사의 IE 6.0을 기준으로 웹 사이트를 만들고 CSS와 Javascript를 적용하는 것으로 호환성을 고객에게 제공한다고 생각하였다. 물론 이때는 지금의 javascript와는 다른 VBscript와 Jscript를 사용하기도 했다. 마이크로 소프트사의 90%가 넘는 절대적인 시장점유율이 불러온 결과로 웹을 이용한 서비스를 제공하는 포털과 개발자는 단지 IE에서 정상적으로 동작하는 웹 어플리케이션을 만들고 배포하면 그만이었다. W3C의 Web기술 권고안을 따르지 않고 IE의 시장 점유율에 지원하고자 하는 Web Browser를 쉽게 결정한 이유는 너무나도 단순하다. 개발비와 유지보수비를 줄이려는 욕구 때문이다. 때문에 대다수의 사용자가 사용하는 IE만 지원하면, 다른 브라우져와의 호환성 테스트와 개발 및 수정에 필요한 비용들 그리고 유지 보수에 대한 비용들을 추가적으로 지불하지 않아도 되기 때문이었다.

그러나 현재의 상황을 다르다. 마이크로 소프트사가 웹 브라우져의 개발에 대한 지원이 몇년가 전무한 상태에서 Firefox와 사파리 브라우져는 깊게 갈린 칼로 무장하고 대중의 앞에 나섰고, 상당한 성과를 올리는 중이다.
그리고, 새로운 기술과 기능들을 경쟁적으로 추가하고, 이를 구현한 새로운 버전의 브라우져를 사용자들에게 수시로 발표하고 있는 상황이다.

문제는 새롭게 시장 점유율을 높여가는 브라유져와 새로운 기능들을 추가할 때마다 나오는 브라우져간의 호환성이 항상 유지되어야 하는데, 꼭 그렇지 많은 않다는 것이다.
IE의 경우는 IE 6, IE7 그리고 얼마전에 발표된 IE 8 사이에서도 동일한 페이지를 전혀 다르게 표시를 해주고 있다.
사파리 브라우저의 경우도 마찬가지이이다. Safari 2와 3가 혼재되어 사용되고 있고, Safari 4에 베타 버전 이야기도 최근이 심심치 않게 들리고 있다. Firefox의 경우는 어떠한가? 이 역시 버전 firefox 2와 3를 같이 사용하고 있는 것이 현실이다.

최근 브라우져들은 속도를 개선하고 자기들이 가장 빠른 브라우져라고 자랑하고 있고, 사용자들은 최고의 브라우져를 골라서 사용할 수 있지만, 개발자 입장에서는 결코 행복한 상황만은 아니며, 새로운 고민에 빠져가고 있는 상황이다.
거기다 모바일 브라우져를 지원해야만 하는 상황에서는 좀더 문제가 복잡해 진다.
구현의 이슈를 뒤로하더라도, 이들 모두를 제대로 지원하기 위해서는 많은 시간과 추가적인 비용에 대한 문제가 있기 때문에 좀더 많은 고민들을 해야할 이유가 생겨나는 것이다.

이러한 이유들로 Flash와 Silverlight와 같은 RIA 기술들을 사용해야 하는 하는 것이다.
사실 이는 웹 표준과는 다른 기술들이고, 다른 방향에서 발전해 왔다. 하지만 Platform 독립적으로 동작할수 있도록 자신만의 컨테이너를 제공하기 때문에, 개발자에게는 동일한 실행 환경을 제공하게 되고, 이 위에서 개발을 진행하면 되기 때문이다.
  
개발과 비용과 유지보수의 이슈는 RIA를 사용하고 도입해야할 또 하나의 이유를 주고 있다.
 
Posted by 행복상자

이번 주는 여는 때와 달리 인터넷을 통해서, 몇가지 이슈들을 일으킬 만한 것들이 소개되었다. 특히 Google에서 몇가지 눈여겨 볼만한 것들을 내 놓았는데, 여기도 우리과 같이 한해를 마무리 하기 전에 프로젝트들을 정리하나 보다. (지금 내가 진행하는 프로젝트도 1.0 버전을 다음주까지 마무리 할 계획이다. 많은 우여곡절 끝에 여기까지 왔다. 그러나 높은 점수를 줄 수 없다. 개인저으로 많은 부분이 만족 스럽지 않기 때문이다.)

구글이 이번주에 발표한 내용중에, 특이 사항으로는 "Native Client"라는 것을 발표 하였는데,웹 브라우져를 통해서, OS가 가지고 있는 리소스를 최대한 사용할 수 있도록 도와줄 수 있고, 브라우져 상에서 애플리케이션을 빠르게 실행시키고, 이는 마치 데스크탑 Application 처럼 사용할 수 있다고 한다.

이미 Google의 도구들을 아는 사람은 유사한 것으로 Google Gears를 생각할 것이고 Googl 크롬을 떠 올릴 것이다. 그리고, RIA 관련 기술로는 MS의 Silverlight와 Adobe의 Flash 그리고 또 아직까지는 많은 사람들의 관심을 끌지는 못하고 있는 Sun의 Java FX가 있다.

이들의 유사점은 모두 Web 브라우져를 지원하지만, 웹 브라우져를 벋어 나려고 한다는 것이다. 내가 이전에 작성했던 글들에도 여러차레 언급 하였지만, 현재의 PC시장 보다는 Mobile 시장이 훨씬 크고, 앞으로의 성장가능성도 휠씬 높다.

위에서 언급하였던, RIA 관련 솔루션을 제공하는 MS, Adobe, Sun과 Google의 "Native Client"는 기술적인 관점에서 유사성이 많다. 왜냐하면, MS의 IE 브라워져의 관점에서 보면 Active X 기술을 사용할 수 밖에 없기 때문이다. 좀더 쉽게 설명하면 IE와 같은 웹 브라우져에서 동작할 수 있는 Application Container를 개발자와 개발업체에 제공하고, 이들이 만든 Software를 이 Application Container에서 동작시키는 것이다. 웹 브라우져에 Software를 구동시킬 수 있는 Layer를 두는 것인데, 이는 Adobe의 Flash Player를 생각하면 쉽게 이해가 될 것이다. RIA Application을 개발하고 이를 Adobe의 Flash Player(Application Container)를 통해 동작시키는 것이다. 이는 기술적으로는 다른지 모르겠지만, Layered Design 관점에서 보면, MS의 실버라이트, Adobe의 Flash, 그리고 Sun의 Java FX가 동일하다. 이렇게 한다면, 브러우져의 종속성을 크게 줄일 수 있는데, 만약 웹 브라우져의 스펙에 이러한 부분들이 반영되어 있고 표준화 되어 있다면, 이들 회사가 이러한 Container를 제공할 필요도 없었을 것이다. 

"Native Client"에 대해서 눈여겨 보아야 하는 이유는 어제는 Google의 크롬 브라우져가 정시으로 Release되었다. Google Gears도 그렇지만, 인터넷 또는 netwrok이 되지 않는 환경에서도 Application을 실행하고 사용자가 원하는 작업을 할 수 있도록, Google은 관련 기술들을 만들어 내고 있다. 이러한 연장 선상에서 기술의 흐름을 이해하는 것이 중요하다.

"Native Client"는 지난 3일 전에 발표되었지만, 아직 자세히 살펴 보지는 못하였다. 이번 주말에 짬짬히 살펴볼 예정인데, 아래 몇가지 링크와 동영상이 있다. 이해 하는데 도움이 될 거라 생각한다.

 
 1. ZdNet에 소개된 기사 
  
 2. Google Native Client
 
 3. Google's Reserch Paper
   





 

Posted by 행복상자
Scott Guthrie의 Blog에 의하면, 내년에 Release될 Silverlight3에는 몇가지 중요한 변화들이 있을 거라고 한다.

Silverlight 3는 미디어지원을 위해서 H.264를 지원할 것이고, Graphic 적으로는 GPU의 Harware acceleration을 직접적으로 지원하기로 하다고 한다.
(사실 이부분은 .Net Framework의 WPF의 기능개선과도 연관이 있는데, 최근에 발표되어 배포되고 있는 Visual Studio 2008의 SP1에 포함되어 있다. 이전보다 약 30%의 성능 향상이 있다고 한다.)

그리고 Application 개발 측면에서는 좀더 풍부한 데이터 바인팅과 Component들을 지원할 계획을 가지고 있다고 한다.

개발 툴 또한 좀더 비쥬얼한 측면에서 쉽게 작업을 할 수 있도록 기능이 개선된다고 한다.


Posted by 행복상자
최근에는 여러가지 기술적인 진보보다는, 성숙해가는 기술들을 이용한 WEB 2.0이라는 테두리 안에서 서비스들이 꽃을 피우려는 했으나, 그냥 지나가는 시대의 화두로 끝날지도 모른다는 두려움이 크다.

물론 이는 세계적인 불황도 한 몫을 하지만, 그렇다고 기술적인 진보와 발전은 멈추지 않을 것이다.
최근에 신 브라우져 전쟁이라는 화두를 던져보기도 하고 브라우져 춘추 전국 시대와 미래예측 이라는 글에서, 주제 넘게도 미래를 그려보기도 하였다.

최근에 미국의 AOL에서 Silverlight를 이용한 Mail Client 프로그램을 개발하고 이를 공개하였다. (아직은 Beta 버전이다.)

Welcome to the AOL® Mail RIA Beta! 라는 제목으로 간략하게 서비스를 설명하고 있는데,
이는 다음의 URL에서 살표 볼수 있다.

AOL Mail RIA - Hubble Skin
사용자가 체험할 수 있는 메일 클라이언트는 윈도우즈, 웹 메일 등의 형태로 제공되어져 왔기에 우리가 그 기능적인 차이는 느끼기 쉽지 않지만, RIA를 통한 경험적인 차별성은 여러가지로 제공되어 질수 있을 것이다.

AOL이 Silverlight를 이용하여 제공할 수 있는 환경은 아래와 같다.
하지만 사실을 아래 표에 나온 환경들은 Silverlight가 동작할 수 있는 브라우져와 OS들의 조합들이다.

AOL® Mail RIA supports the following browsers and operating systems:

Operating System Internet Explorer 6 Internet Explorer 7 Firefox 3 Safari
Windows Vista - Yes Yes -
Windows XP SP2 Yes Yes Yes -
Mac OS 10.4.8+ (PowerPC) - - - -
Mac OS 10.4.8+ (Intel-based) - - Yes Yes

아래는 로그인 Page이다.


RIA라는 환경은 사용자에게 UX를 제공하기도 하지만, 궁극적으로 Cross-Platform에서 동작이 가능한 사용자 환경을 제공할 수 있다는 것이 가장 큰 매력이라고 할 수 있다.
이른 개발자가 한 환경에서 제대로 개발하면, 나머지는 Silverlight의 Container 또는 Play가 처리해 준다는 것이다. 아직은 컴포넌트나 기능들이 초보적인 걸음마 수준이지만, 이는 얼마 안되어서 해결될 것이다. 기술의 성숙기에는 그에 맞는 결과들이 나타날 것이기 때문이다.

 

 
 
Posted by 행복상자

얼마전에  "Silverlight 2.0 발표 즈음하여" 라는 제목의 글을 올린 적이 있었다.
Silverlight 1.0을 발표하고 많은 노력과 공을 들여 개발하고 최근에 2.0을 발표하였는데, MS가 전략적으로 집중하는 모습이 이전의 브라우져 전쟁때와 비슷하다. 
그때는 넷스케이브가 브라우져의 90% 이상의 점유율을 가졌을 때이기 때문에, 새로운 시작과 기술들은 넷스케이프를 중심으로 열릴것이라고 생각되었던 때이다. 

하지만 MS는 OS의 강점을 10분 이용하여, OS의 설치시 자신의 웹 브라우져인 IE 3를 기본적으로 윈도우의 설치해서 배포하였다. 이 당시에는 지금 생각하면 황당한 것은 새로운 브라우져를 설치하면, 내가 개발하던 프로그램이 갑자기 동작하지 않거나, 에러를 발생시키도 하였다. 이는 웹브라우져와 OS에서 사용하는 DLL의 인터페이스가 변경된 것이 원인인데, 브라우져를 통해서 OS의 기능을 변경했다는 이야기와 일맥 상통한다.  

하지만 결국, 이러한 전략적인 배포 방법으로 MS는 넷스케이프를 밀어내고, 그 자리를 자신의 브라우져인 IE를 대체하여 버렸다. 그 당시는 MS에서 브라우져 개발을 최우선으로 하고 약 3000명의 개발자를 할당하였었다. 넷스케이프는 약 200명 정도의 개발자들이 참여했었던 것으로 기억되는데, 이러한 공격적인 개발전략으로 넷스케이프는 역사속의 프라우져가 되었다.

최근에 Silverlight 2의 개발이 끝났는데, 역시 마이크로 소프트이다라고 할 만한 방법으로 Silverlight를 배포하고 있다. MS는 윈도우의 자동 업그레이드를 이용하여 패치를 진행하고 있는 것이다. 최근에 지인과 이야기를 했는데, 그는 Silverlight는 Flash에 비해서는 2수정도 부족하다고 평하였고, 상대가 안될거라 이야기를 했었다.
하지만 나는 실버라이트가 기술적 우수성을 떠나서, 전략적인 면에서는 더욱 우세할 거라는 의견에 한표를 실어주었다. 왜냐하면, MS는 어떤 식으로든 실버라이트를 기본적으로 OS에 탑재하여 배포할 것이기 때문이다.

그런데, 그러한 예측이 며칠전 부터 일어나기 시작하였다. 윈도우즈의 Software 자동 업데이트 기능을 이용하여 배포를 시작한 것이다.

이러한 MS의 공세에, Flash와 JavaFX는 어떤 식으로 방어와 수성을 할지 궁금하다.

아래는 며칠전에 내 PC의 자동 Update 되는 과정을 캡처한 화면이다.



Posted by 행복상자
며칠 전에  ZDNet을 통해서 실버라이트의 정식 버전 발표가 입박했음으로 보았는데, 이제는 쉽게 정식 버전이 출시되었다는 기사를 볼수 있다.

Silverlignt의 정식 버전은 PressPress 을 통해서 발표되었다.
이는 또한 며칠전에 Scott Guthrie's의 블러그에도 언급도기도 했는데, 어제는 Silverlight 2 Released 라는 제목으로 새로 글이 올라와 있다.

공식적으로 한국시간으로 10월 15일자로 마이크로 소프트는 Silverlight를 배포하고 있으며, 이는 http://www.microsoft.com/silverlight/ 에서 다운로드 받을 수 있다.

아시다시피 Silverlight는 다양한 Platform을 지원하고 동작하도록 마이크로 소프트에서 서포트 하고 있는데, 이는 기존의 MS의 정책과는 상당히 다른 접근 방법이었다. 하지만, 이는 10년전에 마이크로 소프트가 OS시장을 주도적으로 이끌고 경쟁에서 살아남기 위해서, 많은 Application을 개발할 수 있도록 SDK만을 제공하던 그 때와는 크게 다르다.

구글의 경우만 해도 MS의 브라우져 시장에 대한 지배력과는 무관한 방향에서 사업을 성장시켰으며, 특정 OS와는 무관한 방향에서 사업을 키워나갔다. 검색엔진과 다양한 Application을 여러 Platform에 제공하며서, Beta아닌 Beta 서비스로 사용자 층을 끌어 모으으고 확장하고 있다. 최근에는 Crom이라는 브라우져를 발표하였다.

하지만 역시, Adobe의 Flash가 MS의 행보에 가장 큰 영향을 키쳤을 거랴 생각한다.
다양한 브라우져와 OS에서 동일하게 동작을 한다. RIA를 떠 올리면 Flash로 만들어진 Application을 쉽게 떠 올리게 되는데, 이는 Flash를 통해서 만들어진 Application이 주변에 많기 때문이다. Adobe는 브라우져가 아닌 OS위에서 Flash가 동작할 수 있는 Application을 개발할 수 있도록 AIR와 Flex 3를 제공하고 있다. 이는 Desktop시장뿐만 아니라 Mobile시장까지 확장하려는 Adobe의 의지가 보이는 대목이다.

MS는 이들과 경쟁을 해야 한다. 최근에는 SUN에서 JavaFX의 정식버전을 발표했다.(Mobile지원에 대해서는 슬그머니 빼 놓고 말이다.) 이는 SUN의 JavaFX도 경쟁 상대임을 의미한다.
따라서 MS는 Cross-Platform을 지원해야 하고, Cross-Browser를 지원해야만 한다. 이를 위한 최적의 기술은 바로 Silverlight임을 쉽게 알 수 있고, 개발되고 있는 것이다.

Eclipse에서 Silverlight를 개발 할 수 있는 툴을 만들고 있는 회사가 있다. 이를 MS에서 지원하고 있다.  http://www.eclipse4sl.org/ 를 보면 툴에 대한 설명과 Screen-shot를 볼수 있다. 그리고 여기를 보면 실버라이트의 Step-by-Step 예제가 있다. 

이번에 Silverlight 2.0 에는 새로운 컨트롤이 많이 추가 되었다.


다음은 Silverlight 2.0의 ReadMe Note 인데, 개발전에 한번 꼭 읽어 보면 많은 도움이 될것이다. 설치에 대한 부분과 달라진 점들은 읽어볼 필요가 있다.

 
 

'공부하는 것' 카테고리의 다른 글

6 New ASP.NET Dynamic Data Videos  (0) 2008.11.06
Spring 3.0 Preview  (0) 2008.10.21
Silverlight 2 Released  (0) 2008.10.15
Silverlight 2.0 발표 즈음하여...  (0) 2008.10.15
MS SQL 2005서버에서 유니코드 사용하기  (0) 2008.10.08
Cocoa Programming을 시작하며...  (0) 2008.10.07
Posted by 행복상자

최근에 구글 크롬을 설치를 하였다. 집에서와는 달리, 회사에서는 몇가지 이유로 설치가 제대로 되지 않아서, 설치와 제거를 수 차례 반복하였다. 결국 설치 후 방치해 놓고 사용하지 않다가, 최근에 해결 방법을 찾아서 사용하고 있다.

내가 사용하고 있는 브라우져는, 맥북에서 사파리 3과 Firefox 3, 그리고 윈도우즈에서는 IE6와 7을 같이 사용하고 있다. 대부분 나는 IE를 사용하고 있는데, 이는 금융거래와 인증서 때문이고, 회사의 인트라넷 역시 IE에서만 동작하기 때문이다.

내가 Google의 크롬에 관심을 가졌던 이유는 내가 IE를 사용하는 이유와 동일하다. 최근에 Crom을 발표할 때 한국의 사용자들의 위하여 CROM에서 ActiveX 지원할 거라는 발언을 들었기 때문이다.
크롬에서 지원하는 AcitveX-Plugin은 다음 링크에서 찾아 볼수 있다. (구글 크롬 ActiveX Plugin) 이미 진행되어지고 있는 프로젝트 중에 하나이다.

ActiveX를 사용하는 것은 한국에서만 진행하고 있는 특이한 상황으로 볼수 있지만, 최근의
MS에서는 새로 개발하고 있는 IE 8에서는 웹 표준을 지원하겠다고 공언하고, ActiveX의 지원을 없애거나, 최소한으로 줄이려는 움직임을 보이고 있다.

이는 MS의 지금까지의 ActiveX를 바라보는 관점이 상당히 달라졌다는 반증이다.
아는 사람들은 알겠지만 ActiveX라는 기술의 탄생은 계획보다는 우연에 가깝다. 약 10년전에 자바 진영에서 Java Applet를 가지고 나와 웹을 동적으로 만드는 기술을 내 놓았을때 MS는 자신들이 가지고 있는 기술중에 가장 이와 유사한 기술을 가지고 내 놓은 것이었다. (사실은 OLE 또는 COM 기술이었다.) 이는 MS의 OS인 윈도우의 리소스를 쉽게 사용할 수 있었끼 때문에 개발 생산성과 효율성은 아주 높았다. 사실 웹 브라우져는 단지 COM 기술의 Container 역할만 할 뿐이었다.

이때 까지마 해도, 자바는 속도가 아주 느리고, 낮은 사양에서는 사용하기 어려운 기술이었기 때문에 개발자들이 선듯 내세우기 힘들었다. 반면 MS는 많은 Intranet환경에서 ActiveX를 이용한 솔루션이 개발되고, 만들어지면서 IE의 사용율을 높여갈 수가 있었다.

MS가 새로운 브라우져에서는 표준을 지향한다고, 이야기 하고 Vista를 비롯하여 IE8에서는 ActiveX의 지원을 하지않겠다고 공공연하게 이야기 하고 있다. 우리나라와 같이 AciveX를 많이 사용하는 나라에서는 갑작으로 방향 전환에 도무지 이해가 안하는 상항인데, MS의 입장을 알면 이해가 되는 부분이다.

최근 몇년 사이에 이러한 것(ActiveX)들을 대체할 수 있는 기술들이 나타나기 시작했는데, 이들은 어느새 웹 개발자들 사이에 표준처럼 사용되고 있기 때문이다.  Ajax와 Flash가 이들을 대표한다고 할 수 있다. 그리고 새로운 브라우져들이 MS의 시장 점유율을 눈에 띄게 줄이기 시작했다. (Firefox, Safari...)
Adobe의 Flash의 경우는 모바일과 윈도우 Application 영역마져도 침범하고 있다. Flash의 경우는 MS의 ActiveX와 마찮가지로 IE를 단지 컨테이너로 밖에 생학하지 않는 독립적을 Architecture를 가지고 있기 때문이다.

그리고, 이제는 웹과 Application의 경계마져도 허물어지고 데스크탑과 모바일의 경계마져도 허물어지고 있는 시점에 다달았고, 이에 부응하여 새로운 패러다임의 전환과 새로운 수익원을 찾아야 하는 때가 되었기 때문이다.

그러면 왜 AciveX를 버리려고 할까?
MS는 윈도우즈를 살리기 위해서 MS-DOS 버려야만 했다. 사람들이 새로운 제품으로 이동하지 않는다면, 윈도우즈가 살아남을 수가 없기 때문이다.
이와 유사하게 Silverlight가 살기 위해서는 ActiveX를 버려야만한다. 지금의 ActiveX는 오르지 윈도우와  IE에서만 작동을 하고 있기 때문에 새로운 패러다임에는 맞지 않는다.

제품의 라이프 사이클이라는 측면에서는 새로운 기술이 적용된 제품이 나오면, 자연스럽게 기존 제품이 사라져야 하지만, ActiveX의 경우는 결코 쉽지 않다. MS의 입장에서는 기존과 마찮가지로 그대로 유지하기에는 사용되는 비용도 결코 만만치 않기 때문에, 결국은 ActiveX를 죽일수 밖에 없다.

며칠 전에 Silverlight 2의 발표가 임박했다는 기사를 보았었다.
개인적으로는 Silverlight는 MS에서 방향을 잘 잡았다고 생각을 하고, 이전 보다 Open된 Platform의 모습을 갖춰가나고 있다고 생각한다. Ruby와 Python과 같은 Dynamic language를 지원하는 것을 봐도 .Net Framework 1.0을 발표 할 때와 사뭇 다른 태도를 보이고 있다는 것을 알 수가 있다. (그때는 수많은 VB 개발자들과 지지자들을 너무나도 쉽게 버렸었다.)

그리고, 기대를 하고 있다. 개발 생산성을 바라지는 않지만,  앞으로도 많은 기능 개선과 개발자 지원으로 인터넷 비쥬얼 베이직으로 자리잡을 수 있기를 바란다. Silverlight 2의 새로운 컴포넌트를 보면, 마치 Visual basic의 툴 컨트롤이 연상이 되기 때문이다.
(Visual Basic은 내가 좋아하는 개발 툴이어서 애착이 많이 간다.)



'공부하는 것' 카테고리의 다른 글

Spring 3.0 Preview  (0) 2008.10.21
Silverlight 2 Released  (0) 2008.10.15
Silverlight 2.0 발표 즈음하여...  (0) 2008.10.15
MS SQL 2005서버에서 유니코드 사용하기  (0) 2008.10.08
Cocoa Programming을 시작하며...  (0) 2008.10.07
Spring Dynamic Modules 1.1.2 Released  (0) 2008.10.05
Posted by 행복상자

며칠전에 스캇 구슬리의 Blog를 통해서 Silverlight 2의 RC버전이 릴리즈되었다는 소식을 접하였었다. 기존의 Beta2를 RC버전에서 Update할 수 있는 방법들이 포함되어 있다.

Soft Architecture를 설계를 할때 가장 중점을 두어야 할 부분은 바로 버전 상호간의 호환성과 수정시에 영향을 최소한으로 줄이는 것이다. 물론 정식 버전이 아니기 때문에 개발자들의 이해할 수 있는 범위는 크지만, 이 역시 상품화를 염두에 두고 있다면 항상 생각해야 되는 문제이다.

Silverlight RC버전에 대한 사용은 다음의 링크를 참고 하면 된다. (Silverlight RC 버전
위 링크 페이지를 열고서 가장 유심히 보아야 할 부분은 Breaking Changes 다큐먼트이다.
이 문서는 Beta 버전과 RC버전간의 달라진 부분들에 대해서 정의되어 있다. 만약 Beta버전을 통해서 이미 개발하고 있는 모듈들이 있다면, 유심히 보아야 한다.

스컷 구슬리의 블러그를 통해서 공개된 몇가지 새로운 번화들을 이야기 하면, 이번 RC 버전에는 몇가지 새로운 컨트롤들이 추가되어 발표되었다. 이는 몇달 후에 나올 최종 버전에 포함될 많은 새로운 컨트롤들의 일부분이다.

아래 소스코드는 이번의 추가된 컨트롤들을 사용할 수 있는 컨트롤들의 사용에 대한 소스코드이다. 보는 바와 같이, PasswordBox와 ProgressBar 그리고 ComboBox에 대한 태그들을 정이 되어 있다.



아래 이미지는 위 코드를 이용하였을 때, 화면에 표시되는 컨트롤들의 모습이다.







아직 Silverlight의 최종 버전이 출시되기까지는 시간이 필요하지만, RC버전은 최종 버전에 근접한 버전이다. 실버라이트를 이용한 개발을 하고 싶다면, 지금 부터 준비한다면 출시후에 아무 무리없이 사용이 가능할 것이다. 새로운 기술이지만 새롭지는 않다. 하지만 예전에 비쥬얼 베이직이 버전 5에서 부터 많은 개발자들에게 사랑 받았던 것을 기억한다면, Silverlight 2는 시도해 봄직하다.

Posted by 행복상자

지난주 화요일은 삼성역 그랜드 인터컨티넨탈 호텔에서 열린 한국 아도비의 제품발표회에 참관차 관람하였다. 제품 소개와 세미나였지만, 솔직한 느낌은 제품소개 측면이 강했다. 기대한 것보다는 수준이 높지는  않았다. 하지만, 세미나에 관심을 가지고 참관한 참가자들이 반드시 개발자가 아니라는 측면을 보면(디자이너들이 상당히 많았던거 같다) 이해가 간다.
여기 저기시 자바 관련된 용어와 기술 설명이 나오면, 이해가 안간다는 말이 들렸다. 좀더 참관자들의 수준을 배려할 필요가 있지 않았나 하는, 지극히 개인적인 의견이다.

그럼에도 불구하고, 정말 놀랐던 것은, 정말 많은 사람들이 관심을 가지고 찾아 왔다는 것이다. 홀 규모는 약 1500명 정도일것 같은데, 2000명 정도가 찾와와서, 준비된 자리가 없음에도 뒤에 서서 키노츠와 제품 소개를 들고, 세미나를 참석하는 열정을 보여주니 말이다. 최근 내가 갔던 행사에서 이정도로 관심이 집중된 것은 몇개 안되는것 같다.

내가 이 세미나를 참관한 목적은 당장의 필요는 적었지만, Web 기술이 어는 정도 성숙한 현 시점에서, 가장 주목 받는 RIA 기술중에 하나라는 측면에서 Adobe의 기술들을 이해하고 싶었다.

Web 기술이 성숙했다는 측면은, 현재 웹 브파우저을 이용한 Data 전송 방법과 동기화 기술  그리고 윈도우 Application과 유사한 서비스의 제공을 들 수 있다. 그 대표적인 예가 구글이고 Ajax를 이용해서 구글에서 만들고 배포한 여러 웹 Application들은 네트워크 연결이 안되거나, 끊어지더라도 지속적으로 서비스 제공하고, 동작하는 기술로 한층 없그레이드 되고 있다. (구글 Gears 참조)
기술이 성숙 되면, 다양한 응용 프로그램들이 나오게 되는데, 결국은 사용자를 위한 UX 측면에세 차별화가 되기 시작할 것이다.

행사를 참여한 여러 회사의 데모를 보았는데, 그중에서 국외는 eBay, 국내는 농협의 Banking System 과 현대 자동차의 상황판 시스템이 인상적이었다.
- eBay Dask top(http://desktop.ebay.com/)


사용자 삽입 이미지


AIR은 Adobe Flash Player의 확장판이으로 보면 쉽게 이해가 된다. 웹브라우저와 PC에 종속되지 않고 독립적으로 Flash 파일을 수행한다고 생각하면 된다. 이는 모바일과 인터넷이 연결되지 않은 환경에서도 동작이 가능하다. 그리고 네트워크가 연결되면, 서버와 데이터 싱크를 할 수 있는 엔진과 Embadded DB를 포함하고 있다. Embadded DB는 Sqlite가 사용된다.
그리고 Flash Player와 가장 큰 차이점 중 하나는 Local 시스템(PC 또는 모바일 기기)의 파일 시스템이 Read/Write가 가능하다는 점이다. 그리고 AIR가 설치된 어떤 OS에서도 사용이 프로그램이 코드 변경 없이 사용이 가능하다.

Flex 3.0은 이를 위한 개발툴이다. (정확하게는 Flex Builder)  Flex 제품군은 서버용 제품들이 여러가지 있다. 그러나 가격이 비싸서 프로젝트에 적용하지는 못했었는데, 요즘은 그 대체 기술들이 많이 나오고 있고, 또 Adobe에서도 이를 위한 기술을 일부 지원하기도 한다.
Flex에 대한 라이센스 정책은 사실 잘 모르겠다.
Adobe의 김 백수 전무에게 물었더니, Flex Builder 3.0을 사면 된다고 했는데, 정말 배포에 대한 추가 라이센스가 없는지 명확하지가 않았다. (지금은 다른 부서 사람인데 Flex 2로 개발 중인 책인 개발자 한명이 이 때문에 어려워했던 기억이 있어서, 확인차 물었었다. 사실 이거 확인하는 것도 나의 참관 이유중 하나였다.)

새로운 것을 배우는 것이 즐거운 이유는 여러가지 호기심이 생기기 때문일 것이다.
반드시 신기술이 좋다고는 할 수 없지만, 사람들의 관심을 끌지 못하는 기술은 아무리 시대를 앞선다고 해도, 사라질수 밖에 없다.

그런 의미에서 이번 행사에서 많은 관심을 끈 Adobe AIR와 Flex는 향후 어떤 모습으로 개발자와 디자이너에게 그리고 사용자에게 다가갈지 귀추가 주목된다.

Posted by 행복상자