Bloggångest

Senaste tiden har jag allt oftare känt av något jag skulle kalla bloggångest. Jag ska försöka beskriva känslan.

Massor av saker sker omkring en, man följer med så gott man kan. Man funderar på ett blogginlägg att skriva, lägger in det i bakhuvudet i väntan på en ledig stund och tillräckligt med inspirationsenergi för att plita ned tankegången.

Men så dyker något nytt ämne upp så innan man ens hunnit med det föregående inlägget är tankarna kring något annat.

Eller så läser man blogginlägg som redan uttrycker det man känner, och tycker att ”vad är det för mening att jag också uttrycker mig? Det har redan sagts, jag har inget att tillföra”.

Här är saker jag velat skriva om senaste veckan eller så, som bara inte blivit av:

• Nakenscanning
• Bonos artikel i New York Times (läs Göran, Marcus och Joshens kärnfulla artikel i SvD)
• Framtidsvision (läs Beelzebjörns inlevelsefulla inlägg som verkar vara inne på samma sak)
• Supportgruppens igångstartande av Piratsupport
• iMacros och hur det kan förenkla blogg-pingande

Det är som om man inte kan andas, för man andas för fort (hyperventilation?). Jag försöker fundera på vad som kan göras åt saken, ingenjörsorienterad som jag är, och kommer fram till några grejer:

1. Det går inte att skriva inlägg om allt som händer; informationsflödet är för stort
2. Det är OK att missa vissa frågor, någon annan tar vid och fyller i
3. Ett kort inlägg är bättre än inget långt inlägg
4. Att ta initiativ och vara positiv är långt roligare än att hela tiden reagera och skrika i efterhand (kallas detta att vara proaktiv istället för att vara reaktiv?)

Att inte skriva något, bygger på pressen att skriva, en ond cirkel skapas. Leffelini tipsade mig om att skriva utifrån eget perspektiv, att skriva för mig själv som publik, även om det som skrivs känns insignifikant i det större skeendet, och det är det jag försökt göra ovan.

Taggar: psykologi, bloggångest

Annons

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

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