Bliv programmør af åben software

Forfatter: Morris Wright
Oprettelsesdato: 24 April 2021
Opdateringsdato: 1 Juli 2024
Anonim
Bliv programmør af åben software - Råd
Bliv programmør af åben software - Råd

Indhold

Skrivning og brug af åben software er ikke kun en form for programmering (også kaldet "hacking" i programmørernes verden), det er en slags filosofi. Mens du kun behøver at kende et programmeringssprog for at kunne kode, handler denne artikel om, hvordan du kan deltage i samfundet, få venner, samarbejde om store projekter og blive en respekteret specialist med en profil, du ikke kan få andre steder. I en verden af ​​åben software kan du ganske let få tildelt opgaver, som kun eliten, programmører på øverste niveau, har lov til at udføre i en virksomhed. Tænk på, hvor meget erfaring dette kan give dig. Når du først har besluttet at blive en åben softwareprogrammerer, skal du dog være villig til at investere tid i dette mål. Dette gælder også, hvis du allerede er IT-studerende. Husk dig, denne artikel handler ikke om, hvordan man bliver hacker eller cracker.

At træde

  1. Download en god Unix-distribution. GNU / Linux er en af ​​de mest populære til programmering, men GNU Hurd, BSD, Solaris og (til en vis grad) Mac OS X bruges også ofte.
  2. Lær hvordan du bruger kommandolinjen. Du kan gøre meget mere med Unix-lignende operativsystemer, hvis du bruger kommandolinjen.
  3. Lær nogle populære programmeringssprog, indtil du når et mere eller mindre tilfredsstillende niveau. Ellers kan du ikke bidrage med kode (den vigtigste del af ethvert softwareprojekt) til det åbne softwarefællesskab. Nogle kilder foreslår at starte med to sprog på én gang: et systemsprog (C, Java eller lignende) og et script-sprog (Python, Ruby, Perl eller lignende).
  4. For at være mere produktiv har du brug for NetBeans eller et lignende integreret udviklingsmiljø.
  5. Lær at bruge en avanceret editor, f.eks. Vi eller Emacs. De har en højere indlæringskurve, men du kan gøre meget mere med dem.
  6. Lær om versionskontrol. Versionskontrol er sandsynligvis det vigtigste værktøj i samarbejdet til delt softwareudvikling. Forstå, hvordan du opretter og anvender programrettelser. Det meste af den åbne softwareudvikling i samfundet sker gennem oprettelse, diskussion og anvendelse af forskellige programrettelser.
  7. Find et passende, lille åbent softwareprojekt, som du let kan deltage i for at få erfaring. De fleste af disse projekter kan findes på SourceForge.net i disse dage. Et passende projekt skal omfatte:
    1. Brug det programmeringssprog, du kender.
    2. Vær aktiv med de seneste udgivelser.
    3. Består allerede af tre til fem udviklere.
    4. For at bruge versionskontrol.
    5. Har en del, som du kan komme i gang med det samme uden at skulle ændre den eksisterende kode for meget.
    6. Ud over koden har et godt projekt også aktive diskussionslister, fejlrapporter, får og implementerer forbedringsanmodninger og lignende aktiviteter.
  8. Kontakt administratoren for det valgte projekt. I et lille projekt med få udviklere accepteres din hjælp normalt med det samme.
  9. Læs projektets regler omhyggeligt, og følg dem mere eller mindre. Reglerne for programmeringsstil eller behovet for at dokumentere dine ændringer i en separat tekstfil kan i første omgang virke latterlige. Formålet med disse regler er imidlertid at muliggøre delt arbejde - og de fleste projekter arbejder med dem.
  10. Arbejd med dette projekt i flere måneder. Lyt omhyggeligt til, hvad administratoren og andre projektmedlemmer har at sige. Udover programmering har du mange ting at lære. Men hvis du virkelig ikke kan lide noget, skal du bare stoppe og skifte til et andet projekt.
  11. Bliv ikke fast i det underjordiske projekt for længe. Når du først er i stand til at arbejde med succes på det hold, er det tid til at begynde at lede efter noget mere seriøst.
  12. Kig efter et seriøst, åbent software- eller open source-projekt på højt niveau. De fleste sådanne projekter ejes af GNU- eller Apache-organisationer.
  13. Fordi vi tager et alvorligt spring her, skal du tage højde for en langt mindre varm modtagelse. Du vil højst sandsynligt blive bedt om at køre uden direkte skriveadgang til kodelageret for første gang. Det tidligere underjordiske projekt burde imidlertid have lært dig meget - så efter flere måneders levering af et produktivt bidrag kan du gøre krav på de rettigheder, du synes, du skulle have.
  14. Tag en seriøs opgave på og udarbejd den. Det er tid. Vær ikke bange. Fortsæt, selvom du finder ud af, at opgaven er meget vanskeligere, end du oprindeligt troede - i dette trin er det vigtigt ikke at give op.
  15. Hvis du kan, skal du ansøge om Googles "Summer of Code" for at lægge nogle penge i dette eventyr. Men rolig, hvis ansøgningen ikke accepteres, da de har langt færre finansierede positioner, end der er rigtig gode programmører.
  16. Find en passende konference, der finder sted i nærheden ("Linux dage" eller lignende), og prøv at præsentere dit projekt der (hele projektet, og ikke kun den del, du programmerer). Når du har nævnt, at du repræsenterer et seriøst gratis / open source-projekt, vil arrangørerne ofte skadesløse dig fra konferencegebyret (hvis ikke, vil konferencen sandsynligvis være uegnet alligevel). Medbring din Linux-bærbare computer (hvis du har en), og kør nogle demoer. Spørg projektlederen om de materialer, du kan bruge til at forberede din præsentation eller plakat.
  17. Søg på Internettet efter meddelelser om en installationshændelse i nærheden, og prøv først at deltage som bruger (bemærk alle de problemer, der opstår, og hvordan hackere løser dem), og tilbud om at installere programmer næste gang.
  18. Gennemfør opgaven, tjek dit arbejde med automatiske tests og bidrager til projektet. Du er færdig! For at være sikker, prøv at møde nogle af programmørerne om projektet personligt og løft et glas øl sammen om resultatet.
  19. For en bedre forståelse, se på et reelt eksempel på udviklingshistorikken for et åbent softwareprojekt (se ovenfor). Hver stigende kurve repræsenterer et bidrag (kodelinjer) fra en enkelt udvikler. Udviklere har tendens til at blive mindre aktive med alderen, men projektet fremskynder ofte, selv når nye mennesker deltager. Så hvis du ankommer med nogle nyttige færdigheder i lommen, er der ingen grunde til, at holdet ikke skal invitere dig.

