Sylvain Wallez

[This is a job offer for a sys admin/ops position in Toulouse, France]

La société Goojet dont je suis le CTO cherche un nouvel administrateur système et responsable des opérations. Le poste est basé à Toulouse, et les missions couvrent le maintien en opération, mais aussi la définition et la mise en place de l'infrastructure qui nous permettra de gérer notre croissance.

L'équipe d'ingénierie est composée d'une dizaine d'ingénieurs passionnés et très (hyper)actifs !

Plus d'informations sur le blog de Goojet. Si vous êtes intéressé(e), contactez moi directement, ou écrivez à jobs@goojet.com.

My dear colleague Thomas recently pointed me to the enlightening presentation “Putting the Fun in Functional: Applying Game Mechanics to Functional Software” where social architect Amy Jo Kim describes the mechanisms that game developers have for long used to keep the interest of gamers, and how they can be (and are) used by websites to engage users, increase their loyalty and finally have them do more and spend more time on the site.

Collecting stuff, earning points, receiving feedback, exchanges with other “players” and customization are the main techniques she outlines. You can see them in many websites: Twitter followers, LinkedIn profile completion status, customized YouTube channels, etc. And of course of Foursquare or Gowalla whose badges and mayorship drive competition so that people always say where they are.

With the upcoming “digital native” generation, people who’ve played video games before they even learned to speak, these techniques are becoming more and more important to engage users. And they do not only apply to social networks but also for more regular work, as show in a recent Venturebeat post or the “Productivity Games” blog.

A good source of information on these topics is Bunchall’s Twitter feed where lots of interesting links are posted.

Side note: interesting to see Wikipedia’s “digital native” page linked to “homo ludens”!

So I've been tagged by Stéphane. Like him, I think limiting the list to 5 sites like Ludo originally asked for will lead to everybody giving more or less the same answers: Google, Wikipedia, Amazon, LinkedIn, Flickr, etc. So let's try to make a list of useful but less widely known websites. Note also that "usefulness" varies over time and activities.

Here's what came out of my head when writing this post:

When you have a cluster of web application servers, you often need to coordinate the activity of your servers to avoid the same expensive work being done at the same time when a condition triggers it.

Most people use memcached as a simple key/value store but it can also be used as a simple distributed lock manager: along with the put(key, value) operation, it also has an add(key, value) operation that succeeds only if the cache wasn't already holding a value for the key.

Locking then becomes easy:

if (cache.add("lock:xyz", "1", System.currentTimeMillis() + 60000)) {
  try {
    doSomeExpensiveStuff();
  } finally {
    cache.delete("lock:xyz");
  }
} else {
  // someone else is doing the expensive stuff
}

The code above tries to get the lock by adding a dumb value for our lock's idenfitier, with an expiration of one minute. This is the lock lease time, and should be more than the estimated maximum time for the lengthy operation. This avoids the lock being held forever if ever things go really bad such as your server crashing.

Once the operation is completed, we delete the lock, et voilà.

If you want the system to be rock-solid, you should check that you still own the lock before deleting it (in case the lease time expired), but in most cases this simple approach works nicely.

And if the expensive operation resets in the database the condition that triggered it, the lock should be released once the transaction has been committed to prevent a race condition in the time interval between the end of the expensive operation and the actual commit that would allow other servers to restart the same work. Spring's transaction synchronization helps doing that.

I'm pretty sure you've already seen some demos of Microsoft Surface (if not, look here). Pretty amazing and sci-fi, eh? Also sci-fi is the ReacTable which allows building sound synthetizers by just moving cubes around on a surface.

The hardware for these things for a cheap personal setup is actually quite simple, and we now have lots of free software to power it and do amazing things. So during this rainy week-end afternoon, I've built my own mulit-touch table! I won't post pictures as it's really ugly for now ;-)

All it takes is a big cardboard box, a piece of Plexiglas, some tracing paper to be taped on it, a webcam, and there you go. I started exactly like this guy demonstrates. It's that easy! In my setup I've added a diffuse light inside the box so that touch detection is more accurate.

Now I wanted to do some ReacTable-ish stuff, using real objects and not only my fingers. The Reactable people have open sourced their fiducial and finger tracking software in the Reactivision project, and there's a recent project to build a Reactable clone.

Yay! Now I can make music (more exactly sounds at the moment) with my tangible multi-touch table!

