ckyl a écrit 3877 commentaires

mais j'ai du mal à me remettre au code, et je fais un blocage devant la todolist et ses dizaines de bugs.

Laisse tomber ta todolist. Corrige les bugs qui doivent être corrigé, et fait en sorte que ta base de code soit bien testée. Au démarrage avoir une test suite solide est bien plus importante que d'avoir pleins de fonctionnalités. Tu en as besoin pour faire les fonctionnalités et avancer vite plus tard.

Sans compter toutes ces fonctionnalités manquantes que je voulais vraiment inclure dès la première version, et qui manifestement, ne seront pas là.

On s'en fou !

Détermine ton ensemble de fonctionnalités minimal (on a bien dit minimal), fait en sorte qu'il soit correctement testé et release. Après c'est de l'incrément. Quand t'as du temps du t'implémente une nouvelle fonctionnalité bien définie qui est correctement testées / documenté. Et tu boucles.

Tu n'auras jamais tout ce que tu veux, et tu risques de troquer la qualité contre les fonctionnalités ce qui n'est jamais un bon choix.

Du coup, j'hésite. J'ai peur d'être ridicule en releasant en l'état une version imparfaite.

Honnêtement tout le monde s'en balance que tu releases un truc imparfait ou minable. Au pire tu auras fait perdre 10 minutes à quelques personnes et tout le monde aura oublié dans un mois…

ou que ça existe déjà en mieux ailleurs

Alors ça en théorie si tu as passé du temps sur quelque chose c'est qu'il est utile. Si tu as raté quelque chose et qu'on te fait découvrir un projet qui répond aux même besoin fonctionnels en mieux et stable alors il suffit de jeter ton code et de te trouver un nouveau passe temps. Ça arrive à tout le monde. (Cette remarque ne s'applique pas si tu écris un CMS, un Window Manager, ou un éditeur il est de bon ton d'écrire la 500 ième variantes de ces choses).

Peur que le logiciel n'intéresse personne, qu'on me dise que ça ne sert à rien

Et alors ?

Si fonctionnellement ton truc est utile alors tu auras des retours pour fixer tout les trucs pourris que tu as fait (et tout le monde en fait beaucoup) ou au moins de retour utilisateur qui te motiveront et t'aideront à te concentrer sur quelque chose.

Vous faites quoi dans ce genre de cas ?

Réfrène tes envies de changer le monde, défini clairement ce dont tu as besoin à minima. Release. Et continu. Tu risques quoi ? Des trucs inutiles et pas fini y'en a des milliers qui sont releasés chaque jour. Occasionnellement ca sert à quelqu'un c'est cool et c'est encore plus cool de le savoir. Rarement ça sert à plein de gens. Mais où est le problème ?

Attention les exigences varient énormément en fonction des usages.

Pour un usage bureautique/code le seul problème peut être quand tu veux passer ton écran en mode portrait (attention au sens de rotation).

Si tu utilises en plus ton écran pour regarder des films ou autre le problème se pose car généralement tu regardes ton écran de beaucoup plus bas que ton poste de travail et l'image vire au noir. C'est le cas extrème.

Si par contre tu bosses sur des images la variation de rendu impliquée par les changements d'angle de vue verticaux existent clairement. C'est très visible sur les tons clairs. Après on peut aussi arriver à bosser en faisant abstraction de ce que nos yeux voient et se repérer aux codes couleurs.

Après, l'écran était très bien noté et précalibré en usine,

En général la première chose que tu fais c'est installer ton écran dans une lumière ambiante totalement différente de la référence et baisser la luminosité de l'écran (et sur le tient désactiver le truc qui boostent les contrastes AFAIK). Alors le précalibrage…

Pour les notes vu la valse des dalles sur les TN c'est une grosse blague. D'ailleurs d'après une recherche rapide ton modèle à eu deux dalles différentes selon sa provenance…

Tu as vraiment des problèmes de lecture ou de compréhension.

