I thought, “No problem, I’ll just look at the IP and block that IP”. Unfortunately, each of the messages was somehow coming from a different IP! Perhaps they were being generated from a network of spambots, or perhaps a lot of people suddenly hate me. Regardless, I wanted it to stop.

This is when I came across the free Akismet WordPress plugin. You can of course read about it at the official website or at Wikipedia. But what you really need to know is:

1. It does a great job at marking comments as spam in a similar manner to GMail. Anything mis-categorized can be unmarked as spam and the filters supposedly get smarter.
2. It is automatically included (but deactivated by default) with WordPress for all WordPress versions since 2.0.

Installing

1. All you need to do is goto Admin, click on Plugins, find Akismet, and click on Activate.
2. After the plugin is activated, click on edit.
3. There will be a box asking for your API Key, with a link on top which you can click on to get your new API key.  Click the link.
4. You are taken to the Akismet website, where they ask you for your email address and username.   Follow the listed steps, and await an email.
5. Read the email, click on the link to verify your email address.
6. Take the provided API Key and copy it into the box from step 3.
7. Rejoice in the lack of spam!

Checking for Mis-categorized Messages

1. Login to Admin.
2. Click on Comments.
3. Choose the Spam category.
4. If you see a mis-categorized message, hover over the content and click on Not Spam.

Group #1 – “Whats the point? Why do you need your application to look good?”

Group #2 – “Cramming in more features and functionality is more important.”

Group #3 – “The interface is the functionality”

Rebuttal for Group #1:

Let us look at the monumental success of the iPhone. It lacks many things including multitasking and until recently cut and paste! Yet despite these deficiencies the iPhone quickly gained an ever-growing religious following.

This enthusiasm has spilled over into the iPad domain. To me the device is highly crippled relative to the tablet PC’s I played with over 8 years ago. Yet Apple has apparently managed to sell one-hundred and twenty thousand units in one day with 99% of those orders coming from those that have never touched the device.

How is all of this possible? It is because despite missing functionality, the iPhone has a fluid, simple to use, aesthetically beautiful interface. People expect the same from the iPad, so they flock to it.

Rebuttal for Group #2:

What people in this group may forget is that the aesthetic value of a product may have a huge impact on usability and functionality. If someone can’t find your feature, they certainly aren’t going to use it no matter how great it is. Now imagine a text editor that perfectly corrects your grammar, spelling, etc., 100% of the time. If the interface consists of dark navy blue text on a black background, it will be very difficult to see and therefore people aren’t going to use this feature for very long. Present 80% of the functionality with a fluid interface and it shall be used. Again, drawing from the example of the iPhone, less functionality presented in a easy to use and fluid interface will be appreciated more than insane functionality that is impossible to use.

Koodos for Group #3:

Being a member of this group I am obviously biased, but I am perplexed as to why more people don’t belong to this group. Creating scalable, efficient, flowing beautiful interfaces requires a great deal of technical skill. One must choose the best design patterns to separate the interface from the logic, select the best data structures and protocols for efficient data lookup and retrieval, and implement the right algorithms to provide a smoother interface.

Compare the stock Android UI with the much smoother HTC Sense interface. Despite having the same or lesser hardware, most people find the HTC Sense interface to be superior. Put on a custom firmware and even the stock HTC Sense is beaten. This is made possible because of better algorithm selection, quality design, and artful development.

To support rich interfaces in the web 2.0+ era, HTML, CSS and JavaScript all need to interact with each other in a world of slow JavaScript interpreters and incompatible browsers. The success of toolkits such as Ext JS is testament to the talents of its developers. The toolkit has a well designed API making it easy to integrate with. And beneath that API is a collection of very efficiently written logic that achieves great performance across all browsers on all systems.

Conclusions

As software developers we should always keep the end user in mind. We should do what we can to become more aesthetically aware, and show pride in our polished interfaces. Our end users will thank us for it, and a happy customer is a repeat customer.

