Om du är det minsta nyfiken på ASP.NET MVC så tycker jag absolut att du ska låna eller köpa den här boken. När jag skaffade den kostade den knappt 300 kr och det var den utan tvekan värd.

För ganska precis två år sedan utvecklade jag LunarBlogGrabber, ett simpelt program som kunde hjälpa till med att spara ner en lokal kopia av ens dagbok/blogg på Lunarstorm. Jag gjorde det eftersom jag själv använt dagboksfunktionen på Lunarstorm när jag var yngre och ville ta en backup, men när jag väl var klar tänkte jag att det kanske fanns andra som kunde ha nytta av den. Och det fanns det – under tiden som gått sedan jag lade upp den första versionen har rätt många testat programmet och jag har fått en del kommentarer, vilket är kul.

LunarBlogGrabber hade flera svagheter. Dels var det ganska instabilt; det kunde sluta arbeta mitt i en lång nedladdning utan att användaren fick någon förklaring till vad som hände (eller ens att något hänt). Dessutom var man tvungen att skriva in sitt användarnamn och lösenord eftersom programmet loggade in som en representant för användaren, och alla var inte så sugna på att dela med sig av sitt lösenord till ett främmande program utvecklat av någon okänd typ, vilket är fullt förståeligt.

Nu har jag skrivit ett helt nytt program som angriper uppgiften på ett annorlunda sätt. Det nya programmet kallar jag för Lunarspindeln och en (gratis) betaversion finns tillgänglig för nedladdning lite längre ner på denna sida. Några features:

• Möjlighet att spara valfri användares publika blogginlägg på din dator. Blogginläggen sparas dels som RSS-fil (vilken kan användas för att importera bloggen i ett annat bloggverktyg, exempelvis WordPress) och dels som vanlig text (bra om man vill klistra in inläggen i ett Worddokument eller liknande).
• Möjlighet att ladda ner valfri användares publika galleribilder.
• Visar en bild på den valda användaren så att man kan vara säker på att man laddar ner rätt blogg eller galleri.
• Kräver inte några Lunarstorm-inloggningsuppgifter.
• Laddar automatiskt ner eventuella uppdateringar.

Ladda ner programmet här (packa upp zip-filen och kör setup.exe):

Lunarspindeln.zip

(Om du använder Internet Explorer kan du välja att istället installera programmet direkt.)

OBS: Om du får problem vid installationen, titta igenom systemkraven nedan – särskilt viktigt är .NET Framework 3.5.

Systemkrav:

• Windows XP eller nyare (programmet är testat på Windows XP x64 och Windows 7 RC).
• .NET Framework 3.5 (hämta från Microsoft här).
• Cirka 400 kb ledigt hårddiskutrymme.
• Internetuppkoppling.

Avgränsningar:

• Endast publika blogginlägg kan laddas ner – hemliga/privata inlägg kommer inte att hämtas.
• Endast bilder laddas hem från galleriet – filmer, ljud och övriga filtyper stöds inte.
• Det är inte möjligt att välja vilken mapp nedladdade filer ska sparas i. De hamnar automatiskt i en mapp som heter ”Lunarstorm” på skrivbordet. I Lunarstorm-mappen skapas en undermapp som heter samma sak som användarnamnet.

Kom ihåg: jag tillhandahåller det här programmet för att vara schysst. Jag tar inget betalt för det men jag tar heller inte något ansvar för eventuella problem eller skador som kan uppstå som följd av användandet av programmet. Jag kan tyvärr inte garantera att programmet fungerar på alla datorer. Ställ gärna frågor om ni har några – jag lovar inte att lösa allas problem men jag kommer att läsa all feedback jag får.

Jag skulle häromdagen skapa en cookie i .NET WebBrowser-kontrollen via WebBrowser.Document.Cookies och gjorde så här (min WebBrowser-instans heter ”browser” i exemplen nedan):

browser.Document.Cookies = "MyCookie=My value";

Den (interna) webbapplikation som browsern navigerade runt i kunde sedan verifiera att cookien fanns och göra vissa saker baserat på det, följt av att sätta cookien till ett annat värde. Det var bara det att ibland verkade cookien ha flera olika värden under samma request, vilket orsakade ett oönskat beteende. När jag tittade närmare på det insåg jag att det ibland fanns dubbletter av cookien. Vadan?

Jag började med att ägna en eftermiddag åt att testa olika varianter av ”kolla-om-cookien-finns-i-så-fall-sätt-den-till-ditten-annars-sätt-den-till-datten-eller-ta-bort-den” och andra dumheter tills det var dags att gå hem för dagen med bultande huvudvärk och dåligt humör.

