Session du 23 mai 2013

[Mélanie]

Bonjour à tous,

La session de mai de CocoaHeads Toulouse aura lieu à une date un peu décalée pour vous permettre de profiter à fond des ponts. Ce sera le jeudi 23 mai.

Pour cette session, on va changer de format et pour ça, on a besoin de votre contribution. Le but est que plusieurs personnes présentent leurs frameworks ou outils de dév préférés en 10-20 minutes chacun pour faire un tour d'horizon de tous les outils employés. Cela permettra d'en découvrir certains ou de partager ses impressions sur d'autres plus connus.

Comme annoncé sur le site de cocoaheads.fr, j'ouvre cette discussion pour permettre aux futurs présentateurs de se déclarer et de dire quels outils ils aimeraient aborder. On a un mois pour rassembler le plus de personnes donc à vous de jouer :)

Mélanie

[Guillaume Cerquant]

Bonjour à tous,

J'ouvre le bal des propositions.
Si ça vous intéresse, je peux vous présenter CocoaPods : http://cocoapods.org
Installation, utilisation, création d'une spec. et bonnes pratiques associées.

Par contre, pour rester dans l'esprit de partage de CocoaHeads, je présenterai seulement si au moins 2 autres contribuent aussi avec une présentation ce soir là.

Ce n'est pas les sujets qui manquent. On a tous au moins un outil ou une technique qu'on adore utiliser.
Quelques idées si besoin : génération de documentation avec appledoc, les outils de statistiques, Crashlytics ou autre, le plugin de vos rêves pour Xcode, un bout de code bien hacky qui vous aide à débugger (ou que vous avez de manière téméraire et inconsciente réussi à mettre en prod sur l'AppStore)...

Happy coding!

--
Guillaume Cerquant
06 14 31 18 53

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes CocoaHeads Toulouse.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toul...@googlegroups.com.
> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
>
>

[Mélanie Bessagnet]

+1 pour CocoaPods !!

Allez je me lance aussi : je propose une petite présentation sur les plugins XCode qui facilitent la vie.

> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toulouse+unsub...@googlegroups.com.

[Patrice Trognon]

vous êtes a ce point intoxiqué par les immondices du monde java que vous voulez a tout prix les reproduire dans le monde cocoa ?

ma politique c'est : si pas fourni par Apple dans Xcode alors poubelle !

Pat

Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toul...@googlegroups.com.

[Guillaume Cerquant]

Patrice, tu parles des plugins, de CocoaPods, ou plus généralement d'utilisation de code source tierce, en licence open-source ou non ?

--
Guillaume

[Patrice Trognon]

un peu de tout en fait mais je vais nuancer .

cocoapods : totalement inutile, cela vient du monde java ou l'horreur mayen était nécessaire car la plateforme est dynamique, ce qui
est compilé n'est pas assuré de passer sans erreur au runtime puisque le linkage est refait par la VM a chaque lancement.
En C / C++ / Obj-C tu as un compilateur et surtout un vrai linker qui va produire un exécutable, donc tes dépendances sont des problèmes
de compilation/linkage uniquement a résoudre a la création du projet, une fois que c'est fait il n'y aura pas de soucis a l'exécution.
C'est pour cela que je dis que cela ne sert a rien ! c'est de la tarabistouille de javaiste.

Les plugins pour Xcode, en gros si ce n'est pas fourni par Apple je ne veux même pas en entendre parler trop risqué, mon Xcode me
permet de produire du code pour iOS et pour OS X, hors de question de prendre le risque qu'il tombe en panne sur un upgrade parce que
le plugin ne va pas suivre.

Le code tierce, les rares fois ou j'ai essayé d'en prendre, ou on me l'a "imposé" j'ai finit par le poubeliser très rapidement pour le réécrire tellement
c'était horrible, donc maintenant je n'essaye même plus, on a maintenant notre librairie de code qui s'enrichie au fur et a mesure et on pioche
dans notre code a nous, plus trop besoin de google.

Pat

[Guillaume Cerquant]

Merci pour la "nuance" ;)

Pour les plugins et le code tierce, différence de points de vue sur lequel on n'est pas d'accord.

Pour Cocoapods, l'intérêt est à la simplification et facilité d'ajout dans ton projet de ce code tierce. Je vois pas ce que l'aspect compilation / linkage change. Cela dit, vu ta position sur l'utilisation de code tierce, effectivement, l'intérêt est limité.

