노무현 대통령 배너

퇴고

Life & Culture/생각지도 2014/04/15 01:00 posted by k16wire



번역을 처음 시작할때가 기억납니다. 나름 자신있게 들고갔던 원고가 온통 빨간색으로 범벅이 되어 다시 번역하길 수차례. 책 한권을 번역하기까지 이런 과정을 몇번이고 되풀이했습니다. 


나름 번역도 많이하고 강의도 많이해봐서 저술도 수월할거라 생각했는데 오산이었습니다. 오늘 출판사에서 원고 2차 리뷰를 받았습니다. 전체적인 구성은 완성이 되었지만 원고 세부적인 내용은 아직 멀었네요. 부사장님이 리뷰해주신 내용을 제대로 반영하려면 한달은 더 작업해야 할거 같습니다. 


번역을 그만둔 이유는 '더 이상 남의 생각을 전달하고 싶지 않다.'였는데 내 생각을 책으로 전달한다는게 참 힘드네요. 국내에 Play 프레임워크에 대한 버즈가 많지않아 얼마나 많은 사람이 이 책을 찾을지 모르겠습니다만 성에 찰만큼 해봐야겠습니다.


저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

퇴고  (2) 2014/04/15
K-POP 스타 YB와 인순이 공연의 차이  (0) 2014/02/08
The Road Not Taken  (0) 2014/02/02
무한한 것에는 소중함을 느끼지 못한다.  (0) 2013/12/29
입코딩과 눈코딩만 하는 가짜 개발자  (0) 2013/12/27
눈은 똑같지 않다.  (0) 2013/11/25

탐스 스토리

Life & Culture/서평 2014/04/09 08:46 posted by k16wire

이 책을 알게된건 일전에 D-Camp에서 진행한 노진선님의 세미나를 통해서입니다. 그 후로 한참이 지나서 이제서야 책을 읽게 되었네요.


깨어 있는 자본주의(conscious capitalism)란 단순히 돈을 버는것 이상이다. 물론 돈도 벌어야 한다. 하지만 그와 동시에 후원자들을 무언가 의미 있는 일과 연결해주고, 세상에 큰 영향을 미치는 성공적인 사업을 하는 것이다.

탐스가 지향하는 사업 방향을 잘 나타내주는 말이라는 생각이 듭니다. 저자처럼 독자도 자신의 열망이 무엇인지 알기 위해 다음 질문을 던져보라고 말합니다. 원래 질문은 3개인데 전 이 하나만 맘에 드네요. 

평생 돈 걱정을 할 필요가 없다면, 무엇을 하면서 살겠는가?


이 책에 나오는 이야기는 아니지만 사업이 얼마나 어려운지 실감하게 만들어줬던 이야기가 생각납니다.

내가 아무리 맛있는 커피를 싸게 팔아도 내 가게 옆에 스타벅스가 생기고, 까페 베네가 생겨서 내가 망하는것은 내가 예측할수도 없고 내가 막을수도 없는 일이다. 그게 바로 사업이다.


전 요즘 스타트업 바람에 휩쓸려서 생각없이 사업을 시작하는것은 위험하다는 경고를 하고싶습니다. 그래도 사업을 하겠다면 두려움을 이기는게 중요한데 책에서 설명하는 두려움 해소법중 한가지를 소개합니다.

가능한 많은 충고를 구하는 것이다. 상대가 누구든 상관없다. 그냥 묻는 것만으로도 모든 사람들에게서 훌륭한 충고를 얻을 수 있다. 인터넷을 이용하면 거의 세상 모든 사람에게 연락할 수 있다.


책에 등장하는 또 다른 재미있는 사업이 sendABall.com입니다. 다른 사람을 대신해서 예쁜 공을 선물로 보내주는 사업인데 이 사업모델이 성공한 이유는 단순함 때문이라고 설명합니다. 저자 블레이크는 자신의 삶 자체를 단순하게 만들어서 이 원리가 의미있는 인생을 사는데도 유용하다는 사실을 몸소 증명해 보이고 있습니다. 이 말에 공감하는게 뭔가 설명하는데 궁색하거나 복잡하면 결국 실패했습니다. 설득하는데 실패했거나 도구를 쓰라고 확산하는데 실패했죠. 쉽고 단순하게 설명할수 있는 사람이 잘 아는 사람입니다.

