Hur väljer man ett språk eller ramverk för en framtida flexibel webbtjänst?

Transkript

1 Hur väljer man ett språk eller ramverk för en framtida flexibel webbtjänst? En fallstudie på en värdekodstjänst JAKOB RASMUSSEN Examensarbete Stockholm, Sverige 2009

2 Hur väljer man ett språk eller ramverk för en framtida flexibel webbtjänst? En fallstudie på en värdekodstjänst JAKOB RASMUSSEN Examensarbete i medieteknik om 30 högskolepoäng vid Programmet för medieteknik Kungliga Tekniska Högskolan år 2009 Handledare på CSC var Hannes Ebner Examinator var Marko Turpeinen TRITA-CSC-E 2009:066 ISRN-KTH/CSC/E--09/066--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Sammanfa-ning Genom intervjuer, workshops och en prototyp togs rekommendationer fram på vilket språk/ramverk som det borde användas i en webbtjänst som uppdragsgivaren Micromarketing utvecklade. I intervjuerna stod det ganska tydligt klart att om man har för avsikt att använda konsulter och extern personal för att sköta själva utvecklingen bör man använda sig utav PHP, ASP.NET eller Java. Det framgick även att beroende på hur pass objekt orienterat ett system är så är det betydligt viktigare för förståelsen av koden än vilken syntax språket använder som man skrivit systemet i. Web services visade sig ha en mycket stor del i MobiCodes vilket ledde till en granskning av vilken typ av web service som man borde använda. Främst studerades den typen av web services som bygger på W3C:s standarder och RESTful web service. Prototypen byggdes i Java och tog hjälp av ett antal nyare bibliotek för att bl.a. testa RESTful web services och att använda convensions over con*iguration i ORM:n. Rekommendationen blev den att vill man få den bästa koden bör man använda sig utav Java eller ASP.NET, i Micromarketings fall blev den slutgiltiga rekommendationen Java eftersom man idag sitter i en open source miljö.

4 How to choose a language or framework for a future flexible web service? a case study of a refund service Abstract Through interviews, workshops and a prototype a couple of programming languages and frameworks were presented as options for continued development of one of Micromarketings web services. The interviews indicated that if you attend to use consults and external people for the development you probably would like to use PHP, ASP.NET or Java. The interviews also indicated that the importance of object oriented architecture was more important than what kind of language syntax you were using when it comes to understanding the code. Web services turned out to be a major part of MobiCodes which led to a deeper studies in W3C web services standards and the RESTful way of designing web services. The prototype were developed in Java and tested a few quit new librarys, one for designing the RESTful web service and another for testing the conventions over con*igurations in the object relational mapper. The Uinally recommendation was for Micromarketing to use Java, you could also use ASP.NET but since Micromarketing already had an open source environment it was more natural to use Java. Both Java and ASP.NET will most likely contribute with the best code.

5 Förord Det Uinns några personer som jag lite extra skulle vilja tacka för att jag har kunnat genomföra detta examensarbete inom webbteknik vid CSC, KTH och på Micromarketing. Ett stor tack riktas till mina handledare Hannes Ebner på KTH som har bistått med tips och idéer från den vetenskapliga sidan samt Donnie SC Lygonis från Micromarketing som bistått med all tänkbar information om MobiCodes, kontaktuppgifter till nyckelpersoner och liknande. Jag vill också passa på att tacka alla de personer som har ställt upp på intervjuer och workshops och på så sätt gjort min studie möjlig.

6 Innehållsförtecking 1. Introduk4on Bakgrund MålsäSning Problemformulering Avgränsningar Läsarmålgrupp MicromarkeGng & MobiCodes Teori Modern webbutveckling Programmeringsspråk Objektorienterad programmering MVC arkitektur Programmeringsspråk och ramverk PHP ASP.NET Java Ruby on Rails Groovy and Grails Python, Django och TurboGears ColdFusion Web services Big Web Services RESTful web services Agil utveckling (Agile development) Agil design (Agile design) Agil dokumentagon Metoder TillvägagångssäS Intervju och workshop urvalet Intervjuer Workshop Prototyputveckling Validitet och reliabilitet Genomförande & Resultat Intervju med MobiCodes utvecklare Intervju med Donnie SC Lygonis, VD på MicromarkeGng Intervju på Fröjd InteracGve AB Intervju med Norbert Täubl, Stopp Intervju med Jim Carlberg och Niklas Eriksson, Pool Telefonintervju företag som migrerat från Coldfusion Gll Ruby on Rails Workshop med Eleni Bellos och Patrik Bruhl, MicromarkeGng Analyser ColdFusion Trender/popularitet Användbarhet/struktur FunkGonalitet Övriga aspekter Prototypen Beslutsunderlag... 40

