SoProCV Sluttdokumentasjon Våren SoProCV. Sluttrapport. Gruppe Askar Mehdi - Thomas Tykesson - Magnus Arneberg Nilsen.

Transkript

1 SoProCV Sluttrapport Gruppe 17 - Askar Mehdi - Thomas Tykesson - Magnus Arneberg Nilsen Page 1 of 78

2 BACHELORPROSJEKT PROSJEKT NR TILGJENGELIGHET Studieprogram: Informasjonsteknologi Åpen Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL SoProCV (SocialProfileCurriculumVitae) PROSJEKTDELTAKERE - Askar Mehdi s Thomas Tykesson s Magnus Arnebrg Nilsen s DATO ANTALL SIDER / BILAG 71/7 INTERN VEILEDER Geir Skjevling OPPDRAGSGIVER Service Broker AS (IT-rekrutteringsselskap) KONTAKTPERSON Sebastian Næss Langaas (Rådgiver) Epost: sebastian@servicebroker.no Telefon: SAMMENDRAG Utvikle nettside/webapplikasjon hvor man kan importere CV-relatert informasjon fra sin LinkedIn-profil til en CV-editor på siden. Dette gjøres ved at brukeren logger inn på sin LinkedIn-profil via webapplikasjonen slik at den dermed kan få hentet informasjonen fra brukerens profil via LinkedIn sitt API. Videre skal man kunne velge og endre den importerte informasjonen i denne CV-editoren. Til slutt eksporteres informasjonen til en valgfri CV-mal i form av et DOCX dokument. 3 STIKKORD Webapplikasjon LinkedIn-profil-informasjon CV (Ciruculum Vitae) Side 2 av 78

3 Forord Dette prosjektet er et resultat av bachelorprosjektet våren 2015, gjennomført i samarbeid med Service Broker og gruppe 17. Vi vil starte med å takke de som har vært med i denne lange prosessen, da denne oppgaven ikke ville vært mulig uten deres hjelp. Vi vil takke Sebastian Næss Langaas, kontaktperson fra Service Broker, for å hjelpe med å skaffe oss denne oppgaven, følge med på hele prosessen, bidra med teknisk hjelp, og gi oss gode og konstruktive tilbakemeldinger. Vi vil også takke Oscar Bull-Hansen, andre kontaktperson fra Service Broker, for å komme på ideen til oppgaven, og gi oss tilbakemeldinger underveis. Vidar Langaas, eier og daglig leder i Service Broker, for å gi klarsignal til oppgaven, Veileder, for hjelpen underveis, og spesielt med ferdigstilling av dokumentasjonen og hjelp med et stort problem gruppen møtte på i prosessen. Dette dokumentet vil bestå av en presentasjon, kravspesifikasjon, prosessdokumentasjon, produktdokumentasjon, testrapport og en brukermanual. Det er svært viktig at den som vurderer denne bacheloroppgaven, leser dokumentasjonen før en kommer i gang med å bruke produktet. Dette gjelder spesielt presentasjon, kravspesifikasjonen og prosessdokumentasjonen. Den som vurderer produktet vil få utdelt en forhåndsopprettet LinkedIn-profil for å teste produktet. Denne er helt nødvendig å bruke i og med at produktet er basert på at brukeren har en LinkedIn-profil. Årsaken til at det er opprettet en forhåndsdefinert LinkedIn-profil er spesifisert i prosessdokumentasjonen. Informasjon om LinkedIn-profilen (passord og brukernavn) finnes i program CD-en (LinkedInProfil.txt) Side 3 av 78

4 Hovedinnhold Dette dokumentet utgjør sluttrapporten og består av følgende: 1 Presentasjon Kravspesifikasjon Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukermanual Vedlegg Meldingsutveksling med LinkedIn 7.2 Tilbakemelding fra oppdragsgiver 7.3 Kilder Side 4 av 78

5 1 Presentasjon Innholdsfortegnelse 1 Presentasjon 1.1 Forord 1.2 Innledning 1.3 Presentasjon av partene Service Broker Kontaktpersoner Veileder Gruppen Oppdragsgiver 1.4 Bakgrunn Side 5 av 78

6 1.1 Forord Det er svært viktig at leseren gjør seg kjent med denne delen av sluttdokumentasjonen. De senere kapitelene vil være avhengig av at leseren er kjent med presentasjonsdelen. Denne delen består aller først av en presentasjon av problemstilling/oppgave og de ulike partene i prosjektet. Til slutt gjøres det rede for bakgrunnen for prosjektet. 1.2 Innledning Vi er en gruppe på tre ivrige datastudenter som har et ønske om å gjøre et spennende og suksessfullt Bachelorprosjekt. Gruppen skal i våren 2015 utføre hovedprosjektet i samarbeid med selskapet Service Broker AS. Oppgaven vil i all hovedsak gå ut på å lage en nettside/webapplikasjon hvor man kan importere CV-relatert informasjon fra sin LinkedIn-profil 1 til en CV-editor på siden. Dette gjøres ved at brukeren logger inn på sin LinkedIn-profil via webapplikasjonen slik at programmet dermed kan få hentet informasjonen fra brukerens profil via LinkedIn sitt API 2. Videre skal man kunne velge og endre den importerte informasjonen i denne CV-editoren. Til slutt eksporteres informasjonen til en valgfri CV-mal i form av et DOCX 3 dokument. Brukeren skal kunne velge om informasjonen fra han/hennes LinkedIn-profil skal være på norsk eller engelsk avhengig om brukeren har opprettet en profil på disse språkene. Default skal være norsk og dersom brukeren ikke har en norsk profil, returneres profilen i det språket som er brukt på profilen. Prosjektet vil inkludere bruk av valgfrie front- og backend-teknologier, og integrasjon av LinkedIn sitt API. 1 LinkedIn: Et verdensledende sosialt nettverk som hovedsakelig brukes i forretningsøyemed. 2 API: Application Programming Interface, et programmeringsgrensesnitt for kommunikasjon mellom programvare. 3 DOCX: En Word Microsoft Office Open XML Format Document fil. Formatet brukes av alle de nye versjonene av Microsoft Word og andre tekstbehandlingsverktøy. Side 6 av 78

7 1.3 Presentasjon av partene Følgende er en presentasjon av oppdragsgiver (Service Broker), gruppen og veileder Service Broker AS Vår oppdragsgiver i dette hovedprosjektet er rekrutteringsselskapet Service Broker AS. Selskapet spesialiserer seg på å finne IT-folk til tidsbegrensede oppdrag og faste ansettelser. Deres kandidater arbeider med blant annet rådgivning, prosjekttjenester, utvikling, driftstjenester, ledelse, og salg. Service Broker har to hovedtjenesteområder. Recruiting jobber med ansettelser til faste stillinger, mens Consulting er oppdragsformidler av midlertidige engasjementer. Selskapet har flere store kunder som blant annet Steria, Bouvet og Elkjøp. Nettside: Kontaktpersoner Veileder: - Geir Skjevling Lektor ved Høgskolen i Oslo og Akershus Epost: Geir.Skjevling@hioa.no Telefon (kontor): Telefon (mobil): Besøksadresse: Pilestredet 35, Oslo, PS Gruppen: - Muhammad Askar Syed Mehdi (Kontaktperson) Studielinje: Dataingeniør (HINGDATA) Epost: s188074@stud.hioa.no, askar.938@outlook.com Telefon: Side 7 av 78

8 - Magnus Arneberg Nilsen Studielinje: Dataingeniør (HINGDATA) Epost: - Thomas Christoffer Tykesson Studielinje: Dataingeniør (HINGDATA) Epost: Telefon: Oppdragsgiver: - Oskar Bull-Hansen (Rådgiver) Epost: oskar@servicebroker.no Telefon: Sebastian Næss Langaas (Rådgiver) Epost: sebastian@servicebroker.no Telefon: Bakgrunn Løsningen vil være en del av Service Brokers tjenester som tilbys arbeidssøkere for å bidra i en jobbsøkerprosess, hvor det å kunne presentere seg selv med en ryddig CV er viktig. Service Broker har i de siste årene observert en økende bruk av informasjon fra LinkedIn når det kommer til innholdet i en CV. Interessen er derfor veldig stor for en løsning (nettside/webapplikasjon) som vil gjøre det enkelt og raskt å overføre relevant informasjon fra LinkedIn-profilen sin til en CV i form av et redigerbart dokument (DOCX) på en brukervennlig måte. Nettstedet resume.linkedinlabs.com er et lignende verktøy som oppfyller noen av kravene, men langt i fra alle. Årsaken er manglende funksjonalitet for å modifisere innhold i CV-en og ingen mulighet for å lage en CV på norsk. Dessuten genereres CV-en som et uredigerbart PDF dokument. Service Broker ønsker derfor at vi skal lage en bedre og en mer skreddersydd løsning for dem. Side 8 av 78

9 2 Kravspesifikasjon Innholdsfortegnelse 2 Kravspesifikasjon 2.1 Forord 2.2 Leserveiledning 2.3 Overordnet systembeskrivelse Hovedmål 2.4 Funksjonelle krav Bruker/kunde krav Ønsket tilleggs-funksjonalitet 2.5 Ikke-funksjonelle krav Produktkrav Organisatoriske krav Eksterne krav Side 9 av 78

10 2.1 Forord Kravspesifikasjonen er et svært sentralt dokument i prosjektet. Dokumentet spiller en essensiell rolle når det gjelder enighet mellom oppdragsgiver og/eller bruker og utvikler. Den fungerer nemlig som en avtale/kontrakt mellom de ulike partene i prosjektet ved å beskrive de krav som oppdragsgiver og bruker har til løsningen som skal utvikles. I tillegg fungerer kravspesifikasjonen som et styringsdokument gjennom hele prosjektet. Man kan hele tiden se mot den under utviklingsprosessen i og med at den uttrykker det som prosjektet skal bli. Fordi gruppen har valgt en smidig utviklingsprosess som er basert på iterativ utvikling, har kravspesifikasjonen, til nytte for både utviklere og oppdragsgiver, alltid vært utgangspunktet og en rettesnor for alle delleveransene våre. Utviklingsmodellen har dermed bidratt til en dynamisk kravspesifikasjon hvor man hele tiden ser etter forbedringer ved å endre eller legge til krav. 2.2 Leserveiledning Kravspesifikasjonen består først av en overordnet systembeskrivelse som beskriver hovedmålene ved løsningen. Til slutt redegjør vi for de funksjonelle- og ikke-funksjonelle kravene til løsning. 2.3 Overordnet systembeskrivelse Tar for seg hovedmålene ved webapplikasjonen, se presentasjons kapittelet «1.2 innledning» for flere detaljer Hovedmål 1. Brukeren logger inn på sin LinkedIn-Profil via webapplikasjonen. 2. Informasjon fra LinkedIn-profilen eksporteres til en CV-editor. 3. Brukeren kan velge eller endre importert data fra LinkedIn-profilen sin ved hjelp av et brukervennlig grafisk grensesnitt (heretter oppkalt som «CV-editoren»). 4. Brukeren kan velge mellom 3 maler for CV-en. 5. Brukeren kan velge mellom å lagre CV-en lokalt som et DOCX dokument eller få den tilsendt på e-post. Alt dette gjøres ved hjelp av teknologier som JavaScript (JQuery), HTML, CSS, AJAX og PHP. Gruppen må også sette seg inn i minst 2 API-er (Application programming interface) for å løse problemet, dette inkluderer LinkedIn sitt REST API og PHPWord. Side 10 av 78

11 2.4 Funksjonelle krav De funksjonelle kravene beskriver hovedsakelig hva systemet skal utføre og kan beskrives som Systemkrav. Dette kan videre deles inn i to kategorier: Bruker/Kunde krav, krav om funksjonalitet fra oppdragsgiver og brukere av systemet og Ønsket tilleggsfunksjonalitet, funksjonalitet som ønskes implementert dersom det er tilstrekkelig med tid: Bruker/kunde krav - Systemet skal være en webapplikasjon, altså et program som kan kjøres i en nettleser. - Systemet skal gi brukeren mulighet til logge inn på sin LinkedIn-profil ved hjelp av OAuth Systemet skal kunne importere relevant data fra LinkedIn-profilen til et skjema (engelsk: form) slik at brukere enkelt kan huke av for/velge de feltene han/hun ønsker å ha med i den endelige CV-en. - Systemet skal gi brukeren mulighet til å velge mellom flere forskjellige maler for CV-en. - Systemet skal kunne gi brukeren mulighet for å endre og velge informasjon i skjemaet ved hjelp av et brukervennlig brukergrensesnitt («CV-Editoren») - Brukeren skal kunne få den genererte CV-en i form av et DOCX dokument som han/hun kan lagre lokalt på systemet sitt eller få tilsendt på sin epost. - Brukeren skal kunne velge om informasjonen fra LinkedIn skal vises på engelsk eller norsk, hvor default er norsk Ønsket tilleggs-funksjonalitet: - Webapplikasjonen skal være mobiltilpasset. - Legge til flere maler. 4 OAuth 2.0: OAuth er en åpen standard for autentisering (Detaljer om OAuth finnes i produktdokumentasjonen) Side 11 av 78

12 2.5 Ikke-funksjonelle krav Ikke-funksjonelle krav beskriver hvordan systemet skal implementere de funksjonelle kravene Disse deles inn i tre hovedkategorier: 1. Produktkrav, krav til endelige produktet som ikke er direkte relatert til funksjonaliteten. 2. Organisatoriske krav 3. Eksterne krav Produktkrav Rammekrav/Tekniske krav - Bruke JavaScript for å styre dynamikken i webapplikasjonen. - Bruke PHP5 for oppbygning av siden og kommunikasjon med server. - Bruke HTML5 og CSS3 for å utforme webapplikasjonen. - Bruke LinkedIn sitt REST API 5 med OAuth 2.0 for å autentisere brukeren og importere data fra LinkedIn-profilen. - Bruke PHPWord API-et for å konvertere den valgte informasjonen til et DOCX dokument. - Bruke NetBeans IDE for å utvikle/programmere systemet. - Webapplikasjonen skal kunne kjøres i alle moderne nettlesere. - Webapplikasjonen skal ligge på Service Broker sin server. - Gruppemedlemmene bruker sine egne maskiner. - Bruke Git med GitHub for versjonshåndtering og Dropbox for backup. - Bruke smidig metodikk for prosjekthåndtering (Extreme Programming) - Bruke Trello som et verktøy for prosjektstyringen. - Generelle krav til brukergrensesnitt - Enkel og intuitiv navigasjon, det skal ikke mange klikk til for å komme til ønsket destinasjon på siden. - Moderne utseende på grafiske elementer. - En beskrivende logo. - Bruker skal få varslinger som står i stil med varslingsgrunnlaget. - Det skal være enkelt å endre den grafiske designen. - Prosessen å få generert en CV skal være rask og enkel. Brukeren skal føle en god «flyt» i prosessen. 5 REST: Representational State Transfer, kort beskrevet en protokoll over HTTP, som benyttes til å kalle web baserte tjenester. (Detaljer om REST finnes i produktdokumentasjonen) Side 12 av 78

13 - Krav til koden - Navn på klasser, funksjoner og variabler skal være relevante og intuitive. - Koden skal være godt strukturert og det skal være enkelt å videreutvikle løsningen. - Kommentarer i koden skal være på engelsk Organisatoriske krav - På nettsted skal det komme fram at dette ble laget i forbindelse med Service Broker. - Service Broker vil ha siste ord i hvilket navn og domene nettstedet skal få Eksterne krav - Følge norsk lovgivning. - Følge LinkedIn sin policy om bruk av deres API. - Følge HiOA sine regler og lover i forbindelse med bachelorprosjektet. Side 13 av 78

14 3 Prosessdokumentasjon Innholdsfortegnelse 3. Prosessdokumentasjon 3.1 Forord 3.2 Innledning 3.3 Planlegging og metode Før prosjektet Utviklingsmetode og prosessmodell Kommunikasjon med oppdragsgiver Styringsdokumenter Arbeidsforhold Verktøy Prosjektstyring og dokumentasjon Utvikling 3.4 Utviklingsprosessen Krav- og datainnsamling Design Implementasjon Funksjonalitet steg for steg Brukergrensesnitt/grafisk design 3.5 Kravspesifikasjonen og dens rolle Hovedrolle og betydning Endringer i kravspesifikasjonen 3.6 Avsluttende del Side 14 av 78