1. Non je ne dis pas que ce n'est pas top. Tab VS Space n'est pas le sujet et je argumenterais pas la dessus.
2. Non je ne dis pas que ta proposition règle le problème
3. Oui je dis que sauf excellente raison il vaut suivre une mauvaise recommandation (l'importance de ce genre de choix est fondamentale…) que de faire son "_moi j'ai raison_" car la consistance à plus de valeur que . Non ta satisfaction à pouvoir mettre des tabs à 2 ou 16 ne sont pas une excellente raison.

Le code sur lequel tu bosses il va finir par passer dans les mains de 100 mecs comme toi qui préfèrent tel ou tel choix. Il va se faire merger et aggréger dans tout les sens. Au final soit ta codebase c'est le bronx et l'enfer à gérer, soit tu finis reformater et tu vas pleurer sur les merges et les hotfixes pendant des années.

Il n'y a pas de recette miracle (les styles divergent toujours etc.) mais se conformer à des règles simples vaut mieux que le "MOI JE SAIS". Tout le monde sait… mais personne n'est d'accord. Alors quand dans un langage tu as une convention reconnue tu la respecte…

Je dois vraiment être aveugle mais je ne vois toujours pas les pdf sur cette page, ça doit juste être la 5ème fois que je regarde..

Un ophtalmo ou Ctrl + F est sont tes amis…

Tu n'as rien compris.

Je ne te dis pas que c'est mieux, je te dis que tu peux vivre avec ce petit inconvénient (bouhh j'ai 4 au lieu de 2 ou la parenthèse pas sur la bonne ligne) et que le coût des petites transgressions pour faire mieux est que c'est galère à long terme. Pour les gens qui bossent à 2 sur du code jetable ou qui n'est pas maintenu c'est certainement pas évident. Pour les autres c'est toujours relou.

Plus tout le monde fait pareil, plus c'est simple même si c'est pas toujours l'optimum.

Déjà qu'ils abandonnent Presto, en libérer le code n'aurait-il pas été un choix possible, ouvrant ainsi une 3º voie aux petits navigateurs et en dopant (éventuellement) le développement de Presto ?

Ca ne se fait pas en claquement de doigt, voir ca demande un effort énorme selon sa base de code, son historique, ses dépendances, son build et l'histoire de la société.

En considérant que tout se passe bien et qu'ils aient des ressources, sur un truc de cette taille tu peux supposer qu'il y aurait eu quelque chose d'utilisable en Open Source d'ici 1 à 3 ans. Si l'investissement n'est pas monstrueux tu peux imaginer qu'ils feront l'effort. Si ils sont un peu juste peu de chances que ca se produise.

On est d'accord. Il faut prendre ma phrase dans son contexte. Je répondais spécifiquement à:

Code MUST use 4 spaces for indenting, not tabs.

j'avoue que celle là je ne la respecterais jamais, je ferai tout l'inverse !

Hum, lorsque tu as du code à relire, tu apprécies une certaine homogénéité qui te permet de savoir a-priori comment les choses sont organisées et présentées. Ça te fais gagner pas mal de temps et ça te permet de te concentrer sur les choses plus essentielles.

Et justement sauf à travailler toute ta vie sur une ile déserte sur un projet qui n'intéresse personne tu passes ton temps à:
- Travailler sur différents projets fait par différentes personnes
- Fusionner, intégrer, mélanger différents projets fait par différentes personnes
- Reprendre du travail fait par différentes personnes

Tes arguments expliquent justement pourquoi il faut avoir une excellente raison pour différer coding standard usuels de ton langage même si ils sont pas parfait. Ta beauté d'avoir des tabs à la place de 4 espaces on peut la comprendre. Mais elle va casser les couilles pour toujours à tout le monde qui va devoir à lire, modifier ou intégrer ton code. Est ce que ca en vaut la peine ? Définitivement non.

j'avoue que celle là je ne la respecterais jamais, je ferai tout l'inverse !

Vu que n'importe quel éditeur décent peux faire ça de façon totalement transparente quel intérêt de vouloir faire à sa façon (quelle soit objectivement ou subjectivement meilleure) ? Ça fait juste chier tout le monde de devoir en permanence adapter ses réglages à chaque projet.

Y'a un moment le tripotage de nouille des développeurs sur la "beauté" ne vaut pas ce que ça implique à long terme.

Et puis bon tu fais du PHP quoi, si y'a vraiment quelque chose qui te choque dans ce que tu énonces tu aurais du fuir depuis très très longtemps…

A ce titre la liste des fonctions m'interpelle et me plaît bien, en plus elle répond à des besoins très courants pour mes clients.

Tu veux livrer un truc faire par un mec dans son coin avec 0 utilisateurs à tes clients ? Miam…

