Friday, July 16, 2010

Maven, Eclipse and Tomcat: alternative to WTP

Despite some frustrations, I like using Maven in my Java projects for its dependency management and standardized project layouts. Since I develop in Eclipse primarily, I use the m2eclipse plugin to make Eclipse maven-aware. Which generally works well, except in the case of developing web applications. Eclipse's primary tool for managing web application development is the web tools project or WTP. WTP takes a fairly heavyweight approach to web apps; in particular it likes to copy the contents of a project into a special location (typically ${workspace}/.metadata/.plugins/org.eclipse.wst.server.core/tmp0) and use that as the web application context. It has to re-copy, including maven dependencies, when code is updated. Partly for this reason, and partly because WTP and m2eclipse don't always play nice, I've been looking at alternatives.

A colleague recommends the Sysdeo Tomcat plugin for Eclipse, which runs only Tomcat (fairly obviously), not the other app-containers that WTP supports, but does so in-place: there's no need for code to be copied to a temporary context. Although there's no Eclipse update URL, it's easy enough to install the plugin. The plugin provides a Tomcat extension DevLoader, which puts dependencies (including maven-managed dependencies) on the app's classpath without them needing to be in webapp/lib. To enable the DevLoader functionality with Tomcat version 6, I had to follow the instructions on this blog post to make a devloader.jar, rather than follow the instructions on the plugin website (which I suspect worked for older versions of Tomcat).

Thursday, June 24, 2010

Design vs engineering: not an either-or

A serendipitous collision of two worlds through links passed via Twitter today. First, a nice rant from Andraz Tori from Zemanta: Do semantic web interfaces have to be ugly?. Tori bemoans semantic web applications that let their clever technological underpinnings and perfect abstractions hang out for all to admire, rather than focussing on helping the user to achieve their goals through superior user experience design. Well and good. Then I got linked to an article by Brian Zmijewski of Zurb: Fewer engineers please!. In this piece, Zmijewski argues that smaller project teams are better: if two pizzas can't feed the team then it's too big. In particular, the suggestion is that there should be fewer engineers messing up the user experience design (ok, I'm paraphasing a bit ... but only a bit). Separate from the main thesis (I'll come back to that), the most interesting part of the article is the furious reaction in the comments, mostly from engineers who claim that the only role of designers is to "pretty things up", presumably by picking exactly the right shade of pastel or something. Of course, if I can borrow an American phrase, that's a total crock. Designers do much more than that. But equally, engineers shouldn't be parodied as introverted inaesthetes either. Nobody wants to develop a poor product or let down customers and users. It's bad for business, but it's fundamentally unsatisfying to work on something that people don't like or won't buy.

What's most depressing to me is to hear from both sides "No, we solve problems - that's our training". And it's true, both engineering training and design training focusses on solving problems. Which is right? Well, it's not a zero-sum game, so both camps are correct – up to a point. What we need more of, in my view, is really thinking about the end-user. The design community have, traditionally, had a greater strength in this regard, but it's a teachable skill and it's a skill that should be shared and developed, not hoarded. Design thinking should not the sole purview of designers. Let's work together to build some non-ugly semantic web interfaces, and other great products.

Are small project teams better? It's axiomatic that adding more people that necessary just increases waste and delay, but arbitrary rules are silly. It depends what you're trying to achieve. Yes a small teams can do good work, but, for example, nearly two thousand two hundred people built the LHC. That would be a singularly big pizza.

In summary: fewer arbitrary rules and demarcations, more user-centred renaissance developers.

Sunday, May 30, 2010

Skype and Ubuntu: lost notification sounds - solution

I use Skype for Linux very successfully on my 64bit Ubuntu 10.04 distribution – it's a great way to call in to the daily scrum at work, for example. Recently update-manager upgraded my Skype to version, at which point I stopped hearing notification sounds (e.g. the incoming-call notification, which is pretty handy!). I still got on-screen popup notifications where enabled, and I could still make calls and hear callers, but no notification sounds.

