So starting today, you will be able to stay abreast of all new Wormly features and announcements by following the notification link shown within the Wormly console to this blog. Simple as that. Naturally you could add this feed to your reader as well.

And to celebrate we’ve just rolled out a new feature, keep reading the next post to learn about it!

Times are expressed in the timezone you’ve specified - the globally set zone or a host specific-one if available.

They’re shown in short form for the SMS & Short Email channels, e.g:
26/Aug 11:15

And long form for email and IM channels, e.g:
Tue, 26 Aug 2008 11:15:53 +1000

Feature Deployed @ 2008-08-26 02:00 GMT

“Even if you have a high quality ad, if advertisers below you are not bidding very much, your actual CPC may not be high enough to qualify your ad to appear in a top position.

With this new formula, instead of considering your actual CPC, we’ll consider your maximum CPC bid, which you control. This means that your ad’s eligibility to be promoted is no longer dependent on the bids of advertisers below you.“

This announcement indicates that Google remains keen to eliminate the long-tail approach to gaining cheap traffic, widely used by so-called (albeit misnamed) arbitrageurs in the SEM industry.

Until this change is implemented, advertisers can continue to place low quality ads in the top positions by bidding on keywords with little competition - generally lengthy, specific phrases.

Like most changes they make, this should be a win for Google and their users - higher prices for their ad inventory and / or better quality ads presented to the users.

Tags: google adwords, sem, arbitrage

14 hours - and counting. One can scarcely imagine the magnitude of the technical failure that causes such a lengthy outage.

Although Skype offers paid-for, business critical services including inbound geographic number routing and outbound PSTN dialling, they have long - and wisely - avoided any commitment to deliver emergency call services. And you can understand their reluctance to start now.

This event also highlights the challenge of keeping customers informed; a typical Skype user almost nevers dials www.skype.com into their browser, so how to get the word out about the outage and status updates?

Luckily (or not), many major media outlets are covering the issue more than adequately.

Fingers crossed for Skype’s engineers that they can effect a resolution soon.

Tags: downtime, outage, Skype, offline, PSTN

When enabled, you can place one of our funky uptime badges on your site showing uptime from the previous 24 hour, 7, or 30 day period. You can also link through to a detailed uptime report where visitors can examine your uptime history on a yearly, monthly, or daily basis.

Take a look at this example - and click to see the full report:

It’s a great way to show your customers that uptime is important to you - Could this transparency be your edge over the competition?

Tags: uptime monitoring, public reports, verify uptime, wormly, proof, embed, mashup

“I need a site to be programmed exactly similar or even better than wormly [dot] com. It is a website monitoring and uptime site. Please register for a free account and understand what it does exactly and then bid.

And I want it to be done in PHP and linux. And moreover it is going to be hosted on a shared hosting.“

We do of course wish them the best of luck - one can only be flattered by imitation, after all.

Tags: wormly, ripoff, rentacoder, uptime monitoring, web services

One of the more painful parts of that process has been testing the newly configured SMTP server before delegating the domain’s MX to it. This involves speaking SMTP through your telnet client, or re-configuring your mail client to speak directly with the new server, then un-re-configuring it.

Neither is a difficult task, of course, but it’s a solid 30 seconds (minimum) that I’d rather not spend.

So I whipped up a handy little SMTP test tool, which does the SMTP-speak for you, and renders the whole conversation in your browser via an IFRAME.

Neat, handy, and of course free. Try it out.

Tags: SMTP, mail server, MX, SMTP server, testing, test tools, Exchange, qmail, sendmail

I don’t subscribe to many podcasts - I’m definitely in the casual listener category - but those that I follow are podcasts which focus on a very narrow, targeted niche. Mitch’s show definitely fits the bill, and his focus on the hosting industry offers listeners a lot of value. Nice work, Mitch!

Listening to our short interview, one thing that does strike me is just how varied the English language is. Despite my best efforts to slow down, my rapid-Australian-speak contrasted quite drastically with Mitch’s slow and measured twang. Keeps thing interesting!

But this morning I finally switched the last one off, and a slightly eerie silence descended on my home office. My new laptop, with the help of VMWare, is more than capable of wearing all the software development hats, and I’ve jettisoned all local email hosting because Google can do it better.

VMWare is the facilitator - I’ve always preferred to use Windows on my desktop, and use GNU/Linux in the server environment. Virtualization makes it extremely easy to have all the operating systems you need on a single machine.

Quiet - and Greener

Compared to my desktop, my laptop is whisper quiet. That’s a nice bonus - No more buzzing and whirring 24×7, something I was so accustomed to that I didn’t even notice it until it ceased to exist.

One of the most obvious advantages is the electricity savings - something that in these intervening 10 years has moved from being a non-issue, to being at the forefront of server management and highly visible everywhere in the face of carbon emissions - and the reduction thereof.

So it feels good to have just one PC at home - a laptop - that gets switched off when not in use. It’s an improvement, although my green credentials still need work given the redundancy built into our uptime monitoring network.

The other obvious advantage is having full access to my development environment whilst I’m on the road. I have quite a number of travel comittments this year, so I expect to make good use of that capability.

The final benefit is the ease of producing backups. The full virtual machine sits in a tidy 8GB disk image, and a backup snapshot becomes as simple as shutting the VM down and copying the file that contains it.

Fewer Points of Failure

Considering backups raises an interesting point - the less hardware that is in use, the smaller your chance of hardware failure. Consider how much time it takes you to rebuild a server even if you had a great backup regime, and virtual servers become much more appealing. If my host laptop fails, getting my servers back up should be as simple of copying a handful of files and reinstalling VMWare.

What will the tomorrow’s data centers hold? One enormously powerful grid computing appliance, containing 1000s of virtual servers? The idea of combining hundreds of physical servers into a single computer, to then run hundreds of virtual servers on it does seem a little strange, I’ll admit.

Update: Further reading on this concept at SitePoint.

Tags: virtualization, vmware, server, windows, linux, uptime, electricity, energy, data center, web server, LAMP

Crucially, the variance in this example is caused by the application response time, rather than the network. That’s the blue Exec component, not TCP or Transfer components.

Variance-of-latency isn’t a huge problem with traditional page-refresh-response websites and applications, but certainly does present an annoyance to your users. When your app starts to get cleverer and offers AJAX goodies, however, the problem becomes more serious.

Sometimes, your user clicks repeatedly in futility, wondering what’s going on and why she is getting no response. Other times she’s not sure if anything is working at all.

So our Happy User rapidly becomes a Sad User. Click… wait… wait. She’s not feeling so empowered by your application at this point.

A more problematic scenario is that out of sequence AJAX responses will break your UI. Many developers using mainstream (read: simple to deploy) libraries fail to code precautions against this.

And it’s easy to see why: By now, most AJAX-happy developers are aware of latency issues, and latency is quite simple to emulate in a test environment.

Variability-of-latency is not getting enough airtime – most likely because few people are actually measuring it as a part of their build process.

It’s not the network.
Raise the issue with the developers and they will probably start a delightful discourse on the “best-effort” nature of internet pipelines, asymmetric routing, and similar vagaries of internet infrastructure. The implication being that the user is at fault because they chose to use your app from a free wifi hotspot in Turkmenistan.

Our graph above, however, shows that the fault lies squarely with the application being unable to offer consistent response times. HTTP network overhead is just a tiny fraction of the total – and runs at a consistent 89ms anyway.

The lesson is: Fully understand your application performance and work to improve its consistency, particularly during peak periods. The underlying network is rarely to blame.

Tags: latency, AJAX, HTTP, user interface, web 2.0, speed, performance, website, application