우리 기쁨을 나눠요^^

블로그용 Google Gadget.

작성해서 웹으로 올리는 보통의 방식과 달리 웹에서 만들고, 웹 상에서 저장해서 어디든지 에디터(Google gadget editor) 불러들여 수정할 수 있는 것이 편했습니다. (컴퓨터에 관계없이 계속 작업을 이어나갈 수 있으니까요.)

웹 상에 저장하는 것은 구글에서 서브버전(SVN) 소스관리 프로그램을 웹 서버에서 제공해서 이용하는 방법도 제공해서 개발자의 편의를 많이 봐주고 있다는 느낌이 들었습니다. 구글에서 버그 관리 프로그램은 제공 안 해주나 모르겠습니다^^;
(일할 때 쓰는 멘티스는 서버에 설치를 하는 방식이라서 개인적인 용도로 사용할 만한 이슈 트래커가 없거든요 ㅡㅜ)


그보다도 웹에 저장할 때 같은 파일이면 항상 같은 번호를 갖고, 같은 장소에 저장이 되는 것 같습니다. 가젯을 만들어서 배포했는데 버그가 발견되어서 다시 전부 재배포하려면 큰 일이죠? 그런데 기존에 웹에 올라가 있는 가젯이 자동 교체되는 방식이라서 자동 업데이트 효과가 있어서 편합니다. (저번에 발견된 버그를 고치면서 잠시 잘 못 고친게 있어서 하루가 지나니 또 다른 버그가 생겼더군요 ㅡㅠ 바로 찾아서 고쳤더니 배포된 곳도 자동으로 고쳐졌습니다 :)

주일 말씀을 들으면서 평소에도 쉽게 성경을 읽으면서 말씀으로부터 힘과 지혜를 공급받았으면 좋겠다는 생각이 들었습니다. 하는 일이 계속 뭔가 만드는 일이다보니, 이 때 떠오른 것이 구글에서 제공하는 가젯 프로그램이었습니다.

처음엔 구글 가젯으로 만들면, 블로그에도 툴바에도 데스크탑에서도 돌릴 수 있다고 생각했는데 후딱 블로그용 가젯을 만들어 놓고 데스크탑엔 어떻게 적용하나 봤더니, 그냥 가젯하고 데스크탑 가젯하곤 다르더군요. 거의 새로 배워서 만드는 거랑 비슷하네요.

어쨌든 블로그용으로 만든 것은 다음과 같습니다.



내 구글 홈페이지에 추가하기 -->

구글 홈페이지에 추가하려면 위 링크를 누르면 되고, 일반 블로그에 추가 시키려면 다음 코드를 붙여 넣으면 됩니다.


오늘의 말씀의 본문을 계속 띄워놓을 수 있어서 다시 기억하는 데 도움이 되게 만들었는데, 원래 처음 생각은 본문 범위(예: 고전 14:1-10)를 클릭하면 온라인 성경 사이트로 연결해서 해당 장(고린도전서 14장)을 볼 수 있게 할 계획이었습니다. 이를 구현하기 위해서 해쉬맵을 사용할 수 있으면 편해지는데, 지금 만들어져 있는 옛 가젯버전(legacy gadget  API)에서는 지원하지 않는 것 같아서 바꾸기전에 우선 데스크탑 가젯부터 만들기로 결정했습니다.

개발자 노트 더보기

참석하기 전 두 가지 걱정/의문이 있었습니다.



이러한 것을 제외할지라도 같은 분야에서 활동하는 여러 개발자들을 만날 수 있다는 것만으로도 설레이는 맘으로 참석했습니다.

이런저런 걱정은 아이스 브레이크를 시작하면서 사라졌습니다. 여러가지  분야의 사람들이 모여서 참석하게 된 동기라던가 하고 싶은 것을 발표할 때 이번 대회에서 경험하게 될 것에 대한 커진 기대감이 걱정을 잊게 해주었습니다.


전체적인 안목을 갖게 해준 API 소개 시간

API 소개도 단순한 기능 소개를 넘어서 전체적인 로드맵을 보여줌으로서, 어떻게 가치를 확장해 나가는지, 무엇을 신경써야 하는지, 왜 그것이 중요한지 등을 많이 생각하게 해 준 시간이었습니다.


