Diigo v Licorize - Round 1: The Journey to the Promised Land

Long time readers of this humble blog will know that I've just heard that Yahoo are pulling the plug on Delicious, the ace cloud-based bookmarking service. The bastards. I decided on 2 potential candidates to take on my bookmarking needs - Diigo and Licorize. They will do battle to the death and the victor will take my bookmarks into 2011 and beyond.

The first step to compare these is in the initial migration from Delicious to these new services - this involves exporting from Delicious to a .htm file, importing to the new tool and accessing my old bookmarks.

Diigo, at time of writing, is not faring well. They have a lot of traffic and a lot of import requests and have so far not finished importing any of my bookmarks. I started this process at lunchtime, I am now packing up to go home for the weekend. Not a great start but understandable.

Licorize have done a somewhat better job. The import was, I was told, carrying on in the background. I went away and came back some time later. All my tags were visible! Hooray! Some had a strikethrough which means they are not yet accessible - it may be that older bookmarks only had these tags and have not yet been processed. It is useable though - using a tag that was available brings up the correct bookmarks, ordered by date, with a collapsible display and calendar function to make searching easier. The interface is slightly confusing but I'll analyse that more when Diigo is ready.

So far based on the importing experience, it's Licorize 1 Diigo 0.

Next round - web interface usability

Battle of the Bookmarks (RIP Delicious)

Delicious is closing! Nooooooo!

I am genuinely gutted. I liked it's clean interface, the effective Firefox plugin, and the fact that it made me change the way I bookmarked pages for ever. Way back when, it was the first time I got to grips with this newfangled "tag" malarkey. I'd never really got it before that. Delicious was a quantum leap for how I did things. I have recommended it to others, and Yahoo have made me look a mug for that. So I extend a middle digit in their direction.

Anyway as with most things in life the best thing for all is to just move on. There seem to be a wealth of similar tools out there now vying for attention, all with helpful "Migrate from Delicious" links, no doubt added last night. Here is a brain dump of what I thought when looking for a new home for my bookmarks.

XMarks - This service routinely gets a lot of love from Lifehacker and their readers. It's not really what I want though - having bookmarks available in browser is great but I need something which stores them "in the cloud" so I can access them from, say, an internet cafe in Thailand. Or a police station. I've said to much. Needless to say this wasn't for me. Next!

Pinboard - This also got a lot of love from Lifehacker and other places. It's a very stripped-back webapp that seems delicious-freindly and a lot of people defecting there. However, It's a paid service where the price goes up the more people use it. Currently nearly eight dollars of toy money er I mean US dollars. Also the plugins/extensions are "3rd party" not that there's anything wrong with that, I just don't fancy looking up forums for how to get round bugs in Pinboardr or Pinchrome or whatever. I like the stability that Delicious has brought me (ironically until today) so I'm going to pass up the chance of parting with over 5 pounds sterling. Next!

Google Bookmarks - The ubiquitous behemoth lumbers over the hill offering another service. I already use quite a few google services and they work well (does anyone not use gmail?). The interface looks a bit "beta" and the functionality is like Delicious lite. The plugin involves using Google toolbar, which is awful. Overall it doesn't float my boat but could work in the way I work. I need a bit more "oomph" though. It's a Meh from me. Next!

Diigo - Like Dover is to Sangatte, this seems to be the destination of choice for most Delicious refugees. Slick interface, loads of plugins, easy Delicious import, stored highlighting, clipping, whole page html archiving, all sorts. Their outlook seems to be to take what Delicious does and run with it and provide a more integrated service of bookmarking, collab tools, and data management. Upgradeable to a premium version but I'm not altogether sure what that would give me, so free is fine with me. Looks really interesting. It could be a goer. What else is there?

Licorize - not a lot of chatter about this service, it was in alpha in May this year according to their own blog. Looks slick, seems to do some of what Diigo does but with more of an emphasis on personal To Do lists. Premium version is just for creating collab projects. Looks an interesting service for what I do... also worth considering.

What I have decided is to sign up for both Diigo and Licorize, pit them against each other and see which one emerges victorious. I will keep track of it on here.

RIP Delicious, we hardly knew ye.

