Wooohoo! Efter ganska precis ett års periodiskt slit är jag äntligen Microsoft Certified Professional Developer inom Enterprise Applications (.NET 2.0)! I praktiken betyder detta att jag är en av de knappt 4.500 i världen som har orkat släpa sig igenom de fem proven och att Avanades certifieringskrav är uppfyllda för min del. FREEEEDOOOOOM!

Okej, detta var kanske det coolaste och bisarraste jag sett under hela förmiddagen: en dator (tunn klient) som är ungefär lika stor som ett eluttag. Det är kanske framtiden, att ha datorn i källaren och sådana här uttag lite här och var där det passar? Undrar hur det skulle funka med CoD4…

Läs mer och se bilder på produktens hemsida.

Jag tyckte att de rena programmeringskurserna under min civilingenjörsutbildning i medieteknik ofta var ganska fantasilösa. Visst, man behöver gå igenom teorin ordentligt och det blir lätt lite torrt, men det kan man ta. Sedan finns det nästan alltid en labbserie, och där har läraren alla möjligheter att ta ut svängarna och hitta på något som inte är torrt. Men det gör hon eller han mycket sällan.

Jag minns ett undantag, och det var inte i en programmeringskurs. I kursen ”Kompression av ljud och bild” fanns det en labb som gick ut på att på valfritt sätt komprimera (duh) en ljudfil så att storleksminskningen blev så stor som möjligt medan kvaliteten skulle hålla sig över en viss nivå. Sedan när man kände sig klar så skickade man in sina resultat och sin Matlabkod och läraren uppdaterade en topplista över alla labbgruppers prestationer. I och med att man kunde se topplistan hela tiden så var det lätt att bara sitta en liiiten stund till och tweaka för att klättra några placeringar. Kom man på en smartare lösning i efterhand gick det bra att skicka in nya resultat.

Nyckelorden här tycker jag är ”valfritt” och ”topplista”. Eftersom det hela var en (vänskaplig) tävling så var det roligt att försöka förstå vad det var man faktiskt gjorde och lägga ner energi och tid. Och visst, en del var säkert helt ointresserade och bara skickade in första bästa godkända resultat, och det är ju såklart helt okej. Men jag tror många gottade sig utmaningen.

Utmaningen är det som saknas i många programmeringslabbkurser tycker jag. Visst, ibland är uppgifterna svåra, men det finns oftast ett sätt att lösa dem som är det bästa eller det som läraren tänkt sig (och det som labbassistenten kommer att peka dig mot om du frågar). Om uppgifterna istället var lite friare och lockade till kreativt tänkande så tror jag många skulle få ut mer av hela kursen.

Anledningen till att jag överhuvudtaget kom att tänka på detta nu är att jag för några veckor sedan fick nys om Google Treasure Hunt. Detta är en skattjakt för programmeringsintresserade, skulle man kunna säga. Deltagaren ställs inför miniuppgifter av stigande svårighetsgrad – det kan handla om att dekryptera en ledtråd eller att räkna ihop tal som gömmer sig i filer med särskilda namn i en stor struktur, eller något helt annat. Det hela är etappbaserat, så nya utmaningar publiceras efter hand. Man kan se det som en tävling (Google delar ut pris till de som är snabbast) eller bara gotta sig åt att klura på problemen i sin egen takt.

Jag har själv inte genomfört Googles skattjakt, men jag tilltalas verkligen av konceptet. Skulle man inte kunna ha något liknande som en slags labbserie som löper under kanske en hel termin, med nya utmaningar typ varje eller varannan vecka? Man lägger den kanske andra eller tredje året på utbildningen så att studenterna har hunnit lära sig grunderna och har de verktyg som behövs. Kan det funka?

Jag har under den senaste månaden jobbat på en webbsajt som ska ligga på ett konto på webbhotellet Loopia. Jag gillar verkligen Loopia, de har bra support, schyssta priser/tjänster och är trevliga att ha att göra med. Tidigare har jag mest kodat webb i PHP, men eftersom jag numera enbart sysslar med .NET i mitt vanliga jobb tänkte jag att det är lika bra att jag kör på med en teknik även på min egna tid. Man lär sig ju grejer hela tiden, och det känns effektivast att koncentrera sig på ett spår i taget.

Hursomhelst! Från och med version 5 finns det stöd för stored procedures i MySQL. Och MySQL har till och med varit så vänliga att de utvecklat en ADO.NET-provider som är specialanpassad för kommunikation just mellan .NET-applikationer och MySQL-databaser. Loopia tillhandahåller den senaste versionen av denna komponent på sina servrar. Bra förutsättningar för att utveckla seriösa webbapplikationer av medelstorlek alltså.

När jag utvecklat den här webbplatsen har jag kört den lokalt och låtit den gå mot min egen Loopia-databas. Det har funkat mycket bra och har fördelen att jag kunnat sätta upp en testsajt på mitt Loopia-konto också, med samma databas, som jag kunnat låta valda personer ha tillgång till.

Nu inför lanseringen av webbplatsen laddade jag upp den till det Loopia-konto där den ska ligga, satte upp databastabeller och stored procedures i kontots databas och tänkte att det borde funka smärtfritt från början just eftersom det är samma webbhotell och funkat så bra innan. Där bedrog jag mig!

När man gick in på en sida som anropar en stored procedure möttes man av följande glada meddelande från MySQL Connector/NET:

Unable to retrieve stored procedure metadata. Either grant SELECT privilege to mysql.proc for this user or use ”use procedure bodies=false” with your connection string.

