Vill slå ett slag för programmet Pencil som är ett gratis mockup-program (GPL-licens med möjlighet att donera till utvecklarna om man vill) . Programmet kan köras som vanlig stand-alone på linux och windows, eller som en addin till firefox.

När du varit ute hos kund och fått en massa input och snabbt måste ta fram ett underlag på program, gränssnitt, programflöde osv så är detta perfekt!

Visst, man kan skapa ett formulär i visual studio och börja koda en prototyp, men problemet med det är att man ofta lägger in för mycket tid och funktionalitet i prototypen och helt plötsligt så har den fått ett eget liv och i slutändan så sitter man och kodar produktionskod i prototypen. Och då är det inte lätt att kasta bort den och börja koda från början. Nackdelen med det är att man fortsätter koda på något som från början inte var meningen att vara något annat än en prototyp.

Ett annat problem med prototyper skrivna direkt i programmeringsverktyget är att kunden måste installera programmet för att se det. Du kan inte lätt skicka prototypen till 100 personer och få dessa förstå vad som ska göras (installeras, kanske avinstallera föregående prototyp osv), dessutom kanske inte alla 100 personerna har rätt att installera programvara på sin dator, många företag har nedlåsta miljöer i verkstäder, kassor osv.

Man kan gå andra vägen och göra bilder i photoshop och skicka ut, men dessa bilder förklarar bäst gränssnittet, inte programflöde m.m.

Därför är detta mockup-program riktigt bra. Du kan göra dina mockup-bilder, länka knappar m.m. till andra bilder. Snabbt göra om, modifiera osv utan att ens riskera att fastna i att överprogrammera en prototyp.

I programmet så finns det en massa färdiga GUI-kontroller (fler finns att ladda ner) som bara är att dra ut och börja använda för att skapa ditt mockup:

Väljer man t.ex. en datalista så populeras den automatiskt med demodata. Men man kan lätt ändra det mesta:

Det går att ladda ner nya kollektioner av kontroller och shapes och det finns olika export-templates att ladda ner också. En av dessa är riktigt bra, templaten heter GUI Prototyping 800x580. Om man laddar ner den och installerar den via Tools / Manage Export Template… så får man en möjlighet att välja den templaten när man exporterar till “Single web page”:

När man väljer det så skapas en mokup-html-sida där man kan testa programflödet enligt mockupen. Den kan man sedan ladda upp på webben och skicka en länk till alla som ska få komma med kommentarer på förslaget. Jag har modifierat min template så den passar mig, vilket är en trevlig möjlighet.

Här är ett exempel på mockup jag gjort: http://develop.itmaskinen.se/stefandev/gui/index.html

Så sluta göra prototyper! Gör mockuper istället! Din säljare, eller till och med din chef kan göra det efter ett kundbesök och sen lämna över den till dig för förfining!

Over and out!

/Stefan.

Ibland så måste man felsöka i program. felsöker man i Visual Studio på sin utvecklingsdator så kör man oftast med breakpoints i kombination med att man skriver ut debuggdata till output-fönstret. Jag har sett att loggning ute hos kund är en sån sak som de flesta programmerare bygger egna lösningar för, loggning mot fil, Eventlog osv som står och fyller upp loggar 99% till ingen nytta, även om man ser flertalet som i alla fall lägger in flaggor för om det ska vara på eller avslaget.

Något vi använder oss av i stort sett dagligen (i alla fall jag) är Debug.Print() vilket skriver ut debugdata till Outputfönstret (eller motsvarande konfigurerbar eventlyssnare) i Visual Studio.

Låt oss säga att vi har ett program där man har en knapp och en listbox:

På olika ställen i programkoden så lägger vi in debug.print () som talar om vad som sker:

När vi kör programmet och klickar på knappen så får vi i Output-fönstret se att allt går rätt till:

DebugView

Om du har problem på en kunddator så vill du inte installera hela visual studio för att få fram den här informationen och det behöver du inte heller, ladda bara ner programmet DebugView från Sysinternals så hookar den in och lyssnar på debug-event från alla applikationer.

På det sättet kan du köra programmet live hos kund och ändå se debug-datat, självklart så krävs det att du har en version av programmet som är kompilerat i Debug-mode. Kunden kör ju antagligen applikationen i Release-mode så du får se till att kompilera programmet i debugmode och ta med och köra på targetmaskinen.

Ovanstående debuggdata ser ut så här när jag kör programmet på samma sätt med Debugview:

Man kan välja att logga till fil, vilket är väldigt smidigt om man vill logga programmet under en hel dag medan kunden använder det. Man kan även logga via nätverket, så du kan köra DebugView på en klient och sen starta DebugView på en server och connecta till klienten och få upp debuggdatat där. Du kan skapa include och exclude-filter som highlightar vissa meddelanden eller filtrerar bort vissa meddelanden osv.

