About pretty print option flag

오늘 팀장으로부터 다음과 같은 프로그램 피드백을 받았다.

The client sending and status always outputs json:

please add -q flag to suppress output

please add -s flag to return ONLY the uuid for use in calling the client with the option -i <case_id>

please add -p flag to output the json as ‘pretty printed’ (jansson -> JSON_INDENT(n) for n=2)

기존에 개발한 프로그램에 대해 추가적인 옵션을 요청한 내용이었는데… 하나하나씩 읽다가 마지막 -p 옵션에 대해 의문이 생겼다.

Pretty print? 대체 이게 왜 필요할까?

기능을 추가하는건 어렵지 않았지만, 그 이유가 궁금했다. 내 마음을 알고 있었는지, 바로 아래쪽 댓글에 그 이유가 적혀 있었다.

pretty print makes it easier to use awk and other tools to find the interesting return line and grab out the value without having to implement a full JSON parser

아!!!! 미처 생각지도 못한 이유였다…

WeWork!

WeWork 라는 스타트업 업체가 $433M 규모의 펀드를 유치했단다(http://venturebeat.com/2015/07/07/wework-raises-a-hefty-433m-funding-round/). 그런데, WeWork 가 뭐지?

WeWork(https://www.wework.com/) – 사무 공간 임대업 쯤으로 이해할 수 있겠다.

하나의 사무실을 차리기 위해서는 어떤 것들이 필요할까? 먼저, 장소를 선정하고, 부동산을 계약해야 하겠다. 그리고, 부동산을 계약하는 과정에는 적지않은 보증금과 여러 절차들이 필요할 것이다. 아마도 이런 점들이 사업을 시작하거나 사무실을 차리는데 많은 걸림돌이 되었을 것이다.

하지만 이 과정을 생략할 수 있다면? 단순히 한달에 일정량의 돈을 지불함으로써 이런 과정들을 단순화할 수 있다면 좋지 않을까?

아마도 WeWork 가 이런 점을 해결할 수 있을 것이다. 보증금 없는 월세와 같이 매달 일정량의 사용료(단순 월세 수준)를 지불함으로써, 뉴욕, 런던 등의 도시에 사무실을 낼 수 있도록 하는 것이다. 게다가 수많은 업체들이 같은 공간을 공유함으로써 시너지효과도 기대할 수 있다.

처음에는 단순 사무 공간 임대로 생각할 수 있겠으나, 한 10분정도만 확인해보면 단순하지가 않다는 것을 알 수 있다. WeWork 에서는 사무 공간과 공공 유틸리티등을 제공한다. 사용자들은, 사무 공간 임대 비용을 내고 사무실을 사용하면서 여러 공공 유틸리티를 사용할 수 있다.

사용 공간에 비해 임대료가 비싸다는 생각을 할 수 있다. 하지만, 정말로 사업을 시작한다면 중요한 것은 사무 공간의 크기가 아니라 WeWork 에서 제공하는 공간이 아닐까 생각된다.

아쉽지만, 아직까진(2015.07), 서울쪽에는 WeWork 가 진출하지 않고 있다. 하지만 얼마 지나지 않아서 진출하거나 최소한 비슷한 유형의 사업이 시작될 것이라 생각한다.

그리고,내가 만약 사업을 시작한다면, 제일 먼저 WeWork 에 사무실을 내는 것을 고려할 것 같다.

[olive] Jenkins setup

드디어 젠킨스를 설정했다.

그동안 올리브 프로젝트를 진행하면서 여러차례 자동 빌드 시스템의 필요성을 느꼈었다.
자동 빌드 + 자동 유닛 테스트 + 자동 배포까지… 포함한 시스템이 필요했었다.
아직은 유닛 테스트와 배포를 위한 부분이 부족했지만, 그래도 언젠가는 자동 빌드 시스템이 필요한 때가 올꺼라는 것은 알고 있었다.

회사 팀장 Chris 에게 이런 내용을 이야기했더니, buildbot(http://buildbot.net/)을 추천해 주었었다.
추천 이유는, 작고, 빠르고, 간단하다는 것이었다.

하지만… 사용하려고 이리저리 노력해본 결과, 나랑은 맞지 않았다.
레퍼런스가 많지 않았고, 무엇보다 필요시 실제 업무에 바로 적용하여 사용할 수 있기를 바랬었기 때문이다.
(실제 업무에서는 Jenkins 와 Buildbot 둘 다 사용하고 있다. 하지만 Buildbot 의 비중은 크지 않았다.)

아무튼, 오늘 간단하게나마 그동안 바래왔던 Jenkins 의 설정을 했다.
간이 테스트 결과, 잘 작동한다. ㅎㅎㅎ 🙂

git master merge into devel

그동안 git 의 devel 브랜치에 대해서 약간 애매한 부분이 있었다.

줄곧 devel 브랜치는 master 브랜치로 merge 를 당하는 쪽이라고 생각한 것이다.

만약, devel 브랜치와 master 브랜치가 서로 다른 소스를 가지게 되는 경우에는 어떻게 할까?

예를 들어, 만약 hotfix 를 master 브랜치에만 적용을 했을 경우라면, devel 브랜치에는 hotfix가 적용되지 않게된다.
이런 경우, devel 브랜치를 master 브랜치로 merge를 하더라도 hotfix 에 대한 내용은 devel 브랜치에는 적용이 되지 않게 된다.

오늘, 이 문제에 대해서 직장동료 Lars 에게 물어보았다. 정말 친절하게 정답을 알려주었다.

간단했다.. 그냥 devel 브랜치에서 master 브랜치 내용을 merge 하면 되는 것이었다. -_-;;

Merge remote-tracking branch ‘origin/master’ into devel