Vad var nu detta? Jag hade ju skapat en databasanvändare speciellt för webbapplikationen, med precis de rättigheter som ska behövas. Och det kunde inte vara något fel på applikations- eller stored procedure-koden, för det hade ju funkat fint i utvecklingsmiljön, som är mycket lik produktionsmiljön.

Efter att ha bankat huvudet i väggen en stund gick jag in och tittade på ROUTINES-tabellen i information_schema-databasen som hör till varje MySQL-databas. Där kunde jag se att mina stored procedures fanns upplagda korrekt, att det var ett särskilt administrationskonto som skapat dem – ett konto som jag själv lagt upp just för detta – och även att något som heter SECURITY_TYPE var satt till ”DEFINER” på samtliga stored procedures. Det sistnämnda verkade intressant! Efter ett par snabba tester kunde jag konstatera följande:

I Loopias MySQL-konfiguration är det endast den databasanvändare som skapade stored procedure:n som kan exekvera den.

Är det smart eller bara irriterande? Jag är nog inte rätt person att bedöma det, men jag vet att det tog en stund för mig att lista ut det.

Uppdatering: Felmeddelandet jag fick ovan antydde att man kunde lösa det genom att ge SELECT-rättigheter för tabellen mysql.proc till aktuell användare, alternativt använda parametern use procedure bodies=false i sin connectionstring. Eftersom man sällan har möjlighet att dela ut godtyckliga rättigheter till höger och vänster om man använder ett webbhotell så testade jag det andra alternativet. Och det funkade! Det man måste tänka på då är att alla parametrar man skickar in till sina stored procedures måste anges i rätt ordning (alltså den ordning som stored procedure:n förväntar sig dem) och med rätt datatyp. Detta eftersom man helt går förbi den kontroll av parametrarna som annars görs av MySQL med hjälp av tabellen mysql.proc.

En annan lurig grej med Loopia har att göra med omstarter av ASP.NET-applikationer. I normala fall håller ASP.NET koll på om de filer som ingår i en webbapplikation ändras, varpå applikationen startas om så att ändringarna blir verksamma. Det kan handla om allt ifrån en ny version av källkoden till en enkel justering av ett parametervärde i en konfigurationsfil. Att hela denna apparat är nödvändig har att göra med att en ASP.NET-sajt faktiskt är kompilerad kod, till skillnad från exempelvis en PHP-lösning, där det rör sig om script som parsas när de efterfrågas. I normala fall fungerar det hursomhelst bra, även om själva omstarten/kompileringen av applikationen oftast innebär att besökaren/användaren får sitta och vänta några extra sekunder vid just det anropet.

Men på Loopia fungerar det inte så här. Enligt dem själva använder de en stor NAS där allt kundmaterial ligger – alltså alla webbapplikationer. Tydligen är den filstrukturen för omfattande för att ASP.NET ska kunna övervaka alla ändringar som görs (låter inte helt ologiskt), vilket rent funktionellt inneb¤r att den här omladdningsfunktionen helt är satt ur spel. Som ett alternativ finns det en automatiskt recycle-process som körs ungefär var 26:e timme, då applikationerna laddas om oavsett om det egentligen behövs eller inte.

Men det duger ju inte om man sitter och utvecklar eller testar en sajt! Vadå, ska man ladda upp filerna, konstatera att man råkat missa en inställning i Web.config och sedan vänta i upp till 26 timmar på att en korrigerad version ska börja användas av sajten? Det är naturligtvis helt ohållbart.

För att försöka lindra frustrationen har Loopia utvecklat en funktion i den kontrollpanel som man som kund har tillgång till där man manuellt kan begära en omladdning. En enkel knapptryckning så läses de aktuella versionerna av filerna in i minnet. På Loopias supportforum står det:

”…i Loopia Kundzon kan du själv begära att ASP.NET-applikationen ska laddas om, exempelvis efter att du gjort en ändring.”

Då är ju allt bra! Eller är det? När jag har använt funktionen har jag ofta upplevt ett märkligt beteende hos applikationen. Ibland laddas den verkligen om och får de senaste uppdateringarna, men om man sedan startar om den igen så kan den gå tillbaka till en gammal version. Och ibland verkar ingenting alls hända. Trots att det mycket tydligt står i kontrollpanelen att ”applikationen startades om med ett lyckat resultat”.

Efter korrespondens med Loopia har de bekräftat att funktionen inte alls fungerar som det står på supportsidorna. I verkligheten fungerar den bara en gång per recycle-intervall, vilket alltså betyder att man kan använda den en gång var 26:e timme. Jag kan alltså som mest uppdatera mina webbapplikationer två gånger per dygn, ungefär. Vilken lyx!

Loopia hävdar att de jobbar på att få fram en mer hållbar lösning på detta problem, men att det inte finns något datum för när det ska vara klart. Vilket betyder att de lika gärna kunde säga att man får leva med det system som finns idag.

Jag skrev tidigare att jag skaffat ett konto hos Marginalen att använda som buffertkonto. Det ger för närvarande 4,75% ränta, vilket ju är bra. Nu har jag dock testat byta till Kaupthing Edge, där man för närvarande får 30 räntepunkter högre ränta än deras ordinarie sparränta om man öppnar ett konto innan 1 juli 2008 (eller redan har ett). Det innebär med nuvarande ränta 5,35% – alltså 0,6 procentenheter (eller cirka 13%) bättre än Marginalen. Räntebonusen på 30 punkter gäller till 1 juli 2009.

Det är enkelt att byta, så varför inte? Kontot är tillgängligt via en internettjänst vars första intryck var bra. Jag gottar mig.