7 2. Språk och ramverk ApplikaGonen Uhörande MobiCodes AdministraGonsgränssniS TestapplikaGonen Resultat MobiCodes AdministraGonsgränssniS Test applikagonen Slutsats Rekommenda4oner Referenser Bilaga 1: Principerna bakom det agila manifestot Bilaga 2: The Zen of Python, by Tim Peters Bilaga 3: Mailksvar från Staffan Rosenberg, Poolia Bilaga 4: Mailkonversa4on Anki Snis, Manpower Figurförteckning Figur 2.1. Klasser och objekt... 5 Figur 2.2. MVC arkitektur... 7 Figur 4.1. Modell av MobiCodes och dess infrastruktur Figur 4.2. Kodtabell Figur 4.3. ASribuSabell Figur 6.1. Utdrag ur MobiCodesApplicaGon.java, definering av vilken URI som ska länkas med vilken resource klass Figur 6.2. Databas schema över MobiCodes, med Primary Key (PK) och Foreign Key (FK) Förkortningar ASP.NET Active Server Pages för Microsofts.NET ramverk CFML ColdFusion Markup Language CGI Common Gateway Interface CRUD Create Read Update Delete DRY Don t Repeat Yourself HTML HyperText Markup Language IDE Integrated Development Environment IP Internet Protocol JDBC Java DataBase Connection JSON JavaScript Object Notation JSP Java Server Pages

8 JVM Java Virtual Machine MVC Model View Controller OOP Object Oriented Programming, ObjektOrienterad Programmering ORM Object Relational Mapping PHP PHP: Hypertext Preprocessor, tidigare Personal HomePage RPC Remote Procedure Call SOAP Simple Object Access Protocol UDDI Universal Description, Discovery and Integration WSDL Web Services Description Language XML extensible Markup Language

9 1. Introduk4on Detta kapitel redogör för bakgrunden och syftet med examensarbetet. En beskrivning av frågeställningen och avgränsningar ges även i detta kapitel Bakgrund En webbläsare kan tolka html kod, all annan typ av kod skrivs ut som ren text. För att inte begränsa sig till statiska sidor där all information måste hårdkodas in i html dokument så vill man kunna använda sig av dynamiska webbsidor. Fördelarna med dynamiska webbsidor är många och en förutsättning för att vi kan använda internet som vi gör idag. Det är en förutsättning för att kunna interagera med webbsidor, göra det möjligt att kunna logga in på olika typer av sajter och ha sina egna personliga inställningar, söka på Google, skapa innehållet på Wikipedia tillsammans med alla andra användare, köpa varor eller tjänser över nätet mm. Men dynamisk webbprogrammering har förändrats en hel del sedan world wide web introducerades runt Den första typen av dynamisk webbprogrammering byggde på CGI script. CGI script var inte helt enkla att använda sig av och man började istället utveckla andra typer av språk och plattformar som var mer anpassade för att användas på webben. Det började med ett fåtal, PHP var ett av de första men med tiden så utvecklades Uler och Uler och med tiden så förändras även språket samt förutsättningarna för språket eller plattformen. Plattformar som var populära för 7 8 år sedan behöver inte vara aktuella idag och samtidigt som plattformar som inte fanns för 7 8 år sedan kan vara högaktuella idag. Valde man en plattform för ett visst antal år sedan så kan man idag se facit av det valet, oavsett om det var rätt val eller fel val så kan tiden vara inne för att byta eller migrera till en annan plattform av en eller annan anledning. Nya möjligheter har dykt upp som inte fanns i första skedet. Trenderna har förändrats och kompetensen kanske idag Uinns i en annan plattform jämfört med när man gjorde sitt val en gång i tiden. Valet man gjorde då kanske inte var tillräckligt underbyggt eller genomtänkt. Det kan Uinnas en mängd olika anledningar för att göra ett byte, det kan vara rent tekniska anledningar. Att något man är ute efter att tillgodose helt enkelt inte är möjligt i den plattform man just nu bedriver sin tjänst i. Ett av dessa företag som nu ser över sitt val av plattform är Micromarketing som idag driver en tjänst som heter MobiCodes. MobiCodes körs och utvecklas idag i ColdFusion. Mircomarketing utlyste ett examensarbete som hade till uppgift att undersöka vilken eller vilka plattformar som skulle passa för att fortsätta utvecklingen av deras tjänst. I den här studien undersöks frågeställningen enligt de metoder som Uinns i kapitel 3 för att förhoppningsvis komma fram till rekommendationer till Micromarketing Målsä-ning Målsättningen med examensarbetet är att skapa en förståelse för betydelsen av att göra ett aktivt val när man står inför utmaningen att byta språk eller ramverk för olika typer av web tjänster. Att undersöka förutsättningarna och efter det använda sig utav det språk eller ramverk som passar bäst. 1

