Poil à gratter

Tout à fait, le pire dans une équipe orienté business c'est le programmeur gourou-autiste: très compétent - ou qui pense l'être - techniquement, mais complètement à côté de la plaque côté business. Il y a parfois des développeurs qui pensent que le métier consiste à pisser du code alors qu'il s'agit juste de faire marcher des trucs. L'expert c'est un type qui va être par exemple capable de bosser sur une routine précise dans un moteur de base de données pour l'optimiser à mort, mais l'écrasante majorité des projets n'a pas besoin de ce genre de personnes. Typiquement c'est le gars qui va vouloir implémenter un framework web Java de zéro parce que le quintillion de frameworks existants ont le défaut de n'être pas assez bien à ses yeux. Par exemple j'ai un pote qui à vécu ça une fois, et le gros malin qui à pondu le framework s'amusait à charger toutes les entités d'une table sur les pages de liste. Ils s'en sont rendu compte en test d'acceptation, lorsque la taille des tables dépassait la centaine de millier d'entités.

À mon avis c'est un biais tout personnel: du code tout pourri en C écrit par des programmeurs nuls, j'en ai vu plus que de raison (du code Java aussi). Et puis il suffit d'ouvrir quelques projets open source pour perdre toute illusion sur le niveau des programmeurs C. À la limite, j'aurais le préjugé inverse: les programmeurs qui font du C, c'est parce qu'ils ne maîtrisent pas la POO. Pourtant c'est complètement faux. Par contre je suis bien d'accord qu'il y a eu une massification du métier, et que ce faisant il y a une proportion de nuls plus grande.Mais ça n'a rien à voir avec les qualités intrinsèques d'un langage: c'est pas parce qu'il y a des gros nuls qui font du Java que Java est nul, idem pour le C. Il y a des développeurs qui sont vraiment arrivés là par hasard, mais c'est le but des entretiens d'embauche que de pouvoir détecter ceux-là avant de faire une grosse connerie: les embaucher. Ceci dit certains arrivent à passer à travers les filtres... En revanche le bas du panier se retrouve clairement dans des langages (?) comme PHP, où j'ai vu des choses que la bienséance m'empêche de rapporter. Bon, il faut de tout pour faire un monde: il y a aussi des gens qui ont besoin de petits sites pas cher, et ces développeurs remplissent leur mission.

Un pressoir pour faire de l'huile ? Ça aussi ça se vend cher sur le marché, l'huile de noix. Je n'y pensais même pas parce que justement il faut du matériel.

Quand j'étais étudiant, avec les potes on avait fait des frises: on retirait les étiquettes de chaque bouteille de bière qu'on buvait et on la recollait au mur. Comme ça on savait où on en était.

Purée qu'est-ce que je donnerais pas pour un bon maroilles... Sinon comme je me sens un peu malade/fatigué ce soir, je me soigne au Pommard, faut pas se laisser abattre.

mondieu mondieu mondieu, comme le monde est mal fait Mais y'a plein de trucs à faire avec des noix: D'abord le broux de noix fait une bonne teinture pour cheveux bruns, ta femme va adorer, ou un bon colorant pour le bois brut, mais aussi une bonne base de peinture sur toile. Les noix fraîches: à manger en cas de petite faim, en plus c'est low-carb. S'utilise en condiment: avec du cantal, du chèvre, pas mal de fromages en fait. Dans les salades, génial avec des gésiers. Avec les noix vertes on peut faire du vin de noix. Le reste, faut le faire sécher et déguster pendant le reste de l'année. Sinon tu peux aussi faire un roulé au noix http://www.recette-gateau.eu/gateau-roule-aux-noix/

Amusant, je connais un peu plus les origines de JavaScript, et finalement c'est un peu la même histoire: - Sun vient de sortir Java, Netscape intègre un plug-in Java - Netscape commissionne Brendan Eich pour pondre rapidement un truc - ils pondent une bouse et la renomment JavaScript pour profiter de la couverture médiatique de Java, introduisant ainsi la confusion dans l'esprit des gens pendant de nombreuses années Et maintenant le monde du web est en train de réinventer les bibliothèques partagées pour JavaScript. Vu la nature du langage, la moindre mise à jour d'un composant va être hyper fun Par contre je te trouve dur sur le "write once run everywhere": everywhere était bien sûr du bullshit, mais c'était tout de même relativement plus portable que la plupart des autres langages, et ça le reste encore me semble-t-il.

Ouais, ça fout les boules au prix où c'est vendu sur le marché... faut vraiment que je me mette en quête de coins pour en ramasser. C'est comme les noix, quoi que ça pourrit moins, mais qu'est-ce que c'est vendu cher !

Les mains, ça sert quand même: J'ignorais qu'il avait finit par se suicider...

