Getting started with Tellurium and Netbeans

One of the principal devs here had heard good things about Tellurium, a testing framework that sits on top of Selenium, so I decided to take a look. Unfortunately the “getting started” material is a bit vague at best and incomplete at worst so here is a quick checklist of the activities I had to go through to get Tellurium tests to pass on my Netbeans installation.

From http://code.google.com/p/aost/downloads/list get http://aost.googlecode.com/files/tellurium-core-0.6.0.jar
and http://aost.googlecode.com/files/tellurium-0.6.0-dependencies.zip

Extract these into a lib folder somewhere and replace the groovy version 1.6 file with the groovy-all-1.6.4.jar from http://groovy.codehaus.org/Download

Now follow the instructions at http://code.google.com/p/aost/wiki/CustomTelluriumNetBeansProject (but obviously make sure you include all the jars you downloaded, not just the ones listed).

Leave a Comment

On owning your .com domain name

Received wisdom on the web is that if you are running a business you should own the .com domain name or else you are doomed to being an also-ran.

So I was surprised to read The Sunday Telegraph Stella Magazine’s (8th March 2009 – yes it was a slow Sunday) article on “the great eccentrics of world fashion”. Some are listed alongside URLs:

Susie Bubble of http://stylebubble.typepad.com
Tavi Gevinson of http://tavi-thenewgirlintown.blogspot.com
Diana Pernet of http://ashadedviewonfashion.com
Yvan Rodic of http://facehunter.blogspot.com

Out of these four, only one runs the .com domain of their online presence. The others are content to let blogspot and typepad do the heavy lifting and are evidently happy to be associated with those domains.

And given that 99% of first time visitors to your location will get there by typing in the name  (e.g. facehunter) into Mr Google’s Guidebook, the .com-ness or not of the domain name becomes less relevant.

Google search for "facehunter"

Google search for "facehunter"

Not surprisingly, as with pretty much any .com name made up of two arbitrary words, facehunter.com is apparently owned by a domain squatting organisation. I presume this to be the case because (a) facehunter.com is just a list of links to adverts and (b) I’m struggling to see what other reason Rough Media can have for registering 2,000+ domains.

Google is wise to this: if you even do a search for “facehunter.com” you still get links to the “real” facehunter at http://facehunter.blogspot.com rather than the squatted domain.

Google search for "facehunter.com"

Google search for "facehunter.com"

Where is the benefit, these days, of having http://www.myname.com over http://myname.wordpress.com or  even http://www.twitter.com/myname? How long before having your own .com domain starts feeling rather stuffy, quaint and old-fashioned?

Comments (2)

My software is more intuitive than yours.

Some notes for those who are touting their software as intuitive/easy to use:

  1. It’s a relative concept. I was very excited in the mid 90’s to see how easy to use SAP R/3 was.  Compared to SAP R/2.
  2. Of course you think it’s intuitive. You wrote it.
  3. Things become intuitive once you’ve been trained to use them. I now find the Office 2007 ribbon intuitive, just as I find the location of Accelerator, Brake and Clutch pedals in my car intuitive. There was a time when I didn’t.

The only person who can convicingly claim that your software is intuitive or not is the person using it. As a developer it’s something I’ve often struggled with because what the end user finds intuitive can often be very different to what I think they’d find intuitive. Getting this right is half the battle (and half the fun).

Leave a Comment

From The Economist Special Report on the future of finance, Jan 24th:

Mr Rajan of the University of Chicago says academic research suggests mortgage originators, keen to automate their procedures, stopped giving potential borrowers lengthy interviews because they could not easily quantify the firmness of someone’s handshake or the fixity of their gaze. Such things turned out to be better predictors of default than credit scores or loan-to-value-ratios …

In other words -  if the devs found something difficult to deliver they descoped it. Pretended it didn’t exist. A viewpoint that is more common than you might think: to develop software you need certainties (if x occurs then do y).

Not that this viewpoint is limited to devs. In my work with buyers I’ve seen a marked reticence to even attempt to quantify the non-price elements of the bids they are being faced with, and certainly a reticence about weighing up the non-price elements of bids against the price (e.g. is a 3-year warranty worth an extra £x per unit).

It’s almost as if there is a tendency to ignore the subjective when what we should be doing is incorporating the subjective, but accepting it as such.

Leave a Comment

Build what I do, not what I say

As developers we keep on asking people to tell us their requirements. And then when we give them something that meets those requirements, surprise, surprise, it turns out that something got lost in translation.

