Share
Dans cette interview, je discute avec Nick Lockwood, l'un des principaux développeurs iOS, de ses contributions à l'open source, de son flux de travail de développement et des ressources pédagogiques qu'il a trouvées utiles pour maîtriser le SDK..
Nick Lockwood est l'un des principaux développeurs iOS et auteur de nombreux projets open source populaires, notamment iCarousel, iRate et FXBlurView..
Nick a récemment écrit le livre iOS Core Animation: Techniques avancées, publié par Addison-Wesley, et nous avons fourni un extrait du chapitre 5 avec cet article..
J'ai d'abord pris un livre de programmation à l'âge de 12 ans. Je ne me souviens pas du nom du livre - quelque chose comme "Programmation de base sur la BBC Micro" - mais ce fut un moment crucial dans ma vie.
J'ai étudié l'ingénierie électronique puis l'informatique à l'université. Le premier était intéressant mais pas particulièrement pertinent pour ma carrière ultérieure; Ce dernier m'a appris les bases des structures de données et des algorithmes, ce qui s'est avéré très utile.
Après avoir obtenu mon diplôme, j'ai créé mon entreprise Charcoal Design, vendant des jeux et des utilitaires Mac simples écrits en REALbasic. Cela ne rapportait vraiment rien, j'ai donc développé du développement web indépendant pour joindre les deux bouts..
Mon premier vrai travail a été celui de développeur Web front-end, ce qui au début ne semblait pas avoir grand chose à voir avec la programmation, jusqu'à ce que JavaScript ait vraiment atteint sa maturité et que le développement web front-end soit devenu une discipline proprement dite du génie logiciel. être à propos de qui connaissait les bogues CSS IE 6 les plus ésotériques.
J'ai vu que l'iPhone allait avoir un impact profond sur le Web mobile lors de sa première sortie, mais je n'y ai pas vraiment pensé. Au Royaume-Uni, pratiquement personne n’a acheté l’iPhone 1ère génération - c’était trop cher et nous avions déjà des téléphones très bons (et beaucoup plus petits).
Cela a changé du jour au lendemain lorsque l'iPhone 3G est expédié. J'ai reçu mon premier iPhone en juillet 2008. Et j'ai acheté Beginning iPhone 2 Development pour pouvoir apprendre à le programmer. J'avais déjà utilisé Objective-C sur Mac, alors j'ai rapidement assimilé les bases. J'ai écrit Rainbow Blocks en tant qu'application HTML5 exécutée dans un UIWebView en plein écran (j'étais encore plus à l'aise avec jQuery qu'UIKit à ce moment-là) et l'ai publié en open source..
J'ai ensuite eu un coup de chance, car la société pour laquelle je travaille a eu l'opportunité de créer une application iPhone pour l'un de nos clients. En tant que seule à posséder une expérience iPhone, elle me l'a confiée. Je suis un développeur iOS à temps plein depuis. Depuis, j'ai également réécrit Rainbow Blocks en tant qu'application native à source fermée..
Comme beaucoup de programmeurs, j'ai un défaut de caractère qui me fait toujours essayer de résoudre le cas général au lieu de l'exigence spécifique. Cela me fait abandonner presque tous les projets que je commence parce que je m'embourbe à essayer de résoudre un problème qui n'est lié que de manière tangentielle à la tâche à accomplir..
Comme beaucoup de programmeurs, j'ai un défaut de caractère qui me fait toujours essayer de résoudre le cas général au lieu de l'exigence spécifique.
Mon disque dur est jonché de projets à moitié terminés (ou à peine démarrés) qui auraient été la prochaine grande chose mais ne verraient jamais la lumière du jour. Mais j’ai trouvé que l’open source était un peu un antidote à ce problème. Si je retire ces bouts de code utiles, les documente et les colle sur Github, je peux encore récupérer quelque chose de précieux de mes idées abandonnées.
De plus, au fur et à mesure que je construisais une bibliothèque de composants réutilisables, je me suis rendu compte que la création d’applications ressemblait à l’assemblage de briques lego. Au lieu de "Ce sera trop compliqué", je trouve que je peux répondre à la plupart des demandes de fonctionnalités avec "Aha! J'ai une bibliothèque pour cela".
En construisant une bibliothèque de composants réutilisables, j'ai découvert que la construction d'applications était devenue un processus d'assemblage de briques lego..
Quant à pourquoi je les partage? Ce n'est pas particulièrement un acte de philanthropie. Cela me procure un avantage personnel énorme, à la fois en termes de retour d'informations réel (rapports de bugs, corrections et demandes d'extraction) mais également en termes de reconnaissance. Mon open source est une vitrine pour mes services en tant que développeur.
Je ressens beaucoup de pression pour maintenir mes projets, mais je m'attendais à cela - cela explique en partie pourquoi je les ai publiés. Je ne suis pas très doué pour ma motivation personnelle et je travaille mieux lorsque je suis soumis à une pression externe. En publiant du code pour la communauté, je sais qu'ils vont me pousser à l'améliorer..
La partie la plus délicate consiste à savoir quand dire «non» aux fonctionnalités et aux demandes d'extraction. Il est difficile quand quelqu'un a passé plusieurs heures à ajouter quelque chose à l'une de mes bibliothèques pour dire «merci mais non merci», mais je dois le faire pour éviter toute déformation des fonctionnalités qui aggrave globalement la dégradation de la bibliothèque..
J'ai soumis quelques-unes d'entre elles à des sites tels que CocoaControls ou Binpress et les ai proposées comme réponses à des questions telles que "Comment créer un contrôle tel que coverflow" ou "Comment inciter les utilisateurs à évaluer mon application". iCarousel a remporté le concours de développement mobile Binpress en 2011, ce qui a probablement contribué à sa popularité.
Ces jours-ci, je poste surtout un message "regarde ce que j'ai fait" sur Twitter et laisse-le grandir à partir de là..
Je n'avais jamais vraiment utilisé Core Animation avant iCarousel. C'était un peu mon projet "Hello World" pour le framework Core Animation. C'était en 2011 cependant - j'en ai pas mal fait depuis!
Le livre n'était pas mon idée. Pearson m'a approché et m'a dit qu'ils préparaient une nouvelle série d'émissions mobiles exclusivement numériques et m'a demandé si j'aimerais écrire sur Core Animation. Il semblait que ça pourrait être amusant, alors j'ai dit OK.
Parce que UIKit est si puissant, beaucoup de développeurs se sentent un peu à l'aise dans ses limites et ne s'aventurent jamais au-delà. Je pense qu'il y a une fausse idée que si vous voulez faire quelque chose d'extraordinaire comme des interfaces 3D ou des effets de masquage, alors vous devez vous arrêter à tout faire avec OpenGL..
Je pense qu'il y a une idée fausse que si vous voulez faire quelque chose d'extraordinaire comme des interfaces 3D ou des effets de masquage, alors vous devez vous arrêter à tout faire avec OpenGL..
Un grand nombre des solutions de type coverflow qui existaient avant iCarousel ont été écrites directement dans OpenGL. C'était une chose assez commune que les gens voulaient faire, mais de nombreux développeurs n'ont simplement aucune idée de l'existence même de Core Animation, ni du fait qu'il s'agit d'une API simple et de haut niveau qui permet d'effectuer ce type d'effets facilement sans avoir à travailler au niveau des sommets et des shaders.
De nombreux développeurs n'ont simplement aucune idée de l'existence même de Core Animation, ni du fait qu'il s'agit d'une API simple et de haut niveau qui permet d'effectuer ce type d'effets facilement sans avoir à travailler au niveau des vertex et des shaders..
L'autre chose que je voulais aborder avec mon livre était la performance. Il est si facile de se tromper sur les performances lorsque vous traitez beaucoup d'images ou de dessins vectoriels. J'ai vu de nombreuses applications qui tremblaient et sautaient parce que les développeurs ne comprenaient tout simplement pas comment utiliser la puissance des threads et du GPU. Une bonne compréhension du fonctionnement de Core Animation est essentielle pour obtenir de bonnes performances d'une application..
Il est destiné aux lecteurs intermédiaires, mais il ne suppose pas une connaissance préalable de Core Animation..
Oui absolument. En fait, l'une des raisons pour lesquelles j'étais si désireux de le faire était la possibilité d'apprendre. Vous ne comprenez jamais vraiment quelque chose avant d'avoir essayé de l'expliquer à quelqu'un d'autre. Lors de mes recherches dans le livre, j'ai découvert de nombreuses nouvelles propriétés et caractéristiques, ainsi que des éclaircissements sur mes propres idées fausses. J'ai dû réécrire le chapitre 8 plusieurs fois parce que lorsque j'ai écrit les exemples, j'ai constaté que les animations ne fonctionnaient pas comme je le pensais (malgré le fait que je les utilisais depuis des années)..
En fait, je suis plutôt prudent quand il s'agit d'utiliser des outils de productivité. J'ai essayé beaucoup de choses, mais j'y tiens rarement.
Je fournis des podspecs pour la plupart de mes bibliothèques, mais je ne les utilise pas réellement. Ceci est principalement dû au fait que je déteste les bibliothèques statiques - chaque fois que cela est possible, j'importe les fichiers source directement afin de pouvoir suivre les problèmes rencontrés dans les composants tiers et apporter des corrections ou des améliorations..
Dans la mesure du possible, j'importe les fichiers source directement afin de pouvoir suivre les problèmes à l'intérieur de composants tiers et d'apporter des corrections ou des améliorations..
En plus de Xcode, je n’utilise que Tower (car le support git de Xcode est floconneux et que je n’aime pas utiliser la ligne de commande), Photoshop (parce que je ne fais pas confiance aux concepteurs pour couper les ressources), Resizer (pour la conversion par lots d’images Retina en standard def quand je suis trop paresseux pour les redessiner), et SubEthaEdit (parce que Xcode a des règles d'indentation bizarres pour les fichiers sources non-obj-C).
En fait, j'utilise rarement des bibliothèques tierces. 90% des bibliothèques que j'utilise sont les miennes, et si je trouve que je suis très dépendant d'une bibliothèque tierce, je finirai généralement par écrire ma propre version..
J'admire vraiment le travail de Mattt Thomson, mais je ne comprends pas l'obsession d'utiliser AFNetworking pour chaque tâche d'accès aux fichiers réseau. Le téléchargement d'un fichier de manière asynchrone sur une file d'attente en arrière-plan nécessite une ligne de code. L'interaction avec les services Web comporte bien d'autres choses, mais la plupart du temps, elles sont très spécifiques au service en question. Je n'ai pas encore trouvé de bibliothèque réseau tierce offrant un avantage substantiel par rapport au roulement d'une pile réseau sur mesure, mais c'est peut-être juste moi.
J'utilise Mantle récemment et j'aime la façon dont il gère le mappage des propriétés JSON, mais je l'ai encapsulé dans quelque chose de similaire à ma propre bibliothèque BaseModel afin de réduire le passe-partout consistant à spécifier des chemins de fichiers pour la persistance, etc..
Je ne peux pas penser à beaucoup de bibliothèques tierces que j'ai utilisées sur plus d'un projet (SDWebImage, peut-être), mais j'ai un tas de mes propres bibliothèques que j'utilise dans à peu près toutes les applications que j'écris (StandardPaths, ViewUtils, BaseModel, AutoCoding).
C'est quelque chose qu'on me demande souvent. Je recommanderais certainement
Début du développement iOS 6 (la dernière édition du livre sur lequel j'ai appris) et iOS 6: Repousser les limites. Cela vaut également la peine de regarder autant de vidéos officielles de WWDC que possible. Le site NSHipster de Matt Thomson mérite certainement d'être lu. Il existe également de nombreuses autres ressources intéressantes. Cacao avec amour, Cocoa is My Girlfriend, Cocoanetics, Ray Wanderlich et le blog de Mike Ash méritent tous le détour. Tout cela étant dit, j'ai tendance à utiliser Twitter plus que toute autre source pour rester au fait des choses.
Accentsconagua