ICoder

Mit web–mit dogme

The IMan — Mon, 20 Dec 2010 13:56:49 +0100

I slutningen af forrige årtusinde, sad jeg i en fugtig kælder, og kodede løs på min første rigtige webapplikation. Den havde en backend, der var lavet i Concorde XAL og en frontend der var lavet i statisk Html og Javascript. Det var en rigtig webshop, med varegrupper, beskrivelser, billeder og en indkøbskurv. Nøjagtig som vi kender dem i dag.

Det var kompliceret at få XAL script til at generere Html og få timet sit Javascript i browseren (IE 3.02). Jeg udtænkte derfor en XAL-Html-template, der gjorde genereringen af nye sider (og nyt design) til en leg. Nu skulle jeg blot vælge publicér i XAL, og så blev de nye Html filer genereret, og uploadet til webserveren via FTP. Skulle der lige snige sig en fejl ind, kunne man hurtigt rette koden i Notepad, og uploade sin patch.

Men – Microsft havde jo arbejdet i et par år med ASP, og udgav i slutningen af 2000 version 3.0. Springet fra mine XAL-templates og over til ASP var ikke langt – nu kunne man lade webserveren generere sin Html, og nøjes med at hente data via Odbc forbindelser. Jeg kunne endda bruge mine Javascript kundskaber på serveren – Microsoft kaldt det godt nok JScript, men det var jo det samme.

Her efter kom et par år, hvor jeg var utroligt produktiv, og jeg fremstillede et hav af webapplikationer: CMS, CRM og webshops – alt kunne lade sig gøre. Samtidig var der masser af virksomheder, der havde de utroligste forretningsideer, som bare skulle omsættes til web. Mit foretrukne værktøj blev Allaire Homesite.

Ind kom ASP.NET. Microsofts nye webudviklingsplatform. Nu kunne man kompilerer sin kode, og man havde hele systemet til sin rådighed. Det var utroligt tiltalende at pakke al sin kode ind i klasser, og begynde at tænke på arkitektur. Jeg skulle pludselig til at tænke i meget mere abstrakte baner. Genbrug og afkobling var den helt store gevinst. Produktiviteten gik helt ned! På trods af at ASP.NET skulle øge produktiviteten, fik det den modsatte effekt. Man kunne bare ikke komme i gang, uden at man skulle lave en flot arkitektur først. Her stoppede utroligt mange projekter – det var simpelthen for dyrt.

Det bringer os frem til i dag, hvor vi jo sidder med Visual Studio 2010, og alligevel er produktive. Ikke fordi vi er blevet mere innovative, eller bedre kodere, men fordi ASP.NET platformen er modnet, og der er kommet en lang række frameworks der hjælper os med de fleste ting. Man skal ikke tænke på databaser – de er mappede til objekter i ORM frameworks. Man skal ikke tænke på autorisation – det klarer Membershipprovideren. Man skal ikke tænke på Html – det klarer Webkontrollerne. Man skal blot hooke de forskellige moduler sammen. Nemt og hurtigt. Så længe det opfører sig som man har forventet, for sker der først fejl, så kommer problemerne. Det er blevet utroligt komplekst at finde en fejl i en ASP.NET applikation i 2010. Man er mange gange nødt til at gå på serveren, og lave et dump, som man kan analyserer for at finde fejl. Ja man bruger nu ikke længere sine udvikler ressourcer til at udvikle, men til at rette fejl.

Her står vi så i dag. Hvordan kommer vi videre, og hvordan bliver vi bedre og mere produktive? Bruger vi flere frameworks, og flere abstarktionslag? Skal vi bruge Sharepoint eller xRM, for overhovedet at få noget fra hånden?

Jeg tror at applikationsudvikling, er blevet for kompliceret, og vil forsøge at stræbe efter mere simple løsninger. “Simpelt er smukt”. Jeg har derfor besluttet at fremsætte en række regler for mit fremtidige arbejde med webapplikationer. Det er min opfattelse, at en webapplikation, der er udviklet efter disse regler, vil være optimal både at udvikle, videreudvikle, drifte og fejlfinde. Første udkast ser således ud:

