케텔과 AOL이 사라진 이유를 모르는... 이동통신사들...

분명... '공룡'이라 불릴만한...
그들이 시대를 주름잡던 시대가 있었다.

'컴퓨서브'로 천하를 주름잡고...
'케텔'로 통신시장을 주름잡던...
그런 시대가 있었다.

하지만...

'참여'를 중심으로한 인터넷 환경에...

'컴퓨터브', 'AOL'이 몰락하고...
국내의 상황도 '케텔(하이텔)', '천리안'도 마찬가지로...
그 시대와 함께 운명을 같이 한것이다.

그런데...
당시 '하이텔'이 몰락한 이유는 아주 간단했다.

사용자들로부터 받는 Telnet관련 통신비용 1인당 7천원~3천원의 '사용료'에 대한
유혹에서 벗어나지 못했기 때문이다.

그런데...
이제는 '참여'의 시대를 지나..
'오픈마켓'의 시대가 도래했고.

iPhone이나 안드로이드는...
절대 다수의 개발자들에 이익을 돌려주는
'오픈마켓'환경으로 시대가 변하고 있다.

이제는 '컨텐츠'의 '이익'에 빠져든
국내의 이통통신사들 또한...
그러한 '공룡'의 시대를 맞이하게 될것인가?

그나마..
비슷하게 흉내는 내고 있습니다.

