Il y a quelques semaines, je suis tombé sur un article de sitepoint sur ruby on rails. Je dois dire que j’ai été complètement renversé parce que j’ai vu. Disons qu’en dix années d’expérience c’est la première fois que je vois ce niveau de productivité.

Ruby : Ruby est un langage purement orienté objet. C’est un langage interprété et non pas compilé comme le C++. Il a été créé par le japonais Yukihiro Matsumoto mon premier contact avec le langage a été plutôt froid. Rien ne m’avais impressionné surtout que j’étais dans une phase Microsoft C#.

Rails : Sans Rails, Ruby n’est pas grand chose. Ce qui donne la puissance de Ruby est Rails. Rails est un cadre d’application (Framework en Englais). Il fournit des services de generation de script, de gestion de base de données, de gestion de service Web et bien plus encore que je n’ai pas eu le temps de regarder.

Les mois passe, et je lis l’article de Sitepoint. Je télécharge les trois vidéo sur le site de ruby on rails. Ça été un choc total. L’efficacité de développement, le support complet pour les tests, la possibilité de connecter à de nombreuses bases de données modernes. Vraiment j’étais très impressionné. De plus, il vient avec son propre serveur Web Webrick. Donc pas besoin d’Apache, du moins pour le développement.

Tout développeur Web sérieux devrait jeter un coup d’œil sur Ruby on Rails. Aller voir les vidéos, et penser aux possibilités.

À bientôt

Voici la dernière partie sur les clients. Un client intelligent ou « Smart Client » est une application qui répond aux critères suivants :

• Ressources locales Les applications résident sur votre poste de manière locale. Elles utilisent votre mémoire et unité centrale (CPU) pour fonctionner. À la différence de clients légers qui effectuent la majorité de leur travail par le serveur distant.
• Connecter Les applications intelligentes sont connectés entre elles soient par un serveur, soit directement.
• Fonctionne de manière déconnecter Ces applications peuvent très bien être exécutées de manière déconnectée. Bien qu’elles auront des fonctionnalités réduites l’application aura un fonctionnement normal.
• Facile de déploiement Les applications intelligentes connaissent leurs besoins en librairie et resource externe. Elles pourront alors récupérer de manière automatique les modules quelles auront besoin.

Source Microsoft Smart Client

Disons que je ne sais pas ce qui m’a pris de parler des types de clients d’application. Je ne sais pas, un sujet comme ça qui m’inspirait. Je trouve important de partager des concepts d’architecture. Vous serez en mesure de proposer de meilleures solutions à vos clients. Donc on continue.

Les clients légers. C’est bien ils sont le contraires des clients lourds, mais qu’est-ce exactement? Et bien le fureteur que vous utilisez présentement est le parfait exemple de clients légers. Votre fureteur est léger dans le sens que l’expérience n’est pas aussi complète qu’avec une application client lourds. Par exemple, le glisser-déposer n’est pas natif. Il doit être laborieusement programmé par un script en Java ou Visual Basic. Outre les cookies, le client léger n’a généralement pas accès aux fichiers de votre disque. Votre utilisation du processeur est de plus moins importante, le gros du travail étant fait sur le serveur. L’installation d’une application en client léger est généralement plus simple. Encore une fois, le gros du travail est fait sur le côté server.

Le client léger est-ce bon ou mauvais? Je dirais que vous devez regarder les besoins de votre client. En contrepartie, il y a de formidables innovations dans le domaine du Web. Les possibilités de développement d’application serveur Web sont de plus en plus facile.

Suite et fin très bientôt avec les clients intelligents.

Non un client lourd n'est pas un client qui ne paie pas ou qui nous appelle sans arrêt. Dans le langage informatique, c’est une application qui réside entièrement sur le poste de travail. En Anglais on utilisera la définition « Thick Clients » et non pas « Fat Client ». Une application de ce genre, aura un environnement de travail riche, une réponse aux actions plus fluide comme le glisser-déposer. (Drag-and-Drop voir le blogue d’hier). En contreparties, l’application sera plus grosse à déployer et n’est générallement pas prévue pour être mise en réseaux.

