Tag Archives: best practices

Code Compression

Was thinking recently about how any good code base tends to go through a continuous cycle of expansion and compression. (This thinking may have been inspired by the recent frantic development work on SearchTempest in the wake of craigslist blocking framing…) The ‘expansion’ part is the standard stuff. Building something new, adding features, even fixing bugs most of the time tends to involve writing more code, causing the code base to expand.

However, if you only expand and never compress, eventually you will inevitably end up with a giant pile of pasta.

It’s critical to occasionally go through your code and simplify. Trace through the logic and figure out how it can be improved. Look at places where procedural stuff could be made object-oriented. Even just strip out legacy crap that isn’t used anymore.

Of course, this can be difficult to justify. There are always higher priorities, and it’s tough to put a bunch of time into a project that, in the best case, has no immediate visible effect. (Especially if you happen to answer to a manager who hasn’t personally done much/any coding.) And that’s the best case. It’s ironic, but this process of cleaning up code can very well introduce new bugs. After all, it may involve making fairly significant structural changes to a code base that is by all appearances working just fine. (And those bugs tend to make people… irate. Don’t do something like this then go away for the weekend.)

So, why do we bother? Here’s a similar issue: why do we bother researching sources of renewable energy? It has always -so far- been cheaper to just stick with fossil fuels. That may well continue to be the case nearly until they run out, since the incremental cost of extracting a barrel of oil does not increase linearly with its scarcity. But if we wait until we run out of oil, or until we destroy our atmosphere burning coal, it’s too late.

Of course, the consequences of ugly code are rather less dramatic, but the analogy holds. If you wait long enough, eventually you will be forced to clean up your spaghetti code because you’ll get to the point where adding one more hack will break the camel’s back. You’ll have a feature to add, or a bug to fix, and it simply won’t be possible to shoehorn it into the existing morass. When that day comes, it is NOT a fun day to contemplate redesigning your whole code base. Especially if the bug you’re trying to fix happens to be a critical one.

On the other hand, when such a fateful day rolls around, a clean code base can be a truly beautiful thing. A little irony: the best thing about nice clean code is that it makes it really quick and easy to slap on an ugly hack. And when your site’s down and the hysterical emails are rolling in, that ugly hack that gets you running again can be a beautiful thing too.

Or more generally, by periodically cleaning up your code, you make your job a lot easier the rest of the time. Of course, you could try to just ‘do things right the first time’. But even without deadlines (which takes us into imaginary-land), it’s pretty difficult to always keep the entire big picture in mind while solving a specific problem. Of course you should still try to write nice, clean, extensible code whenever possible. Sometimes though, you still have to take a step back.

In the real world, the cleanup of a given module will likely be spurred by some other development, which is okay. For me at least, there’s no motivation to sit down for the express purpose of prettifying code. But when you’ve already dug into something a bit and you start to see avenues for improvement -and you’re not in an absolutely critical time crunch- go for it! (If you’re always in a critical time crunch, you’re doing it wrong. Or someone is.) It’s just like cleaning in real life actually. Ever go to pick up a dirty sock and end up doing all the laundry then cleaning the entire house? Do that with code! (If not, go vacuum something. I bet your partner/roommate/cat will appreciate it.)

Nice clean code is a beautiful thing, but it’s elusive; you can’t aim straight for it. What you can do is write fairly decent code, then occasionally compress it. Channel your inner Superman and squeeze that code coal into a precious diamond. (Ha! Tied those analogies together!)

If it ain’t broke, now’s a great time to fix it!

The Ultimate Website Deployment Solution

Most basic websites tend to be deployed something like this:
  1. Write code
  2. Copy code to website hosting via FTP
  3. Refresh page to see latest changes
And.. that works. But it leaves much to be desired, both in terms of performance and convenience, for you and for your users. I’ll go over some of those issues here, then dive into a little more technical detail in an upcoming post (or posts..) So, here are some of the things we would like to add to the deployment process:
  1. Version Control! If you haven’t used version control before, go check out Subversion. I would also recommend the windows client TortoiseSVN. Honestly, version control has the potential to save your ass by allowing you to revert bad changes. The ability to compare current and past versions of files also makes it an invaluable development tool. Plus a million more things.

    As far as the auto-deployment utopia though, version control is key because it allows you to automatically pull the latest versions of files (or the latest stable versions if you prefer) directly to your production server. No hunting around for changed files and uploading via ftp. Plus, in the worst case, if the update breaks the live version of the site, you can easily revert to how it was before.

  2. Compression. One of the goals of good web development is of course to have pages load as quickly as possible. Yahoo offers a fantastic tool call YUI Compressor, which will compress (or minify) CSS and Javascript files to a fraction of their initial size, while maintaining full functionality. It does this by eliminating unnecessary whitespace, optionally renaming variables (in a consistent manner of course), cutting out redundant braces, etc. You obviously wouldn’t want to actually work on the files in this format, but doing it before making them live helps page loads and essentially costs nothing.

    Continue reading

Common CSS Problem – Header background cut off when page scrolled horizontally

Actually it can be any element, but it’s usually seen with header divs. For example, head over to facebook. Shrink your page down until a horizontal scrollbar appears, then scroll to the right. Notice that the blue background in the header is cut off. I’ve been noticing this on a few websites lately, but just today thought to check SearchTempest – and found that it had the same problem! Now fixed. The problem is that by default (or even by explicit css) these divs fill 100% of the width of their container. (For example, the page body.) This is good, because no matter how big the browser window is stretched, the div will stretch to fill it. Unfortunately, the 100% refers to the window width, so if the window is shrunk to less than the size of the content, it will be cut off when the page is scrolled horizontally. The solution? Fortunately, it’s simple. Just use the min-width property, and to set it equal to the fixed-width size of the content. My content is 960px wide, so by setting min-width=960px on the header div, I ensure that it is always at least that wide, even if the window is narrower. Of course, it still extended to 100% of the window size if that is wider than 960px. (If your content is variable width, just set the min-width of the header equal to the greatest min-width within the content – ie to the width at which the horizontal scrollbar appears.) Have a better solution? I’d love to hear about it in the comments!