Nästa dag inledde jag istället med att googla efter typ ”duplicate cookies” och hittade ett kort blogginlägg med budskapet:

Kom ihåg att alltid sätta path för dina cookies, annars defaultar den till den aktuella sidans URL vilket kan leda till dubbletter.

Inlägget handlade visserligen om att sätta cookies genom Javascript och document.cookies, men det är mer eller mindre precis samma sak som att göra det via WebBrowser.Document.Cookies. Så hur sätter man path för en cookie? En ny googling tog mig till en beskrivning av cookies på Quirksmode.org och insikten:

browser.Document.Cookies = "MyCookie=My value; path=/";

Genom det enkla tillägget började min cookie gälla för hela sajten och alla dubbletter försvann hux flux.

Slutsats: Sätt alltid path för dina cookies och ta en paus med lite frisk luft och kanske ett mellanmål när du försöker lösa ett problem men är för trött för att inse att Google har svaret…

Lunarstorm har alltid krävt autentisering för åtkomst till användarnas innehåll – man är tvungen att logga in med ett giltigt Lunarstormkonto för att kunna läsa sin egen eller andras blogginlägg, titta på bilder och så vidare. I den nuvarande versionen av LunarBlogGrabber (shit alltså, jag skulle verkligen behöva hitta på ett bättre namn…), som är ett Windowsprogram, använder jag .NET:s WebBrowser-kontroll för att låta användaren logga in på sajten. Programmet tar sedan över den inbyggda webbläsaren och använder den för att bläddra runt bland användarens blogginlägg och kopiera dess textinnehåll. Det är en ansats som fungerar, men WebBrowser-kontrollen är inte jättesnabb eftersom den ska rendera alla sidor och dessutom tycks den tendera att läcka minne över tiden (den använder ju Internet Explorer i bakgrunden).

En sak jag upptäckte när jag började skissa på en ny version var att blogginläggen på Lunarstorm inte längre kräver inloggning. Det betyder att vem som helst kan surfa in på en Lunarstormanvändares presentationssida och därifrån klicka vidare bland det innehåll som användaren lagt upp. Det går förstås inte att lämna kommentarer och liknande när man inte är inloggad, men att läsa andras tidigare kommentarer går fint. Jag är inte helt säker på varför Lunarstorm öppnats upp på det här sättet, men jag kan tänka mig att det har att göra med att företaget bakom vill ge möjligheter för externa tjänster att integrera med sajtens innehåll.

Det verkar dock som att utvecklarna bakom Lunarstorm har missat vissa grejer. Exempelvis:

• Som Lunarstormanvändare kan man välja att vara anonym, vilket innebär att man kan besöka andra användares presentationer och gå igenom deras material utan att de kan spåra besöket tillbaka till en själv. Det är även möjligt att ange att inga anonyma besökare ska få tillgång till ens material, vilket kan vara bra om man vill minska risken för att främlingar snokar runt bland ens grejer utan att tillkännage sig. Men: den spärren sätts ur funktion när besökaren inte är inloggad alls. En icke-inloggad besökare är ju per definition anonym, men ges alltså fri tillgång till samtliga användares publicerade material. Jag tror och hoppas att det här är en bugg, men det kan också vara ett medvetet, om än något svårförsvarat, designval.
• Lunarstorm håller reda på hur många visningar som gjorts av respektive blogginlägg som en användare publicerat. På det sättet kan man se vilka inlägg som är mest populära, och man kan även se precis vilka användare som läst ett givet inlägg. Som jag förstår det är tanken att bara unika läsare ska räknas – om jag går in och läser en kompis inlägg idag och sedan igen om ett år räknas det fortfarande bara som en visning. Det gäller dock inte för ej inloggade besökare – där ökas läsarräknaren med ett snäpp varje gång man laddar om sidan, vilket gör att man utan problem skulle kunna förstöra lässtatistiken för varenda publik Lunarstormblogg om man ville. Detta är sannolikt en ren defekt.

Den första punkten här spelar ingen större roll för mig i mitt utvecklingsarbete. Faktum är att den gör det enklare – så länge man utan inloggning kan surfa in på alla användares sidor och läsa deras (publika) inlägg behöver inte programmet vara inloggat, vilket är mycket positivt. En del användare har ställt sig frågande till om det är riskfritt att mata in sitt lösenord i ett fristående program så där, och jag tycker att det är en mycket befogad fråga. Det har visserligen blivit allt vanligare att webbtjänster ber om folks användarnamn och lösenord till deras webbmail för att kunna ”hitta ens vänner”, men jag tycker att det är en tråkig utveckling där i sig legitima tjänster lär användarna ett beteende som kan få dem att råka illa ut vid kontakt med mindre seriösa webbplatser. Kan jag slippa fråga användarna om deras Lunarstormlösenord så gör jag gärna det.