성공하고 싶다면 단순하게 생각하라.


책 앞에 나왔지만 이 말이 의미있게 다가온것은 저자가 책을 마무리 하면서 다시한번 언급했을 때입니다. 최근에 봤던 성공의 정의중 가장 와 닿았습니다.

한때 내가 살았음으로 인해

단 한 명의 삶이라도 더 편안해지는 것

그것이 바로 성공


내 머릿속에 잠든 아이디어가 정말 괜찮은 아이디어라면, (당신이 정말 그렇다고 믿는다면)당신을 그것을 실행에 옮겨야 할 의무가 있다.


http://book.daum.net/detail/book.do?bookid=BOK00018059363IN


저작자 표시 비영리 변경 금지

'Life & Culture > 서평' 카테고리의 다른 글

탐스 스토리  (0) 2014/04/09
칸반과 스크럼  (0) 2013/05/21
시작하는 습관(Poke the Box)  (0) 2013/05/12
남자의 물건과 가까이  (0) 2013/05/06
단순한 디자인이 성공한다.  (0) 2012/12/31
린 스타트업(Running Lean)  (0) 2012/12/20

멤버변수 타입과 클린코드

Work & Study/TechTalk 2014/03/31 11:48 posted by k16wire

코드를 리팩토링하다가 배운것 하나를 정리해 봅니다. 아래와 같은 이메일 발송을 위한 VO가 있습니다.

public class MailContents {

private String[] to;

private String subject;

private String text;

private boolean isHtml = true;


public MailContents(String[] to, String subject) {

this.to = to;

this.subject = subject;

}


public MailContents(String from, String[] to, String subject) {

this.from = from;

this.to = to;

this.subject = subject;

}


public MailContents() {

}


}


메일을 받게될 to가 Stringp[] 으로 되어 있네요. 이 객체를 만드는 서비스는 DAO를 호출한 결과로 이 값을 설정하는데 반환값이 List<String> 이어서 아래와 같은 형변환이 일어납니다.

private String[] getMailRecipients(Long projectId) {

        String[] recipients memberRepository.findRecipients(projectId);

  return recipients.toArray(new String[recipients.size()]);

}


문제는 이와 같은 형변환이 이 객체를 사용하는 곳곳에서 일어난다는데 있습니다. 반드시  String[] 배열을 사용해야 하는게 아니라면 데이터를 반환하는 메소드의 반환타입(여기서는 List<String>) 쓰는게 간결한 코드를 만들수 있습니다. 변환이 필요하다면 가능한 중간에 변환하지 말고 마지막까지 변환을 미루는게 좋습니다.



저작자 표시 비영리 변경 금지

Play 책 저자 워크샵을 진행하면서 정말 많은 도움을 받았습니다. 제가 생각하지 못했던 부분에 대한 많은 지적과 의견을 보면서 리뷰가 얼마나 중요한지 다시한번 실감했네요.

그래서 이번에는 책에서 만드는 예제코드에 대한 워크샵을 진행하려 합니다. 

  • 일정: 4월중
  • 시간: 오후 반나절(5시간+)
  • 장소: 강남역 근처 TOZ
  • 참석인원: 3명
  • 내용: 제가 쓰고있는 Play 책에서 진행하는 실습 
  • 자격조건
    • 실습을 위해 노트북을 가져올수 있다.(윈도우, 맥 둘다가능)
    • 자바로 개발이 가능해야 한다.
    • Play를 모른다. (전혀 몰라도 됩니다.)

신청하신 분들이 모두 참석 가능한 날로 잡을생각이라 날짜는 미정입니다.  

반나절만에 Play를 제대로 배워볼수 있는 좋은기회를 놓치지 마세요.