Tips

  • Inden du stiller et spørgsmål om de praktiske krav i projektet, skal du kigge efter svaret i projektdokumentationen og postlistearkivet.
  • Fortsæt altid med at afslutte ethvert programmeringsarbejde, du startede. Kan ikke bygges, kan ikke køre, systemnedbrud? Der at være grunde til alt, og hvis du har kildekoden, betyder det normalt, at du har systemet godt kan tvinge dig til at gøre hvad du vil, især ved hjælp af online-research. Denne regel har selvfølgelig grænser, men det er virkelig vigtigt aldrig at give op for let.
  • Kald dig selv en programmør (eller hacker), først efter at du er blevet anerkendt som sådan af nogle af det virkelige hacker-samfund.
  • I starten skal du vælge en klasse, et modul eller en anden enhed, hvor ingen i øjeblikket arbejder meget aktivt. At arbejde sammen på den samme klasse eller endda en stilling kræver flere færdigheder og pleje fra alle sider.
  • Arbejdsgivere hos nogle hackere / programmører synes motiverede nok til at tillade bidrag i arbejdstiden (normalt fordi institutionen bruger det gratis / open source-program, som programmøren udvikler). Tænk, måske kan du få i det mindste noget af den nødvendige tid på denne måde.
  • Hvis du stadig ikke har tilstrækkelig tillid til dig selv, skal du starte fra en del af koden, som du mener mangler og kan skrives fra bunden. Ændringer i eksisterende kode er meget mere tilbøjelige til at blive kritiseret.