메쉬업을 친근하게 만들어 준 실습 시간, 그리고 퀴즈?

또 실습시간의 몇 개의 퀴즈를 통해서 메쉬업이 기술적으로 쉽게 구현할 수 있음을 알려주고, 어렵게만 생각하던 제게 가벼운 맘으로 다가갈 수 있는 계기를 마련해 주어서 감사했습니다.

개인적으로 일이 많아서 DevDay에 오면서 준비도 잘 못하고, 컴퓨터 설정도 잘 안 되어서 제대로 실습하기 어려운 점도 있지만, 정말 3시간 동안 간단한 프로그램을 재미있게 작성하시는 분들을 통해 도전을 받고, 즐거운 시간을 가졌습니다.


앞으로 이런 기회들이 많이 생겨서 생각의 폭을 넓혀지고, 우리나라에 참신하고 사용자에게 필요한 서비스가 많이 생겨나는 계기가 되었으면 좋겠습니다 ^^*

매쉬업 캠프의 지도 API 3번째 문제는 이벤트만 제대로 이용하면 쉽게 풀 수 있는 문제가 나와서 의외였습니다.

간단히 말하면, 다음 지도에서 조정하는데로 따라 움직이는 야후의 위성지도라 할까요?

그림으로 보면 다음과 같습니다.


조건:


위 두 조건을 맞추려면, 한 쪽 기능 다 끄고, 좌표만 맞춰주고 축척만 맞춰주면 됩니다.
실제로 서비스하기엔 딜레이가 심해서 힘들지만 재미있는 예제입니다.

* 처음에 지도가 잘 안 나와서 왜 그런가 했더니, utf-8로 맞춰줘야 하더군요. 너무 간단한 거라서 잠시 당황했습니다 ㅡ.ㅡ

매쉬업 캠프 가기 전 돌발 퀴즈가 나온다고 하기에 문제 내면 손들고 빨리 맞히는 건가 했는데,
문제 내주면 누가 먼저 프로그래밍하냐는 것이었습니다 ^^;

문제는 3문제 나왔지만, 첫번째 문제는 예제 수준이고
두번째 문제는 Daum DNA 사이트 잘 둘러봤으면 크게 어렵지 않은 수준의 문제가 나왔습니다.

그 문제를 간단히 말하면,



지도로 메쉬업을 하려고 하는 사람이면 한 번쯤 생각해 봤음직한 기본적인 문제이고,
중간에 힌트로 콜백함수를 이용하면 간단히 풀 수 있다고 해서, Open API에 올라와 있는 json 예제를 간단히 고치기 시작했습니다.

너무 똑같이 하면 재미없으니까, 약간 바꾼 초기 화면은 다음과 같습니다.


사진에서 보듯이 검색창에 지역을 입력하면, 관련 주소를 보여줍니다.

원래 문제에서는 '강남구'라고 입력하면,



위와 같이 나오게 하라고 했는데, 위와 같이 나오는 것은 주소를 어떻게 보여주냐의 차이일 뿐입니다.
(주소 결과값에 도시, 구, 동 단위까지는 따라오니까요.)


문제에는 조건은 없지만, 주소만 보고 고르는 것보단 대략의 위치도 알면 고르기 편할 것 같아서
찾은 결과 위치를 지도 상에 다 표시하고 적절한 배율로 보이게 했습니다.

여기서 해당 주소를 클릭하면, 그 쪽으로 이동하고 확대되게 만들었습니다.


거기가 아닌 것 같아서(?) 다른 곳도 찍어봤습니다 ^^;


연습 삼아 간단하게 만들었지만, 지도는 사용자가 편하게 사용하게 하려면 고려해야 할 것이 무척 많다는 것을 다시 한 번 생각하게 하는 시간이었습니다.

현재는 지도 Open API 중에는 야후가 다양하면서도 편리한 기능을 공개하고 있어서 사용하기 편했는데, Daum의 새로운 기능과 계획들을 듣고 보니 앞으로 Daum 지도를 이용한 흥미로운 매쉬업이 얼마나 많이 생길까 기대하게 됩니다.

