A côté de ça, Twitter ne m’ayant jamais attiré, et Facebook pas convaincu plus que ça, j’ai décidé de tester Google, et … j’ai succombé.

Vous pouvez donc me suivre sur G+ ici : http://www.gplus.to/bill2

Si vous m’ajoutez dans vos cercles, merci de me laisser un commentaire ici même, que je puisse en faire autant, et créer un cercle « BPM »

Pour tout dire, j’avais attaqué le travail en janvier 2011, avant de laisser tomber.
A cette date, j’avais décidé de fusionner la fenêtre principale et la fenêtre de Perfs/Stats. J’avais obtenu un bon début : une fenêtre avec les fonctions de bases (listing processus, et affichage des graphiques CPU/mémoire). Par contre, tout ce qui était lié au clic droit était désactivé. Bref, fonctionnalités minimales.

Pour la suite, et avant d’aller plus loin, je vais avoir un énorme travail de fond à effectuer, et il me faudra plusieurs versions alphas pour parvenir à mes fins.
Pour les différentes versions Beta, c’est l’interface qui subira le plus de changements.

Pour la version alpha 1, différentes choses : passage à Visual Studio 2010 et au framework 4.0 (que je compte exploiter plus tard), et refonte du système d’enregistrement des options et des règles, en deux fichiers séparés.

Pour la version alpha 2, c’est le cœur du système que je compte revoir : gestion des processus « en interne », système de détection des nouveaux processus, meilleure prise en compte des fins de processus, etc.

Pour l’alpha 3, je vais m’attaquer à la gestion « en interne » des règles, avec pour objectif de gagner un peu en utilisation mémoire.

La suite du développement n’est pas encore planifiée très finement

Alors, où en suis-je là dedans ? A l’heure actuelle, j’ai « terminé » la version alpha 1, et je suis en plein dans l’alpha 2. Et ça va être un très gros chantier.
D’ailleurs, je compte avant tout travailler sur la structure interne, et je pense que ce cœur du système sera sans doute revu et traité aux petits oignons lors du développement des Betas.

Bref. Avec les alphas, je vais toucher les grandes fondations du programme, et avec les betas, je peaufinerai les détails.

Une date de sortie pour une beta publique ? Pas encore. Et je ne sais même pas si j’en ferais une. Il va y avoir tellement de changements au niveau interface entre les différentes betas, que les offrir en test n’a pas vraiment de sens. Ou alors, je ne proposerais que la dernière beta, voir même une RC … je verrais ça plus tard, si les utilisateurs sont motivés pour tester la chose …

Allez, sortez le popcorn, et marrez-vous un bon coup, ça fait du bien !

http://ploum.net/post/ploum-en-j2ee

Mon CDD se terminant début février 2011, je suis passé du mode « passif » au mode actif, avec inscription sur viadeo et CV en ligne sur DoYouBuzz.

Je dois avouer qu’il n’est pas évident pour moi de trouver un poste sur Dijon, alors si mon profil vous intéresse, n’hésitez pas à me contacter.

Enfin bon, c’est les vacances
Et je sais pas vous, mais moi, l’histoire des easter-eggs sur dailymotion et youtube, ça m’a bien amusé !

Depuis cette date, j’ai reçu des rapports de crash similaires pour ce bug, bien que beaucoup moins nombreux. Mais le bug était visiblement toujours là.
Et pire encore, j’ai eu un contact chez qui le programme crashait à chaque changement de langue, sous Windows 7. 

J’ai donc décidé de retourner voir ce qui pouvait poser problème.
Mais ce bug est corriace : il ne se produit pas à chaque fois sous mon XP, et le debugguer de Visual Studio ne se positionne pas sur la ligne qui pose problème, car visiblement, c’est un plantage plus en interne, directement dans une des DLL  de .Net. 

A force de tatonnement, j’ai fini par mettre en cause différentes choses.
D’une part, le programme ne plante pas lorsqu’on le quitte simplement. Il ne plante que lorsqu’il rencontre la commande Application.Restart()
Donc j’ai déjà remplacé cette commande par un simple Process.Start(), avec le chemin de process manager en argument.
J’ai encore eu des crash, mais beaucoup moins nombreux. Et à chaque fois, j’ai l’impression que BPM a tenté d’accéder à un élément qui ne devait plus exister.

