Gilles Grousset

J’écris très rarement en français dans ce blog, et encore moins pour parler de foot (oui, en fait je n’aime pas trop ça)…

Mais là l’occasion est trop belle : la victoire du Montpellier HSC en L1 hier m’a décidé à faire ce petit tableau, juste pour montrer que l’efficacité d’un club (ses points) par rapport à son budget, ça donne un classement très différent !

Je vous laisse juger :

OpenStreetMap is wonderful ! Not because Foursquare and Apple (for iPhoto) are starting to using it, but because it’s a goldmine for us, developers !

I discovered OpenStreetMap when I started working on BuStopZ (an iPhone application that indicates urban transport lines and stops) 2 years ago.

At the time I needed a datasource to retrieve bus stops and ways (lines) and I found all of that with OpenStreetMap.

With BuStopZ, I use a local database (sqlite) with all those data and I also provide database updates, to keep them up-to-date.

So I need to rebuild the whole database (one database per country) with fresh data every time I need it.

I do it with a simple set of sh scripts.

Here is basically what I do …

Data retrieval

The first step is of course to access the data, and OpenStreetMap provides different API and tools to do so.

However, when you need to extract particular data on a whole region, querying the API is not the right way to do, it’s more efficient to work with bigger datasets: OSM files.

OSM is the XML export format for OpenStreetMap. The site Geofabrik provides fresh OSM exports of the OpenStreetMap database divided by region (countries, states …) that are free to download.

As those files are quite big, they are compressed using the bzip2 algorithm.

A simple curl / bunzip2 script is enough to do the job:

# download
curl —location —globoff http://download.geofabrik.de/osm/europe/france/languedoc-roussillon.osm.bz2 -o languedoc-roussillon.osm.bz2
# uncompress
bunzip2 languedoc-roussillon.osm.bz2

Useful data extraction

Once data is retrieved, it is time to parse it…

An OSM file is quite basic in terms of structure : there are nodes, ways and relations… But don’t even think of working on a OSM file with a traditional XML parser !

As a matter of fact, files are usually way to big to be handled “as usual”, to handle those files the OpenStreetMap community wrote a special command line tool (written in Java) named Osmosis.

The tool is very handy and you can perform many operations on OSM files such a compare them, track changes, extract data from a bounding box but also filter interesting data.

To extract nodes of type ‘restaurants’ from the OSM file:

# extract restaurants
$OSMOSIS_HOME/bin/osmosis \
    -q \
    —read-xml languedoc-roussillon.osm \
    —tf reject-relations \
    —tf accept-nodes amenity=restaurant \
    —tf reject-ways \
    —write-xml file=restaurants.osm

Note that nodes are typed by tags, a node containing a tag with a key equals to “amenity” and “restaurant” as value is a restaurant.

To find out all the node types and properties have a look at here.

Output formatting 

Once the desired data is parsed, the last step is to format OSM data to include it in a database, or convert it to another format (text, xml …).

To do so, I use XSLT in order to generate SQL insert statments, like this:

# output transform
xsltproc -o restaurants.osm tosql.xsl inserts.sql

That’s all folks !

Have you ever tried to record a movie from the iOS Simulator for marketing purposes ?

I did !

I first tested existing applications, but didn’t find what I was looking for.

The best I came up with was using SimFinger + the native QuickTime screen capture: not that bad, but not satisfying enough…

Here are some things that really annoyed me with this setup:

• The ‘setup’ time for every capture is quite long: you have to prepare the simulator, then launch SimFinger and finally select the capture area in QuickTime.
• Movies captured with this setup are not ‘iMovie ready’. What I mean: the aspect ratio is not compliant with standard ones, so it is necessary to crop the frame.. And then you see big nasty pixels..

So I decided to write my own application. As I did it to promote my Whazzer project, I named it WhazzerFinger.

The application runs on OS X 10.6 and 10.7 and has the following features:

• Supports iPhone simulator in portrait and landscape mode.
• Video frames are captured to RAM, so that no frames are dropped. To capture longer videos: make sure to close all unnecessary applications before starting.
• FPS is 16 (which I found is a good compromise between quality / memory).
• Video are encoded in H.264 format, ready for iMovie import.
• The application also takes screenshot images.

If you are interested in using it, then grab the sources (XCode project) on GitHub, right here, and build it.

For the laziest ones, here is the binary (packaged as .dmg): WhazzerFinger 0.1.

The current version is not perfect yet, but I’ll try to improve it later.

I’m a little bit late on this one: I actually released this one 3 weeks ago…

What’s new in this release ?

