Min blogglista

Jag har många gånger fått frågan vilka bloggar jag läser och jag har minst lika många gånger funderat på att skapa en liten "blog roll", en blogglista. Det som hindrat mig är att jag i så fall vill välja ut några verkligt speciella (för mig) och berätta lite om varje blogg och då har det genast blivit ett större projekt. Från och med i dag publicerar jag äntligen en början till en blogglista tillsammans med en kortare beskrivning av varje blogg i denna bloggpost. När jag i framtiden lägger till bloggar till listan kommer jag att försöka posta kort om vad den handlar om.

En snabb överblick i min bloggläsare (jag använder just nu två olika: RssBandit och Outlook 2007) visar att jag just nu prenumererar på ca 120 bloggar. Mer än hälften av dem läser jag så pass regelbundet att jag åtminstone skummar igenom allt som skrivs och de allra flesta skummar jag igenom då och då. Några ligger i frysboxen och väntar på att jag ska inse att jag inte kommer att läsa dem och avsluta prenumerationen. En annan kategori är proffsbloggare som Robert Scoble, TechCrunch och liknande som producerar så många inlägg att det nästan är en heltidssysselsättning att följa dem. Dessa skummar jag oftast bara igenom rubrikvis på jakt efter intressanta nyheter, information om spännande Web 2.0 start-ups m.m. Även med denna metod blir det snabbt svårt att komma i kapp om man inte lästa dem på några dagar. Då markerar jag bara den katalogen som "läst" och börjar om nästa dag.

Av alla dessa bloggar vill jag lyfta fram de jag personligen tycker är mest läsvärda, men huvudsakligen sådana som jag inte ser i så många andras blogglistor. Det innebär att bloggare som Johan Lindfors, André Henriksson, Dag König, Scott Guthrie och andra microsoftare inte finns med på listan eftersom jag räknar med att den som hittat till min blogg redan känner till dem. Och om man inte gör det så återfinns de ändå refererade tillräckligt frekvent i min blogg för att man ska hitta till dem förr eller senare.

Nåväl, här följer en kort presentation av några av de bloggar jag tycker är mest intressanta just nu:

Coding Horror: Jeff Atwood har valt en symbol från Steve McConnells bok "Code Complete" som titel för sin blogg och det är tydligt att McConnell är en viktig inspirationskälla. Atwood är i sin blogg lika mycket av en eklektiker och skriver ingående och inkännande om allt som har med programmering och datorer att göra. Det som särskiljer Coding Horror från många andra tekniknörd- och programmeringsbloggar är Atwoods vurmande för och kunskaper om de mänskliga faktorerna och processerna. Tekniska (men begripliga!) utredningar kring hur slumptal genereras och ingående jämförelser mellan olika processorer blandas med insiktsfulla texter om användargränssnitt och tankar kring vilka egenskaper en bra utvecklare bör besitta.

Inside Architecture: Nick Malik är verksamhetsarkitekt på Microsofts Enterprise Architecture, enligt honom själv "probably the best work on the planet" inte minst eftersom man får jobba med "some of the most experienced and varied folks you can imagine". Malik är naturligtvis en mycket erfaren och kompetent person själv och skriver mycker initierat om två av mina favoritämnen: Serviceorienterad Arkitektur (SOA) och Objektorienterad Analys och Design (OOAD). Jag har länge haft svårt att hitta bra böcker och texter om praktisk erfarenhet av att implementera SOA-lösningar, men Inside Architecture fyller en del av detta tomrum.

Dare Obasanjo: Obasanjo är Program Manager för ett av teamen i Microsofts Windows Live, bland annat ansvarig för utvecklarsajten http://dev.live.com/. Han ägde tidigare XML I/O- och Schema-API:erna i .NET Framework, liksom XSD-implementationen och står med anledning av detta för en del kommentarer angående XML i Framework Design Guidelines. Tillsammans med Torsten Rendelmann har han utvecklat en av de RSS-läsare jag använder: RSSBandit.

Dare Obasanjo skriver mycket intressant om Web 2.0, men han skulle förmodligen inte gilla att jag skriver så eftersom han inte är så förtjust i begreppet. Han skriver dock ofta och gärna om AJAX, "social software", "web startups", webbsatsningar från "GYM" (Google-Yahoo-Microsoft) och andra tydliga "Web 2.0"-ämnen. Jag ser hans blogg som en mer kritisk, mer fokuserad, lite argare och mer webbinriktad Robert Scoble som blivit ännu mer intressant att läsa sedan Scoble lämnade Microsoft.