D’autre part, le crash ne se produisant que lorsque la fenêtre d’option est ouverte, j’ai donc cherché ce qu’elle avait de différent par rapport aux autres fenêtres du programme.

La seule chose, c’est la combobox de sélection de la langue.
Quand la valeur sélectionnée change, BPM exécute un code pour sauvegarder et redémarrer la langue.
Et donc forcément, quand on ferme cette fenêtre, la valeur sélectionnée change, que que la combobox « se vide ».
Mais dans le cas d’un redémarrage de l’application, il semblerait qu’il arrivait parfois que la fermeture relance l’exécution de ce même code, qui plantait, vu que la fenêtre était en cours de fermeture, et que certains éléments n’étaient déjà plus accessibles. En gros, y’avait une boucle d’exécution de code, qui au bout d’un moment finissait par planter en tentant d’accéder à des éléments qui n’étaient plus présents en mémoire.
J’ai donc retiré à la volée la gestion de l’évènement « change » sur la comboxbox lors du premier passage, avant de demander la fermeture et le restart de l’application.

Pour le moment, je n’ai pas réussi à provoquer à nouveau le bug, donc j’espère l’avoir enfin éradiqué !

En effet, je compte publier assez rapidement une nouvelle version. Mineure, mais avec tout de même une petite amélioration : la possibilité, dans les actions spéciales, de ne pas exécuter les programmes déjà lancés.

Pourquoi cette fonction ? Et bien, tout simplement parce que lors de mes séances de débug, j’en avais marre de me retrouver avec mon programme de messagerie ouvert en X exemplaires. Hé oui, mon BPM est configuré pour lancer Outlook et d’autres programmes lorsque BPM démarre.

Cette règle me permet un démarrage « échelonné », avec un timer entre chaque lancement. Pratique sur mon vieil Athlon XP qui est déjà assez à la ramasse …
Et donc maintenant, grâce à une toute petite option, mes programmes ne démarrent plus si ils sont déjà lancés.

Tout ça devrait arriver … ce Week-end ou en début de semaine prochaine, si tout va bien.

Je sais, je n’ai pas donné de nouvelles depuis … trop longtemps !

En fait, Bill2’s Process Manager n’a pas énormément évolué ces deux derniers mois : pas de grosse version en vue.
Mais comme j’ai reçu différents rapports de crash, il va tout de même y avoir une mise à jour mineure d’ici quelques jours.

Bien entendu, j’ai dans l’idée de commencer à travailler sur une version 3.5 mais … avant ça, j’aimerai d’abord changer (enfin !) mon vieux PC.
Comme je l’ai déjà dit, BPM est développé sur un Athlon XP2400+, sous XP SP3.
Oui, c’est un peu la lose de bosser sur un programme spécifique au multicoeur, alors que mon PC est monocoeur !
Bon, je peux tout de même le tester sur le C2D sous Vista de ma femme, mais bon … ce n’est pas très pratique de changer de PC à chaque recompilation pour tester le résultat sur l’ordi d’à côté !

Je ne sais vraiment pas quand j’aurai ce nouveau PC. Ca dépendra des finances, et aussi des dons que je recois. D’ailleurs, je remercie chaleureusement les donateurs au passage.

En conclusion, ne vous attendez pas à voir évoluer BPM en 2010 de façon aussi importante que les autres années.
Mais le développement continue, et je reste toujours à disposition sur le forum pour vous dépanner !

L’aspect le plus travaillé sur cette version a été la gestion de la mémoire, et la correction de fuites mémoire.
Avant de publier la mise à jour, j’ai surtout cherché à ce que l’application des règles se fasse toujours correctement.

Seulement voilà, entre la version « debug », la version « release », la version que j’utilise « en réel » sur mon poste, et le fait que j’ai aussi des copies qui tournent en mode « portable », je n’ai pas poussé les tests assez loin.
Là dessus est venu se greffer le bug dû au fichier Updater.xml … là aussi j’en ai des copies un peu partout. Ce qui fait que mes tests n’ont provoqué aucun crash … et pour cause, je n’ai pas tenté de clean install, avec suppression de toute information dans le répertoire utilisateur.