10 1.3. Problemformulering Vilket/vilka programmeringsspråk/ramverk lämpar sig bäst för framtida Ulexibla utvecklingsprojekt? För att Uinna svar på frågeställningen användes sju stycken underfrågor: 1. Vad är nackdelarna med ColdFusion idag? Varför vill man på Micromarketing genomföra den här migrationen. Vad är inte tillfredsställande med ColdFusion? 2. Hur fungerar och vad är ColdFusion? Har ColdFusion några egenskaper som gör en att en migration till ett visst språk eller ramverk skulle vara mer fördelaktig. 3. Vilka språk och ramverk föredrar konsulter som arbetar med liknande system? För att kunna rekommendera ett språk eller ramverk som inte ska försätta Micromarketing i samma situation igen när det gäller personal rekrytering bör man titta på vad som används i branschen idag. Att även få en översyn på hur dokumentation och struktur bör se ut från branschen håll är intressant. 4. Plattformar med potentiell utveckling, prognoser för framtiden? Att titta på trenderna är en viktig aspekt. Att rekommendera det perfekta ramverket i dagsläget men som på sikt inte kommer att hålla är därför något man bör undvika. 5. Har systemet någon funktionalitet som kan vara avgörande för val av språk eller plattform? Finns det något typ av funktionalitet i MobiCodes som med fördel kan utvecklas i ett visst språk eller ramverk. 6. Vilka ekonomiska aspekter Ainns det att ta hänsyn till? Ekonomiska är en intressant fråga i utvecklings projekt som t.ex. MobiCodes. Hur bör man hantera ekonomin i systemet när man väljer språk eller ramverk. 7. Hur vill Micromarketing arbeta med systemet? Den här frågan önskas ge svar på frågor kring hur man inom företaget ska använda system, hur ska personalen arbeta med det, vad har man för visioner med systemet. Med hjälp av dessa under frågor togs lämpliga metoder fram för att besvara en eller Ulera utav dem. En samlad bild av dessa ska sedan ligga till grund för resultatet av problemställningen Avgränsningar Att avgränsa studien från språk och plattformar känns som en väsentlig del i det här examensarbetet. Dels för att det inte Uinns tid att gå igenom alla och dels för att det inte är en rimlig uppgift att göra. För att avgränsa studien till ett mindre antal ramverk så diskuterades alternativen tillsammans med handledare på Micromarketing och KTH och det ledde fram till följande språk 2

11 och ramverk: PHP, ASP.NET, Java (servlets, JSP m.m.), Groovy and Grails, Ruby on Rails, Turbo Gears och Django. Förutom diskussioner med handledare så hade dessa språk och ramverk intressanta egenskaper som gjorde dem aktuella, en del har stor spridning och popularitet och en del är mer eller mindre nya ramverk som i sin tur bygger på redan mer eller mindre etablerade programmeringsspråk. För att studien ska hamna inom rimliga gränser rent tidsmässigt så har den här studien ingen djupare genomgång av de olika ramverken och plattformarna utan de har istället försökt beskrivas utifrån de särdrag som de olika plattformarna samt språken har. Hur själva migreringen ska gå till undersöks inte i denna studie. Med andra ord så tas det inte hänsyn till om det Uinns automatiserade metoder för att att migrera från en plattform till en annan. Däremot kan grundläggande information om systemets nuvarande infrastruktur spela en roll för beslutet Läsarmålgrupp För att kunna ta del av den här rapporten bör man ha grundläggande kunskap om vad HTML och XML är. Man bör även ha en vis förståelse för hur internet fungerar med de olika protokollen, t.ex. http, IP o.s.v. I det teoretiska avsnittet beskrivs ett antal programmeringsspråk. Men för att få ut mesta möjliga av rapporten är grundläggande programmeringskunskap bra Micromarke4ng & MobiCodes Micromarketing arbetar med digital kommunikation och media och är främst inriktade på den mobila marknaden. Företaget har funnits sedan 1999 och har lång erfarenhet inom skräddarsydda kampanjer. Förutom den mobila marknaden tillhanda håller man tjänster inom webb och tryck (Micromarketing, 2008). En av Micromarketings tjänster heter MobiCodes, vilket är ett registrerat varumärke. MobiCodes är en tjänst som i huvudsak går ut på att generera och validera värdekoder. MobiCodes kan användas på Ulera olika sätt, man har t.ex. använt det tillsammans med ATGs system. Då kunde man gå till en ATG ombudsman och köpa en kod som hade ett värde från 50 kr upp till 250 kr. Sedan kunde man använda koden som betalningsmedel och värdet man köpte produkter på drogs då av från koden. Produkterna gällde då främst innehåll till mobiltelefoner. Mot detaljhandeln har man använt systemet för att ge kunder ett mervärde när de köper en vis typ av produkt. En kampanj som man hade nyligen gick ut på att man köpte ett hemmabiosystem samt en full HDTV från Samsung så Uick man två åskådarbiljetter till Scandinavien masters i golf och ett presentkort från MQ på 500 kr (Newsdesk, 2008). Denna kampanj var då tillgänglig i ett visst antal butikskedjor, t.ex. SIBA och OnOff. I samband med Idol på TV4 så körde man en kampanj där man genom en kod Uick tillgång till en ringsignal, en låt och en bild. I övrigt kan systemet användas i olika typer av tävlingar. 3

