Thursday, September 18, 2008

Pretty Sourdough

I am totally jealous that John got brotforms, but you can make pretty loaves freehand too. :-P

My standard white sourdough.


Saturday, September 13, 2008

Thoughts on Genius

I just installed iTunes 8 with the new Genius music recommendation/playlist feature. I have played around with similar functionality for years in the form of Pandora and MusicBrainz. These tools are how I find new music anymore (combined with iTunes own recommendation system and Amazon's recommendations). I have not listened to the radio in a few years at least.

Genius is pretty cool when it works. It instantly generates a very mood appropriate playlist from a selected song, which is nice. The Genius side bar shows a whole bunch of recommendations too - this function blows away the old school iTunes recommendation system since it allows you to look for specific kinds of music.

But it completely fails on obscure tracks and obscure genres. Even on obscure tracks and genres purchased from the iTunes store. It is useless for classical music, usless for traditional irish music, usless for some classically influenced electronica (where useless is defined as not recognizing a large enough fraction of similar songs to build interesting playlists, not as the complete inability to recognize anything at all). It doesn't work for music videos at all, unfortunately, either (come on Apple - that should be easy to solve for videos purchased in the iTunes store).

Still it works for some surprisingly obscure stuff and it is wicked fast. I'll definitely be using it.

But if you find yourself getting the message, "Genius is unavailable for the song..." frequently, do yourself a favor and install MusicBrainz.


P.S. I have also discovered that it works differently for music purchased from iTunes vs. other music. Even if the tracks are identical otherwise (different formats, but the same sound signature).

Thursday, September 11, 2008

Programming's Dirtiest Secret

Stevey has up a brilliant rant about developers and touch typing. But touch typing ability (or lack thereof) isn't really the dirtiest secret about programming. Even though I can touch type, I am going to use a lot fewer words than Stevey did. Ready?

People are, on average, pretty darn average. Developers are no exception.

In most endeavors average is pretty bad. Software development is no exception.

Telling the difference between an average developer and a great one in an interview is really hard.


Developer Best Practices

I have been thinking about best practices at work and I am going to throw some ideas out here to help me think them through and to get feedback if any of you have opinions. This isn't complete or well organized - I am just trying to get the juices flowing.

  • Do not rely on this or any other document to provide a complete list of best practices. There are too many and some seem too obvious to talk about. You are a professional software developer - learn the craft. Don't stop learning. Aim for 10X.
  • There is no absolute "best" way to do anything. Think about what you are trying to accomplish. Be pragmatic.
  • Design applications in layers. Create distinct modules or blocks of function. Design the module interfaces first. Design by contract.
  • Write unit tests.
  • At a minimum write unit tests of the module interfaces.
  • Ideally write the tests before the code.
  • If you are about to debug something, stop and write a unit test for it first.
  • Don't create mindless unit tests. The auto-generated ones your IDE makes for you are only stubs - don't rely on them for coverage.
  • Inject your dependencies as a matter of course. This will greatly simplify unit testing. You don't actually need a framework for this - understand the underlying principle instead.
  • Keep stuff in source control (SVN, CVS).
  • Do frequent check-ins.
  • Comment your commits.
  • Don't rely on your IDE to do builds. Have a build script instead.
  • Have an independent environment where the build script can be run that is not a developers personal space. Ideally do continuous integration here, but at a minimum regularly check that this build environment still works. Use this environment to build releases.
  • Settle on a layout style for the team. It doesn't matter which style, it matters more that everyone is consistent. Or just agree to do it differently and people can reformat their code using their IDEs. But make sure everyone is on the same page.
  • Optimize code only when you have demonstrated that it performs poorly. Make a regular practice of benchmarking modules. Run the benchmarks with your unit tests so you know when something gets really out of whack.
  • Employ regular peer review of some kind. Internal code reviews. Pair programming. Whatever works for your team. This is how bad code gets found and how developers learn to get better.
  • Also have occasional external code reviews that involve more than just the immediate team.
  • Encourage zero code ownership. Everyone owns all of the code. Anyone can change/fix anything. Any bug is everyone's responsibility.
  • Use tools regularly to check for common bugs/problems. If I review your Java code I am going to run findbugs on it - so you should too.
  • Minimize local configuration information in multi-tier applications. An ideal java midtier should only need to know one thing - a JNDI datasource from which all other configuration information can be derived. An ideal thick client should get global configuration from the server.
  • Always close resources. Take full advantage of try/finally blocks.
  • Don't reinvent the wheel. Use the core libraries of your platform. If you are writing in Java and you think you need to write a sort routine, or a string to date routine, or an array copy routine: STOP. Find good adjunct libraries and use them.
  • Have a well thought out strategy for handling exceptions and logging. All errors should be logged, preferably once. The log entry should give enough information to lead back to the root cause. It should be time stamped. It should contain a stack trace if applicable. It should have a context appropriate message that can be understood by someone not intimately familiar with the code.
  • Do your release cycles faster. I don't care how fast you are doing them now, go faster.
  • It is OK to make pragmatic short term compromises in your code, but make sure you go back and fix them very soon. Do not fall into the boiled frog trap.
  • Eat your own dog food. If you design a service interface and never actually use it, chances are it will actually be unusable in some way. The same for a user interface.

Recommended reading for best practices:
Any thoughts out there?


Thursday, September 4, 2008

What Does Good Software Look Like?

Good software looks and feels like this:

(I drew this - feel free to make fun of my artistic abilities)

And bad software looks and feels a lot more like this:

(image credit)

Far too much of the code that I look at invokes the latter image. Stop it please.