(tid til endnu et langt indlæg fra julemand101)
Dejligt at se nogen tager sig tid til at læse det.
Rapporten er skrevet til folk der har en bachelor grad i software og derfor er alting ikke forklaret i dybere detaljer. Jeg skal dog nok forsøge at svare på alle spørgsmål omkring fagord osv.
1. [OMB07] betyder blot at det er en kilde vi har benyttet som kan findes bag i vores appendix med navnet [OMB07]. Navnet er generet ud fra forfatterne af kilden samt udgivelsesåret således at {OMB07] peger på (du kan i de fleste PDF læsere trykke på [OMB07] i rapporten og den vil så vise dig kilden):
Liam O'Brien, Paulo Merson, and Len Bass. Quality attributes for service-oriented architectures. In Proceedings of the International Workshop on Systems Development in SOA Environments, SDSOA '07, pages 3--, Washington, DC, USA, 2007. IEEE Computer Society.
Systemet til den slags er indbygget i LaTeX sammen med Bibtex og sker helt automatisk. Det er en af de ting der gør at det er til at overkomme at skrive sådan en rapport.
Men altså "Quality Goals" går kort sagt ud på hvilke kvalitetskrav vi stiller til projektet. Her opstiller vi så en række forskellige slags krav der kan være til projektet og giver derefter en vurdering af hvor vigtig de forskellige ting er. Fx finder vi det meget vigtigt at systemet er modulært (det vil sige at systemet er lavet i en række komponenter der hver især er nemme at udskifte og vedligeholde uden at det ødelægger resten af systemet) mens vi derimod i dette projekt ikke finder det vigtigt at fokusere på hvor tilgængelig systemet er da projektet kun er et uni-projekt. Håber det forklarer hvad der menes
2. SOAP (og REST) er en måde til hvordan man forbinder servere med deres klienter i et netværk hvor der er en fælles standard for hvordan der kommunikeres. Et eksempel er Steam. Steam har et web service hvor udviklere kan bruge denne til at hente forskellige informationer om fx hvilke achivements en given bruger har. For at alle udviklere i verden kan forstå hvordan man skal kommunikere med denne web service er der nedskrevet en dokumentation der beskriver den standard der benyttes. Dette kunne så foregå via SOAP eller REST (aner ikke hvad Steam præcist lige gør).
Forskellen på SOAP og REST er så kort sagt hvor avanceret man ønsker tingene. SOAP er yderst kompliceret men gør så også samtidig det muligt at lave mere kompliceret ting. REST derimod er yderst simpelt og eftersom vi i vores projekt kun skal bruge en meget simpel funktion (anbefal film for en given bruger) så kan vi "nøjes" med REST.
3. Stort set alle vores projekter (og alle uni projekter sikkert) kan der bygges videre på. Årsagen til der er et kapitel der hedder "Future Works" er fordi der stilles krav om at vi har dette kapitel i rapporten. Det er vigtigt for vores uddannelse at vi altid fokuserer på hvad der kan gøres bedre, hvad der kan udvikles videre med samt hvilke problemer der er. Vi startede dette projekt med på forhånd at have en temmelig stor plan for projektet og derefter bestemme hvilke dele af dette store projekt vi ønskede at implementere. Fordelen ved dette har været at vi altid kan tage en funktion og pege på hvordan den ville passe ind i det store billede.
Dette har så også gjort at vi har kunne skrive et mere omfattende Future Works afsnit og vi til vores eksamen kan forklare hvordan alt passer ind. Da jeg blev sat til at udtænke den overordnede store plan for projektet var mit mål at finde på et system der ville være noget jeg ville være stolt over at lave. Det system vi har fået lavet er på ingen måde færdigt men det ændre ikke på at jeg synes at der virkelig er en god ide i vores projekt (projektet er lidt mere avanceret end jeg fortalte før så læs sidst i mit indlæg den mere detaljeret plan).
Men som der sker for alle disse projekter så sker der ikke en skid mere med dem efter projektet er afleveret. Årsagen er at vi er nød til at fokusere 110% på det næste projekt for også at gøre dette endnu bedre end det forrige. Hvad kan man gøre ved dette? Ikke ret meget andet end man kan tage projekterne med sig i den store erfaringskuffert og måske bruge det til noget en anden gang.
Projektet i mere detaljeret form:
Web siden har til formål at brugerne kan oprette profiler og give ratings til film. Disse ratings bliver så gemt i vores system og brugerne kan så se hvilke film de ellers bør se. Sådan et system findes der allerede massere af.
Forskellen er så her at vi ønsker at gøre det nemt for forskellige forretning der sælger film at bruge vores system (se det som fx edbpriser.dk og dvdpriser.dk). En forretning kan sende en liste til vores system med hvilke film de ejer og vi registrerer så dette. Vi bruger så denne information på flere måder. Først og fremmest kan folk der går ind under en film se hvilke forretning der har den samt prisen. Dette er der heller ikke noget nyt i.
Det nye er så at vi gør således at en registreret bruger i en forretning kan binde sin konto sammen med sin konto på vores system. Fidusen er så at inde på forretningens side så ser brugeren anbefalinger der passer med de information han/hun har opgivet på vores system. Vi vælger så samtidig at gøre således at der kun bliver vist anbefalinger der samtidig kan købes i den butik brugeren besøger. På den måde vil forretningen ikke komme til at reklamere for produkter som de ikke sælger.
Hvorfor er det så lige at butikkerne ønsker at koble sig sammen med vores system? Jo problemet med at give gode anbefalinger at det kræver tonsvis af brugere der har givet en masse information i form af fx ratings. Den slags information kan en butik aldrig få eftersom der brugerne ingen ide kan se i at de skal fortælle fx cdon.com at de kan lide Titanic, Toy Story og Bambi da brugerne ikke føler de får noget ud af det.
Fidusen er så at på vores web side er der en masse sociale ting som fx at man kan have venner og lave filmklubber. Det vil sige vi ønsker at folk får følelsen af at det har en betydning at bruge vores system til at indskrive en masse informationer. Konceptet er det samme som Last.fm og Facebook benytter bare med film. En vigtig forskel til Facebook er at alle kan altid se alle informationer om alle brugerne. Vi føler ikke det skal være nogen hemmelighed hvilken filmsmag man har. (systemet er desuden en rigtig god ide til at vise vennerne hvad for nogle film der kan gives som gave da man jo nemt kan se hvilke film personen ejer og hvilke film der anbefales samtidig med man kan se butikker der sælger produktet samt prisen).
Desuden kan forretninger bruge vores system til at se hvilke film der er mest "anbefalet" i forhold til de brugere der besøger deres side og kan så se om nogle af disse film skal bestilles hjem (kan jo være at forretningen ser at de går glip af rigtig meget salg fordi de ikke sælger Bambi).
Det var lige en lidt mere detaljeret gennemgang af vores planer. Det er på ingen måde alle delene vi har udviklet i en færdig form men mange af de grundlæggende funktioner er bygget og det er så også disse vores rapport fokuserer på. Men som i kan se ligger der store planer omkring sådan et projekt og vi har gjort et stort arbejde med at lave et realistisk koncept denne gang der følger den trend der nu engang er på nettet.
(håber dette kan give andre lyst til at arbejde med software)