12 2. Teori I detta kapitel ges en redogörelse för teorier som är av betydelse för examensarbetet Modern webbutveckling Modern webbutveckling börjar mer och mer att ta efter mönster i traditionell mjukvaruutveckling. Exempel på detta är ökad stöd för objektorientering i PHP 5 jämfört med PHP 4 även ActionScript som används i Flash programmering är numera objektorienterat. Att strukturera sin kod enligt traditionella mönster är även det något som numera används inom webbprogrammering, exemple på det är MVC (läs mer kap 2.4) och three tier även kallat n tier som påminner om MVC. Att utvecklingen på webben ligger efter traditionell utveckling kan bero på webbens historia. Till en början såg man webben som ett informationsmedium och utvecklingen var då ett problem för de som skapade innehållet. Med tiden har webben gått från ett informationsmedium till en applikations plattform och samtidigt har man börjat se utvecklingen ur ett mjukvaruperspektiv (Gellersen och Gaedke, 1999). Med detta har de arbetssätt som används inom mjukvarubranschen även börjat användas i webbutveckling. Ett programspråk kan vara objekorienterat men det är inte på något sätt kopplat till någon speciell typ av struktur utan det är upp till varje utvecklare att bestämma. För att underlätta detta arbete med struktur och samtidigt undvika att uppuinna hjulet varje gång man bygger en ny applikation så Uinns det ett antal så kallade ramverk som man kan använda. ASP.NET är ett sådant ramverk, dessa ramverk hjälper utvecklaren att öka produktiviteten och återanvända sådan kod som återkommer i många applikationer. Ramverket kan hjälpa till att skapa kopplingar som behövs mellan de olika delarna i systemet. Trots att mjukvarubranschen har en Ulera års erfarenhet av dessa typer av projekt så ligger fortfarande den genomsnittliga kostnaden för underhåll av mjukvaran på 55% av mjukvarans totala livskostnad (SEPT, 2009). Två av de stora kostnaderna ligger på arbete som måste göras om p.g.a. dålig kvalité samt rent underhåll Programmeringsspråk Den här studien försöker visa skillnader mellan klassiska programspråk och de agila programspråken. Programmeringsspråk kan delas in i Ulera olika grupper, kompilerade eller tolkade, statiska eller dynamiska, hårdtypade eller löstypade och till dessa grupper kommer även begrepp som programspråk och scriptspråk. Ofta händer det att Ulera av dessa begrepp tolkas som synonymer och olika källor har olika åsikter i frågan. DeUinitionen på agila programmeringsspråk i den här studien syftar generellt till den grupp av språk som oftast räknas in i grupper så som scriptspråk, dynamiska språk och tolkade eller interpretated languages. De språk som inte räknas in i de agila språken kallas fortsättningsvis programspråk. 4

13 I den här studien kommer programspråken i första hand att syfta till Java, C#, C++, Visual Basic och de agila språken kommer att syfta till Ruby, Python, Groovy och PHP. Med de olika typerna av språk så Uinns det både fördelar och nackdelar. Fördelarna med programspråken är att de är snabbare och det beror på att de behöver färre instruktioner per kommando för att utföra samma operation (Wright och More, 2006). Likaså har de bättre minneshantering, med det inte menat att agila språk inte har detta men de tar hand om det utan att programmeraren behöver bry sig om det. Detta är ytterligare en anledning till att det är långsammare. Fördelarna med de agila språken är dels tiden det tar att programmera olika uppgifter, med dessa typer av språk går det snabbt att ändra och köra applikationen igen utan att behöva kompilera om. Dessutom är syntaxen betydligt enklare och man har plockat bort delar av koden som det annars är vanligt att man gör misstag på som t.ex. måsvingar ({}) samt att man inte behöver avsluta en rad med ett semikolon (;). När dessa språk sedan används i webbprogrammering så ger det även en fördel när man använder sig av information som sparas i webbläsaren. Vill man då göra en uppdatering i en funktion som bygger på att man går igenom Ulera steg på en webbplats så måste man med programspråken kompilera om innan uppdateringen börjar gälla. Man hamnar då Ulera steg bakåt i kedjan och testning av dessa funktioner blir tidskrävande, denna testning blir enklare när kompilering mellan varje uppdatering inte behöver göras (Rocher, 2006) Objektorienterad programmering Alla moderna språk är mer eller mindre objektorienterade, tidigare så var språken funktionsbaserade eller proceduella. Objektorienterad programmering (OOP) innebär bra möjligheter att avbilda eller modellera verkligheten på ett bra sätt (Nordqvist, 2003). Huvudbegreppen i OOP är klasser och objekt. Klasser beskriver hur objekten ser ut och vilka attribut de har. Objekten är instanser av en klasser och har sina speciella värden på sina attribut. Attributen är egenskaper som klassen har, t.ex. kan en bil ha ett attribut som heter registreringsnummer och ett annat som heter färg (se Uigur 2.1). reg nr märke färg motor Klass Objekt ABC 123 Saab gul bensin ABC 456 Volvo grön diesel ABC 789 Renault blå etanol DEF 123 Ferrari svart bensin Figur 2.1. Klasser och objekt. 5