Donc est-ce qu’une application client lourd est une mauvaise application ? Je crois qu’il faut regarder quel sont les besoins des utilisateurs. Une application client lourd bien faites sera certainment très agréable à utiliser. Si elle remplie les besoins des utilisateurs correctement pourquoi pas.

Je vous laisse aujourd’hui avec une image de Microsoft sur les diverses clients. Au cour des prochaines journées j’aborderais les autres types de client possible. Oui je sais Microsoft ne sont pas très code source libre, mais je trouve qu’il ont la meilleur représentation des divers type de client.

Bonne journée.

Dans cet univers informatique anglophone, il est très difficile de passer un message en français. Le Web et l’Internet prennent des lettres majuscules comme des noms propres. On parlera donc de portail Web et de fournisseur de service Internet.

La Société M2i3 étant situé en banlieue de Montréal au Québec, nous sommes normalement exposé à une culture bilingue. Lorsque nous parlons du domaine de l’informatique, nous parlons même plus d’une culture anglophone. Dès le début de la Société, nous avons décidé mon associé et moi-même de faire la promotion de notre entreprise en Français. Disons que c’est un défi de taille. Il n’est pas évident de traduire toutes les expressions fortement anglophones. D’un autre point de vu, est-ce que si nous utilisons les mots francophones corrects, seront nous compris des clients?

À ce jour, je dois dire que nous somme heureux de nos visiteurs. La plupart viennent du Québec ou de la France. Je vous recommande l’excellent site de l’Office québécois de la langue française. À ne pas manquer, le grand dictionnaire terminologique. J’ignore si les traductions sont applicables à la France, mais je n’ai pas trouvé de site équivalent chez nos cousins. Si vous connaissez un site comparable pour la France, n’hésitez pas à vous exprimer en ajoutant un commentaire.

N’empêche que quelques fois, les traductions sont un peu loufoques. Traduire « marketing » de l’anglais à « mercatique » en français. Je ne sais pas pour vous, mais pour moi il y a quelque chose qui cloche.

Bonne journée.

En poursuivant notre lancé dans les méthodologies Agile, j’aborderai aujourd’hui un texte sur les clients Agile.

Pour le succès d’un projet Agile, le client à une part importante à jouer. Je crois qu’il faut mettre derrière soi, le principe de système clé en main. Ceci montre un désintérêt complet du client envers le fournisseur de solutions. Comment est-il possible de produire une solution logicielle de plusieurs mois sans avoir de commentaire du client, sans consultation. Le client doit être responsable.

Responsable est un bien grand mot. Oui en effet le client doit être responsable. C'est-à-dire qu’il est responsable du projet. Il doit communiquer ses attentes et prioriser les fonctionnalités qui lui sont importantes. Lorsqu’une itération lui est livrée, il se doit de fournir des commentaires. Il doit libérer les ressources qui communiqueront avec les développeurs. Et en dernier point, il doit payer correctement les itérations lorsqu’elles seront livrées. Ce point est toujours sensible, les bons comptes font les bons amis.

C’est tout pour aujourd’hui. N’hésitez pas à écrire vos commentaires.

Joomla est un système de Portail Web ou en anglais Content Management System (CMS). Je dois avouer que j’adore ce logiciel. L’architecture est très bien faite. Je reviens sur le détail d’architecture dans quelques lignes.

Joomla est un branchement de Mambo. De l’information que j’ai recueillie, ceci est survenu suite à une dispute sur la propriété intellectuelle de Mambo. « Liser la nouvelle ici sur C-Net » Pourquoi Joomla au lieu de Mambo. Un peu par hasard je dois avouer. Je dois dire que l’évaluation de portail Web sur OpensourceCMS m’a confirmé que mon choix était bon. La note est meilleure que Mambo.

