Share
In dit interview praat ik met de toonaangevende iOS-ontwikkelaar Nick Lockwood over zijn open source-bijdragen, zijn ontwikkelingswerkstroom en de educatieve bronnen die hij nuttig heeft gevonden bij het beheersen van de SDK.
Nick Lockwood is een toonaangevende iOS-ontwikkelaar en auteur van vele populaire open source-projecten, waaronder iCarousel, iRate en FXBlurView.
Nick heeft onlangs het boek iOS Core Animation: Advanced Techniques geschreven, uitgegeven door Addison-Wesley, en we hebben een fragment uit hoofdstuk 5 samen met dit bericht verstrekt.
Ik heb voor het eerst een programmeerboek opgehaald toen ik 12 jaar oud was. Ik herinner me de naam van het boek niet precies - zoiets als 'Basic Programming on the BBC Micro' - maar het was een cruciaal moment in mijn leven.
Ik studeerde elektronische engineering en vervolgens informatica aan de universiteit. De eerste was interessant, maar niet bijzonder relevant voor mijn latere carrière; De laatste leerde me de fundamenten van datastructuren en algoritmen, wat heel nuttig is gebleken.
Na mijn afstuderen heb ik mijn bedrijf Charcoal Design gemaakt, waarbij ik eenvoudige Mac-spellen en hulpprogramma's verkocht die zijn geschreven in REALbasic. Dat verdiende niet echt, dus deed ik wat freelance webontwikkeling om de eindjes aan elkaar te knopen.
Mijn eerste echte baan was als een front-end webontwikkelaar, die aanvankelijk helemaal niet veel met programmeren te maken had, totdat JavaScript echt volwassen werd en de front-end webontwikkeling een goede software engineering discipline werd in plaats van gewoon zijn over wie de meest esoterische IE 6 CSS-bugs kende.
Ik zag dat de iPhone een grote impact zou hebben op het mobiele internet toen het voor het eerst werd uitgebracht, maar ik heb er niet echt veel over nagedacht. In het Verenigd Koninkrijk kocht niemand de 1e gen-iPhone - het was te duur en we hadden al behoorlijk goede (en veel kleinere) functietelefoons.
Dat veranderde 's nachts toen de iPhone 3G werd verzonden. Ik kreeg mijn eerste iPhone in juli 2008. En kocht begin van de iPhone 2-ontwikkeling, zodat ik kon leren om het te programmeren. Ik had al met Objective-C op de Mac gewerkt, dus ik heb de basics vrij snel opgepikt. Ik heb Rainbow Blocks geschreven als een HTML5-app die wordt uitgevoerd in een UIWebView op volledig scherm (ik was toen nog comfortabeler met jQuery dan UIKit) en heb deze uitgebracht als open source.
Ik heb toen een geluksvakantie gepleegd omdat het bedrijf waar ik voor werk de gelegenheid kreeg om een iPhone-app voor een van onze klanten te bouwen, en als enige met een iPhone-ervaring, gaven ze het aan mij om te bouwen. Ik ben sindsdien een fulltime iOS-ontwikkelaar. Ik heb sindsdien Rainbow Blocks herschreven als een native-app met gesloten bronnen.
Zoals veel programmeurs heb ik een karakterfout waardoor ik altijd probeer het algemene geval op te lossen in plaats van de specifieke vereiste. Dit zorgt ervoor dat ik bijna elk project dat ik start verlaat, omdat ik verzand in een poging om een probleem op te lossen dat slechts tangentief gerelateerd is aan de taak die voorhanden is.
Zoals veel programmeurs heb ik een karakterfout waardoor ik altijd probeer het algemene geval op te lossen in plaats van de specifieke vereiste.
Mijn harde schijf is bezaaid met halfafgewerkte (of nauwelijks gestarte) projecten die het volgende grote ding zouden zijn geweest maar nooit het daglicht zullen zien. Maar ik ontdekte dat open source een beetje een tegengif is voor dit probleem. Als ik die nuttige stukjes code eruit haal, ze documenteer en ze op Github plak, dan kan ik nog steeds iets waardevols redden van mijn achtergelaten ideeën.
Gaandeweg, toen ik een bibliotheek met herbruikbare componenten had opgebouwd, ontdekte ik dat het bouwen van apps net zoiets is geworden als het monteren van legostenen. In plaats van "Dat zal te ingewikkeld zijn", merk ik dat ik de meeste functieverzoeken kan beantwoorden met "Aha! Ik heb daar een bibliotheek voor".
Omdat ik een bibliotheek met herbruikbare componenten heb opgebouwd, heb ik geconstateerd dat het bouwen van apps is geworden als het assembleren van legostenen.
Wat betreft waarom ik ze deel? Het is niet bepaald een daad van filantropie. Ik krijg hier een enorm persoonlijk voordeel van, zowel in termen van feitelijke feedback (bugrapporten, fixes en pull-requests), maar ook van herkenning. Mijn open source is een etalage voor mijn diensten als ontwikkelaar.
Ik voel veel druk om mijn projecten te onderhouden, maar ik verwachtte dat - het is een deel van waarom ik ze in de eerste plaats heb vrijgegeven. Ik ben niet erg goed in zelfmotivatie en ik werk beter wanneer ik onder een beetje externe druk sta, dus door het vrijgeven van code aan de community weet ik dat ze me zullen stimuleren om het te verbeteren.
Het lastigste is weten wanneer u "nee" moet zeggen tegen functies en pull-aanvragen. Het is moeilijk als iemand meerdere uren heeft besteed aan het toevoegen van iets aan een van mijn libs om te zeggen "bedankt maar niet bedankt", maar ik moet het doen om te voorkomen dat er een feature creep optreedt waardoor de bibliotheek slechter wordt.
Ik heb een paar van hen ingediend op sites als CocoaControls of Binpress en aangeboden als antwoorden op Stack Overflow-vragen zoals "Hoe kan ik een regeling zoals coverflow maken" of "Hoe kan ik gebruikers vragen om mijn app te beoordelen". iCarousel won de mobiele ontwikkelingswedstrijd van Binpress in 2011, die waarschijnlijk zijn populariteit enigszins heeft bevorderd.
Tegenwoordig post ik meestal een "kijk wat ik heb gemaakt" bericht op Twitter en laat het van daar groeien.
Ik had nooit echt iets met Core Animation gedaan voorafgaand aan iCarousel. Het was een soort van mijn "Hello World" -project voor het Core Animation-framework. Dat was echter al in 2011 - ik heb er sindsdien behoorlijk veel mee gedaan!
Het boek was niet mijn idee; Pearson benaderde me en zei dat ze bezig waren met een nieuwe digitale mobiele programmeringsreeks en vroeg of ik geïnteresseerd zou zijn in het schrijven over Core Animation. Het leek alsof het leuk was, dus ik zei OK.
Omdat UIKit zo krachtig is, krijgen veel ontwikkelaars een beetje een comfortabel gevoel in de beslotenheid en gaan ze nooit verder. Ik denk dat er een misvatting is dat als je iets leuks wilt doen, zoals 3D-interfaces of maskeereffecten, je alles moet doen met OpenGL.
Ik denk dat er een misvatting is dat als je iets leuks wilt doen, zoals 3D-interfaces of maskeereffecten, je alles moet doen met OpenGL.
Veel van de coverflow-achtige oplossingen die bestonden vóór iCarousel, werden rechtstreeks in OpenGL geschreven. Het was heel gebruikelijk dat mensen wilden doen, maar veel ontwikkelaars hebben eenvoudig geen idee dat Core Animation zelfs bestaat, of dat het een eenvoudige API van hoog niveau is die dit soort effecten gemakkelijk kan doen zonder op het niveau te hoeven werken van vertexen en shaders.
Veel ontwikkelaars hebben eenvoudig geen idee dat Core Animation zelfs bestaat, of dat het een eenvoudige API van hoog niveau is die dit soort effecten gemakkelijk kan uitvoeren zonder op het niveau van vertexen en shaders te moeten werken..
Het andere dat ik met mijn boek wilde bespreken, was de uitvoering. Prestaties zijn zo gemakkelijk om fout te raken als je te maken hebt met veel afbeeldingen of vectortekenen. Ik heb veel apps gezien die trillen en overslaan omdat ontwikkelaars gewoon niet begrijpen hoe ze de kracht van threads en de GPU moeten gebruiken. Een goed begrip van hoe Core Animation werkt, is cruciaal om goede prestaties uit een app te halen.
Het is bedoeld voor gemiddelde lezers, maar het veronderstelt geen voorkennis van Core Animation.
Ja absoluut. In feite was een van de redenen waarom ik het zo graag wilde doen, vanwege de kans op leren. Je begrijpt nooit echt iets totdat je geprobeerd hebt het aan iemand anders uit te leggen. Ik vond veel nieuwe eigenschappen en functies bij het onderzoeken van het boek, en het opruimen van veel van mijn eigen misvattingen. Ik moest hoofdstuk 8 verschillende keren herschrijven, want toen ik de voorbeelden schreef, merkte ik dat animaties niet werkten zoals ik dacht dat ze deden (ondanks het feit dat ik ze al jaren gebruik).
Ik ben eigenlijk vrij conservatief als het gaat om het gebruik van productiviteitstools. Ik heb veel dingen geprobeerd, maar ik blijf zelden bij ze.
Ik voorzie Podspecs voor de meeste van mijn bibliotheken, maar ik gebruik ze niet echt. Dit komt vooral omdat ik een hekel heb aan statische bibliotheken - waar mogelijk importeer ik de bronbestanden rechtstreeks zodat ik problemen in externe componenten kan traceren en correcties of verbeteringen kan aanbrengen.
Waar mogelijk importeer ik de bronbestanden rechtstreeks zodat ik problemen binnen componenten van derden kan traceren en correcties of verbeteringen kan aanbrengen.
Naast Xcode, gebruik ik alleen Tower (omdat de git-ondersteuning van Xcode schilferig is en ik de opdrachtregel niet gebruik), Photoshop (omdat ik de ontwerpers niet vertrouw om materiaal te knippen), Resizer (voor batchconversie van Retina-afbeeldingen naar standaard def als ik te lui ben om ze opnieuw te tekenen), en SubEthaEdit (omdat Xcode rare inspringregels heeft voor niet-obj-C bronbestanden).
Ik gebruik eigenlijk zelden bibliotheken van derden. 90% van de libs die ik gebruik is van mijzelf, en als ik merk dat ik erg afhankelijk ben van een derde-partij-lib, zal ik meestal uiteindelijk mijn eigen versie schrijven.
Ik bewonder het werk van Mattt Thomson, maar ik krijg niet de obsessie met het gebruik van AFNetworking voor elke toegang tot het netwerk. Het downloaden van een bestand asynchroon in een achtergrondwachtrij kost één regel code. Er is zeker veel meer om te communiceren met webservices, maar het is vooral heel specifiek voor de service in kwestie. Ik moet nog een netwerkbibliotheek van een derde partij vinden die een substantieel voordeel biedt boven het rollen van een op maat gemaakte netwerkstack, maar misschien ben ik dat gewoon.
Ik heb de laatste tijd Mantle gebruikt, en ik vind de manier waarop het JSON-eigenschappen in kaart brengt leuk, maar ik heb het verpakt in iets dat lijkt op mijn eigen BaseModel-bibliotheek om de boilerplate te verminderen van het specificeren van bestandspaden voor persistentie, enz..
Ik kan niet veel externe bibliotheken bedenken die ik op meer dan één project heb gebruikt (SDWebImage, misschien), maar ik heb een heleboel van mijn eigen libs die ik gebruik in zowat elke app die ik schrijf (StandardPaths, ViewUtils, BaseModel, AutoCoding).
Dat is iets dat ik eigenlijk veel wordt gevraagd. Ik zou het zeker aanbevelen
Begin iOS 6 Development (de nieuwste editie van het boek waar ik van heb geleerd) en iOS 6: Pushing the Limits. Het is ook de moeite waard om zoveel mogelijk officiële WWDC-video's te bekijken. De NSHipster-site van Matt Thomson is zeker het lezen waard. Er zijn ook veel andere goede bronnen. Cocoa with Love, Cocoa is My Girlfriend, Cocoanetics, Ray Wanderlich en Mike Ash's blog zijn allemaal de moeite van het bekijken waard. Dat gezegd hebbende, heb ik de neiging om Twitter meer dan welke bron dan ook te gebruiken om op de hoogte te blijven.
Accentsconagua