Detta är ett mycket värdefullt program när man vill samla debuggdata ute hos kund.

Men Releasemode då???

Av prestandaskäl så tas alla debug.print-anrop bort när man kompilerar programmet i releasemode. Vill man ändå kunna få sådan information via DebugView när man har programmet i releasemode så är det bara att ändra debug.Print() till Trace.WriteLine(), då kommer du att få dessa meddelanden oavsett om det är i debug eller releaseläge på programmet.

Av prestandaskäl kan det vara bra att inte peppra programmet med tusentals Trace.WriteLine, men har man problem med ett program så kan det verkligen vara värt att lägga in dessa rader på ställen man misstänker att det finns problem.

Det är ju smidigt att bara starta DebugView, köra programmet och i DebugView få ut interna data som programmet använder sig av för att se varför man får t.ex. diffar eller error.

Over and out / Stefan

Satt precis med ett litet projekt där jag laborerade med data från en GPS-puck. Datat skickade jag till en listbox för att se vad som kom från GPS-pucken:

Jag ville kunna spara datat till en fil och började då, precis som jag gjort 1000-tals gånger tidigare, att göra en loop som loopade igenom alla items i listboxen för att skriva ner datat till en fil. Det går självklart att göra på massor av olika sätt, nedan är de två vanligaste.

Men så kom jag och tänka på LINQ.
Det borde gå att göra ett LINQ-fråga som skapar en array av listitems som gör att jag kan skriva ner allt till en fil med endast en rad kod. Genom att använda IO.File.WriteAllLines som tar en array av strängar och skapa en LINQ-fråga som returnerar en array av strängar från listboxens items så borde det alltså fungera, jag provade med nedanstående kod:

Vilket fungerade hur bra som helst! Men LINQ-frågan går att korta ner, “Select p” är vedertaget i LINQ-frågan så man behöver inte ange det, vilket gör att vi kan korta ner raden till detta:

Slutsats

LINQ är häftigt, det är rent ut sagt sexigt! Men tänk på att det ibland kan vara svårt att förstå LINQ-kod, så även om den gör koden kompaktare så kan den även göra koden svårare att läsa i vissa fall, samt att man får tänka på LINQs “late evaluation”-teknik som kan ställa till det i andra sammanhang. Men i det här sammanhanget så tycker jag att LINQ gör koden mer lättläst och tar bort onödiga rader kod.

Det finns ett talesätt: Varje rad kod du INTE skriver är en rad du inte kan få en bugg i.

Over and out / Stefan

Att leta buggar kan vara jobbigt, men om man inte vet om det här tipset så är det VÄLDIGT jobbigt.

Felhantering

Vanligtvis så har man ju felhantering (TRY/CATCH/FINALLY) i sina rutiner så att programmet hanterar alla fel som man tänkt kan inträffa i koden. Om man läser en fil så hanterar man att filen är låst eller borttagen och andra saker som vanligtvis inträffar när man läser filer.

