Adam Keys is Thinking

Did you see Garrett Dimon’s slides from WebJam Session ‘07? You should!

What impresses me is what Garrett’s accomplished in designing his issue tracker without much use of intense graphics. He’s got a few icons here and there, but most of his design is based on color and typography. As someone who is horrible at drawing, it gives me hope that I could some day build cool UIs.

On a whim, I took a shallow dive into the world of C this weekend. Its been a long time since I delved into C. I ended up spending nearly as much time tweaking a build script with the ever-amusing Rake as I did remembering my C skillz[1]. In the end, my goal was to write a simple program that just reads a file and writes it back out. Nothing cat couldn’t handle, sure, but you gotta start somewhere.

Of course, the first thing you’ll notice when you go from Ruby on Friday to C on Saturday is that OMG I have to write fourteen-billion lines of code just to open a file? Well, yeah, you do. But the language isn’t that awful. Munging file pointers, getting buffer sizes by stating a filename and all that, it’s kinda fun.

What’s not fun? Managing memory. It’d be fun if it wasn’t just an express ticket on the memory leak train. So lots of people have tried to tackle this. I was playing with the Apache Portable Runtime or APR, in concert with all this C and they take an interesting tack in dealing with memory.

Jumping in the memory pool

In the APR world, your application creates one or more pools that you then allocate memory from. You create a “root” memory pool to start off with, but you can create as many further pools as you like.

The idea is that as you transition from one area of functionality to another, you create a new pool. Once you’re done with that function, you destroy the pool and all the memory allocated to it goes away. Including the stuff you forgot about. Which is kinda rad, it being the case that memory leaks are leaks of (human) memory.

This made me think of generational garbage collection. Java’s garbage collector does this clever trick where objects are initially created in a “nursery” with all the other recently created objects. Since it’s typical that objects are created and then quickly discarded, the nursery is basically the low-hanging fruit for the garbage collector to find memory when it needs to.

Bring that funk back over here

Seems to me you could do the same thing with the APR’s pools. Create a new memory pool for every request, for example. Then when you’re done with the request, just delete the pool and don’t worry. The APR folks list examples of assigning pools to starting your application, parsing the configuration and then doing your actual processing. That sounds reasonable to me too.

This is probably not rocket science. In fact, the developers of the APR readily acknowledge that tuning your app to work with this approach to memory management is the trickiest and most contentious[2] facet of developing with the APR. In the next release, they’re working on an alternative, just in case pools aren’t your thing.

Nonetheless, I find it pleasing that the world of C seems to have, perhaps, moved on from “man up and manage your own memory, we are C programmers!” to “hey man, everyone has trouble with this stuff, give this approach a try!” At some point, with some problems, C becomes a necessity. Anything that helps that out is moving the bar higher for the practice of programming.

[1] Indeed, my build yaks are beautifully shorn

[2] Perhaps you could say, opinionated

Best obituary ever:

A shame, then, that he is now, in the words of Monty Python, an ex-parrot.

Alex The Parrot was adopted by a scientist who wasn’t, at the time, involved in linguistics. But, in teaching Alex to speak, she ended up teaching him things like counting and basic recognition of objects. Over the years, this evolved into all manners of experiments on what kind of cognition Alex was capable of.

By the end, said Dr Pepperberg, Alex had the intelligence of a five-year-old child and had not reached his full potential. He had a vocabulary of 150 words. He knew the names of 50 objects and could, in addition, describe their colours, shapes and the materials they were made from. He could answer questions about objects' properties, even when he had not seen that particular combination of properties before. He could ask for things - and would reject a proffered item and ask again if it was not what he wanted. He understood, and could discuss, the concepts of “bigger”, “smaller”, “same” and “different”. And he could count up to six, including the number zero (and was grappling with the concept of “seven” when he died). He even knew when and how to apologise if he annoyed Dr Pepperberg or her collaborators.

Animals are just amazing.

Newton’s Third Law of Physics: All forces occur in pairs, and these two forces are equal in magnitude and opposite in direction.

Newton’s Third Law, applied to software: To make something generic is to make the simple things complex.

Particle Tree has an excellent article on Fitts' Law. That’s the one tells designers to put the Dock and Start Menu on the edges of the screen. You definitely want to check it out, if only for the terrific images used as demonstration.

Of course, if you’re more about the math (bad news, UI design is a lot of math) you could read up on Fitts' Law on Wikipedia.

Paul Graham’s latest essay returns to ideas for which I first noticed him. Holding a Program in One’s Head asks what kind of intellectual exercise software development is (spoiler: one that requires focused and uninterrupted thinking) and then suggests guidelines for effective programmer working spaces (small teams, distraction-free workspaces). See also: Test #8 on the 12 Steps to Better Code.