Grubblerier, fortsättning

01 augusti 2009

Jag skrev inlägget Grubblerier tidigare idag.

Jag har grubblat under dagen. Försökt analysera problemets ursprung.

Så kom jag på det: Jag oroar mig för att ändra på testkod. Det är ett välkänt ”TDD anti-pattern” – att man på något sätt känner sig känslomässigt fäst vid sina tester – så att man inte vågar eller vill röra vid dem.

Det är såklart en naiv inställning. Testerna liksom produktionskoden är under ständig utveckling i ett programvarusystem; betatanken – inget är någonsin färdigt, bara halvfärdigt. Och under ständig förändring/utveckling/evolution. [Betatanken kan för övrigt appliceras på allt: programvara, produkter, företag, människor, ekosystemen, samhällen, din chef, dig.]

Fortress Defender - en skärmdump

Så här ser Fortress Defender ut idag

Den naturliga vidareutvecklingen i mitt minispel är flytta ut ansvaret från Ball och Boat till en separat klass Entity eller kanske LinearEntity eftersom det handlar om linjär rörelse. Enhetstesterna för Entity kan utan skuldkänslor kopieras från t.ex. Ball och modiferas för att passa Entity. Entity själv kan utgå ifrån Ball.

Enhetstesterna för Ball och Boat som de står nu (som alltså testar linjärrörelse framför allt) är onödiga, då det inte är Ball eller Boats ansvar längre att utföra linjärrörelse. Det är Entity‘s ansvar. Ball/Boat testerna förpassas, när Entity är grön (alla tester OK), till papperskorgen.

Därefter är Ball och Boat enkla ”konfigurationer” av Entity. Vad behöver egentligen testas för dessa två? Frågan kan omformuleras till ”vad är Ball och Boats ansvar”. Och, utan att gå händelserna alltför mycket i förväg, känner jag redan nu att det som är Ball– och Boatspecifikt är punkterna A/B som Ball respektive Boat rör sig mellan. Så Ball och Boat kanske snarare ska vara ”Entititsskapande funktioner” än klasser.

Men förra stycket är ren spekulation. En sak i taget! Entity, here I come.

Taggar: , ,

Annonser

Grubblerier

01 augusti 2009

Våndor i utveckling.

Jag tänkte skriva lite om det idag.

Fortress Defender - en skärmdump

Fortress Defender - en skärmdump

Som du kanske vet sedan tidigare håller jag på att utveckla ett minispel mha. multimediabiblioteket PyGame. Man skulle kunna säga att spelet ”är ett PyGame”.

Nå först byggde jag ”kanonbollarna”, kallade ”Ball” i koden. De rör sig linjärt över skärmen, genom centrumpunkten (eftersom fortet befinner sig i centrum av havet).

När jag började koda attackbåtarna, ”Boat”-klassen, igår upptäckte jag att de har stora likheter, dessa två entiteter. De rör sig båda linjärt, och de består av en enda bild som ritas ut på skärmen. Dessutom triggar de varsin händelse när de är ”klara”. I Ball-fallet triggas ”ta bort mig”-händelsen. I Boat-fallet triggas ”game over”.

BoatCode

En snutt av Boat.py-filen

Båda klasserna är enhetstestade och fina, fast testerna är ganska så likartade. De testar ”var befinner sig entiteten i början”, ”var i slutet” och ”var i mitten” (av sin bana/livstid). Dessutom kollar de så att rätt händelse triggas på slutet.

Så långt allt väl. Men vän av ordning vill såklart bryta loss den gemensamma funktionaliteten i detta – förenkla ”uttrycket” som koden kan ses som. Alltså faktorisera ut en basklass eller hjälpklass som har förmågan att ”röra sig från A till B på tiden T, och triggar händelsen H när den är framme”.

Om jag då skulle utveckla en sådan tredje, mera generell klass, kanske kallad Entity eller något lämpligt, så skulle jag få  ytterligare enhetstester som gör samma sak .

En tredje gång.

Aj.

Så med denna vånda har jag vankat fram och tillbaka i tankevärlden idag.

Du som är lite tekniskt insatt förstår – kanske programmerat några rader själv nångång – att dessa ting inte är tekniskt/matematiskt avancerade. De är snarare psykologiskt påfrestande.

Jag kan ge ett annat exempel på hur mycket psykologi påverkar programmerare. Åtminstone denna programmerare.

Jag kodar spelet i Python – men till vardags jobbar jag i .NET med programspråket C#. Där skrivs klasser så här ”DettaÄrEnKlass”, och metoder likadant: ”DettaÄrEnMetod”. Så naturligt nog använde jag samma konvention i detta projekt av gammal vana.

Igår hittade jag till ett slags Python-konventions-dokument. Metoder skrivs av tradition ”detta_är_en_metod” i Python. Klasser skrivs med samma konvention som i .NET.

Så? Vad betyder detta då? Ja inte ett smack rent tekniskt. Spelet kommer att funka precis lika bra eller dåligt oavsett hur namnen skrivs i källkodsfilerna. Men det är ett sådant där litet dammkorn i ögat varje gång jag nu ser metoder och metodanrop som är skrivna på ”fel” form. Rent psykologiskt.