14 Förutom att objekten har sina speciella värden på attributen så har ett objekt oftast metoder som kan ändra värdena på attributen, en bil kanske lackeras om till en annan färg o.s.v. De här metoderna leder oss till en annan del av OOP, nämligen inkappsling. Inkappsling innebär att man skiljer på gränssnitt och implementation (Nordqvist, 2003). För omvärlden är det helt ointressant att veta exakt hur man lackerar om bilen, man vill bara lämna in bilen och få tillbaka den i den färg man vill ha. På samma sätt fungerar det i OOP, för omvärlden Uinns det bara en metod som med ett logiskt namn förhoppningsvis talar om vad den gör, i övrigt vet inte omvärlden exakt vad som händer när metoden anropas. Arv kan beskrivas som om det Uinns ett visst antal egenskaper som alla bilar har, det här är då superklassen. Under superklassen Uinns det subklasser som ärver från superklassen, de kan t.ex. vara en Cabriolet subklass som har några attribut som inte alla bilar har. Subklassen har då alla attribut och metoder som superklassen har, som färg och registreringsnummer men även en del egna attribut och metoder. PolymorUism innebär att en del subklasser vill utföra en metod från superklassen på ett något speciellt sätt. Det kan vara att samtidigt som man byter färg på bilen så skaman registrera det hos biltillverkaren, har man då en metod i superklassen som heter byt_färg så döper man special metoden i subklassen till samma namn, alltså byt_färg men man implementerar den på ett annorlunda sätt. Objektorientering har en något speciell roll i webbprogrammering. I webbprogrammering är det vanligt att man använder sig av relationsdatabaser. Relationsdatabaser sparar dock inte sina poster som objekt utan som rader i en tabell. En lösning för att arbeta objektorienterat med dessa databaser är att man kopplat samman raderna i tabellerna med ett objekt. Så istället för att använda sig utav SQL frågor så anropar man de rader man vill ha genom klassmetoder och de rader man får tillbaka som resultat blir då objekt av en klass. Man kan på så sätt enkelt skapa egna metoder i klassen för att modiuiera raderna i SQL tabellen istället för att använda SQLsyntax, detta kallas Object Relational Mapping (ORM) MVC arkitektur Model View Controller (MVC) innebär en uppdelning av en mjukvara i tre lager. Modellen tar hand om statusen på applikationen, en del information ska sparas en kortare stund medan andra ska sparas en längre tid. View representerar hur informationen ska presenteras för användaren, hur layouten ska se ut mm. Controllern tar hand om användarens förfrågningar, controllern tar den informationen och ser till att rätt sak blir utförd (se Uigur 2.2, sid 7). MVC har en historia sedan slutet på 1970 talet då det första grauiska gränssnitten började se dagen ljus och Trygve Reenskaug ses som MVCs fader (Ramm, Dangoor och Sayfan 2006). 6

15 Webbläsare Controller Figur 2.2. MVC arkitektur. View Model Databas / Web service Model Modellens huvudfunktioner är de s.k. CRUD operationerna (Creat, Read, Update och Delete), alltså att skapa, läsa, uppdatera och radera data. Men i modellen brukar man även bygga in vad man kallar för Buisness Logic. I en webbshop kan det handla om att en order under ett visst värde inte innefattar fri frakt, då ingår det i modelens uppgift att se till så att applikationen håller reda på det faktum (Thomas och Hansson, 2007). View Viewn får den information den ska visa från controllern och använder sin design för att göra detta. En view kan t.ex. vara en sida som har till uppgift att presentera samtliga produkter, eller endast produkter i en viss kategori. Vilket som gäller beror på vad controllern skickar för information. Controller Controllern är spindeln i nätet och är det lager som tar hand om alla förfrågningar som kommer in. Detta kan innebära att plocka fram information från modelen för att sedan skicka den vidare till Viewn som presenterar informationen. Trots att MVC arkitekturen varit känd sedan länge inom mjukvarubranchen så var det inte där man började när man började designa webbapplikationer. Utan istället buntade man ihop all typ av kod och databas anrop kunde ske direkt från en view sida. De tidiga teknikerna som ASP (Active Server Page), PHP och ColdFusion byggde på tekniken att integrera scriptkoden och på så viss uppmuntrade detta sätt att designa. Men sedan kom JSP och Servlets från java vilket gjorde att man använde JSP som view och servlets som allt annat. Men fortfarande var det enklare att skriva kod i JSPn istället för att göra en servlet (Ramm, Dangoor och Sayfan 2006). WebObjects var ett utav de första stegen mot att använda riktigt MVC i webbramverk och på det följde Struts, båda för Java (Thomas och Hansson, 2007). I webbapplikationer fungerar MVC så att modellen oftast kopplas till en databas men kan även användas mot ett web services gränssnitt. Viewn är i de Ulesta fall en HTML sida med integrerad kod beroende på vilket språk man använder. Fördelarna med MVC ska vara att man tydligt ska separera de olika lagren ifrån varandra för att på så sätt kunna vara utbytbara utan att påverka de andra lagerna (Holovaty och Kaplan Moss, 2008). Detta ger fördelar på Ulera olika sätt, dels blir underhållet enklare när man vet var man bör hitta de 7

