Julien Jorge a écrit 590 commentaires

Effectivement je ne suis pas passé par les SSII, cela doit jouer. Les entreprises où j'ai travaillé étaient des éditeurs et plutôt petits.

Ah la négociation, les salaires, les primes :) je te retourne la question : as-tu déjà été tellement déçu de te voir refuser une augmentation que tu t'es mis à surestimer ta charge de travail et à prendre des notes pour pourvoir retourner les choses contre tes patrons ?

Mmmh j'ai un peu de mal à te suivre. J'ai pourtant l'impression d'être dans le monde du travail (le vrai, pas celui des Hainounours). Sans être un monde idéal il est loin du monde amer que tu décris où les hauts gradés veulent écraser les plus petits qui en retour sont sur la défensive.

Ce que tu nous décrit ressemble plus à l'image du monde de grand papy, où le travail était avant tout une corvée et où on bossait pour rien jusqu'à se faire virer. Enfin j'imagine, je n'ai jamais connu ça. Heureusement pour nous l'informatique est un domaine où on peut encore choisir son employeur et où beaucoup, beaucoup, de personnes sont passionnées ; ce qui fait qu'on peut facilement se trouver dans une équipe que l'on est content de rejoindre quotidiennement.

À vrai dire, dans la mesure où le travail consomme quasiment un tiers de notre temps, si quelqu'un se lève tous les jours pour faire quelque chose qui lui déplait et passer sept heures par jour sur la défensive et dans le conflit alors qu'il a la possibilité de simplement traverser la rue pour vivre autre chose, j'ai l'impression que le problème est chez cette personne, sûrement pas dans le métier. Je ne doute pas que certains sont coincés par une raison où une autre, mais dans l'absolu je doute que ça vienne du fait d'être dans l'informatique.

Ce principe du conflit par défaut entre les patrons et les salariés, dans l'informatique au moins, me semble éculé. Peut-être suis-je naïf et que je changerai d'avis si un jour un patron me fait un sale coup que je n'aurai pas vu venir. Peut-être serai-je alors incapable de lui dire « au revoir, et merci » pour partir chez un autre. En attendant aujourd'hui je vois partout des boites où il fait bon travailler et où on peut aller en souriant.

Ton commentaire et celui de Christophe B. me font remarquer que je ne m'étais jamais demandé ce qu'était un professionnel en fait. Je suis loin des trente années d'expérience et à vrai dire j'avais plutôt le sentiment que le terme « professionnel » était un peu galvaudé aujourd'hui. Il me semble, mais mon regard est peut-être déformé, qu'on trouve assez facilement des gens avec ce libellé qui s'avèrent finalement être surtout de beaux parleurs dont les actes ne sont pas au niveau de leurs promesses ou bien dont le comportement est douteux.

Dans ma courte expérience je n'ai pas eu le sentiment que ces comportements que nous décrivons étaient attendus ou encouragés. Je les ai observés mais j'ai toujours eu l'impression que c'était plus le résultat d'une motivation individuelle que d'un désir commun ; comme s'ils étaient implicites. Cela me semble bizarre en particulier vis-à-vis des juniors qui entrent dans le métiers et qui se retrouvent à devoir deviner par eux-même quels sont les comportements qui agissent pour le bien commun et lesquels sont parasites. Pour prendre une analogie, c'est comme si on entrait dans le métier aux côtés de Linus Torvalds, Ulrich Drepper, Jeff Atwood et Robert C. Martin et qu'on nous disait « choisis ton modèle ». Quelle proportion de débutants comprendraient qu'on peut être d'un haut niveau technique tout en ayant des rapports humains intéressants ? J'ai personnellement le sentiment que l'on a tendance à négliger les retours positifs, ne serait-ce que « nous avons fait du bon boulot » ou « je trouve que l'équipe a bien fonctionné ».

Concernant ta remarque sur les paroles et les écrits, que Christophe B. et blabla ont l'air de rejoindre, je trouve, peut-être naïvement, que cela fait un peu vieille informatique. Peut-être est-ce un problème d'échelle de boîte car dans celles où j'ai travaillé, où les équipes sont de taille humaine et le patron est à n+1 et derrière une porte (toujours ouverte) dans la pièce d'à côté, je n'ai jamais vu quelqu'un chercher un coupable pour quoi que ce soit. Quand tout va bien c'est parce que nous avons tous assuré, quand tout va mal c'est parce que nous avons tous raté. Il y a évidemment parfois des désaccords, qui sont simplement évoqués dans les rétrospectives de sprint, puis tout le monde s'arrange pour trouver un compromis et s'y tient. Bien sûr ce n'est pas sans accrocs, il y a aussi des disputes, des démissions ou des licenciements, mais globalement j'ai le sentiment que tout le monde fait simplement de son mieux pour que ça se passe bien. C'est très différent du comportement défensif que blabla et toi décrivez. À nouveau, peut-être est-ce lié à l'échelle de la boîte ?

Ça aurait pu ! En l'occurrence c'était du Visual Basic…

