De sidste 14 dage har de to haft mindst een defekt mailserver i deres DNS rotation, hvilket effektivt fører til at det er umuligt at udtale sig om hvorvidt en modtager på domænerne kan/vil modtage mails man sender til dem.

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.

Knapt er vi kommet os over panikken omkring år 2000-problemet, også kendt som Y2k, der nærmest truede med verdens undergang i en sådan skala at det gør selv 2012 filmen til skamme, inden at vi rammes af en ny katastrofe; 2010 årsskiftet!

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.

Vores studenterprogrammør Asger, har haft leget med 3D visualisering og programmering. Her følger en artikel om hans første udskejelser i den virtuelle verden.

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.