Présentation de NiClou
NiClou
Membre
Bonjour à tous.
Jeune futur diplômé (moins de 2 semaines) de la Licence Génie Logiciel de Paris Descartes, je m'inscris sur le forum pour partager et profiter des connaissances de chacun.
J'ai appris l'Objective-C tout seul (comme un grand 
), il y a déja 1an et demi environ, et suis impliqué à 100% (voir même plus) dans le dev. iOS...
J'ai bien évidemment quelques lacunes (due à mon manque d'expérience), mais comme tout développeur qui se respecte je cherche toujours la solution (mon RubberDuck y contribue bien lui aussi :P ).
Mis à part l'Objective-C j'ai eu l'occasion de bosser sur tous les langages enseignés en cours: C, C++, C#, JAVA, SQL, les langages web en général (mais je suis parcouru de spasmes quand je dois les utilisé 
). Et j'ai plutôt (je pense) avoir une bonne maitrise des techniques d'analyse (UML, Merise).
En ce moment je suis sur la phase de test d'une application que j'ai développé durant mon un stage de fin d'études, et recherche activement une entreprise pour la suite.
Petit plus: Je vais souvent aux CocoaHeads de Paris, et j'ai déjà remarqué certains d'entre vous que ce soit via l'entreprise dans laquelle je travaille ou via votre présence sur internet .
Destiné à Ali: Je ne te contredirai jamais, à” grand maitre ^_^
Au plaisir de vous reparler 
Réponses
PS : N'hésite pas à me contredire quand même si je dis des conneries, hein (le truc c'est que j'en dis pas souvent ^^ mais j'en dis certainement), sinon c'est pas marrant :P
Bon, dans le DEV IOS, ni clou et ni vis en principe!
(Je sais, elle est trop facile celle la)
Bien venu, même s'il ne faut pas compter sur moi pour IOS.
Chaque fois qu'on me parle des iBidules je fais une éruption de iBoutons et c'est franchement iPénible.
Pour les lacunes, ne t'inquiètes pas trop, Je suis sur ce forum depuis 2005 et j'ai toujours des lacunes. Mais nous avons un AliGator qui compense très souvent les trous de mémoire, les oublis, les méconnaissances ....etc.
Bienvenue à toi.
Je complète, dans le dev iOS:
Ni colle, Ni clou, Ni vis... ça tient tout seul.
Ahaha, Je fais un peu de bidouille pour tenir mon code en place..
Quelques clou et il tient l'espace d'une mise à jour :P
Merci à tous
On met tout à plat.
On fait, la vieille blague était:
M et Mme Niclouçatienttoutseul ont une fille...
=> Nicole
Il est temps d'aller manger...
Un jour.. Mais pas demain, demain j'ai des delegates à faire...
N.B: Meme si le principe de Delegate est un excellent Design Pattern et qu'il me sauve la vie couramment, je le hais >:D.. Je n'aime pas les delegate, j'ai des démangeaisons nerveuses à chaque fois que j'y pense
Il y a une raison ?
Moi je n'aime pas les créer et les implémenter non plus, mais qu'est-ce que c'est pratique non de dieu !
Je pense que c'est parce que je les utilises pas assez souvent et que ça a du mal à rentrer ^^
Mais bon, encore aujourd'hui j'ai du en faire un ^^'
D'ailleurs en ce qui concerne les designs pattern, vous avez un livre ou un article les concernant. Parce que c'est vrai qu'on parle beaucoup de celui la mais les autres?
Design Patterns de Cocoa
Et le livre à l'origine de tout:
Design Patterns
En pratique, on utilise surtout les design patterns MVC, délégation et singleton en Objective-C. C'est parce qu'Apple implémente déjà certaines de ces patterns dans ses propres classes. Par exemple, la pattern Command est implémentée directement par la classe NSInvocation et le runtime ObjC. De même pour la pattern Memento, implémentée notamment dans NSUndoManager.
Super Céroce !
Merci, je vais probablement me commander le livre.
Après quelques recherches j'ai remarqué que j'utilise déja certains de ces design pattern (sans savoir que c'en était).
Donc la lecture de ce livre ne me fera que le plus grand bien
EDIT: Petit cachotier, t'as participé à l'écriture de ce livre
http://www.amazon.fr/Renaud-Pradenc/e/B004N6PNVS/ref=ntt_dp_epwbk_1
Oui et non. J'ai fait un travail de relecture technique de la traduction française. Je précise que je n'ai pas d'intérêt particulier à ce que le livre se vende: j'ai été payé pour ce travail, et je ne touche pas d'argent sur les ventes. Si je peux conseiller ce livre, c'est parce qu'il est bon, quoiqu'un peu trop répétitif et bavard à mon goût.
Je ne remet pas du tout en doute ta capacité a répondre et à me conseiller objectivement
Et dans mes recherches j'étais déja tombé dessus (via un article paru sur MacG entre autres) donc tu ne fais que de me convaincre encore plus de l'acheter
@NiClou: j'entends bien, mais je ne veux pas que d'autres croient que je conseille ce livre parce que j'ai travaillé dessus. Je trouve qu'il a sa place dans la bibliothèque de tout bon développeur Cocoa, même s'il est très orienté Mac.
Je ne suis pas du tout fermé à l'apprentissage et qui plus est à une technique ou à une technologie. D'autant plus que les design patterns sont communs (Mac et iOS si je ne m'abuse). Je n'ai jamais eu l'occasion de dev une appli Mac, donc je ne serait que plus polyvalent avec ce livre si les exemples sont orientés mac.
Au contraire, moi j'adore ces Delegate :°)
Pour les opérations qui informent de la fin d'une opération, je préfère grandement les blocks, qu'on utilise dans ce cas en tant que "completionBlock" donc, que les delegate.
Mais pour les informations de notifications d'une action à tout moment, pouvant parfois être répétée (par exemple sur une application de chat, être informé dès que qqun change de statut, etc... ou bien les méthodes comme "textField:shouldChangeCharactersInRange:..." & co) qui n'indiquent pas spécialement la fin d'une opération mais sont appelés à chaque fois que qqch se passe, certes on peut aussi faire ça avec des blocks mais pour le coup je trouve que les delegate ont encore de beaux jours devant eux, car c'est plus de la notification qu'un événement arrive.
Donc en bref je suis bien + fan des blocks que des delegate, mais ils restent utiles et continuent à avoir du sens (même après l'apparition des blocks dans Objective-C) dans certains cas.
Et évidemment, le pattern delegate n'est qu'une utilisation parmi tant d'autres des @protocol, et là par contre les @protocol j'adore ça pour faire de belles abstractions et découpler mon architecture logicielle
@Ali :
ça m'donne envie d'acheter le bouquin que t'a traduit tout ça !
Et puis, je ne l'ai pas traduit, j'ai juste relu pour vérifier que la traduction était correcte techniquement.
Merde, j'ai mélange...
Du coup :
@Ali & @ Céroce :
Les subtilités dont parle Ali me donnent envie d'acheter le bouquin sur lequel a un peu travaillé Céroce.
je ne crois pas qu'il fasse allusion aux blocks dans son bouquin si?
Je ne sais pas. Mais il m'a titillé sur l'archi'...
Et puis, ça ne me fera jamais de mal de revoir un peu les design patterns.
Non, absolument pas, les blocs n'avaient pas encore été introduits à l'époque de l'écriture du livre.
Mais comme a dit Larme:
Pour info, les blocks c'est un outil plus qu'un design pattern.
Cela correspond aux fonctions anonymes aussi appelées lambda expressions dans certains langages allié au mécanisme de "closure". C'est donc une fonctionnalité du langage.
Après, il y a plusieurs DP pour lesquels les blocks sont tout indiqués pour les implémenter en Cocoa. Mais les blocks sont aux DP ce que les @protocol sont aux delegate, un outil du langage (qui peut servir pour ce DP ou pour d'autres usages plus variés).
La doc c'est Ali !
EDIT: C'est bon j'ai commandé le livre ! Quel galère pour le trouver au format papier !
FNAC, Cultura... Personne ne l'avait j'ai du prendre une occasion chez Amazon