vendredi 8 février 2013

Naming convention for software version

To identify a source code version is a good way to save time during development, test, and deployment phases.
Without it, it is difficult to communicate with all the collaborators, developers, software testers, and final users.

Choosing a naming convention for source code version makes project status easier to control.


Convention de nommage des versions de logiciel

Savoir identifier la version d'un logiciel permet de gagner énormément de temps lors des phases de développement, de test et des différentes phases de mise en production.
Sans cette identification, il est difficile de communiquer avec les différents acteurs d'un projet : les développeurs, les testeurs, jusqu'aux utilisateurs finaux.

En conventionnant le nommage, on assure une compréhension plus rapide de l'état d'un projet.

mardi 5 février 2013

Gérer les différentes versions de ses librairies sous Windows

For an english version of this article, follow this link : http://antoine-agthe.blogspot.com/2013/02/deal-with-different-libraries-versions.html

Comme beaucoup de développeurs, il se peut que j'intervienne sur plusieurs projets en même temps, chacun d'eux exploitant différentes librairies.
La plupart des développeurs travaillent sur plusieurs plateformes, utilisant haXe/NME, Actionscript pour Flash/AIR, Cocos2D, Starling Framework, Apache Ant … ce qui brasse un nombreux important de répertoires de SDK, de frameworks, ou de librairies.

En parallèle, je dois tester de nouvelles versions de librairies sur des projets existants, ou sur de petits prototypes, donc je dois rendre disponible chaque version de chaque librairie afin de ne pas casser tous les projets en cours.

Les développeurs sous Linux ont pour habitude de tirer partie d'une gestion commune des librairies et de leurs versions.
Les programmes partagent naturellement leurs librairies dans des dossiers communs nommés liblib32 et lib64.
Pourtant tous les programmes n'utilisent la même version d'un lib.
Pour s'y retrouver facilement, ils utilisent une ligne commande ln qui crée un lien symbolique sur un fichier ou un dossier..

Un lien symbolique est comme un raccourci sous Windows, mais en plus puissant !

Pour bien comprendre la nuance entre un lien symbolique et un raccourci, il faut suivre les étapes suivante sous Windows.


  • Créez un dossier nommé my_real_folder
  • Un clic droit, et créez un raccourci que l'on nommera  my_shortcut
  • Double cliquez sur my_shortcut.
  • Vérifiez la barre d'adresse. Vous êtes dans my_real_folder.
Windows ouvre automatiquement le dossier spécifié dans le raccourci. Si vous prêtez attention à ces dossier et raccourci en ligne de commande, vous verrez qu'un raccourci est un simple fichier LNK.
Si vous tentez d'ouvrir my_shortcut comme un dossier, vous aurez une erreur ("Nom de répertoire non valide")

CECI est la grande différence entre les raccourcis et les liens symboliques.

Les liens symboliques sont gérés par le système de fichier. Ce n'est pas un fichier produit par le système d'exploitation. Le lien symbolique se comporte tout à fait comme le fichier ou le dossier auquel il fait référence.

Comment créer des liens symboliques sous Windows ?
Vous devez utiliser le mode shell (cmd) en mode administrateur, et appeler la commande mklink.

mklink permet de créer des "raccourcis" au niveau système de fichier, vers un fichier ou un dossier comme le fait ln sous Linux.
La grande différence avec ln, est qu'il faut spécifier /D si on veut référencer un dossier :

mklink /D <link> <target>

Retournons sur notre exemple précédent pour créer un lien symbolique au dossier my_real_folder, que l'on nommera my_ref_folder.
Il suffit de faire :

mklink /D my_reference_folder my_real_folder

Utilisez dir pour lister les fichiers.

Vous pouvez voir que le lien n'est pas un simple fichier, mais une entité différente du système de fichier.
Utilisez maintenant cd pour entrer dans le lien.
Dans le prompt, vous pouvez voir que le système de fichier entre vraiment dans la référence, au lieu de faire une redirection.

Ça fonctionne aussi dans l'interface graphique, où on peut voir deux différences :
  • La dossier dans la barre d'adresse est bien le lien symbolique
  • Le dossier référence est visible dans le volet de gauche, alors que le raccourci ne l'est pas.

Grâce à mklink, vous donc pouvez créer un dossier lib à la manière de Linux, sous Windows.

Par exemple :
Vous avez développé des projets avec Adobe Flex 3.2.0, Adobe Flex 3.4.0 et Adobe Flex 3.4.1.
Vous développez à présent des projets avec Adobe Flex 4.6.0.
Enfin, vous souhaitez tester Apache Flex 4.9.0.

