 En matière de développement, il faut faire des choix au départ. Choix que l'on devra assumer parfois pendant plusieurs années. En général, que ce soit lors de la sélection d'une technologie ou d'un logiciel, nous nous posons les questions suivantes : "Si nous faisons ce choix, serons-nous bloqués, ou au contraire pourrons nous migrer vers des solutions compatibles ?", "Cette technologie existe-t-elle sur plusieurs plateformes ?". On peut dire, puisque nous maintenons certains logiciels "en vie" depuis plus de vingt ans, que nous avons eu la chance de ne pas trop nous tromper.
Pourtant un faux pas existe, c'est Galerie. Au tout début, heureux nouveau possesseur d'un appareil photo numérique, je cherchais un moyen simple de générer des galeries de photos pour la famille. Une recherche approfondie m'a vite fait découvrir les limitations en ce domaine sur Macintosh. Alors je me suis dit, pourquoi ne pas bricoler quelque chose moi-même. J'avais un Mac, XCode que j'avais "tatouillé" un peu, quelques notions d'AppleScript, et je me suis lancé.
Petit à petit, le logiciel à évolué, il a intégré du C, de l'objective-C, du JavaScript, des transfert FTP, des accés QuickTime. Des passionnés m'ont rejoint, m'apportant une rigueur plus que bienvenue (surtout au niveau du code HTML), des modèles plus que sympas, des conseils, des suggestions. Et rapidement, le petit script à usage personnel est devenu une vraie application, s'enrichissant sans cesse.
Et encore plus rapidement, je me suis heurté à de sévères limitations. Un exemple.
Personne, à ma connaissance, ne peut écrire plusieurs milliers de lignes de code sans erreur. Pour localiser les erreurs et les corriger il existe depuis les années 1980 ce que l'on appelle un "débogueur". Pour les non initiés, c'est la possibilité de voir pas à pas ce que fait un programme. Apple a maintenu pendant plus de trois ans sur son site les pages indiquant que l'on pouvait déboguer des applications AppleScript Studio. Mais personne ne pouvait le faire fonctionner. Finalement, Apple a réagi, et... a ajouté dans ses documentations que le débogueur AppleScript ne fonctionnait pas ! Point. C'est tout. Cela fait quatre ans. Pourtant c'est un concept Apple, spécifique à Apple, développé par Apple. Et depuis plus rien.
Devant tant d'immobilisme on pourrait se dire, "bon, on change de plateforme". Ah, mais non, ce n'est pas possible. Objective-C ne fonctionne que sur Macintosh, AppleScript ne fonctionne que sur Macintosh, le format des fichiers "ressource" est privé, jamais publié. Impossible de migrer vers d'autres plateformes.
Alors ami développeur, fais gaffe, ne commets pas la même erreur. Réfléchis à deux fois avant de te lancer... |
|
|
| by Didier Guillion |  |
| |
|
 Depuis quelque temps déjà, Metrowerks a abandonné sa version du compilateur C/C++ Codewarrior sur Windows et Mac OS.