15 3.1 Forord Prosessrapporten er et svært essensielt dokument for alle parter i prosjektet. Den beskriver grundig utviklingsprosessen som resulterte til det endelige produktet. I denne rapporten beskriver vi arbeidet som er utført i forbindelse med dette prosjektet fra start til slutt. Følgende temaer vil bli dekket: - Innledning: Tar for seg bakgrunnen for problemet/oppgaven, den bedriftsmessige situasjonen, begrensninger, rammebetingelser og målet med oppgaven. - Planlegging og metode: Gjør rede for planleggingen, verktøy og teknologi som ble benyttet, hvilken metode som ble brukt i arbeidsprosessen, utfordringer underveis i prosjektet, tilegning av ny og nødvendig kunnskap og samarbeidet/forholdet med oppdragsgiver - Utviklingsprosessen: Her beskrives de ulike utviklingsfasene gjennom hele prosjektet og de faglige utfordringer gjennom prosjektet. I tillegg redegjør vi for valgene våre med hensyn på oppbygning, design og funksjonalitet i programmet. Vi vil også beskrive et vesentlig problem som gruppen møtte på, og hvilke konsekvenser dette fikk for sluttproduktet. - Kravspesifikasjonen og dens rolle: Beskriver viktigheten av en dynamisk kravspesifikasjon. Hvordan den samsvarer med det endelige produktet, beskrives i produktdokumentasjonen. - Avsluttende del: Her kommer vi til å snakke om produktet, videreutvikling og eget læringsutbytte. I tillegg vil vi presentere tilbakemeldingen fra oppdragsgiver. Side 15 av 78

16 3.2 Innledning Se presentasjonsdelen øverst i dette dokumentet. 3.3 Planlegging og metode I prosjekter som dette, er planlegging nøkkelen til et godt resultat. Her gjør vi rede for planleggingen, verktøy og teknologi som ble benyttet, hvilken metode som ble brukt i utviklingsprosessen, utfordringer underveis i prosjektet, tilegning av ny og nødvendig kunnskap og samarbeidet med oppdragsgiver Før prosjektet Gruppen startet tidlig med å finne en oppdragsgiver. Allerede i vårt første gruppemøte dannet vi oss en viss idé om type prosjekt vi ønsket å jobbe med og hvilke teknologier og verktøy vi ville benytte oss av. Vi ble fort enige om å velge noe som var relevant til de fagene vi hadde hatt, men samtidig en utfordrende oppgave som ville gi oss et godt læringsutbytte. Dette resulterte til at valget falt på et utviklingsprosjekt hvor programmering er sentralt. I løpet av kort tid, var i kontakt med flere bedrifter og vi hadde også studert tilbudene på HiOA sin nettside for bachelorprosjektet. Vi fikk flere gode tilbud, men vi endte til slutt med å skrive hovedprosjektet hos IT rekruteringsselsapet Service Broker (beskrevet under presentasjonsdelen). Service Broker hadde tilbudt oss å utvikle en løsning som skulle bli tatt i bruk av jobbsøkere, og av alle tilbud vi hadde mottatt, var nytteverdien med denne oppgaven mye større ved at løsningen forenkler og effektiviserer jobbsøkerprosessen for folk som søker jobb, spesielt IT-folk Utviklingsmetode og prosessmodell Extreme Programming (XP) Ettersom smidig utvikling er svært utbredt og bruken av den har resultert til flere vellykkede prosjekter, falt valget fort på denne utviklingsmetoden. Smidig utvikling går hovedsakelig ut på at man benytter seg av inkrementelle og iterative arbeidsmetoder hvor krav og løsninger utvikler seg kontinuerlig gjennom samhandling mellom utviklere og brukere/oppdragsgiver (Morten Dæhlen, Professor hos UIO, 2010). En populær prosessmodell innenfor smidig utvikling er Extreme Programming eller XP. Extreme Programming involverer, kort oppsummert, følgende punkter: Side 16 av 78

17 - Kommunikasjon - Tilbakemelding - Mot - Enkelhet - Parprogrammering - Refaktorisering av kode - Testdrevenutvikling - Korte iterasjoner (1-3 uker) Årsaken til valget av XP kan enkelt begrunnes med nettopp de overnevnte punktene: Kommunikasjon er helt essensielt i prosjektarbeid, dette gjelder både kommunikasjon innad i gruppen og kommunikasjon mellom gruppen og kunden/oppdragsgiver. Kontinuerlige tilbakemeldinger fra kunden er en sentral del av XP, dette resulterer i en dynamisk kravspesifikasjon hvor man hele tiden ser etter forbedringer. Gruppen presenterte løsningen sin for oppdragsgiver etter hver iterasjon ved å laste opp webapplikasjonen på deres server. På denne måten kunne gruppen få kjappe tilbakemeldinger om progresjonen og selve webapplikasjonen. En annen viktig årsak for valget av denne prosessmodellen var parprogrammering. I og med at gruppen kun bestod av tre personer og det meste av arbeidet skjedde rundt samme bord, var det enkelt å følge dette konseptet. Det ble spesielt brukt mye parprogrammering i forbindelse med refaktorisering av koden ved at vi koblet en av våre bærbare maskiner til en TV/prosjektor og omstrukturerte koden i fellesskap for å forbedre kvaliteten på programmet Kontinuerlig og grundig testing ble brukt for å avdekke feil/bugs og forbedre kvaliteten i programmet. Det ble brukt flere forskjellige tester og det viste seg at disse var absolutt nødvendige for å oppnå et godt resultat. Se testdokumentasjonen for flere detaljer. Et helt essensielt verktøy i prosjektet var prosjektstyringsverktøyet Trello. Verktøyet var nytt for oss, men vi hadde blitt anbefalt av tidligere studenter å bruke det for å kunne å gjennomføre en vellykket smidig prosess. Trello gjorde at prinsippene med Extreme Programming i stor grad ble ivaretatt ved å blant annet gjøre samarbeidet enklere. Trello er et nettleserbasert verktøy der man kan opprette «Boards». Et «Board» er en nettside der man enkelt kan legge inn lister, notater («cards»), bilder, filer, tidspunkt for frister osv. Et «Board» kan enkelt deles med flere personer, som også kan gjøre endringer på det. Vi brukte Trello fordi det bidro til å gi en oversikt over prosjektet og forenklet planleggingen av prosjektet. Dette gjorde vi ved at sette opp en oversikt over hva som skulle gjøres, hva som ble gjort, og fordeling av oppgavene. Vi kunne enkelt sjekke frister, møtetider, arbeidsoppgaver, og vi kunne for eksempel dele korte kodesnutter i notater, eller legge ved hele filer. Side 17 av 78

18 Det ble opprettet et sett med lister som beskrev en bestemt fase, fasene kunne ha navn som «To do», «In progress», «Testing», og «Done». Disse listene inneholdt videre de forskjellige arbeidsoppgavene i form av «cards» og arbeidsoppgavene ble hele tiden flyttet mellom disse fasene avhengig av tilstanden på arbeidsoppgaven. Dette bidro til en oversikt på detaljnivå Kommunikasjon med oppdragsgiver Kommunikasjonen med oppdragsgiver har foregått gjennom hele prosessen, enten det er som fysiske møter i deres lokaler eller kommunikasjon gjennom e-post og telefon. Etter hver iterasjon har det blitt avtalt et møte med Service Broker i deres lokaler ved Oslo sentrum. Her har gruppen presentert løsningen så langt, eventuelle utfordringer i utviklingsprosessen og våre tanker, ideer og forslag rundt den videre utviklingen av løsningen. Oppdragsgiver har deretter kommet med en direkte tilbakemelding rundt det som har blitt presentert og spesielt funksjonaliteten har blitt diskutert i samtlige møter. I forbindelse med tilbakemeldingene har gruppen og oppdragsgiver sammen gjennomgått kravspesifikasjonen og lagt inn de nødvendige endringene. I tillegg har det også blitt lagt til nye krav. Møtene har vært helt essensielle for progresjonen, oppdragsgiver har hele tiden vært tilgjengelig for oss og kommunikasjonen med dem har fungert som en rettesnor i utviklingsprosessen Styringsdokumenter Følgende er dokumenter som har vært med på å sikre framdrift i prosjektet. Dagbok/logg Her ble det ført opp notater om blant annet hva som ble gjort, når og av hvem, problemer/utfordringer gruppen møtte på og hvordan de ble løst. Loggen har fungert som hovedkilden for mye av prosessdokumentasjonen. Arbeidsplan Det ble på starten av prosjektet opprettet en arbeidsplan, den beskrev generelt de aktiviteter som skulle til for å komme i mål med prosjektet. Ved hjelp av Trello kunne vi enkelt sette opp detaljerte arbeidsoppgaver og i tillegg sette opp ansvarspersoner for de forskjellige oppgavene slik at vi da også fikk en oversikt over hvem som skulle gjøre hva Side 18 av 78

19 Fremdriftsplanen I forbindelse med forprosjektrapporten ble det også satt opp en fremdriftsplan i form av et Gantskjema. Her kom det fram hva vi måtte arbeide med når og hvilke ting man måtte arbeide med parallelt. I tillegg ga den en oversikt over hvordan man totalt lå an med hensyn på tidsbruk. Ved hjelp av Trello kunne gruppen detaljere denne fremdriftsplanen og enkelt gjøre endringer i den. Det ble i tillegg satt opp en milepælsplan i form av en liste med de mest sentrale milepælene i prosjektet og frister for disse, denne hjalp gruppen med å få en helhetlig oversikt over arbeidsprosessen Arbeidsforhold Samtlige gruppemøter fant sted på HiOA i og med at oppdragsgiver hadde begrenset med plass på lokalene sine. Gruppen hadde alltid tilgang til et grupperom ved HiOA og ofte var disse grupperommene utstyrt med en skjerm, sik at felles kodegjennomgang ble enklere å få til Verktøy Prosjektstyring og dokumentasjon: Trello Beskrevet under kapittel («Utviklingsmetode og prosessmodell»). Git og GitHub Git er et versjonskontrollsystem. Det hjelper til med å holde oversikt over alle versjonene av et program. GitHub er en online tjeneste, spesifikt laget for å laste opp Git-prosjekter. Der kan man velge om prosjektet skal være offentlig eller privat, + eventuelt dele det med enkeltpersoner. Fordelen med å bruke Git+GitHub over et standard backup-system er at det lar deg ha full oversikt over de forskjellige versjonene av programmet, og kan for eksempel ved hjelp av en kommando sammenligne versjonene for å finne endringene som ble gjort, som kan hjelpe med å spore feil/bugs osv. Dessuten egner verktøyet seg godt for logging. Microsoft Office Pakken består blant annet av Microsoft Word som er et tekstbehandlingsprogram og ble brukt til å dokumentere prosjektet. Microsoft Excel ble brukt til å produsere diagrammer som for eksempel Side 19 av 78

20 gant-skjemaet for fremdriftsplanen. Microsoft PowerPoint ble brukt for å opprette presentasjonen av bacheloroppgaven. Dropbox En nettskytjeneste som sørger for synkronisering av filer mellom PC, nett og mobile enheter. Programmet ble brukt for fildeling innad i gruppen og for backup av filer. Skype Skype er et program som blant annet tilbyr funksjonalitet for meldingsformidling og filoverføring. Dette ble svært mye brukt for å opprettholde kommunikasjonen innad i gruppen. Dessuten fungerte Skype også som en logg for gruppen, da vi enkelt kunne søke oss tilbake til tidligere samtaler dersom det var tvil om at noe ble sagt Verktøy for utvikling: cpanel En Linux basert webhotell-kontrollpanel som tilbyr et grafisk grensesnitt til brukeren slik at man enkelt kan hoste en web server. WinScp (Windows Secure CoPy) En SFTP- og FTP-klient for Windows. Brukt til å overføre filer fra lokal datamaskin til server. Netbeans IDE En open-source integrert utviklingsmiljø(?) for programvare utvikling på de fleste operativsystemer. Programmet ble brukt til utvikling i PHP, HTML og JavaScript. Nettleserens innebygde «debugger» Brukt til å avdekke og rette feil i klient-delen av programmet (JavaScript og HTML) PHPWord Side 20 av 78

21 Et open-source bibliotek skrevet i PHP som tilbyr et sett med klasser for å skrive til og lese fra forskjellige filformater. Vi brukte PHPWord til å opprette DOCX dokumenter (CV-en) dynamisk ved hjelp av PHP. JQuery JQuery er et JavaScript bibliotek som på mange måter forenkler programmering med JavaScript, dette blant annet ved å redusere størrelsen på koden. PHPMailer Et bibliotek skrevet i PHP for å forenkle prosessen å sende epost på en trygg måte fra en webserver. Enkelt å blant annet sende epost med vedlegg, ble brukt for å sende den genererte CVen til brukerens epost. LinkedIn sitt REST API REST (Representational State Transfer) er en standard for Ajax-kall og kan dermed brukes til å kalle serverkode fra ulike enheter (web, telefon, applikasjoner osv.). REST Bruker HTTP verb som GET, POST, PUT, DELETE, man kan derfor i et Ajax-kall bestemme om man skal hente data (GET), lagre data (POST), oppdatere data (PUT) eller slette data (DELETE). Her brukes også HTTP-statuskoder, et eksempel er statuskoden 404 (not found) som indikerer at en forespørsel feilet på grunn av at man ikke finner noe på server. LinkedIn sitt REST API ble brukt for å importere data fra en pålogget bruker sin LinkedIn-profil til webapplikasjonen. Microsoft Word Et tekstbehandlingsprogram brukt for å teste om den genererte CV-en (DOCX fil) var lesbar og kompatibel. LibreOffice Writer Et gratis og open-source tekstbehandlingsprogram og for mange et alternativ til Microsoft Word. Brukt for å teste om den genererte CV-en (DOCX fil) var lesbar og kompatibel med LibreOffice. 3.4 Utviklingsprosessen Her beskrives de ulike utviklingsfasene krav- og datainnsamling, design, implementasjon (testing er beskrevet i et eget kapitel) og de faglige utfordringene gjennom prosjektet. I tillegg redegjør vi for valgene våre med hensyn på oppbygning, design og funksjonalitet i programmet. Side 21 av 78

22 Siden prosjektet baserer seg på en iterativ utviklingsprosess (Extreme programming), vil det være naturlig at de ulike utviklingsfasene beskrevet under gjentas gjennom hele prosjektet. Dette gjelder spesielt utviklingsfasene krav- og datainnsamling, design, implementasjon og testing Krav- og datainnsamling Oppdragsgiver var kjapt ute med de overordnede kravene til oppgaven, men det gjenstod fortsatt mye arbeid rundt innsamling av krav og data. I forbindelse med prosjektskissen, hvor målet var å presisere problemet/oppgaven, valgte gruppen å benytte seg av såkalte «user stories». Dette gjorde vi ved å opprette flere bruker/kunde kort ved hjelp av Trello, hvert kort fulgte mønsteret: «Rolle vil utføre noe for å oppnå et gitt resultat». På den måten kunne gruppen enkelt og kreativt samle inn mange av de nødvendige kravene og flere tilleggskrav for å oppnå et godt resultat. Bildet nedenfor viser en user story som ble benyttet. Figur 1: Et utvidet Trello-kort som består av en typisk user story. I forbindelse med teknologi, bestemte oppdragsgiver at prosjektet skulle inkludere bruk av valgfrie front- og backend-teknologier. Dette medførte at gruppen kunne benytte seg av ønsket teknologi, blant annet den som hadde blitt diskutert i de første gruppemøtene før gruppen hadde kommet i kontakt med oppdragsgiver. De teknologier som ble benyttet var hovedsakelig PHP, JavaScript (JQuery), CSS og HTML5, gruppen hadde mye erfaring med de to sistnevnte, men ikke nevneverdig mye erfaring med PHP Side 22 av 78

23 og JavaScript. I perioden før prosjektstart hadde vi dermed avtalt at alle skulle gjøre seg kjent med disse og det faktum at vi hadde erfaring fra andre programmeringsspråk gjorde jobben enklere. For å oppnå et best mulig resultat, valgte i tillegg to av gruppemedlemmene emnet Webprogrammering (forelesninger i PHP og JavaScript) som valgfag, noe som viste seg å være svært nyttig ved flere anledninger i prosjektet Design Valg av design og oppbygning av webapplikasjonen ble en utfordring for gruppen. Gruppen var kjent med at det fantes flere forskjellige «web application frameworks» å velge mellom. Noen eksempler på aktuelle rammeverk var AngularJS og Bootstrap men ettersom vi ikke hadde noe nevneverdig kunnskap om webprogrammering (spesielt med JavaScript), valgte vi ikke å benytte et slikt rammeverk. Hovedårsaken var at gruppen først og fremst ønsket å lære JavaScript og dette kom vi frem til at var best å gjøre ved å studere JavaScript fra bunnen av, i stedet for å gå gjennom et rammeverk som bruker JavaScript på en måte vi ikke skjønner. Med andre ord, det var viktig med en mestringsfølelse av et grunnleggende språk som JavaScript, vi kunne selvsagt ha blitt enige om å først gjøre oss kjent med JavaScript for så å bruke et rammeverk, men fordi vi naturligvis hadde begrenset med tid, måtte vi også prioritere de andre delene av prosjektet. Når det kom til valg av oppbygningen av webapplikasjonen, falt valget kjapt på en såkalt Single Page Application (SPA). Dette kan begrunnes med selve funksjonaliteten til webapplikasjonen, fra da brukeren blir autentisert til da informasjon fra LinkedIn-profilen blir lest og dynamisk eksportert til en CV-Editor på siden. Alt dette kan enkelt utføres på en og samme side ved hjelp av JavaScript som dynamisk kan skjule og vise de relevante delene av siden i forhold til hvilken steg brukeren befinner seg i prosessen. Fordelen med en SPA er at antall spørringer mot server for å laste ned sider blir redusert, siden vil aldri bli lastet ned på nytt i prosessen (med mindre brukeren tvinger dette fram), dette er spesielt nyttig dersom man har mange brukere. En annen viktig fordel er at tilstandsbevaring blir håndtert på en god måte, dersom man har satt en variabel, vet man at den fremdeles vil være der. Dette gir en følelse av at man utvikler en webapplikasjon i stedet for en typisk nettside og forhindrer unødvendig bruk av ressurser på server ved at man for eksempel slipper å håndtere tilstand Implementasjon Implementasjonen kan deles inn i to hoveddeler: Grafisk design og funksjonalitet. Grafisk design beskriver den visuelle og grafiske delen av webapplikasjonen (CSS). Mens funksjonalitet dekker webapplikasjonens funksjoner (JavaScript og PHP). Nedenfor beskrives hver del i detalj. Side 23 av 78