DWR - multiple context handling

Our current app has a lot of contexts tied to security features - for example content generated by going to a URL for '/area1/' is only visible to certain logged in users. Users who have access to pages in '/area2/' do not have access to pages from '/area1/'.

These servlets are configured in this way:

 <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/area1/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>area1</servlet-name>
    <url-pattern>/area1/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>dwr-invoker</servlet-name>
    <url-pattern>/area2/dwr/*</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>area2</servlet-name>
    <url-pattern>/area2/*</url-pattern>
 </servlet-mapping>

This led to a problem involving DWR (version 3rc1).  As different servlets require different authentication privileges, we use specific filters on each servlet to authenticate the user to make sure they have access; thus the DWR must be relative to these servlets so the filter is invoked. The dwr-invoker was configured in this way:

 <servlet>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
   <init-param>
      <param-name>debug</param-name>
        <param-value>true</param-value>
   </init-param>
   <init-param>
     <param-name>allowScriptTagRemoting</param-name>
        <param-value>true</param-value>
   </init-param>
 </servlet>

Unfortunately, when it came to trying to access dwr objects, the _pathToDwrServlet property was stopping requests. Because the engine.js file is generated dynamically, on the first call to generate engine.js, it uses the current context to populate this value:

  /** The default path to the DWR servlet */
  dwr.engine._pathToDwrServlet = "/area1/dwr";

A caching issue means that when the context is /area2/, this value is still present in engine.js, causing associated security exceptions and puzzled expressions from testers and devs alike.

"So how do we get around this?" I hear you cry. Well I'll tell you.

There is an init param when defining dwr-invoker called overridePath. This allows the _pathToDwrServlet to be a different value than the one obtained in the initial context.

"But surely you need to know what context you'll need each time?" Not necessarily - add this code:

<init-param>
    <param-name>overridePath</param-name>
    <param-value>dwr</param-value>
 </init-param>

which means that the path in engine.js is always:

   /** The default path to the DWR servlet */
   dwr.engine._pathToDwrServlet = "dwr";
 

By giving this value a path that matches the start of the path used to import the engine.js and util.js scripts, it always picks up the correct context when making the call to DWR objects, avoiding any tricky security exceptions but using the correct current context! And it works for situations where you're in the top level context as well, just as the import statements do! It's as easy as pie.

Mmmmmm, pie.

Ch-ch-ch-ch-changes

By way of css practice, I am making some gradual changes to the layout of my blog. Of course, anyone using a reader for this won't notice any difference, so ignore this.

As part of my day-to-day work, I don't get a lot of artistic licence or freedom of expression in terms of how things look or are laid out, so I'm going to take out all related frustration on my blog. I have had a few ideas and posterous is pretty flexible in terms of how things can be laid out. I haven't really done any proper website graphic design for a fair few years, since making my then band's website in fact, so a lot of what is now possible is exciting.

Also after seeing a number of articles in the bioinformatics field, there seems to be a massive knowledge hole in terms of making functional sites user-friendly and attractive. I would love to be able to offer that kind of enhancement to scientific software. This kind of thing will be good for my CV, er I mean personal development.

So if you see this site changing appearance, feel free to add comments. It will truly be a work in progress, I will hide nothing and add some updates explaining my thought processes.

How to: Make small, gemstone-style shaded icons with Gimp

On the product I currently work on, we had a requirement for the site to be customisable in terms of branding and colour. Part of that was a series of icons in a navigation bar. They were to be of a fixed colour and be selected as part of a colour scheme, where the CSS was selected based on the domain key.

The original icons we had look okay and do the job.... to a point. Until we got asked for a new colour scheme to match the customers chosen colours. We got a contractor to make the icons, which he did. He even supplied a template file so we could make other sets. Fine, until we realised it was a Fireworks file, which can only be edited with Fireworks.

"Can I have a Fireworks licence please?"
"Do we have to pay?"
"Yes"
"Then no"

Right then. Time to make our own. I found a step by step for making larger spherical icons that gave some pointers to creating light and shade effects:

http://www.gimpusers.com/tutorials/glossy-orb-icons-for-websites.html - I have borrowed slightly from this in this tutorial but if you're in a hurry for small, square icons this will help.

