REST API는 RPC(Remote Procedure Call) API와 다르게 기본적으로 절차적인 명령 호출의 목록으로 설계하는 것이 아니라고 생각된다.

REST(Representational State Transfer) API는 선언적인 방법으로 리소스(Resource)의 표현되는 상태를 변화(GET,POST,PUT,PATCH,DELETE…)시키는 인터페이스라고 할수 있다.

그리고 이러한 리소스의 상태에 따라 시스템이 동작하는 구조라고 생각한다.(직접 시스템의 동작을 명령하는 인터페이스를 가진 것이 아닌.)

예를 들어, Master Server와 Master의 지령을 받는 Worker Daemon가 있다고 하자.

Master가 특정 Task를 Worker에 요청을 하려고 하는데, 여러가지 이유로 Master가 Worker에 접속을 하는 구조가 아닌, Worker가 실행할때 Master에 접속 할수만 있다고 하자.

(특히 내부 IP만 가진 Worker라면 Master가 Worker에 접속을 할수가 없다.)

10gen의 Mongodb 온라인 수업중 하나인 M102: MongoDB for DBAs을 들었다.

개인적으로 MongoDB을 많이 좋아하지는 않지만(비슷한 것으로 RethinkDB가 더 맘에 든다.) 그래서 오히려 온라인 강의를 들어서 배우는게 어떨까 싶었다.

10gen(MongoDB 제작사)은 커뮤니티를 만드는 작업을 굉장히 잘한다는 생각이 든다. 이런 온라인 코스도 코세라만큼 구성 자체를 잘 되어 있는 편.

오랜만에 데브 페스트에 놀려 갔다. https://sites.google.com/site/2013devfestwkorea/home/aboutspeaker

구글인앱빌링 사용 모듈 구현사례

안드로이드 프로그래밍을 해본 경험이 없어서,잘 알지 못하는 분야이다. 구글의 인앱빌딩 지원을 버젼별로 상세히 설명되어있고,적어도 (나처럼 무경험자에게는) 어떻게 동작하는지 알수 있는 자리이었다.

나중에 안드로이드 프로그래밍을 한다면,그때 다시 한번 찾아 볼듯 하다.

Go Lang for Java Programmer

GoLang에 대한 기본적인 문법과 개념을 설명했다. 발표에 대한 연습을 많이 했다는 걸 느낄수 있었다.

REST API을 만드는 일이 많아졌다. REST API가 이미 널리 알려진 개념이지만,RESTful하다고 할수 있는 API은 어느정도는 주관적인 요소가 개입되는 것 같다.

이번에 설계를 하면서, Twitter나 Facebook의 API을 참고하긴 했지만, 각각의 스타일의 차이를 알수는 있어도 좋은 디자인 규칙에 대한 정보를 얻기가 힘들었다.

특히 리소스 모델링 부분이 어려운데, REST API Design Rulebook을 참고하여 구성하고 있다.

Disco을 잘 모르지만, 이번에 통계관련 계산에 한번 써봤다.

map/reduce

map/reduce는 map의 결과가 하나의 reduce에서 같은 key으로 모이는 것 보장한다.로직에 따라 다르겠지만. 전체 갯수을 얻는 것이 아니라면 reduce을 늘리는 것이 성능에 좋다. (당연한 이야기이지만)

combiner

Disco 문서에서는 보기 힘든데, Hadoop처럼 combiner을 만들 수 있다. combiner은 일종의 accumulator인데. 각 map마다 map의 결과를 받아서 reduce에 넘기기전에 buffer을 가진 function(combiner)을 만들 수 있는데. 대부분의 경우 combiner을 만드는 것이 속도나 메모리 사용에 좋을 것 같다.