Le fil des geeks informatiques

[Poil à gratter]

Ben en fait c'est même plus vrai puisque les applis de nos jours tournent dans des VM, ce qui veut dire qu'elles ne peuvent même pas se partager les libs. Et sinon, pour les trucs internalisables, on fait des petits modules bien fichus qui n'ont pas besoin d'être des librairies linkées.

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.

 

Je ne sais pas quel âge tu as, mais en 96/97, au tout début de Java, donc, il était évident que le calcul ci-dessus ne tenait pas. Personne n'employait ce truc hideux.

Si j'avais le temps, je reprendrais l'histoire abominable et triste de Java depuis ce moment-là. Java, c'est un coup marketing ignoble de Sun qui a réussit.

Snif.

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.

[h16]

Malheureusement, j'ai pas trop le temps. Version courte : Sun avait besoin d'un truc marketing pour se sortir du caca, ils ont quasiment commissionné un universitaire pour commettre Java, basée sur des principes moyennement optimaux pour le dire gentiment. Sun étant bien implanté dans les universités a réussi à faire passer l'idée idyllique du "write once run everywhere" qui, si elle a montré par la suite à quel point c'était du gros bullshit, a permis de vendre le truc à tout le monde. Une fois que les étudiants (notamment de la Silicon Valley) étaient conquis, le reste était facile puisqu'en plus, le SDK était gratosse !

Ca n'a pas sauvé Sun. Et ça a ajouté un langage franchement pénible sur la pile de langages pénibles, avec en plus une couche d'abstraction au niveau langage (aarargh) au lieu du niveau os (comme un vraie VM).

Bref. Snif.

[Mathieu_D]

C'est bizarre comme le go ne coûte rien mais comme le go hébergé et backupé coûte une blinde.

Neuneu2k tu as deux mots pour défendre GTS ?

[neuneu2k]

Non, aucun.

En plus long, le problème de l'équipe storage chez GTS c'est qu'ils savent faire deux niveaux de qualité :

Résiste à un bombardement nucléaire massif sans perte de transactions.

Résiste a un bombardement nucléaire massif, mais le backup peut avoir 5 minutes de données perdues, aussi connu comme le storage "cheap"...

Ce n'est pas faute d'avoir demande une version "je m'en tape des nukes, je peux reconstruire le dataset, filez moi des disques rouilles et de la flash cheap"...

Je suis en arrêt depuis plus de 7 mois, mais en rentrant je suis sensé mettre en place un machin de datamining massif, donc si je trouve une combine pour coller des tas de disques de 3To dans un placard, contacte moi dans 2 mois sur mon mail pro ou par MP.

[Mathieu_D]

