CocoaHeads Rennes: session de Mai
Céroce
Membre, Modérateur
L'équipe rennaise nous informe que la prochaine réunion mensuelle aura lieu le lundi 30 mai à 18h30 à la Cantine numérique.
La première présentation parlera des méthodologies de développement itératif et sera donnée par Olivier Tabone.
La seconde aura pour sujet Xcode 4 et sera présentée par David Bonnet.
Plus de détails par ici.
P.S.: Mais comment font les rennais pour publier les sujets deux semaines à l'avance ?
La première présentation parlera des méthodologies de développement itératif et sera donnée par Olivier Tabone.
La seconde aura pour sujet Xcode 4 et sera présentée par David Bonnet.
Plus de détails par ici.
P.S.: Mais comment font les rennais pour publier les sujets deux semaines à l'avance ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est à dire ? Tu trouves que la publication est trop longtemps avant l'événement, ou au contraire trop peu de temps avant ?
Oui j'ai vu ça pour le mois de mai. Pour Rennes la session était bouclée depuis fin Avril!
Sur la gestion des dépendances de libs tu as bien vu hier à la conf que c'était plutôt pour expliquer comment faire des libs et les intégrer à Xcode, avec les différences pour intégrer ces libs dans ton projet entre Xcode3 et Xcode4 en bonus avec la 2e conf.
Pour moi ces présentations montraient plutôt des bonnes pratiques, ou des façons de te faciliter la vie, quand tu développes sur Mobile... finalement que tu développes sur Xcode ou sur autre chose : c'était appliquable aux autres IDEs aussi, sauf que les astuces données pdt la conf forcément se concentraient sur la mise en pratique au sein de Xcode.
En Java ou sous d'autres environnement, les mêmes problématiques que celles soulevées lors de la conf se posent aussi faut pas croire : il existe aussi des questions sur comment gérer ses libs réutilisables proprement quand nos libs sont sous SVN, pourquoi le svn:external n'est pas forcément la meilleure des solutions, pour les dépendances certes il y a Maven mais il faut encore savoir comment l'utiliser et écrire un scénario propre, tout comme sous Xcode il faut savoir comment définir les dépendances entre projets/libs...
La question des tests unitaires, de la méthodologie à utiliser dans ton cycle de développement, l'émergence de l'Agilité et des méthodos type Scrum... tout ça n'était pas forcément lié à Cocoa et Xcode finalement à proprement parler, mais plutôt des méthodologies en général (avec les subtilités de l'application de ces méthodos à du développement iPhone, par exemple prendre en compte que le temps de validation est long, que pour les livraisons y'a la possibilité de faire du OTA, etc)
Sous Android (Java/Eclipse, donc) tu as les mêmes problèmes de quelle méthodo utiliser, comment automatiser ton build de ton apk et la distribution automatisée de ce dernier à tes beta-testeurs, éventuellement via un serveur web, ce genre de trucs. Fais des sprints courts, faire des Coding Dojo, du Code Review, tout ça, c'est applicable aussi sous les autres environnements de dev !
En Java je ne considère pas l'IDE comme un pré-requis pour générer un produit, par contre il faut un pom ce qui permet à chacun d'utiliser l'IDE de son choix et aussi l'intégration continue.
En Java, le SDK est gratuit donc il y a autour une communauté importante qui développe des outils depuis pas mal d'années. Avec Apple comme c'est payant on serait en droit d'avoir tous les outils nécessaires. On voit que ce n'est pas le cas et comme on ne sait jamais ce que va faire Apple dans le futur, je serai personnellement assez froid pour développer des outils dans mon coin et voir que le SDK suivant a intégré un outil équivalent. Par exemple j'ai cru comprendre que l'intégration avec SVN était bien améliorée dans xcode 4 (pas difficile), ce qui rend moins indispensable d'autres outils externes spécialisés (et payant).
En tout cas c'était très intéressant.
Il faudra que je fasse une libraire (ou un workspace) un de ces jours...
Après, Apple fait avec les ressources dont elle dispose; c'est une petite société comparée à Microsoft ! Franchement, ça me gonfle sévèrement que les outils de tests automatiques (OCUnit et OCMock) cassent à chaque mà j de Xcode, mais ça n'a rien de délibéré, c'est juste que les ingés sont sur tous les fronts, alors pour les outils de tierce partie, si ça marche toujours tant mieux, sinon, on attend que les gens se plaignent pour corriger. Ce n'est pas une question d'argent: franchement ce n'est pas avec les ventes de comptes dév qu'Apple finance le développement de Xcode.
Je crois que ce sont à nouveau deux modèles qui s'affrontent: un modèle totalement libre, et un modèle contrôlé. Le premier est plus universel, le second est plus cohérent. Notre boulot est de réunir le meilleur des deux mondes, d'où ces sujets abordés aux CocoaHeads !
http://cocoaheads.fr/2011/06/slides-de-la-session-de-mai-a-rennes/