And yet we persist in interviewing key users and running workshops to find out how to build our systems. Even though we know that the resulting documentation is often very wide of the mark.

An article in the 17th Jan edition of The Economist, called The Price Of Prejudice makes some strong arguments that not only is what people say they do often different from what they really do … what people think they would do is often different from what they would do in reality.

From the 2nd paragraph:

[T]he implicit association test measures how quickly people associate words describing facial characteristics with different types of faces that display these characterisitcs. When such characteristics are favourable – “laughter” or “joy”, for example – it often takes someone longer to match them with faces that they may, unconsciously, view unfavourably (old, if the participant is young, or non-white if he is white). This procedure thus picks up biases that the participants say they are not aware of having.

They cite three other fascinating experiments. The first two are by conjoint analysis experiments by Dr Eugene Caruso and the third is by Kerry Kawakami.

In the first, students were asked to pick team mates for a hypothetical trivia game. Potential team mates differed in their education level, IQ, previous experience with the game and their weight. When asked to rate the importance of the different characteristics, students put weight last …

However, their actual decisions revealed that no other attributes counted more heavily. In fact, they were willing to sacrifice quite a bit to have a thin team-mate. They would trade 11 IQ points  – about 50% of the range of IQs available – for a colleague who was suitably slender.

In the second, students were asked to consider hypothetical job opportunities that varied in starting salary, location, holiday time and the sex of the potential boss.

When it came to salary, location and holiday, the students’ decisions matched their stated preferences. However, the boss’s sex turned out to be far more important than they said it was (this was true whether a student was male or female). In effect, they were willing to pay a 22% tax on their starting salary to have a male boss.

The last example looks at attitudes to race. In this experiment a non-black student enters a waiting room in which there is a white “student” and a black “student” (these last two are in on the experiment). The black “student” leaves the room and gently bumps the white “student” on the way out. This white “student” either ignores the bump or might say something racist about black people. The real student’s emotional state is then measured and the student is asked which of the two “students” they would pick as a partner for a subsequent test.

A second group of non-black students, rather than going into the waiting room either read a description of the proceedings or are shown a video recording of the scenario and asked to imagine how they would react.

Both those who read what had happened and those who witnessed it on television thought they would be much more upset in the cases involving racist comment than the one involving no comment at all. However, those who had actually been in the waiting room showed little distress in any of the three cases.

In addition, a majority of those imagining the encounter predicted that they would not pick the racist student as their partner. However, those who were actually present in the room showed no tendency to shun the white student, even when he had been rude about the black one

More grist to the mill for an ethnographic approach to software development: one in which we build what people do rather than what people say they do, or say they think they might like to do; one in which the software developer spends significant time doing participant observation with the end users to really understand what she is going to build.

Leave a Comment

Inconsolata and Jedit on Ubuntu 8.04 (Hardy Heron)

The installation process for Jedit(*) on Ubuntu is pretty well documented – as long as you follow option 2 from the jedit download instructions. It’s well worth going for the latest release – as a lot of the plugins don’t work on earlier versions.

But the edit area font looked very uninviting, even with aliasing configured

The fabulous new Inconsolata font looked like the solution. You can install it (or at least the .otf version) as per usual.

But Jedit leans on Java and Java (apparently) requires ttf files, not otf files.

Here’s my workaround which, although a bit hacky, works for me.

  1. Install FontForge
  2. Download the FontForge sources
  3. Open the FontForge source in FontForge
  4. Export it as inconsolata.ttf (ignore any warnings)
  5. Copy it to the ttf-inconsolata font directory that was created as part of the installation of the ubuntu package, e.g: sudo cp inconsolata.ttf /usr/share/fonts/truetype/ttf-inconsolata
  6. Now edit fontconfig.properties.src in /etc/java-6-openjdk and add the following four lines
filename.Inconsolata-Regular=/usr/share/fonts/truetype/ttf-inconsolata/inconsolata.ttf
filename.Inconsolata-Bold=/usr/share/fonts/truetype/ttf-inconsolata/inconsolata.ttf
filename.Inconsolata-Oblique=/usr/share/fonts/truetype/ttf-inconsolata/inconsolata.ttf
filename.Inconsolata-BoldOblique=/usr/share/fonts/truetype/ttf-inconsolata/inconsolata.ttf

There you are, now you can use Inconsolata in your Jedit.