(Pour une part assez large des prestas et des internes, une bande de gros connards, même si on sait bien que c'est la faute à leur management.)

[Malky]

(Pour une part assez large des prestas et des internes, une bande de gros connards, même si on sait bien que c'est la faute à leur management.)

Pas mal sont cool quand on les connais, et plus précisément de leur middle management (les deux niveaux au dessus des managers de proximité, + ou - un ou deux niveaux :-)).

Spiderman est tout a fait conscient des problèmes de flexibilité et de délais de son entité et a une vision saine d'une stratégie GTS agile, mais il se trimbale une armée mexicaine peu manœuvrable...

 

Hmm il y a une cellule sogé ici ?

[neuneu2k]

Toutes mes excuses Mathieu_D je me suis chié dessus avec mon iPhone et j'ai répondu en éditant ton post...

[Mathieu_D]

J'ai l'impression qu'un admin est intervenu...

[neuneu2k]

Ouais, l'interface mobile avec "éditer" et "citer" l'un a côté de l'autre et le même éditeur, c'est dangereux quand on a les droits d'admin, désolé, je vais passer en version desktop sur mon iPhone aussi...

[Mathieu_D]

Toutes mes excuses Mathieu_D je me suis chié dessus avec mon iPhone et j'ai répondu en éditant ton post...

J'ai crû à une gaffe de ma part qui te mettait en danger professionnellement d'où édition.

Pas de soucis donc.

Tu peux me détailler ton besoin pro par MP ?

Maintenant je suis à Lille donc ce n'est plus moi qui interviendrait â la Défense. (mais je vais intervenir dans une filliale qui prête des sous pour acheter des véhicules située dans mon nouveau coin...)

[neuneu2k]

Hmm il y a une cellule sogé ici ?

Yep, je suis notoirement un suppôt de la banque du gros pouce...

[Malky]

Yep, je suis notoirement un suppôt de la banque du gros pouce...

 

Huhu, d'ailleurs tant qu'à y être tu peux éditer la citation dans mon post vu qu'elle reprend la petite mésaventure (pas bien grave ma bon, moi je peux plus éditer là).

 

Cool mon frère y est aussi, mais à Londres sur les docks. Pas du tout dans l'IT par contre.

[Poil à gratter]

Malheureusement, j'ai pas trop le temps. Version courte : Sun avait besoin d'un truc marketing pour se sortir du caca, ils ont quasiment commissionné un universitaire pour commettre Java, basée sur des principes moyennement optimaux pour le dire gentiment. Sun étant bien implanté dans les universités a réussi à faire passer l'idée idyllique du "write once run everywhere" qui, si elle a montré par la suite à quel point c'était du gros bullshit, a permis de vendre le truc à tout le monde. Une fois que les étudiants (notamment de la Silicon Valley) étaient conquis, le reste était facile puisqu'en plus, le SDK était gratosse !

Ca n'a pas sauvé Sun. Et ça a ajouté un langage franchement pénible sur la pile de langages pénibles, avec en plus une couche d'abstraction au niveau langage (aarargh) au lieu du niveau os (comme un vraie VM).

Bref. Snif.

 

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.

[Rincevent]

Je parle d’expérience très concrète, ou le fait d’être loin de la machine (et des trames réseaux en l’occurrence) empêchait la personne de faire un truc qui marche (6 mois a tourner en rond).

 

Et non pas du tout, un code lisible ne fait pas forcement ce qu'il est cense faire. De toute facon avec un language de haut niveau on n'a aucune idée de ce que le code fait.

Mais même en C, aujourd'hui, on ne sait plus ce que le code fait exactement, entre les optimisations les plus poussées que le compilateur peut créer, les vingt-cinq couches de virtualisation et le parallélisme omniprésent...

[jubal]

Mais même en C, aujourd'hui, on ne sait plus ce que le code fait exactement, entre les optimisations les plus poussées que le compilateur peut créer, les vingt-cinq couches de virtualisation et le parallélisme omniprésent...

 

C'est vrai, j'ai d'ailleurs déjà eut des bugs du a l'optimisation de gcc (juste en -O2).

Et puis ça dépend de ce qu'on code, mais moi dans mon expérience ce que j'ai vu plusieurs fois c'est ça: des gens qui a force de vouloir faire des trucs plaisants pour l'esprit, faisait des trucs qui marchait pas.

 

Le code était beau quand tu le lisais, le design était intellectuellement satisfaisant, mais le mec était incapable de faire marcher le truc.

Alors si on considère que le code c'est fait pour être lu, oui c’était un succès: c’était agréable a lire.

Le problème c'est que personne paye des codeurs juste pour lire leur code, il faut aussi que ce code serve a quelque chose.

 

 

 

[h16]

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.

Même pas plus portable. À l'époque déjà, on avait des compilateurs C de base avec des librairies qui se retrouvaient bien partout. Tu écrivais une fois, tu compilais sur les N plateformes et ça marchait très bien. Bien sûr, ce n'était pas des trucs graphiques, comme Java du reste qui a toujours été infoutu de traiter ce pb. D'ailleurs, tous les bouquins algorithmiques de l'époque étaient présentés avec des exemples en C...

Et pour ce qui est du run everywhere, les implémentations des machines virtuelles ont longtemps été folkloriques.

[neuneu2k]

Pour ma part, je considère que la JVM n'avait aucune valeur avant la 1.2 (voir la 1.3), c'est l’arrivée de hotspot qui en fait une plateforme intéressante, pas le langage fadasse.

 

Se focaliser sur le langage est une erreur, c'est un langage assez faible mais qui à comme seul mérite la lisibilité (tiens tiens...), c'est la technologie sous-jacente qui est très importante, qui permet d'avoir des performances exceptionnelles pour du code applicatif à basse complexité de développement (évidemment, pour du code critique, c'est comme toute machine, il faut connaitre les fondamentaux, et ça fait une couche en plus à connaitre).

 

Je défie 99% des développeurs C de venir me dire les caractéristiques de performance de leur implémentation de malloc sous la pression mémoire, de savoir si leur code est cache-friendly en environnement NUMA, les gens qui font du code qui à besoin de ce niveau de performance n'ont aucun problème avec java.

 

Oui, au dela d'un certain niveau, il faut avoir son propre allocateur pour certaines structures, quel que soit le langage, mais ça se fait aussi facilement avec sun.misc.unsafe q'en C, et dans les deux cas, de toute façon, c'est non portable.

 

