Slutrapport Grupp 4, Webscraping

Transkript

1 Webbprojekt I, 1DV411 Slutrapport Grupp 4, Webscraping Author: Caroline Millgårdh, Samuel Bobeck, Martin Svensson och Nikola Romcevic Supervisor: Tobias Ohlsson Semester: Spring 2012 Course code: 1DV411

2 Sammanfattning Det primära målet med projektet var att projektmedlemmarna skulle få lära sig vad det innebär att jobba i ett större projekt mot en riktig kund. Kunden i fråga var IT-företaget Do You Like It AB. Inför ett kommande projekt behövde de hjälp med att utveckla en applikation som hämtade och sparade företagsinformation från webbsidan företagsfakta.se. Applikationen skulle bestå av två interface; ett där användaren specifierade vad för typ av företag som skulle hämtas från företagsfakta.se och ett där användaren kunde söka genom redan sparade företag i databasen. Då applikationen är tänkt att hantera stora mängder av data så behövde kunden även veta vilken av databastyperna MySQL och NoSQL som fungerar bäst för ändamålet. 1(17)

3 Förord Denna rapport beskriver den webbapplikation, och arbetet med att utveckla den, som skapades åt Kalmarföretaget Do You Like It AB. Arbetet genomfördes som en del av vår utbildning, inom kursen Webbprojekt 1, och presenterades mars 2012 för vår handledare och övriga kursdeltagare. 2(17)

4 Innehållsförteckning Sammanfattning...1 Förord...2 Innehållsförteckning...3 Bakgrund...4 Syfte...5 Mål...5 Projektorganisation...6 Teknik...7 Metodik...8 Resultat...10 Avvikelser...12 Slutsats...13 Förslag på vidareutveckling...14 Förslag till förbättringar inför kommande projekt...14 Källförteckning (17)

5 Bakgrund Kunden för gruppens arbete var företaget Do You Like IT AB[1], ett ITföretag med inriktning på webben. I ett utav deras projekt så behövde de en applikation för att samla in och spara företagsinformation, främst ifrån företagsfakta.se[2], vilket de efterfrågade hjälp med. Eftersom stora mängder data skulle sparas så var valet av databassystem viktigt, och kunden efterfrågade således också någon sorts undersökning och redogörelse för vilket system som skulle passa bäst för dem. Valet stod här mellan MySQL[3] och någon form av NoSQL-system[4]. Utöver skrapningsapplikation så efterfrågade också kunden ett enkelt sökgränssnitt mot databasen. Sökningen skulle kunna användas för att enkelt undersöka att en skrapning fungerat som den skulle, och som ett exempel på hur data kan hämtas och presenteras utifrån de databasmodeller som vi skulle bygga. Skrapning Metoden att samla och utvinna data från en webbplats per automatik med hjälp av en robot kallas för skrapning. Skrapningen går till så att roboten simulerar ett besök på den webbsida som ska skrapas genom att göra ett anrop mot den, precis som en vanlig besökare skulle göra, och får som svar sidans innehåll. Ur sidans innehåll kan sedan de element som är av intresse hämtas ut[5]. 4(17)

6 Syfte Syftet med detta projektet var först och främst lärdomen av att jobba tillsammans i en grupp mot ett skarpt projekt, med all planering, dokumentation, utveckling och testning som det innebar. Stor vikt lades på iterativ utveckling, vilket är en arbetsprocess som är vanligt förekommande inom it-branschen och därför väldigt relevant att lära sig och känna sig bekväm med inför framtida projekt. Gruppmedlemmarna turades om med att ta på sig rollen som gruppledare så att alla fick känna på ansvaret med att leda ett webbprojekt. Mål Målet var att skapa en applikation för att kontrollera och genomföra skrapning av företagsinformation från företagsfakta.se. Företagen som skrapades skulle sparas i en databas och där kunna knytas till annan lagrad relevant information. Ett viktigt delmål var att välja bäst passande databassystem och databasmodell för just den sortens data som skulle skrapas. 5(17)

7 Projektorganisation Projektansvarig: Tobias Ohlsson Handledare: Martin Fredriksson Kund: Mahmoud Haidar, Do You Like It AB Projektgrupp: Caroline Millgårdh Martin Svensson Samuel Bobeck Nikola Romcevic 6(17)

