Les fluctuations du dollar et de l'euro ne concernent pas que les spéculateurs, les grands groupes industriels et les touristes.
Même les petites structures comme la nôtre doivent garder un oeil rivé sur ces courbes.
Les prix de nos produits étant indiqués dans les logiciels eux-mêmes ou dans la documentation qui les accompagne, il nous est assez difficile de faire varier nos tarifs fréquemment.
Nous ne pouvons pas dire à quelqu'un qui édite un bon de commande et nous envoie son règlement : "désolé, vous avez téléchargé le programme avant-hier, mais le prix de la licence a augmenté hier", d'autant plus que des dizaines de sites, sur Internet, présentent notre logiciel, avec le prix mentionné à côté, impossible à modifier rapidement.
C'est pourquoi nos prix ne varient que très rarement. Nous avions également décidé d'appliquer une parité euro - dollar. Un produit vendu 1 euro à un client européen était vendu 1 dollar à quelqu'un en dehors de l'europe.
Avec l'euro légèrement plus fort que le dollar, ce n'était pas du favoritisme, mais simplement la prise en compte de l'absence de TVA sur des ventes hors Europe.
En effet, avec un euro aux alentours d'1,20 dollar, une vente, où qu'elle soit, revenait à peu près au même pour nous :
En Europe, nous touchions 1 euro TTC, donc aux alentours de 84 centimes d'euro hors taxe, et hors Europe, nous touchions 1 dollar HT, soit aux alentours de 84 centimes d'euros également.
Bien sûr, il pouvait y avoir de petites fluctuations. D'août 2003 à juin 2007, le cours a varié entre 1,18 et 1,35 dollars pour un euro (voir ici). Nous pouvions nous en accomoder dans l'ensemble, la différence restant raisonnable.
Mais, lentement mais sûrement, le dollar descend (ou est-ce l'euro qui monte ?). Le cours a atteint aujourd'hui 1,52 dollars pour un euro. Les achats en dollars américains commencent à être de moins en moins rentables pour les européens que nous sommes, et cela revient pour nous à accorder contre notre gré une remise de 30% sur tout notre catalogue. Ce n'était plus gérable, et nous avons donc décidé de briser notre règle de parité.
Seuls les clients hors de l'Europe seront touchés par ce changement, qui n'est pas à proprement parler une hausse, mais plutôt un rééquilibrage.
Voila, c'était la page économie. 
|
|
|
| by Olivier Guillion |  |
| |
|
De récentes études ont montré qu'un cadre de travail agréable augmente sensiblement la productivité, que les bugs sont corrigés 25% plus rapidement, les mails traités 30% plus vite et les réponses 42,56% plus pertinentes.
Forts de ces données scientifiques incontestables, collectées auprès d'un échantillon de 3 personnes représentatives de la population mondiale, nous nous sommes dits que le jardin, sur lequel donnent les fenêtres de nos bureaux, serait plus joli si les plantes étaient bien arrosées.
Dans le cadre d'une démarche éco-responsable, prenant en compte le développement durable, la gestion des ressources renouvelables et toutes ces sortes de choses, nous avons interrogé les vieux sages du quartier, qui nous ont dit que, dans le temps, il y avait eu un puits dans le jardin.
Il faut dire que la présence d'une pompe à bras en fonte, connectée à un gros tuyau de plomb s'enfonçant dans le sol, nous avait mis la puce à l'oreille. La pompe ne fonctionnait plus, mais il devait quand même y avoir un puits quelque part.
Un puisatier, qui semblait bien connaître son métier, nous a indiqué que l'eau devait être à 4m50 de profondeur, que le puits ne devait pas être très loin et qu'il devait s'agir d'un puits bâti et non d'un forage. Ce puits était probablement comblé, mais cela vaudrait le coup de le dégager et de le remettre en service. Il nous a alors conseillé de suivre le tuyau, et de rechercher une ouverture circulaire d'environ 90 cm de diamètre.
Après quelques trous percés dans la dalle en béton près de la pompe, nous sommes tombés sur une grosse pierre taillée d'environ 200 kg, ronde et plate, avec un petit évier gravé sur le dessus (probablement l'emplacement pour poser un sceau).
Une fois la dalle de béton enlevée à cet endroit et la pierre dégagée non sans mal, est apparu le haut du puits, bâti en briques de Toulouse, vous savez, ces briques rouge-orange qui ont valu à notre belle cité son surnom de ville rose. 
Le puits était rempli de gravats divers et variés, jusqu'en haut, nous avons donc commencé à le dégager. Au bout d'une journée de travail, nous en sommes déjà à 3m de profondeur, mais n'avons pas fait de découverte archéologique majeure, à l'exception de morceaux de métal, de briques, de tuiles, une pierre à meuler, une tablette en marbre (cassée), une pince à linge (cassée aussi) et une capsule de bouteille de Vittel des années 70.
Plus qu'1m50 et nous devrions connaître le fond de l'affaire !
Vous pouvez voir une galerie photo de l'aventure ici.
La suite au prochain numéro, avec peut-être la réponse à toutes vos questions :
- Vont-ils trouver de l'eau ou du pétrole ?
- Lequel des deux frères a été tiré au sort pour rester au fond ?
- Vont-ils monter une filiale "Myriad terrassement et curage de puits" ?
- Et la version RC2 dans tout ça ? |
|
|
| by Olivier Guillion | |
|
| |
|
Aujourd'hui, nous avons continué à travailler sur le problème coriace décrit à l'étape précédente. Il devrait maintenant être complètement éradiqué.
Un beta-testeur par accident (il ne savait pas qu'il utilisait une version beta, ni où télécharger celle-ci) a permis de localiser et corriger une source de crash : si vous créiez un texte qui s'étend sur toute la largeur de la partition (de la première à la dernière mesure), vous risquiez d'avoir des problèmes lors de d'impression.
Un problème d'impression des vues lorsque celles-ci changent l'orientation de la page imprimée (portrait/paysage) avait été signalé il y a longtemps, et corrigé. Il a été signalé à nouveau, et il nous a fallu un peu de temps avant de nous apercevoir qu'il ne se produit que lorsque le document impose la taille de la page. Cela fonctionne apparemment quand le document utilise la taille par défaut de l'imprimante. Nous travaillons toujours là-dessus.
Un problème d'élimination des caractères accentués et non-occidentaux lors de l'export XML avait été corrigé, mais la correction était mal passée dans la version 9.4.0 RC1. Cela a donc été remis en place, et vérifié, cette fois  |
|
|
| by Olivier Guillion | |
| |
|
Un problème persistant, particulièrement coriace, nous a occupé aujourd'hui : l'aplatissement des coulés après certaines opérations.
Lorsque l'on active/désactive l'affichage de la partition transposée, les notes jouées par un instrument transpositeur changent de hauteur affichée, donc peuvent potentiellement changer de sens de tige.
Or, le positionnement automatique du coulé utilise le sens de tige pour savoir où placer les extrémités de ce coulé. Cela oblige donc à recalculer les positions de chaque coulé, à condition bien sûr que le positionnement automatique soit activé sur celui-ci.
Les vues peuvent choisir si, oui ou non, elles sont en affichage transposé, ou en "tonalité de concert". Changer de vue peut donc, dans certains cas, nécessiter de recalculer tous les coulés.
Enfin, "imprimer toutes les vues", par définition, change de vue lors de la procédure d'impression, donc peut également recalculer plusieurs fois les coulés de la partition.
Lors du changement de vue, les coulés se recalculaient mal. L'option "imprimer toutes les vues" fonctionne maintenant correctement, mais les tests intensifs des changements de vues ont fait apparaître d'autre cas qui, eux, ne sont toujours pas résolus. Nous y sommes donc toujours dessus.
Quand je vous disais qu'il était coriace, celui-ci... |
|
|
| by Olivier Guillion | |
| |
|
Pour débuter la nouvelle semaine, ce sont de vieux problèmes enfouis qui ressortent :
- En mode page, taquets affichés, l'affichage "fantôme" de la clé, tonalité et métrique sur la première mesure est maintenant géré.
- Certaines opérations, comme l'ajout de clé, tonalité, signature temps, rupture, etc, lorsqu'on cliquait en dehors des aires de portées, s'appliquaient à la portée la plus proche trouvée. Il faut maintenant cliquer dans l'aire de la portée. Ce n'est pas très contraignant, et évite que ces objets se retrouvent insérés à un endroit non prévu par l'utilisateur.
- Des problèmes d'impression de copie multiple sur Vista ont été corrigés. Pour ceux que cela intéresse, voici l'explication.
Chaque système d'exploitation a deux manières de gérer les impressions multiples (plus d'une copie de chaque page):
La première, c'est de dire à l'application combien de copies sont demandées, et de laisser celle-ci envoyer plusieurs fois la même page au pilote d'impression. C'est la méthode employée sur Apple jusqu'à récemment, avant la version 10.4 ? (à faire confirmer par Didier).
La seconde, c'est de ne rien dire à l'application, la laisser imprimer une fois chaque page, et que ce soit le pilote d'impression, ou le spouleur/spooler qui se charge d'envoyer les pages plusieurs fois à l'imprimante. C'est la nouvelle méthode employée par MacOS, et la seule que nous avions rencontrée sur Windows jusqu'à XP.
Mais voila. Il semble que Vista, ou tout au moins certains pilotes d'impression sous Vista, ne gère plus la seconde méthode, et lui préfère la première. Donc, toute une partie de code, consistant à envoyer les pages en exemplaires multiples sous Windows, n'avait jamais été exécutée, donc jamais testée. Et, bien sûr, cela ne fonctionnait pas.
Cette partie de code a donc maintenant été corrigée et testée. La seule chose qui ne fonctionnera pas sur Vista, c'est l'impression multiple en copies assemblées, qui consiste par exemple, lorsqu'on veut imprimer en deux exemplaires un document de trois pages, à sortir les pages 1, 2,3 puis à nouveau 1,2,3 au lieu d'imprimer la page 1 en double, puis la page 2 en double, puis la page 3 en double.
Il n'est pas certain que nous ayons le temps de le faire d'ici la sortie de la version définitive, mais cela demeure tout de même un problème mineur, n'empêchant pas l'utilisation de l'application. Cela demandera à l'utilisateur de trier lui-même les pages imprimées, voila tout
|
|
|
| by Olivier Guillion | |
| |
|
|
