Gemensamt slutprojekt 2c:4

På dagens lektion så lade vi in funktionalitet för att kunna skriva kommentarer till ett enskilt inlägg. Förutom att någon, läraren?, tappade bort sig och skapade SQL-sats för fel saker så hade vi inga större problem. När vi väl hittade rätt SQL-sats så fungerade det att lägga till kommentarer utan större problem. Koden för blog.php och insertComment.php hittar du här; Fortsätt läsa ”Gemensamt slutprojekt 2c:4”

Gemensamt slutprojekt 3c:3

Tredje sessionen började med att vi gick igenom en nulägesanalys. Vissa blev klara med kopplingen till inloggningssystemet som vi skulle göra förra lektionen. Vissa hade inte riktigt blivit klara med detta.

Vi skissade sedan på hur resten av applikationen skall se ut, först listade vi de funktioner som måste finnas i ett inloggat läge, vi konstaterade att följande funktionalitet är nödvändig. Fortsätt läsa ”Gemensamt slutprojekt 3c:3”

WEBWEU02: Vägen till ett E

I slutet av kursen så har flera av er ett enda önskemål, hur gör jag för att få ett E? Här kommer därför en uppgift som lotsar dig till betyget E, den bygger vidare på den slutuppgiften som finns för kursen Webbserverprogrammering 1 och den gemensamma uppgiften där. Du som läser den kursen bygger vidare på den applikationen, främst front end, och du som inte läser den kursen får här tre filer som du kan jobba med. Dessa filer är index.html, blog.html och style.css, läser du kursen webbserverprogrammering 1 så jobbar du med dina php och css-filer.

Grundkraven för ett E

Från projektspresentationen hämtar jag följande information;

  • En projektplanering skall göras, i projektplaneringen skall ett tydligt mål för kursbetyget framgå. Behöver inte göras för denna uppgift, däremot måste du skriva i din planering att du följer min uppgift för betyget E.
  • Applikationen skall vara väl fungerande och ligga i en egen mapp på Binero.
  • En fullt fungerande applikation som du själv kodat i HTML5. Sidan bör klara en validering som HTML5 på http://validator.w3.org.
  • Allt som har med utseendets att göra bör styras av en extern CSS-fil.
  • Den bör vara responsive, dvs fungera och förändras beroende på skärmstorlek.
  • Sidan skall funka (inte nödvändigtvis perfekt i alla men vara fullt funktionell) i webbläsarna Google Chrome och Firefox.
  • Hela projektet skall dokumenteras. Dokumentation ska innehålla hur arbetet gått till, hur din sida fungerar samt vilket betyg du anser dig ha uppnått på projektet. Siktar du på ett högre betyg bör dokumentationen vara både omfattande och detaljrik samt innehålla reflektioner kring vad du kunde ha gjort annorlunda.
  • Applikationen skall testas på något eller några olika sätt, testningen skall dokumenteras. Denna dokumentation skall även innehålla vilka saker på er sida ni ändrat pga testresultaten.
  • JavaScript/jQuery/Canvas/SVG/HTML5 Media kan/bör användas när det tillför applikationen något.

Arbetsgång

  • Plocka ner filerna som du sedan skall jobba vidare med. Om du läser kursen webbserverprogrammering 1 skall dessa filer vara grund för detta projekt.
  • Kika igenom HTML-filerna och CSS-filen och se om det är något som behöver ändras? Validera och se om något är fel. Kanske vill du ändra något annat?
  • DOM/CSS: Du skall visa att du behärskar DOM genom att ändra i CSS-filen. Minst ett element som är barn till ett element skall formateras specifikt. Ett förslag är klassen ”signature” som i index.html ligger inom ett section-element som ligger i ett article-element medan den i blog.html ligger i ett section-element som ligger i ett annat section-element. Minst en pseudoklass skall skapas/användas och här kan du tex ändra utseendet på varannan kommentar så att den tex får en annan bakgrundsfärg.
  • JavaScript: Med hjälp av JavaScript skall du skapa en kontroll av inloggningsformuläret så att användaren måste ange ett användarnamn som är längre än 4 tecken. ”admin” är godkänt, då kommer man vidare, ”olle” är inget godkänt användarnamn, då skall användaren få information om detta via en ”alert”-ruta.
  • jQuery (eller liknande): Du skall på sidan skapa någon form av funktionalitet som skapas från jQuery. Förslag kan vara att med knapp eller länk dölja/visa alla kommentarer på en bloggsida (enklare) eller att bara visa rubriken på samtliga blogginlägg på startsidan och sedan med ett klick på länk eller knapp få fram bloggtexten (lite svårare). Annan jQueryfunktionalitet kan implementera.
  • Canvas: Du skall skapa/använda en canvas någonstans på din sida, hur du använder den bestämmer du själv. <header> och <footer> kan vara lämpliga platser att placera den på.
  • SVG: Du skall skapa/använda en SVG-bild någonstans på din sida, hur du använder den bestämmer du själv. <header> och <footer> kan vara lämpliga platser att placera den på. Kanske blir det en logga någonstans på sidan?

Validering

Innan applikationen är färdig är det viktigt att den valideras på olika sätt, allt från att den skall vara korrekt kodad till att den skall fungera på olika klienter och vara tillgänglig även för personer med vissa handikap. Vänta dock inte med valideringen tills du är klar med din applikation, använda det som ett verktyg även under utvecklingen.

Vilka tester skall då göras? Spara ner dina testresultat (de skall redovisas) rätta sedan det som inte blir godkänt och validera en gång till, även denna rapport skall redovisas. Ibland kan man välja att inte rätt något fel som påpekas, men då måste du motivera varför du väljer att inte ändra. Att motivera med att jag är för lat och inte orkar är inte tillräckligt.