LG 개발자 네트워크 ( http://developer.lgmobile.com )
삼성 모바일 이노베이터 ( http://innovator.samsungmobile.com )

하지만...
NDA조항까지..
독소조항 까지 없는

iPhone ( http://devloper.apple.com/iphone )

자...
과연 '개발자'들의 마음을 얻고..
그 '개발자'들과 공존할 마음이 있는 곳은 어디일까요?

과거 '참여'의 시대에...
그 '참여'에 같이 공조하지 못한 회사들은 이미 이 시대에서 보이지도 않습니다.

이제 '참여'와 '오픈마켓'의 시대에서...
과연 국내 개발사나 이동통신사들은 어떠한 정책으로써
'개발자'들과 호흡할까요?

마치...

iPhone만을 막으려고 애쓰는 모습은...
과거 쇄국정책을 사용하던 그런 모습을 보이는 것 아닐까요?

현재와 똑같은 정책을 계속 고수한다면...
국내의 이통통신사들과
휴대폰을 만드는 회사들의 운명도...

결국은...
과거의 '공룡'이 되지 않을까 합니다.

오픈소스 개발이 성공하려면...

많은 개발자들이 오픈소스 기반의 지식에 도움을 받고 있고...
그러한 오픈소스 프로젝트에 참여하고픈 욕심은 생기지만...
뚜렷한 방향성없이...

찻잔속의 태풍이거나...
머릿속에 맴돌다 끝나는 경우가 많다.

특히나...
우리나라 개발자들의 경우에는 더더욱 힘이 든다.

수많은 오픈소스개발과
엄청난 지적 재산이 공개된...

http://sourceforge.net/

그 영역의 방대함과...
그 동안 문을 닫은 컴포넌트 회사들의 소스까지 오픈되어 있는...
정말 진정한 의미의 오픈 소스 공간인듯 하다.

개발경력이 좀 되고...
이름이 좀 알려진 사람들의 경우에는...
누구나 한번쯤 자신이 오픈소스를 시작해서 운영해보면 어떨까하는 욕심이 생긴다.

그러한 마음을 가졌다가도...
많은 현실속에서 그 꿈을 닫아버리는 경우가 허다하다.
그렇다면...

오픈소스 개발에 성공하려면 어떻게 해야할까?
그것도...

꼭... 소스포지가 아니라..
우리나라의 까페나 인터넷 환경에서?

1. 정말 흥미있는 소재여야 한다.

누구나 다 만들어 본듯한 것들... 비슷 비슷한 소재가 아니라.
아주 색다른 소재여서..
그 소재에 호감을 가지는 사람들이 한둘 이상 모여야만
그 프로젝트는 꾸준하게 진행할 수 있다.

2. 가능하면 '언어'영역부터 공략하라.

PHP와 Ruby와 같은 언어들은 그냥 탄생한 것들이 아니다.
한 사람의 창조자가 끊임없는 자신의 개량과 달굼질 속에서 완성된 것이다.
우리나라 최초의 '언어'를 오픈소스 형태로 진행할 멋진 사람은 언제쯤 나타날까?

3. 일단 '영어'는 잘해야 한다. ~.~

좁디 좁은 국내 개발자들과 협업하는 것은 정말 힘이 듭니다.
왜냐구요? 사회 여건상 소프트웨어 개발자들이 여유롭게 오픈소스에 참여하는 사회적인 기반이 되어 있지 않기 때문에... 외국계 개발자들과 협업해야 하는데... 그 의사소통의 가장 기본은 '영어'이기 때문이죠.

4. 최소 1년 이상 자신이 환경을 만들어야 한다.

누가 시켜서가 아니라...
내가 좋아서 하는 일이어야 합니다.
Linux와 같은 거대한 플랫폼도...
자그마한 커널을 만들면서 시작했습니다.

~.~

자그마한 것 부터 알차게 준비하다보면...
언젠가는 그 결과를 볼 수 있지 않을까요?

5. 욕심을 버려라..

다시 한번 생각해보세요?
오픈프로젝트를 진행하면서 얻고 싶은 것이 무엇인지?

'명성'?

만일 '명성'을 원하신다면...
오픈 소스프로젝트를 진행하는 것을 말리고 싶습니다.

차라리...
그 정도 공을 커뮤니티나 '책'을 쓰는데 몰두 하시는 것이
훨씬 성과도 좋답니다.

오픈 소스 프로젝트를 통해서 명성을 얻은 분들을 살펴보면...
자연스럽게 얻게 되는 것이지.
그 분들 자체가 '명성'을 목적으로 시작한일은 아니라는 것이죠...

~.~

마지막으로...

오픈소스프로젝트를 꼭..
내가 만들 필요있겠습니까?

http://sourceforge.net/

소소포지에 가보세요...
정말 많은 프로젝트들이 진행되고 있답니다.
그 공간에 같이 어울릴 수 있는 곳을 찾는 것도
의미가 크답니다.

꼭 내가 아니더라도...
같이 어울릴 수 있는 그런 멤버들을 만나는 경험...

한번 느끼고 싶지 않으신가요?

~.~

IE8의 의미는... 악몽의 IE6은 잘못되었다고 시인하는 것뿐...

웹쪽의 프로그래밍이나 작업을 하는 사람들에게 가장 큰 난관이 하나 있다.
그것은...

넘을 수 없는 커다란 태백산맥!
바로...

IE6...

Explorer 6 버전이다.

가장 비표준으로 만들어진 이 IE6의 환경은 정말로 극악의 브라우져였다.
소위...
크로스 환경을 만든다고 만들어 보면...

유일하게 반항하는 넘이~~~
바로 이 IE6이다.

IE6은 2001년 8월에 정식으로 릴리즈되고 5년동안 세상을 지배(?)하다가...
2006년 10월쯤에 출시된 FireFox에 긴장하며...
2006년 11월 바로 IE7을 출시하게 됩니다.

그런데 잠 재미있는 것은 2001년부터 그후 시대는...
윈도우즈 XP의 전성시대로써...
거의 대부분의 사용자들은 IE6이 당연한 지배적 브라우져이기 때문에...

이 사실상의 표준인 브라우져에 맞추어서 작업을 하게되고...
그 시대에 가장 많은 홈페이지(?)를 구축한 대한민국의 환경은...

IE 표준 정도가 아니라...
거의

IE6 표준으로 환경을 구축했다는 점이 문제입니다.

머... 이제 IE7, IE8을 만들어도...
IE6의 환경을 지원해야하는지 말아야 하는지도 고민거리이니...
ㅋㅋ

전세계에 퍼져있는 Windows XP를 모두 수거하기 전에는...
해결이 안될 문제죠.

좌우당간...

MS도 IE6의 실수를 진즉에 인정하고 진즉에 IE7을 발표했으면 좋으련만...
아마도...
자신들의 브라우져간의 싸움이 IE6과 IE8과의 싸움이 될터인데...

사실상...
브라우져의 보급률을 비교해보면...

현재 점유율에서는 사실상 FireFox가 대세라고 해도 과언이 아닙니다.
그 이유는...

[출처 : MarketShare ]

여기서 단순하게 그림만 놓고 본다면... IE가 67%, FireFox가 21%로 나옵니다.
이 그림을 버전별로 살펴보면...

[ 출처 : http://marketshare.hitslink.com/report.aspx?qprid=3 ]

IE7은 47.32%, IE6은 18.85%
FireFox 3.0은 19.11%, FireFox 2.0은 2.27%로써...

IE 점유율은 시간이 지날 수록 IE7은 거의 현상을 유지한체로...
IE6의 시장만 줄어들고 있습니다.
그 자리를 FireFox가 차지하고 있다고 봐야겠죠?

이번에 IE8은 이러한 IE6이 줄어드는 자리를 메우기 위한 하나의 수단으로 보이는데...
과연 시장의 선택은 어떤식으로 결론이 날까요?

정말 흥미진진한 전개가 아닐 수 없습니다.

~.~

브라우져들의 재격돌... 꿈꾸는자가 끄적거려본 UI설계 철학들...

어제 전세계적으로 IE8 버전이 정식 출시되었다는 소식에...

문득, 제 PC를 살펴보니.

와우~~ 브라우져 3종을 다 쓰고 있었네요...

( 사실.. 이렇게 다 쓰는 이유중에 하나가 IE7의 대책없는 뻗음 때문이라는 사실도... )

Google 크롬은 1.0.154.48 버전...

Safari는 4 Public Beta(528.16)...

그리고, IE는 좀전에 업그레이드 해서

Ie 8.0.6001.18702

재미있는 것은 브라우져들이 각자 비슷하면서도...

또 다른 모습들...

가장 최근.. ( 머.. 어제 나왔으니.. ) IE8을 살펴볼까요?

탭에 배치된 무수한 기능들... 역시.. MS는 기능하나로 뭉치기는 참 잘한다는...

역시나 다운로드 받고 설치후에 윈도우즈를 다시 시작하면서 상당히 많은 넘들을 설치한다는...

( 머, 루머로는 MS가 다른 브라우져의 속도를 떨어틀이는 기능까지 새롭게 보강한다는 웃기지도 않는 이야기도 돌지만.. ~.~ )

좌우당간... 탭에 기능배치는 참 많이 합니다.

일반 PC에서는 화면이 넓으니.. 상관없겠지만, 노트북과 같은 혹은 넷북과 같은 작은 화면에서는 번거롭죠...

하여간 MSN로그인을 비롯한 잡다한 서비스들을 모두 한 곳에서 불러 볼 수 있으니...

그것은 장점에 해당되겠네요.

그리고,,, 요즘 가장 꿈꾸는자에게 마음을 들게한 Safari...

깔끔한 구글의 디자인을 잘 받아들인...

뉴페이스죠.

속도는 정말 최강인듯합니다. 화면의 디스플레이하는 것은...

다른 어떤 브라우져보다도 ...

그리고...

구글크롬의 장점은 역시.. 깔끔함...

군더더기 없는 기능이 없는... 심플한 브라우져 자체의 강한 모습이 보이고...

자 다른 것은 모르겠습니다만...

IE의 모든 탭기능을 꺼버린 상태에서 3개의 브라우져의 최소치를 볼까요?

저는 다른 것은 모르겠지만, 화면에 배치되는 사이즈를 가장 중요시합니다.

아마도, 그러한 것이 개발사가 사용자들을 얼마나 이해하고 만들었는지에 대해서 가장 많은 것을 판단하게 하는 기준이 아닐까요?

크롬, IE8, Safari의 순서입니다.

분명, 크롬의 공간이 가장 적습니다. 그리고, 사파리, IE8의 순서인데...

윈도우즈의 캡션부분을 크롬과 Safari는 가능한 크기를 줄인데 비하여, IE8은 기존의 표준을 지키고 있어서 벌어진 차이가 아닌가합니다.

이러한 UI의 설계 사상은 화면을 Max했을때에 좀더 확연하게 구분됩니다.

구글 크롬의 경우에는 윈도우즈의 기본캡션은 사라지고 탭이 가장 상단에 배치된 상태로 변하고, 주소창이외에는 보이지 않는 가장 큰 공간을 배치해줍니다.

아마도, 이러한 설계 사상은 이후로도 변하지 않을 것으로 보이죠.

그리고, 윈도우즈 IE8은 자신들이 만들어 놓은 윈도우즈의 기본표준을 어길 수 없겠죠?

역시, 캡션과 주소창, 그리고, 탭... 아마도, 자신들의 표준에서 표현할 최소한의 것들이라고 보입니다.

즐겨찾기와 같은 전통적인 것들을 상단에 배치한것도 그러한 이유가 아닌가 합니다.

그럼, Safari는 어떨까요? 이번에 새롭게 업그레이드된 Safari는 구글의 캡션부분의 탭영역에 대한 디자인을 받아들이는 유연함을 보였다고 할까요? 하지만... 확실하게 구글의 UI철학보다는 좀더 회사틱(?)한 느낌이 보이는 점을 보이고 있습니다.

다른 기능들에 대해서는 워낙에 많은 분들이 서술하고 있는 점들이 많아서리.. 저는 그런 부분에 대한 글은 빼고..

그냥, UI의 설계 철학에 대한 내용들을 살펴보았습니다.

총평을 내자면...

IE8은 자신들이 기준과 표준을 만들고 있다는 생각을 아직 버리고 있지 못하고 보입니다. 그 고집스러움이 결국, 이러저런 서비스들을 뭉쳐놓는 복잡함을 가중하고 있다는 안타까움을 가지게 한다고 할까요?

Safari는 분명 디자인을 전문적으로 전면에 내세우고, 타 회사의 장점마져도 흡수하려는 혁신적인 생각을 설계사상으로 가지고 있다는 점은 정말 놀랍다고 생각하지만, 역시... 자신들이 세운 기준에는 순응하는 조금은 안타까운 마음이 보입니다.

크롬은... 일단, 파괴적인 깔끔한 디자인... 어찌보면, 미니멀리즘 적인 입장에서 본다면, 크롬과 같은 디자인이 스티브잡스를 통해서 표현되었어야 하지 않을까 합니다. 아마도, Safari는 스티브잡스가 직접 컨트롤하는 것 같지는 않는것 같다는... 그런 생각을 가지게 합니다.

머... 꿈꾸는 자의 취향으로 본다면...

Safari에 구글 크롬 처럼 최소화 할 수 있는 기능정도만 제공해준다면 가장 좋겠습니다.

~.~

클라우딩의 환상에 너무 빠져들 필요는 없다. 다만, 필요한 곳에 쓸뿐...

IT세계에 오랫동안 있으면서 느끼는 점은... 이곳도 세상살아가는 수 많은 다양한 방법의 이야기들이 무수하게 전해지고 이야기가 되고 있다는 점이다.

그리고, 이 곳에서도 유행이라는 것이 존재하고, 스타일이라는 것도 있고, 문화로 만들어지거나 특정 영역에서만 존재하는 법칙이나 규칙, 문화등이 아주 세분화되어 있기도 하다. 전반적인 시류를 꽤뚫는 철학적인 바탕까지, IT세계에는 사업적인 것과 사람, 사회까지 철학적인 배경으로 문제를 해석하는 방법까지 이제는 인간사회의 한축으로 크게 성장한것 같다.

어제도 구글과 결합한 세일스포스닷컴과 IDC Korea가 주관한 '클라우딩 컴퓨팅 컨퍼런스 2009'에 다녀왔다. 나름 흥미있는 소재들이고 그 역활과 담당해야할 한 축의 미래에 대한 여러가지 이야기들이 나와서 아주 즐거운 시간이었다.

다만... 어떤 신개념이건 이야기되어지는 철학적인 내용이건... 그 환상에 너무 빠져들 필요도 없고, 다만.. 호기심있게 그것들을 바라보는 시선정도는 많이 필요하다는 것을 느낀다.

국내의 IT환경을 약간 외부의 시선으로 바라보면, 너무 유행에 민감한 측면들이 보인다. 물론, 여러가지 이유와 시장의 여건들이 있겠지만, 꿈꾸는자가 생각하는 가장 큰 이유는, 시장의 협소함으로 인한, 유행의 창출과 시스템 갈아업기와 같은 영업적인 시선등의 복합적인 대한민국 IT의 고질적인 병폐까지 많이 뒤섞여 있는 편입니다.

그나마... 요즘은 엉터리 전문가들이 잘못된 기술이나 철학적인 배경들을 국내에 전파하는 경우는 많이 줄어들었습니다. 모두다 인터넷이 발달해서 그런것이니... ~.~ 정말 다행이죠.

어제도 컨퍼런스가 끝나고, 몇가지 나온 질문중에서도 아주 오래된 고전스타일의 질문... 대표적으로 ASP와 클라우딩의 차이점이나, 용어에 대한 혼란등...

저도 몇가지 질문하고 싶었지만, 너무 공통적으로 궁금해하는 내용이 아니라는 생각에 굳이 질문을 하지는 않았습니다. ~.~

자.. 그렇다면, IT 아키텍트 일을 하고 있는 저의 입장에서 바라본 클라우딩에 대한 작은 끄적임을 끄적거려볼까요?

~.~

저는... 클라우딩의 미래에 대해서는 어느정도 공감합니다. 그리고, 그 유용성에 대해서도 정말 생각의 발상이라는 측면과, 세일스포스닷컴이 준비한 그 비즈니스 모델을 적극적으로 저의 비즈니스 영역에 사용하고 싶다라는 생각을 하게 합니다. ~.~

다만, 전체 시스템을 모두 클라우딩으로 가져갈 필요도 없을 뿐... 적절한 분석과 배치를 통해서 클라우딩을 필요 서비스의 위치에 배치하게되겠죠. 하지만, 그동안 전통적으로 구축한 시스템과의 연계성이 더욱더 중요해지고, 신규 서비스의 확장에 대해서도 좀더 많은 고려가 될 것으로 보입니다.

이번에 세일스포스의 포스닷컴에서 Facebook과 연계되는 내용을 보고서는 나름 즐거운 생각이 들었습니다.

머랄까요? 내부 정보시스템과 웹2.0의 만남.. 그리고 소셜네트워크와의 접목등을 풀어 낼 수 있는 매쉬업 세상에 대한 재미를 느꼈다고 할까요?

그리고, 오픈소스의 미래의 정점과 그 시장의 유료화 모델로써의 모델과 구글앱스와의 연계성, 구글기어스등의 프레임워그와 실 서비스의 결합된 모습들... 프로토타입모델을 적극적으로 시도할 수 있는 것까지... ~.~
정말 즐거운 상상과 해당 서비스를 조합하고 있는 제 머릿속을 그려보면... 대단히 행복한 시간이었다고 할까요?

머.. 꿈꾸는 자의 생각은 그렇습니다.

정보의 흐름을 내부 조직간의 흐름만 고려하신다면 굳이 클라우딩까지 가지 않아도, 현재까지 만들어진 수많은 개념이나 솔루션등을 통해서 그리 어렵지 않게 시스템을 구성할 수 있습니다.
하지만, 외부의 흐름과 고객의 흐름, 그들과 연동할 수 있는 정보 흐름까지 고려한다면...
클라우딩의 개념을 어느정도 선까지는 정보시스템의 구조설계에 반영하는 것도 충분한 고려사항이 된다는...
그런 끄저거림을 해본다고 할까요?

클라우딩은 미래라기 보다는...

그 미래를 가지 위한 또 하나의 디딤돌의 역활을 할 것으로 생각되어집니다.
단순하게 내 시스템의 흐름을 다른 곳과 유동적으로 유통할 수 있는 생각의 발상전환을 하게 하는
중요한 수단이 아닌가 하는 생각도 듭니다.

~.~

머... 결론적으로는...

필요한 곳에 배치되는 것은 해당 정보시스템의 컨셉이나 철학에 맞다면...
그 위치에서 살아남겠죠.
그리고, 중요한 역활을 할 것이구요.

소프트웨어 개발자 신고제도??? 차라리.. 개발자들이 따로 평가하자!

머... '삽'을 좋아하시는 어떤 분과...
이번에 시행된다는 '소프트웨어 개발자 신고'제도...
그 전에도.. 끄쩍 끄적 글을 써서 그 문제점에 대해서 이야기했었는데...

오늘 그 내용들을 자세하게 살펴보니...
정말 웃기는 것이 하나둘이 아니군요.

'근무경력확인서'와 '기술경력확인서'라는 것이 필요한데...
이 넘들의 서류에...
별~~ 확인절차들을 다 거쳐야 하네요.

그것도...
각 개발자들이 알아서!!!

ㅡㅡ;

http://es.sw.or.kr/

궁금하신 분들은 들어가서 함 보시기를...

정말 웃긴 코미디같은 내용들..

1. 폐업된 회사들의 직인을 못받으면 80% 인정...

머야? 기술 없어서 망했다는 평가인가?

2. 국가기술자격증이 없는 동안의 경력은 50% 인정...

머야? 국가기술자격증이 없으면 개발도 하지 말라는 것인가?

3. 비 SW업체의 경우 'SW기술연구 전담부서확인서'를 받으라구?

머야? 지금 장난하슈? 해당 업체 찾아다니면서... 아쉬운 소리해야하겠네요.. ㅡㅡ;

4. 머! 발주처의 직인까지 받으라구?

머야!!!! 갑,을,병,정을 거쳐서... 페이퍼 컴패니까지 거친 소심한 프리랜서들은 우짜란 말인가?
ㅡㅡ;

5. 머야!!! 서류는 직접방문과 우편접수만 하라구?????

이넘들이 ㅡㅡ; IT랑 관계 있는 거야 없는거야????

6. 수수료... 한시적으로 뮤료지만... 필요시 내라구??

ㅡㅡ; 그래.. 돈 많이 받아서 부자 되세요~~

.
.
.

차라리...
국내의 개발자 커뮤니티에 계신 많은 분들이 모여서...
조금 더 건설적인 방법으로
경력을 인정받을 수 있는
단체를 설립하면 어떨까 하네요.

이런 말도 안되는 '행위'를 하는...

정말...

이거는 개발자들 가슴을 난도질 하는 것도 아니구...

정부에서 이런 일하는 것...
하든지 말든지...
무시하고...

차라리..

소프트웨어 개발자들 끼리...
별도로 '사단법인'만들어서...

개발 개발자들의 경력을 인정받을 수 있고...
그 능력을 검증 받을 수 있는..
그런 제도를 만듭시다.

아니면...

각 개발자 커뮤니티에서 인정받을 수 있는
제도를 각자 만드는 것이 훨씬 좋지 않을까요?

ㅡㅡ;

이러니...

닌텐도같은(!) 것은...
누구도 못만들지..

ㅡㅡ;

C/C++과 Flash의 조화... Alchemy... 오호!

Adobe의 연구 프로젝트중에 하나 Alchemy...
델마당에 들어가보니 재미있는 소식이 있어서 자료들을 검색해보니...
제법 꽤! 수준높은 수준까지 올라가있다.

http://www.arcadenoid.com/doom.html

다른것은 다 집어치우고... Doom을 Flash로 변화시킨것을 보면...
정말 멋지다.

ActionScript VirtualMachine(AVM2)용으로 컴파일할 수 있는 프로젝트인데...
http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf<- 상세 문서는 이넘...

http://www.craftymind.com/2008/04/18/updated-elastic-racetrack-for-flash-9-and-avm2/ <- 이문서도 참조할만하다.

연구의 바탕자체는...
Flash 9에서부터 시작해서 Flash Player 10과 Adobe AIR 1.5에서 구동가능한 SWF or SWC형태로 컴파일 할 수 있게 해주는것으로써, GCC를 이용해서 LLVM(Low Level Virtual Machine)으로 변화시킨후에, 이 넘을 AVM바이트 코드르 변경시키는 과정으로서 완성된다.

LLVM프로젝트도... Java의 JVM처럼 가상머신위에서 명령어 집합 + 형식 시스템의 3번지 코드 방식으로 만들어지는 일종의 가상코드이다. 내부적으로 정수이지만 파생된 포인트, 배열, 벡터, 구조제, 함수등의 5가지를 통해서 표현된다. 어찌보면 그 자체가 C++의 클래스를 받아들일 수 있는 구조가 되어있다고 볼 수 있다.

C++의 클래스를 구조체 + 함수, 함수에 대한 포인터로 변형할 수 있기 때문이다.

호~ 발상이 멋지죠?

C와 C++ -> LLVM -> SWF라...

머.. 가장 중요한것은 AVM2가 사실 오픈되었다는 것...
그래서, 이 방식을 맞추면...
어떤 언어이던지 가능하다는 이야기인데...

이거...
새로운 플랫폼의 방향을 제시하는 것 일 수도.. ㅎㅎ

좌우당간...

좀더 적극적으로 활용한다면...
다른 언어들도 충분하게 가능하다라고 이야기할 수 있는데.. ~.~
다양한 확장이나...
고려대상이 될만하겠네요...

아...
결론적으로는...

AVM2를 Java의 JVM의 레벨까지 끌어올리겠다는
고차원적인 발상인듯..
ㅎㅎ

많은 것을 버리는 것 같지만...
가장 많은 것을 얻는
Adobe의 전략이 멋집니다.

~.~

AVM2관련 문서를 살펴보니...
ActionScript Byte Code (ABC) Format에 대한 이야기가 있고...
세부적인 명령어들에 대해서도 나열되고 있네요...

좀더 상세한 내용들은...
아래의 블로그를 가보세요.

~.~

http://jidolstar.com/blog/archives/356 <- C/C++ Flash 플랫폼과의만남, Alchemy 1부
http://jidolstar.com/blog/archives/436 <- Adobe Alchemy 속도 테스트

자세하게 나와있는 글들도 체크할만하다.

ps~~

오호...
구글링을 해보니...

꽤 많은 곳에서...
pascal과 접목하려고 시도하고 있네요...
하긴..
어렵지는 않을테니...

ㅇㅇ;

웹서비스의 진화와 ERP, CRM을 구글앱스로...

우리나라에도 세일즈포스닷컴이 상륙했다. 더더군다나... 별도의 기업홈페이지를 가지기 보다는 Tistory에 기업의 소개내용들이 담겨져있다.

http://pietechnology.tistory.com

'파이테크놀로지'라는 이 기업은 굳이... 온라인에 큰 비용을 쓰지 않고도, 온라인 마켓에 홍보를 위한 전략적인 개념을 변화시킨것이다. 하긴... 뭐, 굳이 홈페이지가 필요하랴... Tistroy에 구축하면 그만인것을...

해당 블로그의 기업대표의 인사말에 적힌것처럼... 기업의 '의지'가 담긴 모습이라고 생각하면... 이 역시 멋진 변화가 아닐까 한다.

구글 솔루션 마켓플레이스는 웹기반 기업용 솔루션의 강자인 세일즈포스닷컴과의 제휴로 정말 무시무시한 괴물로 변해갈 것으로 보인다. Gmail을 비롯하여 캘린더, 구글문서, 구글 토크까지...

현재 4만여개의 기업고객이 사용하고 있는 세일즈포스닷컴의 역량에...
아.. 스카이프도 결합한다고 하는데... 통신까지라... ~.~

아래의 동영상은 구글앱스의 홍보동영상이다... 잘 설명된 내용이라서...
함 보면 좋을듯...

대한민국에서 소프트웨어 개발자로 산다는것... (1)

요즘은 블로그에 글 올리는 재미가 쏠쏠합니다. 머랄까... 말을 배설하는 쾌감을 느낀다고나 할까요? 그런데... 제 블로그에 올라온 글들을 보니... 정작 제가 속해있는 소프트웨어 개발에 대한 내용들은 '소프트웨어 아키텍처'에 대한 내용빼고는 그다지 많은 것 같지 않습니다.

그래서... 오래간만에... 대한민국 소프트웨어 개발자에게 '소프트웨어 개발자로 사는 것'에 대해서 끄적거려 보려합니다.

뭐부터 시작해야할까요? 뭐.. 보통 이런 류의 글을 쓸때에는 자기소개를 하는 것이 먼저겠죠?

음,.. 개발경력이라... 컴퓨터를 처음 만진것은 국민학교 6학년 졸업때쯤 부터 시작해서... 중학교 2학년때에 정보처리 기능사취득하고, 그 사이사이... 플밍 알바도 좀 하고... 91년 정보처리 기사자격증 취득해서... 병특생활하다가, 고난의 병특길을 포기하고, 공군에서 전산병으로 제대했습니다.

그후로... 소프트웨어 개발자의 길을 계속 걸어오고 있는데... 순수하게 소프트웨어 개발을 한 경력만 따져본다면...
군대 가기전 2년 병특시절, 전산병생활 3년, 패키지개발 및 연구소생활 5년, 대형SI개발 3년, 소프트웨어 개발 및 IT경영 3년 정도 되겠네요.

나름 파란만장한 IT의 경력을 가지고 있게되었습니다. ~.~

자그마한 통신사의 경품 당첨 프로그램 부터, 백억 넘게들어간 대형SI 프로젝트에서 기술부분을 책임지기도 하고, 원천기술적인 미들웨어나 라우터에 들어가는 플밍이나 설계도 해보고, 아... 온라인 게임개발도 해봤네요. ~.~
거기에 초보시절에는 하드웨어 엔지니어에 어셈블리까지 다루어봤으니...
정말 해볼만한 것은 다 해본듯합니다.

또... 나름 운이 좋았다고 생각하는 것은 실제 사회생활을 나와서... 어느정도 경력이 쌓이면서 IT붐이 일어서 더더욱 좋은 경험을 한것이고, 군대에서는 계룡대에서 군의 전체적인 정보시스템의 구축실무와 업무내용을 바라보는 시야도 생겼고... OMG에 다니면서 방법론이나 UML에 대한 노하우까지...
참 다양한 경험을 습득했습니다.

나이 30전에는 정말 월요일에 출근해서 토요일날 퇴근하는 무지막지한 생활을 즐기기도 했으니까요. 그사이 사이 참으로 많은 결단을 내릴 기회가 많았죠.

그간 결단을 내린것을 따져보면.

1. 병역특례업체에서 고생하기 보다 군대를 가기로 결정한것.
2. 건설설계쪽 소프트웨어 개발사에서 독립해서 테크니션쪽으로 방향을 정한것.
3. 커뮤니티의 대표가 되어서 인맥을 넓히고 명성도 얻게 된것.
4. 개발아이템을 확고이 해서 개발회사를 설립하고, 내 제품을 들고 라스베가스 컴덱스에 나가본것.
5. OMG에 활동하면서 세계최고 수준의 개발자들과 만나본것
6. 소프트웨어 아키텍처를 선택하고 그에 필요한 스킬을 연마한것.
7. 적당한 시기에 개발자의 미래에 대해서 생각해본것.

나름 좋은 결단을 내린 것이라고 생각하는데...
또 뒤돌아보면 잘못된 판단을 내린 경우도 많았습니다.

1. 사업파트너를 만나면서 사람의 됨됨이를 고려하지 않았던 점.
2. 정치적인 역학관계의 매력에 빠져서 순수 개발자로써 오버한점.
3. 비즈니스의 마무리를 해야하는 시점에서 같이 일한 동료들을 일일이 챙겨주지 못한점.
4. 중요한 결단이 필요할때에 남을 공격할 기회가 있으면 해야했는데 그냥 포기한점.

살아가면서...
특히나 소프트웨어 개발자로 살아가면서...

좋은 판단, 나쁜 판단...

결국 다 제가 하는 것이고, 그 결과에 대해서 본인이 책임지는 것이더군요. 이제는, 나이도 40대를 바라보는 시야에서 개발자 보다는 IT를 기반으로 한 경영관리쪽의 일을 하고는 있지만.
제가 살아온 인생길을 뒤돌아보면... 정말 많은 경험을 한듯 합니다.

그런데, 재미있는 것은 소프트웨어 개발자로 살아오면서 느낀것은... 개발자들은 참 많은데 같이 일하고픈 동료들은 그렇게 많지 않았다는 것.

취업난이다, 구인난이다... 다 공감합니다.
어느것이 먼저라고 이야기하기 힘들정도로 복잡한 사회구조를 가지고 있죠.
경험과 스킬이 풍부하고 거기에 학벌까지 좋은 사람들도 많은 것을 보면...
머.. 그런 사람들은 그 사람이 필요한 자리에 가니까요.

생각보다... 실력이 뛰어난 사람은 적은것 같습니다.
어느 곳에서나 '능력'이 탁월한 사람들은 대우를 받으니까요.

머... 이렇게 주절 주절 쓴것은...
후배개발자들에게 이런 이야기를 해주고 싶어서 입니다.

'자신의 능력에 대해서 얼마나 정확하게 알고 있는가?'

능력이상의 일을 도전하는 도전정신도 중요하고...
자신의 스킬을 업그레이드 하는 것도 중요하고...
'실력'에 대한 열망을 가지는 것도 중요합니다.

그런데... 여기서 이야기하는 '능력'에서 가장 중요한 것이 무엇인지 아십니까?

그것은 '커뮤니케이션' '소통'능력입니다.

개발자들에게 가장 중요한 것은 다른 개발자들과 어떻게 일하고, 그사람이 나를 어떻게 느끼고... 내가 다른 사람들을 어떻게 이해할 것인가에 대한 것들입니다.

정말 살벌한 이야기를 하자면...
요즘 소프트웨어 개발 기술은 정말 평준화 되어있고...
수많은 자료들에 대해서 습득하고 약간의 경험과 시간이 주어지면...
할 수 있는 일이 대다수입니다.

특히나... 우리나라의 현실에 있어서... 특수하고 복잡한 일을 하는 경우는 정말 드물죠.

적당한 일에...
적당한 대우를 받는...
그런 곳이 더 많다는 것이죠.

그럴 경우에 '나'를 돋보이게 하는 것이..
바로 '커뮤니케이션'..
'소통능력'이...

가장 최고의 대우를 받게 해준답니다.

'소프트웨어 개발자'에게 있어서
사람이라는 개발자들과 어울려 일하는 곳에 가장 중요한 것은...

바로.. '그'... '소통능력'입니다.
그것을 어떻게 만들어야 하는지는 다음번에... ~.~

... To be Continued

새로운 AJAX 개발툴... Morfik 2.0으로 업그레이드 하다...

그동안 관심을 가지고 지켜보던...
Morfik이 그동안의 몇가지 문제점들을 나름 처리하고선
새로운 모습으로 나타났다.

http://www.morfik.com

이 개발툴은 델파이를 기본적인 개발툴로 하고서는 개발된
RAD 방식의 AJAX개발툴이었다.

설치형태를 봐도 나름 깔끔한 형태로 바뀌었지만...
한편으로는..

그러므로 장점이 하나 손상되기도 했다.

먼저 그동안의 Morfik 1의 가장 큰 문제점이었던..
한글 처리부터 살표보자.

데이터 처리를 위한 테이블의 생성과 데이터 입출력에서 문제가 없다.
정말 깔끔하게 처리된 느낌이다.

폼 디자인 부분에 있어서도...
정말 깔끔하게 잘동작한다.

웹의 RAD툴의 나름대로의 정석을 만들려고 하는듯.

Subform개념으로 형성된 모습은...

웹UI의 특징을 잘 살리면서...
직관적인 RAD툴의 장점을 나름 뛰어나게 살리고 있다.

델파이나 비주얼베이직과 같은 툴에 익숙한
C/S개발자들에게 커다란 개념전환없이
개발툴을 사용할 수 있게 해준다.

다만, Demo 버전이라서 가진 단점이 몇개 초기에 발견되었는데.
그중 가장 큰것은 '데이터베이스'에 연결할 수 없다는 점과...

웹UI를 3개이상 만들지 못한다는 점...
더더군다나...
기본적으로 생성되는 메인의 경우 3개가 기본이기 때문에...

실제 업무에서 사용될 형태를 만들기에는 어려워보인다.

하지만...

말그대로의 Demo이기 때문에...
기능에 대한 테스트를 목적으로 하기에는 나름 충분하다고 생각한다.

아 그리고... 델파이의 Visual Component와 VB의 비주얼 컴포넌트처럼..
Morfik 특유의 '컨트롤 컴포넌트'를 등록시키는 부분이 새롭게 깔끔하게 정리되었다.

아마도...

이 부분이 RAD툴이 가지는 가장 큰 장점이 될것인데...
이 부분들을 얼마나 효과적으로 사용할 수 있을 지가 관건이다.

향후 새롭게 지원되는 툴들을 위함이리라...

.
.
.

다른 부분들에 대해서는...
깔끔한 지원...

웹UI를 기반으로한 델파이나 비주얼 베이직 사용자들을 흡수하기 위한 좋은 대안툴로 보인다.

다만...

Morfik 1에서는 내부 시스템들이 상당수 오픈되어진
델파이의 철학을 계승하고 있어서...
시스템에 다양한 각도의 델파이 컴포넌트들을 변형하여 탑재가 가능했는데..

Morfik2에서는 그런부분들이 많이 봉쇄되었다..

특히나...
메뉴의 한글화 라던지..
( 이 부분은.. 지금 막 설치한지 1시간도 지나지 않았기 때문에... 다른 방법이 있는지도 모르겠다. )

.
.
.

좌우당간...

웹UI를 제작하는 가장 빠른 방법의 개발툴로써
그 위상을 차지할 것인지?

서버사이드의 기반을...
윈도우즈 기반이 아닌 영역까지 활동영역을 높인것인지...
그것들이 정말 궁금하다.

관심이 있으신분은...

네이버 Morfik 까페로 오시죠~

http://cafe.naver.com/morfik

획기적인 웹UI 스케치 프로그램...

웹사이트 디자인의 초기버전을 도와주는 아주 유용한 프로그램..

DENIM...

http://dub.washington.edu:2007/denim/

타블렛과 어우러지면 짱일듯...

~~~

당장에라도...

실무에 적용할 만한듯...

이거 연습해야겠는걸..

~.~

GAE의 다음 단계는 무엇일까?

분명 GAE는 안정화될것이고...
그 시스템자체가 안정화 된다음에...
가장 먼저 공략할 대상은..

설치형 GAE를 오픈하거나 배포...
혹은.. 상용으로 판매를 하지 않을까?

그동안 웹어플리케이션서버라는 명목으로 나왔던 수많은...
프레임워크를 단 한큐에 밀어버리는

무시무시한 괴력을 발휘하지 않을까?

.
.
.

정말 소름끼친다...

하지만...

한편으로는 상당히!!! 즐겁고 흥미로운 일이될듯해보인다.

설치형 GAE라... ~.~

무시무시한 괴물... Google App Engine... 이넘은 어디까지 진화할 것인가!!!

구글에서 선보인 Google App Engine..

http://code.google.com/appengine/

이넘이 괴물인 이유는 '데이터베이스 플랫폼'과 단순한 호스팅 수준이 아니라...

'서비스'만 추가하면 되는...
통합된 서버사이드 아키텍처를 제공한다.

ㅡㅡ!!!!

좀더 상세하게 살펴보자.

1. 파이썬을 기본적으로 제공..
   - 현재는 파이썬만 제공하지만... 다른 언어도 확대할 예정이란다.

2. BigTable/GFS를 기반으로한 데이터베이스 플랫폼을 더욱 진화시킨 데이터스토어!!!제공!!!
   - 구글내부에서 사용하는 구글 검색, 구글 어스, 구글 Finance등의 방대한 데이터 처리능력을
     보여준 BigTable/GFS기반의 데이터스터어 플랫폼.
   - 환경은 SQL과 유사한 GQL을 통해서 웹서비스를 제공받는 것이다.. (!!!!)
     ( 물론... 아마존의 SimpleDB도 있지만... 아예 패키지가 되어버린 이넘은 정말 괴물이다. )

3. 아예 공간 + 확장성까지 포괄한 호스팅 공간!
   - 당근!!!! 서비스 트래픽 자체를 무시한다.. ㅡㅡ;
     구글의 어마어마한 서버사이드 공간을 활용한다니.. ㅡㅡ;
     이 얼마나 혁명적인 발상인가? !!!!!
   - 물론, 무료 사용자에게 제공되는 500MB의 공간과 월 500만 Page View... ( 나중에.. 대박모델을 포용한다는.. ㅇㅇ )

4. 구글의 인증제도
   - 회원관리 자체는 더이상 개발할 필요가 없다.. Why? 구글 사용자가 모두 사용자이니..
     당근, 구글메일등 다른 내부의 다양한 구글 어플리케이션과 결합이 가능하다.

5. SDK를 통한 로컬 개발 + 테스팅 환경
   - 개발자체도 로컬에서 개발할 수 있다는 환경...
     전용 도메인인 appspot.com...

.
.
.

아예.. 통째로!!! 웹서비스 개발자들 자체를 포용하겠다는 어마어마한 포부를 보인 구글!!!

Google App Engine...

정말 Engine이라 불릴만 하지 않은가?

이제 웹기반의 사업을 시작한다면...
Google App Engine은...
옵션이 아닌 필수가 되어버릴 것으로 보인다.

.
.
.

다만...

아직까지는... 다른 언어의 지원이 안되었으니...

1. 모든 코드는 파이썬으로...
2. 사용량 제한과 비용지불의 가능성...
3. 모든 데이터는 서버상에 존재?
   ( 흠.. 이 부분은 피할 방법이..쿨럭~~~)

.
.
.

더욱더 중요한 고민은...
구글 플랫폼에 종속된 어플리케이션을 개발해야 한다는 것인데...

.
.
.

지구상의 모든 웹어플리케이션을
모두 포용하겠다는

어마어마한 구글의 야심!!!

과연 어떻게 될 것이며!!
우리는 어떻게 대응해야 하는가?

ps...

흠 각각 개별적인 사용자들끼리 연합해서 만들어진 웹어플들은..
내부에서 또 독립할 것인가?

~.~

그리고 하나더...

이미 외국의 스타트업 기업들은...

이미 구글의 이 App Engine을 사용하기 시작한 기업들이 나타나기 시작했습니다.

( 머.. 대박이 나면.. 자연스럽게 구글에 인수되기도 좋으니.. ㅡㅡ; )

http://www.pannonrex.com/products-services/pmap/

Morfik + App Engine + PMAP...

정말 무시무시한 괴물이 나타났네요...

마지막으로..

http://www.appspot.com <- 들어가셔서 등록하시면 ( 국내 이동통신도 지원합니다. ~.~ )

처음 올려본... 서비스..
http://zetlos.appspot.com/
~.~

[펌] 오픈소스, 전방위 인기「리눅스 넘어선다」

예산이 빠듯한 업체들 사이에서 인기가 높아지고 있는 오픈소스 소프트웨어가 새로운 영역으로 세를 확산하고 있다. 바로 MS와 같은 대기업이 지배하고 있는, 수익성이 높은 인프라스트럭처 소프트웨어다.

이미 오픈소스 데이터베이스와 몇몇 애플리케이션들은 높은 인기를 구가하고 있다. 또한 별도로 MS, IBM, 오라클, BEA 시스템즈와 같은 업체들의 상용 소프트웨어와 동일한 오픈소스 대안을 구축하기 위해 두개의 오픈소스 프로젝트가 진행 중에 있다. 이 프로젝트들은 소프트웨어 애플리케이션의 ‘계층’을 구축한다는 목표를 세우고 있다.

지난 주 글루코드(Gluecode)라는 업체가 아파치 재단의 인프라스트럭처 툴 패키지에 대한 기술 지원·유지 보수 서비스를 판매하기 시작했다. 아파치 재단은 현재 가장 인기가 높은 오픈소스 소프트웨어인 아파치 웹서버를 감독·개발하고 있다. 이 패키지에는 포털·데이터베이스 소프트웨어와 애플리케이션 서버가 포함돼 있다.

그리고 6년전 프랑스 업체들과 연구기관이 설립한 비영리 컨소시엄인 오브젝트웹(ObjectWeb)이 최근 엑소(eXo) 플랫폼을 공개할 것이라고 밝혔다. 여기에는 이미 컨소시엄에서 제공하고 있는 연결성, 그리드 컴퓨팅, 기업용 인스턴트 메신저 이외에 기업용 웹 포탈·CMS 애플리케이션 등이 포함돼 있다.

비록 이 새로운 소프트웨어들이 수십억달러 규모의 백엔드 소프트웨어 시장을 어떻게 뒤흔들 수 있을지 논하기는 이르지만 상용 소프트웨어 업체들에게 있어 가장 수익성이 높은 분야에 있어 오픈소스 대안이 늘어나고 있다는 것은 엄연한 사실이다.

이런 추세는 갈수록 더 강해질 것이다. 아파치 재단과 오브젝트웹은 증가세에 있는 자바 서버 소프트웨어 컴포넌트를 결합해 사유 애플리케이션들과 경쟁 구도를 형성하게 될 것으로 보인다.

버튼 그룹의 애널리스트 앤 토마스 메인즈에 따르면 좋은 소식은 데이터베이스에서 비즈니스 애플리케이션에 이르기까지 이제 오픈소스 대안이 존재하게 됐다는 것이다. 그럼 나쁜 소식은? 이에 따라 많은 일들을 스스로 해결해야 한다는 것이다.

메인즈는 “오픈소스 기술에 기반해 똑같이 구축하는 것도 가능하다. 그러나 시스템 통합을 스스로 진행해야 한다는 것이 난제다. 통합 환경을 구축하려면 상당한 작업이 필요하기 때문”이라고 말했다.

오픈소스의 장점으로는 비용절감이 있다. 구매자들은 기술 지원 요금만 부담하고 소프트웨어 가격은 지불하지 않는다. 또한 MS를 비롯한 상용 소프트웨어 업체들과 장기 라이선스 정책이나 업그레이드 권한에 대해 마찰도 거의 없다. 회사의 성장에 따라 애플리케이션을 추가하기도 쉬우며 필요한 경우 소스코드를 즉시 이용할 수 있다.

물론 상용 서버 소프트웨어 패키지가 상당기간동안 지속적으로 가장 진보된 기능을 제공한다는 것에는 모든 사람들이 동의하고 있다. 그러나 이 오픈소스 미들웨어 프로젝트를 후원하고 있는 소프트웨어 프로그래머와 기업가들은 이미 자리를 잡고 있는 기존 상용 업체들과 정면 대결할 것이라고 공공연히 말하고 있다.

오브젝트웹의 실무 담당 부장 크리스토프 네이는 “오브젝트웹의 기반 코드에 포털을 추가함으로써 결함을 메웠기 때문에 상용 제품에 대한 진정한 대안으로 자리잡을 수 있게 됐다. 회원사들은 이미 애플리케이션 서버 이상을 구현할 수 있다는 것에 관심을 보이고 있다”라고 말했다.

네이는 오브젝트웹이 BPEL(Business Process Execution Language) 표준에 기반한 통합이나 비즈니스 절차 자동화와 같이 고가의 소프트웨어와 연동되는 제품을 개발하고 있다고 덧붙였다.

아직 어떤 대형 업체도 오브젝트웹의 서버 컴포넌트 패키지를 지원하는 서비스를 제공한다고 밝히지 않고 있다. 그러나 레드햇은 올 연초부터 자사의 요나(Jonas) 애플리케이션 서버용 서비스를 제공하기 시작했다.

기술 지원 서비스 ‘잘팔린다’
IBM, BEA 시스템즈, 오라클은 자바 애플리케이션 서버와 웹 포털, 통합 소프트웨어, 애플리케이션 개발 툴 등이 포함된 상용 자바 소프트웨어 패키지를 판매하고 있다. 또한 MS는 닷넷 개발 모델에 기반을 두고 있는, 이와 유사한 윈도우 서버 소프트웨어 패키지를 제공한다. 비즈니스 애플리케이션에 있어 기술적인 기반을 구성하는 이 인프라스트럭처 소프트웨어와 관련 툴들은 라이선스 비용만 해도 최대 수십만 달러에 달한다.

대규모 상용 기술 업체들은 최근 몇 년간 오픈소스 대안 소프트웨어의 수요가 늘어나고 있다는 현상을 인지하고 있다. IBM은 이미 리눅스, 그리드 컴퓨팅, 더비라고 불리는 전문 자바 데이터베이스 프로젝트 등 오픈소스 프로젝트의 주요 참여업체가 됐다. 그러나 웹스피어 자바 서버 패키지와 DB2 데이터베이스 등 수십억 달러의 매출을 거두고 있는 IBM의 미들웨어 제품들은 아직 사유 소프트웨어를 사용한다.

BEA 또한 개발자들에게 호감을 사기 위해 일부 제품을 오픈소스 형태로 배포하고 있다. 그러나 여전히 매출 실적은 사유 소프트웨어에 의존하고 있다.

HP의 리눅스 담당 부사장인 마틴 핑크는 “소프트웨어 자체에서 컴포넌트 통합으로 가치가 이전되고 있다”라고 설명했다. 이 회사는 최근 HP의 하드웨어에서 작동되는 JBoss, MySQL, 리눅스 소프트웨어를 대상으로 하는 컨설팅 서비스를 확대했다.

오브젝트웹, 아파치와 상용 소프트웨어 업체인 J보스의 오픈소스 컴포넌트들은 이미 많은 프로그래머들의 지원을 받고 있다. 그러나 업계 애널리스트와 중역들은 이 제품들에 적절한 상용 기술지원이 제공되느냐에 수용도가 결정된다고 지적한다.

글루코드와 신생업체인 스파이크소스(SpikeSource), 소스랩스(SourceLabs)는 이 점을 파고들고 있다. 이 업체들은 인증받고 통합된 오픈소스 소프트웨어 패키지의 가입자 기반 지원 서비스를 판매한다는 개념에 근거한 사업을 진행하고 있다.

글루코드는 아파치 오픈소스 라이선스 하에 구할 수 있는 다수의 오픈소스 제품에 대해 기술 지원·유지 보수 서비스를 제공한다. 이 업체는 조(Joe)라는 패키지를 이용해 자바 애플리케이션 서버인 제로니모(Geronimo), 포탈 소프트웨어 플루토(Pluto), 데이터베이스 더비, 워크플로우 소프트웨어인 아질라(Agila)에 대한 서비스를 판매하고 있다.

글루코드는 자사 패키지가 인텔의 IA64 프로세서에서 수행되며 하드웨어 업체들과 협력해 조 패키지를 번들 배포할 계획이라고 밝혔다. 이 회사의 CEO 윈스턴 다마릴로는 기술 지원과 정기적인 소프트웨어 업데이트에 드는 비용은 매월 3500달러이며 조 패키지가 기반을 잡은 자바 업체는 물론이고 MS와 같은 업체보다도 저렴한 가격에 제공된다고 강조했다.

다마릴로는 “서버 분야의 소프트웨어 비용에 시장은 질려 있는 상태다. 우리는 바로 이 비용을 0으로 만들려 한다”라고 말했다.

뒤이어 다마릴로는 제로니모가 모듈 형태로 설계돼 있기 때문에 포털이나 통합 소프웨어와 같은 애드온 제품이 필요할 경우 쉽게 추가할 수 있다고 전했다. 글루코드는 또한 설치와 관리를 용이하게 진행할 수 있는 관리 소프트웨어도 판매하고 있다.

스파이크소스와 소스랩스는 램프(LAMP)라고 불리는 오픈소스 소프트웨어 묶음을 중심으로 서비스를 제공하려 한다. 여기에는 리눅스 운영체제, 아파치 웹서버, MySQL 데이터베이스, 그리고 PHP 개발 툴 등이 포함돼 있다.

JBoss는 무료 소프트웨어를 중심으로 컨설팅·지원 서비스를 판매하고 있다. 자바 프로그래머들로부터 인기를 끌고 있는 애플리케이션 서버를 보유한 이 회사는 자체 개발·지원하는 워크플로우 서버 등으로 제품군을 확대하고 있다.

아파치, 오브젝트웹, JBoss는 자바 애플리케이션 서버에 기반한 미들웨어 제품을 각각 개발하고 있으며 별도의 오픈소스 라이선스를 제공하고 있다. JBoss는 최근 자사 소프트웨어가 J2EE 표준을 따른다는 인증을 받았다. 제로니모와 요나도 J2EE 인증을 받을 예정이다.

사유 SW 업체 “오픈소스 영향? 없어!”
아직까지 대형 상용 소프트웨어 업체들은 오픈소스 대안 제품들이 시장 점유율이나 수익을 잠식하고 있다는 것을 부인한다. 썬 마이크로시스템즈의 경우 자바 애플리케이션 서버 패키지를 오픈소스 형태로 제공할 것을 고려한 적도 있다고 전했다.

비록 오픈소스 미들웨어가 아직 전체시장에서 극히 일부분만을 차지하고 있지만 오픈소스 애플리케이션과 리눅스의 전체 사용도는 지속적으로 증가하고 있다. 시장조사기관 가트너는 조사대상 대기업의 80% 이상이 일부 영역에서라도 리눅스를 사용하고 있는 것으로 답했다고 전했다.

게다가 오픈소스를 받아들이는 데 있어 이미 잘 확립된 수용 패턴이 존재하고 있다. 리눅스를 예로 들어 보자. 1990년대 일반적인 서버에서 웹 또는 파일 서버로 처음 사용된 리눅스는 이제 각 부서의 서버부터 시작해 고성능 컴퓨팅·데스크톱 소프트웨어에 이르기까지 유닉스나 윈도우에 대한 저가의 대안 제품 역할을 수행하고 있다.

오픈소스 자바 애플리케이션 서버, 데이터베이스, 개발 툴들도 빠르게 두각을 나타내고 있다. 사명과 같은 이름의 애플리케이션 서버용 지원 서비스를 판매하는 JBoss와 오픈소스 데이터베이스 업체 MySQL은 지난해 많은 사람들에게 인기를 끌었다.

리눅스와 오픈소스 애플리케이션이 광범위하게 수용되는 데 있어 장애물은 바로 대기업들이 얼마나 큰 위험을 감수할 의지가 있느냐라고 지난달 발행된 가트너 보고서는 지적한다. 여기에는 출처가 다양한 각양각색의 애플리케이션을 지원해야 한다는 것도 포함된다. 바로 이런 부분을 글루코드 등 몇몇 업체들이 떠맡으려 하고 있다.

가트너는 지적재산권과 법적 문제에 대한 위험 부담이 오픈소스 소프트웨어의 수용에 있어 또다른 문제로 작용한다고 전했다. 이 문제들은 리눅스와 오픈소스의 광범위한 성장에 있어 향후 5년간 도전 사항이 될 것이다. 레드햇, 노벨 등 몇몇 업체들은 리눅스 고객을 대상으로 법적 보호장치를 제공하기 시작했다.

BEA의 CEO 알프레드 추앙은 오픈소스 자바 애플리케이션 서버, 특히 JBoss 현재로서 BEA의 사업에 전혀 침해를 주고 있지 않다고 이달 초 밝힌 바 있다. 그는 JBoss가 “기업에서 사용되고 있는 것을 본 적이 없다. 우리에게 전혀 위협적인 존재가 아니다”라고 말했다.

MS의 플랫폼 전략 총괄 마틴 테일러는 오픈소스 미들웨어 컴포넌트가 한번 조립되고 나면 “마치 우리 것인 것처럼 보인다”라고 말했다. 그러나 그는 대다수 고객들이 낮은 수준의 소프트웨어 통합에 시간과 노력을 투자하길 원하지 않는다고 지적했다. 테일러는 또한 패키지 애플리케이션이 오픈소스 소프트웨어에서 수행될 수 있도록 인증받았는지 고려해야 한다고 전했다.

테일러는 “오픈소스에 특정 애플리케이션이 존재하는지 안하는지 문제가 아니다. 바로 각 소프트웨어 묶음에 걸친 통합의 정도로 상위와 하위의 통합 정도, 그리고 튜닝에 걸리는 작업의 정도”라고 말했다.

오픈소스 인기, 부인할 수 없는 사실
그러나 품질이 좋은 오픈소스 소프트웨어들은 기업들에게 받아들여지고 있다는 것은 분명하다. 또한 상용 소프트웨어와 오픈소스 방식이 한 기업 내에 공존할 수도 있다. 포레스터 리서치의 애널리스트 헨리 페이렛은 오픈소스 미들웨어 프로젝트가 대부분 저가 시장 쪽에 치중하고 있으며 상용 업체들처럼 가장 진보된 기능을 좇지는 않는다고 설명했다. 따라서 오픈소스 소프트웨어가 항상 이미 완성된 제품들과 직접적으로 경쟁하는 것은 아니라고 그는 덧붙였다.

페이렛은 “일부 고객은 자신들이 충분히 좋은 제품을 선택한다는 것을 확실하게 자각하고 있다. 비록 모든 기능을 제공하진 않는대도 말이다. 특정 기능을 원한다면 그 분야에만 상용 소프트웨어를 적용하면 된다. 기업 전체에 적용할 필요는 없다”라고 말했다.

반면 메인지는 오픈소스 미들웨어 제품을 수용하는 것이 위험을 감수할 수 있는 준비와 자체적인 기술 지원 능력을 필요로 한다고 전했다. 오픈소스 프로젝트들은 중단될 수도 있으며 상용 기술 지원이 항상 명쾌하게 맞아 떨어지는 것은 아니기 때문이다.

메인지는 “사실 IBM의 소프트웨어를 사용하느냐, 아니면 기술 지원 분야에 투자하고 오픈소스 사용에 따른 위험을 감수하느냐 하는 것은 완전히 기술적인 문제는 아니다. 여기에는 문화적인 이슈도 분명히 존재한다”라고 전했다

[펌] Ant란?

Ant의 소개 Ant 는 Java 기반의 Build 툴로써 Unix 의 make 와 같은 툴이라고 보면 된다.

왜 Ant 를 사용해야 하나?
make.gnumake,nmake,jam 과 같은 다른 Build 툴은 놔두고 왜 Ant 를 써야하는가에 대한 질문이다. Java 기반으로 프로그램을 짜고 컴파일 및 배포용 쉘 프로그램을 짜봤는가? 해봤다면 그것의 어려움을 잘 알것이다. 각 OS 마다 쉘 스크립트가 다르고 일반적으로 사용하고 있는 Unix 에는 또 각종 쉘들이 존재한다. 윈도우 쉘 또한 복잡하긴 매한가지이고 프로그램을 모두 작성하고 컴파일 및 배포 쉘 스크립트를 작성하기 위해서 이것들을 모두 작성하는것 자체가 프로그래머에게 또 하나의 고난이 아닐까 생각한다.(즉, 쉘 프로그램을 배워야 한다는 의미이다.)


게다가, 팀 단위 작업을 한다고 할때, 작업하는 컴퓨터와 IDE 들이 각각 다른 경우, IDE 에 따라서 classpath, 배포디렉토리 경로들도 다를 것이다.

Ant 는 OS Indepenent 하게 프로그램을 Build 할 수 있는 환경을 제공해준다. build.xml 이란 Build 파일을 작성해서 그 내용에 따라 Build 를 진행해 나갈 수 있다. Ant 는 Java 에서 거의 표준으로 굳혀져가고 있으며, 거의 모든 IDE들이 Ant 를 지원한다.



Install 현재 Ant 는 Binary 와 Source 두가지를 배포하고 있습니다.


Ant 얻기 - IDE 에 따라서 Ant 가 기본내장되어있는 경우가 많다.

http://jakarta.apache.org/ant/index.html 에서 최신버전의 binary, source 를 얻을 수 있다. CVS 를 이용, source 를 얻을 수도 있다.


시스템 요구사항

Ant 를 사용하여 Build 하기 위해서는 JAXP 호환 XML파서가 있어야 합니다. 그런데 Ant 를 다운받으면 그 패키지 안에 포함되어 있으므로 따로 다운받으실 필요는 없습니다. JAXP 에 대해서는 http://java.sun.com/xml/ 정보를 얻을 수 있습니다.
Build 툴이기 때문에 당연히 JDK 가 필요합니다. JDK 1.2 이상을 가지고 있으면 됩니다.
Ant 의 몇몇 특정 Task 들의 경우 (JUnit, FTP, Telnet 등) 해당 라이브러리가 필요하다. 이는 http://jakarta.apache.org/ant/manual/install.html#librarydependencies 항목을 읽기 바란다.


Install

바이너리 파일을 기준으로 설명하겠습니다. 설치는 Windows 기반으로 설명하겠습니다. Unix/Linux 기반을 비슷하니 알아서(?) 하세요. ^^;


일단 받은 Ant 압축파일을 C:\Ant 에 풀어 놓고 시작해봅시다. 하위 디렉토리는 bin,doc,lib 등이 있겠죠. ^^ (Win 9x 시리즈에서는 환경변수에 들어가는 긴 파일명이 문제가 될 수 있으니 위와 같이 C:\Ant 에 설치하는 것이 좋습니다.)

PATH 환경변수에 Ant 아래에 bin 디렉토리를 추가합니다. 즉 C:\Ant\bin 을 추가합니다.

ANT_HOME 이라는 환경 변수를 만들고 그안에 Ant 가 설치된 디렉토리 값을 넣습니다. 즉 C:\Ant 를 넣습니다.

JAVA_HOME이라는 환경변수에는 JDK가 설치된 디렉토리를 추가합니다.

Windows Shell


set ANT_HOME=c:\ant
set JAVA_HOME=c:\jdk1.3.1_01
set PATH=%PATH%;%ANT_HOME%\bin


Unix(Linux) (bash)

export ANT_HOME=/usr/local/ant
export JAVA_HOME=/usr/local/jdk-1.3.1_01
export PATH=${PATH}:${ANT_HOME}/bin


Optional Tasks

Ant 는 다양한 Optional Tasks를 제공합니다. 일단 Task 라는 말이 앞으로 많이 나올텐데 Glossary 를 참고하세요. 예를들면 CVS 에 소스를 업데이트 해주는 Optional Task 가 있을 수 있고, 또 .NET 컴파일을 한다던지.. 기타 등등 다양한 Task 가 있습니다. (이에 대한 예제로는 AntTask를 참조)



Running 이제 Ant 를 실행하는 방법에 대해서 알아보자. Ant를 실행하는 것은 마치 make 명령을 내리는 것처럼 쉽다. Ant 에서 중요한 것은 make에서 "Makefile" 을 만들듯이 Build 파일을 잘 만드는 것이 중요합니다. Build 파일을 만드는 것에 대해서는 나중에 알아보기로 하고 일단 실행하는 방법부터 알아보죠.

일단 쉘에서 실행하는 간단한 형태는 다음과 같습니다.(여기서 '%'는 쉘을 의미합니다.)


% ant

이것은 현재 디렉토리에 build.xml 이라는 파일을 Build File 로 해서 Build 를 하겠다는 것입니다. build.xml 파일이 없다면 에러를 출력하겠죠? ^^

% ant -buildfile test.xml

이것은 build 파일을 test.xml 이라는 파일을 build 파일로 사용해서 build 하겠다는 의미입니다.

% ant -buildfile test.xml dist


이것은 바로 위에 있는 것에다가 dist라는 것이 붙었는데 이것은 target 을 나타냅니다. Unix/Linux 에서 make 명령으로 컴파일 해보신 분들을 아실껍니다. 보통 make 명령으로 컴파일 하고 make install 명령으로 인스톨을 하죠? 거기서 쓰인 install 이 target 입니다. Ant 에서는 Build 파일 안에 다양한 target 을 둘 수 있습니다. 예를 들면 debug 모드 컴파일과 optimal 모드 컴파일 2개의 target 을 만들어서 테스트 할 수 있겠죠? ^^

% ant -buildfile test.xml -Dbuild=build/classes dist

위의 예에 하나가 추가됐죠? -D 옵션은 Build 파일의 Property task 와 같은 역할을 합니다. 즉 Build File 내부에서 사용되는 일종의 변수를 선언한다고 볼 수 있겠죠? ^^


직접 실행하기
실행 파일 ant는 Unix 계열에서는 shell 스크립트로 Windows 계열에서는 ant.bat 라는 배치파일로 배포됩니다. 내부에 보면 java 프로그램을 실행하는데, 다음과 같이 자신이 직접할 수도 있습니다.

% java -Dant.home=c:\ant org.apache.tools.ant.Main [options] [target]


Buildfile(build.xml) 을 만들어보자 Ant 를 다룰줄 안다는 말은 즉, Build File 을 만들줄 안다는 의미와 같다. Build File 은 파일이름에서도 알 수 있듯이 xml 을 기반으로 하고 있다. 예제로 참조해볼만한 화일로 Ant/TaskOne, Ant/BuildTemplateExample 이 있다. 해당 화일을 보면서 설명을 읽으면 편할것이다.


--------------------------------------------------------------------------------

project 태그

일단 제일 처음 나오는 Root Element 로는 project 태그로 프로젝트 정의를 하는 곳이다.

Attribute Description Required
name 프로젝트의 이름 No
default default target 명을 넣는 곳이다. ant 를 실행할 때 target 을 지정하지 않으면 여기서 지정한 target 으로 실행한다. Yes
basedir 프로젝트의 base 디렉토리를 말한다. ant 내부에서 사용되는 모든 path 들은 이 디렉토리를 기반으로 한다. No


추가적으로 project 태그 뒤에 description 이란 태그를 사용하여 Project 를 설명할 수 있다.


--------------------------------------------------------------------------------

target 태그

project 태그 다음에 올수 있는 태그로 아래 나오는 Task 들의 묶음이라고 생각하면 된다.
기존의 Makefile 이라던지 다른 Build 툴을 보면 의존관계(Dependency)라는 것이 있을 것이다. 즉, 배포(distribute)라는 target 을 수행하기 전에 compile 이라는 target 을 먼저 수행해야 하는 의존 관계가 발생할 수 있을 것이다. target 에서는 이런 의존관계(dependency)를 다음과 같은 방법으로 제공한다.


<target name="A"/>
<target name="B" depends="A"/>
<target name="C" depends="B"/>
<target name="D" depends="C,B,A"/>


위의 예를 보면 B 는 A 를 의존하고 있고, C 는 B를 D는 C를 의존하고 있다. 처음 시작하는 tag 라 D라고 했을 때, D 는 C에 의존하므로 C 를 실행하러 간다. C 를 보면 B 를 의존하므로 B 를 수행하고 B 는 A를 의존하므로 A 가 수행된다. 즉 이것의 수행 순서는 A,B,C,D 순으로 수행된다.
그리고 D 가 C 에 의존해서 A,B,C 를 수행하고 난 후에 다시 B 에 의존하게 된는데 B는 한번 수행했으므로 다시 실행되지 않는다. 이점을 유의하도록 하자. target 은 한번만 수행된다.

의존관계외에 target을 수행하기 위해서 조건을 걸어서 사용할 수 있다. 이는 "'if'"와 "'unless'" 라는 attribute 를 사용해서 할 수 있다. 형식은 다음과 같다.



<target name="build-module-A" if="module-A-present"/>
<target name="build-own-fake-module-A" unless="module-A-present"/>

[펌] Struts MessageResources에서 한글 문제 해결법

펌 : www.javaservice.net

 

JDK의 ResourceBundle을 쓰건, Struts의 MessageResources를 쓰건 자바의 Properties
파일을 이용하는 이상 인코딩 문제는 피해갈 수가 없습니다. 실제 대부분의 프로퍼티
파일들은 각 시스템의 기본 인코딩으로 작성되는 반면 자바의 Properties는 무조건
ISO-8859-1 인코딩으로만 인식하고 읽기 때문에 이를 기반으로 한 대부분의 클래스들
역시 인코딩의 문제를 피해갈 수 없습니다.(ISO-8859-1로 인식할 수 없는 문자에
대해서는 유니코드로 인식합니다.) 따라서 원죄는 Properties에 있는 것이고 근본적인
해결책은 Properties에 현재의 load, store를 빨리 deprecated시키고 Reader, Writer
혹은 nio를 통해 설정파일에 입출력할 수 있는 메쏘드가 추가되는 것입니다.

그러나, 현실적으로 프로퍼티를 사용하는 곳은 너무나 많고 이를 모두 수정하기는
불가능에 가까운 일입니다. 따라서, 프로퍼티에서 읽을 때 인코딩 변환을 해주는
방법이 가장 현실적인 대안이라고 할 수 있겠습니다. 그렇다면 차선책으로 가장 좋은
것은 Struts에서 이 점을 반영한 패치를 내놓는 것입니다. 이건 동아시아권
개발자들이 참여해야할 부분이라고 생각됩니다. 그러나, 그렇다고 패치가 나오기까지
무작정 기다릴 수는 없겠죠. 그 패치가 다른 나라 개발자들의 동의를 얻을 수
있을지도 미지수이고요. (이 문제는 우리가 유니코드만 쓴다면 아무 문제가 안되는
것입니다. 사실 저 역시 우리도 어서 UTF-16이든 UTF-8이든 유니코드 기반의
인코딩으로 모든 소스들을 전환해야한다고 생각합니다.) 결국 마지막 남은 방법은
우리 개발자들의 몫이겠죠.

다행스럽게도 Struts의 MessageResources 클래스는 어느 정도 추상화가 되어
있습니다. 실제 구현하는 클래스는PropertyMessageResources입니다. 이놈의 코드를
살펴보면, 어떤 로케일로 getMessage를 호출했을 때 해당하는 로케일로 읽어둔
메세지가 없으면 그 때 해당 로케일의 프로퍼티 파일을 찾아서 읽게 되어 있습니다.
근데, 그냥 읽어서 Properties 객체로 갖고 있는 것이 아니라 새로운 HashMap 객체를
생성해서 이곳에 담습니다. (이 개발자도 Properties에서 Hashtable을 사용하는 것은
못마땅했던 모양입니다.) 덕분에 우리는 큰 퍼포먼스 저하 없이 쉽게 인코딩 변환할
할 방법을 찾을 수 있게 되었죠. HashMap으로 옮겨 담는 부분에서 Configuration
등에서 읽어온 인코딩으로 변환을 시켜주면 됩니다. 사실 이 작업을 getMessage를
오버라이드해서 해줄 것인지 HashMap에 옮겨 담는 과정에서 해줄 것인지 고민하긴
했습니다만 결국 중요한 것은 프로퍼티 파일 작성자의 의도가 담긴 객체로 남아 있는
것이라 생각해서 HashMap에 옮겨 담을 때 인코딩 변환을 하도록 구현했습니다.

아직도 문제는 남았습니다. 그렇다면 이 과정으로 Struts 소스를 고쳐서 새로
컴파일하고 사용하는 것이 바람직할까요? 제 생각엔 No입니다. 개발자 자신이
유지보수하는 것이 아닌 패키지를 제공 받아 사용할 때 이를 함부로 수정해서
사용하는 것은 많은 문제를 낳습니다. 당장 Struts 버전업할 때마다 새로 수정,
컴파일, 패키징 과정을 거쳐야하죠. 다행스럽게도 Struts의 개발자들은 이런 부분에
대해 세심한 배려를 해두었습니다. Factory 클래스를 교체할 수 있게 한 것이죠. 이런
배려는 여기 뿐 아니라 Jakarta 프로젝트 전반에 걸쳐 나타나고 있죠.(사실 Abstract
Factory 메쏘드 패턴을 사용할 때 당연히 따라오는 장점이기도 합니다.) 따라서
우리는 PropertyMessageResources와 PropertyMessageResourcesFactory를 상속 받아서
위에서 설명한 부분을 오버라이드하고 이 팩토리를 struts-config.xml에 설정해주면
됩니다. 다음과 유사하게 설정하면 됩니다.

<message-resources parameter="messages" factory="com.hangame.jwdf.util.NativePropertyMessageResourcesFactory"/>

상속 받아 추가된 클래스는 다음과 유사하게 작성하면 됩니다.

NativePropertyMessageResourcesFactory.java

package com.hangame.jwdf.util;import org.apache.struts.util.MessageResources;import org.apache.struts.util.PropertyMessageResourcesFactory;public class NativePropertyMessageResourcesFactory extends PropertyMessageResourcesFactory { public NativePropertyMessageResourcesFactory() { super(); } public MessageResources createResources(String config) { return new NativePropertyMessageResources(this, config, this.returnNull); }}

NativePropertyMessageResources.java

package com.hangame.jwdf.util;import net.javaservice.jdf.util.CharConversion;import org.apache.commons.logging.Log;import org.apache.commons.logging.LogFactory;import org.apache.struts.util.MessageResourcesFactory;import org.apache.struts.util.PropertyMessageResources;import com.hangame.jwdf.ExceptionHandler;import com.hangame.jwdf.config.Configuration;import com.hangame.jwdf.config.ConfigurationException;import java.io.IOException;import java.io.InputStream;import java.io.UnsupportedEncodingException;import java.util.Iterator;import java.util.Locale;import java.util.Properties;public class NativePropertyMessageResources extends PropertyMessageResources { Log log = LogFactory.getLog(NativePropertyMessageResources.class); /** * */ public NativePropertyMessageResources(MessageResourcesFactory factory, String config) { super(factory, config); } /** * */ public NativePropertyMessageResources(MessageResourcesFactory factory, String config, boolean returnNull) { super(factory, config, returnNull); } /** * Load the messages associated with the specified Locale key. For this * implementation, the config property should contain a fully * qualified package and resource name, separated by periods, of a series * of property resources to be loaded from the class loader that created * this PropertyMessageResources instance. This is exactly the same name * format you would use when utilizing the * java.util.PropertyResourceBundle class. * * @param localeKey Locale key for the messages to be retrieved */ protected synchronized void loadLocale(String localeKey) { if (log.isTraceEnabled()) { log.trace("loadLocale(" + localeKey + ")"); } // Have we already attempted to load messages for this locale? if (locales.get(localeKey) != null) { return; } locales.put(localeKey, localeKey); // Set up to load the property resource for this locale key, if we can String name = config.replace('.', '/'); if (localeKey.length() > 0) { name += ("_" + localeKey); } name += ".properties"; InputStream is = null; Properties props = new Properties(); // Load the specified property resource if (log.isTraceEnabled()) { log.trace(" Loading resource '" + name + "'"); } ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); if (classLoader == null) { classLoader = this.getClass().getClassLoader(); } is = classLoader.getResourceAsStream(name); if (is != null) { try { props.load(is); } catch (IOException e) { log.error("loadLocale()", e); } finally { try { is.close(); } catch (IOException e) { log.error("loadLocale()", e); } } } if (log.isTraceEnabled()) { log.trace(" Loading resource completed"); } // Copy the corresponding values into our cache if (props.size() < 1) { return; } synchronized (messages) { Iterator names = props.keySet().iterator(); while (names.hasNext()) { String key = (String) names.next(); if (log.isTraceEnabled()) { log.trace(" Saving message key '" + messageKey(localeKey, key)); } String convertedMessage = props.getProperty(key); try { Configuration conf = Configuration.getInstance(); convertedMessage = CharConversion.convert(props.getProperty(key), "ISO-8859-1", conf.get("native.encoding")); } catch (UnsupportedEncodingException e) { log.fatal("Invalid Encoding.."); } catch (ConfigurationException e) { log.fatal("Configuration Error.."); } messages.put(messageKey(localeKey, key), convertedMessage); } } } /** * */ public String getMessage(String key) { String message = super.getMessage(key); try { Configuration conf = Configuration.getInstance(); Locale locale = new Locale(conf.get("native.locale.language"), conf.get("native.locale.country")); message = getMessage(locale, key); } catch (ConfigurationException e) { ExceptionHandler.handle(e); } return message; }}

좀더 생각해보면 더 좋은 해결책도 있을 것입니다. 일단 이 정도만 해도 struts에서
별 불편 없이 메세지를 그대로 사용할 수 있을 것입니다.

제목 : Re: xml 은 어떨까요 글쓴이: 이희승(anoripi) 2003/10/30 23:08:06 조회수:26 줄수:21

잘 이해가 안가는데요 그러니까...프로퍼티즈 파일을 직접 에디터로 수정해서 한글 메시지 같은 것을 넣을 수 없다는문제점을 지적하신 것 같은데요. (\uXXXX 로 표현되는..)더 좋은 방법은 리소스 파일을 xml로 만들어서 쓰는게 아닐까 하네요.일단 XML 은 파서 측에서 엔코딩에 맞게 해석하고, 사람이 직접 수정할 수도 있고, XML 의 장점도 그대로 가져갈 수 있어서 좋다고 봅니다. JSF cardemo 를 보면 JSF 의 메시지 리소스를 구현해 만든 XML 리소스 클래스가 있습니다. 그것을 참고해도 좋을 것 같네요.--what we call human nature in actually is human habit.--http://gleamynode.net/

제목 : Re: 글쎄요... 글쓴이: 박영록(poci) 2003/10/31 00:00:02 조회수:8 줄수:12

움. 논쟁 거리가 될 수도 있는 문제를 끄집어내시는군요-_-개인적인 생각으론, XML도 충분히 좋은 선택이나 그렇다고해서 Properties보다 나은선택이라고 말할 수는 없다..정도인 것 같습니다.XML을 쓸 때는 아무래도 그 무게와 복잡성을 고려하지 않을 수 없고, 또 XML을 쓰면서Properties 수준의 key-value 구조만 사용한다면 XML을 쓴 이유가 희석되겠죠.근데 사실 제가 제기한 문제는 이게 아니죠. Properties의 문제를 지적하긴 했지만그건 struts MessageResources가 뜻대로 동작하지 않는 원죄가 Properties에 있다는걸 말하기 위한 거지 Properties 자체의 문제를 해결하자는 것이 목적인 건 아니었죠.struts에서 bean:message 태그를 한글 문제 걱정 없이 쓰기 위한 방편 정도로 보면잘 이해가 안간다는 말을 하실 정도는 아닐 겁니다.

제목 : Re: 글쎄요... 글쓴이: 이희승(anoripi) 2003/10/31 00:51:50 조회수:11 줄수:13

잘 이해가 안간다는 말은 음..> 프로퍼티즈 파일을 직접 에디터로 수정해서 한글 메시지 같은 것을 넣을 수 없다는> 문제점을 지적하신 것 같은데요. (\uXXXX 로 표현되는..)이게 긴가 민가 하다는 이야기였습니다. ^^--what we call human nature in actually is human habit.--http://gleamynode.net/

제목 : Re: XML 사용해서 성공했습니다 글쓴이: 박원호(guest) 2003/11/03 10:05:35 조회수:62 줄수:33

메세지 리소스 문제로 저도 고민하다가,XML 가지고 해결하는 방향으로 했습니다.PropertyMessageResources 클래스 대신에MessageResource 클래스를 상속받은 XMLMessageResource 라는 클래스를 작성해서해결했습니다.위에 박영록님이 말씀하신데로Property 정도의 수준으로 XML을 이용하기에는 낭비같지만,다국어 처리에는 이게 가장 쉽고 편한 방법인 것 같습니다.그리고, 데이터 형태도 "CDATA" 타입을 사용하면메세지 안에 내용도 HTML과 긴 내용도 사용이 가능합니다.리소스 관리 측면에서는,처음에 Resource가 초기화 될때 한번만 XML 파싱을 하고,로딩이 끝나면 내용을 "List" 구조에 넣어 두게 되므로성능에서는 큰 차이는 없을 듯 합니다.소스 파일은 첨부된걸 참고하세요.<message-resources null="false" factory="com.em.struts.util.XMLMessageResourcesFactory" parameter="com.em.strutsfile.ApplicationResources" />struts-config.xml 파일에 위의 내용을 추가해주셔야 합니다.그리고, 현재 첨부된 소스 파일은 JDOM을 이용해서 구현하였습니다.(XML 처리를 쉽게 하기 위해서.)필요하시다면 JAXP 등으로 구현하셔도 별로 어려움은 없을 듯 합니다.참고하세요. XMLMessageResources.zip (3120 Bytes) ApplicationResources.xml (1448 Bytes)

[펌] 자카르타 서브프로젝트 대강 훑어보기

 

 

출처 : www.jongsclub.com

 

자카르타 서브프로젝트 대강 흩어보기 [ 조회수: 553 ]

jakarta.apache.org 혹은 아파치 서브프로젝트 한글화 프로젝트인 http://jakarta.apache-korea.org/ 에 가시면 보다 상세한 정보를 얻을수 있습니다. ** 이페이지는 자카르타-서울 프로젝트에서 번역한 내용들의 서두부분만 발췌해온것에 불과합니다.그냥 한눈에 보기 편하달까?         아파치 앤트    아파치 앤트는 Java기반의 빌드 도구입니다.   make, gunmake,nmake,jam .. 같은 기존의 툴들은 멀티 플랫폼   에서 소프트웨어를 개발하는것을 고려하지 못했지만, 앤트는   쉘기반 명령어 대신 자바클래스를 사용하여 다양한 환경에서 이용및   확장 되고 xml을 기반으로 다양한 기능을 제공합니다.  Avalon은 공통의 프레임워크와 자바 언어로 작성된 어플리케이션의 컴포넌트를 생성, 디자인, 개발 및 유지하기 위한 프로젝트입니다....     캑터스는 서버측 자바 코드(서블릿, EJB, 태그, 필터 등)을    단위 시험하기 위한 간단한 시험 골격중의 하나입니다.       Commons는 자카르타의 새로운 서브프로젝트로서 재사용가능한 자바 콤퍼넌트들의 모든 측면에 포커스를 맞추고 있습니다. 자카르타 Commons 프로젝트는 두 부분으로 구성됩니다: The Commons Proper - 재사용가능한 자바 콤퍼넌트들의 창고. The Sandbox - 자바 콤퍼넌트 개발을 위한 작업공간. 콤퍼넌트 페이지는 현재 Sandbox와 Commons Proper 둘 다에서 이용가능한 콤퍼넌트들을 나열하고 있습니다.     자바 아파치 메일 엔터프라이즈 서버(일명 아파치 제임스)는 100% 순수 자바 서버이며, 현재 사용 가능한 오픈 프로토콜(SMTP, POP3, NNTP)에 완전하고 이식가능하게 설계된 엔터프라이즈 메일 엔진 솔루션이다. 또한, 제임스는 메일 애플리케이션 플랫폼이다. 제임스 프로젝트는 Apache Mailet API를 주관하고, 이 메일 애플리케이션 플랫폼 API의 구현을 제공한다. 제임스는 아파치 아바론 애플리케이션 프레임웍에 기반하였다. (아바론에 관한 더 많은 정보를 위해, 이곳을 참고하라. http://jakarta.apache.org/avalon)           Log4j를 사용하면 애플리케이션 바이너리를 수정하지 않아도 런타임시에 로깅 작업이 가능합니다. Log4j 패키지는 로깅 문장이 퍼포먼스 저하를 야기시키지 않는 채로 완성된 코드에 남아있을 수 있도록 설계되었습니다. 로깅 동작의 제어는 애플리케이션 바이너리를 건드리지 않고, 설정 파일만을 편집함으로써 가능합니다. POI 프로젝트는 마이크로소프트 OLE 2 복합도큐먼트포맷형식의 파일을 순수 자바를 이용하여 핸들링하는 APIs로 구성되어있습니다. OLE 2 복합도큐먼트포맷형식의 파일은 마이크로소프트 엑셀 혹은 워드파일 등의 대부분의 오피스파일들입니다.                                                                     Struts는 전형적 Model-View-Controller(MVC) 디자인 패러다임의 변화, 즉 Model2 접근법에 기반한 어플리케이션 아키텍쳐를 권장합니다. Struts는 자체적으로 컨트롤러 컴포넌트를 제공하며, Model과 View를 제공하기 위한 다른 기술들을 통합합니다. Model의 측면에서, Struts는 엔터프라이자 자바 빈즈, JDBC, 그리고 Object Relational Bridge를 포함한 어떠한 표준 데이타 접근 기술과도 상호작용 할 수 있습니다. View에 있어서 Struts는 자바서버 페이지, Velocity 템플릿, XSLT, 다른 표현 시스템과 잘 작동합니다. 이 프로젝트는 JSP커스텀태그 라이브러리와 TLV(TagLibraryValidator)클래스와 태그라이브러리를 지원하는 페이지제작도구와 같이 이 프로젝트와 관련있는 프로젝트들의 오픈소스 보관소이다. 태크라이브러리의 전반적인 설명은 여기를 보면된다. JSP(tm) 태그라이브러리. 벨로시티는 자바기반의 템플릿 엔진이다. 벨로시티를 이용하면 기본적으로 제공되는 자바코드들과 템플릿으로 보다쉽게 웹 사이트를 개발하수 있게 되며, 궁극적으로는 jsp난 php를 대체하는 효과를 목표로 하고 있다.    알렉산드라는 오픈소스 프로젝트시 CVS/Javadoc/Source code/Documentation 관리시스템 으로 이용하려한다. 이것의 목표는 프로젝트시 코드를 공유하고 소스코드를 이해하기 쉽게 돕는 광범위한 문서와소스의 체제 시스템을 구축하는 것이다.  ( 영어가 딸려서 좀 이상함 -_-?)     ecssms Element Construction Set  말그대로 HTML이나 XML관련 마크업 언어의 기능 요소들을 구현하기 위한 자바 API이다. 하지만 확장성이 좋기때문에 다른 마크업 언어 또한 역시 잘 지원한다.                  내용관리 구성 시스템 즉 CMS를 구현하는  low-level의 문서 관리 구조 이다. 슬라이드는 추상적인 여러 가지 데이터들을 계층적으로 분산시켜 저장할수 있고, 보안,잠금,내용, 버전관리 등도 지원한다. 슬라이드가 우수한것은 서블릿으로 구현된 WebDAV 접속 모듈을 지원하기 때문이다.

[펌] 실제 개발시 CVS와 ANT이용방법....

출처 : www.javaservice.net

 

 

이번 개발시에 cvs와 ant를 이용 웹 어플리케이션을 개발 하려고 합니다. 시나리오는 다음과 같습니다.1. cvs를 이용해 파일의 형상관리를 한다. 서버는 개발서버를 사용한다.2. 개발자들이 cvs 레파지토리에 올리고 브라우져로 바로 확인 할 수 있도록 레파지토리에 있는 내용을 자동으로 웹 어플리케이션에 올린다.3. 개발자들이 웹 브라우저에서 변경 사항을 확인한다.웹 서버와 cvs 레파지토리는 같은 서버입니다. 2번 단계에서 수정사항을 자동으로레파지토리에서 웹 어플리케이션 디렉토리로 복사하고 자바 파일(클래스 파일은레파지토리에 저장하지 않는 경우)인 경우 컴파일까지 자동으로 하려고 하는 부분에서 ant를 사용할 수 있을 것 같은데 이부분을 어떤 식으로 해결해야할지 궁금합니다. 비슷한 방법으로 사용하시는 분께 도움 구합니다.

제목 : Re: CVS와 ANT 글쓴이: 손권남(kwon37xi) 2004/02/15 20:14:36 조회수:87 줄수:34

우리 회사에서 쓰는 ant 파일입니다.모듈 이름을 proejct 라고 할 때의 가정입니다.CVS 의 모듈중에 바뀐 것들을 가져오고, 그 중 WEB-INF/classes 에 있는 자바 파일들응 자동으로 컴파일을 합니다.마지막의 copy 부분은 저희가 프로그램 짤때 *.properties 와 *.xml, *.xsl 들을리소스로서 읽으들이기 때문에 그것들도 또한 classes 디렉토리로 옮겨주는 것입니다. <target name="build" depends="prepare"> <cvs cvsRoot=":pserver:anoncvs@localhost:/var/cvs" package="project" /> <cvs command="update -A -d" dest="."/> <javac srcdir="project/WEB-INF/src" destdir="project/WEB-INF/classes" debug="on" failonerror="false" deprecation="on"> <include name="**/*.java"/> <classpath refid="xlms.classpath"/> </javac> <copy todir="project/WEB-INF/classes" overwrite="true"> <fileset dir="project/WEB-INF/src"> <include name="**/*.xml"/> <include name="**/*.xsl"/> <include name="**/*.properties"/> </fileset> </copy> </target>나도 expert가 될날이..

제목 : Re: 감사합니다.. 글쓴이: 손님(guest) 2004/02/15 22:32:33 조회수:10 줄수:2

감사합니다..많은 도움이 되겠군요...^^..잘사용하겠습니다.

제목 : Re: 톰캣에 있는 추천 웹개발 가이드 글쓴이: 허광남(heogn) 2004/02/17 09:54:35 조회수:37 줄수:14

웹 개발 경험을 토대로 정리된 개발 가이드입니다.소스 디렉토리, 디플로이 디렉토리, cvs 커맨드 사용법, build.xml 샘플 스크립트 등의 내용이 있습니다.문서 작성자는 Struts를 만든 Craig R. McClanahan 아저씨입니다.http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/processes.html번역링크http://jakarta.apache-korea.org/tomcat/tomcat-4.1-doc/appdev/processes.html----------------------------------------------------jsp/서블릿 정보공유; http://www.okjsp.pe.krjakarta 문서 한글화; http://jakarta.apache-korea.org----------------------------------------------------

[펌] Forrest

Forrest...

프로젝트 문서화를 해주는 유틸리티라네요...

한번 사용해 봐야 겠네요...

 

http://xml.apache-korea.org/

 

포레스트로 빌드를 하면 위 페이지 같이 문서화 할 수 있다는군요...

pdf로도 변환이 되구...

 

참고사이트

 

Forrest 프로젝트 사이트

http://xml.apache.org/forrest/

 

Cocoon프로젝트 사이트

http://cocoon.apache.org/

 

Cocoon한글 번역 사이트

http://cocoon.apache-korea.org/

 

 

[펌] 한글 &lt;-&gt; 영문 언어팩 손쉬운 변환방법

 

출처 : http://www.jlab.net/

 

 

언어팩을 설치해서 한글 플러그인 이클립스를 사용하다 보면 영문 플러그인 이클립스가 필요할 경우가 생깁니다.
 
eclipse -nl en_US
 
이렇게 실행할 경우 영문으로 이클립스 플랫폼이 시작됩니다. 단축아이콘이나 심볼릭 링크만 만들어두면 편리하게 사용할 수 있습니다.