I forbindelse med et eksamensprojekt i kurset IT-projektledelse har Hinnerup Net og de fire kandidatstuderende Rune Lykke, Mikkel Løfquist, Daisy Steffensen og Pernille Thorsen været så heldige at få lejlighed til at indgå i et samarbejde om en case.

Kurset de studerende fulgte omhandlede overordnet alle faserne i et projektforløb, hvor gruppen valgte at have særlig fokus på opstart, styring og udførelse af et IT-projekt. Her inddragedes forskellige ledelses- og projektmæssige teorier til at beskrive opstarten.

Basis for casen var det samarbejde Hinnerup Net har med LEGO, i forbindelse med de nuværende og kommende projekter, der er henholdsvis er i gang og under planlægning. I og med at Hinnerup Net og LEGO anvender SCRUM, blev dette desuden et af fokusområderne i opgaven.

Eksamensprojektet er tvedelt, således at opgaven i sig selv gøres til objekt for projektledelse, sideløbende med at der blev udarbejdet en analyse af den aktuelle case. Gennem casen opnås værdifuld indsigt i, hvad det vil sige at opstarte og lede et projekt samtidigt med, at der opnås et indblik i hvorledes en professionel organisation griber projektledelse og projektarbejde an.

For Hinnerup Net betyder samarbejdet med de fire studerende en mulighed for at holde fingeren på pulsen med hvad der sker i uddannelsesmiljøet, og det er naturligvis ikke uden en vis stolthed, at der bringes viden tilbage til en af de institutioner vi selv gennem tiden er uddannet fra.

Karaktererne for projektet er netop uddelt idag, og vi bringer hermed et stort tillykke til de fire 12′tals modtagere! Godt gået!

LINQ to XML er en del af LINQ, og er designet til at trække data ud af xml, fra eksempelvis en fil.

Vi skal bruge namespacet ”System.Xml.Linq”. Dette namespace indeholder klasser som XDocument, XElement, XAttribute og XNode. Det er nogle af disse vi bruger i vores query.

LINQ syntaksen minder meget om SQL og kan ses her:
http://msdn.microsoft.com/en-us/library/bb308959.aspx#linqoverview_topic5

Lad os springe ud i det.

Lad os først finde noget XML vi selektivt vil trække data ud af. Følgende er et log udtræk fra SVN:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

<?xml version=”1.0″?>
<log>
  <logentry revision=”200″>
    <author>Lars</author>
    <date>2010-06-03T08:24:19.329726Z</date>
    <paths>
      <path action=”M”>/sti/Upload.ascx.cs</path>
      <path action=”D”>/sti/Projekt.csproj.user</path>
    </paths>
    <msg>Changes to upload path handling</msg>
  </logentry>
  <logentry revision=”199″>
    <author>Lars</author>
    <date>2010-05-31T14:30:23.080950Z</date>
    <paths>
      <path action=”M”>/sti/Database.mdf</path>
      <path action=”M”>/sti/Database.ldf</path>
    </paths>
    <msg>Shrinked database again</msg>
  </logentry>
  <logentry revision=”198″>
    <author>Lars</author>
    <date>2010-05-31T13:59:33.689391Z</date>
    <paths>
      <path action=”A”>/sti/Projekt.sln</path>
      <path action=”A”>/sti/Projekt.suo</path>
    </paths>
    <msg>VS2010 Solution files.</msg>
  </logentry>
  <logentry revision=”197″>
    <author>Sral</author>
    <date>2010-05-28T07:10:51.597195Z</date>
    <paths>
      <path action=”M”>/sti/</path>
    </paths>
    <msg>Added files/folders to ignore filter.</msg>
  </logentry>
</log>

Først tæller vi alle log entries grupperet på author. Det kan klares således:

1
2
3
4
5
6
7

var output = from logentry in SvnLog.Elements("logentry")
    group logentry by (string) logentry.Element("author")
    into logentries
    select new { 
        Author = logentries.Key,
        Entries = logentries.Count()
    };