On ne parle pas de portabilité d'architecture la, on parle de portabilité sur des changements mineurs, j'ai du code qui a des branches différentes selon qu'il tourne sur du Sandy Bridge ou du Ivy Bridge, et des branches différentes selon qu'il y à deux CPU ou quatre CPU (parce que le rapport de cout entre copie de données et messenging inter CPU s'inverse).

 

Tl;Dr: H16 n'a jamais vu un développeur java compétent, et comme il n'est pas tout jeune, il a des souvenirs roses de l'époque ou les gens codaient en C et ou par contre, il à connu des gens compétents.

 

 

 

[h16]

Tl;Dr: H16 n'a jamais vu un développeur java compétent, et comme il n'est pas tout jeune, il a des souvenirs roses de l'époque ou les gens codaient en C et ou par contre, il à connu des gens compétents.

Ben justement, je connais deux trois codeurs java très compétents, donc non.

Je dis que l'écrasante majorité ne sait pas programmer, et qu'avec les programmeurs C, la proportion de nuls était plus faible.

[neuneu2k]

Ben justement, je connais deux trois codeurs java très compétents, donc non.

Je dis que l'écrasante majorité ne sait pas programmer, et qu'avec les programmeurs C, la proportion de nuls était plus faible.

 

La différence c'est qu'il y en à bien plus, au total, tout le monde et son chien a la sortie de l'école d'ingé fait du développement, donc forcément, y'a un afflux de tocard, qu'ils fassent du java ou du microcode, ça change pas grand chose, mais tu confonds l'époque avec le langage de l'époque, cargo cult !

[h16]

Il y a peut-être une question de nostalgie, mais si je te dis qu'il y a plus de facilité à écrire de la merde en Basic qu'en C, tu en conviendras aisément. Et c'est pareil avec Java. En gros, les erreurs sont plus sournoises et méchantes en C qu'en Java ce qui impose une barrière à l'entrée en terme de propreté des mécanismes intellectuels qui sous-tendent un programme en C, barrière bien plus basse en Java.

Et je parlais de proportion, donc le fait que tout le monde et son chien code en Java ne change rien. La raison est simple : l'info est maintenant plus facilement vue comme une débouchée moyenne pour trouver un job qu'il y a 20 ou 30 ans. Il y a 20 ans, rares étaient ceux qui faisaient ça par dépit ou faute de mieux.

[Sloonz]

Je défie 99% des développeurs C de venir me dire les caractéristiques de performance de leur implémentation de malloc sous la pression mémoire, de savoir si leur code est cache-friendly en environnement NUMA, les gens qui font du code qui à besoin de ce niveau de performance n'ont aucun problème avec java.

Quand tu es à ce niveau (à la fois en termes de compétences et de besoin), c’est qu’à priori tu es tout à fait capable de faire du C. Dans ce cas, pourquoi s’emmerder à ajouter une couche d’abstraction en plus quand l’objectif c’est justement d’optimiser au plus proche du matériel ? Pour le plaisir de s’ajouter de la complexité ?

[neuneu2k]

Non, tout simplement parce qu'on ne fait pas un composent bas niveau à haute performance indépendamment du besoin applicatif, et pour le code de haut niveau, c'est pas compliqué, a effort égal, le code java est plus performant et plus sur que le code C.

 

Evidemment, on peut aussi être en max effort pour tout le code et pas juste sur le code critique et faire tout en C, mais ça coûte une blinde et ça n'apporte strictement rien.

 

 

[neuneu2k]

Il y a des gens dont le rôle, c'est de traduire le business en code, pas de faire de l'infrastructure, ce que je leur demande c'est pas d’être des experts mais de connaitre leurs limites et leur domaine de compétence (et c'est déjà pas gagné) et d'y rester.

 

Faire les choses en C, le défaut c'est que si tu à une proportion peut être un peu plus élevée d'experts, tu à aussi une proportion plus élevée de gens qui croient en être, et qui vont sortir de leur domaine de compétence et foutre la merde.

 

J'ai travaillé sur les deux types de systeme, et entre un type en java qui ne comprends pas le hardware et un type en C qui ne comprends pas le hardware mais s'imagine etre "proche du métal" et fait sa propre liste chainée ratée, j'ai fait mon choix !

 

Et je ne parle meme pas du C++, qui est de facto le cumul des défauts des deux.

 

