FlipStorm » rants

Don’t Use Easyspace!

Simon — Tue, 12 Jan 2010 23:41:00 +0000

A friend recommended me to Easyspace (a web hosting company based in Glasgow, Scotland – part of the iomart group). Their prices looked good, they were UK based, and I could handle almost everything online…

My VPS has been running silky smooth ever since. It’s never been blindingly fast in terms of network speed… but I don’t need a huge pipe onto the net yet.

Problems started as work slowed towards the end of the 2009 and funds dried up. I didn’t even notice, but the December invoice didn’t get paid. I had no notice or warning. Because of the holidays, I left my accounting until the new year.

While I was off, I received an email (twice, on 29th December) stating that someone from Easyspace had tried to call me (I received no such call), but they needed me to call back to sort out a problem with payment. This email stated that my services “have lapsed”.

I checked that my server was still operational: it was. I checked my Easyspace Control Panel for recent, failed transactions requiring my attention: none. My assumption: their mistake.

As I came to do my accounts for December (a little later than normal), I noticed that no payment was taken at the beginning of December for Easyspace. Was I wrong to assume that this could have been an internal error? If you were a hosting company and a customer had failed to pay for your services, when would you contact them to sort it out?

While I was in my Easyspace Control Panel, I noticed that there was an invoice outstanding: dated 02/02/10… ”This must be the one they’re talking about,” I thought. I paid this invoice there and then online (even assigning it a special code of their choosing so they could flag it up on their accounts more easily).

I had acknowledgement of this payment and my service seemingly continued. My server showed up in my account; all was well.

Skip to today. For various reasons I don’t know from when my server went down, but it has now been down all day.

After two very calm and collected phone calls to Easyspace to sort this problem out, even paying the payments they had failed to take (December + January), and waiting very patiently (for now 11 hours from initial contact!) I am royally cheesed off.

So to recap: they didn’t warn me that my payments weren’t processed, the “warning” they did give was late and uninformative (it was an automated email after all), and even though I had attempted to comply to their wishes they still took my server offline (again without warning) and have so far yet to restore it, although all accounts are settled.

And to top it all, their automated telephone queuing service is rubbish. It simply rings and puts you straight into the queue; no “Thank you for calling Easyspace” to let you know you’ve called the correct number, just music until you hear the standard rotation message of “thank you for waiting”.

Therefore, I am now looking to move my web hosting needs to another provider. So if you have any suggestions, I would be welcome to hear them! Stick your referral links in the comments.

While this may be painful for me, this experience has taught me a few lessons:

If in doubt, speak to a person – despite how difficult they make it
Always have a backup server ready to take over
Don’t trust other organisations to do things the ideal way (no matter how easy it should be for them to implement)

Yet, despite all of this I am thankful for a couple of things:

At least this server wasn’t running anything too mission critical
Other important services (esp. email) are hosted elsewhere, e.g. Google
I don’t have to stay with Easyspace
I can go to bed without worrying or stressing because I’m so laid-back it’s not ruffling my feathers all that much, in the grand scheme of things

Rant over, Simon out.

Dawn Ascends! Ready Your Swords!

Simon — Mon, 21 Dec 2009 13:20:00 +0000

I absolutely love coding in PHP. Sometimes I get distracted by the glitz and glamour of some of the more popular languages (and their associated frameworks) – and I agree, they have their place. But PHP is in a class of its own.

The truth is that for years PHP has had an active community – and this continues to thrive. Because it’s so easy to get your hands on PHP, and get it installed, hosting is cheap, and there are no major licensing issues, uptake was fast.

The PHP site fast became the home of many PHP-related projects and spun off into package managers and extension managers (PEAR and PECL respectively). Literally thousands of developers write setup and “Hello World” tutorials. Loads of scripts and apps are open-source and open-licensed. No wonder it is the most popular language in use on the web!

However, we’re moving into a new age. A very competitive era dawns. PHP needs to stand up to the impending onslaught of faster compilers and VMs. The competition will be tough. But I believe PHP can hold its own.

As we move into this era of greater web app interconnectivity, PHP seems poised to reign strong. With a flock of transport layer extensions (think JSON, SOAP, XML-RPC) and authentication modules (OAuth, OpenID etc) at the ready, it looks pretty solid.

One thing stands at the gates, pleading nervously and gently as we give out our warcry: documentation, documentation, documentation. And for good measure… DOCUMENTATION!

The PHP site is littered with it. The community add to it. But when it comes to third-party tools, especially PEAR libraries and other third-party code, we’re pretty weak.

The area of most concern has to be client libraries for web service APIs. Some are just totally appalling: outdated, incorrect, poorly formatted or purely non-existent.

This is a bad show and something we need to improve upon desperately if PHP is to be the language of choice for web development in the next decade.

You might argue that it’s not going to disappear off the map. You may be right. But there’s no harm in making our lives easier and ensuring PHP’s safety and continued popularity by writing better documentation!

Come on chaps… for GLORY!

