Tu as raison c'est assez dommage de bruler du jus pour rien.
Par contre il peut prendre entre énormement et un petit peu de CPU quand il idle dans les menus en fonction de la config et de certains plugins (dont certains par viennent par défaut comme le cache). J'ai pas encore testé la 12 mais la 10 et la 11 sans config idlaient à plus de 40% CPU sur un U2300 alors qu'après réglage ca tombe à 3%…
Bha justement je ne vois rien dans la dépêche et c'est bien là ma question. 99% du contenu est bateau. Dire qu'on peut utiliser des flux RSS, twitter, site web ou rencontrer des gens pour faire de la veille je pense que tu n'apprends rien à personne; ou en tout cas aux personnes concernées. De même pour savoir si tu vas écrire sur un wiki (doku, moinmoin), ton blog (dotclear, wordpress) ou envoyer un mot doux (outlook, lotus notes) à ton boss.
D'un autre côté tout ce qui peut être intéressant et spécifique au sujet est passé sous silence. Par exemple tu nous fais un joli paragraphe sur la curation mais il tombe a plat, aucune info rien.
Bref si je me permets la remarque c'est que je pense que tu as des choses intéressantes à dire mais que tu ne les as pas dites. Peut être la faute à vouloir ratisser trop large. Quelqu'un qui doit faire de la veille techno tu n'as pas besoin de lui expliquer que RSS existe ou qu'il peut avoir un blog. Tu peux utiliser ces caractères pour dire des choses plus intéressantes il me semble. De même proposer un, ton, workflow peut être un bon point de départ pour lancer des discussions. Une liste d'outil ces intéressants mais ca se trouve facilement si tu ne fais que lister leur nom.
Pour moi, 2 fichiers php qui servent de moteur, des fichiers textes en txt2tags qu'on envoit sur le serveur, et ça suffit pour monter un blog :
Ca n'a rien de statique ton truc .
Tu paies l'overhead du PHP pour servir des choses qui n'en ont pas besoin.
Tu paies le cout de maintenance (c'est dégueulasse les variables dans les .php)
Tu paies la sécurité d'un truc dynamique. Oh un joli XSS sur ton blog statique…
Et on peut continuer.
Non la solution de crEv est très élégante. D'ailleurs je recommande le même genre d'approche pour écrire la documentation dans vos équipe de dev. Dégagez les wiki dont l'UX est assez moisie et remplacez les par ce genre de système. On peut facilement réutiliser tout les outils de dev, de l'éditeur au VCS en passant par l'intégration continue ou grep pour trouver les infos. C'est du coup vachement plus productif. Pour ceux qui aiment pas le Ruby y'a Markdoc en Python qui fait le job.
Bref, je pense qu'on n'est pas loin d'être d'accord mais que je suis plus nuancé.
Je pense aussi.
Tu vois les petites avancés des deux dernières releases de Java comme des plus. Ce qui est vrai. J'y vois un constat d'échec de n'avoir eu droit qu'a du sucre et ne pas s'être attaqué aux vrais problème en 7 ans. Je ne suis pas certain que l'argument compilé tienne entièrement. Car il y a déjà énormement à faire du côté JDK comme le trillion de libs le prouve.
Pour l'utilité de Sonar tu as raison encore. Évidement je caricature avec mes gros sabots car la phrase "Gérer la qualité avec Sonar" me fait rire. Ce n'est pas l'outil qui gère la qualité. C'est la démarche, l'organisation et la dynamique de l'équipe de dev. Si un dashboard sur l'intraweb aide très bien. Le travers de ce genre d'outil c'est que c'est généralement mis en place de facon transverse et la tout par en vrille. On sort du monde de la démarche pour entrer dans celui de l'outil.
Et on semble aussi d'accord sur le "1000x plus rentable". Tu le dis toi même je pense. Sonar c'est la couche de polish pour une équipe qui ronronne déjà et qui s'est déjà posé les bonnes questions et qui à déjà eu la démarche de chercher à livrer bien et toujours mieux. C'est désolant mais très peu de gens en sont là ou n'ont même pas réussi à comprendre qu'ils n'en étaient pas là. Dans ce genre de cas le truc genre Sonar font rapidement plus de mal que de bien.
Après comme le l'ai dit si tu fait de la webapp ou assimilé en Java ton monde à entièrement changé en bien c'est 5 dernières années. Si tu es dans les couches basses et les choses "plus techniques", ce qui est mon cas, ton avis est peu être beaucoup plus nuancé.
C'est marrant tu reprend Guillaume qui dit que le langage c'est amélioré et l'argument que tu donne c'est quelque chose qui justement a évolué dans le bon sens.
C'est volontaire par ce que c'est l'argument le plus grossier pour ne pas rentrer dans un discours pointilleux. On peut lister des dizaines d'exemples mais je trouve que c'est sans fin et ca n'a que peut d'intêret.
Et ça c'est bien. Si tu as besoin d'un langage qui a le comportement inverse choisi python.
Java à un énorme problème de ce côté là. Le langage et la lib standard se retrouvent paralysées. Y'a un moment ou il faut faire quelque chose (et on peut le faire sans rien, ou trop, casser) mais le JDK à du mal.
Par common, je présume que tu parle de common collections principalement.
Absolument pas. Si je dis commons c'est commons. Pas un sous projet précis de commons.
Pour guava une partie n'a plus de sens avec Java 7 grâce à des évolutions de la bibliothèque standard et du langage.
Voila. Le fait que le JDK ait besoin d'être patché dans tout les sens pour le rendre productif et éviter de réinventer la roue implique une fragmentation de malade. Dès que tu ne bosses sur des projets sérieux tu te retrouves avec une base de code qui mélange 3 libs faisant presque la même chose mais qui ne se recouvrent pas entièrement donc tu dois garder les 3.
En fait le problème est juste délégué d'un niveau on se retrouve avec un sale JAR hell et des dépendances délirantes.
Tu peux développer ? Notamment au niveau de ce que tu appelles "outils de base" ?
Ca va être extrêment grossier donc pas très intéressant et sujet à dérive.
Pour le SE basiquement le langage, entre Java 5 et Java 7, est mort. Il y a eu d'énorme loupés dans le design de lib standard et des collections qui ne sont pas corrigés par soucis de backward compatibilité et qui forcent à mélanger 100 bibliothèques qui font la même chose (bonjour commons, guava & les amis). C'est assez pauvre en ADT. L'interaction avec les systèmes hôtes est ridicule. Pour prendre l'exemple le plus grossier il a fallut attendre fin 2011 pour avoir un accès basique aux fichiers.
Note que je ne dis pas "Java c'est nul". Je dis que c'est un langage moyen qui n'évolue plus mais qui est sauvé par d'excellentes boîtes logicielle et son outillage. J'ai certainement une vision biaisée par rapport à pas mal de dev Java qui font majoritairement de la webapp ou du webservice sans "gros code métier" hormis jouer avec une DB. On en revient à l'usine logicielle.
Pour un langage compilé qui a une longue histoire, je trouve que Java évolue plutôt vite et dans le bon sens.
Sur le langage il ne s'est absolument rien passé de notable entre Java 5 et Java 7. A voir si Oracle relance la machine…
Ce n'est pas parce qu'on peut en faire mauvais usage que c'est un mauvais outil.
Je n'en ai encore jamais vu un bon cas d'utilisation.
Les outils peuvent être pratique. Mais les balancer dans une webapp ca n'a que peu d'interet. Les gens qui sont dans le code seront beaucoup plus productif à intégrer les outils dans leur environnement de dev. Les gens qui ne sont pas dans le code c'est pas leur soucis. Si ils en arrivent à trouver des problèmes avec Sonar ca à dérapé depuis bien trop longtemps. Ce n'est pas un outil qu'il te faut c'est revoir complètement ton équipe et son organisation.
il se passe quand on n'est pas dans le code au quotidien.
Si tu n'es pas dans le code c'est le rôle de ton tech lead de faire ce genre de chose. Tu cherches à faire quoi en regardant le Sonar ?
C'est une bonne idée, ça. Tant qu'à faire, le mieux est de bloquer le build sur chaque problème, comme ça, chaque build devient une aventure.
C'est juste le principe de l'intégration continue: détecter et fixer les problèmes au plus tôt. Si le code est mauvais (c'est bien le but de Sonar non ? ) il ne passerait pas une code review et ne serait jamais intégré à la branche de dev. Là il a déjà été intégré donc tu échoues ton build comme tu le ferais pour un test qui ne passe pas et tu corriges maintenant. Pas dans 9 mois. Si ce n'est pas si important que ca à quoi servent les mesures et les règles mises en place ?
Si tu fonctionnes par patch et par code review tu peux même le faire en avance. C'est ce que font la plupart des projets Apache par exemple. Quand tu attaches un patch au bugtracker le robot fait passer un build et compare son résultat par rapport au dernier build. Il donne un +1 ou -1 pour chaque mesure. Le code n'est pas intégré tant que c'est pas vert ou que quelqu'un décide manuellement que c'est ok quand même.
Dire que c'est "la dernière chose dont tu as besoin" est volontairement provocateur qui vient contrebalancer le "Sonar youhou c'est super". Mais je pense vraiment que si tu cherches à produire du soft de qualité c'est effectivement très très très loin sur ta liste de priorité que tu
sois dev, development manager ou project manager. Il y a tellement d'autres choses qui paient 1000x plus avant.
Une grosse partie de la lourdeur a disparu, ça a pas mal sédimenté
Au niveau des outils pour le web oui.
Au niveau du langage malheureusement non. Au niveau des outils de base malheureusement non.
Bref Java c'est cool pour assembler des briques et faire de la plomberie.
Sonar
Sonar c'est vraiment le dernier truc dont tu as besoin pour "gérer la qualité". Ca fini toujours en porn-metric qui ne sert à rien. Si tu as des règles à faire respecter et qu'elles ne le sont pas ca doit bloquer ton build pas pondre des graphes.
A quoi servent des rapports sur la complexité cyclomatique, le pourcentage de commentaire ou la duplication de code ? Ton équipe est compétente et résponsable ou elle ne l'est pas. Si elle ne l'est pas installer Sonar ne résoud aucun problème. Ton projet va déjà dans le mur depuis beaucoup trop longtemp.
D'après ce que tu dis ca donne un peu plus de 42h hebdo. C'est plus que ce que font la plupart des gens que je connais en France… Par contre c'est sur que si tu arrives 2h plus tôt bin tu vas partir 2h plus tôt.
Mais le plus marrant c'est que sur le post du départ d'alan cox sur /. les ricains disent exactement la même chose d'eux et qu'ils détestent leur culture de faire des journées de malade et de rebosser le soir chez eux pour rien…
Mais bizarrement, tu ne tapes sur les gens qui sont sûrs qu'il bosse 100 heures par jour (à la base, je répondais à ce préjugé, rigolo que tu n'ai pas réagi…). L'attaque est pas mal à la tête de celui qui parle… Paille, poutre.
Par ce que je passe pas mes journées à jouer à l'art d'avoir toujours raison même si je sais pas de quoi je parle.
Du coup je sais que dans ses interviews des années RH, rip kerneltrap, il indiquait bosser dans les 60 à 70h sur le noyau. Et il a fait deux ou trois autres trucs à côté…
Il y avait la légende qu'il ne dormait jamais et Linus à dit un jour " Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea. None of the individual gnomes read all the postings either, they just work together really well. "
Perso, je trouve que c'est surtout insultant pour lui que vous croyez qu'il ne soit pas si compétent que ça, chacun sa façon de voir.
Il est extrêment compétent ET il a fait des heures. Mais ca il faut savoir de qui on cause pour pouvoir l'affirmer plutôt que de passer son temps à parler pour parler…
Je vais probablement me faire arracher la tete par plein de gens ici mais… Qu'est ce qui nous dit franchement qu'Alan Cox etait un "tout bon" ?
Il suffit de regarder ses contributions depuis plus 20 ans. Il a a la fois touché un nombre incroyable de domaines et sous systèmes, et à toujours eu une démarche de faire des choses qui marchent et de fixer celles qui ne marchent pas. C'est un bon codeur et un bon ingénieur.
Tu as raison dans un sens que ce n'est pas un concours et que beaucoup de gens ont tendance à focaliser sur les dev noyau Linux alors qu'il existe plein de talents ailleurs (souvent caché dès qu'ils ne sont pas dans l'open source). Mais il se classe définitivement dans le paquet des extrêmement bons: des mecs capables de bosser sur n'importe quoi, à toujours faire des choses qui marchent avec une productivité démentielle. Sans aucune idolaterie croire que qu'il suffit de se mettre à bosser pour attraper des mecs comme ça, c'est un poil naïf. Y'a un moment dans ta vie quelque soit ton niveau tu te rends compte qu'on est pas tous égaux.
Maintenant si tu vas dans le sens de Zenitram avec un refrain "Il fait juste son travail c'est un type normal". Je te propose une interview pour lui demander son volume horaire (au moins à l'époque) et des interviews des mecs qui ont bossés avec lui sur sa productivité. J'ai pas suivi ce qu'il a fait ces dernières années, mais tout le monde dit qu'il ne dort pas (quand il a arrêté le 2.4-ac il a dit que ça lui permettrait de dormir) et niveau productivité il semble y avoir consensus aussi.
1) le suivi des conversations grâce au système des nhorloges. je sais que l'idée de créer un système équivalent à été cherché dans jabber, mais sans succès.
Suivre des conversations dans un système décentralisé c'est juste des horloges de lamport.
Atteindre le niveau de Alan Cox ne semble pas insurmontable, il faut y mettre les moyens et en avoir la volonté.
C'est que tu as jamais bossé avec des vraiment bons. Des mecs qui arrivent à être 4 à 10x plus productif que toi (je suppose que tu es bon) et qui en plus sont capable d'enchainer 70+h/semaine. Bref des machines.
Tu peux bosser autant que tu veux, tu progresseras mais penser qu'il suffit de bosser pour arriver au niveau de n'importe qui est un poil naïf. C'est comme dans toutes les disciplines, en bossant comme un chien tu arrives à te hisser aux championnats de France. Mais tu es encore très très loin du niveau élite…
Dans l'autre sens je comprends même si c'est stupide. Mais dans ce sens là non. L'inconscient collectif il a même oublié que ça existait les jeux de rôles.
Laisse tomber c'est Zenitram. Il va te développer une théorie sur 300 posts pour t'expliquer qu'il a raison en se focalisant sur son point de départ alors qu'il n'a foutrement aucune idée (tout comme toi ou moi) du volume de travail qu'abattent réellement les gens dont il parle.
Il part d'une base vraie: "C'est leur boulot" par contre savoir si les mecs bossent 7 ou 16h/jour et la charge de travail qu'ils ont du bouffer pour arriver à leur poste c'est laissé en exercice. Bref encore une discussion très instructive signée Zoro…
Bin voilà. Jeune diplômé sorti de l'école, on m'a aussi proposé des "super" postes payé des queues de cerise dans des labos de recherche (en plus généralement précaire CDD non renouvelable) et des postes dans le privé payés un salaire décent (et CDI).
En l'occurence ce n'est pas un poste mais un stage. Et je pense que c'est une très bonne chose de voir ca comme un investissement à long terme et se foutre de la rentabilité immédiate. C'est extrêment variable en fonction des équipes mais c'est l'occasion de faire des choses intéressantes et de t'ouvrir beaucoup de portes. Au final quand tu regardes les salaires de ceux qui sont passé par là…
Après ce que tu dénnonces sur les CDD de la recherche en France est vrai. En dehors des postes pour jeunes ingénieur qui sont intéressant sur le plan carrière et correct sur le plan financier c'est une vaste blague.
Là, on a pas le salaire, mais on a l'incommensurable honneur de pouvoir participer aux RMLL,
Ca se réfléchi. Les RMLL uniquement c'est un peu faible. Mais avoir l'occasion de naviguer dans les grandes confs en début de carrière c'est pouvoir se faire une très bonne vision du marché et rencontrer plein de gens… qui travailent et recrutent dans ton milieu.
Et cerise sur le gâteau: on nous dit que dans ce labo, on peut ne pas travailler (faire du kayak), alors oui trouver un gars motivé par le fait d'aller faire du canoë n'est pas le meilleur moyen de trouver un codeur.
Jamais vu de remarque aussi con.
On te propose un poste dans une région qui à un climat et une localisation qui permet de faire des activités extérieurs toutes l'année. Beaucoup de monde de toutes les boîtes en profite. Ca n'a aucune incidence sur la qualité ou la quantité du travail. Tu vas faire 2h15 de VTT le midi ? Bin tu arrives/pars 1h15 plus tôt/tard que celui qui à pris 1h… Un codeur c'est pas un autiste frusté hein.
Je ne sais pas comment tu fais, mais perso je voyage quasiment toujours sans "guide", ce qui m'a certes amené aux "grandes places" (faut quand même les voir) mais aussi permit de découvrir plein de petits endroits non touristiques bien sympathiques.
Oui par ce que si tu as un guide dans les mains tu ne peux absolument pas découvrir plein de petits endroits non touristiques bien sympathiques par ce qu'il te force à faire ce qu'il veut…
PLONK.
Autrement rien à voir mais conseil de photographe apprenez à vous lever très tôt ou à ressortir tard ainsi qu'avoir une notion des points cardinaux et des heures de coucher/lever soleil. Y'a moyen de découvrir des lieux touristiques sous un tout autre angle.
Plus sérieusement, avec ces conneries ils vont finir par dire que Linux est plus vérolé que Windows !
Je suis le seul à le voir venir gros comme une maison ?
Bha ca calmerait les linuxiens qui vivent sur un nuage et n'ont toujours pas compris qu'à partir du moment ou l'utilisateur peut rajouter du code exécutable à son environnement c'est game over avec Linux aussi…
" Once forwarded in the core Internet, LISP-encapsulated
packets look like any other UDP packets, achieving goal 2).
Indeed, UDP packets transit in the core and traverse middle-
boxes. This point is very important as middle boxes are likely
to refuse, because of security reasons, to process datagrams
with unknown features such as protocol numbers, IP options,
or addressing syntax. "
Ca me laisse le même goût que toi, c'est conceptuellement crade et ca va être rigolo au niveau du MTU mais comme souvent si tu veux pouvoir déployer il faut que ca puisse se faire incrémentalement à partir de la situation d'aujourd'hui. Ce qui semble justifier le choix de tunneller dans de l'UDP
L'usage de map fait de toute façon débat, pylint trouve que c'est pas terrible. Sans chercher à savoir quelle écriture est la plus compréhensible, s'ils utilisent ce genre d'outils pour noter le code, c'est normal que l'usage de map fasse perdre des points.
L'étape suivante c'est de coder pour faire plaisir aux 400 rapports Sonar totalement stupides mis en place par des "génies logiciels". Mais l'important c'est que ce soit vert sans chercher à comprendre pourquoi ! C'est gage d'un bon soft…
L'important c'est d'énnoncer des conventions et de pouvoir les justifier très facilement, pas de tourner à droite par ce qu'on te dit de tourner à droite. Les conventions Google sont très bonnes la dessus en justifiant toujours le pourquoi de leur décisions (et ils virent map/reduce d'ailleurs). Mais ca ne reste qu'un ensemble de choix parmis tant d'autres.
( WoW et Starcraft 2 pendant un an, Diablo 3 pendant quelques mois ; […] c'est un putain de sacerdoce. C'est certes gratifiant pour un libriste intégriste, on a l'esprit tranquille conceptuellement,
Y'a un pull request en attente. Si tu as une idée de comment détecter les commits qui n'ont pas été pushés sans rajouter de coût à l'exécution n'hésite pas.
Le support de bzr se sent quand même dans les perfs. On peut améliorer le truc car le design actuel de _lp_set_prompt force à lancer deux fois bazaar alors qu'une suffirait. Je suis pas sur d'avoir le temps de m'y pencher si tu as du temps à perdre ;)
Affirmatif. J'ai fait un proto rapidement, le support modifié/non modifié est trivial. Avoir le même niveau de support que git demande un peu plus de travail par contre (notamment les commits locaux à pusher et le numstat). Il serait peut être bon d'avoir une nouvelle couleur pour les merges non commités aussi.
Après les perfs de Bazaar étant toujours aussi désastreuses ca plombe pas mal l'interactivité du shell. Faut voir si c'est viable car un simple bzr nick et bzr diff rendre le shell inutilisable…
[^] # Re: charge CPU en veille
Posté par ckyl . En réponse à la dépêche XBMC 12 "Frodo" est de sortie. Évalué à 3.
Tu as raison c'est assez dommage de bruler du jus pour rien.
Par contre il peut prendre entre énormement et un petit peu de CPU quand il idle dans les menus en fonction de la config et de certains plugins (dont certains par viennent par défaut comme le cache). J'ai pas encore testé la 12 mais la 10 et la 11 sans config idlaient à plus de 40% CPU sur un U2300 alors qu'après réglage ca tombe à 3%…
[^] # Re: Utilité ?
Posté par ckyl . En réponse à la dépêche Méthode et outils pour la veille technologique. Évalué à 10.
Bha justement je ne vois rien dans la dépêche et c'est bien là ma question. 99% du contenu est bateau. Dire qu'on peut utiliser des flux RSS, twitter, site web ou rencontrer des gens pour faire de la veille je pense que tu n'apprends rien à personne; ou en tout cas aux personnes concernées. De même pour savoir si tu vas écrire sur un wiki (doku, moinmoin), ton blog (dotclear, wordpress) ou envoyer un mot doux (outlook, lotus notes) à ton boss.
D'un autre côté tout ce qui peut être intéressant et spécifique au sujet est passé sous silence. Par exemple tu nous fais un joli paragraphe sur la curation mais il tombe a plat, aucune info rien.
Bref si je me permets la remarque c'est que je pense que tu as des choses intéressantes à dire mais que tu ne les as pas dites. Peut être la faute à vouloir ratisser trop large. Quelqu'un qui doit faire de la veille techno tu n'as pas besoin de lui expliquer que RSS existe ou qu'il peut avoir un blog. Tu peux utiliser ces caractères pour dire des choses plus intéressantes il me semble. De même proposer un, ton, workflow peut être un bon point de départ pour lancer des discussions. Une liste d'outil ces intéressants mais ca se trouve facilement si tu ne fais que lister leur nom.
# Utilité ?
Posté par ckyl . En réponse à la dépêche Méthode et outils pour la veille technologique. Évalué à 5.
TL;DR: Tu lis des informations, tu les notes, tu en fais ce qu'il te semble utile.
Je me suis fais une reflexion en lisant la nouvelle: "Tant de mots pour ne rien dire". Je suis le seul ?
[^] # Re: usine à gaz
Posté par ckyl . En réponse au journal Web Log Today est juillet - écrire un blog de nos jours. Évalué à 5.
Générer des fichier statiques compliqué ?
Ca n'a rien de statique ton truc .
Tu paies l'overhead du PHP pour servir des choses qui n'en ont pas besoin.
Tu paies le cout de maintenance (c'est dégueulasse les variables dans les .php)
Tu paies la sécurité d'un truc dynamique. Oh un joli XSS sur ton blog statique…
Et on peut continuer.
Non la solution de crEv est très élégante. D'ailleurs je recommande le même genre d'approche pour écrire la documentation dans vos équipe de dev. Dégagez les wiki dont l'UX est assez moisie et remplacez les par ce genre de système. On peut facilement réutiliser tout les outils de dev, de l'éditeur au VCS en passant par l'intégration continue ou grep pour trouver les infos. C'est du coup vachement plus productif. Pour ceux qui aiment pas le Ruby y'a Markdoc en Python qui fait le job.
[^] # Re: Usine
Posté par ckyl . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 3.
Je pense aussi.
Tu vois les petites avancés des deux dernières releases de Java comme des plus. Ce qui est vrai. J'y vois un constat d'échec de n'avoir eu droit qu'a du sucre et ne pas s'être attaqué aux vrais problème en 7 ans. Je ne suis pas certain que l'argument compilé tienne entièrement. Car il y a déjà énormement à faire du côté JDK comme le trillion de libs le prouve.
Pour l'utilité de Sonar tu as raison encore. Évidement je caricature avec mes gros sabots car la phrase "Gérer la qualité avec Sonar" me fait rire. Ce n'est pas l'outil qui gère la qualité. C'est la démarche, l'organisation et la dynamique de l'équipe de dev. Si un dashboard sur l'intraweb aide très bien. Le travers de ce genre d'outil c'est que c'est généralement mis en place de facon transverse et la tout par en vrille. On sort du monde de la démarche pour entrer dans celui de l'outil.
Et on semble aussi d'accord sur le "1000x plus rentable". Tu le dis toi même je pense. Sonar c'est la couche de polish pour une équipe qui ronronne déjà et qui s'est déjà posé les bonnes questions et qui à déjà eu la démarche de chercher à livrer bien et toujours mieux. C'est désolant mais très peu de gens en sont là ou n'ont même pas réussi à comprendre qu'ils n'en étaient pas là. Dans ce genre de cas le truc genre Sonar font rapidement plus de mal que de bien.
Après comme le l'ai dit si tu fait de la webapp ou assimilé en Java ton monde à entièrement changé en bien c'est 5 dernières années. Si tu es dans les couches basses et les choses "plus techniques", ce qui est mon cas, ton avis est peu être beaucoup plus nuancé.
[^] # Re: Usine
Posté par ckyl . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 3.
C'est volontaire par ce que c'est l'argument le plus grossier pour ne pas rentrer dans un discours pointilleux. On peut lister des dizaines d'exemples mais je trouve que c'est sans fin et ca n'a que peut d'intêret.
Java à un énorme problème de ce côté là. Le langage et la lib standard se retrouvent paralysées. Y'a un moment ou il faut faire quelque chose (et on peut le faire sans rien, ou trop, casser) mais le JDK à du mal.
Absolument pas. Si je dis commons c'est commons. Pas un sous projet précis de commons.
Voila. Le fait que le JDK ait besoin d'être patché dans tout les sens pour le rendre productif et éviter de réinventer la roue implique une fragmentation de malade. Dès que tu ne bosses sur des projets sérieux tu te retrouves avec une base de code qui mélange 3 libs faisant presque la même chose mais qui ne se recouvrent pas entièrement donc tu dois garder les 3.
En fait le problème est juste délégué d'un niveau on se retrouve avec un sale JAR hell et des dépendances délirantes.
[^] # Re: Usine
Posté par ckyl . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 4.
Ca va être extrêment grossier donc pas très intéressant et sujet à dérive.
Pour le SE basiquement le langage, entre Java 5 et Java 7, est mort. Il y a eu d'énorme loupés dans le design de lib standard et des collections qui ne sont pas corrigés par soucis de backward compatibilité et qui forcent à mélanger 100 bibliothèques qui font la même chose (bonjour commons, guava & les amis). C'est assez pauvre en ADT. L'interaction avec les systèmes hôtes est ridicule. Pour prendre l'exemple le plus grossier il a fallut attendre fin 2011 pour avoir un accès basique aux fichiers.
Note que je ne dis pas "Java c'est nul". Je dis que c'est un langage moyen qui n'évolue plus mais qui est sauvé par d'excellentes boîtes logicielle et son outillage. J'ai certainement une vision biaisée par rapport à pas mal de dev Java qui font majoritairement de la webapp ou du webservice sans "gros code métier" hormis jouer avec une DB. On en revient à l'usine logicielle.
Sur le langage il ne s'est absolument rien passé de notable entre Java 5 et Java 7. A voir si Oracle relance la machine…
Je n'en ai encore jamais vu un bon cas d'utilisation.
Les outils peuvent être pratique. Mais les balancer dans une webapp ca n'a que peu d'interet. Les gens qui sont dans le code seront beaucoup plus productif à intégrer les outils dans leur environnement de dev. Les gens qui ne sont pas dans le code c'est pas leur soucis. Si ils en arrivent à trouver des problèmes avec Sonar ca à dérapé depuis bien trop longtemps. Ce n'est pas un outil qu'il te faut c'est revoir complètement ton équipe et son organisation.
Si tu n'es pas dans le code c'est le rôle de ton tech lead de faire ce genre de chose. Tu cherches à faire quoi en regardant le Sonar ?
C'est juste le principe de l'intégration continue: détecter et fixer les problèmes au plus tôt. Si le code est mauvais (c'est bien le but de Sonar non ? ) il ne passerait pas une code review et ne serait jamais intégré à la branche de dev. Là il a déjà été intégré donc tu échoues ton build comme tu le ferais pour un test qui ne passe pas et tu corriges maintenant. Pas dans 9 mois. Si ce n'est pas si important que ca à quoi servent les mesures et les règles mises en place ?
Si tu fonctionnes par patch et par code review tu peux même le faire en avance. C'est ce que font la plupart des projets Apache par exemple. Quand tu attaches un patch au bugtracker le robot fait passer un build et compare son résultat par rapport au dernier build. Il donne un +1 ou -1 pour chaque mesure. Le code n'est pas intégré tant que c'est pas vert ou que quelqu'un décide manuellement que c'est ok quand même.
Dire que c'est "la dernière chose dont tu as besoin" est volontairement provocateur qui vient contrebalancer le "Sonar youhou c'est super". Mais je pense vraiment que si tu cherches à produire du soft de qualité c'est effectivement très très très loin sur ta liste de priorité que tu
sois dev, development manager ou project manager. Il y a tellement d'autres choses qui paient 1000x plus avant.
[^] # Re: Usine
Posté par ckyl . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 4. Dernière modification le 30 janvier 2013 à 09:49.
Au niveau des outils pour le web oui.
Au niveau du langage malheureusement non. Au niveau des outils de base malheureusement non.
Bref Java c'est cool pour assembler des briques et faire de la plomberie.
Sonar c'est vraiment le dernier truc dont tu as besoin pour "gérer la qualité". Ca fini toujours en porn-metric qui ne sert à rien. Si tu as des règles à faire respecter et qu'elles ne le sont pas ca doit bloquer ton build pas pondre des graphes.
A quoi servent des rapports sur la complexité cyclomatique, le pourcentage de commentaire ou la duplication de code ? Ton équipe est compétente et résponsable ou elle ne l'est pas. Si elle ne l'est pas installer Sonar ne résoud aucun problème. Ton projet va déjà dans le mur depuis beaucoup trop longtemp.
[^] # Re: rapidité, changement
Posté par ckyl . En réponse au journal Systemd: tuons les mythes. Évalué à 5.
Vous avez surtout de super bon yeux pour les utiliser comme base pour en faire une généralité.
[^] # Re: Chapeau bas l'artiste !
Posté par ckyl . En réponse au journal Alan Cox quitte le kernel. Évalué à 3.
D'après ce que tu dis ca donne un peu plus de 42h hebdo. C'est plus que ce que font la plupart des gens que je connais en France… Par contre c'est sur que si tu arrives 2h plus tôt bin tu vas partir 2h plus tôt.
Mais le plus marrant c'est que sur le post du départ d'alan cox sur /. les ricains disent exactement la même chose d'eux et qu'ils détestent leur culture de faire des journées de malade et de rebosser le soir chez eux pour rien…
[^] # Re: Chapeau bas l'artiste !
Posté par ckyl . En réponse au journal Alan Cox quitte le kernel. Évalué à 8.
Par ce que je passe pas mes journées à jouer à l'art d'avoir toujours raison même si je sais pas de quoi je parle.
Du coup je sais que dans ses interviews des années RH, rip kerneltrap, il indiquait bosser dans les 60 à 70h sur le noyau. Et il a fait deux ou trois autres trucs à côté…
Il y avait la légende qu'il ne dormait jamais et Linus à dit un jour " Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea. None of the individual gnomes read all the postings either, they just work together really well. "
Il est extrêment compétent ET il a fait des heures. Mais ca il faut savoir de qui on cause pour pouvoir l'affirmer plutôt que de passer son temps à parler pour parler…
Tu sais au moins ce sur quoi il a bossé hein ?
[^] # Re: Chapeau bas l'artiste !
Posté par ckyl . En réponse au journal Alan Cox quitte le kernel. Évalué à 5.
Il suffit de regarder ses contributions depuis plus 20 ans. Il a a la fois touché un nombre incroyable de domaines et sous systèmes, et à toujours eu une démarche de faire des choses qui marchent et de fixer celles qui ne marchent pas. C'est un bon codeur et un bon ingénieur.
Tu as raison dans un sens que ce n'est pas un concours et que beaucoup de gens ont tendance à focaliser sur les dev noyau Linux alors qu'il existe plein de talents ailleurs (souvent caché dès qu'ils ne sont pas dans l'open source). Mais il se classe définitivement dans le paquet des extrêmement bons: des mecs capables de bosser sur n'importe quoi, à toujours faire des choses qui marchent avec une productivité démentielle. Sans aucune idolaterie croire que qu'il suffit de se mettre à bosser pour attraper des mecs comme ça, c'est un poil naïf. Y'a un moment dans ta vie quelque soit ton niveau tu te rends compte qu'on est pas tous égaux.
Maintenant si tu vas dans le sens de Zenitram avec un refrain "Il fait juste son travail c'est un type normal". Je te propose une interview pour lui demander son volume horaire (au moins à l'époque) et des interviews des mecs qui ont bossés avec lui sur sa productivité. J'ai pas suivi ce qu'il a fait ces dernières années, mais tout le monde dit qu'il ne dort pas (quand il a arrêté le 2.4-ac il a dit que ça lui permettrait de dormir) et niveau productivité il semble y avoir consensus aussi.
[^] # Re: En fait...
Posté par ckyl . En réponse au journal Une tribune décentralisée est-elle possible?. Évalué à 5.
Suivre des conversations dans un système décentralisé c'est juste des horloges de lamport.
[^] # Re: Chapeau bas l'artiste !
Posté par ckyl . En réponse au journal Alan Cox quitte le kernel. Évalué à 10.
C'est que tu as jamais bossé avec des vraiment bons. Des mecs qui arrivent à être 4 à 10x plus productif que toi (je suppose que tu es bon) et qui en plus sont capable d'enchainer 70+h/semaine. Bref des machines.
Tu peux bosser autant que tu veux, tu progresseras mais penser qu'il suffit de bosser pour arriver au niveau de n'importe qui est un poil naïf. C'est comme dans toutes les disciplines, en bossant comme un chien tu arrives à te hisser aux championnats de France. Mais tu es encore très très loin du niveau élite…
[^] # Re: Bha non
Posté par ckyl . En réponse au journal Ce soir, je joue, tu joues, nous jouons !. Évalué à 4.
Dans l'autre sens je comprends même si c'est stupide. Mais dans ce sens là non. L'inconscient collectif il a même oublié que ça existait les jeux de rôles.
# Bha non
Posté par ckyl . En réponse au journal Ce soir, je joue, tu joues, nous jouons !. Évalué à 3.
C'est nouveau ? D'où tiens tu cette idée saugrenue ?
[^] # Re: Chapeau bas l'artiste !
Posté par ckyl . En réponse au journal Alan Cox quitte le kernel. Évalué à 10.
Laisse tomber c'est Zenitram. Il va te développer une théorie sur 300 posts pour t'expliquer qu'il a raison en se focalisant sur son point de départ alors qu'il n'a foutrement aucune idée (tout comme toi ou moi) du volume de travail qu'abattent réellement les gens dont il parle.
Il part d'une base vraie: "C'est leur boulot" par contre savoir si les mecs bossent 7 ou 16h/jour et la charge de travail qu'ils ont du bouffer pour arriver à leur poste c'est laissé en exercice. Bref encore une discussion très instructive signée Zoro…
[^] # Re: Je vais faire mon Gripsou, mais:
Posté par ckyl . En réponse au journal [Stage] Conception d'IHM et développement d'une application de suivi de news en rails. Évalué à 4.
En l'occurence ce n'est pas un poste mais un stage. Et je pense que c'est une très bonne chose de voir ca comme un investissement à long terme et se foutre de la rentabilité immédiate. C'est extrêment variable en fonction des équipes mais c'est l'occasion de faire des choses intéressantes et de t'ouvrir beaucoup de portes. Au final quand tu regardes les salaires de ceux qui sont passé par là…
Après ce que tu dénnonces sur les CDD de la recherche en France est vrai. En dehors des postes pour jeunes ingénieur qui sont intéressant sur le plan carrière et correct sur le plan financier c'est une vaste blague.
Ca se réfléchi. Les RMLL uniquement c'est un peu faible. Mais avoir l'occasion de naviguer dans les grandes confs en début de carrière c'est pouvoir se faire une très bonne vision du marché et rencontrer plein de gens… qui travailent et recrutent dans ton milieu.
Jamais vu de remarque aussi con.
On te propose un poste dans une région qui à un climat et une localisation qui permet de faire des activités extérieurs toutes l'année. Beaucoup de monde de toutes les boîtes en profite. Ca n'a aucune incidence sur la qualité ou la quantité du travail. Tu vas faire 2h15 de VTT le midi ? Bin tu arrives/pars 1h15 plus tôt/tard que celui qui à pris 1h… Un codeur c'est pas un autiste frusté hein.
Work smart not hard
[^] # Re: Triste voyageur
Posté par ckyl . En réponse à la dépêche Wikivoyage lancé officiellement. Évalué à 4.
Oui par ce que si tu as un guide dans les mains tu ne peux absolument pas découvrir plein de petits endroits non touristiques bien sympathiques par ce qu'il te force à faire ce qu'il veut…
PLONK.
Autrement rien à voir mais conseil de photographe apprenez à vous lever très tôt ou à ressortir tard ainsi qu'avoir une notion des points cardinaux et des heures de coucher/lever soleil. Y'a moyen de découvrir des lieux touristiques sous un tout autre angle.
[^] # Re: bureau vs grand public
Posté par ckyl . En réponse au journal quel os pour les desktop ?. Évalué à 9.
Bha ca calmerait les linuxiens qui vivent sur un nuage et n'ont toujours pas compris qu'à partir du moment ou l'utilisateur peut rajouter du code exécutable à son environnement c'est game over avec Linux aussi…
[^] # Re: Weuah…
Posté par ckyl . En réponse au journal Les RFCs sur le protocole LISP sont sortis. Évalué à 4.
" Once forwarded in the core Internet, LISP-encapsulated
packets look like any other UDP packets, achieving goal 2).
Indeed, UDP packets transit in the core and traverse middle-
boxes. This point is very important as middle boxes are likely
to refuse, because of security reasons, to process datagrams
with unknown features such as protocol numbers, IP options,
or addressing syntax. "
Ca me laisse le même goût que toi, c'est conceptuellement crade et ca va être rigolo au niveau du MTU mais comme souvent si tu veux pouvoir déployer il faut que ca puisse se faire incrémentalement à partir de la situation d'aujourd'hui. Ce qui semble justifier le choix de tunneller dans de l'UDP
[^] # Re: Impératif
Posté par ckyl . En réponse à la dépêche Concours de programmation CodinGame le 29 janvier 2013. Évalué à 2.
L'étape suivante c'est de coder pour faire plaisir aux 400 rapports Sonar totalement stupides mis en place par des "génies logiciels". Mais l'important c'est que ce soit vert sans chercher à comprendre pourquoi ! C'est gage d'un bon soft…
L'important c'est d'énnoncer des conventions et de pouvoir les justifier très facilement, pas de tourner à droite par ce qu'on te dit de tourner à droite. Les conventions Google sont très bonnes la dessus en justifiant toujours le pourquoi de leur décisions (et ils virent map/reduce d'ailleurs). Mais ca ne reste qu'un ensemble de choix parmis tant d'autres.
[^] # Re: 60 FPS
Posté par ckyl . En réponse au journal performances 3D sous GNU/Linux. Évalué à 7.
Merci j'ai bien ri.
[^] # Re: PROMPT_COMMAND
Posté par ckyl . En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 2.
Y'a un pull request en attente. Si tu as une idée de comment détecter les commits qui n'ont pas été pushés sans rajouter de coût à l'exécution n'hésite pas.
Le support de bzr se sent quand même dans les perfs. On peut améliorer le truc car le design actuel de _lp_set_prompt force à lancer deux fois bazaar alors qu'une suffirait. Je suis pas sur d'avoir le temps de m'y pencher si tu as du temps à perdre ;)
[^] # Re: PROMPT_COMMAND
Posté par ckyl . En réponse à la dépêche LiquidPrompt version 1.2. Évalué à 2.
Affirmatif. J'ai fait un proto rapidement, le support modifié/non modifié est trivial. Avoir le même niveau de support que git demande un peu plus de travail par contre (notamment les commits locaux à pusher et le numstat). Il serait peut être bon d'avoir une nouvelle couleur pour les merges non commités aussi.
Après les perfs de Bazaar étant toujours aussi désastreuses ca plombe pas mal l'interactivité du shell. Faut voir si c'est viable car un simple bzr nick et bzr diff rendre le shell inutilisable…
Je pousserais ce que j'ai fait ce soir ou lundi.