Admettons et donc le problème de sécurité est bien le programmeur lui-même et pas le langage qu'il utilise. On ne pas désigner directement l'outil comme mauvais du fait qu'on l'ai donné à un ouvrier qui ne le maîtrisait pas.

Si on suit cette logique on peut faire tout la merde que l'on veut. Aucun problème l'utilisateur n'a qu'à le maîtriser… Après tout MOI je maîtrise.

Tu sais au ouvriers aussi on essaie de leur donner des outils qui font leur job et qui évite de leur faire perdre des membres…

Un outil c'est fait pour t'aider, te faire gagner du temps de cerveau et t'empêcher de faire des conneries en étant normé, intuitif et en ayant déjà résolu les problèmes pour toi. Pas pour en inventer de nouveaux ni auto-justifier l'expertise simplement pour pas tomber dans les pièges tendus devant toi…

-dalle IPS/PLS : technologie à temps de réaction plus lent (6/20 ms), mais avec un rendu des couleurs bien plus fidèles. Principalement utilisés par ceux qui en ont besoin (photographes par exemples).

Et surtout à un angle de vision horizontal et vertical bien plus large que du TN. Si t'es pas pile en face de ton TN les couleurs c'est n'importe quoi et il est impossible de bosser avec. Il faut toujours être exactement pile en face et ne jamais changer sa tête de place. En vertical ca se joue seulement à quelques degrés. Il suffit d'oscillier entre la position affaler et droit pour avoir deux images totalement différentes.

Effectivement je ne suis capable de rien sauf de prévoir des interfaces qui supportent l'édition concurrente de configurations orthogonales qui n'ont aucune raison d'avoir un impact l'un sur l'autre.

Après effectivement on s'en sort très bien avec du scotch et de la ficelle où simplement en misant sur le fait que ça n'arrive jamais. Après tout ca n'arrive jamais hein. D'ailleurs on devrait appliquer ce principe à tout, la concurrence et la cohérence c'est vachement surfait en fait.

crontab >/tmp/fichier_cron
Tu fais tes modifs …
crontab /tmp/fichier_cron pour prise en compte. Et le tour est joué.

Oh la belle race condition…

Si je veux le même nombre de cm, je vais voir apparaître les pixels de la photo.

Non le dpi de ton image reste le même… Ton écran peut faire mieux (à un pixel image correspondent plusieurs pixel écran) mais la qualité de l'objet que tu possèdes reste exactement la même. Tu n'as aucune raison de voir apparaître des pixels.

Avec la version papier la taille de l'objet est fixée. Avec la version numérique tu peux la garder fixe si tu veux (et la tu as un exact équivalent au papier), où jouer sur ses dimensions ce qui à évidemment une incidence sur sa définition. Ca peut donner le meilleur comme le pire mais de toute facon une version imprimée n'en est pas capable.

Par contre, on aura une qualité toute pourrite avec nos écrans ultra-méga-giga-HD-delamortkitue. Ou alors une bonne qualité, mais une taille toute petite sur nos écrans de 128 pouces.

D'un autre côté ta BD papier elle ne va pas grandir non plus par magie… C'est exactement la même chose.

Et comme on parlait d'Alan Cox il y a quelques temps:

"A Computer is a state machine. Threads are for people who can't program state machines"

-- Alan Cox

Merci pour le lien vers la retrospective.

Ca fait plaisir de voir que je suis pas complétement à côté de la plaque et que je retrouve beaucoup de mes critiques. Ce qu'on peut inferrer en tant qu'utilisateur se confirme.

Elle vaut vraiment le coup d'être lue. Il y a des choses à tirer d'un projet qui aurait pu être bien mais a complétement dérapé. Le mieux ou la pureté conceptuelle peuvent mener au très moyen pour les utilisateurs.

mais le truc ne sait rien faire de base

Ca marche aussi pour bzr

il faut avoir recours à des extensions

Ca marche aussi pour bzr. Au passage la moitier des extensions sont pourries ou mortes

pour éditer l'historique (git rebase -i)

Ca marche pas pour bzr. Y'a bien un plugin rewrite mais le -i faut pas rêver. Un DCVS où on peut bosser efficacement avec des branches locales n'y pensez pas mon bon monsieur

faire des commit partiels (git add -p)

Non plus.

Et il y a des concepts que je n'arrive pas à retrouver