크로스도메인 문제.
흔히 나오는 예제는 php로 proxy server 만들어 쓰는 겁니다.

php 설치하기 곤란하고, 잘 모를 경우 jsp 개발자를 위해서 간단하게 하는 방법이 있는 것 같아서 올려봅니다.

아파치에 프록시 설치하고 간단한 설정으로 끝난다고 합니다.

mod_proxy 모듈 설치하고

httpd.conf 파일에 다음과 같이 설정하면 됩니다.

( 참고도서: Professional Apache Tomcat 6, V. Chopra 외 2명, Wrox, 2007 )

이걸로 간단히 내 서버로 request 보내는 것처럼 하면서 다른 서버로 보낼 수 있다니 아파치 대단한 것 같습니다 ^^

Ajax(예. XMLHttpRequest) 를 이용해서 다른 사이트로부터 정보를 가져올 때 다른 도메인일 경우, 보안정책에 걸려 가져올 수 있습니다. 보안을 위해서 소스의 근원이 같을 때만 허용한 다는 동일 근원지 정책(Same origin policy, 이하 SOP)입니다.

간단히 말하면, SOP에 따르면 같은 프로토콜을 이용하고, 같은 서버(호스트)에서 같은 포트를 사용하는 경우만 정보를 주고 받을 수 있습니다.
(링크가 걸려있는 위키에 나와 있는 표를 보면 이해가 쉽습니다. )

어쨌든 이를 해결하기 위한 방법으로는 다음과 같은 방법이 있습니다.

1. 이름 속이기(?)

window.document.domain = 'google.co.kr';

자바스크립트에서 간단하게 도메인 이름만 같은 것처럼 이름을 속여서 가져오는 방법이지만,
여러 곳에서 정보를 가져오거나, 나중에 이름이 바뀌는 경우에는 유지보수의 어려움이 있습니다.

2. JSON with padding

JSON 데이타를 다른 사이트에서 가져오기 특별한 포장지로 감싸는 작업을 하는 겁니다.
XMLHttpRequest로 바로 가져오면 동일 근원지 정책에 위반되기에 자바스크립트 소스인 것처럼 가져오면 이 정책에 위반되지 않고 가져올 수 있습니다.
이에 대한 설명은 Remote JSON이라는 다른 사이트에 올라와있는 글이 있습니다.
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/
(이를 구현하는 방법에 관한 글은 다른 곳에도 많이 올라와 있을 것으로 생각하므로 여기선 생략하고 넘어갑니다. 필요시에는 간단하게 정리해서 올리겠습니다.)

위 방법으로 이전에 올렸던 JSON 데이타를 자바스크립트 소스인 것처럼 다음과 같이 만들어서 가져오면 됩니다.

callback2([{"symbol":"ee","price":42.0460580763757,"change":0.03570531273294014}])

이전 글의 JSON 데이타에 callback2()라는 함수를 불러오는 것처럼 만듭니다.
함수의 이름을 인자값으로 넘기는 건 다음과 같이 한다고 가정합시다.

이전 글과 달라진 점은 callback이라는 인자를 넘겨서 그 값으로 함수명을 결정도록 한 것 밖에 없습니다.

위와 같이 인자를 바꿔서 자바스크립트 소스처럼 감싸진 결과를 만들려면 이전 소스가 다음과 같이 바뀌면 됩니다.

예전 소스에서 크게 달라진 것은 없죠? 함수명을 인자로 받아서 감싸준 부분밖에는요.
이 소스의 예제는 원래 구글 코드에 python으로 만들어졌고, 그 전 소스는 php로 만들어졌는데,
자기 컴퓨터에서는 무엇을 설치해도 상관이 없지만 만약 서버에서 구현할 때 이것저것 설치해야 한다면 문제가 될 수 있으므로
다 JSP 소스로 바꾸기만 한 것입니다.

원 소스 주소는 다음과 같습니다.
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=GettingStartedJSON

화면에 json 코드가 보여진다고 다 만들어진 것이 아니었습니다.

예를 들어 다음과 같은 json을 만들어주는 페이지가 있다고 할 때,