Bref. sur ce coup là, j’ai vraiment merdé ! Et je sais que la v3.4.1.1 comporte d’autres bugs du même genre … il suffit de vouloir créer une règle sans passer par un clic droit dans la fenêtre des processus : on a une fenêtre qui s’ouvre pour explorer l’ordi, et si on clique sur « Annuler », on un crash direct !

Je vais donc bosser plus sérieusement sur la v3.4.1.2. Pour cette version, mon objectif sera un test complet de tout le programme : fenêtre par fenêtre, toutes les fonctions seront passées au crible, avec validation et annulation, pour vérifier le comportement global.
Après la phase d’optimisation (v3.4.1), voici la phase des tests poussés.
Ces tests avaient été réalisés pour la v3.4, et j’aurai du les refaire pour la v3.4.1, vu les changements interne apportés.

Je bosse dessus, et je vous remercie pour la confiance pour que vous continuez à m’apporter.
Encore toutes mes excuses pour cette sortie un peu trop précipitée.

UAC et installeur
Sous Vista (et Windows 7), si on veut installer un programme dans Program Files, il faut le faire en tant qu’administrateur. C’est pourquoi mon installeur déclanche l’UAC.
Ainsi, le programme peut s’installer là où l’utilisateur le souhaite. Là où ça se complique, c’est qu’une fois installé, si l’utilisateur choisi de lancer directement le programme, il le démarre avec les même droits que l’installeur : en mode admin. Et donc la configuration est sauvegardée dans le répertoire Admin, et pas dans celui de l’utilisateur courant.
C’est pour ça que depuis la v1.2.1 de l’installeur, Bill2’s Process Manager n’est plus lancé automatiquement : ça force l’utilisateur à passer par son menu démarrer, et à lancer le programme avec ses droits utilisateur.
Mais il y a aussi un effet de bord que je n’avais pas prévu …

Mise à jour du fichier des « Exceptions »
Bill2’s Process Manager utilise différentes listes d’exceptions, pour la fonction de Priorité Automatique, pour l’assistant de création de règle, et depuis la v3.4, pour la fonction de « Règle par défaut ».
J’avais donc mis au point un système pour mettre à jour ces listes lors de l’installation d’un nouvelle version. Un fichier Updater.xml était copié sur l’ordi, et au chargement de Bill2’s Process Manager, les nouvelles infos étaient fusionnées avec les paramètres de l’utilisateur.

Sauf que … vu que l’installeur tournait en mode Admin, le fichier Updater.xml était copié dans le répertoire de l’admin, et non dans celui de l’utilisateur courant.
Résultat, vu qu’ensuite l’utilisateur lançait le programme « en son nom », la mise à jour n’était jamais intégrée, vu que le fichier Updater.xml n’était pas dans le répertoire de l’utilisateur.
Vous allez me dire : pourquoi copier se fichier dans le répertoire utilisateur, et pas dans le répertoire d’installation ? Et bien tout simplement parce que ce fichier est supprimé après intégration, et que par défaut, l’utilisateur courant n’a pas le droit de supprimer un fichier dans Program Files …

La solution que je vais mettre en oeuvre
L’installeur v1.3, sur lequel je suis en train de travailler, déposera le fichier Updater.xml dans le même répertoire que l’exécutable, vu qu’il n’a pas accès au répertoire de l’utilisateur courant.
Ensuite, lors de l’initialisation, Bill2’s Process Manager vérifiera un paramètre dans le fichier de config, et intègrera les nouvelles données si besoin est.
Ce nouveau paramètre, intégré avec la v3.4.1, sera tout simplement basé sur la version du programme.

Si j’ajoute cette vérification, c’est tout simplement pour que chaque utilisateur de l’ordinateur puisse avoir accès à la mise à jour.
En effet, les versions 3.3 et 3.4 supprimaient le fichier Updater.xml après intégration.
Si on supprime le fichier qui se trouve dans le répertoire de l’exécutable, alors seul le premier utilisateur qui lancera le programme bénificiera de la mise à jour …
Donc la v3.4.1 ne supprimera plus le fichier, mais conservera en mémoire le numéro de la dernière version ayant fait un update.