I Hate Google Ads

Simon — Mon, 02 Nov 2009 10:59:00 +0000

I officially hate Google Ads. Like me, you probably ignore them so easily. They’re the bane of a web designer’s life… and don’t even start talking about the UX!

The simple fact is they’re hated all round. But quite clearly they work otherwise Google wouldn’t be stinking rich (enough to offer a free GPS satellite navigation product). So who the heck is clicking on these stupid ads?

Well, I don’t care to be honest, because it’s getting to the point where I could do with a bit of the money that Google get. So unfortunately I’m bringing ads back to this blog I know, it’s a sad day. Rather than asking for donations (I’m certainly not doing anything worthy of donations), if you feel the urge to click on an ad, don’t quash it with your educated supremism – support a poor blogger and give in to the click. Thanks

Putting My DBA Hat On… Again

Simon — Tue, 06 Oct 2009 12:04:00 +0000

It’s not often I have to worry too much about the minutia of database administration… well, I try not to. But this question on StackOverflow got me intrigued, so I put on my trilby.

labratmatt was having a bit of a problem with inserting data into a MySQL table with field defined as DECIMAL(3,2). Can you guess what his problem was? That’s right…. 9.99! How did you guess?

This has got to be one of the most popular MySQL-related Google searches. The initial problem is easy to solve… correct the presumptuous field definition.

However, the underlying problem is really why his data was being truncated, even inserted incorrectly. You may notice the same if you run MySQL (v5.0+) from a default setup on other field types: VARCHAR for example, where you set a maximum field length. When you INSERT data that is too long it simply gets truncated.

Not hugely worrying you may think, especially in development and testing phases. True. But this wasn’t enough for me, so I went on a hunt.

I found this interesting article by Robin Schumacher on MySQL Data Integrity.

It seems that there is a configuration variable in MySQL (v5.0+) called ’sql_mode’ that determines exactly how strict MySQL should be when writing data to tables. The problem is that, by default, it’s unset, which means MySQL uses its standard mode… fudged SQL.

It has a vast array of options, so read through and choose wisely.

The default MySQL setup essentially turns all of your INSERT and UPDATE statements into INSERT/UPDATE IGNORE statements. It is an unexpected “gotcha” for many… any self-respecting software developer would want the INSERT query to fail and for the DBMS to tell you why it failed, not automatically munge the data for you.

To achieve this, the general option to use for ’sql_mode’ is STRICT_ALL_TABLES… but even this has some gotchas (VARCHAR and TEXT expect only string values etc…) and may need to be combined with other options.

Of course, if you write your programs to send MySQL the correct datatypes, changing this option shouldn’t cause any problems

The annoying thing is that I’ve only just found about this now after nearly 6 years of database development.

You followed, you RT’d, then you clicked the link

Simon — Thu, 01 Oct 2009 15:39:00 +0000

Well it turns out we want the same thing. And chances are neither of us is going to get it. So stop fretting about Google Wave and get on with some work.

Or if you really must procrastinate, watch my video from yesterday’s post

If It Ain’t Broke, Don’t Fix It

Simon — Mon, 10 Aug 2009 09:42:00 +0000

There have been literally dozens (if not hundreds) of articles on the latest CSS3 styling techniques that you can use right now to “enhance” your web designs. I have a problem with them.

(I found this one this morning and this roundup from the other week is also very good.)

Some of these articles openly state that there’s a good chance that you will find these new features unsupported by a number of browsers – most notably, of course, is Microsoft’s latest version of Internet Explorer as well as stable releases of Opera.

So my first problem is the lack of universal support for these shiny CSS styles. Why is this a problem? Chances are, in order to use some of the newer styles found in CSS3’s draft you will have to use vendor-specific code where those vendors apply the draft.

In order to achieve a fully backwards compatible design, your stylesheet(s) will need:

one set of instructions as a backup (for non-supporting browsers),
the current draft recommendation standards compliant code (for when it goes to official recommendation), and
each individual browser’s vendor-specific code.

All of that for each style. This results in a bloated stylesheet and to a smaller extent, breaking the DRY principal.

Then there’s the obvious differences in how the browser vendors interpret the draft recommendations from W3C and even in certain cases creating options that aren’t a part of the draft. It can be hard to see which way is the right way to go from a design point of view at this early stage, especially if you’re like me and you don’t want to have to come back and fix broken designs later on.

We’ve come a long way in web design. Thanks to standards support in browsers like Firefox and Safari, Internet Explorer and others have had to adapt quickly to keep up. And they have.

However we’re starting to tread over old ground. In the bygone eras of the web—when Netscape and Internet Explorer vied for supremacy—each had an array of browser-specific HTML. And we hated it. For example, if you wanted the benefit of layers in Netscape and you used it to the full, IE visitors were quietly asked to leave. Or you could hack around and find a solution that made your designs cross-browser.

That’s why the W3C took over the evolution of HTML and defining an open forum for standards. Those days should be over, but it seems we’re heading back down that old road.

