Redovisning av kursmoment i kursen javascript1

Kmom01

Jag använder samma utvecklingsmiljö som jag tidigare använt. Det är samma miljö som jag använder för mina hobbyprojekt men jag har blivit tvungen att skilja dessa åt då eran validation inte stämmer med hur jag brukar skriva. Som tur var var det bara att ändra inställningar i Prettier så kan jag skriva som en schimpans och det rättas till automatiskt. Prettier är en tilläggsmodul för Visual Studio Code som jag använder som min text editor.

Jag skulle vilja påstå att jag är rätt så välbekant med HTML och CSS. Jag har för det mesta även börjat gå ifrån det och använder numer React eller Vue. Jag tycker både React och Vue är bra men känner mig nog mest hemma med React. I React skrivs allt i “javascript” och kompileras sedan ner till HTML, CSS och JS.

Jag valde att använda JSFiddle och jag tyckte det gick bra. Det känns inte som att det faktiskt är tänkt att man ska stoppa in en hel sida där. Känns mer som att man det är till för att testa olika moduler som man hade tänkt att använda på sin sida. Då kan man i exempelvis JSFiddle ta fram en fungerande bas att jobba vidare på eller debugga någo som redan finns.

Det gick finfint att komma igång min utvecklingsmiljö var lätt att ställa in för att fungera tillsammans med dbwebb validerings inställningar. Jag är inte helt överens med de inställningarna men jag behöver knappt bry mig då Prettier fixar till koden så fort filen sparas. Jag har petat en del på de verktyg som används och visades upp. Jag kan dock tycka att det var många olika verktyg som visades upp. Jag gillar inte att behöva kopiera in kod i JSHint, skulle hellre sett att man installerade något ordentligt som sköter sådant automatiskt när man exempelvis sparar en fil eller upptäcker i editorn medans man skriver.

TIL: Min tro på att aldrig skriva ren HTML eller CSS och använda bibliotek såsom React eller Vue för att skapa sidor istället har stärkts.

http://www.student.bth.se/~rasb14/dbwebb-kurser/javascript1/me

Kmom02

Jag har faktiskt programmerat en del i javascript, de språk jag har störst färdighet med är JS och C#. Dessa två språk är ganska lika C# är dock en hel del striktare och måste kompileras till binära filer innan programmet går att köra. Syntaxen i dessa två språk är väldigt lika vilket gör det enklare att hoppa mellan dessa. Jag har fortfarande råkat försöka använda sådant som är standard i C# när jag skriver javascript och vice versa.

Jag vet inte om jag tyckte att något i detta kursmoment var särskilt svårt. Flaggorna var lite dryga men jag kämpade igenom dem. Jag hade också problem med min matte när jag försökte få min unit/div att stanna i content. Jag vände några variabler så att den mest teleporterade runt när man försökte flytta sig. Det var i if-satserna i slutet av eventHandlern som jag använde left istället för top på något ställe och allt blev konstigt.

Jag tror att det som tog mest tid vat flaggorna. Det var mycket css för så lite. Jag bestämde direkt för att använda flexboxes för att lösa den uppgiften. Sen var det bara att tugga på och se till att css:en fungerade som tänkt.

TIL: Jag har faktiskt lärt mig lite mer om vad man kan ändra på ett htmlobjet ifrån javascript.

http://www.student.bth.se/~rasb14/dbwebb-kurser/javascript1/me

Kmom03

Det är inget konstigt med funktioner, det är ett kodblock som kan anropas från en annan bit av kod för att utföra något. Att tänka sig kod utan funktioner får man ont i huvudet av. Du slipper med funktioner en massa duplicerad kod och du kan dela upp koden i block som löser specifika problem och kan anropas från anna kod. Detta gör koden hanterbar och enklare att underhålla. Funktioner kan jämföras med metoder i C# (de är i princip samma).

