Latest Tweets:
Yesterday was a very good day, achieving something I seemed to get tasked with a lot. Optimising somebody else’s rails app. This is never without it’s pitfalls because first and foremost you have to learn the problem by studying the solution in front of you. Most of the time this has one or two nasty bolted on features which throw you in one direction or the other.
That was the brilliant filesharehq.com a application that lets you easily and cheaply store and share your files. You can setup users and share certain files and folders, the big difference between most filesharehq.com and something like GetDropbox is that you can give people access through FTP so anybody with a FTP client can add files. This is brilliant for many reasons and uploading large files through the browser is somewhat scary and in you can’t resume the upload process. Filesharehq.com gets around that by simply letting you setup FTP folders for your clients, while still giving you complete control. All your clients files in one place, on the cloud, globally and securely accessible and with the ability to give folder access to clients!
Not to say the codebase I’m looking at was bad in anyway, as programmers we all have our own little flavours of doing things, like regional accents we use different words and ways of constructing language which most of the time is derived from background. The great thing about rails is that it is based on a set of standards and rules, files are usually in the place you expect them and you can generally find what you are looking for very fast.
Yesterday’s problem came from overriding one of those defaults, a table without a primary key existed, so the table wasn’t indexed. Now it’s got several hundred thousand rows in it the performance of that table suffered. Adding a simple index to the table solved the problem and took the page rending time down to under half a second again. It highlights an error that is quite fundamental but because rails usually handles quite well the indexing of database tables something we don’t tend to think about anymore.
When developing an application on a super fast MacBook Pro the developer would have never noticed, it wasn’t until it landed in the domain of the public and got battle tested that slowness started to occur.
This brings me back to my point though, how do you start to understand the way other people do things, there would have been a reason and a thought process to having a table with an under-standard primary key. Whenever you have a codebase put in front of you, if it be at a new job or making amends to an old project, the code isn’t the thing at all that is what you need to decipher. It’s the thought process!
Hundreds of questions have been asked internally before and there are reasons no-matter how silly something looks for it being that way. I know i have left some real clangers behind me in the past and it is a fool who doesn’t admit to doing so while learning a new feature or language set. At the end of the day whenever you build something new the first unknown is usually the business logic, that untold point that you wish you knew upfront. The point where the client turns round to you and rubbishes one of your assumptions. Hopefully to you that isn’t something too fundamental.
At that point in the process you are usually over or close to the end of the budget, your line manager is going to be under as much pressure as you are to deliver the working version and fast. It’s nothing to be ashamed off and most of the time clients will respect you for putting your hands up and saying “we did it this way because, however we can correct it”
As application developers we very often find it hard to admit when we are wrong! So be nice to the next guy, don’t write something in a line if you can do it in 4 and it has absolutely no effect. Write simple cleaner code, if you do have to go back to it and change the way things work then you will find it a lot easier to insert and if or an unless if the code is already broken down into digestible chunks.