The browser vendors will always put their own code in place, but it’s only when we use it in the mainstream that problems start to occur. Then we blame the vendors for dangling that chocolate-covered banana in front of us when things get out of hand.

I’m not saying you shouldn’t try all these new toys out, just go easy on the less well-supported ones. You’ll save yourself a lot of hassle down the line when everything changes again.

Remember: If it ain’t broke, don’t fix it!

The Problem With Twitter

Simon — Tue, 21 Jul 2009 23:17:00 +0000

An innocent prank? Not really. I think Ryan will not be pleased. It seems becoming even remotely popular on Twitter draws unnecessary attention from silly people.

Sad times. Perhaps I should only use Twitter-based apps that have successfully implemented OAuth

Progressive Ehancement, Graceful Degradation and Legacy Support

Simon — Thu, 30 Oct 2008 15:12:00 +0000

Are we still supporting browsers that have had their day? It seems the simple answer is “hell yes!” I ask why…

I stumbled across a website today consisting of one page prompting users to upgrade their browser. It offers the hope of a better user experience, but also notes that it would make developers’ and designers’ lives easier.

I know there are many arguments that exist for supporting all possible browsers on all possible platforms. I know there are services around (such as Litmus) that provide cross-browser, cross-platform testing. I know there are still a bevy of users out running older browsers.

However, my argument is that there are few enough of those that we as designers/developers can actually start to make them feel outcast. Not that we are trying to bully anyone into upgrading their browser – heck we’ve been so subservient up till now, our bluff would be called and we’d probably cry and run off.

The thing is that most users who are still sporting legacy software are running a machine too old to cope with a newer browser. That, or they’re insistent on using old, comfy browsers. In either case, supporting them is a burden we need not bear and definitely not a necessity.

I put forward that web sites (and other modern software) should be built to work on the latest and greatest… to a point. I concede that there is an acceptable grace period while we wait for the majority of users to upgrade, but if we make it clear that they should, then this process wouldn’t be quite so long. If the content doesn’t render quite right, then that’s their fault.

I appreciate that’s a little harsh. I would therefore like to put forward a proposal: an introduction of META tags for various user agents. Once you are happy that a site works well in a minimum browser version, insert the tag for that browser.

Browser vendors could then check for their User Agent meta tag and compare the version data and use this to perhaps prompt the user that they need to upgrade. I guess this is a bit like Adobe AIR and Microsoft’s proposals in IE8 (except none of this conditional comments crap).

Unfinished Business

Simon — Mon, 07 Jul 2008 23:21:00 +0000

I just wanted to write a quick post (as it’s late and my Mrs wants me to come to bed) about lingering jobs. We all have them. Washing up that’s starting to grow its own ecosystem, that lightswitch that’s still hanging off the wall (but it works!)…

For me it’s a plethora of oddjobs for old clients. In my case they come back for more, usually at the most inconvenient times. This time however it’s all my fault. In desperation I have offered to do work in the hopes that I will finally get these people off my back.

It’s not that they’re begging me to do things, but more for my own sanity. I guess I have some mild form of OCD. I just want things tidy. Is that so bad?

I find that eventually there are so many things on my mind that I can do none of them. So I suffer silently in a corner somewhere waiting for the light to come on. Ultimately it’s a crippling fear of failure that grips me most. Of course it is that very fear that breeds itself.

I’m sure you understand…

So follow my changing mental state on Twitter. You’ll catch some of my mini rants and you may even witness my entire nervous breakdown (reality TV eat your heart out!)

When “Can I…” or “I’m going to…” becomes “I want you to…”

Simon — Thu, 26 Jun 2008 18:10:00 +0000

Dear Audrie,

Today I have been mostly making “final tweaks” to a fairly simple project that I’ve been working on. It’s a content site with a Flash gallery.

It’s quite easy, but we’re not dealing directly with the client. We’re dealing with a go-between art studio who produced the design. They’ve basically done the whole rebranding and needed someone to put the site together.

This sounds great from a programmer’s point of view: No designing, just programming… more like this please.

There is a major problem with this though. The design studio tend to get their own “ideas” of how the copy should go and what goes where. All within their power? ‘Yes’ you might say.

However, it becomes a little silly when as the programmer you are providing a product to a client that allows them to update their website themselves and you end up making all the changes.

I’m not going to name drop because that may enlighten the client a little too much for the studio’s liking. It may also highlight how this particular studio stays in business.

I know this sounds like I’m just getting at the studio in question, but rather I’m trying to portray just how difficult a programmers life tends to be. You sign up for one thing and do 101 other tasks.

In my experience the following rules apply:

Is it possible to… means … Do that…

Can I… means … Do that…

I’m going to… means … Do that…

And so I find that instead of one person to answer to, I have hundreds all vying desperately for my time. And all increasing in their requests.

Why can’t people tell you all of the things that need doing and just let you get on with it? I much prefer that as opposed to this ‘do this and get back to me’ approach.

Ah well.

Until next time!