Bli en programmerer av åpen programvare

Forfatter: Morris Wright
Opprettelsesdato: 24 April 2021
Oppdater Dato: 1 Juli 2024
Anonim
Bli en programmerer av åpen programvare - Råd
Bli en programmerer av åpen programvare - Råd

Innhold

Å skrive og bruke åpen programvare er ikke bare en form for programmering (også kalt "hacking" i programmererens verden), det er en slags filosofi. Mens du bare trenger å kjenne et programmeringsspråk for å kunne kode, handler denne artikkelen om hvordan du kan bli med i samfunnet, få venner, samarbeide om flotte prosjekter og bli en respektert spesialist med en profil du ikke kan få andre steder. I en verden av åpen programvare kan du ganske enkelt få tildelt oppgaver som bare eliten, toppnivåprogrammerere, har lov til å gjøre i et selskap. Tenk på hvor mye erfaring dette kan gi deg. Når du har bestemt deg for å bli en åpen programvareprogrammerer, må du imidlertid være villig til å investere tid i dette målet. Dette gjelder også hvis du allerede er IT-student. Husk deg, denne artikkelen handler ikke om hvordan du kan bli en hacker eller cracker.

Å trå

  1. Last ned en god Unix-distribusjon. GNU / Linux er en av de mest populære for programmering, men GNU Hurd, BSD, Solaris og (til en viss grad) Mac OS X brukes også ofte.
  2. Lær hvordan du bruker kommandolinjen. Du kan gjøre mye mer med Unix-lignende operativsystemer hvis du bruker kommandolinjen.
  3. Lær noen populære programmeringsspråk til du når et mer eller mindre tilfredsstillende nivå. Ellers kan du ikke bidra med kode (den viktigste delen av ethvert programvareprosjekt) til det åpne programvaresamfunnet. Noen kilder antyder å starte med to språk samtidig: ett systemspråk (C, Java eller lignende) og et skriptspråk (Python, Ruby, Perl eller lignende).
  4. For å være mer produktiv trenger du NetBeans eller et lignende integrert utviklingsmiljø.
  5. Lær deg å bruke en avansert redaktør, for eksempel vi eller Emacs. De har en høyere læringskurve, men du kan gjøre mye mer med dem.
  6. Lær om versjonskontroll. Versjonskontroll er trolig det viktigste verktøyet i samarbeidet for delt programvareutvikling. Forstå hvordan du oppretter og bruker oppdateringer. Det meste av den åpne programvareutviklingen i samfunnet gjøres gjennom opprettelse, diskusjon og anvendelse av forskjellige oppdateringer.
  7. Finn et passende, lite åpent programvareprosjekt som du enkelt kan delta i for å få erfaring. De fleste slike prosjekter finner du på SourceForge.net i disse dager. Et passende prosjekt bør omfatte:
    1. Bruk programmeringsspråket du kjenner.
    2. Vær aktiv, med nylige utgivelser.
    3. Allerede bestående av tre til fem utviklere.
    4. For å bruke versjonskontroll.
    5. Ha en del som du kan komme i gang med en gang, uten å måtte endre den eksisterende koden for mye.
    6. I tillegg til koden har et godt prosjekt også aktive diskusjonslister, feilrapporter, får og implementerer forbedringsforespørsler og lignende aktiviteter.
  8. Kontakt administratoren for det valgte prosjektet. I et lite prosjekt med få utviklere vil din hjelp vanligvis bli akseptert umiddelbart.
  9. Les reglene for prosjektet nøye og følg dem mer eller mindre. Reglene for programmeringsstil eller behovet for å dokumentere endringene i en egen tekstfil kan virke latterlig i begynnelsen. Formålet med disse reglene er imidlertid å muliggjøre delt arbeid - og de fleste prosjekter jobber med dem.
  10. Arbeid med dette prosjektet i flere måneder. Lytt nøye til hva administratoren og andre prosjektmedlemmer har å si. Foruten programmering har du mange ting å lære. Men hvis du virkelig ikke liker noe, er det bare å stoppe og bytte til et annet prosjekt.
  11. Ikke bli sittende fast i det underjordiske prosjektet for lenge. Når du er i stand til å jobbe vellykket på det teamet, er det på tide å begynne å lete etter noe mer alvorlig.
  12. Se etter et seriøst, høyt nivå åpen programvare eller åpen kildekode-prosjekt. De fleste slike prosjekter eies av GNU- eller Apache-organisasjoner.
  13. Fordi vi tar et seriøst sprang her, må du ta hensyn til en mye mindre varm mottakelse. Du vil mest sannsynlig bli bedt om å kjøre uten direkte skrivetilgang til kodelageret for første gang. Det forrige underjordiske prosjektet burde imidlertid ha lært deg mye - så etter flere måneder med å gi et produktivt bidrag, kan du kreve rettighetene du mener du burde ha.
  14. Ta på deg en seriøs oppgave og regne den ut. Det er på tide. Ikke vær redd. Fortsett selv om du synes at oppgaven er mye vanskeligere enn du først trodde - i dette trinnet er det viktig å ikke gi opp.
  15. Hvis du kan, kan du søke på Googles "Summer of Code" for å sette penger i dette eventyret. Men ikke bekymre deg hvis søknaden ikke godtas, da de har langt færre finansierte stillinger enn det er veldig gode programmerere.
  16. Finn en passende konferanse som skjer i nærheten ("Linux dager" eller lignende) og prøv å presentere prosjektet ditt der (hele prosjektet, og ikke bare delen du programmerer). Etter at du har nevnt at du representerer et seriøst prosjekt med gratis / åpen kildekode, vil arrangørene ofte skadesløse deg fra konferanseavgiften (hvis ikke, vil konferansen sannsynligvis være uegnet uansett). Ta med Linux-bærbare datamaskiner (hvis du har en) og kjør noen demoer. Spør prosjektlederen om materialene du kan bruke til å forberede presentasjonen eller plakaten.
  17. Søk på Internett etter kunngjøringer om et installasjonsarrangement i nærheten, og prøv å delta som bruker først (merk alle problemene som oppstår og hvordan hackere løser dem) og tilbyr å installere programmer neste gang.
  18. Fullfør oppgaven, sjekk arbeidet ditt med automatiske tester og bidra til prosjektet. Du er ferdig! For å være sikker, prøv å møte noen av programmørene på prosjektet personlig og hev et glass øl sammen på resultatet.
  19. For en bedre forståelse, se på et reelt eksempel på utviklingshistorien til et åpent programvareprosjekt (se ovenfor). Hver stigende kurve representerer et bidrag (kodelinjer) fra en enkelt utvikler. Utviklere har en tendens til å bli mindre aktive med alderen, men prosjektet øker ofte selv når nye mennesker blir med. Så hvis du kommer med noen nyttige ferdigheter i lommen, er det ingen grunner til at teamet ikke skal invitere deg.

