Julien Jorge a écrit 590 commentaires

J'ai aussi eu l'occasion d'organiser des entretiens d'embauche et j'ai eu le même sentiment que l'auteur du journal. À l'opposé, j'ai aussi passé des entretiens dans des domaines ou je pensais avoir un niveau moyen et où j'ai appris que mon niveau était plutôt débutant. À mon avis quand il parle de code dégueu, c'est plus pour soulever l'absence de sensibilité du candidat à bien présenter son code et à se faire comprendre, plutôt qu'une simple histoire de goût.

Il suffit de lire les discussions, ici dès que cela parle de code, sur 100 personnes il y a 100 avis différents de ce qui est bien ou mal.

Justement, quand je fais un entretien j'attends du candidat qu'il soit ouvert sur le style et la façon de travailler. Tous les projets sur lesquels j'ai travaillé avaient des conventions différentes (présentation, commentaires, flux de travail, etc.) et la seule chose qui était commune était que chacun avait la volonté de produire un code clair pour les autres. C'est exactement ce que je veux voir en entretien : quelqu'un qui ne s'arrête pas dès que ça marche, mais qui fait attention à être cohérent avec le code qui l'entoure ; quelqu'un qui sait me donner une estimation juste de son temps de travail, et non pas pour avoir un truc qui marche et qu'il ne reste plus qu'à finir.

Enfin, proposer au débotté de faire du code à un mec, moi je l'aurais pas fait, car je ne te connais pas assez pour être certain que le code que tu me demandes n'est pas un code dont tu as besoin et que tu ne sais pas faire ou que tu cherches à avoir un code meilleur que le tien, sans être certain de ne pas être juste un pigeon que l'on va faire travailler gratos.

Sans savoir précisément la quantité de travail que représente l'exercice proposé par l'auteur, je peux néanmoins t'indiquer que dans mon cas les exos sont très très courts, comme une recherche sur une propriété des objets d'une liste. Ça me demande même plus de temps d'écrire l'énoncé que d'implémenter la solution. Pourtant ça permet déjà de bien filtrer entre les solutions fausses, les recherches en n², les recherches qui utilisent simplement les fonctions déjà présentes dans le fichier… Bref, avant que je file du vrai boulot au candidat il faut déjà qu'ils aient les bases.

Une critique qui revient souvent sur vos à l'annonce des CD et clés lanpower est que le support est dépassé. Je rejoins devnewton plus haut qui propose de passer à des dépôts, mais je ne vois pas comment vendre ce service.

Personnellement j'aime beaucoup votre approche consistant à reverser les bénéfices à divers projets libres, comme le fait notamment it2l.

Pour passer dans le monde moderne, que diriez-vous d'organiser des ventes de bundles de jeux libres, à la Indie Bundle ? La présentation devrait s'orienter vers le financement général du libre plutôt que vers l'achat de jeux déjà gratuits mais ça me semble pertinent. Pour mes propres jeux, je pense même pouvoir proposer des goodies pour les acheteurs.

Ça coûte rien dans l'implémentation mais ça fait tâche au niveau de l'unité du système. C'est comme si je faisais une application bureautique sans reprendre le thème système pour les icônes de couper-copier-coller, ou d'annulation, ou si les boîtes de dialogues avaient les boutons à gauche plutôt qu'en bas. Cela fonctionne mais ça fait tâche.

Donc pas de bouton « quitter » car je respecte les règles du système hôte. Par contre je mettrai le passage en arrière plan avec le bouton « retour arrière »

Pourquoi ne pas avoir tout mis sous GPLv3, code et données ?

Historiquement la GPL s'applique plutôt au code qu'aux données annexes, tandis que les Creative Commons s'appliquent plus aux médias qu'au code.

Ce qui manque pour ce moteur de jeu, c'est de la documentation. Parce que, oui, c'est peut-être possible de faire d'autres types de jeu, mais si on veut se faire une idée plus précise, on peut difficilement. Sans compter qu'il y a des choix qu'on pourrait questionner comme le fait de ne pas avoir choisi Box2D pour le moteur physique (y a-t-il une raison particulière ou c'est juste un petit NIH ?)

Les premières lignes du moteur ont été écrites en 2005, à une époque où il n'y avait pas de moteur physique 2D libre en C++. Comme notre moteur a bien répondu à nos besoins jusqu'ici, nous n'avons pas fait de migration.

Pour la documentation, il y a bien le vieux wiki mais il est un peu obsolète. De mon point de vue il manque surtout des petits tutoriels du genre « mettre en place un jeu de plates-formes en 5 minutes », et surtout il manque du courage et des mains pour rédiger tout ça :) C'est clairement un point bloquant à la réutilisation par d'autres personnes.

Boost.locale a besoin d'iconv ou d'ICU à la compilation. Aucun des deux n'est disponible par défaut et quand j'ai compilé Boost il m'a bien dit qu'il ne pouvait pas construire cette bibliothèque.

