Grubblerier, fortsättning

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.]

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: programmering, fortdef, psykologi

Annons

Grubblerier

Våndor i utveckling.

Jag tänkte skriva lite om det idag.

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”.

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: programmering, fortdef, psykologi

Lekt lite mera med Launchpad

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:

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: programmering, fortdef, launchpad, bzr

Första Launchpad-uppladdningen genomförd!

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: programmering, launchpad, bazaar

Veckoutmaning, kort update

Ibland måste man vara lite praktiskt.

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: python, programmering, idle

Veckoutmaning: Litet spel med Pygame (6/7)

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:

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: python, pygame, programmering, spel

Veckoutmaning: Litet spel med Pygame (5/7)

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:

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: iphone, programmering, objective-c, opengl, spel

Veckoutmaning: Litet spel på IPhone (3/7) och (4/7)

Detta har hänt: igår försökte jag förgäves få igång enhetstestning mha. OCUnit på Mac:en. Detta visade sig vara pilligt som satan, och jag gav till slut upp. Det är väl en blandning av ovana vid Mac i allmänhet och XCode i synnerhet. [och fan vad jag är trött på grafiska gränssnitt med massa switchar och flaggor!! Att följa en instruktion steg-för-steg som nästan men bara nästan stämmer överrens med GUIt – XCodes konfigfönster – är bara lagom kul.]

Under kvällen igår och morgonen idag funderade jag över alternativ. Till slut kom jag fram till att Python+PyGame får bli miljön för denna gång. Det är lätt att installera, och jag kommer vidare istället för att vara låst.

Dock så är det stort frågetecken på om tidsplanen håller då jag nu tappat två dagar på grund av ”tekniska problem”. Jag jobbar på så gott jag kan, har åtminstone fått ihop enhetstestning på lagom nivå i Python denna fjärde dag. Hoppas kunna posta en liten screenshot ikväll eller imorgon.

En fördel med denna nya miljö är att jag kan släppa allt som öppen källkod när jag är färdig. Just nu håller jag på att lära mig Launchpad.net som används av Ubuntu community, det verkar riktigt bra för kollaborativa projekt.

Pythons IDLE-editor efter lite lek med färgerna

Taggar: iphone, programmering, objective-c, opengl, spel

Veckoutmaning: Litet spel på IPhone (2/7)

(detta är del 2 av 7 i en serie om hur jag bygger ett litet spel till IPhone på en vecka. Läs del ett som beskriver spelidén och reglerna.)

Den här dagen har blivit lite av en ”reality check” för mig. Jag började med att sätta ihop en lång lista med ”items” jag behövde för att kunna bygga spelet. Den blev längre än jag trodde, och det är lätt att bli lite missmodig.

Här är valda delar från den listan, som beskriver det jag behöver lära/bygga/designa:

• Grafik: teknik. Använda texturer eller bara trianglar? Om texturer: lär om hur läsa in bitmappar i Objective-C, implementera texturuppladdning till OpenGLES (GLES = Graphics Library Embedded Systems; en strippad version av vanliga OpenGL som används på ”små enheter” som mobiltelefoner)
• Grafik: data. Oavsett metod, måste bilderna/triangelinformation skapas.
• Ljud: teknik. Läs om hur man spelar upp ljud på IPhone., och hur man läser in samplingar i minnet/laddar upp till ljudkortet (eller hur det nu funkar på IPhone). Prototypa/implementera.
• Ljud: data. Skapa samplingar, eller hitta på nätet.
• TDD. Jag är såpass invand med TDD-tekniken att jag helst av allt vill ha vettiga enhetstestmöjligheter. Ja faktiskt har jag svårt att se hur jag skulle trivas med att utveckla någonting utan enhetstester nuförtiden.

Jag hittade en artikel som beskriver googles approach till TDD på IPhone, den har jag skummat plus en introduktion till OCTest som är ett enhetstestramverk för XCode.

Installation + första testet med OCTest blir en bra början imorgon tror jag!

Taggar: iphone, programmering, objective-c, opengl, spel

Veckoutmaning: Litet spel på IPhone (1/7)

Ganska långt ned i en tråd på OpenTK.com* skrev jag (du får gissa mitt alias själv!) att två erfarenheter jag dragit när det gäller att ”slutföra projekt” är följande:

1. Skriv ned ”visionen” först av allt (typ spelregler i ett brädspel)
2. Tidbegränsa! (aka time-boxing)

Och nu ska jag leva som jag lär! Jag utmanar mig själv att, på time-boxen en vecka, bygga ett litet spel till IPhone.

Så idag har jag tänkt ihop en liten spelidé som jag presenterar med bild & regelbeskrivning.

Skydda fortet!

Så till spelreglerna:

• Spelet går ut på att skydda fortet i mitten av skärmen
• Fortet attackeras av små fartyg som kommer inseglande
• Till skydd har man en ”slangbella-kanon”
• Man drar i kulan, och släpper för att avfyra!
• Efterhand kommer det fler och snabbare segelfartyg
• Så fort ett fartyg nuddar vid ön fortet står på, är spelet slut

Om jag skulle skriva en hiscore-lista är det antalet sekunder man lyckas försvara fortet som gäller som ”poäng”.

* OpenTK är ett multimediabibliotek för .NET, opensource! Det wrappar OpenGL, OpenAL så man kan skriva plattformsoberoende grafik- och ljudaccelererade spel i C#/Visual Basic.

Taggar: iphone, programmering, objective-c, opengl, spel