En vrac

02 03 2009 In: Cocoa, Interview, Livres

Aujourd'hui ça va du développement de jeu, aux livres en passant par des interviews de développeurs :

Des ressources Cocoa en français

19 02 2009 In: Cocoa, iPhone / iPod Touch, Liens

Les ressources en français concernant Cocoa et le développement sur Mac / iPhone sont relativement rare, alors quand plusieurs sont mise en ligne la même semaine, je ne peux m'empecher de vous les signaler :

L'actualité de ces derniers jours

22 01 2009 In: Cocoa, iPhone / iPod Touch, Liens

Après quelques jours sans billets de ma part, voici une grosse sélection des dernières actualités utiles pour les développeur Mac :

  • Cocoa for Scientists est une série d'article pour apprendre àutiliser Cocoa dans des applications scientifiques. Cela va de la présentation de données en 2D ou 3D, à la gestion du réseau avec Bonjour, en passant par la gestion des threads.
  • pysmell est un outil qui propose de l'auto-complétion du code Python dans différents logiciels dont TextMate.
  • Si vous pouvez vous rendre en Angleterre le 16 et 17 Avril 2009, essayer de faire à tour à MacDev 2009, la conférence pour les indépendants sur le développement Mac. En tout cas, la liste des conférenciers est particulièrement intéressante.

Et parce que Cocoa c'est aussi l'iPhone, voici quelques liens en provenance de Mobile Orchad qui peuvent vous être utiles :

Pour finir, je voudrais juste signaler que je vais dans la journée migrer le site sur un nouveau serveur. Les commentaires seront désactivés sur l'ancien serveur. Si vous pouvez ajouter des commentaires, c'est que vous voyez la nouvelle version.

10 manières de réduire les bogues

21 01 2009 In: Astuces, Cocoa, Logiciel, Objective-C

Les bogues ne sont pas une fatalité: ce sont des défauts dus à des erreurs d'êtres humains:

  1. Trop grande complexité
  2. Méconnaissance des API ou du langage
  3. Étourderies
  4. Laxisme !

Comme vous êtes comme moi et détestez passer vos après-midi sur un débogueur, voici quelques stratégies éprouvées pour les réduire.

10. Documentez

Je vais ici seulement insister sur les aspects de la doc qui permettent de limiter les bogues :

  • Rédigez une partie de la description d'une méthode avant de la coder
    Vous devez réfléchir aux cas particuliers du déroulement, aux valeurs possibles des arguments d'entrée (notamment comment gérer les gammes de valeurs inattendues), et quelles erreurs peuvent subvenir pendant l'exécution. Inspirez-vous de la programmation par contrat.

  • Faites des commentaires utiles
    Ils ne doivent pas paraphraser le code, ni expliquer chaque appel de méthode. Expliquez le cheminement du code, et soulignez ce qui est le moins évident. C'est très utile au débogage, quand on revient au code quelques semaines plus tard.

  • Nommez vos variables avec grand soin
    Je suis toujours étonné qu'à notre époque, les gens nomment encore leurs variables i,j, tab[] ou ptr, dans la plus pure tradition du Kernighan & Ritchie. Il m'est arrivé de rendre des bogues évidents rien qu'en renommant.

9. Relisez-vous

D'expérience, la moitié des bogues pourraient être évités lors de l'écriture du code. Je ne parle pas des erreurs de syntaxes (signalées par le compilateur), mais utiliser une variable à la place d'une autre, effectuer les opérations dans le mauvais ordre, etc.

Si vous programmez seul, pensez à relire — avec un œil critique s'entend — votre nouveau code systématiquement avant de compiler.

8. Corrigez les bogues dès qu'ils apparaissent

Il arrive fréquemment de découvrir un bogue, et de le laisser à plus tard. Comme vous êtes un programmeur consciencieux, vous y reviendrez. Mon expérience dicte de corriger le bogue immédiatement, parce qu'il arrive souvent de commettre encore et encore la même erreur. Mieux vaut donc la corriger au plus tôt, pour ne faire l'erreur qu'une fois.

7. Testez les codes d'erreur et gérez les exceptions