Là encore ça n'était pas utile d'insister car même si j'arrivais à compiler Boost.locale, ça n'aurait pas aidé gettext. Éventuellement j'aurais pu l'utiliser dans libintl-lite mais cela m'aurait demandé une bien plus grande implication dans son code (qui n'est déjà pas marrant).

Bref, l'objectif était d'avoir le jeu qui tourne avec ses traductions actuelles et libintl-lite est le chemin le plus direct que j'ai trouvé. En plus il n'a pas d'impact pas le code existant. Dès que j'aurai des traductions qui nécessitent de l'unicode je me pencherai sur d'autres solutions :)

pourquoi ne pas utiliser gettext? C'est plus rapide pour la compilation?

Je me suis arrêté sur libintl-lite car c'était la première solution qui m'a permis de passer la compilation avec la chaîne d'outils du NDK. J'ai essayé de compiler gettext aussi mais cela s'est avéré beaucoup plus compliqué, principalement à cause de la dépendance à iconv. Je ne me souviens plus où je m'étais arrêté mais je crois que la compilation de libiconv bloquait à cause de fichiers d'entêtes manquants dans le NDK.

Cependant j'ai quand même dû modifier quelques trucs dans libintl-lite : il manquait quelques méthodes à l'interface pour retrouver celle de gettext et l'implémentation était un peu buggée.

concrètement, est-ce que les fonctionnalités qui manquent sont utilisées des fois où ce ne sont que des cas particuliers?

Il manque la conversion entre locales du coup ! Ce que gettext fait avec iconv, libintl-lite ne le fait pas du tout. En pratique cela signifie que les fichiers de traductions .po doivent utiliser le même encodage que celui du système. Là aussi il y avait un piège puisque les appels à setlocale sont ignorés dans le code natif et renvoient toujours la locale C plutôt que celle de l'interface Android (i.e. la langue de l'utilisateur). J'ai dû patcher la SDL pour obtenir la langue de l'utilisateur depuis mon code C++.

Je viens de regarder les spécifications de la Galaxy Tab 3 et il me semble que c'est du Intel. Je n'ai compilé qu'en ARM, cela pourrait-il être la cause du problème ? Je pensais que le Play Store ne proposait pas l'application si elle ne correspondait pas à l'architecture !

Tu peux ouvrir un ticket dans le GitHub ou nous envoyer le problème à contact at stuff-o-matic.com.

Oui oui, le bouton retour arrière est celui que j'essayais de nommer Back. Je mets ça dans ma liste de trucs à faire.

Pourquoi ne pas poster le jeu F-DROID qui un "magasin" opensource d'application opensource pour android tout à fait sympathique ?

Je ne connaissais pas, je vais regarder !

De plus j'ai lancer le jeu, mais je n'ai pas trouver comment en sortir, je veux dire par là mettre fin à l'application !
Je sais c'est pas à la mode sur téléphone les menus "Quitter", mais moi j'aime bien terminer les taches dont j'ai plus besoin !

J'avais implémenté le bouton pour quitter mais cela va clairement à l'encontre des directives de développement pour Android. La politique est que les applications ne doivent jamais quitter d'elles-mêmes. Du coup j'ai enlevé le bouton.

Pour quitter il faut donc appuyer sur le bouton Home de l'appareil, par exemple. J'ai fait attention à réduire autant que possible la consommation du jeu en arrière plan (il ne devrait réagir qu'aux événements du genre « réactivation du jeu »).

Éventuellement je pourrais implémenter un retour à l'écran principal en pressant le bouton Back quand on est dans le sélecteur de niveau, pour permettre de sortir sans quitter.

Je te rejoins là dessus. Je me retrouve aussi avec des commentaires qui ont l'air de reprendre le nom des méthodes mais je me sens obligé de les mettre pour expliciter le fait qu'il n'y a rien de particulier, pas de surprise, dans l'implémentation de la méthode.

J'ai pour habitude de compiler les versions Windows de mes jeux en utilisant Wine, après y avoir installé et compilé toutes les dépendances. C'est un peu galère sur plusieurs points, notamment parce que MinGW est super lent et galère à mettre à jour, que certaines bibliothèques mettent par défaut une éternité à compiler (Boost notamment) et que CMake ne trouve pas les bibliothèques tout seul sous Windows. Du coup j'évite de modifier le ~/.wine/drive_c et d'y mettre à jour les bibliothèques et outils.

Penses-tu que ton outil va me simplifier la vie ? En particulier, est-ce que ça va compiler a une vitesse normale et en utilisant tous les cœurs ? Est-ce simple d'utiliser une bibliothèque non présente dans le MinGW de Fedora (j'utilise notamment libclaw) ?

G'MIC fait des trucs supers mais son intégration à GIMP n'est pas géniale. On se retrouve avec deux ensembles de filtres dans deux interfaces différentes : les filtres par défaut de GIMP et ceux listés dans la boîte de dialogue de l'effet G'MIC. J'aurais préféré avoir les filtres G'MIC éparpillés dans les menus existants et dans les bonnes catégories.

