Bedriftspraksis. David Andreas Helgestad EVRY Østfold Høgskolen i Østfold

Transkript

1 Bedriftspraksis David Andreas Helgestad EVRY Østfold Høgskolen i Østfold

2 Takk til EVRY Østfold for at jeg fikk ha min praksisperiode hos dere. Fagansvarlig Gunnar Misund for veiledning og raske svar. 1

3 Innholdsfortegnelse 1 Innledning Terminologi Praksisplassen Prosjektet Oppgaven Arbeidet Refleksjoner Planlegging Utvikling Administrativt Oppsummering Vedlegg Attest Vedlegg Timeliste

4 1 Innledning I løpet av faget bedriftspraksis har jeg vært så heldig å få ha praksis hos EVRY Østfold, jeg skal i denne oppgava skrive om hva jeg har jobbet med samt erfaringer og refleksjoner jeg har gjort som følge av det. Noe av det første jeg merket når jeg kom i praksis var hvordan de som jobber der snakker med hverandre. Det er svært mange tekniske begreper som blir brukt i dagligtale, så jeg måtte bruke litt tid på å bli vant til det og å gjøre det selv i like stor grad. Derfor vil også denne rapporten være ganske teknisk i språket, da det er naturlig i en rapport om en praksis med utviklingsoppgave. Det har også vært litt utfordrende å finne gode norske ord ettersom alle IT-begrepene er engelske. Derfor der det ikke er naturlig å gjøre en fornorskning skriver jeg det engelske ordet. I tillegg til å forklare mye underveis er det også en liten liste over terminologi som er brukt i teksten. 1.1 Terminologi MongoDB: Er en åpen kildekode dokumentdatabase, og verdens mest populære NOSQL database. Som for tiden er et svært populært alternativ til de tradisjonelle relasjonsdatabasene. Noe av det som er spesielt med denne typen database er at den lagrer dataene i dokumenter av type JSON i stedet for på tabellformat slik relasjonsdatabasene gjør. Ember.js: Ember.js er et webapplikasjons rammeverk utviklet i JavaScript. Dette rammeverket benyttes for å lage såkalte «single-page applications», der formålet er å få en veldig responsiv og rask applikasjon ved at all koden for alle sider blir lastet på en gang. En annen fordel er at det tilrettelegger for utvikling med designmønsteret MVC, som tilrettelegger en separering av modellen, brukergrensesnittet og kontrolleren. På den måten vil de tre lagene bli isolert og endringer i brukergrensesnittet vil for eksempel ikke få innvirkninger på hvordan dataene blir behandlet i modellen. Web API: er et applikasjonsprogrammeringsgrensesnitt for kommunisering med databasen, i dette tilfellet MongoDB. Det fungerer da som et mellomledd mellom front end og back og muliggjør da å gjør lese-, skrive-, oppdatere- og slette operasjoner mot databasen. Phonegap: er et rammeverk for å kompilere webapplikasjoner utviklet med JavaScript, HTML og CSS til plattform spesifikke mobilapplikasjoner, som for eksempel Android eller ios. Slik at man kan utvikle applikasjonen en gang, i stedet for på hver enkelt plattform. CRUD: engelsk forkortelse for skrive, lese, oppdatere og slette. Brukes gjerne i sammenheng med de operasjonene som normalt utføres mot en database. 1.2 Praksisplassen EVRY er et norsk IT-selskap etablert i 2010, etter sammenslåelsen av ErgoGroup og EDB Business Partner. EVRY er Norges største IT-selskap og har ansatte fordelt på 16 land. Selskapet leverer tjenester som drift, konsulenttjenester og rådgivning, til kundegrupper innen blant annet finans, offentlig sektor, olje og gass og helse. Hver dag benytter over en million nordmenn EVRYs tjenester. 3

