Det var ikke så lenge siden at Apple overrasket iOS-utviklere med Swift. På kort tid siden da har det hatt et raskt tempo for adopsjon blant utviklingssamfunnet. Faktisk, i en undersøkelse utført av Stack Overflow, ble Swift kåret til det mest elskede programmeringsspråket.
Den 3. desember holdt Apple seg i sitt ord og offisielt laget Swift helt åpen kildekode. Gitt Swifts popularitet, er det absolutt spennende å tenke på implikasjonene av bevegelsen. Hva holder fremtiden for Swift, og hva kan vi gjøre som utviklere for å bidra til å forme utviklingen sin?
Ikke helt sikker på hva åpen kildekode betyr? Les Sam Bersons artikkel om åpen kilde her.
Som noen som liker å gjøre iOS-utvikling som en levende, har jeg alltid vært litt sjalu på open source-samfunnet. Selv om det er sant at GitHub trives med åpen kildekode-iOS-prosjekter, i både Swift og Objective-C, har Apple historisk sett ikke latt iOS-fellesskapet bidra mye til dets verktøy, rammer, IDE eller språk i noen offisiell kapasitet bortsett fra ResearchKit.
Nå, med Swift, har vi fått en invitasjon til å bidra til å fremme fremtiden for språket. Dette er en ny grense for iOS-fellesskapet, og jeg tror det vil også utvide litt godwill fra Apple til utviklerne som jobber på plattformene sine hver dag. I tillegg kan Swifts fremtid nå strekke seg langt ut over iOS-noe vi diskuterer senere.
En umiddelbar fordel av dette trekket, for meg i det minste, er at vi nå kan nyte et intimt blikk på Apples utviklingspraksis og prosesser. Faktisk har Swift's repository på GitHub alle forpliktelser for alle å se, dateres helt tilbake til det opprinnelige engasjementet den 17. juli 2010.
Hvis du ikke har tenkt på virkningen av Apples flytt til Open Source Swift, synes jeg det er viktig å ta et skritt tilbake og ta en titt på det. Historien viser at åpen sourcing et programvareprosjekt har mange fordeler.
Generelt utvikler et åpen kildekodeprosjekt som får traksjon i samfunnet seg raskt, og blir stabilere over tid. Hvis samfunnet er aktivt involvert, kan nye funksjoner implementeres raskt.
Bortsett fra raskere iterasjoner, hjelper samfunnet programvaren moden på en måte som er gunstig for de som bruker det mest. Åpen sourcing av et prosjekt resulterer også ofte i mer samarbeid i samfunnet, som er seier for alle involverte.
Listen fortsetter og fortsetter. I en verden som er avhengig av teknologi og verktøyene bak den, foreslår jeg at du aldri har vært viktigere og relevant for åpen programvare. Kraften til et samfunn som arbeider med programvare kan være en givende, og enda viktigere, produktivt initiativ.
Faktisk har vi sett Apple-partner opp med andre fremtredende teknologibedrifter for å hjelpe Swift til neste nivå. IBM ser ut til å ha stor interesse i å implementere Swift som serversidespråk, og du kan allerede nyte et utrolig prosjekt fra deres innsats i sin online swift sandbox.
Til slutt, åpne sourcing Swift betyr at det kommer til å endres i et raskt tempo. Vanligvis kan rask forandring bety hodepine for ingeniører. Vi har til og med sett dette i Swift til en viss grad. Swift 2 introduserte mange endringer som gjorde Swift 1-kode utdatert og ukomplisert.
Nøkkelen forskjellen nå er at Apple og og samfunnet er de som driver forandringen. Med en åpen dør se hva som skjer med Swift, kan utviklere være bedre forberedt på kommende endringer. Iterasjoner i programvare bør ikke være en øvelse i frustrasjon, det bør være en gunstig og velkomment praksis. Open source-programvare utmerker seg i den forbindelse.
For å demonstrere dette, vurder disse beregningene som Swift-depotet har opplevd på kort tid det har vært live:
I skrivende stund er Swift også jevnt trending på # 1-spot på GitHub. Det er ganske en suksess på kort tid, og det viser tydelig at utviklingssamfunnet generelt er klar og villig til å bidra.
Som utvikler er det energisk å se språket tilpasse seg allerede i et "open source" tempo. For eksempel har den populære iOS-utvikleren og forfatteren Erica Sadun allerede gjort et overbevisende tilfelle for å fjerne C-Style looping i Swift. Dess, --
og ++
operatørene er sannsynligvis på vei ut også.
Med tanke på disse fakta ser vi allerede Swift nytte av å være åpen kildekode. Ikke bare er den moden, blir gjort kompatibel med andre plattformer bortsett fra iOS, men utviklere kan også se endringene som skjer offentlig. Å tilpasse kodebaser for Swift 3 burde egentlig ikke være noe problem, fordi vi ikke lenger trenger å vente på neste WWDC for å bli gjort oppmerksom på fremskritt til språket.
Tatt i betraktning open source-effekten, lurer du kanskje på hvordan du skal involvere deg selv. Open source-programvare kan i utgangspunktet være litt skremmende hvis du ikke har vært involvert med det før. Her vil jeg påpeke noen måter du kan få en bedre følelse av for åpen kildekode, og spesielt Swift.
Et godt sted å begynne å bli involvert i open source Swift er diskusjonene selv. Det er overraskende at mange av disse diskusjonene kommer fra Twitter. Noen fremtredende feilrettinger nevnt over Twitter har selv blitt løst før Swift ble åpnet.
Utviklere kan enkelt stemme sine ideer til Swift ved hjelp av Twitters lave barriere for oppføring. Dessuten trenger du ikke å gå gjennom prosessen med å bidra med kode helt ennå. Det er en lav stress måte å begynne å bidra til Swift.
Det er også morsomt og lærerikt å samhandle med Swifts utviklere. De var ganske aktive på Twitter som ledet til åpen kildekodeflyt, og enda mer etter det. Når det er sagt, her er noen Apple-ingeniører som umiddelbart er involvert i Swift.
Chris er ansvarlig for å bringe oss med Swift, og han var også den opprinnelige forfatteren av LLVM-kompilatorinfrastrukturen. Han er selvsagt alltid engasjert i Swift-samfunnet. Faktisk har han selv akseptert trekkforespørsler kl 10:00 på en lørdag. Å si at han er aktivt involvert i prosjektet, ville være en underdrivelse.
Jordan er en annen topp-ingeniør fra Apple som primært fokuserer på Swift. Som Chris, er Jordan også en stor ressurs for å heve Swift spørsmål eller bekymringer.
Joe er også en dyktig ingeniør som jobber med Swift. Han har besvart flere spørsmål om Swift og er alltid glad for å engasjere seg i samfunnet.
Swifts open source-initiativ drives gjennom den populære GitHub-plattformen. Hvis du ikke er kjent med GitHub eller Git generelt, kan det være ganske skremmende å bidra til Swift. Hvis det er tilfelle for deg, vil jeg sterkt anbefale å bli kjent med disse verktøyene først, og dette er et bra sted å starte.
For å komme i gang må du sette opp et lokalt miljø. Swift's GitHub README er en utmerket guide for å følge, så jeg vil ikke gjenta disse trinnene her. I utgangspunktet, etter bare noen få kommandoer fra kommandolinjen og samspill med depotet, blir du oppe.
Når du bidrar til åpen kildekode programvare eller programvare generelt, er det godt å starte med et lite, håndterbart mål. Faktisk oppfordrer Chris Lattner det.
Prøv å finne noen deler av kodebasen og bli kjent med dem. Derfra vil du være bedre egnet til å se hva som kan forbedres. Personlig er det første skrittet jeg vil ta, å lese Swift Bidragende Guide.
Noen spennende (og overraskende) nyheter som kom fra Swifts open source-kunngjøring var noen prosjekter som er i utvikling med språket. Noen av dem var forventet, for eksempel kompilatoren og standardbiblioteket, og noen var helt nye tiltak.
Hver av de fire store prosjektene utvikles åpent, så bidrag er velkomne. La oss ta en kort titt på hver av dem nå.
Utført fra swift.org er Swifts kompilator hovedsakelig ansvarlig for å oversette Swift-kildekoden til effektiv, kjørbar maskinkode. "Selv om du ikke har en dyp forståelse av kompilatorer eller hvordan de fungerer, er det fascinerende å bla gjennom koden sin hvis kun for utdanningsformål.
Den andre komponenten av dette prosjektet, standardbiblioteket, er sannsynligvis noe de fleste utviklere vil bli kjent med. Den huser alt fra de mest grunnleggende datatyper, for eksempel int
og Dobbelt
typer, til avanserte samlingstyper, for eksempel Array
og Ordbok
.
Hvis du er en ivrig Swift-utvikler, har du nå muligheten til å hjelpe til å skape hvordan disse typene fungerer. Eller hvis du ville ha et spesialtilpasset sett som er spesifikt for dine behov, kan du til og med gaffle lageret og tilpasse Swifts typer som du ser.
IOS-fellesskapet har sett flere forskjellige veier for å distribuere kode. Noen populære valg inkluderer Cocoapods og Carthage. Nå kan vi legge til Swift Package Manager på den listen.
Selv om det er i de tidlige utviklingsstadiene, er dette prosjektet som jeg finner mest interessant. Faktisk støtter det for øyeblikket ikke iOS, tVOS eller watchOS. Mens støtte for disse plattformene sikkert kommer, da den modnes, kan det potensielt brukes til å distribuere Swift-kode langt utover bare iOS eller OS X.
Prosjektet Swift Core Library er nært knyttet til standardbiblioteket, bortsett fra at det gir høyere ordensfunksjonalitet. Verktøy som inngår i dette prosjektet, er vanligvis plattform agnostiske konsepter.
For eksempel huser kjernebiblioteksprosjektet funksjonalitet for JSON-parsing, enhetstesting og interaksjon med filsystemet. Dette er verktøy som vil avhenge av uansett plattform eller prosjekt ved hånden.
For å sette dette prosjektet i mer relatable vilkår for iOS og OS X utviklere, er libdispatch plassert her. Du er sannsynligvis kjent med det siden det er hvor Grand Central Dispatch kommer fra. Når det er sagt, er det fornuftig at det er inkludert i Kjernebiblioteker siden kjøring av samtidig kode er ikke en oppgave som er spesifikk for bare iOS eller OS X.
Til slutt er REPL- og Debugger-prosjektet sannsynligvis litt selvforklarende. Dette prosjektet er ansvarlig for implementeringen av Swifts fulle feilsøkingspakke. LLDB debugger er noe utviklere har brukt for en stund nå, fordi den er inkludert i Xcode.
REPL og Debugger er imidlertid svært koblet, noe som gir mening fordi de gir tilsvarende verdi på mange måter. REPL står for "Les Eval Print Loop", og det er flott å bruke til lett Swift-kode. Hvis du åpner terminal og skriver "Swift", begynner du å kjøre Swift REPL lokalt.
Som du kan se, er det absolutt ingen mangel på prosjekter eller komponenter av Swift å bidra til. Selv om cliché som det høres ut, er dette bare begynnelsen, og flere nye prosjekter vil dukke opp over tid.
For å pakke opp, vil jeg gi deg noen ressurser du kan bruke til å øke kunnskapen om Swifts open source-landskap.
Dette er den offisielle destinasjonen for hele Swifts utvikling. Den inneholder guider for å komme i gang, oppsummeringer av alle pågående prosjekter og mer. Dette bør være din knyttnevestopp hvis du vil bli involvert.
Mens denne har eksistert i en stund, hvis du ikke har besøkt den før du burde. Den inneholder mye nyttig informasjon om Swift og dens arkitektur skrevet av Chris Lattner. Selv om det fortsatt er å se om det vil bli opprettholdt i stedet for swift.org, er det fortsatt en verdifull ressurs.
Jeg har nevnt dette noen ganger nå, men det er her hvor Swift utvikler seg. Hvis du ønsker å bla gjennom kode, gaffelbibliotek eller sende inn forespørsler, er dette her hvor det skjer.
Dette er en utmerket adresseliste for å abonnere på hvis du først og fremst er interessert i å se hvordan Swift vil utvikle seg og hvilken retning språket tar. I tillegg er det flere andre adresselister å vurdere å abonnere på, som alle diskuterer ulike aspekter av Swifts utvikling. Du kan se dem alle her.
Som enhver annen programvare har Swift feil. Dette er den sentrale plasseringen som Swift-teamet bruker til å spore feil og følge dem til de er løst. Bortsett fra feil kan forbedringer også foreslås her.
Swift kommer til å spille en stor rolle i iOS utvikling fremover. Jeg tror utviklere har kjent at siden det ble annonsert på WWDC 14. Hva er spennende er at det nå vil manifestere seg utenfor bare Apples plattformer. Tenk deg å bruke Swift som serversidespråk når du utvikler en API?
Kanskje viktigere enn Swifts vekst er det faktum at samfunnet vil drive forandringen. Åpne sourcing Swift åpner mange dører for både deg og språket. Nå er det tid til å bli involvert, så begynn å lese de bidragende retningslinjene, og jeg gleder meg til å se ditt neste engasjement i Swift-depotet.