CrazyEgg er et værktøj til at visualisere brugernes færden på ens site, og indeholder smarte funktioner som: Click-overlay, Heatmap og Confetti.

Man indsætter en enkelt linje kode på de sider der skal trackes:

<script src="http://s3.amazonaws.com/new.cetrk.com/pages/scripts/0010/6701.js"
type="text/javascript"></script>

Derefter opsættes de sider der skal trackes i CrazyEgg:

Efter nogle dage begynder statistikken at være på plads.

Her er de forskellige overlays.

Standard overlay:

Heatmap:

Confetti:

Standard overlayet giver os mulighed for at se hvor mange clicks et givet link har fået. Heatmap er rimeligt selvforklarende – den viser os hvor “populært” et link eller anden detalje er. Den mest interessante er Confetti, som har følgende indstillings-muligheder:

Alle disse overlays skulle sammenlagt give ens hjemmesidedesigner mulighed for at designe en mere brugervenlig oplevelse.

Kombineret med det faktum, at det kan konstateres at have været tilfældet temmelig mange gange over de seneste par år, samt at det (selvsagt) er 100% umuligt at komme igennem med en fejlmelding til de to giganter, kan jeg vanskeligt konkludere andet end at det er en usædvanlig dårlig idé at benytte deres services, med mindre man er indstillet på at acceptere at mails periodisk og uden meldinger eller advarsler vil gå tabt.

Dog vil gælde, at afsenderen af mails der ikke afleveres må forventes at modtage en tilbagemelding om, at den/de pågældende mails ikke kunne afleveres – men hvis ikke afsender derefter finder en anden måde at kontakte modtager på, og orienterer om problemet, vil man aldrig blive opmærksom på at der er noget galt.

Supplerende ovenstående, for at give det lidt mere tekniske indblik, er mailserver-administrationen for systemer så store som de to, naturligvis ikke en enkel og simpel sag. Jævnfør det her indsatte øjebliksbillede af et opslag med nslookup, fordeler Hotmail sine mailservere over 5 indgange, hver med cirka 10 IP numre. Hvorvidt det i praksis bliver til 50 servere er vanskeligt at udtale sig om udefra – men det er indlysende at kompleksiteten af en sådan opsætning ikke er ubetydelig.

Som man kan læse i denne artikel, er Dankort systemet i ca. 1.600 P-automater i København, umiddelbart lige efter kl. 23.59 d. 31/12-2009, ophørt med at fungere til stor undren for folkene bag, og stor irritation for alle øvrige.

Det er en påstand herfra, at P-automat betalingssystemet der anvendes utvivlsomt er udviklet efter år 2000-problemet blev konstateret og løst.

Dels har det jo kørt upåklageligt da årstallet viste “00″, “01″, “02″, “03″, …, og “09″, og der ville nok først igen opstå problemer når der trilles over de “99″ til “00″ (lige som sidst). Desværre vippede det nye årstal ikke rundt til et “10″ som man vist havde regnet med, men istedet til “0A”, der er det hexadecimale talsystems repræsentation af decimaltallet 10. Det hexadecimale talsystem er et som computere har det ret godt med – en byte omfatter 8 bits, der dækker decimaltallene 0 til 255, eller hexadecimalt 00-FF. Og så gik maskineriet i selvsving, “0A” og “10″ kunne ikke sammenholdes mellem den grænseflade der er mellem betalingssystemet og yderligere systemer.

Den anden vinkel på hvorfor P-automat betalingssystem må og skal være etableret efter Y2k er at det simpelthen ville være opdaget i 1999 også; decimaltallet 99 repræsenteres som 63 hexadecimalt. Mon ikke der havde været rod i et regnskab eller to, med bogføring af indkomster fra 1963 i år 1999 uden nogen form for renteindtægt eller forudgående poster med langsigtede krediteringer?

