넷플릭스 마이크로 서비스 가이드

우린 계속 같은 문제의 해결을 반복하고 있다.
하나의 거대한 코드베이스를 클래스들로 쪼개어 내고
하나의 svn리파지터리에 몽땅들어있는 제품들을 각각의 git리파지터리로 분리했듯
하나의 거대한 웹서비스를 개별 서비스들로 분리해내고 있다.

다루는 내용이 많아 두고두고 봐야할 듯

안드로이드 epub 리더 앱 개발

작년에 썼던 글들을 한데 모아 epub포맷으로 전자책을 만들었다. 딱히 공개할만한 퀄리티를 가진 것은 아니지만 작년 초에 세웠던 계획이 어떻게든 이루어졌다는 점에서 의미가 있었다. 그리고 이번에 이 전자책을 안드로이드 공부삼아 개발한 eBook리더 앱에 Embed하여 앱스토어에 공개하였다.

현재 두 개의 앱을 배포했다. 하나는 내가 작년에 쓴 글 모음이고, 하나는 다른 프로젝트 그룹에서 함께 작성한 릴레이 소설이다.

eBook리더 앱의 소스는 Github에 공개되어 있다. Embed된 전자책을 교체하고 프로젝트 패키지이름만 바꾸면 따로 스토어에 출시할 수 있다.

1주일 정도 집중해서 만들었는데 기능이랄 것은 별로 없고 기본에만 충실했다. ePub포맷이 단순히 html파일을 내장한 형태라 쉽게 될거라 생각했는데 의외로 신경쓸 것이 많다. Readium SDK가 아니었으면 이렇게 단시간에 이뤄지진 않았을 것이다.

요새 글쓰기가 열풍이라고 한다. 개인적으로 참여하고 있는 글쓰기 모임에는 관련 주제로 KBS에서 취재차 다녀갔다. 내가 글을 좋아하는 사람을 곁에 많이 두어서인지 정말로 열풍인 것인지 나는 모르겠으나 분명 많은 사람들이 자신의 글을 쓰고 책을 내는 것에 관심이 많은 것 같다. 여기에 내가 무언가 기여해볼 수 있을까.

 

Tinkering-driven in code

code on Github

Why you should never use MongoDB

원문 보기

제목이 다소 과장되어 있긴 하지만.

1. 몽고디비에 저장되는 도큐먼트간에 링크가 있다면 몽고디비는 좋은 솔루션이 아니다.
2. 몽고디비는 디비라기보다는 캐시다.

When the MongoDB folks say “documents,” in many ways, they mean things you can print out on a piece of paper and hold. A document may have internal structure — headings and subheadings and paragraphs and footers — but it doesn’t link to other documents. It’s a self-contained piece of semi-structured data.
If your data looks like that, you’ve got documents. Congratulations! It’s a good use case for Mongo. But if there’s value in the links between documents, then you don’t actually have documents. MongoDB is not the right solution for you. It’s certainly not the right solution for social data, where links between documents are actually the most critical data in the system.