Was it worth it? For me – being used to Windows and Mac it has made my Ubuntu dev environment much more friendly than it was before. YMMV: screenshots of different fonts on my machine are below.

Bitstream Vera Sans 12

Bitstream Vera Sans 12

Courier New 12

Courier New 12

Deja Vu Mono 12

Deja Vu Mono 12

Inconsolata 12

Inconsolata 12

(*) FWIW – I do my RoR hacking on Textmate on the Mac and recently moved from Aptana to Jedit on Windows (I didn’t need the full-on IDE features). On Ubuntu I was looking for an alternative to Eclipse. I started with Gedit for a while but syntax highlighting was pretty poor and I spent too long chasing down all the different advice available on the interwebs and still not getting anywhere. IMHO Jedit is an altogether simpler option for RoR as it needs only a few tweaks as documented by the likes of Eadz and Xiabozz to get you moving in the right direction.

Comments (4)

Inspiring Apps: Deadline

Today I love Deadline (http://www.deadlineapp.com/)

They’ve taken on one feature and implemented it really, really well. 

You simply type in your calendar item using one box (e.g. lunch with john tomorrow 1pm). It then parses out the date and time and sends you email reminders.

The web user interface is brilliant. It really does invite you to enter your calendar items. Not sure what it is about the UI, but I think it’s something to do with the big typeface and the little flash you get as the screen updates with your new entry.

But even better – you don’t need to use the web UI at all. You can send your invites in by IM and receive updates by email. I am a big fan of apps that don’t need you to log into a website every time you want to do something. And I am a big fan of leveraging email more in apps.

Thank you, Alex Young.

Leave a Comment

Ethnography in enterprise software development

We need more ethnographers in the (enterprise) software industry. 

We would produce better software (by which I mean software that achieves its intended benefits more) if we started our projects off with an understanding of how people really work in their day to day lives.

Instead we start off with interviews and workshops in which we gather a view of what managers say their staff do. Or rather, what they say they think their staff do. Which is often several steps removed from what people really do. 

The only way to really understand what people do is to spend time with those people. If you were to take this kind of approach in enterprise software development you would spend a year or even 18 months figuring out how people really work, and only then would you start designing new software. But your software would be better.

On one cynical level I wonder whether this happens anyway. The first version of an enterprise system is implemented based on what key individuals have said they think the organisation needs to do. It fails to deliver its benefits. Then it is reworked and reworked over the next 18 months.

If so it would definitely be better to do some ethnography first, before implementing your new system.

Comments (3)

AIR spam

So I was installing a fresh version of Acrobat Reader 9 on an XP machine a few days ago and guess what … it comes bundled with AIR runtime by the looks (and there is no option to select/deselect when you try to install).

“Interesting” tactic by Adobe to rapidly grow the installed base who can run AIR applications.

Installer options:

Acrobat Installer

Acrobat Installer

 

My Add/Remove programs after installation

Air installs with Acrobat Reader

Air installs with Acrobat Reader

Leave a Comment

US vs Europe on what software is patentable

I once heard a business manager from a large, global organisation based in the UK speak about his dilemma about how to protect his IP globally. This is a summary of what he explained.

In the USA you can patent so-called “software business processes”. Perhaps the most notorious of these is Amazon’s 1-click ordering saga. In Europe the rules governing what software you can patent are much tighter.

So here’s the dilemma:

If you have a clever software business process then do you patent it in the USA? If you do make a patent application in the USA then all your competitors can now read that patent application and learn your special process. Your European competitors can even go ahead and copy that process with impunity, thereby lessening your competitive advantage in Europe.

Now, suppose you decide to go down the route of protecting your special business process by keeping it secret. You are now risking that one of your competitors may come up with the same process independently and that they might patent it in the USA. This would mean that the special process you were using is now subject to a patent owned by one of your competitors. You can no longer use that software business process in the USA, thereby lessening your competitive advantage in the USA.

What’s the answer? There isn’t a good one, unfortunately.

But this issue does highlight an important issue in the use of software patents globally.

My personal view is to hope for a brighter future where IP protection for software is covered more by Copyright rather than Patent protection. For three reasons:

  • A piece of software is, in my view, more akin to a book than to hovercraft landing gear
  • Copyright is automatic and so nowhere near as complex or costly to implement than a patent application, meaning businesses can focus on running their businesses rather than on retaining lawyers
  • I’m not aware of any example where a software business process patent genuinely helped innovation and progress

Comments (1)

Older Posts »