8 Teknik Skrapningsapplikationen skrevs i PHP[6] på kundens begäran. Utöver det så användes javascriptbiblioteket jquery[7] för applikationens gränssnitt och användarinteraktion. Orsaken till att blanda in jquery till så stor del som möjligt var att göra applikationen mer responsiv och användarvänlig. Google Docs[8] användes mycket flitigt till all sorts dokumentation för att kunna skriva tillsammans. Då det mesta av programmeringen skedde enskilt var det viktigt med versionshantering. Detta gjordes med hjälp av TortoiseSVN[9] och lagringsutrymme på skolservern som projektgruppen blivit tilldelad. Tack vare detta arbetssätt kunde risken att spara över varandras kod minimeras samtidigt som det skapades backuper om något gick snett. Valet mellan MySQL eller något NoSQL-system föll till slut på båda genom att applikationen skrevs med stöd för två databassystem och funktionalitet för att enkelt i gränssnittet kunna styra vilken databas som skulle användas. Detta gav en mycket bra möjlighet för både projektgruppen och kunden att kunna testa applikationen i sin helhet med vardera databassystem, och enkelt kunna jämföra tid och prestanda. Det gjorde också situationen för kunden lättare genom att denne slapp ta beslutet om databassystem under projektets gång baserat på våra redogörelser, och istället fick levererat ett system där båda alternativ ingick. NoSQL-systemet som valdes var MongoDB[10]. MongoDB MongoDB är ett NoSQL-databassystem med öppen källkod, som släpptes år 2009 och som sedan mars 2011 anses vara produktionsredo. Det är dokumentbaserat vilket innebär att varje post, som i en relationsdatabas skulle sparas som rad, istället sparas som ett dokument med noder för varje fält posten innehar. I MongoDBs fall så är dessa dokument strukturerade i BSON[11] (Binär JSON). Det är mycket likt JSON[12] förrutom att det är snabbare och bland annat kan hantera datatyper. I dokumenten kan man, precis som i ett vanligt JSON-objekt, spara valfria egenskaper och nästlade objekt och arrayer (kallade inbäddade dokument), vilket gör dem väldigt dynamiska och anpassningsbara[13]. 7(17)

9 Metodik Arbetsmetoden för projektet var till en viss del utstakad av kursledningen och denna del var tvungen att följas. Detta innefattade ett par moment som skulle genomföras under varje iteration: Handledarmöte Projektledarbyte Test av systemet Leverans och återkoppling Riskhantering Individuell tidsrapportering Ny iterationsplan för kommande iteration Handledarmöte och projektledarbyte skedde regelbundet varje vecka under de första 4-5 veckorna tills projektet och planeringen ansågs vara helt under kontroll. Återkoppling med kund, testning och riskhantering skedde så fort nya väsentliga delar hade implementerats för att garantera att projektet var på rätt spår och allting fungerade som det skulle. Både skrapning och NoSQLdatabaser var nya områden även för kunden vilket innebar att frekventa möten och genomgångar av vart projektet vart på väg var viktigt. Flera gånger under utvecklingen så tillkom det nya önskemål från kundens sida vilket vi i de allra flesta fall kunde tillmötesgå tack vare iterativt arbetssätt och god kontakt med kunden. För att hålla ordning på projektets alla delar och uppgifter så sattes en taktisk plan upp, en lista med alla uppgifter som skulle göras i projektet, som sen fylldes på under projektets gång så fort nya uppgifter eller detaljer dök upp. Med hjälp av den taktiska planen var det lätt att dela upp arbetet mellan gruppmedlemmarna och hålla koll på vad som var gjort och hur mycket som var kvar att göras. Skrapnings- och sök-applikationen var båda relativt små vilket innebar att arbetet redan från början var ganska lätt att överblicka. I och med det så märktes snart att det inte fanns något större behov av att använda sprint backlog och burndown chart som del av våran iterationsplan, de 8(17)

10 metoderna tillförde ingenting till planeringen som inte kunde ersättas av den gemensamma taktisk planen Projektgruppen delades i ett tidigt skede upp i två primära grupper, en grupp som tog hand om databasmodelleringen och en grupp som tog hand om själva skrapningsfunktionen. Till en början lades den mesta tiden på att läsa på, sätta sig in i och testa både NoSQL och olika skrapningstekniker. Det finns en uppsjö av NoSQL-system, och MongoDB var inte det självklara valet från början. Det var viktigt att det system som valdes passade för den sorts data som skulle sparas, men också var relativt enkelt att installera och hantera så att kunden smidigt kunde få det i bruk på sin server så fort som möjligt. Skrapning kan göras med flera olika tekniker och eftersom det var en otroligt omfattande mängd data som skulle hämtas så var det mycket viktigt att den absolut mest optimala metoden användes. När det gäller hämtning av data så testades och jämfördes bland annat PHP s inbyggda funktioner (file_get_contents) och data-transfereringsbiblioteket curl[14]. För själva skrapningen (extraheringen av information från den hämtade datan) så testades metoder för att omvandla datan till DOM-strukturer kontra reguljära uttryck. curl tillsammans med reguljära uttryck var det som visades sig vara den optimala metoden. Under början av utvecklingen så användes lokala servrar och lokala MySQLdatabaser. Efter att beslutet om MongoDB som NoSQL-databas tagits så började vi använda tjänsten Mongolab[15], vilken erbjuder en gratis MongoDB med upp till 250 megabytes utrymme. Ungefär halvägs in i projektet så var kundens server redo för användning med både MySQL och MongoDB installerat. Detta öppnade upp för de första leveranserna, och efter det så skedde en frekvent uppdatering på kundens server varje gång någon ny funktionalitet hade testats klart lokalt. För varje uppdatering så laddades en change log upp på servern med beskrivning om vad som var nytt så att kunden enkelt kunde följa utvecklingen. 9(17)

