Månadsarkiv: maj 2014

Trevlig provning i Ingelstad

I fredags var det äntligen dags för Ingelstad Whiskyvänners första provning någonsin. Med peppet uppskruvat till max stressade jag hem från jobbet, lagade mat åt familjen och styrde kosan mot Trollkvarnen.

Provlokalen och tillika fiket ligger farligt nära vårt hus och efter ett par minuters promenad var jag på plats. De andra i styrelsen hade jobbat på bra och allt var i stort sett klart när jag anlände vid halv sju. En dryg halvtimme senare satt vi (cirka 30 förväntansfulla entusiaster) framför dagens utbud bestående av sex glas a 2 ml. Jonas och Mats sa några väl valda ord, berättade om kvällens tema ”Smått och gott” och gav lite tips på hur man brukar prova whisky. Många (alla?) saknade erfarenhet av whiskyprovning sedan tidigare så det var välkommet. Vi skulle även under provningen (som var ett blindtest) välja ut två favoriter för att på så vis kunna kora en vinnare vid kvällens slut.

Äntligen var det dags att sätta igång. Vi plockade bort pappret som fungerade som lock för att hålla doftämnen kvar i glaset och snart spreds en angenäm doft i lokalen. Den närmaste timmen ägnades åt att dofta, smaka och vattna de olika sorterna för att klura ut vilken man tyckte bäst om. Allt eftersom tiden gick steg ljudvolymen i lokalen och mot slutet hade en riktigt gemytlig stämning infunnit sig.

Mumma.
Mumma.

Hur var då whiskyn? Provglas nummer ett hade jag av någon anledning ganska svårt att placera till en början trots att igenkänningsfaktorn var hög. Efter att ha diskuterat lite med min bordsgranne stod det klart att det var en bourbon, en lite mer fancy utgåva av Jack Daniels. Whisky två och tre tyckte jag var alldeles för spritiga och det var inte förrän jag nådde glas fyra som jag blev på gott humör igen. I glaset visade det sig sedermera vara en 30-årig (!) Glenfarclas.

Men det var först vid glas nummer sex som mitt rökbehov stillades. Smaken påminde om en Ardbeg jag mumsade på för ett par veckor sedan – och mycket riktigt var det en Ardbeg Uigedail som gömde sig i glaset. Som rökälskare gick en av mina två röster till detta glas (min andra röst gick till glas nummer fyra). När så vinnarna utsågs visade det sig att dessa två hamnade på första respektive andra plats i omröstningen. För mer info om sorterna kan man läsa föreningens beskrivning av kvällen (klicka här). Det känns lovande att min smak passar bra med de andra i gruppen och att en rökig rackare hamnade högst upp på pallen.

De jag pratade med under och efter provningen verkade väldigt nöjda och laddade inför nästa provning framåt sensommaren. Information om den kommer inom kort att dyka upp på föreningens hemsida (klicka här). Nästa gång kanske just du är med oss?

Pengar i sjön

Jag blev mycket glad när jag hörde att schweizarna sa nej i folkomröstningen om att köpa Gripenplan av Sverige. För oavsett om det innebär en förlust eller ej för Sverige rent ekonomiskt borde man inte ha investerat i krigsutrustning vars syfte är att döda människor från första början. Vi bor i ett land där vi i många frågor anser oss vara eller försöker agera som ett föredöme. Så borde vi även göra här. Om vi nu är så bra på teknik och innovation i Sverige borde vi väl lägga vår energi på bättre saker?

Jag hade den här diskussionen tillsammans med en kollega över en bit mat tidigare idag. Av någon anledning var vi inne på kärnkraftens varande eller icke varande – vi var båda rörande överens om att den borde avvecklas på sikt – och i samband med det sa han något jag fastnade för. Han sa något i stil med följande.

Varför inte sluta att lägga energi och stora pengar på att utveckla dödsmaskiner och istället lägga vårt tekniska kunnande på att fundera över vettiga alternativ till just kärnkraften?

Man kan försöka argumentera för vapenindustrin hur mycket man vill. Man kan hävda saker som ”om inte vi gör det gör någon annan det” eller ”om vi inte ligger i framkant kommer ryssen och tar oss”.

Men i slutändan måste det väl ändå handla om vilken värld vi vill bidra till. För mig är valet mellan vapen och hållbar energi enkelt.

Setters under ansvar

För många systemutvecklare är det jag nu tänker skriva om något vedertaget – bok efter bok förklarar varför man inte ska ägna sig åt det – men för andra verkar det inte vara det vilket ligger till grund för detta inlägg. Det jag pratar om är det där med att peta in setters på attribut i sina klasser bara för att man kan, något som enligt mig (och andra) i de flesta fall är snudd på kriminellt beteende. I vissa avseenden kan det väl vara ok – jag tänker då på primitiva databärare som enkelt ska kunna serialiseras och deserialiseras – men dessa ska ses som undantagsfall.

Varför? Jo, därför att man skapar en state machine från helvetet. Vad menar du nu? Jo, ponera följande klassdefinition. Ni får försöka låta bli att irritera er på den något retarderade klassen och dess attribut – exemplet syftar bara som underlag för att få fram min poäng.

public class Car {
   private String regNumber;
   private String model;
   private Owner owner;
   private Date ownerRegisteredDate;
}

Låt oss säga att vi slänger in publika getters och setters på alla attribut. Om vi nu tänker oss att varje attribut har två möjliga tillstånd – satt eller icke satt – kan vi räkna ut totalt antal möjliga tillstånd som instanser av klassen kan befinna sig i. Med endast fyra attribut landar vi på 2*2*2*2 = 16 möjliga tillstånd. Och nu snackar vi bara om huruvida attributen är satta eller ej. Tänk er att vi kastar in ett attribut till – en enum med fem möjliga tillstånd – och vi landar på 16*5 = 80 möjliga tillstånd. Ja ni ser vart jag är på väg.

Nu pratar jag dessutom bara om möjliga tillstånd vilket inte är samma sak som giltiga tillstånd. Är tillståndet i en instans giltigt om alla attribut har värdet null? Skulle man kunna tänka sig att det alltid bör finnas ett regNumber på en bil? Borde det inte alltid finnas ett ownerRegisteredDate om owner är satt?

Med setters på allt kan man inte dra sådana slutsatser. Designen begränsar därmed domänmodellens potential och man degraderar dess klasser till beteendelösa databärare vars tillstånd man underhåller med logik i servicelager och validatorer. Hela grejen är bara så fel.

I synnerhet som det finns så enkla lösningar med vilka man kan komma ganska långt.

Låt oss säga att ovanstående klass alltid måste ha ett regNumber satt. När en ny bil registreras måste man dessutom ange model. Det finns inga krav på att model någonsin ska ändras. Låt då bli att lägga dit en setter! Vidare kan en bil ha en ägare (owner) med ett startdatum för ägandeskapet (ownerRegisteredDate). Dessa kan komma att ändras över tid. Här behöver vi någon konstruktion som låter oss sätta dessa värden. Vi tittar på hur en enligt mig mer sund klassdefinition skulle kunna se ut:

public class Car {
   private String regNumber;
   private String model;
   private Optional<Owner> owner;
   private Optional<Date> ownerRegisteredDate;

   public Car(String regNumber, String model) {
      this.regNumber = checkNotNull(regNumber);
      this.model = checkNotNull(model);
   }

   public void registerOwner(Owner owner) {
      this.owner = Optional.of(checkNotNull(owner));
      this.ownerRegisteredDate = Optional.of(new Date());
   }

   public void deregisterOwner() {
      this.owner = Optional.<Owner>absent();
      this.ownerRegisteredDate = Optional.<Date>absent();
   }
}

Det ska tilläggas att jag i ovan exempel använder Preconditions från Guava och Optional från Guava/Java 8 för att få koden mer läsbar. Koden är dessutom skriven på frihand så jag reserverar mig för syntaxfel. Jag har även utelämnat eventuella getters. Men min poäng är ändå att vi här endast har två möjliga tillstånd för instanser av denna klass. För att förtydliga detta tittar vi i nedanstående tabell. Varje rad anger ett tillstånd och x markerar att attributet har ett värde.

regNumber model owner ownerRegisteredDate
x x
x x x x

Vi går alltså från 16 möjliga tillstånd till endast två. Dessutom är dessa två tillstånd även giltiga. Vi vet att regNumber och model alltid har ett värde och att de aldrig kommer att ändras. Vi vet också att owner och ownerRegisteredDate endast kan existera och ändras tillsammans. Med enkla medel och avgränsningar på rätt ställe kommer man väldigt långt.

För den intresserade vill jag återigen lobba för Eric Evans bok Domain-Driven Design: Tackling Complexity in the Heart of Software. Alla borde läsa den.