[ 
{ "symbol": "ABC", "price": 96.204659543522, "change": -1.6047997669492 }, 

{ "symbol": "DEF", "price": 61.929176899084, "change": 0.22809544419493 } 
]

위 json을 만들어주는 코드를 jsp로 짜고 출력했더니 화면에 똑같이 나왔습니다. 그런데 계속 파싱에러 ㅡ.ㅡ

이상해서 받은 거 그냥 뿌렸더니 html 코드랑 섞여 나오더군요.

중요한 건 contentType을  text/html이 아니라 text/javascript로 해주는 것이었습니다.

이걸 실수해서 괜히 엄한 코드 디버깅하며 쫓아가며 겨우뚱 했네요 ㅎㅎ

컨텐트 타입을 자바스크립트로 하면 웹에 뿌려지는 것이 아니라 보통은 다운로드됩니다.

참고로 위 json 만드는 JSP 소스를 싣습니다. (구글 코드에 있는 php 예제를 단순히 jsp로 바꾼 겁니다.)

<%@ page language="java" contentType="text/javascript; charset=EUC-KR"

    pageEncoding="EUC-KR"%>

<%@page import="java.util.Random"%>

<%

  final double MAX_PRICE = 100.0; // $100.00

  final double MAX_PRICE_CHANGE = 0.02; // +/- 2%

  double price;

  double change;
Random random = new Random();
String q = request.getParameter("q"); 

 out.print("[" + "");

 if(q != null){

  String[] symbols = q.split(" ");

  for(int i=0; i<symbols.length; i++){




   price = random.nextDouble() * MAX_PRICE;

   change = price * MAX_PRICE_CHANGE * (random.nextDouble() * 2.0 - 1.0);

   out.print("{" + "");   out.print("\"symbol\":\"" + symbols[i] +"\"," + "");   out.print("\"price\":" + price +"," + "");

   out.print("\"change\":" + change +"" + "");   out.print("}" + "");

   if(i < symbols.length - 1)

    out.print("," + "");

  }

 }

 out.print("]" + "");

%>

1. 실버라이트가 2.0 넘어가서 좋아진 점은? 초기화가 간단해졌더군요.

실버라이트 사이트에 있는 메뉴얼 다운로드 받아서 보다가 내용이 너무 단편적인 것 같아서
도서관에서 책을 빌려보았습니다.

우선은 쉽게 구할 수 있는 실버라이트 1.1에 대한 책을 빌려서 따라하기 시작했습니다.
1.1에서 2.0. 분위기나 명령어들이 변한 게 좀 있더군요. 예전 코드가 실행 안 되는 것도 있고, 어떻게 2.0에서 바꿔서 작성해야 할지 몰라서 실행해보지 못 하는 예제도 있었습니다.
(이런 점은 레일즈가 하위 버전과 많이 달라져서 예전 책으로 보는 사람이 난감해 하는 거랑 비슷하네요. 기본적으로 하위버전 호환성은 지켜주었으면 하는데 말입니다. ㅡㅜ)

대강 책으로만 이해하고 넘어가야지 했다가 문득 이러다가 실행해 보는 게 너무 없어지는 것은 아닐까?하는 위기감이 들었습니다. 그래서 인터넷에서 예전 버전에 쓰던 명령어가 어떻게 바뀌었나 찾아보기 시작했고, 그렇게 바꿔서 작성해보기 시작했습니다.

그러다가 문득 든 생각. 왜 이렇게 바꿨을까? 이거 너무 복잡하지 않을까?

복잡에서 또 다른 복잡함으로 넘어갈 이유는 없지 않을까 하는 생각이 들더군요.

복잡하던 명령이 없어진 것은 그걸 안 써도 된다는 것이 아닐까?
이미 디자인에서 작성하고, 이름을 붙여준 것을 코드에서 다시 정의해주는 의미가 있을까?

그래서 예전 1.1에서 해주던 초기화 코드들을 과감하게 빼 보았습니다.
대신 2.0에서 기본적으로 적혀있는 InitializeComponent()가 그 역할을 해 줄 것을 기대하면서 실행 해 보았습니다.