11 Resultat Projektet flöt på mycket bra och alla baskrav uppfylldes utan några större problem. Arbetet hade redan från början känts relativt överkomligt och detta bekräftades halvvägs in i projektet då de flesta baskrav redan hade implementerats. Detta gav möjlighet att gå vidare med applikationen och implementera ytterligare funktionalitet för att förbättra den. Kunden hade flera nya idéer och önskemål om vad de gärna ville ha med och gruppen presenterade flera förslag vilket ledde till en mängd nya krav under projektets gång. Mot slutet av projektet så blev det lite stressigt då några nya krav dykt upp under sista veckorna som gruppen väldigt gärna ville ha med i leverans. Det ledde till att vi fick gå över leveransdatumet något vilket vi varnade kunden för innan men de tyckte inte det var några problem för att få med de extra kraven de önskade. Kunden var väldigt tillmötesgående och sa redan från början att de var osäkra på hur mycket tid och arbete projektet kunde tänkas ta, och att de var nöjda med att vi gjorde så mycket vi hann. De var således mycket nöjda vid projektets slut med resultatet som innehöll allt de hade bett om plus en hel del extra funktionalitet. Projektet var dock inte helt utan komplikationer. Det allra största problemet som uppstådde var att MongoDB presterade mycket ostabilt på kundens server och kraschade flera gången när servern var under belastning, oavsett om det var MongoDB eller MySQL som belastades. Detta var mycket svårt att felsöka och hitta orsak till då varken vi eller kunden själv var ägare till servern utan den hyrdes av kunden och stod någon annanstans. Vid projektets slut fanns fortfarande inget svar eller lösning på detta bekymmer vilket var en besvikelse. Kunden nämnde att de var mycket missnöjda med de som tillhandahöll servern och möjligvis var det helt enkelt något fel på serversidan eller installationen av MongoDB. Om felet på något sätt låg i den levererade applikationen så lyckades det tyvärr inte lokaliseras, och då allting fungerade som det skulle när det testades lokalt och på Mongolab.org så är förhoppningen att servern hos kunden bråkade och en enkel ominstallation av MongoDB eller serverbyte kan lösa det. Tidigt i utvecklingen så implementerades tidmätning i skrap-applikationen vilket gjorde att testning och jämförelse mellan MongoDB och MySQL samt 10(17)

12 undersökande av var flaskhalsarna i skrapningen fanns blev möjligt. Det märktes snabbt att de största flaskhalsarna var hämtningen av sidor från företagsfakta.se samt användandet av MySQL. Följande är exempel på tidsskillnader vid skrapning. Företagsfakta.se skrapas på sökorden Städservice + Stockholm, detta returnerar 1650 företag: Hämtning av företagssidor: Extrahering av sidornas innehåll med reguljära uttryck: Insättning i databas vid användning av MongoDB: Insättning i databas vid användning av MySQL: Samma skrapning igen för att testa update till databas: Uppdatering i databas vid användning av MongoDB: Uppdatering i databas vid användning av MySQL: sekunder sekunder sekunder sekunder sekunder sekunder 11(17)

13 Avvikelser Bortsett från ett par avvikelser så har samtliga krav i kravspecifikationen implementerats. Den första avvikelsen är att vi beslutade oss att implementera stöd för både MongoDB och MySQL för att underlätta testning. Detta har även inneburit att kunden nu kan använda sin applikation med båda databaserna, och i lugn och ro själv bestämma vilken som passar dem bäst. Den andra avvikelsen var att använda jquery för att göra både söknings- och skrapningsgränssnittet mer responsiva och användarvänliga. Vi föreslog dessutom ett antal förbättringar och funktioner för kunden som mottogs med ett positivt gensvar och således implementerades. Det tillkom även nya önskemål från kundens sida under utvecklingen, vilket vi i de allra flesta fall kunde tillmötesgå. 12(17)