Viens à la session CocoaHeads, je suis toujours ravi d'avoir des points de vue contradictoire !

--
Guillaume

[Patrice Trognon]

dans le texte :

Le 30 avr. 2013 à 15:40, Guillaume Cerquant <guil...@cocoaheads.fr> a écrit :

> Merci pour la "nuance" ;)
>
> Pour les plugins et le code tierce, différence de points de vue sur lequel on n'est pas d'accord.
>
> Pour Cocoapods, l'intérêt est à la simplification et facilité d'ajout dans ton projet de ce code tierce. Je vois pas ce que l'aspect compilation / linkage change. Cela dit, vu ta position sur l'utilisation de code tierce, effectivement, l'intérêt est limité.
>

voila, tout est question d'approche, j'ai grande méfiance pour du code que je n'ai pas écrit moi ou le collègue, soit tu fais l'effort
d'écrire les 5% de la super lib bien lourde dont tu as besoin, soit tu vas intégrer la lib bien lourde et te coltiner les 95% inutiles
et leur overhead. je suis plus pour la première approche au moins dans le code que je produis il est maitrisé a 100% même plusieurs
années après son écriture et ainsi pas de soucis si la super lib en question n'est pas maintenu.
Je ne parle pas bien sur des framework d'apple avec lesquels je n'ai pas de soucis de couplage (enfin on pourrait aussi en débattre longtemps
parce que meme apple nous fait des gags).

donc en gros d'après ce que tu dis l'intérêt est limité si tu n'as pas a intégrer de code tierce, c'est a dire que pour du code qui s'appuie
uniquement sur les frameworks d'apple ce genre de truc ne sert a rien c'est bien ça ?

j'ai tendance a faire des bonds de 15m quand je vois revenir dans le monde cocoa des trucs qui m'ont fait fuir en courant du monde java
(maven par exemple), et ce genre d'outil m'y fait furieusement penser, je me trompe ?

> Viens à la session CocoaHeads, je suis toujours ravi d'avoir des points de vue contradictoire !
>

2h de route aller, idem au retour, désolé mais je limite mon impact de co2 sur la planète :)

Pat

[Laurent Gaches]

Cocoapods n'a pas grand chose a voir avec Maven. Maven permet de structurer un projet Java (organisation, dépendance, Test unitaire, génération de documentation, etc...), j'ai bien compris ta haine profonde pour Maven.

Cocoapods permet uniquement de gérer les dépendances de code tierces, il peut être utile même pour gérer tes propres librairies réutilisables d'un projet à l'autre. De plus Cocoapods n'a rien a voir avec Java mais plus avec Ruby puisqu'il s'inspire de Rubygem et de bundler.

>>>>>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toulouse+unsub...@googlegroups.com.

>>>>>> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes CocoaHeads Toulouse.

>>>>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toulouse+unsub...@googlegroups.com.

>>>>> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes CocoaHeads Toulouse.

>>>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toulouse+unsub...@googlegroups.com.

>>>> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
>>>>
>>>>
>>>
>>> --
>>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes CocoaHeads Toulouse.

>>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toulouse+unsub...@googlegroups.com.

>>> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
>>>
>>>
>>
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes CocoaHeads Toulouse.

>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toulouse+unsub...@googlegroups.com.

>> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
>>
>>
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes CocoaHeads Toulouse.

> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse cocoaheads-toulouse+unsub...@googlegroups.com.

[Guillaume Cerquant]

Le mardi 30 avril 2013 à 16:05, Patrice Trognon a écrit :

dans le texte :

Le 30 avr. 2013 à 15:40, Guillaume Cerquant <guil...@cocoaheads.fr> a écrit :

Merci pour la "nuance" ;)

Pour les plugins et le code tierce, différence de points de vue sur lequel on n'est pas d'accord.

Pour Cocoapods, l'intérêt est à la simplification et facilité d'ajout dans ton projet de ce code tierce. Je vois pas ce que l'aspect compilation / linkage change. Cela dit, vu ta position sur l'utilisation de code tierce, effectivement, l'intérêt est limité.

voila, tout est question d'approche, j'ai grande méfiance pour du code que je n'ai pas écrit moi ou le collègue, soit tu fais l'effort

d'écrire les 5% de la super lib bien lourde dont tu as besoin, soit tu vas intégrer la lib bien lourde et te coltiner les 95% inutiles

et leur overhead. je suis plus pour la première approche au moins dans le code que je produis il est maitrisé a 100% même plusieurs

