Dring a écrit 1149 commentaires

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();
}

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.

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.

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.

Désolé de me (ré)insérer dans cette discussion.

Tu pars du principe (fort louable) que les tests unitaires/d'intégration sont bien faits, bien maintenus, etc.

De tous les projets que j'ai vu, on a cette approche sur les 6 à 12 premiers d'un projet. Puis ça part en sucette. Pas toujours, certes. Mais très souvent. Dès que la pression commence à monter.

Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".

Maintenant, si sur les projets que tu as vu, la couverture de test reste une priorité sans limite de temps, j'applaudis des deux mains et je te souhaite tout le bonheur du monde. Mais vraiment, c'est pas ce que j'ai vu jusqu'ici, et des projets, j'en vois passer beaucoup (environ 30 nouveaux projets par an dans le secteur bancaire, aux alentours de 15 000 jours/homme).

D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.

Sur ces individus, je les classifie in fine en deux catégories.

1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.

2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.

J'ai vu des énormes projets (i.e. > 10 mio €, au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.

Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.

Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.

Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.

Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).

Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.

Ce que tu décris, c'est l'exception ; dans la plupart des cas, plus de cache signifie moins d'I/O physiques et plus d'I/O logiques.

Sur une base pouvant tenir entièrement en RAM (i.e. moins de 200 Go pour des machines un peu récentes), j'ai vu une amélioration des performances d'environ 50% sur une machine qui saturait les I/Os entre le dataserver et le SAN.

Donc oui, je l'ai déjà testé. Plusieurs fois.

Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.

C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.

Tu as déjà eu des traitements de masse à faire sur une base SQL ? Et tu fais ça via ton appli qui charge chaque ligne, fait le calcul, et stocke le résultat ? Tu fais ça 10,000,000 fois, et tu penses que parce que tu as été super fort, en répartissant le travail sur 200 noeuds, tu as obtenu une bonne vitesse de traitement ? Quid des I/Os engendrées entre la machine hébergeant la base, et la machine hébergeant ton application ? Le franchissement de DMZ, la charge sur la baie de stockage, la non-utilisation du cache de la base, et j'en passe ?

Mon dieu…

C'est pas seulement une question de savoir où on met la couche truc et la layer bidule. C'est juste d'avoir un temps d'exécution acceptable pour répondre aux contraintes des utilisateurs.

J'utilise ça tous les jours et ça fonctionne plutôt bien.

Par contre, pleins de fonctionnalités sont en option (minimal logging, compression), le transac-sql (langage de procédures stockées) évolue très très très lentement. Bref, je bave devant un postgresql.

L'autre soucis c'est que c'est tellement en perte de vitesse que le support se dégrade : plusieurs semaines pour le correctif d'un bug qui fait crasher le dataserver systématiquement…

Le planificateur Windows existait déjà sous Windows 95… Et sous Windows NT 3.x. Où on avait aussi la formidable commande "at".

Dans l'article je vois qu'effectivement Mozilla n'est pas un des navigateurs testés, mais en remontant à l'article source (eweek) je ne vois nulle part écrit 'because it's too easy'. Juste qu'il n'y a pas eu d'évolution significative coté sécurité.

Quelqu'un a une autre source pour confirmer la motivation derrière la décision des organisateurs ?

Sinon, on parle beaucoup d'IE dans les commentaires de ce journal mais ce dernier n'est plus testé non plus c'est désormais Edge qui retient l'attention.

10 cl de liquide (5 de votre alcool fort préféré + 5 d'eau, on peut remplacer par autre chose si on n'aime pas l'alcool)

Je préfère l'hydrogène, ça marchera si je prends ça comme liquide ? ;-)

Bon, sérieusement, le liquide en question doit être liquide à l'état naturel, sinon vous ne passerez pas l'hiver.