Pragmatic Story(실용주의 이야기)

오늘 지인분과 테스트 커버리지에 대해 나눈 이야기를 간단하게 정리해봤습니다.

테스트 커버리지를 측정하는게 필요할까요?

저는 필요하다고 생각합니다. 커버리지를 측정하지 않으면 현재 가진 문제점이 드러나지 않습니다. 현재 얼마나 테스트 코드를 작성하고 있는가에 대한 대답을 할 수 있어야 합니다.

테스트 커버리지를 어떻게 가이드 해야 할까요?

N사에 있을때는 80% 이상이면 Gold, 70% 이상이면 Silver 이런식으로 등급을 나누어서 이를 각 조직에서 달성하도록 했습니다. 그러면 각 팀이 현재 어느수준에 와있고 어떤 노력을 해야 하는지 조금은 명확해 집니다. 아래 그림은 CI 서버를 이용해 자동으로 커버리지를 계산하여 등급을 보여주는 화면입니다.

테스트 커버리지를 높히기 위해서 경쟁하게 될거 같은데요

맞습니다. 그래서 커버리지를 측정한다고 해도 이를 강요해서는 안됩니다. 커버리지는 현재 테스트 코드 수준을 판단하는 한가지 지표일 뿐입니다. 

그럼 얼마나 높은 수준을 유지해야 할까요?

80%. 사실 테스트 코드를 작성하는 수준이 높아지면 테스트 커버리지는 의미가 없어집니다. 테스트 커버리지로 테스트 코드의 질을 평가할수는 없기 때문입니다. 어떻게 하면 좋은 테스트 코드를 작성할 수 있을까를 고민하는 개발자에게 '너 왜 코드 커버리지가 이렇게 낮아. 이 부분을 보강해.' 이런 식의 강요는 의미없죠.

너무 테스트 코드가 많으면 테스트 코드를 유지하느라 많은 비용이 들거 같아요.

소스가 변경되었을때 테스트가 실패하는것은 당연합니다. 그게 바로 테스트 코드가 해야하는 일입니다. 테스트 코드를 수정하는 일을 비용으로 보는것은 잘못된 시각입니다. 깨지는것, 버려지는것을 테스트 코드의 라이프 사이클로 보세요.

테스트 커버리지에 대한 논란이 있다는건 아직 테스트 코드 작성에 대한 마인드가 개발조직에 자리잡지 못했다는 징후라고 생각합니다. 숫자에 얽메이지 마세요. 

버그를 막아주는 좋은 테스트 코드를 작성하는데 집중하세요. 

참고자료

[1] http://googletesting.blogspot.kr/2010/07/code-coverage-goal-80-and-no-less.html

glu는 배포에 필요한 작업을 모델에 정의합니다. 이 모델은 json 형태로 되어있으며 모델이 갖는 정보는 3가지입니다.: 애플리케이션을 배포하기 위해서 무엇을, 어디에, 어떻게 할것인지  

튜토리얼에 들어있는 샘플 모델을 보겠습니다.

{
  "fabric": "prod-chicago",
  "entries": [
  {
   "agent": "node01.prod",
   "mountPoint": "/search/i001",

   "script": "http://repository.prod/scripts/webapp-deploy-1.0.0.groovy",
   "initParameters": {
      "container": {
        "skeleton": "http://repository.prod/tgzs/jetty-7.2.2.v20101205.tgz",
        "config": "http://repository.prod/configs/search-container-config-2.1.0.json",
        "port": 8080,
      },
      "webapp": {
        "war": "http://repository.prod/wars/search-2.1.0.war",
        "contextPath": "/",
        "config": "http://repository.prod/configs/search-config-2.1.0.json"
      }
   }
  }
  ]
}

위 예에서 어디에 해당하는것이 agent와 mountPoint 이며 
어떤 스크립트를 이용해서 배포를 하겠다는 부분이 script 이며 
마지막으로 무엇을 배포하겠다는 정의가 initParameters 입니다.

glu 오케스트레이션 엔진은 이 모델파일을 읽어서 다음과 같은 작업을 진행합니다.
현재 배포되어 있는 상태와 모델에 정의된 상태를 비교한다.
실행 명령을 가지고 배포 계획을 만든다. 