À moins que cela n'alourdisse exagérément le code, il est sage de vérifier les résultats des fonctions. Gérez aussi les exceptions. Ces deux tâches triviales ne doivent pas être laissées à plus tard — c'est à dire jamais.

6. Créez des projets d'essai

Bien que je travaille sur un gros projet, je crées de nombreux petits projets annexes. Le dernier en date était destiné à vérifier sur mon site web si une nouvelle version de l'appli est disponible. Je n'avais aucune expérience du téléchargement d'un fichier texte. Sur ce petit programme de vingt lignes, j'avais tout de même commis deux bogues. Avoir un programme léger permet de les cerner rapidement.

Si j'avais intégré la fonction directement dans mon appli, je me serais demandé si les problèmes venaient du nouveau code ou de l'ancien. J'aurais peut être modifié du code valide. Enfin, maîtriser une technologie permet de savoir comment l'intégrer au mieux au reste de l'application.

5. Ayez des scénarios de test sous la main

D'expérience, il arrive que les bogues apparaissent dans des circonstances déjà rencontrées. Lorsque vous avez trouvé une procédure pour reproduire un bogue à coup sûr, notez-là et déroulez cette procédure à chaque version. Si possible, automatisez les tests. Par exemple, les tests de l'interface utilisateur peuvent être automatisés avec Instruments.

4. Écrivez des tests unitaires

Les tests unitaires s'appliquent essentiellement aux classes de la couche modèle. Ma première expérience fut une classe que je n'arrivais pas à mettre au point pour un programme de musique, qui devait renvoyer les notes faisant partie d'une gamme. J'étais capable de trouver ces notes sur le papier, mais je m'y suis repris à trois fois avant d'avoir un algorithme… qui ne marchait pas dans certains cas particuliers.

Après avoir écrit les tests unitaires, les erreurs apparaissaient de façon évidente dans la couche modèle, plutôt que de manière indirecte dans l'interface utilisateur. J'ai gagné du temps, et j'étais enfin sûr de mon code.
Nous reviendrons sur les tests unitaires, à la mode, et ceci pour d'autres très bonnes raisons.

3. Réduisez les contraintes

Comme dit plus haut, la cause principale des bugs est la complexité. En effet, des scientifiques ont mesuré que les individus les plus doués étaient capables de prendre en compte simultanément sept contraintes. Pour la plupart des gens, c'est plutôt quatre (<- c'est là que je me situe).

L'idée est donc de limiter la complexité du logiciel:

  • en ajoutant de l'abstraction
    pour pouvoir se concentrer sur la tâche présente au lieu des détails d'implémentation.

  • en limitant le couplage
    c'est à dire les interdépendances entre objets.

Et cela est difficile. Très. Beaucoup de gens se disent programmeur ("oui, j'ai étudié un peu le langage C pendant mes études de biologie"), mais peu ont déjà travaillé sur un projet conséquent, un où les bogues deviennent difficiles à résoudre et semblent réapparaître sans cesse.

Je n'ai pas de secret, il faut se forger une expérience: étudier les patrons de conception, savoir comment fonctionne la machine et le système d'exploitation, étudier d'autres langages de programmation ou d'autres bibliothèques…

2. Ne construisez que les infrastructures nécessaires maintenant

Ce point est un peu en contradiction avec le précédent. En effet, quand on commence à ajouter de l'abstraction, on a ensuite tendance à vouloir rendre tout réutilisable et générique. Imaginons que vous vouliez écrire un texte en rouge. Il est tentant d'écrire une méthode générique qui prend la couleur en paramètre, pour le jour où vous voudriez écrire en vert.

Pourtant, la méthode générique sera forcément plus difficile à écrire et à tester. Pourquoi passer du temps sur quelque chose d'inutile aujourd'hui ? Attendez un jour prochain que le besoin soit réel. De plus, une méthode simple sera une bonne base de départ pour écrire une méthode plus complexe.

1. Codez moins

Aucun code n'est plus flexible que pas de code.