16 olika delarna av systemet. En ytterligare fördel av utdelningen av arbete. I den har arkitekturen kan man på ett enklare sätt dela upp arbetet mellan programmerare och designers, även de som har sin expertis inom databaser har sin del att arbeta med Programmeringsspråk och ramverk Under de tidiga åren av internet använda man sig av s.k. CGI script (common gateway interface). Det är ett protokoll som låter webbservern använda sig utav externa program för att skapa dynamiskt innehåll på webbsidor (Holovaty och Kaplan Moss, 2008). Före detta fanns det endast Uiler med HTML kod som man Uick uppdatera en efter en om man ville ändra innehållet. Detta hade sina begränsningar, bl.a. var inlärningströskeln ganska brant och det var en hel del upprepning av kod. CGI script var inget språk utan endast ett protokoll, språk som kunde användas var bl.a. Perl eller Python. Efter detta började man utveckla metoder för att på enklare sätt integrera de dynamiska funktionerna i webbuilerna istället för att hämta externa script PHP 1995 började utvecklingen av vad idag kallas PHP. Det var en utveckling av CGI scripten och tjänade till att minska kodupprepningen. PHP/FI hette det då och stod för Personal Home Page / Forms Interpreter (PHP.net) och var utvecklat i C. På detta följde PHP/FI 2.0 och efter ytterligare utveckling kommer 1998 PHP 3. Man har då byt namn till endast PHP som nu får betydelsen PHP: Hypertext Preprocessor (PHP.net). I maj 2000 kommer PHP 4 som nu har fått objekt orienterande egenskaper men det ska dröja till PHP 5 innan det blir mer användbart (Naramore et al., 2005). PHP är från början tänkt att användas just som ett script som läses från topp till botten och har ingen naturlig MVC arkitektur men har efter att Ruby on Rails släppts fått många ramverk till sitt förfogande (Golding, 2008). Detta gör att det blir extra svårt att välja ett som passar bättre än andra men eftersom de kan ha olika varianter så Uinns det vissa som påminner om varandra mer än andra. T.ex. är CakePHP ett ramverk som har stora likheter med Ruby on Rails, Fuse är ett annat som Uinns till både PHP och ColdFusion men i original utförande är utvecklat för ColdFusion, ramverk som har likheter med Javas Struts Uinns också i ett antal varianter (Web Application Component Toolkit, 2008). Vad gäller syntax så är PHP en blandning av Java, C och Perl samt några egna. Som scriptspråk har det en låg ingångströskel och man kan snabbt komma igång med att utveckla(php.net). Nackdelen är att PHP inte har en klar struktur över hur man ska använda och strukturera upp sin kod och Uiler. Det blir enkelt att man bara bygger på det och på så sättet får en struktur som är svår att underhålla och framför allt bygga på för någon annan. För att hantera externa paket har PHP ett extension interface som kallas för PHP Extentions and Application Repository (PEAR) ASP.NET Active Server Pages (ASP) var introducerat runt 1997 av Microsoft. ASP var inget språk i sig utan stod för en teknik som användes för att skapa dynamiska webbsidor. Språket som användes var Visual Basic script, VB 8

17 script. Som namnet antyder så var det det ett språk som tolkades och inte kompilerades. ASP lämnade mer att önska och den sista versionen som kom ut var version 3. Efter detta började man utveckla ASP.NET, det är igen vidareutveckling av ASP utan är en ny utveckling och är inte bakåtkompatibelt med ASP. Som namnet antyder bygger ASP.NET på Microsofts.NET plattform..net plattformen är inte bunden till ett språk utan är uppbyggt på ett speciellt sätt för att kunna hantera Ulera olika språk. Common Type System (CTS) och Common Language SpeciUications (CLS) är de grunder som alla språk inom.net måste förhålla sig till. I princip går det till så att alla typer av språk ska kompileras till så kallad Intermediate Language (IL) kod. Common Language Runtime (CLR) som är Microsofts implementation av IL just in time kompilerar sedan koden till maskinkod som operativsystemet kan tolka..net har fem stycken standardspråk som ingår i ramverket, dessa är C# (C sharp), Managed C++, Visual Basic.NET (VB.NET), J# (J sharp) och JScript.NET (Hurwitz och Liberty, 2003). Men med hjälp av CTS och CLS kan man skapa Uler språk som är kompatibla med.net. IronRuby och IronPython är två sådana exempel. Att.NET har stöd för dessa språk innebär att även ASP.NET har stöd för dessa samt alla de bibliotek som ingår.net. Att det är uppbyggt på det här visset innebär att man kan bygga en CLR för en annan plattform än Microsofts, t.ex. Unix eller Mac OS X och köra samma applikationer på dessa utan att behöva ändra källkoden, write once run anywhere. I ASP.NET använder man sig av termer som Code Behind, Code Beside och Code Inline. Code Beside är en nyare variant av Code Behind men fungerar på liknande sätt. Code inline innebär att all dynamisk kod samt HTML eller layoutkod ligger i samma dokument. Code Beside innebär istället att man använder sig av en separat Uil för att hantera all dynamisk kod. Att använda sig utav den ena eller andra har inga prestandamässiga skillnader utan de enda skillnaderna som Uinns är att att det blir lättare att underhålla, läsa och ändra (Esposito, 2005) Java Java har ett antal olika tekniker för webbprogrammering och de är i huvudsak Java Server Pages (JSP), Servlets och Applets. Applets är ett Javaprogram som är inbäddad i HTML koden på liknande sätt som man lägger in en bild i koden. Koden bäddas in i HTML koden med applet taggar, och kan använda param taggar för att skicka parametrar till programmet. För att sedan kunna exekvera koden måste man ha en webbläsare med Java teknologi som i sin tur kör koden i sin Java Virtual Machine (JVM) (Sun Microsystems, 2009a). Java Servlets API:t är en standardpåbyggnad till Java som gör det möjligt att bygga dynamiska webbapplikationer. Servlets kan liknas vid en Applet som körs på serversidan (Sun Microsystems, 2009b), Servlets har tillgång till hela Javas API inklusive Java Database Connector (JDBC) (Sun Microsystems, 2009c). JSP är en påbyggnad av Servlets och är till för att enklare skapa HTML och XML sidor. JSP gör det enklare att mixa statisk och dynamiskt innehåll (Sun Microsystems, 2009c). JSP påminner lite om PHP på det sättet att det är en blandning av HTML kod med integrerade Javakod. Skillnaden från PHP är att JSP sidan inte tolkas av webbservern utan skickas vidare till en servlet engine som bryter ut HTML koden och 9

