우선 HTTP method를 요청하는 URI는 자원으로 생각하고,

• GET은 자원의 정보 반환
• PUT은 자원의 생성 또는 갱신
• DELETE는 자원의 삭제
• POST는 자원에 자료 처리

의미를 생각한 쇼핑몰 API 요청 예

PUT /api/product/123 HTTP/1.1 {상품 정보 데이터}
- 123 상품 등록/갱신

GET /api/product/111 HTTP/1.1
- 123 상품 정보 반환

DELETE /api/product/111 HTTP/1.1
- 123 상품 삭제

POST /api/order/send HTTP/1.1 {상품번호=123&방식=택배…}
- 123 상품 택배 배송 처리

참고

• Method Definitions : http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
• Representational State Transfer(Wikipedia): http://en.wikipedia.org/wiki/Restful

새로운 미래가 온다 – 다니엘 핑크 지음, 김명철 옮김/한국경제신문

평소 어떤 일을 할 때 항상 기존 보다 낳은 방법으로 창의적인 결과를 만들어 내고 싶은 욕구가 있다. 새로운 시도를 하면서 어려움을 겪을 수 있지만 내가 맡은 일을 보다 즐겁고 열정적으로 할 수 있는데 그 의미와 행복을 느낀다.

‘새로운 미래가 온다’에선 내가 궁극적으로 추구하는 삶, 그리고 그 이상의 새로운 미래 인재에 대해 설명한다. 디자인, 스토리, 조화, 공감, 놀이, 의미 이것이 미래인재의 6가지 조건이고, 이에 대한 배경과 함께 흥미로운 이야기로 쉽게 동의하며 이해할 수 있었다.

미래인재 조건의 대부분은 과거 개발자인 나에게 우선 필요하지 않거나 간과되는 능력들이었다. 하지만 현재 이미 느껴지고 있다. 새로운 미래에 필요한 인재가 되기 위한 앞으로의 노력에 많은 도움이 될 것 같다.

apt-get upgrade를 실행하여 우분투 서버 8.10으로 업그레이드 했다. 업그레이드를 성공적으로 마치고 재부팅을 했는데.. 부팅 하다가 에러메세지가 나오고 (initramfs) 쉘로 빠지는 문제가 발생했다. 그래서 구글링으로 원인을 찾아봤는데 다행히 간단한 해결방법으로 쉽게 해결했다.

우분투 8.10 릴리즈 노트 : Boot failures on systems with Intel D945 motherboards (Bug 290153).

# 원인 : 인텔 D945 메인보드 시스템에서 우분투 서버 8.10 업그레이드 시 버그
인텔 D945 메인보드 시스템의 우분투 8.10에서 SATA 하드 드라이브를 늦게 인식하는 문제가 있습니다. 이런 문제로 부팅 중 “Gave up waiting for root device.” 메세지와 함께 busybox initramfs shell로 빠지게 합니다.

# 해결 : 위의 우분투 릴리즈 노트에 지시한대로 따라 했다.

1. initramfs shell 에서 “exit” 를 입력하여 부팅이 계속 진행
   (initramfs) exit
2. 부팅이 된 후에 /boot/grub/menu.lst 편집기로 열어 현재 커널 부분에 “rootdelay=90″ 추가
   kernel /boot/vmlinuz-2.6.27-14-server root=UUID=58786110-f5f0-44c4-b117-a86fed0a7b26 rootdelay=90 ro quiet splash

memcached는 분산 메모리 객체 캐싱 시스템으로 일반적으로 데이터베이스 부하를 메모리 캐시로 대신하여 웹서비스 속도를 대폭 향상하는데 사용되는 시스템이다.

내부 동작은 엄청 복잡하겠지만 동작 방식은 쉽게 설명되어 있었다.

1. 여러대의 각 서버에서 메모리 크기를 지정하여 데몬을 실행
2. 각 서버 메모리는 하나의 공용 캐시 메모리로 관리
3. memcached 라이브러리를 통해 객체 읽기/쓰기

memcached 라이브러리는 거의 모든 언어에 지원한다.
http://code.google.com/p/memcached/wiki/Clients

RDBMS의 문제

• RDBMS의 특성상 ACID 조건을 충족시키기 위해 읽기/쓰기 쓰레드 블럭처리를 하면서 오버헤드가 발생

메모리 캐시는 블럭과 같은 오베헤드가 없고, 해시 테이블을 사용하여 매우 빠른속도로 RDBMS의 한계를 극복하는 좋은 대안이 될 수 있다.