As the web continues its trend from static pages to rich interactive content and applications, the role of a software developer only grows.   As this movement continues, our need for becoming fluent with web-based debuggers is undoubtedly of the utmost importance.

For those of you unfortunate enough to work in the world of Internet Explorer, MS Script Editor or MS Visual Studio is probably your only tool of (mis)choice. To me it has been more like a blunt instrument than a precision tool.   It offers basic functionality but trying to use it beyond that it causes constant frustrations. Basic conditional breakpoints often crash Visual Studio, and more advanced conditional breakpoints refuse to be set. Stepping through code too fast occasionally freezes up Visual Studio 2005 through 2008 to the point only a task kill can shut it down.  In short, it has been a constant struggle for me to work with these MS based tools.

Which brings us to Firebug, the best JavaScript debugger that I know of. I’ve found Firebug to be a much a more powerful debugger than MS Visual Studio for a long time.  I could write dozens of blog entries about this ever-evolving debugger of choice (and I plan to), but this article is meant to describe how to patch a randomly occurring bug in the current 1.5 release (at time of writing), using a fix recently provided in the upcoming 1.6 release.

The Bug

I have used firebug for a long time, but I never came across this bug until I started work at NexJ. Their software applications offer amazingly advanced functionality, which of course requires more advanced coding. And with this advanced coding comes:

1. More JavaScript Files
2. Larger JavaScript Files

With these two ingredients, the debugger script view will randomly:

1. Cut off the display of certain JavaScript  files at random line numbers.
2. Make certain breakpoints no longer fire after random line numbers
3. Make breakpoints repeat themselves on refresh, while referring to “undefined” functions.

I’ve kept in contact with some of the developers on the IRC and have been tracking the bug. Thankfully it appears a fix was committed to the upcoming 1.6 branch.  I’ve modified the patch slightly to apply to the 1.5 branch, and it has solved all of the above beautifully.

The Fix

The patch is very simple.

Step 1) Open up firebugs tabPanel.js file.

C:\Documents and Settings\YOUR.PROFILE.NAME\ApplicationData\Mozilla\Firefox\
      Profiles\RANDOMSTUFF.default\extensions\firebug@software.joehewitt.com\
      content\firebug\tabCache.js

C:\Users\PROFILE.NAME\AppData\Roaming\Mozilla\Firefox\Profiles\
      RANDOMSTUFF.default\extensions\firebug@software.joehewitt.com\
      content\firebug\tabCache.js

/home/LOGIN_NAME/.mozilla/firefox/RANDOMSTUFF.default/extensions/
      firebug@software.joehewitt.com/content/firebug/tabCache.js

Step 2) Find the line similar to:

sink.init(true, true, 0, 0, null);

sink.init(false, false, 0x20000, 0x4000, null);

Step 3) Directly after this line add:

newListener.wrappedJSObject.inputStream = sink.inputStream;

Step 4) Save the file, kill all instances of Firefox, and restart Firefox. All fixed!

The original patch can be found here,  but is based on the 1.6 branch which is likely different than what you are running at the time of this post.

Explanation:

The problem was that the reference to the input stream was lost and was randomly collected by the JS garbage collector. This is why the bug is random and more prevalent on some machines (probably with lower memory conditions at the time), and why it was more likely to occur with more and larger files (allowing greater opportunity for the garbage collector to get in the way).

The good news is this problem will no longer require a manual patch once the 1.6 branch becomes an official release.

Let me know how this works for all of you, and happy debugging!

Putting my old phone through the wash was probably the best mistake I ever made, for it brought me to the HTC Hero, the Android operating system, and with it, mobile computing. Since then I have gone from thinking of smart phones as a luxury device to an essential part of every day.  It has largely replaced my eee pc as a way of making use of the daily public transit commute dead time.

In the process I’ve grown a new passion for the possibilities of mobile computing. I’ve come to believe this will be the basis for a slew of innovative ways for us all to connect and share our lives.  Being the eager software developer I am, I’ve read through much of the Android developer documentation, and hope to find the time to develop some kick-ass applications for others to enjoy.