예전의 여러줄의 걸쳐서 xaml을 불러오고, UI 개체의 인스턴스를 만들고 하던 부분이 매소드 하나 부른 것으로 바꿨다니 확실히 편해졌긴 하네요.
(하지만 이건 이전 버전의 불편한 점의 개선이지 실버라이트의 장점이 될 수 있는 부분은 아닙니다.)


2. 실버라이트도 디자인하고 코딩하는 것은 마찬가지인데 플래쉬보다 좋은 점은 뭘까요?

플래쉬도 메뉴 만들때 그림 그리고 스토리보드 만들고, 마우스 이벤트에 따라 스크립트 만드는 걸 실버라이트에 비교하면
실버라이트에서 비슷한 과정을 거쳐서 만드는 데 실버라이트가 좋은 점은 무엇일까요?

메뉴를 동적으로 생성할 수 있다는 점. 메뉴 만들 때 필요한 정보를 파일이나 DB에서 불러와서 상황에 맞게 변화를 줄 수 있다는 점?

플래쉬에서는 그것을 못 할까요? 어쩌면 할 수 있을지도 모릅니다. 단지 플래쉬를 다루는 사람이 디자이너의 경우가 많았기에 파일 처리라던가 DB 처리와 같은 프로그램과 관계된 부분을 생각 안 했을지도 모르겠습니다.
플래쉬가 그랬을지다도 Flex나 Air에서는 이런 것들을 다 처리할 수 있을텐데 실버라이트의 좋은 점은 뭘까요?

평소에 쓰던 언어를 혹은 방식을 그대로 쓸 수 있다는 점이겠죠?
C#을 그대로 쓸 수 있고, xaml을 이용하는 면에서 WPF하고 비슷하기에 기존 사용자가 쉽게 접근할 수 있습니다.
실버라이트를 보면 ASP.NET 2.0하고 구조가 비슷하다는 느낌도 듭니다. 디자인하고 비하인드 코드를 분리해 놓은 점이 말입니다. (MS가 시장 진입에 쉽게 하려고 기존 개발자가 사용하던 것을 새로운 곳에 그대로 적용하는 전략 덕분이겠죠^^;)

개발자가 아무리 새로운 것을 배우는 것을 좋아한다고 할지라도 바쁜 프로젝트를 하는 와중에 전혀 새로운 것을 배우는 것은 쉬운 일이 아니기에 기존에 알 던 것을 그대로 이용할 수 있다는 점은 좋은 점이겠죠 :)


3. 접근하기 쉬운 JavaFX와 같은 또다른 RIA 언어와 비교하면 어떨까요?

제 경운 C#을 알고 상황에서 실버라이트를 접근한 거고, 어떻게 올 초에 xaml로 디자인 할 일이 있었던 것이 더 쉽게 접근할 수 있는 계기가 되었지만, 순수(?) 자바 개발자라면 어떻까요?

웹 쪽에 UX를 더한게 RIA라면 웹 시장의 많은 부분을 차지하고 있는 JAVA 진영이 접근하기 쉬운 것은 실버라이트보다 JavaFX이겠죠? 다만 실버라이트가 유리한 점은 JavaFX보다 빨리 나와서 책이라던가 사용자들을 어느 정도 확보해 놓았다는 점이고 데스크탑 어플리케이션을 웹으로 옮긴다는 점에서 데스크탑 어플리케이션 개발자들이 접근하기 쉽다는 점이겠죠?

문제는 웹에서 돌아가는 프로그램인데, 데스크탑 개발자들이 얼마나 빨리 웹의 특성을 자유자재로 다루는 가와 웹과의 연동을 어떻게 처리하냐가 관건일 수도 일 수도 있을 겁니다. C#을 할 줄 알아도 ASP.NET를 다루는 것이 쉬운 일이 아닌 반면, Java를 알면 JSP는 쉽게 할 수 있다는 점에서 JavaFX가 더 유리한 점일 수도 있고요.

디자인이라면에서 보면 JavaFX는 Adobe Photoshop CS3에서 플러그인을 달아서 디자인을 바로 넘길 수 있는 반면, 실버라이트는 디자이너가 Xaml을 배워야 하는 어려움이 있을 수 있습니다. 우리나라의 경우 실버라이트 시장이 형성되는데 시간이 걸릴텐데 복잡한 코드처럼 보이는 xaml을 공부하려는 디자이너가 얼마나 될지도 관건이고요.