Ingen servergenereret Html – Al Html skal komme fra statiske filer, eller klientside script. Det er forbundet med et unødvendigt overhead både på server cpu, memory og responsstrøm. Det er langt smartere at lade klienternes datakraft bruge energi på at manipulere Html og styling. Det frigiver ressourcer på serveren, der kan bruges langt smartere på forretningslogik.
Json respons fra servervicekald – Json er det naturlige data format for webapplikationer, samtidig er det langt mere komprimeret en Xml. Ingen klientside overhead i forbindelse med parsning af overflødig og tung Xml. Vi taler om en faktor 1:10 på almindelige Xml-dokumenter, og 1:x så snart der introduceres namespaces. Man sparer responsstrøm, og klientside ressourcer.
Minimér relationel data – Data der ikke er relationel, skal gemmes som f.eks. Json. Det åbner databasen for hurtigere og senere ændringer i databærende klasser. Konceptuelt som en dokumentdatabase - i praksis gerne som felter i en relationel database.
Autorisation via Http digest – Implementeret af alle browsere, og niveauet kan skrues op og ned efter behov og temperament. Minimal payload, og dermed formindsket respons- og requeststrøm

Nogle tanker ideer?

Start med MicroDal

The IMan — Mon, 02 Aug 2010 12:04:00 +0100

Hvordan kommer man i gang med at bruge MicroDal i mit web-projekt?

Når klassebiblioteket (microdal.dll), er downloadet og inkluderet i projektet, er man klar, og mangler blot at konfigurere sin databaseforbindelse. Man skal kun huske at kvalificerer den med provider navn. F.eks.:

<connectionstrings>
  <add name="MyDb" 
          connectionstring="data source=|DataDirectory|\cmsdata.s3db;New=true" 
          providername="System.Data.SQLite" />
</connectionstrings>

Nu kan man bruge MicroDal med manuel sessions-management. Det vil sige man angiver navn på forbindelsen hver gang man bruger bruger en session:

using (var ses = new DataSession("MyDb")){
    var idx = ses.ExecuteScalar<int>("SELECT @@IDENTITY");
    //.... 
}

Ønsker man at lade MicroDal administrere databaseforbindelsen, og på den måde optimerer brugen af forbindelser, skal man blot tilføje en appsetting med nøglen: MicroDalConnectionName:

<appsettings>
  <add value="MyDb" key="MicroDalConnectionName" />
</appsettings>

Så ligger al funktionalitet i en statisk property på DataSession objektet – Current. Man kan så bare bruge sessionen, når man ønsker det – MicroDal lukker og rydder op automatisk.

Databinding er nu en simpel sag:

list1.DataSource = DataSession.Current
    .Fetch<Address>(
        "SELECT * FROM Address WHERE id=@1",
        Request["ID"])
   .ToArray();
list1.DataBind();

Her er forudsætningen, at Address objektet har en parameterløs konstruktør, og at der er sammenfald mellem kolonnenavne og egenskaber på objektet. Hvis ikke, skal man kvalificerer sin SQL søgning med alias der passer på egenskabsnavnene.

Code on…

Faldgruber i JavaScript

The IMan — Mon, 30 Nov 2009 13:53:05 +0100

parceInt bruger octet som standard

Man må bare elske den måde hvorpå parseInt virker på. Ikke så meget vrøvl – bare resultater.

var width = parseInt(“153px”);

giver helt som forventet: 153. Ingen behov for at fjerne enheder fra strengen først, som i c#. Det virker bare.

Men hvad sker der så når man prøver med:

var id = parseInt(“009”);

Man får “0” – det viser sig nemlig at parseInt bruger octet som udgangspunkt, og det første tal fra systemet er “0”, da 9 jo ikke er et tal i octet, ignoreres det blot, som var det en hvilken som helst anden enhedsangivelse. Man kan tvinge 10-talsystemet ved at angive radix:

var id = parseInt(“009”, 10);

En streng er ikke en streng

Ikke alle er klar over at JavaScript faktisk kan representerer en streng på to forskellige måder: Som en primitiv og som et objekt.

var a = "Jeg er en primitiv";
var b = new String("Jeg er et objekt");

alert(typeof a == typeof b); // Vil alerte 'false'

Hvis man har kode der laver type-check, kan man altså ikke bare nøjes med:

if (typeof var1 == "string")
    ...

DOM id’er

Brug ikke DOM id’er som variabelnavn. Det giver “object undefined” fejl i IE. Brug namespacing…

Replace er ikke global

Hvis du vil foretage en udskiftning af karakterer i en streng, skal du bruge en RegExp som parameter, ellers er det kun første forekomst der udskiftes:

var headline = "Min overskrift på artiklen";

var itemname = headline.replace(" ", "_");
// Giver: Min_overskrift på artiklen

var itemname = headline.replace(/ /g, "_");
// Giver: Min_overskrift_på_artiklen

Coder on..

Betinget scriptinkludering

The IMan — Thu, 26 Nov 2009 08:43:14 +0100