Il existe souvent une méthode qui rend 80% du service avec seulement 20% du travail que demanderait une méthode parfaite. Ne visez pas la perfection. La vie est trop courte ! Demandez-vous si vos utilisateurs préfèrent une fonction parfaite dans un an ou une fonction correcte aujourd'hui.

Moins de code = moins de bogues
Travaillez le cœur de métier de votre logiciel. Les détails seront réglés plus tard (voire jamais).

Pour finir

Voilà les méthodes que j'utilise — avec plus ou moins de rigueur — pour conserver mes applis stables. Auriez-vous d'autres techniques à proposer ?

L'indépendance de la résolution

20 01 2009 In: Cocoa, Mac OS X

La résolution

Commençons par rappeler ce qu'est la résolution. On l'exprime habituellement en points par pouce. C'est à dire qu'il s'agit du nombre de points — pour un écran, des pixels — alignés sur un pouce de longueur (1 pouce = 2,54 cm).
L'abréviation ppp (points par pouce) se rencontre, mais l'abréviation anglaise dpi (Dots per Inch) est la plus courante.

Paradoxe: "Plus les pixels sont nombreux, et moins on les voit".

Des pixels aux centimètres

Si vous avez bien suivi, vous pourrez tenter de répondre à cette question: combien faut-il aligner de pixels pour tracer un segment d'un centimètre de long ? Réfléchissez.

En fait il vous manque quelques données pour répondre. Alors, prenons l'exemple de l'écran de mon iMac: il affiche 1440 x 900 pixels. Sa diagonale mesure 17 pouces. Les pixels sont carrés.

Calcul des dimensions physiques de l'écran

Commençons par calculer les dimensions physiques de l'écran, grâce au théorème de Pythagore:
largeur^2 + hauteur^2 = diagonale^2

Sachant que
largeur = (1440/900) x hauteur = 1,6 x hauteur

Vous devez trouver:
hauteur = 9 pouces
largeur = 14,41 pouces

Calcul de la résolution

L'écran a donc une résolution de 900 pixels / 9 pouces = 100 points/pouce.

La réponse à la question de départ

En divisant par 2,54, on trouve que 100 ppp correspond à 39,37 points/cm. Il faudra donc aligner 39 pixels pour tracer un segment d'un centimètre de long.

Où veux-tu en venir, Renaud ?

Ça vient ! Prenons l'exemple de votre traitement de texte habituel. Le format d'impression est un A4 et le zoom est réglé à 100%. Comment se fait-il alors que lorsque je superpose une feuille A4, la feuille à l'écran est plus petite ?

Réponse: parce que le traitement de texte part du principe que la résolution de votre écran est de 72 ppp. Pourquoi 72 ppp ? C'est historique; dans les années 90, c'était une résolution courante pour un écran. Sous Windows, il me semble qu'on utilise 85 ppp, ce qui est un peu plus proche de la réalité. Tout ça n'est tout de même pas très WYSIWYG.

Donc, si je veux voir la page à la taille réelle sur mon iMac, il faut que je règle le zoom à (100 / 72) = 139%.

Pourquoi ce problème n'est pas encore résolu en 2009 ?

Notez bien que la résolution de chaque écran est différente, elle est plus dense encore pour l'écran de mon MacBook. Des API existent pour connaître la définition (en pixels) de l'écran. On peut sans doute également obtenir sa diagonale (en pouces) et procéder au calcul vu plus haut. Et le problème sera résolu: le traitement de texte fera le calcul de la résolution et affichera sur l'écran de mon MacBook la feuille A4 avec une largeur mesurant très exactement 21 cm.

Bien. Imaginons que j'ai maintenant l'idée saugrenue de brancher à mon MacBook un écran externe d'une résolution de 100 ppp, et que je place la fenêtre à cheval entre les deux écrans: ça ne va plus du tout ! La page est maintenant trop grosse sur l'écran externe !

Ce problème est insoluble au niveau applicatif. La seule possibilité est que le Window Server fasse les adaptations.

Les réflexions d'Apple sur le sujet

L'indépendance de la résolution était annoncée pour Mac OS 10.5 et ne fut finalement pas présente. Il est possible qu'elle fasse son apparition dans 10.6. Il existe pourtant déjà quelques API:

Resolution Independence Guidelines

Je vous fait un petit résumé:

  • Les ingés d'Apple ont l'air de s'embrouiller avec tout ça.
  • Il faudra dessiner à 72 ppp. Quartz effectuera ensuite les conversions pour avoir les coordonnées en pixels.
  • Il est pour l'instant possible de changer le facteur d'agrandissement à l'aide de l'application Quartz Debug, dans le menu Tools > Show User Interface Resolution. Essayez, c'est marrant.

Ce petit essai devrait vous faire comprendre la complexité de la chose: c'est moche, on voit plein de gros pixels. Il va donc falloir rendre l'interface utilisateur entièrement vectorielle. C'est un énorme travail, et il est donc compréhensible qu'Apple ne l'ait pas encore complètement implémenté.

Présentation des tests unitaires sur Vimeo

05 01 2009 In: Cocoa, Vidéos

Peter Hosey vient de publier sur son blog une présentation des tests unitaires qu'il a donné lors d'une réunion Cocoa Heads sous forme de vidéo (mise en ligne sur Vimeo). Il est donc possible de télécharger la présentation pour la regarder en local.


Unit testing from Peter Hosey on Vimeo.

Pour quelles versions de Mac OS X développer ?

22 12 2008 In: Cocoa, Mac OS X

En ce moment, l'une des questions les plus présentes dans mon esprit, au sujet du développement de Marquise, est sous quelles versions du système d'exploitation mon application devra être capable de tourner. L'idéal serait de gérer le maximum de versions d'OS X. Cependant, cela présente des contraintes techniques, mais surtout économiques.

Les avantages d'assurer la compatibilité avec 10.4 (voire 10.3)

Ou plutôt, le seul avantage, mais un gros avantage: pouvoir toucher un maximum de clients. Voilà maintenant sept ans que la première version de Mac OS X est sortie. Il faut être conscient qu'il y a sûrement plus de machines tournant sous les OS 10.0 à 10.4 cumulés que Mac OS 10.5.

Il faut toutefois relativiser: la plupart sont tout de même sous 10.2 à 10.4, pour deux raisons. La première, c'est que les améliorations de 10.0 à 10.1 à 10.2 à 10.3 sont très visibles. L'autre raison, c'est que la reprise des ventes de Mac s'est faite lorsque 10.4 était le système actuel.

Pourquoi j'avais fixé le ticket d'entrée à 10.4

Une raison technologique: Core Data

Cette technologie fut introduite dans OS 10.4. Apple la présente comme une solution permettant de ne pas s'occuper de la gestion des fichiers, ni de l'Undo, avec à la clef un gain de productivité. J'ai été très déçu par Core Data (ce sera l'objet d'un autre article), que j'ai remplacé depuis par un enregistrement en XML. Aujourd'hui, j'utilise la classe NSXMLDocument, qui n'est disponible qu'à partir de 10.4.

Une raison pratique: je ne peux pas tester sous des versions antérieures

Ma machine principale est un iMac G5 sous 10.5, qui était livré avec 10.4. Je me suis donc acheté un disque dur externe et y est installé 10.4 pour mes tests. Il me faudrait une autre machine pour tester sous 10.3.

Une raison de puissance

Une machine sous 10.3, je vois ce que c'est: mon vieil iMac G3. Cette machine ne pourra jamais faire tourner Marquise qui manipule des images par dizaines. Fixer le système minimum à 10.4 permet de se limiter aux machines capables de faire tourner 10.4 correctement, c'est à dire les G5 et les tous derniers G4.

Pourquoi j'envisage de mettre le ticket d'entrée à 10.5

