cedric a écrit 1074 commentaires

Source ? Je peux te dire que mes étudiants qui me font du code sale, ils se font enguirlander sévèrement. On leur apprend à bien architecturer leur code, on leur apprend à faire des tests unitaires, on leur apprend à documenter correctement ce qu'ils font. On leur fournit tous les outils et les méthodes pour qu'il fasse du code maintenable.

Du code maintenable, c'est du code qui est clairement decoupe en fonctions/fichiers/bloc de code avec des noms de variable comprehensible et juste ce qu'il faut de documentation pour comprendre pourquoi le code est ecrit ainsi. Ensuite le fait que ce code sera revue par une tierce personne avec qui on ne peut pas communiquer autrement qu'en envoyant du texte, force mecaniquement a ecrire un code "comprehensible" et donc maintenable. Le reste, tests unitaires, couverture de code, benchmark, documentation, whatever, c'est juste meme pas la question. Ca doit etre la, et je doute qu'il y ait des ecoles d'info qui n'enseigne pas ces outils, mais ce n'est pas ca qui faira que le code sera maintenable de mon point de vue. C'est son organisation et sa capacite a "s'expliquer" quand on le lit… lorsque le developpeur n'est plus a cote.

Il y a reconnu et reconnu. Reconnu, pour moi, ça veut dire reconnu par l'Etat et derrière par les conventions collectives. Et puis il y a reconnu par la pub qu'a pu faire l'école et/ou reconnu par le niveau (bon ou mauvais) de ses anciens élèves, c'est-à-dire la notoriété, qui n'a aucune valeur en soi sorti d'un petit microcosme. Et je le répète, en France il est illusoire de croire que ça a de la valeur.

Pour le coup, la reconnaissance de l'etat est secondaire. Ce qui compte c'est la reconnaissance industrielle. Comment se comporte la majorite des anciens de cette universite/ecole. Apres la plus part des grands groupes ont des grilles de salaire qui sont juste calle sur la reconnaissance de l'etat et c'est a peu pres tout. Mais bon, ces grilles ne revellent, en tout cas pour celle que j'ai vu, absolument pas les qualites d'un developpeur. Il vaut mieux aller faire un tour dans la silicon valley pour voir qu'elles sont les ecoles qui marchent, plutot que dans les grands groupes francais…

mais pour la plus grande partie, ce n'est pas une obligation (jusqu'à présent).

Peut etre, mais quand tu fais passer un entretien, tu as 30min, peut etre maximum 1h. Il est impossible de savoir dans ce laps de temps si une personne te sortira un code maintenable ou non. Tu passes normalement ton temps a voir si il s'integrera dans l'equipe et si il correspond bien a sa reputation. Je pense que quelqu'un qui n'a pas de code visible publiquement est impossible a evaluer sur un simple entretien (Il aura ses chances pour un stage sur lesquels les criteres de recrutements sont differents). Mais meme pour du developpement proprietaire, avoir du code dont je peux, en tant que recruteur, lire online avant l'entretien, est clairement le point le plus important quand je fais un entretien avec un developpeur. En fait, il y a aussi un autre point, mais celui la est plus un bonus, c'est si il y a eu interaction avec des communautes de developpeurs.

Maintenant je sais tres bien que la plus part des recruteurs sont incapable de faire un recrutement de dev et joue plutot a la roulette russe. Si le mec est sympa, qu'il vient d'une ecole/universite connu, on va le prendre apres un petit test minimal de code (dans le meilleur des cas). Mais ce n'est pas forcement comme ca que cela se passe dans le reste du monde…

Pour moi, c'est plus une question de generation que d'ecole ou d'universite. La proportion d'individu capable a trouver l'information puis a coder du code maintenable autour de la dite information, est en declin. L'universite ne t'apprend pas la rigueur necessaire pour faire du code maintenable, les ecoles d'ingenieurs generalistes ne forment juste absolument pas a faire de l'informatique (mais ils finissent tous par en faire), les ecoles specialises ont tendance a donner la grosse tete (et donc ca se plante pas mal au debut en etant trop confiant), … Au final, etre bon developpeur, c'est plus par rapport au gens que tu as rencontre et au communaute qui t'ont fait progresser que par ta formation.