5 2 Prosjektet 2.1 Oppgaven Ettersom vi var to studenter som hadde praksis hos EVRY så hadde de naturlig nok to prosjekter. Det ene kalt «App Factory» og det andre «AGR-oppslag». Vi fikk presentert begge prosjektene og skulle bli enige oss imellom hvem som skulle ha hvilket prosjekt. Vi bestemte da at skulle ha «App Factory» og den andre studentent fikk da «AGR-oppslag». Jeg vil presisere at dette er det eneste samarbeidet vi har hatt og alt etter dette er gjort individuelt. «App Factory» er en plattform for enklere applikasjonsutvikling til mobil plattform (Android, Windows 8, ios og HTML5). Prosjektet vil være tredelt med et databaselag API-lag og applikasjonslag, alle tre skal utvikles fra bunn av. Datalaget vil bestå av dokumentdatabasen MongoDB. Applikasjons APIet vil vil muliggjøre applikasjonen i å foreta CRUD spørringer mot databasen, og fungere som et bindeledd mellom datalaget og applikasjonslaget. Applikasjonslaget skal utvikles med Ember.js, HTML5, CSS og JavaScript. Dette skal kompileres med Phonegap som da igjen kompilerer koden til de ønskede plattformer. Mye av hensikten med prosjektet er å få testet ut ny teknologi, for å se om og hvordan det fungerer. Vi vil da bruke en del tid på å sette oss inn i de teknologiene samt planlegging av prosjektet. Oppgaven min vil da være å delta i hele utviklingsprosessen av dette prosjektet sammen med prosjektleder fra EVRY. 2.2 Arbeidet Jeg vil her gå gjennom hva jeg konkret har jobbet med i praksisperioden. Rekkefølgen er kronologisk men hvor mye jeg velger å skrive om hver del er ikke tilsvarende med hvor mye tid som ligger bak, noe som kommer fram i timelisten. Etter å ha fått innføring i prosjektet skulle jeg gå i gang med arbeidet. Jeg fikk da en liste over teknologier jeg måtte sette meg inn i og få oversikt over. Hensikten var å få meg opp til et tilnærmet likt nivå med prosjektleder slik at programmeringen og samarbeidet skulle gå mer flytende når vi begynte med utviklingen. Listen var som følger: NOSQL, MongoDB, ASP.NET Web API, RESTful, SOAP WCF, JSON, GIT, Phonegap, Ember.js, serialisering/deserialisering, HTTP metoder, HTTP statuskoder og URL endpoints. Dette var bare begynnelsen og da jeg startet var det en del av de jeg aldri hadde hørt om. Den første tiden gikk det litt tid til lesing, oppsett av utviklingsmiljø, planlegging av prosjektet og skrive en prosjektplan. I prosjektplanen estimerte jeg også hvor lang tid jeg ville bruke på hver enkelt del. Hvordan det gikk vil jeg beskrive i refleksjonsdelen. Deretter kunne jeg gå i gang med utviklingen. Jeg valgte å begynne med back end da jeg mener det blir mer hensiktsmessig å jobbe med applikasjonen senere når vi har et fungerende back end. På den måten slipper vi også å gjøre front end delen først uten back end, for så å senere måtte gå tilbake å oppdatere referanser. Det lar oss også teste med realistiske data fra APIet i stedet for å bruke tid på å skrive dummytekst. 4

6 Jeg startet derfor med å sette opp datalaget med MongoDB. Ettersom MongoDB er en dokumentdatabase og den bryr seg da ikke noe om hva som settes inn i databasen utover å være et gyldig JSON dokument, så var det ikke mye som skulle til for å få datalaget klart. Det ble derfor desto mer arbeid på API laget ettersom logikken for hva som skulle være lov å sende til databasen måtte implementeres her. Utviklingen av APIet gikk hovedsakelig ut på å implementere CRUD metoder. Til jeg var tilnærmet ferdig med hadde dette så hadde prosjektleder fått på plass nye konvensjoner og struktur av koden, slik at det meste måtte skrives om. Det ble da blant annet bestemt at vi skulle benytte de funksjonene av Visual Studio Online for prosjektsamarbeid. Dette innebar da blant annet at all funksjonalitet som skulle utvikles måtte være koblet til tasker som var koblet til et backlog item som igjen var en del av en feature, samt at alle backlog items skulle være utformet som en user story. Under denne delen av prosjektet fikk jeg da litt mer erfaring av den delen ved å være konsulent hvor man samarbeider med kunde. Jeg samarbeidet riktignok ikke med reell kunde men jeg fikk beskjed av prosjektleder om hva som skulle utvikles også ble det min oppgave å skrive det som «user stories», som er en beskrivelse av en oppgave en person skal kunne utføre i programvaren, de måtte han godkjenne før jeg kunne implementere de. Alle slike administrative oppgaver ble løst på Visual Studio Online, som er et verktøy i skyen for prosjekter med flere brukere. Det er et verktøy for å holde styr på bugs, product backlog, kildekode m.m. Product backlog er en liste over funksjoner som skal implementeres, de inneholder en status og oppgaver. Oppgavene, ellers tasks som det heter, er det utvikleren som holder kontroll på mens product backlogene gjerne må godkjennes av prosjektleder. Her er et eksempel på et enkelt backlog item jeg har skrevet (Figur 1). Figur 1 Backlog item Det kommer fram i tittelen hvem user storien gjelder for og hva som skal kunne uføres. I dette tilfellet er det event manageren som skal kunne opprette et event. Det finnes flere backlog items og de er alle koblet mot en overordnet Feature kalt Event. I beskrivelsen så er det beskrevet en user story. I tillegg har hvert backlog item akseptanse kriterier, som er som navnet tilsier kriterier for at denne funksjonen skal kunne bli godkjent. 5