Comme je l'écris plus haut, je dois redémarrer pour tester Marquise sous 10.4. En pratique, cela se déroule ainsi: je copie l'application sur une mémoire USB, je redémarre avec Option appuyée et sélectionne mon disque externe pour le démarrage. Enfin, j'arrive sous 10.4, je lance Marquise, et m'écrie: "Bon dieu, ce que c'est moche !". Ce qui m'intéresse en particulier, c'est un des boutons de la barre d'outils qui devrait présenter un petit triangle, indiquant qu'un menu s'affiche, mais qui ne le fait pas. Je dois alors retourner sous 10.5, trouver un compromis sur la taille du bouton, reconstruire l'appli, la remettre sur la mémoire USB, redémarrer, etc. On peut perdre des heures sur ces manipulations. Évidemment, la solution serait de me payer une nouvelle machine, mais il va falloir que Marquise me rapporte quelques thunes avant.

D'autres développeurs, je pense à ceux de Delicious Library ou RapidWeaver, ont carrément fait le choix de ne plus développer que pour 10.5. La première raison est celle que je viens d'évoquer: maintenir leur logiciel pour deux versions d'OS X représente trop de boulot, par rapport au gain économique attendu. La deuxième raison est technologique: ainsi Delicious Library fut la première grosse application à utiliser Core Animation (introduit avec 10.5). On peut trouver cela tape-à-l'œil, mais c'est très certainement séduisant pour les clients potentiels qui essaient le logiciel.

À chaque fois que sort un de ces logiciels dédiés à 10.5, on peut lire les même commentaires aux nouvelles de MacGénération: "c'est bien dommage qu'il ne tourne pas sous 10.4". Ce que je pense, c'est que les deux tiers des gens qui laissent ce genre de messages sont sous… 10.5. Car la réalité la voici: les gens de Delicious Monster ou Real Mac Software ne sont pas suicidaires. S'ils prennent ce genre de décisions, c'est parce qu'il savent que leurs clients sont en grande majorité (au moins 85%) sous 10.5. Ils le savent par les statistiques d'accès à leur site web. Ce n'est pas contradictoire avec ce que j'écrivais plus haut: que la majorité des machines sous OS X, étaient sous 10.4 ou antérieures. En effet, un client qui est prêt à installer et payer un shareware n'est pas un utilisateur moyen.

Ma décision alors ?

À vrai dire, je n'ai toujours pas décidé. Mon code peut encore tourner sous 10.4. Mais un élément va être décisif: l'arrivée de 10.6, certainement à la même période que la première version commerciale de Marquise. Je devrai alors travailler sous trois versions d'OS X. Je me dis que limiter à 10.5 serait une bonne idée, rien que ne pas avoir de clients qui se mettent à râler quand j'abandonnerai 10.4, ce qui arrivera. Au final, je crois que je vais regarder les statistiques de mon site web quand je proposerai les premières versions béta en téléchargement pour décider.

La documentation indispensable

09 12 2008 In: Cocoa, Liens, Livres

Ce site n'est pas l'endroit pour prodiguer un cours sur Cocoa. Non seulement, le sujet est trop étendu, mais aussi, la documentation existe déjà.

La doc d'Apple

Vous trouverez cette documentation sur le site developpeurs d'Apple, mais le plus pratique est de la consulter sous XCode via le menu Help > Documentation. Il s'agit d'une documentation de référence: elle contient beaucoup, en fait beaucoup trop d'informations; d'autant plus qu'on y trouve beaucoup de blabla. Il s'agit pourtant d'un outil quotidien, qui répondra à presque toutes vos questions, quand vous saurez où chercher.

Même si Apple a fait des efforts pour fournir quelques guides d'introduction, vous attaquer de front à la doc ne peut que vous impressionner, vous noyer et finalement vous dégoûter, ce qui nous amène à…

Cocoa Programming for Mac OS X

Couverture Cocoa Programming À sa sortie en 2002, ce livre fut accueilli avec un grand soulagement. Son auteur, Aaron Hillegass, était formateur pour NeXT avant de monter sa propre société de formation, et propose un livre simple d'accès, destiné à vous procurer le bagage minimum. À vrai dire, si vous posez des questions sur les forums, on s'attendra à ce que vous l'ayez lu, sinon on vous invitera souvent à le faire.

Les sujets couverts sont les suivants:

  • utilisation de base de XCode et d'Interface Builder
  • le langage Objective-C: syntaxe, gestion mémoire (y compris le ramasse-miettes), protocoles, catégories, propriété
  • Foundation
  • AppKit
  • Principes courants de Cocoa: délégués, archivage, notifications
  • Key-Value Coding, Bindings, Core Data
  • Core Animation