Hvis man indsætter klientside script på sine websider med Xslt transformeringer, kan man af ukendte årsager få problemer med den resulterende html. Jeg har oplevet (Sitecore) at hvis jeg forsøger at indsætte en række scripttags med reference til eksterne javascriptfiler. Ja, så bliver de indlejret i hinnanden, og resulterer i scriptfejl:

<script type="text/javascript" src="/script/jquery.cycle.all.js"></script>
<script type="text/javascript" src="/script/jquery.easing.1.3.js"></script>
<script type="text/javascript" src="/script/jquery.easing.compatibility.js"></script>

Bliver til:

<script type="text/javascript" src="/script/jquery.cycle.all.js">
    <script type="text/javascript" src="/script/jquery.easing.1.3.js"></script>
    <script type="text/javascript" src="/script/jquery.easing.compatibility.js"></script>
</script>

Jeg opgav at finde den dybere forklaring på problemet, og lavede en lille funktion i stedet:

var loader = function(url) {
    var tag = document.createElement("script");
    tag.attributes.setNamedItem("type", "text/javascript");
    tag.attributes.setNamedItem("src", url);
    document.getElementsByTagName("head")[0].appendChild(tag);
}

I sin enkelthed, så tager den en script-url, og konstruerer en DOM-node af typen: SCRIPT. De ønskede attributter sættes på noden, for til sidst at indsætte den i head-sektionen. Nu kan jeg så blot lave en lille initialiceringsblok:

loader("/script/jquery.cycle.all.js");
loader("/script/jquery.easing.1.3.js");
loader("/script/jquery.easing.compatibility.js");

Og jeg er fri for scriptfejl…

Man kan også bruge funktionen, hvis man ønsker at loade sine scripts dynamisk/konditionelt. Inkluderer en type script hvis brugeren har Silverlight installeret, eller loade script ud fra browsertypen. På den måde kan man minimerer de bytes der sendes til klienten.

loader(navigator.appName.indexOf("Microsoft") != -1 ? "ie.js" : "fox.js");

Mulighederne er uendelige.

Code on…

Funktionskæder

The IMan — Tue, 24 Nov 2009 08:50:36 +0100

Teknikken bag funktionskædning, også kendt som currying, kan med stor fordel anvendes i JavaScript applikationer. Jeg ved godt at de fleste webudviklere render skrigende bort, og flamer en med etiketter som: Übergeek og akademiker-wannabe, når man nævner funktionel programmering, men hvis man piller lidt af den værste matematik-teori væk, og tager et par simple eksempler, så kan de fleste vist godt se fordelene.

Currying er den teknik man bruger, når man fylder de første parametre ud i en funktion, og returnerer en ny funktion.

var add = function(x, y){ 
    return x + y; 
} 
var add5 = function(x){ 
    return add(5, x); 
}

Så burde de fleste jo nok genkende teknikken. Oliver Steelehar lavet en lille fix funktion, som gør currying, eller funktionssammenkædning meget lettere. Lad os sige vi f.eks vil lave en partiel funktion, der hooker op på click-events. Så kan vi deffinerer den således:

var hookupClick = document.body.addEventListener
	.partial("click", undefined, false);

Og kalde den sådan:

hookupClick(function(){
	alert("Hello!");
});

Det smarte her, er at man blot udfylder parametrene med undefined på de pladser, som den nye funktion skal udfylde. Funktionen er for så vidt rimelig simpel:

Function.prototype.partial = function(){
    var fn = this, args = Array.prototype.slice.call(arguments);
    return function(){
      var arg = 0;
      for ( var i = 0; i < args.length && arg < arguments.length; i++ )
        if ( args[i] === undefined )
          args[i] = arguments[arg++];
      return fn.apply(this, args);
    };
  };

Den inplementeres som prototype på Function objektet.
I første linie initialiceres de private variabler, som kommer til at holde reference til henholdsvis den kaldende funktion (fn) og til de medfølgende argumenter (args). Det smarte her er at funktionen i sig selv returnerer en funktion, som selv har en potentiel argument array, men som samtidig får de oprindelige argumenter med via closure i den private variabel: args.
På kaldetidspunktet laves der et gennemløb af disse argumenter, og den kaldende funktions argumenter indsættes på de pladser hvor man har udfyldt med: undefined.
Til sidst afsluttes med et kald til den oprindelige funktion med den nye funktion som this parameter og den nye sammensatte argument array (args) som parameter arry.

Med den funktion, er det super let at lave sine funktionskæder, og husk at funktionen returnerer en funktion, så der er ikke overhead forbundet med at kalde den igen og igen.

Code on…

Hjælp til IL

