It's Myself

만들고 싶은게 무척 많은데, 간단한 것 부터 출발하자는 생각으로 시작했다.

메인 아이디어는 Google Calendar의 기념일 관리도구를 하나 만들려고 한다.
다만, 음력으로 된 기념일을 등록/수정/삭제가 가능한 도구이라는 것.

전에 ical 파일을 만들어 이 파일을 Google Calendar에 등록하는 방법이 있어 해봤다.
원리는 음력의 기념일을 기준으로 매년 양력일자를 ical 내에 미리 넣어주는 방법.
그래서 해당 양력일자의 일정을 Google Calendar에 우겨 넣는 것이다.

다 좋은데, 문제는 일정 수정이나 삭제할 때, 우겨 넣은 모든 일정을 일일히 찾아 지워야 한다는 점이다.

예를 들어 음력 6월 1일이라고 하면, 그에 맞는 양력 일자를 2011년, 2012년, 2013년... 2020년 양력 날짜가 쫙 생긴다. 11년에서 20년까지면 무려 9개. 그 9개의 날짜가 조금만 틀려도 매년 달력으로 넘어가서 수정/삭제를 해줘야 한다.
기념일이 한 개정도면 귀찮아서 그렇지 그냥 그냥 하면 되지만, 이게 20개 정도만 되면, 슬슬 머리가 아파오기 시작한다.

그래서 이것을 Windows 기반의 어플리케이션으로 만들어 관리하려고 한다. 그리고 그 관리도구를 만들기 위한 장소를 네이버 개발자에 넣었고, 네이버 개발자 사이트에서 제공하는 SVN에 등록하려고 한다.

사이트는 http://dev.naver.com/projects/googlecalendarm 이며, 틈 나는 대로 적용하려고 한다.

전문적으로 개발하는 것은 아니고, 어디까지나 취미로 시작했던 작업이다.

기존에 Azuare로 구현했던 내용을 이번에는 Google Apps Engine으로 개발한 것이다.

아마도 단순 접근성으로 따지면 단연 Google Apps Engine인 것 같다.

제일 먼저 높은 점수로 줄 수 있는 부분은 대부분의 비용이 Free 라는 사실이다.

이거 때문에, Azure에서 이 Google Apps Engine을 선택한 주요한 원인이니까,

상당한 매리트였다.

그리고 Java 지원. 사실 지금 그나마 다룰 줄 언어는 C/C++, C#, Java 뿐이니, Python이라든가, Peal 이렇게 나왔으면 아마도 GG였을 것 같다. Google Apps Engine 초창기는 Python 이라고 했는데, 그 당시의 생각만 했다면 접근 불가였을 것이다. 그런 시스템이 지금은 Java를 훌륭하게 지원한다.

다음은 시작하기 가뿐한 Start up Tutorial 이다. 이것 따라하기만 하면 금방 개념이라든가

처리하는 방법을 배울 수 있었다. 훌륭한 내용이지 않을까 싶다.

그러나, 이런 훌륭한 접근성에 비해 마음에 안드는 부분이 있기는 했다.

제일 먼저 Back 단에서 처리하는 작업을 하기 위한 일종의 Service 개념이 없었다.

지금까지 찾아서 확인한 것 까지 본다면, JSP 페이지와 같은 I/F를 통해 Request/Response 기반의

작업 뿐인 것 같다. 물론 cron 이나, queue와 같은 것들을 활용하여,

각 Request를 마치 Service 처럼 구성하면 될지는 모르겠지만…

처음에 아무 생각없이 Azure에서 구현한 방식대로 구현한 뒤, 내 PC에서 돌릴 때는 문제가 없었다가,

이번에 처음으로 Google Apps Engine에 올려보니, 역시 Request Time out 이 발생하였다.

아마도 Request가 들어오게 되면 처리하는 내용이 많다보니, Response까지 나오는 시간이

의외로 많이 걸리게 되었는데, 바로 걸려 버리는 문제가 발생했다.

일단, 소정의 목적만 달성하고, 현재는 재설계 계획 중이다.

Response가 빠르게 할 수 있도록 Job을 Page 단위로 분해하여 재조립을 해야 할 필요가 느껴졌다.

여튼 현재로는 Back 단에서 서비스 처럼 동작하는 부분이 없다는 약점만은 어떻게든 보완할 필요가 있다.
( 최소한 Azure에는 Worker 라는 개념이 있고, Amazone 에서는 Enterprise 서비스를 활용하면 그 안에서 처리할 방법이 있는 것 같다. )

Java로 웹 서비스 같은 것을 개발할 계획이라면, 한번 활용해 보는 것도 나쁘지 않을 것 같다!!

The Windows Azure development fabric and development storage are running on a 32-bit workstation. In the cloud, Windows Azure Hosted Services run in a 64-bit environment. The use of native code execution or .Net Full Trust features such as P/Invoke may require migration to 64-bit. See http://go.microsoft.com/fwlink/?LinkId=145047 for details.

다음과 같은 경우에는 조심해야 할 것같다.

Role 구성시 FastCGI를 사용하는 경우.
서브 프로세스를 생성하는 경우.
P/Invoke를 사용해서 내장 라이브러리를 호출하는 경우.

즉, 순수 .NET으로 구성하거나, 시스템과 직접적으로 부딛히는 경우가 없다면 전혀 신경 쓸 필요 없다는 사실.
x85이나 x64나... 뭐...