bool SIM_FoodMemory::IsBoringChoice(std::string foodname)
{
	//return true if we ate the same food more than once in the last 14 days
	int recentmatches = 0;
	iter it;
	for(it = Items.begin(); it != Items.end(); ++it)
	{
		SIM_FoodMemoryItem* pitem = *it;
		if(pitem->FoodName == foodname)
		{
			int diff = SIM_GetSim()->GetTurnCount() - pitem->TurnConsumed;
			if(diff < 14)
			{
				recentmatches++;
			}
		}
	}

	if(recentmatches > 1)
	{
		return true;
	}
	else
	{
		return false;
	}
}

Autant vous le dire tout de suite, ce bout de code ne me plait pas du tout. Si l’on fait une remarque sur ce genre de code, beaucoup de coders sortent leur carte anti-troll ; « les goûts et les couleurs, ça ne se discute pas » ainsi que l’autre carte souvent utilisée ; « pas grave, ce n’est pas ‘time critic’ ».

Mais est-ce que ces 2 cartes devraient tout autoriser ? Alors sous ces 2 prétextes, on peut faire tout et n’importe quoi ? Je suis désolé, mais je ne suis pas d’accord.

Prenons le cas de la classe string qui est passé en paramètre, on est loin du débat « est-ce que ++i est mieux que i++ » ! Même si la fonction n’est pas ‘time critic’, passer une classe string comme cela entraine non seulement un overhead de code mais surtout, des allocations/désallocations mémoire! Il faut allouer la classe sur la pile, appeler le ctor, allouer la mémoire pour la chaine de caractère, la copier, et, à la fin, la désalouer. En plus de prendre du temps CPU, ça fragmente la mémoire, ce qui peut avoir des effets réellement génants.

Maintenant le fait de ne pas utiliser de const ? Mettre un header SIM_ au lieu d’utiliser un namespace ? Ce code montre très clairement que c’est un ancien programmeur C et qu’il ne maitrise pas des concepts basiques du C++ et continue à utiliser ses anciennes habitudes du C.

Tout le monde fait des erreurs, tout le monde a tendance à faire comme il a toujours fait, c’est humain. Ce qui me dérange plus, c’est la réaction, plutôt que d’accepter qu’il y ait un problème et le corriger, le programmeur se réfugie derrière le “c’est pas grave, les gouts et les couleurs… c’est pas time critic…”. Comment évoluer, s’améliorer dans ces conditions ?

Pour finir, voilà comment, moi, j’aurais surement écrit ce bout de code (ce n’est pas du tout pour montrer la solution parfaite, mais juste pour jouer le jeu) :