La grande force de ce livre, c'est son approche TP. Point de chichi: l'auteur vous montrera par exemple une fenêtre en écrivant "débrouillez vous pour que ça ressemble à ça". Il s'agit d'un enseignement progressif: les objectifs sont fixés, quelques principes expliqués, puis vient le codage. En fin de chapitre, se trouve un encart "pour les plus curieux" où l'auteur fournit quelques informations sur le fonctionnement de Cocoa. Enfin, sont proposés des défis: il s'agit pour le lecteur de travailler tout seul cette fois-ci, et d'améliorer le programme. Et il est utile de le préciser: tous les défis sont faisables.

Il ne s'agit pas d'un livre de référence, on n'y découvre que quelques classes, mais ce sont des classes représentatives, et l'essentiel de chaque concept est expliqué pour pouvoir approfondir avec la doc d'Apple par la suite.

Couverture Programmation Cocoa Le livre a été mis à jour à la sortie de Mac OS 10.5. Cette troisième édition, traduite en français, vient tout juste de paraître, sous le titre Programmation Cocoa sous Mac OS X.

En résumé: conseillé sans réserve aucune, pourvu que vous ayez les pré-requis: connaître le langage C et avoir des notions de programmation orientée objet.

Objective-Cocoa.org

Il s'agit d'un forum en français qui existe depuis deux ans. L'ambiance y est détendue, les débutants bienvenus même si des usagers de Cocoa qui ont de la bouteille y participent.

Le guide du débogage

Il arrive un moment où le débogage à base de NSLog() montre ses limites. Si n'explique pas l'utilisation du débogueur, le guide suivant fournit quantités d'astuces: Technical Note TN2124.

La mailing-list d'Apple

Apple a mis en place des listes sur divers sujets. Celle qui nous intéresse est bien évidemment celle de Cocoa. À vrai dire, utiliser cette liste est à faire en dernier recours. En effet, pour poser une question, il est nécessaire de s'y abonner — normal, me direz-vous — sauf que vous allez recevoir de l'ordre de 100 messages par jour, la plupart n'ayant pas d'intérêt pour vous. Je vous conseillerais donc d'activer le mode "digest" dés le départ !

Reste qu'on y trouve des gens qui ont une connaissance poussée de Cocoa, et même parfois des ingés d'Apple. À ce propos, ces employés le font bénévolement, un hot-dog à la main, ou entre 20 et 22h. Cela dit, vous pouvez considérer que si vous n'obtenez pas la réponse sur cette liste, c'est que personne ne l'a.

Les sites spécialisés sur Cocoa

StepWise L'un des plus vieux sites. Contient beaucoup d'articles techniques et très intéressants.

Cocoa Dev Central Quelques articles d'introduction, et des liens.

Une des pratiques importantes dans le développement logiciel, est l'utilisation de tests unitaires. Cela permet de s'assurer du comportement de son code, d'éviter les régressions et de manière général d'avoir plus confiance en son code.

Google vous propose dans le cadre de son Google Mac Developer Playground un certain nombre d'outils pour développeur dont CoverStory, qui permet de visualiser facilement le taux de couverture de votre code à partir des fichiers générés par Gcov.

CoverStory

Pour plus d'informations sur CoverStory, les outils Google pour développeurs Mac et Gcov, utilisez les liens ci-dessous :

Livre: Programmation Cocoa sous Mac OS X

26 11 2008 In: Cocoa, Livres

Couverture On l'attendait avec impatience, la voici. La version française de la troisième édition de Cocoa Programming for Mac OS X vient de paraître.

L'éditeur a changé (ce n'est plus Eyrolles), et nous ne pouvons pas encore vous donner notre avis sur la traduction, mais la version anglaise reste le seul livre indispensable à tout programmeur Cocoa. À commander au père Noël d'urgence.

Note de Fabien: Je peux vous dire qu'il est vraiment sympa pour l'avoir lu dans le cadre de la relecture technique de la version française.