Advarsler

  • Din hacker-status inden for fællesskabsprojektet afspejler mere din nutid end din fortid.Hvis du ønsker en anbefaling eller lignende fra projektlederen, så spørg om du stadig bidrager aktivt.
  • Kom ikke ind i små kodeoptimeringer, ekstra kommentarer, forbedringer i kodestil og andre lignende "småskala" ting. Dette kan mødes med langt mere kritik end et seriøst bidrag. I stedet kan du medtage disse ændringer i en enkelt "oprydning" -plaster.
  • Hvis du planlægger at møde de åbne software-hackere personligt, skal du lade din Windows-laptop være hjemme. Mac OS tolereres lidt mere, men det er heller ikke rigtig velkomment. Hvis du medbringer din bærbare computer, skal den køre Linux eller et andet operativsystem, som de betragter som "åben software."
  • Hvis din e-mail-klient understøtter HTML-beskeder, skal du deaktivere denne funktion. Vedhæft aldrig dokumenter, som kun kommerciel software (såsom Microsoft Word) kan åbnes korrekt. Hackere betragter dette som stødende.
  • Vær ikke frivillig i projekter fra et firma, hvis kode ikke er dækket af en godkendt open source-licens. I sådanne tilfælde forbliver de virkelig vigtige dele af projektet sandsynligvis bag lukkede døre fra ejeren, hvilket forhindrer dig i at lære noget nyttigt.
  • Undgå ethvert spørgsmål om det grundlæggende ved programmering eller programmeringsværktøjer. Tiden for en åben softwareprogrammerer er dyrebar. I stedet skal du diskutere det grundlæggende ved programmering i amatør- eller begyndelsesgrupper.
  • Etablerede og meget succesrige projekter kan have skriftlige eller uskrevne politikker om aldrig at godtgøre dit arbejde (ingen penge, ingen evne til at promovere dig selv, ingen forhøjet status uanset dit bidrag osv. - se: Do_not_expect_reward Wikipedia). Hvis du ikke kan være enig i dette, skal du holde dig til mere almindelige projekter, der ikke har råd til en sådan holdning.
  • Start ikke dit eget projekt, medmindre du altid vil bruge stolt ensomhed. Af samme grund er det bedre ikke at gå i gang med et forsøg på at genoplive et allerede forladt projekt, som dets tidligere team allerede har mistet.
  • I tilfælde af et uformelt møde om projektet, som du aldrig har bidraget med nogen kode til, vil du have den ubehagelige følelse af at blive fuldstændig ignoreret. Bare rolig, nogle hackere kan blive gode venner senere, efter at du har optjent deres respekt med din egen kode.
  • Store åbne softwareprojekter, især dem omkring GNU-domænet, behandler ikke dit job som din personlige forretning. Når du har fået jobbet i en software-relateret virksomhed, beder de din arbejdsgiver om at underskrive visse aftaler [1], som virksomheden vil eller ikke vil underskrive. Dette kan tvinge dig til at vælge et projekt med mindre strenge krav.

Nødvendigheder

  • Linux. Mange åbne softwareprojekter er mere komplicerede at bygge på Windows eller er slet ikke bygget korrekt. Dette gælder især for avancerede projekter dedikeret til programmering af mobiltelefoner, USB-nøgler og andre enheder.
  • En computer med en relativt god internetforbindelse. Hvis du vil beholde dobbeltstart med Windows, kan en anden harddisk eller partition til Linux være en god løsning.
  • Grundlæggende viden om mindst et programmeringssprog og en stærk intention om at lære mere. De mest populære sprog synes i øjeblikket at være C og Java.
  • En betydelig tid, mindst fem timer om ugen (en typisk hardcore-programmør bidrager med hele 14 timer).
  • Mens formel it-uddannelse vil gøre din vej meget lettere, er det det ikke et obligatorisk krav, og intet ægte hackersamfund vil nogensinde spørge dig om det. Programmører / hackere bedømmer hinanden efter andres programmering, ikke falske kriterier som karakterer, alder, race eller position. Mind dig, mindst 60% af open source-hackere, der vurderer dine programrettelser, har den "korrekte" universitetsgrad og vil ikke tillade dig at bidrage med vrøvl til projektet.
  • I løbet af de sidste trin (konference og 'installer fest') kan du drage fordel af din egen bærbare computer. Men det er ikke okay at arbejde på det derhjemme, så køb kun en, hvis du har råd til den anden maskine.
  • Den sti, der er beskrevet for at blive en "hacker" til open source-software, tager mindst to år at gennemføre.