Conseils pour développeurs (asp.net) du dimanche

Cela fait quelques semaines que j'interviens de façon ponctuelle sur la maintenance d'un extranet pour un client, et que je m'énerve régulièrement sur l'incapacité de la plupart des développeurs à comprendre qu'un code doit être un minimum propre... L'application, écrite en asp.net, est un ensemble de morceaux de code réalisés, probablement, à la va-vite par des CDD si j'en juge par la "qualité" très médiocre.

Voici donc quelque conseils à retenir si vous faites du développement ASP.net et que vous souhaitez voir votre code être maintenu...

N'accèdez jamais, directement dans votre page, à des variables de sessions ou d'application : c'est probablement le B-A-BA du développement avec des langages typés... Il n'est pas normal de voir dans une page ASP.net (sauf cas exceptionnels) des accès du type :

(int) Session["MEMBRE_ID"] // non !!!!!

Pourquoi cela n'est-il pas bien ? eh bien tout simplement parce que si une autre page accède (ou encore plus catastrophique met à jour) votre valeur, il y a 1 chance sur 2 pour que celle-ci ne manipule pas le même type de données (dans l'exemple de l'application extranet, l'une des pages traitait l'identifiant client comme un decimal et l'autre comme un int...). Pour réaliser un code maintenable, il vous reste à faire une class "Helper" qui se charge de masquer l'accès à la variable de session et le typage :

public class SessionHelper
{
    public int MembreId
    {
        get
        {
            object o = Session["MEMBRE_ID"];
            if (o == null || !(o is int))
                return 0;
            return (int)o;
        }
        set
        {
            Session["MEMBRE_ID"] = value;
        }
    }
}