Hvis vi tænker lidt over hvorfor man efter en så voldsom omgang skruen på kode der vedrører datoer, alligevel er kommet frem til at holde årstallet i en byte og repræsentere denne talværdi i systemet hexadecimalt både internt og eksternt, ja så er min personlige konklusion helt klar. Tanken må have været at alle da bare skal se i en fart at få lært det hexadecimale talsystem. Det er jo over 2,5 gange mere fremtidssikret med hensyn til hvornår en ny Y2K fejl opstår, vi har jo med talrummet fra 0 til 255 at gøre og ikke kun 0 til 99. Desuden vil det fjerne enhver form for enkodnings- og/eller formatteringsproblematik der måtte være en gang for alle, ved ganske enkelt blot at anvende et fælles og maskinelt nemt behandlingsbart talsystem.

Snedigt!

Der er flere der er ramt af andre nye årstals problemer, blandt andet kan nævnes Windows Mobile. Her er problemet at SMS beskeder ankommer i 2010 som om de er sendt i 2016. Det skyldes samme problemstilling bare vendt på hovedet: “10″ kommer ind, og behandles hexadecimalt, hvilket giver decimalværdien 16.

Alle SAP systemer er tilsyneladende også ramt af 2010 problemet, det kan man læse mere om her.

Så husk det nu: Enkodning, formattering og valg af datatyper er vigtigt.

Her i juletiden har mange været påvirket af huller i asfalten langs eksempeltvist Vejle fjordbroen. Hvis vi begiver os ud i et tankeeksperiment er det med relativt simple billedbehandlingsalgoritmer “nemt” at detektere en betydelig andel af opbyggende huller og dermed kunne man forebyggende iværksætte udbedrende vejarbejde før et problem opstår.

Et eksempel kunne være anvendelse af thresholding, erosion og dilation på en stribe billeder taget af asfaltoverfladen på udvalgte vejstrækninger. For resten af denne artikel antages det, at sådanne billeder er tilgængelige.

Herunder vises en række billeder af asfaltoverflader hvor der er opstået minimale huller og sprækker, samt hvor alvorlige slaghuller forekommer og er delvist udbedrede. Ligeledes vises en normal asfalt overflade. Under hvert billede vises en morfologisk behandlet udgave, der har været underlagt den samme algoritme for samtlige billeder. Givet disse resultatbilleder er det relativt simpelt at afgøre hvorvidt et behandlet resultatbillede udgør en kandidat til manuel inspektion eller ej.

Klik på billedet for at se en stor udgave.

“Proof-of-concept” algoritmen benyttet på resultatbillederne herover er skrevet i .NET C#, og ser overordnet således ud:

Bitmap input = new Bitmap(filename);
Bitmap output =
  Dilate(
    Dilate(
      Threshold(
        Dilate(
          Dilate(
            Dilate(
              Dilate(
                Grayscale(input)
              )
            )
          )
        ), 70
      )
    )
  );

output.Save(
  Path.GetFileNameWithoutExtension(filename) +
  ".processed" + Path.GetExtension(filename));

Tankeeksperimentet skal naturligvis føres videre ud før det bliver praktisk anvendeligt.

Det er klart at der vil være tale om mange tusinde billeder og adskillige terrabytes data, hvorfor system arkitekturen bag processeringssystemet bør være baseret på en skalerbar multiserver/multikerne teknologi. Et eksempel på en gratis open-source arkitektur kunne være AMD’s Framewave eller nVidia’s CUDA.

Ligeledes vil der være særlige elementer i billederne der skal tages særlig hånd om, f.eks. vejstriber og overgange mellem forskellige belægningstyper med videre.

Herfra tak for året der går på hæld, med alle de bedste ønsker for de næstkommende.

MPMoviePlayerControlleren gør at vi som udviklere kan abstrahere fra hvilket format filmen ligger i, om den ligger lokalt på iPhonen eller skal tilgås gennem en URL og om filmen skal streames eller hentes helt før afspilning starter.

Trinene for at afspille film fra vores iPhone app er derfor ganske simple.