années après son écriture et ainsi pas de soucis si la super lib en question n'est pas maintenu.

Je ne parle pas bien sur des framework d'apple avec lesquels je n'ai pas de soucis de couplage (enfin on pourrait aussi en débattre longtemps

parce que meme apple nous fait des gags).

donc en gros d'après ce que tu dis l'intérêt est limité si tu n'as pas a intégrer de code tierce, c'est a dire que pour du code qui s'appuie

uniquement sur les frameworks d'apple ce genre de truc ne sert a rien c'est bien ça ?

Tout à fait.

En gros, cela te permet d'intégrer dans ton projet des libs du genre AFNetworking - mais je sens que tu es fan de NSURLRequest - ou des classes plus limitées en périmètre. 

j'ai tendance a faire des bonds de 15m quand je vois revenir dans le monde cocoa des trucs qui m'ont fait fuir en courant du monde java

(maven par exemple), et ce genre d'outil m'y fait furieusement penser, je me trompe ?

Pas a ce point.

La, c'est plus une automatisation quand tu veux ajouter du code a ton projet.

Soit tu suis les étapes manuellement depuis le ReadMe, soit un outil le fait pour toi.

Le code intégré est ensuite versionné comme le reste de ton projet.

 

Viens à la session CocoaHeads, je suis toujours ravi d'avoir des points de vue contradictoire !

2h de route aller, idem au retour, désolé mais je limite mon impact de co2 sur la planète :)

En vélo ? 

[Patrice Trognon]

Le 30 avr. 2013 à 16:49, Guillaume Cerquant <guil...@cocoaheads.fr> a écrit :

Le mardi 30 avril 2013 à 16:05, Patrice Trognon a écrit :

dans le texte :

Le 30 avr. 2013 à 15:40, Guillaume Cerquant <guil...@cocoaheads.fr> a écrit :

Merci pour la "nuance" ;)

Pour les plugins et le code tierce, différence de points de vue sur lequel on n'est pas d'accord.

Pour Cocoapods, l'intérêt est à la simplification et facilité d'ajout dans ton projet de ce code tierce. Je vois pas ce que l'aspect compilation / linkage change. Cela dit, vu ta position sur l'utilisation de code tierce, effectivement, l'intérêt est limité.

voila, tout est question d'approche, j'ai grande méfiance pour du code que je n'ai pas écrit moi ou le collègue, soit tu fais l'effort

d'écrire les 5% de la super lib bien lourde dont tu as besoin, soit tu vas intégrer la lib bien lourde et te coltiner les 95% inutiles

et leur overhead. je suis plus pour la première approche au moins dans le code que je produis il est maitrisé a 100% même plusieurs

années après son écriture et ainsi pas de soucis si la super lib en question n'est pas maintenu.

Je ne parle pas bien sur des framework d'apple avec lesquels je n'ai pas de soucis de couplage (enfin on pourrait aussi en débattre longtemps

parce que meme apple nous fait des gags).

donc en gros d'après ce que tu dis l'intérêt est limité si tu n'as pas a intégrer de code tierce, c'est a dire que pour du code qui s'appuie

uniquement sur les frameworks d'apple ce genre de truc ne sert a rien c'est bien ça ?

Tout à fait.

En gros, cela te permet d'intégrer dans ton projet des libs du genre AFNetworking - mais je sens que tu es fan de NSURLRequest - ou des classes plus limitées en périmètre. 

Oui elles fonctionnent très bien les classes d'apple pas besoin de surcouches :)

tu m'as bien compris.

j'ai tendance a faire des bonds de 15m quand je vois revenir dans le monde cocoa des trucs qui m'ont fait fuir en courant du monde java

(maven par exemple), et ce genre d'outil m'y fait furieusement penser, je me trompe ?

Pas a ce point.

La, c'est plus une automatisation quand tu veux ajouter du code a ton projet.

Soit tu suis les étapes manuellement depuis le ReadMe, soit un outil le fait pour toi.

Le code intégré est ensuite versionné comme le reste de ton projet.

ok pigé.

et bien merci pour ton retour :)

 

Viens à la session CocoaHeads, je suis toujours ravi d'avoir des points de vue contradictoire !

2h de route aller, idem au retour, désolé mais je limite mon impact de co2 sur la planète :)

En vélo ? 

non, voiture, mais du coup j'ai capté le périmètre grâce a notre échange, c'est parfait.

Pat