jQuery.com - Those Mouse-over Tooltips are BAD

jQuery is a good thing. It allows you to minimise the amount of Javascript you write, while maintaining elegance and ease-of-use. jQuery.com has recently relaunched with a brand-new design. Feedback from around the web was initially quite negative due to a bizarre decision by someone who thought it’d be great to apply a ‘rockstar’ ethos to the whole redesign. The new landing page initially had a horribly misplaced drawing of a rockstaresque character splattered across the majority of the screen. It was nothing short of embarassing really. It screamed of teenage identity crisis.

Kudos to jquery.com though, who listened to their critics and removed the image. Right now, the site’s looking cool but still a little out of place. This is a Javascript library, not a corporate website. Anyhow, I digress.

Another element of the homepage that thoroughly annoys me is the tooltips on the three links titled “Lightweight footprint”, “CSS 3 compliant” and “Cross-browser”. To me, Web-2.0 (I’m sorry for using that phrase) style UI elements are largely about usability and common sense. jQuery seems to be an embodiment of that, and allows developers to enhance their sites greatly with a small amount of effort.

Shocked and awed I was then, when I moved my mouse around the page while reading only to find these terribly intrusive ‘tooltips’ that show when you hover over the aforementioned links. Right out of how-not-to-do-widgets-school it seems. Those elements on the page go against the original intentions behind underlining text (denoting a hypertext link). Not only are the tooltips pointless, but as widgets they’re very annoying to use. Hovering over them can sometimes show another (unrelated), as well as them hiding text around them - forcing the user to have to move their mouse again, only to find that they’ve set off yet another tooltip. They’re too large, unnecessary and bad-practice.

Whilst I can see the usefulness of such a plugin, I think it’s a perfect example of how not to do it. I can’t sleep at night because it annoys me so much.

Seriously!

Server Benchmarking Diary - Debian, Apache 2 and MySQL

This blog took nearly 7 thousand hits yesterday. At its peak, it took 1.8 thousand an hour. That’s a decent amount of traffic. This was all brought about when I submitted a link to reddit.com regarding a way to crash Google Chrome instantly. Coincidentally, I had spent an hour or so the night before testing the stability of my Slicehost Xen virtual machine (more info here) just out of curiosity. I was using wget, ab (Apache benchmarking tool) and htop to mirror, send concurrent requests and monitor respectively. I’m going to document my findings here.

What I’m Running

Here’s a rundown of what sites I’m running and the software used.

Wget - the Swiss army knife of HTTP command line tools

Wget’s one of those tools you really take for granted. It’s versatile, reliable, simple and most importantly - it does its job very well. One of its nicest features is the –mirror option. This allows you to…mirror a given website. I initially thought of running multiple instances of wget at the same time. I started small at first: one instance running to mirror the entire site. I ran the following in a shell:

alex@prometheus:/tmp$ wget –mirror beplacid.net/

It’s simple: mirror beplacid.net. Watching the processes and CPU usage on the server, it became apparent that  this wasn’t going to do much. The CPU usage didn’t exceed 5% on its first core. I had to rethink. Then ab sprung to mind.

ab - Apache benchmarking tool

This is another useful tool. It’s simple to use and allows you to quickly and easily hit a given hostname with HTTP requests, all tailored to your specific needs. To do all this, however, you need to be running as root. A noble security measure.

I wanted to generate some traffic that would put the server under some strain, so I started with 50 requests and 5 at a time:

prometheus:/root$ ab -n 50 -c 5 beplacid.net/

Now things started to get fun. This peaked CPU usage to 94% on one core, the others were between 60 and 80. I was starting to see some real stats. I doubled things - 100 with 10 per request:

 prometheus:/root$ ab -n 100 -c 10 beplacid.net/

This was a little more representative of a heavy amount of traffic. Perhaps akin to slashdot or a reddit. Put simply, that’s 100 requests with 10 each sent each time. Still nothing major, so I went all out:

Concurrency Level:      10
Complete requests: 1000
Total transferred:      4856792 bytes
HTML transferred:       4687792 bytes
Requests per second:    4.99 [#/sec] (mean)
Time per request:       2002.453 [ms] (mean)
Time per request:       200.245 [ms] (mean, across all concurrent requests)
Transfer rate:          23.69 [Kbytes/sec] received

To summarise, the server took 1000 requests with an average of 5 per second, each returning just over 2 seconds. Not bad, considering what I’m running.

I’m pleased with my setup. It can take a punch and it’s still running. My next task is to hit both beplacid.net and the blog, with perhaps some traffic mirroring readingbeerfestival.org.uk too.

Tasty Google Chrome Bug - So Much For Isolated Tabs/Processes

Update: it seems this bug was already reported, but the amusement value seemed to escape most of the web.

The web’s abuzz with talk of Google’s new venture - Chrome. My workplace is no exception; in fact we’ve had numerous discussions about it, spanning from “should we support it” to adoption paths.

One of Chrome’s highlights is its isolated tabs. The idea is that tabs run as separate processes, so if one lags, the rest still operate correctly. Therefore, it was quite a surprise when a colleague emailed me with this nifty trick to crash Chrome:

 Type this into a Chrome tab’s address bar
:%

No need to press enter, it happens as soon as you hit %. Here’s a screenshot:

Google Chrome Crash

Again: so much for isolated tabs.

Note: I’ve submitted a bug report here

- atc

Google Maps - Random Finding

I saw this image linked on reddit. Not entirely sure what it is, but it sure looks like a missile:

View Larger Map

Nick Change - Placid to atc

I’ve given up on the nick ‘Placid’. Gonna use my initials ‘atc’ instead. Much cooler ;) The term ‘be placid’ remains, as I like it as a slogan/way of life.

Pyela - Python Eternal Lands APIs

Some time ago, I began hacking away at a simple API (Application Programming Interface) for Eternal Lands written in Python. I intended to write something that was quick and concise, and that would be easy to reuse. Using a typical OO approach, I finally came up with ‘Pyela - Python Eternal Lands API’.

Pyela is an object oriented (OO) API for communicating with an Eternal Lands server. It aims to be a simple wrapper for socket operations and messages that pertain to the undocumented Eternal Lands Network Protocol. A demonstration of the API is easy to see in the Pyela - GUI application, which is a Eternal Lands chat client written using Pyela. You can download that here.

Pyela is released under the GPL3 and is open to patches and any suggestions you may have and is hosted by Google code - pyela.googlecode.com.

Best Image Ever?

I found the following image while scouring the web one day. Has to be the funniest image manipulation I’ve seen in a long time…

Duck to Crocodile hybrid