Code Softly

Yes! A Python manifesto to add to my informal collection. It’s nice to have such passion around a language.

Here’s a funny part:

Choose to finish early and laugh at your colleagues as they waste their miserable lives bowing down in subservience to that sadistic little C++ compiler.

Busting on C++ never seems to go out of style.

Near as I can tell, this comes from Alan Issac, associate professor at American University. If you know better, please holler at me.

Chose Python (pdf)

via “Choose Python” [For Some Value of “Magic”]

Ever wonder what’s going on inside your architect-friends’ heads? My brother the architect (I KNOW, Mom, but computers are the future! Stop judging me!), sent me this video. I’m pretty sure it’s an accurate depiction of what’s looping through most architect-y peoples brain at any given moment.

Keep in mind that this thing is completely computer generated. That’s right, textures have moved on to some seriously next-level stuff. Also remember to full-screen the video for maximum awesomeness.

Watching Holmes On Homes is a great way to get your head right for programming.

I’m not even really talking about the software craftsmanship angle, though it is related. I’m talking about the attitude that Mike Holmes brings to his contracting projects. It can be summed up as:

• Do it right
• Doing it right isn’t that much harder than doing it wrong
• Doing it wrong is evil

Watch an episode or two. You’ll see what I mean. Whenver I feel myself start to whine “Ugh…I really should refactor this, but it’s a freaking BEAST”, I imagine Mike coming by later and talking shit about what crappy code I wrote.

I was poking through my reading list, and found this gem. It’s Ted Dziuba’s description of Twisted, and I almost wet myself when I read it.

However, Twisted is probably the douchiest programming library out there. Every time I open up that code, I feel like I’ve wandered into a late-night bar on the Jersey Shore where everybody’s drinking Jager-bombs, and nobody is wearing a shirt. Twisted is a cool network library, but not cool enough to be named “Twisted”. It’s the Python programmer’s version of Ed Hardy clothing and a baseball cap with the tag still hanging off the side. When I’m digging around in this code and my co-workers ask me what’s up, the only appropriate response is “NOT NOW CHIEF. I’M STARTIN’ THE FUCKIN’ REACTOR.”

You can read his whole post on Twisted and Tornado to get a bit more context, but that part cracked me up.

I've written before about the awesomeness of Balsamiq Mockups. I just learned of Mockups To Go, a site where people are sharing their own Balsamiq components like a 960 grid, pagination controls, star rating modules, and lots more.

I’ve got a hankering to try my hand at GUI application development with Python. What’s a good framework to use? Which ones stink on ice?

My highest priorities are:

1. Good on Windows.
2. Ultra-easy for people to install the finished application.
3. Won’t piss me off.

Any suggestions?

As you can tell from the elaborate imagery on Code Softly, I’m kind of a fan of minimal site designs. Design Shack posted 35 great ones.

My favorites are Subtraction (pictured above), Cynosura, and Tobias Bjerrome Ahlin.

I’d like to think someday I could whip up a cool and clean layout for Code Softly that impresses people with my restraint and eye for clean lines. In the meantime, we’re all stuck with the design mess you see before you.

If your project has more “idea people” than builders, you’re likely having a rough time of things.

Think about it. A good idea almost certainly takes less time that its implementaton. If your project has more people thinking up features than implementing them, the implementors will never catch up.

Frustration prevails. The stage is set for disappointment. You’re always behind.

So what’s a good ratio of “doers” to “thinkers”? I submit it’s ten to one. It sounds drastic, but building software is complex stuff. If you pick one really good person to design feautres, and have ten working to implement them, you have a good chance at success.

The ten to one ratio also sounds horribly inefficient, but what’s the success rate of new ideas when you’re spouting out all kinds of new features? Does more than one in ten of your features really ever pan(pay) out?

Construction projects are a nice example. The ratio of builders to architects on a typical high rise is like 50 to 1.

We wouldn’t dream of having 50 or 75 architects for a building, so why are we ok with the same percentage for software?

[photo courtesy of joherob - some rights reserved]

To the mantra of Commit Early. Commit Often, I humbly submit Commit EVERYTHING.

When I was a wee young programmer and had my first experience with cvs, I was scared. Optimistic locking was mysterious. I only wanted to check in one teeny change at a time.

Eventually, I got comfortable and realized that committing my ENTIRE working copy is the only way to be sure I haven’t broken things.

Sins against this range from

“Shoot, I forgot to svn add that file before committing, sorry guys; One sec..”

to

“Well, I was keeping my own version for the last few weeks until I felt like it was really done.”

In the end, not committing your entire copy keeps you out of touch with the codebase and threatens stability. You leave yourself wide open to “Well, it works for ME”, when really you just have local changes you haven’t committed yet.

There’s a few ways to have your cake and still eat it. If you feel the urge to not commit everything, you might want to:

1. Make your own experimental branch and work from that for a while (remember to merge in changes from trunk occasionally/)
2. Commit more often, and in smaller chunks.
3. Write enough tests so you can verify the integrity of the entire working copy before committing.

Too much pain and time is wasted when you need to decide which files are safe to check in, and which ones aren’t quite done yet.

Does the expected value of a unit test assertion go on the right or the left side?

Option 1: Expected Value on Left

    assert "Aaron Oliver" == user.fullname()

Option 2: Expected Value on Right

    assert user.fullname() == "Aaron Oliver"

Yes, it’s a bikeshed issue, but I think it’s worth discussing. Mixing conventions is confusing.

I think option 2 is closer to how we speak and think about test assertions:

Verify the result is what was expected

However, I’ve been doing option 1 since my Java days, I think because that’s how JUnit wants it.

What’s the best way?