7 Til valg av versjonskontrollsystem falt valget på Git, tross at vi kunne valgt Microsoft sitt eget TFVC. Grunnen til det er at vi ønsket et distribuert fremfor et sentralisert system. Ettersom dette tillater at hver utvikler har en kopi av hele kildekoden på sin maskin, så gir det oss muligheter til å gjøre operasjoner som kodehistorie, branching, merging m.m lokalt uten å publisere på serveren. Dette passet oss spesielt til utviklingen av front end delen hvor for eksempel Android branchen ikke skulle inneholde kode fra ios branchen, i stedet skulle begge hente siste kode fra det vi hadde som utviklings branch og ikke motsatt. Vi kan da legge til ny funksjonalitet i utviklings branchen og ikke for hver enkelt plattform. Det vil da også være enkelt å skille ut plattform spesifikk kode, samt å hente siste endringer fra utviklings branchen over til hver plattform branch. Dette blant flere fordeler gjorde at vi valgte Git fremfor TFCS som er et sentralisert versjonskontrollsystem hvor de aktuelle operasjonene må utføres på serveren. Da back end med API og database var på plass, kunne jeg begynne på front end applikasjonen. Som nevnt tidligere skulle den utvikles med webteknologi for så å kompilere det med Phonegap til de ønskede platformene, i første omgang desktop nettleser og Android. Ettersom noe av hensikten med prosjektet var å teste ut ny teknologi så er front end delen av prosjektet det mest naturlige stedet å gjøre det på. Ettersom ASP.NET Web API er såpass populært og utbredt så valgte prosjektleder å gå for dette, men for min del ble også dette å teste ut ny teknologi. Vi skulle da prøve å se om vi kunne få phonegap til å fungere med ulike JavaScript bibliotekene Ember.js og Handlebars samt Bootstrap for utvikling av design og en responsiv webapplikasjon. Ettersom det mot slutten av praksisen begynte å bli knapt med tid, så ble målet å få på plass en minimalistisk demo applikasjon, hvor minimum artikkel modulen var implementert med designet på plass. Dette ble gjennomført innen fristen, og det ble også det siste jeg gjorde. Vi fikk også lagt databasen og APIet opp i skyen og testet at alt fungerte fra en mobiltelefon. Arbeidsmetodikken vi benyttet i prosjektet var en tilnærming til SCRUM. Med en tilnærming mener jeg at vi jobbet med SCRUM tilpasset våre behov, som ikke er helt etter malen. Ettersom jeg hovedsak var på praksisplassen en til to dager i uka så lot det seg ikke gjøre med daglige statusmøter, det var heller ikke nødvendig. Det var ikke alltid vi fikk tatt statusmøter de dagene jeg var på praksisplassen da prosjektleder var i perioder svært opptatt med andre prosjekter. Planen var egentlig at vi skulle fordele product backlogen over flere sprinter, men det ble det aldri noe av. V benyttet riktignok product backlog og tasks aktivt, slik at prosjektleder kunne følge med hvor langt jeg har kommet og hva jeg har gjort. I tillegg har vi noen ganger hatt lengre møter på noen timer hvor jeg får litt undervisning, vi prater teknologi, vurderer konvensjoner, planlegger videre m.m. 6

