Today marks the first beta release of the coming version of Rails, version 3.0 and I figured it’d be fun revisiting that post.

1. $ rails hello

2. $ cd hello

3. $ rails generate controller hello

4. Open the file config/routes.rb. Almost at the bottom (line #57) is this line:

   # match ':controller(/:action(/:id(.:format)))'

   Remove the # in front so the line looks like:

   match ':controller(/:action(/:id(.:format)))'

5. Create a file named index.html.erb in app/views/hello containing the text 'Hello world'.

6. $ rails server

7. Navigate to http://localhost:3000/hello in your browser and be greeted by your friendly application: "Hello world".

PS: http://localhost:3000/ is (still) a lot prettier “Hello world”-ish page.

PPS: Note that the Rails 3 example above actually has a step more than the Rails 1 ditto. This comes from the fact that Rails 3 doesn’t build a default route for you.

It’s one of the best decisions I’ve ever made.

Being directly responsible for my own income has been fun, empowering, fulfilling, and pretty damn scary. I’ve met lots of great people, worked with great customers on great projects, and I’ve learned a lot of lessons in the process. Allow me to share a few of those lessons with you.

Your network is important

I am a geek. I am not particularly outgoing. Small talk is not a forté of mine.

However, as a freelancer, entrepreneur, or anyone running a business you cannot isolate yourself in a dark basement producing high quality work. You need to get out of your chair and meet people - partly in order to stay sane and get outside influences, but definitely also because your network is very important to your business.

I have gotten the majority of my customers through my network. If you provide a great service, your previous customers will happily recommend you and your coworkers will happily refer clients you. If you’re a great person, your friends are going to talk about you.

Leverage your network, and don’t forget to make yourself available for them as well.

Running a business will consume you

One of the things I have been most surprised by, is how much I think about the company.

There are always a ton of things to think about; processes that could be improved, ideas that might be worth pursuing, people to get in touch with.

Whenever I have some downtime; doing the dishes, walking the dog, watching television or in some other way allow my mind to wander, it tends to wander towards Substance Lab.

You won’t bill out as many hours as you think

Many other people have written about this point in length, but it is important enough to bear repeating.

If you plan on working reasonable hours - and you should - you cannot expect to work 8 billable hours per day. There are so many other tasks that you need to take care of, that a part of running the business. Admin, taxes, sales, marketing - Jon Hicks have a longer list.

I have, on rare occasions been able to work 6-7 billable hours in a day, but more realistically, I count on around 3-4 billable hours on any given day.

Scheduling is really hard

Things will take longer than you think. Period. Couple that with the fact that you probably won’t be able to work as many hours as you figure, and you have a scheduling problem on your hands.

You want to minimize the amount of time without client work. But at the same time you need to leave buffers in place for when your estimates are flat out wrong or when something goes wrong and needs to be dealt with.

I wish I had any words of wisdom to dish out that would instantly transform you - well, myself - into a scheduling demi-god. Unfortunately, I don’t. For now, I am relying on optimism and a lot of running really fast when things get tight - hardly optimal.

I’ve shown you mine…

That’s just a few of the lessons I’ve learned over the last years of freelancing. If you do any freelancing or run your own business, what have you learned? What would you tell someone who’s thinking about starting out on their own?

>> person = Person.first
=> #<Person id: 1, name: "Jakob", height: 170, created_at: "2010-01-22 08:57:02", updated_at: "2010-01-22 08:58:57">
>> person.height = 169,5
=> [169, 5]
>> person.height
=> 1

Uhm, huh? The above is from Rails 2.3.5 using SQLite, but I originally saw the issue running on PostgreSQL.

It turns out, that if the object you assign to an integer attribute/column does not respond to to_i, the attribute will be set to 1 - unless the object evaluates to false in which case the attribute will be set to 0.

My best guess is that ActiveRecord is trying to work around the lack of boolean columns in MySQL with this. So even though I am not using MySQL I still have to suffer its ineptitude. One just can’t win.

The concept is simple, started by Tim van Damme:

A simple game: Go to the address bar in your favorite browser, and type one letter. Start with “a”, end with “z”.

• A: apidock.com/rails
• B: Internal blinksale.com site
• C: Client Basecamp site
• D: Client Redmine site
• E: en.wikipedia.org
• F: facebook.com
• G: github.com
• H: Internal Highrise site
• I: images.google.com
• J: My Backpack site
• K: kongregate.com
• L: Client Lighthouse site
• M: mentalized.net
• N: Client staging site
• O: kongregate.com
• P: planetstorm.com
• Q: quotagio.us
• R: wiki.railsbridge.org
• S: substancelab.com
• T: twitter.com/mentalizer
• U: upcoming.yahoo.com
• V: Client staging site
• W: Internal Redmine site
• X: live.xbox.com
• Y: youtube.com
• Z: www.eizo.dk

Funny how some sites I’ve rarely visited still appear. Neither live.xbox.com, eizo.dk, nor quotagio.us are particularly common destinations for me, but I guess not many domains have z, x, or q in them.

You are in flow.

Suddenly an unexpected idea spawns in your head. This idea must be preserved and dealt with, but you can’t risk losing your flow, so you quickly launch your favorite notes application to jot the idea down before it escapes the grasp of your mind.

A new version of UberNotesMaster is available, would you like to download it now?

Stumped, you try to gauge whether the update is quick enough that you won’t lose your flow, but you have already lost. Your flow is interrupted, the idea is escaping, and your application is still not updated.

Do you prefer the plague or cholera?

Typically, when an application announces that it has a new version available, you have two options:

• Upgrade now and generally disrupt what you are doing
• Ignore and continue to run outdated, potentially buggy and insecure software, and get annoyed the next time you launch the application.

While I like upgrading my software as much as the next person, I launch an application for a reason; to use it - instead the application forces me to choose between performing the task at hand or get the latest version of the software. You know what, I want both!

Possible solutions

Update after use

Instead of asking me to update an application when I am actually trying to use it, how about dealing with the update after I am is done using the application?

This way, the upgrade dialog could appear when I quit the application, and the update would take place while I am doing my work in another application. A much smoother experience whose only interruption is easily dealt with.

It might, however, prove to be quite frustrating when you attempt to shut down your computer and all running applications want to update themselves. Also, OS X users are known to never actually shut down applications and also never restart their machines, so they would end up never updating.

Background update

A variation of the above would be to still ask me, the user, when I launch the application, but allow me to say “Yes, I want to update, please download and update in the background while I continue with my task at hand”. The actual update then happens after I quit the application, making the entire process almost invisible to me.

Out of band updates

We could also move the application update process out of the actual applications themselves. This strategy is known from the iTunes App store, where updates to all installed applications happen in the background while you’re doing other stuff. Smooth and seamless and allows you to maintain your installed software when /you/ are ready for it.

The process in itself is probably the smoothest offered, but it also bears the penalty of centralization. This software updater application somehow needs to know about all independent and unique applications you have installed and be able to update them.

Larger software vendors like Adobe have taken this approach and created their own - usually pretty crappy - updater applications. I would love to see something kickass here - preferably from the ISV community, but it could also be interesting seeing Apple build this into their own Software Updater app (or in the Windows equivalent if one exists).

Now, excuse me, I have to update my blogging application…

The decline of blog readers

The number of visitors to mentalized.net keeps declining. This is hardly surprising; I don’t write as much as I used to here (I have a feeling Twitter is eating up a bunch of potential articles), and a lot of content is probably being consumed off the site in news readers and other aggregators.

Still, I am quite happy having more than 125000 people visit my humble website and I owe each one of you my thanks.

What people came for

My collection of totally free, animated GIFs for showing Ajax activity continues to reign supreme as the most popular content on mentalized.net. It is followed by my satirical web 2.0 webdesign tutorial.

Both of those were published back in 2005 over 4 years ago, yet they still continue to draw readers to the website. The only article on the content top 10 that’s actually published in 2009 is my response to a Java developer spreading some FUD (which unfortunately detoriated into more FUD and mud-slinging).

Top content on mentalized.net in 2009

1. AJAX Activity indicators
2. Building your very own web 2.0 layout
3. No such file to load — mkmf
4. Java kicks Ruby in the what now?
5. Hello Ruby on Rails World
6. Rails 2.0 deprecations
7. Browser size does matter - Actual numbers
8. Hunting down VBScript error codes
9. Setting the request content type in Rails
10. AJAX activity indicators

How people got here

Google is still, hands down, the biggest source of traffic for mentalized.net. Almost half of all visits have been referred by Google. For comparison, the next search engine on the list is Bing with less than 1% of Googles referrals.

Social media sites like Digg, Twitter, and Facebook still aren’t providing me with a lot of traffic. I must be “old media” - or perhaps my content simply isn’t the kind of content that cries out for immediate attention.

The only post I’ve made in 2009 that was in relation to “current events” (link) did in fact get some traction on the social sites with roughly half the visitors coming from various social sites.

2010?

I am looking forward to redoing the above stats for mentalized.net when 2010 is over. I signed up for Project52 fully intent on accomplishing the goal (“to write at least 1 new article per week for 1 year”). Hopefully, getting back into the thrill of writing regular content should provide for better content that can at least break the decline of visits. Time will tell.

I don’t blame them. Most web analytics packages don’t provide us with a metric that tells us the viewport widths of our users, and as humans we are likely to grasp onto the metrics that is available to us, not necessarily those that are important.

A tiny sparkle of hope has now emerged in a sea of ignorance: Someone at Google figured out that people browse the web with differently sized browser windows.

The result is a small tool to visualize what percentage of users can actually see a given area of your website without having to scroll: Google Browser Size

The tool is still pretty crude - as the comments to the introductory post clearly tells - but in time it could get really useful. If nothing else, it can hopefully be used to open the eyes of clients and designers.

All I am waiting for is getting this rolled into Google Analytics, preferably instead of the useless Screen Resolution metric.

4 years ago, when I was still thinking PHP was a great language, I needed a real project to use for my experiments into Rails. At the time, I was getting into playing World of Warcraft along with a bunch of friends, and we needed a website where we could discuss tactics, organize events, and all the other small tidbits that go into running a guild.

I figured I could use Rails for that website, and hey, I might even be able to make a little money on the side by letting other guilds use the same application on a pay-per-month basis. Step 1: Build it - Step 2: ? - Step 3: Profit! As it turns out, step 2 is actually pretty important and harder than I thought.

Things I did wrong

Over the last course of the project, I’m sure I’ve made a lot of mistake. Following are a few of them, the ones, I think are most important. Writing them out here, shaming myself publicly, will hopefully result in me not forgetting the lessons learned.

Perhaps someone else might even learn from my mistakes.

I was not passionate enough

Probably the number one reason for the failure of Guildspace, was the fact that I did not take the project seriously enough. All the other problems can be traced back to this.

I built the application for myself and some friends, and the business part was just a stray idea. As long as we used the application, I was motivated to improve it. Consequently, when we stopped using the application, I lost the motivation to build the application.

Certainly, if the application had customers and was generating revenue at that point, I might have been motivated enough to keep it running, but the reality was different. Which isn’t surprising, because no one knew about Guildspace.

I didn’t tell anyone

I launched Guildspace with no real plan for how to market it. I invited a few friends and members of my family who used the application and were reasonably pleased with it, but other than that, I never really told anyone about it.

To this day, I am surprised by that fact. I have a weblog with thousands of visitors every month, yet I’d be very surprised if any of the readers of this blog knew about Guildspace. To be fair, I’ve never claimed to know the first thing about marketing. Yet, I could easily have done better than what I did.

I wasn’t prepared to invest

My lackluster attitude towards the project also resulted in my not wanting to invest any money in it. Sure, I could pay for a few domains, but that was pretty much my upper limit when it came to hosting. You know what? If you want to turn a project idea into a profitable business you need to invest money in proper infrastructure. And no, the cheapest hosting plan you can find will not cut it.

Hosting wasn’t the only piece of infrastructure I skimped on. I didn’t want to spend money on proper payment processing. I figured, as soon as the customers start flowing in and I actually have some payments to process, I can just use PayPal. They only charge a transaction fee, so if I don’t make money, I don’t pay them anything. Big mistake!

In order for PayPal subscription payments to work, the customer needs to create an account on PayPal - or if they already have one, log in there. This totally messed up the signup process, but I was too much of a scrooge to care. Not only would a potential customer have to sign up for Guildspace, she’d also have to sign up on a seemingly unrelated website.

Not surprisingly, the majority of new signups never got past the PayPal step.

Post-mortem

The net result of all of the above is that Guildspace is no more. The life-support-system keeping it alive has been turned off. I’ve had fun building the application and I learned a lot in the process.

Rest in peace, Guildspace, we hardly knew you.

The Projects folder contains a bunch of other folders, one for each client. Each of those folders contain a folder for each project I am working on for that client. This keeps everything grouped nicely together in my eyes.

And then my neat structure breaks down. The only fairly constant element inside each project is a folder where the actual code of the project is stored. This is usually a clone of the Git repository named, but a projects have Subversion checkouts inside them.

Outside of that, the folder for a single project can contain any number of different folders, usually for design ideas, requirements documents, specs, prototypes, and all the other bit and pieces that exist around the process of building a project.

Archived projects

In the Projects folder is also an Archived folder where I put zipfiles of the projects I no longer work on. The archive folder follows the same structure as the Projects folder, with a folder for each client, containing the zipped projects I’ve built for them.

Contracts and documents

I currently keep my contracts and proposals and documents like that in a separate structure, keeping everything under Projects focused on actually producing the project.

I’ve showed you mine…

I’m kind of curious as to how you organize your projects. Are there any applications I should be using, any important metadata I’m missing out on, or any other tricks you employ?

I teamed up with Kasper from activeart and aided by Laust Rud Jacobsen and built them the simple almost-one-page-website you can see at http://vpsforce.eu.