C'était un produit excellent, tant en terme d'ergonomie que de performances, et qui n'est égalé par aucun des produits restant sur le marché.
Car le choix des compilateurs C (outils permettant de développer des programmes dans ce langage) s'est fortement réduit ces dernières années, ceci étant probablement lié à la complexité grandissante des "couches" propriétaires des systèmes d'exploitation (.NET, Cocoa...), et des langages spécifiques (C#, Objective C...) qui sont apparus.
Ces langages plus ou moins "propriétaires", s'ils ne sont pas mauvais en eux-mêmes, posent cependant le problème de la portabilité des applications d'une plateforme à l'autre. Alors qu'avec un bon vieux source C bien écrit, ce problème ne se posait -presque- pas.
Basiquement, sur PC il ne reste plus que Microsoft Visual C/C++, bien adapté à de gros projets, mais à l'ergonomie contestable, truffé de gadgets microsoftiens permettant de créer des objets très spécifiques, destinés à fonctionner uniquement sur Windows.
Quelques essais de portage d'interface graphique autour de compilateurs issus du monde du libre (GCC) on bien été tentés, mais jamais transformés.
Sur Macintosh, cet essai a également été tenté, et a abouti à XCode, qui est bien meilleur que les timides tentatives sous Windows, mais malgré tout largement au-dessous de ce qu'avait réalisé Metrowerks en son temps, et qui pose la question cruciale du développement de gros projets sous Mac OS X. Le compilateur est extrèmement lent, ne génère pas un code très optimisé, et on sent bien le "raboutage" de parties disparates qui a été effectué pour créer ce produit.
Pour ce qui est de la rapidité et de l'optimisation, au moins sur MacTel, la solution pourrait passer par Intel, qui propose un compilateur utilisable dans XCode. Le prix semble cependant plutôt prohibitif ($400) pour un simple module de compilation. Nous n'avons pas encore eu l'occasion de tester cette solution.
Ce que je n'arrive pas à m'expliquer, c'est pourquoi, lorsqu'un éditeur de logiciels abandonne un produit sans espérer un jour le reprendre, il ne rend pas public le code source de l'application, laissant une communauté d'utilisateur (qui, de plus, sont ici tous des programmeurs) continuer son développement en "libre". Quelle perte financière cela entraînerait-il?
Et Metrowerks n'est pas le seul exemple. Apple a abandonné purement et simplement le développement de ses outils de développement Macintosh Programmer Worskhop. Pourtant, l'équipe Apple chargée de MPW était d'accord pour passer le logiciel en OpenSource et ne pas trancher la gorge aux développeurs qui avaient naïvement suivi leurs recommandations. C'est la division "juridique" qui a mis son véto au dernier moment. Apple semble vouloir agir de même avec son éditeur de ressources Resedit, préférant, pour des raisons obscures de copyright, laisser les programmeurs dans la mouise plutôt que de leur permettre de continuer à développer confortablement (sur des machines Apple, qui plus est).
Malheureusement, beaucoup de décisions de ce type sont plus politiques que dirigées par le bon sens, et, pour ces sociétés, le respect de leurs propres clients semble être le cadet de leurs soucis. |
|
|
| by Olivier Guillion |  |
| |
|
 Pour nos programmes, nous sommes des demandeurs fréquents d'icônes et autres graphismes d'interface. A ce jour, nous n'avons travaillé qu'avec des graphistes américains. Quand nous avons constaté ce fait, nous avons cherché une explication. Ce serait tout de même plus aisé pour nous d'exprimer nos besoins dans notre langue maternelle. Je me suis un peu balladé sur des forums où des graphistes Francophones s'expriment et j'ai fait plusieurs demandes. Aucune n'a pu aboutir à un contact sérieux. Impossible d'obtenir des exemples de réalisation, un aperçu des tarifs, ou même un mode de réglement compatible avec la comptabilité d'une société. Certains graphistes demandaient même d'être payé au pourcentage ! Je me dis que, peut être, les graphistes Français considèrent la réalisation de l'interface d'un logiciel comme un travail trop trivial ? Je reste dans l'incompréhension.
A titre d'exemple, voici le dernier contact que nous avons eu avec un graphiste d'outre-atlantique.
je recois un email où il me dit que nous devrions changer d'écran de démarrage et d'icone d'application car ceux que nous utilisons semblent dater un peu. D'après ce qu'il m'écrit, il a pris le temps de survoler nos logiciels, il ne parle pas dans le vide, bon point pour lui. Je lui fais donc la demande d'exemple de graphismes et de tarif. Il m'envoie un lien sur un site simple et bien fait, présentant ses réalisations. Je lui dis que tel style de graphisme, vu sur son site me plait bien. Il me fait une proposition commerciale. Je dis ok. Quinze jours plus tard, je recois les premiers rushs, un ou deux ajustements mineurs et une semaine après l'affaire était réglée.
Alors, amis graphistes, notre porte vous est toujours ouverte, n'hésitez pas à frapper avec votre carton à dessins sous le bras ! |
|
|
| by Didier Guillion | |
|
| |
|
|