참석을 원하시는 분은 이 글에 비밀댓글로 '이름/이메일/연락처/간단소개'를 남겨주세요.

리뷰에 적합한 분인지 판단해서 진행하기 때문에 신청은 선착순이 아니며 신청은 이번주 수요일까지 받겠습니다.


예상했던 인원보다 신청자가 많아서 이정도에서 신청 마감합니다.

신청해주신 분들께는 개별적으로 연락드리겠습니다.

저작자 표시 비영리 변경 금지

자바를 이용해 빠른 웹개발을 가능하게 해주는 Play 프레임워크(http://www.playframework.com/)에 대한 책을 쓰고있습니다. 현재 70~80%정도 원고가 마무리되었고 원고에 대한 1차 출판사 리뷰를 받았습니다. 원고를 마무리하기 전에 현재 수준의 원고를 가지고 저자 워크샵을 진행하고자 참여하실분을 모십니다.


저자 워크샵은 저자와 참가자가 만나서 저작물에 대한 피드백을 주고받는 모임입니다. 저자는 저작물에 대한 반응을 얻을수 있고 참가자는 저작물을 미리 볼수 있습니다. 자세한 내용은 아래 URL을 참고하세요.

https://www.ibm.com/developerworks/community/blogs/9e635b49-09e9-4c23-8999-a4d461aeace2/entry/273?lang=en


  • 참가인원: 최대 10명
  • 시간: 2시간~3시간
  • 날짜 및 시간: 3월 17일 or 18일, 저녁 7시
  • 장소: 강남역 토즈
자바를 모르시는분은 아무래도 참여하기 힘들거 같고 Play는 알고 계셔도 되고 모르셔도 됩니다. 
워크샵 당일 노트북을 가져오실수 있는분 우대합니다.
17일이나 18일중 가장 많은분이 참석하실수 있는 날짜에 한번만 진행합니다.

참여를 원하시는분은 이 글에 다음과 같이 비밀댓글을 남겨주시거나 제게 메일(k16wire@gmail.com)주세요.

ex) 황상철/이메일/핸드폰/17일 가능/Play 잘 알아요.


저작자 표시 비영리 변경 금지

빌드배포 시스템 JARVIS

Work & Study/TechTalk 2014/02/26 11:10 posted by k16wire

작년은 회사에서 사용할 빌드/배포 시스템을 만드느라 보낸거 같습니다. 모든 내용은 아니지만 간단하게 이 시스템을 만들면서 고민했던 내용을 정리해서 회사 블로그 README에 올렸습니다.


http://readme.skplanet.com/?p=7148


빌드 배포 시스템에 관심있는 분들 한번씩 읽어보세요.



저작자 표시 비영리 변경 금지

FWIW

Relation/번역 2014/02/10 01:09 posted by k16wire

FWIW = For What It's Worth


저작자 표시 비영리 변경 금지

뒤 늦게 K-POP 스타라는 프로를 몰아서 봤습니다. 그런데 조금 재밌는게 느껴져서 적어봅니다. 2012년 Top10 스페셜 무대에서는 인순이씨의 특별공연이 있었고 2013년 Top10 스페셜 무대에서는 윤도현씨의 공연이 있었습니다. 둘 다 유투브에 올라와 있으니 한번 보시죠.





어떤 차이가 느껴지시나요. 전 YB의 공연을 훨씬 좋게봤습니다. 인순이씨의 공연도 경연자들의 노래로 시작합니다만 인순이 씨가 나온 1분 15초 뒤에는 인순이씨의 독무대가 되는거 같습니다. 경연자들을 한방에 코러스로 바꿔 버리네요. 그에 반해 YB의 무대는 처음부터 끝까지 같이 어우러져서 공연합니다. YB가 기타를 치고 경연자들이 노래를 부르는 장면도 보기좋고 마지막 피날래를 경연자들이 주고받으며 부르는 것도 멋지네요. 심사위원, 관객들 입가에 웃음이 안떠나는것도 바로 그런모습 때문이 아닐까요.