8 3 Refleksjoner Da jeg kom til EVRY og fikk en introduksjon til prosjektet og hva jeg skulle jobbe med denne praksisperioden, så var mye fortsatt uklart og ubestemt. Som for eksempel valg av teknologier og design av systemet, for å gi «kunden» det systemet han ønsker. Ettersom jeg fikk delta på en del av dette samt å være med på å ta avgjørelser. Så har jeg fått nyttig erfaring med hvordan man går fra oppstartsfasen til å begynne utviklingen i større prosjekter. Men de største avgjørelsene tok naturligvis prosjektleder, selv om han hele tiden har lagt vekt på å få innspill fra meg. Nå som prosjektet er ferdig for min del kan jeg se tilbake på hva som gikk bra og hva som kunne gått bedre. Jeg har fått erfart hvordan en konsulent jobber. Selv om jeg ikke hadde en reell kunde i mitt prosjekt, så har jeg hørt og sett hvordan de rundt meg på EVRY jobber med kunder. Slik jeg har erfart det så jobber en konsulent under et større tidspress enn en som jobber som ren utvikler. Det vil da innebære at konsulenten i praksis kanskje må droppe flere viktige aspekter ved prosjektsyklusen for å komme innenfor estimatene. Det kan da for eksempel være at man som konsulent ikke får tid til god nok testing, en grundig dokumentasjon eller å bruke tid på koden utover det å kun få noe til å fungere, i prosjekter hvor tidspresset er høyt. Så finnes det helt sikkert unntak i prosjekter hvor slike ting er viktigere enn i andre. 3.1 Planlegging Som nevnt tidligere så var ikke alt på plass før jeg kom inn i prosjektet. Det var en fordel da jeg fikk være med på prosessen. Men det førte også til at for eksempel kodestrukturen og konvensjoner i APIet måtte endres da det var nesten ferdig utviklet. Hvis jeg ser dette utelukkende fra mitt synspunkt så fikk jeg da ny læring med blant annet å skrive generisk kode. Med det menes at koden skrives generell slik at den kan bli brukt av flere klasser og blir først spesifisert når den blir instansiert. Så for min del var det utelukkende fordeler men om det hadde vært en kunde og en gitt frist for prosjektet så kunne det ha blitt mer kritisk. Da hadde slikt måttet vært på plass før vi gikk i gang med utviklingen. Da jeg skrev prosjektplanen måtte jeg også estimere i antall timer jeg skulle bruke på de forskjellige delene av utviklingen samt prosjektdokumenter og presentasjon. Mitt inntrykk er at estimering er noe av det vanskeligste man gjør som konsulent. Uten erfaring vil det være svært vanskelig å treffe på estimatene. Det er jo også derfor det heter estimat da det ikke er ment å være det faktiske antall timer man kommer til å bruke. Det tror jeg også er viktig å presisere når man er i møter med kunder slik at det ikke blir noen misforståelser der. Grunnen til at jeg mener estimering er svært vanskelig er fordi det krever erfaring. Har man ikke erfaring blir det derfor nødvendigvis mye gjetting. Det jeg tror kjennetegner en som er god på estimering er en som kan forutse problemer og utfordringer som vil komme. Når man estimerer som nybegynner han man nok lett for å tenke beste utfall og ikke tenke på at det vil komme uforutsette hendelser. Jeg tenker da at man må være forsiktig med å teste ut ny teknologi i prosjekter med en streng og kort tidsfrist. Da det er spesielt vanskelig å estimere hvor lang tid noe man bruker på noe man aldri har gjort før, slik jeg fikk erfare. 7

