The Messy Notebook

Originally performed in front of a live audience at the Go Open 2011 / Communities in Action event in Oslo.

A code kata is a simple exercise used to sharpen programming skills. You only actually practice problem solving the very first time you perform the kata. Then you repeat, and repeat again. And again. The objective of the exercise is to practice speed, technique and tools.

In the following clip I implement a variant of the Minesweeper code kata in JavaScript.

(Run it in fullscreen to see the code more clearly)

Note: I use testdriven development through most of the process. Toward the end I drop the unit testing when I finish the visuals and gameplay logic. I could drive the whole thing with unit tests but opted for a more visually interesting ending.

You can look through the code at my github account. Each commit in the repo is separate exercise done from scratch.

Libraries and tools used:

• Underscore.js
• jQuery
• Grid.js
• clAutotest
• TextMate

So I blew 150$ on a new keyboard recently. Was it worth it?

I've used a desktop Apple keyboard for a while, but never really got comfortable with it. It was just... off. I felt slower than I should, and never got used to the shape and feedback of the keys.

I've had my eye on the more classic, mechanical IBM Model-M style keyboards for a while. Jeff Atwoods recent blog post finally pushed me over the edge. I ended up with this: the Das Keyboard Model S Ultimate.

After a month of use I'm really happy with it. My typing speed has gone from 70-ish to 85-ish words per minute, and I love the feel of it.

It may not be for everyone, though. Here's my summary:

Pros:

• The keys have a  great, tactile feedback. I really like the old-school mechanical "CLICK-CLACK" feedback, it's much crisper than anything else I've used for the last decade.
• Solid build quality. It feels three times as heavy as my old Apple aluminum keyboard.
• Cool aesthetics. I mean, just look at it! It's as if Batman and Darth Vader got together to design computer hardware.

Cons:

• It has a shiny finish. Looks good... but stains really easily. I had fingermarks all over it after a few hours.
• It's loud. Really loud. "Wake up your child sleeping in the next room"-loud. I'm not kidding about his: my office is way down in the basement of our house. My Significant Other can hear me loud and clear upstairs when I'm working.

All in all: If you have the money, are considering an old-school keyboard and don't mind the noise, go for it!

This is the blog post version of a talk I gave at the JavaZone 2010 conference.

I've had dynamic programming languages (JavaScript, Ruby, Lisp) on the brain lately. A common trait of these languages is the ability to program interactively.

The concept is simple, but I think it's easier to show rather than tell what interactive programming is. Here's an example, demonstrated in IRB (Interactive Ruby).

What's happening here?

Well, I write very basic Ruby code. But watch what happens along the way. Every Ruby statement I write is evaluated and run by the environment. The result is printed back on the command line. The environment remembers my actions. I define variables and functions. I'm able to build new things on the fly, and I get instant feedback for everything I do. No recompilation or restart steps necessary.

Our usual process for software development is like a steel mill. We create a mold (write code in an IDE). Then we stamp out a chunk of steel (compile, deploy, restart). Does the steel chunk (software system) have the wrong shape? Back to the drawing board, then.

This feedback-loop is much shorter than before thanks to faster compilation, incremental compilation, faster computers and unit testing - but we still waste time running back and forth like this.

Interactive programming, on the other hand, is somewhat like working with clay; work on the actual artifact directly. Mold it, add some clay (code), keep working, see what happens. No feedback loop at all.

This isn't a replacement for our usual tools and workflow - it's a useful supplement. Yes, you'd better use steel to build a production car. But prototypes are easier to build in clay. Likewise, interactive programming is a useful utility for serious software development.

So interactive programming is useful because you work faster, due to a shorter feedback-loop. You're able to write less code, because you spend less time building infrastructure and boilerplate.

However, I suspect that the single Ruby example above didn't full drive home the point. Let's look at a few other scenarious, all of which I use regularly myself.

I sometimes use interactive programming as an systems interface for running webapps. In the clip below I start up an interactive Rails console on a testserver. This gives me access to the same APIs and data as my server backend - interactively - while the system is still running.