Vous pouvez créer différents liens symboliques pointant sur chaque version majeure et mineure de vos librairies, comme je l'ai fait.

Sur ce screenshot, vous pouvez voir :

  • flex-4.9.0 est référencé par flex-4.9
  • flex-4.9 est référencé par flex-4
  • et flex-4 est référencé par flex
Grâce à cette technique, si je veux créer un projet Flex 4, je peux utiliser la référence flex-4 dans ma configuration de projet.
Quand Apache Flex 4.10 sortira, je n'aurais qu'à recréer les liens symboliques et tous mes projets utilisant flex-4 en bénéficieront.



Si vous voulez utiliser une version plus précise de la librairie, il reste possible d'utiliser les dossiers réels.

Cette façon de gérer les SDKs et les librairies n'est pas la seule. Vous pouvez regrouper les différentes librairies dans un dossier spécifique à chaque langage, à chaque technologie. La technique que je décris est celle que j'utilise, et ça fonctionne plutôt bien.

lundi 4 février 2013

Deal with different libraries versions on Windows

Pour une version française de l'article, cliquez sur ce lien : http://antoine-agthe.blogspot.com/2013/02/gerer-les-differentes-versions-de-ses.html

As many developers I have to deal with a lot of projects at the same time, each of them using quite different libraries.
Most developers work on multiplatform projects using haXe/NME, Actionscript Flash/AIR, Cocos2D, Starling Framework, Apache Ant … That means a lot of SDK/framework/library folders.

In parallel, I have to test some new library versions on existing projects, or experiment them on small prototypes, so I have to keep every single version of each library in order not to break any WIP projects.

Linux developers usually take benefits of a common way to manage libraries and versions.
Programs usually share their libraries in common folders called lib, lib32 and lib64.
But all the programs don't use the same version of their libraries.
In order to manage different versions, it is possible to use a simple command-line tool called ln that creates a symbolic reference of a folder, or a file.

A symbolic reference is like a shortcut on Windows, but more powerful.

In order to understand the difference between a symbolic reference and a simple shortcut, just follow these steps on your Windows OS.


  • Create a new folder called my_real_folder
  • Right click on it and create a shortcut that you'll rename my_shortcut
  • Then double click to my_shortcut.
  • Check the address bar. You're in my_real_folder.
Windows automatically open the folder specified in the shortcut. If you take a look on these folder and shortcut with cmd, you'll see that your shortcut is a LNK file.
If you try to open my_shortcut as a folder, an error will occur ("invalid folder name", or something like that)

THAT is the big difference between shortcuts and symbolic references.

Symbolic references are managed by the file system. It is not a simple link file produced by the operating system. A symbolic reference behaves AS the file or folder it's linked with.

How to create symbolic references on Windows ?
You have to use the cmd shell in administrator mode, and call the mklink command-line program.

mklink allows you to create a file-system-level reference on a file or a folder, as ln does on Linux.
The big difference with ln, is that you have to specify the /D parameter if you want to reference a folder:

mklink /D <link> <target>

We'll go back to our example and use this command to create a reference of our my_real_folder, that we'll name my_ref_folder.
All you have to do is tip :

mklink /D my_reference_folder my_real_folder

Then use dir to list files.

You can see that the reference is not a simple file, but a completely different entity in the file system.
Then use cd to enter the reference folder.
In the prompt, you can see that the file system really enters the reference folder, instead of doing a visible redirection.

It also works on your graphical interface, where you can see two things:
  • The folder in the address bar is the reference folder
  • The reference folder is visible in the folder exploration on the left, while folder shortcut is not.


Thanks to mklink, you can create a Linux lib-like folder on Windows.

For example:
You developed some projects with Adobe Flex 3.2.0, Adobe Flex 3.4.0 and Adobe Flex 3.4.1.
You currently develop some projects with Adobe Flex 4.6.0.
At least, I want to experiment Apache Flex 4.9.0.

You can create several folder references to point major and minor versions of your librairies, as I did.

On this screenshot, you can see that:

  • flex-4.9.0 is referenced by flex-4.9
  • flex-4.9 is referenced by flex-4
  • and flex-4 is referenced by flex
Thanks to this technique, if I want to create a Flex 4 project, I can use flex-4 reference in my project configuration.
When Apache Flex 4.10 will be released, I just will recreate my references and all my projects using flex-4 reference will be updated.



If you want to use a more precise version of a tool, it is still possible if you use real folders.

This way to manage SDKs and librairies is not the only one. You can regroup libraries in a language or technology specific folder. The one I describe is the one I use, and it works great.