Avec ça, plus jamais de "InvalidCastException" - enfin, si je ne me suis pas trompé dans l'écriture de la classe :) - et vous risquez moins de problème qu'à tout stocker en string (je pense principalement à des soucis d'injection sql...). Sans parler du fait que vous ne chercherez plus si vous avez appelé votre variable "MEMBRE_ID", "IdMembre", "MEMBREID", ou tout autre variation...

Dans le même ordre d'idée, ne réalisez jamais les updates sans typer vos variables : à moins de réaliser une application poubelle et donc d'utiliser le RAD à 100%, vous avez probablement écrit des méthodes (si ce n'est des objets) pour l'implémentation de vos règles métiers et de vos accès aux données. Bien ! mais pitié, n'utilisez pas des signatures du type :

public static Membre GetMembre(string membreId)
{
     // non !!!!!
}

lorsque vous savez que membreId est un int, cela fait désordre. Lorsque je vois ce genre de signature, cela m'effraie toujours un peu : si le développeur n'a même pas été capable de typer ses variables, il y a peu de chance qu'il ai fait des requêtes paramétrées, et c'est donc une porte ouverte à l'injection SQL...

Si vous avez des cas complexes dans vos règles de gestion, découpez le problème en différentes méthodes axées chacune sur la résolution d'un problème simple. Ce conseil la, je pensais vraiment que tout le monde l'avait en tête, mais je me trompais lourdement... Toujours sur le même exemple (oui, cela pourrait être un cas d'école cet extranet, pour le cours "programmez comme des pieds, c'est mieux !"), l'application présente une menu général dont les fonctionnalités changent en fonction de critères multiples (droits accordé à un client, type de structure dont il fait partie, etc.), voici (extrêmement simplifiée) la façon dont cela est traité :

string matricePossibilite = "";
matricePossiblite += Session["MEMBRE_TYPE"].ToString();
matricePossibilite += Session["..."].ToString();
// il y a encore 3 autres criteres comme ceci...

switch (matricePossibilite)
{
    case "11012":
        // une bonne cinquentaine de lignes de code
        break;

    case "21012":
        // d'autres lignes...
        break;
}

Non, non, vous ne rêvez pas, c'est bel est bien écrit comme cela, avec un minimum de commentaires, pour la plupart inutiles d'ailleurs, histoire de simplifier l'affaire... Hormis le fait que tout le code se trouve dans la même méthode, c'est aussi typiquement le cas ou un switch est une très mauvaise idée : cela rends plus difficile à lire. Admettons que l'on garde le switch pour une premiere ré-écriture, il est déjà plus qu'obligatoire de virer toutes ces lignes de codes :

string matricePossibilite = "";
matricePossibilite += Session["MEMBRE_TYPE"].ToString();
matricePossibilite += Session["..."].ToString();
// il y a encore 3 autres critères comme ceci...

switch (matricePossibilite)
{
    case "11012":
        NomDuCasNumero1();
        break;

    case "21012":
        NomDuCasNumero2();
        break;
}

C'est déjà un poil plus lisible... Il reste ensuite, soit à bien documenter ce que signifie chacun des cas :

case "11012":
// l'utilisateur est de type ...
// dans une structure ....
// etc

Ou même encore mieux : ne pas utiliser de variable bizarre pour déterminer les droits mais des variables avec des noms compréhensibles :

bool estAdmin = SessionHelper.MembreType == MembreType.Admin;
TypeStruct type = SessionHelper.TypeStructure;
// les autres critères selon le même principe

if(estAdmin)
{
    if(...) // un autre critère
        NomDuCasNumero1();
    else
        NomDuCasNumero2();
}
else if(!estAdmin && type==TypeStruct.Type1)
{
    NomDuCasNumero3();
}
// etc.

C'est un peu plus verbeux, et cela demandera certainement un peu de réflexion pour ne pas tomber dans une liste de if/else if ou une cascade de if imbriqués - pensez de nouveau à découper en plusieurs méthodes si vous avez trop de if... - mais qu'est-ce que c'est plus simple à comprendre !

Si vous êtes adepte des procédure stockées (ce n'est pas mon cas, mais bon, tous les goûts sont dans la nature...), n'hésitez pas à les nommer proprement : mbr_s c'est bien comme nom mais MembreSuppr c'est carrément plus lisible... et tant qu'à faire, pensez à définir des méthodes-metier dont les noms sont en relation avec celui de la proc-stock.

Voila, ce sont les quelques conseils/remarques qui me sont venus à l'esprit au cours des heures passées à me battre avec cette application. Pour résumer :

• la plupart des langages actuels sont fortement typés (cela n'a pas que des avantages, mais évite certains dérapages...), assurez vous donc que votre code en soit conscient et compense automatiquement les cas où le typage est plus léger (pour asp.net, il faut comprendre par là : tout ce qui à été conservé compatible avec asp...)
• votre code doit pouvoir être compris dans son ensemble par un autre développeur sans avoir à lire 2000 pages de document Word ou sans avoir besoin de lire dans vos pensées, un peu de commentaires et surtout un code lisible qui peut se comprendre facilement est très souvent préférable à un code plus optimisé - ou du moins qui vous paraît plus optimisé.
• ah...oui... pour avoir eu aussi un problème de code source livré différents de l'application en production : utilisez un système de gestion de source : il est rageant de devoir décompiler la version de production pour retrouver des bouts de code...

Et pour thierry, si il passe sur ce billet : essayez de trouver un prestataire qui ne soit pas en carton pour la prochaine fois :)

Visualiser les commentaires(RSS) ou en Ajouter

Conseils pour une présentation/formation réussie

Il y a déjà pas mal de temps (ah oui, 5 ans, tout de même...), Scott Hansleman donnait un certain nombre de conseils pour la réalisation du présentation/formation technique. Heureusement, il ne s'est pas arrêté là, et les a remis à jour il n'y a pas bien longtemps. Pour résumer (et hormis l'inévitable "essayez au moins de connaître un minimum votre sujet"), voici les remarques que je trouve les plus pertinentes - un peu remis à ma sauce - :

• Utilisez des machines virtuelles pour vos présentations. Cela a deux gros intérêts : le premier, comme scott le suggère c'est d'avoir une solution de remise à zéro simple et rapide. Le second, encore plus intéressant, c'est de pouvoir laisser aux techniciens venus assister à la démo un environnement complet qu'ils pourront utiliser pour reproduire votre démonstration et/ou approfondir, sans avoir à se soucier de trouver un serveur, de prendre le temps d'installer etc. De quoi Passer pour un dieu(TM) . J'ai pour habitude de mettre ces machines virtuelles sur un disque USB (et depuis peu e-sata) mais rien ne vous empêche de graver un ou deux DVDs (et de pleurer sur le peu de données que l'on peut mettre sur 4.7go...)
• Ne courrez pas au travers de la pièce pour faire avancer vos slides. J'ai utilisé aussi bien le Cordless Presenter de Logitech que la Presenter Mouse 8000 de Microsoft, et franchement, c'est vraiment indispensable. Nous ne pouvons pas tous être Steve Jobs et avoir quelqu'un juste là pour faire avancer la présentation, donc optez pour une solution vous permettant de ne pas avoir à vous pencher sur votre notebook. (Pour info, j'aime beaucoup l'horloge du Cordless, cela permet de ne pas trop dépasser le temps prévu)
• Réduisez au maximum le "bruit" de vos interfaces. Vous avez 17 toolbars personnalisées dans l'application ? Oubliez les pour vos présentations : elles ne feront que surcharger l'écran pour pas grand chose. Rappelez vous que votre contenu devra être visible de loin donc que la quantité d'informations présentées doit être réduite. Tant que vous y êtes, en plus de supprimer les toolbars inutiles, regardez si vous pouvez changer la taille de police et ou le paramêtre dpi de Windows pour rendre le texte plus lisible à distance. (Si vous essayez de changer les dpi pour mettre en "grande police" selon la terminologie XP, soyez sûr de refaire un tour complet de votre présentation, peu d'applications supportent ce genre de plaisanterie sans faire n'importe quoi)

Visualiser les commentaires(RSS) ou en Ajouter

Retour d'expérience sur WPF

Cela fait maintenant un an que je réalise (principalement) du développement WPF, d'abord pour 2 ou 3 projets "direct-poubelle" - vous savez ces mini-projets que l'on prévoit de ne jamais arriver à finir et qui ne sont là que pour faire toutes les gaffes possibles et imaginables - puis pour deux applications LOB. Bien qu'ils ne soient pas finis, ces deux derniers projets ont aboutis à la création d'un certains nombres de règles d'or que nous utilisons (et utiliseront) pour améliorer le développement...

C'est probablement l'un des points les plus difficiles à mettre en place - et un sujet de complainte fréquent sur les blogs parlant de WPF - mais une fois un certain nombres d'idées prises en compte et appliquées, cela va beaucoup mieux... La règle à retenir pour ce point est : "ne faites pas faire au développeur le travail du designer". Dans les règles suivantes, j'utiliserai le terme "fonctionnel" pour désigner les données et la façon de les manipuler, et le terme "présentation" pour tout ce qui est de l'ordre du rendu visuel. Si vous utilisez un modèle de séparation "règles métier" / "affichage", sachez donc que la partie que je nomme "fonctionnelle" correspond au code utilisé dans la "vue" pour appeler les objets métiers et traiter leurs réponses.

• Le développeur doit exposer des propriétés pour toutes les données qu'il souhaite voir afficher. Ce n'est pas à lui de décider de où, ni de comment seront affichées les informations d'un écran.
• Les animations et autres effets graphiques sont du ressort du designer. Oui, même celles que l'on ne peut pas facilement exprimer en XAML ! Il n'est pas logique que le développeur "fonctionnel" se charge de déclencher des animations ou de manipuler directement des objets (panels, listview...) de la partie "présentation". Après tout, lorsqu'un designer fait une animation Flash, il écrit du code ActionScript pour de très nombreuses choses. Le principe est ici le même : il devra probablement mettre les mains dans le cambouis. Bon, bien sûr, ça c'est le concept, mais une bonne solution pour éviter que le code soit saccagé - euh, oui je suis développeur dans l'âme, pourquoi ? - est :
  1. Si votre équipe est suffisamment grande, d'affecter un développeur à l'équipe design, ou dans le cas d'une petite équipe de faire travailler le développeur au code de présentation après qu'il ait fini le code fontionnel. Ce développeur-designer sera chargé d'écrire tout le code nécessaire aux animations et autres effets graphiques.
  2. de séparer dans des fichiers sources différents (à l'aide de partial class) la partie fonctionnelle de la partie présentation.
• Le développement d'une fenêtre ou d'une page, demandera probablement plusieurs aller-retour. C'est l'une des choses qu'il ne faut clairement pas oublier : il n'y a que très peu de chance que le designer ne soit pas bloqué par un oubli du développeur et/ou que le développeur ne soit pas amené à ajouter du code (évenements, nouvelles propriétés) à cause du designer.
• Vos développeurs vont devoir oublier une bonne partie de ce qu'ils savent sur l'écriture d'une application.Dans chaque développeur Windows Forms se cache un bidouilleur-né : nous avons été habituées depuis longtemps à nous servir des contrôles directement (qui ne s'est jamais servi de la propriété Tag d'un ListViewItem comme seul et unique conteneur pour ses données métier ?) et donc à nous appuyer sur eux, mais ce genre de comportement ne doit plus être de mise avec WPF.

Prenez le temps de développer un framework applicatif

L'un des points que l'on omet aussi souvent lorsque l'on parle de WPF c'est de se souvenir qu'il s'agit d'un framework de présentation et en tant que tel, qu'il n'est pas suffisant dans le développement d'une application complexe. Qu'il s'agisse de répercussions de ce fait ou des oublis dans le framework, voici deux exemples de fonctionnalités à développer.

• Le modèle de gestion des threads choisi pour le framework est... comment dire ? .... extrêmement pénible ! Pour éviter de nombreux soucis de concurrence, les données utilisées sur celui d'affichage ne sont pas accessibles sur les autres. Il vous faudra donc, pour la santé mentale de vos développeurs, faire développer des classes simplifiant la discussion inter-thread( par exemple pour fusionner le résultat d'un appel asynchrone à un web-service avec une ObservableCollection exposée par votre contrôle)
• Il n'est pas possible d'écrire du code ni même des expressions dans le fichier XAML (il n'y a pas d'équivalent XAML à "IsEnable= (madonne==null)" par exemple), il vous faudra donc créer des classes de conversion de données ou d'extension du markup pour pallier à ce manque.

Acceptez les limites de WPF

Avec .net 3.0 (et 3.5), nous avons le droit à une version 1.0 de WPF, ce qui engendre un certain nombre de soucis et de limitations. Pour un développement réussi, il vous faudra donc les prendre en compte.

• La performance de WPF est loin d'être exceptionnelle... Exit donc les délire d'animations qui demanderont un QuadCore minimum pour fonctionner correctement. Si dans l'ensemble la performance n'est pas mauvaise pour un système vectoriel, certaines fonctionnalités de WPF ne sont clairement utilisable qu'avec parcimonie : les bitmaps effects par exemple sont à réserver à de très petites surfaces
• XAML n'est pas suffisant ! Il est vain d'essayer de faire croire que XAML est une solution parfaite pour les designers. En effet, et malgré une étendue déjà plus qu'impressionnante, certaines choses ne sont pas réalisables en XAML ou ne le sont qu'avec un niveau de complexité bien plus grand qu'en C# (par exemple). N'hesitez donc pas à écrire du code lorsque cela est nécessaire et/ou plus simple !
• Le compilateur XAML a encore du chemin à parcourir. C'est peut-être le point le plus gênant lors de l'utilisation de WPF : il existe de nombreuses erreurs dues à des facteurs techniques (mauvais type d'objet, paramètres incorrects, etc...) qui ne sont pas détectées par le compilateur (alors qu'un compilateur comme celui de C# est capable de les repérer) et qui se traduisent donc par des exceptions plus ou moins compréhensibles (plutôt moins d'ailleurs...) lors de l'exécution. Il n'y a malheureusement pas de palliatif à ce problème mis à part un : prenez votre mal en patience.

Visualiser les commentaires(RSS) ou en Ajouter

Applications WPF

Il y a quelques temps, j'ai évoqué des projets WPF/Silverlight sur lesquels je travaillait... En voici quelques screenshots, histoire que vous puissiez avoir une idée du rendu :

• d'abord un outil de visualisation de statistiques, récupérant ses données soit depuis des rapports sous SqlServer Reporting Service soit - et c'est le but principal recherché - depuis les vues statistiques de la gestion commerciale d'un client/partenaire.

Le concept-art réalisé sous CorelDraw - parce que je suis un fan de ce produit - avec le tag "beta" histoire de faire un peu Desktop 2.0 :)...


...et sa réalisation ou plutôt l'état actuel de sa réalisation puisqu'il reste encore quelques modifications à apporter.

• Je travaille aussi actuellement à la ré-écriture de certains modules de la Gestion Commerciale précédemment évoquée (les deux screenshots sont réalisés sur la même partie de l'application, le suivi des clients) :

L'un des grands challenge lorsque l'on écrit ce type d'application est d'arriver à innover - et à rendre une application visuellement plus agréable - sans pour autant changer les habitudes de travail ni même ralentir celui-ci. Vous remarquerez probablement dans ces screenshots un petit emprunt à Zune 2.0 (le système de tri de la liste), mais il est plus que probable que celui-ci soit remplacé par les beaucoup-plus-classiques entêtes de colonnes pour la version finale.

• Je ne reviens pas vraiment dessus, puisque j'en ai déjà parlé, mais, pour le plaisir (en tout cas pour le mien), voici un petit screenshots de l'application kiosque réalisée en silverlight pour un client :

PS : oui, je sais, ca fait beaucoup de orange & noir, mais ce ne sont que des coïncidences : ce n'est pas moi qui ai choisi les thèmes de couleurs...

Visualiser les commentaires(RSS) ou en Ajouter

Quel type d'applications développe-t-on avec WPF et Silverlight ?

Il y a de cela quelques jours, je suis tombé sur un billet - de Thomas Lebrun - appelé [WPF / Silverlight] Quel type d'application développe-t-on avec WPF et Silverlight ?.

WPF est une plateforme très complète, fournissant grâce à toutes les classes de .net - et à l'interop si nécessaire -, une solution robuste pour construire des applications complexes. Traditionnellement, les applications "clients lourds/clients intélligents" faisait pale figure face à la qualité visuelle de la moindre application web, mais cela est maintenant terminé.

Silverlight, surtout parce que très jeune (et assez limité, il faut bien le dire dans cette version 1.0), va se trouver pendant lontemps utilisé à simplement "rendre un peu plus interactif" un site web. Comme pour Flash, il est peu probable de voir arriver avant quelques années des applications vraiment intelligentes réalisée avec cette techno : les limitations du modèle "web-embedded" étant bien trop nombreuses (Adobe l'a d'ailleurs bien compris en déclinant sa plateforme avec AIR).

Voila, ca c'était les généralités... Je suis très "client intelligent", donc - surtout depuis que WPF est sorti - lorsque je doit choisir une technologie c'est rarement le web qui gagne, mais voici les deux projets (enfin, les deux qui entre dans le cadre de la question WPF ou asp.net+Silverlight ?) sur lesquels je travaille en ce moment ou que je viens de terminer :

• un afficheur de rapports/statistiques : en WPF, le choix ayant été assez compliqué... Il s'agissait au début de fournir des aspects graphiques un peu plus sympa aux Reporting Services de SQL Server 2005, et puis, au fur et à mesure de la réflexion de nombreuses fonctionnalités supplémentaires ont été imaginées, dont la plupart demande l'interaction avec le système de fichier de l'utilisateur - par exemple la possibilité d'envoyer un graphique dans un slide de présentation PowerPoint.
• une visite virtuelle et un complément d'exposition pour un musée. Le choix a été assez simple (après les 15 premieres secondes pendant lesquelles je me suis dit : "chouette une appli WPF à faire !") puisque l'application est plus destinée à être fournie aux visiteurs avec le catalogue de l'exposition qu'à être utilisé sur place. Dans ce cadre, les 50Mo et le quart d'heure d'installation de .net 3.0 sont inenvisageables donc : Silverlight

Visualiser les commentaires(RSS) ou en Ajouter

Puisque vous me l'avez demandé : tada ! une appli Silverlight !

Suite à mon billet précédent, et après quelques demandes, je vous propose de voir l'application SilverLight que je viens de terminer.

Concept-art de l'application

Attention : ce que vous allez voir n'est pas la version définitive, loin s'en faut ! Il s'agit de la premiere pré-version de l'application, avant d'avoir le contenu, et avant d'avoir finalisé le fonctionnement (il y a encore pas mal de bugs) et l'aspect graphique... [Enfin, j'ai été obligé de faire quelques modifs ce matin dans le javascript et dans les images pour que cela fonctionne en mode "web", comme je l'ai déjà dit, l'application est prévue pour être distribuée sur CD... Le pourquoi de l'utilisation de Silverlight est assez simple : les Macs ! Nan, je plaisante, c'est la taille et la durée d'installation de WPF quoi ont orienté le choix vers Silverlight]

Je peux difficilement vous proposer une version plus complète : dans mes archives, je n'ai conservé que celle-là et la finale (qui fait quand même plus de 400Mo avec les documents, les images et les videos !)

Ca se passe ici : Application Silverlight Expo 2007 - Pré-version

Visualiser les commentaires(RSS) ou en Ajouter

Même les erreurs peuvent "avoir de la gueule"

[Ooops, en écrivant un autre article, je me suis rendu compte que ce post était resté dans mon Live Writer et n'avait pas été publié]

Je suis de plus en plus amoureux de WPF... avec un tout petit peu de temps et quelques connaissances en design (je suis pas encore merveilleux dans ce domaine, je l'avoue, mais je m'améliore), on peut facilement transformer des applications ternes en quelques choses d'un peu plus sympatique.

Je viens par exemple de réaliser un outil, pour un client/partenaire, permettant de visualiser les erreurs survenues lors des processus batchs d'une gestion commerciale. Comme toute l'application est en train de migrer vers WPF, c'était l'occasion de faire un peu de présentation. Voila le résultat :

C'est plutôt joli, pour une application de suivi d'erreurs, non ?

Visualiser les commentaires(RSS) ou en Ajouter

Un peu de WPF...

... pour bien commencer terminer le week-end !

Comme déjà présenté WPF (Windows Presentation Foundation) est la nouvelle couche de developpement d'interface graphique de .net 3.0 (et donc pour Windows XP & Vista). L'un des plus gros intérêt de ce nouveau joujou est la séparation entre l'interface graphique / et la logique de présentation. Pour bien me faire comprendre, je vous présenterai un "écran" en cours de réalisation sur l'une de nos applications dans ses différentes phases.

Cet écran permet de rapprocher un compte en banque avec les opérations réalisées dans une gestion commerciale (factures, encaissement, dépots en banques, achats...). Son interface est relativement simple : une liste des opérations, un menu popup, et quelques critères.

Premiere phase : schéma

La premiere phase dans la vie de cet écran, correspond à un simple petit schéma (en l'occurence sous Visio), du look général de celui-ci.

Deuxième phase : développement

Après quelque temps passé dans les limbes de la gestion de projet et du développement, l'écran est enfin prêt, enfin il est terminé du point de vue fonctionnel (la copie d'écran ci-dessous date d'une version antérieure des spécifs...)

Comme vous pouvez le constater, il/elle ne s'est pas foulé(e) pour la présentation...

A la fin de cette phase du developpement, il est fréquent de devoir faire un point avec le développeur sur ce que l'on compte faire de son écran. En effet, il est souvent nécessaire que celui-ci modifie le programme en ajoutant quelques propriétés qui n'ont pas d'autres raisons d'exister que l'interface graphique. (Ici par exemple, j'ai ajouté des booleens permettant de determiner si l'élément est au crédit ou au débit, etc.).

Troisième phase : une premiere "mise en page"

La troisième phase correspond à un premier jet de l'interface, sans grandes frioritures, juste de quoi expliquer au designer ce que l'on attends de lui... Ce premier design est fait en interne de l'équipe de développement, pour pouvoir revenir à la phase précédente si nécessaire (pour les fameuses modifications "cosmétiques"). C'est aussi à partir de ce moment là que l'écran part en béta test : il n'y aura en effet plus de modification de la partie "code" dès lors que ce design rudimentaire est pret.

Quatrième phase : le design complet.

Bon, ben une fois arrivé la, il reste à passer la main à quelqu'un qui va devoir ajouter :

• un look un peu plus sympa
• quelques animations discrètes (fade-in fade-out sur les lignes etc.)

Bon, la je n'ai pas encore le résultat, vu que ce n'est pas encore fait, mais normalement, cela devrait ressembler à ça (c'est tout du moins ce qui a été fait dans Microsoft Expression) :

Voila, si vous comparez la phase N°2 - dont le design est vraiment digne d'un développeur - à ce qui est prévu dans la dernière phase, vous serez certainement étonné de la différence entre les deux. Et pourtant, une fois la phase N°2 terminée, le développeur ne touche plus du tout au code de cet écran (enfin, sauf pour corriger des bugs, evidemment). Toutes les modifications se font au niveau présentation grâce à un langage de présentation à la HTML et même, pour un grand nombre de celles-ci, grâce à une interface graphique de "skinning" digne d'un éditeur CSS (mais en beaucoup plus puissant)

Visualiser les commentaires(RSS) ou en Ajouter

Arrrrggggghh

Il y a des jours où l’on ferait mieux de ne pas se lever. et aujourd’hui semble bien en faire partie.

Avez-vous déjà essayé de vous y retrouver dans un fichier d’import/d’export Sage, à chercher des données en doublons ? Pour les non informaticiens et/ou les non spécialistes en gestion, Sage est un logiciel de compta utilisé pour les sociétés taille assez conséquente.

Je viens de passer plus de quatre heures le nez plongés dans des chiffres et des enregistrements pour repérer des pièces comptables (des factures) qui passaient plusieurs fois en compta. Eh bien,le moins que l’on puisse dire, c’est qu’il y a environ 250 milliards de choses plus fun à faire parmi lesquels «aller chez le dentiste», «partir en vacances avec ses beaux-parents», «sauter à pieds joints dans une moissonneuse-batteuse» et j’en passe.

D’autant plus pénible quand on fini par remarquer que la raison de ces supplices tient en une ligne que vous avez oublié de remettre dans un if et qui ne sert qu’à un cas de test. Comme je le disais en titre :

Aaaarrrrrgggghhhh…

[Update] Enfer et damnation ! Ce n’est même pas ce bout de code qui est en cause, c’est une requête écrite dans l’urgence et sur laquelle j’ai oublié une clause where ! d’où un troisième et justifié :

[Your Wife is a big hippo]

(pour ceux qui ne comprennent pas, je vous invite à lire Interesting Times de Terry Pratchett) 

Visualiser les commentaires(RSS) ou en Ajouter

Nos amis de Techdata

Ca y est, je viens encore de me fâcher avec un fournisseur… Il y avait vraiment longtemps, et ça devient pénible de devoir les supporter par moment.
TechData, pour ne pas les citer, est l'un de mes fournisseurs de "dépannage" lorsque nous avons besoin de (principalement) logiciels et consommables. Et quand je dis "dépannage" comprenez bien qu'il s'agit de montant de commandes vraiment faibles, pour ne pas dire ridicules (300€ par ci, 1000 € par là)
Ce n'est pas la première fois que je refléchis à me passer d'eux et à faire des commandes, comme tout le monde sur des sites comme LDLC.com : au vu de nos besoins et des marges proposées pour les "petits", TechData est CHER (la plupart du temps je reçoit des mails de pubs avec des tarifs plus intéressants quelque jours après mon achat sur www.je-vends-beaucoup-moins-cher-que-n'importe-qui-d'autre.com ou sur www.super-discount-de-la-mort.com, qui a dis que j'étais maudit par la loi de Murphy ?)
Bon, voici l'exposé du problème, pour faire court : il y a de ça quelques mois, nous avions besoin de divers petits articles, donc fidèle à notre habitude : www.techdata.com, mot de passe et blah blah, nous passons ma commande. Un Fax nous confirme la commande et nous sommes contents du prix : grosso modo 350€ TTC. Commande reçu comme à l'habitude dans des délais raisonnables : pour ça rien à redire, mais c'est la même chose chez tous nos fournisseurs.
Quelques jours après nous recevons la facture et là, les choses se corsent : 450 € TTC. Bon 100 € ce n'est pas mortel, mais (calculette en main) mais cela fait quand même une différence de prix de 28%. Ouch… Sur ce, nous décidons de ne payer que le montant originel de 350€ (je vous passe les détails des 5 ou 6 de réclamation fax "perdus" et autre...)
A ce jour, j'ai fini par recevoir un coup de téléphone du service juridique (pas très aimable il faut bien le dire), qui comme c'était prévisible râle et argue du fait que le document qui m'a été envoyé n'est pas un bon de commande, ni meme une confirmation de commande, mais un bout de papier réalisé comme ça et qui n'engage personne, mis à part Dieu en personne peut-être ! C'est un peu fort ! Non seulement la personne contacté ne veut rien savoir mais après à peine quelques secondes me parle déjà de tribunal de commerce en référé pour savoir qui de nous deux à raison…
Belle mentalité commerciale il faut bien le dire. Et d'arguer "ce n'est pas grave si nous perdons votre clientèle, vous savez des clients comme vous…" (je prefère penser qu'il voulait dire "… on en a des dizaines" et que "comme vous" ne voulait pas dire autre chose que "petit", mais j'ai un gros doute !). J'ai finalement préféré lui raccrocher au nez (technique déjà utilisée par une autre personne de TechData lors de mon dernier appel téléphonique).
Enfin, voila encore un endroit ou je ne commanderai plus jamais, même si ils sont (je cite le service juridique) "le plus grand mondial", bon le plus grand quoi je ne sais pas… en tout cas pas "mon plus grand copain", ça c'est sûr.

Visualiser les commentaires(RSS) ou en Ajouter