February 2010 Archives

Every now and then I find myself writing HTML by hand. Sometimes the tags have lots of attributes, or they have long values. This makes them way longer than the aesthetic 80-ish character max. What’s the best way to wrap them?

If I start with:

<a href="http://codesoftly.com" id="awesome-link-one" class="link main" rel="bookmark">mylink</a>

What’s the best way to wrap it?

Stacked: Everything on Its Own Line?

<a href="http://codesoftly.com" 
     id="awesome-link-one" 
     class="link main" 
     rel="bookmark">mylink</a>

I like this because it’s clear what all the attributes are. There’s little chance of missing one because it’s way off the right of the screen.

I don’t like that it hides what the link text is.

One Long Opening Tag With Linked Text Indented?

<a href="http://codesoftly.com" id="awesome-link-one" class="link main" rel="bookmark">
    mylink
</a>

I like this because it leaves the link text clear and on a line by itself. It’s crummy because that first line can get really long.

Something In Between?

<a href="http://codesoftly.com" id="awesome-link-one" 
     class="link main" rel="bookmark">mylink</a>

I’m not sure this is any better. It feels like the worst of both worlds.

Oh, and “How Dreamweaver does it” isn’t a legitimate answer.

I’ve been a proponent of Movable Type as a publishing platform for a while now. I stick with it for one big reason: it is absolutely great at static publishing.

I realize that Wordpress and the gang have all kinds of neato features, fancy themes, and powerful plugins. Despite all that, I find the reliability of good old-fashioned HTML pages comforting. Even commodity hosting plans have that part figured out.

Not needing a database connection means that if the host’s database dies, my site is fine. It means that if for some unfathomable reason Code Softly gets Digg-bombed I don’t need to worry about blowing away connection pools or overwhelming my page logic.

The fact is that most sites, especially blogs, have no business being written with dynamic pages in PHP or .NET or Perl, and they certainly don’t need a connected realtime database.

Not sure if you can benefit from static publishing? Take this short survey:

1. Does your site change depending on which user views it?
2. Are you sure about that?

Bottom line, most fancy stuff is unnecessary or can be accomplished with javascript.

Think about it, what’s the most fragile piece of your website, the part that breaks the most often? (hint: it’s probably the database) The database can be mis-configured, run out of juice, or just fail to start. Tell me you’ve never had a host accidentally have a DB outage.

What’s the part of your infrastructure that’s the last thing to fail? (hint: it’s the http server, aka Apache) Why tie the fate of your site to the most fragile part of your stack, especially when you don’t really need it?

Take a look at your site. I’ll bet you can get by with a bunch of static pages.

I’ve just had my first experience manning a booth at a career fair. Now that I have gained only passing wisdom around this event, I choose to dispense concrete tips with guaranteed results:

You Don’t Have to Dress Up, Just Don’t Dress Down

The suit and tie looks sharp, but isn’t really necessary. A job fair is busy, kind of loud, and full of people. Most important is that you look (and smell) clean. You’re not going to win any beauty contest, but you don’t want employers to think you’re a slob.

Your Department’s Home Page Doesn’t Really Count

I usually ask prospectives “What experience have you had working with websites?” The answer an alarmingly high number of times is “I help maintain my department’s home page”.

I realize that not everyone has the opportunity to work at Amazon or CNN.com, but at least come back with something. Even running a personal blog involves at least a few principles of sound web programming.

Be Specific About What You Know

Don’t walk up and say “sooooo…what have you got?”. This is a dumb question, In this economy, you already know the answer is “not much”. Introduce yourself with “Hello, I’m Flavio. I’m studying linear algebra and am interested in a full-time programming job.” This helps the person zero in on how good a fit you might be. The people at the booth might be looking for linear algebra specialists, but when you only give them a general inquiry, they have little chance of learning that you’re a perfect match.

You Need Them More Than They Need You

If you’re participating in this cattle-call, chances are you’re not sweet enough to have attitude. Remember the part about there not being enough jobs to go around? You don’t need to approach on your knees, but don’t act offended if there isn’t anything for you. Just keep moving.

Have a Conversation

The point of the Job fair is human interaction. You could learn everything about an employer and position online and submit your resume there. You’re at the fair to stand out and maybe get an interview or job on the spot, thereby beating out all the digital posers. To do that you need to make your interaction unique but not flashy. Just having a detailed conversation will do that.

A quick fly-by to drop off your resume then pick up pamphlets and swag doesn’t do the trick. Do that and prepare to become a part of The PIle. Seize the opportunity to meet people face to face. Otherwise just apply online and save everyone the trouble.

I’m always trying to impress upon people that more than anything else, their sites need content. It’s fun and sexy to harp on visual and design things, but at the end of the day, people won’t use your pages because they look nice. They use them because they contain some information the reader wants, be it text, images, or a neato flash game (my best distance is 321,492 feet. Deal with it).

Boagworld has a post that reinforces this nicely, putting emphasis on having a good copywriter:

Copywriters also tend to know how to spell and, vitally, how to use grammar properly. If you’re a designer and you doodled through English lessons at school, you should do all you can to catch up on your grammar and spelling. A miss-placed apostrophe or hyphen could change the entire meaning of your piece. At which point you’ve failed as a designer.