출처: http://pongasoft.github.io/glu/docs/latest/html/index.html

오늘 인사이트에서 최근 출간된 '칸반과 스크럼' 책을 받았습니다. 이미 원서로 한번 본 책인데다가 책도 얇아서 받자마다 한 숨에 읽어버렸네요. 이 책의 저자 헨리크리닉버그는 요즘 많이 인정을 받는 애자일러입니다. 그의 전작의 번역판인 '스크럼과 XP'역시 많은 사람들의 사랑을 받았습니다.

책 서두에 나오는 아래 이미지는 RUP,XP,Scrum,Kanban이 비교했을때 어떤 애자일 방법론이 얼마나 규범적인지를 잘 나타내는 도표입니다. 이 도표를 잘 이해하면 스크럼과 칸반의 차이를 확 느끼게 됩니다.

저는 2009년 애자일 컨퍼런스를 다녀온 이후로 국내에 칸반게임을 전파한 장본인이기도 하며 수많은 교육에서 칸반게임을 진행했습니다. 그러면서 늘 가져던 궁금증이 '왜 Queue가 효과적인 경우를 보기 힘든걸까?'였는데 책에서 든 '예:칸반에 WIP 리밋 실험하기'를 읽으면서 그 이유를 찾을 수 있었습니다.

이 책은 그리 친절하지는 않습니다. 상세한 이론을 담고 있지도 않구요. 그보다는 두명의 애자일러가 칸반을 적용하면서 자신들의 생각을 즉석에서 정리해놨다가 묶어서 책으로 만든 느낌입니다. 하지만 그 느낌이 나쁘지 않습니다. 책 마지막에 이런 말이 나옵니다. 

유일하게 실패라고 부를수 있는 때는 실패로부터 아무것도 배우지 못했을 때이다.(The only failure is the failure to learn from failure)

칸반을 제대로 이해했는지 궁금하시나요? 

스크럼이 무겁게 느껴진다면 반은 맞았다고 해드리겠습니다. :)

참고자료

[1] http://www.infoq.com/minibooks/kanban-scrum-minibook

glu는 무엇인가

오픈소스 배포 모니터링 자동화 플랫폼

glu로 무엇을 할수 있는가

- 많은 노드에 애플리케이션을 배포하고 모니터링 할 수 있다.

- 배포 시간때문에 발생하는 불일치를 막아준다.

- 문제가 발생했을때 이를 재빨리 알아내서 해결할 수 있게 해준다.

어떻게 동작하는가

glu는 필요한 작업을 model에 정의해 놓으면 이를 바탕으로 동작한다. glu가 동작하는 방식을 나눠보면

- 어플리케이션을 배포/업그레이드하는 일련의 작업을 계산한다.

- 일관성을 유지하기 위해 얼마나 시간이 걸리는지 확인한다.

- 배포가 잘못되면 확인해서 알려준다.

glu 아키텍처

glu는 크게 ZooKeeper, glu 오케스트레이션 엔진, 에이전트로 구성된다. ZooKeeper는 glu 에이전트가 보내주는 정보를 받아서 애플리케이션이 배포된 서버가 살아있도록 유지해주는데 사용한다. glu 에이전트는 애플리케이션이 배포될 서버에 설치되어 실행된다. glu 엔진이 이 시스템이 중요한 부분이다.

출처: http://pongasoft.github.io/glu/docs/latest/html/index.html

눈을 감은 사람은 손이 미치는 곳까지가

그의 세계요.

무지한 사람은 아는 것까지가

그의 세계요.

위대한 사람은 비전이 미치는 곳까지가

그의 세계다.

- 폴 하비 -

이 책의 원제는 Poke the Box 입니다. 하지만 시작하는 습관도 그리 나쁜거 같지는 않네요. 세스고딘(Seth Godin)은 뭐 하도 유명한 마케터이자 저자라서 따로 설명할 필요는 없을거 같습니다.

Poke the Box는 어떤 의미 일까요? 뭐가 들어있는지 모르는 블랙박스 같은 상자를 포크로 쿡쿡 찔러 보는것을 의미합니다. 서두에서 이 책을 이렇게 정의해 놨습니다. 

이 책은 시작에 관한 선언문이다. 

