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

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

You can do this:

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:

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.

(pun intended.)

So a couple of weeks ago, we knocked out our third release of Skribit into production. The Skribit team has done a great job of covering what is in the latest release, so I don’t it isn’t necessary to cover what we’ve added here.

So what is the real value of Skribit? Before Skribit, things look a lot like this:

Bloggers posted and readers read the posts and commented on the post. Occasionally, comments will lead into more posts, but still, bloggers for the most part led the conversation. Sometimes you’ll get emails, instant messages or direct conversations asking you to write about something, but they only come from people who can reach you directly. Also, you have no idea if the rest of your readers are interested in that same subject.

With Skribit, things now look more like this:

By using Skribit and taking in suggestions, bloggers can now have their readers lead conversations, as well as gain better understand who their reader are.

Another thing important about this release is that it’s a declaration Skribit hasn’t croaked (oops) and we’re still hoppin’ (yep, sorry!) along. And beyond the initial idea of Skribit we’ve developed the plan will make Skribit a real awesome product.

So please, go sign up on Skribit and join in the conversation. And let us know what you think!

For Sunday, December 2 2007 –

• 

  Andre on Tech: In Your Brain, Everything is a Relative Reference

  `Can software infer what is familiar terrain for us, and provide navigation relative to that? Can Google or Delicious know what my mental "anchors" are, and help me find stuff from there?`

  Tag(s):

Bookmarks provided by del.icio.us. Thumbnails courtesy of WebSnapr

Here are some of my thoughts on Startup Weekend and in particular, Atlanta’s Startup Weekend.  I suggest everyone read Micah’s accounts of ASW as well.  He wasn’t there when we were finally able to turn it around Sat. night, but his account was pretty accurate up to that point.

 So here goes:

• StartupWeekend is not your traditional startup.  Most Startups usually start with an idea before building the team, which means the team would have already bought into the idea.  Traditional Startups also have a core group from which the idea originates from.  In SW, there is no initial idea to begin with, and everyone has an input on what the ultimate idea should be.  It’s now a week later and I’m still surprise that we actually chose an idea.  It’s very hard to run a company as a democracy.  We probably should have elected a person in each of the subgroups to help come to a final decision.
• Unless your normal job involves delivering a product from conception to production in 2 1/2 days, don’t expect any ‘This is the way I’ve always done it’ to fly.  It didn’t seem like many of us were working in a mindset of having to finish something in 2 days.  I admit I was guilty of that as well.
• The whole team was split up into separate sub-groups (dev, marketing, biz-dev, etc.), and I didn’t get an opportunity to work with them as much as I would have liked to.  There were a lot of interesting, heated discussions going on everywhere, but there was no realistic scenario where I can participate in them and get the development that needed to be done finished by the Sunday.  There really should be a ‘MockupWeekend’, where people get together just to find, build, and mock up the idea in a weekend.
• From a development standpoint, we got ourselves into trouble by often classifying things as ‘easy’.  Our gauge of what ‘easy’ is is normally in the context of no less than a week.  In a weekend, nothing is really ‘easy’.  So what problems did this cause?  For one, we were constantly pushing the easy things til the end, which is smart in the traditional development sense, but when you have an overabundance of developers, it makes sense to identify those easy tasks and get people started working on them.  Calling things out as easy too often also opened up the flood gates to additional features that weren’t necessarily vital to the launch of the product.
• ASW would have benefitted if Andrew brought more structure into group, but I think ultimately Startup Weekend would suffer if was ran that way.  This was Atlanta’s opportunity to show what we could do, and from a self-organizing standpoint, we did pretty poorly.  Ultimately though, we did learned how to work together, and no doubt if we did this again we would be much better at it.  If there was one thing we did do well, and that was when it came down to crunchtime, we rocked it.

Keys to Success

Like Micah said, at some point on Saturday night, the momentum started to turn in our favor.  As always, there were probably many things working together that helped turn the ship, but I felt there were a few things that were key. This is from development side — I had to shut myself from the other groups otherwise I couldn’t have focused on doing actual development.

• Jason and Alan was finally able to get on top of the situation and make themselves gate keeper of what development was supposed to be building.  Before then, we were getting conflicting requirements left and right.
• Jeff, Amro, and Andrew from Appcelerator jumped in a took the task of the developing the widget using appcelerator, while the rest of us worked on the website with traditional Rails.  I was one of those that was originally wary of using Appcelerator, but in the end it looked like appcelerator was a very good fit — at least on the widget side.  More importantly, it put together a team that was already used to with working with one another hammering away at probably our most complex task.
• There were a lot of devs that really came through and filled in the gaps where help was needed. I can’t stress how important this was, to have people filling in doing sysadmin, CSS/layouts, and other small but definitely-not-insignificant details that really helped. I see these things as the 20% that always takes 80% of the time, and having people fill in where ever they can really helped a lot.

In later posts, I’m going to a recap of the events.  I’d also like to talk a little more about Skribit, which I have high hopes for.

I’m about to head to work after 2 1/2 long days and nights of Startup Weekend, but I wanted to make sure I at least posted something about it. I’m sure I’ll have more to say about it as I replay all the events in head, but overall it was a blast. It was roller coaster ride of emotions compressed into less than 60 hours, and while there were many moments of frustration over the course of this weekend, it only made the ending so much sweeter.

For Saturday, October 6 2007 –

• 

  blog.pmarca.com: The web and mainstream consumer behavior in 2007

  "Almost all read the "most popular" or "most emailed" items on sites"

  Tag(s): demographics web2.0 webdesign

Bookmarks provided by del.icio.us. Thumbnails courtesy of WebSnapr