트위터는 여러단계의 캐시를 사용하는데 중요한건 모든 DB를 캐시하여 서비스한다고 한다. 전체 메모리 용량이 얼마나 될까?..

나도 이런 분산 시스템 기반의 대규모 서비스를 제공해보고 싶은 욕망이^^ 열심히 구상해봐야지.. Google AppEngine에서도 memcache를 지원하니 한번 해봐야겠다.

구글을 지탱하는 기술 – 니시다 케이스케 지음, 김성훈 옮김, 전병국 감수/멘토르

“전세계 웹의 엄청난 데이터를 어떻게 처리할까?”, “그 거대한 데이터를 어떻게 단시간에 검색해줄까?” 등등의 구글 기술에 대해 오래전부터 궁금했었다. 이런 궁금증을 쉽게 풀어준 책이 바로 ‘구글을 지탱하는 기술‘ 이다.

인덱스 생성 방식부터 분산처리, 분산 파일 시스템, 분산 스토리지 시스템 등의 기술 원리를 쉽게 이해할 수 있게 잘 설명해준다. 대부분은 구글이 발표한 논문을 참고하여 설명하고, 컴퓨터과학에서 배운 내용이 전반적으로 내포되어 있어 보는 내내 흥미로웠다.

지난 한 주간 구글 앱 엔진을 접해 본 느낌은 클라우드 컴퓨팅의 플랫폼은 정말 매력적이었다. 웹호스팅과는 비교할 수 없이 플랫폼으로서 보다 편리하고 즐거운 개발을 위한 환경을 지원해주었다. 구글 앱 엔진에서 개발 시작은 단순히 SDK를 다운받아 설치하고 개발하면 되었다. 웹서버, 데이터베이스, 버전 관리 설치/설정 이런 개발 외의 작업들이 모두 사라졌다.

개발의 편리함을 시작으로 클라우드 컴퓨팅은 사용자 규모가 커질 수록 그 효과는 더욱 극대화 될 것 같다. 웹서비스는 사용자가 많아짐에 따라 서버 확장과 유지보수의 복잡함과 비용이 매우 높아지는데 클라우드 컴퓨팅으로 이런 부분에 매우 효율적으로 대체할 수 있을 것으로 생각한다. 또한 글로벌 웹서비스를 제공할 때에도 매우 유용할 것 같다.

얼마 전 자바를 지원하면서 Cron Jobs 기능까지 추가됬다. 앞으로 구글 앱 엔진의 발전에 완전 기대된다+.+

회사에서 정기구독하는 마이크로소트웨어 잡지를 보게 되었다. 처음엔 가벼운 마음으로 잡지를 펼쳐봤는데.. 와~ 볼께 무지 많았다! 평소 잡지는 흥미거리 위주로 대충 훑어보고 마는데, 이건 볼께 너무 많아 목차를 건너뛰고 그냥 거의 정독하게 됬다.

마치 군대에서 맥심을 정독한 느낌ㅋ

소프트웨어 개발자를 위한 이렇게 괜찮은 잡지를 이제야 알다니.. 학생 때 좀 더 빨리 보았으면 더 잼있었을 것 같은 아쉬움이 들지만, 한동안 이 잡지를 보면서 즐거울 것 같다.

Crayon Physics Deluxe

크레파스로 그림을 그리면 실제 물리적인 물체가 되는 게임이다. 이 게임의 아이디어와 상상력은 IGF의 가장 큰 상을 받을만 하다. 더이상 말이 필요없이 비디오를 봐야한다!

Crayon Physics Deluxe from Petri Purho on Vimeo.

Fez

2D게임 처럼 보이지만 직교투영을 하여 2D와 3D를 번갈아가며 느낄 수 있는 3D 픽셀 게임이다. 차원을 돌리는 기발한 아이디어, 귀엽고 단순한 캐릭터 그리고 중독성있는 음악까지! 이런 게임을 만들 수 있는 팀, 멋지다..

Fez teaser trailer from fish on Vimeo.

Fez LIVE from fish on Vimeo.

다시 고민하여 OpenAPI를 이용한 위젯을 구상하였데 또 약간의 고민이 생겼다. 보통 OpenAPI를 사용하려면 사용자 Key를 발급받아야 하고, 한 Key당 약 5000회 정도 요청 제한이 있다. 5000회 정도는 한 곳(프로그램)에서 사용하기 넉넉한 량이지만, 위젯은 수많은 블로그에서 등록되기에 그 요청량은 급격하게 늘어난다. 그래서 OpenAPI를 사용하여 만든 위젯을 배포할때 위젯을 퍼가는 사람들에게 API에 대한 Key를 발급받아 넣어주도록 해야한다. 또한 API를 여러개 사용하면 발급해야할 Key도 많아지는데 이렇게 된다면 상당히 번거로울 것 같다.

