SOAP 웹 서비스 명세를 하다보면,  여러개의 input을 넣고 싶은데 여러개의 part는 입력이 되질 않는다.

“이게 무슨 멍청이같은 인터페이스란 말인가?” 역시나 항상 느끼는 것이지만 SOA를 위한 기술들은 개발자들에게 위화감을 제대로 선물한다.
(혹자들은 SOAP이 SOA를 구성하는 가장 편한 기술로서 채택된 것은 그저 우연에 불과하다 라고 하는데 내 눈엔 둘 다 제대로 된 발전을 하지 않고 말만 많은 인간들 사이에서 나와서 똑같이 바보스럽다… 알만한 개발자들은 다 안다.)

SOAP 웹서비스에서 여러개의 Input Parameter를 넘기는 방법은 아래와 같이 두개가 있다.

1. Part를 하나 사용하는 경우 : 기본 SOAP에서 사용하는 데이터 타입인 Element는 내부에 다시 Primitive 타입들을 선언할 수 있다. 그 자체로서 복합 구조이므로 사실상 Part하나를 Element하나로 지정하여 사용해도 해당 서비스에게 여러개의 Input을 전달 할 수 있다.

2. Part를 여러개 사용하는 경우 : Part를 여러개 선언하고 type을 지정해 주는 방법이다.

1번 방법을 사용할 수 있지만, 대부분의 Eclipse를 사용한 개발자는 BPEL Designer GUI를 사용하게 될거고, WSDL이 이쁘게 보이는데 본능적으로 Part를 여러개 두어서 보기 좋게 하고 싶을것이다.

2번 방법을 하고자 할때 [ERROR] More than one part for message 같은 황당한 Error를 맞는 이유는 Multi-part는 RPC-style에서만 사용가능하기 때문이다. Document-style은 1번 방법만을 지원한다.

기본 구성으로 WSDL을 생성하면 다음과 같이 element가 선언된다. (PrintOut은 임의로 지정한 값)

<element name=”PrintOutRequest”>

<complexType>

<sequence>

<element name=”input” type=”string”/>

</sequence>

</complexType>

</element>

<element name=”PrintOutResponse”>

<complexType>

<sequence>

<element name=”result” type=”string”/>

</sequence>

</complexType>

</element>

<message name=”PrintOutRequestMessage”>

<part name=”payload” element=”tns:PrintOutRequest”/>

</message>

<message name=”PrintOutResponseMessage”>

<part name=”payload” element=”tns:PrintOutResponse”/>

</message>

<message name=”PrintOutRequestMessage”>

<part name=”payload” type=”p:string” />

<part name=”payload2″ type=”p:string”/>

</message>

<message name=”PrintOutResponseMessage”>

<part name=”payload” type=”p:string”/>

</message>

<binding name=”PrintOutBinding” type=”tns:PrintOut”>

<soap:binding style=”rpc”    

transport=”http://schemas.xmlsoap.org/soap/http” />

<operation name=”process”>

<soap:operation

soapAction=”http://print.bpel.tps/process” style=”rpc” />

<input>

<soap:body namespace=”http://print.bpel.tps” use=”literal”/>    

</input>

<output>

<soap:body namespace=”http://print.bpel.tps” use=”literal” />

</output>

</operation>

</binding>

• Jersey Archive

현재 Jersey 홈페이지에서 다운받을수 있는 최선 버전은 1.5 이며, 다운 후 압축을 풀면 11개의 Archive가 나온다.
저는 귀찮아서 다 import했으므로, 좀더 경량화 된  구현물을 원하신다면 스펙을 보고 필요한것만 추가하길 권장합니다.
(jackson 도 들어있으므로 json을 쓰지 않거나, 특정 다른 json처리 api를 쓰는경우 빼셔도 무방합니다.)

• Jersey 클라이언트 기초

Jersey 클라이언트 API를 사용하기 위해서는 Client 클래스의 객체를 생성해야한다.