24 Funksjonalitet steg for steg Her beskrives prosessen ved implementering av følgende hovedfunksjoner i webapplikasjonen. Utfordringer og problemer blir også dekket: 1. Integrasjon av LinkedIn sitt REST API 2. Autentisering av en bruker 3. Importering av brukerens LinkedIn informasjon 4. Oppbygning av CV-Editoren og eksportering av profil-data fra LinkedIn til CV-Editoren 5. Oppbygning av CV-en som et DOCX dokument 6. Lagring av CV 1. Integrasjon av LinkedIn sitt REST API For å få tilgang til LinkedIn sitt API, måtte gruppen først gjennomføre en registreringsprosess på LinkedIn sin utviklerside. Her registrerte vi blant annet informasjon om bedriften, utviklerne og til slutt selve webapplikasjonen/nettsiden. Som et resultat av dette fikk vi tildelt en API-nøkkel som blir brukt til å autentisere programmet som prøver å kommunisere med API-et. Dermed kunne LinkedIn sikre at API-et kun ble brukt av den rettmessige brukeren og på en riktig måte (i samsvar med LinkedIn sine regler for bruk av deres API). Etter hvert i prosjektet, fikk gruppen nyheter om at LinkedIn ønsket å begrense bruken av sitt API i og med at flere utviklere i over en lengre periode hadde benyttet seg av deres API på en måte som strider imot LinkedIn sine grunnprinsipper. Dessuten ville en begrensning bidra til flere fordeler for LinkedIn, blant annet økonomiske fordeler. ( Denne meldingen kom i midten av februar og prosjektet hadde allerede hatt betydelig fremgang og omfattende arbeid hadde blitt gjort. Det ville dermed være veldig uheldig om prosjektet vårt ville bli negativt påvirket av disse endringene. I tillegg til forandringer i kravene om bruk av LinkedIn sitt API, ble det også gjort omfattende forandringer/oppdateringer i dokumentasjonen til API-et. Dette beskrives nærmere i et senere punkt «Importering av brukerens LinkedIn informasjon». Fra og med nå (midten av februar), måtte bruk av API-et oppfylle LinkedIn sine krav om API-bruk avhengig av hvilke deler av API-et som en ønsket å bruke. I vårt tilfelle gjaldt dette «Profile-delen» av API-et, på grunn av at vi kun ønsket å få ut informasjon fra den påloggede brukerens LinkedIn-profil. Dermed var vi nødt til å oppfylle følgende krav: This API is intended for you to use on your company s career site, to help candidates easily apply for jobs. ( Side 24 av 78

25 Det er enkelt å se at webapplikasjonen vår oppfyller kravet om å hjelpe kandidater å enkelt søke etter en jobb. Dette skjer ved å tilby dem en måte å konvertere deres LinkedIn-profil til en CV i et av ServiceBroker sine CV-maler, slik at Service Broker videre kan bruke denne i rekrutteringsprosessen sin. Gruppen fulgte dermed brukerveiledningen på LinkedIn sin utviklerside om å søke om lov til å bruke deres «Profile API» med rettighet til brukrens fulle profil (r_fullprofile). Her ble vi bedt om å fylle et skjema med litt informasjon om bruken av webapplikasjonen og informasjon om bedriften: Det første svaret vi fikk, virket negativt. Det virket som om LinkedIn ikke skjønte hensikten med webapplikasjonen vår og refererte til «People search»-api-et deres som vi ikke engang bruker. Vi bestemte oss derfor for å oppklare eventuelle misforståelser fra deres side. Denne gangen virket responsen positiv, og svaret ga et inntrykk av at webapplikasjonen vår ville fungere som normalt. Det vil si at webapplikasjonen skulle ha tilgang til den fulle profilen til den påloggede brukeren via et profil-objekt som ble returnert fra LinkedIn sitt API. Vedlegg 1 lister opp skjermbilder av samtlige meldingsutvekslinger mellom LinkedIn og gruppen på deres utviklerside. Det er også merkverdig at det tok 13 dager å få det første svaret og omtrent 3 dager å få det andre svaret. Dermed gikk mye tid til venting. Det var tydelig at oppklaringen vår fikk et annet- og et mer positivt svar. Det var derfor naturlig for oss å anta at ting ville fremdeles fungere som det gjorde etter innføringen av forandringene på API-et deres. Ved annonsering av forandringene hadde LinkedIn i tillegg satt en dato for når forandringene skulle tre i kraft. Denne datoen var satt til Frem til da hadde gruppen nærmest utviklet et ferdigprodukt. Oppdragsgiver virket fornøyd og det ble planlagt et møte hvor gruppen og oppdragsgiver hovedsakelig skulle diskutere design av logoen på siden. Det viste seg at møtet ble et krisemøte i stedet, da gruppen ved midnatt fant ut at webapplikasjonen hadde mistet aksess til den fulle profilen til en tilfeldig pålogget bruker på webapplikasjonen. Dette var svært rystende nyheter for både gruppen og oppdragsgiver, og vi ble på møtet enige om å prøve å søke om tillatelse for bruk av API-et igjen, men denne gangen formulert på en litt annen måte og med selve bedriften (Service Broker) som avsender. Vi var alle klar over at det kunne ta flere dager å få et svar og dessuten var det også mulighet fot at vi kunne få enda et avslag av LinkedIn. Det ble derfor bestemt av oppdragsgiver at en midlertidig løsning var å bruke det API-et kunne tilby oss. For selv om en ikke hadde tilgang til den fulle profilen («r_fullprofile») til den påloggede brukeren, var det likevel mulig å hente noe grunnleggende data fra profilen, men denne var selvsagt mye mer begrenset («r_basicprofile»). Nedenfor er det to figurer Side 25 av 78

26 som viser forskjellen på profil-data returnert med aksess til den fulle profilen sammenlignet med profil-data returnert fra den grunnleggende profilen til vår test LinkedIn-profil spesifisert øverst i dokumentet). Figur 2: Det returnerte objektet fra LinkedIn sitt API med aksess til den fulle profilen. Figur 3: Det returnerte objektet fra LinkedIn sitt API med aksess til den grunnleggende profilen, her mangler informasjon om utdanninger, ferdigheter, kurs, sertifiseringer og diverse kontaktinformasjon om brukeren. Det ble på samme dag som møtet med oppdragsgiveren, holdt et møte med veilederen av prosjektet (Geir Skjevling) hvor vi diskuterte hva som hadde hendt og hvordan det kunne løses. Veilederen og gruppen kom fram til at det var lite vi kunne gjøre med LinkedIn sin avgjørelse, og det var en lettelse å få vite at LinkedIn sine forandringer ikke kom til å påvirke karakteren på bacheloroppgaven vår. Både veileder og oppdragsgiver fikk se webapplikasjonen når den fremdeles hadde tilgang til en pålogget bruker sin fulle profildata, spesielt oppdragsgiver kan bekrefte dette, se vedlegg 2 (tilbakemeldingen fra oppdragsgiver). Nå gjaldt det bare å finne en måte å demonstrere webapplikasjonens funksjoner for sensoren. Side 26 av 78

27 For å få demonstrert all funksjonaliteten til webapplikasjonen, ble vi enige om å lage et objekt med profildata for en forhåndsdefinert LinkedIn-profil. Dette objektet ser identisk ut som det som ville ha blitt returnert av LinkedIn sitt API dersom webapplikasjonen vår hadde hatt tilgang til den bestemte brukerens fulle profil. Objektet skal representere LinkedIn-profilen som sensor har fått tilgang til se forordet til dette dokumentet) og er kun ment for å demonstrere produktet og dets funksjonalitet. Dette blir nærmere beskrevet under punktet «3. Importering av brukerens LinkedIn informasjon». 2. Autentisering av bruker: Autentisering var en forholdsvis vanskelig prosess i og med at sikkerhet er et svært viktig tema. Autentisering skjer via OAuth 2.0 som tilbyr en sikker måte for autentisering i klienten. Dette var nytt for oss og vi måtte dermed sette oss inn i hvordan OAuth 2.0 kunne brukes i programmet vårt for å oppnå en sikker autentiseringsprosess. Prosessen å autentisere kan i korte trekk beskrives som følger: Brukeren trykker på logginn-knappen, han/hun vil deretter bli omdirigert til LinkedIn sin autentiseringsvindu hvor man blir bedt om å oppgi brukernavn og passord. Dette vinduet er selvstendig og bruker applikasjonsprotokollen HTTPS, dermed blir for eksempel «tyvlytting» av data veldig vanskelig å utføre for en angriper. Etter å ha oppgitt et gyldig brukernavn og passord og blitt OAuth 2.0-autentisert, blir man omdirigert tilbake til nettstedet. Mer spesifikt, blir man omdirigert til et PHP-skript som tar i bruk argumentene i URL-en for å hente en «Access Token» via AJAX og til en tilstandssjekk for økt sikkerhet. Skriptet oppretter «session-variabler», og en «cookie» som forteller om brukeren er innlogget eller ikke. Deretter blir man omdirigert tilbake til startpunktet, hvor man nå er logget inn og kan se data fra sin LinkedIn-profil importert via LinkedIn sitt REST API og presentert i en CVeditor. 3. Importering av brukerens LinkedIn informasjon Etter å ha autentisert brukeren, måtte vi få ut relevant data fra brukerens profil. Det krevde imidlertid at en var godt kjent med LinkedIn sitt API, mye tid gikk derfor til å studere dette grensesnittet og muligheten den tilbød oss. Det faktum at LinkedIn nylig hadde gjort flere omfattende forandringer i dokumentasjonssidene sine, gjorde ikke prosessen noe enklere i og med at vi allerede hadde fått en viss idé om hvordan dokumentasjonen var strukturert på deres gamle sider. Mye av den gamle dokumentasjonen ble ikke fjernet og ble dermed værende igjen på nettet sammen med det nye, dette resulterte i en forholdsvis rotete dokumentasjon. Det var derfor ingen overraskelse å se misfornøyde utviklere på Side 27 av 78