9 Estimatene mine hadde også et vesentlig forbedrings potensiale. Planen var å brue minimum 200 timer på praksis- og prosjektarbeid. De skulle jeg fordele med 120 timer på praksis og de resterende 80 på rapport- og presentasjonsarbeid. I realiteten ble det en nesten 30 timer mindre prosjektarbeid og nærmere 60 timer mer på praksisen, med det kom jeg i det minste godt over minimums grensa. Det å skulle planlegge å gjøre noe med et minimum antall timer er jo også noe spesielt i praksis, men kan være nødvendig i tilfeller som dette. Grunnen til at jeg bommet med dette var at jeg tenkte først at prosjektarbeidet ville ta lengre tid enn det gjorde og det fikk da igjen ringvirkninger for resten av estimatet. Når det gjelder praksisen så delte jeg prosjektet opp i fire deler, og gav hver av de et gitt antall timer. På grunn av endringer i prosjektet underveis og ringvirkninger fra det andre estimatet ble også dette feilestimert. Ettersom MongoDB ikke trenger noe særlig med konfigurasjon, planlegging med databasediagram osv. Videre gikk datalag delen langt raskere enn forventet, men desto mer tid måtte jeg bruke på APIet da all forretningslogikk måtte håndteres her. Samtidig ble den delen jeg kalte moduler i praksis det samme som APIet. Av den grunn gikk estimatene litt opp i opp så derfor traff jeg ganske bra, hvis man ser på back end og front end over ett. 3.2 Utvikling Selve utviklingen har vært det morsomste, mest interessante og samtidig den mest utfordrende delen av det jeg har gjort under praksisen. Det å sitte sammen med andre utviklere i et åpent landskap og programmere har vært en god erfaring for å se hvordan det foregår i praksis sammenlignet med hvordan det er å studere, og forskjellen er ganske stor. I skole sammenheng så kan man jobbe mer når man føler for å jobbe mens i arbeidslivet skal man jobbe og yte de timene man er på jobb, noe som er en selvfølge men kan være en overgang. Jeg opplevde at de stilte vesentlig høyere krav til meg på praksisstedet enn det skolen kanskje har gjort, på et generelt grunnlag. Derfor mener og tror jeg også at jeg har lært mer enn om jeg skulle lært og erfart det samme på skolen på like kort tid. Det tror jeg bedriften har gjort bevisst da det er slik man jobber i praksis. Når en kunde kommer med et oppdrag er det stor sannsynlighet for at det elementer ved det prosjektet man ikke har jobbet med før. Det stiller da krav til at man kan finne informasjon og sette seg raskt inn i ting på egenhånd. I tillegg til det generelle har jeg også fått god erfaring med spesifikke teknologier jeg knapt hadde hørt om da jeg begynte. Jeg har også fått erfaring i å ikke kun skrive kode som fungerer men også god kode. I skolesammenheng er målet ofte å kun få kode som fungerer som er formålet og ikke å legge å vekt på å skrive god, gjenbrukbar, effektiv og sikker kode. Når det gjelder valg av teknologier så var det svært mye som fungerte som forventet men også noe jeg personlig ikke ville valgt om igjen. For eksempel rundt det som jeg kaller det administrative med kildekontroll, tasker og backlog items, så fungerte verktøyene svært godt. Jeg benyttet Git bash og koblet det mot tasker og lagde nye backlog items ved behov. Når jeg var ferdig med en større endring og skulle merge med en av hovedbranchene så sendte jeg inn en pull request via Visual Studio Online, slik at prosjektleder kunne gå gjennom koden før de nye endringene ble sendt til en mer kritisk branch. Dette var en svært god måte å jobbe på og det ville vært mer og mer aktuelt desto flere som samarbeider på et prosjekt. Ettersom det ikke alltid passet med 8