Il y a un mec qui avait fait sauter quelques radars à l'explosif maison: un beau jour ça lui a pété à la tronche et il a perdu quelques morceaux au passage. Il était encore sur son lit d'hôpital, que l'état, dans sa grande mansuétude, engageait déjà des poursuites.

Aie aie aie, les pieds nickelés s'intéressent à JM Lab, pourvu qu'ils ne décident pas de les aider !

De rien, ah oui tu peux aussi les faire au four, mais surtout, surtout ne pas oublier de les inciser, sinon ça explose. Environ 20 minutes à 220, retourner à mi cuisson. Mais du coup c'est plus de boulot (mettre sur la plaque, retourner), alors je les fais à l'eau... C'est pas obligé d'inciser quand tu les fais à l'eau, mais ça cuit plus vite comme ça, et comme l'eau rentre dedans tu as l'espèce de peau interne qui se ramollit et tu peux la retirer au couteau et avoir des châtaignes bien blanches.

Ouep, mais dans mon cas précis, c'est un Tomcat qui tourne sur une VM (avec le moins de RAM possible), et ce Tomcat fait tourner entre 2 et 4 webapps. Tout ce qu'on peut coller dans les shared lib de Tomcat, c'est autant de gagné sur chaque appli, et à priori nos applications n'ont aucune raison de ne pas utiliser les mêmes briques de base. Mais c'est loin d'être satisfaisant, je pense qu'on peut mutualiser beaucoup plus de choses en utilisant un JBoss 7 par exemple, et profiter de tout ce qui vient en standard avec le serveur. En particulier si je pouvais me débarrasser de ce boulet de Spring. Pour des grosses équipes avec des douzaines d'applis, j'ai effectivement le sentiment que partager des bibliothèques, ça ne va pas franchement bien finir. Le peu de fois où j'ai bossé dans ce genre de configuration, on est partis sur du web service, et ça marche pas trop mal, mais il y a une grosse déperdition d'énergie. J'ai appris C++, ce qui ne m'a servi strictement à rien vu que j'ai choisi de démarrer en PHP vers 2000, quand c'était encore fun et relativement nouveau. J'ai aussi appris COBOL d'ailleurs. Java j'ai tout appris sur le tas, parce que j'ai toujours cru en le potentiel de l'approche VM, même si à l'époque tout le monde se foutait de ma gueule Donc si tu as le temps, ça m'intéresse d'avoir ta version, j'ai pas connu le début en 96/97.

Donc en gros il y a un radar qui surveillent le radar pour flasher les gens qui s'approchent du radar. Est-ce qu'il y a un radar pour surveiller le radar qui surveille le radar ?

J'ignorais qu'ils en faisaient jusqu'à ce que quelqu'un en parle ici. Apparemment on en fait aussi jusque dans le sud des Pays-bas, Limburg. Merci, vais regarder ! Percer les châtaignes avec un couteau, plonger 5-10 minutes dans l'eau bouillante, passer à l'eau froide et les éplucher. Ensuite tu termine la cuisson avec ton plat. Ou si tu ne veux vraiment pas les cuire avec le plat, plus longtemps dans l'eau bouillante, 20 minutes ça suffit en général: tu peux les piquer avec un couteau pour vérifier si elles sont cuites.

Je vais à Antwerpen 2 jours pour la Devoxx (un truc de geeks), est-ce qu'il y a des vins belges que vous pourriez me conseiller pour rendre mon séjour plus agréable et/ou faire un peu de shopping en repartant ? Si quelqu'un connaît un bar sympa avec du vin et des bières, je suis preneur aussi.

Oui et non: ça n'a pas pour unique but de faire gagner de la place sur disque mais aussi en mémoire. Tu vas me répondre: le Go de mémoire ne coute rien. Certes, mais quand on héberge plusieurs apps sur un serveur, ça commence à changer la donne. Sans compter les temps de chargements qui sont réduits aussi. Je ne te suis pas trop. Par exemple, je bosse avec des trucs comme Apache commons-collections depuis des années, il n'y a que très peu de soucis de compatibilité entre les versions, sauf bug, la compatibilité ascendante est respectée. Et ça évite de réinventer la roue carrée. Pour ce que tu fais - et je ne sais pas ce que c'est - sans doute que COBOL est utilisable, mais pour faire des applications web, j'ai comme un gros doute Les websockets en COBOL, je ne le sens pas trop... C'est une des raisons, mais si on apprend Java au jeunes développeurs, c'est avant tout parce que c'est fortement utilisé dans l'industrie. À quoi bon leur apprendre C++ si ce n'est pas une compétence recherchée ? Oui, aujourd'hui les (des ?) employeurs cherchent des devs C++, mais des expérimentés, pas des juniors.