28 deres forum og det var også ofte her man fant svar på det man lurte på og forumet ble for oss en god del av «dokumentasjonen» til LinkedIn API-et. Et problem gruppen spesielt slet med, var å få ut en LinkedIn brukers profilinformasjon i et spesifikt språk. Som default ville profilinformasjonen på det språket som var spesifisert i innstillingene på nettleseren returneres. Dersom profilen kun var fylt ut på ett språk, ville denne bli returnert. Gruppen hadde til nå benyttet LinkedIn sitt JavaScript API som fungerer som en «wrapper» rundt deres REST-API. Poenget med dette API-et var å tilby utviklere med JavaScript bakgrunn en enkel måte å kommunisere med API-et på ved hjelp av et få antall kodelinjer på klienten. Dette viste seg å fungere bra for grunnleggende bruk, men svakheter ved denne kom tydelig fram etter hvert. Et av problemene med LinkedIn sitt JavaScript API «wrapper» var at man ikke kunne spesifisere hvilket språk man var interessert i å få profildataene til. LinkedIn sitt JavaScript API hadde både IN.API.profile( ) og IN.API.RAW( ), to funksjoner som begge kan brukes til å hente profildata, men ingen av dem tar en tekststreng for å sette ACCEPT-LANGAGE-header informasjon. Løsning ble å kommunisere med LinkedIn sitt REST API direkte i PHP script på serveren. I disse skriptene konstruerer vi http GET kall nesten fra grunnen av, ved å sette feltene selv. Som nevnt tidligere, hadde webapplikasjonen vår blitt fratatt rettigheten for aksess til den påloggede brukerens fulle profil. Nå var det kun mulig å få ut grunnleggende informasjon fra brukerens profil (se figur 2 og 3). For å få demonstrert funksjonaliteten til webapplikasjonen vår, var det helt nødvendig med aksess til den fulle profilen til brukeren. Gruppen valgte derfor å benytte seg av en forhåndsdefinert LinkedIn-profil (ola_nordmann@outlook.com) og simulere bruken av webapplikasjonen som om den hadde aksess til den fulle profilen til denne brukeren. Dette lot seg enkelt gjøre ved hjelp av LinkedIn sin «REST API Console» ( en nettside som brukes for å teste REST API-et deres av utviklere. Ved å logge inn på den forhåndsdefinerte LinkedIn-profilen vår på denne nettsiden og samtidig be om profil-data fra den fulle profilen til denne brukeren manuelt, kunne vi motta profil-dataen i samme form som den ellers ville ha blitt returnert fra deres REST API og til webapplikasjonen vår. Profil-dataen er formatert i JSON 6 og er identisk med profil-dataen webapplikasjonen vår ville ha mottatt dersom den hadde hatt full-profil aksess. Alt som skulle til nå, var noen små endringer i koden slik at webapplikasjonen kunne avgjøre om den påloggede brukeren var ola_nordmann-profilen eller en annen. Dersom 6 JSON: JavaScript Object Notation, en enkel tekstbasert standard for datautveksling. Side 28 av 78

29 den påloggede brukeren er ola_nordmann-profilen, vil webapplikasjonen benytte seg av den forhåndsdefinerte JSON-dataen for denne profilen. Dersom det er en annen bruker som prøver å logge seg på, vil kun den grunnleggende profil-dataen fra denne brukerens profil bli aksessert og eksportert til CV-editoren på siden. Skulle det vise seg at applikasjonen vår, i senere tid, likevel får tillatelse fra LinkedIn om å aksessere den fulle profilen til brukeren, må en kun endre på API-nøkkelen i koden og dermed kan mer data fra profilen eksporteres til CV-editoren og webapplikasjonen vil fungere slik den var ment å fungere. 4. Oppbygning av CV-editoren og eksportering av profil-data fra LinkedIn til CV-Editoren Når vi endelig kunne hente ut informasjonen fra den påloggedes LinkedIn-profil, gjaldt det å presentere denne informasjonen i en CV-Editor på en oversiktlig og brukervennlig måte for brukeren. Siden mengde informasjon selvsagt vil variere fra en LinkedIn-profil til en annen, skjønte vi kjapt at vi måtte dynamisk opprette denne CV-Editoren for å tilpasse mengde informasjon fra en profil. Spørsmålet var bare hvordan informasjonen skulle presenteres. Etter mye brainstorming og flere diskusjoner om brukervennlige designløsninger for en webapplikasjon/nettside, kom gruppen fram til en løsning som kort kan beskrives slik: Presentere data fra profilen i et skjema (engelsk: form), slik at brukeren enkelt og kjapt kan redigere og velge ønsket data. Til slutt velger brukeren en CV-mal som dataen skal eksporteres til. Fordelene med en slik løsning er at plassbruken på siden blir liten i og med at skjemaet kan splittes opp i flere logiske deler i forhold til type informasjon fra LinkedInprofilen slik at brukeren kun ser en del av skjemaet om gangen. Eksempler på de ulike delene av skjemaet er «personalia», «erfaringer», «utdanninger» og «kurs» osv. En annen viktig fordel med denne løsningen er støtte for en flytende og rask prosess, oppdelingen av informasjonen i ulike deler gjør det enklere for brukeren å raskt få en oversikt over informasjonen og brukeren trenger dermed bare å huke av for de data som skal med i den endelige CV-en, velge en ønsket CV-mal og lagre CV-en lokalt eller få den tilsendt på e-post. Alt skjer på en og samme side (Single Page Application, beskrevet under «Design») 5. Oppbygning av CV-en som et DOCX dokument Når brukeren endelig er ferdig med å redigere og velge informasjon via CV-Editoren, skal han/hun kunne eksportere denne informasjonen til en ønsket CV-mal i form av et DOCX dokument. Gruppen var derfor nødt til å finne en måte for å dynamisk opprette et DOCX dokument basert på informasjonen som brukeren ønsker å ha med i dokumentet. Etter en god del research, landet vi til slutt på PHP biblioteket PHPWord (beskrevet under verktøy). Side 29 av 78

30 Det fantes ikke et bedre open-source bibliotek skrevet i PHP enn denne, de andre var ikke open-source og ikke gratis å bruke. Det var fint å jobbe med et vel-dokumentert bibliotek med drøssevis av eksempler i motsetning til LinkedIn sitt API. Problemet var imidlertid at PHPWord manglet flere grunnleggende funksjoner, som for eksempel det å sette en bakgrunn på dokumentet og plassering av visse elementer i dokumentet. Dermed kunne det bli et problem å opprette et DOCX dokument for CV-en fra bunnen av, derfor valgte vi i stedet å prøve ut PHPWords funksjoner for redigering av allerede eksisterende dokumenter eller såkalte «templates» (mal). Det å ta utgangspunkt i en predefinert mal og bygge videre på denne basert på dataen som brukeren vil ha med i CV-en virket som en god idé, men det viste seg at det å legge inn nye elementer i en mal ikke fungert veldig bra. Planen var at vi kunne bruke PHPWord sin «replaceblock» -funksjon, for å bytte ut tomme indekserte paragrafer i en mal, med paragrafer som for eksempel «Utdanning», og deretter «setvalue» - funksjonen for å legge inn ønsket data som «tittel», «år», «beskrivelse», osv. Denne løsningen burde egentlig ha vært enkel å gjennomføre, men svakheter i PHPWord API-et resulterte til at det var helt tilfeldig om en variabel eller paragraf ble endret, eller ikke. Etterhvert fant vi ut hvorfor disse feilene oppstod, ved hjelp av å studere documents.xml-filen som ligger pakket inn i DOCX-filen. Feilen var at teksteditorene ofte ville splitte opp de indekserte paragrafene i malen i flere deler, og derfor kunne ikke API-et finne de variablene og paragrafene den skulle endre. Dette kunne løses ved å manuelt redigere documents.xml filen til malen, ved å legge inn indekserte paragrafer på en måte som gjør at API-et finner frem. Dette fant vi ut ganske sent, og vi hadde allerede kommet godt i gang med den første løsningen. Vi ble derfor enige om å opprette et dokument fra bunnen av. Delvis av tidsmessige årsaker. Vi fant snart ut at det meste av plasserings problemene lot seg løse ved hjelp av tabeller og litt kreativitet. Usynlige tabeller og tabeller i tabeller ble brukt for å etterligne CV-malen spesifisert i kravspesifikasjonen, det viste seg at resultatet faktisk ble nærmest identisk med malen vi hadde som vi prøvde å etterligne og dokumentet så relativ lik ut i begge de store tekstbehandlingsverktøyene Microsoft Word og LibreOffice Writer. 6. Lagring av CV Til slutt kan brukeren velge om å få laste ned CV-en direkte eller få den tilsendt på e-post. Dette var en enkel prosess i og med at PHPMailer ble brukt for å håndtere sendingen av epost. Det eneste som tok tid var å få serveren vår ut av blacklisten slik at vi kunne sende e-post. Side 30 av 78

31 Brukergrensesnitt/grafisk design Oppdragsgiver hadde ikke mange spesifikke krav til brukergrensesnittet og gruppen var derfor relativ fri om valg av grafisk design på webapplikasjon. Vi valgte å gå for en enkel, ren, brukervennlig og intuitiv design. Følgende valg ble utført for å oppnå dette: - Navigasjon Navigasjonen foregår hovedsakelig ved at brukeren logger inn via sin LinkedIn-profil slik at informasjonen fra denne profilen blir vist i en CV-Editor. Her kan man enten velge å logge ut eller eksportere informasjonen til en CV- mal i form av et DOCX dokument. Øverst på siden valgte vi å ha en relativ enkel navigasjonsmeny som består av en link til hovedsiden, en side for brukerveiledning, en link til CV-editoren og til slutt en nedtrekksmeny for å logge ut av LinkedIn og dermed webapplikasjonen, endre profilspråk og gå til linkedinprofilen sin. Dennen nedtrekksmenyen vises dessuten kun når brukeren er innlogget. Med andre ord ble resultatet en enkel og intuitiv navigasjon på nettsiden, hvor det ikke må mange klikk til for å oppnå ønsket resultat. - Fargevalg Fargevalget ble avgjørende for brukeropplevelsen, vi gikk for relativ harmoniske farger. Fargekombinasjonen lys sort, lys grått og hvitt vil gi brukeren en følelse av behag og gi brukeren en god kontrast mellom bakgrunn og tekst. Dessuten skal fargevalget være tilpasset brukere med fargeblindhet. - Grafikk og visuelle effekter Moderne utseende på grafiske elementer ble fokuset. Logo, knapper og annet grafikk ble nøye gjennomtenkt og testet i alle de store nettleserne. Logoen ble valgt med hensyn til domenenavnet som både oppdragsgiver og gruppe kom til enighet om. Visuelle effekter ble brukt for å tilføre siden «det lille ekstra», det vil gi brukeren en følelse av å bruke en webapplikasjon istedenfor en statisk nettside. 3.5 Kravspesifikasjonen og dens rolle Dette kapittelet beskriver viktigheten av en dynamisk kravspesifikasjon og tar for seg hvordan den samsvarer med det endelige produktet Hovedrolle og betydning Side 31 av 78

32 Kravspesifikasjonen er et svært sentralt dokument i prosjektet. Dokumentet spiller en essensiell rolle når det gjelder enighet mellom oppdragsgiver og/eller bruker og utvikler. Den fungerer nemlig som en avtale/kontrakt mellom de ulike partene i prosjektet ved å beskrive de krav som oppdragsgiver og bruker har til løsningen som skal utvikles. I tillegg fungerer kravspesifikasjonen som et styringsdokument gjennom hele prosjektet. Man kan hele tiden se mot den under utviklingsprosessen i og med at den uttrykker det som prosjektet skal bli Endringer i kravspesifikasjonen Kravene i kravspesifikasjonen ble i utgangspunktet hovedsakelig spesifisert av oppdragsgiver, men fordi vi har valgt en smidig utviklingsprosess som er basert på iterativ utvikling, har kravspesifikasjonen fortløpende blitt endret gjennom utviklingsprosessen. Disse endringene er ikke et resultat av et manglende bilde av det endelige sluttproduktet, men endringene reflekterer heller over en smidig utviklingsprosess hvor man hele tiden ser etter forbedringer og dermed oppnå et best mulig resultat. Etter hver delleveranse av produktet, har gruppen og oppdragsgiver avtalt et felles møte hvor gruppen har presentert arbeidet utført så langt i forhold til kravspesifikasjonen. Dermed har oppdragsgiver fått en oversikt over eventuelle utfordringer, veien videre og progresjonen i prosjektet med hensyn til tiden. Alt dette har videre resultert i en dynamisk kravspesifikasjon. 3.6 Avsluttende del Produktet Applikasjonen endte opp med å oppfylle alle hovedkravene fra oppdragsgiver, og de fleste tilleggskravene. Hvis det ikke hadde vært for LinkedIn som endret retningslinjene for API-et, hadde dette endt opp som et komplett produkt, som kunne gitt nytteverdi til oppdragsgiver, og deres kunder. Dersom Service Broker i senere tid får rettigheter til den fulle profilen til den påloggede brukeren (r_fullprofile), kan webapplikasjonen enkelt endres til å hente ut ønsket informasjon. Læringsutbytte I løpet av prosjektperioden har vi lært mye mer om programmering på web. PHP og JavaScript (JQuery) sitter nå i fingrene. Vi har lært mye om å kommunisere med API-er (LinkedIn sitt REST API og PHPWord), og har erfart at vi ikke kan stole på at det alltid vil fungere. I tillegg har vi har lært hvordan det er å være i en virkelig arbeidssituasjon, hvor vi skal utvikle et produkt ut ifra oppdragsgivers spesifikasjoner, og deretter om kommunikasjonsprosessen, frem til produktet er ferdig. Det har vært nyttig å benytte den smidige utviklingsmodellen Extreme Programming sammen prosjektstyringsverktøyet Trello. Side 32 av 78

33 Konklusjon Vi kan si at vi er ganske fornøyde med prosjektet. Arbeidsgiver har hele tiden gitt uttrykk for at de var veldig fornøyd med fremgangen, og resultatet av prosjektet. Dersom LinkedIn ikke hadde begrenset API-et, kunne vi sagt at prosjektet var en suksess. Side 33 av 78

34 4 Produktdokumentasjon Innholdsfortegnelse 4. Produktdokumentasjon 4.1 Forord 4.2 Hensikt og prinsipiell beskrivelse av produktet 4.3 Samsvar med kravspesifikasjonen 4.4 Innledning til produktet LinkedIn sitt REST API Programmeringsspråk 4.5 Oppbygning Generelle trekk og de ulike delene av programmet 4.6 Detaljert beskrivelse Integrasjon av LinkedIn sitt REST API Autentisering av en bruker Importering av brukerens LinkedIn informasjon Oppbygning av CV-Editoren og eksportering av profildata fra LinkedIn til CV-Editoren Oppbygning av CV-en som et DOCX dokument Mottakelse av CV-en Side 34 av 78

35 4.1 Forord NB! Det er en forutsetning at leseren har kjennskap til presentasjonsdelen av prosjektet. Det å ha blitt kjent med problemstilling, bakgrunn og de ulike partene i prosjektet vil naturligvis gi en bedre forståelse av det som skrives om i dette dokumentet. Produktdokumentasjonen er hovedsakelig ment for oppdragsgiver, men den vil selvsagt også være egnet for sensor og veileder. Dokumentet beskriver programmet på en utfyllende måte, og tar spesielt for seg den tekniske delen av produktet. I rapporten brukes det en del data-relaterte begreper, det vil derfor være en fordel å ha kompetanse innenfor data, spesielt webprogrammering. Datatekniske ord og begreper blir forklart underveis slik at leseren hele tiden forstår eksakt hva det skrives om. Flere av disse begrepene blir forklart på samme side som de blir nevnt, slik at leseren slipper å forholde seg til en «ordbok» i form av et vedlegg. 4.2 Hensikt og prinsipiell beskrivelse av produktet Produktet er en nettside/webapplikasjon hvor man kan importere CV-relatert informasjon fra sin LinkedIn-profil 7 til en CV-editor på siden. Dette gjøres ved at brukeren logger inn på sin LinkedInprofil via webapplikasjonen slik at den dermed kan få hentet informasjonen fra brukerens profil via LinkedIn sitt API 8. Videre skal man kunne velge og endre den importerte informasjonen i denne CV-editoren. Til slutt eksporteres informasjonen til en valgfri CV-mal i form av et DOCX 9 dokument. Brukeren skal kunne velge om informasjonen fra han/hennes LinkedIn-profil skal være på norsk eller engelsk avhengig om brukeren har opprettet en profil på disse språkene. Default skal være norsk og dersom brukeren ikke har en norsk profil, returneres profilen i det språket som er brukt på profilen. Hensikten med dette produktet er å forenkle jobbsøkerprosessen for folk med relevant informasjon på sin LinkedIn-profil. Løsningen vil være en del av Service Brokers tjenester som 7 LinkedIn: Et verdensledende sosialt nettverk som hovedsakelig brukes i forretningsøyemed. 8 API: Application Programming Interface, et programmeringsgrensesnitt for kommunikasjon mellom programvare. 9 DOCX: En Word Microsoft Office Open XML Format Document fil. Formatet brukes av alle de nye versjonene av Microsoft Word og andre tekstbehandlingsverktøy. Side 35 av 78

36 tilbys arbeidssøkere for å bidra i en jobbsøkerprosess, hvor det å kunne presentere seg selv med en ryddig CV er viktig 4.3 Samsvar med kravspesifikasjonen Samtlige obligatoriske krav, både funksjonelle- og ikke-funksjonelle krav, har blitt implementert og fullført. Det som derimot ikke ble fullført, var det ønskede tilleggskravet om mobiltilpasning av webapplikasjonen. Selv om webapplikasjonen fungerer på mobil, er ikke det grafiske utseende egnet for små skjermer og nettsiden er dermed ikke veldig brukervennlig på mobil. Planen var å opprette en egen CSS stylesheet for mobil-versjonen, men på grunn av flere tidskrevende og samtidig uforutsette utfordringer i prosjektet (se prosessdokumentasjonen) valgte vi å la dette være noe for videreutviklingen av webapplikasjonen. Fordi et av kravene var «Det skal være enkelt å endre den grafiske designen» og fordi dette kravet også er oppfylt, skal det være forholdsvis enkelt å oppfylle kravet om en mobiltilpasset versjon av nettsiden. 4.4 Innledning til produktet Her beskrives det steg for steg hva som skulle til for å komme i gang med utviklingen av produktet. Dette var helt essensielt forarbeid og videreutviklere bør absolutt gjøre seg kjent med denne innledningen. Til slutt skrives det kort om hvilke teknologier som benyttes og deres bruksområder i webapplikasjonen LinkedIn sitt REST API Fordi kjernen i webapplikasjonen består av å hente informasjon fra en pålogget bruker sin LinkedIn-profil, er det helt nødvendig med aksess til LinkedIn sitt programmeringsgrensesnitt/api. Dette gjøres enkelt ved at man først oppretter en LinkedIn-profil og deretter går til LinkedIn sin utviklerside hvor man kan få opprettet en applikasjon. Ved opprettelse av en applikasjon blir man bedt om diverse informasjon om bruk, bedrift og utvikler. For webapplikasjonen vår, ble vi nødt til å spesifisere standardomfang (Engelsk: scope) og på grunn av at vi ønsket CV-relatert informasjon fra en profil, valgte vi følgende «scopes»: r_fullprofile, r_ adress og r_contactinfo. Ved autentisering, vil brukeren bli spurt om å godkjenne tilgang til de oppgitte «scopene» slik at brukeren vet hva slags informasjon programmet ønsker fra han/hennes profil. Etter å ha fullført registreringsprosessen for applikasjonen, vil det bli generert en API-nøkkel og en hemmelig-nøkkel som brukes i webapplikasjonen slik at LinkedIn kan autentisere programmet ved API-kall. Siden LinkedIn endret en del på reglene for bruk av API-et, er det også nødvendig å søke om bruk av API-nøkkelen og dermed unngå blokkering av denne. Fordi webapplikasjonen vår møter LinkedIn sine kriterier (spesifisert på LinkedIn sin utviklerside) om bruk av deres API, ble forespørselen vår godkjent. Side 36 av 78

37 Etter å ha fått aktivert API-nøkkelen fra LinkedIn, kan man spesifisere denne sammen med den hemmelige nøkkelen i programmet. Dette beskrives i detalj senere i dokumentet under «3. Importering av brukerens LinkedIn informasjon». LinkedIn tilbyr, i skrivende stund, hovedsakelig to forskjellige måter å kommunisere med deres API på. Den mest utbredte måten er å benytte deres REST-API og den andre måten er å bruke deres JavaScript API som fungerer som en «wrapper» rundt REST-API-et. Ulempen med sistnevnte er imidlertid at den er noe begrenset og produktet vårt bruker derfor REST (flere detaljer om dette i prosessdokumentasjonen) Programmeringsspråk Webapplikasjonen benytter seg av flere forskjellige programmeringsspråk, under følger en kort beskrivelse av bruksområdene til disse: PHP PHP brukes på backend/server for oppbygning av siden og kommunikasjon med LinkedIn sitt REST- API. Dessuten brukes PHP for generering av CV-en i DOCX format via open-source biblioteket PHPWord og for nedlastning av CV-en lokalt, inkludert sending av CV-en til e-post. HTML med CSS HTML og CSS brukes for å opprette selve nettsiden, HTML utgjør strukturen mens CSS definerer det grafiske. JavaScript (JQuery) JavaScript brukes for å styre dynamikken i webapplikasjonen. Fordi programmet er en såkalt «single page application» er JavaScript helt nødvendig for å kunne skjule og vise de forskjellige delene av programmet. JavaScript biblioteket JQuery gjør JavaScript-kode mer kompakt og brukes konstant i koden. Det er ved hjelp av JavasScript at informasjonen fra en pålogget bruker sin LinkedIn-profil eksporteres til en dynamisk opprettet CV-editor i webapplikasjonen. AJAX AJAX brukes hovedsakelig sammen med JQuery og PHP for å autentisere en bruker via OAuth 2.0 og for å kommunisere med LinkedIn sitt REST-API. 4.5 Oppbygning I dette kapittelet beskrives oppbygningen til webapplikasjonen ved å først redegjøre for generelle trekk ved den og deretter gi en oversikt over de ulike delene av programmet og hvordan de Side 37 av 78

38 henger sammen. Til slutt beskrives funksjonaliteten steg for steg fra da en bruker autentiseres til da han/hun mottar den genererte CV-en Generelle trekk og de ulike delene av programmet Webapplikasjonen er en såkalt Single Page Application (SPA). Fordelen med en slik modell er at antallet spørringer mot server for å laste ned sider blir redusert, siden vil aldri bli lastet ned på nytt i prosessen (med mindre brukeren tvinger dette fram), dette er spesielt nyttig dersom man har mange brukere. Webapplikasjonen lastes en gang fra server og deretter brukes Ajax for å kommunisere med server. Fra da brukeren blir autentisert til da informasjon fra LinkedIn-profilen blir lest og dynamisk eksportert til en CV-editor, vil alt skje på én og samme side ved hjelp av JavaScript (JQuery og CSS) som dynamisk skjuler og viser de relevante delene av siden i forhold til hvilken steg/tilstand brukeren befinner seg i prosessen. En annen viktig fordel med en SPA er at tilstandsbevaring blir håndtert på en god måte, dersom man har satt en variabel, vet man at den fremdeles vil være der. Dette gir en følelse av at man utvikler en applikasjon i stedet for en nettside og forhindrer unødvendig bruk av ressurser på server ved at man slipper å håndtere tilstand. Med andre ord, siden webapplikasjonen er en «Single Page Application», vil det være et hovedprogram som vil utgjøre en stor del av programmet. Hovedprogrammet vil bestå av mye kode og alt kommunikasjon med andre underprogrammer vil skje via dette programmet. I vårt tilfelle vil hovedprogrammet være hovedsiden i webapplikasjonen som er index.php. Under følger en visuell oversikt over de ulike delene av webapplikasjonen og hvordan kommunikasjon dem imellom foregår. Side 38 av 78

39 Figur 4: Oversikt over hovedprogram og underprogrammer. Servicebroker.php, Simple.php og Unformatted.php utgjør CV-malene. 4.6 Detaljert beskrivelse Dette delkapittelet tar for seg en detaljert beskrivelse av oppbygning og funksjonaliteten til de ulike delene av webapplikasjonen steg for steg. Beskrivelsen av programmet kan deles opp med hensyn på funksjonaliteten i de ulike delene av programmet: Integrasjon av LinkedIn sitt REST API Dette er beskrevet under «innledning» ovenfor («4.4 Innledning til produktet») Autentisering av en bruker For at vi skal kunne hente ut brukernes profildata fra LinkedIn's servere, eller gjøre ting på brukernes vegne, så må de autentiseres. LinkedIn bruker industristandarden OAuth 2.0 til dette. OAuth 2.0 er en åpen standardisert protokoll brukt til å gi klientapplikasjoner sikker tilgang til ressurser på ens servere. Vi er i denne sammenhengen en klient sett fra LinkedIn's perspektiv. Protokollen er lagd spesifikt for HTTP (Hypertex Transfer Protocol). Sikker tilgang gis ved at OAuth utsteder tilgangstokener som kan brukes av en tredjepart klient (vår applikasjon). Disse tilgangstokene kan vi som tredjeparts klient bruke til å få tilgang til ressurser på LinkedIn's servere. Første steg i å autentisere en bruker er å ha registret og konfigurert webapplikasjonen hos LinkedIn. For å hindre uredelige transaksjoner så krever LinkedIn at vi har spesifisert URL-ene til alle stedene på serveren vår, hvor vi skal kommunisere med LinkedIn. Kun disse endepunktene vil LinkedIn stole på. I tillegg har vi måtte oppgi hvilke endepunkter som skal brukes som «OAuth 2.0 Redirect URLs». Dette punktet er auth.php, PHP skriptet vil bli kjørt ved tilbakekall fra LinkedIn etter de har sjekket at brukernavnet og passordet brukeren skrev inn var korrekt. URL-ene som oppgis må være absolutte, og HTTPS burde brukes så mye som mulig. Etter man har skrevet inn nødvendig informasjon i ens LinkedIn applikasjons profil, så vil man få tildelt en unik API-nøkkel («Client ID») og en hemmelig nøkkel («Client Secret»). Disse nøklene vil bli gitt som parametere i omdirigering til LinkedIn autentisering og henting av tilgangstoken. OAuth-brukertoken og OAuth-brukerhemmelighet tas ikke i bruk av vår applikasjon. I filen conifg.php så oppgir vi API-nøkkelen og den hemmelige nøkkelen, denne egne konfigurasjons filen inkluderes og verdiene i den assosiative array-en lagres i session variabel, som brukes i filene auth.php og fetch.php. Side 39 av 78

40 Fil config.php: 1. <?php 2. return array( 3. 'api_key' => '78fnimuk3fzha5', 4. 'secret_key' => 'QjCmcogrjIcFH9pI' 5. ); 6.?> I filen auth.php så håndteres OAuth 2 kontroll flyten. Dette skriptet blir omdirigert til, først av vår JavaScript kode kjørende på brukernes maskiner, for å starte autentiserings prosessen. Andre så er det LinkedIn som omdirigerer tilbake til dette skriptet, etter å autentisering og deretter skal man hente tilgangstoken. Begge gangene må auth.php skriptet sjekke parameterne som ble sendt med HTTP forespørslene, på bakgrunn av hvilke parametere som er gitt så vil neste handling tas. OAuth 2 kontroll flyten i auth.php ser slik ut: Fil auth.php: 1. // OAuth 2 Control Flow 2. if (isset($_get['error'])) { 3. header("path_on_server/index.php"); } elseif (isset($_get['code'])) { 6. // User authorized application 7. if ($_SESSION['state'] == $_GET['state']) { 8. // Get Access Token to make API calls 9. getaccesstoken(); } else { header("location: path_on_server/index.php"); 14. } 15. } else { 16. if ((emptyempty($_session['expires_at'])) (time() > $_SESSION['expires_at'])) { 17. // Token has expired, clear the state 18. $_SESSION = array(); 19. } 20. if (emptyempty($_session['access_token'])) { 21. // Start authorization process 22. getauthorizationcode(); 23. } 24. } Her sjekkes hvilke parametere som har blit send med HTTP GET kallet til auth.php filen. Hvis en av de parameterne man sender med til LinkedIn ved autentisering eller tilgangstoken forespørsel er feil, så vil LinkedIn omdirigere tilbake til gitt endepunkt (auth.php) med en parameter error i URLen (server/path_on_server/auth.php?error=error_message). I disse tilfellene pluss hvis brukeren Side 40 av 78

41 trykker avbryt under autentisering så vil først if test resultere til sant. Vi håndterer da dette tilfellet ved å enkelt omdirigere brukeren til startsiden. Om parameteren «code» er satt, så har brukeren blitt omdirigert vellykket fra forespørselen om OAuth 2.0 autorisasjonskode. Koden er en av to parametere som man får fra LinkedIn etter at brukeren har gitt LinkedIn gyldig brukernavn og passord. Parameter nummer to er «state», dette er en litt lengre tilfeldig tekststreng (fra funksjonen uniqid()) som er praktisk umulig å få riktig ved et XSS (Cross-site scripting angrep). Tekststrengen «state» er det vi som genererer og både sender til LinkedIn og lagrer i en (session) variabel. Hvis LinkedIn sender tilbake samme tilstand tilbake i URL-en er alt greit. Her er funksjonen som omdirigerer brukeren til LinkedIn's OAuth 2.0 autorisasjons endepunkt: 1. function getauthorizationcode() { $params = array('response_type' => 'code', 4. 'client_id' => API_KEY, 5. 'redirect_uri' => REDIRECT_URI, 6. 'state' => uniqid('', true), // unique long string 7. 'scope' => SCOPE 8. ); // Authentication request 11. $url = ' http_build_query($params); // Needed to identify request when it returns 14. $_SESSION['state'] = $params['state']; // Redirect user to authenticate 17. header("location: $url"); 18. exit(); 19. } Funksjonen får klientens maskin til å sende en HTTP GET forespørsel til adressen: i tillegg så sender vi med fem parametere. Første er response_type som alltid er satt til 'code', fordi det er ikke noe annet å få tilbake enn OAuth 2.0 koden. Andre er client_id, med andre ord API-nøkkelen hentet fra config.php (define('api_key', $config['api_key']);). Tredje er redirect_uri, den URI-en som brukerne vil bli sendt tilbake til etter autentisering, må være lik den registrert hos LinkedIn. Fjerde er state, en unik tekststreng som er vanskelig å gjette. Femte er scope, valgfri, en URL-kodet, mellomrom separert liste av områder applikasjonen ønsker tilgang til (define('scope', 'r_fullprofile r_ address r_contactinfo');). Andre steg i kontrollflyten er å utveksle autorisasjonskoden for en tilgangstoken («Access Token»). Dette er gjøres ved å sende en «x-www-form-urlencoded» HTTP POST forespørsel til LinkedIn, til denne adressen: Dette sørger kontrollflyten å gjøre når brukeren har bli omdirigert tilbake til auth.php etter autentisering, ved å sjekke at LinkedIn har gitt oss parameteren «code» og «state». Når i tillegg tilstanden er den samme som vi lagret i session variablene vår tidligere ($_SESSION['state'] == $_GET['state']), så kan endelig funksjonen getaccesstoken bli kjørt: Side 41 av 78

42 1. function getaccesstoken() { 2. $params = array( 3. 'grant_type' => 'authorization_code', 4. 'code' => $_GET['code'], 5. 'redirect_uri' => REDIRECT_URI 6. 'client_id' => API_KEY, 7. 'client_secret' => API_SECRET, 8. ); // Access Token request 11. $url = ' http_build_query($params); // Tell streams to make a POST request 14. $context = stream_context_create( 15. array('http' => 16. array('method' => 'POST', 17. ))); // Retrieve access token information 20. $response = file_get_contents($url, false, $context); // Convert to Native PHP object 23. $token = json_decode($response); // Store access token and expiration time 26. $_SESSION['access_token'] = $token->access_token; // guard this! 27. $_SESSION['expires_in'] = $token->expires_in; // relative time (in seconds) 28. $_SESSION['expires_at'] = time() + $_SESSION['expires_in']; // absolute time return true; 31. } Denne funksjonen tar seg av utveksle av autorisasjonskoden for en tilgangstoken. Det første som skjer er at den konstruerer URL-en hvor vi henter tilgangstoken fra, med de riktige parameterne. Alle de fem parameteren er obligatoriske. «grant_type» skal alltid være satt til «authorization_code», fordi det er kun det den forventer (en autorisasjonskode i bytte mot tilgangstoken). «code» er den autorisasjonskoden vi akkurat fikk fra at brukeren kommuniserte med LinkedIn (godtok oss ved å gi brukernavn og passord). «redirect_uri» er samme tilbakekall endepunkt som forrige steg (auth.php), LinkedIn vil omdirigere brukeren til auth.php enda en gang, etter å ha utstedte tilgangstoken. «client_id» («API Key») er API-nøkkelen og «client_secret» («Secret Key») er den hemmelige nøkkelen til webapplikasjonen vår. Det andre som skjer er at vi lager konteksten til forespørselen som kommer til å skje mot URL-en vi akkurat konstruerte. Konteksten er «headere» i HTTP forespørselen, altså data som sendes med som bestemmer hvilke type forespørsel dette er, headeren 'method' settes til 'POST', dette gjør HTTP forespørselen til en POST istenfor et standard GET kall. Funksjonen file_get_contents henter og leser en hel fil inn i variabelen $response, den filen vi fikk ved å spesifiere gitt kontekst til gitt URL. Et vellykket "Access Token» forespørsel returnerer et JSON (JavaScript Object Notation) objekt med to felter: 'access_token' som vi har ventet så lenge på og 'expires_in' som er antall sekunder til tilgangstokenet er gyldig fra det ble overrakt. Vi dekoder JSON objektet til et PHP objekt, ved hjelp av funksjonen json_decode, slik at vi kan enkelt hente ut feltene. Feltene lagrer vi i session variabler, slik at de kan enkelt brukes når vi skal importere brukernes profil informasjon i skriptet fetch.php. Etter at funksjonen returnert true, så Side 42 av 78

43 har kontrollflyten i auth.php gjort jobben sin. Skriptet avslutter ved å gi klienten en cookie (setcookie("linked", "true", time() + some_time, '/');), som vi kan bruke i JavaScirpt-koden vår for å sjekk om auth.php var vellykket. Deretter omdirigere brukeren tilbake til startsiden hvor han eller henne kan gjøre et AJAX kall til fetch.php, som vil ta i bruk tilgangstokenet og hente brukerprofilen deres. Helt til slutt så gjør vi et kall på die(), som er tilsvarende til exit(), forsikrer oss om at skriptet blir terminert. 1. session_name('linkedin'); 2. session_start(); $config = include( DIR. '/config.php'); Siste par bemerkninger. «session_name('linkedin');» setter eller henter sesjonen «linkedin», alle data man lagret i sesjonsvariable i andre skript vil være tilgjengelig til samme bruker som opprettet den sesjonen. Sesjonsvariabler er som cookies på serveren. «session_start();» starter eller forsetter på en eksisterende økt, slik at man manipulere (sette, endre eller slette) ressurser tilknyttet økten. PHP tilbyr et stort antall magiske konstanter, der i blant ' DIR ' som står for stien til gjeldene fil (auth.php i dette tilfellet). Man kan da spesifisere relativ sti til config.php som skal inkluderes, som her er i samme mappe som auth.php Importering av brukerens LinkedIn informasjon AJAX (Asynchronous JavaScript and XML) handler om å kunne oppdatere deler av en web side, uten å måte laste ned hele nettsiden om igjen. Med AJAX, så kan en webapplikasjon som vår sende til og motta fra data mellom serveren og klient asynkront, det vil si i bakgrunnen utføres kallet uten at brukeren merker dette. Resultetet er at AJAX forstyrrer ikke utsende og oppførselen til den eksisterende siden. Data kan mottas ved bruk av et XMLHttpRequest objekt, til tross for XML i navnet, så brukes dette objektet også til motta JSON. Webapplikasjonen vår bruker egentlig AJAJ (Asynchronous JavaScript and JSON), men dette håndteres likt, man spesifiserer bare JSON i kallet. Man kan også spesifisere forespørselen til å ikke være asynkront. Siden webapplikasjonen vår allerede bruker jquery, så har vi tatt i bruk jquery.ajax() som abstraherer og forenkler AJAX for oss. For at vi kan importere brukerens LinkedIn informasjon så må auth.php skriptet ha blitt kjørt. Brukeren skal da være autentisert ved hjelp av protokollen OAuth 2.0, tilgangstoken skal være hentet ved hjelp av autorisasjonskoden og lagret i sesjonsvariabelen 'access_token'. Når dette er på plass så vil JavaScript koden kjørene hos klientene finne at cookie-en 'linked' er satt til 'true', og dermed utføre et AJAX kall ved hjelp av jquery sin $.ajax funksjon. Vår JavaScript funksjon fetchprofile tar seg av dette, alt man trenger å gjøre er å spesifisere språket og feltene man helt vil ha. Denne funksjonen kaller vi kun etter å ha sjekket cookie-en 'linked': 1. // Function to do a ajax GET request to get ones profile information Side 43 av 78

44 2. // Parameters: accept language (no-no, en- US), query string. 3. function fetchprofile(lang, fields) 4. { 5. $.ajax({ 6. url : 'path_on_server/fetch.php', 7. type: 'GET', 8. data: {'lang': lang, 'fields': fields}, 9. datatype: 'json', 10. // async: false, 11. success: function(data, status) { 12. if (status == "success") { 13. // Users profile data in a JSON object 'data' 14. console.log(data); 15. } 16. }, 17. error: function(xhr, desc, err) { }); 20. } 21. }); 22. } Her ser vi hvor enkelt AJAX kall kan gjøres ved hjelp av JQuery. I stedet for å omdirigere brukeren til fetch.php så kjører vi «fetch» i bakgrunnen. URL-en er til ressursen man skal ha på serveren. 'type' er 'GET' fordi vi bare henter data fra serveren. 'data' er parametere sendt med URL-en, og datatypen vi skal ha tilbake er JSON. Hvis skriptet ble kjørt vellykket så vil den annonyme success funksjonen bli kjørt, først argument 'data' vil da være brukerens profildata i form av et JSON objekt. Hvis derimot PHP skriptet ikke returnerer med return, men for eksempel terminerer skriptet med exit() eller die(), så vil error funksjonen bli kjørt. At dette skjer kan være forårsaket en «parse error» i PHP skriptet, som igjen har skjedd for eksempel fordi brukeren oppdaterte siden mens den lastet, se testdokumentasjonen for detaljer angående dette. AJAX kallet fra JavaScript funksjonen kjørende på brukernes maskiner, vil få PHP skriptet fetch.php kjørt av serveren. Men skriptet trenger å få tilsendt to parametere, 'lang' og 'fields'. Første parameter er en tekststreng med språkkoder som brukes i headeren «Accept-Language» i PHP skriptetes forespørsel til LinkedIn. Listen forteller LinkedIn hvilke av de språk man har innført sin profil på, man ønsker helst å få utgitt til seg. Hvis man kaller «fetchprofile» med en tom tekststreng til 'lang' argumentet, så vil LinkedIn gi brukeren engelske profil, standard «Accept- Language» som blir brukt av LinkedIn er «en-us». Sett «lang» til «no-no» for å få ut brukerens Norske profil. Språkkodene JavaScript funksjonen og fetch.php krever er standard «acceptlanguage HTTP header» verdier, ikke de LinkedIn bruker til sitt JavaScript API wrapper ( Argumentet nummer to, 'fields', er en tekststreng som legges til 'host' URL-en: Alle forespørsler som henter data fra LinkedIn's REST API, sendes til undermappen /v1/people/~ på serveren api.linkedin.com. I tillegg til stien så inneholder tekststrengen fetchprofile andre argument alle parameterene som spesifiserer hvilke LinkedIn seksjoner som skal hentes ut fra brukerens profil. LinkedIn kaller disse seksjonidentifikatorene for Side 44 av 78

45 «Profile Field Descriptions», her er lister over felter som er tilgjengelig under rettighetene man trenger for å hente dem ut: Følgende variabel querystr holder på en tekststreng som når gitt til fetchprofile vil bli lagt til verten api.linkedin.com, til sammen dannes URL-en som vi får ønskede brukerprofilseksjoner fra. 1. // The query string to LinkedIn's REST API, telling which information is needed from the 2. // user's profile. 3. var querystr = "/v1/people/~:(first-name,last-name,headline, -address,picture-url"; 4. querystr += ",positions,industry,date-of-birth,summary,main-address,phone-numbers"; 5. querystr += ",skills:(skill),public-profile-url,languages:(id,language,proficiency)"; 6. querystr += ",educations,courses,publications,certifications:(id,name,authority:(name)"; 7. querystr += ",number,start-date,end-date))"; For at vi får lov til å hente ut alle informasjonen webapplikasjonen vår trenger, så har vi hos LinkedIn registeret at vi ønsker at de ber brukeren om å godkjenne under autentisering, at vi får tilgang til disse tre områdene: r_contactinfo, r_ address og r_fullprofile. Vår webapplikasjon får altså lov til å hente ut kontaktinformasjon, epostadresse og hele profilen med alle sine seksjoner som 'Experience', 'Summary', 'Education', 'Skills & Endorsements' og 'Languages'. Skriptet fetch.php tar seg av alt dette, med hjelp av sesjon variable fra auth.php som blant annet har lagret områdene vi har tilgang til. Kontrollflyten i skriptet som håndterer importering av brukernes profilinformasjon ser slik ut: Fil fetch.php: 1. session_name('linkedin'); 2. session_start(); if (isset($_get['lang']) && isset($_get['fields'])) { 5. return fetch($_get['lang'], $_GET['fields']); 6. } die(); Her importer vi sesjonen 'linkedin' og starter den, kontrollflyten er en enkel test for å se om forespørselen til skriptet inneholder parameteren 'lang', språkkodene som vil settes i «Accept- Language» header-en, og 'fields' med resten av URL-en som nevnt over. Hvis disse to parameeterene er git så vil de bli gitt til funksjonen fetch, som kan ses under. Funksjonen returnerer JSON objectet vi henter fra '?format=json' legges til av funksjonen ellers vile profilinformasjonen returneres av LinkedIn på XML format, vi valgte å bruke JSON fordi dette går bedre sammen med JavaScript koden som skal vise informasjonen. Her er endelig fetch funksjonen som auth.php gjorde ting klart for. 1. function fetch($language, $resource) { 2. $params = array('oauth2_access_token' => $_SESSION['access_token'], 3. 'format' => 'json' 4. ); // Need to use HTTPS 7. $url = ' $resource. '?'. http_build_query($params); // Streams makes a GET request 10. $context = stream_context_create( Side 45 av 78

46 11. array('http' => 12. ray('method' => 'GET', 13. 'header' => "Accept-language: ". $language. "\r\n" ) return file_get_contents($url, false, $context); 16. } Her setter vi først parameterne som skal gis til LinkedIn, tilgangstokenet som gir oss tilgang til brukerens data og format=json slik at vi får disse dataene på JSON format. URL-en blir så konstruert med host-en api.linkedin.com som vi henter dataene fra og resursene (kodeord for profilseksjonene vi ønsker) vi gir programmet hos LinkedIn som vil hente dem ut av LinkedIn databasene. I tillegg til URL-en så trenger vi en kontekst fil forespørselen, i den spesifiserer vi at dette HTTP kallet er av type 'GET' og at vi vil ha skesjonene på gitt språk, som foreslått av 'Accept- Language' headeren. Til slutt så returner vi det vi får av LinkedIn og avslutter skriptet med die(). JSON objektet som returneres ser slik ut, når skrevet ut i Google Chrome konsollen: Figur 5: Det returnerte objektet fra LinkedIn sitt REST API. AJAX kallet som fikk serveren til å kjøre fetch.php vil nå være fullført og 'on success' funksjonen blir kjørt. Brukeren vil se sin profilinformasjon grafisk i nettleseren og kan ta i bruk nettstedets mange andre funksjonaliteter. Når brukeren er ferdig og trykker logg ut, eller hvis AJAX kallene ikke er vellykket og kjører «on error» funksjonen, så gjør vi et kall på skriptet end.php. I dette siste PHP skriptet angående sesjon 'linkedin' så tar vi å frigjør ressursene brukeren har krevd av serveren og setter cookie-en 'linked' til false. Det gjør ingenting at cookie-en utløper, for funksjonen som sjekker om den er true vil returnere false om den er slette av brukerens nettleser. Her er det siste PHP skriptet: Fil end.php: 1. <?php 2. session_name('linkedin'); Side 46 av 78

47 3. session_start(); // remove all session variables 6. session_unset(); 7. // destroy the session 8. session_destroy(); setcookie("linked", "false", time() , '/'); exit("success"); 13.?> Oppbygning av CV-Editoren og eksportering av profil-data fra LinkedIn til CV-Editoren Etter å ha importert data fra den påloggede brukerens Linkedin-profil via «fetchprofile()» funksjonen, vil dataen som nevnt organiseres i et objekt. Dermed kan man aksessere dets attributter som vil være informasjon om den påloggede brukeren. Dette profil-objektet («result») sendes videre til funksjonen «showprofiledataincveditor(result)». Nå er man sikker på at brukeren er autentisert og kan vise brukeren relevant innhold på siden som nedtrekks-menyen (tre horisontale streker) i hovednavigasjonen og selve CV-editoren (HTMLskejmaet). Profil-objektet blir lagret i en variabel med navn «profile» og HTML-skjemaet, som utgjør CV-editoren, blir lagt i variabelen «theform». Disse variablene sendes videre til en rekke andre funksjoner som har som oppgave å opprette selve CV-editoren og fylle den med forskjellig informasjon fra brukerens profil. Funksjonen «updatefielddata()» beskrives senere. 1. // index.php 2. function showprofiledataincveditor(result) { showmainnavdropdown(); 5. gotocveditor(); 6. console.log(result); var profile = result; 9. var theform = document.forms["cveditorform"]; addpersonalia(theform, profile); 12. addsummary(theform, profile); 13. addeducations(theform, profile); 14. addexperiences(theform, profile); 15. addskills(theform, profile); 16. addcourses(theform, profile); 17. addcertifications(theform, profile); updatefielddata(); } Side 47 av 78

48 Øverst i index.php blir det deklarert en del globale variabler, flere av disse er navn på id-attributtet til HTML-elementer på siden og navn på CSS-klasser. Dette er selvsagt for å gjøre endringer på disse navnene enkelt å utføre i senere tid. De variablene som er viktigere å legge merke til, er følgende: 1. // index.php 2. var chosenfields = []; 3. var numberofskills = 0; 4. var numberofcourses = 0; 5. var numberoflanguages = 0; 6. var numberofeducations = 0; 7. var numberofexperiences = 0; 8. var numberofcertifications = 0; 9. var profilepictureurl = ""; 10. var DIRECT_DOWNLOAD = "directdownload"; 11. var ON_ = "on "; 12. // Default profile and CV language set to norwegian 13. var cvlang = no; «chosenfields» er en array som består av name-attributtene til input-feltene som brukeren velger ved å trykke på den tilhørende sjekk-boksen til feltet. Variablene som starter med «numberof» vil bestå av antall utdanninger, ferdigheter og erfaringer osv. en bruker har på sin LinkedIn-profil. Mens «profilepictureurl» naturligvis vil bestå av en url til brukerens profil-bilde på LinkedIn. Det er videre i koden definert to «konstanter», disse er egentlig variable, men endres aldri i koden. Konstantene er skrevet med store bokstaver for å skille dem fra vanlige variabler. Konstantene «DIRECT_DOWNLOAD» og «ON_ » blir brukt for å avgjøre om brukeren vil laste ned den ferdigenererte CV-en direkte eller motta den på e-post. Variabelen «cvlang» blir brukt for å avgjøre hvilket språk profil-informasjonen skal importeres på og språket som blir brukt i CV-en og på deler av CV-editoren. Felles for alle disse varabelene og konstantene er at de utgjør informasjon som blir brukt for å opprette CV-en. CV-en blir opprettet i et DOCX format via PHP-biblioteket PHPWord, de nevnte variablene er definert i klienten (JavaScript) og må dermed sendes videre til serveren (PHP) for å kunne brukes av PHPWord. Måten det skjer på er via såkalte «hidden input fields», altså skjulte input-felter i CV-editoren, som er et HTML-skjema. Når brukeren enten velger å laste ned CV-en eller motta den på e-post, vil dette HTML-skjemaet sin «submit()» funksjon kalles. Denne sørger for at det som står spesifisert i action-attributtet til dette HTML-skjemaet (et PHP-skript) vil kjøres. Deretter vil all data som står i input-feltene til CV-editoren være tilgjengelige på server (PHP) via et superglobalt-array kalt $_POST og man kan dermed bruke dataen fra variablene og konstantene definert i klienten på serveren. Her er en kodesnutt fra index.php som viser HTML-skjemaet som utgjør CV-editoren: 1. <form id="cveditorform" name="cveditorform" action="cvgeneration/cvtemplates/servicebroker.php" metho d="post"> 2. <input type="hidden" id="chosenfields" name="chosenfields" value=""></input> 3. <input type="hidden" id="cvdocumentlanguage" name="cvdocumentlanguage" value=""></input> Side 48 av 78

49 4. <input type="hidden" id="numberoflanguages" name="numberoflanguages" value=""></input> 5. <input type="hidden" id="numberofeducations" name="numberofeducations" value=""></input> 6. <input type="hidden" id="numberofexperiences" name="numberofexperiences" value=""></inpu> 7. <input type="hidden" id="numberofskills" name="numberofskills" value=""></input> 8. <input type="hidden" id="numberofcourses" name="numberofcourses" value=""></input> 9. <input type="hidden" id="numberofcertifications" name="numberofcertifications" value=""></input> 10. <input type="hidden" id="pictureurl" name="pictureurl" value=""></input> 11. <input type="hidden" id="directdownloadoron " name="directdownloadoron " value=""></input> 12. </form> For at disse input-feltene skal få data fra de nevnte variablene og konstantene, må en bruke funksjonen «updatefielddata()» som blant annet brukes i «showprofiledataincveditor»: 1. // index.php 2. function updatefielddata() { 3. $("#chosenfields").val(chosenfields.join()); 4. if (cvlang === no) { 5. $("#cvdocumentlanguage").val("no-no"); 6. } else { 7. $("#cvdocumentlanguage").val("en-us"); 8. } $("#numberoflanguages").val(numberoflanguages); 11. $("#numberofeducations").val(numberofeducations); 12. $("#numberofexperiences").val(numberofexperiences); 13. $("#numberofskills").val(numberofskills); 14. $("#numberofcourses").val(numberofcourses); 15. $("#numberofcertifications").val(numberofcertifications); 16. $("#pictureurl").val(profilepictureurl); 17. } Når det gjelder selve oppbygningen av HTML-skjemaet som utgjør CV-editoren, vil noe av innholdet bygges opp dynamisk via JavaScript, mens resten vil være definert som statisk HTML. Kodesnutten som viser de skulte input-feltene er blant annet definert som statisk HTML. I tillegg er også den vertikale navigasjonsmenyen for CV-editoren definert som statisk HTML. Informasjonen fra en bruker sin LinkedIn-profil deles opp i ulike logiske deler, informasjon om selve brukeren kategoriseres som «personalia», informasjon om utdanninger, erfaringer, kurs, ferdigheter og sertifiseringer deles opp i hver sin del. Disse delene kalles heretter seksjoner fordi de separeres i hver sitt HTML-section-element («<section>»). All denne informasjonen vil dynamisk bli lagt til det overnevnte HTML-skjemaet. Dette skjer først ved et kall på den nevnte funksjonen «showprofiledataincveditor» 1. // index.php 2. function showprofiledataincveditor(result) { showmainnavdropdown(); 5. gotocveditor(); 6. console.log(result); var profile = result; 9. var theform = document.forms["cveditorform"]; Side 49 av 78

50 addpersonalia(theform, profile); 12. addsummary(theform, profile); 13. addeducations(theform, profile); 14. addexperiences(theform, profile); 15. addskills(theform, profile); 16. addcourses(theform, profile); 17. addcertifications(theform, profile); updatefielddata(); 20. Funksjonene bygger opp HTML-skjemaet i CV-editoren slik at den vil bestå av profil-informasjonen som brukeren lett kan velge og endre. 1. addpersonalia(theform, profile); 2. addsummary(theform, profile); 3. addeducations(theform, profile); 4. addexperiences(theform, profile); 5. addskills(theform, profile); 6. addcourses(theform, profile); 7. addcertifications(theform, profile); Samtlige av disse funksjonene bruker JavaScript Document Object Model (DOM) som rett og slett er JavaScript for manipulering av HTML-elementer. Det brukes hovedsakelig samme fremgangsmåte i alle disse funksjonene, det vil derfor være tilstrekkelig å studere kun en av dem for å forstå funksjonaliteten i de andre. La oss se nærmere på hvordan funksjonen «addeducations» er implementert del for del: 1. function addeducations(theform, profile) { var section = createsection(educations_section_id); 4. var subtitle = createsubtitle(cvlang.education); 5. var checkbox = createcheckboxallfields(section.id); subtitle.appendchild(checkbox); 8. section.appendchild(subtitle); var fieldset; 11. var fieldsetcontainer = document.createelement("div"); 12. } I den første delen, opprettes det et section-element deretter lages det en tittel-boks som hovedsakelig er et h2-element, dette er den mørk-fargede boksen som er plassert øverst på hvert section-element. Videre opprettes det en sjekkboks som brukes til å velge alle eller velge bort alle Side 50 av 78

51 input-feltene som befinner seg i et section-element i CV-editoren. Nedenfor listes funksjonene som gjør denne jobben: 1. function createsection(sectionid) { 2. var section = document.createelement("section"); 3. section.id = sectionid; 4. return section; 5. } function createsubtitle(title) { 8. var subtitle = document.createelement("h2"); 9. subtitle.classname = "cveditorsubtitle"; 10. subtitle.innerhtml = title; 11. return subtitle; 12. } function createcheckboxallfields(sectionid) { var checkboxmaincontainer = document.createelement("div"); 17. checkboxmaincontainer.classname = "checkboxmaincontainer"; var checkboxcontainer = document.createelement("div"); 20. checkboxcontainer.classname = "custom_checkbox"; var checkbox = document.createelement("input"); 23. checkbox.type = "checkbox"; 24. checkbox.checked = false; 25. checkbox.addeventlistener("click", function () { 26. if (checkbox.checked) { 27. checkallfields(sectionid, checkbox); 28. } else { 29. uncheckallfields(sectionid, checkbox); 30. } 31. }); var name = "button_"; 34. var checkboxlabel = document.createelement("label"); checkbox.id = name + checkboxnumber; 37. checkboxlabel.htmlfor = name + checkboxnumber; 38. checkboxnumber++; checkboxcontainer.appendchild(checkbox); 41. checkboxcontainer.appendchild(checkboxlabel); 42. checkboxmaincontainer.appendchild(checkboxcontainer); return checkboxmaincontainer; 45. } Side 51 av 78

52 Hver funksjon returnerer det opprettede HTML-elementet slik at det kan lagres i variabler i callback-funksjonen («addeducations(theform, profie)) slik at man ved hjelp av «appendchild()» kan sette sammen de forskjellige elementene. Videre i koden deklareres en variabel for å holde rede på et fieldset-element, dette elementet vil bestå av flere andre elementer som label, inputfield og checkbox. Det vil for hver utdanning bli opprettet et eget fieldset-element slik at de forskjellige utdanningene kan separeres i sectionelementet. Fieldset-elementene legges først inni et div-element som fungerer som en container («fieldsetcontainer») som igjen blir lagt til section-elementet. Videre ser funksjonen slik ut: 1. function addeducations(theform, profile) { // var educations = profile.educations.values; 6. if (educations === undefined educations === null) { 7. fieldset = document.createelement("fieldset"); 8. shownodatamessage(fieldset, fieldsetcontainer, section); 9. } else { 10. numberofeducations = educations.length; 11. for (var i = 0; i < numberofeducations; i++) { fieldset = document.createelement("fieldset"); var study = educations[i].fieldofstudy; 16. if (study === undefined study === null) { 17. fieldset.appendchild(addfield("fieldofstudy" + i, "", TEXT_LABEL_CSS, cvlang.title, false)); 18. } else { 19. fieldset.appendchild(addfield("fieldofstudy" + i, study, TEXT_LABEL_CSS, cvlang.title, true)) ; 20. } var deegre = educations[i].degree; 23. if (deegre === undefined deegre === null) { 24. fieldset.appendchild(addfield("degree" + i, "", TEXT_LABEL_CSS, cvlang.degree, false)); 25. } else { 26. fieldset.appendchild(addfield("degree" + i, deegre, TEXT_LABEL_CSS, cvlang.degree, true)); 27. } var schoolname = educations[i].schoolname; 30. if (schoolname === undefined) { 31. fieldset.appendchild(addfield("schoolname" + i, "", TEXT_LABEL_CSS, cvlang.school, false)); 32. } else { 33. fieldset.appendchild(addfield("schoolname" + i, schoolname, TEXT_LABEL_CSS, cvlang.school, tr ue)); 34. } var startdate = educations[i].startdate; 37. var enddate = educations[i].enddate; 38. if (enddate === undefined) { 39. fieldset.appendchild(addfield("educationsperiod" + i, startdate.year + " - " + cvlang.current, TEXT_LABEL_CSS, cvlang.period, true)); 40. } else { 41. fieldset.appendchild(addfield("educationsperiod" + i, startdate.year + " - " + enddate.year, TEXT_LABEL_CSS, cvlang.period, true)); 42. } 43. Side 52 av 78

53 44. var notes = educations[i].notes; 45. if (notes === undefined) { 46. fieldset.appendchild(addtextarea("notes" + i, "", "fieldtextarea", TEXT_LABEL_CSS, cvlang.abo ut, false)); 47. } else { 48. fieldset.appendchild(addtextarea("notes" + i, notes, "fieldtextarea", TEXT_LABEL_CSS, cvlang. about, true)); 49. } 50. fieldsetcontainer.appendchild(fieldset); 51. } 52. } 53. section.style.display = "none"; 54. fieldsetcontainer.style.display = "none"; 55. section.appendchild(fieldsetcontainer); 56. theform.appendchild(section); 57. } Kodelinjen var educations = profile.educations.values sørger for å få tak I utdanningene til den påloggede brukeren, hvor values er en array bestående av objekter som igjen består av informasjon om en utdanning. If-testen: 1. if (educations === undefined educations === null) { 2. fieldset = document.createelement("fieldset"); 3. shownodatamessage(fieldset, fieldsetcontainer, section); 4. } sørger rett og slett for at dersom brukeren ikke har noen informasjon om utdanningene sine på sin LinkedIn-profil, vil en melding om det vises. Dersom brukeren har informasjon om utdanningene sine på sin LinkedIn-profil, vil man gå videre til er løkke som går gjennom samtlige utdanninger fra brukerens profil. 1. for (var i = 0; i < numberofeducations; i++) { fieldset = document.createelement("fieldset"); var study = educations[i].fieldofstudy; 6. if (study === undefined study === null) { 7. fieldset.appendchild(addfield("fieldofstudy" + i, "", TEXT_LABEL_CSS, cvlang.title, false)); 8. } else { 9. fieldset.appendchild(addfield("fieldofstudy" + i, study, TEXT_LABEL_CSS, cvlang.title, true)); 10. } 11. // 12. } Det blir for hver gjennomgang av løkken opprettet et fieldset-element som det legges andre HTML-elementer i. Et eksempel på et attributt i utdannings-objektet er «fieldofstudy» som betyr studieretning på norsk. Her blir den tidligere definerte variabelen «educations» brukt, den består av en array med utdanningsobjekter. I første gjennomgang av løkken vil første utdanningsobjekt bli benyttet, det gjøres først en sjekk om at attributtet «fieldofstudy» er fylt ut på brukerens Side 53 av 78

54 LinkedIn-profil. Dersom det ikke er tilfellet vil det bli opprettet et tomt input felt som vil bestå av en hjelpe-tekst som ber brukeren å skrive noe i feltet og sjekkboksen til feltet vil ikke være sjekket. Dersom brukeren derimot har fylt ut «fieldofstudy» på profilen sin, vil det bli opprettet et inputfelt bestående av denne informasjonen og sjekkboksen til dette feltet vil være sjekket. Følgende kode utgjør funksjonen «addfield()», denne legger hovedsakelig til et label-element, et inputfield-element og en checkbox-element og dette utgjør til sammen et «felt» i CV-editoren: 1. function addfield(key, value, classlabel, flabel, ischecked) { 2. if (ischecked) { 3. chosenfields.push(key); 4. } var input = document.createelement("input"); 7. input.name = key; 8. input.classname = INPUT_FIELD_CSS; 9. input.id = key; 10. if (value === "") { 11. input.placeholder = "Fyll inn informasjon"; 12. } else { 13. input.value = value; 14. } var checkbox = createcheckboxsinglefield(key, ischecked); var field = document.createelement("div"); 19. field.classname = "fieldcontainer"; 20. field.id = key + "p"; var label = document.createelement("label"); 23. label.id = key + "l"; 24. label.classname = classlabel; 25. label.value = flabel; 26. label.innerhtml = flabel; field.appendchild(label); 29. field.appendchild(input); 30. field.appendchild(checkbox); return field; I den siste delen av «addeducations(theform, profile)» blir alle HTMLelementer slått sammen og lagt i section-elementet: 1. function addeducations(theform, profile) { 2. // section.style.display = "none"; 4. fieldsetcontainer.style.display = "none"; Side 54 av 78

55 5. section.appendchild(fieldsetcontainer); 6. theform.appendchild(section); 7. } Oppbygning av CV-en som et DOCX dokument Etter at brukeren er ferdig med å redigere informasjonen fra sin LinkedIn-profil i CV-editoren, vil det være mulig å velge en mal for CV-en. Dette gjøres ved at brukeren trykker på «Velg CV-mal» i den vertikale menyen og deretter klikker på en ønsket mal slik at malen blir valgt og dermed vist som et stort bilde. Bildet er et eksempel-bilde og er kun ment for å demonstrere hvordan malen ser ut. Dette er egentlig et bildet av en ferdig generert CV fra en LinkedIn-profil som ble laget for å teste og presentere webapplikasjonen. Det er viktig at dette bildet har samme navn som malen. Dersom brukeren for eksempel velger malen Simple.php (vist i figur 4), bør også bildet ha samme navn, kun filetternavnet vil være annerledes, bildet vil da for eksempel hete «Simple.png». Årsaken til dette er at man for det første enkelt kan finne fram til en mal sin tilhørende demonstrasjons-bilde. Dessuten er de små klikkbare elementene på bunnen CV-mal-velgeren opprinnelig bilde-elementer definert i HTML: 1. <img src="simple.png" onclick="selectcvtemplate(this)" /> Ved å klikke på et av disse elementene, vil funksjonen selectcvtemplate(this) kalles og den vil rett og slett bruke det som står i src-attributtet og erstatte filetternavnet med «.php». Resultatet i dette eksempelet vil da være Simple.php. Denne tekst-strengen blir videre sendt til «action» attributtet til HTML-skjemaet (CV-editoren). Dette medfører at dersom brukeren ønsker å motta CV-en sin, enten via direkte nedlastning eller på e-post, vil PHP-filen som er spesifisert i «action» attributtet i HTML-skjemaet kjøres og brukeren vil dermed få CV-en sin i den malen som ble valgt i «Velg CV-mal»-seksjonen. Når det gjelder selve genereringen av CV-en i DOCX format, skjer det i PHP-filene som er spesifisert i «action» attributtet. Dersom man ser på figur 4 kommer det fram at disse PHP-filene består av en annen PHP-fil, nemlig «ClientDataAndLibraries.php». Denne filen består igjen av 3 andre PHP filer: - lang.php: Inneholder to assosiative arrays, den ene består av norske ord som blir brukt i den genererte CV-en og den andre består av de engelske oversettelsene av disse ordene. Denne filen blir dermed brukt for å håndtere språket som brukeren vil spesifisere CV-en i. Her en kodesnutt som viser hvordan en slik array kan se ut: 1. $norwegian = array( 2. "personalia" => "Personalia", 3. "summary" => "Oppsummering", Side 55 av 78

56 4. "education" => "Utdanning", 5. "experience" => "Erfaring", 6. "skills" => "Ferdigheter", 7. ); For å benytte dette kan man for eksempel skrive: $norwegian["summary"]; som vil gi tekststrengen «Oppsummering». - PHPWord: Et open-source bibliotek skrevet i PHP som tilbyr et sett med klasser for å skrive til og lese fra forskjellige filformater. PHPWord brukes til å opprette selve DOCX dokument dynamisk ved hjelp av PHP. - PHPMailer: Et bibliotek skrevet i PHP for å forenkle prosessen å sende epost på en trygg måte fra en webserver. Enkelt å blant annet sende epost med vedlegg, blir brukt for å sende den genererte CV-en til brukerens epost. PHPWord, lang.php og PHPMailer blir alle inkludert i ClientDataAndLibraries.php filen. Denne blir igjen inkludert i PHP-filene for CV-malene, som for eksempel Simple.php og ServiceBroker.php. Det er derfor viktig at man først forstår hva filen ClientDataAndLibraries.php gjør: - ClientDataAndLibraries.php Fordi denne filen inkluderer «lang.php» og PHP bibliotekene PHPWord og PHPMailer, vil man i «ClientDataAndLibraries.php» kunne bruke all kode som er spesifisert i disse. Det første som utføres er at data fra de skjulte input-feltene i CV-editoren leses. Lesingen skjer ved at man benytter seg av den superglobale array-en «$_POST» og funksjonen «filter_input(input_post, "DATA")». Dersom man for eksempel ønsker å hente data fra et input-felt i CV-editoren, bruker man «name»-attributtet fra dette input-feltet og erstatter «DATA» med det som står i «name». Et eksempel for å få tak i språket brukeren har valgt: 1. <input type="hidden" id="cvdocumentlanguage" name="cvdocumentlanguage" value=""></input> Her ser vi at «name» er satt til «cvdocumentlanguage», man kan dermed bruke denne verdien for å få tak i data-en I input feltet: 1. filter_input(input_post, "cvdocumentlanguage"); Følgende kodesnutt avgjør hvilket språk CV-en skal genereres i: Side 56 av 78

57 1. // Choose the CV-language 2. if (filter_input(input_post, "cvdocumentlanguage") === "no-no") { 3. global $labelnames; 4. $labelnames = $norwegian; 5. } else { 6. global $labelnames; 7. $labelnames = $english; 8. } Her er «$norwegian» og «$english» assosiative arrays definert i lang.php som ClientDataAndLibraries.php inkluderer. Kodesnutt fra lang.php: 1. <?php 2. $norwegian = array( 3. "personalia" => "Personalia", 4. "summary" => "Oppsummering", 5. "education" => "Utdanning", 6. "experience" => "Erfaring", 7. "skills" => "Ferdigheter", 8. "courses" => "Kurs", 9. "certifications" => "Sertifiseringer", 10. ); Videre i ClientDataAndLibraries leses alle de skjulte input-feltene, som for eksempel antall språk, antall utdanninger, informasjon om brukeren vil laste ned CV-en direkte eller få den tilsendt på e- post og en array med alle felt som brukeren vil ha med i CV-en. Et eksempel på det sistnevnte: 1. $chosenfieldsstring = filter_input(input_post, "chosenfields"); 2. $chosenfields = explode(",", $chosenfieldsstring); De valgte feltene fra CV-editoren er oppgitt i input-feltet som en komma-separert streng med «name»-attributtene til feltene. Denne strengen gjøres senere om til en array slik at man enkelt kan søke etter relevant data for å generere CV-en med PHPWord. PHPWord brukes først i selve PHP filene som genererer CV-en: ServiceBroker.php, Simple.php og Unformatted.PHP. For å bruke PHPWord må man først opprette en instans av PHPWord klassen: 1. $phpword = new \PhpOffice\PhpWord\PhpWord(); Deretter kan man definere eventuelle «styles» for fonten, titler og selve dokumentet. Videre, opprettes det en seksjon og i denne vil alt innhold som blir laget, legges inn: Side 57 av 78

58 1. $section = $phpword->addsection(); CV-en som opprettes vil være et DOCX dokument som hovedsakelig består av flere tabeller, nedenfor følger en forklaring av en kodesnutt fra Simple.php. Metoden som beskrives her brukes av samtlige PHP filer som genererer CV-en (Servicebroker.php, Simple.php og Unformatted.php), det vil være små forskjeller grunnet forskjeller i selve malen, men man vil enkelt kunne forstå og gjøre endringer i disse filene ved å forstå denne fremgangsmåten: Vi antar at brukeren som er pålogget, har flere utdanninger på LinkedIn-profilen sin, det skal nå opprettes en CV med informasjon om alle utdanningene til brukeren. Man starter med å sjekke om brukeren har noen utdanninger, dersom det er tilfellet, gjør man et kall på outputeducations($numberofeducations, $section) som tar imot antall utdanninger og selve seksjonen som alt innhold i dokumentet skal skrives til. 1. // Simple.php 2. if ($numberofeducations > 0) { 3. outputeducations($numberofeducations, $section); 4. $section->addtextbreak(1); 5. } Det kan være lurt å danne seg et bildet av hvordan resultatet vil se ut, bildet på figur 6 viser en av utdanningene til brukeren. Figur 6: Informasjon om en utdanning i en ferdig generert CV. Denne funksjonen bruker de globale variablene som er definert i ClientDataAndLibraries.php og i den øvrige delen av Simple.php. «$labelnames» vil bestå av et assosiativ array som enten er en tabell over de norske ordene brukt i en CV, eller de engelske. «$chosenfields» som også er nevnt tidligere, består av «name»-attributtene av de feltene som brukeren har valgt i CV-editoren. «$stylecell» definerer stilen en enkel celle skal få i tabellen som opprettes. Deretter går man i en løkke like mange ganger som det er antall utdanninger, for hver utdanning legges det til en rad i tabellen og denne raden deles opp i 3 celler med ulik størrelse hver. Side 58 av 78

59 Videre sjekker man om det er den første gjennomgangen av løkken, dersom det er det, legges det til en tittel i første kolonne i tabellen. Avhengig av hvilket språk brukeren har valgt, vil tittelen være «Utdanning» eller «Education». Til slutt vil funksjonen writeeducationsvalues($j, $chosenfields, $educationscol2, $educationscol3) kalles. Denne tar I mot $j som forteller hvilken utdannings-nummer som er den aktuelle, dersom brukeren har 3 utdanninger vil «$j» ha 0, 1 og 2 som verdi etter 3 gjennomganger. Andre parameter er en array som består av de valgte feltene. Deretter sendes henholdsvis andre og tredje kolonne av tabellen (første brukes til tittelen) 1. // Simple.php 2. function outputeducations($n, $sec) { 3. global $labelnames; 4. global $chosenfields; 5. global $stylecell; $educationstable = $sec->addtable('tablecv'); for ($j = 0; $j < $n; $j++) { $educationstable->addrow(array('cantsplit' => true)); $educationscol1 = $educationstable->addcell(1800, $stylecell); 14. $educationscol2 = $educationstable->addcell(4000, $stylecell); 15. $educationscol3 = $educationstable->addcell(5000, $stylecell); if ($j === 0) { 18. $educationscol >addtext(htmlspecialchars($labelnames["education"]), 'subtitlecv'); 20. } 21. writeeducationsvalues($j, $chosenfields, $educationscol2, $educationscol3); 22. } 23. } writeeducationsvalues() funksjonen vil rett og slett for hver utdanning skrive ut perioden («educationsperiod»), studienavn («fieldofstudy»), skolenavn («schoolname»), grad («degree») og til slutt en liten oppsummering («notes»). Dette gjøres ved å søke etter verdiene i «$chosenfields» ved hjelp av en PHP-funskonen array_search() denne vil enten returnere «TRUE» eller «0» dersom elementet det søkes etter er det første og FALSE dersom elementet ikke finnes. Det er derfor viktig at if-testen er slik: if ($i!== FALSE) og ikke slik: if ($i) eller if ($i === TRUE) Side 59 av 78

60 Dersom if-testen slår til, vil det I andre kolonne legges til perioden og I den tredje kolonnen vil studienavn («fieldofstudy»), skolenavn («schoolname»), grad («degree») oppsummering («notes») legges til etter hverandre. 1. // Simple.php 2. function writeeducationsvalues($j, $chosenfields, $educationscol2, $educationscol3) { 3. $i = array_search("educationsperiod". $j, $chosenfields); 4. if ($i!== FALSE) { 5. $value = filter_input(input_post, $chosenfields[$i]); 6. $educationscol2->addtext(htmlspecialchars($value), 'pcv'); 7. } $i = array_search("fieldofstudy". $j, $chosenfields); 11. if ($i!== FALSE) { 12. $value = filter_input(input_post, $chosenfields[$i]); 13. $educationscol3->addtext(htmlspecialchars($value), 'pboldcv'); 14. } $i = array_search("schoolname". $j, $chosenfields); 18. if ($i!== FALSE) { 19. $value = filter_input(input_post, $chosenfields[$i]); 20. $educationscol3->addtext(htmlspecialchars($value), 'pcv'); 21. } $i = array_search("degree". $j, $chosenfields); 25. if ($i!== FALSE) { 26. $value = filter_input(input_post, $chosenfields[$i]); 27. $educationscol3->addtext(htmlspecialchars($value), 'pcv'); 28. } $i = array_search("notes". $j, $chosenfields); 32. if ($i!== FALSE) { 33. $value = filter_input(input_post, $chosenfields[$i]); 34. $educationscol3->addtext(htmlspecialchars($value), 'pcv'); 35. } 36. } Mottakelse av CV-en Når all data er skrevet til PHPWord objektet, vil man komme til følgende kode: 1. // Checks wether user wants the CV directly or on // Variables and functions from ClientDataAndLibraries.php 3. if($directdownloadoron === "directdownload"){ 4. downloadcv ($phpword); 5. }else{ 6. getcvon ($phpword,$recipient ,$name); 7. } Side 60 av 78

61 Avhengig av om brukeren har valgt å laste ned CV-en direkte eller motta den på epost, vil en av funksjonene downloadcv($phpword) eller getcvon ($phpword,$recipient ,$name) kalles. Disse er spesifisert i ClientDataAndLibraries.php. Side 61 av 78

62 5 Testdokumentasjon Innholdsfortegnelse 5. Testdokumentasjon 5.1 Forord 5.2 LinkedIn sitt JavaScript API test 5.3 Klient-server stresstest 5.4 Cross browser support test 5.5 Cross office suite test Side 62 av 78

63 5.1 Forord Vi har med vår testing av produktet forsøkt å tilby oppdragsgiver et objektivt perspektiv på både, kvaliteten av kildekoden, og til den grad vi oppfyller kravene spesifisert i kravspesifikasjonen. Testingen var nyttig for å kartlegge risikoen ved videre satsing på vår løsning. Vi har konkludert at forbedringer vil være mer lønnsomt enn å starte fra bunnen av for videreutviklerne. Deler av koden er abstrakt nok og nødvendig i enhver applikasjon mot LinkedIn sitt REST API. Vi tenker da spesielt på koden for å omdirigere brukeren til autentisering, hente «Access Token» og spørringer mot LinkedIn API-et (for å hente LinkedIn-profil informasjon om pålogget bruker). I tillegg til de større testene under, så hadde vi fokus på testing ut igjennom utviklingsfasen, komponentene og delkomponentene som gjør opp webapplikasjonen ble testet individuelt forløpende. 5.2 LinkedIn sitt JavaScript API test Formålet med denne testen var å finne begrensningene til LinkedIn sitt JavaScript REST API wrapper. Dette API-et brukte vi i vår første løsning. Det ble brukt både til å logge brukeren inn og hente ut brukerens profil data. Grunnen for at vi gikk for denne løsningen i starten var fordi det skulle være tilstrekkelig for den type webapplikasjon vi tenker oss, og fordi det tok seg av mye av jobben vi ellers hadde måte gjøre på vår egen server. Nemlig å hente tilgangstoken og sende spørringer til REST API-et. Område som ble testet var hvilke kall vi kunne gjøre med JavaScript wrapper API-et og hvilke data som vi fikk tilbake. Måtene vi testet på var å bruke webutviklingsverktøy innebygd i Firefox og Google Chrome, egne formaterings funksjoner som hjalp oss visualisere det som var av data i objektene vi fikk tilbake, og enkelt nok skrive ut argumentene vi ga til de forskjellige funksjonene og deres retur verdi. Hele gruppen trengte ikke å være med på denne testen så ansvaret for testen ble delegert til enkelte. Det vi fant ut av testen, er at LinkedIn sitt JavaScript API kan enkelt inkludere JavaScript biblioteket i nettsiden ved å putte en enkel <script> blokk i <head> seksjonen i HTML dokumentet. At det har en rekke greie funksjoner som hadde gjort utviklingen av nettstedet mye enklere, slik som å kunne: // Be om å autorisere brukeren IN.User.authorize(callbackFunction, callbackscope); // Sjekke om brukeren er allerede autorisert IN.User.isAuthorized(); // Gjøre råe autoriserte API kall IN.API.Raw(url).method(methodType).body(bodyContent).result(resultCallback); // Oppdatere brukerens session Side 63 av 78

64 IN.User.refresh() // Logge brukeren ut IN.User.logout(callbackFunction, callbackscope); Konklusjonen er at JavaScript API-et er enkel og lett å jobbe med, men låser oss som utviklere til en viss grad. Et av kravene til oppdragsgiver kan ikke bli tilfredsstilt med JavaScript wrapperen. Nemlig å kunne velge hvilken versjon av sin profil man vil lage CV-en av, dersom man har profilen sin på forskjellige språk. Selv med IN.API.Raw så har man ingen mulighet til å sette «Accept- Language» headeren i HTTP GET kallet som blir sendt til LinkedIn's REST API. JavaScript wrapperen bruker automatisk språk innstillingene som er spesifisert i nettleseren. JavaScript API-et er kompatibel med følgende nettlesere (Firefox 3+, Chrome (latest), Safari 5+, IE 7+). 5.3 Klient-server stresstest Formålet med stresstesten var å finne ut robustheten av kildekoden, hvor godt den håndterer feil, alle slags inndata, mulige angrep. Spesielt fokus på kommunikasjonene mellom klient og server, siden dette skjer asynkront og kan derfor forårsake at serveren eller klienten er i en tilstand som ikke er kompatible med hverandre. Hadde også et generelt fokus på å teste hvordan webapplikasjonen oppfører seg når en bruker er stresset og gjør ting fort. Hadde ikke muligheten til å teste kapasitet til noe stor grad, det må skje i senere fase hvor nettsiden har et antall test brukere, eventuelt ved hjelp av bots. Området som ble testet var kommunikasjonen mellom klient og server, og brukergrensesnittets representasjon av bruker data og PHP løsningens generering av CV-er. Hele gruppa var med på testingen. Vi lagde mange forskjellige LinkedIn profiler, på forskjellige språk, med forskjellig grad av mengden tekst og bruk av LinkedIn funksjonaliteter. Alle disse profilene gikk igjennom alle use caseene nettsiden vår støtter, fra å enkelt logge inn, til at CV-en som ble generert ser bra ut. Testen resulterte i at vi nå sjekker om «state» variabelen er den samme som vi sendte med brukeren til LinkedIn for autentisering, som den vi får tilbake fra LinkedIn som parameter i URL-en. Tilstandsvariabelen er en lang tilfeldig tekst streng som det er praktisk umulig for andre parter å gjette. Tekst strengen for en spesifikk gitt bruker blir lagret i en variabel tilknyttet brukerens «session». Ved så å utføre if testen ($_SESSION['state'] == $_GET['state']) kan man forhindre «cross site scripting» angrep. Videre så ble det oppdaget at man får en «parse error» når man ikke lar nettsiden laste seg ferdig for man refresh-er nettsiden. Denne type feil oppstår når en algoritme får data på et format den ikke forventer. Analyse feilen oppsto på begrunn av at nettsiden blir avbrutt i å asynkront hente tilgangstoken som trengs for autentiserte kall til LinkedIn's REST API. I løpet av den tiden det tar serveren vår å hente tilgangstoken (som brukes til å hente ut data på brukerens vegne) så har klientsiden endret tilstand og er ikke klar over å ha bet serveren om en tjeneste (hente tilgangstoken). Side 64 av 78

65 Denne tilstandsproblematikken løste vi ved at brukerne vil bli logget ut hvis tilstanden på klient og server ikke lenger er kompatibel. Når klient og server ikke lenger snakker sammen så vil et ajax kall til PHP scriptet fetch.php feile og «error callback» funksjonen til kallet vil bli kjørt. Det er i denne funksjonen vi logger brukeren ut, slik at man får en ren start og kan prøve igjen. En problemstilling som har vært i fokus når vi valgte denne løsningen vår å minimalisere antall ganger webapplikasjonen gjør kall på LinkedIn resurser. Hvis vi hadde valgt en løsning som hadde prøvd å hente tilgangstoken flere ganger, så hadde den gjennomsnittlige bruker gjort flere kall til LinkedIn og dermed brukt opp kvoten vår raskere. 5.4 Cross browser support test Testens formål var å finne hvordan webapplikasjonens utsende og funksjonalitet varierte mellom de store nettleserne i forskjellige operativsystem. Om det var vesentlige design forskjeller mellom standard HTML tager og til hvilken grad det var støtte for nyere teknologi som CSS3 og HTML5. Test området omfavner en rekke av de største nettleserne: Google Chrome, Mozilla firefox, Internet Explorer, Opera og Safari. I tillegg til å teste i alle disse nettleserne ble det også testet på forskjellige operativsystemer, Linux (Ubuntu), Windows og Mac. Testprosedyren for denne testen var ganske rett frem, alle satt seg ned og prøvde alle funksjonene og så hvordan ting så ut på de forskjellige plattformene. Resultatet av denne testen var en del endring av større og mindre design valg, større oppdeling av LinkedIn seksjonene (personalia, oppsummering, utdanning, erfaring, ferdigheter, kurs og sertifiseringer), en egen side meny (Ferdigstill) logisk separert fra den over (Velg og rediger), egen dropdown meny for valg av språk, lenke til brukerens LinkedIn profil og logg ut knapp. Den største endringen var å erstatte standard checkbox-ene med egenlagde checkbox-knapper. Grunnen til denne siste avgjørelsen var at standard checkbox design er opp til hver enkelte nettleser og deretter operativsysteme å bestemme utsende på. HTML tagen «<input type="checkbox">» resulterer i vidt forskjellige checkbox-knapper som passer dårlig inn utsende messing, og slike checkbox-er blir ikke større når man zoomer inn. Checkbox-ens størrelse vil forbli den samme selv om man zoomer ut (da blir layout-en rundt liten i forhold) eller zoomer inn (da blir checkbox-en liten i forhold til det rundt). Vår egendefinerte checkbox skalerer sammen med resten av nettsiden, dette er mer i tråd med universell utforming. 5.5 Cross office suite test Formålet med denne testen var å kvalitets sjekke generering av cv ved hjelp av PHP løsningen vår som bruker PHPWord PHPWord er et bibliotek skrevet i ren PHP som gir oss et sett med Side 65 av 78

66 klasser til å skrive til og lese fra forskjellige fil formater. Vi bruker dette biblioteket til å generere CV-er på DOCX file format (Microsoft Office Open XML). Test området inkluderte generering av cv i de større nettleserne, Fireforx, Opera, Google Chrome, Internet Explorer og Safari. I tillegg ble det testet under operativsystemene Linux (Ubuntu) og Windows. Men viktigere så testet vi hvordan de forskjellige cv malene ser ut, ikke bare i Microsoft Word men de to store open source tekstbehandlings programmene LibreOffice og OpenOffice. Hele gruppa var med på å teste og kom med innspill til forbedringer. Måten vi testet på var å prøve forskjellige XML tag-er (med forskjellige attributter) og layout løsninger. Microsoft Word, OpenOffice og LibreOffice tolker disse standardiserte tag-ene forskjellig, alle tekstbehandlings programmene forstår tag-ene, men varierer vesentlig i hvordan de får CV-en til å se ut. Resultatet av testingen var at vi fant ut at LibreOffice og OpenOffice viser ting noe lunde likt men klarer nesten ikke å vise noen av de mer avanserte Microsoft Office Open XML-tagene ordentlig. Bare et enkel tabell layout-tag og et lite antall stil tag-er vises likt i alle tre programmene og til og med da måtte vi finjustere en god del. Kjente feil og mangler Må gjøres noe med Burde gjøres noe med Bruke https istedenfor http Større grad av mobil tilpasning Mer universelt utformet Kan gjøres noe med Design valg Egenskaper Vår vurdering (1 til 6 stjerner) Utsende * * * * * Funksjonalitet * * * * * Intuitivt * * * * * * Enkelhet * * * * * * Kode kvalitet * * * * * Dokumentert * * * * * Side 66 av 78

67 6 Brukermanual Innholdsfortegnelse 6. Prosessdokumentasjon 6.1 Forord 6.2 Innledning 6.3 Innlogging og utlogging 6.4 Fjerne webapplikasjonen fra sin LinkedIn-profil 6.5 Bruk av CV-editoren Redigere felter Velge felter Endre Språk Velge mal for CV-en 6.6 Motta CV-en Laste ned direkte Få på e-post Side 67 av 78

68 6.1 Forord Denne manualen omhandler webapplikasjonen beskrevet i de øvrige kapitelene av dette dokumentet, og skal gå gjennom prosessen for å generere en CV, steg for steg. Manualen går ut ifra at brukeren allerede har en LinkedIn-profil, og en nettleser som støtter JavaScript. 6.2 Innledning Denne webapplikasjonen skal kunne importere informasjon fra en pålogget bruker sin LinkedInprofil, og ved hjelp av den informasjonen skal det genereres en ferdig CV. Applikasjonen tilbyr følgende funksjoner: Hente ut profil-data fra en pålogget bruker sin LinkedIn-profil Endre ønskede felter fra LinkedIn-profilen i en CV-editor Endre språk Mulighet for å velge en ønsket CV-mal Laste ned CV-en Motta CV-en på e-post Webapplikasjonen kan aksesseres på alle nyere nettlesere som har støtte for JavaScript. 6.3 Innlogging og utlogging Det første man må gjøre for å ta i bruk webapplikasjonen er å logge inn med sin LinkedIn-profil informasjon. Dette gjør man ved å trykke på «Sign in with LinkedIn»-knappen på hovedsiden («Hjem»). Figur 7: Sign in with LinkedIn Side 68 av 78

69 Etter at man har trykket på knappen kommer man inn på en egen innloggingside. Den forteller hvilke opplysninger webapplikasjonen skal ha tilgang til. For å gå videre må man godkjenne at webapplikasjonen kan få tilgang til disse opplysningene. I E-post-feltet fyller man inn e-postadressen som er knyttet til sin LinkedIn-profil. I Passord-feltet fyller man inn passordet som brukes for LinkedIn-profilen sin. Deretter trykker man på «Godkjenn tilgang»-knappen for å logge inn med LinkedIn, og dermed koble LinkedIn-profilen sin med webapplikasjonen. Ved vellykket innlogging kommer man inn på CV-editoren. For å logge ut av applikasjonen trykker man på nedtrekks-menyen i hoved navigasjonen (tre horisontale streker) øverst til høyre hjørne på siden. Deretter trykker man «Logg ut». Ved vellykket avlogging kommer man inn på hovedsiden igjen. 6.4 Fjerne webapplikasjonen fra sin LinkedIn-profil Dersom man ønsker å fjerne webapplikasjonen fra sin LinkedIn-profil, er det mulig ved å følge denne stien på LinkedIn sin hjemmeside (LinkedIn.com): LinkedIn.com > Konto og innstillinger > Personvern og innstillinger (Administrer) > Grupper, bedrifter og applikasjoner > Applikasjoner > Vis applikasjonene dine > Huk av «SoProCV» > Trykk «Fjern». Figur 8: Autentiserings-vindu fra LinkedIn Side 69 av 78

70 6.5 Bruk av CV-editoren Dersom man ønsker å redigere innholdet i CV-en før den lastes ned, kan dette gjøres i CV-editoren i seksjonene under «Velg og rediger» Redigere felter Dersom man ønsker å endre på et felt i CV-editoren klikker man på ønsket seksjon under «Velg og rediger». For eksempel «Personalia». Der kan man endre på ønskede felter, ved å klikke på tekst-feltet. Feltene kan redigeres helt fram til CV-en lastes ned. Hvis man ønsker å gjøre flere endringer etter nedlastning, må CV-en lastes ned på nytt. Figur 9: CV-editor navigasjon Fjerne felter Dersom man ønsker å fjerne et eller flere felter fra CV-en, kan markering fra sjekkboksen fjernes, til venstre for ønsket tekstfelt. Dette må gjøres før CV-en lastes ned Endre språk Dersom man har flere språk på sin LinkedIn-profil, er det mulig å velge hvilket språk CV-en skal være på. Dette gjøres ved å klikke på nedtrekks-menyen i hovednavigasjonen øverst til høyre (tre horisontale linjer), deretter velge «Profilspråk». Der kan brukeren velge ønsket språk Velge mal for CV-en Det er allerede forhåndsvalgt en mal som CV-en lagres i. Dersom man ønsker å endre denne, gjøres dette ved å klikke «Velg CV-mal». Der kan det velges mellom flere forskjellige forhåndsdefinerte maler. Side 70 av 78

71 6.6 Motta CV-en Det er to forskjellige måter en bruker kan få tak i den genererte CV-en på: Laste ned direkte Når brukeren har gjort ønskede endringer, kan CV-en lastes ned i DOCX-format. For å laste ned klikker man på «Last ned!». Den ferdigenererte CV-en vil dermed bli lastet ned til standard nedlastings-mappe. DOCX formatet støttes av de fleste moderne tekstbehandlingsverktøyene og er spesielt godt egnet for Microsoft Word Få på e-post Man kan også få CV-en tilsendt på e-post. For å få CV-en tilsendt på e-post klikker man på «Motta på e-post!». Deretter fyller man inn ønsket e-post adresse og klikker på knappen til høyre for dette feltet. Dersom som e-posten er gyldig, vil brukeren få melding om at den er sendt. Side 71 av 78

72 7 Vedlegg Vedlegg 1: Meldingsutveksling med LinkedIn Side 72 av 78

73 Side 73 av 78

74 Side 74 av 78