Tag Archives: outil

Gliffy

(pour une raison qui m’échape l’image s’affiche déformée dans wordpress, faire view image pour voir une bonne qualité)

Petit schéma réalisé en 2 minutes avec Gliffy qui est à Visio ce que Writely est à Word.
Bon évident ça ne remplace pas Visio pour faire un schéma d’architecture un peu complexe mais ça peut être très utile pour un brainstorming collaboratif à distance.

Au fait j’utilise depuis quelques temps Draw (OOo 2) à place de Visio et ça se passe plutôt bien. Par contre je reste frustré quand j’utilise Writer à la place de Word. Tout particulièrement à cause de l’absence de mode plan, la fenêtre navigator de Writer ne m’a pas convaincu.

Débugguer des web services

Grâce ou à cause de la SOAmania du moment on croise de plus en plus de web services sur les projets. Et quand il s’agit de débugger plusieurs appels successifs de web services c’est pas toujours simple.

Heureusement les petits gars d’Axis ont prévu le coup.
Le jar d’axis contient un programme qui répond au dou nom de tcpMon
pour le lancer cette ligne de commande suffit:
java -cp axis.jar org.apache.axis.utils.tcpmon

tunnel.gif En fait c’est un simple proxy/tunnel http qui se met entre le client et le serveur. Il permet de voir les requêtes qui passe, de les modifier et de les rejouer. Simple et efficace. Pour en savoir plus Using the Axis TCP Monitor TcpMon.

Si vous avez besoin d’un outil un peu moins rustique et que vous etes prêt à dépenser la somme de 99$ Mindreef SOAPscope devrait vous combler. Parmi les fonctionalités en plus par rapport à tcpMon on retiendra:
– Gestion du WSDL
– Enregistrement et partage de scénario de test ou de bug
– Sait sniffer le réseau pour récupérer les messages SOAP (évite d’avoir à se positionner en proxy)
– Fournit des stats sur les temps de réponse

J’ai trouvé mon outil UML idéal

screenshotUMLet.gifJe suis un grand fan de l’utilisation d’UML en tan que croquis.
Le meilleur outil pour cette utilisation est sans doute le paper board ou le bon vieux papier + crayon. Malgrès tout on fini toujours par avoir besoin de passer tout cela au format électronique et c’est là que ça se gâte. La pluspart des outils sont conçus pour utiliser UML en tan que plan, ils sont compliqués et regorgent de fonctions qui me sont totalement inutiles (round trip engineering , apply pattern…). Bref, après être passé par Structure Builder, Objecteering, Together, Rose, XDE, Visual paragdim for UML, Poseidon, Omondo… J’ai toujours été frustré et trouvé que le temps d’apprentissage pour être productif avec ces outils était trop long. Je précise une nouvelle fois: ces critiques portent sur une utilisation d’UML en tan que croquis.

Mais ma quête du Graal est finie!! J’ai enfin trouvé mon outil UML de rêve : il est conçu pour faire la seule chose qui m’intéresse: des croquis UML de manière simple et rapide. Il m’a fallu 10 min pour savoir m’en servir et 5 de plus pour faire mon premier diagramme d’une dizaine de classes.
Pour ne rien gâcher:

– C’est un programme open source en java.
– Il permet d’exporter ses diagramme dans de nombreux format.
– L’interface est simple et sans pop-up!
– Il fonctionne en standalone où comme plugin eclipse.
– Il est extensible très facilement.
– Il supporte les principaux types de diagramme UML.

Je vous fait pas patienter plus longtemps. Courrez essayer UMLet.

J’ai encore succombé à google..

Suite à la lecture du retour d’expérience de Laurent Simon sur google reader. J’ai donné une seconde chance à l’aggrégateur de news de google. Et me voici encore un peu plus dépendant de google… Je n’utilise plus Bloglines mais Google Reader.

Pour 2 raisons:
– Google reader classe les billets par pertinence. Je ne sais pas comment il s’y prend (pageRank??) mais ça à l’air de fonctionner relativement bien.
– Google reader est beaucoup plus rapide que bloglines. Au final je me suis rendu compte que je passais beaucoup moins de temps à lire mes news avec google reader qu’avec bloglines. Vive l’Ajax!!

Je n’ai plus de vision globale sur le nombre de news qu’il me reste à lire mais comment je vais plus vite pour lire/scanner les nouveaux billets ce n’est pas grave.

Attention toutefois google reader est vraiment en béta: il n’est pas rare qu’il me présente plusieurs fois un billet déjà lu, on peut tagger les billets super! Mais ensuite impossible de se servir de ces tags pour retrouver un billet??

Conclusion: Il est vraiment temps que bloglines passe un bon coup d’ajax sur son application, ce n’est pas les raccourcis clavier qui vont suffire.

DNG 2005: Outiller et industrialiser ses développements

Intervenants : Eric Groise et Jean-Louis Bénard

Avec en toile de fond la présentation de Visual Studio Team System Eric et Jean-Louis nous ont présenté le concept d’usine de dev.
Importance du concept d’intégration continue (avec une présentation de cruise control qui existe aussi bien pour java que .net) qui repose sur le build automatique et sur des référentiels de code source, d’artifact de documentation… Ces outils sont essentiels pour réussir des développements “agile” ou tirer pleinement parti d’une démarche itérative est impossible sans build automatique.
Il est important que l’usine de dev couvre l’ensemble du cycle de vie du projet depuis le recueil des besoin jusqu’à la recette (c’est ce que propose VSTS)
Concernant les outils java est en avance sur .net notamment grâce à maven qui vient de sortir en version 2.0.

Dans la démo de VSTS la présentation des diagrammes applicatifs m’a bien impressionné. Ces diagrammes sont une sorte de visio “on stéroid” dédié à l’architecture. Ils permettent de décrire l’architecture logique (les composants logiciels) puis l’architecture technique (les machines) de définir des contraintes (protocole, sécurité, bande passante…) d’indiquer la manière dont on déploie les composants logiciels sur l’architecture technique et de valider que toutes les contraintes sont bien respecté. Le tout avec du drag & drop et une interface graphique très agréable.

Pour conclure les speakers ont insisté sur l’importance des test unitaires et donc d’une architecture testable. Il n’existe pas de formule magique pour calculer le ROI des tests mais il n’y a pas à se poser la question il faut les faire on ne le regrettera pas.

Si vous n’avez pas encore mis en place d’usine de développement il faut s’y mettre.