Ca marche aussi. Par contre ils arrivent à inventer des concepts moisis. C'est "beau" mais inutilisable en pratique.

Un fanboy de Mercurial pourrait-il m'expliquer ce qu'il aime dans Mercurial et pourquoi ça roxxe du poney ?

Idem…

PS: Dis moi mercurial c'est aussi rapidelent et bien outillé que bzr ?

Pour les deux.

1- Il te maintient une liste synhronisée de tout les trucs que tu as à lire. Il peut les lires hors ligne sur plein de terminaux. Choix très personnel mais avoir ce truc en dehors du compte firefox ou google me plait bien car ca me permet d'utiliser le même compte au boulot et chez moi. Il contient juste de la veille.

2- Il garde en mémoire ce que tu as lu et permet de le tagger mais l'interface built-in est pas extra. Bon le plugin firefox dans le mode archive répond à 80% de mes petits besoins. Pour d'autres trucs il suffit de tout exporter avec l'API.

Il ne faut pas se focaliser sur getpocket en lui même et je ne veux surtout pas lui faire de pub. Je l'utilise car c'est ce que j'ai trouvé de mieux en cherchant 5 minutes. Je suis certain qu'il y a 100x mieux. Tu pourrais faire la même chose avec un delicious ou tu utiliserais un tag pour marquer les choses lu ou non lu. Ou utiliser googlebookmark. Etc. J'ai utilisé les 3, getpocket est le plus pratique pour mes besoins (100% subjectif).

L'idée c'est que c'est très pratique d'utiliser un outil dédié qui peut facilement être alimenter de n'importe ou, avec n'importe quoi. Il ne sert qu'à maintenir une pile de document non lu et une archive de ce qui a été lu.

Pour:

Là où il y a encore un gros manque dans mon workflow c'est pour stocker les trucs déjà lu mais que je veux garder.

Si tu te bases sur ton reader il faut encore que tu trouves une solution pour tout les trucs qui n'arrivent pas par ton lecteur de flux.

Ton lecteur RSS tu peux le voir comme un front-end parmis d'autres. L'activité de lecture et d'archivage c'est du back.

Avec un peu de hack tu peux utiliser la combinaison lecteur de flux + getpocket.

Basiquement ton lecteur de flux tu le parcours rapidement. Tu sautes tout ce qui t'intéresse pas. Tu ajoutes à getpocket tout ce que tu veux lire. Tu fais la même chose quand tu surfes le web, lis tes mails ou n'importe quoi.

Quand tu as du temps pour lire, tu vas voir ta liste getpocket. Tu lis le truc. Tu le marques comme lu. Tu le tag si t'as besoin. C'est forcément pratique pour parcourir ce que tu as déjà lu, mais en 10 minutes tu te fais un truc qui attaque l'API du service et voilà. Tu peux certainement abuser pleins d'autres services comme ça. Ce qui est intéressant c'est de décorreller ton lecteur de flux (ta source de donnée), de ta pile de document à lire.

C'est le plus connu qui a évolué, mais il y a aussi le framework de parallélisation (qui va encore évolué avec Java8).

C'est exactement ce que je dis. On bouche en s'en battant de rendre les trucs performants ou utilisables.

Le fork/join de la JSR166y est très bien. Une nouveauté. Cool ! (enfin c'est dispo comme lib externe depuis 5 ans)

En attendant tu peux toujours pas instancier un foutu Future sans utiliser l'AbstractFuture de Guava (FutureTask ne marche qu'avec un Runnable). L'API des Executor est tellement mal gaulé que 90% des gens qui essayent de créer un thread pool avec un nombre min et max de thread se plantent (la compatibilité Java 5/6/7 en exercice). Faire un thread group nommé demande encore de dupliquer 30 lignes de code ou d'utiliser une lib externe. On peut continuer comme ca longtemps sur ce tout petit module fonctionnel mais le constat est généralisé sur presque tout le JDK.

On rajoute des briques très bien. Mais les bases qui servent à construire ces briques sont en train de pourrir. Pour avec un semblant de DRY t'es obligé d'utilisé 1000 libs. Mais laisser ca a des third party c'est prendre le risque de retomber sur le délire du logging ou d'avoir une compatibilité beaucoup plus difficile à gérer que si le JDK cassait quelque chose ou se bougeait simplement le cul. Rare sont les projets reposant sur un OSGI ou assimilé et t'es bien malin quand ton runtime arrive déjà avec ses 30 libs dans une version donnée… Même en OSGI t'as intêret à être à grin très fin pour jamais tomber sur ce genre de problème.