1. Tilføj frameworket MediaPlayer til Xcode projectet.
2. Alloker plads til MPMoviePlayerControlleren og initialiser denne med en URL eller en sti til en film.
3. Fortæl afspilleren at den skal starte afspilningen.

Et kode eksempel kan ses her

Og voila! App’en kan nu åbne iPhonens medieafspiller og via denne afspille film.

Det var jo dejligt nemt så vi kan hurtigt gå videre til at kigge på nogle af de lidt mere avancerede ting, der stilles til rådighed med MPMoviePlayerController.

Det første vi vil kigge på er at tilpasse afspilleren til vores behov. Som udgangspunkt bruger afspilleren iPhonens standardinstillinger, så det er op til brugeren om filmen skal afspilles i fullscreen tilstand, om han vil have mulighed for at spole i filmen og ændre på volumen.

Hvis vi selv vil kunne styre dette, for eksempel bestemme at filmen skal afspilles i fullscreen og uden mulighed for at spole, kan dette også klares med et par linjers kode.

Og nu til noget mere avanceret. Afspilleren har mulighed for at underrette os når den skifter tilstand, som for eksempel når den har loadet filmen, afspilning er færdig eller skærmen liver resized. Herunder ses et eksempel på brugen af disse notifications hvor vi deallokerer afspilleren når den er færdig.

Først skal vi fortælle iPhonens notification center at vi gerne vil observere meddelelser af typen MPMoviePlayerPlaybackDidFinishNotification og når der kommer en af disse skal funktionen moviePlaybackFinished kaldes.

Dernæst skal vi have skrevet funktionen moviePlaybackFinished som bare skal deallokerer afspilleren.

Og til sidst skal vi for en god ordens skyld huske at fjerne observeren når applikationen er færdig.

Observers kan også bruges til at initialisere overlays, GUI elementer
der ligger hen over filmen, når filmen er færdig med at loade eller
meget andet. Herunder ses et eksempel på en film med undertekster.

En god indgang til 3D programmering er landskabet. Landskaber er som oftes statiske og programmøren behøver derfor ikke tage hensyn til bevægelige dele. På nettet kan man finde tonsvis af tutorials omkring landskabsgeneration ud fra højdekort, både ment som introduktion til 3D programmering, men også til de udviklere, der gerne vil optimere deres første implementation og tilføje flere visuelle effekter til det. Desuden er udgangspunktet for mange spiltyper, FPS-, RPG- eller strategispil, en verden hvor spilleren kan bevæge sig rundt, og landskabet kan være grundstammen for at skabe denne verden.

Derfor faldt valget naturligt på et landskab som første applikation til at prøve kræfter med 3D programmering.

En demo af Asger’s landskabsapplikation kan ses her:

En 3D verden er mere end bare trekanter tegnet på en skærm. Det kan være en god idé at finde sig en 3D engine til at tage hånd om bruger input, renderingsstrukturen og som tillader programmøren at abstraherer fra hvordan billeder loades som texture og hvordan matematikken bag rotation og kollision fungerer.

Her faldt valget på OpenEngine. En open source engine komplet med matematik biblioteker, geometri abstractioner, loading af 3D Studio Max modeller og brugerinputhåndtering. Derudover kan programmøren selv ændre eller tilføje til engine, hvis man har idéer til udvidelser.

OpenEngine har desuden en OpenGL 2.0 extension. OpenGL er et cross platform 3D api, så dette vil tillade landskabsapllikationen at køre på både Linux, Mac os X og Wndows. Windows har desværre ikke support i øjeblikket, så det vides ikke om OpenEngine stadig kan køres fra det OS.

Rustet med OpenEngine skulle landkabet så implementeres. Det er pt. blevet til et landskab med følgende features.

