Møter og Møtereferater

Transkript

1 Møter og Møtereferater De neste sidene innholder møtereferater fra diverse møter vi har hatt gjennom prosjektperioden. Møtereferatene kjører en standard mal som ble brukt på samtlige referater og har en gjennomgang av emnene som ble tatt opp underveis. Møtereferatene vi har vedlagt er de vi føler har gitt oss noe i prosjektet. Det er også verdt å nevne at ved flere av disse er Gjennomgang av møte skrevet på Engelsk. Dette har seg at møtene hvor Simon, Rachel eller Jayson har vært deltagere har disse foregått på engelsk, og det ble da mest naturlig å skrive gjennomgangen på engelsk. Oversikt over møtene vi har hatt gjennom prosjektperioden: - Simon McCallum ukentlig hver fredag. - Harald Liodden annenhver tirsdag. - Administrasjonen 22/ Interne og eksterne konsulenter: o Monica Strand 25/02-10 o Guro Wang Øverli 02/03-10 o Rachel Gibb 28/01-10, 20/04-10 Utenom disse har vi hatt statusmøter innenfor gruppen jevnlig. Vedlegg 1, side 1

2 Introduction with Simon and Hilde 22/01/10 Høgskolen i Gjøvik Møte innkalt av: Hilde Bakke Type møte: Introduction Møteleder: Simon McCallum Protokollfører: Petter Andersen Busterud Møtedeltakere: Lasse Krøger Vanebo Petter Andersen Busterud Oddbjørn Undseth Bakke Simon McCallum Hilde Bakke (Teknisk Veileder) (Oppdragsgiver) Gjennomgang av møte Emne Why Alumni? Marketing school, keep contact with former students/graduates ant get information on where they are now (Studies, work, etc ), giving out information on research upcoming/going HiG. Want to give former students information on maybe taking a master degree part-time. And also using the Alumni s to give information about HiG to other co-workers. Today HiG have some information on a few former master/bachelor graduates. Hilde still keeps and updated list of some of them Request for the HiG Alumni system: - Easy to update information - Guest login - Linked to Facebook and LinkedIn via application Rachel (External Consultant): Have great experience on working with Alumni systems, can help out with use-cases, SQLqueries and more. SU-Model: For this project three models came up; Agile, SCRUM or Spiral Developer phase: We should go with 3 phases. Database, Web-frontend (2 parts; Admin and users) and Facebook/LinkedIn Application. Other contacts for the project: Monica Strand (Web-frontend) Guro Wang Øverli (Web Journalist) Andreeas Braaten (A220 / Master) Vedlegg 1, side 2

3 Consultation meeting with Rachel 28/01/10 Høgskolen i Gjøvik Møte innkalt av: Simon McCallum Type møte: Consultation Meetings Møteleder: Lasse Krøger Vanebo Protokollfører: Petter Andersen Busterud Møtedeltakere: Lasse Krøger Vanebo Petter Andersen Busterud Oddbjørn Undseth Bakke Rachel Gibb (External Consultant) Gjennomgang av møte Emne About Rachel: Rachel worked earlier with an Alumni System at The University of Otago in New Zealand. They used a platform called Razor Edge, and had around thousand alumnus/alumna What to consider in HiG Alumni: - Automatic registration for students at the end of their education. - Unique ID - Keep maiden name - Gender (specially on international students) - Relationship / Children - Ability to do advance search on client database, finding students by business, class, etc Things to consider at the Database: - Client / Admin, how to use, simple documentation - Address format (May be different from each country how to pull out the information) - Keep more than one address, Parents / Work / Home etc - Also store former addresses - , personal and business - Alternative name, nickname. So we could lock names and unique id used at HiG - Deceased / inactive users School: Should be easy collection data via forms. Keep log on what have been done (messages sent to user and things like that). Vedlegg 1, side 3

4 Weekly meeting with Simon 29/01/10 Høgskolen i Gjøvik Møte innkalt av: Simon McCallum Type møte: Weekly meeting Møteleder: Simon McCallum Protokollfører: Petter Andersen Busterud Møtedeltakere: Lasse Krøger Vanebo Petter Andersen Busterud Oddbjørn Undseth Bakke Simon McCallum (Teknisk Veileder) Gjennomgang av møte Emne Feedback for Rachel (See Rachael docx ): She is quite impressed by our background research on Alumni. She also thinks our project has great potential. Simon had also talked with Morten Irgens (Dekan HiG) who thinks our project is a great idea and he says it is possible to apply for resources from HiG if necessary. He sees potential in using this project on more universities, especially in Mjøs-region (Høgskolen i Gjøvik, Høgskolen i Lillehammer and Høgskolen i Hedmark) What would students want in HiG Alumni: - Should be possible for an Facebook application to update contact information on both systems at once. - Fast and Easy to use - Communication channel, delivering messages - Use it as a Social Network Storing information in database: - Queries; what should/could go fast and what can take time - How many copies should we keep on addresses etc With addresses we can use Google maps to map up students / alumni easy. A plug-in for this is maybe something to look at. Vedlegg 1, side 4