Je suis d'accord pour dire que le JCP a du mal à sortir des choses mais c'est parce qu'il est difficile de sortir un consensus pas un manque de volonté (du moins je pense pas).

Non par ce que le bateau s'est enlisé depuis longtemps et que le remettre à flot est difficile. Si on pousse pas ca avance pas.

il y a une volonté de découper l'API pour la rendre plus modulaire (voir le JSR 337).

La JSR 337 c'est juste la JSR de Java8 qui listent les JSR qui seront incluses. Le DRAFT-1 n'indique pour le moment absolument rien à propos de Jigsaw. Toute les chances pour que ce soit encore repoussé à Java 9.

Note que Jigsaw au niveau du JDK ne rend absolument pas l'API plus modulaire. Ils veulent juste pouvoir charger les différents sous modules du JDK par bout fonctionnel (réduire le coût du download + boot). Ca demande un énorme boulot de nettoyage puisqu'il faut péter toutes les dépendances qui traînent. Mais d'un point de vue utilisateur ca n'a absolument aucun impact.

Ça ne ressort pas mais c'est un avis personnel.

Il me semble personnellement très foireux.

Je n'ai absolument jamais entendu ce genre d'idée. Autrement on inventerait pas des trucs comme tweaker la résolution de méthode virtuel pour ajouter les implémentation par défaut dans les interfaces pour le support des lambdas. On s'amuserait pas prévoir des gesticulations immondes pour réparer les conneries qui ont été fait avec l'autoboxing et son interaction avec les collections. Et on peut continuer.

En quoi elle est paralysée ?

Y'a deux pauvres sous systèmes qui évolue à chaque release tout les 2/3 ans. On rajoute les features qu'il manque mais absolument rien au niveau expressivité et productivité générale. On va quand même pas se tripoter sur les NIO2 qui ne font que combler une vaste blague !

mais ça n'a rien à voir avec la compatibilité.

Voilà tu as tout compris. On peut bouger pour devenir meilleur. Java l'a oublié pendant 7 ans. Il comble ses trous fonctionnels mais ne fait plus rien d'autre. Les API merdiques restes merdiques. Et on ne pousse rien d'un peu novateur pour chercher à rendre la plateforme meilleure, on laisse ca à groovy, scala ou clojure et aux libs externes et c'est bien dommage… Ca donne des débilités comme le système de logging, junit, devoir utiliser guava pour avoir des collections correctes, un pauvre multimap ou de bêtes outils pour bosser sur des les iterateurs.

Par contre le problème de garder toutes les APIs c'est que tu fais rapidement exploser la complexité et la taille du bouzin. Par exemple l'algorithme derrière le hashcode de String a été documenté du coup on peut plus le changer. Maintenant on en arrive à des patchs comme ca pour limiter le nombre de collision dans les collections. Et évidement comme toujours on balance une property système pour activer/désactiver la nouvelle fonctionnalité ce qui donne à terme une complexité folle pour les utilisateurs.

Si Java fait de gros effort pour la compatibilité j'ai l'impression que tu la surestimes beaucoup quand même. Avec une grosse base de code tu tombes souvent sur des changements dans les JDK (même en mineur):
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
http://www.oracle.com/technetwork/java/javase/compatibility-137541.html
http://www.oracle.com/technetwork/java/javase/compatibility-137462.html

Sachant que tu n'as pas tout là.

Ils se permettront de casser la compatibilité pour la version 2.x (pas prévue à ce que je sache).

Citation needed.

Ca fait très longtemps donc c'est très approximatif et peut être de anneries:
- Virer le plugin de cache. Oui oui !
- Virer le plugin qui affiche les derniers ajouts à la collection
- Jouer dans les préférences avec le vsync dans les menus
- Jouer avec la config des dirtyregion (activé par défaut dans la 12 d'après le changelog). Mais chez moi ca avait pas changé grand chose

J'avais trouvé ces pistes sur l'interweb sans trop galérer donc ca doit être retrouvable sans gros effort. Après savoir si c'est toujours d'actualité avec la 12 ou si c'est spécifique au hardware…