You can use Rails console as a replacement for a heavy web interface. Instead of building functionality you might not need, simply use the console. If you find yourself doing the same task repeatedly, then consider building a web UI for that task.

The console is also useful for small experiments while developing the system - try ideas out before commiting to them with production code.

Now, let's move on to frontend work. The Firebug plugin provides another useful interactive environment. Watch:

This was a very simple example. I do however use the same techniques when I develop more complex UIs; the Firebug console is useful for testing stuff out "live".

Unit testing is great for JavaScript development, but I often don't know exactly what I'm looking for, how I want the final result to look. The Firebug console lets me quickly, iteratively look for a solution.

With me so far? In that case I think I know what you're thinking. "I don't want to write code straight to the command line! I like my editor just fine!" Well, you could write code in your IDE and then paste it into the interactive environment. However, it would be nice if the IDE let us send code straight to the console, right? Let's look at one way of doing this.

Clojure is a young but promising programming language. It's just a few years old, but it's built on mature technology. Clojure is a Lisp dialect. What we've called interactive consoles so far, Lispers often call REPL (Read Eval Print Loops), and Lisp has a much stronger tradition of using REPL tools.

Let's look at an example in Clojure. I stay in Emacs during the entire demonstration, marking and sending code to a separate REPL process. In this example I use this workflow to work effectively with 3d graphics (OpenGL is something I know very little about, so an interactive workflow is useful to ensure I get immediate feedback while testin things out).

The clip starts with a demonstration of the basic workflow, then some simple 3d graphics play, and finally I implement the rendering of a simple Tetris game (download src here, if you wish).

What have we seen so far?

Interactive programming gives you fast feedback. You're able to work faster and write less code. This is useful for learning and exploring, for system administration and testing, and for visual prototyping.

Finally, have a look at the clips below. They are examples of Livecoding, where programmers and artist use interactive programming as a medium for performance art. The code and its output is improvised, sometimes in front of a live audience. Interesting example of skilled interactive programming taken to the extreme!

References:

A list of REPL environments

Demystifying IRB commands (interactive Ruby)

Secrets of the Rails Console Ninjas

The Firebug Console Panel

Clojure.org: 'Getting started'

in which are found tricks of the trade concerning clojure authorship

Penumbra OpenGL framework: 'Getting started'

Impromptu livecoding environment introduction

Andrew Sorenson livecoding videos

I used to hate public speaking. Sweaty palms, stomach aches... the works. However, over the last year or so I finally got over it. Speaking to a big room of people simply doesn't bother me anymore.

It somehow happened over a relatively short period of time. I talked this over with a friend recently: "what changed?" I think the following three points did the trick for me:

Know your material inside out. Throw away your index cards, force yourself to really internalize your material before presenting it. Mastery breeds confidence.

Practice practice practice. Every time you speak you'll improve, and you'll get a little more comfortable each time. Super obvious point, but speaking regularly does diminish the fear of it.

Set it in perspective. I think this was key for me. I've had several scares at the hospital during the last year (unfounded ones, fortunately!) Now I use that experience to ground myself before speaking. Compared to the loss of a loved one, how scary is it really to get up in front of a crowd of peers? "Remember that hospital waiting room? This is peanuts in comparison! Sack up, dude!"

Perhaps some of these measures will work for you as well?

I'm starting to fall in love with Clojure, and I'm having lots of fun learning the basics of it. The best way to get up to speed in new programming language is to write something useful, so that's what I'm currently doing.

My first crack at a Clojure program is a simple auto-testing tool. I like test-driven development, and I wanted a light-weight way of running my clojure unit tests continuously in the background. If I break a test, I want to find out at once. When I fix the error I want a confirmation of that as well.

An autotest workflow is extra useful when learning a new language - in that situation you should take extra small steps, with very rapid feedback cycles guiding your way.

This is what it looks like:

Keep in mind that this works best with lean, rapid unit tests (measured in seconds, not minutes). Massive fifteen-minute test-suites defeats the purpose of autotesting.

The algorithm is trivial: a one-second-interval loop that scans for changes to source files in the project directory. If file timestamps change or new files are added, a test run is triggered. The result of the test is determined by scraping the output of the terminal. The terminal is then colored green for test success or red if anything fails (I use tiny osascripts to color the terminal in different colors).

Source code:

(ns com.thomanil.autotest
  (:require clojure.contrib.shell-out))
 
(use 'clojure.contrib.shell-out)
 
(defn cmd-line [command] (sh "bash" :in command))
(defn clear-console [] (println (cmd-line "clear")))
(defn visually-indicate-test-running [] (cmd-line "osascript bin/testrunner/make-term-yellow"))
(defn visually-indicate-success [] (cmd-line "osascript bin/testrunner/make-term-green"))
(defn visually-indicate-failure [] (cmd-line "osascript bin/testrunner/make-term-red"))
(defn visually-indicate-exception [] (cmd-line "osascript bin/testrunner/make-term-red"))
(defn all-source-files [] (seq (.split (cmd-line "ls **/*.clj") "\n")))
(defn all-test-files [] (seq (.split (cmd-line "ls test/*.clj") "\n")))
(defn file-state [file-path] (cmd-line (str "ls -l -T " file-path)))
(defn state-of-src-files [] (map #(file-state %) (all-source-files)))
 
(def run-cmd "java -Xmx1G -cp lib/clojure.jar:lib/clojure-contrib.jar:.:classes clojure.lang.Script ")
(defn run-tests [] (cmd-line (str run-cmd (apply str (interpose " " (all-test-files))))))
 
(defn set-console-state [test-result]
	(let [test-status (get test-result 0) test-output (get test-result 1)]
		(when (= test-status :success)
			(println test-output)
			(println "ALL TESTS SUCCEED")
			(visually-indicate-success))
		(when (= test-status :failure)
  			(println test-output)
  			(println "SOME TEST(S) FAILED")
  			(visually-indicate-failure))
		(when (= test-status :exception)
			(println test-output)
			(println "EXCEPTIONS OCCURRED")
      		(visually-indicate-exception))))
 
(defn exception-or-failure-in-text [result]
	(cond
		(.contains result "Exception in") :exception
		(.contains result "FAIL in") :failure
	 	(.contains result "0 failures, 0 errors") :success ))
 
(defn determine-test-status []
	(clear-console)
	(let [result (run-tests)]
		(let [state (exception-or-failure-in-text result)] [state, result] )))
 
(defn run-test []
	(visually-indicate-test-running)
	(set-console-state (determine-test-status)))
 
(def monitored-files (ref (state-of-src-files)))
 
(defn files-changed? []
	(let [current-state (apply str (state-of-src-files))
		  last-state (apply str @monitored-files)]
			(if (not(= current-state last-state))
				(do (dosync
					(ref-set monitored-files (state-of-src-files)))
					:true)
				nil)))
 
(defn test-loop []
	(loop []
		(if (files-changed?) (run-test))
		(Thread/sleep 1000)
		(recur)))
 
(run-test)  ;Do first test no matter what
(test-loop) ;Wait for changes in files to trigger new tests

Disclaimer: Some of the above is probably not idiomatic Clojure code, since I'm still very much a novice in this language.

I'm not a great teacher. I don't have any special instructor credentials. I have, however, attended some bad technical presentations in the past, so I know of some common problems. Fortunately they're not too hard to fix.

I recently held a programming course of my own. Resolved to avoid as many pitfalls as possible, I invested some time to properly market, prepare and present my class. These are some principles and techniques which seem to work well.

MARKETING

Start with basic market research. Consider your intended audience - what are they likely to want from the workshop?

Write a carefully worded invitation to the course. Create a proper pitch - sell it well! Standard principles of marketing and copywriting apply: state why the reader should care (the benefits) before listing concrete curriculum and details (the "features").

Announce the workshop in a wide range of channels: face-to-face, email, social media... the more the better.

Make sure it's easy to sign up. Think of it like converting prospects to customers - make the "buy" threshold really low for potential pupils.

Once signed up, contact participants individually well before the workshop. Send reminders and practical info. Also, try to gauge their experience level and interest in the subject of the class. This lets you tailor your material to the audience beforehand.

PLANNING & STRUCTURE

Again, think about your target audience - after the steps above you should have a better idea who will show up. Generalize this into personae - which archetypes of people should you prepare for? Can you tweak the workshop to offer something to both Pro Programmer Penny and Middle Manager Mike, if both kinds of people have signed up?

Think through the overall structure and syllabus of the workshop thoroughly. Use flexible techniques like whiteboarding, sketching and mind maps to brainstorm scope and content. Like software development, missteps are much cheaper to fix in the initial planning stage.

How will you teach? A range of methods works best, if you have time for it. Some lecturing, some "show and tell", some "try yourself". Each individual attending has her own way of learning - try to present the material in several ways to cater to everyone. Don't worry if this duplicates a lot of material; repetition aids memory retention!

Present both core facts and related context. In other words, present both "what it is" and "why you should care". Micro and macro.

Your audience will have varying levels of expertise and aptitude in the material you are teaching. Try to cater to both the experienced student as well as the total novice, if both are likely to attend.

I like to start workshops with a lecture to lay some foundation, with plenty of live demos and moving examples along the way. Then I move on to practical exercises. In short: talk about it, show it, let people try it. Note: the rest of the article assumes this workshop format.

THE SLIDES

Start strong. Present a clear agenda - "what are we going to learn today?". Keep your personal introduction brief; people care about what you intend to teach them, not your credentials.

Avoid long rambling slides. Short slides are good, one-word slides better, a simple picture is best. Many succinct slides are better than few, text-heavy slides. Make. As. Short. Points. As. Possible. Each slide then serves as a very precise prompt for you, making you less likely to ramble and forget your next point.

Your slides don't need to be works of art, but do use some basic techniques of graphic design:

• Decide on overall style beforehand in order to make the slides as consistent as possible.
• Use large fonts with high contrast colors. How will your code, text and video look when projected on a canvas? In normal daylight? From thirty feet away?
• Use repetition. Content which repeats sticks in your mind after a while.
• Use contrast. Content which stands out is memorable.
• Employ evocative, high quality images. Avoid bland clip-art.
• Write short, to-the-point text with plenty of whitespace around it.
• Drop the standard company-branded powerpoint template. I'm sure your official company stationary is nice, but it simply adds clutter beyond the first slide. Limit your marketing and branding to the introduction and conclusion.

THE EXERCISES

Prepare to spend a lot of time creating good practical exercises! Some factors to consider:

• Assignments should start nice and easy to give a sense of accomplishment. Make the pupil feel awesome!
• Each exercise should be focused on teaching a single thing, and it should be obvious what the student is learning. "Why it this awesome?"
• Create a wide range of exercises, make them possible to solve in any order. A long chain of cumulative exercises is vulnerable to "blocking". Instead, make it possible to jump to something different if the pupil gets stuck.
• Provide for a wide range of expertise in audience. Cater to both the star pupils and the less experienced. One way of doing this is to add "extra credit" parts to every exercise.
• Demand little to no preparation from students before the workshop begins. Instead, make it really easy to get started during the actual session. Think user experience!
• Don't assume reliable internet or intranet access during the workshop. Instead, provide tools, documentation and cheat sheets in the exercise handout.
• Make sure it's easy to distribute the files and tools to the students. Buy a bunch of usb sticks, preload them with the handouts before the workshop begins.

ITERATE & PRACTICE

Once you have the basic structure and content in place, set aside plenty of time practice, tweak, practice, tweak. Iterate and internalize the material. Like any other writing process, your material improves as you return to it repeatedly with fresh eyes. Make sure to leave time for the material to "breathe a little" in your mind before the big day arrives.

D-DAY

Arrive early. Survey the room, set up your own laptop, make sure the light level is under control. You don't want to burn time hunting for light switches, cables and curtains once the workshop starts.

When people start arriving, greet as many as you can at the door. Get some smalltalk in before the actual workshop starts. You need to build rapport with the audience as quickly as possibly in order to engage them, so reach out to them at once! Don't like public speaking? You'll find it much easier if you already have some friendly faces in the audience before your presentation begins.

Now for the hard part (at least for me): the lecture. Strive for a relaxed and clear presentation. Control your body language. Keep a steady, calm pace. Like a singer or a martial artist, use your stomach: breathe and speak from your gut, don't squeak from your throat.

Engage your audience. Ask both retorical and actual questions to the room. Have people answer with a show of hands, individual answers or group discussion. Participation is good!

Take short questions as you go, refer longer discussions to a QA session at the end - or possibly one-on-one email correspondence after the workshop ends.

Structure your talk in short sessions with plenty of breaks, say 30-45 minutes with 5 minute breaks in between. Make the sessions even shorter if the venue is small and cramped - the crowd will quickly use up the fresh air.

Pay attention to your audience. If the seem bored, speed up. If they seem to "fall off", slow down.

Hand out slides and exercises after the lecture - not before. With a bunch of laptops and cellphones in the room, you're already fighting for the attention of your audience, so don't undercut yourself further by giving them something to read while you're talking. Control the message. You want their focus on you and the big screen.

During the practical exercises, actively circulate, talk to students, gauge their progress. Offer to help. It's easy to ask questions to an instructor who is present and attentive. A teacher sitting behind a desk fifteen feet away? Not so much.

Finally, solicit feedback from the audience at the end of the workshop. What worked well? Which parts of the workshop felt weak? Why?

Take their feedback to heart, and give an even more kickass workshop the next time!

REFERENCES

Presentation Zen (Amazon)

The Copywriter's Handbook (Amazon)

Creating Passionate Users

TedTalks

Tim Ferris on public speaking

Special thanks go out to Siv Fjellkårstad, Johannes Brodwall, and Markus Krüger for material and feedback for this article.

I've created a free, downloadable workshop for you. It introduces you to the skills, tools and techniques of modern JavaScript development.

The workshop takes roughly half a day (3-4 hrs) when presented properly, with equal parts presentation and practical exercises. You can use the slides and exercises as a personal study aid, or you can arrange a proper workshop for your own colleagues or clients. Alternatively, contact me. I'm able to hold the workshop on-site in and around Oslo.

DOWNLOAD HERE (slides, lecture notes, exercises, solutions, examples, tools)

A code kata is a short programming task. Its purpose is to let you practice tools and technique. You pick a relatively small problem and practice it repeatedly. Since the task is small, you free yourself to focus on technique and speed, tools and workflows, as opposed to active problem solving.

I was inspired by the "katacasts" of Uncle Bob as well as my friend Johannes, and decided to do one of my own. I chose a very simple task for this clip: the FizzBuzz interview question.

Print digits from 0 to 100. For every digit which divides with three, print "fizz" instead. For digits dividing with five, print "buzz". For digits which divide with both, print "fizzbuzz".

My solution, as shown in the video below, was meant to accomplish two things:

Demonstrate simple TDD workflow in JavaScript. Many software developers tend to treat JavaScript as the redheaded stepchild of programming languages. We unit test our "real" code (Java, C#, Ruby, whatever), but for some reason, that tends to go out the window when we switch to JavaScript. This is a shame; automated regression testing becomes extremely useful once your JavaScript code grows into hundreds or thousands LOC.

Improve my technique and speed in my editor of choice - TextMate. I'm trying to use the mouse as little as possible, can you tell? I still consider myself fairly slow in TextMate, but I improved while practicing for this screencast.

Note: I generate a tiny development environment in the beginning of the clip. This setup is something I've put together for a JavaScript course I'm holding internally at my workplace. The environment is meant to get you started quickly with good practices and useful tools (like YUI Test, jsLint, jQuery). I'll probably turn it into a tiny open source project once it's somewhat more stable. Feel free to tweet me if you want a look at it.

The clip was shot using SnapzProX on OS X 10.6.2. I edited the clip with Final Cut Express. No changes were made to the kata footage itself - I only added music and intro/outro screens.

For the past couple of months I've worked on a nontrivial project: build, launch and sell a commercial product on my own.

I set fairly strict constraints for the project:

• Use less than five months to release the first version.
• Work on it no more than fifteen hours a week (nights and weekends).
• Don't neglect my family, which I love.
• Keep my dayjob, which I really enjoy.

Well, I did it. The result is ThoughtMuse, an online mindmapping tool which runs in your browser. I released v.1.0 a week ago.

It's early days.  ThoughtMuse has some rough edges which I need to improve, and there's plenty of additional features I'd like to add to it.

So do I have any paying customers yet? Well, the magical first sale ticked in a few days after launch; the sweetest $35.40 I've ever earned. Building and selling something on your own is extremely rewarding. Making a profit? Sure, that would be nice as well.

You learn a lot by building a commercial product all on your own. I'm going to write more on this later on.

The magical first sale ticked in a few days after launch. The sweetest $ 35.40 I've ever earned, and one of the most rewarding moments I've had as a software developer. Building and selling something all on your own is extremely rewarding in itself. Making a profit? Yes, that would be nice as well.

Three months ago I stumbled across a time management system called 'The Pomodoro Technique'. I really liked it due to the immediate productivity gains it gave me. I thought I'd follow that blog post up with my current impression of the technique, now that I've used it for a while. Todays blog entry will make more sense if you read my the original post first.

Recap

The idea of the Pomodoro Technique is that you work in timeboxed intervals of 25 minutes. Each interval is called a "Pomodoro" (tomato). Once you've completed a pomodoro you make a note of it, and take a five minute break. After four pomodoros you take a longer break.

The Good

I'm ultra focused when I work on tasks using this system. I initially found the ticking egg timer somewhat distracting and stressful, but that passed after a week or two. Once I start the clock I'm usually able to enter a state of flow really quickly.

I've repeatedly seen clear benefits from the self-enforced breaks; they sometimes make me step back, rethink and adjust what I'm working on. This has prevented me from going too far down some potentially time-consuming dead ends.

Recording completed pomodoros forces me to document and take stock of how much time I spend on different tasks. This provides historical data which really helps when I estimate similar future tasks.

"I'm going to complete a few eggs, dear" has become a catchphrase at home (eggs = egg timers / pomodoros). It's a clear way of communicating to my fiancè that I'm setting aside a concrete amount of time for work. This lets her know exactly when I'll emerge from my cave again.

The Bad

It's hard to stop working once the egg timer rings. This is especially noticeable if I'm almost done with a task; it's very tempting to put a few more minutes in before I take that break. Of course, those "few minutes" sometimes end up taking an hour or two...

The technique forces me into a certain mindset. I become really focused and efficient, which is great for concrete, well planned tasks. It's not always suitable for more reflective and explorative work, though. I find I do better at things like research, brainstorming, design and general planning when I'm not under the gun of my egg timer.

I have not used the technique seriously at my dayjob yet. I'm not using a mechanical timer there, since a ringing egg timer would be quite distracting for my coworkers (several of us share an office). One solution: use headphones combined with a software-based timer instead. Unfortunately, I find tools like mytomatoes.com much less effective than a mechanical clock; the "break" audio signal is far less noticable, and it's often lost on me because I take off my headphones or listen to music while working.

Conclusion

The Pomodoro technique has boosted my productivity, and I highly encourage more software developers to try it out. I will keep using it for my side projects. It has been less useful at my dayjob, but I'm going to try to adapt it to work well there as well.