Refactoring vs Rewriting (preamble)

The say the path to recovery starts with admitting you have a problem.

I wish our problem was code-rot, or a simple case of a good design gone horribly wrong through bodged maintenance and hacks. (If only we’d managed to achieve such lofty goals to start with.)

Let’s just rephrase: the path to recovery starts with acceptance.

Think of this as an acceptance speech, or a first-time introduction at Incontinence Anonymous. “Hi. My name is Ash, and I’ve made a mess.”

I’m admitting to a problem (in public) because I want to move on. I want to get the feeling of acceptance, figure out the six-step plan to recovery, and start climbing out of this pile of manure one shitty handful at a time.

This is going to be public and painful, but I’ve checked with my partner and extracted a grumbling murmur to go ahead.

What are we talking about here?

We’ll be talking about our price comparison site: That’s the beast waiting for a handy dollop of TLC, or a lethal injection (I leave it to you to make your own call on that.)

The code-base is a nightmare. From tier-to-tier, front-to-back; a full blown living nightmare. Every day I sit down to code I debate whether to poke it a little more, or pronounce the code dead and rewrite the whole thing from scratch.

Not good.

More haste, less speed

For a two-man team, we managed to rack-up an impressive tally of mistakes very early on, starting with how we chose a language:

I was a Java aficionado, and my partner came from a Microsoft background. Neither of us wanted to cross-train – not out of loyalty or hate, but because neither platform seemed like the best way to get stuff out the door quickly.

Without ruminating obsessively, we decided scripting was the path to follow and quickly short-listed the three P’s (perl, python and PHP), ruby and lua. Python and Perl were quickly ruled out for the most immature reasons (the partner hates perl’s stereotypical punctuation-heavy style – and I hate python’s space-sensitivity.) A brief foray into installing Lua on OS X convinced me it was too unpopular and risky to use. With high hopes for Ruby (and Rails) that option quickly hit a wall too due to immense confusion and a complete absence of “mod_ruby” (I know, things have moved on.)

So we ended up with PHP. I think its important (to me) to realize we ended up with PHP by default, not on its merits. PHP, of all things. PHP with it’s “magic” methods. PHP with its retarded unicode support. PHP with its piss-poor objects.

In case you missed the subtle undertone there: I don’t like PHP. But at the time, we’d ruled out all other options and talked ourselves into PHP with the convincer “Facebook runs it… it’s gotta scale!”

Design? What design?

A two-man team: both degree educated, both experienced with languages from Ada to Eiffel and Lisp to Miranda. Both with industry experience working on small, medium and large teams. Both smart enough to know better.

Of course, it’s different when you’re your own boss. When there’s no client. No timescale. No requirements.

We got sucked into the ‘agile’ cult, taking on all their bad practices, and failing to follow any of the good. Very soon we were banging out code with gay abandon. We never planned a proper object model, and felt more productive banging out procedural code instead of implementing class hierarchies – this has lead directly to inefficient, inelegant code with a more than a touch of the cut’n'pastes.

To his credit, my partner introduced unit-testing with SimpleTest quite early-on. To our detriment, we never grouped tests into test-suites, only ever running tests in isolation. With human-error at play we’d regularly introduce code that broke a test, and not notice till weeks later. It wasn’t long before we were so used to having broken tests around that on we’d actual revel in the rare occasion when a test went green again.

Stupid, stupid, stupid, stupid…

The way forward…?

Though I’m sorely tempted to throw our code out the window together with PHP, I’m driven by the hope step-by-step refactoring can lead us to safety, breathing new life into the code, and new momentum into the site – without the unavoidable stagnation a total rewrite-from-scratch would entail.

We have a ton of work ahead of us, and its hard deciding what to focus on first:

Unit Tests
  • remove/update outdated tests
  • fix failing tests
  • organize into suites and then into a one-click “run all tests”
  • integrate “run all tests” into the build process: no pass, no deploy
  • general tuning (setting caching and buffer sizes)
  • query optimizations (using High Performance MySQL [])
  • finish class design using ActiveRecord / ActiveObject
  • solve bottlenecks with caching (where possible)
  • simplify/rewrite semantic HTML
  • break-up & organize CSS

That’s simply a list of things to refactor and fix, excluding all the new things we want to do (total front-end redesign, better ajax, more features…)

I’ve no doubt this is going to be a slow and painful process, but I’m hopeful the end results will be worth it. It’s been said that the only way to understand something is to try and explain it (hence this waffling preamble) – I’m planning to write follow-up articles as we go along, sharing the best-practices we discover, as well as pitfalls to avoid.

Please excuse me, I have some work to do.

Leave the first comment

Google: Where art thou time conversion?

I love the fact you can use Google to perform basic calculations and conversions.

Once you know your currency codes, currency conversion couldn’t be simpler: 100 USD in GBP

