Varför man inte ska bekämpa SD med odemokratiska medel

september 22, 2010

Sverigedemokraterna har fått sin hemsida hackad och en stulen namnlista har publicerats. Detta är en kort fundering om varför jag inte tror att det är ett bra sätt att minska Sverigedemokraternas inflytande på.

I Sverige har vi åsiktsfrihet, yttrandefrihet och röstskydd. Hindrar man någon från att utöva dessa fri- och rättigheter måste man förstå att man bryter mot grundläggande demokratiska principer, och dessutom anse att detta offer är mindre betydelsefullt än det man hoppas uppnå. Man har med andra ord en ganska tung uppgift att motivera sitt handlande när demokratiska rättigheter ligger i ena vågskålen.
Det var den hobby-filosofiska sidan.

Om man nu ska motivera sitt handlande gäller det att komma fram till vad man tror sig kunna uppnå. Kommer SD på något magiskt sätt att upphöra om man gör deras hemsida otillgänglig? Kommer de som röstat på SD på något magiskt sätt att ta tillbaka sina röster? Tvärtom tror jag bara man spelar SD i händerna genom att hindra dem från sina demokratiska rättigheter; det är med andra ord rent kontraproduktivt. SD är ett parti som attraherar de som känner sig exkluderade av det etablerade politiska partierna. SD frodas i martyrskap. Att ge dem mer vatten på sin kvarn genom att vägra dem sina demokratiska rättigheter kommer bara att göra dem starkare ”Vad var det vi sa”, och locka fler väljare.
Vad ska man göra då? Bemöta dem med demokratiska medel såklart; dra fram unkna åsikter i ljuset, dissekera argument och ställa till svars. Men också förstå vad missnöjesröstarna är missnöjda med. Jag tror inte att 5,7% av Sveriges befolkning är ideologiskt övertygade sverigedemokrater, det är många av dem som bara anser att SD är bästa sättet att visa sitt missnöje. Och det kan man ändra på.

Andra med ungefär samma tankar:
Soran Ismail: Visa respekt för Sverigedemokraternas väljare
jardenberg kommenterar – 21 Sep, 2010

”Location based service”. Var vänlig välj.

augusti 27, 2010

Tänkte jag skulle hoppa på tåget och köra någon här-är-jag ”Location Based Service” på min mobil. Inser att det finns en uppsjö alternativ (Foursquare, Gowalla, Brightkite, Lattitude, Facebook Places …) och att det inte finns något val som är helt fel, men inte heller är det något som är självklart rätt. Antagligen blir det som med sökmotorerna; först fanns det en uppsjö varianter, sen kom metasökmotorerna och till sist nådde en specifik sökmotor en kritisk massa och alla andra dog. Längtar dit!

Tills dess, titta till exempel på Jämförelse Foursquare-Gowalla Gowalla eller Foursquare – hur ligger det till

Generationsklyftor

maj 20, 2010

I flera av intervjuerna i boken ”Secrets of a Rock Star Programmer” (Ja, det är en samling intervjuer med duktiga utvecklare) diskuteras om hur de som nu utbildas till programmerare saknar vissa, enligt de intervjuade viktiga kunskaper, eftersom de aldrig har använt X (typ emacs) för att Y (typ skriva sin egen tcp/ip-stack). Ett ganska tramsigt synsätt som en äldre generation alltid har haft på en yngre. Men när jag läser det kommer jag ihåg vad jag själv konstaterade när jag började läsa datateknik under första halvan av 90-talet; det som intresserade mig inom datateknik var inte alls samma saker som hade fått mina lärare att studera ämnet. Och när jag tänkte närmare på det var det alldeles självklart varför det var så. Utvecklingen går helt enkelt så snabbt att ett datatekniskt intresse betydde en sak på 80-talet, en annan på 90-talet och självklart ytterligare en sak år 2010. Medan jag var intresserad av den skapande delen av programmering verkade många lärare lockats mer av själva hålkorten än programmeringen man skulle ha dem till. Och hur skulle det kunna vara annorlunda? Under min tid har aldrig hårdvaran varit något man behövt ta särskilt mycket hänsyn till och aldrig något jag varit intresserad av, medan hårdvara under hålkortens tid var en så väsentlig bit att ett intresse för det antagligen var nödvändigt för att härda ut.
Och vad innebär då det? Jo, precis som inom alla andra yrken kan en generationsklyfta vara i vägen vid kommunikation även inom datatekniska yrken. Och eftersom generationsklyftorna kommer så mycket oftare blir kommunikationsproblemen också så mycket vanligare. Det gäller till exempel när högskolor ska försöka locka till sig datateknikstudenter, när it-företag ska utforma anställningsannonser, när anställda på en utvecklingsavdelning ska försöka samarbeta.

Språk och programmering

maj 2, 2010

I ett avsnitt av Filosofiska rummet i SR P1 handlade det om ”… hur språkbruket påverkar vårt sätt att tänka”. En hel del i sig tankeväckande aspekter diskuterades, men särskilt intressant tycker jag det är att man lätt kan se att mycket av dessa diskussioner om vårt vardagliga tal- och skriftspråk också är direkt överförbart på  hur vi använder ord för att namnge saker när vi modellerar och programmerar.
Två exempel från programmet:

På en fråga om tvåspråkighet och hur man använder olika språk i olika sammanhang kom man in på ordet ”ångest”. Den danska sångerskan i studion hade förstått att man i Sverige kan använda det ordet på ett ganska avslappnat sätt, till skillnad från i Danmark där ”angst” endast har den tunga medicinska innebörden. Lingvisten Sven Strömqvist kunde då berätta att man gjort försök som visat att att det var mätbara skillnader i hur mycket hjärnan var tvungen att arbeta när man man utsatte försökspersoner för entydiga respektive mångtydiga ord. Inte särskilt konstigt kanske eftersom hjärnan måste se till att undertrycka alternativa betydelser och associationer. Men anpassat till vår modellerings- och programmeringsvärld innebär det att det faktiskt är mätbart viktigt att man använder så exakta och lättolkade benämningar som möjligt för att underlätta både för sig själv och andra. Det gällar att inte bara hitta beteckningar som kan tolkas rätt, utan beteckningar som bara kan tolkas rätt!

Sven Strömqvist berättade också att det finns forskning som visar att försökspersoner som får ta del av en berättelse med mer precisa ordval kommer ihåg mer av berättelsen än försökspersoner som fått ta del av berättelsen med mer allmänna ordval. Exemplet i programmet var att en uggla beskrevs som att den antingen flaxade ut ur sitt bo eller bara lämnade det. Bättre, mer precisa ordval i vår programmeringsvärd borde därmed också göra det enklare för oss själva och andra att komma ihåg modeller och programkonstuktioner!

Självrannsakan: Inversion of Control bara för testbarhetens skull? Och vadådå, skulle det vara så farlig?

februari 11, 2010

När man skriver kod som ska enhetstestas är det lätt att hemfalla åt att slentrianmässigt se till att injicera beroenden i en klass istället för att kapsla in dem, bara för att man vet att klassen kommer att bli lättare att testa. Som allt annat man gör slentrianmässigt finns det såklart en fara i det, själva definitionen av slentrian innebär att man gör något utan att tänka efter.
Så för att förhoppningsvis stilla den gnagande känslan av oro tänkte jag i alla fall för mig själv fundera igenom vad jag tycker. Det handlar alltså om hur IoC står i förhållande till inkapsling. Är det alltid ok att injicera beroenden i sin klass?
Man kommer kanske lätt undan om man kan motivera injiceringen med att man på sätt och viss bara följer strategy-mönstret. I ärligheten namn kräver detta att man faktiskt har tänkt sig att injicera olika implementationer av beroendet även utanför testkoden. Ett annat fall där det känns designmässigt korrekt att bryta ut beroendet är när man kan motivera det med någon form av loose coupling (svag koppling? ) eller separation of concerns.
Men om man till slut kommer fram till att man skulle vilja använda IoC primärt för att göra en klass testbar så har jag bestämt mig för helt enkelt se på det pragmatiskt; visst bryter man inkapslingen och då gäller det att väga nackdelarna med detta mot fördelarna med ökad testbarhet. Om man ser på inkapslingen som ett sätt att göra det svårare för programmerare att använda en klass ”fel”, det vill säga genom att injicera ett annat beroende än vad som ursprungligen var tänkt, så håller jag med min förre detta kollega Göran Krampe som en gång konstaterade något liknande ”Jag har sett mer problem med klasser där man inte fått göra det man vill  än med klasser där man får”. Det ligger väl i linje med idén om att man måste lita på att de som ska använda ens kod vet vad de sysslar med. Med detta sagt så är det naturligtvis inte så att testbarhet alltid går före inkapsling. Snarare gäller det att vid varje tillfälle ställa dessa två mot varandra och känna efter vad som är viktigast. Och min känsla är att testbarheten ofta i praktiken är mer värd än inkapslingen.

Digital verklighet

december 4, 2009

Många försöker få ihop den fysiska, ”vanliga” världen och den digitala.  Här är en MIT-kille som tänkt lite längre… och imponerande enkelt (typ två datormöss och en webbkamera) byggt en fungerande liten manick som visar vad man kan åstadkomma. Här är framtiden!

http://paul.kedrosky.com/archives/2009/11/ted_talks_livin.html

DDD i uppdragsbeskrivningar

september 6, 2009

Hmmm… Som konsult har jag hitintills aldrig sett en uppdragsbeskrivning som nämner något om domändriven design och inte heller tror jag att jag någonsin sett en jobbannons där ddd efterfrågas… Som Niclas Nilsson helt riktigt kommenterade när jag tog upp frågan på den svenska ddd-listan så brukar det ju i och för sig aldrig nämnas något om designkunskaper i annonser. Så är det förstås, men ddd är en begreppsvärld och att försöka genomföra ett projekt utan ddd-kunniga projektmedlemmar känns väldigt svårt. om jag satt som ddd-intresserad arkitekt/modellerare/programmerare/whatever och ville ta in extern hjälp så skulle jag nog lägga större vikt vid de sökandes ddd-intresse än om de var gurus på ramverket si-och-så i version så-och-si.
Men det kommer väl. Kanske.

Events och domändriven design

juli 1, 2009

Flera av sista tidens diskussioner om ddd har det gemensamt att Events-hantering är en central del. Kanske är det bara en slump, men det verkar som om events är på väg att bli en viktig de facto-byggsten inom ddd.

Greg Young har visat hur han byggt ett börshandelssystem med en kombination av Event Sourcing och det som kommit att kallas ”Command Query Separation (CQS) at the architectural level” (till skillnad från ”vanlig” CQS). Genom detta har han skapat ett mycket skalbart och dynamiskt system med tillförlitlig audit.

Udi Dahan skriver om ”Domain Events” som ett sätt att lösa det ofta diskuterade problemet med hur domänobjekt ska få tillgång till service-klasser.

Eric Evans har själv uttalat sig om Events som en av de saker han nu lägger mer vikt vid än när han skrev Boken.

Nytt hem

juni 30, 2009

Här finns jag nu. Några gamla inlägg finns på

http://blog.msc.se/blogs/index.php/bitforbit/