We have been in the process of redesigning and upgrading the Quillcards site, and we finally carried out the changeover yesterday.
We have been designing and tweaking the site on a development server (we used Heroku) so that we could test the changes without interfering with the day-to-day running of the ‘live’ site.
Additionally, the development site is password protected and we (Tamara and I) have been going in and tweaking bits of it and changing the text, the colors, and the layout.
I like the new look and the new navigation and improvements – and that’s saying a lot because my sense of how much I like our designs usually goes through rapid peaks and troughs.
If you have a website – maybe a site here on WordPress.com – then I am sure you know what I mean about the temptation to keep changing the look of things.
Other People’s Sites
Often I will go to a WordPress site that I follow, and find that the look of the site has changed completely.
The funny thing is that I can always find things to like in other people’s sites: And I can always find things to dislike in my own site.
And it is the same for the way I see Quillcards – and it is usually not very long before I want to rip up the design and start all over again.
But now the die is cast – at least for the medium term – and we have moved the code from the development server to the production server and ‘gone live’.
I was somewhat on tenterhooks because the new code has got to pick up and marry with the existing data. In fact it all went together very well, with just a couple of small snags that were easily dealt with.
From Cars To Code
It reminds me of the time (the only time) I and some friends changed the engine on our car. Everything worked except that the clutch wouldn’t engage. Then I tightened the connecting wire that ran under the car and suddenly – Bingo! – it worked.
I knew, of course, that cars parts are built on production lines to close tolerances – but nonetheless the fact that we could swap out a whole engine and that it worked. Amazing!
Perhaps even more surprising was that the changeover worked even though the car was very old. It was so old that the chassis under our feet had worn very thin.
It was so thin that every time we went through a puddle at speed, a fine misty spray filled the inside of the car.
So with code, the fact that the new code actually married up and captured all the existing data – and works with it – is amazing to me too.
That may surprise you. After all, it is digital code, so everything is built of discrete parts that are an exact fit. Nothing is built to close tolerances – it either passes through the digital gate or it doesn’t.
But, and this is the big ‘but’ it’s not just a few lines of code – there are many lines of code in lots of files that all go together to make up the site.
Ruby On Rails
Quillcards is written in Ruby – which is a fairly new programming language built on an equally fairly new framework named Rails. Ruby On Rails (ROR) is becoming more popular all the time. In fact Twitter was originally built on it although I didn’t know it was at the time we chose the language as the way we would build our site.
[Twitter subsequently moved away from ROR because of scaling problems. What that means is that Twitter gets so many requests per second that they needed to change to another framework that would handle them, but that’s another story.]
Lots of other sites are built on ROR including Basecamp, Hulu, Zendesk, Github, GetSatisfaction, and CrazyEgg, to name just a few.
I Met A Man
But on the subject of making changes to code and having everything still work, I met someone the year before who was working in Germany on mid-level smartphones for a big company.
He told me how the development team had inherited some of the code they used in the phones they were working on from another company that had originally designed them.
He said that his team worried about changing even one bit of one line of the legacy code they had inherited.
That was because no-one could say with certainty exactly how those millions of lines of code might interact with the change in all kinds of unforeseen ways.
In common with many sites (and with smartphones), Quillcards is interactive – meaning that their is interaction between the user and the site- as opposed to a static site where the visitor would just be able to read what is there on the page.
That means that there is always the input from the user to consider. Luckily though we don’t have any legacy code.
For our part, we test and we test and we try to do everything in as many possible combinations as possible, including in unusual ways that no-one would do.
Test And Test Again
Testing – even for small sites – is guaranteed to make you go cross-eyed as you hop from one part of the site to another and do all the things the site is supposed to allow you to do.
That’s because all the time we have to have your eyes peeled for changes that we might otherwise fail to see.
For example, it is ever so easy to fail to notice that a line of explanatory text has disappeared.
And then not only does the site have to work – it has to work in various browsers and at various resolutions – and now on tablets and smartphones as well.
I marvel at people who write code all day and make things work in a stable way.
Slow, Slow, Quick, Quick, Slow
One of the things that can slow down a site is images. They have to be a certain quality or they won’t look good. But better quality means larger file sizes – which, potentially, makes sites slow.
So together with changing the design of the site we have also pushed all our images out to the ‘Cloud’ on Amazon’s S3 multiple servers. Because they are located worldwide, it makes the process of serving them up to visitors much quicker.
Actually, thanks to our code, we have been pretty fast anyway, even before using S3.
We employ a coder who makes very efficient code. I periodically test to see how the code is running and am always impressed with how it stacks up against other sites.
Spot The Unexpected
On the subject of noticing changes, have you seen this?