Jag tycker att sandbox steg 3 var den roligaste uppgiften. Det var den som det kändes mest att jag kunde visa vad jag kan. Jag kunde skriva kod som jag gillar och blev nöjd med. Jag gillar dock inte att ha en blankrad efter en variabeldeklaration. Jag vill kunna skapa en variabel precis ovanför en for-loop, då ser jag direkt att den variabeln hör till for-loopen. Om en variabel inte används endast inom det inre scopet så håller jag helt med men i vissa fall skulle jag önska att inte ha blankrad efter variabler.

Jag gillade inte uppgiften med flaggorna den var mest dryg och irriterande. Det finns bättre sätt att åstadkomma samma resultat än det som visades i videon och i texten.

TIL: Fler av JavaScripts inbyggda funktioner börjar fastna i skallen.

http://www.student.bth.se/~rasb14/dbwebb-kurser/javascript1/me

Kmom04

Jag har koll på objekt och arrayer sedan tidigare. De är väldigt lika C# även om du i C# måste definiera din a objekt och inte kan lägga till egenskaper hur som helst som du kan i javascript. En array i C# kan heller inte expandera efteråt som en javascript array kan. Vill du ha den funktionen får du i C# istället använda en lista. För mig är en javascript array mer likt en lista. Jag gillar det dock då det blir mer “dynamiskt”. Samma gäller objekten, det kan vara lite jobbigt att man inte vet exakt vad ett objekt innehåller. Så kan det dock vara i C# också men oftast har du en objekt definition att luta dig på.

Jag tycker att uppgiften med flaggorna var bättre i detta kmom då man kan använda arrayer och enumrering för att generera flaggor. Jag gjorde detta med de randiga flaggorna. Du får från “basobjektet” en init funktion som tar ett html element, en flaggtyp och en eller fler färger, du kan då loopa igenom färgerna och skapa ett element med bakgrundsfärgen i din flagga. Något liknande hade säkert gått att göra med den svenska flaggan men det hade blivit orimligt mycket parametrar så jag hoppade det.

TIL: Använda fler av inbyggda funktioner för arrayer.

http://www.student.bth.se/~rasb14/dbwebb-kurser/javascript1/me

Kmom05

Jag tyckte att uppgiften till en början var rätt kul. Efter att ha gjort ca hälften av kraven började jag tröttna lite. Det kändes lite som att allt var samma och det blev lite tjatigt. Det var egentligen inte mycket som var svårt det var bara att ha sin matte på plats och att ta reda på vad alla inbyggda funktioner heter och vad dem gör. Det var en sak jag märkte och det var att ett element har ingen bredd före det att man “appendat” det. Det ställde till det lite för mig. Bland annat blev matten fel och saker hamnade utanför webbläsarfönstret o.s.v.

Den sista uppgiften gör att elementen börjar “dansa”, dem darrar lite. Du får valda element att dans genom att klicka på ‘f’. Ju fler gånger i rad du klickar ‘f’ desto hårdare dansar elementen. Det som händer i bakgrunden är att det 20 gånger per sekund slumpas fram en punkt på ett rutnät {-10, -10} - {10, 10} och elementet flyttar sig så mycket som beskrivs av punkten. Detta pågår under 5 sekunder.

Jag kollade inte på någon video så kan inte uttala mig om dem tyvärr.

TIL: Jag har fått lite bättre koll på vad de stora ramverken som React eller Vue troligtvis gör i bakgrunden.

http://www.student.bth.se/~rasb14/dbwebb-kurser/javascript1/me

Kmom06

Jag tycker inte att det var knepigt att förstå scopes och closures. Jag har skrivit javascript en del på min fritid, jag tror att det har gjort det lättare för mig att förstå det som denna kurs tar upp. Det fungerar nästan lika som i c/c++ eller C#. Jag kände igen mig rätt mycket när jag skummade igenom litteraturen och dem berättade om skillnaderna. Jag tror det syns tydligt i min kod att jag skriver lite mer likt en C# programmerare. Jag kan därför tycka att det är jobbigt när man inte direkt vid funktions definitionen inte ser om den är privat eller inte. Jag måste istället kolla på vad som exponeras via return.