14 Slutsats Projektet har i sin helhet flutit på bra. Det tog lite tid innan vi fick riktigt grepp om det vi skulle göra, men eftersom projektet var relativt litet skapade detta inga problem tidsmässigt. Samtliga medlemmar har deltagit aktivt och gjort att projektet stadigt gått framåt. Tidsplanen har i stort sett hållit, även om det blev lite stressigt sista veckan p.g.a. sena kundändringar och en kraschande server. Ingen av oss hade arbetat med skrapning förrut, och det tog lite tid att klura ut det bästa och mest effektiva sättet att göra det. Vinnaren blev till slut reguljära uttryck. De är snabba men även väldigt fragila. Om html-strukturen på företagsfakta.se skulle ändras på något sätt så kommer inte skrapan fungera längre. De flesta av oss hade inte heller någon kunskap om nosql-databaser. Det var intressant att undersöka den marknaden och se vad som fanns till buds. MongoDB utkristalliserade sig tidigt som en favorit, och efter närmare studier så kändes den som ett självklart val. En av dess fördelar var inbyggd funktionalitet för geolocation, vilket passade projektet perfekt. Vi blev alla imponerade av MongoDBs snabbhet och flexibilitet, och arbetar gärna med den igen i framtiden. Det vi kunde ha gjort bättre var att vi kunde ha kontaktat kunden snabbare. Efter det första mötet tog det även en tag för oss att inse att vi inom gruppen fått helt olika uppfattningar som vad som skulle utföras. Det krävdes en rejäl gruppdiskussion där vi skrev ner frågor till kunden för att komma till rätta med problemet. Först efter ytterligare ett kundmöte kom vi på det klara med vad vi skulle göra. Detta skulle ha lösts under första veckan men tog istället två till tre veckor. Testningen på kundens server skulle ha skett tidigare, på så sätt skulle vi möjligtvis kunnat upptäcka dess tendens att krascha lite tidigare och haft mer tid till att felsöka det. Vi hade tidigare gjort alla tester på lokala servrar eller mot Mongolab.org och blev ganska tagna på sängen när kundens server slutade fungera under samma tester. Allt tyder på att felet är hos servern och vi hade isåfall ändå inte kunnat göra något åt det men hade iallafall kunnat varna kunden tidigare. 13(17)

15 Förslag på vidareutveckling Både söknings- och skrapningsformuläret skulle bli mer användarvänligt med autocomplete-funktionalitet[16], men för övrigt är det svårt att föreslå fler förbättringar och funktioner då kunden var ytterst förtegen om vad applikationen skulle användas till. Förslag till förbättringar inför kommande projekt Inför framtida projekt skulle vi se till att etablera kundkontakt snabbare och verkligen se till att vi vet exakt vad det är som ska utföras. Vi skulle även testa servrar tidigare för att se att de fungerar även när de utsätts för lite press. Om vi fick välja versionshanteringsverktyg skulle valet falla på git[17] istället för svn. Vi skulle även anpassa dokumentationen efter projektet och välja bort några dokument till förmån för andra. 14(17)

16 Källförteckning [1] 'Do You Like It AB', Tillgänglig: [Hämtad: 1 april, 2012]. [2] 'FöretagsFakta i Halmstad AB', Tillgänglig: [Hämtad: 1 april, 2012]. [3] 'MySQL', Tillgänglig: [Hämtad: 1 april, 2012]. [4] 'Wikipedia: NoSQL', Tillgänglig: [Hämtad: 1 april, 2012]. [5] 'Wikipedia: Web Scraping', Tillgänglig: [Hämtad: 1 april, 2012]. [6] 'PHP: Hypertext Preprocessor', Tillgänglig: [Hämtad: 1 april, 2012]. [7] 'jquery: The Write Less, Do More, JavaScript Library', Tillgänglig: [Hämtad: 1 april, 2012]. [8] 'Google Dokument', Tillgänglig: [Hämtad: 1 april, 2012]. [9] 'TortoiseSVN', Tillgänglig: [Hämtad: 1 april, 2012]. [10] 'MongoDB', Tillgänglig: [Hämtad: 1 april, 2012]. [11] 'Wikipedia: BSON', Tillgänglig: [Hämtad: 1 april, 2012]. [12] 'Wikipedia: JSON', Tillgänglig: [Hämtad: 1 april, 2012]. [13] 'Wikipedia: MongoDB', Tillgänglig: [Hämtad: 1 april, 2012]. [14] 'curl', Tillgänglig: [Hämtad: 1 april, 2012]. [15] 'MongoLab - MongoDB Hosting Cloud Hosted MongoDB', Tillgänglig: [Hämtad: 1 april, 2012]. 15(17)

17 [16] 'Wikipedia: Autocomplete', Tillgänglig: [Hämtad: 1 april, 2012]. [17] 'Wikipedia: Git (software), Tillgänglig: [Hämtad: 1 april, 2012]. 16(17)