Riktigt trevligt att Microsoft till slut börjar göra verklighet av planerna på att ”öppna Live Arcade” för amatörutvecklare. Alla spel som skickas in måste godkännas på något sätt (ännu ej definierat) vilket ju är helt vettigt. Undrar just hur mycket merarbete detta kommer att innebära för Microsoft…? Men men, nu kan man i alla fall säga att det finns en riktig anledning för hobbyister att börja titta på XNA Game Studio 2.0 – och kanske även något för kursansvariga på diverse universitetsutbildningar att ta hänsyn till?

FZ har skrivit lite om det hela här: http://www.fz.se/nyhetsarkiv/?id=23716

Tjoho! Jag är sedan ett par timmar tillbaka ”Microsoft Certified Technology Specialist: .NET Framework 2.0 Windows Applications”. Det går framåt!

Det finns ruskigt mycket man kan göra för att förbättra prestanda och skalbarhet i en webbsajt/webbapplikation. De senaste dagarna har jag på jobbet suttit och tittat på hur vi kan få front-end-delen av en av våra webbapplikationer att ”gå snabbare” – med avseende på ”upplevd prestanda”, ungefär.

Idag hittade jag en utmärkt ”checklista” som utvecklare på Yahoo har tagit fram just i syfte att optimera front-end hos webbsajter. De kallar den ”Best Practices for Speeding Up Your Web Site” och jag rekommenderar den som läsning för alla som sysslar med webbutveckling på någon som helst seriös nivå.

Sedan länge använder jag Firefox-tillägget Firebug som ett verktyg när jag kodar webb. Lämpligt nog finns det ett plugin till Firebug som utvärderar godtycklig webbsida mot just de 14 riktlinjer som tas upp i nämnd artikel och föreslår vad man kan göra för att förbättra sin prestanda. Grymt bra! Pluginet heter YSlow.

De tips som jag tog till mig och implementerade i vår applikation var framför allt:

• Aktivera HTTP Compression i IIS (på serversidan alltså). Detta innebär att när en klient requestar en fil kommer servern komprimera den med GZIP eller deflate före överföringen om klienten stöder det. Detta minskar förstås storleken på det som verkligen skickas med väldigt mycket och kräver bara en gnutta extra CPU-tid på server (och klient). Instruktioner för hur det går till finns exempelvis här.
• Förbättra cachningsmöjligheterna genom att sätta en Expires-tidpunkt som ligger långt fram i tiden (typ ett år framåt) för statiskt innehåll (bilder, Javascript, CSS-filer).
• Minskat antalet HTTP-requests genom att lägga ihop bakgrundsbilder från knappar och liknande till en och samma bildfil och sedan använda CSS-propertyn background-position för att välja ut rätt område bilden. Principen är ingen nyhet, men den är praktisk. Den beskrivs i detta blogginlägg.

Resultatet? Storleken för överförda filer minskade typiskt med 40-45% då besökaren har tom cache och med 65-70% då cachen innehåller så många av sidans komponenter som möjligt. Rätt grymma grejer om man vill minska trafiken och öka den upplevda hastigheten faktiskt.

Wohoo! För ett par timmar sedan klev jag glad ut på trottoaren efter att ha klarat Microsoftprovet 70-528, som tillsammans med det tidigare genomförda 70-536 ger mig en certifiering av klassen ”Technology Specialist” inom webbaserad klientutveckling i .NET Framework 2.0 (fullständigt, fett namn: Microsoft Certified Technology Specialist: .NET Framework 2.0 Web Applications). Det är allt en början, va?

Hela bakgrunden till det här är, som jag säkert tidigare nämnt, att min arbetsgivare (Avanade) kräver att alla nyanställda under en viss nivå på företaget ska ta certifieringen MCPD: Enterprise Applications Developer inom två år från anställning. De prov jag tagit är två av totalt fem som jag måste beta av. Och för att plåga mig själv lite extra har jag satt upp ett personligt (och dessvärre dokumenterat) mål att klara av hela karusellen innan sommaren i år.

Kul vår, Anders!

Jag tänkte att jag skulle dela med mig av några erfarenheter från mitt senaste miniprojekt som involverade WebBrowser-kontrollen i .NET 2.0. Ett par observationer som kan underlätta för andra som tänker använda kontrollen (eftersom dokumentationen på nätet inte är sådär otroligt utförlig):

• Eventet DocumentCompleted uppstår varje gång ett dokument är färdigladdat och renderat, vilket innebär att det triggas lika många gånger som det finns frames (eller iframes) på sidan. Om man har kod i eventhanteraren som ska manipulera eller tolka innehållet i det laddade dokumentet är det därför viktigt att man håller koll på vilket dokument det är man tar emot. Detta gör man enklast via WebBrowserDocumentCompletedEventArgs.Url.
• I .NET 2.0 krävs FullTrust-permissionset:et för att ett program ska få använda en WebBrowser-kontroll. Vad jag förstår så har detta justerats i 3.0 genom introducerandet av System.Security.Permissions.WebBrowserPermission, vilket naturligtvis är mycket bättre eftersom det då går att tagga ned lite på rättigheterna för programmet i övrigt.
• När man ska undersöka DOM-trädet eller HTML-koden för ett laddat dokument som innehåller frames/iframes så är det inte alltid som de element man söker efter finns med, även om de syns i browserfönstret. Jag tror att detta har att göra med hur IE (för det är dess motor som används) uppdaterar DOM-trädet för dynamiskt innehåll, eller något liknande. Däremot, om man vet vilken frame som de eftersökta elementen finns i så kan man leta sig fram till dem genom browser.Document.Window.Frames[frameIndex].Document. Detta HtmlDocument har metoder som exempelvis GetElementById som funkar, under förutsättning att det aktuella frame-dokumentet är laddat fullständigt. (Här har jag antagit att instansen av WebBrowser-kontrollen heter browser och att index för den intressanta framen är lagrat i frameIndex. Jag misstänker dock att förpopulerade samlingar som HmtlDocument.Links och liknande inte uppdateras korrekt för de olika frame-dokumenten. Vet inte varför, och jag kan inte med hundra procents säkerhet säga att det är på det sättet, men jag stötte på det ett par gånger i alla fall (varför jag använde HtmlDocument.GetElementsByTagName istället).
• När du navigerar med din WebBrowser så laddas dokumenten asynkront, vilket är bra – det vore ju tråkigt om programmet slutade svara bara för att en webbsida tog lång tid på sig att ladda.
• Om du behöver fylla i formulärfält, klicka på knappar eller på något annat sätt härma en verklig användares handlingar så kan du manipulera DOM-trädet precis som du skulle gjort med Javascript. Metoden HtmlElement.InvokeMember används för att trigga events på element i dokumentet (exempelvis ”click” på knappar/länkar).

Hoppas det hjälper!