5 Weekly meeting with Simon 05/02/10 Høgskolen i Gjøvik Møte innkalt av: Simon McCallum Type møte: Weekly meeting Møteleder: Simon McCallum Protokollfører: Petter Andersen Busterud Møtedeltakere: Lasse Krøger Vanebo Petter Andersen Busterud Oddbjørn Undseth Bakke Simon McCallum (Teknisk Veileder) Gjennomgang av møte Emne Innlands University. If this ever occurs, we have to think about identification numbers. - The universities (Mjøs-region): Høgskolen i Gjøvik (HiG), Høgskolen i Lillehammer (HiL) and Høgskolen i Hedmark (HiHm). - Can solve this by using G, L, H in front of the ID s. - We should contact the other universities to get information about how the student ID s are build up. - All three schools should be using same database / server - Link records in database, example if a student takes a master on another school. - Should consider generation new unique numbers from data that already exist. Birth, university, etc In our final project report on the Alumni System we should have documentation about this problem with the identification numbers. Example on unique ID: xxxxxx = studentnumber (6 or 7 digits) University (4 or 5 columns) HiG 1001xxxxxx HiL 1002xxxxxx HiHm 1003xxxxxx University Innlandet 1004xxxxxxx To do: Talk with IT-department about HiG ID s Vedlegg 1, side 5

6 Konsulent møte med Monica 25/02/10 Høgskolen i Gjøvik Møte innkalt av: Lasse Krøger Vanebo Type møte: Konsulent Møte Møteleder: Lasse Krøger Vanebo Protokollfører: Petter Andersen Busterud Møtedeltakere: Lasse Krøger Vanebo Petter Andersen Busterud Oddbjørn Undseth Bakke Monica Strand (Konsulent fra HiG) Gjennomgang av møte Emne Anbefalt kontaktpersoner i prosjektet: Guro Wang Øverli: - Har vært på foredrag om Alumni systemer - Fått mye informasjon om andre Alumni nettverk - Vet kanskje litt om eventuelle kostnader å r siden presenterte hun et Alumni forslag for høgskolestyret Ole E. Wattne: - Design Web-frontend; Har CSS orginalen, informasjon om tidligere student som lagde denne. Aktive brukere av Alumni system: - Universitetet i Oslo: Erik Hjelmås og Are Strandlie - NTNU: Rune Hjelsvold Hva Monica ser for seg / anbefalinger til Alumni Systemet: Ønsker et nettverk som LinkedIn, bare mer sosialt: - Diskusjoner / Forum for nåværende og tidligere studenter (Få erfaringer) - Spille på kontaktnettverk - Tyngre faglig - Sterk inndeling Beste løsning vil være en kombinasjon av Facebook sitt sosiale nettverkt og LinkedIn sin profesjonelle holdning. Lag en lur løsning for abonnere på informasjon fra skolen / studenter / grupper (unngå spam) - Informasjon utenom dette hentes av bruker selv - Abonnement går via personlig mail, med valg fra brukeren sin side om dette skal komme hver uke, måned, år eller lignende. - Kategorisering av informasjon, nivåer innen kategoriseringene. Ved jobbannonsering, kan slik informasjon være like interessant for 3. års studenter som Alumnier allerede ute i jobb. Forside for ikke registrerte / innloggede; om HiG, nyheter, personer etc Se på mulighet for annonseplasser for en eventuell finansiering? Vedlegg 1, side 6

7 Weekly meeting with Simon 26/02/10 Høgskolen i Gjøvik Møte innkalt av: Simon McCallum Type møte: Weekly meeting Møteleder: Simon McCallum Protokollfører: Petter Andersen Busterud Møtedeltakere: Lasse Krøger Vanebo Petter Andersen Busterud Oddbjørn Undseth Bakke Simon McCallum (Teknisk Veileder) Gjennomgang av møte Emne We should arrange a meeting with central HiG through Hilde Bakke: Have a min presentation ready where we show: - Summary of the project, not a full walkthrough - Current database - What the system can (/can t) do - Currently working on and planned activities Get feedback! Our use-cases should be personas use-cases. This includes creating persons, which have a story. Daniel is a 25 year old student, who have gone 2 yearss at Høgskolen i Gjøvik and bla bla. He now works at Telenor as an bla bla. Admin users: - Involve the people who will be administrators for the final product, ask them for inputs and priority tasks. About LDAP: - Importing from LDAP should occur at end of each semester, before summer and Christmas. - Week (or something) before importing is due, admins should get a warning. LDAP import process (Soft maintained) Export button Excel (?) spreadsheet Check file Error fix import to database Build up a sheet with studentnumbers succeeded imported. Vedlegg 1, side 7

8 Konsulent møte med Guro 02/03/10 Høgskolen i Gjøvik Møte innkalt av: Lasse Krøger Vanebo Type møte: Konsulent Møte Møteleder: Lasse Krøger Vanebo Protokollfører: Petter Andersen Busterud Møtedeltakere: Lasse Krøger Vanebo Petter Andersen Busterud Oddbjørn Undseth Bakke Guro Wang Øverli (Konsulent fra HiG) Gjennomgang av møte Emne Tenke litt på hvordan godkjenne nye brukere Grunner til hvorfor ikke skolen har valg alumni: - Stilling, blir ikke veldig stor arbeidsmengde ved start, så en ansatt på en % stilling må eventuelt ansettes - Kostnad! Mira.se sin løsning brukes i de fleste Alumni system i Norge i dag. Guro vil kontakte Mira.se for oss og skaffe oss opplysninger om: - Skaffe pris, Nå (kun HiG) og ved innlandsuniversitet. - Informasjon om løsningen Innlandsuniversitet ligger nå estimert 2016 (var 2012) Ved jobbannonse osv for studenter / alumni, kanskje ha mulighet for å hente ut innfor fra finn, NAV eller lignende jobbsider (?) Vedlegg 1, side 8

