API Design Granulity

http://blog.naver.com/saltynut/120210979446

http://blog.naver.com/saltynut/120211621879 API

디자인을 하다보면 얼마나 상세하게 디자인할까의 문제를 다룬 글입니다.

너무 상세하면 consumer입장에서 불편하고 성능 이슈도 생기고.. 너무 집약되면 다양성과 유연성이 떨어진다 것.

이에 대해 어떻게 적절히 할까에 대한 고민에 관한 글로..한번 읽어보면 좋을듯합니다.

Fabric

http://docs.fabfile.org/en/1.9/tutorial.html

fabric은 우연치 않게 deployment tool을 찾다 알게된 것으로, 현재 제가 속한 팀은 webistrano를 사용중입니다만..

더 좋은 솔루션이 없나 찾아보다 알게된 tool입니다.

webistrano로도 만족하고 있고, 당장 사용할 것 같지 않지만  python이 대세인 곳에서는 괜찮을 것으로 판단.

tutorial 첫문단에  다음과 같이  fabric의 정의가 있는데..

Fabric is a Python (2.5-2.7) library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.

즉,  시스템 관리 및 배포를 위해 SSH기반의 파이선으로 된 라이브러리와 커맨드 라인 툴로 해석하면 될것 같습니다.

http://www.pythonforbeginners.com/fabric/how-to-use-fabric-in-a-development-environment

위의 링크 글을 읽다보면 감 잡겠지만.

아주 특별할 것 없는, 호스트 설정 및 환경 설정에 관한 기능에 ssh를 통한 cmd 명령을 수행할 수 있는 tool.

shell script로도 되잖아? 라고 물을지도 모르겠지만, 좀 더 편하고 python의 기능을 적극 활용할 수 있다는 점이 좋을 것으로 판단합니다.

다만, 배포 히스토리 및 source controll integration (svn, git … ) 등이 부족한건 사실이고..

webistrano에 비해 기능면에서 더 뛰어나 보이진 않습니다. 다만, simple하고 가벼운 느낌!!

ruby가 익숙하면 capistrano의 web버전인 webistrano,

python이 익숙하거나.. 심플한 배포 스크립트를 만들고 싶다면  fabric이 좋은 대안중의 하나로 생각합니다.

플랫폼

http://liveandventure.com/2014/08/11/platform/ 플랫폼에 관한 좋은 글입니다.

플랫폼이란 용어가 너무 남발되는 것 같은 느낌입니다.

제가 하고 있는 팀도  플랫폼을 개발하는팀이라고 되어 있지만..아직 플랫폼은 아니네요.

가장 중요한 .. 핵심 가치 혹은 핵심 이슈를 해결을 잘 해내지 못하고 있거든요.

이 바탕위에 참여, 공유, 오픈, 가치창출 등을 해내야 하는데..  아직 그 단계까지는 ..흠.

핵심 가치를 창출해나가는 과정에서 플랫폼화를 시켜야하는 거겠죠?

 

Grails vs. Play

http://www.ubertracks.com/preso/#/intro

빠르게 파악하고 싶다면 뒷부분의  conclusion 부분만 보셔도 됩니다.

둘다 java를 support한다는 점에서 관심을 두고 있던차,  둘다 겉핧기 식으로만 프레임웍을 살펴보고 있어서

위의 자료는 좀 더 판단하는데 도움이 되지 않나 생각.

개인적으로 성능 이슈는 중요하지 않아서 (성능을 극한으로 쓰는 프로젝트는 많지 않음)

커뮤니티, 프레임웍 지원, 개발자층, 레퍼런스, 충분한 다큐먼트, IDE 지원, 언어(groovy, scala)의 learning curve, 하위 호환, third party 언어나 lib, 미래상(트렌드를 보아..) 등을

주요 판단 기준으로 보는데..현재로서는  grails가 좀 더 나은 선택이지 않나 생각합니다.

(옆에 훌륭한 scala나 groovy개발자가 있다면 선택이 달라질수도.. ^^)