And Maths? As well as your basic arithmetic operators, it also handles has pretty natural syntax for “to the power of”. e.g. (2143/22) ^ (1/4). Trigonometry function use radians, so it also lets you use PI as a constant: sin(PI/6)

They’ve even got a (really) nice way of handling percentages – you can even keep your commas and currencies in place – so calculating VAT is as simple as £4,399.99 * 17.5% (Note: I switched to the UK site for that one… If you run it on the answer automatically gets converted to US dollars! Of course, they let you override that by adding ” in GBP” to the query string.)

You can do weight conversions, distances, storage capacity… the list goes on.

So how come they don’t do time conversion? I don’t mean minutes into days, I mean converting one time zone into another.

I’m looking forward to reading about Apple’s new Macbooks, and I know there’s a conference at 10AM Pacific Time, or 1PM Eastern Time… but I don’t know what time that is where I am. I’m gutted Google can’t handle 10AM PST IN GMT.

Oh well… I guess I’ll just have to wait.

Update: I’ve just discovered Google’s things-to-do page (UK only?) Amongst other things, it explains how to get the current time for any location: simply prefix the place-name with “time ” – e.g. time london. That may be helpful if you know your geography? Personally, I’ve no idea which cities are in PST, and I’d only be guessing that maybe New York is in EST? (Google says EDT for New York – is it daylight savings time at the moment?)

One comment so far, add another

Bloody hosting providers

Choosing a hosting provider can be a difficult process, especially when you’re on a budget.

I’m heavily involved with ewelike, a product information and price-comparison site that we’re slowly improving as we integrate more price and information feeds.

Of course you can’t actually see ewelike right now, as our hosting provider‘s been trying to commit hari kari for the last 3 days.

On-demand computing? Not quite.

Update: 2008-09-01 ewelike came back to life on Friday night. Aside from some recoverable table-corruption, I think we’ve emerged relatively unscathed – and possibly a little bit wiser.

Decisions on a shoe-string

We didn’t have the option of cloud-computing when we started, and we definitely didn’t have the venture capital to buy our own hardware. Our choice was between shared-hosting and private-servers.

We chose shared-hosting with dreamhost. Compared to service providers in England, dreamhost offered an enticing package with plenty of storage and bandwidth included. We’d got a good feel about them as we knew plenty of designers, developers and bloggers that used or recommended them.

Setup was simple, and we were pleasantly surprised by the freedom offered for a shared-hosting platform – they even allowed users to install custom-compiled copies of PHP to run on.

Sadly, we suffered a few reliability issues, and we never had any guarantee of performance. Once our database started to grow and performance dropped, we realized we need to look around at someone else (at this point, we’d had too many reliability issues to give dreamhost’s private servers a go.)

There were so many options for private-servers that we suffered a touch of analysis-paralysis. Should we rent or buy? Build our own server, or let someone else do it? Which flavor of Linux should we go for?

And then cloud-computing took off.

Cloud computing

After looking at various grid services, we narrowed our options to Amazon’s Elastic Compute Cloud and Flexiscale. Running a price-comparison site using Amazon’s platform just felt wrong – including Amazon is price-comparison is almost mandatory, but storing their competitor’s prices, product images and information within Amazon’s data-centers? That’s just weird.

The FlexiScale service is provided by xcalibre, a UK-based company I use to host the hexmen site, run by a team I’ve found supportive and responsive in the past. The most enticing things about FlexiScale were fast setup times, low startup costs, and simple methods for improving (virtual) server performance – with straight-forward billing costs.

We’ve been running on a Flexiscale for a few months without any problems. Until a few days ago.

Your risk or mine?

When Amazon’s EC2 service had an outage earlier this year, I asked a friend “would you rather deal with regular outages yourself, or put-up with occasional problems completely out of your control?”

We’d been thinking about hosting something ourselves: our own PCs in our own homes, using our own broadband connections. The hardware would probably be the most reliable piece of the puzzle, and the broadband the least. In fact, we worked on the assumption that we’d probably be missing for an hour or so every week, with the occasional issue where we’d be gone for a few hours (and ranting down the phone at our ISP.)

The risks of home-hosting seemed too great. Much better to go with a professional outfit with monitoring and procedures in place to resolve the inevitable problems as quickly and painlessly as possible.


Ewelike’s been down 3 days now. Three days! I know we’ve still got a lot of work to do to build-up traffic and a loyal user-base, and that’s probably a saving grace at this point. I’d hate to be clock-watching thinking “that’s another thousand pounds lost… And another…”.

I’m going to crawl off and figure out how to handle fail-over in future. Do we need to go so far as having the app ready to run on two different clouds? Would we be paranoid enough to have primary and secondary name-servers pointing to different services, just in-case one goes down?

It’s time to stop wallowing and crack on with things – but first I’ll get my English on and make a nice cup of tea. That’ll fix it.

