Dring a écrit 1149 commentaires

Ouaich ! Y a ceux qui sachent, et y a ceux qui croivent sachoir !

Ayons une approche pseudo-scientifique. Si on prend un cas : arrivée à 08h30, récré à 10h30, puis dehors après la cantine de 13h à 13h30, récré à 15h, et sortie à 16h, avec 30 minutes de dehors pour cause de garderie à l'école, nounou ou parent qui prend le temps pour rentrer voire passe par le parc…

Scénario 1 : UTC+2 (donc soleil de 10h à 18h)
- Arrivée de nuit
- Récré 15 minutes avec ensoleillement à 20%
- Midi 30 minutes à 60%
- Récré 15 minutes à 100%
- Sortie 30 minutes à 60%
==> Equivalent de (15*0,2)+(30*0,6)+15+(30*0,6) = 54 minutes

Scénario 2 : UTC (donc soleil de 08h à 16h)
- Arrivée donc 15 minutes dehors, avec ensoleillement à 20%
- Récré 15 minutes à 60%
- Midi 30 minutes à 100%
- Récré 15 minutes à 60%
- Sortie 30 minutes à 20%
==> Equivalent de (15*0,2)+(15*0,6)+30+(15*0,6)+(30*0,2) = 57 minutes

Bref, c'est pareil, à peu de chose près. Ca invalide mon argument, en effet. Mais comme je suis un super parent, je passe plein de temps avec mes enfants à la sortie, et je donne un net avantage à UTC+2. En plus, je les fais dormir avec des lampes à UV braquées sur leurs visages (de toute façon mes plants de cannabis ne donnent plus rien).

Mes gamins sont des recharges à vitamine D. Du coup, je les revends sur eBay et je rentabilise mes lampes à UV.

Au final quand je regarde les chiffres extraits par gUI, je me dis que l'heure d'été (je préfère dire UTC+2) est celle qui "s'équilibre le mieux".

Je m'explique : en juin on a le soleil de 06h à 22h. En décembre de 10h à 18h. Donc le temps de soleil a été réduit uniformément, de 2 heures le matin, et de 2 heures l'après-midi.

Ca permet aux enfants d'avoir un peu d'exposition à la lumière du soleil même en hiver - important pour la synthèse de vitamine D.

C'est con, j'avais pas réfléchi assez, et j'avais répondu UTC quand on me posait la question jusqu'ici, parce que je trouvais ça plus simple, et logique puisqu'on est aligné avec Greenwitch. Maintenant je vais militer pour UTC+2.

Au temps pour moi, le commit d'il y a 6 ans rajoutait les commentaires homophobes.

J’ai pas eu le temps de lire tous les commits, le Git me renvoie un 502 maintenant.

Mais le premier avait 6 ans et le commit contenait notamment le retrait des commentaires homophobes (avec un « b » en passant :-)). Les autres étaient du même aloi ?

Autant ces commentaires sont inacceptables dans un repo public, autant le nom reste un point de détail. Je me demande ce qu’on trouverait si on vérifiait tous les repos des projets libres majeurs (Linux, LibreOffice, KDE, Gnome, …).

J’applaudis des deux mains et je regrette de ne pas en avoir plus.

Tout excès est par définition excessif ; et côté sécurité on met les moyens sur la répression et pas sur l’outillage. La formation - au moins dans mon entreprise - est bien là, mais uniquement sur les bons usages du quotidien (ne pas laisser traîner mon mot de passe, ni de document permettant de faire du social engineering, etc.).

Comment éviter une attaque Man in the Middle, les rudiments de crypto, comment marche une clé de hachage, c’est quoi une injection : là on est beaucoup moi d bien lotis.

Tu as une source à ce propos ? Et quelle est leur politique officielle aujourd’hui ?

Ben du coup sa présentation est en contradiction avec ce qui est présenté dans ce journal.

Ici, quand on parle de concurrence, on parle de ressources qu'il faut se partager (la gamelle), et pour ça organiser les différents "consommateurs" (les chats) pour que ça se passe au mieux.

Dans sa définition, la présence de ressources à partager est totalement absente. C'est juste "programmer une composition de processus qui s'exécutent indépendamment les uns des autres" :

Concurrency: Programming as the composition of independently executing processes.

Il insiste sur cette indépendance en plus, en faisant une des différences notables avec le parallélisme.

Je sais pas qui a tort, qui a raison, mais clairement c'est pas clair. On a une gamelle ou pas ? Ils bouffent comment les chats ?

Plutôt d’accord avec cette approche sauf que le gars qui utilise null pour signifier froid, je propose immédiatement le châtiment à mort par l’empal.

Ce que j’apprecie surtout c’est que ça pose le bon niveau d’abstraction.

