Thursday, August 25, 2011

Continuous integration and dependency management

Unless you're using Maven or Ivy to manage dependencies on external jars, you're not doing continuous integration.

You have to keep up with new releases of external tools or you will lose support (blog and forum posts are more likely to address issues with recent releases). But worse, you will end up boxed in if you need some additional component that only works with a newer release. And there will always be newer releases, so while you could argue that there might be a component that requires and older release, the likelihood of something cool, modern and worthwhile being tied to an old release of a shared lib is pretty remote.

Big Bang integration is a pain. So do continuous integration and manage your deps.

Wednesday, August 10, 2011

Knowing is not acting

I know, I know. Doesn't mean I do the right thing.

Many times I have felt puzzled and even miffed when someone smart invents something that I think is obvious. "I coulda done that!"

But the fact is, I didn't.

Knowing is not doing.

Tuesday, May 03, 2011

Programming while stupid

A significant benefit of test-driven development (TDD) is that you don't need to work very hard. Now turn that idea around: when you cannot work at your full capacity, you can still be productive and produce well designed, working code.

TDD reduces cognitive load by encouraging small steps and by capturing the precise requirements for a piece of code in the test's assertions. Typically, that allows us to devote more of our energy to other important matters like clear design, intention-revealing code and delivering value to the customer.

But what if you're tired? What if you're just not at your best? It happens; we're human! Sleep deprivation makes us stupid. So does stress.

How are we supposed to program while stupid?

Maybe you have a teething baby. Maybe you got into an accident on the way to work. Maybe the office is absolute Bedlam today. Maybe you're hung over. (Note: I have never experienced this latter phenomenon, though I believe I may have read about it in books.)

The rhythm and structure of TDD provide enough support that you can still be productive. Granted, those "extra cycles" will not be available to perform the higher level functions we mentioned, such as keeping an eye on the broader design of the code. But at least you'll be able to function. You will be able to program - without embarrassing yourself.

Contrast this with situations in which intense focus and concentration are an absolute requirement for producing any code at all.

Before I learned to TDD, I would keep large chunks of infrastructure in my head. Needless to say, such a volatile storage mechanism had to be treated with great care. An overheard conversation or a phone call could cause enough of a distraction that I would lose track of what I was trying so desperately to keep aloft. I'd get frustrated and angry. Back in my wilder youth, I'd often call out loudly for peace and QUIET!!

And what about the morning after a colicky baby all-nighter? You've made it in to work. You want to sling some code. You have a moral and ethical obligation to do something useful to earn your pay. But keep a complex design, a lofty edifice, a convoluted algorithm in what remains of your battered brain? Not gonna happen.

So don't even try. Take baby steps, write the asserts first, be modest and methodical and your work-ethic conscience is assuaged.

I still don't enjoy distractions, and having learned a lot more about neuropsychology over the decades, I decry the misplaced affinity for multitasking that some people seem to think is a necessary part of modern life. But I can happily walk away from a red test, knowing that I can pick up at any time and, by continuing to take baby steps, finish what I was doing.

Interruptions are more tolerable with TDD. A trance-like focus is no longer a basic prerequisite for programming.

And TDD cures hangovers.

Sunday, April 10, 2011

How to Integrate Jenkins monitoring into Eclipse

Install the Hudson/Jenkins Mylyn integrator to see build status in Eclipse.
  1. Add this update site to your Eclipse: http://download.eclipse.org/mylyn/releases/latest/ It's still in "incubation" so it seems it's not available in the regular download site yet.
  2. Under Mylyn Integrations, select and install "Mylyn Builds Connector: Hudson/Jenkins (Incubation)"
  3. Once it's finished installing, use Window > Show View > Other... to select the Mylyn Build window
  4. Select the blue cylinder representing "Add new build server" from the task bar.
  5. Enter the info for the Hudson/Jenkins server and voila!
It's pretty nifty, too. Not only do you see build results, but you can view test results in the regular Eclipse JUnit view, examine the build's console output, view the changes for that build – in short, see pretty much all you see in the regular Jenkins web UI, but laid out in better (?!) and integrated nicely with Eclipse. Recommended.

For more info, see the Mylyn site.

Friday, April 08, 2011

Bookmarklets break MobileMe sync

Bookmarks weren't syncing between my iOS devices and my desktop machines, but I managed to find a solid description of the bug and a good workaround. In short, do not add bookmarklets on your devices. Instead, add them on the Mac and let them sync across. The message I was getting on the Mac side was "You need to replace your Bookmark Information on MobileMe" with two buttons: Fix Later and Replace.

