Johan babblar på.

Det börjar bloggas om att det går att tanka ner Visual Studio 2008 från MSDN nu.
Med tanke på hur svårt det är att komma in på downloads-sidan stämmer nog ryktena…

…men jag hittar den inte ännu. Betan är däremot bortplockad. De håller säkert på och propagerar ut releasen till alla servrar.

I dag lyssnade jag på MSDN Radio där de pushade lite för svenska MSDN och för att de med MSDN Subscriptions borde bli bättre på att använda de gratis supportärenden som ingår i abonnemanget.

Jag har kontaktat supporten tre gånger och har ungefär samma intryck av alla försöken: Det tar för lång tid att komma i kontakt med någon som kan hjälpa till. Alla mina försök har berott på buggar i .NET Framework som jag inte fick reda på vid mina efterforskningar innan jag ringde Microsoft. Problemet jag fick var att ramverket inte är en produkt som står med på listan som första ledet i supporten har att tillgå. För att komma vidare fick jag helt enkelt hitta på ett fel i tex Visual Studio för att komma i kontakt med någon som kan titta på det riktiga felet och göra en ordentlig bedömning. Dessutom måste man, oftast, kunna isolera sitt problem i en liten applikation som man man skicka över till supportpersonen. Det kan ibland ta rätt lång tid att sätta upp en miljö som är så liten som möjligt och ändå återskapar felet. I ett av mina fall var det decimaltal som inte hanterade rätt av XMLConvert så det räckte med två rader kod. I ett annat var det en ASP.NET applikation som inte lyckades göra ‘impersonation’ i kombination med en specifik AD-installation. Det var betydligt svårare att återskapa.

Min erfarenhet är sålunda att man förmodligen hittar lösningen på sitt problem snabbare med MSN Search eller Google om man inte stött på en bugg. Det kan i och för sig bero på min ‘kan själv’-mentalitet, men jag tycker supporten är absolut sista steget innan man ger upp.

Eftersom jag i alla fall sitter hemma och pluggar Microsoft-teknik så passade jag på att titta in på ‘nya’ MSDN i Sverige och jag blev positivt överraskad. Jag kommer nog inte ha den som startsida, men den ligger helt klart med i veckoschemat. Bra gjort! Förut kändes svenska MSDN lite oengagerad, men nu känns MSDN lite mer närvarande på något sätt.

Försäkra dig om att dina automatiska, dagliga och kontinuerliga, byggen verkligen fungerar.

Det är precis som att kontrollera att dina backuprutiner fungerar. Du vill inte komma på att någon av dem slutat fungera när du verkligen behöver dem.

I helgen flyttades vår Team Foundation Server och allting såg ut att fungera som det skulle på måndagsmorgonen. Det var inga problem alls att ansluta till den nya servern och Cruise Controls lilla ikon sken betryggande grönt. Jag hade dock en lite oroande känsla av att något inte stod rätt till…..

…och se’n kom det; Konfigurationsfilen till Cruise Control var inte uppdaterad så den kontrollerade och byggde källkoden på den gamla servern.

Trasiga byggen suger och det borde vara en kollektiv uppoffring att hålla systemet i ett byggbart skick, men någon måste vara ansvarig för automatiseringen. Någon som kontrollerar att bygget fungerar.

Jag har ändrat uppfattning, men orkar inte skriva om det på svenska.

Microsoft försöker få Jamie Cansdale att ta bort funktionalitet från TestDriven.NET.

Jag tycker Microsoft gör riktigt fel. Kommer någon verkligen köpa Visual Studio för att de vill få TestDriven att fungera? De företag som är så snåla att de använder gratisversionerna i verksamheten kommer inte betala ändå. Det är fortfarande möjligt att köra sina unit-tester utan för Visual Studio så TestDriven.NET motiverar inte den kostnaden.

Om Microsoft är rädda för att det ska komma en massa andra tillägg till Express-versionerna borde de göra licensen tydligare. Det är inte så svårt att tala om att all utökning av produkten är otillåten. Om det dessutom är sant att de har samma licens för betal-versionerna så borde de stoppa alla tillägg som inte kommer via VSIP-programmet.

Det här sättet att behandla utvecklarsamhället får mig att använda SharpDevelop och MonoDevelop för all utveckling som jag inte gör under arbetstid.

Om alla studenter som funderar på .NET gör likadant så försvinner incitamenten att köpa Visual Studio när de börjar programmera som yrke. de kanske till och med hoppar av .NET-tåget för en annan utvecklings- och driftmiljö.

Jag var på Developer Summit förra veckan och gick mest på arkitekturspåret.
Ett genomgående tema var att vi (systemutvecklare och arkitekter) måste närma oss verksamheten. Ett annat tema var att man måste inse att det tas en hel del arkitekturbeslut på utvecklarnivå.

Det första temat av dessa är en sak som jag själv tagit för givet, men jag tror det beror på att jag jobbade flera år på en ekonomiavdelning innan jag blev systemutvecklare. De som blivit tekniskt skolade och egentligen aldrig sett system från ett process- och användarperspektiv måste förmodligen väckas, men om man anser att det är ett paradigmskifte att se systemutveckling som en möjliggörare av affärer så tycker jag att man nedvärderar en massa duktiga människor runt om i världen.

Det andra temat känns lite lösryckt utan en omfattande diskussion om vad arkitektur är. Vi använder i princip samma yrkestitel oavsett utövarens abstraktionsnivå. I ett sammanhang kallar man det arkitekturbeslut när man väljer mellan att använda statiska metoder eller en singleton och i ett annat sammanhang när man beslutar hur många geografiskt åtskillda datacenter man behöver.

Jag tycker, i princip, att man överlåter rätten att besluta saker nedanför sin egen abstraktionsnivå i samma stund som man lämnar över sin design till den som ska implementera. Jag skrev här att jag tycker en arkitekts roll är att samla ihop kunskap utanför sin organisation och sprida den inom sin organisation. Sett ur det här abstraktionsperpektivet gör det att nästan alla inom en systemutvecklarorganisation förväntas aggregera information och förmedla den till de som aggerar innom nästa abstraktionsnivå. I förlängningen betyder det även att man måste förmedla kunskap till den som står ovanför sig i abstraktionstrappan eftersom finkorniga implementationsdetaljer kan förhinda en optimal lösning.

Det handlar inte längre om att man kliver högre och högre ju duktigare man blir, det handlar om att hitta den abstraktionsnivå man trivs i och utveckla sig inom den.