The IMan — Wed, 18 Nov 2009 09:10:11 +0100

Jeg arbejder for tiden på et lille fritidsprojekt, hvor en af sideeffekterne er at jeg kommer til at lære lidt IL og i særdeleshed; Blive fortrolig med namespacet: System.Reflection.Emit.

Min fremgangsmåde har hidtil været at bygge koden op i et demo-projekt, og så bruge Reflector til at se den resulterende IL. Ud fra IL’en, har jeg så forsøgt mig frem, til at Emit’te instruktioner der kan fremstille den ønskede IL. Lærrerigt, men meget besværligt.

Så faldt jeg over en pudsig lille plugin til Reflector:ReflectionEmitLanguageplugin.

Når man har dll’en åben i Reflector, kan man vælge: Reflection.Emit i sprogmenuen. I modsætning til de andre sprog der er understøttet, vises der her C# kode, der konstruerer IL til de valgte objekter. Det er uhyre smart..

Her har jeg valgt sæt-metoden på en property, og voilla: BuildMethodset_Name.

Man må undres over at den plugin overhovedet findes, da publikum må være uhyre lille, men ikke desto mindre findes den, og den har været en stor hjælp på mit projekt. Min nye ven..

Code on…

Dynamiske delegates

The IMan — Tue, 03 Nov 2009 08:49:00 +0100

Har du nogensinde set Java’s DynamicProxy, så må du være lidt midsundelig. Man forstår simpelthen ikke, hvorfor folkene bag .NET, ikke har stillet den feature til rådighed. Men hov – det har de! Godt nok ikke så fint indpakket, som i Java, men den er der via Reflection.Emit. En statisk metode, der lader dig tilføje IL til en assembly runtime. Ret mig hvis jeg har opfattet det forkert, men for mig ser det sådan ud.

Jeg havde lavet forsøg med CodeDom, men kan ikke lide det overhead der er med runtime kompilering af kildekode. Så Emit er blevet min nye ven. Jeg starter ud med en opgave der er meget simpel, men som ikke kan lade sig gøre i Java: Dynamisk delegate. Lad os sige vi har brug for at hooke dynamisk kode op på en klik event – for eksemplets skyld, skal min dynamiske kode blot skrive: Hello world, men det kunne være hvad som helst.

Man starter et proxy objekt: DynamicMethod, som man så kan føje IL til via en ILGenerator.

var method = new DynamicMethod("", null, null);
var il = method.GetILGenerator();

I eksemplet her, vil jeg blot lave en delegate, så derfor er det ikke nødvendigt at angive et navn til metoden, ligesom retur type og parametre angives til null. Med ILGenerator’en, kan man nu “Emitte” IL til metoden:

il.EmitWriteLine("Hello world");
// ldstr "HelloWorld"
// call void [mscorlib]System.Console::WriteLine(string)
il.Emit(OpCodes.Ret);
// ret

Nu har vi dannet vores IL dynamisk, og så er der ikke andet tilbage, end at hooke metoden op på en event:

var myEvent = (Action)method.CreateDelegate(typeof(Action));
// Og så rejser vi eventen:
myEvent();

Det her er virkelig en kraftfuld feature, og er endnu et værktøj i C# (og VB.NET) udviklerens værktøjskasse med dynamiske muligheder. Eneste ulempe, som jeg ser det, er at man ikke kan debugge i VS.NET, og at man skal til at lære IL.

Jeg vil spike lidt på C# 4.0, og se om der er kommet features, der kan lette ovenstående.

Code on…

Handy extension

the iman — Mon, 19 Oct 2009 08:48:38 +0100

Når man arbejder med anonyme klasser, kommer man fra tid til anden, ud for at skulle udlæse properties fra et anonymt objekt. Hvad gør man så, når man ikke har en type at caste til?

Ja, principielt er der kun een ting at gøre: Reflection. Det er jo en anelse besværligt, og jeg har derfor lavet en lille extension på object. Den tilføjer metoden: Get, på alle objekter. Metoden tage et property-navn som input og returnerer et typen T eller default(T) hvis propertien ikke findes.

public static class ObjectExtension
{
    public static T Get<T>(this object container, string propertyName) where T: class
    {
        PropertyDescriptor descriptor = TypeDescriptor.GetProperties(container).Find(propertyName, true);
        if (descriptor == null)
        {
            return default(T);
        }

        return descriptor.GetValue(container) as T;
    }
}

Nu er det muligt at tilgå egenskaberne fra de anonyme objekter via en simpel metode:

var obj = new { 
    Name = "Jesper", 
    Answer = 43 
};

obj.Get<string>("Name")

Code on…