9 Mail transaksjon BRREG Fra: Petter A. Busterud Sendt: 25. februar :17 Til: Roger Haugen Emne: Testapplikasjon/-database Hei Vi er tre studenter som i vår avsluttende bacheloroppgave har fått et oppdrag fra Høgskolen i Gjøvik om å utvikle forslag til et Alumni system for dem. Dette vil si et system for å opprettholde kontakten mellom skolen og studenter; ved og etter endt utdanningen. I denne sammenheng ser vi for oss å implementere muligheten for de tidligere studentene å kunne registrere sine tidligere og nåværende arbeidsplasser. Det er her Brønnøysundregisteret vil være en stor hjelp for oss. Når en bruker registrerer en bedrift han/hun har jobbet i, linkes informasjon som: hjemmeside, adresse, kontaktinformasjon og annen praktisk informasjon. Dette vil gjøre det enklere/bedre for gamle eller nye studenter å utvide sitt kontaktnettverk. Siden Høgskolen i Gjøvik kun er ute etter et forslag (som vil videreutvikles hvis det er godt nok!) til et Alumni system, ønsker de ikke noen bindende økonomiske rammer for øyeblikket. Det vi lurer på da er om dere har noe form for testapplikasjon og -database vi kan kjøre mot for å simulere uthenting av data fra Brønnøysundregisteret? Med vennlig hilsen Petter Andersen Busterud Fra: Roger Haugen [roger.haugen@brreg.no] Sendt: 04. mars :09 Til: Petter A. Busterud [petterbusterud@gmail.com] Emne: VS: Testapplikasjon/-database Hei Petter, Beklager sen tilbakemelding på denne. Vi har en Web Services tjeneste som er knyttet mot Enhetsregisteret som vil passe for dere. Tjenesten er utviklet ovenfor private brukere. De opplysninger som levers fra Enhets- og Foretaksregisteret vil være: - Basisdata mini - tjenesten inneholder organisasjonsnummer, organisasjonsform, navn, forretningsadresse og postadresse - Kontaksdata - tjenesten inneholder telefonnummer, telefaksnummer, mobiltelefonnummer, e-postadresse og hjemmesideadresse - Navnesøk - tjenesten gjør det mulig å finne et organisasjonsnummer ved å søke på navn/foretaksnavn Vedlegg 2, side 1

10 - Særlige opplysninger - tjenesten inneholder statusinformasjon, som for eksempel om enheten er registrert i Foretaksregisteret eller merverdiavgiftsregisteret. Tjenesten har en årlig kostnad for private brukere på kr 5000,-. I tillegg kommer det kr 0,50 pr oppsalg for tjenestene Basisdata mini, kontaksdata og navnesøk. Særlige opplysninger koster kt 1,- pr oppslag. Siden dette er et skoleoppdrag vil vi gi dere tilgang til disse tjenestene gratis for en periode. To spørsmål til dere. 1. Hvor lenge trenger dere tilgangen 2. For å gi dere tilgang må vi ha en skriftlig bekreftelse fra Høgskolen i Gjøvik som bekrefter det oppdrag dere har fått. Mer om tjenesten kan dere lese om her: Ta kontakt dersom dere har spørsmål. Med vennlig hilsen Roger Haugen Førstekonsulent - Opplysningsavdelingen Brønnøysundregistrene Telefonnummer: E-post adresse: roh@brreg.no Fra: Petter A. Busterud [petterbusterud@gmail.com] Sendt: 04. mars :45 Til: Roger Haugen [roger.haugen@brreg.no] Emne: Re: VS: Testapplikasjon/-database Hei, Det høres veldig bra ut! Presentering av bacheloroppgaven vil være 3. Juni Om dere ikke har noe policy på hvor lenge vi kan ha tilgang til systemet. Ønsker vi gjerne tilgang til og med denne datoen, slik at vi også kan få presentert en implementering opp mot Brønnøysundregistret. Vi skal få hentet ut en bekreftelse fra Høgskolen i Gjøvik de nærmeste dagene. Vil en innscannet kopi sendt via et vedlegg i mailen holde? Eller ønskes det i en annen form? Mvh Petter Andersen Busterud Fra: Roger Haugen [roger.haugen@brreg.no] Sendt: 04. mars :03 Vedlegg 2, side 2

11 Til: Petter A. Busterud Emne: SV: VS: Testapplikasjon/-database Hei, At dere ønsker tilgang til den 3 juni er ikke noe problem for oss. Vi tar selvsagt en forutsetning at data kun brukes til den oppgaven dere har, og at data ikke blir distribuert videre. Send meg gjerne en scannet bekreftelse fra Høgskolen i Gjøvik, så åpner jeg tilgang til dere. Mvh Roger Fra: Petter A. Busterud [petterbusterud@gmail.com] Sendt: 10. mars :07 Til: Roger Haugen [roger.haugen@brreg.no] Emne: Re: VS: Testapplikasjon/-database Vedlegg: bekreftelse.pdf Her kommer bekreftelsen fra skolen. Om vi får tilgang fram til 4. Juni hadde dette vært strålende. Uthentet data vil selvsagt kun bli brukt i prosjektsammenheng. Mvh Petter Busterud Fra: Petter A. Busterud [petterbusterud@gmail.com] Sendt: 24. mars :55 Til: Roger Haugen [roger.haugen@brreg.no] Emne: SV: VS: Testapplikasjon/-database Hei, Har du et mobilnummer som vi kan sende en kode til, en kode som du bruker for å åpne secure . Mvh Roger Fra: Roger Haugen [roger.haugen@brreg.no] Sendt: 24. mars :57 Til: Petter A. Busterud [petterbusterud@gmail.com] Emne: Re: VS: Testapplikasjon/-database Hei Kan bruke mitt som er: XX XX XX XX Petter Vedlegg 2, side 3