3 comments so far, add yours

Getting git to work on OS X Tiger

If you haven’t heard of git yet, it’s quickly becoming the preferred version-control system for tons of open-source projects, including the twin suns of ruby on rails and prototype.

In fact, if you keep your eye on the github blog you’ll see a steady stream of well-known projects moving over to git, as diverse as the Blueprint CSS framework and the Haskell compiler.

Basically, if git was a stock-market commodity, analysts would be issuing strong buy recommendations left, right and centre. Git’s tipping-point has arrived.

How to play

If you’ve arrived here via search-engine, it’s probably because you’re trying to work around errors like Can’t locate or Can’t locate SVN/ Read on…

I already had macports installed, but if you haven’t, follow the macports install instructions – we’ll be using macports to download and install git as it’s supposed to be simpler than building from source.

If you’ve had macports installed a while, make sure it’s up to date:

$ sudo port selfupdate

We want to use git to connect to subversion repositories as well, so we’ll just check that’s possible:

$ port list variant:svn
git-core        @1.6.0  devel/git-core
subversion      @1.5.1  devel/subversion

I already had subversion installed but through trial-and-error found I needed to reinstall it with perl-bindings (git must be using perl scripts to talk to subversion…) Note: I’m using the -f flag to force it to reinstall, you might want to try without first, just to see what conflicts it brings up:

$ sudo port uninstall -f subversion-perlbindings
$ sudo port install -f subversion-perlbindings

Next, we install git:

# This may take a while to install with all its dependencies:
$ sudo port install git-core +svn

And finally, we check it works:

$ mkdir myproject; cd myproject;

# Check your PATH's set properly, this should output:
# fatal: Not a git repository
$ git svn

# If that's OK... clone a repository:
$ git svn clone

Can’t locate

If you’re getting Can’t locate or Can’t locate SVN/ you should immediately try:

$ PATH=/opt/local/bin:$PATH git svn

If that works, you know it’s just a PATH problem. It’s something to do with Apple’s perl install having slightly kooky ideas about where to store perl libraries.

If you’re still getting complaints about, you need to install the CPAN module – and we’re going to use the /opt/local/bin instance of cpan, to make sure things go in the right place for us:

$ sudo /opt/local/bin/cpan -i lib::Error

Cross your fingers, and try again:

$ PATH=/opt/local/bin:$PATH
$ git svn clone

If things are working, git will spend a while cloning the subversion repository by pulling out every single revision so you can have a complete set of revisions (including deltas), ready for you to refer to with lightning-speed regardless of internet connectivity. Which is nice.

4 comments so far, add yours

PHP Session Management (grievance 2)

Sometimes PHP surprises you with an easy-to-use feature, like sessions.

Sessions are quite easy to use in PHP. One call to @session_start(), and you have a magic global called $_SESSION to store data in; associated with the user using a cookie called PHPSESSID. PHP takes care of reading and writing the session data for you, and you think no more about it.


Time passes, and you haven’t given sessions another thought. Your site’s evolving, using more and more AJAX, and seems to be performing ‘OK’. But, there’s a niggling doubt that something’s not quite right.

For us, we realized something was wrong when we opened multiple search-results in separate windows. We could see the tabs were loading one by one, slowly.

I guess we should have paid more attention to start with. Our previous web development background revolved around enterprise-class application servers. Sessions just worked, no concurrency worries. If you happened to run into a race-condition, you worked around it using threading and locking facilities provided by the implementation language. It never occurred to us that PHP would be so different.

PHP, the way we’re running it (via mod_php) couldn’t be further from the application-server model if it tried. (By default) sessions are implemented using file-based storage, not held in shared memory ready for use by multiple threads.

Storing sessions in files means PHP has to take heavy-handed precautions against concurrent read/write access to the session – it locks the session file for the duration of a request.

The idea never occurred to us – that session management would block user-requests, stopping concurrent requests completing (think AJAX.) Fortunately the quick-fix solution is simple: call session_write_close() as soon as you’ve finished writing to the session. Depending how you use sessions, you may find a number of actions only need read-access to the session, in which case you may want to open and close the session together: @session_start(); session_write_close()

That’s the quick fix, but there are plenty of other options to explore to. A quick code-audit could identify a ton of actions, controllers and pages that simply don’t need session access at all. Now you know PHP locks the session file, you probably want to avoid calling session_start() unless absolutely necessary.

Secondly, PHP allows you to choose what type of session-management you use. You can use memcached either on its own, or with a database backing-store. You could use a MySQL back-end, or roll your own session management registered using session_set_save_handler. It’s really up to you.

Perhaps that’s the problem right there. All the session-management hooks are there because the default session management sucks. The simplicity of using sessions lulls you into a false sense of security, but make no mistake – sessions need to be handled with care if you’ve any hope of running a high-volume website.

Are your sessions managed properly?

Leave the first comment