Mais bon, en France, on est tres ecole/universite et on a une tres forte tendance a donner de l'importance au diplome qui finalement, je trouve, n'a pas de valeur dans l'informatique en tant que recruteur. Apres c'est sur pour la plus part des recruteurs, ils vont faire confiance a un diplome, parce que c'est plus simple et qu'ils sont incapable d'evaluer les competences a ecrire du code rapidement et maintenable d'un candidat… Et la forcement, avoir un diplome reconnu, ca rassure tout le monde (et pas que les parents).

D'ailleur a l'etranger, tu peux oublier, ca a juste aucune valeur. Personnellement, je ne connais qu'une methode d'evaluation valable, google et github !

Je crois que tu as marche dans le troll. On va voir si ca prend !

Donc, faisable au clavier aussi tout ça, ou pas ?

Pas a ma connaissance pour l'instant. Tu peux ouvrir un ticket sur https://phab.enlightenment.org/maniphest/ pour demander cette fonctionnalite. Pas franchement la mer a boire a rajouter. Par contre, le plus problematique, ca va etre de trouver des raccourcis claviers sans conflits… Ca commence a etre assez difficile !

/o\ Euh, juste non. Il n'y a aucun rapport.

Quelque soit le type de fenetre, ca marche toujours avec une boucle principal (main loop) et des callbacks asynchrones sur evenements. Ce qui genere des freezes, c'est quand le temps passe dans les callbacks de ton application ne laisse plus le temps au code de rendu graphique pour faire le dit rendu en moins de 1/60 seconde. Il y a plein de chose qui peuvent generer des freezes en plus de calcul un peu long, acces au disque non asynchrone, acces reseau non asynchrone, rendu inutile, … En mettant le rendu dans un thread separe (meme si il faut le piloter), tu te retrouves a avoir un peu plus de temps entre le dernier moment ou tu l'as piloter et le moment ou tu dois le piloter. Combiner avec des IO asynchrones un peu partout, tu eviteras les freezes et tiendra les 60 fps, si ton second core et le code de rendu en est capable.

J'avoue que le trend du tout HTML, va pas vraiment vers l'efficacite… Mais ca n'empeche que toutes les communautes ne suivent pas le meme chemin et que certains developpeurs y font attention. La masse n'a jamais fait la validite d'un choix technique, Windows… tout ca…

tout le monde s'en fou (hormis peut être les créateurs de Wayland…) d'avoir un espace utilisateur moisi sous linux, Gnome et KDE sont sensés suffire!

Ah mais non, c'est pas vrai ca ! Si on se demerde pour que Enlightenment avec tous les effets fonctionnent de maniere fluide meme sur le bas de gamme, c'est pas pour s'entendre dire ca quand meme ! Il y a des communautes pour qui la fluidite, la legerete, les effets graphiques doivent etre la. En tout cas, il y en a au moins une, Enlightenment.

Enlightenment en software marche tellement bien que les devs ne se rendent pas compte quand leur driver OpenGL ne fonctionne plus ! En plus, il fait gagner de la batterie par rapport a utiliser le backend OpenGL ! Terminologie, l'emulateur de terminal de Enlightenment, est aussi rapide que urxvt, consomme moins de memoire et a plus de fonctionnalite graphique que n'importe lequel de la concurrence.

Allez demo time: http://enlightenment.org/p.php?p=about/terminology&l=en . Donc non, il y a des trucs rapide, lege et customisable de dispo sous Linux. Apres si tu te cantonnes a KDE et GNOME, c'est clair, ce n'est pas leur objectif !

Il y a 11 ans, quelques aspects de X(Free86) qui me font toujours sourire !

Plus aucun toolkit sain d'esprit ne fait ca de nos jours ! Tout est rendu cote client et c'est juste un swapbuffer cote serveur ou un xshm upload.

Effectivement tres different de la stack Linux. Le principe ici, si j'ai bien compris, est que l'application construit une liste de ce qu'elle veut rendre a l'ecran et la donne a un thread en charge du rendu. Celui-ci est synchronise par le serveur graphique (equivalent de X) qui va en fait definir une zone de clip a l'ecran et laisser le thread de rendu faire le rendu de la fenetre en question directement dans le buffer de l'ecran.

Sous Linux, l'evolution de tous les toolkits graphiques est allez vers l'utilisation d'un systeme a multiple buffer qui est donne au compositeur. C'est a dire que l'application n'a jamais acces directement a l'ecran. Apres chaque toolkit peut si il le veut faire le rendu dans un thread de maniere asynchrone avant de donner le buffer au serveur graphique. C'est ce que font a ma connaissance les EFL et Qt/QML.