Jag har jobbat med design mönster tidigare även om jag i viss grad inte har koll på allt. Det märks tydligt om man skriver c++ att det behövs annars blir det lätt kaos och spaghetti av allt. Just module patterns känns väldigt lika klasser och namespaces i C# och c++. Det är tycker jag ett bra sätt att dela upp sin kod. Jag tycker av det jag gjort hittills att module patterns känns väldigt statiska. Det står dock i kurslitteraturen att man kan skapa instanser av moduler men jag testade aldrig.

I min kod så hade det kanske kunnat användas till att bara slänga statet för spelet när en omgång var klar. Nu har jag istället en reset på det mesta som återställer statet. Det hade säkert gått att skapa “klasser “ för det iställer. En helt anna sak jag reagerade på var att spel logiken var i den “klass” som hade med grafik att göra, det brukar vara ett “big no no”. Jag hade velat lägga all logik för spelet i en modul utanför Hangman. Jag visste inte om det skulle vara okej så jag la istället mer logik i main. De funktioner som krävdes på Hangman ska ändå fortfarande vara där.

Jag vet inte om jag kan säga så mycket om boken, jag skummade mest igenom den och läste lite mer noga om jag såg något nytt eller intressant. Det jag läste var dock mycket lärorikt.

TIL: Bakgrunden till vad som i dag är klasser och hur de relaterar till att få en bättre kodstruktur i javascript. Äv för och nackdelar av att jobba med module patterns.

http://www.student.bth.se/~rasb14/dbwebb-kurser/javascript1/me

Kmom07-10

Jag började med deltestet tipsfrågor eller quiz. Medans jag skrev koden för quizet så såg jag till att ta fram ett API för hur Test modulen skall anropa de olika deltesten. Jag såg också till att det fanns funktioner som hade hand om olika saker så att det i alla deltest finns funktioner för att rendera element, initiera testet, var som sker när testet är klart och eventhanterare.

Quiz

Quizet hämtar frågor från en json fil på servern. Den använder sedan den datan för att kapa element för alla frågor och svar och rendera dem rätt. För varje svar får det elementet ett extra attribut som pekar på indexet för frågan i den bakomliggande arrayen. När ett svar blir klickat på så hämtas rätt svar met hjälp av indexet och om svaret är rätt så markeras det på objektet i arrayen. Det syns också direkt på sidan om man gissat rätt eller inte. Är man nöjd med sina svar klickar man på ‘Next’ knappen. Antalet rätt frågor delas då med det totala antalet frågor vilket ger ett normaliserat värde för quizet. Det normaliserade värdet returneras sedan tillbaka till Test modulen med hjälp av en callback.

Fizz Buzz

När Fizz Buzz deltestet initieras genereras en lista av nummer och en lista med möjliga svar. Nummer listan konverteras sedan till en Fizz Buzz sträng och den korrekta svaret blandas in i listan av möjliga svar. I svars listan kontrolleras även att samma tal inte kan förekomma mer än en gång. Jag tyckte det såg konstigt ut när samma tal fanns fler gånger. När man gissat på en siffra så syns det direkt om det var rätt eller inte. Jag hade kunnat tänka mig att ha fler Fizz Buzz sekvenser att gissa på för som det blev nu kan detta test endast returnera de normaliserade värdena 0 eller 1. Detta gör att Fizz Buzz testet påverkar totalen mer än andra test.

Memory

Minnes testet. Det svåraste enligt mig (inte att skriva kod för utan att genomföra på sidan). Här bestämde jag mig också för att läsa konfiguration från en json fil på servern. Mest för att slippa skriva massa extra kod. Detta deltest gjorde att jag behövde tänka om lite i min modell för hur en testmodul skulle fungera. Jag blev tvungen att lägga till informationsblad i testen. Jag tänker nu i efterhand att det hade vart riktigt smidigt med en egen modul för det. Hade jag haft mer tid eller gjort detta igen så hade jag nog gjort så. Det blev rätt rörigt i koden när jag inte gjorde så. Men generering av flaggor blev en egen modul. Det var smidigt för då kunde jag bara anropa den modulen och skicka med en callback och få ett flagg element tillbaka som om man klickade på det anropade callback funktionen. Callback funktionen ligger i Memory modulen som har koll på vilken flagga som är nästa och om det är tillåtet att klicka o.s.v så den har koll på själva test logiken. Om fel flagga klickas eller om alla flaggor har klickats ser callback funktionen till att returner ut det normaliserade värdet av rätt klickade flaggor genom totala antalet flaggor. För att vända flaggorna efter 5 sekunder så sätts en helt vanlig timeout.