12 admin admin_id CHAR(10) tittel VARCHAR(45) kontor VARCHAR(45) fnavn VARCHAR(32) enavn VARCHAR(32) admin_type CHAR(1) Events grupper_gid INT published_by CHAR(10) refrens_nr CHAR(16) company_org_nr INT from_date DATETIME to_date DATETIME subject VARCHAR(45) text TEXT published_status CHAR(1) NULL To_date: News To_Date not NULL: From/to event Published_status: P: Pending / Admin Private U: Published T: Autopublish(Time controled) news(like a "blog"): informasjon about school etc. events(like a calendar): seminars, courses skole skole_id CHAR(4) login login_id CHAR(16) paswdhash CHAR(32) alumni_alumni_nr CHAR(10) navn VARCHAR(45) users studnr CHAR(6) skole_skole_id CHAR(4) alumni_nr CHAR(10) alumni alumni_nr CHAR(10) aktiv BIT fnavn VARCHAR(32) medlemmer grupper_gid INT medlem_siden DATETIME alumni_nr CHAR(10) get_notifies BIT enavn VARCHAR(32) birth DATE picture_url VARCHAR( hash VARCHAR(45) sex CHAR(1) curwork_org_nr INT linkedin_profile_url VA facebook_profile_url V titler homepage_url VARCH grupper gid INT gnavn VARCHAR(45) opprettet DATETIME alumni_nr CHAR(10) utdannelse_u_id CHAR(8) date DATE work company_org_nr INT alumni_nr CHAR(10) utdannelse u_id CHAR(8) u_navn VARCHAR(45) from_date DATE to_date DATE hidden BIT Approve levels for status_approved: P: Pending A: Approved L: Less priority org_messages refrens_nr CHAR(16) company_org_nr INT auto_publish_date DATETIME subject VARCHAR(45) text TEXT group_description VARCHAR(45) status_approved CHAR(1) company org_nr INT landkode CHAR(2) name VARCHAR(45) adresse VARCHAR(45) hjemmeside VARCHAR(45) postnr VARCHAR(45) telefon VARCHAR(45) telefaks VARCHAR(45) Company: Connected to postal.nr. etc. adresse adr_id INT alumni_nr CHAR(10) postnr CHAR(8) postnr_land VARCHAR(45) adresse VARCHAR(45) adresse2 VARCHAR(45) hide_adr BIT approved BIT type_type CHAR(1) telefon tlfnr INT type_type CHAR(1) alumni_nr CHAR(10) hide_tlf BIT postnr postnr CHAR(8) landkode CHAR(2) poststed VARCHAR(32) kommunenr CHAR(4) kommunenavn VARCHAR(30) kategori CHAR(1) fylke VARCHAR(45) typ typ CHAR(1) navn VARCHAR(45) cell BIT epost epost VARCHAR(255) typ CHAR(1) alumni_nr CHAR(10) hide_ BIT inbox message_id INT reciver CHAR(10) sender CHAR(10) tidspunkt DATETIME lest BIT Subject VARCHAR(45) Message TEXT land landkode CHAR(2) land VARCHAR(45) land_tlf tlf_prefic INT land_landkode CHAR(2) Epost;Typ W: Work H: Home F: Foresatte B: Billing Cell: Cellphone (only under Telephone) Vedlegg 3, side 1

13 Samling av data om nåværende studenter. RAW-LDAP-CLASSES class VARCHAR(45) Raw-LDAP-Data skole CHAR(3) studnr CHAR(10) fnavn VARCHAR(45) date DATE Raw-LDAP-Data_studnr VARC Raw-LDAP-Data_skole VARC enavn VARCHAR(45) higmail VARCHAR(255) RAW-LDAP-SUBJECTS fagkode CHAR(10) date DATE Raw-LDAP-Data_studnr VARCHAR(45) Raw-LDAP-Data_skole VARCHAR(45) fagnavn VARCHAR(45) Info om tidliger studenter Feide DB fodselsnr INT fnavn VARCHAR(45) enavn VARCHAR(45) adresse VARCHAR(45) Uvist struktur på data.. OBS. Inneholder: personsensetive opplysninger eks. fødselsnr, kraterer osv VARCHAR(45) Vedlegg 3, side 2

14 admins user_ tittel VARCHAR(255) tlf VARCHAR(32) rom VARCHAR(32) alumnis fnavn VARCHAR(255) enavn VARCHAR(255) birth DATE user_ bildeurl VARCHAR(255) hjemmeside VARCHAR(255) groups name VARCHAR(100) parent_ created DATETIME modified DATETIME lft INT(11) rght INT(11) events user_ created DATETIME modified DATETIME subject VARCHAR(255) text TEXT published_status BIT(1) skoler skole VARCHAR(255) kode CHAR(6) hjemmeside VARCHAR(255) users username VARCHAR(255) password CHAR(80) created DATETIME modified DATETIME skole_ comfirmed BIT(1) group_ aktiv BIT(1) contact_mail VARCHAR(255) comfirmed_mail BIT(1) comfirm_code VARCHAR(36) fnavn VARCHAR(255) enavn VARCHAR(255) work companies_ user_ from_date DATE to_date DATE hidden BIT(1) companies name VARCHAR(255) hjemmeside VARCHAR(255) godkjent BIT(1) adresser user_ postnr_ adresse VARCHAR(255) hidden BIT(1) type_ telefoner tlfnr INT(11) type_ hidden BIT(1) user_ mobil BIT(1) epost epost VARCHAR(255) hidden BIT(1) user_ type_ messages user_ userfolder ENUM(...) recipient_ recipientfolder ENUM(...) status ENUM(...) subject VARCHAR(45) message TEXT created DATETIME modified DATETIME postnr poststed CHAR(32) kommunenr CHAR(4) kommune CHAR(30) kategori CHAR(1) typer name VARCHAR(255) navn VARCHAR(255) Autorisering tabeller aros acos parent_ parent_ model VARCHAR(255) model VARCHAR(255) foreign_key INT(11) foreign_key INT(11) alias VARCHAR(255) alias VARCHAR(255) lft INT(11) lft INT(11) rght INT(11) rght INT(11) Foreing_key hos aros og acos er linket til users id aros_acos aro_ lft og rght er for å bygge opp treet aco create VARCHAR(2) _read VARCHAR(2) _update VARCHAR(2) _delete VARCHAR(2) Vedlegg 3, side 3

15 Vedlegg 4, side 1 ID Aktivitetsnavn Varighet Start Slutt 1 Alumni Comunication System 101 dager? on to Forprosjekt 13 dager on fr Innføringsmøte 0 dager on on Sette opp utviklingsmiljøet 3 dager to ma Forprosjektraport 13 dager on fr Deadline prosjektplan og -avtale 0 dager fr fr Prosjekt 88 dager? ma to Fase1 - Databasedesign 25 dager? ma fr Kravspesifikasjon 5 dager? ma fr Designe DB struktur 15 dager? ma fr Grunnleggende PHP mot 10 MySQL dager? koding ma fr Integrasjon fra skolens 10 systemer dager? ma fr Fase2 - Web Frontend 35 dager? ma fr Koding av webfrontend30 dager? ma fr GUI Design frontend 10 dager? ma fr Sikker innlogging/registrering 5 dager? ma fr Fase 3 - Facebook og finpussing 18 dager? ma on (1 person) Facebook 15 integrasjon dager? ma fr Sette seg inn i FB. API 5 dager? ma fr Kode API 10 dager ma fr (2 personer) Teste finpusse 18 dager? ma on Finpusse på koden/forbedre 10 dager? kommantarer ma i koden fr Skrive raport 8 dager? ma on Oppgave ferdig 10 dager to to Bacheloroppgaven leveres 0 dager til kopisentralen to to Bacheloroppgaven leveres 0 dager Studenttorget ti ti A3 Plakaten leveres til laminering 0 dager to to Laminert plakat leveres til 0 Studenttorget dager ti ti Presentasjon 0 dager to to Kjente komplikasjoner 87 dager? on fr Personer utilgjengelige 37 dager? to fr Påskeferie 5 dager? ma fr Oddbjørn i Oslo 2 dager? to fr Petter i England 2 dager? fr ma Lasse i Bergen 5 dager? to on Prøver & innleveringer 87 dager on fr Prosjekt: Alumni Comunication system Dato: fr Aktivitet Deling 11. jan jan jan feb feb feb feb mar mar mar mar mar apr apr apr apr mai mai mai mai mai j s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t Deadline prosjektplan og -avtale Fase1 - Databasedesign Kravspesifikasjon Designe DB struktur Grunnleggende PHP mot MySQL koding Integrasjon fra skolens systemer Koding av webfrontend GUI Design frontend Sikker innlogging/registrering (1 person) Facebook integrasjon Sette seg inn i FB. API Kode API (2 personer) Teste finpusse Finpusse på koden/forbedre kommantarer i koden Skrive raport Oppgave ferdig Bacheloroppgaven leveres til kopisentralen Bacheloroppgaven leveres Studenttorget A3 Plakaten leveres til laminering Laminert plakat leveres til Studenttorget Presentasjon Kjente komplikasjoner Personer utilgjengelige Påskeferie Oddbjørn i Oslo Petter i England Lasse i Bergen Prøver & innleveringer Fremdrift Sammendrag Eksterne aktiviteter Tidsfrist Milepæl Prosjektsammendrag Ekstern milepæl Side 1

16 Vedlegg 4, side 2 ID Aktivitetsnavn Varighet Start Slutt 1 Alumni Comunication System 101 dager? on to Forprosjekt 13 dager on fr Innføringsmøte 0 dager on on Sette opp utviklingsmiljøet 3 dager to ma Forprosjektraport 13 dager on fr Deadline prosjektplan og -avtale 0 dager fr fr Prosjekt 90 dager? to to Fase1 - Databasedesign 25 dager? ma fr Kravspesifikasjon 5 dager? ma fr Designe DB struktur 15 dager? ma fr Grunnleggende PHP mot 5 MySQL dager? koding ma fr Integrasjon fra skolens systemer 5 dager? ma fr Grunnleggende koding 10 av dager? CakePHP ma fr Fase2 - Web Frontend 35 dager? ma fr Sette seg inn i CakePHP20 dager? ma fr Kode CakePHP 25 dager? ma fr Koding av webfrontend30 dager? ma fr GUI Design frontend 10 dager? ma fr Fase 3 - Teste finpusse 18 dager? ma on Finpusse på koden/forbedre 10 dager? kommantarer ma i koden fr Kun skrive raport 13 dager? ma on Møter og presentasjoner 60 dager to to Rachel Gibb 0 dager to to Monica Strand 0 dager to to Guro Wang Øverli 0 dager ti ti Rachel Gibb 0 dager ti ti Presentasjon for administrasjonen 0 dager to to Oppgave ferdig 10 dager to to Bacheloroppgaven leveres 0 dager til kopisentralen to to Bacheloroppgaven leveres 0 dager Studenttorget ti ti A3 Plakaten leveres til laminering 0 dager to to Laminert plakat leveres til 0 Studenttorget dager ti ti Presentasjon 0 dager to to Prosjekt: Alumni Comunication system Dato: on Aktivitet Deling 11. jan jan jan feb feb feb feb mar mar mar mar mar apr apr apr apr mai mai mai mai mai j s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t o t f l s m t Deadline prosjektplan og -avtale Fase1 - Databasedesign Kravspesifikasjon Designe DB struktur Grunnleggende PHP mot MySQL koding Integrasjon fra skolens systemer Grunnleggende koding av CakePHP Sette seg inn i CakePHP Kode CakePHP Koding av webfrontend GUI Design frontend Finpusse på koden/forbedre kommantarer i koden Kun skrive raport Møter og presentasjoner Rachel Gibb Monica Strand Guro Wang Øverli Rachel Gibb Presentasjon for administrasjonen Oppgave ferdig Bacheloroppgaven leveres til kopisentralen Bacheloroppgaven leveres Studenttorget A3 Plakaten leveres til laminering Laminert plakat leveres til Studenttorget Presentasjon Fremdrift Sammendrag Eksterne aktiviteter Tidsfrist Milepæl Prosjektsammendrag Ekstern milepæl Side 1

17 Avvik fra prosjektplan Vi fikk noe avvik fra prosjektplanen som fra det vi hadde planlagt, dette dreier seg hovedsakelig om endringer i forbindelse med at vi gikk for CakePHP rammeverket. Siden vi valgte å gå for CakePHP rammeverket, har vi måttet bruke en del tid på å sette oss inn i dette. Vi har derimot kunnet fjerne punktet hvor vi tenkte å sette oss inn i innloggingsprosedyrer og krypteringer, da Cake har hatt dette integrert som en del av rammeverket. Koding av webfrontend har vi latt stå fremdeles, da dette er blitt gjort parallelt sammen med koding av selve kjernen til applikasjonen våres. Vi har også valgt å droppe Facebook integrasjon. Dette har hovedsakelig for at vi har kommet fram til at Facebook støtte ikke vil gi oss så mye relevant informasjon om Alumni brukeren, og vil være mer en belastning for brukeren enn ett hjelpeverktøy. Vi har her derfor valgt å heller prioritere viktigere deler av systemet. Vedlegg 4, side 3

18 AutoComplete Lisens: MIT & GPL Versjon brukt: v1.1 Hjemmeside: Forfatter: Jörn Zaefferer Avhengigheter: jquery Endringer i koden gjort av oss: ingen Komme i gang: AutoComplete er et jquery tillegg som raskt og enkelt genererer listemenyer under inntastingsfelt. Med dette tilegget kan man definere hvordan man ønsker informasjon vist, samt hva man ønsker skal skje dersom man velger ett element på listen. Figur 1 Før man starter å bruke dette tillegget, må man inkludere jquery biblioteket, jquery.autocomplete.js, samt jquery.autocomplete.css. I prosjektet har vi brukt dette tillegget med Ajax teknologi. Ajax er kort og enkelt at man kjører et PHP skript skjult for brukeren ved hjelp av JavaScript, for så å hente ut resultatet generert av PHP skriptet. For å få en funksjon som den på Figur 1, har vi brukt følgende kode: Figur 2 Her kan man bytt ut [name=sok] med id, klasse, elementtype og lignende. Her er filen ajax.php definert som skriptet som generer listen. Autocomplete er også avhengig av en funksjon til, denne funksjonen tar hånd om hva som skal skje dersom man velger et av elementene i listen: Figur 3 Vedlegg 5, side 1

19 Siden vi her bruker Ajax, må man ha et PHP skript å hente informasjon fra. For at AutoComplete skal vise denne informasjonen riktig, må denne formateres på en bestemt måte. AutoComplete bruker tegnet en vertikal strek som skilletegn for å dele informasjonen horisontalt, og tegnet \n for å skille informasjonen vertikalt fra hverandre. Eks. for Figur 1: Første 1\nAndre 2\nTredje 3" her vil Første, Andre og Tredje vises på listen, mens 1, 2 og 3 som her indikerer elementets id, vil bli sendt skjult med listen, og kan hentes ut dersom man trykker på elementet i listen. Informasjonen i eksemplet over hentes ut ifra data parameteren i Figur 3, i dette tilfellet data[0] for navn, og data[1] for id. Behandling av listens elementer Dersom man her ønsker en liten ekstra sikkerhet for at elementet alltid skal være det siste i data matrisen, kan man bruker data[data.length -1]. Dette kan være nødvendig dersom brukeren skal kunne legge med egne tegn i navnet. Dersom man også ønsker at alt utenom siste oppføring i matrisen skal vises i selve listen, slik at dersom brukeren legger med tegn i navnet, vil dette vises korrekt må man formatere listeelementet i tilleggets konfigurasjon(figur 2) for å gjøre dette: Figur 4 Her vil det bygges opp en ny tekst hvor alle elementer utenom den siste legges inn i listen, dvs. at dersom man har situasjonen Første1 Første2 1\nAndre 2\nTredje 3", så vil Første1 Første2 vises, og ikke bare Første1. Parametere Som standard vil AutoComplete sende teksten i tekstfeltet inn i Ajax PHP skriptet med $_GET metoden som variabel q. $_GET metoden er en metode som sender med parametere i form av url?q=tekst. I dette eksemplet vil teksten tekst bli sendt med bak skriptets adresse som parameter q. Denne hentes så inn igjen med $_GET["q"] i PHP skriptet. Vedlegg 5, side 2

20 Dersom man skal legge inn diverse ekstra parametere til søket, må dette gjøres i med konfigurasjonen extraparams: Figur 5 Her sendes parameteren aktiv med inn i skriptet. aktiv er her enten en JavaScript variabel, eller en JavaScript funksjon som returnerer en verdi. På denne måten kan man gjøre mer sofistikerte spørringer mot databasen. Dersom man gjør en endring som så skal sendes med inn i Ajax skriptet, bør man først bruke AutoComplete sin funksjon flushcache. Dette for å passe på at AutoComplete henter ut ny data, fremfor å søke gjennom gammel data. Dette kan i dette tilfelle gjøres med: Figur 6 Vi har market I dette prosjektet at dersom man bruker andre nettlesere enn Internet Explorer er dette spesielt viktig å være nøye med, da man her ofte ikke vil kunne merke så mye til dette problemet. Vedlegg 5, side 3

21 jstree Lisens: MIT & GPL Versjon brukt: v0.9.9a2 Hjemmeside: Forfatter: Ivan Bozhanov Avhengigheter: jquery Endringer i koden gjort av oss: ingen For å komme i gang med jstree: For å bruke denne pluginen, må man legge til jquery og jstree skript-filenene i html koden. Deretter må man definere treet, her vist gjort med treets id: Figur 7 For å kode selve treet bruker man følgende struktur: HTML: Utseende: Figur 8 Som man kan se av illustrasjonen over, så ligger treet i en <div> tag, og selve strukturen baserer seg på en standard html-liste. For hvert nivå i treet lager man derfor en <ul> tag, med <li> tags for hver node i treet. <ins></ins> er brukt for å få fram selve ikonene i treet. For å gjøre nodene i treet klikkbare, legger man disse inn i en link på vanlig måte. Disse linkene vil derimot ikke fungere på vanlig måte, og man må definere hva som skal skjer under trykking i jstree sin konfigurasjon. Konfigurasjon: Konfigurasjonsparametere settes inn i utkommentert område i kode på Figur 1 ovenfor. Definisjon av utseende: Figur 9 Her har vi laget våres eget utssende, som er en blanding mellom utseendene default og classic. Vær oppmerksom på at dersom man endrer utseende må man være ganske nøye med å også oppdatere innholdet i style.css under utseendets mappe slik at navnene der passer med det nye navnet. Vedlegg 5, side 4

22 Node konfigurasjon: Figur 10 Her har vi kun konfigurert bort muligheten for å dra noder rundt i treet, da dette ikke har noen funksjonalitet for prosjektet, og vil kun ødelegge for treets integritet. default settes da vi ikke har definert egne typer av nodene. draggable: false skrur av muligheten for å dra noder rundt med musen. Hendelser: Under hendelser(callbacks) definerer man hva som skal skje når en bruker gjør et inngrep på treet som for eksempel velger en node, åpner eller lukker en node og lignende. I dette prosjektet har vi brukt 4 hendelser: onselect: En node i treet blir valgt. onopen: En node åpnes, og undernoder vises fram. onclose: En node lukkes. onload: når treet hentes ut første gangen. Et eksempel på en hendelse kan være: Figur 11 Her vil nodens id bli vist på skjermen dersom man velger en node. Siden noden er definert som <li> elementer, så vil dette da si <li> sin id er den som hentes ut. Riktig struktur på en node vil derfor da bli <li id= node_id >. Dersom man henter ut en id, kan man identifisere den spesifikke noden med denne, og dermed gjøre en del andre opperasjoner ut ifra dette. Om man ønsker å besøke en link, kan dette gjøres med: Figur 12 Her vil jquery sørge for at linken under noden blir besøkt på samme måte som om man skulle trykket på den uten jstree aktivert. Vedlegg 5, side 5

23 Generere tre ut ifra CakePHP sin traversering: Siden CakePHP traverser treene sine før de legger dem i databasen, kan man ikke helt uten videre får disse treene ut i html form som kan leses av jstree eller andre JavaScript plugins. CakePHP traverserer trestrukturen sin på en måte som er en mellomting av pre- og postorder. Hver node i tabellen vil derfor få to heltall(integer) nøkler for å identifisere sin plassering i treet, et som kalles lgt, og et som kalles rght. Tabell: Treeksempel Tre: Figur 13 Regler for bygging av tre blir som følger: 1. Under henting fra databasen, skal uthentet informasjon sorteres etter lft for å holde treets integritet på plass. 2. Hver node kan ha flere barn, så treet er ikke binært. 3. Om en nodes rght = lft+1, har denne noden ingen barn. 4. Dersom en nodes(x) rght lft+1, skal alle noder videre behandles om undernoder av x til man finner en node som har lft større enn x sin rght. Koden vi har laget for dette prosjektet: Figur 14 Vedlegg 5, side 6

24 TinyMCE Lisens: LGPL Versjon brukt: v3.3.4 Hjemmeside: Forfatter: Moxiecode Systems Avhengigheter: jquery Endringer i koden gjort av oss: ingen Komme i gang: TinyMCE er et av de mest brukte og populære WYSIWYG 1 tekstbehandlingsprogram. Kort forklart er det brukeren skriver og ser i tekstfeltet, er slik det vil se ut ved publisering. Siden vi har valgt å gå for jquery i prosjektet, har vi også her valg å gå for TinyMCE sin jquery pakke. Under er et eksempel på TinyMCE i bruk: Figur 15 I Figur 1 over tilkalles TinyMCE med en rekke tilleggsfunksjoner, mange som i flere tilfeller er unødvendige eller kan oppføre seg merkelige ved enkelte webdesign. For å ta i bruk TinyMCE, må vi først legge til jquery og TinyMCE skript-filene i html koden vår. For å lage en helt enkel en trenger vi kun å kjøre følgende kode: Figur 16 Det eneste nødvendige av kode, er her å starte skriptet og deretter initiere TinyMCE med kun konfigurasjonen at vi skal bruke HTML-taggen <textarea> som tekstbehandlingsområde. Etter å ha lagt til skriptfilene og koden over vil vi ikke få noe ut på websiden før vi legger til <textarea>- og <form>-tagsene. Koden for disse to blir som følger: 1 What You See Is What You Get Vedlegg 5, side 7

25 Figur 17 Disse kodesnuttene gir oss en nedstrippet versjon av TinyMCE og med kun enkle tekstbehandlingsverktøy, slik ser den ut i en webleser: Figur 18 Det som kan være ønskelig nå er å legge til en submit knapp for å gjøre noe med tekst innholdet. Om det så er at man ønsker og kun vise det på en annen side, eller ønsker man kanskje å legge det inn i en database. Under prosjektet våres ble blant annet artiklene som vises på forsiden og hos Alumner produsert i TinyMCE, ved submit lagret inn i Events tabellen. Alt som fylles inne i feltet på TinyMCE vil bli omgjort til HTML kode bak kulisene, eksempelvis teksten brukt i Figur 4: En helt enkel og grei utgave av TinyMCE!. Ser teksten egentlig slik ut: <p>en helt <strong>enkel</strong> og <strong><span style="text-decoration: underline;"><strong>grei</strong></span></strong> utgave av TinyMCE!</p>. Når denne kodesnutten så blir skrevet i en HTML-fil og så visst i en nettleser, vil vi da få ut teksten identisk med slik det så ut når vi skrev den inn! Konfigurasjon: TinyMCE er veldig konfigurasjonsvennlig og det finnes en rekke forskjellig tillegg som kan legges til i TinyMCE. For å bli mer kjent med alle mulighetene og se noen eksempler på de i bruk, vil det beste være å gå over hjemmesidene og dokumentasjonen til TinyMCE. Sidene og er de to sidene som er anbefalt å se på. Vi vil under her gå raskt gjennom de forskjellige funksjonene vi valgte å legge til i vårt prosjekt. Først vil vi se på hele koden: Vedlegg 5, side 8

26 Figur 19 Theme: Advance, vi må legge til denne for at theme funksjonene skal kunne aktiveres og legges inn i TinyMCE. Plugins: Enkelte funksjoner krever at du legger til plugins. Theme_advance_buttons1(2,3 osv.): Her fyller man på funksjonene man ønsker. Tallene 1,2 osv har med hvilke rad knappene for funksjonen settes. CSS filen: For at det vi faktisk skriver i TinyMCE skal se identisk ut ved publisering, må vi legge til samme CSS fil i konfigurering. Dette har med at CSS filene vil jo forandre hvordan HTML-koden skal presenteres og det er da viktig at denne presenteringen også blir gjort inne i TinyMCE. Vedlegg 5, side 9

27 Timer brukt Vi har i dette prosjektet brukt timeplanen: fra til antall timer mandag 12:00 15:00 3 tirdag 14:30 15:30 1 onsdag 09:00 16:00 7 torsdag 09:00 16:00 7 fredag 09:00 12:00 3 helg ~ 8 Totalt: 29 Tabell 1 fredag 10 % helg 28 % antall timer mandag 10 % tirdag 4 % onsdag 24 % torsdag 24 % Figur 1 (Minst ett kakediagram må til i prosjektet) Denne timeplanen har fungert veldig greit, og vi har vært pliktoppfyllende og møtt opp til riktige tider. Og dersom noen har vært borte, har vi prøvd å ta dette igjen så godt som kunne for å få det til å gå. Unntak fra reglen over er: Borte statistikk Hvem Timer borte Hvorfor Oddbjørn 10 Jobbintervju Petter 10 Jobbintervju Lasse 10 Jobbintervju Oddbjørn 3 Rammsteinkonsert Petter 10 Englandstur Petter 2 NAF kontroll(bilen ble ikke godkjent) Lasse 4 Askefast(Jobbet noe fra Bergen) Oddbjørn 3 Lege, tannlege, og synssjekk Tabell 2 Totalt er antall timer fritatt 52 på alle sammen. Vedlegg 6, side 1