18 kompilerar Java koden till en servlet där HTML koden läggs tillbaka som write funktioner i Java (Downey, 2007). Servlets är redan kompilerad källkod som körs av en servlet engine, Tomcat är en populär sådan men det Uinns Uler. Servlets och JSPs är de metoder som kan ansluta till en databas, Applets kan inte göra detta p.g.a. den anledningen att den körs hos klienten och är inte tillräckligt säker för att få göra det (Dr. Zhiqi, 2007). När det gäller att koppla ihop Java med en databas så har Java just där en styrka i JDBC. JDBC är ett API för Java för att kunna kontakta en databas och just antalet databaser som det Uinns stöd för i JDBC är mycket stort och det Uinns så gott som ingen databas som inte har stöd av en JDBC driver. Applets är den tredje delen av Java och är kompilerade klasser som inte har tillgång till databaser men kan användas för mer avancerade grauiska inslag på klient sidan. JSP sidor har sina fördelar i att Java script (inte att förväxlas med JavaScript) kan integreras i HTML koden. Detta leder till att det går fortare att utveckla den grauiska layouten utan att behöva använda sig utav en massa writefunktioner som skulle krävas i en Servlet. Att underhålla layouten i en Servlet är betydligt svårare än att göra det i en JSP sida. I och med den uppdelningen är det inte helt ologiskt att använda Servlets i controllers samt i kontakt med databasen och JSPs i views (Downey, 2007) Ruby on Rails Ruby on Rails är ett ramverk som bygger på det dynamiska språket Ruby utvecklat av Japanen Yukihiro Matsumoto och släpptes första gången Målet var att göra ett språk kraftfullare än Perl men mer objektorienterat än Python, resultatet blev Ruby (Thomas, 2004). Till Ruby Uinns ett ramverk kallat RubyGems. RubyGems är en standard för hur bibliotek (librarys) och tilläggsapplikationer ska paketeras för att det ska vara så enkelt som möjligt att hitta installera uppdatera och avinstallera. RubyGems har en gemensam lagringsserver där alla paket Uinns tillgängliga för det mesta men det kan även vara så att man explicit måste ange källan man vill hämta det ifrån. Innan RubyGems fanns var man tvungen att leta på nätet efter det paket (gem) man ville ha och när man väl lyckats installera det kunde det visa sig att man saknade ett paket som man var tvungen att ha för att just det paketet skulle fungera. Med RubyGems kan man be om att installera ett paket och alla paket som det i sin tur behöver (Thomas, 2004) släpptes ramverket Ruby on Rails (rails) första gången under MIT license vilket är en öppen källkods licens. Basecamp är ett projectmanagement verktyg utvecklat i Ruby och från detta projekt plockade man ut delar för att sedan skapa Ruby on Rails. Rails är ett RubyGem men har ett antal gems som också krävs för att det ska fungera, ett av dem är Active Record paketet som tar hand om mappningen till databasen (ORM). ORM innebär att man istället för att använda sig av SQLsyntax i koden för att arbeta mot databasen så använder man sig av objekt. Varje objekt motsvarar en tabell i databasen med ett antal attribut som då är kolumnerna i tabellen. Så istället för att arbeta direkt mot databasen så 10