Tips

  • Før du stiller et spørsmål om de praktiske kravene i prosjektet, må du se etter svaret i prosjektdokumentasjonen og adresselistearkivet.
  • Forsøk alltid å fullføre programmeringsarbeidet du startet. Kan ikke bygges, kan ikke kjøre, systemkrasj? Der å være grunner til alt, og hvis du har kildekoden, betyr det vanligvis at du har systemet vi vil kan tvinge deg til å gjøre hva du vil, spesielt ved hjelp av online forskning. Denne regelen har selvfølgelig grenser, men det er virkelig viktig å aldri gi opp for lett.
  • Kall deg selv en programmerer (eller hacker) bare etter at du har blitt anerkjent som sådan av noen av det virkelige hacker-samfunnet.
  • I begynnelsen velger du en klasse, modul eller annen enhet der ingen jobber veldig aktivt for øyeblikket. Å jobbe sammen i samme klasse eller til og med en stilling krever flere ferdigheter og omsorg fra alle sider.
  • Arbeidsgivere av noen hackere / programmerere virker motiverte nok til å tillate bidrag i arbeidstiden (vanligvis fordi institusjonen bruker det gratis / åpen kildekode-programmet programmereren utvikler). Tenk, kanskje du kan få i det minste noe av tiden som trengs på denne måten.
  • Hvis du fremdeles ikke har nok tillit til deg selv, kan du starte fra en del av koden du tror mangler og som kan skrives fra bunnen av. Endringer i eksisterende kode er mye mer sannsynlig å bli kritisert.

