Newer versions of Rails has a nice feature where you can use label references for fixtures. So instead of:

1
2
3
4

# posts.yml
test_post:
  user_id: 1
  title: My Test Post

You can do this:

1
2
3

test_post:
  user: quentin
  title: My Test Post

However, if your model class name is in a pluralized form, you might find that label references won’t work. That’s because fixtures derive their class name from the singular form of the table name by default. Fortunately, you can fix this by adding this line to your TestHelper:

1
2
3
4
5

class Test::Unit::TestCase

  # Explicitly map the table name to class name
  set_fixture_class :accounts => 'accounts'
end

Hopefully, this will save someone else from having to dig through the Rails fixtures internals.

I’ve been doing a lot of work with Maven recently, and having a miserable time of it.  Earlier this week I was ranting about it on a mailing list I was on, when I thought it would be therapeutic to try to list 100 things that irks me about Maven 2 that I’ve personally ran into.  So, I didn’t come close - I only came up with 25.  But I do feel much better now.

Here goes, in no particular order:

1. The Maven AntRun tasks allows you run ant from within Maven, but you have very limited access to the POM.
2. If you have a multi-module project configuration, changing the version of the root project requires you to change all the versions of the sub-modules
3. Maven Ant Tasks doesn’t resolve transitive dependencies exactly the same as a regular Maven project does.
4. Maven manages adding all the dependencies you need… and then some.  You end up probably spending the same amount of time having to exclude the dependencies you don’t need, especially in EAR/WAR setups
5. You pretty much have to declare the versions of every Maven plugin you use, or risk your build breaking when someone updates the plugin.
6. You can’t create a ‘macro goal’ that is a chain of multiple goals
7. Your custom plugins might not work if it is organized as a sub-module of a project.  Inexplicably, if you run the build inside that sub-module it works.  (Might just be a problem with Ant-based plugins)
8. Maven goes out of its way to not use Ant.  So, some things that work correctly in Ant don’t in Maven (for example, building GNU compliant tarball with the assembly plugin)
9. You can activate build profiles based on OS, file existence, and environment variables in Maven, but how do you disable them?
10. You can configure the build to deploy additional artifacts (e.g. javadoc and sources), but it won’t use the repository or snapshot repository configured for your project
11. Figuring out how a build works from reading plugin declarations is not easier than reading an Ant script
12. Good luck trying to find the artifact that you need to fix your NoClassDefFoundError
13. Passing Maven properties to your AntRun configuration?  Bah! who needs that?
14. What happened to my Maven 1.x pre/post-goals?  How is attaching plugins to build phases a better solution?
15. Multi-module projects is like having old school recursive Makefiles
16. Why can’t I define variables other than artifactId, groupId, and version to be substituted when building from an archetype?
17. Why can’t all the files in archetype-resources be included in the archetype?  Why do I have to define them all in an archetype.xml as well?
18. Versions of dependencies with classifiers are not be inheritable
19. Extending a build is difficult without creating a plugin, which requires creating yet another project
20. Customizations to the build always seems to take a few takes of trial and error before you can get them working.
21. Configurations specified for an Ant-based plugin doesn’t work if they’re specified at the execution level or the build profile level.  They will work if you specify them globally
22. Maintaining updates of plugins and what bugs are fixed in what version and what Maven version it’s compatible with is a PITA.
23. Documentation sucks.  Pretty much everything out there is surface deep.  There’s 50/50 chance that features that are skimmed over in the docs won’t work as expected
24. Why does the site:deploy and site:stage-deploy behave so differently for multi-module projects?
25. Why are build profiles inheritable?

So I imagine some of the explanation are vague, but my experience is that it is par for the course when you deal with builds in Maven.  Sometimes there’s seemingly no rhyme or reason for why things don’t work, and by the time you do find a workaround that does, you just don’t want to spend anymore time figuring why your previous approaches didn’t work.  I supposed the open source thing to do is to help fix the problem, but honestly, I just don’t love Maven that much.

I found Tablefy via Lifehacker last night, which is an application that is very much like one of the ideas I wrote about almost 2 years ago.  It’s still rough around the edges (the petfinder captcha is a first for me and is pretty cool, although klunky), but I’m looking forward to using it and seeing what kind of usage can come out of it.

Skribit’s downtime last Monday got me thinking about my past experience with performance tuning.  I’ve troubleshot a lot of performance problems in the past, and here are some things I’ve noticed:

It’s Never Just Because Pure Load.  I’ve used this excuse many times before and still mutter it today, but I never truly believe it.  If you hear yourself saying this, it should be setting off red flags in the back of your head.  Look harder.  Why is it never because of load?  Because we don’t write perfect software.  Deadlines happen, we can’t always predict how users will use the site, and we sometimes we don’t know how things should be designed until later.  Basically, shit happens.  Chances are there’s something in the software that’s misbehaving under load.

There are Long Term and Short Term Solutions.  Depending on the immediacy of the performance problems, you might want to tackle the short term solutions first.  It’s hard to fix the long term solution quickly and correctly when you have unhappy customers.

Know the Performance Problems You’re Solving.  Don’t just guess at what the problem might be, try to figure out how to identify it.  Check the logs and maybe the resulting data created.  Try to predict how your site should behave when the problem is occurring and prove it out.  Even if this takes some time, you want to make sure your changes fix the problem, and that if performance problem still exists afterwards at least you know you’ve correctly fixed one problem.

Caching is Great for Hammering out Performance Issues.  I usually use caching as the first line of defense against load.  Others like to tweak database indices, code, and/or configuration first, but my experience has been that caching gives you the most bang for your buck.  However, caching is like cleaning up your room by stuffing everything into your closet - if you don’t go back and clean things up later, things will eventually come crashing down.

I took the time today and moved my blog from a self-hosted Wordpress Installation to Wordpress.com.  I did this for mainly two reasons:

1. I was tired of keeping up with the constant WP upgrades.  It seems like everything I get around to installing on update, I would have to upgrade a few days later.
2. The service I was hosting my blog on, Media Temple’s Grid Service, seemed horribly slow, especially when it came to the administration screens.  My blog is also the only think I’m really running on Media Temple (gs), so if I could move my blog I can eventually reclaim that $20/month.

I’ve been holding off on moving because of the lack of Skribit support on Wordpress.com.  However, our most recent Skribit update now provides a comprehensive set of RSS feeds that are available for use with the RSS sidebar widget provided by WP.com.  We’ve also made a change so that bloggers can add their blog without having to add the Skribit widget on their blog, so link to my Skribit blog profile page.

Moving to WP.com wasn’t exactly a seamless process, for a couple of reasons:

• I needed to buy credits to map my domain to WP.com, but the buy credits button wasn’t available until you point your DNS server to WP.com.  This didn’t sit well me, since there could be potential downtime between the time I point my server over to WP.com and when the credits become available for me to use.  It was even more disconcerting to read that credits might not show up for use immediately after purchase.  Fortunately, I was able to find another place on the site to purchase credits (on the page allowing you to gift credits), and the credits did showed up immediately after purchase.
• There’s no apparent way to import uploads from your old server, so I had to mainly upload them.  Fortunately, I’m not exactly a prolific blogger.
• I used the old Ultimate Tag Warrior plugin before WP had tagging functionality built-in, so I lost the tags for all my older posts.
• I haven’t been able to figure out how to import my Intense Debate comments into my new blog (if anyone else have done this before on a WP.com blog, I’d love some pointers).
• WP.com doesn’t have any FeedBurner support, so although I’m using the FeedBurner RSS link on the sidebar, I still have no control over the auto-discovery link that’s in the page header.  I imagine I can fix this if I upgrade my WP.com service though.

I’m not sure how all my changes will affect the RSS feeds, so I apologize for any feed spam.  And there’s still some more images to upload, and I still have to change my header image.

I’m still waiting to get into the GAE beta, but I wanted to share a couple of thoughts about why I think GAE is significant beyond grid computing and making it cheaper for developers to build applications.

A New Way of Building Web Applications

Today, when we build applications developers have to pretty much understand the full stack from top to bottom. If you’re a PHP person, you need to know LAMP. If you’re a Java person, you need to know J2EE, the Application Server, etc. GAE removes that need - all you need to know is how to code your application logic, GAE handles the data storage, scaling, deployment, web serving, etc for you. It is the ultimate application server.

This model can work very well outside of grid environments. What if companies have their own app engines, which allows their developers to code to application units with push button ability to deploy to development, staging, production?

Well, isn’t this just a Java WAR file you ask? No, because WAR files aren’t opinionated. You want to use MySQL/Oracle/PostgreSQL? You want to use EJB/Spring/POJOs? You can do that with WAR files. You can’t do that with GAE. Options are great, but they limit your ability to make assumptions, and assumptions makes development easier. That’s what Rails means by convention over configuration. Most application developers shouldn’t really have to care about these issues anyway.

