Big redesign in the sky

This is perhaps one of the greatest articles every written on software rewrites. Every single developer should read and understand what it is trying to say.

...but the reality of green field projects is that they create the illusion that your messes don’t matter. Your messes do matter. Every single one of your messes matters. And if you don’t clean them up from the very start, you are going to wind up with a horrible messy legacy wad in short order.

How true. Few years back, I went through most of what is written in the article. I watched two systems, built to replace the same system before it, one after another. We fixed some messes but didn't quite understand what we were trying to overcome. Each new system got out of date and messy faster than the previous one!

This was also the reason for me hiring the architect for my new home. She walked around the old place and asked us about our messes, habits and workflows:

Why do you have a chair here? Is this where your mail pile up? Why do you take work calls from the sunroom?

Nowadays, whenever I hear about the need for a rewrite, I dig into understand issues in-depth. They often surface smaller pieces to fix.

Why is it hard to deploy? Let's run through a recent feature, why did it take so long?

Couple of other questions I ask:

Where do the rubbish pile up in the system? (example: are all the AB tests wired in your REST API and it is a monster...) What system do you have in place to collect the rubbish periodically?

Lastly, my colleague @Anuraag used to say:

Is your rewrite trying for a revolution or evolution? Definitely don't attempt a rewrite if you are looking for an evolutionary change.

Keep this in your bookmarks. Read it often. Share it with everyone. Thanks @JoeS for sending this to me few years back.

Ember.JS: How to handle invalid URLs

There’s a lot of documentation for the new Ember Router. However, I found that no one was talking about how to handle the “*” route in Ember, i.e. the routes that don’t match anything.

I first tried to look at the ApplicationRoute but that didn’t seem to throw anything. Ember just sits there with a lovely blank page!

ApplicationRoute { 
  events: { 
    errors: function(reason, transition) {
        console.log("never happened");
    } 
  } 
}

So here’s the easiest solution for handling bad urls. My router looks like this now:

App.Router.map( function() {

 this.route('login');
 this.resource('companies', {path: 'companies'});
 this.resource('company', {path: 'companies/:company_nice_url'}, function() {
   this.route('members');
   …
 });

 …

 this.route('bad_url', { path: '/*badurl' }); // Catch everything else!

});

The last route named “bad_url” will catch all the other unrecognized URLs and direct the user to the App.BadUrlRoute where you can handle them. You will get the URL segment as params.bad_url for you to inspect and offer friendly advice like “hey did you mistype companies?”.

If you simply want to show a page that says “There’s no one here you fool!”, just create a handlebars template:

<script type="text/x-handlebars" data-template-name="bad-url">
  <h1>There’s no one here you fool!!!!</h1>
</script>

And you’re done! Any path that doesn’t match your routes will get routed through ‘bad-url’, where you can act on it accordingly.

EDIT ON 6TH AUGUST

Marcus in the comments pointed out to me that using path: '/*badurl'  is better due to this handling "/this/is/wrong/path" situations. My initial solution to using a dynamic segment (:bad_url) did not catch this. Thanks to all the commenters!

EDIT ON 7TH AUGUST

I have realised that having "*badurl" instead of ":bad_url" has one caveat. I am implementing a funky search route that deals with all URLs past a base route like this: /search/x/y/z/a/b/c . Having the astriks to catch all the bad url's makes it impossible to have a search router which deals with "/search/*search_terms". So there you go... ups and downs to both methods. More on that awesome search route another day... :)