Sylvain Wallez

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!

My first son is 18 today, which in France means he is officially an adult. At 24 I was rather young when he was born, but still, today is a milestone. Another important milestone was last september, when he left the home to study in Montpellier, only coming back home on week-ends with a bag of dirty laundry :-)

Kids grow fast and times flies. Quite common statements, but why are they so common? I guess it's because our lives are packed with too many activities, and there are even more that we don't have time for. So in a way this is because our lives are not boring.

Anyway, enough old fart's rants. Happy birthday Corentin!

The Toulouse Java User Group was recently created, and I will give a talk about J2ME development at its first meeting. There will also be a talk on GWT, and plenty of time for informal discussions around the buffet.

So if you happen to be around on May 12th, you're more than welcome to join the party!

I borrowed part of this post's title from an interesting article at The Register. Basically, the article says Oracle now owning MySQL won't change anything, since MySQL is already dying because of the slow pace at which new features are released, and that forks are already in the works to take over (see Drizzle and OurDelta). This fork-and-continue-elsewhere model has already been seen several times when an open source company goes against open development (i.e. community diversity). Now a database is probably something different.

At Goojet we rely heavily on MySQL, as it stores all of our data. The reasons that led us to choose MySQL are quite common among internet (in our case mobile internet) startups: it's free, which is important when you plan to scale out and don't want to spend all your money in costly per-CPU license fees, and it has rather well-known solutions for replication and load balancing, even if these have some shortcomings.

I hear you, die hard bleeding-edge'rs: I've used Hadoop in the past, but it's not (yet) good as a front-end database, and I'm not sure alternative databases such as CouchDB are ready for production, at least for storing the very business-critical data that is our user base. And not everything can be stored in a distributed key-value store. So we stick to MySQL, at least for now.

Google has silently released a personal profile service, whose purpose is to "give you greater control over what people find when they search for your name". Everybody has searched for their name once to see how well (or badly) they were "findable", and Google promises to give your name a higher ranking if you fill your profile page.

Now this narcissistic feature based on Google's big gun, their search engine that everybody uses, is actually a smart stealth move towards a social network that doesn't say its name. Your profile can contain information that you only want to disclose to your GMail contacts which are now named "friends". No need to recreate a social graph, it already exists in your mail account. And if you have an Android phone, Google knows your close relatives since your phone's address book is sync'ed with your GMail contacts. You can even grant special permissions to the phone contacts marked as "favorite".

This profile page is not – yet – a threat to Facebook, since it only shows things about you, and not about your friends. But how long before Google adds OpenSocial gadgets to the profile page and merges it with iGoogle? And how long before Google aggregates news from the various URLs about you it invites you to publish (blog, photos, twitter, etc) and kills FriendFeed?

At Goojet we are developping applications for the mainstream mobile platforms, currently J2ME, iPhone, Android and BlackBerry, and Symbian in a near future. These applications are essentially enhanced web mobile browsers, supporting the mobile widgets and social features brought by our platform.

Our J2ME application is the most complex because this environement is very low level, and we're currently looking for a talented and experienced J2ME developer to grow our mobile development team.

The job includes writing efficient graphic rendering of HTML content (there's no WebKit on J2ME as we have on other platforms) and usage of optional J2ME APIs such as camera, location and video while ensuring the portability on the wide range of phones we support.

Being able to work in our offices in Toulouse would be a big plus.

If you are interested or know someone who could be interested, please contact me.

I have two very old Macintosh computers in my basement: a Mac SE bought in 1987 and a PowerMac 7200 bought in 1995. I also have hundreds of floppy disks for these computers, with all sorts of games and utilities, including the very first versions of Word and Excel!

These computers are still functionning, but what can you do with these except powering them once in a while to show kids how slow and limited they were compared to today's computers? Also, most probably many of the floppies have lost their data.

So what should I do? Trash them? They represent so many memories and so much time spent staring at their screens. That's a difficult decision, but they are taking to much space! My old Apple IIe, bought in 1984, is still alive, but is still at my parent's house. They ofen tell me to take it back, so asking them to host my old Macs seems out of question :-)

I think that at some point you have to consider that time has passed, and bury those old things that you once loved. Note that I had absolutely no problem trashing my old PCs!!!

When I started blogging in November 2002, there weren't many free blogging tools available. The major one was Movable Type, which I first installed on the company server before moving it to my own domain.

Alas, Movable Type is written in Perl, which I find hard to read and never took the time (nor found the motivation) to learn. That means my blog engine was merely a black box to me, and I've been regularly thinking to switch to something else I could really understand and fix and hack when I felt the need to. At some point, being a developer at heart, I even considered to write my own thing, but lacked the free time to do something that would be good enough.