Every day a load of new start-ups appears on the scene. Every day is full of announcements of new Web-2.0-like tools, platforms, and whatnot. Every day another start-up gets new funding, sometimes in ridiculous amounts. TechCrunch is full of news like that. And every day I ask myself: Haven’t I seen all this before? Before the new millennium millions, if not billions of investor and stock money went down the drain with the crash of the first wave of web start-ups. Venture capitalists invested without questioning business plans, if such a thing even existed. Personally I crashed rather soft. I was still a student, and I found a new job without any problems. I switched from new economy to old economy for a while.

But what about this new wave? What’s so different about it that big buckets of money are once again poured into sometimes questionable ideas which may or may not bring any money? What distinguishes today’s start-ups from the ones back then is the user. Without users, the content and therefore value they create, most of these start-ups aren’t worth a penny. But are some of them really worth pouring millions of dollars in them without an obvious business concept? Think about YouTube, Last.fm or the blatant German Facebook-copy StudiVZ. All of them have only one value: their users. But what can you do with that? Throw ads at them might be the obvious answer, but is that really something in the long run? A community is a brittle construct. Change something they're used to, even if it is going to help you get more money out of it, and they'll run in flocks.

I’m not sure in which direction this is going to go, but I have a weird gut feeling about the recent fundings. New start-ups also tend to look for people like they used to back then, by offering shares and working on something “new”. Even cheap labour isn’t easy to find these days, and yet a lot of start-ups pour their money into cheap and inexperienced development teams, near-shore or off-shore, only to realize later on that they screwed up and lost a big load of money. Not only does this hurt the developer market, the danger of the bursting Web 2.0 bubble will cause a lot more pain. Once again armies of unemployed web developers may find themselves walking down the street with “Will code AJAX for food” signs. I'm not very excited about that thought. Nowadays I'd crash a lot harder than back in the day.

Is that what we want? I’m thinking no. All that funding is ridiculous. I wholeheartedly agree that new ideas should have the opportunity to get out in the open, but why not start with a smaller amount? Some of the newer start-ups seem to have missed the bursting of the first web bubble which is not a bad thing, but there's always something to learn from the past. I love bringing ideas to life, but if they exist only for the purpose of getting you a nice sum of money, where's the fun in that? Hopefully they won’t witness the second bubble going up in smoke. I know I'd rather not see it happen again.

Tags: web

They wanted me to spread the word, so that's what I'll do.

A List Apart (if you don't know it, it's a great resource for web designers and developers) is running its first annual Web Design Survey to increase knowledge about the people involved in all things dealing with the web design and development. I think you should take part in it too.

Tags: web

When I built the billing process for Travis CI's commercial offering, I decided to try out some new things to avoid callbacks in ActiveRecord models, including validations.

In 2010 I wrote about why callbacks and validations scattered about the persistence layer bother me. I recommend reading it to get the full background on this.

What I went for this time was a mix of a service layer that handles all the business logic and a layer of form objects that handle communications between the controller and the services, including handling validations.

The goal was to have simple Ruby objects to take care of these things. No special frameworks required. Inspiration in part stemmed from Django's form objects, though my implementation lacks the part that talks directly to the model, for instance to save data to the database. Quite intentionally so, as that part is up to the services layer.

The last thing I wanted to avoid is having to use attr_accessible in the persistence layer. In my view, that part is not something persistence should be concerned with. It's a contract between the controller and the services it calls into to make sure parameters are properly narrowed down to the set required for any operation.

Form Objects

For form objects, I looked at Scrivener, which was a great start. It's a very simple framework for form objects, the code could barely be simpler, but it lacks some validations, as it implements its own set.

On top of that, it doesn't tie in with Rails' form handling that well, which requires some parts of ActiveModel to work properly. Scrivener is great when you integrate it with e.g. Sinatra and your own simple set of forms.

It's so simple that I decided to take its simple parts and merge it with ActiveModel's validations support. Thanks to Rails 3, that part has been extracted out of the ActiveRecord code and can be used for anything.

The beauty of form objects is that they allow you to specify different views on the same data. Every database record wrapped by ActiveRecord can have multiple representations depending on which data is required by a specific form.

ActiveModelSimpleForms

Here's the base code for the forms, which doesn't have a name, it's just a snippet of code that's part of our Rails project:

It defines a few things that are required by Rails' form_for, but other than that it's straight-forward. It can populate form attributes based on the model handed in, which makes it suitable for re-use, for instance when editing an existing object or when validations failed on update.

Here's a sample form object:

It declares a few attributes and some validations. Thanks to ActiveModel you could use anything provided by its validations package in a form object.

By declaring the attributes a form object brings a simple means of implementing mass assignment protection without requiring any sort of sanitization and without poisoning the model with attr_accessible and jumping through hoops in tests to create valid objects to work with.

If an attribute assigned to the form doesn't exist, the assignment will fail.

In the controller...

The interaction with the controller is rather simple, no added complexity:

I'm liking this approach a lot, and it's been in use for a few months. There'll be some refinements, but the simplicity of it all is what I find to be the best part of it.

It's all just plain Ruby objects with some additional behaviours. Add a simple service layer to this, and cluttered code in the ActiveRecord model is nicely split up into lots of smaller chunks that deal with very specific concerns.

Tags: rails, web