Tim Hardy

David MacIver drew my attention to Chickenfoot today: “a Firefox extension that puts a programming environment in the browser’s sidebar so you can write scripts to manipulate web pages and automate web browsing.” It sounds like a slightly better Greasemonkey (although I must admit I haven’t touched Greasemonkey for a long time and it has no doubt changed since then.)

Being unable to install it was the final straw in making me decide to upgrade firefox. I’ve been running the default debian version out of a combination of laziness and paranoia about security but in the last few months I’ve really began to notice how out of date it is. More and more sites have been crashing my browswer. Fewer and fewer extensions have been working. But like the proverbial frog in the pan of boiling water, I have noticed all this happening but failed to jump out.

Turns out it was very simple to do. I just added backports my /etc/apt/sources.list

deb http://www.backports.org/debian sarge-backports main

then

apt-get update && apt-get install firefox -t sarge-backports

Now I’m finally able to install Chickenfoot but I haven’t played with it yet because I’m catching up on the 1000+ unread posts in bloglines that I haven’t been able to read for months since the sites last upgrade made it crash my browser.

Starting with Bjarne Stroustrup’s observation “our civilization runs on software”, Grady Booch offered a thought provoking overview of the history and promise of software at this year’s BCS Turing lecture, taking listeners from the austere beauty of Alan Turing’s 1930s thought experiments through to “the rise of the machines” in 2030.

Booch is an interesting, relaxed and witty speaker, whose asides on the superiority of OS X to Windows, George Bush and Google (”Am I the only one who thinks there’s a company in desperate need of some adult supervision?”) provided comic relief in an at times informationally dense speech.

One point that intrigued me was his observation that much of the history of computing is unrecorded, existing only in the “tribal memory” of the greybeards. He foresees the emergence of both software artists and historians who might translate and record some of the strange beauty of code for non-programmers as well as formally archiving a form of communication in danger of vanishing with the death of its authors.

The full lecture is available as a recording from the link below and is well worth watching.

Now anyone with $2400 (£1200) can build a machine at home capable of generating 3D objects from plastics.

Hod Lipson from Carnegie Mellon and PhD student Evan Malone have developed a desktop fabricator as detailed in this week’s New Scientist: Desktop fabricator may kick-start home revolution.

The developers define fabbing on the project’s main page:

Fabbers (a.k.a 3D Printers or rapid prototyping machines) are a relatively new form of manufacturing that builds 3D objects by carefully depositing materials drop by drop, layer by layer. Slowly but surely, with the right set of materials and a geometric blueprint, you can fabricate complex objects that would normally take special resources, tools and skills if produced using conventional manufacturing techniques.

The design is open source enabling anyone to download the blueprints and build their own.

I’ve been fascinated by the potential of home fabrication ever since I read Neil Gershenfeld’s Fab: The Coming Revolution on Your Desktop - From Personal Computers to Personal Fabrication a couple of years ago. It’s coming out in paperback in the UK early February and offers an inspiring if slightly breathless tour of the potential of giving the power of manufacturing to people. If you enjoyed Thomas Friedman’s The World is Flat you may well like this too.

Bulldog broadband have no instructions on their site on how to switch off voicemail. The keypresses you need are:

*1571# = Activate voicemail
#1571# = Disable voicemail
*#1571# = hear voicemail status (i.e is it on or off)

A few extracts from a great two-part interview with Bjarne Stroustrup: Technology Review: The Problem with Programming,
More Trouble with Programming.

On over-abstraction:

Software developers have neutralized the astounding performance of modern computer hardware by adding layer upon layer of overelaborate [software] abstractions. We seem to have hit the limits of linear speedup for hardware, but in many cases, we could win a couple of orders of magnitude back from the software.

On “the next big thing”:

I don’t know what the next major conceptual shift will be, but I bet that it will somehow be related to the management of concurrency. As programmers, we have been notoriously bad at thinking about lots of things happening simultaneously, and soon our everyday computers will have 32 cores.

On .NET and the JRE:

I want my software to run everywhere it makes sense to run it. I also want to be able to change suppliers of parts of my system if the suppliers are not the best. Obviously, suppliers of huge integrated systems, such as .Net and Java, see things differently. Their claim is that what they provide is worth more to users than independence. Sometimes they are right, and of course some degree of integration is necessary: you cannot write a complete application of any realistic size without introducing some system dependencies. The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to “the outer world,” and then integrated through a thin layer of interface code.

Well worth the read.

Over 90% of email is now junk mail according to a recent BCS article.

Not only are spam volumes increasing, but junk messages are proving harder to filter. Some spam buries its message in images to prevent filtering on content. To reduce the number of these in your inbox, quarantine messages with headers containing “Content-Type: multipart/related” but check your quarantine folder regularly for false positives.

