Adam Keys is Thinking

You’re here! That means I’ve managed to convert my site (back) over to WordPress. In the interest of making progress, I had to cut some corners. Currently, that manifests itself as taking my old weblogs Man vs. Machine and Punchline Labs offline while I figure out how to rejigger the content into WordPress.

Don’t stop reading! This isn’t “Yet Another Boy-Have-I-Been-Busy But Now I Promise To Post More” post!

The decision to switch (back) to WordPress is bittersweet. I’d originally switched away to Typo, but that didn’t work out well. On the one hand, Typo went a little sideways, requiring me to poke the database a little before I could post. On the other hand, running a big Rails app like Typo on shared hosting like TextDrive isn’t a recipe for reliability. So a change was necessary.

Point: you’re cooler if you write your own weblog software. Its been pointed out that Jedi build their own lightsabers and thus, so should programmers. I think it’s a wonderful idea and I subscribe to it where I can. However, it’s an idea at one end of a spectrum of pragmatism and I need to live at the other end.

• On one end, you've got building your own software, all the time, because you're that cool or because you've got an insanely weird domain. So you build your own software. See also, Not Invented Here. Usually, this is the wrong choice.
• Then you've got building your own lightsaber. You do this because learning is more important than implementing something quickly. This is usually the wrong choice for "production" code.
• If you need to go quickly but still need to get involved in the domain you're working on, hacking something is a great choice. You don't have to start from scratch and you don't have to learn everything by making mistakes.
• Finally, you could just buy or download something and tweak it in the ways the creator predicted you would. Adopting hosted web apps is one in the same. This is ideal for times when you just don't care about the domain the app caters to. Bug trackers and mail clients fall into this category for most people.

Counter-point: the writing is more important than the gizmos. To a point, writing my own weblog software is yak shaving. In fact, I’ve contemplated switching weblogs, hosts and a myriad of other choices for month. Thus, with a cleanly shorn yak and nothing to show for it, I finally jumped in the pool and switched. And now, I can write. Awesome!

The writing here is the most important thing. Not so much whether I’ve got Ruby cred because I run a Ruby-powered weblog, web cred because I skipped using widgets to pull in some content rather than hacking it in (I went with widgets) or design cred because I built my own theme. Very few people will come back on those strengths alone. Its the writing stupid! Thus, I’m re-aligning development choices based on removing friction from writing.

I think I made a reasonable choice going with WordPress and hacking DePo Clean. In the end, I just want something that lets me write whatever and whenever I want with as little friction as possible. WordPress fits that maxim. Plus I think Matt Mullenweg and the rest of the Automattic team have pretty good taste, and I can get behind that.

So, what have we learned?

• Adam is using this post to justify his decisions to himself.
• Adam changed some software around and hopes you like it.
• Don't spend too much time waffling on software choices. Just take a shot in the middle.
• Making an educated choice somewhere in the middle of build vs. buy is important

See, I told you this wasn’t one of those posts where I apologize for not posting for many months and then promise to post more frequently. Though with my luck, I won’t post again for three weeks ;)

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.