# The Native POSIX Thread Library (NPTL) is a software feature that enables the Linux kernel to run programs written to use POSIX Threads fairly efficiently.
# Thread Create/Exit 시 Linux Thread 에 비해서 엄청난 속도를 자랑한다고 함(Linux에서)
This kata arose from some discussions we’ve been having at the DFW Practioners meetings. The problem domain is something seemingly simple: pricing goods at supermarkets.
Some things in supermarkets have simple prices: this can of beans costs $0.65. Other things have more complex prices. For example:
three for a dollar (so what’s the price if I buy 4, or 5?)
$1.99/pound (so what does 4 ounces cost?)
buy two, get one free (so does the third item have a price?)
This kata involves no coding. The exercise is to experiment with various models for representing money and prices that are flexible enough to deal with these (and other) pricing schemes, and at the same time are generally usable (at the checkout, for stock management, order entry, and so on). Spend time considering issues such as:
does fractional money exist?
when (if ever) does rounding take place?
how do you keep an audit trail of pricing decisions (and do you need to)?
are costs and prices the same class of thing?
if a shelf of 100 cans is priced using "buy two, get one free", how do you value the stock?
This is an ideal shower-time kata, but be careful. Some of the problems are more subtle than they first appear. I suggest that it might take a couple of weeks worth of showers to exhaust the main alternatives.
Goal
The goal of this kata is to practice a looser style of experimental modelling. Look for as many different ways of handling the issues as possible. Consider the various tradeoffs of each. What techniques use best for exploring these models? For recording them? How can you validate a model is reasonable?
What’s a Code Kata?
As a group, software developers don’t practice enough. Most of our learning takes place on the job, which means that most of our mistakes get made there as well. Other creative professions practice: artists carry a sketchpad, musicians play technical pieces, poets constantly rewrite works. In karate, where the aim is to learn to spar or fight, most of a student’s time is spent learning and refining basic moves. The more formal of these exercises are called kata.
To help developers get the same benefits from practicing, we’re putting together a series of code kata: simple, artificial exercises which let us experiment and learn without the pressure of a production environment. Our suggestions for doing the kata are:
find a place and time where you won’t be interrupted
focus on the essential elements of the kata
remember to look for feedback for every major decision
if it helps, keep a journal of your progress
have discussion groups with other developers, but try to have completed the kata first
There are no right or wrong answers in these kata: the benefit comes from the process, not from the result.
How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practicing; applying the theory over and over again, using feedback to get better every time.
How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.
But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.
Sometimes ‘kata’ isn’t quite the right word; karate uses other techniques to teach too.
The Kata
What makes a good practice session? You need time without interruptions, and a simple thing you want to try. You need to try it as many times as it takes, and be comfortable making mistakes. You need to look for feedback each time so you can work to improve. There needs to be no pressure: this is why it is hard to practice in a project environment. it helps to keep it fun: make small steps forward when you can. Finally, you’ll recognize a good practice session because you’ll came out of it knowing more than when you went in.
Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer. I add a new kata every week or so. Invest some time in your craft and try them.
If you want to discuss kata, there’s a mailing list here, and a wiki here. However, remember that the point of the kata is not arriving at a correct answer. The point is the stuff you learn along the way.
How Big, How Fast? Quick estimation is invaluable when it comes to making design and implementation decisions. Here are some questions to make you turn over the envelope.
Checkout. Back to the supermarket. This week, we’ll implement the code for a checkout system that handles pricing schemes such as "apples cost 50 cents, three apples cost $1.30."
Hash vs. Class. Is it always correct to use (for example) classes and objects to structure complex business objects, or couple simpler structures (hash as Hashes) do the job?
More Business Rules. The rules that specify the overall processing of an order can be complex too, particularly as they often involve waiting around for things to happen.
Simple Lists. Play with different implementations of a simple list.
There are places (apart from the comments in this blog) where you can discuss Code Kata.
The first is a YahooGroups mailing list, the second an index page on the PragProg wiki.
I have to admit that I’m nervous doing this. My hope is that folks will work on the kata for a while before discussing them; much of the benefit comes from the little "a-ha!" moments along the way. So, it’ll be interesting to see how (and if) the discussion develops.
# " 사랑하지 않으면 떠나라! " 는 책을 읽으면서 개발자들이 이론, 코딩등 연습을 할 수 있는 것들이 필요하다는 얘기가 나온다. 악기 연주자들은 전문가가 되기 위해서 끊임없이 연습하고 노력해서 실제 공연에 연습한 만큼의 결과가 나오는데 개발자들은 악기 연주자들의 실제 공연과 같은 프로젝트를 진행하고 있는 회사에서 연습을 하고 있으니 자기 발전이 없다는 얘기가 나온다. 이에 개발자들도 공연에서 진정한 실력을 발휘하기 위해 연습이 필요한데 이런 연습을 할 수 있는 여러가지 자료 중에 Code Kata 를 추천하고 있다.
How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practicing; applying the theory over and over again, using feedback to get better every time.
How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.
But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.
훌륭한 개발자가 되기 위한 것은 그리 어렵지 않다고 한다...과연 그런지? Programmerthink에 올라온 글에 의하면 사실 매우 간단하다고 한다. 5세의 동심으로 돌아가 유치원에서 배운 것만 잘 실현해도 좋은 개발자가 된다고 한다. 동심으로 돌아가서 유치원 시절에 가르쳐준 것들을 생각해보자, 아마 좋은 개발자로 거듭날 수 있을 것이다. 참고로 프로그래머뿐만 아니라 일반인들도 세상을 살아가면서 우리가 어렸을때 배운 것들이 어른이 되어서도 좋은 교훈이 된다는 것은 잊지 말기 바란다.
1. 모든 것을 나누어 가지자. 오픈소스를 활용하고 가능하다면 나도 함께 동참하자. 서로 모여서 나눈다면 분명 더 좋은 결과들이 나올 수 있다.
2. 공평해라. 다른 기술, 방법, 언어들에게 기회를 주자. 내 방법만이 정답이라는 생각을 버리자. 열린 마음으로 다른 방법들에게도 기회를 주자. 특히 일부 한국 개발자들의 액티브엑스 없이는 아무 것도 할 수 없다는 그런식의 생각은 버리자.
3. 다른 사람을 공격하지 말자. .Net, Java또는 PHP를 사용한다고 공격하지 말자. 2번에 이어서 반대로 또 너무나 액티브엑스 개발자들을 공격하지 말자..그 들에게도 충분한 이유가 있기 때문이다
4. 내가 어지른 것은 내가 치우자. 프로그램을 만들었으면 계속적으로 테스트하고 더 좋은 코드를 만들도록 노력하자. 베타테스터에 붙여서 다른 사람들이 모든 오류를 찾아주기를 바라지 말고 내가 직접 더 열심히 완벽하게 만들도록 계속 노력하자. 뒷 처리 잘하라는 말..
5. 다른 사람의 것을 빼앗지 말자. 허락을 받던지 라이센스의 내용에 존중하자. 지금 사용하고 나중에 발뺌하기 없기다. 사용하고 싶다면 꼭 허락을 받도록 하자.
6. 누구를 다치게 했다면 꼭 미안하다는 말을 하자. 나보다 경험이나 실력이 없는 개발자들을 보고 욕을 하거나 무시하지 말자. 그들의 마음을 다치게 해서 좋을 일은 별로 없다. 언젠가는 그들의 도움을 받을 날이 있기 때문이다. 모두가 함께 노력해서 좋은 결과물을 얻을 수 있도록 협력하고 격려하자.
7. 먹기 전에 손을 꼭 씻자. 코드를 작성하기 전에 무엇을 어떻게 할 것인지 미리 이해를 하고 하자. 프로토타입도 만들고, 가지고 놀아보기도 하고 주변 개발자들과 이야기도 하면서 정보를 얻은 후 개발에 나서자.
8. 화장실 사용 후 물 내리자. 좋지 않은 코드를 버리거나 취소하는 일에 두려움이나 아까움을 가지면 안 된다. 절대로 자신이 만든 코드와 사랑에 빠지지 말자..형편없는 것이면 과감하게 버리자.
9. 따뜻한 과자와 차가운 우유는 몸에 좋다. 작업환경이 아주 잘 갖추어 있어야 한다. 편안한 의자, 조용한 환경, 좋은 컴퓨터, 그리고 코딩을 하기 위한 편리한 툴들이 필요하다. 오너들은 이들이 프로그램에만 신경 쓰도록 환경을 만들어 주어야 한다. 오너가 너무나 많은 희생과 요구를 한다면 더 좋은 오너를 찾아서 떠나야 좋은 프로그램이 나올 수 있다.
10. 균형 있는 삶을 가져라. 배우고, 생각하고, 운동하고, 놀고, 노래하고, 춤추고 일하는 것을 균형 있게 생활화하자. 구글의 방침처럼 자신의 시간 중 20%는 자신이 하고 싶은 아무 일이나 하게 놔두는 경영방침이 좋다. 오너들은 프로그래머들을 위하여 수면실, 게임방 같은 휴식 공간을 만들어 줘야 한다. 코딩을 하는 작업은 상당한 스트레스와 뇌에 무리를 주는 작업이다...반드시 휴식이 필요하다. 주당 80시간 이상 근무를 요구한다면 절대로 좋은 결과가 나올 수 없다.
11. 꼭 낮잠을 자자. 하루 24시간 일한다고 능률이 올라가는 것은 아니다. 휴식, 낮잠 등을 잘 활용하자.
12. 밖에 나갔을 때는 자동차를 조심하고 서로 손을 잡고 뭉쳐있어야 한다. 커뮤니티 활동은 중요하다. 블로그를 읽고, 새로운 언어나 개발 툴에 대한 정보를 얻고, 토론과 모임에 참가해서 활동하자. 혼자만의 세계에서 헤매지 말고 서로 교류하며 좋은 정보를 얻어 계속 발전해 나가자.
13. 놀라움을 잃지 말자. 매일 새롭고 놀라운 것들이 프로그래밍 세계에서 나온다. 이런 것들에 관심을 가지고 항상 새롭게 받아들이며 흥분할 줄 알아야 한다. 이런 새로운 기술들을 받아들일 준비가 돼 있어야 한다. 만약 프로그래밍이 지루하고 재미없다고 생각한다면 다른 직업을 찾아야 할 것이다.
14. 금붕어도 죽고, 햄스터도 죽고, 내가 심은 꽃도 언젠가는 죽는다...물론 나도 그런 날이 온다. 코드는 결국 시대에 뒤 떨어지고 죽기 마련이다. 결국은 이런 코드를 포기하고 새로운 코드로 작업을 해야 하는 것을 반드시 인식하자. 돈 몇 푼 아끼겠다고 쓸모없는 코드를 붙잡고 고집을 피우는 일은 없어야 한다.
15. 어릴적 동화들을 생각하고 내가 가장 먼저 배웠던 글들을 기억하자... 그 중에서도 "보라(look)"를 꼭 기억하자. 무작정 시도하지 않고는 아무것도 배우지 못한다. 계속 가지고 놀고, 보고, 배우는 것이다. 항상 프로그래밍 세계에서는 어떤 일들이 일어나고 있는지 계속 업데이트하자..정보에 뒤 처져서는 안 된다. 항상 어떤일들이 일어나고 있는지 보고 있는 자가 휼륭한 프로그래머다.
nptl-design.pdf
