In recent times I find it is rare that the BCS’s increasingly glossy publication, IT Now, contains anything of interest. Too often an article appears to be a modified version of a corporate marketing piece with the specifics of the company’s product removed so as to maintain the illusion of being editorial rather than advertorial. The result is even worse than an actual sales pitch since all substance is lost!

A recent special issue on open source software was especially disappointing. The articles were not the usual marketing speak, but they were still vague and anecdotal rather than informative and analytical. For example, an article entitled “Cracking the Desktop” fails to mention Firefox, one of the most successful open source desktop applications.¹ A case study of the challenges faced when deploying this faster and more secure alternative to older versions of IE to corporate desktops would have been informative, yet the article looks at the cost benefits of switching to OpenOffice, an obsolete technology compared to online office tools such as Google Docs.

“Can Open Source Be Secure?” also exemplified the lack of editorial rigour in IT Now. The phrase “Experts do not agree” should not be allowed without referencing at least two sources (i.e. the “experts” on either side of the argument) yet the article contains no citations at all. The label ‘Journalist hiding their own opinions…’ from http://www.tomscott.com/warnings/ should perhaps be applied here.

I have renewed my BCS membership for another year on the basis that my local branch and Specialist Groups provide some value. The new Academy of Computing project should be given a chance to demonstrate that it can be the UK’s Learned Society of Computer Science, but the chance of another copy of IT Now not going directly to my recycling bin is slim.

BCS members can participate in a discussion about the future of IT Now.

1. As of today, Mozilla reports 127 million downloads since 21st January 2010 versus 48 million OpenOffice.org download since 11th February 2010. [back]

It’s a great survey of what’s hot right now, but I don’t think that this is a particularly unique situation within IT—there are always new technologies pushing the boundaries of current thinking—what makes this moment different is that several core technologies are moving simultaneously. What potential for a confluence?

Recently there’s been a lot of discussion about programming languages at work and Python is receiving a lot of attention for many reasons. I’ve been a big fan of Python for a long time, and the more Perl I see out in the wild, the less I like it: “There’s More Than One Way To Do It” doesn’t scale.

Since it has been two years since I wrote any Python in anger, I am feeling a bit rusty, but this example came to my attention today that reinforced my belief in Python’s coolness. Conventional wisdom is that a programmer should abstract away the implementation from a published API so that are no downstream dependencies to manage if the underlying implementation changes. In a language like Java, this typically means making all object attributes private and providing public accessor methods¹.

In a large program this makes sense since setx(value) will perform additional operations such as validation behind the scenes. However, in a small program this involves writing huge amounts of boilerplate code that will have no benefit until the day the program reaches the size and importance where validating a value before setting the attribute becomes a useful. And even if you know in advance that accessor methods are going to be useful, they result in large amounts of unimportant code that future maintainers will need to read and understand.

The Python solution is typically elegant. In the beginning all public attributes are accessed directly: C.x = "foo" is more readable and quicker to type than C.setx("foo"). If you then decide that reading and writing to x needs to be controlled, then you write you accessor methods, define “x” as a property and Python ensures all those instances of C.x are handled using the correct accessor. Here’s an example from docs.python.org.

Class C(object):
    def __init__(self): self.__x = None
    def getx(self): return self._x
    def setx(self, value): self._x = value
    def delx(self): del self._x
    x = property(getx, setx, delx, "I'm the 'x' property.")


1. aka “getters” and “setters” since reading a variable is usually accomplished using getx() and updating a variable is often called setx(value) [back]

With a single bound it was free!

My book on Security Engineering is now available online for free download here.

Professor Anderson’s book is an invaluable reference guide for anyone wishing to implement “secure” computer systems, or simply gain a better understanding of the field. This is great news.

An example:

p = proc do |x|
       print "Hello ",x ,"\n"
    end
p.call "Fred!"

p = lambda x:
         print "Hello ", x
p("Fred!")

Ruby’s pure object syntax leads to the ugly p.call ... while Python’s p("...") looks pleasing to the imperative and functional camps. Object-orientation is a great paradigm, but as anyone who has tried to “knock-up” a quick program in Java will know, trying to shoe horn objects into a small program is a waste of effort.

The paper concludes:

Overall there is not much different between Ruby and Python, though Ruby offers some cleaner syntax due to its object oriented model. [...] The disadvantage of Ruby is the fact that it is very poorly documented. Our advice is that you choose Ruby, if you are new to both the languages, otherwise weigh the option of continuing with language you are using.

So, in other words, Ruby has little to offer over Python except its theoretically purer syntax, and at the same time it is poorly documented which is likely to mean that the learning curve is a steep and painful climb. My advice: choose Python [1].

[1] This discussion has been entirely free of Rails. I haven’t used it and the paper I am responding to here doesn’t mention it—but I hear it’s a strong contender in the web app arena.

The two most obvious problems that inflict laser pointing users are that:

1. it causes the speaker to turn their back to his/her audience so they can point at the screen;
2. a bright spot whizzing around the screen in a random manner is very distracting.

I think a more fundamental problem is that the ability to point at one’s slides also encourages the speaker to talk to the slides rather than using them as a visual aid supporting one’s talk.

The final word count was 42,776. Many thanks to everyone who proof-read chapters for me!

TODO items can then be marked up in the text as:
\todo{Add a reference here.}

[1] Don’t get me started on Powerpoint — producing anything with more than one mathematical formula is as annoying as positioning graphics in a LaTeX slide.