När man bygger webbapplikationer med kortbetalning för flera korttyper än enbart Visa och Mastercard så stöter man på problemet att de inte ska hanteras likadant. Tex så har American Express inte 3D-secure, vilket gör att många betalväxlar vill att man skickar AMEXuppgifter till någon annan webservice för verifiering.

För att slippa be kunden att välja vilken korttyp så kan man istället själv ta reda på det, eftersom olika korttyper har olika nummerserier och olika många siffror. En liten tabell över vilka nummerserier som respektive kort har kan man hitta här:

http://en.wikipedia.org/wiki/Bank_card_number

Den är inte helt komplett. Jag vill minnas att det finns en krock någonstans mellan Visa och AMEX, om jag inte missminner mig så har Visa också en serie som börjar på 37 och har 15 siffror. Men när jag tog upp det med Dibs för några veckor sedan så sa de att korten som de berör enbart existerar i USA och att de håller på att bytas ut.

Upptäckte en lustig sak idag i C# som jag inte visste om sedan tidigare. ??-operatorn som skulle kunna komma till användning när man jobbar med variabler som kan vara null.

Vi tänker oss att vi har en klass som vi inte vill ska kunna returnera null, även fast variablerna kan vara null. Så om variabel A är null så ska den istället returnera variabel B, och om även den är null så ska den returnera -1.

Tidigare så skulle jag har gjort så här:

int? A = null;

int? B = 12;

(Lite kod som gör att resultatet i A och B kan vara vad som heslt..)

if(A != null)

  return A;

if(B != null)

  return B;

return -1;

Men ?? kan ge oss en snyggare lösning. Hela return-biten kan bytas ut till det här som ger exakt samma resultat:

return((A ?? B) ?? -1);

Jag blev först lite ställd över att min RowCommand inte ser ut som tex RowDelete. e.RowIndex finns inte, och hur kan jag då få ut vilken Datakey som min rad i gridden har?

Svaret ligger i e.CommandArgument, som innehåller samma sak som e.RowIndex:

int index = Convert.ToInt32(e.CommandArgument);
DataKey myGridKey = myGrid.DataKeys[index];
int myRowId = Convert.ToInt32(myGridKey.Value);

I fredags var vi på en heldagskurs i Scrum och hur vi kan arbeta med Scrum med hjälp av Microsoftverktyg. En riktigt underhållande och matnyttig dag som vi har Björn Eriksen från Connecta samt Mikael Deurell från Microsoft att tacka!

Tänkte publicera bilder på tre stora män med tre underbara citat från fredagens kurs.

Björn Eriksen (Connecta): "Gammal kod blir automatiskt dålig kod".

Mikael Deurell (Microsoft): "SourceSafe är nog det sämsta vi gjort, tyvärr".

Urban Björkman (Delegia): "Det är inte bra att lära sig om bra saker, man märker hur oprofessionell man själv är".

Till nästa version så kommer Microsoft att bygga in ett officiellt stöd för JQUERY i .NET. Jag länkar till Mikael Söderström som var den som upplyste mig, han har skrivit lite mer om det och har även referenser vidare för den som är nyfiken.

Mikael Söderströms blogg: http://weblogs.asp.net/mikaelsoderstrom/archive/2008/09/28/asp-net-ajax-jquery-sant.aspx

Jag har en tabell där alla poster ska ligga i en hierarki under varandra. Tabellen innehåller alltså ett id- och parentid-fält. Det är inte helt ovanligt att man i sådana lägen kommer på att man vill ha hela hierarkin ovanför posten som man är på, i det här fallet för att visa var man är på en site.

Lite exempeldata i tabellen:
id | parentid
1 | Null
2 | 1
3 | 2
4 | 2
5 | 3
6 | 5

Om vi exempelvis har plockat fram posten med id 6, så vill vi ha ut en lista på hur hierarkin ser ut uppåt tills det inte finns någon relaterad längre. I det här fallet så är det alltså enbart posten med id 4 som inte ska finnas med i vårat urval, men vår SQL ska självklart fungera i alla lägen. Min lösning förutsätter MsSQL 2005 eller MsSQL 2008 eftersom begreppet "With" inte finns i exempelvis MsSQL 2000.