Others send spam for you to a third party and forge the sender’s address so that it appears to have come from you. This technique is known as backscatter. If you keep receiving messages with the header “Undelivered Mail return to sender” about emails you never sent then you may be the victim of this technique. Quaranting messages containing “Action: failed”, “Delivery Status Notification (Failure)” and/or with the subject containing “Undeliverable” will help reduce the volume of these although again this risks filtering off genuine messages alerting you to a failed delivery.

I’ve just started testing greylisting on my email. Email from unknown senders is temporarily bounced back: legitimate mail clients will try again later; spammers either will not try again or hopefully will have been added to a blacklist by the time they do so. Known senders are added to a whitelist and automatically bypass the greylist filter.

Mailsnare offer server-side greylisting. However, I have been disappointed with their service levels recently and am not sure how strongly I would recommend them.

I’ve noticed a plague of “Undelivered Mail return to sender” messages recently in my inbox - all of them spam. Friends with their own domain names have reported the same.

Clearly conventional spam filters are working too well and the vermin who make a living out of unsolicited junk mail are changing their tactics.

Now instead of spamming the victim direct, they forge the headers of their messages so that it appears to come from the person they wish to spam, send it to a non-existent account elsewhere and let the second account bounce it back to their real target.

This level of indirection helps it get through the victim’s spam filters.

If you have received email pitches about dubious stocks that are “about to take off” from this domain please rest assured that they do not originate with me.

Edit: For advice on tackling this problem, please read the following post on using greylisting.

My father told me an anecdote about a patient who, while clearly very ill, showed a baffling lack of symptoms. To the first doctor he claimed everything was perfectly normal. To the second, he claimed that he’d noticed no change to his normal daily routine. It wasn’t until a the third doctor to see him asked him to step through a “normal” day that a missing key symptom became apparent: “The alarm goes off at 7.30, I get out of bed, go to the bathroom, throw up…”

This isn’t meant as an argument for using debuggers when coding but rather a warning always to challenge assumptions and to fix problems when they occur. Routine blinds us to everything. This can be a blessing in day-to-day living but it’s a curse when problems cascade and the root cause is obscured by habit.

If there’s an error in your java code, Eclipse sticks a marker in the gutter with a light-bulb icon. Clicking on the marker or pressing Ctl+1 with the cursor in the offending line brings up a helpful pop-up of suggested fixes for the problem.

I’ve always assumed that this was called Quick Fix. If you right click on the marker, the option is labelled Quick Fix. However, after struggling for a long while to understand why some Quick Fix code I wrote wasn’t showing up in this menu, I’ve come to the conclusion that this is actually Quick Assist and that the label is wrong (I’ve flagged this as a bug).

To launch Quick Fix you need instead to right click on a Warning/Error in the Problems View. Quick Fix and Quick Assist are in fact two different things with confusingly similar names and functionality.

Internally appropriate Quick Fixes are calculated by a class implementing IMarkerResolutionGenerator that extends org.eclipse.ui.ide.markerResolution. The fixes themselves are contained in classes implementing either IMarkerResolution or IMarkerResolution2. By contrast, Quick Assists are calculated by a class extending org.eclipse.jdt.ui.quickAssistProcessors and implement IQuickAssistProcessor. The classes containing the assists implement IJavaCompletionProposal.

So, if you’re developing a plug-in and cannot work out why your Quick Fixes are not showing up, take a closer look. Maybe like me you’re checking in the wrong place and what you meant to write was actually a Quick Assist.

I’ve been coding exclusively in Java for the last few weeks. However, when I needed to write a quick program to crunch some numbers the other day, I decided to write it in C++ for the change. Since I’ve also been working exclusively within Eclipse, I decided to use a simple text editor for this and gcc from the command line.

The experience made me reflect a little on the importance of good tools.

In Contributing to Eclipse, Kent Beck and Erich Gamma speak of the compiler moving from being a separate tool to “air - something vital that’s always around”. While using the JDT, the compiler is constantly running in the background, warning you of potential errors as you type each line of code. The IDE also makes suggestions for fixes that save much typing. In this collaborative model, the compiler/editor is like a helpful colleague looking over your shoulder and making gentle suggestions from time to time. By contrast, the model of finishing the code, trying to compile it and working through the often opaque error warnings thrown by a c++ compiler is more like facing a difficult interview. The rhythm of work is completely different.

Doug Schaefer, project lead for the Eclipse CDT, explains in this Callisto podcast (direct link to mp3) that the simplicity of Java makes the JDT experience possible but that it would be prohibitively expensive to do the same with CDT.

Another thing I missed was JUnit. At the moment, I frequently work outside my comfort zone, learning through discovery and error and unit testing gives me the confidence to do this and to refactor. The task at hand was so brief it wasn’t worth investing the time to explore the xUnit variants for C++ but I intend to do so the moment I need to write more substantial code in that language.