Den andra punkten är lite mer problematisk. I praktiken innebär den att mitt program, om vi antar att det inte kommer att agera som en inloggad användare, kommer att påverka lässtatistiken för de blogginlägg som man väljer att ladda ner. Och i och med att programmet inte kräver något lösenord blir det möjligt för vem som helst som använder programmet att öka antalet läsningar för helt andra användare, vilket kanske inte är så kul för dem.

Å andra sidan är det fullt möjligt även utan mitt program. Och det känns fel att min programvara ska bygga runt en defekt som Lunarstorms utvecklare bär ansvaret för. Med andra ord lutar jag åt att låta den kommande versionen av LunarBlogGrabber agera helt anonymt och vara kapabelt att ladda ner godtyckliga användares publika blogginlägg.

Så ser det ut i nuläget. Jag kommer ha mycket att göra med andra mer kommersiella åtaganden under veckan som kommer, så jag vågar inte sätta något releasedatum för nästa version, men jag hoppas att det blir snart!

Nu senast var det hos en kund som jag satt och fipplade med WebBrowser. Jag ville att popup-fönster skulle öppnas i en ny WebBrowser-kontroll istället för i ett vanligt Internet Explorer-fönster (vilket är standardbeteendet), och det gick att åstadkomma med lite pill. När användaren öppnat en popup och sedan stängde den så slängdes WebBrowser-instansen bort, med allt vad det innebär av Dispose():ande. Det jag insåg ganska snabbt var att det minne som allokerades vid skapandet av popup-webbläsaren inte frigjordes när den stängdes. En minnesläcka alltså. Detta var något som sett i tidigare projekt, men då handlade det mest om det minne som kontrollen läcker varje gång en ny sida laddas, vilket sker i ett mycket långsammare tempo. Jag hade aldrig tidigare kommit på varför minnesläckorna uppstått eller hur jag skulle komma till rätta med dem. Det har heller inte varit något affärskritiskt i de tidigare fallen, men för den här aktuella kunden var det just det.

Efter lite Googlande kunde jag konstatera att minnesläckorna i WebBrowser-kontrollen är kända av Microsoft, och att det även finns ”hotfixes” för dem (som jag tror ska vara inkluderade i diverse service packs för olika versioner av Windows). Jag provade att installera en sådan hotfix och kunde inte se någon skillnad överhuvudtaget.

Några timmar senare hittade jag däremot ett mycket intressant API-anrop som jag faktiskt tror löser min kunds problem, nämligen SetProcessWorkingSetSize i assemblyn kernel32.dll. Metoden används för att ställa in övre och undre gränser för det reserverade arbetsminnet för en given process, men om man anropar den med -1 som parametrar för gränserna så frigörs så mycket arbetsminne som möjligt. Så här kan det se ut i ett program skrivet med C#:

// Importera metoder från kernel32.dll, någonstans i klassdefinitionen...
[DllImport("KERNEL32.DLL", EntryPoint = "SetProcessWorkingSetSize", SetLastError = true, CallingConvention = CallingConvention.StdCall)]
internal static extern bool SetProcessWorkingSetSize(IntPtr pProcess, int dwMinimumWorkingSetSize, int dwMaximumWorkingSetSize);

[DllImport("KERNEL32.DLL", EntryPoint = "GetCurrentProcess", SetLastError = true, CallingConvention = CallingConvention.StdCall)]
internal static extern IntPtr GetCurrentProcess();

// ...och frigör arbetsminne där det passar.
IntPtr pHandle = GetCurrentProcess();
SetProcessWorkingSetSize(pHandle, -1, -1);

Så var det med den saken. Den ursprungliga forumtråden där jag läste om detta hittar du här, och Microsofts dokumentation av de aktuella metoderna i kernel32.dll finns här. Hoppas det hjälper någon.

Felscenario: Om man har en UpdatePanel utan innehåll (eller med osynligt innehåll) så kommer den, när den uppdateras, att renderas som en div-tagg, förutsatt att dess RenderMode är satt till Block, vilket är default. Taggen kommer, vare sig man vill eller ej, att innehålla en massa whitespace – som i sin tur triggar en visningsbugg i Internet Explorer 6. En vettig webbläsare förstår att en div som bara innehåller whitespace inte har något innehåll och därför inte ska ta upp plats på sidan. Så är inte fallet för IE6 – där kommer nämligen div:en att få samma höjd som den aktuella fontstorleken.