Je me demande d'ailleur comment s'en sort Haiku avec OpenGL, car ca me semble tres difficile a implementer dans un tel contexte.

Cependant, il y a des différences de taille, comme par exemple l'absence d'un serveur X.

Ca m'interresse de savoir comment la stack graphique fonctionne sur Haiku. Tu as un lien ou de la doc sur le sujet ? De plus, c'est une question historique, si il y a plusieurs moyens d'acceder a l'ecran (fb, kms/drm, X, directfb et wayland). Et le poid de porter un toolkit graphique est tres largement sur evalue. Ce qui prend du temps, c'est de l'optimiser. Mais ca, ca se fait en faisant evoluer le protocol sous jacent le plus souvent.

Un deuxième avantage de Haiku est une stabilité des APIs mais aussi des ABIs.

C'est le boulot de toolkit comme Qt ou les EFL de fournir ca, tout en tirant parti des ameliorations du systeme au fur et a mesure du temps. Sans compter que l'API de la libc et du kernel sont aussi stable. Donc je ne vois pas en quoi cela fait une difference ici (Il est vrai que des projets tierces n'auront pas cette garantie de fournit, mais au final le probleme se posera aussi pour Haiku).

D'ailleur une question qui me taraude quel est l'interet du toolkit graphique de Haiku par rapport aux autres toolkit existant.

Juste comme ca luajit est tres proche des perfs du C quand celui-ci ne peut pas utiliser d'instruction vectorielle (cas quand tu ne compiles pas avec -march=native globalement).

Et Java est extremement lent :-)

Ca je n'ai pas dit le contraire. Maintenant il y a des constructions par exemples sur l'heritage multiple que tu ne peux pas faire en C++, mais que tu peux coder en C. Par contre, le boiler plate sera clairement plus long a creer. Mais ca a un avantage, celui-ci sera plus explicite.

Je n'aime pas ce qui fait disparaitre de l'information quand on lit le code. Lorsqu'on passe un objet par reference en C++, on ne le voit que lorsqu'on lit le prototype de la fonction. Cela implique d'avoir un modele mental complet de l'ensemble du code qu'on est entrain de maintenir. Forcement plus la lecture manque d'information, plus les potentiels de bugs sont eleves. C'est au final le meme probleme qu'avec la surcharge d'operateur, on lit le code, mais on ne peut pas voir l'ensemble des appels de fonction et de logique que cela va declencher.

Tu peux me pointer ce qu'on ne peut pas coder en C, s'il te plait ? Parce que la ca me parait pas bien compliquer de faire des fonctions virtuelles, un pointeur sur fonction, ou une table de pointeur sur fonctions partage, des signaux et une macro :-)

Je dis ca parce que j'ai vu trop d'horreur !

La reponse depend de toi. Si tu connais bien le C++ ou si c'est un projet a valeur educative, alors prend le C++. Si tu ne connais pas bien le C++ et si tu tiens a avoir un resultat utilisable et maintainable… Evite a tout pris le C++ ! Je rajouterais meme, si tu dois travailler en equipe et que cette equipe n'est pas tres tres stable dans le temps (genre tout le monde reste au moins 2 ans sur le projet).

Les abus de ce language sont tel qu'elles ouvrent la porte a plein d'horreur dans lesquel tombe les debutants qui rendent impossible la maintenance d'un projet en C++. En gros faut eviter comme la peste toutes les surcharges d'operateur, les passages par reference et autre subtilite qui cache de l'information. Si tu ne fais pas ca, accroche toi pour debugger et optimiser ton projet.

J'ai vu tellement de projet en entreprise echoue sur cet ecueil que je pense que le C++ est trop complique pour la majorite des developpeurs et des projets. Le seul cas ou ca marche, c'est quand tu as une equipe competente, dedie et volontaire…

Je ne suis pas d'accord en C, tu peux controller le design de ton modele objet. Alors qu'en C++, il t'est impose. Le C++ t'offre plus de facilite, pas plus de possibilite.

Parce que ce n'est pas dans le code de ton application que tu vas passer 90% du temps, mais dans celui du toolkit graphique. On parle de GNOME + JS ici, pas de HTML + CSS + JS. Ca n'a absolument rien a voir en profil de performance. Dans le monde du web, tout ton toolkit est implemente en JS. Dans le monde des bindings JS, celui-ci est fait en natif. Donc tu as une application avec une logique simple qui ne prend pas plus de 10% du temps et tout ce qui est couteux est fait en natif.

