C3 - API
Jag har hämtat data från Google Books API och gjort en sida där det går att söka fram böcker baserat på förslag på genrer eller genom en egen sökning.
Se projektet här
Länk till repository på Github här
C2 - Spel
Min spelidé bygger på de klassiska spelen som kallas för "breakout games", som går ut på att krossa brickor med en boll. Jag ville göra en variant på den typen av spel där själva idén är att en pingvin är instängd i en gruva och ska försöka ta sig ut genom att slå sönder stenblock. Spelets målgrupp är framförallt barn och tanken är att de genom spelet kan lära sig precision och snabbhet.
Jag har använt mig av spelramverket Phaser för att bygga spelet, det var en rolig utmaning och kändes relativt lättsamt. Eftersom Phaser använder sig av Canvas så kändes det även nyttigt att få mer förståelse för hur det fungerar.
Det finns mycket som skulle vara kul att utveckla i framtiden på spelet. Jag skulle vilja lägga in olika svårighetsgrader/nivåer, en tidsbegränsning för att klara varje nivå och fler olika typer av "brickor" som ger olika mycket poäng när de krossas.
Se projektet här.
C1 - Todo-applikation
Nu har jag gjort min första riktiga applikation i form av en att göra-lista. Den var en perfekt uppgift för mig för att bli säkrare på att manipulera html-DOM:en med JavaScript. Jag är nöjd med resultatet men det vore roligt att utveckla den vidare i framtiden och till exempel bygga in att uppgifterna som användaren lägger in sparas i webbläsaren.
Stina provade min app och gav mig feedback på att det inte var så självklart hur man ska göra för att spara ändringarna när man har redigerat en uppgift. Jag löste det genom att ändra-knappen får en "ok"-symbol istället för en penna när man är i redigeringsläget. En annan sak jag fick feedback på var att om man markerar en uppgift som klar i redigeringsläge så flyttas den till de klara uppgifterna i det läget. Det löste jag genom att lägga till en if-sats som tar bort redigeringsläget när uppgiften markeras som klar.
Se projektet här.
B5 - Infografik
Jag har gjort en infografik som ska informera om klimathotet på ett lättsamt sätt. Grafiken är uppbyggd av tre olika frågor som besvaras i text och bild.
De interaktiva elementen har jag lagt till med jQuery, JavaScript och använt mig av ramverket wow.js.
Se skissen här.
Se projektet här.
Länk till repository på Github här.
B3/B4 - projektet Benefix
Jag och min grupp har skapat en hemsida för vårt fiktiva företag Benefix. Här är en reflektion över arbetet med projektet.
Se slutresultatet här.
Det har varit ett väldigt roligt projekt som började med ett fysiskt möte som en “kick off” och för att bolla idéer och diskutera hur vi skulle lägga upp arbetet.
Vi jobbade sedan mycket utifrån att alla bidrog med förslag, skisser etc som vi sedan röstade om eller diskuterade fram vilket som vi skulle gå vidare med. Som helhet så känner jag att jag har kunnat bidra i de flesta moment under projektet, till exempel med designidéer, grafisk profil och en hel del med det faktiska kodandet av webbplatserna. Vi delade upp arbetet så att vi kodande varsin sektion på webbsidan och att man ansvarade för samma sektion både i B3 och B4. Vi valde en rätt enkel design för vår webbsida där fokus ligger på att få fram vårt företags budskap och att visa tidigare projekt. Vi vill att vårt företags budskap ska gå fram direkt till användaren och därför har vi en tydlig text om det på landingssidan och en bakgrundsbild som ytterligare ska kommunicera och förstärka buskapet. Vi bestämde oss för att bygga webbsidan som en scroll-sida där allt innehåll finns i en och samma html-fil. Det beslutet tog vi för att vi ville prova att bygga på det sättet och att det går lite trend i att bygga webbsidor på det sättet just nu. Det blir även mer flexibelt för en användare eftersom man kan välja om man vill scrolla eller navigera genom menyn. Vi valde en enkel logotyp som tydligt visar att det är utveckling vi sysslar med, och vi definierade tre stycken färger som används på webbsidan i de olika sektionerna, som en färgkodning som gör det extra tydligt för användaren.
Att arbeta utifrån scrum har varit intressant och lärorikt, det har däremot varit lite svårt att verkligen gå in i sin roll som Scrum master eller Product owner och det tror jag beror mycket på att vi arbetar på distans. Ses man varje dag på en arbetsplats så tror jag det är mycket lättare att upprätthålla en struktur med dagliga scrum-möten och de olika rollerna. I vår grupp delade vi upp det så att två stycken var Scrum master och två stycken var Product owner, så att alla skulle få prova på att vara någon av de rollerna och det tycker jag har fungerat, även om det inte är så man vanligtvis gör ute i arbetslivet. Vi skapade en “daily scrum”-kanal i Slack där vi har skrivit nästan varje dag om hur det går för oss och vad vi ska göra under dagen till exempel, och vi har även haft “Sprint planning” varje vecka i Slack vilket har fungerat bra.
Arbetet har varit relativt problemfritt och flytit på bra, vi har haft ett bra samarbete i gruppen och en tät och bra kommunikation. När vi har stött på problem med koden så har vi diskuterat det för att komma fram till lösning och hjälpt varandra när det är något vi inte har förstått.
Det som jag känner att jag lärt mig allra mest om under projektets gång är versionshantering. Jag har blivit säkrare på Git och att använda terminalen för versionshanteringen. Att hantera merge-konflikter, branches/grenar och skapa pull requests är ett par exempel på sånt som jag blivit säkrare på under det här arbetet.
En annan viktig lärdom är hur det är att jobba med ramverk. Det kunde jag ingenting om innan det här projektet och nu känner jag att jag har relativt bra koll på Bootstrap, hur man använder det och vad man kan uppnå med det. Det har varit bra att se skillnaden på att använda sig av ramverk jämfört med att inte göra det. Jag kan se fördelar och nackdelar med båda. Det kan vara otroligt skönt att använda ett ramverk för att bygga saker snabbt, men det kan även bli komplicerat att anpassa css:en så att det blir precis som man vill ha det. Ifall man vill uppnå ett väldigt specifikt resultat för till exempel en komponent, som skiljer sig från det ett ramverk erbjuder, så känns det som att det kan vara lättare att bygga det från grunden utan ramverk.
En erfarenhet av att jobba i projekt och utveckla en webbsida tillsammans är också att det är en utmaning att skriva koden så enkel som möjligt, det blir lätt mycket upprepande kod så en lärdom är att det är bra att diskutera igenom till exempel vilken generell css man kan lägga in som ska gälla för hela sidan innan man börjar ge alla element en specifik styling.
B2 - CSS Zengarden
Jag ville få till en "röd tråd" genom hela designen och därför återkommer samma färger i både bakgrunder och text, och jag har använt mig av tre olika teckensnitt; två för rubriker och ett för brödtext.
Jag har gjort rubriker större, brödtext mindre och storleksordnat efter ordningen texterna "ska" läsas i, för att det ska bli så lättläst som möjligt. Jag separerade huvudinnehållet från sidoparagraferna för att ytterligare öka läsbarheten så att användaren förstår vilka element som hör ihop och bör läsas efter varandra.
För att få in mer dynamik i designen så har jag lagt till bilder och de går i samma stil och färg för att de inte ska ge ett rörigt intryck.
Se skissen här.
Se slutresultatet här.
Länk till repository på Github här.
B1 - HTML-struktur
Titta på min webbsida om äppelkaka här.
A3 - Yrkesrollen frontendutvecklare
Vad innebär det i praktiken att arbeta som frontendutvecklare, mer än att bygga upp det vi ser och interagerar med på en skärm med hjälp av kod? det är inte helt okomplext att svara på för en nybörjare som jag som precis påbörjat min bana till en karriär inom yrket.
För att komma närmare svaret vill jag först titta närmare på termen webbdesign och vad den innebär. Webbdesign är ett brett begrepp som spänner över allt från färglära till HTML (som står för HyperText Markup Language och utgör strukturen för webbsidor). Olika företag kan alla söka efter en webbdesigner men det kan skifta vad den rollen egentligen innebär på det specifika företaget. Det kan även skifta hur rollen benämns; den kan kallas Frontend-designer eller User experience designer lika gärna som det föregående.
Webbdesigner-rollen kan ta olika inriktningar, ibland mer fokuserad på design och ibland mer fokuserad på den tekniska aspekten. På designsidan behövs det kunskaper inom till exempel färglära, typografi och användarens interaktion med webben. På tekniksidan är det framförallt teknikerna HTML, CSS, som står för Cascading Style Sheets och beskriver hur innehållet på en sida ska presenteras, och JavaScript som är viktiga. Det sistnämnda är ett programmeringsspråk som gör det möjligt att utveckla dynamiska webbsidor som användaren kan interagera med.
Gemensamt för både den teknikfokuserade och den designinriktade är att det i dagens läge är viktigt med ett “know how” kring responsiv design. Begreppet Responsiv design myntades enligt Google av Ethan Marcotte och innebär webbdesign som tillåter layouten att förändras beroende på vilken skärmstorlek och upplösning som används. Till exempel; på en telefon kan användaren se innehåll i endast en kolumn, men en surfplatta kan visa samma innehåll i två kolumner.
Webbutveckling är precis som webbdesign ett brett begrepp, det finns dock två huvudinriktningar; Frontend och Backend. Frontendutvecklare arbetar mot klient-sidan (webbläsaren), alltså det som användaren ser och interagerar med. Backendutvecklare arbetar istället mot server-sidan som är det bakomliggande som tar emot anrop från klient-sidan. För att bli framgångsrik som frontendutvecklare behövs kunskaper inom tidigare nämnda HTML, CSS och javaScript. För backend krävs kunskaper inom programmeringsspråk som exempelvis Python, Ruby eller PHP.
Vad är det då för skillnad på en webbdesigner och en webbutvecklare? ja, vissa företag vet nog knappt själva när de lägger ut sina jobbannonser. Ibland kan en utannonserad tjänst som webbdesigner faktiskt innebära mestadels utveckling. Det man kan säga är iallafall att den som benämns som en webbdesigner vanligtvis inte jobbar med backend-programmering, men kan mycket väl arbeta dagligen med frontend-teknikerna.
För att ta reda på mer om vad yrkesrollen som frontendutvecklare kan innebära tog jag mig till min förra arbetsplats Fyndiq. Det är ett e-handelsföretag som precis har fyllt fem år. Fyndiq har över en halv miljon produkter ute till försäljning i olika kategorier som Mode, Elektronik och Mobiltillbehör. De är nu över hundra anställda och satsar mycket på att anställa just utvecklare. Jag träffade Daniel Hååg som jobbat som frontendutvecklare i tre år, varav ungefär halva tiden på Fyndiq.
Tidigare bestod Daniels team av ett frontend- och ett backend-team, men nu håller strukturen på att göras om. Teamet har delats upp i mindre team som arbetar mot ett specifikt område eller avdelning. Daniel tillhör User Experience-teamet som fokuserar på användarupplevelsen av butiken på både desktop- och mobilversionen av Fyndiqs sajt. Daniels team består av två frontendutvecklare, två backendutvecklare och en Product Manager som sköter kontakten mellan avdelningarna och utvecklarna och även är den som bestämmer prioriteringen av arbetsuppgifterna.
Även om alla frontendutvecklare inte kommer tillhöra samma team längre så vill Daniel poängtera att frontend-kollegorna fortfarande kommer att samarbeta, diskutera, kunskapsöverföra och hjälpa varandra i arbetet. Vad som ska fokuseras på och är prioriterat att arbeta på är mycket beroende av vad företaget har för mål uppsatta under den specifika tidsperioden. Ett exempel är att det under förra julhandeln satsades mycket på att bygga upp en avdelning för “presenttips” på desktopversionen för att öka försäljningen under den viktiga julperioden.
Jag frågar om hur samarbete och kommunikation med backendutvecklarna ser ut och får svaret att saker i vissa fall kan lösas helt på frontend-sidan men att det ibland kan behövas exempelvis en viss datastruktur, alltså att datan ska organiseras på ett visst sätt. Det behöver då diskuteras med backendutvecklarna. Även idéer bör diskuteras, men enligt Daniel beror det mycket på projektets storlek och omfattning hur mycket kontakt som behövs mellan backend- och frontendutvecklarna.
Kommunikationen ur ett bredare perspektiv sker annars mycket med Product Managern, men dialogen med marknadsteamet är även tajt eftersom det allt som oftast är de som kommer med förslag och önskemål om ändringar som ska göras i det som användaren ser och interagerar med på sajten.
Under intervjun djupdyker vi en del i de tekniker och ramverk som används i arbetet, som hjälpt till att bygga upp Fyndiqs sajt. Desktop- och mobilsidan är olika frontend-projekt men de bygger på samma backend. Mobilsidan är byggd i Backbone.js som är ett JavaScript-bibliotek. Backbone innehåller olika komponenter som vyer och modeller som hjälper till att ge struktur åt webbsidor. De har även använt ett ramverk som heter Marionette vilket är som ett extra lager på Backbone för extra funktionalitet. För arbetet med CSS-koden används Less, som är en CSS pre-processor och innebär att det utökar CSS-språket och lägger till funktioner som tillåter utvecklaren att göra CSS som är lättare att underhålla och strukturera.
För mobilsidan körs en så kallad Single Page Application som är en webbapplikation eller webbsida som laddar en enda HTML-sida och dynamiskt uppdaterar den sidan när användaren interagerar med den. För desktop används jQuery som även det är ett bibliotek för JavaScript och innehåller funktioner som förenklar och ger flexibilitet, och koden är anpassad för att fungera i de mest använda webbläsarna. Enligt Daniel var det mer standard att använda jQuery en tid tillbaka, idag är webbläsarna så pass moderna och fungerar så pass bra att det inte finns ett lika stort behov av det menar han.
Jag är nyfiken på om de ofta lägger ned tid på projekt som blir ett misslyckande eller som det inte blir något av i slutändan. “Vi lanserar lite kod ofta istället för mycket kod sällan, på det viset vet man mycket lättare vilken kod som är fel ifall det upptäcks att man lanserat en felaktig eller buggig kod”, svarar Daniel. De har även som rutin att köra en “code review” - vilket menas att en annan frontendutvecklare alltid går igenom och godkänner den kod man jobbat med innan lansering, för att få fler ögon på koden och kunna upptäcka eventuella fel lättare.
För att återknyta till min tidigare diskussion om webbdesign frågade jag Daniel hur mycket han får vara med och bestämma om själva designen för sajten och om han han har något specifikt ansvar för den biten. Daniel säger att han själv inte är någon designer men att man lär sig av alla projekt och de erfarenheter som kommer med dem. Han har genom erfarenheter fått det “designiga” tänket och vet hur saker kan göras på ett bra och logiskt sätt, vad som är standard och så vidare. Men att till exempel göra prototyper på hur webbsidor ska se ut är inte något som ingår i hans arbete på Fyndiq. Slutsatsen jag kan dra är att man inte behöver vara “en designer” för att arbeta med frontend men det är i många fall och beroende på var man jobbar en fördel att ha kunskap om design och framförallt vad som är bra logik och standard inom branschen när man bygger webbsidor.
Lite samma sak kan egentligen sägas om hur mycket man behöver vara insatt i backendutveckling som frontendutvecklare. Daniel säger att det kan bero mycket på hur företagsstrukturen ser ut där man jobbar. På Fyndiq behöver man inte vara insatt i backendutveckling på så sätt att man arbetar i själva backend-koden, men det krävs ändå en viss kunskap om hur det fungerar, det underlättar jobbet helt enkelt.
När Daniel får spåna om hur han skulle säga att yrket Frontendutvecklare har utvecklats sedan han började jobba inom det säger han att det har gått från att man utvecklar allt med själva grundspråket till att mer och mer använda olika ramverk. Frontend har även blivit tyngre och populärare, och man vill lägga mer av beräkningarna på frontend-sidan. Även tidigare nämnda Responsivt har slagit igenom och Single page-appar, som Fyndiqs mobilsajt exempelvis, har kommit stort. Daniel tycker att det är svårt att sia om framtiden för frontend-yrket som helhet, men hans tankar går till de standarder och tekniker som möjligtvis kommer att slå igenom eller dö ut. Coffeescript och Typescript, som är programmeringsspråk som kompileras till JavaScript, tror han inte har en framtid. “Lär man sig bara dem kan det bli svårt för att man inte lärt sig grundspråket” säger han. En standard för JavaScript som han däremot tror kommer att slå igenom heter Ecmascript 6, den kommer att stödjas av fler webbläsare än vad den gör idag. Kanske finns det rentav språk som kommer ersätta javaScript helt? Daniel vill inte uttala sig i detalj om det men ett som är säkert är att i stort sett vad som helst kan hända. Idag finns det många olika standarder och ramverk och en tanke jag själv har är att det i framtiden kanske kommer att bli mer standardiserat vilka tekniker som används.
Nåväl, vad som händer i framtiden får just framtiden utvisa. För egen del har jag fullt upp med att få kunskap om hur frontendyrket ser ut just idag i en nära framtid, men Daniel har lyckats ge mig en klarare bild av hur vardagen kan se ut för en frontendutvecklare på ett e-handelsföretag. Det har gjort mig ännu mer inspirerad att ge mig in i vad branschen har att erbjuda, idag och i framtiden.
Källor som inte nämnts i artikeln:
http://teamtreehouse.com/tracks/digital-literacy
https://teamtreehouse.com/library/careers-foundations/careers-in-the-tech-industry/
A2 - Webben om 5 år
Jag tror att webben kommer att ta stora kliv framåt och förändras under kommande åren eftersom utvecklingen går så otroligt snabbt redan idag. Responsivt är ju ett viktigt begrepp idag men jag tror att det kommer att bli ännu mer “obligatoriskt” på webben i takt med att användandet av mobiler, surfplattor och andra enheter ökar och det kommer nya typer av enheter och plattformar att använda webben på. Jag tror också att app-industrin kommer att växa ännu mer och att i stort sett alla företag kommer ha någon slags app kopplad till sin verksamhet, och det kommer att bli ännu mer orienterat kring att göra sina tjänster så enkla som möjligt för kunderna.
Idag använder vi ju webben till allt möjligt och kan till exempel göra många av våra vardagsärenden där, som att handla mat och boka tid hos optikern. Jag tror att företag kommer att satsa mer på att ha sina tjänster helt och hållet på webben i framtiden. Kanske kommer det att bli helt naturligt att till exempel ta ett möte med sin bank direkt över internet. Den typen av tjänster är såklart bekväma men det finns även en risk att människor blir mer distanserade från varandra och att kommunikationen blir lite sämre när man inte träffas “face to face”.
Jag tror också att gränssnitten för webben och utrustningen kring den kommer att förändras mycket, till exempel att det går mer och mer mot att bli helt touch-baserat med touch screen-lösningar även för desktop. Det kommer nog även att komma fler nya plattformar för webben med bra interaktionsdesign. Kanske kommer man till exempel att kunna surfa direkt i en touchskärm inbyggd i bordet när man sitter på café eller på en buss.
Webben kommer att spridas till fler människor i världen kommande åren och då blir det säkert mer och mer självklart för fler att använda webben i syfte att vara social med de man känner och även för att nätverka och knyta nya kontakter. Det blir en självklarhet för fler människor att alltid vara närvarande på webben, men samtidigt så kommer nog en del att ta avstånd från det och gå tillbaka till en mer “nedkopplad” vardag för att få tid till annat i livet.