Un superflux, c’est un flux avec une cape et le slip par dessus son pantalon ?

(Pour les histoires de contrat qu’il faut « explicater », j’imagine que c’est le correcteur automatique qui a rajouté sa touche personnelle ?)

Le volet latéral seul n'est pas utilisable, puisqu'il n'offre accès qu'à quelques fonctionnalités. J'attends qu'il évolue pour proposer l'ensemble des fonctions accessibles via les barres d'outils, pour les remplacer. Il y avait une version d'OpenOffice, éditée par IBM, qui faisait ça il y a quelques années ; c'était magique.

Sinon on peut aussi se faire des barres d'icônes personnalisées si on veut s'éviter l'horreur d'aller dans les menus. Bref, faut apprendre à s'en servir.

On peut faire la même chose dans n'importe quelle application bureautique, mais on constate vite que ce qui compte auprès des utilisateurs, c'est la configuration par défaut. Y'en a pas beaucoup qui touchent à ça.

Sinon le jeu Colibre, a été fait par des djeunz justement, et il a une disquette comme symbole d'enregistrement. Il est très frais je trouve (et joliment coloré, ce qui va à l'encontre des tendances mortuaires actuelles).

Je te rejoins sur "les tendances mortuaires actuelles".

Par contre, bien sûr qu'il y a plein de personnes et même des jeunes qui utilisent encore cette icône pour des nouveaux logiciels. Mon propos, c'est de dire que ça n'a plus de sens, et qu'il faut penser à passer à autre chose. Là, les gens qui ont 15 ans ont vu l'ancien PC de leur père avec le lecteur, ou ont lu un magazine, etc. Mais bon, tu dirais quoi si l'icône présentait une carte perforée ?

D'ailleurs, il y a plein de personnes qui se posent aussi la question, depuis déjà longtemps : tu peux trouver ce thread par exemple (https://graphicdesign.stackexchange.com/questions/323/new-generation-of-save-icon-that-is-not-a-disk) qui a 7 ans déjà !

Y'avait une réponse intéressante, qui signalait qu'à terme, on ne devrait même plus avoir besoin de sauvegarder ; l'opération étant automatique, et la seule chose à faire étant de donner un nom au document.

Le ruban est un non-sens pour l’occupation de l’espace, ou alors les écrans 16/9 sont un non-sens pour des machines destinées à une activité bureautique / développement. Les deux sont envisageables.

Il faut quand même reconnaître que l’interface de LibreOffice pose quelques soucis. Trop de fonctionnalités imposent d’explorer les menus.

J’aime beaucoup leur idée de travailller en parallèle sur plusieurs solutions, et j’aime particulièrement le volet latéral même si il n’est pas encore vraiment utilisable.

De même, je suis content qu’ils n’aient pas cédé à la mode du flat design (contrairement à Gimp hélas), mais qu’ils travaillent quand même à revoir leurs icônes qui n’ont plus de sens pour les djeun’s. Sérieux, une disquette pour « enregistrer » ? Ceux qui ont moins de 20 ans n’en ont jamais utilisé de leur vie.

Bref en terme de design il faut toujours se remettre en cause, s’adapter au monde mais pas n’importe comment.

Dans le développement du noyau, le rôle de l'intégrateur (ou mainteneur officiel) est clair : il reçoit les patchs, il les relit, les valide (ou non) et alors seulement ça rentre dans son repo git. C'est lui que git affiche, et si l'intégrateur a bien fait son travail, il montre l'auteur original dans le log du commit.

C'est plutôt logique : le "coupable" en cas de commit foireux est d'abord l'intégrateur qui a accepté le code, qui se retourne ensuite vers l'auteur original si besoin.

Perso, je vois ça comme une limite de la plupart des gestionnaires de configuration, mais ce n'est pas mon sujet du jour.

Maintenant, regardons comment git est (parfois) utilisé dans les grosses entreprises. Vous avez des équipes, chacune travaille sur un projet, composées de plusieurs développeurs, et en général un intégrateur. Les développeurs travaillent sur leur propre branche, et quand ils sont contents, ils envoient le tout à l'intégrateur, qui merge dans la branche principale. En général, c'est moins rigoureux que pour le noyau, et le log du commit fait référence uniquement à la fiche Jira/Bugzilla/… Et vous n'avez que la version finale du code. L'intégrateur est juste là pour faire le taf d'intégration, il ne comprend pas grand chose au code, et par ailleurs il s'en fout.

Avec un peu de malchance, la branche qui avait servi au développement a été supprimée pour gratter de la place (ou était uniquement sur le poste local du développeur, un presta qui a depuis fini sa mission ; le poste a donc été reformaté).