The solution was to go to the gnome-volume-control, and massively increase the slider for Alert volume slider. It had been at about 20%, it's now set at about 95%. However, I can once again hear skype notifications – at pretty much the same volume as before. So I don't know what's changed between gnome-volume-control and Skype: there may have been an update to the volume control that I didn't notice go by, or maybe this version of Skype is more sensitive to that setting. Still, at least that's one more annoyance is off the list.

Friday, May 28, 2010

A bit of gentle advice for student projects

Because my email address is attached to some the Jena source code, I quite often get direct email from students seeking help with projects. In general I don't mind this, though I'm sufficiently busy with actual work that I can't offer much direct support. My usual feedback is that most people need to get much clearer what they are actually to do. Often they come with very vague ideas:

I have to complete my project on ontology. Can you please help me to create a Jena interface?

Which gives pretty much nothing to go on. As a UI designer, you need some idea of who you are designing for, and what they care about. Here's my standard advice, which I've given out sufficiently often that it's worth repeating it in public so that I can just refer to it in future!

My core advice would be to get much clearer what you mean by "Jena interface" – (or however you've termed your project) without more context, I don't understand what that means, and I suspect you don't really understand it either.

So my suggestion is: consider a person using your interface when it's completed. Ask yourself some basic questions about them: are they beginners or experts? Are they a programmer, end-user, ontology designer, or what? What are the most important tasks do they need to do in order to succeed in their role? For example, an ontology designer might want to load an ontology file that someone else has created and add their own annotations to it, to fit their customers data needs. Or, a programmer might want to search for an ontology that would help them represent concepts about wildlife for a media catalogue program, so that users of the catalogue can tag consistently. By making this description as detailed as possible, you get a much clearer understanding of your users' needs.

Then ask yourself what are the three most important features of your interface that would make those users' jobs easier. Imagine them sending a twitter message: "Hey, this interface is really cool, it allows me to do X really well!" And that gives you the starting point for your design process.

By the way it doesn't matter if you are only doing this as a student project, not as a real product. Either find a group of real users to work with, or make up some users and jobs for them to do. That way, you'll end up with a more interesting interface, and it will make it much easier for you to write your end-of-project report!

And by the way, specific questions about Jena should be asked on the Jena support email list.

Monday, February 22, 2010

Google gdata library and maven

Despite a number of requests from a variety of users, there are as-yet no official maven versions of Google's gdata client Java library. There are various scripts to push the .jar files into a local repo, and one project on Google code containing an older version of the client library, mavenized. I think it's up to the code maintainers (Google) to put a process in place for pushing official maven versions of the gdata .jars out to the public repos. In the meantime, the best we can hope for is to load into local repos. However, a problem with the scripts I've seen is that they bake-in the various versions of the libraries to the script. So here's my variant, which takes the artifact name and version from the .jar filename:


for f in java/lib/*.jar
  if [[ $f =~ java/lib/gdata-([a-z-]*)-(.*)\.jar ]]; then

      echo "installing mvn artifact $n $v"
      mvn install:install-file \
          -DartifactId=$n -Dversion=$v -Dfile=$f -Dpackaging=jar \

Tested on my Linux system at home, but I'm expecting this to also run on Windows/cygwin when I get into the office tomorrow!

Update Thanks to ildella on Twitter for pointing out that there's a maintained, up-to-date collection of maven-ized gdata artifacts on googlecode. maven, gdata,

Saturday, January 09, 2010

British English Thesaurus for OpenOffice 3.x

OpenOffice 3.x on Ubuntu doesn't come with a thesaurus for British English (en-gb), which is irritating. Google shows lots of recipes for faking a British thesaurus using the installed thesaurus for US English, which is at best an approximation, but in any case they don't work on OO3. A much better solution is to download the British English Thesaurus OpenOffice extension from the weekly whinge and install it (from any OO application: Tools » Extension manager... » Add ...). Kudos! openoffice, thesaurus, solved.