HTML에 레이아웃을 테이블이 아닌 CSS로 짤 수만 있어도 개발자에게 인기 좋은 디자이너가 될텐데, 제가 많은 디자이너를 못 봐서 아직 그런 사람을 못 본 상황에서 Xaml을 다루는 디자이너란 관련된 큰 프로젝트가 생기지 않는 이상 양성되기 쉽지 않을까 하는 생각도 듭니다. JavaFX처럼 포토샵으로 레이어 나눠서 넘겨주면 그걸 받아서 프로그램 짜는 편이 편하겠지요.

저도 사실 JavaFX는 데모랑 설명 약간만 보고 하는 말이라서 정확히는 모라하기는 뭐하지만, JavaFX 잘 다루는 분과 만나서 얘기해보고 싶습니다 ^^*

오랫동안(?) JSP만 만졌는데, silverlight랑 연동할 때 ASP.NET을 사용하면 어떤 장점이 있을까 궁금하던 차에
ASP.NET도 배워보자는 맘으로 도서관에서 ASP.NET 책을 3주동안 빌렸습니다.

빌리자마자 본 ASP.NET 2.0으로 할 수 있는 것들이 무엇이 있나 특징들을 쭉 봤습니다.
첫 느낌은 오픈 소스 진영인 JAVA에서 하던 것들을 한 곳에 모아놓으려고 애썼다는 맘이 들었습니다.

그런데 그 많은 기능을 언어 자체에서 지원하려고 하니까 명령어나 예약어가 너무 많아졌다는 생각이 듭니다. 책 두께도 1000페이지 가까이 되고 ㅡㅜ

자바에서는 기본적인 웹쪽 언어인 jsp는 간단해서 2-300페이지면 책이 끝납니다. 그래서 JAVA만 알고 있다면, jsp 배우는데 4일 정도면 끝낼 수 있습니다. 4일 공부해서 구현 가능한 수준은 DB랑 연결해서 게시판 만들 수 있는 수준인 기본 기능 구현 정도입니다. 페이지 구성은 한 쪽에 메뉴가 있고 그 메뉴랑 연결해서 목록보여주고, 상세정보 보여주고 하는 간단한 구성입니다.

그런데 ASP.NET은 4일만에 필요한 걸 다 뽑아봐서 게시판을 만들 수 있을까요? 그 전에 어느 부분이 필요하고 나중에 봐도 되는지 구분하기도 어렵지 않을까 하는 염려가 생깁니다. 각 장이 뭔가 대단한 걸 줄 것처럼 소개해 들어가기에 처음 접하는 사람이 쉽게 손을 떼기가 어려우니까요. 막상 들어가보면 굳이 그 기능을 안 써도 되는 새로울 것이 없는 기술인 경우가 많지만요.

참고로 전 Spring Framework와 iBatis를 이용해서 틀을 간단하게 만들고, 화면은 Sitemesh로 쉽게 나누고, JAVA랑 웹의 연계는 DWR로 쉽게 처리하면 되겠다는 밑그림이 그려지는 상태라서 ASP.NET 2.0이 별 새로울 것이 없는 기술로 비쳐졌습니다.

그런데 그런 걸 접해보지 않은 사람이라면 마스터 페이지라던가 국제화라던가 웹 파트 등이 신기한 기술로 보일 수도 있습니다. 이런 걸 다 떠 앉고 있기에 ASP.NET 2.0이 무거워진 것일까요?

오픈 소스 진영인 JAVA에서는 이러한 것들을 서블릿 컨테이너와 프레임 워크랑 라이브러리끼리 나눠서 맡기에 로드도 분산되고, 필요한 것만 취해서 조합해서 뭔가 만들기 편하게 된 것이고요.
그 대신 오픈 소스의 단점이 있다면, 이런 것이 어디에 있는지 모르면 쉽게 못 쓰는 것이겠죠?

결국 Knowhere(오픈소스)냐, Knowhow냐(닷넷)냐의 문제군요.