Hvordan lusker man…

The IMan — Fri, 16 Oct 2009 08:55:06 +0100

Hvordan lusker man personlige oplysninger ud af en Facebook bruger?

Hvor alle autorisations- og genkendelses services har haft ekstrem modvind i forsøget på at nå ud til en bred kreds af brugere, såer det helt anderledes ud for Facebook. Jeg har talt med mange gennemsnits brugere, der bare nægter at oprette en LiveID eller en OpenID, da de er meget skeptiske over for sikkerheden – godt hjulpet på vej af advarsler fra de forskellige mediers fantastiske IT redaktioner. De samme brugere har ingen problemer med at klikke på f.eks. www.eb.dk ’s Connect with Facebook knap.

Trods advarslen skulle være åbenbar:

Forbind til Facebook, men accepter betingelserne, og lad den forbundne site få adgang til alle dine oplysninger og alle dine venners oplysninger! I betingelserne står der blandt andet:

you grant us a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content that you post on or in connection with Facebook ("IP License").

Du giver altså i dette tilfælde Ekstrabledet ret til, at bruge alt dit meteriale og alle dine oplysninger! Hvordan der er nogen der accepterer disse betingelser fatter jeg ikke. (Ekstrabladet er blot nævnt her for eksemplet, det kunne lige så godt have været en af de 1000 andre Facebook applikationer der er der ude).

Hvor svært er det så at lokke de oplysninger ud af brugeren? Er det kun dygtige hackere der kan få disse oplysninger? Nej – det er alle der kan læse en API dokumentation… Via API’et kan man itererer igennem alle billeder, venner eller videoer uden problemer. Her står jeg midt i en for-each løkke, og har adgang til: politisk overbevisning, religion, sexuel observans og billeder. Man har adgang til alt undtagen e-mail adressen – den holder de (Facebook) for sig selv.

Ikke så ringe, når man tænker på jeg kun har brugt omkring 1 dag på at få en komplet applikation op og køre…

Hvorfor er der nogle websites, der kan tillade sig alt, uden at nogen stiller spørgsmål, og andre er under ekstrem granskning hele tiden – google.com <—> bing.com.

Nå – jeg må videre i mit beskidte arbejde med at luske personlige oplysninger ud af de godtroende brugere.

MUA-HA-HAAAaaa.

Hvordan: $.databind

the iman — Thu, 01 Oct 2009 11:16:30 +0100

Jeg har tidligere vist hvordan man kan skrue et simpelt klientside databindings framework sammen med JavaScript og jQuery. Her vil jeg vise hvordan jeg bruger det til løsningen af simple som i komplekse opgaver.

Scenarie: Visning af data i en tabel

Jeg starter med at hente de data jeg skal bruge. Her foretrækker jeg at modtage data der er serialiceret som JSON, men Xml kunne lige så godt have været brugt. Oftest bruger jeg en Controller, der sættes til at returnerer et ActionResult af typen: JsonResult. Det har vist sig at være den nemmeste måde, og den understøttes direkte i MVC frameworket. En typisk implementering:

public ActionResult GetAppointments(int userid, DateTime date)
{
     var result = new JsonResult();
     result.Data = model.GetAppointments(userid, date);
     return result;
}

Andet skal der ikke til for at returnerer data i et kompakt og hurtigt format. Ovenstående kontroler vil give et resultat af formen:

[
{uid: "12-aa-234", time: "9:00", subject: "Morgenmad", description: "Fælles spisning i kantinen" },
{uid: "12-aa-235", time: "12:30", subject: "Frokost", description: "Fælles spisning i kantinen" },
{uid: "12-aa-236", time: "13:45", subject: "Sprint planning I", description: "Vi skal have planlagt næste måneds sprint\nProductowner: Henning" }
];

Vi kan altså i vores JavaScript kode, kalde kontrolleren, og få data retur. Det gøres nemt med jQuery:

$.getJSON(
    "/Schedule/GetAppointments", 
    {userid: "JJ", date: new Date()},
    onDataRecieved
);

Læg mærke til at man i metodekaldet kan angive en callback funktion, der skal udføres, når data kommer retur. Metoden kan have to parametre; data og status. Data er det Json objekt der returneres fra servicen, og status er en streng der blandt andet kan have værdien “success” og “failed”, alt efter hvordan kaldet forløb, men går alt godt, har man nu det dataobjekt, der blev genereret på serveren, som parameter i callbackmetoden. Vi kan nu tage skridt til at vise data.

Her er det min databind extension kommer ind i billedet. Jeg starter med at lave Html til visningen:

<table id="myGrid">
    <tr>
        <td><a href="/Schedule/Detail/{uid}" title="{description}">{time}</a></td>
        <td>{subject}</td>
    </tr>
</table>

Læg mærke til “tuborg”-klamme syntaksen. Det er databindingssyntaksen for mit lille framework, og vi kan nu kalde extensionen via jQuery:

function onDataRecieved(data) {
    $("#myGrid tr").databind(data);
}

Voilla – vi viser data i tabel-html’en. Læg mærke til at metoden tager udgangspunkt i det element som jQuery selectoren rammer. Havde jeg brugt: $("#myGrid"), var det hele tabellen der var blevet gentaget for hver record. I det jeg rammer TR, fungerer den dynamiske tabel.

Code on…

Arrays er objekter

the iman — Mon, 28 Sep 2009 08:39:46 +0100

Eller: Hvordan begrænser man virkeområdet for sine klasser i JavaScript?

Bruger du mit jsCoreExtensions, eller prototyper du Array eller Object i dine JavaScript, så vil du på et eller andet tidspunkt løbe ind i det problem jeg taler om her (hvis du da ikke allerede er det).

Hvis du f.eks. bruger en for(in) løkke, eller kalder Array.push, så får du Objektet understøtter ikke denne metode fejl. Fejlen opstår når man laver udviddelser til Array via prototype egenskaben. Så er arrayen nemlig ikke længere at betragte som en array, men som et objekt. Derfor har man ikke længere de specielle metoder fra array objektet til rådighed. Hvad gør man så, hvis man bruger mit lille bibliotek for at kunne “LINQ’e” i JavaScript?

myArray
	.where("itm.age > 35")
	.select(function(itm){
        	return {
			name: itm.name,
			isApproved : true
		};
    	});

Her kan vi ikke nøjes med at namespace sig ud af problemerne. Man har brug for at indkredse sit virkeområde, og fremstille en ny klasse (objekt). Mine array extensions er inspireret af LINQ, og bruger derfor method-chaining, for at opnå den “rigtige” LINQ feel. Mit nye objekt skal altså returnerer en instans af sig selv ved hver metodekald:

var Chain = function(array) {
    // privat medlem
    var _array = array;
    return {
        metode1: function(arg) {
            // Impl. af metode 1 funktionalitet der arbejder med _array
            // returner frisk Chain
            return new Chain(_array);
        },
        metode2: function(arg) {
            // Impl. af metode 2 funktionalitetder arbejder med _array
            // returner frisk Chain
            return new Chain(_array);
        }
    }
}

På den måde får man pakket sin array logik ind, og man får ikke problemer med 3. parts kode, der arbejder med Arrays. Det eneste minus ved dette mønster, er at man nu er tvunget til at konstruerer et nyt objekt, for at kunne benytte funktionaliteten:

var myArray = [1, 2, 3, 6, 9 ,8];

// Tidligere: 
myArray.metode1().metode2();

// Med indkapsling
var chain = new Chain(myArray);

chain.metode2().metode1();

Den pris finder jeg lille nok til at jeg nu vil implementerer det på mine Array-prototype-extensions. Da man så ikke længere kan kalde metoderne for core-extensions, vil jeg flytte dem ud af jsCoreExtensions, og ind i et nyt array-linq bibliotek. Jeg vender tilbage når arbejdet er afprøvet.

Code on…

Dato SQL roundtrip

the iman — Tue, 22 Sep 2009 11:28:06 +0100

Jeg var måske lidt forvirret da jeg skrev min post om datoer i går, så jeg kommer lige med en specificering af mine undersøgelser. Jeg tager udgangspunkt i følgende lille konsol app:

var sel = new SqlCommand("SELECT TOP 1 * FROM DatoTabel order by id desc", forbindelse);
var insert = new SqlCommand("INSERT INTO DatoTabel (Dato) VALUES (@dato)", forbindelse);

var dato = new DateTime(2009, 9, 21, 12, 0, 0);

Console.WriteLine("DateTime instans");
Console.WriteLine("Værdi: {0:o}", dato);
Console.WriteLine("Kind: {0}", dato.Kind);
Console.WriteLine("====================");

insert.Parameters.AddWithValue("@dato", dato);
forbindelse.Open();
insert.ExecuteNonQuery();

using (var r = sel.ExecuteReader())
    if (r.Read())
        dato = r.GetDateTime(1);

forbindelse.Close();

Console.WriteLine("SQL roundtripped instans");
Console.WriteLine("Værdi: {0:o}", dato);
Console.WriteLine("Kind: {0}", dato.Kind);

Den giver følgende output:

Her skal man bemærke at variablen: dato, bliver instantieret til et specifik dato-klokkeslæt. Kind er som default Unspecified, og SQL roundtrippet returnerer også Unspecified. Helt som man kunne forvente (men var det det man forventede?).

Hvis vi prøver med den overload, hvor man kan specificerer Kind:

var dato = new DateTime(2009, 9, 21, 12, 0, 0, DateTimeKind.Local);
// DateTime.Now har også Kind=Local

Så får man følgende overraskende resultat:

Vi gemmer en dato med tids-zone, men får en “DK-UTC” værdi tilbage – altså det samme klokkeslæt, men man har mistet zone informationen. Nu er man altså overladt til konventioner, når man hiver datoer ud af databasen. Det viser sig at vi helt upåagtet har en konvention der siger:

Når vi gemmer en DateTime i databasen, så gemmer vi den med dansk zone-offset som udgangspunkt.

Man bør derfor rette sin udlæsningskode til på følgende måde, når man har den konvention:

dato = DateTime.SpecifyKind(r.GetDateTime(1), DateTimeKind.Local);

Det vil give følgende output:

Så er der styr på zonen… så længe klienten har dansk som lokal indstilling… Man kan altså få overraskende resultater, hvis man f.eks. har en webserver der står i USA, og man bruger ovenstående konvention, for så bliver man offsat med 6 timer.

Hvis man starter på en ny database, vil den rigtige løsning være at vedtage en konvention, der siger at alle DateTime værdier der gemmes i databasen, skal tolkes som UTC. På den måde vil man ikke blive snydt af klienter/servere med forskellige zoner. Man skal så sørge for at konverterer DateTime objektet inden man gemmer, og så skal man specificerer Utc når man henter:

Console.WriteLine("DateTime instans");
Console.WriteLine("Værdi: {0:o}", dato);
Console.WriteLine("Kind: {0}", dato.Kind);
Console.WriteLine("====================");

insert.Parameters.AddWithValue("@dato", dato.ToUniversalTime());
forbindelse.Open();
insert.ExecuteNonQuery();

using (var r = sel.ExecuteReader())
    if (r.Read())
        dato = DateTime.SpecifyKind(r.GetDateTime(1), DateTimeKind.Utc);

forbindelse.Close();

Det giver følgende output:

Nu kan ma så lade klienten tage stilling til hvilken tids-zone der skal vises, og man kan kalde ToLocalTime metoden, hvis man vil udlæse i den aktuelle tids-zone.

Alternativt, kan man vælge en af de nye felttyper i SQL Server 2008, hvor man har DateTimeOffset, som jo gemmer zone info. Husk bare at en konvertering fra DateTime, skal tage højde for den implicitte konvention på de eksisterende felter.

Hvilken dato gemmer du?

the iman — Mon, 21 Sep 2009 15:30:09 +0100

Jeg sidder for tiden og arbejder med en applikation, der håndterer kalender events. Applikationen er gammel, og har masser af data. Den gamle data ligger i SQl server, så vi får ingen problemer når vi skal til at håndterer tids-zoner…øhh vel?

Hvordan er det lige at vi gemmer DateTime med SqlClient i .NET frameworket?

Jeg har prøvet at undersøge sagen lidt nærmere, og jeg må sig jeg blev lidt overrasket. Når man instantierer en DateTime struct, får den automatisk sat egenskaben; Kind til Local. Det vil sige at følgende kode:

var dato = new DateTime(2009, 9, 22, 12, 0, 0);
Console.Write(dato.ToString("o"));

Giver følgende output: 2009-09-22T12:00:00+2 (når det bliver kørt i dag 21/9 2009)

Når jeg så gemmer værdien i Sql-server med SqlClient, og læser den ud igen, så er Kind egenskaben gået tabt. Den er nu angivet til Unspecified, og tidspunktet er stadig 12:00.

Man putter altså tids-zone info ind, men den forsvinder i databasen. Det skyldes at Sql servers felttype, kun indeholder en dato-tid værdi – ikke tids-zone værdi. Den kan altså ikke bare lade udlæsninger fra klienten blive angivet til Local – det har den simpelthen ikke viden om.

Hvad gør man så når man vil kode en applikation, der kan håndterer forskellige tids-zoner?

Man skal vedtage en konvention, om at DateTime kolonnerne i databasen, skal tolkes som UTC.
Man skal koverterer inputdatoer til UTC når man sætter SqlParameter værdier.
Man skal specificerer Kind til Utc, når man udlæser fra databasen

ins.Parameters.AddWithValue("@dato", dato.ToUniversalTime());

