Dring a écrit 1211 commentaires

Quant aux IDEs… bah, ce sont des IDEs quoi, perso, ça me gave de devoir créer un fichier projet juste pour debugguer un binaire qui est de toute façon déjà (fraîchement) compilé.

Ben c'est sûr que si tu n'installes l'IDE que lorsque tu as un bug c'est un peu lourd, mais la plupart des êtres humains ne s'en servent pas que pour débogguer : c'est aussi utile pour le refactoring, par exemple.

Du coup tu fais tout dans l'IDE. On me signale même que ce serait le concept du truc.

Alors, pour ma part, tout ce qui tourne autour de UML : c'est de la merde. Les diagrammes peuvent être intéressants, mais dès lors qu'ils sont utilisés par un spécialiste ça tourne au cauchemar. La grammaire peut être assez sournoise et ce qui devait être un langage "universel" devient alors un nid à piège ("mais si regarde : le bout de la flèche est comme ça, donc c'est une relation qui se lit dans l'autre sens !"). Et au final, je préfère largement écrire une spécification en langage naturel…

Pareil pour la génération automatique de code avec cette horreur : ça ne tient jamais au delà de la génération initiale. Je n'ai jamais vu personne faire vivre un logiciel avec ça, et au final le code généré fait chier tout le monde.

Pour BPMN, je n'ai pas d'expérience directe, et j'attends vraiment de savoir comment ça se tiendra dans le temps. Mais le premier cas que j'ai pu voir, c'est jBPM+Drools, et ce que j'entends c'est : "tout est en drools, du coup c'est à la main du métier, et du coup c'est le gros merdier, personne ne comprends plus rien".

Bref, tous ces trucs me font très peur, et à part pour des petits trucs tout simples pour lesquels de toute manière n'importe qui peut sortir un truc en quelques jours, je n'ai rien vu qui ne parte pas en cacahuète.

Après c'est quand même beaucoup une question de goût, et surtout d'expérience.

Quand je lis ça :

[ -d $REP ] || mkdir $REP

Je me dis : OK, je vais créer un répertoire, mais c'est quoi le truc avant ? Ah oui, la syntaxe shell permet de "tester" en utilisant une syntaxe qui fait penser à un argument (le "-p"). Évident pour celui qui fait du shell depuis 15 ans, cryptique pour celui qui en fait peu ou prou.

En bon développeur java, le code code java correspondant (comme celui fourni par Sufllope plus bas) me semble infiniment plus clair, et donc plus maintenable.

Et puis, $REP c'est quoi ? Une simple chaîne, ou une liste de fichiers/répertoires ? Et comment se comporte mkdir si tu lui passes plusieurs répertoires ? Tout ça, un expert shell va le savoir sans avoir besoin d'aller consulter man ; là où un développeur java va préférer itérer sur une liste et tester pour chaque répertoire ce qui se passe, et comment se comporter en cas d'erreur.

Alors, comme dit également plus bas, java n'a pas été pensé pour l'écriture rapide de scripts. Mais en ce qui me concerne, l'écriture rapide de script est souvent une mauvaise solution à un problème. Mauvaise solution qui peut quand même être la meilleure par manque de temps, du coup je sais quand même faire du shell…

Quel est selon toi la contrainte à faire un langage de script avec un langage fortement typé ?

Beurk. Un wiki ou un bug tracker intégré ? Pourquoi ?

À la rigueur, faciliter l'usage de ces outils, rajouter des moyens pour simplifier l'interfaçage, voir s'associer pour distribuer des packs complets, mais surtout pas une application fourre-tout.

Bon, en me relisant je me rends compte que ma question peut sembler débile et mérite elle aussi un éclaircissement.

L'auteur indique qu'in fine il tague tout avec le même label, ce que je traduit en : on ne gère qu'une seule version globale de tout ces repos.

Je vois très bien l'intérêt de l'outil si on gère plusieurs softs certes distribués ensemble mais avec chacun son rythme de livraison. Si tout est livré par définition d'un bloc, alors un repo central semble plus adapté, et on fait les ajustements nécessaires sur la partie build

J'ai (encore) raté un truc ?

Ok, j'ai raté cette partie, mais je ne connais pas assez GO pour comprendre. Avec un répertoire par langage tout en haut de l'arborescence on a le même résultat non ?

Et pour le point sur la doc pareil je ne vois pas.

À ce stade tout ça ressemble à une solution bien compliquée au niveau SCM pour régler un problème qui se trouve en fait au niveau outil de build.

C'est quoi exactement qui vous empêchait de tout mettre dans le même repo ?

Ah, cool. Dans le précédent journal, j'étais déçu par Rust, mais là c'est de la balle.

Rust est un langage qui m'attire vraiment beaucoup, mais par manque de temps je ne m'y suis pas encore mis. Jusqu'ici je n'ai vu que des belles choses, et le seul reproche que je lui trouvais, c'était la difficulté à trouver un librairie mature pour faire une application graphique.

Mais là, je trouve que le message d'erreur est… comment dire… Cryptique. Verbeux. Inutile. Décevant.

Curieusement, ça m'a décidé à enfin l'installer et commencer à m'amuser avec.

Je lis ça :