선배란 저 무대위의 YB 같이 후배들이 같이 빛나도록 만들어 주는 사람인거 같습니다.


저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

퇴고  (2) 2014/04/15
K-POP 스타 YB와 인순이 공연의 차이  (0) 2014/02/08
The Road Not Taken  (0) 2014/02/02
무한한 것에는 소중함을 느끼지 못한다.  (0) 2013/12/29
입코딩과 눈코딩만 하는 가짜 개발자  (0) 2013/12/27
눈은 똑같지 않다.  (0) 2013/11/25

The Road Not Taken

Life & Culture/생각지도 2014/02/02 03:14 posted by k16wire

Two Roads diverged in a yellow wood,

And sorry I could not travel both

And be one traveler, long I stood

And looked down one as far as I could

To where it bent in the undergrowth;


Then took the other, as just as fair,

And having perhaps the better claim,

Because it was grassy and wanted wear,

Though as for that the passing there

Had worn them really about the same,


And both that morning equally lay

In leaves no step had trodden black.

Oh, I kept the first for another day!

Yet knowing how way leads on to way,

I doubted if I should ever come back.


I shall be telling this with a sigh

Somewhere ages and agesh hence:

Two roads diverged in a wood, and I-

I took the one less traveled by,

And that has made all the difference.


저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

퇴고  (2) 2014/04/15
K-POP 스타 YB와 인순이 공연의 차이  (0) 2014/02/08
The Road Not Taken  (0) 2014/02/02
무한한 것에는 소중함을 느끼지 못한다.  (0) 2013/12/29
입코딩과 눈코딩만 하는 가짜 개발자  (0) 2013/12/27
눈은 똑같지 않다.  (0) 2013/11/25

Today is the day

Life & Culture/일상다반사 2014/01/09 01:43 posted by k16wire




저작자 표시 비영리 변경 금지

git 레파지터리를  가지고 통계 데이터를 뽑아줍니다. 


설치