Content Is King [Boagworld]

I recently started keeping a small notebook (graph-paper) to the left of my keyboard when I write code. It’s a short list of what I want to accomplish during a session, maybe for the next half-hour or pomadoro or whatever. I lovingly call it my analog burn-down chart.

It works great. I use it to:

1. Record sins I commit in the name of un-breaking tests
2. Jot down micro-goals; things I want to accomplish before I step away from the computer. This really helps focus me. It’s especially handy for tasks I don’t like doing or that I suck at. Javascript fits both criteria nicely.
3. Force myself to do things I find distasteful, like verifying javascript in IE 6.

Here’s what I had down on a recent page:

But That’s Just a To-Do List!

Yes. My analog burndown could be called a to-do list, but for me it’s a “to do right NOW” list. It keeps me focused on the task, and I know when I’m done because the list is all crossed off. I rarely go back and look at previous pages. They’re either cleared entirely, or repeated on the next list. Sort of a mini backlog for my brain.

While you may not experience all this in your code reviews, I’ll bet you’ve felt some of this pain. Code review meetings are the worst. They eat time, are poorly attended, and people are bad at preparing for them. Further, there’s generally no good pattern in place for actually implementing the outputs of the meeting.

Review Board is an awesome web-based tool that helps solve a lot of those shortcomings. It turns the review from a monolithic death march to a conversation among programmers. There’s very little pressure. You request peoples’ eyeballs, they weigh in, you update, rinse, and repeat.

Review Board will not blow your process to hell. It’s a very generic tool. If you have more than one person writing code, Review Board will be useful.

Think of it like a message board centered around a code diff. One person posts a diff, the “subject” of the thread, emails go out to other programmers who can look at the diff and have threaded conversations around it.

To learn more about Review Board, visit their homepage and get started. For the visually inclined, check out their screenshots of the app in action.

Stumbled across this open letter to Python, written by Luke Magill. In it he goes through some of the ways Python has let him down, including

• No Encapsulation
• Static Libraries
• Lack of an implied “this”
• No explicit support for member definition
• On-lined Lambdas

A few parts resonated with me, especially the when he talks about how Python does objects.

But you weren’t ecstatic about objects. You didn’t really like them and you didn’t trust them. So you decided to only give them a little. You cut corners. You made objects but you made them hard to use. That was a mistake.

As a former Java programmer myself, I’ll admit I’ve felt some of this pain. Not enough that it stops me from getting things done, but there have been times I’ve scratched my head over how different Pyhton objects really are from their counterparts in other languages.

Anyway, the comments make for good reading, rife with handy links. If nothing else the whole thing is a good thought-exercise.

I’m a huge fan of always seasoning iterations with a couple of technical stories. It’s great for closing the feedback loop and empowers developers to improve the way they deliver products.

Jack Milunsky discusses the pro’s and cons of putting technical stories in the product backlog.

But what about the type of story asked by one of the members “As a development team member, I want the existing unit tests to run under CruiseControl, so that I know if anything breaks”. Where does this belong? Well this is a perfectly written story but the story really has no ultimate value for the end user at least not directly.

I personally feel that if you don’t have some official place to put these kinds of improvements, they will always get shoved aside in the name of “real features”. Maybe adding them to the official backlog sows confusion and strife, but trying to sneak them into task estimates or something seems just as dangerous, because they’re effectively invisible and untracked.

via Technical stories - are they included on the backlog? [AgileSoftwareDevelopment.com]

Our job as web developers is to build defect-free sites. That job is getting harder. As sites become bloated more feature-rich, verifying everything in multiple browsers before it goes to QA becomes impossible. The only way to keep afloat is to allow automated web testing frameworks shoulder the burden.

Test EVERY Browser Your Site Supports

Yes, the line between tester and developer is blurring. The fact is that you really can’t call something “done” if you haven’t verified it yourself first. That means checking all the browsers your site claims to support, even the dinky ones.

“But my job is to build, not test!”, shouts the programmer. “My job is to verify, not to sniff out all browser compatibility issues you were too lazy to handle”, replies the tester.

It’s a balancing act, and as professionals we need to commit to delivering verified code. In the end, there are more feature and browser combinations than any developer could possibly check in a reasonable amount of time.

Uncle Bob posted a message in which he points out some of Scrum’s shortcomings. It’s a well-put and thoughtful critique of the places where Scrum falls down or is silent.

Scrum carries an anti-management undercurrent that is counter-productive. Scrum over-emphasizes the role of the team as self-managing. Self-organizing and self-managing teams are a good thing. But there is a limit to how much a team can self-X. Teams still need to be managed by someone who is responsible to the business. Scrum does not describe this with enough balance.

Reading this list, you’ll probably realize two things.

1. Your team isn’t really doing Scrum
2. Your team has figured out practical ways to work around these shortcomings or skip them entirely.

In the end, this is a critique of strict Scrum, and really not of Agile itself. It kind of reinforces how nebulous the space still is.

Scrum / Agile’s inherit shortcomings? Uncle Bob Martin’s 7 theses via @markneedham

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.

Update: This was the work of Tim Lesher. Thanks Tim!

Chose Python [Aftermarket Pipes]

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