Advarsler

  • Din hacker-status i fellesskapsprosjektet er mer en refleksjon av din nåtid enn din fortid.Hvis du ønsker en anbefaling eller lignende fra prosjektlederen, kan du spørre om du fortsatt bidrar aktivt.
  • Ikke gå inn i små kodeoptimaliseringer, ekstra kommentarer, kodestilforbedringer og andre lignende "småskala" ting. Dette kan møte mye mer kritikk enn et seriøst bidrag. I stedet kan du inkludere disse endringene i en enkelt "oppryddings" -oppdatering.
  • Hvis du planlegger å møte de åpne programvarehackerne personlig, må du la Windows-datamaskinen være hjemme. Mac OS tolereres litt mer, men det er heller ikke veldig velkommen. Hvis du tar med den bærbare datamaskinen din, må den kjøre Linux eller et annet operativsystem som de anser som "åpen programvare."
  • Hvis e-postklienten din støtter HTML-meldinger, bør du deaktivere denne funksjonen. Legg aldri ved dokumenter som bare kommersiell programvare (for eksempel Microsoft Word) kan åpne ordentlig. Hackere anser dette som støtende.
  • Ikke meld deg frivillig til prosjekter fra et selskap hvis kode ikke er dekket av en godkjent åpen kildekode-lisens. I slike tilfeller vil de virkelig viktige delene av prosjektet sannsynligvis forbli bak lukkede dører fra eieren, og hindrer deg i å lære noe nyttig.
  • Unngå spørsmål om grunnleggende programmerings- eller programmeringsverktøy. Tiden til en åpen programvareprogrammerer er dyrebar. Diskuter i stedet det grunnleggende om programmering i amatør- eller begynnerprogrammeringsgrupper.
  • Etablerte og svært vellykkede prosjekter kan ha skrevet eller uskrevet policy om å aldri refundere arbeidet ditt (ingen penger, ingen evne til å markedsføre deg selv, ingen forhøyet status uavhengig av ditt bidrag osv. - se: Do_not_expect_reward Wikipedia). Hvis du ikke kan være enig i dette, hold deg til mer vanlige prosjekter som ikke har råd til en slik holdning.
  • Ikke start ditt eget prosjekt med mindre du alltid vil bruke stolt ensomhet. Av samme grunn er det bedre å ikke sette i gang et forsøk på å gjenopplive et allerede forlatt prosjekt som dets forrige team allerede har mistet.
  • I tilfelle et uformelt møte om prosjektet som du aldri har bidratt med noen kode til, vil du ha den ubehagelige følelsen av å bli fullstendig ignorert. Ikke bekymre deg, noen hackere kan bli gode venner senere etter at du tjener respekt for dem med din egen kode.
  • Store åpne programvareprosjekter, spesielt de rundt GNU-domenet, behandler ikke jobben din som din personlige virksomhet. Etter at du har fått jobben i et programvarerelatert selskap, ber de arbeidsgiveren din om å signere visse avtaler [1], som selskapet vil eller ikke vil signere. Dette kan tvinge deg til å velge et prosjekt med mindre strenge krav.

Nødvendigheter

  • Linux. Mange åpne programvareprosjekter er mer kompliserte å bygge på Windows, eller er ikke i det hele tatt bygget riktig. Dette gjelder spesielt for avanserte prosjekter dedikert til programmering av mobiltelefoner, USB-nøkler og andre enheter.
  • En datamaskin med relativt god internettforbindelse. Hvis du vil beholde dobbelt oppstart med Windows, kan en annen harddisk eller partisjon for Linux være en god løsning.
  • Grunnleggende kunnskaper om minst ett programmeringsspråk og en sterk intensjon om å lære mer. De mest populære språkene ser for tiden ut til å være C og Java.
  • En betydelig tid, minst fem timer i uken (en typisk hardcore-programmerer bidrar med hele 14 timer).
  • Mens formell IT-utdanning vil gjøre veien mye enklere, er dette det ikke et obligatorisk krav, og ingen reelle hackersamfunn vil noen gang spørre deg om det. Programmerere / hackere bedømmer hverandre etter noens programmering, ikke falske kriterier som karakterer, alder, rase eller stilling. Vær oppmerksom på at minst 60% av åpen kildekode-hackere som vurderer oppdateringene dine har "riktig" høyskoleeksamen og vil ikke tillate deg å bidra med tull til prosjektet.
  • I løpet av de siste trinnene (konferanse og 'installer fest') kan du dra nytte av din egen bærbare datamaskin. Men det er ikke greit å jobbe med det hjemme, så kjøp bare en hvis du har råd til den andre maskinen.
  • Stien som er beskrevet for å bli en "hacker" med åpen kildekode, tar minst to år å fullføre.