Il y avait déjà CMake pour remplacer ces horreurs.

D'ailleurs CMake génère des Makefiles ; on va pouvoir faire des scripts CMake qui génèrent du Makefile Guile qui génère du CMake…

Nous utilisons un gestionnaire de bugs (Trac) pour poser les tâches toutes les deux semaines et pour lister les problèmes et améliorations désirées au fur et à mesure que nous les rencontrons.

Je n'imagine pas mettre toutes les spécifications dans le gestionnaire dès le départ, tout d'abord parce que nous faisons une relecture des tickets toutes les deux semaines, ce qui nous impose de garder une liste courte pour éviter d'y passer la journée. Ensuite parce que beaucoup de tâches ne sont pas pertinentes tant que d'autres ne sont pas faites, ou alors elles risquent de changer en fonction de l'avancement. Dans ce cas nous nous retrouverions avec beaucoup de bruit dans le gestionnaire.

Tu indiques aussi le temps estimé ?

Pour Plee the Bear et Andy's Super Great Park, une fois la bible écrite, nous avions fait un tableur reprenant les trucs à faire et une estimation du temps nécessaire. Nous avions choisi de compter en demies journées et à la louche. L'idée n'est pas d'être précis mais plutôt d'avoir une valeur pour comparer les éléments. Il s'agit aussi de discuter de chaque point pour lever rapidement les problèmes éventuels.

Les estimations pour Plee the Bear sont en ligne.

Pour l'exemple voici la bible de Plee the Bear (qui n'est pas fini). Pour Andy's Super Great Park (qui est fini) nous étions partis sur plus petit : nous nous en sommes sortis avec une feuille et un tableur listant les trucs à faire.

Dans les deux cas l'approche est la même : nous commençons par poser les concepts du jeu et nous notons quoi fait quoi à chaque moment du jeu.

Ensuite nous nous servons de cela pour poser nos jalons, en commençant par décider d'un horizon de livraison (deux fois 3 mois pour Andy's Super Great Park). Toutes les deux semaines nous nous posons la question « que voulons-nous voir dans le jeu dans deux semaines ? ». Nous notons toutes les réponses dans des tickets de Trac et nous nous mettons au boulot.

Il nous arrive de revenir sur des décisions de la bible au fur et à mesure de l'avancement, voire d'ajouter des nouveaux trucs, mais grâce au rythme imposé nous avons une bonne vision de ce que cela coutera. Du coup nous pouvons trancher sur l'inclusion, le report ou l'exclusion assez facilement.

Je pense aussi que tu as tout à gagner à écrire une bible qui détaille chaque élément du jeu. J'ai eu l'expérience d'un jeu commencé en 2005 qui devait aussi être terminé en 3 ans, j'étais aussi très motivé et il n'est toujours pas fini. Le bilan est clair, à chaque fois que j'ajoutais du contenu au jeu, je rajoutais des fonctionnalités parce que « ça sera mieux ! ».

Tout a changé quand j'ai commencé à poser sur papier tout le contenu attendu. Maintenant je fais des estimations de temps correctes et je ne dérive pas durant la production.

Donc je pense que ça vaut le coup de le faire. Ça prend une demie-journée pour un petit jeu et ça fait gagner un temps infini.

Ce n'est pas dans un forum mais ça n'empêche pas de poser la question : qu'en est-il du salaire ? Est-il libre ? Fonctionnez-vous en bring your own money ?

As-tu rencontré des problèmes à l'utilisation d'emscripten ? J'ai essayé de l'utiliser plusieurs fois sur une grosse base de code et j'ai toujours rencontré un paquet de petits problèmes dans des entêtes standards comme climits et dans Boost.

De plus le site du zéro ne donne pas forcement les bases de l'algorithmique. Encore une fois pour commencer c'est bien, pour avoir les connaissances de base c'est un autre problème et j'aurais tendance à me tourner vers des livres.

Comme les livres du zéro par exemple ?

Si vous ajoutez brainf**k, je tiens à ce que Goto++ fasse aussi son entrée !

Les sites qui reçoivent du contenu de leurs utilisateurs ont plutôt tendance à s'approprier les droits via un sombre article dans les conditions générales, alors quand un site les mets en libre, je trouve déjà cela bien.

Lors de la livraison, OpenFunding demande aux donateurs de confirmer que le travail est effectivement fait comme il avait été annoncé. Les donateurs ne peuvent pas se faire avoir sur cette plate-forme : si l'objectif n'est pas atteint, l'auteur peut quand même faire son projet et j'en bénéficie ; si l'objectif est atteint, je peux reprendre mes sous si c'est mal fait.

Et puis c'est uniquement pour des jeux libres, alors que jeuxlinux.fr parlait de tous les jeux sous Linux.