Vi piller querien fra hinanden og ser på de enkelte dele.

from logentry in SvnLog.Elements("logentry")

Dette statement returnerer en IEnumerable liste af XElementer indeholdende alle under-noder i hvert <logentry> element. Disse bliver så placeret i en variabel kaldet “logentry”.

group logentry by (string) logentry.Element("author") into logentries

Vi grupperer her på datasættet fra før med en under-node i <logentry> ved navn <author>. Note: Det er vigtigt at huske castet til string da de fleste klasser i System.Xml.Linq har custom type converters (http://msdn.microsoft.com/en-us/library/ayybcxe5.aspx).

Et cast til string giver elementets værdi, hvor logentry.Element(“author”).ToString() ville give en string repræsentation af objektet.

Til sidst placerer vi vores gruppering i en ny variable ved navn ”logentries”.

select new { Author = logentries.Key, Entries = logentries.Count() };

Her over laver vi en anonym type indeholdende vores fundne data (Anonymous Types: http://msdn.microsoft.com/en-us/library/bb397696.aspx)
Logentries.Key er altid hvad man grupperer på. I dette eksempel laver vi en simpel count på de fundne værdier.

Vi kører det igennem en foreach løkke:

foreach (var d in output) {
     Console.WriteLine("{0}: {1} entries.", d.Author, d.Entries);
}

Resultat:

Lad os prøve en lidt mere avanceret query med nestede selects.

Vi prøver følgende: Vores query skal tælle attributen action (i <path>) grupperet på værdien. For at være endnu mere vanskelig grupperer vi også på author igen.
Resultatet vi søger skulle gerne se sådan ud:

Querien kommer til at se således ud:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

var data =
  from logentry
  in SvnLog.Elements("logentry")
  group logentry by (string)commit.Element("author")
    into logentries
    select new
    {
      Author = logentries.Key,
      Added = (
          from path in logentries.Elements("paths").Elements("path")
          where (string)path.Attribute("action") == "A"
          select path
      ).Count(),
      Modified = (
        from path in logentries.Elements("paths").Elements("path")
        where (string)path.Attribute("action") == "M"
        select path
      ).Count(),
      Deleted = (
        from path in logentries.Elements("paths").Elements("path")
        where (string)path.Attribute("action") == "D"
        select path
      ).Count()
    };

Det første i querien ligner statementet fra før: vi grupperer blot på author. Inde i vores anonyme type har vi nu 3 næsten ens selects:

from path in logentries.Elements("paths").Elements("path")

Vi finder alle ”path” noder som vores gruppering i det ydre scope indeholder.

where (string)path.Attribute("action") == "A"

Af de fundne path noder, finder vi alle dem der har attributten ”A”.

select path

Dem der matcher vores where clause selecter vi, plus pakker det hele ind til sidst, så vi kan lave en Count() på det.

foreach (var user in data) {
   Console.WriteLine("{0}: A:{1}, M:{2}, D:{3}",
      user.Author, user.Added, user.Modified, user.Deleted);
} 

Og nu får vi det output vi søgte:

Hinnerup Net ApS har netop indfundet sig i nye lækre lokaler i Frichsparken, Søren Frichs Vej 38C stth, 8230 Århus/Åbyhøj. Vi glæder os enormt meget til at tage de nye lokaler i brug, og ikke mindst at få besøg af samarbejdspartnere, kunder og gæster i al almindelighed.

Vi placerer snarest en flok billeder af det fine nye sted her på bloggen.

Foto: Nils Jepsen

Og Unity har gjort det rigtig nemt at lave 3D. En af de største styrker ved Unity er at brugeren kan lave projektet en gang og så udgive det til flere forskellige platforme, så som OS X, windows eller deres egen webplayer. Med Unity Pro kan man også udgive til Wii og iPhone/iPad.

Derudover er selve editoren nem at bruge, hvor objektor i verdenen, så som geometri og lyskilder, kan skabes som GameObjets. Fysik og scriptet adfærd er hellere ikke længere end et klik væk.

Et sjovt projekt der kombinere fysik, simpel geometri og en introduktion til scripting er xkcd’s Hell. Desuden er point systemet utroligt nemt.

Først skal blokkene laves. Under menuen GameObject -> CreateOther findes Cube, som skaber en kube i verdenen. Disse kuber kan så skaleres og placeres til at skabe alle de kendte tetris blokke.

For at kunne arbejde med blokkene som et stykke geometry skabes der et nyt tomt GameObject og geometrien for hver blok placeres under hver deres tomme GameObject. Tyngdekraft og kollision tilføjes som beskrevet blot ved at tilføje en rigidbody komponent til GameObjectet.

Til sidst skal geometrien gemmes som en struktur hvorfra et nyt objekt kan instantieres hver gang en ny blok skal dale ned. Til dette bruges Unity’s Prefabs, prefabrikeret geometry. At obrette en ny blok kan nu gøres ved simpel drag ‘n drop fra prefab’en og over i scenen, eller ved at instantiere prefab’en i et script.

Selve banens geometri er ligeledes lavet ud fra 7 kuber. Hele geometrien samles så til et fungerende spil gennem 3 scripts.

Det første script TetrisGod.js, hvis navn er inspireret herfra. Formålet
med dette script er at skabe en tilfældig og muligvis spejlvendt blok.

Det andet script er StartGame.js. Dette scripts eneste formål er at bede den almægtige tetris gud om at starte spillet ved at skabe den første blok. Scriptet bliver sammen med TetrisGod.js placeret på kameraet og sat til at starte når kameraet “vågner”.

Det sidste script hedder MoveBlocks.js og er tilføjet på alle vores blocke. MoveBlocks er ansvarlig for at spilleren kan flytte blokken, at blokkene ikke falder udenfor banen og at en ny blok bliver spawnet når blokken kolliderer med et andet objekt. Desuden fjerner scriptet blokke når de ikke længere kan ses af kameraet.

Resultatet kan ses her. Et lille ekstra touch af smerte og pinsel er tilføjet ved ikke at teste for om der plads til at blokkene kan spawne. Hvis en blok derfor spawner oven i en anden blok resulterer det i at en sværm af blokke spawnes og spilleren må siges at have tabt.

For at finde ud af mere om Unity og hvordan man nemt kommer igang med at lave 3D projekter, kan man klikke ind på Unity3D.com’s resource sektion eller se en af de mange tutorials, der er tilgængelige på youtube.

Certified .NET Developers

Et stort tillykke til de ny-certificerede medarbejdere:

 Michael Schøler
 Jakob Justsen
 Rune Alblas
 Tobias Hinnerup
 Lars Støttrup Nielsen
 Casper Hornstrup

Vi føler os nu rigtig godt klædt på til at indgå i opgaveløsning med relation til Sitecore CMS, med en fornyet og gennemgående teknisk indsigt, inden for eksempelvis:

• Rådgivning om forskellige aspekter omkring Sitecore CMS løsninger
• Udvikleroplæring og workshops
• Integration af websites, webservices og eksterne systemer med Sitecore CMS
• Udvikling af komponenter, kontroller, layouts med videre
• Udvidelser til Sitecore CMS systemet samt administrations-wizards
• Design, implementering og vedligeholdelse af eksisterende såvel som nye Sitecore CMS Sites

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.

Opdatering 2010-06-25, af Michael Schøler

Vi er ikke de eneste der har opdaget problemer med Gmail, og man kan i dag på Computerworld læse en artikel om lange modtage- og leveringstider, ligesom at der i April i Secure Computing magazine blev udgivet en artikel om at der var opstået panik blandt alle Hotmail’s brugere da de ved forsøg på login fik af vide at de ikke havde en konto.

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.