var dato = DateTime.SpecifyKind(sqlReader.GetDateTime(1), DateTimeKind.Local)

Følger man de retningslinier, får ma ingen problemer.

Har man et legacy system, hvor man har gemt datoer i dansk zone, skal man enten

Konverterer alle datofelter til UTC

eller

Isolerer koden der læser/skriver til kolonnerne, og tvinge dem til at angive Kind til Local, ved alle læsninger.

Hvad vælger du?

2 teams – 2 parsere

the iman — Wed, 16 Sep 2009 09:37:15 +0100

Eller: Hvorfor ved højre hånd ikke hvad venstre gør?

Jeg har tidligere plederet for at man skulle ligge sig op ad MS’s System.Web.Script.JavaScriptSerializer til serialicering af Json objekter, og specielt datoer. Det virker super fint, selvom jeg har været noget ked af formatets læsbarhed (en egenskab som ikke er helt ubetydelig). Nu bliver jeg så opmærksom på at alle de store browsere: IE, Firefox og Chrome er begyndt at understøtte native Json serialicering. Ja man kan nu skrive følgende, uden at inkluderer 3. parts biblioteker:

var json = JSON.stringify(new Date());
alert(json);

Men hvordan serialicerer den nye parser så datoer? Jo resultatet er overraskende: 2009-09-16T22:00:00Z

Implementeringen understøtter iso datoer som også kendes fra xml!

Det er jo dyb krise at man på den ene side har en server teknologi der serialicerer datoer på en måde, og en klient teknologi der serialicerer på en anden.

Bruger man System.Web.Script.JavaScriptSerializer på serveren, kan man ikke udnytte den overlegne performance som serializeren har på klienten.

Heldigvis understøtter JSON.parse en mulighed for at man efterbehandler resultatet, inden objektet returneres. Man giver bare metoden en funktion som 2. parameter:

var date = JSON.parse(json, function(key, value){
    // Implementer efterbehandling
});

Det åbner muligheden for at man på klienten kan understøtte MS’s specielle format, og Rick Stahl har implementeret den form for efterbehandling i et minimalt bibliotek, så man kan håndterer MS dato serialicering.

Det løser problemet, men havde højre hånd bare vidst hvad venstre foretog sig…

Code on…

En ikke helt problemfri opdatering

the iman — Tue, 15 Sep 2009 09:00:44 +0100

Jeg er faldet over et website, der bruger jQuery til at styre forskellige layout ønsker, og til at hooke forskellige handlere op på events. Det sprang mig i øjnene, at sitet havde reference til JQuery 1.1, og jeg opdaterede selvfølgelig straks. Jeg havde brug for nogle af de animations effekter der kom med 1.3 - Det skulle jo ikke være noget problem vel? EEEEIk! Wrong answer. Hele skidtet brager ned, og primært på grund af nøglefunktionen i JQuery - $(exp). Den melder: Objektet understøtter ikke denne egenskab eller metode, når koden forsøger at lave følgende udvælgelse: $("*[@behaviours='inputInitValue']").

Det viser sig nemlig at jQuery tidligere brugte XPath til at udfører sine søgninger i DOM’en med. Man fandt bare ud af at en mere optimeret søgning i kilde-html’en med regulære udtryk, performede langt bedre. Det jeg oplever her, er blot et grænsetilfælde af konverteringen, som den nye parser ikke kan håndterer.

Men hvad gør man så, når man har kode der tidligere kunne udvælge på tilstedeværelsen af en bestemt attribut værdi?

Det viser sig at man har valgt en syntaks, der er lidt mindre kryptisk – man har fjernet @ fra syntaksen, og så har man jo lige tilføjet et par ekstra features.

Den simple: [attr], som udvælger elementer med den angivne attribut uanset værdi
[attr=value], udvælger elemeter der har en attribut med en bestemt value
[[attr!=value], som udvælger de elementer der har attributten, men som ikke har den angivne value
Mere eksotisk: [attr^=value], som udvælger de elemeter der har en attributværdi der starter med value
Endnu mere eksotisk: [attr$=value], som udvælger de attributter der har en værdi der ender med value
[attr*=value], som udvælger elementer med en attributværdi der indeholder value
Flere attributfiltre kan tilføjes ved at man kæder dem: [attr1=value][attr2=value] osv.

Ved første øjekast, ser det måske lidt kryptisk ud, men kender man RegExp, kan man hurtigt se at der er en linje i syntaksen, og den er ret nem at huske.

Det API er bare så fyldt med gode sager, og jeg bliver dagligt forundret over de måder man kan kode JavaScript på med hjælp fra jQuery.

Code on…