Le plus terrible dans l'apport de nouvelles fonctionnalités est pour moi de n'avoir aucun retour sur la contribution. Il y a plusieurs outils tiers dans lesquels je me retrouve à faire des modifications au boulot, soit parce que j'ai des soucis à la compilation, soit parce que j'ai besoin d'une fonctionnalité, et depuis quelques temps j'essaie de remonter les modifications pour jouer le jeu du libre et aussi pour éviter d'avoir à les réappliquer quand je mets l'outil à jour. Bilan des courses, cinq pull requests, zéro merge et un seul retour.

Par exemple, ajouter la composition de skins à un outil d'animation. Aucun retour. Est-ce trop gros ? Est-ce inintéressant ? J'appuie ma demande en citant trois entrées de forums qui demandent cette fonctionnalité mais les devs laissent dormir la requête.

Sur un autre projet, je modifie la gestion des polices pour avoir un comportement homogène sur iOS, Android, Linux et OSX. Premier retour en une semaine et une demande de correction en un mois. Je traîne un peu et presque trois mois plus tard j'envoie les corrections. Et là c'est le silence. Je me dis que la pull request est trop grosses et je tente d'autre demandes, plus petites et triviales mais rien n'y fait, c'est toujours le silence.

C'est assez difficile de rester motivé quand les contributions tombent ainsi dans l'oubli.

J'ai eu la même réaction sur le prix, 800 € c'est vraiment peu cher payé.

Encore plus étonnant, tel que le journal présente le concours j'ai l'impression qu'il y a 10 « gagnants » mais qu'un seul récupère les sous.

Tout à fait. Voici une présentation sur ce sujet.

Il y a d'autres vidéos de la CppCon 14 qui ont le même discours. En gros ils nous disent « on voulait que ça aille vite alors on a fait des tableaux de POD et du traitement en lot ».

Pour l'orthographe j'utilise flyspell qui met les mots mal orthographiés en évidence au fur et à mesure de la frappe. Je ne sais pas si on peu lui faire utiliser hunspell pour profiter des déclinaisons ; quelqu'un a-t-il déjà essayé ?

Alors ça ne fonctionne toujours pas, par contre si dans la la configuration du serveur DHCP je met des IP fixes associées à certaines machines, alors ces machines ont le bon DNS et arrivent à résoudre le domaine. J'aimerais bien avoir ce comportement sans IP fixe.

Pour le DHCP wifi, j'ai testé en configurant mon serveur DHCP pour que cette machine ait une IP fixe, et après reconnexion elle a bien obtenu l'IP attendue.

Sur une autre machine où ça ne fonctionne pas non plus, le dig donne ça :

$ dig nas.lan

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> nas.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7590
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nas.lan.           IN  A

;; AUTHORITY SECTION:
.           84614   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2015042500 1800 900 604800 86400

;; Query time: 68 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Apr 25 08:26:36 CEST 2015
;; MSG SIZE  rcvd: 114

Pour ma part je trouve l'approche de la vidéo très intéressante en cela qu'elle permet de rendre l'algorithme concret en manipulant ses étapes et met en évidence l'aspect répétitif du processus. De cela on comprend l'intérêt de l'automatiser et son implémentation n'est plus qu'une traduction des manipulations que l'on a faites. La complexité de l'algorithme se retrouve dans la quantité de mouvements faits et on peut donc même comprendre qu'un algorithme est plus efficace qu'un autre juste en les déroulant. C'est un exercice qui me semble tout à fait adapté à la découverte de l'algorithmique et de la programmation.

Comme suggéré dans un commentaire précédent je pense aussi que le visualiseur serait le bienvenu sur le premier exercice. Avec la vidéo pour voir les étapes attendues et le visualiseur pour voir les étapes que l'on fait, cela me semble une bonne combinaison.

Puis-je suggérer de tourner les vidéos dans la remorque d'un camion avec des maquettes en carton pâte ?

Ça fait 3 ans que je pratique les revues de code et je trouve ça super. Le premier intérêt tel que cité dans la dépêche est que cela permet de trouver rapidement un paquet de bugs et des défauts d'architecture, globalement l'application s'améliore très vite. C'est en effet très rare qu'un commit ne reçoive aucun commentaire, ne serait-ce que pour relever des éléments qui sont acceptés mais pourraient poser problème dans d'autres situations. L'autre intérêt est que cela diffuse rapidement la connaissance du code et casse le cloisonnement par auteur. On n'hésite plus à modifier ou casser le travail d'un autre car grâce à la revue on a une bonne idée des tenants et aboutissants.

Les tests unitaires sont pour moi un moyen de renforcer ce dernier point. Je ne pratique que depuis quelques mois et bien que ce soit souvent pénible d'écrire les tests je suis toujours ravi de les voir tomber, que ce soit parce que je les ai écrits avant le code client ou bien parce que je modifie une ancienne partie de l'application. Grâce à eux je sais que mes modifs sont cadrées et qu'on ne me laissera pas faire de bêtises.

Code Complete est un excellent livre. Lisez-le.

