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
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.
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.
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.
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…
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.
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.
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.
On a pareil ici ; un truc installé au niveau du bios et avec un pilote Windows qui empêche d'utiliser une clé USB en mass storage. Super pénible, mais moins depuis qu'ils ont rajouté github et stackoverflow à la liste blanche.
Je travaille moi aussi pour une institution financière mais d'une autre couleur.
Je pensais à "mois", mais je suis certain qu'il est déjà arrivé que ce soit "jours". De toute manière, c'est dès que la pression monte et qu'on commence à bosser dans l'urgence.
Je pense qu'on est effectivement pas dans le même monde, et ce n'est pas du tout péjoratif : en fait je t'envie.
modifier la responsabilité en montrant que le problème/bug qu'ils ont en prod est corrigé depuis N temps de notre coté et que la balle n'est plus dans notre camps, qu'il n'est pas besoin de nous en reparler tant qu'ils n'ont pas fait de mise à niveau. Sur le long terme mettre en évidence les temps de cycle, ça a était payant.
J'ai d'un côté mon "client" (le métier sponsor de l'application et demandeur d'évolutions) qui voudrait que tout aille très vite, donne son accord à tout pourvu que la réactivité soti là, et de l'autre ma production informatique (typiquement une filiale du groupe dédiée à l'exploitation informatique) qui est accrochée à ses procédures, son respect idéologique à ITIL et surtout à son implémentation locale.
Quand j'ai un bug fonctionnel, que je peux corriger rapidement parce qu'il est dans une procédure stockée, je peux faire la modification et ne livrer que cette procédure stockée. Une fois que le fix est testé, je peux faire une demande de livraison pour ce morceau uniquement, pour lequel on va me donner un accès (temporaire) à la base de production. Je livre vite, mon client est content. Ma production informatique, elle, s'en fout : le périmètre du changement est maîtrisé donc le risque est faible.
Si il est dans la couche Java/JSP/Javascript/… je dois relivrer un EAR complet. Là, c'est l'artillerie lourde, je fais une demande, elle sera prise en compte sous une semaine. Je n'ai pas et je n'aurais jamais accès à la machine hébergeant mon serveur d'app, donc je suis totalement dépendant de ma production pour ça. En fonction de la modification, si en plus il y a un changement de structure de base, je suis obligé d'arrêter l'application, et donc le service, en pleine journée ou attendre le week-end (oui, nos applications tournent 24/5). Par défaut, on ne peut pas arrêter nos applications plus de 15 minutes en journée, sinon les pertes financières peuvent être abyssales.
Je peux montrer tous les tests de la terre, un zoli écran Sonar montrant ma couverture de test unitaire (j'essaye d'être au moins à 50%), mes tests automatiques (un automate simulateur de flux d'entrée/sortie), mon respect des règles de codage, etc. Ca ne change rien ; ma production s'en fout, s'en est toujours foutue et continuera ainsi bien après ma retraite.
Le seul cas où je peux accélérer les choses, c'est en cas d'incident majeur, mais auquel cas je dois justifier de la gravité et de l'impact, faire une escalade hiérarchique pour obtenir 2 ou 3 tampons. Autant dire que si je fais ça trop souvent, je peux mettre tout de suite un terme à ma carrière et partir élever des chèvres dans le Larzac. Donc c'est réservé à la résolution d'incident avec impact, pas juste pour faire plaisir à mon client. Et c'est pensé pour être comme ça, ce n'est pas un effet collatéral.
[^] # Re: Bugs
Posté par Dring . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 8.
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.
[^] # Re: je ne suis pas sûr d'avoir saisi l'intérêt de l'outil
Posté par Dring . En réponse à la dépêche tsrc — un gestionnaire de dépôts git. Évalué à 5.
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 ?
[^] # Re: je ne suis pas sûr d'avoir saisi l'intérêt de l'outil
Posté par Dring . En réponse à la dépêche tsrc — un gestionnaire de dépôts git. Évalué à 2.
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.
[^] # Re: je ne suis pas sûr d'avoir saisi l'intérêt de l'outil
Posté par Dring . En réponse à la dépêche tsrc — un gestionnaire de dépôts git. Évalué à 2.
C'est quoi exactement qui vous empêchait de tout mettre dans le même repo ?
[^] # Re: Rust
Posté par Dring . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.
Ah, cool. Dans le précédent journal, j'étais déçu par Rust, mais là c'est de la balle.
# Un peu déçu par Rust
Posté par Dring . En réponse au journal Un print(1 + "3a"), ça nous inspire comment ?. Évalué à 5.
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.
# Yum toujours ?
Posté par Dring . En réponse à la dépêche Red Hat Enterprise Linux 7.3. Évalué à 6.
Je lis ça :
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.
[^] # Re: Qu'elle n'envoie pas mes données de déplacement partout
Posté par Dring . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 1.
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") :-).
[^] # Re: Décevant
Posté par Dring . En réponse au journal LibreOffice fait évoluer son interface. Évalué à 3.
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.
# Java c'est plus fort que toi
Posté par Dring . En réponse au journal Cohérence des fonctions d'arrondi. Évalué à 5.
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.
[^] # Re: Merci
Posté par Dring . En réponse au journal Cohérence des fonctions d'arrondi. Évalué à 3.
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…
[^] # Re: Moui
Posté par Dring . En réponse au journal systemd: attention à RemoveIPC. Évalué à 3.
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…
[^] # Re: firefox
Posté par Dring . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 10.
J'utilise Linux depuis 1923 et j'en ai donc une plus grosse que la vôtre.
[^] # Re: Le téléphone est vraiment IP67 ?
Posté par Dring . En réponse au journal Tout simplement E P I Q U E. Évalué à 4.
Par contre ça peut prendre feu comme une Tesla S.
[^] # Re: Pb financiers en France
Posté par Dring . En réponse à la dépêche Au fait RuggedPOD et OpenTower c'est quoi ?. Évalué à 4. Dernière modification le 28 juin 2016 à 07:24.
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 ?
[^] # Re: Structure
Posté par Dring . En réponse à la dépêche Au fait RuggedPOD et OpenTower c'est quoi ?. Évalué à 2.
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.
[^] # Re: mimétisme
Posté par Dring . En réponse au journal Ethereum, The DAO et un petit malin sont sur un bateau.... Évalué à 5.
On est d'accord pour dire que c'est une différence mais pas un avantage ?
[^] # Re: Juste milieu ?
Posté par Dring . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 10.
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.
[^] # Re: javascript ?
Posté par Dring . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à 4.
Damn, je savais même pas qu'on pouvait être à -6 avant le moindre vote.
# A propos du W3C
Posté par Dring . En réponse au journal Il faut sauver le soldat Firefox!. Évalué à 6.
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.
[^] # Re: Exclusif le code source du stationnement intelligent à Nice
Posté par Dring . En réponse au journal Les chroniques du progrès : à bégayer ou à dégager ?. Évalué à 10.
D'ailleurs, il passe très bien les tests unitaires…
[^] # Re: La sécurité ? Une contrainte pour la productivité
Posté par Dring . En réponse au journal Avant c'est trop cher, après c'est trop tard. Évalué à 2.
On a pareil ici ; un truc installé au niveau du bios et avec un pilote Windows qui empêche d'utiliser une clé USB en mass storage. Super pénible, mais moins depuis qu'ils ont rajouté github et stackoverflow à la liste blanche.
Je travaille moi aussi pour une institution financière mais d'une autre couleur.
[^] # Re: Traditions du HS
Posté par Dring . En réponse au journal LinuxFr.org n'aime pas discuter du hors sujet [titre réécrit]. Évalué à 6.
Bonjour,
Je suis nouveau sur le site, et je vois souvent l'emploi du verbe "bronsoniser". C'est quoi donc que ça veut dire ?
D'avance merci,
Un gars qu'il est nouveau sur le site et qui aime l'humour de répétition. De répétition.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Je pensais à "mois", mais je suis certain qu'il est déjà arrivé que ce soit "jours". De toute manière, c'est dès que la pression monte et qu'on commence à bosser dans l'urgence.
[^] # Re: Facile!
Posté par Dring . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Je pense qu'on est effectivement pas dans le même monde, et ce n'est pas du tout péjoratif : en fait je t'envie.
J'ai d'un côté mon "client" (le métier sponsor de l'application et demandeur d'évolutions) qui voudrait que tout aille très vite, donne son accord à tout pourvu que la réactivité soti là, et de l'autre ma production informatique (typiquement une filiale du groupe dédiée à l'exploitation informatique) qui est accrochée à ses procédures, son respect idéologique à ITIL et surtout à son implémentation locale.
Quand j'ai un bug fonctionnel, que je peux corriger rapidement parce qu'il est dans une procédure stockée, je peux faire la modification et ne livrer que cette procédure stockée. Une fois que le fix est testé, je peux faire une demande de livraison pour ce morceau uniquement, pour lequel on va me donner un accès (temporaire) à la base de production. Je livre vite, mon client est content. Ma production informatique, elle, s'en fout : le périmètre du changement est maîtrisé donc le risque est faible.
Si il est dans la couche Java/JSP/Javascript/… je dois relivrer un EAR complet. Là, c'est l'artillerie lourde, je fais une demande, elle sera prise en compte sous une semaine. Je n'ai pas et je n'aurais jamais accès à la machine hébergeant mon serveur d'app, donc je suis totalement dépendant de ma production pour ça. En fonction de la modification, si en plus il y a un changement de structure de base, je suis obligé d'arrêter l'application, et donc le service, en pleine journée ou attendre le week-end (oui, nos applications tournent 24/5). Par défaut, on ne peut pas arrêter nos applications plus de 15 minutes en journée, sinon les pertes financières peuvent être abyssales.
Je peux montrer tous les tests de la terre, un zoli écran Sonar montrant ma couverture de test unitaire (j'essaye d'être au moins à 50%), mes tests automatiques (un automate simulateur de flux d'entrée/sortie), mon respect des règles de codage, etc. Ca ne change rien ; ma production s'en fout, s'en est toujours foutue et continuera ainsi bien après ma retraite.
Le seul cas où je peux accélérer les choses, c'est en cas d'incident majeur, mais auquel cas je dois justifier de la gravité et de l'impact, faire une escalade hiérarchique pour obtenir 2 ou 3 tampons. Autant dire que si je fais ça trop souvent, je peux mettre tout de suite un terme à ma carrière et partir élever des chèvres dans le Larzac. Donc c'est réservé à la résolution d'incident avec impact, pas juste pour faire plaisir à mon client. Et c'est pensé pour être comme ça, ce n'est pas un effet collatéral.