Les bibliothèques (librairies, ça n'est pas français ) partagées c'est juste une implémentation facile et rapide pour résoudre le problème de la réutilisabilité: ça marche pas trop mal, mais ça devient vite ingérable lorsqu'il y a des dépendances communes dans des versions différentes. En fait c'est un peu comme l'héritage d'implémentation: facile, rapide, un cauchemar à maintenir sur le long terme. Idéalement, si on veut du self-contained, il faut tout organiser en web services, mais comme je dis à chaque fois: de quel genre d'applications parle-t-on ? Se lancer dans du web service, ou même de l'OSGI, c'est carrément over kill pour une large majorité des applications web. Ajouter quelques dépendances Maven suffit largement. En revanche j'ai le sentiment qu'on va dans la bonne direction avec J2EE 6 et supérieurs, et le mieux c'est que ça devient utilisable dans des conteneurs web légers (comme Tomee). On a enfin des composants réutilisables et modulaires. Le soucis c'est de convaincre les développeurs que les EJBs c'est pas la mal incarné, et que Spring c'est en fait pas terrible. COBOL c'est pas un langage, c'est un fossile Blague à part, Java, le langage, n'a que peu changé (le SDK c'est autre chose): j'ai commencé avec la 1.3 il a fallu attendre la version 1.5 - renommée 5.0 - pour voir un changement significatif dans le langage: génériques, mot clé enum. Java 7 - 5 ans plus tard - n'amène pas grand chose: c'est surtout du syntactic sugar pour le développeur. Donc il va falloir attendre Java 8 - qui doit sortir incessamment sous peu - pour voir arriver les lambdas et les streams. Comparé à des langages utilisés aussi pour le web, c'est très conservateur et lent, ce qui explique sans doute en grosse partie son succès, comme COBOL.

Excellent

Bof, ce qu'il y a de bien avec Java c'est que le langage évolue très peu et très lentement. Oui, pour le backend, mais je n'ai pas le sentiment que c'est si nouveau que ça. Bon avant c'était peut-être plus du C que du C++. Enfin je ne dis pas le contraire pour les micro-benchmarks, je soulignais juste que pour optimiser, encore faut-il savoir quoi optimiser dans un système. Et pour moi qui travaille dans le monde du web, un système ça commence depuis le browser et ça se termine avec le système de logging, avec au milieu une base de données, des serveurs d'application, et des services tiers. Dans ce contexte, optimiser un memcopy c'est bien, mais c'est plutôt le boulot du fournisseur de DB, on a un peu d'autres choses à optimiser avant ça. Si tant est qu'on a besoin d'optimiser... Oui et non, voir plus bas ma réponse à Jubal. La moindre webapp Java intègre désormais des dizaines de composants qui sont ultra testés et solides, implémentant une interface connue. On est franchement plus très loin de fonctionner sur ce modèle. J'insiste, si En fait je veux du code lisible et propre, sans fioritures, parceque c'est le seul moyen d'avoir un audit correct. Et pour être sûr que du code est utile et fait ce qu'il doit réellement faire, je ne connais pas de meilleure méthode que la relecture systématique. De plus je ne connais pas de code qui ne doit pas être modifié dans le futur, alors effectivement on peut tout réécrire, mais c'est quand même plus économique si c'est possible de simplement améliorer l'existant. D'ailleurs lorsque ce n'est pas possible de modifier et qu'il faut réécrire, c'est pas vraiment pour un problème de lisibilité (on trouve toujours quelqu'un pour comprendre), mais plutôt un problème de conception.

Tout à fait: l'optimisation prématurée, rien de pire pour flinguer un projet. Surtout qu'il y a malheureusement trop de développeurs qui n'ont aucune idée des ordres de grandeur qu'ils manipulent et qui vont passer du temps à optimiser des parties qui n'en ont aucun besoin. Genre rendre du code illisible pour optimiser une boucle de traitement, tout en laissant des appels de web service sans cache... M'enfin bon, écrire du code bas niveau (ASM ou C) en 2013 faut vraiment en vouloir ou n'avoir rien de mieux à faire de son temps. Je me souviens d'une comparaison qui avait été faite entre la version originale de Git, écrite en C avec des parties en assembleur, et un portage Java de Git (faudrait que je retrouve le post...). Conclusion: JGit était seulement 50% moins rapide que CGit lorsque la comparaison porte sur du calcul intensif. Soit sur une machine moderne, un truc qui doit se compter en micro-secondes pour une opération standard. Ensuite devinez lequel est le plus maintenable et rapide à écrire...

+1 Surtout qu'il écrit des pavés monstrueux pour noyer le poisson. C'est une caractéristique des gens de gauche d'ailleurs: ils écrivent toujours d'énormes pavés.

Ah ouais, j'aurais du chercher sur un .fr, pas fait gaffe que c'était du franglais tout moche. C'est nul, on avait un mot tout trouvé pour ça: bout-en-train

Pinaise, y'a des gens qui regardent ça volontairement sans être attachés à leur chaise ? Tout le script du film pourrait figurer dans ce fil on dirait !

les quoi, les fluffeuses ?