• Level of detail – Landskabet understøtter dynamisk level of detail. Det vil sige at når kameraet flytter sig længere væk fra landskabet, bliver landskabet automatisk mindre detaljeret. Grunden til dette er at langt væk fra vil brugeren alligevel ikke kunne se de finere detaljegrader, så vi kan fjerne disse og vinde noget performance.
• Culling – En anden måde at vinde performance på er naturligvis ved slet ikke at tegne noget. Det giver ikke meget mening for ting på skærmen, men for geometri der er udenfor skærmen eller gemt bag ved anden geometri, kan man vinde ekstra performance ved slet ikke at tegne disse.
  Landskabet understøtter dette ved en teknink kaldet frustum culling. Her beregnes der en boks rundt om dele af geometrien og denne boks testes så imod skærmens placering. Kan boksen ikke ses på skærmen, kan geometrien inde i boksen naturligvis heller ikke og vi undlader derfor at sende geometrien til grafikkortet.
• Geomorphing – Problemet med level of detail er at der pludselig popper flere vertices ind i verdenen når verdenen bliver mere detaljeret, eller der pludselig forsvinder en del af verdenen når nogle detaljer fjernes. Denne poppen er meget synlig for brugeren og skal derfor fjernes. Der er flere løsninger til dette,
  blending, geomipmapping eller geomorphing. Valget faldt på geomorphing, da denne rimelig nemt kan udvides til at tillade et dynamisk terrain og kan laves med næsten intet performance tab i en shader.
• Shadowmaps – Et problem, der ikke er håndteret ved geomorphing, er skygger. Skyggerne er som udgangspunkt beregnet pr vertex, men dette giver samme poppen i skyggerne, som vi lige har fjernet ved geometrien.
  Løsningen her er enten at morphe skyggerne sammen med geometrien eller bruge et shadowmap. Begge løsninger er blevet afprøvet og den sidste er klart den flotteste. Grunden er at ved brug af et shadowmap har vi altid skyggerne i den højeste detaljegrad, så selvom små bakker i landskabet ikke længer bliver tegnet i geometrien, kan spilleren stadig ’se’ dem, da de stadig kaster skygger på terrainet. Denne løsningen tillader også at fjerne nogle af de højeste level of details for yderligere performance, men spilleren vil stadig kunne ’se’ dem, da skyggerne stadig kastes.
• Shaders – Skal man lave noget som helst interessant i 3D grafik i dag skal man bruge shaders. Shaders tillader programmøren selv at specificerer hvad grafikkortet skal gøre med vertices og hvordan det skal beregne farver og skygger.
  Naturligvis er der derfor også brugt en shader på landskabet. Denne står for at lave geomorphing, smide texture på landskabet baseret på højde, så der kommer strand i bunden og sne på toppen af bjergene. Desuden beregner den skygger og hvor meget af landskabet, der skal kunne ses under vand.

Koden bag landskabet kan ses her eller ved at hente OpenEngine, som beskrevet her og hente projektet terrain. Herfra kan projektet også kombileres og køres. Som nævnt er der ikke Windows support for OpenEngine pt, så projektet er kun blevet testet under Linux og Mac os X.

Eksempel på IE6 advarselsdialogboks

De logiske
Som ofte er tilfældet viser der sig i praksis at være forskel på hvordan markedets browsere håndterer sikkerhed – herunder er de selvskrevne kandidater til en checkliste for at undgå problemer er inkluderinger af eksternt indhold, som skal angives enten med en relativ eller HTTPS URI.

• <img src="..." alt="Ellipsis" />
• <script type="text/javascript" src="..."></script>
• <link rel="..." href="..."></script>

Værd at bide mærke i, i forhold til ovenstående er at følge op på hvad eventuelt 3. parts værktøjer som eksempelvis Google Analytics, Omniture og lignende indsætter af referencer – de fleste af disse har HTTPS-baserede ækvivalenter.

De bemærkelsesværdige
Hvad der formentlig er knap så indlysende er, at i Internet Explorer også <object codebase="..."> og <embed pluginspage="..."> skal angives relativt eller eksplicit med HTTPS. På trods af at browseren ikke gennemfører en request på URI’en, bliver der lavet en kontrol af overenstemmelse med dokumentets protokol.

Intuitivt eller ej, gør det sig også gældende for Internet Explorer, at eventuelle inkluderede URI’er der resulterer i en HTTP fejlkode, vil blive behandlet som usikre, idet det er browserens klassificering af sine egne fejlsider.