Toujours dans le domaine des journaux, Yum et NetworkManager augmentent leur verbosité par défaut.

Et je me rend compte que RHEL est toujours sur Yum. Quand est-ce que le passage à dnf est prévu du coup ? Je soupçonne que la réponse soit RHEL 8, mais je n'ai rien trouvé sur ce sujet. Non pas que ça change grand chose pour l'utilisateur final, hein… Moi je ne fais aucune différence.

On voit bien que tu n'as pas de smartphone. Et je parie que ton T9 est désactivé sur ton vieux mobile. Ça explique pourquoi tu tapes encore en SMS ("tjr") :-).

Les écrans qui permettent ça, c'est souvent pas génial au final. La plupart des écrans ont un très bon angle de vision… tant qu'on reste en mode 16/9. Tu pivotes l'écran, et tu te rends compte que si ta tête est décalée de 20 centimètres sur la gauche ou la droit, tu vois plus rien !

Quand l'angle de vision sera parfait dans les 4 directions, on en reparlera.

A noter que la classe BigDecimal de Java supporte tous les types d'arrondis possibles, y compris le Round Half Uneven que je n'ai pas vu cité dans les commentaires.

Il y a une page Wikipédia dédiée au sujet pour ceux que ça passionne : https://en.m.wikipedia.org/wiki/Rounding.

Pour tout ce qui est impôt, la loi privilégie toujours le contribuable. Si ça peut t'aider dans ta compréhension du bouzin…

Le monsieur du dessus parle d'environnement de développement, local ou non, et tu lui réponds sur production et pré-production. Vous risquez pas de vous comprendre…

J'utilise Linux depuis 1923 et j'en ai donc une plus grosse que la vôtre.

Et ça fait pas crisser les pneus comme une Tesla S.

Par contre ça peut prendre feu comme une Tesla S.

Question sans doute idiote mais en quoi votre tour a une forme d'escalier, et pourquoi ça la rend plus modulaire ?

Et aussi : quid de la dissipation de la chaleur, au niveau du micro data enter je vois le boîtier alvéolaire qui doit servir à ça mais pour la tour dans son ensemble ?

Encore mieux en effet car il a l'air plus facile de remplacer des pièces avec cette solution. Alors qu'une pièce qui aurait 'regonflé' me semble indéplaçable, non ?

Pour des prototypes cela dit le métal c'est pratique.

On est d'accord pour dire que c'est une différence mais pas un avantage ?

Oublions 2 secondes le cas de l'auto-stop et revenons sur le covoiturage. Celui-ci existe depuis toujours : je passe te prendre cette semaine et la semaine prochaine ce sera ton tour ; ou si tu n'as pas de voiture c'est toi qui paye l'essence, ou le péage, ou…

Comme dit précédemment il ne s'agit pas là de revenu mais de partage de dépense ; l'état n'a rien à redire et - pour autant que je le sache - n'a aucune velléité.

Par contre dès qu'il s'agit d'une activité destinée à générer du revenu oui l'état s´y intéresse, et oui c'est légitime, notamment pour équilibrer le rapport avec les autres activités commerciales sur le même secteur.

Et je plussoie aussi le montant minimal de revenu avant taxation, mais la déclaration dès le premier euro. Le problème étant que la gruge est tentante et facile, il y a quand même une injustice qui s'installe mais je ne vois aucune solution simple à ce problème, qui est celui de l'honnêteté en général.

Damn, je savais même pas qu'on pouvait être à -6 avant le moindre vote.

Peux-tu nous éclairer sur ce qui te chagrine dans la proposition de médias encryptés du W3C ? J'ai plutôt l'impression que c'est une option en plus qui répond à un vrai besoin (donc si ce n'est pas mis dans la norme ça pourrait conduire à une autre horreur bien pire - genre le retour en grâce de technos à la Flash) et qui se pose les bonnes questions (c.f. les références à la vie privée).

Sinon, je vois que tu es sensible au slogan de la MoFo, mais ils ont quand même un impératif de rentabilité et pourraient basculer du côté obscur assez facilement ; pour moi le point clé est de pousser vers de nouveaux navigateurs alternatifs.

Hélas avec le temps créer un tel navigateur qui réponde aux besoins de la majorité des utilisateurs devient de plus inaccessible sans une grosse puissance financière.

Est-ce qu'un Konqueror pourrait voir le jour aujourd'hui pour servir de base à une nouvelle génération de navigateurs comme ce fut le cas avec Webkit ? Alors qu'aujourd'hui une grande partie de la bataille se joue sur l'efficacité du moteur Javascript. Et qu'arriver au niveau de l'existant implique plusieurs années de travail.

Il est possible qu'on soit condamné à ne voir apparaître que de nouvelles UIs se basant sur des moteurs existant et n'apportant pas de grosse contribution à l'amélioration du web, que ce soit d'un point de vue technique ou sur le respect des utilisateurs. Et que seuls Mozilla, Google, Microsoft et Google soient en mesure de proposer et suivre les futures évolutions.

D'ailleurs, il passe très bien les tests unitaires…

void test_calculer_nb_places_disponibles() {
    assertEquals(0, calculer_nb_places_disponibles();
}