import com.sun.jersey.api.client.Client;
Client client = Client.create();

Client 클래스는 jersey를 통해 RESTful 클라이언트를 구성하기 위한 기본객체이다. Client 클래스를 사용하여 클라이언트 기능을 구성하고 목표 RESTful 서비스 공급자를 지정한다.

클라이언트의 요청을 보내기위해서는 웹 리소스를 캡슐화하는 WebResouce개체를 만들어야 한다.

import com.sun.jersey.api.client.WebResource
WebResource webResource = client.resource(“http://yonghyun.net/restservice” );

이와 같이 정의한 후에는 해당 URI를 향해 HTTP GET, PUT, POST, DELETE Action을 요청할수 있다.  
(yonghyun.net에 restservice는 없는 SEI 입니다. 요청을 보내실경우 404 Error만 돌아올뿐입니다.
예제일 뿐이니 사용하고자 하는 SEI를 입력하시기 바랍니다. )

GET 요청 :  String s = webResource.get(String.class);

GET Action은 위와 같이 쉽게 보낼수 있고 Parameter Passing은 MultivaluedMap 클래스를 통해서 지정할수 있다.

MultivaluedMap queryParams = new MultivaluedMapImpl();
queryParams.add("param1", "val1");
queryParams.add("param2", "val2");
String s = webResource.queryParams(queryParams).get(String.class);

이는 다음과 같은 요청을 보내는 형태이다.

http://yonghyun.net/restservice?param1=val1&param2=val2

이와 같이 쉽게 클라이언트를 구성할수 있다. Jackson을 사용하여 JSON을 자바 객체로 파싱해 넣는다던지, BASE64 Encoding을 위한 Filter방법은 후에 업데이트 한다.

이녀석을 얻고 싶어서, 정말 많은 중고차 딜러들을 찾아다녔고 10대가 넘는녀석을 몰아보았고 계약다하고 파기도 당하고 별별 일이 많았는데, 결국은 얻었다.

남자는 (내같은 성격의 녀석은 더욱 ㅋ) 차에게 빠지기 마련이다.
어린나이에 좋은차 한번 몰아보자! 라는 생각에 겉멋든 외제차와 스포츠카만 찾아보곤 했는데,
…. 지금도 어리지만.. 더 어릴때 싸질러놓은 일들을 처리해야 하기에 여유가 없단걸 깨달았다.
나란녀석 ….ㅡㅜ 뭐 그리 질풍노도의 사춘기를 20대 중반까지 즐겼는지..

차는 사고 싶고,,..  하지만 돈은 없고, ….. 또 하지만 평범한 차는 죽어도 타기 싫었다.
그렇게 찾다 찾다 하다보니 나타난 레!!!토!!!나!!!

엄청 개성넘치는 데다가!!
사나이다운 매력이 터져나오고!!
결정적으로 가격이 200만원 후반대 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이녀석 정말 멋진녀석이다.
98~99년도 즈음부터 몇년간 군납을 했기 때문에, 군용짚차로 더 많이 알려진 녀석.

4륜구동으로 넘치는 힘에
등판각도 55도까지 올라간다.

생긴것도 완전 클래식한게 딱 내 스타일이다.

오프로드…

차를 타고 산을 헤집고 다니면서,…
뒷 좌석에는 온갖 잡다한 내 물건들을 싣고…
거친 엔진소리 내면서 돌아다니고 있는데,
몇년 같이 살면 엄청나게 추억을 쌓아갈것 같다.

하드코어하게
아무데나 뚫고 다니진 않을테지만 ㅋ
댐이나 강변 적절한 언덕이나 공터에 나를 내던질수 있다.

젊은 나이 아니면
이렇게 거친 차 한번 몰아보기 힘들것 같단 마음에 골랐지만,
정말 남자의 영혼을 자유롭게 만들어주는 녀석이다.

보잉선글라스 끼고 창문 열고 올드한 곡 틀어제끼면서
기어 변속하며 다니면 기분이 다풀린다.

싸게 샀지만, 다들 말하듯이 벌써부터 돈 왕창 깨지고는 있다 ㅋㅋ
오래된 녀석이고
전 차주께서 장기정비 소모품 같은걸 바꿀때가 됬으니 싸게 주셧겠지 ㅡㅜ

타임벨트랑 클러치디스크 등 갈아주고 잘 정비해서 오래도록 타야겠다. ㅋ

요즘 Exception을 정의해서 사용하느라 자주보게 되는데, 뭔지 잘 모르고 있다가.
궁금해서 Java Tutorial을 찾아보았다.

serialVersionUID는 serialize (직렬화)를 할때 메타 정보로 저장되는 id값이다.
객체를 직렬화 해서 전달하고 다시 역직렬화 할때 데이터파일에 저장되있는 serialVersionUID를 확인한다.

이 ID를 확인하는 이유는 소프트웨어는 시간이 흐르면서 버전이 바뀌기 마련인데,
원격지와 로컬의 버전이 같은지를 확인해주는 일종의 장치라고 생각할수 있겠다.

이게 warning인 이유는 대개 보통의 로컬 Java 프로그램은 직렬화 할 일이 없을뿐더러,
혹시 직렬화할일이 생기더라도 컴파일러가 알아서 해주기 때문에 신경쓰지 않아도 된다.

하지만, 개발을 오래 하다보면 노란줄만 봐도 짜증이 생기게 되는데 그럴땐 그냥 ctrl + 1 누르면 Default로 알아서 넣어준다.
(그것도 아주 황당한 숫자..)

나의 경우에는 모조리 그냥 1로 때려 넣는다. (Java Compiler로 별로 나와 다를건 없음 ㅋㅋ)
private static final long serialVersionUID = 1;

이래놓고 나는 평안한 표정을 지으며, 그냥 다시 하려던 부분을 구현한다 ㅡㅂㅡ;;;~~~

아마 이걸로 언젠간 … 고생을 할지도 모른다.
하지만 exception에 serialVersionUID라고 뜰 것이기 때문에, 그냥 넘어가는 인간미도 좀 있어야 ..

… 황당한 지옥구경도 하고 그러는 거겠지ㅋㅋ

몇년전에 처음 이녀석을 봤을때 엄청 땡겼는데,
요즘 개발업무의 과중한 스트레스에 시달리던 중 질러버렸다.

와우도 꽤 오래 끊었는데,……
한…

…

한달은… 안 들어간거 같다…. (더 짧은가…?..)

난 뭐 디바이스 매니아들처럼 분석하거나 그런 멋진 포스팅능력은 없으니까.
 그냥 감격을 끄적여 놓자면 간지하나는 확실하다. 버튼도 기본 세팅외에 12개를 더 사용할수 있다.

후……. 어쩔수 없이 또 투기장의 거친 격노한!!! 냉혹한!!!!!!!! 분노의!!!!!!!!!!!!!!!!! 한 그루  힐 주는 나무가 되어야 하나….

읭(?) …

아쉬운 점이 있다면, 좀 가볍다.
생긴건 방패처럼생겨가지곤 묵직했으면 좋으련만… 쇠같은 느낌이 있었으면 좋을텐데.

근데, 간지위엄 하나는 쩐다… 불도 들어오는데 진짜 멋지다.

마우스 세팅에서 불빛 색도 바꿀 수 있다.

어쨋든, 난 이놈을 얻었기 때문에 와우를 할수 밖에 없다.
변명이 아니다. 이건 숙명이네(?)ㅋㅋㅋ

POJO의 등장

POJO란 Plain Old Java Object의 줄임말입니다. 꽤 오래된 단어죠. 최근 자바의 엔터프라이즈 기술을 필연적으로 사용할수 밖에없는 분야에 발을 들여놨기때문에 다시 보게 되었는데 느끼는게 참 많은 개념입니다. 그 등장과 발전되는 양상이 시사해주는 점들은 특별한 의미를 가지고 있습니다.

POJO의 등장은 다음과 같습니다. Refactoring의 저자이며, 식견있고 훌륭한 오피니언 리더로서 이름나 있는 마틴 파울러(Martin Fowler)가 2000년도에 한 컨퍼런스에서 다음과 같이 말을 하면서 POJO는 세상에 나타났습니다.

“We wondered why people were so against using reqular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it is caught on very nicely”

이 말을 의미는 아마도 그 철학적인 완전성을 위해 마구 비대해지고 있던 J2EE에 대한 일침이었습니다. 즉, EJB보다는 단순하고 원시적인 Java Object에 해당 도메인 로직을 넣어 사용하는것이 더 좋다. 어째서 사람들은 EJB가 아닌 평범한 Java Object를 사용하지 않는가? 아무래도 그건 단순한 Java Object에는 멋진 이름이 없기 때문이다. 개발자들은 기술에 있어서 멋들어진 이름 또한 중요하기 때문이죠. 새로운 기술이 었기 때문에 뒤쳐지지 않기 위해서 앞뒤양옆을 보지 못하고 더 첨예하고 완성도 높은 기술만을 바라보면서 달려 나왔습니다. 마틴 파울러는 멋져보이는 이름을 다시 원시 Java Object에 붙임으로써 사람들이 객체지향에 대한 반성을 다시 할수 있게 해주었습니다.  – (아주 단순하면서도 이렇게 멋진 발표는 역사상 별로 없을것만 같습니다.)

EJB와 POJO

POJO가 등장하게 된 기술적인 배경을 조금 더 보자면 아주 논리 정연하고 소프트웨어 진화에 대한 한 단면을 볼수 있습니다. 아주 훌륭한 모범예제라고 할수 있죠. 먼저 EJB가 먼저 오래도록 사랑(?) 받아온 이유를 돌아보자면 다음과 같습니다. EJB는 J2EE의 살아있는 화신이라고 할 만큼 자바의 엔터프라이즈 기술을 선도해 왔습니다. EJB의 장점은 엔터프라이즈 애플리케이션에서 필연적으로 요구하는 다양한 기능들을 거의 빠짐없이 제공한다는 것입니다. 특히, 더 멋진 점은 애플리케이션에서 분리해서 서비스 형태로 제공하는 점입니다. (요즘은 안 그런 기술이 없습니다만, 이 당시는 EJB의 자태가 독보적이고 참 아름다웠다고들 합니다.) EJB는 응용 서비스에 대한 컨테이너 기능 및 데이터베이스와 연산 리소스들을 관리하는 기능 등을 제공해주었고 ‘개발자들이 여러가지 환경적인 문제들 보다는 비지니스 로직 자체에 대해 집중하여 개발할수 있다’는 것을 실현시켜주었습니다.

엔터프라이즈 기술에서 종합선물세트와 같은 거대한 능력을 가진 EJB는 아주 불행한 실수를 저지르고 말았습니다.

- EJB는 극소수의 애플리케이션에서만 필요로하는 다중 데이터베이스를 위한 글로벌 분산 트랜잭션(JTA)과 같은 복잡하고 무거운 기능을 강요하는 경향이 있습니다.

- 보통의 중소형 프로젝트에서 사용하기에는 단가가 너무 쎈 WAS를 요구합니다. (요즘에는 활발히 발전하고있는 Geronimo를 쓰면 되긴 하죠. 글을 작성하고 있는 지금에도 Dev-Mailing List로 JIRA Comment가 마구 쏟아져 들어옵니다.)

- 제일 문제라고 생각하는 것은 훌륭한 IDE없이는 (사실 요즘에는 이클립스 플러그인들이 너무 훌륭해서요.. 괜찮긴 합니다만,.. ) 엄청나게 복잡한 설정 파일속에서 개발자들의 정신이 아찔해진다는 점입니다. 저는 표준적인 스펙과 다양한 팁이 있는 훌륭한 문서들을 가지고 있지만 직접 작성할라면 한 세월 걸립니다. (사실 저는 XML 다루는데 재주가 없습니다.)
자동화된 툴들이 해주는 일가지고 왜 바보같이 하고 앉았냐? 라고 하실수 있지만 제 개발 철학상 손으로 다 하진 않더라도 머리속에는 다 그려야 합니다. 조금 더 복잡해지면 전 더이상 개발을 할수 없는 시대의 탈락자가 될지 모르죠.^^

- EJB로 제작된 컴포넌트는 컨테이너 밖에서는 정상적으로 동작하지 않습니다. 앞서 말한것과 이어지는 맥락입니다. 아주 간소화한 컨테이너 환경을 작성해서 수행해도 되지만, 결국 개발중에 만나는 수정-빌드-배포-테스트의 되풀이 속에서 우리는 제정신을 유지 하기 힘들거나, 도를 깨우치게 됩니다.

결국 EJB는 엔터프라이즈 응용 개발자들에게 완벽한 환경을 제공해주며 “비지니스 로직”에만 집중할수 있게 해주겠다!라는 야심찬 포부와 함께 등장했지만 너무 무거워져 버렸습니다. 다양한 요구들이 섬세한 고찰 없이 합해져왔기 때문입니다.

무분별한 기술적 완성도를 추구하는 가운데 EJB는 객체지향이라는 근본도 잃어버린 모습을 갖추게 되었습니다. 결국 마틴 파울러와 레베카 파슨과 같은 Opinion Leader들이 EJB의 발전에 대해 반성하고  객체지향 원리에 따라 기본에 충실하게 비지니스 로직을 구현하는 POJO방식으로 회귀하자고 주장하면서 다시 훌륭한 진화의 길로 접어들게 되었습니다.

오늘 이런 오래된 내용을 포스팅 한데에는 두 가지 이유가 있습니다. 첫째로, 소프트웨어 (비록 모든 소프트웨어 개발분야에 적용할순 없을지라도) 개발에 대한 진화의 정말 멋진 예라고 생각되었기 때문입니다. 사실 Computer Science/Engineering 에 국한되지 않고 그저 발전방향/진화양상 이라는 면만봐도 꽤 멋집니다.

둘째로는, 많은 사람들이 EJB와 SPRING을 Versus관계로 보는 경향이 있어서 한번 쯤 이런 내용을 정리하고 가고싶었기 때문입니다. 사실 EJB vs SPRING으로 비교하는것이 아니라 EJB 와 POJO를 비교한 후에 POJO를 효과적으로 지원하는 Framework로서의 SPRING을 바라봐야 한다고 생각합니다.
EJB가 가진 기능을 SPRING에서 많이 커버해주기 때문에, ’EJB가 더 낫다. SPRING이 더 낫다.’ 라는 분쟁이 넷상에 꽤 많은데 제가 생각하기에 좀 더 본질적인것은 EJB에 대한 고민과 POJO의 등장이 보여준다고 생각합니다.

혹시 어떻게 지나가시다가 들리셨는데 2010년에 이런 글을 썻다고, 기분이 얹짢아 질수도 있는 컴퓨터 공학도 및 개발자 분들을 위해 PS를 넣자면,

P.S : 사실 EJB 3 부터는 많은 부분이 수정 보완되었고 훌륭한 개념도 많이 추가되었습니다. 일례로 엔티티 빈 대신에 JPA를 이용한  데이터 영속성 처리등이 있습니다. 앞으로 다양한 프레임워크(struts, SPRING, iBatis, Hibernate)들과 비지니스 툴(BPEL2J)등을 정리할 것인데 그전에 단편적으로 제 생각을 조금 끄적여 본것뿐입니다 ^^. 물론 EJB 3.1 에 대해서도 객관적으로 정리해서 포스팅 할 생각입니다.

ㅡㅡ   ㅡㅜ   ㅜㅜ   ㅠㅜ

2010.03.21   09/10  EPL 31 Round 맨유 vs 리버풀전에서

지성형이 골을 넣었습니다. 그것도 결승 역전골 으헝헝허엏어헝헝헝 흐규흐규흐규

플레쳐의 크로스에 맞추는 돌진 다이빙 헤딩 슛!!

 지성형님의 가슴팍 세러모니와 환장하는 나니 

 형님 점프 세러모니

세러모니 브뤠이커 플레쳐는 크로스를 올린관계로

함께하지 못한 아쉬움이 있었습니다.

 뒤늦게 와서 담담한 하이파이브

플레쳐 답지 못했음…. 왠지 기대하게 되는

플레쳐의 세러모니 훼방질(?)이 안나와서…

 아아 밀란전 골도 그렇고

요즘 박지성 형님때문에 주말마다 쫄깃한 경기 볼수 있어서 너무  즐겁다

경기내내 열심히 뛰는 모습이야 당연하고

공미로 나와서 PSV시절 간지 나오나 하고 엄청 기대하고 봤는데

문전앞 중거리 슛팅도 좋았고, 여러번 헤딩도 좋았다.

남은 리그랑 챔스경기도 다 챙겨봐야지

 마지막은 제일 멋진 사진으로 남겨야 겠음.

뭔가 느낀게 있습니다.
아주 좋은 깨달음이라 참 다행입니다.

연구하고, 새로운 기술을 만들고, 새로운 생각을 퍼뜨리고 하자면 완벽해야 합니다.
저는 아직 제 무대를 만들지 못했다는것을 알았습니다.

제대로 된 무대를 만들고, 그 위에 올라서서 의미있는 행동을 하고자 합니다.

빨리 더 많이 더 넓게 더 깊게 공부를 해야겠습니다.
지금은 시간이 많으니까 말입니다.

DB는 다시 공부를 시작할 생각입니다.
세세하게 빠짐없이 볼것입니다.
마치 구구단을 외듯이 말입니다. 그 정도로 머리에 다져야겠습니다.
스스로에게 거짓말은 다시는 치지 말아야겠습니다.

제 연구방법은 앞으로는 상상하고 검증하는게 아니라, “이번에는 이것을 할 차례다.” 라는 식으로 순차적으로 나가고자 합니다.

즉흥곡은 그만 쓸때가 됬습니다.
이젠 교향곡을 써야죠.

“error while loading shared libraries:

libstdc++.so.5: cannot open shared object file: No such file or directory”

Synaptic을 사용하지 않고, 바이너리 파일을 다운받아서 설치를 할 경우에 심심치 않게 보는 에러입니다.
보시는 바와 같이 라이브러리 경로상에 libstdc++ 가 없기때문입니다.
저는 J2EE를 깔기 위해서 이녀석과 싸웠는데, 많은 사람들이 이녀석때문에 짜증을 경험하고 이녀석을 얻는 방법을 올려주셨더라고요.

일반적으로 많이 올려주신 방법으로는 (1) 쉘창에서 aptitude 명령을 통해 얻는 방법이 있습니다.

~#> aptitude install libstdc++

을 할경우엔 현재에는 libstdc++6 가 깔리게 됩니다. 일반 Karmic 저장소에 version 6 이 있기 때문입니다.

그러나 J2EE는 libstdc++5만을 원하기 때문에, 성질머리를 맞춰주기 위해서… 우리는 version 5를 구해야만 합니다.
(대부분의 많은 프로그램들은 libstdc++6으로 설치가 되긴 합니다. 그러나, 몇몇의 소프트웨어는 libstdc++5를 연결해줘야만 합니다. Sun의 J2EE가 바로 그렇습니다.)

(2) 아래의 방법으로 libstdc++5를 구하시면 됩니다.

1. deb 패키지를 다운로드합니다.

~#> wget -c http://lug.mtu.edu/ubuntu/pool/main/g/gcc-3.3/libstdc++5_3.3.6-10_amd64.deb

2.패키지 압축을 풉니다.

~#> dpkg  -x  libstdc++5_3.3.6-10_amd64.deb  libstdc++5

3. /lib 로 libstdc++라이브러리를 복사합니다.

~#> sudo  cp  libstdc++5/usr/lib/libstdc++.so.5.0.7  /lib

4.  /lib 로 이동한 후에 심볼릭(symbolic) 링크를 걸어줍니다.

/lib#>sudo ln -s libstdc++.so.5.0.7  libstdc++.so.5

(예제 에서는 일반적인 라이브러리 경로인 /lib로 복사하였지만, /usr/lib 이나 /lib32등 설치 프로그램이 찾는 PATH로 넣어주시는 것이 좋습니다. ldd 명령어로 확인하고 복사하세요.)
이와 같은 방법으로 libstdc++를 필요로하는 Binary install 프로그램들을 설치 하실수 있습니다.

이제는 대전 에트리 기숙사에 둥지도 틀었고,
생활세팅도 거의 마쳤으니 알찬 2010년을 시작해야겠다.

오늘은 그냥 잡담이나 좀 끄적여 놓자면,

1. 그동안 블로깅 뭐 이렇게 허접하게 했던가에 대해 반성하고, 이제 차곡차곡 정리 잘해서 쓸만한 것들을 모아야
     겠다는 생각을 했다.

2. 에트리 기숙사는 몇몇분들 블로그나 게시판 입담들을 통해 대강 알고 있었지만 생각만큼 지옥은 아니다.
     일단 나의 경우엔 룸메형도 매우 좋은 사람이고,  인터넷 속도 하나는 기가막히가 빠르네.
     매점에서 소주, 맥주도 팔고. 특이하게 밤 12시까지 안주도 판다. (계란말이, 찜, 볶음류 등등..)
     방이 좀 춥지만, 현재 회사도 안나가고 그저 뒹굴거리면서 책보고있기 때문에 귤까먹으면서 이불안에 있으면 됨.
     아쉽게도 카메라를 들고내려오질 않아서 전혀 방을 찍어 올리지를 못함
    

3. 원체 내가 좀 이상한 시도를 많이 하는 타입인데, 경제학 공부를 좀 본격적으로 시작했다. 
     사실 조금이라도 나이 어릴때, 하나 더 전문적인 지식을 얻고 싶은 마음에 열과 성을 다하고있다. 
     나름 전공이 데이터베이스, 데이터를 가지고 어떻게 추출하고 응용하고 관리하고 해서 전혀 생각지 못한 정보를
     뽑아내느냐가 나의 연구와 삶의 목적이기 때문에 개인적으로 가장 흥미로운 주제를 대상 데이터로 잡은것이다.
     (이건 좀 말이 마이닝에 가깝네.. 데이터베이스와 데이터마이닝을 헷갈릴정도의 바보는 아님을 밝혀두고 싶음..)
    

     궁극적인 목적으로는 관계형 네트워크 데이터 모델을 통해 경제적, 정치적, 사회적 현상에 대한 새로운 정보를
     추출하고 그 정보에 대한 간단명료한 의의를 정의하는것이다.

     아무것도 아닌거 하고있는데… 말이 심하게 거창하네.  
     여간 에트리에서의 나의 업무와는 상관없이 이는 내 삶의 주축이니까, 절대 게을리 하지 않을것이다.

4. 썸네일 그림은 80년대 하던 패밀리 게임 시작 화면에서 잘라왔음
     저 Press Start 문구는, 꼬맹이에게도 왠지모를 비장함을 안겨줬던 기억때문에 항상 설레임

4-1. 역시 Press Start 는 각진 저비트 느낌의 글체가 제맛!
4-2. 2010년도 Start 누르고, 멋지게 클리어 해야지