Similar concept but a little simpler and avoids manually written recursion.

  notes = cycle ["c", "c#", "d", "d#", "e", "f", "f#", "g", "g#", "a", "a#", "b"]
  majorSteps = [2, 2, 1, 2, 2, 2] :: [Int]

  scale note = map (dropWhile (/= note) notes !!) . scanl (+) 0

I think it's less clear, but if you want to avoid the rescan via (!!), then

  scale note = map head . scanl (flip drop) (dropWhile (/= note) notes)

Both result in

  λ> scale "d" majorSteps
  ["d","e","f#","g","a","b","c#"]

I personally don't suggest the truly ergonomic. While it's well designed from the outset, the underpinnings are a bit lacking. The existing firmware is buggy and has issues with Mac; and the programmable software has been promised for a while now but was never delivered. To boot, the company's support is nearly non-existent, except for - thankfully - their return process.

As mentioned by gokfar, I really look forward to the ergodox group buy

While I prefer the module solution, it's not always possible when you have mutually recursive record definitions. Well, technically it is possible - but it's very unpleasant [1].

[1] http://www.haskell.org/ghc/docs/latest/html/users_guide/sepa...

I think it's referring to the sudoku TDD blog series that happened a few years back. Essentially, someone tried to implement a sudoku solver using TDD - and after several posts, never managed to finish. Peter Norvig then came along and wrote a short elegant implementation.

Some use this to say TDD - which has ties to agile - doesn't work. But most people conclude that TDD isn't a silver bullet and you have to know about your problem domain before diving in.

Here's someone elses' blog post which includes links to both sets of posts: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

Ok, that at least makes sense. But ... sudoku is a puzzle - you don't (or at least I didn't) get there by iteration and testing, you get there by a flash of insight - "if I try searching like this, I might be able to end up with a solution to any sudoku board" and few hours later I knew I was right. In that way, it is unlike almost all large-scale software development.

Agile can't generate insight from nothing, it's not a silver bullet. But at least if you have some unit tests around your cool new code, you know that you won't accidentally break it later.

Sigh - easier said than done.

Hard decisions are difficult things to do with a stress-shot mind. Particularly when it's so easily framed as "admitting defeat"

I'd like to second SICP and specifically the accompanying book - available online at http://mitpress.mit.edu/sicp/full-text/book/book.html

I'm starting to reach this point too. And I can't seem to convince myself to buy fancy (expensive) keyboards - even though I /know/ I should.

If you haven't already, just swap your CTRL and CAPS lock keys. That makes for a pleasant typing experience.

I used to use a Typematrix 2030, but have gone back to standard keyboards. I use viper and vimpulse in emacs, so I'm currently using the following mappings (in addition to a Dvorak layout):

CapsLock key = Backspace (I hate that reach)

Tilde key = Escape (for VI)

Escape key = CapsLock (for when you need it)

Backspace key = Tilde

My windows keys also function as Control, so that I don't have to be super accurate when using my pinky joint (where my pinky meets my palm) to press it.

At first, this combination looks weird. But thinking about it, it makes great sense.

Having the tilde so far away is pretty annoying in a shell, but I haven't invested the time in coming up with something better.

I prefer to have it as an additional ctrl, who needs caps anyway? And while you're at it, use the Windows keys, too (if you have 'em). Dividing keyboard shortcuts between Control, Alt, Meta (and maybe Hyper) is much nicer…

Then install smex[1] and searching for commands in the long form is much faster, so you don't need to have that many shortcuts in the first place.

And the fastest and easiest key press is the one you don't have to do: Learn to use keyboard macros, you won't regret it.

[1] http://www.emacswiki.org/emacs/Smex

I've done that, and I don't even use Emacs.

Jakob Nielson argues that, specifically in usability testing, 5 people gives you a majority of your flaws but not the entire picture - where ~15 people would give you that. That is to say, more is better but there is diminishing returns. Given this, he argues that rather then expending resources to gather the entire picture for a single iteration, it's even better to test 3 sets of 5 people with design improvements between each set.

I think this argument is slightly different than just saying 5 people is enough for any sort of study. I still would have liked to seen more people. Or at least additional studies with modifications to inspect or confirm specific aspects of their findings.

I fully agree. For instance, PHP implements it's own round function. Now there very well may be a good reason they don't just use/implement the C99 round - but one can at least expect it not to change. This isn't true, in some version (I forget which), they changed their implementation and that caused all sorts of headaches to us and our users that depend on these numbers.

Moral of the story? Don't use PHP for stats.

I used vim for about 5 years. I decided to give emacs a roll about a year ago. The first few weeks were hard, the next few were interesting, and the rest was just fun.

I suppose it's because I've always been a tinkerer and I love the fact that the wall between editing with emacs and editing emacs is so small.

Anyways, this is all old news. Everybody already knows the arguments for both sides and they're both true. I still use vim when the job fits (configs or quick edits) and I use largely emacs for my development (even if though I work at a vim shop and everybody gives me dirty looks).