10 statusmøter så kunne prosjektleder enkelt holde kontroll på hvor langt jeg var kommet ved hjelp av disse verktøyene. Ettersom vi fikk gjort en del utforskning og forsøk med Git og Visual Studio Online så ville egentlig prosjektleder at jeg/vi skulle holde en faglunsj for de andre ansatte for å dele erfaringer. Dette er en praksis hos EVRY at man deler kunnskap og erfaringer over såkalte faglunsjer. Når det gjelder valg av front end teknologi så mener jeg ideen om å utvikle èn webapplikasjon for så å kompilere den til enhver mobilplattform med noen få kommandoer i cordova, er genial. Det fungerte også slik i praksis. Slik jeg ser det, så er det fordeler og ulemper ved å benytte Ember.js. Når det fungerer så leverer det svært responsive sider men jeg syns det var veldig tungt å sette seg inn i tillegg til at det kan være vanskelig å finne svar på nett. Det kanskje største problemet med Ember.js er at det kommer ofte nye versjoner, det er positivt når utviklerne jobber aktiv med å utbedre et rammeverk men ikke når de endrer syntaks, struktur og programmeringsmåte så ofte som de har gjort. Det fører til mye av de ressursene man finner ikke er oppdatert. En annen ting er såkalte «stille feilmeldinger», som er feilmeldinger som man ikke får noe varsel på. Prosjektet kompilerer og alt virker bra helt til man skal teste applikasjonen og alt er bare hvitt. Jeg opplevde dette ved flere tilfeller og i ett av tilfellene hvor jeg brukte ganske så lang tid på å debugge, så viste deg seg å være en Handlebars skrivefeil. Handlebars benyttes i Ember for å legge ekstra funksjonalitet på grensesnittet, blant annet benyttes det til templates og for å holde data på siden oppdatert uten å trenge å laste inn sida på nytt. Feilen var som følger: {{model.content}} i stedet for {{model.content}}, ganske irriterende feil med andre ord. Routinga til Ember var også noe av grunnen til at vi gikk for den, den tillater hver enkelt side å få sin egen URL. Dette kan være praktisk, for eksempel api/articles/12, vi vil da naturlig nok komme til den tolvte artikkelen. Problemet kommer når man går direkte til den linken uten å klikke seg frem til den. Da opplevde jeg at det noen ganger fungerte å gå direkte og noen ganger ikke. Jeg måtte da skrive kode som tar forbehold om begge måtene man kan komme til en side på. Ettersom routinga er noe av det Ember er mest kjent for så er ikke dette en ny og ukjent problemstilling, det var klart noe galt med min kode men jeg opplevde det som unødvendig komplisert å få til noe så enkelt. Kort oppsummert så syns jeg Ember.js fungerer veldig bra når det er ferdig implementert men å utvikle en applikasjon med det syns jeg var unødvendig komplekst og derfor også veldig tidkrevende. Det er dessuten også veldig bra til å behandle JSON dokumenter, som også var spesielt aktuelt i dette tilfellet. En annen ulempe ved å gjøre det med denne løsningen er når man prøver å kjøre applikasjonen uten nettilgang. Da vil hele applikasjonen bare bli hvit. Selvsagt kunne jeg lagt inn funksjonalitet for når det ikke kunne oppnås nettilgang så vises en feilmelding, men det ville vært mer hensiktsmessig å heller vise gamle data fra sist applikasjonen ble lastet. Dersom vi hadde utviklet applikasjonen i for eksempel native Android ville det ha vært veldig enkelt å benytte den innebygde SQLite databasen. Med Phonegap derimot så er det slik jeg har forstått det at dette må løses ulikt for de forskjellige plattformene, og da er jo litt av poenget borte. I tillegg vil man heller aldri få den ytelsen av en web applikasjon som med en native utviklet applikasjon. Selv om Ember sin single-page teknikk fungerer stort sett godt. Men man må naturlig nok hente ned nye data relativt ofte uansett og desto oftere man må det, desto mindre vil man få utbytte av denne teknikken. Det vil også generere mer datatrafikk at Ember laster ned hele web applikasjonen hver gang, også de sidene man ikke kommer til å besøke. 9

11 3.3 Administrativt Som beskrivet tidligere så benyttet vi Git til kilkdekontroll. Dette fungerte tilnærmet uten problemer, det var et par ganger jeg måtte klone prosjektet ned på nytt hvis det begynte å oppføre seg unormalt. Utover det har bruken av Git gått på skinner. Jeg tror mye av grunnen til det er at prosjektleder har hatt ganske strenge regler på bruk av Git. Det har vært regler som: at commits alltid skal ha en beskrivelse og være linket mot en task, når man jobber på oppgaver så skal dette gjøres i en lokal personlig branch, før det blir gjort en pull request så skal koden testest og merges med de siste endringer som ligger på serveren, det er ikke lov å merge direkte med dev eller master branch. Det skal da isteden gjøres en pull request slik at prosjektleder kan gå gjennom koden før det blir implementert. Da jeg skulle begynne med dette så syntes jeg det var unødvendig mye administrativ jobbing i forhold til mengden kode jeg produserte, med andre ord ville dette forlenge utviklingstiden betraktelig. Men etter å ha jobbet en del med det så innså jeg at ved bruk slike regler/konvensjoner, så vil man oppnå en veldig ryddig og oversiktlig kildekode samt versjonskontroll. Samtidig vil det være lett å se om oppgavene er tilstrekkelig utført og funksjonaliteten er på plass, ved å se på tasks og backlog items committene er koblet mot. Planen var fra begynnelsen av å ha et system for å publisere nyeste versjon av koden. Det skulle fungere slik at når man gjorde en pull request mot for eksempel master branch så skal koden automatisk Unit testes og dersom den er godkjent blir koden publisert og hvis ikke vil vi få et varsel med feilmelding på for eksempel mail. Dette var dessverre en av delene som det ikke ble tid til. Det eneste jeg fikk sett på var noe Unit testing og jeg fikk implementert et par metoder. 10