Om du inte hört talas om honom tidigare men tycker att namnet låter bekant kan det bero på att han är son till Nigerias nuvarande president, Olusegun Obasanjo.

Julie Lerman: En kvinnlig .NET-utvecklare med ett lite annorlunda anslag och perspektiv. Medan många andra bra bloggar ibland kan upplevas som super-experter som talar till oss vanliga dödliga, känns det som om Julia Lerman är en av oss och talar med oss. Det betyder absolut inte att hennes blogg är mindre intressant. Hon brottas med samma problem som många andra, till exempel har hon på sistone publicerat en serie inlägg där hon brottas med att förstå ADO.NET Entity Framework och LINQ. Hon har en prestigelös attityd och är bra på att förmedla saker på ett rakt och enkelt sätt.

Lerman har nyligen bytt bloggmotor. Missa inte hennes gamla bloggposter.

Det får räcka med bloggtips vidare. Fortsättning följer.

SOA - rena fakta

Äntligen en riktigt bra förklaring till SOA... ;-)

http://soafacts.com/

(Via Patrik Löwendahls blogg.)

Mer om .NET properties

Sedan jag skrev om att använda .NET properties istället för get- och set-metoder och varför det är en god praxis att använda properties istället för publika medlemsvariabler, har ämnet diskuterats en hel del i bloggosfären. Bland annat Eric Gunnerson har skrivit ett inlägg och en uppföljning där han lutar lite mot publika medlemsvariabler, Jay Bazuzi håller mer än helhjärtat med och Jimmy Nilsson instämmer. Chris Hedgate köper inte argumenten, en ståndpunkt han delar med flera kommentatorer på Gunnersons blogg. Alla påpekar förstås att det beror på kontext och hela diskussionen kan förefalla vara hårklyveri. Trots detta, eller kanske just därför, kan jag inte hejda mig själv från att fortsätta delge er mina synpunkter i frågan.

Flera förespråkare av publika medlemsvariabler hänvisar till Rico Morianis prestandaargument som jag redan tagit upp i min andra uppdatering i mitt första inlägg (längst ned). Den prestandaförlust och den marginellt större assemblystorlek som kan bli följden av att använda properties måste i de allra flesta fall anses vara försumbar. Denna princip kan i alla fall inte gälla som tumregel utan måste i så fall snarare ses som förhastad optimering och som Donald Knuth sa:

"Premature optimization is the root of all evil (or at least most of it) in programming."

Gunnersons andra invändning, att properties som används "just in case" innebär "extra clutter in the class", äger väl viss tyngd, men det är enligt min mening dels något av en vanesak, dels något som kan hanteras av regions och andra sätt att strukturera sin kod. Dessutom kommer man från och med nästa version av C# och VB.NET kunna deklarera properties mer koncist.

Bazuzi vidareutvecklar Gunnersons argument om det onödiga i att använda properties bara för säkerhets skull; om man använder properties bara för att undvika att bryta binär kompatibilitet, varför då inte som tumregel också alltid använda en factory method som returnerar ett interface istället för att använda konstruktorer? Då skulle man i framtiden kunna byta ut vilket objekt som returneras utan att bryta binär kompatibilitet. Bazuzi förväntar sig att man ska välja allt eller intet:

"If you still believe that you need to use properties in the trivial cases, I hope you will examine these constructs and consider them seriously in your own code.  I suspect you should be choosing all or nothing."

Den här typen av argument brukar kallas "reductio ad absurdum" och kan vara intressanta i formallogik, men använt på det här viset är det inte mycket mer än ett retoriskt knep; bara för att man argumenterar för att det är säkrast att använda properties som tumregel innebär det inte per automatik att man måste göra allt annat som står i ens makt för att bibehålla binär kompatibilitet. Att använda en factory method för att returnera ett interface är betydligt mer "clutter in the class" än properties, det är ett betydligt mindre vanligt koncept och förstås inte naturligt av alla utvecklare på samma sätt som properties. En bästa praxis betyder inte att man aldrig någonsin får bryta mot den, utan den är ett stöd inte minst för de som inte är fullt medvetna om konsekvenserna av att avvika från den. Därför anser jag fortfarande att properties är bästa praxis.

Jimmy Nilsson hos Avega (eller Svenska som allestädes närvarande språk)

