codekata.com Open in urlscan Pro
52.219.113.155  Public Scan

Form analysis
1 forms found in the DOM

GET http://google.com/search

<form action="http://google.com/search" method="get">
  <fieldset role="search">
    <input type="hidden" name="q" value="site:codekata.com">
    <input class="search" type="text" name="q" results="0" placeholder="Search">
  </fieldset>
</form>

Text Content

>


CODEKATA


BECAUSE EXPERIENCE
IS THE ONLY TEACHER

 * RSS


Navigate…» PragDave» Kata» Archives» RSS
 * PragDave
 * Kata
 * Archives


CODEKATA

(11 Comments)

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 from 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.


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.

Remember that the point of the kata is not arriving at a correct answer. The
point is the stuff you learn along the way. The goal is the practice, not the
solution.


LINKS

 * A description of how this all started

 * Sometimes ‘kata’ isn’t quite the right word; karate uses other techniques to
   teach too.


THE KATA

 * Kata 1: Supermarket pricing. Pricing looks easy, but scratch the surface and
   there are some interesting issues to consider.

 * Kata 2: Karate Chop. A binary chop algorithm is fairly boring. Until you have
   to implement it using five totally different techniques.

 * Kata 3: 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.

 * Kata 4: Data Munging. Implement two simple data extraction routines, and see
   how much they have in common.

 * Kata 5: Bloom Filters. Implement a simple hash-based lookup mechanism and
   explore its characteristics.

 * Kata 6: Anagrams. Find all the anagram combinations in a dictionary.

 * Kata 7: Reviewing. What does our code look like through critical eyes, and
   how can we make our eyes more critical?

 * Kata 8: Objectives. What effects do our objectives have on the way we write
   code?

 * Kata 9: 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.”

 * Kata 10: 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?

 * Kata 11: Sorting it Out. Just because we need to sort something doesn’t
   necessarily mean we need to use a conventional sorting algorithm.

 * Kata 12: Best Sellers. Consider the implementation of a top-ten best sellers
   list for a high volume web store.

 * Kata 13: Counting Lines. Counting lines of code in Java source is not quite
   as simple as it seems.

 * Kata 14: Trigrams. Generating text using trigram analysis lets us experiment
   with different heuristics. (And it let’s us create new, original Tom Swift
   stories…)

 * Kata 15: Playing with bits. A diversion to discover the pattern in some bit
   sequences.

 * Kata 16: Business Rules. How can you tame a wild (and changing) set of
   business rules?

 * Kata 17: 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.

 * Kata 18: Dependencies. Let’s write some code that calculates how dependencies
   propagate between things such as classes in a program.

 * Kata 19: Word chains. Write a program that solves word chain puzzles (cat →
   cot → dot → dog).

 * Kata 20: Klondike. Experiment with various heuristics for playing the game
   Klondike.

 * Kata 21: Simple Lists. Play with different implementations of a simple list.

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.


CODEKATA: HOW IT STARTED

(4 Comments)

(This is a long one. It explains how I discovered that something I do almost
every day to improve my coding is actually a little ritual that has much in
common with practice in the martial arts…)

Read on →


KATA, KUMITE, KOAN, AND DREYFUS

(6 Comments)

A week or so ago I posted a piece called CodeKata, suggesting that as developers
we need to spend more time just practicing: writing throwaway code just to get
the experience of writing it. I followed this up with a first exercise, an
experiment in supermarket pricing.

Read on →


KATA01: SUPERMARKET PRICING

(16 Comments)

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.

Read on →


KATA02: KARATE CHOP

(17 Comments)

A binary chop (sometimes called the more prosaic binary search) finds the
position of value in a sorted array of values. It achieves some efficiency by
halving the number of items under consideration each time it probes the values:
in the first pass it determines whether the required value is in the top or the
bottom half of the list of values. In the second pass in considers only this
half, again dividing it in to two. It stops when it finds the value it is
looking for, or when it runs out of array to search. Binary searches are a
favorite of CS lecturers.

Read on →


KATA03: HOW BIG? HOW FAST?

(10 Comments)

Rough estimation is a useful talent to possess. As you’re coding away, you may
suddenly need to work out approximately how big a data structure will be, or how
fast some loop will run. The faster you can do this, the less the coding flow
will be disturbed.

Read on →


KATA04: DATA MUNGING

(23 Comments)

Martin Fowler gave me a hard time for Kata02, complaining that it was yet
another single-function, academic exercise. Which, or course, it was. So this
week let’s mix things up a bit.

Here’s an exercise in three parts to do with real world data. Try hard not to
read ahead—do each part in turn.

Read on →


KATA05: BLOOM FILTERS

(12 Comments)

There are many circumstances where we need to find out if something is a member
of a set, and many algorithms for doing it. If the set is small, you can use
bitmaps. When they get larger, hashes are a useful technique. But when the sets
get big, we start bumping in to limitations. Holding 250,000 words in memory for
a spell checker might be too big an overhead if your target environment is a PDA
or cell phone. Keeping a list of web-pages visited might be extravagant when you
get up to tens of millions of pages. Fortunately, there’s a technique that can
help.

Read on →


KATA06: ANAGRAMS

(23 Comments)

Back to non-realistic coding this week (sorry, Martin). Let’s solve some
crossword puzzle clues.

Read on →


KATA07: HOW’D I DO?

(3 Comments)

The last couple of kata have been programming challenges; let’s move back into
mushier, people-oriented stuff this week.

Read on →
← Older Blog Archives


RECENT POSTS

 * CodeKata
 * CodeKata: How It Started
 * Kata, Kumite, Koan, and Dreyfus
 * Kata01: Supermarket Pricing
 * Kata02: Karate Chop
 * Kata03: How Big? How Fast?
 * Kata04: Data Munging
 * Kata05: Bloom Filters
 * Kata06: Anagrams
 * Kata07: How’d I Do?
 * Kata08: Conflicting Objectives
 * Kata09: Back to the Checkout
 * Kata10: Hashes vs. Classes
 * Kata11: Sorting It Out
 * Kata12: Best Sellers
 * Kata13: Counting Code Lines
 * Kata14: Tom Swift Under the Milkwood
 * Kata15: A Diversion
 * Kata16: Business Rules
 * Kata17: More Business Rules
 * Kata18: Transitive Dependencies
 * Kata19: Word Chains
 * Kata20: Klondike
 * Kata21: Simple Lists

Copyright © 2016 - Dave Thomas (@PragDave) - Powered by Octopress