Sjukt frustrerande! Om det hade varit en vanlig statisk div så hade man kunnat komma runt det hela genom att manuellt ta bort allt whitespace mellan taggarna, men det kan man inte på något enkelt sätt med en standardkontroll, om man inte vill skriva om hela renderingen för kontrollen. Det vill inte jag, i alla fall.

Fix: Efter mycket lidande kom jag på en lösning. Lägg helt enkelt till ett absolutpositionerat element inuti UpdatePanel:en, till exempel s¥här:

<asp:UpdatePanel ID="upTest" runat="server">
<ContentTemplate>
<div style="position: absolute; width: 0; height: 0;"></div>
</ContentTemplate>
</asp:UpdatePanel>

Problemet löst! Visst, jag tycker inte om att lägga in markup som inte gör något, men om det krävs för att lösa en bugg som annars får sidan att se helt muppig ut s¥ implementerar jag den utan att blinka.

Ser det ut såhär just nu? Inte på långa vägar. Jag har en vanlig anställning som sysselsätter mig mer eller mindre 40 timmar i veckan. Det jag gör är helt okej kul/utmanande/lärorikt. Jag är nöjd med den lön jag får för arbetet. Men jag hade ännu hellre själv velat disponera min tid, kunna arbeta intensivt under vissa perioder för att sedan ta det lugnare och göra annat under andra perioder. Inkomsten skulle vara mindre knuten till antalet arbetade timmar per vecka. Det hade varit något!

Passiva inkomster är pengar man tjänar utan att utföra ett direkt proportionellt arbete. Exempel är förstås ränta på de pengar man har på banken, avkastning på aktier och fonder, royalties från en bok eller skiva man givit ut, hyresintäkter från en lägenhet man äger och hyr ut och så vidare. Det som är bra med passiva inkomster är att de ger en ett visst ekonomiskt svängrum – genom att inte behöva jobba en timme för att få motsvarande lön kan man använda den tiden till något annat istället. Men det kluriga är att hitta källor till passiva inkomster. Vi är ju i princip uppvuxna med konceptet att man skaffar sig en utbildning för att kunna få ett bra, stabilt jobb (underförstått: en anställning) – det är inte alls lika välbekant att sträva efter att skaffa sig passiva inkomstkällor eller göra långsiktiga investeringar.

Jag har funderat en del på vilka typer av passiva inkomstkällor som skulle kunna passa mig, och som jag faktikst också skulle kunna skaffa mig i praktiken. Några (mer eller mindre uppenbara) idéer:

• Traditionellt sparande. Denna är egentligen rätt självklar, men svårare att realisera än man tror om man inte har tagit sparande på allvar tidigare. Jag satsar på att först skaffa mig en ordentlig buffert på ett vanligt bankkonto (fast med bra ränta) och sedan sätta igång med ett seriöst fondsparande. Ränta på ränta – det blir faktiskt pengar till slut. Och det är bra att ha något undanstoppat både inför oförutsedda utgifter och pension.
• Annonsering på nätet. Om jag någonsin skapar en webbtjänst eller blogg som får tillräckligt många läsare/användare så behöver den faktiskt inte kosta pengar för att jag ska kunna tjäna en hacka. Nackdelen är förstås att jag själv tycker lite halvt illa om annonser. Donationer är ett alternativ.
• Serviceavtal med kunder. Jag har ju en enskild firma där jag pysslar med diverse system- och webbutveckling åt olika kunder. Genom att sluta någon form av serviceavtal kan jag garantera kunderna exempelvis kortare svarstider i supportfrågor, lägre timtaxa vid incidenter eller liknande mot att de betalar en fast avgift per månad.
• Sälja egenutvecklad programvara. Detta är nog det alternativ jag tror skulle vara både roligast och mest potentiellt lönsamt. Jag gillar att programmera och lära mig tillämpa både nya och gamla tekniska kunskaper för att lösa mer eller mindre vardagliga problem. En bra mix! Det skulle vara lite som att fortsätta i samma stil som mitt program för att ladda ner och spara Lunarstorm-dagboksinlägg, fast i en större skala och kanske med lite mer kommersiellt gångbara produktidéer. Jag har en del uppslag. Allt jag producerar kommer troligen dyka upp under Fjeldstad Medietekniks flagga.

Det finns förstås mer jag skulle kunna göra, men jag måste ju börja någonstans. Ett mål jag har satt upp (utan att räkna på det särskilt mycket) är att inom fem år ska minst 25% av min totala årsinkomst vara passiv. Realistiskt eller optimistiskt? Vi får väl se…

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