Dring a écrit 1149 commentaires

Alors je te rejoins totalement ; on néglige souvent la valeur d'une explication textuelle "classique".

Un double clic sur l'onglet du ruban le fait disparaître, et ensuite un survol le fait apparaître.

Cela dit, et comme indiqué au dessus, j'aurais préféré une approche "on met tout sur le côté" ou "on laisse le choix"..

Ben chez moi ça marche pas. Tu fais clic droit sur quel élément ? Moi, où que je sois, c'est la barre d'outils "Accès rapide" qu'il me propose de paramétrer… (celle qui est sur la barre de titre de l'application).

Le danger avec cette approche c'est que tu te retrouves vite à ne plus faire de documentation.

La doc, les specs, ce n'est pas uniquement pour préparer l'étape développement, c'est aussi pour communiquer. Avec les utilisateurs, et valider ce que tu vas faire. Avec tes pairs, pour discuter/valider tes choix. Avec les autres développeurs, qui feront le support/la maintenance. Etc.

Alors évidemment, il y a l'approche "j'ai mis plein de commentaires, les variables et noms des méthodes sont explicites, pas besoin de doc", mais sur des projets complexes impliquant plein de règles "métier", ça ne marche pratiquement jamais.

D'ailleurs, c'est pour ça que j'aime pas UML, qui était pensé au début pour pouvoir communiquer avec les utilisateurs, mais qui est illisible pour qui n'est pas dans l'informatique et déjà un peu versé en UML.

retour au point de départ : comment présente-t-on tout ça ?

Moi je sais ! On fait des rubans, et chaque ruban représente une activité, et contient un accès rapide à la majeure partie des fonctions de cette activité. Plus un ruban "général" pour les fonctions communes à la majorité des utilisateurs.

J'ai bon ?

Plus sérieusement, j'ai longtemps craché sur les rubans, avant d'être obligé de m'en servir. Je peste encore car l'organisation n'est pas toujours logique, et retrouver ses petits est parfois ardu, mais dans l'ensemble c'est pas mal.

Mon principal reproche : tout est encore en haut de l'écran, à l'époque des écrans 16/9ème c'est un peu chiant de voir la zone de travail encore réduite (même si le masquage automatique des rubans est efficace). Mon autre gros reproche : on ne peut plus rien paramétrer (ou j'ai pas trouvé comment).

Je crois que les gens de chez IBM ont fait un bon boulot là dessus, avec des "espèces" de rubans verticaux. Calligra est assez souple aussi - je crois. Mais loin d'être complet et stable, hélas.

Ah. Dommage, j'aurais bien aimé troller là dessus.

Ben en l'occurrence, je trouve que là on a une illustration d'un bon usage. Ca aide bien à comprendre comment est initiée une partie, on voit les intervenants, la séquence, les méthodes, etc.

Dans ce cas, je dirais que je trouve ça plutôt utile, et vraiment enrichissant par rapport à un texte qui aurait été lourd et long - et donc chiant.

Hum, ta question est-elle "est-ce que tout le monde trouve que UML c'est de la merde", ou est-elle vraiment innocente ? Ca vaudrait le coup d'un autre journal pour répondre à ça. Ca sent la digression (et le troll) à plein nez.

Bon, un élément quand même : moi, du texte ou un diagramme UML, ça me donne exactement la même info. Mais parfois, la vision graphique donne une vision d'ensemble en plus.

Après, ça n'empêche pas UML d'être de la merde.

Pas vraiment ; pour le calcul du libor, les banques doivent publier les prix auquel elles empruntent, pas celui auquel elles prêtent.

C'est très différent, et c'est d'ailleurs pour ça qu'une banque a fini par tricher. Avouer qu'elle empruntait à un taux plus élevé que les autres aurait montré un manque de confiance envers elle.

Je confirme également. Lotus Notes est sans doute à l'origine du mot bloatware.

