삼각형의 결정 조건

python koan 을 풀어나가다 오늘 뜻밖의 난관에 봉착했다.

   1: def trianlge(a, b, c):

   2:     pass

   3:  

   4: with self.assertRaises(TriangleError):

   5:     triangle(2, 4, 2)

triangle(a, b, c) 에서 a, b, c 가 삼각형의 각 변의 길이를 의미할 때,
triangle(2, 4, 2) 에서 TriangleError를 raise 하기만 하면 되는 데...
아무리 쳐다보고 있어도 triangle(2, 4, 2) 가 왜 exception 이 되는지 이해가 안되었다.

googling 을 하다가 삼각형의 결정조건 이라는 듣보잡 단어를 발견, 아래와 같은 법칙이 있다는 것을 알게 되었다.

      “삼각형의 세변이 주어졌을 때, 가장 긴 변은 나머지 두 변의 합보다 작다”
      (몰바이데의 공식)

뭔가 어렴풋이 기억이 나는 듯 하면서도 듣보잡 같은 이 기분은 뭘까?
정규교육에 대학교육(사립)도 받은 나인데... 교육의 실패인지 개인의 실패인지,

거 참, 씁쓸한 11월, 한겨울 밤이구나!

Python TDD example 을 보고 난 후

 

python 을 이용해서 TDD 하는 예제를 찾아보니, youtue 에 재미있는 예제가 있었습니다.

간단해서 python 을 잘 모르는 사람도 할 수 있을 거 같아 따라 해 봤는데 재미 있었습니다.

동영상을 통해서 3가지 사실을 알게 되었는데,

첫째는 python 에서 unittest 수행하는 방법을 알게 되었다는 것,

둘째는 pytddmon 을 이용해서 continuous testing 을 수행할 수 있다는 것,

셋째는 TDD problems 란 사이트를 알게 되었다는 것입니다. TDD를 이용해 볼 수 있는 많은 예제가 있는 사이트입니다.

남이 하는 코딩을 그저 쳐다보기만 해도 많은 것을 얻을 수 있다는 생각이 들었습니다.

프로그래머 작업 시간 변환표

재미있고 공감이 가는 article이다.

http://coding.abel.nu/2012/06/programmer-time-translation-table/

프로그래머가 30초짜리 일이라고 말한다면 그건 실제로는 1시간짜리 일이란 얘기다.  (혹은 그 이상). 나도 비슷한 경험을 많이 했기 때문에 더 와닿는 글이다. (간단한 일이라고 말하고 하루종일 보고 있기..).

팀에서도 agile 을 진행하고 매 scrum 마다 backlog 에 대한 estimation 을 하지만, 항상 주먹구구식이며 review 때도 작업 시간에 대한 얘기는 하지 않는다. (완료 여부가 더 중요하게 생각되므로..)

ariticle 에서 저자는 esitmation 을 하고 후에 작업 완료 후에 실제 작업 시간과 비교해 보고 차이점을 생각해 봐야 배울 수 있는 게 있다고 얘기하고 있다.
estimation 에서 뭘 놓치고 있었는지 알게 된다면, 다음번 estimation에서는 더 정확한 작업 시간을 예상할 수 있을 것이다.

다음번 review 시간에는 estimation time 을 review 해 볼 수 있도록 분위기를 만들어야 겠다.

<<프로그래머의 작업 시간 변환표>>

Estimate	The Programmer Thinks	What the Programmer Forgot	Actual Time
30 seconds	There’s just a small change to the code to be done. I know exactly what to type and where. It takes 30 seconds to type.	Time for starting the computer, the development environment and getting the right source. The time to build, test, check in and document the fix	1 hour
5 minutes	It’s a minor thing, I just have to look up the exact syntax on google and fix it.	It’s quite rare to find exactly the right information on the first try. Even if it is found, it probably needs some adjustments before it works. Add time for building, testing etc.	2 hours
1 hour	I know how to do it, but it’s some code to write so it will take some time.	1 hour is too tight to have any margin for unforeseen problems. Something always fails.	2 hours
4 hours	It’s some code to write, but I roughly know the step. I know the Wizzabanga module of our standard framework can do it, but I have to check the documentation on exactly how to call it.	This is probably the only realistic estimation. It is large enough to have some margin for unexpected problems, while the task is still small enough to grasp.	4 hours
8 hours	I first have to refactor the Balunga class into two, then I’ll add a call to the Wizzabanga code and finally add the new fields to the GUI	There’s a lot of dependencies on the Balunga class from different parts of the system. About 40 different files have to be adjusted. The newly added field in the GUI has to be added in the database as well. 8 hours is too large to grasp completely. There will be more steps than the programmer thought of when estimating.	12-16 hours
2 days	It’s really quite a lot to code. I have to add some new tables to the database, a GUI for those and then the logic to read and write data to the tables.	2 days of work is too large to overview for most developers. There will surely be things that are missed. Not just small things, but entire major pieces of functionality required will be forgotten during the estimation.	5 days
1 week	Ouch… that’s a HUGE task. I don’t have a clue on how to do it, but I can’t say I don’t know. One week should be enough, I hope, I really hope, but I can’t ask for more or they’ll think I’m not competent enough.	The task is way too large to get an understanding of for most programmers. It has to be sent back to an architect that can help splitting it in smaller parts and provide some direction how it should be solved. The architect might find a simple way to do it – or find that there’s a lot more work than expected.	2-20 days

베트남 여행 준비

베트남 여행 준비

비엣남에 가려고 한다. 진짜 동남아에 가게 되다니.

http://blog.naver.com/icecoolmt/130140407151

2011, 무엇을 읽고 살았나

2011년 읽은 책을 정리하자

1. 은하수를 여행하는 히치하이커를 위한 안내서(1~3)
2. NHN은 이렇게 한다! 소프트웨어 품질관리
3. Y: The last man
4. 프로그래머의 길, 멘토에게 묻다
5. 베르나르 베르베르의 상상력 사전
6. The road
7. 최악의 외계인
8. Captin America(1~3)
9. 서유요원전(1)
10. 이제 지구는 누가 지키지
11. Effective Java
12. 미친 말의 수기
13. 공중그네
14. 촌마게푸딩
15. 프로젝트가 서쪽으로 간 까닭은

막상 오늘에서야 적어보려하니 생각이 잘 나지 않는다.
올해는 열심히 기록해 놔야겠다.

내용은 다음에 다시 정리할 기회가 있을테니..
firefox라서 그런지, 블로그에 글 쓰기가 쉽지 않다.