Revenons à l’architecture de Joomla. Pour moi, c’est très bien fait. Tout est dirigé par module. Que se soit, les menus, les contenus, l'administration ou les sondages, chaques fonctionnalité est un module. Le module est reponsable de le contenu HTML sur la pages. Les modules peuvent être assignés à des pages précises. Les modules sont assignés à une zone.
Écran d'administration des modules

De l'autre coté nous avons un script PHP qui contient quelle zones sont chargées. Votre site peut être aussi simple que de simplement chargé toutes les zones les une après les autres.
templates/demotemplate/index.php (extrait)

<div id="newsflash"><?php mosLoadModules ( 'top',-1); ?></div>
<div id="leftpanel"><?php mosLoadModules ( 'left',-3); ?></div>
<div id="topmenu"><?php mosLoadModules ( 'user3',-1); ?></div>
<div id="mainbody"><?php mosMainBody(); ?></div>
<div id="footer"><?php include_once( $mosConfig_absolute_path .'/includes/footer.php'); ?>
</div><?php //mosLoadModules ( 'right',-3); ?></div>

C'est laid mais le site est fonctionnel. Comme on vois ci-haut, nous chargeons la zone top, left, user3, mainbody, footer et right.
Certain module sont un peu spécial comme mainbody et footer. Ils sont chargés autrement.

Remarquez les DIV. Maintenant avec la puissance des feuilles de style en cascade (CSS) nous pourrons mettre les modules en forme et en utilisant de belles polices de caractères.

templates/demotemplate/css/layout.css (extrait)

#mainbody {
position: relative;
top: -858px;
left: 280px;
width: 430px;
height: 288px;
overflow: auto;
}


#leftpanel {
position: relative;
top: -618px;
left: 90px;
width: 179px;
height: 289px;
}


L’autre aspect très intéressant est qu’au contraire de Drupal, Joomla est plus facile d’utilisation pour les non-techies. Un utilisateur Internet normal ne devrait pas avoir de problème à faire des ajouts ou modifications de contenu après un peu de pratique.

Bon ceci conclu le blogue de la journée. C’est peut-être un peu abrupte, mais si le désire se manifeste, il me fera plaisir de complémenter le tout avec d’autre article.

Bonne journée.

Le développement du Logiciel est en train de se chercher. Au cours de mes années d’expérience en logiciel, il y a de nombreuses histoires d’horreur. Des logiciels livrés en retard, en dépassement de budget ou de mauvaise qualité sont des récits communs en informatique. En réaction à ces problèmes l’industrie commença à mettre de plus en plus de contrôle. On tombe alors dans un cycle de spécifications fonctionnelles et de gestion de projet. J’ai participé moi-même à ce cycle. Croyant fermement que plusieurs centaines de pages de document et un plan de projet solide et suivi était la solution aux problèmes en informatique. J’ai regardé plusieurs fois pour recevoir des formations de PMP (Project Manager Professional) ou bien de CMM (Capability Maturity Model). Bien que je dénie aucune l’effort et le sérieux d’une personne ayant suivit les cours et certifications ci haut, il n’y avait que peu d’amélioration dans les résultats que j’obtenais dans mes projets.

Lorsque je fus introduit aux méthodologies Agile par un consultant que je côtoyais, je fus conquis rapidement. Bien sur, des discussions animées se dégagent. On ne change pas de méthodologie suite à une seule discussion. La conversion s’est faite après plusieurs rencontres et discussions. Cette méthode est très bien adaptée aux styles de projets de je dirigeais. Le cahier de charge prend une réduction de grosseur en faveur de tableau blanc et de post it. L’approche est devenue plus humaine et plus communicative avec le client. La méthode est plus réactive et demande moins d’énergie pour la gestion. Il y a de nombreuses adaptations des méthodes Agile. Scrum et XP en sont quelques-unes. Elles sont plus ou moins contraignantes à implémenter en entreprise. Peut importe, quel soit formelle ou pas, une ouverture vers une réduction des documents inutiles, une coopération avec le client, la réaction positive aux changements et l’interaction personnelles vous amènera un meilleur succès dans votre développement logiciel.