Du coup, vous avez juste :
- le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
- votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
- perdu le détail des itérations du code

Et là, vous avez un doute. Ce qui semble être un bug à la lecture du code (mal commenté) est peut-être volontaire. Le dev a peut-être été obligé d'écrire ça pour contourner autre chose. Après tout, ce damné soft est un cauchemart, le résultat de plusieurs années de retouches successives que personne ne maîtrise plus depuis bien longtemps.

Bref…

En gros, la question c'est :
- est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
- ou est-il préférable de n'avoir que les commits "finaux", quitte à perdre le ou les auteurs intermédiaires et les versions intermédiaires en cas de stratégie de stockage merdique/très contrainte
- ou avez-vous d'autres approches ?

Je l'ignorais, mais je ne sais pas encore si ça change grand chose. Entre "ça existe" et "c'est utilisé et suffisamment répandu pour que je puisse m'en servir", il y a un pas.

Je vais creuser, merci pour la piste. Ca pourrait permettre de sortir des erreurs plus propres.

Il ne faut pas perdre de vue que, en l'état, le toolkit n'est prévu que pour réaliser du prototypage, donc, à priori, l'application finale n'utilisera pas ce toolkit, rendant, il me semble, ce genre de questionnement superflu.

Un bon prototype c'est - entre autres - un prototype qu'on peut reprendre en grande partie pour construire l'application cible.

Du coup, dans ton modèle, si le proto rend les utilisateurs heureux et qu'on veut aller plus loin, qu'est-ce qui est réutilisable ? Ou, est-ce que de toute façon tu penses faire évoluer ton framework pour fournir à la fois une version "développement/lab/proto", et une version "prod" ?

Autre question. Sur le fond, j'aime bien le principe de framework tout intégré, mais à quel point ton framework est plus intégré que l'existant ? Côté Front, comment je gère la zolie interface graphique ? Côté Back, comment je me connecte à des ressources de type bus de message et base de données ?

D'accord pour dire que "très chiant" c'est exagéré.

Cela dit, XML reste pénible à utiliser/taper/lire, et perso, partout où j'ai le choix pour de la configuration, c'est JSON ou YAML/INI, en fonction de "contexte web ou pas web, complexe/simple".

YAML a l'avantage d'être également utilisé par d'autres outils type Ansible qui ont potentiellement la même base utilisateur. XML reste rare pour tout ce qui est setup du système de base.

Je garde XML pour de l'échange de données inter-systèmes et quand une validation formelle en entrée ou en sortie est nécessaire.

Pas vraiment, Antédiluvien ça veut juste dire que ça date d’avant le déluge.

Ça fait des décennies que l'on développe des application avec une interface native,

Comme pour la prose, des fois on fait du MVC sans le savoir. Il y a plein de bibliothèques de création d'interfaces "natives" qui font du MVC. Mais si c'est pas écrit dessus, tu peux passer à côté de l'info.

Plus généralement, pour gérer des listes de très grandes tailes, ça reste la solution la plus simple. Pour réutiliser un max de code, ça reste la solution la plus simple.

Merde, j'ai plussé. Ca ne peut vouloir dire qu'une seule chose… :'-(

…à quand la réécriture en J2EE ? Depuis le temps, je commence a vraiment m’inquieter.

Sur un système financier, j'ai créé une boucle infernale en livrant un bugfix, qui est monté en production. Il a fallu bosser 3 jours et 3 nuits avec les ops pour corriger toutes les données et éviter tout impact pour les clients.

Sur un autre système financier, j'ai voulu livrer en environnement dev une mise à jour du paramétrage de contrôle de position titres que j'étais en train de modifier. Je l'ai livré en production. J'ai mis 15 minutes à m'en rendre compte ; le contrôle de position n'a pas été très efficace ce jour-là, puisqu'il a fallu réinitialiser tout et attendre le jour suivant pour retrouver des chiffres corrects.

Tout ça, c'était y'a 15 ans. Maintenant on peut plus faire des livraisons en production à la sauvage, et c'est pas plus mal…

Pour la référence cachée je pense à un morceau de Megadeth. « Captive honour » si ma mémoire est bonne. Mais il est possible qu’elle-même fasse référence a quelques.

Verdict ?

Ce journal aurait sa place dans les liens !

…

Bon en fait il est un peu trop long pour être complètement qualifié de bookmark, mais quand même, l’occasion était trop belle.

Cela aurait pu être pire, et être ass-bean. Déjà que j'aime pas les haricots…

En effet, ça ferait un OVNI difficile à diffuser. Je vais réfléchir à la question cette nuit, puis ma procrastination naturelle fera le reste pour oublier tout ça.