Si on parle de langage et de plateforme, les deux sont corrects, je préfère le java sur beaucoup de points, en particulier l’écosystème, et le C sur quelques points (des types primitifs plus riches principalement), si on parle de communauté, la communauté java est remplie de tocards et à au total plus de développeurs incapables, mais par contre à une proportion nettement plus faible de demi-habiles hyper-dangereux.

 

 

 

 

[Poil à gratter]

Ben justement, je connais deux trois codeurs java très compétents, donc non.

Je dis que l'écrasante majorité ne sait pas programmer, et qu'avec les programmeurs C, la proportion de nuls était plus faible.

 

À 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.

[Poil à gratter]

Il y a des gens dont le rôle, c'est de traduire le business en code, pas de faire de l'infrastructure, ce que je leur demande c'est pas d’être des experts mais de connaitre leurs limites et leur domaine de compétence (et c'est déjà pas gagné) et d'y rester.

 

Faire les choses en C, le défaut c'est que si tu à une proportion peut être un peu plus élevée d'experts, tu à aussi une proportion plus élevée de gens qui croient en être, et qui vont sortir de leur domaine de compétence et foutre la merde.

 

J'ai travaillé sur les deux types de systeme, et entre un type en java qui ne comprends pas le hardware et un type en C qui ne comprends pas le hardware mais s'imagine etre "proche du métal" et fait sa propre liste chainée ratée, j'ai fait mon choix !

 

Et je ne parle meme pas du C++, qui est de facto le cumul des défauts des deux.

 

Si on parle de langage et de plateforme, les deux sont corrects, je préfère le java sur beaucoup de points, en particulier l’écosystème, et le C sur quelques points (des types primitifs plus riches principalement), si on parle de communauté, la communauté java est remplie de tocards et à au total plus de développeurs incapables, mais par contre à une proportion nettement plus faible de demi-habiles hyper-dangereux.

 

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.

[Noob]

Non, tout simplement parce qu'on ne fait pas un composent bas niveau à haute performance indépendamment du besoin applicatif, et pour le code de haut niveau, c'est pas compliqué, a effort égal, le code java est plus performant et plus sur que le code C.

+200.

Quand on voit la somme de bug corrigés dans les années 2000-2010 liés uniquement à des problème d'overflow, on se demande bien où sont passés les stars de la programmation dont tout le monde parle.

La réalité c'est que plus humblement plein de gens codent encore comme on leur a appris dans leur école.

[Theor]

Finalement, j'ai retenté Linux avec un nouveau shell et redonné sa chance à Gnome 3 plutôt que XFCE.

 

En fait, quand on l'utilise de la façon dont il est conçu pour, on se surprend à trouver le workflow efficace.

Le concept des workspaces dynamiques sur lesquels on disperse ses fenêtres sans les minimiser est très unixien dans l'âme. L'UI est superbement raffinée et minimaliste, les raccourcis claviers pour passer d'un workspace à un autre et y assigner les fenêtres sont bien pensés. On bosse sans quitter le clavier comme un tiling WM.

Mais surtout, ça marche bien. MS Office/Wine ne crash plus, le drag'n drop entres VM sous VirtualBox fonctionne enfin correctement, je n'ai plus de problèmes de connexion GVFS, les composants communiquent tous correctement entre eux.

 

Quand on s'est habitué à utiliser les workspaces dynamiques, revenir à la barre des tâches des autres DE donne l'impression d'utiliser des clones vieillissants de Windows 95.

 

Bref, essayez d'adopter le nouveau paradigme quelques heures avant de trop critiquer Gnome 3, parce que finalement c'est plutôt efficace et bien foutu, surtout avec quelques extensions.

[Malky]

Rammstein style coding
 

[Theor]

J'ai testé Office 365 pour avoir la suite Office (et surtout Outlook) en natif sous Linux.

 

C'est globalement bien foutu, la qualité et la fonctionnalité des webapps est essentiellement identique aux versions lourdes. Tout est là, ce ne sont pas des versions light comme Google Docs.

 

Mes déceptions sont les suivantes :

- Impossible d'éditer directement un document par glisser-déposer, il faut d'abord l'uploader sur Skydrive puis le re-télécharger sur le disque une fois terminé... On s'y fait, mais c'est pas pratique

- Les présentations plein écran se font dans un pop-up maximisé, pas en plein écran réel

- Outlook ne gère pas IMAP pour les comptes emails hébergés sur Google Apps, ce qui est mon cas... Or c'est surtout Outlook qui m'intéressait...

 

Les premiers points sont pénalisants, mais le dernier est bloquant. Tant pis, il faudra attendre 2014 pour la version Linux native officielle.

[Jesrad]

Je me suis mis à checkio, après un an sans coder ça décrasse