Ofta så har man en generell felhantering Catch ex as Exception, eller först specifika catch:ar följt av en generell som sväljer allt man inte tänkt på.  (Nu förespråkar jag inte att göra som i exemplet nedan utan det är som sagt bara ett exempel:

I och med att man har lagt till try/catch på det här sättet så sväljs ju andra fel. I exemplet nedan så kommer man få index out of bound om filen inte innehåller några rader, detta fel sväljs dock av try/catch:en och samma felmeddelande visas oavsett fel:

Det gör att du inte vet var det smällde, bara att nånstans i anropskedjan så smällde det och du hamnade i Catch-delen (som kan vara en helt annan klass i en helt annan fil än där felet inträffade. Om rutinen innehåller många rader kod så vet man ju inte i vilken rad det smäller för man hamnar i catch-delen.

Den svåra vägen

Här har jag sett att många utvecklare kör den svåra vägen, sätter breakpoints överallt i koden och steppar igenom programmet tills det smäller, letar sig tillbaka till sista raden innan det smällde och sedan sätter breakpoint där för att se vad det var som hände. Detta kan vara väldigt tidsödande om det är en invecklad kodbas.Speciellt om det är svårt att återskapa felet och det kanske bara inträffar vid vissa speciella förutsättningar.

Lösningen

Visual Studio har stöd för att lösa detta problem snabbt. Nånstans smäller det, du vet inte vart för felet sväljs av befintlig felhantering. Lösning: Tala om för debuggern att break:a ÄVEN fast du hanterar felet. Då stannar programmet och den raden som orsakade felet markeras i editorn direkt. Inget krångel med att steppa igenom kod med breakpoints osv.

Som standard så är debuggern inställd på att hamna i break-mode enbart på fel som du INTE hanterat med try/catch. Genom att välja menyn Debug och undermenyvalet Exceptions så får du upp en dialogruta som ser ut så här:

När du letar buggar så öppnar du helt enkelt bara upp den dialogrutan (går att göra även när programmet körs) och kryssar i att den ska break:a när ett CLR exception är kastat (thrown) och klickar på OK, alla fel som inträffar i din kod kommer nu att göra så att debuggern breakar och markerar raden som utförde felet, oavsett om du hanterar felet eller ej. I bilden nedan är kryssrutan markerad.

Happy bug hunting!

/Stefan

Ett säkerhetshål gör att man kan komma åt en applikations kryptonyckel som används för att skapa authentierings-cookies och utifrån det så kan man t.ex. logga in som vilken användare som helst i en .Net-applikation som använder sig av sådana, här är ett live-exempel på hur man blir superuser på valfri DotNetNuke-site: http://www.youtube.com/watch?v=yghiC_U2RaM

Här beskrivs hålet närmare: http://threatpost.com/en_us/blogs/new-crypto-attack-affects-millions-aspnet-apps-091310

Här diskuteras problemet och eventuella workarounds på en utmärkt programmerarsite:

http://stackoverflow.com/questions/3720720/how-serious-is-this-new-asp-net-security-vulnerability-and-how-can-i-workaround-i

Inte bara ASP.Net sårbart

Säkerhetshålet existerar inte enbart i ASP.Net, utan upptäcktes först i JSF (Java Server Faces) framework. Det existerar även i Java.

EDIT: Nu har det kommit en patch från microsoft,

Jag rekommenderar alla att köra den om den inte kommer med windows update automatiskt.

http://www.microsoft.com/technet/security/bulletin/ms10-070.mspx

Något av det snyggaste freeware (Freeware om man använder det för personligt bruk) jag någonsin testat på.

Stardock:s Fences.

Skapar små fina areor på skrivbordet där alla dina ikoner sorteras in.

Genom att högerdra på skrivbordet skapar man nya areor man kan namnge. Alla ikoner som läggs däri justeras automatiskt i sin area.

Varje area har sin egen scroll-area om det blir för många ikoner i dem.

Så här fint vart mitt skrivbord efter att jag installerade Fences och valde att låta den själv ordna upp ikonerna på mitt stökiga skrivbord (Jag håller musen över arean “File & Documents, det är därför man ser scrollbaren där, annars syns inte scrollbaren):

Gillar program som bara funkar out of the box och som underlättar och strukturerar tillvaron för en. Känner mig mycket mer effektiv med ett automatiskt rent och fint skrivbord.

Ladda ner:
http://www.stardock.com/products/fences/index.asp?ref=fa_101

Jag gillar Silverligt 4 med kamerastöd. Ihop med SLARToolkit, ett opensource-projekt som gör att vilken programmerare som helst kan börja interagera med webbkameran.

Med hjälp av markörer (bilder som SLARTookit kan leta efter i webbkameraströmmen) så kan man göra en massa roliga saker som att projicera en film ovanpå markören i realtid, eller projicera ett 3D-objekt som vrider sig när man vrider på markören och många andra roliga saker. Man kan ha flera markörer samtidigt utan problem, vilket öppnar upp för att man t.ex. skulle kunna spela pingpong framför kameran eller kanske styra spel på ett litet roligare sätt än med musen.

Har du en webcam och silverlight4 installerat så är det bara att testköra direkt:
SLARToolkit live test

Läs mer:
http://kodierer.blogspot.com/2010/02/slartoolkit-silverlight-augmented.html

Ladda ner SLARToolkit och börja labba på en gång:
http://slartoolkit.codeplex.com/

En film som visar det hela om man inte kan testköra eller bara snabbt vill se vad det handlar om:
http://www.youtube.com/watch?v=9tYn_w0xaZU&feature=player_embedded#!

En till film:
http://vimeo.com/9713000

Det sägs att microsofts hade ett team som forksade kring röstigenkänning (voice recognition) .

Teamet hette “Wreck a nice beach” och namnet fick de av deras egen mjuvara. När de sa “Recognice Speech” i mikrofonen översatte röstigenkänningen det helt sonika till “Wreck a nice beach”.

Sådana små anektoter gillar jag. ;)

adMob som vi skrev om tidigare är nu en del av Google, läs mer om det här.

http://googleblog.blogspot.com/2010/05/weve-officially-acquired-admob.html

Google betatestar nu en https-version av sin söktjänst. Läs mer här:

http://googleblog.blogspot.com/2010/05/search-more-securely-with-encrypted.html

Testa live här:

https://www.google.com/