De lumske
Til gengæld er det formentlig kun blandt Microsofts egne udviklere indlysende, at brugen af iframe’s med enten tom eller ingen src-angivelse betragtes som en reference til HTTP og altså vil give en advarsel på en HTTPS side. Har man brug for den tomme iframe, kan eventuelt angives en reference til et tomt dokument, eller værdien “javascript:false“

Sidst, men bestemt ikke mindst: Hvis der benyttes javascript der kalder removeChild() på et element der har et baggrundsbillede kan fejlen også optræde. Omgåelsen er nem: Sæt i stedet outerHTML='' (og nej, der er ingen logisk og rimelig grund til at tingene skal virke sådan).

De ligegyldige
Blandt de ting der kan ignoreres uden konsekvenser, er protokolangivelser i:

• DOCTYPES
• XHTML namespaces
• Links

Forhåbentlig ovenstående kan redde uskyldige forbipasserende for timevis af fejlsøgning – kommer man alligevel dertil hvor der skal graves, er netværksovervågning et godt angrebspunkt – herfra er høstet gode erfaringer med både Ethereal og Fiddler.

Bemærk, at CONNECT requests altid vil ske via HTTP, men alt andet skal ske på HTTPS.

Det Open Source API fra MaxMind som vi har anvendt består af seks C# klasser, hvoraf kun to skal instantieres for at benytte applikationen til fulde (der er API til yderligere programmeringssprog også, se forrige link). Det drejer sig om klasserne: LookupService og Location.

LookupService instantieres med en sti til databasen, samt (optionelt) en int, der fortæller om databasen skal læses direkte fra filen, eller gemmes i en buffer. Som standard læses der direkte fra filen, men i hastighedskritiske sammenhænge, kunne man muligvis ønske at cache databasen. Dernæst bruges LookupService objektet til at instantiere Location.

Location instantieres ved at kalde getLocation() på LookupService med den ønskede IP-adresse som parameter. Når det er gjort, er man klar til at udnytte de mange muligheder GeoLite City tilbyder. Dette gøres i første omgang ved at tilgå de public attributter der ligger i Location.

Dette eksempel udskriver land og breddegrad for IP-adressen, 208.77.188.166:
Bemærk at der kastes en exception hvis IP’en ikke findes, og koden bør derfor sættes i en try-catch blok.

LookupService ls = new LookupService(@"C:\...\...\GeoLiteCity.dat", GEOIP_STANDARD);
Location l = ls.getLocation("208.77.188.166");
Console.WriteLine("Land: " + l.countryName);
Console.WriteLine("Breddegrad: " + l.longitude.ToString());

Oplysninger om land ville i praksis f.eks. kunne bruges til, at redirigere en hjemmesidebruger hen til en version af siden i det pågældende lands sprog.

Man kunne også forestille sig, at en hjemmeside ønskede at vise mindre ressourcekrævende udgaver af siden til langsomme forbindelser. Her ville man også kunne benytte sig af GeoLite City. I dette tilfælde kunne koden se nogenlunde sådan her ud:
Bemærk at man her benytter LookupService og ikke Location.

int i = ls.getID("208.77.188.166");
if (i == LookupService.GEOIP_UNKNOWN_SPEED)
{
   Response.Redirect("http://example.net/standard.asp");
}
else if (i == LookupService.GEOIP_CABLEDSL_SPEED)
{
   Response.Redirect("http://example.net/fast.asp");
}
else if(i == LookupService.GEOIP_DIALUP_SPEED)
{
   Response.Redirect("http://example.net/slow.asp");
}


Her er et eksempel på en lille webapplikation, der oplyser land, by og koordinater for angivne IP adresser. Eksemplet vælger som standard www.hinnerup.net serverens globale IP. Der kan indtastes såvel IPv4 som IPv6 adresser i IP-adressefeltet.

GeoLite City kan hentes her og opdateres en gang om måneden.