Jade Warrior
Jaha, så har jag sett Jade Warrior, det finsk-kinesiska kampsportseposet.
Har radas den ena sago/epos-klyschan efter den andra. Tyvärr identifierar jag mig inte med någon av rollfigurerna, så de blir bara dockor i ett animerat skyltfönster för mig, hur snyggt det än ser ut.
Sedan blir trovärdigheten låg när man försöker lura i mig att kineser på något sätt härstammar eller har något slags mystiska förkinesiska band till Finland. Finnar som talar kinesiska må väl existera, svårare att tro på är kineser som talar finska (på medeltiden typ), men allra svårast har jag för hammarsvingande finnar som slåss som kineser.
Ledsen Finland, men det här kan kineserna bättre än er, låt dem göra det.
Har radas den ena sago/epos-klyschan efter den andra. Tyvärr identifierar jag mig inte med någon av rollfigurerna, så de blir bara dockor i ett animerat skyltfönster för mig, hur snyggt det än ser ut.
Sedan blir trovärdigheten låg när man försöker lura i mig att kineser på något sätt härstammar eller har något slags mystiska förkinesiska band till Finland. Finnar som talar kinesiska må väl existera, svårare att tro på är kineser som talar finska (på medeltiden typ), men allra svårast har jag för hammarsvingande finnar som slåss som kineser.
Ledsen Finland, men det här kan kineserna bättre än er, låt dem göra det.
Flytta källkodsfiler i SVN+VisualStudio-miljö
Det är inte superenkelt att flytta filer om man kör VisualStudio och SVN som arkivprogram.Problemet är att Visual Studio's projektfiler innehåller sökvägarna till källkodsfilerna. Alternativet, som storkonkurrenten Eclipse valt, är att det är en 1-1 mappning mellan filsystem och projekt.
Detta gör att det blir hårigt att flytta en källkodsfil som finns med i ett projekt. Här är min nuvarande "algoritm", om någon har ännu smidigare sätt, hojta till!
Jag förutsätter att man vill flytta en fil in i en ny projekt-mapp för att strukturera upp sitt projekt.
I projektroten: A.cs
Vill ha den i: rot\NyMapp\A.cs
- Skapa NyMapp mha. Visual Studio högerklick på projektet
- Stäng av Visual Studio
- Högerklicks-dra A.cs till NyMapp, välj "SVN Move versionen files here" på kontextmenyn
- Starta Visual Studio
- Högerklicka på NyMapp och välj "Add->Existing Item", välj A.cs
Läs även andra bloggares åsikter om svn, tips, visualstudio
Modell för mjukvaruutveckling
Håller på att ta mig igenom en artikel med filosofisk ton som beskriver en modell för utveckling av mjukvara. Författaren ser mjukvaruutveckling som ett spel, i spelteoretisk mening. Intressant!
The end of software engineering
Artikeln har tydligen publicerats i denna vetenskapliga tidsskrift:
The end of software engineering
Artikeln har tydligen publicerats i denna vetenskapliga tidsskrift:
En liten godbit innifrån:
Thus, unlike a rock-climbing trip, a software project has two goals:
* To deliver the system;
* To set up for the next game.
The full evaluation of the project therefore includes, first, whether the system was delivered, and second, to what extent an advantageous position was created for the next game.
These two goals compete for resources. The team can deliver the system more quickly if the system will not have to be extended in the future. (It can deliver the system much, much sooner if bugs will not have to be fixed!) Or, the team can set in place a better software architecture and more training and documentation for their successors at the expense of delaying or even preventing the current delivery.
Jäkligt vist sagt... Ett mjukvaruprojekt har två mål i det mest abstrakta: att ge ett resultat (programmet) i slutet av projektet och efterlämna en källkodsbas som är bra att bygga vidare på! Det är detta som är dilemmat man upplever dagligen som programmerare: kunden vill bara ha så snart som möjligt, och man kan koda ihop skräp snabbt också, men man själv funderar på hur kan kan skriva så enkelt som möjligt, så det går att hantera koden i framtiden...
Thus, unlike a rock-climbing trip, a software project has two goals:
* To deliver the system;
* To set up for the next game.
The full evaluation of the project therefore includes, first, whether the system was delivered, and second, to what extent an advantageous position was created for the next game.
These two goals compete for resources. The team can deliver the system more quickly if the system will not have to be extended in the future. (It can deliver the system much, much sooner if bugs will not have to be fixed!) Or, the team can set in place a better software architecture and more training and documentation for their successors at the expense of delaying or even preventing the current delivery.
Jäkligt vist sagt... Ett mjukvaruprojekt har två mål i det mest abstrakta: att ge ett resultat (programmet) i slutet av projektet och efterlämna en källkodsbas som är bra att bygga vidare på! Det är detta som är dilemmat man upplever dagligen som programmerare: kunden vill bara ha så snart som möjligt, och man kan koda ihop skräp snabbt också, men man själv funderar på hur kan kan skriva så enkelt som möjligt, så det går att hantera koden i framtiden...
Intressant TDD-artikel
En seriöst skriven artikel om erfarenheter hos ett spelbolag som använt TDD en längre tid. Speciellt intressant om "bad practices" t.ex. "functional tests instead of unit tests" och "overly complex tests").
http://www.gamesfromwithin.com/articles/0603/000107.html
Den innehöll den klassiska TDD/Waterfall-kurvan också:
http://www.gamesfromwithin.com/articles/0603/000107.html
Den innehöll den klassiska TDD/Waterfall-kurvan också:
Namngivning: min metod
Jag är mycket känslig för namngivning i källkod. Det kan gå så långt att jag sitter och tänker på namn en halv dag utan att "få något gjort" - eftersom jag inte hittar något ord som passar för begreppet ifråga.
Just av denna anledning, att jag är så känslig för namngivning, försöker jag att "bortse ifrån" namn initialt, när jag löser ett nytt problem. Jag använder helt enkelt det första jag kommer på, för jag är 99% säker på att jag kommer att vara besviken på namnet om någon dag eller två. I och med att refactoring-verktygen i Visual Studio blivit så kraftfulla, är detta ett bekvämt arbetssätt som inte blockerar min utvecklingsinsats, och dessutom ger mig "rätt" namn i slutändan.
Ett problem är fortfarande att publika APIer framförallt i gemensam kod och utilitybibliotek, kan ingå i flera olika solutions, och därmed är refactoring-verktygen verkningslösa. Därför är jag extra försiktig med att lägga till publika APIer i bibliotek - kanske först när koden använts någon månad i aktivt projekt, och känns "stelnad".
För övrigt anser jag att refactoring ska heta faktorisering på svenska! För det är vad det är ..
Just av denna anledning, att jag är så känslig för namngivning, försöker jag att "bortse ifrån" namn initialt, när jag löser ett nytt problem. Jag använder helt enkelt det första jag kommer på, för jag är 99% säker på att jag kommer att vara besviken på namnet om någon dag eller två. I och med att refactoring-verktygen i Visual Studio blivit så kraftfulla, är detta ett bekvämt arbetssätt som inte blockerar min utvecklingsinsats, och dessutom ger mig "rätt" namn i slutändan.
Ett problem är fortfarande att publika APIer framförallt i gemensam kod och utilitybibliotek, kan ingå i flera olika solutions, och därmed är refactoring-verktygen verkningslösa. Därför är jag extra försiktig med att lägga till publika APIer i bibliotek - kanske först när koden använts någon månad i aktivt projekt, och känns "stelnad".
För övrigt anser jag att refactoring ska heta faktorisering på svenska! För det är vad det är ..
Lite TDD-spekulation
Funderade på vad som är roligt med tecknade serier idag. Åtminstone en del av humorn ligger i att ta upp människors dubbelmoral; observation av beteenden som strider mot vad människor själva säger ger upphov till en stripp.
Alltså en form av "bevis" på tvetydighet eller motsägelser. Och där finns det en likhet med en upplevelse jag haft av TDD - det tvingar mig att tänka på tvetydigheter i APIer. Det tvingar mer eller mindre fram (mer eller mindre) icke-tvetydiga klasser. Det tvingar mig att tänka på hur klassen ska användas, hur den ska bete sig, hur den inte ska bete sig. Dessa tankegångar har alltid funnits inom mig, men inte stavats eller uttryckts bokstavligen förrän jag kom i kontakt med TDD.
Alltså en form av "bevis" på tvetydighet eller motsägelser. Och där finns det en likhet med en upplevelse jag haft av TDD - det tvingar mig att tänka på tvetydigheter i APIer. Det tvingar mer eller mindre fram (mer eller mindre) icke-tvetydiga klasser. Det tvingar mig att tänka på hur klassen ska användas, hur den ska bete sig, hur den inte ska bete sig. Dessa tankegångar har alltid funnits inom mig, men inte stavats eller uttryckts bokstavligen förrän jag kom i kontakt med TDD.
Facebooks goda sida
Mycket kan man säga om Facebook och dess "sug åt sig all information som finns" och "skräpa ned världens inboxar tills dess email är omöjligt att använda för normala användare".
Men det funkar riktigt bra för en sak: planering av jippon. Ska gå på KISS-konserten i Stockholm om några månader, och det är guld värt att ha en gemensam plats på nätet för kompisgänget som ska dra dit. Planering, inspiration.. Väldigt praktiskt!
Ett kort TDD-inlägg
Jag är ett fan av TDD sedan ungefär ett år tillbaka. Men ibland diggar jag det inte; det passar inte allt utvecklingsarbete en programmerare gör vid datorn.
Problemet
Igår ställdes jag inför problemet att försöka sortera ett antal punkt i något slags sick-sack ordning, nerifrån och upp, rad för rad. Algoritmen ska klara att börja i alla fyra hörn av den omslutande boxen kring punkterna, och dessutom "röra sig" antingen horisontellt eller vertikalt. En ytterligare komplikation är att den förutom sicksackmönstret ska klara av att röra sig "radvis" dvs. starta om istället för att "vända" när den påbörjar en nyrad.
Försök till exempel i ASCII-art:
* *
* * *
* *
.. skulle ge, med start i neder vänster hörn, horisontell rörelse och sicksackmönster:
+-->
|__,
>--+
Det är ett ganska inprecist ställt problem och är (tyvärr?) ganska lättlöst för det mänskliga ögat. En förenklande åtgärd är att anta att man alltid börjar i nedervänster hörn och alltid rör sig horisontellt; alla andra fall kan lösas med hjälp av en sådan algoritm plus speglingar/rotationstransformationer av punkterna.
Försök ett
Min kollega och jag diskuterade en "enkel lösning" först av allt. Idén gick ut på att dela upp problemet i en optimeringsdel och en "arbetshäst"; arbetshästen delade upp punkterna i N antal mängder mha. jämnt fördelade linjer från botten till toppen av den omslutande rektangeln. Optimeringsdelen testade sedan alla möjliga sådana delningar för N=3 till 50 eller liknande fixa konstanter, och valde helt enkelt den "orm" som var kortast.
Entusiastisk inför uppgiften satte jag mig och började skissa på olika hjälpklasser jag skulle använda mig av för att implementera algoritmen. Till att börja med ville jag göra klassificeringen av punkterna enkel, och den blir väldigt enkel om man skalar om punkternas y-värden till heltal, i en skala som bestäms med hjälp av N och den omslutande boxen. Det problem som verkade enklast att börja med var också icke-sicksack-mönstret, dvs. radvis ordning. Då slapp jag tänka på exakt när och hur "ormen" skulle vända. Jag byggde tre miniklasser för detta delproblem:
RowByRowOrder: givet en lista med punkter, klassificeras punkterna efter (int)y dvs heltalsdelen på sin y-koordinat och därefter x. Snabbt och lätt alltså.
SupportLine: kunde givet en omslutande rektangel och ett N beräkna ymin, ystep för linjärt positionerade stödlinjer.
Scaler: kunde omvandla från y i världskoordinater till RowByRowOrder-anpassat y.
Att utveckla och få rätt på dessa klasser tog kanske en eftermiddag. De funkade som tänkt, och jag kunde påbörja den omslutande optimeringsdelen.
Käppar i hjulet
Här uppstod problem. Med tex. en 9x3 grid av punkter som var något ojämnt utplacerade, valde optimeringsdelen hellre N=27 än det mer naturliga N=8, något det mänskliga ögat utan vidare såg. Men optimeringsalgoritmen följde endast vad jag bett den om: minimera ormens längd. Den hittade helt enkelt en orm som splittade en punktrippel i två delar, så att ormen kunde ta sig "rakt upp" istället för att röra sig diagonalt till nästa rad. Smart, men inte riktigt vad jag var ute efter.
Så jag började fundera på vad som var en bättre kriterie, var kort inne på minimera N men det är dödfött eftersom det alltid gick att hitta en orm oavsett N. Tredje försöket blev att minska övre gränsen 50 ner till något rimligt, hastade ihop gränsen N = antal punkter / 2, efter som det på något sätt är rimligt att anta att varje rad innehåller åtminstone 2 punkter. Då hittade algoritmen N=12 istället för N=8 i ovan beskrivna exempel.
Alphasort
Det slog mig plöstligt hur jag kunde splitta punkterna med hänsyn taget endast till deras y-värde och ett bra kriterie som löst baseras på två på varandra följande punkters y-koordinat. Jag ska inte avslöja exakt hur, men jag kan säga att den algoritmen kodade jag på mindre än 10 minuter och den ger riktigt övertygande resultat, inte bara i 9x3-fallet utan i alla andra "trovärdiga" fall jag kunnat hitta på! Jag kallade algoritmen Alphasort. Dessutom klarar den både sicksack och rad-för-rad-mönstret utan någon komplicerad logik.
Jag kunde skrota alla tre hjälpklasser och använda min mindre-än-en-kodsida-alphasort. Den utvecklade jag utan TDD medan de övriga utvecklades minutiöst med TDD.
Slutsats
Nå, vad är sensmoralen? Jo det är att prototypning / efterforskning bäst görs INNAN TDD stadiet - jag visste inte vad jag ville ha förrän jag prövat flera metoder.
TDD när man har en klar bild av matematiken i huvudet; efterforskning, prototypkod innan dess!
Problemet
Igår ställdes jag inför problemet att försöka sortera ett antal punkt i något slags sick-sack ordning, nerifrån och upp, rad för rad. Algoritmen ska klara att börja i alla fyra hörn av den omslutande boxen kring punkterna, och dessutom "röra sig" antingen horisontellt eller vertikalt. En ytterligare komplikation är att den förutom sicksackmönstret ska klara av att röra sig "radvis" dvs. starta om istället för att "vända" när den påbörjar en nyrad.
Försök till exempel i ASCII-art:
* *
* * *
* *
.. skulle ge, med start i neder vänster hörn, horisontell rörelse och sicksackmönster:
+-->
|__,
>--+
Det är ett ganska inprecist ställt problem och är (tyvärr?) ganska lättlöst för det mänskliga ögat. En förenklande åtgärd är att anta att man alltid börjar i nedervänster hörn och alltid rör sig horisontellt; alla andra fall kan lösas med hjälp av en sådan algoritm plus speglingar/rotationstransformationer av punkterna.
Försök ett
Min kollega och jag diskuterade en "enkel lösning" först av allt. Idén gick ut på att dela upp problemet i en optimeringsdel och en "arbetshäst"; arbetshästen delade upp punkterna i N antal mängder mha. jämnt fördelade linjer från botten till toppen av den omslutande rektangeln. Optimeringsdelen testade sedan alla möjliga sådana delningar för N=3 till 50 eller liknande fixa konstanter, och valde helt enkelt den "orm" som var kortast.
Entusiastisk inför uppgiften satte jag mig och började skissa på olika hjälpklasser jag skulle använda mig av för att implementera algoritmen. Till att börja med ville jag göra klassificeringen av punkterna enkel, och den blir väldigt enkel om man skalar om punkternas y-värden till heltal, i en skala som bestäms med hjälp av N och den omslutande boxen. Det problem som verkade enklast att börja med var också icke-sicksack-mönstret, dvs. radvis ordning. Då slapp jag tänka på exakt när och hur "ormen" skulle vända. Jag byggde tre miniklasser för detta delproblem:
RowByRowOrder: givet en lista med punkter, klassificeras punkterna efter (int)y dvs heltalsdelen på sin y-koordinat och därefter x. Snabbt och lätt alltså.
SupportLine: kunde givet en omslutande rektangel och ett N beräkna ymin, ystep för linjärt positionerade stödlinjer.
Scaler: kunde omvandla från y i världskoordinater till RowByRowOrder-anpassat y.
Att utveckla och få rätt på dessa klasser tog kanske en eftermiddag. De funkade som tänkt, och jag kunde påbörja den omslutande optimeringsdelen.
Käppar i hjulet
Här uppstod problem. Med tex. en 9x3 grid av punkter som var något ojämnt utplacerade, valde optimeringsdelen hellre N=27 än det mer naturliga N=8, något det mänskliga ögat utan vidare såg. Men optimeringsalgoritmen följde endast vad jag bett den om: minimera ormens längd. Den hittade helt enkelt en orm som splittade en punktrippel i två delar, så att ormen kunde ta sig "rakt upp" istället för att röra sig diagonalt till nästa rad. Smart, men inte riktigt vad jag var ute efter.
Så jag började fundera på vad som var en bättre kriterie, var kort inne på minimera N men det är dödfött eftersom det alltid gick att hitta en orm oavsett N. Tredje försöket blev att minska övre gränsen 50 ner till något rimligt, hastade ihop gränsen N = antal punkter / 2, efter som det på något sätt är rimligt att anta att varje rad innehåller åtminstone 2 punkter. Då hittade algoritmen N=12 istället för N=8 i ovan beskrivna exempel.
Alphasort
Det slog mig plöstligt hur jag kunde splitta punkterna med hänsyn taget endast till deras y-värde och ett bra kriterie som löst baseras på två på varandra följande punkters y-koordinat. Jag ska inte avslöja exakt hur, men jag kan säga att den algoritmen kodade jag på mindre än 10 minuter och den ger riktigt övertygande resultat, inte bara i 9x3-fallet utan i alla andra "trovärdiga" fall jag kunnat hitta på! Jag kallade algoritmen Alphasort. Dessutom klarar den både sicksack och rad-för-rad-mönstret utan någon komplicerad logik.
Jag kunde skrota alla tre hjälpklasser och använda min mindre-än-en-kodsida-alphasort. Den utvecklade jag utan TDD medan de övriga utvecklades minutiöst med TDD.
Slutsats
Nå, vad är sensmoralen? Jo det är att prototypning / efterforskning bäst görs INNAN TDD stadiet - jag visste inte vad jag ville ha förrän jag prövat flera metoder.
TDD när man har en klar bild av matematiken i huvudet; efterforskning, prototypkod innan dess!
Att uttrycka sig
Ibland gillar jag att fundera på vad ord eller uttryck betyder, semantiskt, som betydelser av programspråkskonstruktioner. Om du tillhör skaran som inte klarar av flum, ordbajseri eller filosofi för den delen, undvik att läsa nedanstående.
Denna gång hamnade jag i tankesnurran "Vad betyder det att uttrycka sig?". När jag tänker på att ge uttryck för något, tänker jag på "vad är ett uttryck". Ett uttryck är en bild eller ett mönster för något annat - en förenkling av något komplicerat till en liten sak. Ett uttryck i matematiken, en miljöbeskrivning i litteraturen. Alltså att beskriva något, klä det så att säga i en annan kostym än sin konkreta form.
Att uttrycka sina känslor blir således att försöka, i muntlig skriftlig eller annan form, beskriva det man känner. Avbilda något inom sig på ett externt media.
Det handlar alltså om att konkretisera eller konstruera en bild av något man sett eller känt. En sådan artefakt är med nödvändighet en förenkling eller reduktion av objektet det beskriver, annars hade det varit en identisk kopia av ursprungsföremålet.
Det ligger alltså något i att ett uttryck försöker kommunicera något till en mottagare; annars kunde mottagaren titta på föremålet ifråga själv. Alltså är ett uttryck en tolkning av något komplicerat, till en förenklad avbild, med avsikt att kommunicera något observatören iakttagit.
Detta stämmer väl in på vad språk är; språk är en förenkling av tankar och idéer man formar inom sig, t.ex. tankegångarna som ledde fram till denna text. Denna text är en artefakt konstruerad av mig för att avbilda tankegångarna jag hade för 15 minuter sedan.
Denna gång hamnade jag i tankesnurran "Vad betyder det att uttrycka sig?". När jag tänker på att ge uttryck för något, tänker jag på "vad är ett uttryck". Ett uttryck är en bild eller ett mönster för något annat - en förenkling av något komplicerat till en liten sak. Ett uttryck i matematiken, en miljöbeskrivning i litteraturen. Alltså att beskriva något, klä det så att säga i en annan kostym än sin konkreta form.
Att uttrycka sina känslor blir således att försöka, i muntlig skriftlig eller annan form, beskriva det man känner. Avbilda något inom sig på ett externt media.
Det handlar alltså om att konkretisera eller konstruera en bild av något man sett eller känt. En sådan artefakt är med nödvändighet en förenkling eller reduktion av objektet det beskriver, annars hade det varit en identisk kopia av ursprungsföremålet.
Det ligger alltså något i att ett uttryck försöker kommunicera något till en mottagare; annars kunde mottagaren titta på föremålet ifråga själv. Alltså är ett uttryck en tolkning av något komplicerat, till en förenklad avbild, med avsikt att kommunicera något observatören iakttagit.
Detta stämmer väl in på vad språk är; språk är en förenkling av tankar och idéer man formar inom sig, t.ex. tankegångarna som ledde fram till denna text. Denna text är en artefakt konstruerad av mig för att avbilda tankegångarna jag hade för 15 minuter sedan.
Dagens visdomsord
"När du känner att du måste skriva en kommentar, skriv en metod istället"
-Martin Fowler