Härom veckan gästades Avega av Jimmy Nilsson som talade lite om Test-Driven Development (TDD), Domain-Driven Design (DDD) och O/R-mappers. Det var en ganska lättillgänglig introduktion, inte minst om man läst hans senaste bok, men frågor och diskussioner var (som alltid på Avega) riktigt intressanta. Eftersom många aveganer i publiken var Java-människor fanns det ganska mycket kunskap om DDD och O/R-mappers i rummet. En intressant fråga som dryftades och som jag själv funderat mycket på var om man i regel bör använda svenska för ett projekts "ubiquitous language".

En förklaring av "ubiquitous language" kanske kan vara på sin plats för den som inte är bekant med DDD. Ett "allestädes närvarande språk", för att prata svenska, är en central ingrediens i DDD. Eric Evans understryker i sin bok "Domain-Driven Desgin: Tackling Complexity in the Heart of Software" vikten av en för domänexperterna och utvecklingsteamet gemensam modell och ett gemensamt språk:

"A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design. [...] Translation blunts communication and makes knowledge crunching anemic."

Lösningen är att tillsammans arbeta fram ett "ubiquitous language" som är mer fylligt och robust än den minsta gemensamma nämnaren för de olika språken och att verkligen konsekvent använda detta språk i allt som har med projektet att göra. Språket bör inbegripa allt från klassnamn och viktiga operationer, verksamhetens termer för att diskutera explicita affärsregler och till och med designmönster (och andra typer av mönster, t.ex. analysis patterns), som teamet tillämpar på domänmodellen. Det bör användas när utvecklare och domänexperter kommunicerar med varandra, men också i utvecklarnas egna grupp för att beskriva system, uppgifter och funktionalitet, liksom i domänexperternas egna kommunikation och arbete med krav, featurelistor m.m. Refactoring av koden kan leda till refactoring av språket och när språket ändras måste klassdiagrammen anpassas, klasser och metoder döpas om. På samma sätt som "continuous integration" är en bästa praxis bör man enligt Evans även tillämpa något han kallar "conceptual integration":

"Constant exercise of the UBIQUITOUS LANGUAGE in discussions of the model and application."

Åter till Jimmy Nilsson och diskussionen om svenska. Även om man inte känner till DDD eller har dragit samma långtgående och djuptänkta slutsatser som Evans och andra DDD-förespråkare, är det lätt att känna igen problematiken och behovet av ett gemensamt språk; jag har själv funderat mycket på detta och gillar därför verkligen hur en gemensam modell och "ett allestädes närvarande språk" ges en så pass central roll i domändriven design. Och utifrån denna roll är det åtminstone för mig uppenbart att modellen och språket, liksom i förlängningen därmed även koden, bör vara på svenska för svenska projekt i svenska verksamheter.

Alla åhörare var emellertid inte överens om detta och jag vet från andra diskussioner att många till och med föredrar engelska för sina kommentarer och för dokumentation, så länge det inte finns uttryckliga önskemål om något annat. Ofta används argumentet att koden kan komma att sättas i händerna på engelskspråkiga utvecklare, inte minst med den växande offshoremarknaden. Det kan dock knappast vara så pass vanligt förekommande att man alltid skulle vara tvungen ta höjd för det till priset av alla problem språkförbistringen innebär (YAGNI!).

Ett problem med svenska har varit att man inte kunnat använda svenska tecken (åäö) i koden och att det därför minskat tydligheten, men det är inte längre något problem i moderna utvecklingsmiljöer. Lite värre är kanske att det i mjukvaruvärlden finns en hel del begrepp som saknar bra eller i alla fall naturliga svenska översättningar, t.ex. namn på designmönster (Factory, Composite, State etc) eller något så grundläggande som Set- och Get-prefix. Programmeringsspråk, befintliga ramverk och klassbibliotek har sällan (aldrig?) översättningar vilket leder till att man antingen måste blanda språken (KnappEvent) eller använda olika språk för ramverk och applikation(OnClickEvent, KnappHändelse).

Dessa invändningar är tämligen bagatellartade enligt min mening och förtjänsterna med att använda svenska, snarare än att tvinga domänexperter och utvecklare att hitta på mer eller mindre krystade översättningar, överstiger vida nackdelarna. Nu undrar väl alla vad Jimmy Nilsson tyckte, men det här är ju trots allt min blogg... Okej då, han skämtade först om att problemet enklast löses genom att avskaffa svenska språket och att han skriver på engelska för att slippa ta itu med problemet, men menade sedan att så länge vi måste dras med svenska bör det förstås vara regel snarare än undantag att använda svenska för sitt ubiquit... förlåt, allestädes närvarande språk.