using namespace std;
namespace SIM {
bool FoodMemory::isBoringChoice(const string &foodname) const
{
	int recentmatches = 0;
	for(iter it = Items.begin(); it != Items.end(); it++)
	{
		FoodMemoryItem *item = *it;
		if(item->FoodName == foodname)
		{
			int diff = sim()->turnCount() - item->TurnConsumed;
			if(diff < 14) recentmatches++;
		}
	}

	return (recentmatches > 1);
}

J’ai clairement un style plus compact, j’ai fait exprès de ne pas changer l’algo sinon j’aurais fait directement un return dans le if pour casser la boucle ‘for’ le plus tôt possible.

Et comme je suis curieux, vous l’auriez écrit comment vous ?

Par contre avec la sortie de Mtp Target sous GNU/Linux, je me suis lancé dans quelque chose de nouveau ; la distribution d’un logiciel sous GNU/Linux.

Sous Windows, j’ai l’habitude, un coup de NSIS pour faire l’installer et le tour est joué. Bon, ce n’est pas aussi simple, il faut gérer les problèmes sous VISTA, les problèmes de directX et beaucoup d’autres petits soucis, mais je gère.

La question était donc : comment faire pour que Mtp Target soit jouable par tous les Linuxiens.

La première piste était de faire comme sous Windows ; un installer. Il en existe un certain nombre qui marche plutôt pas mal. Le plus simple est makeself, c’est celui qui est utilisé par Id Software et nVidia. C’est en ligne de commande, on exécute, ça déarchive et exécute un script si nécessaire.

Sauf que voilà, le gros problème est que lorsque l’on télécharge un programme sous GNU/Linux, les droits d’origine ne sont pas gardés, donc on se retrouve avec un programme sans le bit d’exécution et quand on double clique dessus, ça l’ouvre dans un éditeur de texte ! Il faut que l’utilisateur s’y connaisse pour ajouter le bit d’exécution et ensuite l’exécuter. La raison invoquée est que c’est une question de sécurité. Un utilisateur pourrait télécharger un programme sans le faire exprès et l’exécuter.

La solution choisie par Mozilla est de créer une archive “.tar.bz2″. L’avantage est qu’il suffit de double cliquer sur l’archive pour que ça l’ouvre grâce au logiciel associé. Ensuite, l’utilisateur drag&drop le répertorie contenu dans l’archive où il le souhaite et il peut exécuter ce qui va bien. Je ne trouve pas que ça soit l’extase, mais au moins ça marche sans bidouiller, car les droits sont gardés dans l’archive.

Autre problème, impossible d’associer une icône à l’exécutable. Encore une fois, la raison invoquée est la sécurité (oui, sinon on pourrait mettre une icône d’un autre logiciel pour se faire passer pour celui çi). Mais bonne nouvelle, il est possible de créer une sorte de raccourci à la Windows, c’est un fichier texte qui contient le path vers l’exe, une icône, etc. Super ! Sauf qu’en fait non, c’est naze, on ne peut pas mettre de chemin relatif vers l’exe!!! Ca serait trop simple, on peut pas faire : path=bin/myexe, il faut un chemin absolu, sauf que bien sûr, comme l’utilisateur peut extraire le jeu n’importe où, il est impossible de créer ce fichier, donc retour à la case départ, pas d’icône.

Problème suivant ; mon jeu utilise une lib dynamique, FMod. Sous Windows, c’est simple, l’exe va automatiquement chercher les lib dynamiques dans un ordre précis, d’abord dans le répertoire courant, puis dans des répertoires spécifiques. Sous GNU/Linux? Il cherche dans les chemins définis dans la variable d’environnement LD_LIBRARY_PATH. Il est donc impossible de lancer le jeu directement, car il ne trouve pas la lib dynamique. Il faut donc écrire un script Shell qui va ajouter le chemin courant dans LD_LIBRARY_PATH puis exécuter le jeu. Sauf que c’est un script, et donc quand on double clique dessus, ça pop une message box demandant à l’utilisateur s’il veut l’exécuter, l’éditer, etc. Malgré le bit d’exécution !

Dernier souci ; la portabilité. Si je veux que le jeu marche sur un maximum de distribution GNU/Linux, il faut que je limite les dépendances avec les librairies externes. Chaque dépendance risque de poser un problème, car chaque distribution a sa propre version de chaque librairie. Il faut donc *tout* compiler en librairies statiques.

Dans les versions récentes de gcc, le compilateur ajoute un système de stack check pour limiter les bugs, sauf que, pas de bol, il faut la GLIBC 2.4 pour que cela fonctionne, sauf que ce n’est pas très répandu encore. Donc tous les utilisateurs qui tournent sur des distribs avec la GLIBC inférieure à 2.4 ne pourront lancer le jeu. Après une grosse prise de tête, j’ai enfin trouvé le moyen de retirer ce système et donc retirer les symboles dépendants de la GLIBC 2.4. Ouf…

Après tous ces problèmes, j’ai finalement réussi à faire un package unique qui fonctionne sur quasiment toutes les distribs GNU/Linux!

J’ai toujours le problème du script qui ne veut pas se lancer automatiquement quand on double clique dessus. Toujours pas d’icône associée au script. Pas de version 64bits (mais ça marche bien avec l’émulation automatique). Pas d’ajout du jeu dans le menu… La solution ultime serait peut-être un tar.bz2 qui contient un installer mais ça ne règlera pas tous les problèmes.

Quand je discute avec des fans de GNU/Linux, leur réponse est toujours la même, c’est naze ce que tu fais, la bonne façon de faire est de créer un package. Sauf que le système de package est différent sur chaque distrib! Ça veut dire que si je veux que mon jeu soit disponible partout, je dois créer une bonne 10ène de version du jeu ! C’est vrai que c’est mieux intégré, mais ça demande un boulot monstre. Prenons par exemple le simple cas de la distrib Debian, si je veux que tous les utilisateurs Debian puissent jouer à Mtp Target, il faudrait que je fasse un package debian, sauf qu’il y a plusieurs versions de Debian, etch, lenny, sarge, woody… Donc, il faudrait en théorie faire autant de package que de version de Debian, donc au moins 3 pour Debian. Je vous laisse imaginer le boulot (nombre de distrib * nombre de versions par distrib)!

Peut-être qu’un jour il y aura assez de monde dans la communauté de Mtp Target pour faire ce boulot, mais ce n’est pas quelque chose que je peux faire tout seul. Mon système n’est pas parfait, mais il permet au moins à tout le monde sous GNU/Linux de jouer à Mtp Target sans dépendre d’une distrib ou d’une version de distrib. Je n’ai à ce jour aucun linuxien qui est venu me voir en disant que ça ne marche pas chez lui.

Je profite de cette occasion pour faire un ticket sur les jeux vidéo libres. Voici les différentes catégories :

Les jeux développés sur le temps libre

Ça représente surement 95% des jeux libres. Ils sont très souvent développés par des étudiants qui ont beaucoup de temps libres (forcement, ce sont des geeks) et qui veulent faire un jeu parce que c’est fun (oui, ce sont des geeks, ils n’ont pas la même notion du fun que les gens normaux).

Ça part toujours d’une très bonne intention, les développeurs se démènent pour faire un programme clean, se focalise sur le dernier design pattern, le dernier moteur 3D libre et rédigent des game designs. Ils sont super contents, motivés, en une semaine ils arrivent à ouvrir une fenêtre 3D et à afficher un triangle rouge au milieu.

Au bout d’un an, à force de boulot acharné, ils n’ont rien à montrer si ce n’est une fenêtre 3D qui s’ouvrent avec un triangle au milieu (mais qui tourne !) et un doc de 500 pages décrivant un jeu tellement complexe que même la NASA ne comprendrait pas les spécifications. Quelques fois, ils arrivent à amener quelques potes de classe sur le projet et arrivent à faire quelque chose de jouable. Mais ces projets tombent très souvent à l’eau, non pas qu’ils soient mauvais mais par manque de temps. L’étudiant découvre les boites de nuits et les filles (non, c’est pour rire, c’est un geek !). Je veux dire l’étudiant trouve un travail et n’a plus le courage le soir et le weekend de passer encore du temps sur ce satané bug introuvable (et oui, le dernier design pattern n’a finalement pas suffit à éviter les bugs).

Les jeux tellement vieux qu’il faut ressortir l’Atari pour les compiler

Bon ok, j’exagère, mais c’est un peu ça quand même. Les seuls jeux produits par l’industrie du jeu vidéo et qui sont libres aujourd’hui sont ceux qui sont tellement vieux que de toute façon ils ne peuvent plus espérer les vendre (même pas dans les boites de Frosties). C’est le cas par exemple de Quake. 5 ou 6 ans après la sortie, quand la technologie est complètement dépassée et que le code source n’a plus aucun intérêt compétitif, le studio le passe en licence libre pour se faire un coup de pub. C’est clairement mieux que rien. L’avantage est que ce sont des jeux beaucoup plus connus et donc qui attirent beaucoup de geeks qui veulent voir comment ça a été codé (QUOI ? ça a été codé sans design pattern? Comment ont-ils pu en vendre des millions ?). C’est très instructif et toute une ribambelle de geek bidouillent le code pour le fun en faisant une version pour iPhone, une pour le C64 et une autre avec des design patterns parce que c’est quand même mieux comme ça.

3ème catégorie de jeux libre… Euh… bah en fait, il n’y en a pas.

Dans de très rares cas, les jeux développés sur le temps libre attirent d’autres geeks et deviennent connus (TuxRacer par exemple). Dans d’autres rares cas, un groupe de geeks se réunit autour d’un ancien jeu close source et fait un super mod (Warsow par exemple) mais dans la grande majorité des cas, ce n’est pas fameux et on se retrouve avec 90% des jeux complètement injouables, pas fun et sans intérêt… tant d’énergie perdue…

On peut s’étonner de voir de superbes applications libres comme GNU/Linux, Open Office, Firefox et si peu de bons jeux (et encore moins de jeux originaux). C’est d’autant plus étrange que faire un jeu est souvent un rêve de geek.

Je pense qu’une des raisons à cela est que les geeks ont tous une idée différente de jeu révolutionnaire et donc que chacun veut développer son jeu dans son coin et n’arrive à rien car il est tout seul. Une autre raison est que les geeks misent beaucoup trop de temps sur la technologie et les docs. Combien de fois j’ai discuté avec des geeks qui veulent faire “un MMORPG où on sera libre de faire toute ce qu’on veut dans un monde 3D avec de la physique qui tue tellement c’est réaliste, qu’à coté, Second Life c’est du pipi de chat.” (c) Je n’ai rencontré que si peu de geeks pragmatiques. Je pense que ceux qui arrivent à faire de bons jeux libres aujourd’hui sont justement ceux là, les pragmatiques. Des personnes qui savent à quel point c’est complexe de réaliser un jeu et donc qui se donnent un objectif simpliste, sur un gameplay extrêmement simple et efficace. Et une fois cette version lancée, fonctionnelle et amusante alors d’autres geeks tomberont peut être dessus, trouveront l’idée sympa et rejoindront le projet pour l’améliorer. Alors une version améliorée sortira et ainsi de suite jusqu’à arriver à un jeu vraiment bien.

Je trouve dommage qu’il y ait si peu de bons jeux dans le logiciel libre alors que tous les ingrédients sont présents. Je trouve encore plus dommage qu’aucun studio ne s’intéresse au logiciel libre alors que tout le monde sait qu’un bon jeu est avant tout un game play original et fun et non un moteur 3D nouvelle génération. Ce n’est pas le code source du jeu qui fait vendre, c’est le fun du jeu. Si l’industrie du jeux vidéo partageait son code, elle pourrait baisser ses coûts de développement et surtout aurait plus de temps pour se concentrer sur le fun et l’originalité de leur jeu ce qui serait positif pour tout le monde et surtout, les joueurs.

Ce dont je suis convaincu, c’est qu’il est aujourd’hui possible de développer des jeux vidéo libres (et même gratuits) et d’en vivre et je suis là pour tenter de vous le prouver à tous avec Mtp Target

Il prend l’exemple des outils de source control et je ne peux qu’être d’accord avec lui… J’ai eu l’occasion de voir un bon nombre de projets utilisant des sources control et à chaque fois c’était un désastre ! Aucune discipline n’est apportée sur l’arborescence des répertoires alors que c’est la base du projet, ses fondations. Le problème principal est que personne ne s’intéresse à ce sujet, chacun met ses fichiers où il veut et s’il ne sait pas où, il va surement créer un répertoire quelque part portant son nom. Il y a ceux qui vont créer un répertoire par classe, d’autres qui vont tout mettre en vrac dans un même répertoire, après tout, on s’en fiche du moment que ça compile et que ça se lance !

Quelque chose qui m’horripile encore plus, c’est la nomenclature des noms de fichiers. Vous êtes vous déjà posé la question sur comment vous nommez vos fichiers ? En français ? En anglais ? En minuscule ? En majuscule ? Peu importe ? Pas tant que ça…

Par exemple, accepter les espaces dans les noms de fichiers peut devenir une réelle galère pour les programmeurs et peut entrainer un bon nombre de bugs.

Accepter les majuscules ne pose pas de problèmes sous Windows, car il ne fait pas la différence, mais si pour une raison quelconque vous devez faire fonctionner un outil sous Linux, alors vous allez le regretter. J’ai pu voir des projets où les règles de nommage des fichiers étaient différentes en fonction du programmeur. Il y avait des MyClass.h yourClass.h voir même des his_Class.h. Mais lors de l’inclusion dans le code avec la directive #include, les majuscules ne correspondaient pas. Ça marche très bien sous Windows mais aucune chance que ça passe sous Linux et vous êtes alors bon pour repasser sur tous les #include du code source. L’autre gros problème est pour les nouveaux programmeurs : comment peut-il s’y retrouver ? Un coup il y a un _, un autre coup non, en gros il faut apprendre par cœur le nom de chaque fichier !

Vous pouvez dire que c’est ce qui arrive fatalement quand on a une grosse équipe ou alors quand on engage des gens incompétents mais en fait non. Regardons ce projet développé par 2 programmeurs talentueux et expérimentés qui viennent de créer un studio ensemble dans le but de réaliser le projet de leurs rêves. Le projet a commencé il y a moins d’un an, et ils ne sont que 2. Ils s’amusent à afficher leurs commits alors profitons-en pour essayer de trouver les règles de nommage des fichiers et répertoires qu’ils ont mis en place :

• Règle 1: Nommage des répertoires et des code sources : une majuscule pour la première lettre de chaque mot et le reste en minuscule.
• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _.
• Règle 3: Nommage des répertoires des assets graphiques: c’est la que ça se complique… Il semblerait que ça soit la règle 1 pour les 2 premiers répertoires, puis la règle 2 pour les répertoires suivants.

Regardons maintenant un autre commit qu’ils ont fait sur le même projet quelques mois auparavant :

AIE. Il semblerait que ma règle 2 ne soit pas correcte, en fait il faut la modifier comme ça :

• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _ ou des - en fonction du sens du vent (où tout autre paramètre aléatoire).

Imaginez, ils ne sont que 2 ! des ingénieurs avec l’esprit cartésien ! et au bout de quelques mois on ne peut déjà plus décrire le nommage des fichiers/répertoires avec des règles simples. Qu’est ce que ça va devenir dans 1 an, ou quand il y aura des nouveaux dans l’équipe ?

Pourtant, il existe une règle simple qu’en général les programmeurs aiment bien : KISS (Keep It Simple, Stupid). Mais pour je ne sais quelle raison, ils ne l’appliquent que pour la programmation.

À mes débuts à Nevrax, pour le développement d’un MMORPG Windows/Linux, j’avais proposé une règle très simple suivant justement le principe KISS en partant du principe que plus les règles seront simples, plus il y a de chance que les gens la connaitront et la suivront.

• Règle 1: Nommage de tous les fichiers et tous les répertoires : uniquement des caractères alphanumériques en minuscule, les mots étant séparés par des _. Pour les geeks, on peut résumer ça en [a-z0-9_]+
• Règle 2: pas de règle 2…

On peut difficilement faire plus simple, ça évitait tous les problèmes des espaces, des majuscules et des caractères bizarres. Bien que cette règle soit simple et rabâchée depuis le début du projet, un certain nombre de programmeurs n’arrivaient pas (ou ne voulaient pas) la suivre et mettaient des noms de fichiers qui ne suivaient pas cette règle. Mais le pire a été avec les graphistes, designers, sound designers… Ils ne voulaient pas se plier à cette règle et voulaient continuer à faire comme ils faisaient avant (c’est à dire sans règles, au gré des humeurs). Pour éviter des conflits trop violents, il a été décidé de n’appliquer la règle que pour le code source et ce fut une belle erreur. Pendant des années on a du ajouter des bouts de code (rustines) dans les tools, sous Linux uniquement pour gérer des cas particuliers dans les noms fichiers et répertoires parcequ’ils ne voulaient pas se plier à cette règle simple. Il est même arrivé de devoir mettre des rustines dans des outils qui fonctionnaient parfaitement bien depuis 4 ans parce qu’une personne avait trouvé un nouveau moyen fun de nommer les répertoires qui cassait le peu de logique qui restait dans l’arborescence des datas.

Autant je comprends que les gens soient réticents à suivre des règles complexes ou qui n’ont pas de sens. Mais je ne comprends toujours pas pourquoi autant de personnes ont protesté si fortement contre une règle simple qui aurait mis de la discipline dans le source control et aurait rendu la vie tellement plus simple à tous.

Tout d’abord, il faut définir ce qu’est un “bon programmeur”. Selon moi, avoir un diplôme reconnu n’est pas un critère, connaître par coeur les puissances de 2 jusqu’à 2 puissance 32 non plus. Je définirais un bon programmeur comme quelqu’un d’extrêmement curieux, qui maîtrise ce qu’il fait, qui a une très bonne capacité d’écoute et de résolution de problèmes techniques. Il doit aussi être capable de se remettre en question, aimer travailler en équipe et être capable de finir ce qu’il commence.

Dans les 95 % des entreprises, on est confronté à l’un de ces scénarios :

- Si l’entreprise a de la chance, quelques bons ingénieurs vont être recrutés par erreur et se retrouveront au milieu d’une grande majorité d’ingénieurs qu’ils trouveront incompétents. Ces bons ingénieurs ont toutes les chances de vite quitter la société, car un bon ingénieur a besoin de trouver dans son environnement de travail des gens au moins aussi bons que lui. La société ne se retrouvera donc rapidement plus qu’avec des ingénieurs de niveau moyen ou mauvais et cela reviendra au cas suivant.

- Si l’entreprise n’a pas de chance, elle ne recrutera que des ingénieurs moyens ou incompétents. Pour que cela fonctionne quand même un minimum, la solution choisie est souvent de les encadrer de très près par des managers. Le problème est que ces managers n’ont aucune raison d’être mieux recrutés que les ingénieurs et donc sont du même niveau de compétence. Il faut alors mettre en place une énorme hiérarchie où tout le monde surveille tout le monde et où personne n’ose plus rien faire de peur de se faire taper sur les doigts par son chef… Dans ces entreprises, les managers mettent alors en place des méthodologies très lourdes et complexes avec beaucoup de paperasse, de planning, etc., pour essayer de se protéger en cas de problème et pouvoir rejeter la faute sur quelqu’un d’autre. On pourrait croire que ce genre de scénario n’arrive que dans les grosses sociétés, mais j’ai pu rencontrer des PME avec ce schéma (par exemple 6 ingénieurs pour 4 managers). Autant dire tout de suite, dans ces entreprises, les ingénieurs n’ont aucune reconnaissance. Ils sont vus comme le bas de l’échelle, les ouvriers, les moins bien payés, ceux qui sont à l’origine de tous les problèmes (retards, bugs, mauvaise qualité, …). Ils sont souvent considérés comme des gens qu’on peut remplacer comme on remplacerait une roue sur une voiture. Bref, il est évident que l’effet le plus indésirable de cette organisation est que l’ingénieur se trouve à détester sa position et va tout faire pour, soit partir, soit monter dans la hiérarchie pour gagner plus d’argent et arrêter de se sentir un moins que rien. Évidemment, on va vite se retrouver avec une énorme compétition entre ingénieurs, car le nombre de place de chef est inférieur au nombre de place d’ingénieur (enfin normalement). Ca crée alors des conflits d’intérêts, des histoires politiques entre équipes et les ingénieurs passent plus de temps à essayer de bien se faire voir par leurs chefs plutôt qu’à faire du bon code. Autre problème, c’est l’organisation idéale pour rencontrer le principe de Peter.

Dans ce genre d’entreprises, passer aux méthodes agiles où n’importe quelle autre méthode ne servira à rien, car c’est un problème de fond, un problème culturel où seule une prise de conscience de la part du boss peut prétendre à une amélioration. Mais même dans ce cas, il serait très long et très compliqué de faire des changements de fond, car cela nécessiterait forcément des licenciements, de remettre des managers en programmeurs et souvent les esprits sont trop habitués à la culture de leur entreprise et considèreraient ça comme un affront. Bref, je ne pense pas que ça soit réellement possible de changer une culture d’entreprise, car les personnes sont recrutées en général parce qu’ils partagent justement cette culture.

Maintenant, prenons le cas des 5 % restants (et encore, je crois que je suis gentil, je dirais plutôt 1 %), ce sont des sociétés où le recrutement est une partie primordiale et ils feront tout ce qui est nécessaire (ne pas céder à la pression, mettre les budgets et le temps nécessaire) pour ne pas laisser entrer dans leur société des individus qui ne correspondent pas. L’idée de base est la suivante : “On ne recrute que des gens vraiment intelligents, ou on ne recrute pas.” Dans ce genre de société, le recrutement est permanent et maximal. Permanent, car ces ingénieurs vraiment intelligents sont difficiles à trouver et souvent déjà en poste, si on ne recrute que 2 mois dans l’année, la probabilité de tomber dessus est très faible. Maximal, car pour être vu par les meilleurs, il faut se faire voir. C’est exactement la même chose que pour vendre un produit à un client sauf que dans ce cas, le produit c’est la société et le client est l’ingénieur talentueux. Et comme ils savent qu’ils sont bons, ils sont difficiles et veulent aller dans des sociétés où ils se sentiront vraiment bien. Comment réussir toucher ce genre de personnes mériterait un sujet à part entière (JoelOnSoftware en à déjà parlé). Cela n’est pas gratuit, ça coûte même cher à une entreprise aussi bien en temps (car il faut des gens pour faire passer les entretiens) qu’en argent. Mais c’est un investissement qui sera extrêmement rentable sur le long terme.

Une fois que vous avez réussi à attirer les meilleurs, il faut savoir faire le tri et c’est là qu’intervient l’entretien. Comment faire passer un bon entretien ? Encore une fois, ça mériterait un article complet (vous pouvez lire ça).

Supposons que la structure est en place pour ne recruter que des bons ingénieurs, qu’est ce que ça change ? Tout d’abord, vous pouvez avoir une confiance beaucoup plus importante dans ces personnes. Vous n’avez pas à fliquer leurs horaires de travail (ils en feront même surement beaucoup plus que la normale sans même le demander), à vérifier s’ils bossent vraiment ou s’ils se tournent les pouces, etc. Bref, vous pouvez alléger au maximum la hiérarchie. Du côté des ingénieurs, ils sont beaucoup plus contents, car ils sentent qu’on leur fait confiance, ils sont beaucoup plus libres et le résultat est qu’ils bosseront beaucoup mieux et qu’ils ne voudront pas aller voir ailleurs. En plus, ces ingénieurs se retrouvent avec d’autres bons ingénieurs, ils se comprennent, s’entraident, se respectent plus facilement. Ils ne vont pas se prendre la tête pour savoir s’il faut mettre des espaces ou des tabulations, s’il faut faire des tests unitaires ou pas, car ils sont assez intelligents et ont assez d’expérience pour savoir ce qu’il en retourne et où se situent les vrais problèmes.

Donc dans ces sociétés, la hiérarchie est réduite à son minimum, il y a des ingénieurs qui programment, des lead ingénieurs qui sont aussi très techniques, mais qui peuvent facilement gérer 10 à 20 personnes, car les méthodes de travail peuvent elles aussi être très simplifiées. Pour que cela fonctionne, il faut évidement savoir mettre l’argent où il faut, par exemple ne pas lésiner sur les locaux, les ordinateurs, les tables, chaises, etc. Plus l’environnement sera agréable, plus il y a de chances que l’ambiance y soit bonne et donc que les gens y travaillent bien.

Ça peut paraître simple de mettre en place ce genre d’équipes, mais ce n’est clairement pas le cas. Tout d’abord, les lois de la concurrence, la pression des investisseurs, le manque d’ingénieurs sur le marché du travail font que les boss ont souvent tendance à vouloir recruter au plus vite, quitte à ne pas suivre la règle de base en pensant qu’après tout, ce n’est pas si grave que ça, on verra plus tard. Au début, ça marche bien, car la boite est petite, mais au fur et à mesure que des personnes peu compétentes arrivent, les problèmes arrivent par la même occasion et l’entreprise tombe dans les 95 %. L’autre problème est que les fondateurs/boss ont beaucoup de mal à mettre de l’argent sur quelque chose qui n’est pas rentable à très court terme (le problème du bûcheron). Ils prendront les chaises premier prix qui font mal au dos sans penser que derrière cela augmentera le turn-over (qui veut passer 8 heures ou plus sur une chaise inconfortable?) qui au final coûtera beaucoup plus cher que d’avoir mis des fauteuils corrects dès le début (l’exemple de la chaise vous parait peut-être exagéré pourtant c’est du vécu et des histoires comme celle-là, j’en ai vu tellement d’autres…).

Le meilleur exemple d’entreprise qui utilise la 2ème méthode est Google. Bizarrement, ils sont devenus la boite la plus recherchée par les ingénieurs et c’est aussi une société qui fait beaucoup d’argent. Je suis convaincu que leur réussite tient d’abord à leurs méthodes de recrutement et leur culture d’entreprise. Je suis aussi convaincu que même s’ils n’avaient pas eu l’idée de faire un moteur de recherche ou un business sur Internet, ils auraient obtenu un résultat similaire dans une autre industrie.

Vous allez me dire que c’est facile pour eux, ils ont énormément argent, mais ils ont commencé à moins de 10 personnes et ont tout bâti eux même. C’est avant tout leur façon de construire la société (et donc l’équipe) qui leur a permis d’arriver là où ils sont aujourd’hui.

Un autre exemple d’une entreprise qui suit ces principes est FogCreek. C’est une petite société qui ne fait que grossir, doucement, mais sûrement. Ils ont un peu la même philosophie que Google, mais avec seulement une 20aine de personnes. Cette boite a toujours été rentable. Ils suivent la règle d’or qui dit que si on recrute les bonnes personnes, quel que soit le projet qui sera choisi, il sera rentable. Et ils le prouve par exemple avec leur bugtracker. Il existe des 10aines de bugtracker différents, dont beaucoup de gratuits, mais bien que le leur soit payant il se vend bien et suffit pour faire vivre la société.

Tout ça pour dire que le processus de recrutement commence dès les premiers jours de la vie d’une entreprise et que de mauvaises méthodes de recrutement risquent d’entrainer par la suite de gros problèmes qui ne pourront pas être rattrapés. Malheureusement, c’est aussi la période où il y a tellement de choses à faire que le recrutement des programmeurs peut être mis au second plan où alors les conséquences du choix de mauvais programmeurs sont clairement sous-estimées.

Je rêve un jour de pouvoir rencontrer des créateurs d’entreprises français assez ouverts pour pouvoir comprendre l’intérêt et le potentiel énorme de ces nouvelles façons de construire et gérer une société informatique. Si vous pensez en être un, n’hésitez pas à me contacter, je serais ravi d’en discuter plus longuement !

Tout d’abord un portable Dell Inspiron 9400. C’est vraiment pratique pour pouvoir bosser n’importe où. C’est un portable avec 2go de RAM, une carte graphique qui boost bien, le seul problème est le disque dur un peu lent lors des compilations.

L’écran du portable me sert d’écran secondaire où je mets le chat de Mtp Target, ce qui me permet de suivre les discussions sur les serveurs. C’est un peu du gâchis d’utiliser un écran 17 pouces 1920×1200 pour seulement ça, mais quand je suis en déplacement, je suis bien content d’avoir un grand écran.

Mon écran principal, un Samsung 206BW est vraiment bien, rien à redire si ce n’est le manque de pied réglable.

Le clavier est vraiment super sympa, c’est un G15 de Logitech. Grâce à un utilitaire que j’ai programmé, l’écran à cristaux liquides du clavier affiche les stats du jeu, à savoir, le nombre de joueurs inscrits, le nombre de joueurs connectés au jeu, le nom du dernier joueur inscrit, le nombre de sujets dans le forum, etc. Un autre truc bien pratique, c’est les 18 touches de fonctions de G1 à G18. Elles sont presque toutes mappées. Par exemple, si je veux un ssh sur mon serveur web, c’est G7, une touche et ça s’ouvre.

Dans le coin en bas à droite de la photo, on trouve un petit disque dur externe pour les backups, un téléphone, un PDA et un GPS. Sur le clavier du portable, c’est un casque Koss. Et pour finir, un tapis souris Ryzom, et un pense bête des commandes de svn sous le clavier.

Tout est posé sur un bureau Ikéa, le même que celui que j’avais à Nevrax, sauf que celui-là est réglable en hauteur avec un moteur. Ne me demandez pas l’intérêt, il était en promo et moins cher que le bureau normal

Un jour, un grand nombre de jeunes joueurs suédois ont débarqué dans le jeu grâce à un site suédois très fréquenté. Ça m’a permis de voir quelques nouveaux caractères avec des accents bizarres sur certaines lettres, mais rien de bien original.

Par contre, cette semaine, un administrateur travaillant dans un FAI m’a proposé de s’occuper d’un serveur de jeu dans le but d’avoir des ping plus bas pour les joueurs de son pays. Ce pays est l’Ouzbékistan. Je ne savais même pas où se trouvait exactement ce pays et je me suis demandé comment ils ont pu entendre parler de Mtp Target.

Historiquement, ils utilisent le charset cyrillique, mais le pays fait beaucoup pour passer au latin. Ils écrivent donc habituellement avec les 2 alphabets.

Tout ça pour voir que ça marche super bien l’unicode J’attends avec hâte des gens voulant héberger des serveurs en Corée, en Chine ou au Japon.

Il y a des jours, j’aimerais vraiment me reconvertir et arrêter l’informatique…

Faire des bugs, c’est normal, tout le monde en fait, mais il y a des fois où les bugs sont vraiment vraiment insupportables et j’en ai un en ce moment qui me nargue et que je n’arrive pas à trouver et voici pourquoi :

- C’est un bug qui se trouve sur la partie serveur de Mtp Target

- Il se produit qu’une fois environ par 24 heures (mais des fois, il ne se produit pas pendant plusieurs jours)

- Il se déclenche aléatoirement et sans aucune raison apparente

- Il fait freezer l’OS (GNU/Linux) sur lequel tourne le serveur de jeu (quand je dis freezer, c’est vraiment freezer, même un reboot soft ne marche pas, il faut éteindre/rallumer le serveur)

- Rien n’apparait dans les logs

- Il se produit uniquement quand des joueurs réels jouent (je peux laisser tourner le serveur avec 16 bots 24/7, le bug n’apparait pas).

- Il se produit sur les 2 serveurs dédibox dont j’ai accès, mais pas sur d’autres serveurs GNU/Linux hébergés ailleurs.

Pas simple hein… J’ai des pistes pour le trouver, mais vu qu’il faut attendre quelques jours à chaque fois, ça avance très lentement et c’est vraiment frustrant. Espérons qu’une de ces pistes m’aidera à éradiquer ce bug une bonne fois pour tout. Je vous tiendrai au courant !

En effet, quand une application est lancée sous le débogueur et que vous appuyez sur la touche F12, ça déclenche automatiquement un point d’arrêt utilisateur (__asm int3). C’est pratique si on veut arrêter rapidement un programme mais quand on veut utiliser cette touche pour déclencher un comportement précis dans l’application, ça devient vite pénible de se retrouver avec le programme bloqué.

Alors oui, une méthode simple, me direz-vous, est de ne pas utiliser la touche F12, mais quand toutes les touches de fonctions sont déjà prises et bien on a pas le choix. De plus, cette touche est bien pratique, car c’est la dernière sur le pavé des touches de fonctions et donc elle est facile d’accès.

J’ai fait le tour sur le net et je me suis aperçu que ça n’avait rien à voir avec Visual Studio, mais que c’était un comportement intrinsèque à Windows !

La bonne nouvelle c’est qu’il est possible de changer la touche qui déclenchera le point d’arrêt utilisateur. Pas mal de sites web expliquent comment faire en mettant un lien sur une page de Microsoft qui n’est plus disponible, alors après des recherches plus approfondies, j’ai enfin trouvé :

Dans la base de registre, il y a le répertoire HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug qui contient 2 variables bien pratiques :

Auto: Par défaut à 1, si on met cette clé à 0, alors le déboguer ne prendra pas la main si un programme plante. (plus d’info…)

UserDebuggerHotKey: Par défaut à 0, cette clé indique quelle touche déclenche le fameux point d’arrêt. 0×0 correspond à la touche F12, et 0×13 à la touche PAUSE qui, je trouve, est plus adaptée pour mettre le programme en pause. Pour la liste complète des touches disponibles et plus d’info, c’est là…

Ah, une dernière chose, comme vous pouvez peut-être vous en doutez, pour que la nouvelle touche soit prise en compte, il faut relancer… Windows… Bon reboot.

Je suis un fan de Google (voir j’ai tendance à idolâtrer un peu trop cette boite) et je voulais absolument être à cette conférence, surtout par curiosité. Google n’a jamais rien fait comme les autres donc je m’attendais à des surprises, des goodies et à être étonné.

Le jour J, j’arrive 15mn avant l’ouverture, on entre dans la cour d’entrée avec les quelques autres participants déjà présents et le premier contact avec Google arrive aussi tôt ; ” On n’est pas prêt, s’il vous plait, retournez dehors dans la rue, ne restez pas dans la cour “. Un peu en retard, Google nous fait finalement prendre notre badge et entrer. On se retrouve avec un stylo, un bloc note et un super pin’s clignotant Google. Sur le coup, je suis un peu déçu niveau goodies, je m’attendais à quelque chose de plus original, mais bon, je ne suis pas venu pour ça. La salle est vraiment sympa, décorée à la Google, avec de belles lumières, des chaises de toutes les couleurs, des coins ” lounge ” avec des gros fauteuils, un coin jeu avec babyfoot et bornes d’arcade, bien sur un coin bar avec plein de boissons et des plateaux remplis de bonne nourriture grasse (brownies, cookies, gâteaux) mais aussi de fraises (super bonnes). Comme j’ai une heure à attendre avant le lancement de la conférence, j’ai le temps de faire le tour et de tester un peu tout.

Google Developper Day a lieu la même journée un peu partout dans le monde, certains pays comme l’Australie ou les pays asiatiques sont donc déjà en plein milieu de la conférence. Les photos sur le site montrent qu’il y a parfois beaucoup de monde. A Paris, il n’y a ” que ” 200 personnes et c’était vraiment très bien comme ça. Ça permet de garder une certaine ambiance familiale très agréable. Ce qui était original, c’est de pouvoir regarder au fur et à mesure du déroulement de la conférence les photos dans les autres pays. A Paris aussi, on se fait prendre en photo et 5mn plus tard, on la retrouve sur Internet.

Ce qui m’a vraiment frappé c’est la gentillesse et la disponibilité de tous les membres de Google. Peut-être est-ce dû au fait qu’il y a peu de monde, mais il est facile de discuter avec les Googlers.

Maintenant, parlons un peu des sessions. Les orateurs sont vraiment intéressants, on sent qu’ils sont vraiment motivés par ce qu’ils font et sont contents de partager leurs connaissances. Bien que je connaissais le thème des sessions avant la conférence, je suis resté un peu sur ma faim. J’aurais aimé une session sur les ingénieurs de Google, les techniques de travail, leurs pratiques, leurs méthodes de management. Bref un retour sur comment ils travaillent plutôt qu’uniquement des sessions techniques sur les API de Google et comment coder en utilisant les produits Google.

J’attendais aussi avec beaucoup d’impatience le keynote fait en temps réel avec Mountain View et là… rien. Ils ont bien parlé de Google Gears qui a un potentiel énorme, mais j’étais déjà au courant de ce produit depuis 24 heures… (Peut-être une fuite ?). Autre déception d’un autre genre ; les points d’accès Wifi à Internet. Bien que le signal soit bon, on se fait déconnecter régulièrement, c’est très frustrant. Le manque de prises de courant est aussi très gênant.

Entre les sessions, il y a du temps pour les discussions et le networking. Pour ce faire, j’ai, comme à mon habitude, enfilé mes t-shirts publicitaires favoris La première partie, j’étais en polo Nevrax et en deuxième avec un t-shirt XP Day. Le résultat est toujours sympa, car ça donne aux gens la possibilité de m’aborder avec un sujet “ah tiens tu as travaillé à Nevrax ?”, “Ah tiens tu étais à la conférence…” et ne connaissant personne au début de la conférence, j’ai pu rencontrer des gens fort sympathiques.

La journée s’est donc très bien passée et c’était une conférence vraiment à la hauteur de mes espérances. Il ne manquait plus que le petit truc, la touche Google, qui les différencie si bien des autres. Et ça s’est produit à la fin quand ils nous ont invités à repartir avec un petit sac contenant le t-shirt Google, mais aussi un hélico d’appartement ! Il y a une semaine je regardais justement ce genre de gadget pour mon anniversaire et Google à dû lire dans mes pensées, encore mieux que le père Noël, même pas besoin de lui écrire une liste Je ne l’ai pas encore essayé, mais je crois que Google a visé juste niveau “jouet pour les geeks”. J’attends de voir qui osera mettre en vente son hélico estampillé Google sur eBay et voir à combien pourra monter les enchères

Bravo à Sabine et à toute l’équipe pour cette organisation et Vivement l’année prochaine !