Extra hjälp?

Här finns en sida med lite extra tips och kodexempel.

Lägga upp på Binero

Innan det är dags för redovisning skall du lägga upp sidan på ditt Binerokonto. Lägg projektet i en egen mapp och slutför sedan din rapport/dokumentation på egen sida eller på din redovisningssida (WordPress?). Du skall dokumentera vad du har gjort under ditt arbete, ta hjälp av punkterna under rubrikerna ”Arbetsgång” och ”Validering” och dokumentera vad du har gjort under varje punkt och hur det har gått och om det var svårt eller enkelt.

Checklistan innan redovisning

Kolla att du har gjort följande saker;

  • Följt varje punkt under rubriken ”Arbetsgång” och genomfört den.
    • html5/css/DOM
    • JavaScript
    • jQuery, eller annat scriptpaket
    • Canvas
    • SVG
  • Validerat applikationen enligt de krav som jag ställer.
  • Lagt upp applikationen på ditt binerokonto.
  • Skapat en rapport/dokumentation som uppfyller kraven.

När du kan bocka av dessa punkter är du redo för redovisning och har goda chanser för att klara den utan rest! Glöm nu inte att anmäla tid för redovisning.

PRRPRR02: Vägen till ett E

Så här i slutet av kursen och vårterminen så vet jag att många av er kämpar för att nå i mål med flera kurser och en fråga jag ofta får nu är ”Vad krävs för att nå betyget E?”. Då tänkte jag skriva det här, dels vilka krav jag har, tips på förändringar du kan göra i spelet och hur det skall redovisas. Se det som en checklista, det är också denna checklista jag har när du redovisar. Har du inte uppnått alla delat så kommer du få rest, så enkelt är det.

Grundkraven för ett E

Från Projektspresentationen klipper jag följande;

”För betyget E krävs det att du jobbar vidare med spelet SpaceShooter och lägger till minst tre funktioner som tillför någonting till spelet. Exakt vad detta är för funktioner har du stor frihet att bestämma själv. Ett krav är dock att du skapar minst en egen klass inom hierarkien för arvet.”

”När du är klar med ditt spel skall det redovisas. Det gör du genom att dema ditt spel för läraren och lämnar in en enklare rapport med planering och utvärdering av ditt projekt, denna rapport lägger du på den sida som du använder för att redovisa kursens uppgifter (WordPress?).”

Då blir det ju ganska tydligt vad som behöver göras.

Tre ändringar

  1. Vi börjar med den nya klassen, här är det nog enklast att skapa en ny fiende. Du har redan skapat två så att det finns bra exempel med kod som går att återanvända. I klassen Enemy, om du inte skapat egna klasser för Mine och Tripod, så skall du nu skapa din nya klass. Hitta på ett bra namn, skapa eller leta upp en sprite som du har rätt att använda och bestäm hur din nya fiende skall röra sig. Skapa klassen i Enemy, eller egen fil, och sedan ser du till att i klassen GameElements skapar den nya fienden på samma sätt som du skapar Mine och Tripod samt lägger de nya fienderna i listan enemies.
  2. I spelet så skapas det slumpmässigt nya guldmynt som ger spelaren möjlighet att samla poäng. Hittills i spelet så skapas det bara fiender när spelet startar men nu vill vi skapa fiender även under spelets gång.
    I klassen GameElements finns logiken för att slumpa fram ett värde och skapa ett guldmynt om det slumpade värdet är 1. Här kan vi bygga en ny logik som innebär att vi slumpar fram ett värde mellan 1 och någonting (ju högre värde vi sätter, desto mer sällan kommer det inträffa, sätter vi 60 kommer det statistiskt att skapas en ny fiende varje sekund) och sedan så ser vi till att om det slumpade värdet är 1 så skapas en Mine, om det är 2 så skapas en Tripod och om det är 3 så skapas vår nya fiende.
    OBS! Gör inte denna logiken samtidigt som guldmynten skapas, utan gör det innan eller efter, återanvänd gärna variabeln random för att slumpa fram ett nytt tal.
  3. Låt en kula (bullet) försvinna efter träff mot fiende.
    Följande kod hittar du i klassen Player och den tar bort de kulor som i medlemsvariabeln IsAlive har värdet false. Det finns alltså redan en logik för att rensa bort dessa kulor, nu blir ditt uppdrag att leta upp kollisionen mellan bullet och enemy och sätta värdet på IsAlive till false på den specifika bullet som har träffat en fiende.

// Flytta  alla skott
foreach(Bullet b in bullets.ToList())
{
    // Flytta  skottet
    b.Update();
    // Kontrollera  att skottet inte är dött
    if (!b.IsAlive)
        // Ta bort skottet ur listan
        bullets.Remove (b);        
}

Checklistan innan redovisning

Kolla att du har gjort följande saker;

  • Tre ändringar i spelet, som kommer anses tillräckligt omfattande, varav minst en egen klass har skapats! Tänk på att den kod du skriver skall vara kommenterad.
  • Är ändringarna tydligt presenterade i ett inlägg på din redovisningssida?
  • Är ändringarna tydligt utvärderade, alltså hur gick det att genomföra ändringen, i ett inlägg på din redovisningssida? Det går att göra dessa två punkter i samma inlägg.
  • Ritat ett UML-diagram för den nya klassen? Dessutom ritat hela UML-strukturen för spelet där vi tydligt ser var den nya klassen befinner sig? I boken på sida 99 hittar du klasshierarkin för spelets objekt.
  • Vid redovisningen vill jag också se att du har gjort övningar i bokens kapitel 9, 10 och 11.

När du kan bocka av dessa punkter är du redo för redovisning och har goda chanser för att klara den utan rest! Glöm nu inte att anmäla tid för redovisning.