Fait des tests avec valgrind, tu verras ou le temps est passe. Je suis pret a prendre le paris que dans aucune de ces applications, tu arrives a avoir un morceau de JS dans le hot path.

Oui, bah, ca rame la ou un truc natif aurait ete plus performant. C'est exactement l'exemple a pas donnee. De plus, asm.js est deux fois plus lent que du natif qui a lui meme etait compile sans le support de la vectorisation… Mais c'est des benchmarks qui font de l'html avec tout le coup que ca implique…

Parcontre javascript n'est pas un bon choix pour l'embarqué.

Uh ? Une justification ? La majorite des trucs couteux sont fait par le toolkit graphique. Il n'y a qu'un peu de logique applicative a faire en javascript, c'est pas ca qui va poser le probleme. Tu as deja fais des benchmarks ? Le probleme des navigateurs web, c'est pas franchement le javascript… Il faut regarder du cote du modele de rendu graphique qui force a mettre la logique du toolkit en JS et est loin d'offrir une architecture ideale de ce cote la. Mais ca, tu n'as pas ce probleme lorsque tu as un binding vers un toolkit natif.

Ou les lecteurs de disquettes…

Autant le dire tout de suite, c'est une idee de designer un peu hippie ! Dans la pratique, faut juste oublier.

La premiere problematique, c'est comment tu interconnectes tes bus avec des debits consequents ? Ensuite comment tu fais pour upgrader tous ces bus qui change en moyenne tous les deux ans ? Ensuite faut ajouter les problemes de dissipation termique et d'emission radio. Cette approche ne sera valable que lorsque l'evolution des telephones aura ralenti et qu'on aura donc une duree de vie de l'ensemble plus grande… Je sais pas, mais je vois pas ca arriver tres rapidement !

Non, non, tu as inverse ce que je dis ! La composition software consomme moins de batterie lorsque j'edite juste du code que la composition OpenGL. Ce qui est logique si le GPU n'est pas capable de faire des mise a jour partiel de l'ecran (limitation du driver plutot que du hardware). Le compositeur OpenGL est oblige de faire une mise a jour complete de l'ecran, alors que le compositeur software va juste rafraichir le curseur qui clignote et quelques pixels a gauche et a droite pour le contenu qui a change. Il y a clairement un avantage indeniable au logiciel dans cette situation.

Wayland avec un driver Intel permet de faire de la mise a jour partiel, si je ne me trompes pas. Mais je n'ai pas encore eu le temps de tester (J'attend surtout l'integration du support KMS/DRM dans Enlightenment pour pouvoir le tester). D'ailleur quel est le status des extention GLX_EXT_buffer_age et eglSwapBuffersWithDamage avec le driver radeon ? C'est vraiment l'extention qui change les choses dans ce que fais un compositeur. Et si tu veux tester, Enlightenment les detecte et utilise directement out of the box ;-) D'ailleur toutes les applications bases sur les EFL les utiliseront automatiquement si elles sont disponible !

Hum, je ne savais pas qu'il y avait un compositeur software dans KWin.

Le compositeur software de Enlightenment est en fait le backend software de la bibliotheque de rendu Evas. Celle-ci est en charge de faire l'abstraction complete du backend et Enlightenment ne fait rien de particulier pour utiliser le GPU. Le backend software en question ne fait appel a aucune bibliotheque externe pour les operations de rendu. Ce qui implique que les resultats d'Enlightenment ne sont lie que a Enlightenment et n'engage que cette solution :-)

Il est a note que Samsung qui sponsorise le projet, est tres interesse pour avoir la plus faible consomation batterie et memoire. Ca en devient des fois un peu excessif, mais ca peu expliquer les differences avec d'autres projets :-)

Tu peux remplacer "les" par Ubuntu dans ta phrase, car c'est bien les seules qui ne misent pas dessus pour des raisons politiques. Tout le monde a part eux travaille sur Wayland. Toute l'industrie, tous les desktop, toute la communaute. Ils sont tout seul. Et ils se prennent juste pour Google et veulent prendre le controle de leur stack.

Sauf que techniquement Mir n'apporte pas ce qu'apporte Wayland et ils n'auront aucune traction. Il n'y a que les utilisateurs d'Ubuntu qui suivent et gobent gentillement leur marketing pour supporter leur effort. Les developpeurs ne se fairont pas manipuler aussi facilement…

Ils ne font de remonte upstream que quand ca les arrange. Ici, c'est a leur avantage.