Bonne journée.

Cette citation m'est venue d’un mélange d’Agile et d’une lecture de Brendon Sinclair. Je ne l’ai vu nulle part ailleurs, et j’espère que je ne plagie personne. Une courte recherche sur Google montre quelques exemples, mais aucun n’aborde l’aspect que je veux présenter. Alors du moins pour l’instant je m’approprierais la propriété.

Quand on fait du développement Agile, on essaie de faire le minimum de travail. Retarder au maximum l’estimation, la réalisation et la livraison de fonctionnalité. Ceci ne veut pas dire qu’on ne travaille pas, mais juste qu’on travaille seulement sur les éléments importants du projet. En développement Agile, nous sommes en présence de livraison itérative. Donc, le produit n’est pas fini, mais il est fonctionnel. Comme parfait exemple, le site que vous consultez actuellement. Il est fonctionnel, mais à l’heure actuelle, il manque l’inscription des usagers pour faire des commentaires, il manque des éléments graphiques comme des effets de survol sur les boutons. À tout les jours, j’essaie de faire au moins un blogue, puis j’ajoute un éléments ou deux pour rendre le site de plus en plus désirable. Donc lors du lancement du site, il était « good enough ».

Brendon Sinclair est un spécialiste du Web en Australie. Il a conçu des centaines de sites, donc certaine d’entre eux ont plus de 5000$ Australien en vente par jour. Il est bien informé sur le marketing Internet et mérite d’être écouté. Lors d’une lecture du livre The Web Design Business Kit Brendon souleve le point suivant. Il demande à un client sa note de satisfaction sur 10. Celui-ci est satisfait, mais donne Brendon un 9. La réplique est immédiate. Brendon : Que dois-je faire pour avoir un 10. Le client réfléchit et donne certaines indications. Brendon part et fait les corrections pour le client jusqu'à ce qu’il soit totalement satisfait. L’histoire ne dit pas si le client à été facturé cet effort supplémentaire.

De mon coté maintenant, comment concilié deux philosophies, si loin l’une de l’autre. D’un coté un méthodologie qui fait appel à l’humain et au bon sens, de l’autre une obsession de perfection. Si on développe « Just good enough » peut-on avoir 10/10 comme cote de satisfaction du client. Moi je crois que oui. Si on donne les fonctionnalités que le client veut dans les priorités qu’il a décidé avec qualité. Un produits qui partira simple, prendra une grande valeur avec le travail.

Responding to change over following a plan
Répondre aux changements prime sur la planification.

C’est cette dernière remarque qui donne la force aux méthodologies Agile. Le pouvoir de changement. En affaire, bien des changements surviennent. Une acquisition, une nouvelle idée ou un commentaire sont tous des raisons de vouloir changer la direction d’un projet informatique.

Avec une approche de gestion classique, une fois le carnet de charge signé. Toutes demandes de changement seront fracturables. De plus les fonctionnalités qui ne sont plus nécessaire seront livrées quand même. Ceci à mon avis est un non-sens. Un client sera d’autant plus ravi de recevoir les fonctionnalités qui sont vraiment importantes et utiles pour lui. Le pouvoir de s’adapter le rendra plus compétitif grâce à votre travail.

Le pouvoir de cette méthode est de ne livré que ce qui est vraiment important et utile. Bien sur, le client pourra se retirer avant le temps prévu du projet, mais en proposant des arrangements d’affaire vous pourrez vous en tirer avec un léger bonus. Je vous suggère de regarder le document de Mary Poppendieck sur les contrats Agile une formulation PS 2000 ou partage de profit peut être très avantageux pour les deux parties.

Bonne journée.