To make some nice square shaped, professional looking icon bases, I did the following

Opened GIMP and created a new file, 24x25 pixels (to match our existing icons) with transparent background. But you could use 24 x 24, which would probably be better.

Select the rectangle select tool, check the Rounded Corners box and the Antialiasing box and draw a square from corner to corner.

Select a dark version of the colour you will be using for your icon. in this example I'm making a red icon so I used RGB (138,5,10). Fill the shape.

Icon_howto_1

Create a new layer, then Select > Shrink. Shrink the selection by 1 pixel.

No select the colour that you want the overall icon to be and also a lighter colour. Here I have used RGB (144,0,0) and RGB (221,77,76).

Select the gradient tool and ensure it is set to FG to BG (foreground to background). Draw the line for your gradient on the selection from the top right corner to the bottom left corner.

Icon_howto_2

Icon_howto_3


You have a gradient of colour implying a light source. Your icon is starting to take shape!

We want to give it a blur though to stop it looking blocky. Select Filter > Blur > Gaussian blur. Set the amount of pixels to 1px. Apply to the current selection.

No we want to give it an extra highlight. Create a new layer and Shrink the selection by 2 pixels.

Pick a lighter colour than your previous foreground, nearly white but not quite. In this example I have used RGB (242,121,112). In the gradient tool set the gradient type to FG to transparent. Draw your gradient from top left to bottom right again, maybe with a slight anticlockwise rotation. Perform another Gaussian blur on the selection.

Icon_howto_4


Export this as a png file to the location of your choice. You're done! You can now overlay these with white images to create icons - set the icon base you have created as a background to a div, position it, then position an image tag over this. Here it is at normal magnification (you can rob it if you just want red icons)

Template

You could probably script this in GIMP if you supplied to colours... which I may do. You could probably make larger versions using vector graphics as well, I just didn't have time and had a very specific requirement. Anyway, enjoy and let me have your constructive criticisms below!

Short Sharp Science: Fossilised mind control, 48 million years ago

death_grip_fungus_ant.jpg

This carpenter ant (Camponotus leonardi) is caught in the throes of a fungus-induced death grip. It has clamped itself to a leaf 25 centimetres above a forest floor in Thailand, and died.

The reason is growing out of the back of its head. The reddish-brown stalk is made by a fungus called Ophiocordyceps unilateralis, which has invaded the ant's body and manipulated its behaviour. The exposed position is ideal for releasing spores.

It turns out this parasitic mind-control is at least 48 million years old. David Hughes of Harvard University and colleagues discovered fossilised leaves of this age in Messel, Germany that bore characteristic "death grip" scars, suggesting that ants once clamped themselves onto them.

It is the first time this sort of behavioural control has been discovered in the fossil record, and supports the idea that the ants and fungi have been locked in an evolutionary arms race for many millions of years.

Journal reference: Biology Letters, DOI: 10.1098/rsbl.2010.0521 (in press)

(Image: David Hughes)

Absolutely terrifying but undeniably amazing.

Why won't my form submit when I press enter?

Here's a nice problem we've just come across.

We had a web form. Pressing enter used to submit the form.Then we added all kinds of whizzy bells and whistles and subforms. It stopped submitting. Why was that?

Well when you press enter on a form, the browser finds the first input type="submit" it comes across and tries to submit using that. So if you have used this in subforms or for a reset button (as we had), you need to ensure that the form submit button is the first input type="submit" that the browser encounters to achieve this universally expected behaviour.

Alternatively, get rid of subforms adding things to the spring context/view. Fortunately this is what I'll be doing in the next version of our product, so that the only input type="submit" left is the one which will, er, submit the form.

Try it at home!

Delicious - foiled again!

Another idea down the pan! A webOS client for delicious, the social bookmarking site. They even had the same name I came up with! 

I _might_ have a look at the code anyway as it's open sourced, but I am wary of pitching in on someone else's project and ending up with loads of support requests or just doing all the work! This is meant to be a learning exercise after all.

The search continues for another unique idea.

Oh and I am blogging this on the bus from my Pre. Extremely liberating!