19 arbetar man mot dessa objekten som har en del fördeuinerade metoder för t.ex. skapa, läsa, uppdatera och radera (CRUD) men även metoder för att söka efter objekt. Mappningen följer en av Rails grundstenar convention over con*iguration, alltså konventioner framför konuiguration (Geer, 2006). Detta innebär att skapar du ett objekt som heter week så skapas det efter det en tabell i databasen som heter weeks. Rails har bra stöd för detta och stöder inte bara regelbundna substantiv utan även oregelbundna som person och people. Man kan även skapa egna regler om man t.ex. vill använda svenska ord. Att det fungerar så här innebär att man slipper en massa konuiguration om vilken tabell som hör till vilket objekt och vilken kolumn som hör till respektive attribut. Andra egenskaper som Rails använder sig av är generatorer och scaffolding. Generatorer innebär att skelett för olika typer av Uiler i applikationen skapas och lägger sig på rätt plats, t.ex. controllers och objekt där man kan välja vilka metoder man kan behöva för controllern och vilka attribut man vill ha på objektet och vilken typ de ska vara. Scaffolding är en annan typ av generator där man kan välja att göra en scaffold av ett objekt och då skapas ett helt grauiskt gränssnitt med alla CRUD operationer och ett index över alla objekt i objektets motsvarande tabell. Funktioner som man i de Ulesta fall använder sig av i databasdrivna webbapplikationer. Förutom convention over con*iguration så använder sig Rails av Don t Repeat Yourself (DRY), vilket innebär att ramverket eftersträvar att man så långt det går inte ska behöva upprepa kod Groovy and Grails Groovy är vad man kallar ett dynamiskt språk utvecklat för att kunna användas i Java miljö. Det skiljer sig dock på en väsentlig punkt från andra och det är att det faktisk kompileras ner till bytecode och sedan exekveras. Det beter sig i sin natur precis som Ruby eller Python men det tolkas inte utan kompileras. Detta märker man inte av av den anledningen att det fungerar som ett scriptspråk men mer viktigt är att veta att en Groovy class är en Java klass och de kan på så vis arbeta med varandra. En Java klass kan alltså använda sig av metoder i ett interface som är implementerat av Groovy utan att märka någon skillnad (Rocher, 2006). Eftersom Groovy är så nära integrerat med Java så drar Groovy samma fördelar från JDBC som Java gör. Även alla bibliotek (librarys) som Uinns tillgängliga för Java är även tillgängliga för Groovy och det Uinns en hel del och oftast Ulera för samma uppgift och mer parten av dessa är öppen källkod (open source). (Rocher, 2006) Groovy släpptes första gången sommaren 2005 och ses som ett svar på Java implementationerna av Ruby och Python som kallas JRuby och Jython. Detta är scriptspråk som i princip fungerar som i originalutförande men har fördelen av att kunna köras på en Java Virtuell Machine (JVM). Det är en stor fördel med tanke på alla de installationer som Uinns av JVMs och att byta ut hela sitt system bara för att byta plattform är kostsamt (Bini, 2007). Integrated Development Environment (IDE) är något som är populärt i Java miljön och Eclipse är en av de populäraste, Microsoft har sin Visual Studio för att nämna några. IDE innebär en textredigerare, kompilerare och en 11

20 debugger. Utrycket Edit Compile Run är välkänt för Java utvecklare och innebär att man först redigerar sin kod, kompilerar den för att sedan köra applikationen (Dr. Zhiqi, 2007). Att ha allt detta samlat i ett utvecklings verktyg gör förfarandet snabbare än om man skulle ha olika delar för de olika stegen. En anledning för att inte byta plattform från Java är att det saknas bra IDE för andra språk och i detta fallet speciellt för Ruby on Rails. Med Groovy and Grails är det möjligt att jobba vidare i Eclipse eftersom det Uinns en groovy plug in och förutom möjligheten att jobba med Groovy kan man köra Grails ifrån Eclipse (Rocher, 2006) Python, Django och TurboGears Python släpptes första gången redan 1989 och var då utvecklat av Guido Van Rossum (Agarwal och Agarwal, 2005). Pythons har liksom Ruby ett system för att enkelt installera och uppdatera externa paket, i Pythons fall heter det easy_install. Python har till skillnad från Ruby ett Ulertal olika ramverk som utvecklare använder. Två utav dem som påminner mycket om Ruby on Rails är Django och TurboGears. Django är ursprungligen utvecklat för artikelpublicering för nyhetstidningar. Det är alltså precis som Ruby on Rails skapat efter ett verkligt projekt. Man utvecklade alltså ramverket för att man verkligen behövde det och såg det som ett sätt att underlätta framtida projekt (Holovaty och Kaplan Moss, 2008). Funktionerna i Rails, Grails, Django och TurboGears är ganska lika och ramverken har bara valt att implementera dem på olika sätt och tolkat MVCarkitekturen på lite olika sätt vilket är beskrivet tidigare. En funktion som dock är unik för Django är ett automatiskt genererat administrationsgränssnitt med enklare inloggningsfunktioner. Man kan sedan välja vilka objekt som ska ingå i gränssnittet. Med andra ord lämpar sig Django väl för olika typer av publiceringsapplikationer vilket dess ursprung även talar för. Även speciuikt för Django är att man har speciella datatyper för e post adresser och URL (Uniform Resource Locator) adresser. Ett känt begrepp inom Python programmering är Pythonic. Det är ett karakteristiskt sätt för hur Python och dess bibliotek används (Ramm, Dangoor och Sayfan, 2006). Detta sätt att använda koden som påminner om en UilosoUi och sträcker sig utanför standardbiblioteken och går även att känna av i många tredjepartsbibliotek. Tim Peters har formulerat detta i The Zen of Python (Appendix B). TurboGears har även försökt fånga denna UilosoUi så långt det är möjligt. Man har även tagit hänsyn till förfrågningar på webben, vilket gör att de ser ut som standardmetoder när de väl når koden i applikationen (Ramm, Dangoor och Sayfan, 2006) ColdFusion ColdFusion har haft många turer genom åren från olika bolag utvecklade Alaire Corporation första versionen. Alaire blev uppköpt av Macromedia och ColdFusion MX utvecklades (Churvis et al., 2003). Efter detta köptes Macromedia upp av Adobe som nu utvecklar och under håller 12