Friday, 23. October 2009, 10:09:29
logiciel libre en entreprise
Et hop… Bon cela faisait longtemps que je n’avais pas écrit un article. Et peut-être celui-ci est-il décousu du reste, mais bon. Faut bien se refaire non ?
Et si nous faisions un point sur les logiciels libres que j’ai découvert (ou qu’on m’a fait découvrir) ? (Je rajoute que j’ai ressortis pour l’occasion un logiciel non libre mais gratuit: Windows Live Writer)
Et tout cela en quelques semaines. On peut faire mieux mais c’est plus cher.
Pourquoi une telle présentation alors que je ne fais cela qu’une fois par année ? Car j’ai lancé hier un troll sur Twitter… Les réactions n’ont pas trainé, mais c’était aussi pour dire que je n’étais pas passé du coté obscure de la force (et non je n’ai rien contre le logiciels propriétaires, ils sont excellent aussi…).
D’avis je pense que la récalcitrante n’est pas au niveau de la DSI, mais bien de l’utilisateur sur le changement. Tout le monde s’oppose au changement. Dommage, mais n’est-il pas “mieux” d’avoir des utilisateurs contents qu’un DSI heureux ? (le résumé de la réaction au troll)
Bien entendu j’aurais pu réaliser d’emblée un autre troll, mais je me suis retenu: “pourquoi les standards ne seront jamais en entreprise” (ou du moins majoritairement) ?
Saturday, 3. October 2009, 05:54:13
pc soft, dll, Windows, logiciel libre
...
J’ai pu suivre récemment une formation d’un
AGL (dénommé
Windev pour ceux qui n’étaient pas au courant

) et aussi la manière d’utilisation d’un
framework par une application.
En règle générale il y a 3 méthodes d’utilisation :
L’extériorisation : l’application dispose de son framework à coté d’elle et pointe directement dessus et c’est le cas pour chaque application qui dispose de son propre framework. L’avantage est que nous pouvons personnaliser le framework pour l’application en soi, l’alléger ou l’alourdir pour l’application etc. etc. Le désavantage est la multiplication de celui-ci et la maintenance de ceux-ci (au vu qu’ils sont différents). La maintenance peut être pourvue d’une documentation afin de faciliter tant l’utilisation que la fonctionnalité…
La centralisation : toutes les applications utilise un même framework qui se trouve à un endroit sur un serveur, toutes le contenu s’y trouve et chaque application l’attaque. Peu importe qu’il utilise le composant, la
DLL, ou autre… Tout s’y trouve.
La maintenance s’en retrouve facilitée mais le développement pur et dur est quant à lui plus complexe. Nous devons bien entendu nous assurer que le framework est compatible toutes version descendante tout en le mettant à jour régulièrement avec de nouvelles entrées et composants.
L’
encapsulation : le framework est dans l’application et au moment d’ouvrir l’application, celui-ci est décompressé dans un endroit temporaire du disque dur. Cela sous-entend bien sur que l’application à droit d’écriture etc. L’inconvénient est les droits applicatifs, la maintenance d’évolution (il faut mettre à jour tout d’une traite) et bien entendu le poids !
Quelle est la méthode idéale pour bien faire ? Chacune ont leurs avantages comme leurs désagréments !
Je pense d’une manière générale que s’il s’agit d’une application interne le framework extériorisé dans le répertoire application est le plus simple, s’il s’agit d’un groupe d’application à faible potentiel évolutif et utilisant une même base de programmation la centralisation est le plus simple (toujours dans le cas d’une application d’entreprise) ; dans le cas d’une application livrée à un client, l’encapsulation peut facilement se montrer la solution de facilité, tout en ayant précisé les dépendances bien sûr !
Mais faut-il absolument utiliser un framework ? C’est la question qu’il faut se poser aussi… Principalement que ceux-ci sont propriétaires (Microsoft, PC Soft, etc.) (bien que de nombreux repose aussi sur des technologies libres). N’est-ce pas se restreindre ou se limiter dans la fonctionnalité ?
Pour répondre facilement : le cas où le framework est distribuable librement et utilisable de cette même manière je dirais oui, l’utilisation n’est pas bloquante… Mais que faire si on n’est pas le propre mainteneur du dit framework ?