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

내가 사용하고 있는 브라우져는, 맥북에서 사파리 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은 내가 좋아하는 개발 툴이어서 애착이 많이 간다.)

올초에 한글만 지원하던 프로젝트를 다국어 버전으로 만들기 위해 몇가지 작업을 하였는데, 그중에서 제일 까다롭지만, 쉽게할 수 있었던 것이 DB에서의 처리이다. 사실 이 부분들을 위하여 이미 MS SQL은 데이터 타입이 정의되어 있다. 
단지 필드만 재 정의해서 사용하면 되는데, 아래 표의 내용을 참조해서 사용하면 된다.
아래의 내용은 MSDN에 정리되어 있는 내용들이다.
(http://msdn.microsoft.com/ko-kr/library/ms175180(SQL.90).aspx)


자세한 내용을 위의 내용들을 참고해서 찾아보면 도움이 될것이다.

드디어, 어제 신청했던 책이 오늘 도착하였다. 사실 회사에서 어제 원서를 빌려서 잠시 읽었는데, 원서는 쉬운 영어로 정확한 표현들, 쉬운 표현들을 사용하여여 읽기에 큰 무리가 없을 것 같다.

요즘 회사에서 내가 하고 있는 프로젝트는 OSGi와 Spring DM을 이용하여 Framework를 만드는 것이다. 하지만, 사람들이 바라보는 것은 Common 모듈을 만든다고만 생각을 한다. 그리고, 지원 할 수 없는 기능은 구현이 불가능하다고 단정하는 사람들도 가끔 보인다.

사실 보이지 않는 것은, 사람들은 느끼지도 믿으려하지 않는다. 그래서 가끔은 닥쳐야 일을 하기도 한다. 어떠 어떠한 프레임워크가 좋다라고 하지만, 실제로 사용하지 않으면, 그 두꺼운 레퍼런스는 그 효용성이 떨어질거다. 이는 개발자에게는 무용지물이라는 생각을 들게 만들지도 모른다.

오늘 도착한 책의 역자 서문을 읽다보니 이러한 글이 있어서, 잠시 내가 하고 있는 일과 프로젝트를 되돌아 보았다.

코코아 프레임워크 전체를 책에서 하나 하나 설명한다면 그 책은 단순히 프레임워크 레퍼런스가 되고 말것입니다.

단순하지만, 저자가 책을 쓴 목적이 명확히 들어나 있다. 그리고 책은 예제와 많은 그림들이 들어 있다. 원서에는 믿고 따라오라는 저자의 강력한 메시지가 있었는데, 기억은 나지 않는다. 암튼 새로 오늘 받은 책이 마음에 든다.

같이 공부하는 다른 사람들과 조만간 Workshop도 한번 계획해 보아야 겠다.

Spring DM 1.1.2 버전이 Released 되었다. 1.1.1 정식 버전이 나오고서 2달만에 1.1.2버전이 나왔는데, 그 빠름에 놀라움을 금치 못한다.

사실 내가 이 이야기를 하는 것은 내가 회사에서 미국의 연구소의 개발자와 같이 Spring DM을 이용한 OSGi 관련된 일을 하고 있기 때문이다. 이는 개발적인 측면에서는 많은 부분을 정리해야하는 새로운 분야이고 또한 안정성이나 상품화 측면에서 많은 우려스러움을 블러올 수 있기 때문에, 한참 진행하고 있는 프로젝트에 새로운 버전의 Library를 집어 넣거나 변경하는 것은 신중에 신증을 기해야 한다. 왜냐하면 Spring DM 1.1.0과 1.1.2는 여러 부분에서 개선이 되고, 변경이 일어나고 있기 때문이다.

최근에 미국의 같이 일하는 미국인 개발가 1.1.2 M1으로 라이브러리들을 변경한 적이 있는데, 기존 코드의 수정이 일어나는 중대한 일을, 그는 아무런 이야기가 없이 변경해 버렸다. 내가 이를 보고 그에게 원인이 뭐길래 변경했냐고 물었더니, 새로이 Spring DM에 추가된 기능이 필요했다는 것이었다. 그래도 개발하는 중간에 갑자기 M1정도 되는 버전으로 바꾸면 어떻하냐?, 개발 기간이 이제 2달 여 밖에 남지 않았는데, 그는 11월 말에 1.1.2 버전이 릴리즈 될거라고 이야기 했다.

아무튼 그때, 갑자기 라이브러리 변경을 하지 말라는 주의를 주었는데, 그가 예상했었던 11월보다 1달이상은 빠르게 릴리즈 되어서 정말 놀랐다.
이는 아마도 Spring dm server의 영향일 것이다. 예전에는 Application Platform이라는 이름으로 공개되었는데, 최근에 보니 Spring dm server라는 이름으로 발표되었다. SpringSource dm Server 1.0.0 이 최근에 공개된 버전이다. 이의 개발로 인하여 빠른 버전 Change가 일어나고 있는 것 같다.

아래는 1.1.2에서 변경 수정된 내용들이다. ( Change Log참조)
Changes in version 1.1.2 (2008-10-03)
-------------------------------------

General
* improved sample wars packaging
* various minor documentation improvements

Package org.springframework.osgi.context
* added reporting of Errors raised during delegated refresh in AbstractDelegatedExecutionApplicationContext

Package org.springframework.osgi.extender
* fixed bug related to enabling Spring-DM annotation depedency processing
* improved annotation injection processing
* improved extender configuration thread-safety
* fixed potential race condition in asynchronous waiting for service dependencies

Package org.springframework.osgi.io
* improved existence check for bundle resources
* improved jar space pattern matching when the root is not specified
* fixed classpath pattern matching on certain resources when the default Bundle-ClassPath entry (.) is not specified
* improved file resolving under Equinox

Package org.springframework.osgi.service
* changed the proxying classloader strategy to address package dependency visibility
* fixed usage of incorrect class loader for imported services with client thread context class loader management
* fixed intermittent deadlock that appeared in some cases betweem importers and exporters during shutdown
* refined single service proxies so that any waiting activity is interrupted on destruction
* improved single service proxies to allow settings update at runtime

Package org.springframework.osgi.web
* improved web extender configuration thread-safety
* improved web extender initialization by using an asynch model for cases with out-of-order dependencies