무언가를 처음 시도하는것이 얼마나 중요하며 왜 그래야 하는지를 책 전체에 걸쳐 다양한 사례와 인용문을 통해 설명하고 있습니다. 

사람들은 왜 처음 시도하지 않는가? 

위험하다고 생각하며 실패를 두려워 하기 때문입니다. 하지만 저자는 이런 생각에 정체되어 있는 때가 더 위험하다고 이야기합니다. 새로 시작하는 일의 대부분이 실패하지만 다행스럽게도 우리는 수많은 실패는 기억하지 못하고 성공만을 기대합니다. 오프라는 쇼를 망치고 많은 일에 실패했지만 우리는 그런 일을 전혀 기억하지 못합니다.

평범함에 안주하지 말라

우리 스스로 평범한 식당,서비스에 불평하지만 완전히 엉망이지만 않으면 평범함을 받아들이는 경향이 있다. 문제는 자기들끼리 힘을 모아 잘못된 것을 고치는 경우는 없다. 기회는 당신이 힘과 의지를 찾아 평범함에 도전하는 데 있다.

모든 일에는 대가가 따른다

시도하는 사람은 매우 드물다.

그래서 귀하다.

기꺼이 유용한 프로젝트를 시작할 만큼 똑똑한 사람을 구하는 일은 정말 어렵다.

제멜바이스의 책임

이그나즈 제멜바이스는 1800년대 살았언 헝가리 출신의 산과의이다. 그는 의사들의 불결한 위생 상태, 특히 손을 잘 소독하지 않는 관행이 환자들의 질병과 사망의 주요 원인임을 알아냈다. 하지만 이 중대한 사실을 알아내고도 이 주장에 대한 과학적 원리를 설명하고 사람들에게 알리는데는 실패했다.

-> 사람들은 자기 좋다고 생각하는 사실,지식에 대해 다른 사람들이 그 사실을 경험하고 느낄수 있는 기회를 박탈하는 경향이 있습니다. 애자일을 말하는 사람들중에도 이런 사람들을 왕왕 볼수 있습니다.

호기심이 기회를 가져온다.

호기심은 우리로 하여금 어떤 일을 시작하게 하고, 세상에 어떤 일을 가져오게 한다. 그 일을 자세히 살피고 다듬고 그 과정을 반복하게 한다.

3000번 테드 강연의 비밀

애초에 TED 컨퍼런스는 과학과 문학 분야의 거장들을 강연자로 선정하는 것이 특징이었기 때문에 테드 강연이 인터넷에서 인기를 끈 것도 별로 놀라운 일은 아니다. 정작 놀라운 것은 TEDx 이다. 당신에게 테드 토크에서 강연할 기회가 주어진다면 무슨 이야기를 할 것인가? 당신이 발견한 사실과 알고 있는 사실, 가르칠 수 있는 것은 무엇인가? 당신은 강연을 해야만 한다. 강연을 하지 않더라도 준비는 되어 있어야 한다.

-> TEDx의 가치를 다시 한번 느끼게 된 부분입니다. 저도 TEDxNHN을 통해 TEDx의 가능성을 몸소 느꼈지만 이 말처럼 와 닿는 설명은 보지 못했던거 같습니다. 무엇을 이야기 할지 항상 준비해야 한다는데 100% 공감합니다. 

가장 많이 실패한 사람이 성공한다.

성공한 사람들과 이야기를 나눠보라. 당신에게 기꺼이 무수한 실패담을 애기해줄 것이다. 성공한 사람은 실패로부터 배움을 얻는다.

시작하지 않으면 기회는 없다.

오늘날에느 시작하지 않는 것이 일을 잘못하는 것보다 훨씬, 아주 훨씬 더 나쁘다. 시작했다면 발전의 여지가 있고, 잘못한 일을 바로 잡을 기회가 있다. 하지만 시작하지 않았다면 기회조차 가질 수 없다.

시작하는 길이 안전한 길이다.

-> 일전에 안철수 교수님이 무릅팍 도사에서 하신 말씀이 생각났습니다. 강호동씨가 '왜 의사라는 안정적인 직업을 버리고 보안회사를 시작했나요?' '세상에 안정적인 직업이란 없습니다.' 맞다. 구성에 웅크린채 가만히 있는다고 안전한게 아닙니다. 평범해 질 뿐입니다. 