The problem ostensibly lies with improper URL encoding of bookmarklets on the iOS side, which results in "corrupt" data in the cloud. The devices don't know or complain about this, but Mac OS does.

What I did was to delete all but my most useful bookmarklets on my Mac, then sync just the bookmarks. Everything works again!

Thanks to this discussion, the fix was pretty simple.

Note the dates on those postings. Sigh. I am so sick of MobileMe sync bugs!

Tuesday, March 29, 2011

Software informs theatre

Brenda Laurel's Computers as Theatre is about the influence on UX of theatrical elements of structure and context. It's all about UI and so on, and it was a seminal book at the time.

While Laurel wrote about computers as theatre, I posit theatre as a software project.

And that reminds me of a story.

I spent over a year preparing for my debut as a director. The show was Brian Friel's Molly Sweeney. In addition to all the background reading I did on the subject matter, (a lot of philosophy), visits with dialect experts and a blind consultant, I also did some reading on directing. The book I liked most was a short one, the late William Ball's A Sense of Direction.

Big Bang Integration

Let me explain a bit about the usual process in theatre. The final week before opening is known as Hell Week. It starts with a Tech Rehearsal, usually on the Sunday before opening. Two full dress rehearsals are scheduled for Tech Sunday, with a dinner break between. The first one starts mid-morning or lunch time, and drags on until dinner time. A two hour show is stretched out to breaking point — oh, wait. That's the nerves I was talking about.

During that first run-through, the lighting designer is making final instrument adjustments. Lighting cues are programmed into the board, which means that every few lines, the run-through stops while the lighting designer goes tappity-tap on the lighting computer keyboard.

The sound designer is adjusting levels and getting cues straight. Because nobody beyond the sound designer actually knows anything about sound design and yet everyone thinks they do, everyone basically ignores the sound designer until a cue obliterates a crucial piece of dialog, or feedback cause the ingénue's ears to bleed.

The costume designer fritters and frets, chasing people with pins and making last-minute adjustments and bawdy actors wait in hopeful anticipation for a wardrobe malfunction of one sort or another. Everything stops while the costume designer and director debate in great depth the relative merits of yer press-stud vs. yer hook-and-eye.

The scenic designer, prevented from making any concrete contributions while the stage is occupied, admonishes the actors to avoid the patches of wet paint and taunts them by drawing chalk lines for them to trip over.

The stage manager, long ago having given up communicating with the lighting booth, the sound booth, or the props master, is breaking up a green room turf war between rival gangs of actors. In reality, they really need have no concern about him seeing her naked: He's gay, and honestly, there's really nothing worth seeing.

We have a saying. If the Tech goes well, opening night will be a flop. And vice versa.

So, XPers, what do we call this kind of pulling together all the components at the last minute? That's right, it's Big Bang Integration.

Continuous Integration

And what does Ball have to say about this? He says that's all wrong. He says you, the director, need to have your designers and techs involved from the very first rehearsal. They contribute to the show as a whole, proving their input from their experience. They internalize the other designers and from the director, and they gain a deeper understanding of the characters as they are brought to life by the actors.

What do we call that? Continuous Integration.

My exposure to Extreme Programming has given me the opportunity to learn that principles and techniques applied in the micro can often be extended to the macro too. When we pair up on a piece of code as a matter of course, we discover that pairing is a damned fine technique for all kinds of hard problems. When we test-drive our code, we discover that perhaps test-driving our managerial decisions can help us fail fast and derive huge benefit.

But Apart From That, Mrs. Lincoln...?

And when we use Continuous Integration in our rehearsals, the show's a success! Under my direction, our Tech Rehearsal was smooth and effortless.

Molly Sweeney rocked! For years afterwards, people said that it was the best show The Masquers had ever done.

Saturday, February 26, 2011

It's my turn to blog about ringtones on an iPhone

This has been done to death, but so much info is out of date, so I am writing it all down here in one spot.

I had some old MIDI files that I had created using TuneToys that I had used on my old LG VX4400 phone (the one that embarrassed my daughter, it was so old) and I wanted to continue using them on my shiny new iPhone. These are the steps I followed.

  1. Drop the MIDI file on iTunes. It will get imported.
  2. Select it, right-click and select "Create Apple Lossless Version". This makes a .m4a version in your library.
  3. Drag the new .m4a version onto your Desktop (or somewhere)
  4. Change its extension to .m4r
  5. Delete the .m4a version from iTunes. While you're at it, delete the MIDI version too.
  6. Drag the .m4r version into iTunes. It will show up under Ringtones.
  7. Sync.

iTunes will kvetch if the sample is more than 30s long (which is prolly some legal thing – now I have to limit my own use of my own composition because of some RIAA lawyers?) so trim it.