Le problème, c'est que ça ressemble également beaucoup à Lotus Notes, d'où ma première réaction : une grosse nausée, heureusement compensée par l'organisation des outils sur le côté qui colle un peu mieux avec les écrans modernes.

C'est par ici la bonne soupe : http://kde-apps.org/content/show.php/luckyBackup?content=94391

Pas essayé, mais ça à l'air intéressant. L'interface est pas trop vilaine.

Déjà que Selenium remplace avantageusement QuickTest Pro pour une grande majorité d'IHM.

Ah, un retour d'expérience dans ce domaine m'intéresse fortement. Ici, on utilise les deux, mais Selenium est plutôt utilisé par l'IT, et QTP par les utilisateurs (avancés). Mais du coup, l'IT commence à s'en servir, à mon grand désespoir.

Je peux me tromper, mais l'outil s'interfaçant directement avec le bug tracker, il est tout à fait envisageable de mettre en place dans ton cas une instance de JIRA reliée à Squash pour les défauts de recette et une autre instance indépendante pour les "bugs de prod".

C'est effectivement une piste ; mais est-ce que dans ce cas on perd tout ou partie des fonctionnalités de navigation défaut/cas de test/exécution de test/exigence qui sont vraiment naturelles dans un outil comme QC (que j’exècre par ailleurs).

Pour la partie gestion à un bugtracker, juste un retour d'expérience sur comment ça marche les tests "chez nous", pour plusieurs centaines de projets et autant de développeurs, répartis sur 3 pays.

On a d'un côté un bugtracker (un JIRA) qui sert à :

• suivre les demandes de changement, i.e. améliorations, corrections de bugs et nouvelles fonctionnalités
• suivre les incidents et demandes de support de production

De l'autre côté, un outil de suivi de test (QualityCenter), qui sert à :

• suivre les exigences ET les demandes de changements (et là déjà y a un peu de variation d'un projet à l'autre)
• créer/gérer les plans de tests
• créer/gérer les campagnes de tests
• créer/suivre les défauts

Et oui : on gère d'un côté les défaut dans QC (pour ce qui est détecté pendant les phases de tests) et de l'autre les bugs dans JIRA (pour ce qui est détecté en production). D'ailleurs, quand un défaut détecté en recette ne peut être corrigé (soit parce que c'est trop compliqué et non bloquant, soit parce que finalement c'est une nouvelle fonctionnalité), on crée une demande de changement dans JIRA, pour la planifier dans une version ultérieure.

Bref, tout ça pour dire que l'idéal serait qu'un outil comme SquashTest propose une gestion intégrée des défauts de recette. Ainsi, un défaut est clairement lié à une exécution de test, à une ou plusieurs exigences, … Et n'est pas mélangé à des demandes de changement et des bugs "de production".

De manière plus générale, le site de test de Squash ne répondait pas quand j'ai voulu l'essayer ; les copies d'écran laissent apparaître quelque chose manquant de fini sur la partie présentation, avec peu de possibilités de personnalisation. Mais je garderai un oeil sur ce projet à partir de maintenant, car trouver un remplaçant à QC serait… un pur bonheur (ActiveX suxxxent !)

M'enfin là, c'est l'histoire de l'homme qui a vu l'homme qui a vu l'ours.

Au final, et tu le dis toi même, tu n'as que peu de détails, et l'histoire t'a été racontée par une personne non informaticienne. Pour travailler dans un grand groupe bancaire, la situation est loin d'être rose, mais la plupart des gens n'ont pas idée de la complexité engendrée par un système d'information qui comprend des milliers d'applications, de serveurs, et des centaines de milliers d'utilisateurs.

On est parfois obligé de composer entre une volonté légitime de rationaliser et d'uniformiser les outils et les besoins spécifiques. Regarder par le petit trou de la lorgnette, et pointer un problème en particulier, c'est un peu facile et ça mène pas loin.