The Nook ebook reader sounds quite compelling compared to the other ebook readers such as the Kindle or Sony Readers: it has a black and white e-Ink display to comfortably show book pages like all other readers, but it also has a small LCD touch screen at the bottom where all the action happens.

And this second screen makes all the difference: e-Ink screens are perfect for reading and use very little power, but they're definitely not suited for user interaction since they require to "wipe" the screen before changing what's displayed.

The Kindle has a keyboard that takes a lot of room for something that's accessory to the main device's feature, and some Sony Readers have a resistive touch layer on top of the e-Ink surface that reduces its clarity, and probably don't allow smooth interaction (I haven't tried it though).

The Nook looks like a great compromise: e-Ink display to read, and a speedy colorful capacitive touch screen for browsing, searching, etc. As an additional bonus, it's also powered by Android. Not sure you'll ever find the Android Market on this very specialized device, but this could open the door to additional applications being available to enhance your reading device.

Reading books on a computer display is a strain for the eyes, and I'm always reluctant to print lots of pages. The Nook could be the device I was waiting for. Now will it ever be available in France since it's a Barnes & Nobles thing?

Looking around for Java cache systems, I found that a lot of them claim to be JSR-107 compliant. Now this JSR never went past the review ballot in 2001, and the latest available draft is from 2005.

Among the products that claim compliance, some of them are "serious" ones and I'm surprised that they're happy with a dormant draft specification:

• EHCache
• Google App Engine
• Infinispan (aka JBoss Cache 4.0)

But many of them implement their variant or repackaging of the spec, requiring developers to define their own interfaces to shield the application from these naming variations.

So what happened to this JSR? In these times where memcached is king but memory grids (aka distributed caches) are probably more suited to Java servers, why has it stalled?

In any web 2.0 business, it is important to understand where you new users come from to understand where to put the effort in order to increase your user base. Browser-based services usually embed tracking information in URLs, but things are more difficult when you provide mobile phone applications for your service, because passing tracking parameters through the installation process is all but easy.

When the application is downloaded from your servers, it's rather easy to include tracking information in the downloads. But all application stores such as the iPhone AppStore, Android Market, Ovi and others imply a strong isolation between the application and the link that has been driving the user to the app store. There's no way to pass parameters to the installed application, and so the tracking information is lost.

I have found an ugly trick on iPhone and Android to circumvent this isolation and get back this precious information in the application. The key is to use the phone's browser cookies as an intermediate storage, and the ability provided by these platforms to associate a URL scheme to an application. Here is the process:

1. First make sure your application registers its own URL scheme. We used "goojet:" for ours.
2. Let ads, affiliate links, partner landing pages, etc link back to your server as would be the case for a regular web site
3. When these URLs are called, your server should place a tracking cookie in the user's browser and redirect to the application store so that the user can install the application
4. At the very first launch of the application, start the phone's browser, pointing to a "tracking reinjection" URL
5. This URL should read the tracking cookie and redirect the user to your application, using it's special URL scheme and the tracking information, e.g. "goojet:start?source=foobar"

You now have the tracking information in your application.

Very nice quote from Brian McCallister on Twitter:

Before saying "but there is more support for X," remember, there is more support for breathing underwater than above.

This is so true: sometimes, using a different tool or technology, or even simply a different approach removes a whole set of problems which you don't have to find support for, because you don't need to anymore.

We're preparing a big new release at Goojet, and wanted to collect some feedback from some of our users. For iPhone applications, Apple allows "ad-hoc" installation of an application on up to 100 devices, without going through the AppStore and its painful validation process.

Reading the documentation, this sounds easy: just create an ad-hoc provisioning profile where all test devices are listed, sign your application with this profile and off you go. Alas, there is a tiny but absolutely mandatory step that isn't described in the docs, and I banged my head for hours before finally finding it...

iTunes refused to install the ad-hoc application, saying that it cannot be verified. Inspecting the iPhone's log shows "entitlement 'get-task-allow' has value not permitted by provisioning profile". This entitlement thing is mentioned only once in the whole documentation, in a place totally unrelated to ad-hoc installation and it barely explains what it is useful for.

So, here is what you have to do: in XCode, select File/New, and then in the "Code Signing" section you'll find an "Entitlements" template. Create an "Entitlements.plist" file, open it and uncheck the "get-task-allow" property. In the project's ad-hoc build configuration (that you should have created to sign with the ad-hoc profile), set the "Code Signing Entitlements" to "Entitlements.plist" you just created.

Build your application, done, you can deploy!