By making assumptions about all these applications, I can make it easier deploy the application to multiple environments. I can apply sweeping changes that can improve performance for all applications. Infrastructure support for different applications won’t require different knowledge sets.

Inverting the Facebook Applications Platform

Another interesting aspect of GAE is that by leveraging Google Accounts, GAE has created a platform that can ultimately be the inverted version of the Facebook Application Platform. The Facebook platform takes a ‘Department Store’ model, where applications are housed inside of the Facebook website. Applications have limited styling capabilities, and pretty much has to adhere to the Facebook look and feel.

In contrast, GAE is more like the ‘Mall’ of social applications. Applications can have their own unique storefronts (which allows them to better create a brand), while still taking advantage of the facilities provided by Google.

Granted, Google hasn’t yet integrated those social features required to compete with Facebook, and there aren’t any signs that it will. But considering how Google has GData’d every significant service they have, I can’t imagine this not being far behind.

This pass weekend, my wonderful wife got me a shiny new MacBook Pro for our anniversary. If you’ve ever seen my old laptop, you know it’s been a long time coming.

I’m now looking for a IM application for the Mac (I’m testing out Adium now), and thought I’d write about how IM applications have grow stagnate of late. I know, we now have the ability to instant message people from a browser or mobile phone, but outside of that, everything else have been aesthetic bells, whistle, doo-hickeys, and thingamabobs.

It’s time for someone to revisit what it means to instant message someone. The current model is definitely flawed and is failing as an effective tool communication. This is why we have services like twitter Today. Here are some of the flaws of current instant messenger applications:

Roster Lists Suck

In the early days of IMs, roster lists were sufficient. But now, everybody’s on the internet. As a result, my roster list is now long and unmanageable. Scrolling through my roster list now would be like if I had to scroll my whole address book to find the exact person I want to send an email to. There should be an easier way find the person I want to instant message.

Also, the roster list is a poor representation of how we connect with people today. Instant communication today is such a major part of what we do online today, so it’s amazing to me that it is constraint to such a small and confined window.

I Want a Connect to People, not their Identities

Most clients treat contacts on different IM networks differently. IM applications should treat all my buddies identities as one. Adium seems to do this pretty well. IM should be about connecting with real people, and separating them by what network they’re coming from is impersonal.

The Concept of Instant Messaging should be Expanded

Services like Twitter and Jaiku suggest that there is a communications gap that instant messaging currently doesn’t provide. Instant messaging networks are getting more and more inter-operable. Instant messaging applications should be looked at as a conduit for all informal communication. Users don’t care what network they’re using to communicate - they care that they can connect to the person they want when they want.

Before I read Seth Godin post about opportunities during an economic downturn, I was running the some pretty similar thoughts through my head.While the natural (and maybe correct) tendency during bad economic times like we are in now to is to tighten the purse strings, it’s important to remember that your customers are probably doing the same thing as well. They might be looking for alternatives to things they normally pay a lot for when times were better. And when things do get better, will they find that they really missed what they were previously paying for?For small startups, this is a great time - if you can provide lower cost alternatives to existing offerings, right now you have an active audience. The companies that can figure out how to exploit that will be the ones that lead us out of this recession.

While I sitting through Jesse’s git presentation during the atlrug meetup last week, I migrated my Beast Plugins from my own Subversion repository to github.

One thing in Jesse’s presentation that I didn’t necessarily agree with is that github is characterized as the MySpace for hackers. That’s not exactly accurate - it understates the tangible value of github. At the end of the day, MySpace only really provides an emotional value, whereas github provides very real and measurable benefits. In that sense, it is more like the delicious for hackers.

What I like about github is how it has taken the open source model to a social source model. While current open source made the source public accessible, contributing to the source was still a pretty closed model. Submitting patches to projects required using an obscure patching utility and was managed by some centralized authority that could reject your patches. With github that changes - submitting patches is as easy as clicking a link, and if original maintainer doesn’t want to incorporate your changes, you can fork their code while still keeping your fork up to date with the original. This allows everyone to have their voice, and not force users to have to be accepted in order to be heard. While this might seem a little chaotic - you could possibly have hundreds forks of a project - it does create a model that is more organic and Darwin-esque, which will only make the final product stronger.

While I still have some concerns about git itself (the different vocabulary, how applicable it is to the enterprise), I definitely see it as being a catalyst for the next generation open source.