사이트(http://gitstats.sourceforge.net/)에서 압축파일을 다운받아 적당한 위치에 압축을 해제하면 됩니다.

파이썬으로 되어 있어 별다른 설치가 필요없지만 내부적으로 gnuplot(http://www.gnuplot.info/)을 사용합니다. 그래서 gnuplot도 설치해 줍니다.

brew update

brew install gnuplot

설차하다 중간에 libpng를 찾을수 없다는 에러가 떠서 brew(http://brew.sh/)를 업데이트 한 다음 다시 설치하니 정상적으로 끝났습니다.


실행

gitstats를 실행하려면 분석할 git 레파지터리를 clone 받아야 합니다. 

gitstats [options] <gitpath..> <outputpath>

gitpath는 미리 로컬에 clone 해놓은 위치를 명시해주면 됩니다. 실행하면 결과는 html 형식의 레포트로 나옵니다. gitstats 사이트에 가보면 레포트 샘플을 확인할수 있습니다.


http://gitstats.sourceforge.net/examples/dokuwiki/activity.html


저작자 표시 비영리 변경 금지

내게 주어진 시간이 얼마나 남았는지 알게 된다면, 정말로 원하는 일에 집중하며 삶을 더욱 가치 있게 살 수 있을 겁니다. 죽음이 결코 나쁜것만은 아닌거죠. 영원한 삶이 항상 좋은 것은 아닙니다. 

무한한 것에는 소중함을 느끼지 못하기 때문이죠.

- 셀리 케이건 -


http://navercast.naver.com/magazine_contents.nhn?rid=1089&contents_id=30803


저작자 표시 비영리 변경 금지

요즘에는 코딩 면접관으로 들어갈 기회가 많습니다. 어제도 그런 면접이 하나 있었는데 느낀바가 있어서 적어봅니다. 어제 본 면접은 피면접자가 미리 풀어온 결과를 가지고 이야기하면서 평가를 하는 방식이었습니다. 

문제는 5문제. 어떤 문제를 풀었는가 살펴보니 쉬운 문제만 풀고 어려워 보이는 문제는 손도 못 댄거 같더군요. 이런 경우 변별력을 따지기 힘들어 못 푼 문제를 다시한번 도전해 볼것을 권하는 편입니다.

여기 화이트 보드가 있어요. 여기다가 직접 한번 풀어보시죠.

그 문제는 언뜻 보기에는 어려워 보이지만 사실은 5-6줄로 풀수 있는 문제였습니다. 그런데 그 친구는 결국 문제를 풀지 못했습니다. 그냥 보내기 아쉬워서 어떻게 풀면되는지를 3-4분간 설명해줬습니다.

그 친구가 면접을 끝내고 아쉬워 하면서 하는 말이 "분명 아는건데 구현을 해본적이 없어서.."


 아무리 쉬운 문제도 직접 코딩해본적이 없으면 어렵습니다. 근래 입코딩, 눈코딩만 하는 개발자들이 간혹 보이는데 가짜 개발자입니다. 말 잘하는 가짜 개발자들이 개발에 대해서 이러쿵 저러쿵하는 말에 현혹되지 마시고 직접 코딩해보고 느껴보세요.



  

저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

The Road Not Taken  (0) 2014/02/02
무한한 것에는 소중함을 느끼지 못한다.  (0) 2013/12/29
입코딩과 눈코딩만 하는 가짜 개발자  (0) 2013/12/27
눈은 똑같지 않다.  (0) 2013/11/25
성형수술  (0) 2013/11/11
진짜는 귀하다.  (0) 2013/10/08

PMI 회고

Work & Study/애자일 개발 2013/12/15 23:32 posted by k16wire

PMI 회고는 가장 흔하게 많이 사용하는 회고입니다. 사용하기 쉽지만 Minus를 쓰라고 하면 주저하는 사람들이 많습니다. Minus를 내려면 훈련이 필요합니다. Minus에 익숙치 않은 사람들에게 어떤 말을 해주면 좋을까요.

Minus는 비판이 아니라 제안입니다. 현재 상태를 개선하고자 하는 제안이자 아이디어입니다.

개선을 하려면 문제의식이 있어야 하고, 제안을 하려면 유심히 살펴봐야 합니다. 건성으로 아무 생각없이 보면 어떤 제안도 떠오르지 않습니다. 회고를 해보세요. 그러면 평소 주의깊게 관찰하고 문제의식을 갖고있는 사람이 누구인지 알게될겁니다.

 

저작자 표시 비영리 변경 금지



애자일 방법론의 하나인 스크럼에는 크게 3가지 역할이 존재합니다.:제품책임자, 스크럼마스터, 스크럼 팀  스크럼 프로세스 모델 어디에도 팀장의 역할은 없습니다. 


스크럼팀의 궁극적인 형태는 자기 조직적인 팀(Self Management Team) 입니다. 자기 조직화된 팀이 무엇입니까? 팀장이 업무를 일일이 할당하는것이 아니라 각자가 직접 자기가 할일을 플래닝하고 진행하는 팀입니다. 자기 조직적인 팀은 팀장이 없는 팀일까요.


스크럼뿐 아니라 애자일 조직에서는 전통적인 형태의 관리 팀장은 설 자리를 잃어버립니다. 애자일 조직에 맞는 팀장 리더십은 섬김의 리더(Servant Leader)입니다. 과거처럼 통제하고 관리하려 든다면 애자일의 장점은 살릴수 없을뿐더러 효과도 볼 수가 없습니다. 


스크럼 도입시 실무를 진행하는 사람에게 최대한의 권한을 주는게 중요합니다. 하지만 권한 위임은 어렵습니다. 흔히 이렇게 말하죠.

권한은 위임할 수 있지만 책임은 위임할 수 없다.

 기존 조직구조는 그대로 남겨둔채 권한만 위임한다면 팀장은 책임만 떠안게 될 확률이 높습니다. 이런 상황에 팔짱끼고 가만히 앉아있을 팀장은 어디에도 없습니다. 프로젝트에 적극적으로 개입하게 됩니다. 

그래서 가능하다면 조직구조를 프로젝트에 맞게 바꿔야 합니다. 평가체계도 바꿔야 합니다. 개인평가보다는 스크럼 팀단위 평가가 이루어져야 합니다.


스크럼과 같은 애자일 개발을 적용한다면 팀장은 손 털고 나가야 할까요? 아닙니다. 오히려 더 고도의 교묘할 정도의 관리능력을 발휘할 수 있어야 합니다. 팀원에게 (일을) 시키고 쪼고 (했는지 안했는지) 일일히 체크해서 성과를 내는게 아니라 (팀원 각자가) 스스로 알아서 일을 챙기고 꾸려나가도록 만들어야 합니다. 비유를 하자면 공부 열심히 하라고 다그치는 부모에서 스스로 공부하도록 배려하는 부모가 되야 하는 것이죠.


어렵죠. 팀장의 역할이 사라지는게 아니라 한 차원 높아지는거라고 생각합니다.

  


저작자 표시 비영리 변경 금지



요즘 사내에서 애자일 교육을 진행하면서 몇가지 스크럼에 대한 단상이 떠올랐습니다. 


스크럼 프로젝트에서는 매 스프린트마다 누가 무슨일을 할지를 스스로 정하라고 이야기합니다. 하지만 모두가 이런 방식에 익숙한것은 아닙니다. 그래서 처음 이런 방식으로 업무배정을 하게되면 팀원들은 매우 불안해 합니다. 편안함을 느끼지 못합니다. 내가 할수 있을까. 해도 되나. 


팀의 리더도 불안해 합니다. 우리 팀에는 숙련된 팀원외에 아직 경험이나 역량이 부족한 팀원들이 많은데..이런 방식으로 일하는게 맞을까? 


자율이 오히려 부담으로 작용하는 것 입니다.

이런 부분을 배려하는게 필요합니다.


저작자 표시 비영리 변경 금지

눈은 똑같지 않다.

Life & Culture/생각지도 2013/11/25 20:00 posted by k16wire



눈은 항상 힌색이지만

한번도 똑같다고 생각해본적은 없다.

                                            - 스노우보더 김은광 -


저작자 표시 비영리 변경 금지

성형수술

Life & Culture/생각지도 2013/11/11 18:12 posted by k16wire

누군가를 위해서 성형수술을 받는 사람은 꼭 나중에 후회한다고 합니다.

하지만 자기 자신을 위해서 받는 사람은 절대 후회하지 않는다고 합니다.


누군가가 아닌 자기 자신을 위해서 행동하고 계십니까


저작자 표시 비영리 변경 금지

진짜는 귀하다.

Life & Culture/생각지도 2013/10/08 15:23 posted by k16wire

돈 생기면 성형하지 말고 좋은 공연을 보고 콘서트장에 가라. 

외형적인 데 말고 나의 내면을 업그레이드하는 데 돈을 썼으면 좋겠다. 

진짜는 귀하다. 흔하지 않다. 

내가 나를 귀하게 만들어야겠다는 자존심이 있어야 한다.

나는 예술가다. 

나는 배우다. 

남이 알아주기 전에 내가 날 그렇게 만들어야 한다.


- 배우 최민식, 인터뷰 중에서 -


저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

눈은 똑같지 않다.  (0) 2013/11/25
성형수술  (0) 2013/11/11
진짜는 귀하다.  (0) 2013/10/08
나는 시간이 있으면 늘 상상을 하오  (0) 2013/07/02
비전이 미치는 곳까지가 그의 세계다.  (0) 2013/05/18
Nothing  (0) 2013/05/05


출처: http://blog.jr0cket.co.uk/2010/08/my-favourite-estimation-technique.html


어느 팀장님이 개발자에게 물어봅니다. 


이 스토리 개발하려면 얼마나 걸릴까? 

한 3일이면 될거 같은데요.


정말 3일이면 될까요? 이런 경우는 2가지 입니다. 

정말 개발을 잘하는 슈퍼 개발자이거나 개발을 많이 안해본 초보 개발자이거나

여러분이 프로젝트에 참여했다고 했을때 여러분 주변의 개발자가 슈퍼 개발자일 경우가 많을까요? 아니면 보통내지는 초보 개발자인경우가 많을까요? 당연히 후자의 경우가 많을겁니다.

이런 개발자들이 말하는 개발완료는 무엇을 의미할까요? 좀 심하게 말하면 코딩 다했고 자기 로컬 PC에서 잘 동작하면 개발완료라고 말할수도 있습니다. 하지만 이게 다가 아니죠.

  • 테스트도 해야하고
  • 개발서버 내지는 운영서버에 배포하기 위해서 빌드/배포도 해야합니다. 
  • 정적분석으로 코딩 표준은 지켰는지 
  • 잠재결함은 없는지
  • 보안진단
  • QA의 제3자 테스트
한달이라는 기간이 긴것 같지만 주말 제외하면 20일입니다. 여기에 생산성 지표를 70%로 잡는다면 약 14일이죠. 여기에 앞서 이야기한 작업들이 선행되다거나 후행된다면 실제 개발에 쓸수있는 기간은 더 줄어듭니다. 이런 상호간의 차이를 줄이기 위해서는 개발완료(Definition of Done)에 대한 의미를 프로젝트에 참여하는 사람들이 똑같이 이해하도록 하는게 중요합니다.

팀장님들 개발자가 3일 걸린다고 말하면 최대 한달 걸릴지도 모른다고 생각하세요.


저작자 표시 비영리 변경 금지

오는 9월7일 토요일 열리는 애자일 코리아 컨퍼런스 2013의 참가 신청을 받고 있습니다. http://onoffmix.com/event/18754


자세한 프로그램은 아래 포스터를 참고하세요.




저작자 표시 비영리 변경 금지

Good Bye

Life & Culture/일상다반사 2013/07/05 19:39 posted by k16wire

This blog doesn't talk any more.

Good bye.





저작자 표시 비영리 변경 금지

나는 시간이 있으면 늘 상상을 하오.

만약 내가 손님이라면 하고 말이오.

만약 내가 손님이라면, 누구와 어느 가게에 가서, 어떤 것을 먹고 마시고 싶어할까 하고.

만약 내가 이십대의 독신 남성으로, 좋아하는 여자를 데리고 간다면, 어떤 가게에 갈것인가.

그런 상황을 하나하나 세세한 부분까지 상상해 가지.

예산은 어느 정도인가.

그런 구체적인 예를 수없이 생각하오.

그런 생각을 쌓아가는 사이에, 가게의 이미지가 점점 명확한 형태를 잡아 가는 것이오.


- 무라카미 하루끼 '국경의 남쪽, 태양의 서쪽' 중에서 -


저작자 표시 비영리 변경 금지

'Life & Culture > 생각지도' 카테고리의 다른 글

성형수술  (0) 2013/11/11
진짜는 귀하다.  (0) 2013/10/08
나는 시간이 있으면 늘 상상을 하오  (0) 2013/07/02
비전이 미치는 곳까지가 그의 세계다.  (0) 2013/05/18
Nothing  (0) 2013/05/05
마케팅/PR/광고/브랜드의 차이  (0) 2013/04/29



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


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

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


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

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



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

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


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

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


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

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


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

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


참고자료

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


저작자 표시 비영리 변경 금지

glu 모델

Work & Study/TechTalk 2013/05/27 00:42 posted by k16wire

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 오케스트레이션 엔진은 이 모델파일을 읽어서 다음과 같은 작업을 진행합니다.

  1. 현재 배포되어 있는 상태와 모델에 정의된 상태를 비교한다.
  2. 실행 명령을 가지고 배포 계획을 만든다.
출처: http://pongasoft.github.io/glu/docs/latest/html/index.html

저작자 표시 비영리 변경 금지