그보다는 중요한 일을 시작하는게 낫다. Go Go Go

---

시작하는 습관

저자

세스 고딘 지음

출판사

21세기북스 | 2011-11-30 출간

카테고리

자기계발

책소개

떠오르는 순간, 바로 시작하라!머뭇거리는 순간, 기회는 지나간다...

---

2012년 9월1일에 열렸던 Agile Korea 2012 영상을 모두 공개합니다. Agile Korea Conference에 대해 잘 모르시는 분은 컨퍼런스 사이트(http://agilekorea.org/event/2012)를 참고하세요.

1. 애자일을 실천하는 사람들이 격는 어려움(최보나)
2. Lean Startup in Practice(정지웅)
3. 애자일하게 스펙 작성하기(황상철)
4. OEC facilitation Season2(채홍미)
5. Traditional vs Agile(경기원)
6. 애자일을 통하여 얻은것(황순삼)
7. 협업도구를 활용한 Agile Practice 활용사례(한문근)
8. 개인이 조직을 바꾸는 법(김창준)
9. 유니콘 목장(정기원)
10. User stories workshop(박준표, 최보나)

• 발표자 분이 영상촬영 거부하신 경우
• 촬영 자체를 진행하지 못한 경우
• 촬영을 했으나 잘못되어 제대로 촬영되지 못한 경우

GTAC은 Google Test Automation Conference 입니다. 지난 4월23~24일 양일간 뉴욕에서 열렸는데요. 이 멋진 컨퍼런스의 모든 발표자료와 영상이 무료로 공개되었습니다. 

GTAC 2013 WrapUp

GTAC2013: Presentations

제목만 봐도 끌릴만한 발표들이 즐비합니다. 잘 준비해서 내년에는 직접 한번 가보고 싶네요.

요즘 이북으로 책을 봅니다. 무거운 책을 가지고 다니지 않아도 되고 갤럭시S 3가 생겼는데 이걸로도 그럭저럭 읽을만 하네요. 한글 이북이 많지 않다고 하지만 IT 분야가 아닌 책들은 그래도 꽤 구할수가 있습니다. 제가 이번에 읽은 책은 두권입니다.

---

남자의 물건

저자

김정운 지음

출판사

21세기북스 | 2012-02-07 출간

카테고리

자기계발

책소개

인생의 의미를 잃어버린 남자들이여, 당신만의 이야기를 꺼내라!김...

---

---

가까이

저자

이효리 지음

출판사

북하우스 | 2012-05-24 출간

카테고리

시/에세이

책소개

이효리와 순심이가 말하는 함께 살아가는 삶뮤지션이자 엔터테이너,...

---

김정운 교수의 남자의 물건은 제목은 조금 그래도 내용은 남자의 심리와 인생에 대한 진솔한 책입니다. 2부에서 안성기,문재인,조영남 등 그가 만난 많은 남자들의 애장품(물건)에 대한 소개도 재밌습니다.

이효리씨가 쓴 가까이는 반려동물에 대한 에세이집니다. 그전에도 가수 이효리씨를 좋아했는데 이 책을 읽고 나서 더 좋아졌습니다. 동물보호라는 사회운동에 새로운 시각을 갖게 되었습니다.  

이 두권의 책을 읽고 나서 다음과 같은 생각이 들었습니다.

사회를 변화시키는일에 나서고 싶다.

나를 힐링할수 있는 무언가를 갖고 싶다.

아무것도 버리지 못하는 사람은 아무것도 바꾸지 못한다.

이전에 NHN에서 진행했던 테크 브리핑 영상입니다. 사내행사를 녹화한것입니다만 어차피 시간이 지나면 의미없으니 공개하려고 합니다. 40분동안 Play2 Framework의 특징에 대해 설명합니다. 

샘플을 가지고 시연하는 부분도 사이사이 들어있으니 부담없이 보세요.

그림 한장으로 유사한 용어를 이렇게 명쾌하게 정의하다니..놀랍습니다.

사내 뉴스레터에 좋은 내용이 있어서 옮겨봤습니다. 

출처: SKP M&C News Letter(http://www.commhere.net/)

팀원분이 공유해주신 Programmer Competency Matrix를 보면서 궁금해 졌습니다. 

나는 프로그래머로서 어느정도나 되는걸까? 

많은 개발자분들이 저와 같은 고민을 하고 있지 않을까요. 아래 링크를 따라가시면 Computer Science, Software Engineering, Programming, Experience, Knowledge 영역별로 Level0 ~ Level3 까지 정의되어 있는 매트릭스를 보실수 있습니다. 

http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm

내용이 모두 마음에 드는것은 아닙니다. 특히 SE는 너무 내용이 빈약하네요. 하지만 Computer Science와  Programming은 괜찮은거 같습니다. 한번쯤 재미로라도 본인의 수준을 확인해보시죠.

저는 영역에 따라 다르기는 한데 Level2 ~ Level3를 왔다갔다 하네요.

애자일 프로젝트 관리 도구 및 교육을 진행하는 버전원(VersionOne)에서 2012년 애자일 현황에 대한 설문조사 결과를 2013년 2월 26일 발표했습니다. 설문조사 결과 전문은 아래 URL에서 다운로드 가능합니다.

http://www.versionone.com/state-of-agile-survey-results/

애자일 강의를 준비하다보면 '트렌드'에 대한 자료가 필요한데 전 이 설문조사를 자주 애용합니다. 특히 이번에는 인포그래픽으로 만들어져서 깔끔하니 좋네요. 몇가지 흥미로운것만 추렸습니다.

• 애자일 도입에 실패한 이유는? 적절한 사람을 찾지 못해서, 팀 문화를 정착시키지 못해서
• 애자일 도입에 성공한 이유는? 경영진의 스폰서쉽(23%), 교육/워크샵(18%), 공통의 도구 사용(13%)
• 어떤 애자일 방법론을 사용하는가? 스크럼(54%), 스크럼과 XP(11%), 자체(9%)
• 사용하는 애자일 기법은? 일일스크럼(85%), 단위 테스팅(74%), CI(56%), CD(23%)
• 애자일 도입의 걸림돌은? 조직문화에 대한 변화(52%), 변화에 대한 저항(41%)

자료를 전부 살펴보기 싫으신 분들은 설문조사를 분석한 IDG의 "애자일 개발의 발목을 잡는 것은 문화와 사람"을 읽어보세요.

맥에는 python이 기본으로 설치되어 있습니다. 이 python으로 초간단 웹서버를 띄우는 방법입니다. 

python -m SimpleHTTPServer 8081

플레이 프레임워크가 뜨지 못하는 이유중 하나를 저는 서드파티 모듈이 부족해서라고 생각합니다. 

RoR, GRails, Play와 같이 빠른 개발을 지향하는 기술에서는 굉장히 중요한 부분이죠. 부족하다고 말했지만 그래도 2.0을 지원하는 모듈이 꽤 많이 개발되고 있습니다. 아래 링크에서 한번 확인해보세요. 

http://www.playframework.com/documentation/2.1.1/Modules

KTH 개발자 블로그에 올라온 좋은 API 디자인하기, 왜 그것이 중요한가? 를 읽다가 내용이 너무 좋아서 원본 동영상을 공유합니다. API를 코드로 바꿔도 손색이 없을만큼 좋은 내용이네요.

역시 좋은 발표는 시간이 흐른다고 흐트러지는게 아니네요. 꼭 한번씩 감상해보세요. (영어자막도 있으니 잘 안들리면 키고 보셔도 좋습니다.)

DevOps에 대한 내용이 궁금해서 좀 찾아봤습니다. 

KTH 개발자 블로그 & H3 Conference

• DevOps, 개발과 운영의 새로운 문화: http://dev.kthcorp.com/2012/06/20/devops-new-trend-in-developement-and-operations/
• 요리사가 뭔말인가? Chef.series: #1, #2, #3
• API와 서비스를 스마트하게 모니터링 하는 방법, Safari Tour를 소개 합니다.: http://dev.kthcorp.com/2013/02/05/smart-api-monitoring-safari-tour/
• H3 Conference: Just Do IT, Chef 언제까지 손으로 일일이 할텐가? 영상보기
  
• H3 Conference: 앱(APP) 중심으로 생각하기 - DevOps와 자동화 영상보기
• DevOps팀으로써 1년: http://devopser.me/belongs-to-devops%20-team/
• Netflix의 DevOps == NoOps: http://devopser.me/noops-at-netflix/

SKP에 오자마자 가이드를 만드는 일을 맡아서 오랜만에 코딩 표준을 좀 찾아봤습니다. 

그런데 몇년전에 비해 하나도 변한게 없네요. 안드로이드쪽은 많이 다를거라 생각했는데 의외로 코딩에 대한 기준은 차이가 없더군요. 그러다 구글링으로 찾은 슬라이드에서 우연히 본 내용이 마음에 들어 공유합니다.

출처: http://courses.coreservlets.com/Course-Materials/pdf/android/Android-Coding-Style.pdf

코드에 달린 주석을 살펴보면 쓸데없는 주석이 많습니다. 그런 주석중 대표적인 형태가 이런겁니다.

"이 클래스는 사용자 관리를 위한 클래스 입니다." 있으나 마나한 주석이죠. 

그 보다는 어떤 동작을 하는지 설명하는 주석이 좋은데 잘 안 와닿습니다. 그럴때는 3인칭 관점에서 주석을 써보시죠. 좀 더 의미있는 주석이 나올거 같습니다.

이런 영상 보면 소프트웨어 개발에 대한 일을 하고 있다는게 참 행복하게 느껴집니다. :)

두달에 걸쳐 진행된 Play! 프레임워크에 대한 스터디가 끝났습니다. 

처음에 5명으로 작게 시작했던 스터디라 끝까지 진행될 수 있을까 걱정했었는데 기우더군요. 많은 분들이 끝까지 스터디에 참여하셨고 이제 좀 더 진행하자는 의견까지 나왔습니다.

두번째 스터디는 4월9일(화요일)에 시작합니다. 

1차와 동일하게 Play For Scala 책을 교재로 사용하며 온라인과 오프라인 병행으로 진행합니다. 지금 스터디 신청받고 있으니 참여를 원하시는 분들은 페이스북 그룹(https://www.facebook.com/groups/400984499987421/)에 가입하시고 신청하시면 됩니다. 

ps) 플레이 스터디를 플레이 사용자 그룹으로 확대했습니다. 플레이 쓰시는 분들 동참하셔서 같이 경험을 공유하시죠.

이런 서비스 하나 있으면 좋겠다 하는 생각은 누구나 합니다. Programmable Web에 올라오는 수많은 오픈 API들을 보면서 이런 서비스들을 잘 엮어주는 서비스 없나. 그런것 있으면 참 좋을거 같은데..하는 생각을 했습니다. 있네요. ^^;

Zapier(https://zapier.com/)는 코딩 한줄 안해도 원하는 서비스를 엮을수 있도록 해줍니다. gmail에서 메일을 받아서 evernote로 남기는 작업을 어떻게 통합하는지 한번 보시죠.

통합작업이 아무리 쉬워도 내가 원하는 서비스가 없다면 소용없죠. Zapier를 이용해 통합할수 있는 서비스에 어떤것들이 있는지는 https://zapier.com/zapbook/에서 확인 가능합니다. 제가 아는 서비스는 이미 대부분 지원하는군요. 와우!

UX도 깔끔하고 정말 맘에 드는 서비스네요.

Last year I attended TED challenge in Korea. It was a Korean Round to find a TED 2013 speakers in the world. I voted her because she spoke her life. It was not a just presentation.

We have little opportunity to hear about the real life of North Korea's refugee. Latest movie, Berlln is a movie about North Korea. But it emphasize special agent too much to catch people interesting.

I hope that her message remind many people how much serious north korea's refugee life is.   

LinkedIn에 올라오는 기사중에도 유용한것들이 많습니다. 그중에 업무를 편하게 해주는 모바일 앱을 소개하는 기사가 올라왔네요. 이중에는 evernote, dropbox, trello처럼 이미 많이들 사용하고 있는것들도 보이네요.

이것외에도 컨퍼런스 콜 서비스인 UberConference는 꽤 유용해 보입니다.

http://www.linkedin.com/today/post/article/20130312182519-2967511-7-must-have-free-mobile-apps-to-do-your-job-better