Merci, ça fonctionne bien mieux comme ça :) (et c'est très pratique).

Avec une version de colout clonée depuis GitHub ce matin, j'ai une erreur qui m'empêche de voir la pile d'appel :

Program received signal SIGABRT, Aborted.
0x00007ffff5e7abb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
(gdb) where
[colout] ERROR: unknown color: cpp
cat: erreur d'écriture: Relais brisé (pipe)

Une idée pour résoudre ce petit souci ?

Je vois bien ce que tu fais devnewton ; sous couvert de trolls tu veux surtout nous montrer ton dernier jeu ;) Et bien j'ai testé et je dois dire que hormis une petit problème de recherche d'assets vite corrigé, le jeu est… waw ! C'est complètement différent de tout ce qu'on a pu voir jusqu'à maintenant. Bien que légèrement répétitif au début, on se prend vite au jeu et on se laisse entraîner par le rythme. C'est simple, sobre et efficace. À quand une version Apple Watch ?

Tu peux passer Plee the Bear en version 0.7.0 sortie il y a quelques mois :)

Pour ma part c'est beaucoup pour l'exercice : pratiquer, m'entraîner, découvrir et m'améliorer. J'essaie aussi de produire autre chose que du code, comme des sprites ou de la musique, et jusque là j'ai plus souvent lancé des projets libres que contribué à des projets tiers.

À ce sujet, je cherche un jeu libre auquel contribuer graphiquement, de préférence en dehors des styles FPS et stratégie. Des idées ?

Bon finalement j'ai trouvé. Pour ceux qui se posent aussi la question, il s'agit de la nouvelle syntaxe C++11 de déclaration de fonctions, où le type de retour est indiqué après la flèche et le nom est précédé du mot clé auto.

Ici la déclaration de G::f est équivalente à

class G {
public:
  void f() {
    // …
  }
};

Comme le type de retour (nommé trailing return type) est indiqué après la fonction, il est interprété dans le contexte de la fonction. Par exemple (inspiré de cette source), si j'écris

class C {
public:
  enum E { a, b, c };

  E f();
  auto g() -> E;
};

Je dois implémenter C::f en préfixant le type de retour avec le nom de la classe :

C::E C::f() {
  // …
}

Tandis que la nouvelle syntaxe m'épargne ce préfixe pour C::g :

auto C::g() -> E {
  // …
}

Ici le type de retour est bien C::E, c'est à dire E interprété dans le contexte de C.

C'est super car j'ai économisé l'écriture de C:: au prix de l'écriture de auto -> ! Je ne me suis pas fait avoir…

En fait l'intérêt est surtout lié à l'arrivée de decltype. On peut ainsi déclarer le type de retour en fonction des entités apparaissant dans la signature de la fonction, comme dans l'exemple suivant :

template<class T, class U>
auto add(T t, U u) -> decltype(t + u);

Ici la fonction add retourne une valeur du même type que le résultat de operator+ sur les paramètres. Si T et U sont int, alors le type de retour est int ; si T est int et U est double, le type de retour est double.

Une troisième source sur le sujet.

Dans la présentation sur bounded::integer, il y a une classe dont la syntaxe des fonctions m'étonne (classe Goblin, slide 25). Ça ressemble à cela :

class G {
public:
  auto f() -> void {
    ++m_h;
  }

private:
  int m_h;
};

Quelqu'un peut-il m'expliquer la déclaration de G::f ? Ça ressemble à la syntaxe des lambda avec une déduction automatique du type de f. Je pensais que ça serait une variable de type fonction nommée f mais GCC n'est pas d'accord.

On a vendu un peu plus de 10 exemplaires d'Andy's Super Great Park et 3 exemplaires de Newton Adventure. Pas de quoi faire des stats :(

Sur les deux derniers mois, la version d'ASGP sur Android (gratuite) a environ 40 nouveaux joueurs par jours.

Autre retours, sur une Fedora 20 x86_64 et en utilisant les librairies fournis par le système (eg. après un rm lib/*) le binaire ne fonctionne pas si l'utilisateur n'a pas la version i686 de la libGL.so.1 spécifique à chaque driver.

J'ai mis en ligne une version 64 bits de l'archive. Pourrais-tu tester si cela fonctionne sur la Fedora x86_64 (éventuellement après le rm lib/* ?

Mmh… la tâche sur OpenFunding me semble tout à fait accomplie avec cette nouvelle version. En fait je suis obligé de la fermer (la tâche) pour pouvoir faire valider son accomplissement par les utilisateurs.

J'ai une autre tâche en attente, qui consiste en fait à réaliser les trois niveaux suivants. Le coût est bien plus grand que la première tâche, qui n'avait même pas reçu la moitié de la somme prévue, donc je dois trouver une autre façon de l'aborder si je veux pouvoir la faire financer.

Merci :)

En appuyant sur F2 pendant le jeu tu pourras voir le nombre d'images et d'itérations de la boucle de jeu par seconde. Si tout va bien ils doivent être à 66 tous les deux.

Nous avons quelques artefacts graphiques parfois (des sprites qui tremblent) et il y a aussi un petit saut de mouvement de temps en temps, qui se voient surtout quand le perso court. Est-ce que ça correspond à ce que tu as ?