ploum a écrit 5847 commentaires

  • [^] # Re: Modifie les!!!

    Posté par  (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 2.

    nooon... arrête :-(

    Bon, va falloir que je me lance dans la bataille alors.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.

    Effectivement. C'est un cas assez limite mais tout à fait valable auquel je n'avais pas pensé.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 3.

    hihi, c'est vrai que c'est pas mal. Et autour de moi, le principal argument en faveur de Java est "Tout le monde utilise Java". Qui est un argument tout à fait recevable, il est vrai, mais un peu dommage quand même...

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.

    le débat sur les multicores me fait rigoler vu que la majorité des programmes C, C++ ou Java n'exploitent pas non plus le multicore.

    Perso, je vois le multicore comme une opportunité de faire tourner des processus différents, pas de gagner en perf sur mon programme monoprocessus. D'ailleurs, si les perfs sont si importantes pour ton programme, tu ne l'écris pas en Java ou en Python.

    Je trouve donc que la discussion n'a pas beaucoup de sens et qu'avant d'optimiser un programme pour qu'il utilise le multi-core, il faut d'abord avoir le programme complètement fonctionnel et optimisé au poil sous tous les autres aspects.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.

    c'est pas parce que ça s'adresse à des développeurs que tu dois faire tout en dépit du bon sens. Genre le menu en clic droit qui est "presque" le même que le menu dans la barre d'outils. Manque de bol, y'a une ou deux fonctions qui sont pas les mêmes.

    Eclipse n'a tout simplement pas d'interface : c'est juste plein de fonctions (très puissantes et utiles, je l'admet) auxquelles on a assigné des bouttons et puis on a lancé ces bouttons au hasard dans une grosse fenêtre. Lotus Notes est comme ça, Open Office est dans le même genre. C'est la philosophie de GUI des années 90 quoi.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 3.

    Je trouve qu'Eclipse est un monstre en termes de ressources, qu'il est complètement anti-ergonomique (et encore) mais, fonctionnellement, je reconnais que ce genre de fonctionnalité est très utile quand on développe.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Modifie les!!!

    Posté par  (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 4.

    Ton "c'est très clair" ressemble beaucoup plus à une explication a fortiori qu'à une logique de départ.

    D'ailleurs je te suggère d'essayer de l'expliquer à une personne qui n'a jamais touché un ordinateur, tu verras comme c'est non intuitif. (la taskbar ne l'est pas plus d'ailleurs)

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Modifie les!!!

    Posté par  (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 2.

    "juste apparaitre temporairement en notification lorsqu'il y a un message"

    C'est comme ça que j'utilise pidgin perso. Et pour ceux qui veulent connaître leur status en permanence, il y a le fast-user-switcher applet qui le fait. (par défaut sous Ubuntu 8.10)

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Modifie les!!!

    Posté par  (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 6.

    ça se défend mais l'important c'est de garder un comportement constant entre les applis. Or ici il n'y aucun moyen de prédire si une application donnée va quitter ou juste être cachée quand on clique sur la croix, c'est ça que je reproche.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: amsn

    Posté par  (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 10.

    C'est pas bien d'utiliser le compte linuxfr de ton papa pour troller. Tu sais, troller c'est comme fumer et rouler à fond : faut être un grand pour pouvoir le faire.

    Alors tu retournes à Gcompris et qu'on ne t'y prenne plus.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Modifie les!!!

    Posté par  (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 3.

    C'est le cas dans Rhythmbox et je considère ça comme un bug (et je ne suis pas le seul) :
    http://bugzilla.gnome.org/show_bug.cgi?id=317982

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Modifie les!!!

    Posté par  (site web personnel, Mastodon) . En réponse au journal Les clients de messagerie instantanée son tous pourris. Évalué à 5.

    Euh, la zone de notification de Pidgin est facultative et, justement, la HIG considère que "c'est mal" de mettre une icône de manière permanente dans la zone de notification.

    Lire à ce sujet la discussion à propos d'empathy :
    http://bugzilla.gnome.org/show_bug.cgi?id=467829

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.

    Celui qui met le plus de temps, c'est celui qui a deux commandes à taper. Ce n'est que ce que je dis depuis le début. Bien sûr que Python compile de la même manière qu'une voiture automatique change de vitesse : je m'en fous, il fait juste ce que je veux.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: C'est trop drôle

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.

    ça a été fait d'un jet à une heure du mat, complètement crevé et sans relire et de manière non-linéaire (j'ai écrit les mois puis j'ai rajouté des trucs par-ci par-là au feeling). Cela explique (sans excuser) les fautes et les incohérences... désolé.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.

    oui mais, par définition, tout code que tu écris te parle sur le moment. Mais pas 2 mois plus tard.

    Personnellement, je suis en train de tester une nouvelle approche : plutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.

    "Bof. Quand on est habitué, un code java est tout à fait lisible."

    Un truc qui me fait peur avec les "experts J2EE", c'est qu'ils m'ont tous toujours tenu le même discours concernant la lisibilité du code :

    - Les commentaires sont inutiles, un bon code parle de lui-même.
    - Il faut écrire le moins de lignes possibles : pas d'espaces entre les classes, pas de commentaires "inutiles"
    - Les commentaires nuisent à la lisibilité du code (sic).


    Bon, ce n'est évidemment pas lié au langage mais je trouve significatif que tous les chefs de projets J2EE (et certains C++) m'aie sorti, à peu de choses près, ce genre de choses. Et généralement ces règles sont même écrites sur la page Coding Rules du wiki !

    J'ai pour habitude, lorsque j'ai pris du temps à comprendre un bout de code, de mettre un commentaire expliquant ce que j'ai compris (histoire de pas devoir refaire le boulot). Durant ma brêve carrière J2EE, ces commentaires étaient systématiquement effacés par les commit après moi.


    Mais je reconnais 100% que ce n'est pas techniquement lié au langage. Je pense que cela fait plus partie d'une culturee très présente dans le milieu J2EE.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.

    Je sais pas pourquoi vous vous tuez à vous acharner pour m'expliquer le fonctionnement d'un compilo. Je sais bien que ça fait plein de trucs et que ça trouve des erreurs. Mais ces erreurs là, je les trouve aussi en Python en lançant mon code. Et tout ce que fait le compilo "en plus", ça ne justifie pas le fait de compiler (dont la définition est de produire un exécutable, je le rappelle. On ne compile pas pour vérifier son code, c'est une conséquence, pas un but).

    Depuis le début, j'explique que je critique la nécessité de "compiler" à chaque fois dans un environnement de dev. Je ne critique pas le fait de checker le code et d'optimiser car c'est très utile mais, en cours de dev, ça devrait juste être facultatif.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 3.

    Vu le nombre d'offres d'emploi que je vois pour des dev django dans les sites spécialisés, je me dit que ça commence à devenir sérieux. Je connais même des spécialistes J2EE qui se sont retrouvé à apprendre Django pour des missions de quelques mois. Le marché évolue, c'est comme tout le reste.

    Personnellement, j'ai un gros problème avec Java (alors que c'est avec Java que j'ai commencé l'informatique, que j'ai failli abandonné le domaine jusqu'au jour où j'ai découvert le C). Et j'aime troller. Du coup, on comprend mieux mes messages ;-)

    Mais plus sérieusement : J2EE est bien (waw, ça me fait mal de le dire). C'est la solution actuelle. Mais J2EE est devenu trop complexe, trop gros. Le futur est à des outils plus légers dont, je pense, font partie Django et Python. Et eux-même seront remplacés par autre chose dans quelques années, c'est l'évolution qui veux ça. Et selon que l'on soit conservateur, que l'on soit confronté à des problèmes présents, urgents et concrets ou que l'on soit idéaliste, rêveur et un peu visionnaire, on soutiendra Cobol, J2EE ou Python. Et dans quelques années, on rechangera...

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 4.

    Je renonce à argumenter plus car je ne ferais que me répéter. Je comprend ton argument comme "Un compilateur comporte un vérificateur de code dont on doit utiliser un compilateur plutôt qu'un vérificateur de code dédié" et cela ressemble à un sophisme.

    Mais juste une note pour Ant : j'aurais du préciser que j'écris ce script qui compile/lance sauf en python où c'est automatique. Le fait que Ant existe est la preuve que c'est une faiblesse du java mais Ant est justement un outil de plus à apprendre.

    Ce que j'essaye d'expliquer c'est que, plus tu rajoutes des outils, plus tu complexifies et plus tu vas rajouter des outils pour simplifier. C'est une voie de garage par excellence et c'est complètement anti-productif. ("j'ai passé seulement 2heures et j'ai un super script Ant." Super. C'est 2h que tu n'as pas passé sur ton produit).


    Je vais faire plus simple : j'ai deux machines qui font un travail. La première comporte un gros boutton rouge. La seconde comporte 5 bouttons : rouge, vert, mauve, jaune, bleu. Le manuel de la première explique qu'il faut appuyer sur le boutton pour la mettre en marche ou pour l'arrêter si elle est en marche. Le manuel de la seconde explique que le boutton mauve est un préchauffage, le boutton bleu l'initialisation, le boutton vert le lancement, le boutton rouge la confirmation du lancement et le boutton jaune l'arrêt de la machine.

    Et toi, tu es en train de défendre que c'est logique d'appuyer sur le boutton bleu parce que, forcément, il faut bien initialiser la machine et que c'est une machine super facile à utiliser vu que quand tu veux la lancer il suffit de faire mauve, bleu, vert, rouge et encore, le mauve n'est pas toujours nécessaire, t'es pas obligé d'appuyer dessus si l'indicateur de température dépasse une certaine valeur.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.

    "Contrôle qualité le plus en amont possible."

    Dans ce cas, il faut utiliser un vérificateur de code où quoi que ce soit d'autres. Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.

    Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.

    De plus, quand tu développes, tu peux vouloir tester une fonction tout en sachant que le reste n'est pas encore développé. Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.

    L'utilisation du compilateur comme un indicateur de la qualité du code est l'un des trucs les plus effrayant qu'on puisse sortir pour justifier la compilation. Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.


    "La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule "

    Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps". Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois ("sinon y'a des erreurs du à des trucs pas recompilé mais qui devraient l'être (sic)"). Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).

    Et quand bien même le temps serait vraiment ridicule, ce n'est pas une justification : tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...


    Lors du développement d'un soft, personnellement je finis toujours par écrire un script qui compile, fais tout ce qu'il faut et qui lance le soft. Je modifie le code, lance mon script pour tester, modifie le code, lance le script, ...

    Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 1.

    Ta comparaison est complètement foireuse. Le programmeur, il ne connait que le langage de programmation. Il n'a pas besoin de savoir comment c'est implémenté. Tu peux être un excellent programmeur et ne pas savoir ce qu'est un transistor.

    Par contre il doit connaitre, en plus du langage de programmation des tas d'outils pour faire fonctionner son langage de programmation et encore d'autres outils pour faire fonctionner les outils.

    Se compliquer la vie pour tenter de la simplifier, c'est voué à l'échec sur le long terme, faut pas chercher très loin pour s'en rendre compte. Lorsqu'un programmeur passe 2 semaines pour réussir à compiler un projet sans toucher une ligne du projet lui-même (juste les makefile et les configure), n'importe qui avec un peu de recul dirait "mais c'est quoi ce délire ?". Mais bon, le nez dans le guidon est le lot de90% des gens. Y'a peu de gens qui se posent la question "mais au fond, c'est quoi le résultat qu'on aimerait avoir ?". Le problème de la vie c'est que poser cette question, c'est remettre en question le travail, les acquis, la souffrance endurée les années précédentes. Alors, on préfère se convaincre que la question ne doit pas être posée.

    Autolink : http://ploum.frimouvy.org/?197-le-conte-du-mousse-et-des-vin(...)

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: réponse d'un "proche de l'organisation"

    Posté par  (site web personnel, Mastodon) . En réponse au journal Concours de logo RMLL 2009 : flop. Évalué à 10.

    "nous sommes actuellement face à quelques problèmes disons...technique et logistique nous empêchant d'annoncer le gagnant."

    C'est une manière bien diplomatique de dire que vous avez reçu 2 propositions et que les deux sont des bouses infâmes non ? ;-) (auteur du journal, le prend pas mal hein, blague, toussa)

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à -2.

    Me semblait que Java était également interprété ... (aha, la blague).

    Mais sinon, pourquoi vous voulez absolument compiler ? Quel est l'intérêt ? Ok, cela peut être intéressant pour des raisons de performances mais dans ce cas là on n'utilise pas Java.

    Compiler, c'est un concept dépassé quand on fait du développement, cela ne devrait plus exister que pour l'optimisation d'un produit "fini".

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Grandiose

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 2.

    "Ça c'est facile quand même. Si les modules sont pas dispos en package pour la distrib de ton utilisateur? "

    C'est un bug de la distrib et ça se corrige. Mais c'est rarement le cas (et même très rarement) et, au moins, ce n'est pas le cas par défaut. Dans la toute grande majorité des cas, c'est ultra facile.

    Et tu sais quoi ? Ta solution de VM est à présent utilisée par de nombreux logiciels qui se contentent de fournir une image Vmware d'un système configuré. (et à part ça, je vois pas le rapport avec ma solution à moi)

    Mes livres CC By-SA : https://ploum.net/livres.html

  • [^] # Re: Rire jaune

    Posté par  (site web personnel, Mastodon) . En réponse au journal Linuxfr en J2EE. Évalué à 7.

    Sur linuxfr je sais pas, mais dans mes journaux de ces 3 dernières années, j'en suis certain.

    Mes livres CC By-SA : https://ploum.net/livres.html