12 Oppsummering Jeg har under praksisperioden fått erfart hvordan det er å jobbe med IT i den virkelige verden. Jeg har vært med i en utviklingsprosess fra begynnelsen til å ha en fungerende demo applikasjon. Rent utviklingsmessig innebærer dette: Utvikling av en web applikasjon med HTML 5, CSS og JavaScript Utvikling av et RESTfult web ApI i ASP.NET Bruk av databasen MongoDB. Men i tillegg til å få jobberfaring har jeg også lært mye om hvordan utvikling fungerer i arbeidslivet samtidig som jeg har utviklet meg som programmerer. Ved å sette lista høyt og å gi gode tilbakemeldinger og veiledning underveis har jeg lært veldig mye om programvare utvikling av praksisen hos EVRY. Men også det administrative rundt det å jobbe i større prosjekter, som er viktigere og en større del av det å jobbe som utvikler/konsulent enn jeg trodde før. Jeg har da fått en erfaring jeg vil ha med meg resten av skolegangen min og den dagen jeg skal ut i jobb som jeg ikke ville vært foruten. Med den erfaringa jeg nå har fått så vet jeg i større grad hva jeg må jobbe videre med meg selv for å stille sterkt den dagen jeg skal søke jobb. Både med tanke på programmeringsferdigheter men også hvilke ferdigheter, kunnskaper om forskjellige teknologier og personlige egenskaper som er ettertraktet i bransjen. 11

13 Vedlegg 1 Attest 12

14 Vedlegg 2 Timeliste Dag Timer Kommentar Planleggingsmøte Arbeid med prosjektplan Lest og begynt å sette opp utviklingsmiljø ,4 Skrevet dagbok Arbeid med prosjektplan ,5 Oppsett av Oppsett av utviklingsmiljø (MongoDB, Git, Node, Ember, VisualStudio) ,5 Gjennomgang av http-metoder + arbeid med klassediagram og oppsett ,3 Skrevet dagbok ,5 Skrevet klassebeskrivelse + diagram, kommet i gang med MongoDB og Web API Jobbet med http-metoder og få de til å jobbe med database ,5 Importert alle modeller fra tidligere prosjekt. Jobbet videre med å implementere http-metoder Abstrahert deler av prosjektet i et mer generisk repository ,25 Skrevet dagbok ,25 Begynt med UNIT-testing ,5 Jobbet med relasjoner mellom modeller i MongoDB ,25 Begynt med embeddede objekter i MongoDB og da lagd medfølgende CRUD metoder i Web API Møte + arbeid med booking sin controller + service lag Arbeid med midtsemesterrapport Jobbet videre med implementasjon av controller + service lag Arbeid med midtsemesterrapport Fullført midtsemesterrapport Feil retting med konvertering av GUID til/fra MongoDB + gjort ferdig api og service lag til booking modulen + startet på den nye prosjektstrukturen Jobbet videre med omskrivning av prosjektstruktur + Lagd backlog items og user stories Oppdatert og reinstallert programmvare Jobbet videre med omskrivning av prosjektstruktur + testing 13

15 ,5 Jobbet videre med omskrivning av prosjektstruktur Feil rettinger + booking module Rettet feil hvor endringer ikke ble lagret til databasen + fullføring av api og planlegging av videre utvikling av front end applikasjon Oppsett av utviklingsmiljø for front end applikasjon (ANT, Phonegap, ADT, Ember.js, NPM m.m) Oppsett av versjonskontroll program (GIT) for front end applikasjonen Jobbet med å få ember til å ta imot JSON dokumentene fra APIet Kompilert koden til android applikasjon + jobbet med design Design Design + jobbet med å få applikasjonen til å hente og vise enkelt nyheter ,5 Design + feil retting av APIet hvor ikke ember applikasjonen fikk hentet data grunnet CORS + kompilert og testet på android ,5 Arbeid med rapport Oppdatert verktøyene + testing + implementering av events i applikasjonen + noe design på news modulen Implementering av events modul + navigering mellom sider + design på news Implementert handlebars funksjoner for å ikke vise all tekst når alle artikler listes ut i news modulen. + design Administrativ fullføring av prosjekt Arbeid med rapport Arbeid med rapport Ferdigstilling og innlevering av rapport Arbeid med presentasjon Arbeid med presentasjon Arbeid med presentasjon 14