WITH Merged (id, parentid) AS (

	SELECT id, parentid FROM t1 WHERE id = @id

	UNION ALL

	SELECT t1.id, t1.parentid 

	FROM t1 INNER JOIN Merged ON t1.id = Merged.parentid

)

SELECT * FROM Merged

 
(Tack till Tant102 @ Aspsidan.se för hjälpen med att lösa problemet)

Tänkte nu följa upp det jag skrev i mitt blogginlägg för ett tag sen:
http://blogs.itmaskinen.se/post/2008/09/15/In()-i-SQL.aspx

För det första vill jag verkligen återigen klargöra att det absolut inte ska ses som vetenskapligt, utan enbart byggde på mina egna erfarenheter utefter när jag satt och testade.

Jag och min kollega Ubbe har lekt vidare, och gjort liknande tester på SQL2005-databaser. Och precis som det kommenterades på mitt förra blogginlägg så upptäckte vi att det inte var så generellt som jag fick det att framstå. Skillnaderna mellan att köra en Join och en In() var väldigt mycket mindre, och ibland var det även effektivare att använda sig av In().

Vi har lite databaser som rullar på MsSql 2000 skarpt för våra produkter. Ubbe som kör MsSql2005 lokalt märkte under förra veckan av ganska stora skillnader i prestanda mellan när han körde lite tyngre frågor mot sin lokala version av databasen under MsSql2005 och när frågorna kördes mot den som låg skarpt på MsSql 2000, även fast de innehöll likvärdig data.

Så helt ovetenskapligt har vi nu testat att köra frågor mot en MsSql 2000 databas och en MsSql 2005 databas som är installerade på samma maskin med allt inställt som det är som standard, vi har alltså inte pillat på cache eller nått sånt. Ganska snabbt kunde vi konstatera en otrolig skillnad.

En fråga som tog ca 4 minuter att köras första gången på en 2000-databas tog ca 2 minuter på en 2005-databas. Andra gången vi körde samma fråga, direkt efter, så tog den 3 minuter och 30 sekunder på 2000-databasen och 2 sekunder på 2005-databasen. Förmodligen så kan man få ner skillnaderna väldigt mycket om man leker lite med inställningarna på 2000-databasen.

För er som bloggar via Windows Live Writer så tipsade Stefan Karlsson på SkiBar mig om ett riktigt bra plugin som ser till att färgkoda kodbitar. När man inkluderar kod så väljer man bara vilket språk det är så fixar det resten. Smart och uppskattat!

När man installerat pluginet så får man alltså en ny rad i menyn "Insert" som heter "Insert Source Code...".

Tydligen så lägger sig pluginet i fel mapp om man kör Svenska windows, så då får man manuellt flytta det från "c:\program files\windows live writer\plugins" till "c:\program\windows live writer\plugins".

Tack Stefan!

Länk: http://gallery.live.com/liveItemDetail.aspx?li=10d724ab-0d28-4c78-8310-a6e2cfdef891&bt=9&pl=8

Nu på förmiddagen så var jag i behov av att hämta ner data från en querystring till en javascriptfunktion. Jag tror aldrig tidigare att jag faktiskt stött på det problemet. Hur som helst så började jag fundera över hur man gjorde, i brist på svar från tomtarna i mitt huvud så googlade jag. Förvånande nog så verkar det inte finnas något inbyggt i javascript för att hantera enskilda nycklar i querystrings, utan man kan tydligen bara plocka ner alltihop för att sedan själv grotta runt med stränghantering för att få ut det man vill ha.

Hittade ganska många riktigt dåliga försök att hantera det där vettigt i javascript. Det loopades genom strängar till höger och vänster, splittades och bökades runt. Precis när jag höll på att ge upp och istället själv sätta mig för att bygga en vettig funktion baserad på regular expressions så hittade jag en som är helt i min smak, så jag tänkte att jag passar på att ge den lite mer uppmärksamhet om det är fler som stöter på behovet i framtiden.

function getQuerystring(key, default_)

{

  if (default_==null) default_=""; 

  key = key.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");

  var regex = new RegExp("[\\?&]"+key+"=([^&#]*)");

  var qs = regex.exec(window.location.href);

  if(qs == null)

    return default_;

  else

    return qs[1];

} 

Källa: http://www.bloggingdeveloper.com/post/JavaScript-QueryString-ParseGet-QueryString-with-Client-Side-JavaScript.aspx