물론 좋은 위젯이라면 이러한 번거로움은 별 문제 없을것이고.. 이런 저런 생각을 하던 중 MediaWiki API가 생각났다. MediaWiki API를 이용하면 위키백과를 위젯으로 만들 수 있겠다는 생각이 들었고, MediaWiki API는 따로 인증 키를 발급 받을 필요도 없다!

MediaWiki는 위키백과를 위해 개발된 자유 소프트웨어 위키 패키지이다. 그러니까 위키백과는 MediaWiki로 만들어졌는데 MediaWiki 소프트웨어는 API를 제공하고 위키백과 또한 API를 제공한다. MediaWiki를 사용하면서 API를 제공하고 싶지 않으면 설정에서 변경할 수 있는걸로 알고 있다.

위키백과 API – http://ko.wikipedia.org/w/api.php

그래서 구상한 위젯은 ‘위키백과 지식상자’이다. 위키백과에 등록된 문서의 요약된 내용을 표시하고 관련된 문서를 지속적으로 계속 보여주어 사용자에게 위키백과의 유용한 지식을 전달하는 위젯이다.

이제 구현을 하는데 위키백과 문서의 요약된 내용을 표시하는데 문제가 생겼다. 위키백과 API에는 유용한 많은 정보를 제공하는 API가 있는데 정작 내가 원하는 문서 내용을 제공하는 부분이 없었다. 구글맵이나 Wikipedia Roll과 같은 위키백과를 이용한 매쉬업에서는 위키백과 문서의 내용을 표시한다. 어떻게 내용을 표시하나 궁금해서 찾아봤는데 위키백과:데이터베이스를 다운로드 받아 사용하는 것이었다. 하지만 이 데이터베이스를 받아서 운용할 서버가 없다. 방법을 찾다가 단순한 생각으로 위키백과 문서에 직접 접근하여 스크래핑하여 내용을 가져오려 했지만, 부적절한 방법인 것 같고 무엇보다 속도가 느려 다른 방법을 찾아야 했다. 어떻게 하면 위키백과 문서의 요약된 내용을 표시할 수 있을까 고민하던 중 마침 구글 검색이 떠올랐다. 모르는 용어를 구글에 검색하면 보통 위키백과에 등록된 문서의 내용의 일부분을 검색결과를 나타내고 이런 점을 응용하여 문제를 해결했다. Google AJAX Search API 이용해서ㅎㅎ

모든 기능과 외형을 개발하고 마지막으로 디자인이다. 원래 디자인 감각은 없어 디자인에 별로 신경쓰지 않지만 그래도 다른 사람들이 위젯을 퍼가기 때문에 조금은 신경써야 했다. 그래서 이미지를 넣어 디자인해보려 했는데 또 문제가 생겼다. 역시 위젯을 처음 만들어 보니까 참 문제도 많타-.- 위젯을 등록할때 xml 소스만 등록하기 때문에 이미지나 플래시는 내 계정에 올려야 하는데 내 홈페이지 계정에 올려서 나중에 트래픽 제한 걸릴 수가 있다. 당연히 트래픽 제한이 되면 위젯을 퍼간 사람도 문제가 생긴다. 넉넉한 계정을 가지고 있다면야 이미지를 사용하여 디자인 했겠지만 그냥 CSS만로 디자인했다. 사실 디자인 감각이 있었다면 계정 신경 안썼을텐데;;

디자인을 뭐 했냐고 할 수도 있겠는데 그래도 CSS가 179라인이다. 줄내림을 많이 했긴 했지만.. 쩝.. 그래도 가장 큰 특징은 위젯 박스 테두리를 둥글게 했다. CSS3에는 박스 테두리가 둥글게 표시하는 border-radius가 있지만 대부분의 브라우저에서는 지원을 안하니 약간은 트릭인 방법을 찾았다. 이 방법은 ‘css round box‘라고 검색하면 여러가지가 나오는데 Snazzy Borders를 조금 수정하여 사용했다.

자 이렇게 만든 ‘위키백과 지식상자’ 위젯=가젯이 다행히 1차 전문가 심사를 통과했다^^ 지금은 응모작 투표 진행중~