Ca ne m'empêche pas de m'énerver régulièrement et de pester, mais je garde en tête que derrière, c'est un gros truc.

De toute façon, en bon français, on dit pas "emoticon", mais "frimousse".

Donc on peut dire qu'Apple a inventé la tablette qui se vend, là ou d'autres avaient seulement inventé la tablette.

Tout devient clair.

Tout pareil ici. Je vote pour l'ajout de l'option dans le sondage !

Le monde se sépare en deux type de personnes. Ceux qui catégorisent les gens en deux et les autres

Tout ça pour dire qu'effectivement, mon propos était caricatural pour me focaliser sur ce qui constitue l'essentiel du "travail" de nos jours.

Dans ce que j'ai eu à faire jusqu'ici, tout le travail batch est assimilable à "de petits utilitaires" qui s'appuient eux-même sur des outils "systèmes".

Genre un gros shell qui appelle de la base de données, fait des greps, et alimente un fichier de log. Donc, du "*sh/perl/python/..." qui s'appuie sur du "C/C++/Assembleur" dans beaucoup de cas.

Mais peu importe. La question demeure : quels sont les gros projets pour lesquels un outil comme Gambas, qui est quand même pas mal orienté GUI si je ne me trompe pas, trouve sa place face aux applications web ?

Pour moi, Gambas se situe dans la droite ligne de VisualBasic, Delphi, Powerbuilder, Windev, etc...

Ces environnements qu'on a appelé des AGL (Ateliers de Génie Logiciel) ou L4G (même si ça ne répond sans doute pas aux définitions "officielles" de ces termes), et qui ont périclité depuis l'avènement des applications web, ont-ils encore une place dans l'avenir de l'informatique ? C'est une vraie question, pas une affirmation.

Personnellement, je suis resté très nostalgique de Delphi : un IDE visuel, du vrai code, un vrai compilateur, etc.

Pour moi, le monde se divise désormais en deux familles. Les environnements "à la dure", avec assembleur, C/C++, pour tout ce qui est système, temps réel, super optimisé, etc... Et les environnements web pour le reste (applications métiers en entreprise et petits logiciels personnels).

Ne reste que quelques miettes pour les Gambas et autres : frontaux à des outils en ligne de commande et/ou petits utilitaires.

Je vois qu'il y a des exemples pour me contredire (cf. commentaires plus haut), mais quelle est la nature de ces projets ? Pourquoi est-ce qu'un outil comme Gambas a été retenu plutôt qu'une application RoR / PHP / JavaEE / GWT / etc... ?

... c'est Hans Reiser !

De toute façon les JSPs c'est le mal. C'est moche.

Vive les frameworks "tout java" (genre GWT). Vive le vendredi !

...et notamment, sur ce qu'est un utilisateur.

Une mamie de 70 ans, lui "laisser gérer ses mises à jour", c'est juste totalement décalé. Même si tu marques "attention, ces paquets sont des mises à jour de sécurité importantes", elle va flipper, et par défaut dire non.

Un ado de 15 ans, il va dire oui à tout. Il sait ; il a confiance en lui et peur de rien.

A mon avis, lors de l'installation, pour une distribution "grand public", on devrait poser la question de "quel type d'utilisateur êtes-vous ?".

• novice -> mises à jour de sécurité installées automatiquement, sans rien demander. Autres mises à jour jamais proposées par défaut.

• intermédiaire -> mises à jour de sécurité installées automatiquement. Autres mises à jour proposées à l'écran.

• avancé -> aucune mise à jour installée par défaut. Tout est proposé, au choix de l'utilisateur.

Ben en même temps, l'usage du latin en langue française fait généralement moins hurler que celui de l'anglais.

C'est drôle ET de mauvais goût. L'un n'exclue pas l'autre.

Moi aussi, j'espère qu'il y aura du monde pour rire de ma mort. Mais pas en sortant des vannes de ce type à ma veuve et mes gamins le jour de l'annonce... Question de tact.