• Fixed bug with PSDocument getPageCount method.
• Fixed bug with Renderer with 64bit archs (see http://bugs.ghostscript.com/show_bug.cgi?format=multiple&id=692754).

Contributions and support

I’m quite happy to see that more and more developers are using my little library, and I’m also happy when other people share their enhancements and fixes with me.

So if you also want to contribute, send me an e-mail, a DM or whatever with your fix or proposal (a patch file is the best for me) and I will review and (probably) integrate it in next releases.

On the other hand, if you need support (I receive more and more requests): the best is to leave a message on the forum here: http://sourceforge.net/projects/ghost4j/support. It is much better than an e-mail that only you and me will see…

Hi and happy new year to everyone!

It has been a while since my last post so here is a new one, that some of you may find useful.

This one is about handling internationalization (i18n) in an iOS App: this is not always as easier as it seems, especially when it comes to maintaining translations in between each application release.

Apple Tools

When working with iOS SDK there is already a set of functions / tools to help you managing your i18n.

First, you have to use the NSLocalizedString function to make your strings internationalized.This is pretty easy: the first parameter is the key, the second the comment. However don’t use a code (like in a Java property file) as key but the default string value: it will make things easier when generating localized string files.

Here is an example:

NSString *myLocalizedString = NSLocalizedString(@”Edit”, @”Edit button label”);

Providing a comment is not mandatory but can be very useful to locate the string in the application when translating.

If your string as variable parts, your can also use variables in the string, like this:

NSString *myLocalizedString = [NSString stringWithFormat:NSLocalizedString(@”Hello %@”, @”Welcome message”), @”Bob”];

Once strings are prepared for localization, they must be written down to a file for translation work.

For this task, Apple provides a command line tool: genstrings, that browses source files to extract strings to localize.

It can be used like this:

genstrings -o en.lproj *.m

This command will extract all i18n strings from .m files in the current directory and will write them in the en.lproj directory. Of course, en.lproj can be changed to any locale you want to extract to. If your keys are written in french in your code, use fr.lproj instead.

As in most of my projects, sources are spread in different folders / sub-folders, I wrote a shell script to automate the task, here it is:

#!/bin/sh
# Script to regenerate en Strings
find . -name \*.m | xargs genstrings -o Resources/Strings/en.lproj

When you need to add a language, run the command with another locale and translate the strings in the generated file.

Localization Suite

The above solution works fine for the initial translation of the application, but with updates and new releases, it becomes hard to maintain.

As a matter of fact, if you need to modify a string or add a new one, you have to generate the strings file for each language again and all your previous translations will be lost (you can also add every new string by hand in every file, but you will get lost soon…).

Hopefully, I had the chance to find a set of free tools named Localization Suite. This suite provides tools to manage and translate strings of an application.

It contains 3 applications:

• Localization manager : to store and maintain strings of the application in a database.
• Localizer : to translate strings.
• Dictionnary: to manage a glossary and reuse translations accross different projetcs (I have never used it myself).

To use the suite, you first have to import your projet strings into the Localization manager: this is pretty easy as you can import an XCode projet from it.

Then, from here you can mange languages and check if localization is complete for each of them.

To translate into a given language, select it and click ‘Edit…’ to open it the Localizer application.

You need to click ‘Write Out’ to write the Localizer file for the given language the first time you use it.

The Localizer is a clear editor where you can see the keys you have to translate and their translation in the default language. You can also filter keys to show only missing ones.

Once the translation is complete, save the file, then go back to the Localization manager, select the language you just translated and click ‘Read In…’ to import your localized file into the database.

Repeat the operation for each language you want to translate (‘Edit…’ language file, translate, save and import with ‘Read In…’).

When the translation work is finished, click the ‘Synchronize’ button (the above one, near ‘Re-Inject’): the new strings files are exported to your XCode project.

Make sure to keep your Location manager database (.ldb) and Localizer files (.loc) in a safe place for latter use.

Maintaining strings

The main advantage of the Localization suite is that you can easly update your application strings.

To do so:

• Re-generate your strings for the default language with the genstrings tool.
• Open your Localization manager database file and click ‘Rescan’: this will add / remove new strings to the database.
• Translate the new strings and import them back to the database.
• ‘Synchronize’ to export up to date strings files to your XCode project.

That’s it!

There are probably other ways and tools to perform the same operations, but I have been using this one for some times now and I have never been disappointed!

The fact that the Localization suite comes with 3 different applications can confuse the user at the beginning (especially when you have to export / import from / to the Localization manager and the Localizer), but once you got it, it is pretty straight forward!

Note that the Localization suite works with localized XIB files too.