Visual

Testet börjar med en instruktionstext som användaren klickar sig vidare ifrån. Då användaren klickat sig vidare genereras en lista av objekt från modulen Objects som från servern hämtar data om hur den kan generera objekt i en json fil. Det genereras upp en lista om vilken ordning objekten skall klickas på. Objekten ritas ut på skärmen och får en eventhandler för onclick på sig. Under objekten ritas ordningen ut i en ordered list. När ett element klickas på så kollas det om det är rätt är det det så syns det i listan och på elementet. Är det fel så syns det i listan och på det element som skulle ha klickats på. När det är klart så returneras rätt klickade element delat met totala mängden element.

Reaction

I reaktions testet så visas först en instruktionstext. När användaren läst och klickat sig vidare genereras objekt lika som i tidigare test och ett antal regler byggs slumpmässigt och skrivs ut på skärmen. Reglerna slumpas fram med e olika värdena: equals eller not equals, shape eller color och värdet att jämföra. Sedan visas elementen ett i taget och användaren skall klicka på det om det stämmer med alla reglerna. När ett element klickas på så markeras det med en flagga och när visningstiden är slut så valideras elementet mot reglerna och sedan kollas det värdet mot om användaren klickat eller inte. Jag hade stora problem med valideringen av element mot reglerna när vissa regel kombinationer fanns. Exempelvis så ställde det till det om man hade två equals regler på shape eller color. Ett element kan exempelvis inte vara både en cirkel och en triangel. Det tog ett tag att komma på det då det var svårt att hitta ett mönster bland felen. Jag fick tillslut utvidga validerings funktionen så att den gjorde eller på equals med samma target (color eller shape). När tillslut alla objekt har visats så kan användaren klicka på nästa och då returneras de normaliserade poängen för testet.

Allmänt

Jag gick in i uppgifterna med ett mindset att skriva så generellt som möjligt och få deltesten att fungera så lika som möjligt i kod. Därför finns extra moduler som Network och Common som samlar en del generella funktioner. Samma gäller API:et för deltesten, varje deltest exponerar fyra funktioner: initialize, setOnCompleted, show, hide. Den utomliggande modulen Test behöver då bara fara en fabrik för de olika testen. Test modulernas interna struktur gjorde att det var lätt att ta en av de tidigare modulerna och skriva om de funktioner som fanns till det nya testets funktion. Jag tyckte det var ganska lätt när jag väl fått strukturen på plats. Det är tänkt som att det ligger ett interface under varje modul för deltesten. Detta betyder att vissa funktioner måste finnas. Att få den generella strukturen gick ganska snabbt att få på plats sen var det bara att meka och testa och se till att alla deltest fungerade som väntat. Det var detta som tog mest tid också och var det svåraste tyckte jag men det var ändå skönt att ha en struktur så jag bara hade ett test att tänka på i taget. Jag kan tycka att det var lite mycket. Och att det var mycket copy pasta.

Tankar

Jag gick in i kursen och hoppades att jag skulle lära mig något nytt men jag tycker ändå att jag lärt mig rätt mycket. Det känns som att man kommer att använda ett bibliotek som React eller Vue när man väl gör en sida själv. Den känsla jag fått av kursen är nog att jag har koll på vad som händer i bakgrunden av dessa bibliotek. Jag har också lärt mig massor om javascrips inbyggda funktioner och datatyper. I detta kmom fick jag lära mig en hel del om promises också då er eslint hatar på async. Jag kan tycka att den skulle kunna validera mer modern kod också. Jag skulle ändå ge kursen en stark 7:a och rekommendera till nya webbisar.

http://www.student.bth.se/~rasb14/dbwebb-kurser/javascript1/me