Jaja. Nu ska jag fortsätta våndas över att jag kommer att ha tre-gånger-upprepade enhetstester i mitt projekt, tills dess jag kommer på en elegant lösning. Hjälpa mig?

Taggar: , ,


Lekt lite mera med Launchpad

30 juli 2009

Mitt minispel ”Fortress Defender” är nu uppladdat som Open-Source-projekt på Ubuntu/Canonicals OSS-host Launchpad.net. För att plocka hem det, om du har ‘bzr’ installerat, ska det räcka med att skriva:

bzr branch lp:fortressdefender

Jag har lekt lite med Launchpads Blueprint-system, som kan sägas vara ett slags upphottad TODO-lista. Det funkade riktigt bra tycker jag:

Blueprints

Listan med blueprints för Fortress Defender

Dessutom har jag så smått börjat lära mig hur Bazaar fungerar. Den stora skillnaden mot Subversion t.ex. är att varje branch är ”sin egen” – den har egen historik etc. och är så att säga ”lika mycket värd” som trunk-branchen. Men allt har jag inte förstått ännu.Det blir lite komplicerat eftersom det är så flexibelt – det stödjer t.ex. även ”centraliserad” versionshantering, via checkouts som CVS och Subversion.

Taggar: , , ,


Första Launchpad-uppladdningen genomförd!

28 juli 2009

Jag håller på att lära mig Launchpad.net/bazaar, som är en hemsida för öppen mjukvara. Alltså en ”project host” ungefär som SourceForge.net (störst och äldst?) eller code.google.com (googles initiativ – enklast att använda). På Launchpad huserar t.ex. Linux-varianten Ubuntu, bland många andra OSS (Open Source Software)-projekt.

Det jag laddat upp (kallas att ‘pusha’ i Bazaar/LP-terminologi) är vad jag hittills åstadkommit i mitt minispel som du kanske läst om i något av mina tidigare inlägg.

Hurra! Ska bli skoj att lära mera..

Uppdatering: Jag har hittat till kommandoraden för att ladda hem projektet. Så om du har Bazaar (bzr) installerat, är det bara att dra igång en kommandoprompt och klistra in följande:

bzr branch lp:~objarni/fortressdefender/wip-first-commit

Taggar: , ,


Veckoutmaning, kort update

18 juli 2009

Ibland måste man vara lite praktiskt.

utvmiljö

Utvecklingsverktyg

Min utvecklingsmiljö är en WinXP-dator med Pythons inbyggda editor IDLE. Detta för att jag jobbar på min brorsas dator och inte vill skräpa ned alltför mycket med en massa program. Dessutom gillar jag att använda så få verktyg som möjligt, eftersom jag med åldern blivit lite ”anti-install/konfigg” rent allmänt. Denna hållning kommer egentligen från insikten ”ju fler steg tills miljön är uppsatt, desto fler felkällor att leta i när något fallerar”. (Förvisso ett mera verkligt problem först vid långtidsprojekt/många utvecklare!)

Nå denna miljö må uppfylla mina minimalism-krav, men den har också sina skavanker i form av att IDLE brukar ”hänga sig” ibland när man trycker F5 (kör). Det är något med sockets-connections hit och dit (IDLE verkar använda sockets för att kommunicera mellan texteditor och shell-fönster). Den praktiska lösning jag läst på nätet var att ta kol på alla python-processer mha. task manager, och sedan starta IDLE igen.

Denna morgon hängde sig IDLE osedvanligt många gånger, vilket ledde till frustration. Så jag bestämde mig för att lösa problemet en gång för alla. Jag kom på att om dödandet av processerna var ett dubbelklick istället för harangen — Ctrl+Alt+Delete — sortera om namnlist — döda en process i taget mha musklick — så hade gräset varit grönare.

Sagt och gjort, jag fixade en .bat-fil som gjorde jobbet åt mig: killpythonw.bat. Här är dess innehåll:

TASKKILL /F /IM "pythonw.exe"

Så om du råkar ha samma problem som jag nån gång vet du att det finns en smidig lösning!

Taggar: , ,


Veckoutmaning: Litet spel med Pygame (6/7)

17 juli 2009

Läs tidigare delar: Ett Två Tre&Fyra Fem

En liten uppdatering. Nu har jag fått rätt på muspekare och ”sikte”. Siktet är helt enkelt en liten röd halvgenomskinlig kanonkula:

screenshot

Nu börjar det röra sig lite på skärmen äntligen!

Det som kvarstår innan det ska vara någorlunda spelbart är egentligen bara fartygen. Fast för att få ett komplett spel behövs såklart smått&gott som ”Press to begin” och snyggare grafik&ljud (just nu har jag bara en sampling när man ”släpper” en kanonkula, en sampling av något slags fjäder som släpps upp!). Och så explosioner/vattenkaskader när man missar!

Taggar: , , ,


Veckoutmaning: Litet spel med Pygame (5/7)

17 juli 2009

Som ni vet sedan tidigare bytte jag på grund tekniska bekymmer plattform till Python+PyGame.

Postar en liten screenshot från vad som finns hittills:

screenshot

Bild från spelet

Närmst på tur står placering av den röda bollen som ska representera ett sikte, och därefter animering av själva kannonkulan.

Taggar: , , , ,


%d bloggare gillar detta: