IT udvikling

/IT udvikling
IT udvikling2017-12-09T13:59:30+00:00
IT-udvikling til dig der er for lille til at have en fastansat, men stor nok til at have brug for bedre IT-systemer

Arbejdsområderne

Mine arbejdsområder strækker sig over et ret bredt spektrum, fra de små Excel-løsninger der skal bruges én gang til de større, strategiske løsninger der tager måneder at udvikle og som forventes at være operative i 5-10 år.

Kundegruppen jeg har mest fokus på er SMV + mikrovirksomheder, dvs. virksomheder der er for små til at have en udvikler ansat, men som stadig vil kunne have god gavn af at bruge IT mere operativt.

Så hvis du repræsenterer en mikrovirksomhed eller SMV, hvad kan jeg så hjælpe netop dig med? Det korte, og formodentligt ret kække, svar er, at jeg kan hjælpe dig med næsten alle opgaver der relaterer sig til udvikling af software, uanset om det som anført ovenfor er en meget lille opgave eller en forholdsvis stor løsning, der er brug for.

Og er du i tvivl om jeg kan hjælpe dig, vil jeg opfordrer dig til at bestille et uforpligtende møde. Så kontakter jeg dig og vi kan sammen diskuterer, hvordan jeg kan hjælpe dig og, ikke uvæsentligt for små virksomheder, i hvilket prisleje du kan forvente en løsning kommer til at ligge i.

Værktøjer og platforme

Når jeg skal udvikle en løsning, starter jeg først med at danne mig et overblik over om der allerede findes ’noget der kan bruges’ først. Det er generelt ikke en god idé at forsøge at udvikle noget der allerede findes, så det er det første skridt på vejen. Dernæst vælger jeg det værktøj eller den platform jeg mener er den mest hensigtsmæssige, dvs. det værktøj der kan levere den løsning, min kunde har behov for.

Jeg kunne f.eks. vælge at udvikle en løsning i Excel, da det, upåagtet at det ikke var intentionen med regnearkene, da de blev udviklet, er en ligefrem og hurtig platform at udvikle på, hvilket er med til at holde omkostningen nede og understøtte en hurtig levering og idriftsættelse.

Er der behov for et lidt mere poleret værktøj, kan jeg udvikle det som et almindeligt stykke software, dvs. et program med et ikon på din desktop.

Er der behov for kommunikation mellem brugere eller skal værktøj og data kunne tilgås forskellige steder fra, herunder fra mobiltelefon, udvikler jeg dit værktøj som en web app, hvilket lidt forsimplet forklaret er en hjemmeside med højere fokus på indhentning af data fra brugere, interaktion med denne samt analyse og viderebearbejdelse af data.

Sidst, men ikke mindst kan jeg udvikle din applikation til Android smartphone. Android er den mest udbredte smartphone platform og derfor har jeg valgt at fokusere på denne. For at gøre det helt klart: Jeg udvikler ikke til iPhone.

Pris og forløb

Vi slipper jo nok ikke for at diskutere pris, men det er i sagens natur svært at give et prisleje, før opgaven er kendt. For de fleste opgaver gælder det dog, at opgaven bliver udviklet til fast pris, så du, når aftalen indgås, ved, hvad løsningen kommer til at koste, hvad de evt. løbende udgifter bliver og dermed også, hvornår løsningen har tjent sig selv hjem.

Hvis din opgave er af en lidt mere kompliceret natur, bliver den delt op i 2: En krav- og prissættelsesdel og en udviklingsdel. Første fase har til hensigt at fremskaffe alle relevante oplysninger, så der kan gives en pris og anden fase er selve udviklingen. Før fase 1 bliver startet, holdes der et eller flere møder, hvor der indhentes tilstrækkelig information til at jeg kan give dig en ca. pris. Denne fase kalder jeg fase 0 og er naturligvis uden beregning. Circa-prisens præcision er typisk 75%-150%, dvs. at en opgave med en circa-pris på 10.000,- formodentligt kommer til at ligge i intervallet 7.500 – 15.000, men usikkerheden er stor og den endelige pris kan således først gives ved udgangen af fase 1.

Fase 1 og fase 2 faktureres særskilt og faktureres særskilt. Ved udgangen af fase 1, hvor du får den endelige pris, kan du derfor vælge om du vil fortsætte udviklingen.

Kontakt mig

Et par eksempler på opgaver jeg har løst igennem tiden:

Kunden havde sine fakturadata liggende i et proprietært system, til hvilke der ikke umiddelbart kunne gives direkte adgang til den bagvedliggende database. Fakturadata ønskedes konsolideret i en ‘superfaktura’, dvs. en faktura der indeholdt alle åbne fakturaer. Denne superfaktura ønskedes skrevet i PDF-format og skulle herefter være tilgængelige for autoriserede personer til download via en intern webside.

Først skridt på vejen var at få udpeget, hvilke værktøjer der skulle anvendes. Det var af største vigtighed at der ikke var for store licensomkostninger involveret, hvorfor jeg rettede blikket mod, hvad Open Source-community’et kunne byde på. Med mange år i IT-branchen kan jeg stadig godt tage mig selv i at være lidt imponeret over, hvor meget fantastisk godt software der bliver givet væk, kvit og frit og i forbindelse med dette projekt fik jeg udvidet min horisont yderligere.

Jeg skulle have data ‘skrabet’ fra en hjemmeside, hvilket egentligt betyder, at jeg skulle have en agent(dvs. et stykke software der kører uden umiddelbart opsyn) til at emulerer en menneskelig bruger og gennem denne agent udsøge mig de informationer på siden jeg havde brug for.

Det er mere kompliceret end man måske umiddelbart forestiller sig, for med den menneskelige intelligens kan vi mere eller mindre instinktivt reagerer på små afvigelse i forhold til, hvad vi forventer. Logger vi på Facebook og finder ud af, at søgefeltet er flyttet over til den ene side, skriver vi bare i dette felt uden at hjernen kommer på overarbejde af den grund. Sådan er det ikke med en agent: hvis normalbilledet afviger, skal man have indkodet en del undtagelser, baseret på tidligere erfaringer (dvs. fejl, hvor agenten er gået amok og har foretaget sig guder-må-vide-hvad), så agenten bliver så robust, at den kan foretage korrektioner i sin adfærd.

Agenten var kø-baseret, hvilket i store træk betyder at den fik en liste (en kø) over elementer den skulle behandle. Hvis køen var tom, skulle agenten logge af systemet og blot overvåge om der kom ny elementer til. Når det skete, ville agenten logge på systemet og starte udtrække. På denne vis kunne agenten passe sig selv og, hvis køen blev for lang, kunne yderligere agenter startes op og køre parallelt og dermed nedbringe køen hurtigere. Køen skulle være synlig via et web interface, så en menneskelig operatør ville kunne ændrer på eksekveringsrækkefølgen, idet køen var, som køer er per definition, FIFO: First In-First Out, altså at ældeste element bliver behandlet først.

Når data var blevet udtrukket skulle det indsættes i en database til senere anvendelse.

En anden komponent i systemet var en batch-baseret proces der med jævn mellemrum ville blive startet op (eller manuelt startet gennem et webinterface af en menneskelig operatør, hvis der skulle prioriteres anderledes). Denne komponent skulle samle de høstede data i en datakonstruktion, der skulle lægge grunden til PDF-superfakturaen. Når alle records fra databasen var compilet til en færdig datakonstruktion, ville processen formatere data i en pdf, hvorefter det færdige dokument blev uploadet til en intern webserver. Slutteligt blev data fjernet fra databasen og processen ville fortsætte til næsten element eller, hvis der ikke var flere elementer, terminere.

Gennem webinterfacet kunne operatørerne i de forskellige lande (det var et pan-europæisk projekt) finde de ønskede fakturaer hvis de var autoriserede til at se dem og herefter downloade dokumenterne til videre behandling.

Systemet tog omkring 5 mdr. at implementerer og kostede som ovenfor anført ikke noget andet end arbejdstid, idét der kun bliver brugt Open Source software og hardwaren var en aflagt laptop der blev lænket til et vandrør i et serverrum (!).

Det generelle programmeringssprog var Java, omend der var en smule PHP og JavaScript involveret i webinterfacet, der blev hostet på en Apache webserver.

Data blev opbevaret på en MySQL-server og til web-skrabningen blev benyttet HTMLUnit, der er et Java-bibliotek der kan emulerer en browser. Til PDF-delen blev benyttet iText.

Volumen var anslået ~150 superfakturaer pr. dag.

For at få et overbliver over, hvilket platforme forskellige virksomheder benytter til deres hjemmeside, lavede jeg for en kunde et system, der ud fra en liste over email-adresser, kunne uddrage domæne-information herfra. Når de mest gængse email-udbyderes domæner var filtreret fra (google.com, yahoo.com etc), stod jeg tilbage med en liste over domæner, der kunne danne grundlag for en webbots indsamling af data, under skyldig hensyn til robots.txt, naturligvis. Data der skulle indsamles var platformen nævnte hjemmeside kørte på samt evt. en bekræftelse på at et tidligere opgivet telefonnummer og email-adresse kunne findes på siden, hvilket med rimelig sikkerhed ville verificere at telefonnummeret stadig var validt.

Listen endte med at bliver på ca. 650.000 domæner der skulle undersøges og af disse blev ca. ~500.000 sider besøgt.

Da dette var en engangsforestilling, blev der ikke gjort det store ud af systemet, hvorfor det blev kodet som et command line interface program, udviklet i C#, med anvendelse af HTMLAgility til parsningen af den indhentede data og en MySQL-database til opbevaring af domæne-køen og den indsamlede data.

Da det i denne forbindelse tog længere tid at oprettet forbindelse til hjemmesiden end det tog at hente robots.txt og evt. forsiden, besluttede jeg at kører adskillige ‘bots parallelet og lod dem selv finde ud af, hvilke domæne de skulle arbejde på. For at nedbringe antallet af dobbelte downloads som følge af flere ‘bots kørende på samme data, valgte jeg at segmenterer data vha. en simpel moduls-operation på database-recordens primære nøgle (ikke kønt, men det virkede og var hurtigt at skrue sammen) i bundter af 100 domæner.

For at foregå at skulle køre operationen endnu en gang når jeg kom i tanke om, hvad jeg havde glemt at skrabe første gang, valgte jeg at gemme første side i en database, således at jeg kunne lave analysen flere gange og i forskellige scenarier, inden data blev slettet.

Opgaven tog ca. 5 timer at udvikle og ca 48 timer at eksekverer, da jeg havde valgt at indsætte en begrænsning på, hvor mange ressourcer en ‘bot kunne benytte.

En kunde, der leverede firmajulegaver, ønskede et system til håndtering af valg af julegave til de medvirkende virksomheders medarbejdere.

Istedet for kun at tilbyde én type julegave til virksomhedernes medarbejdere, gav kunden virksomhederne mulighed for at definerer forskellige julegaver, inden for en given prisramme, som deres medarbejdere kunne vælge imellem.

Udgangspunktet for denne løsning var WordPress med et specialfremstillet tema baseret på HTML5Blank boilerplate temaet, med den tilhørende funktionalitet opdelt i tema og plugins, efter hvad der var mest passende.

Systemet skulle tillige give kunden mulighed for at se, hvilke medarbejdere der endnu ikke havde valgt julegave, med henblik på at lade virksomhederne udsende en reminder, hvis de fandt det passende. Medarbejdere der ikke inden en given deadline havde valgt, ville få en foruddefineret julegave, aftalt med virksomheden. Tillige skulle systemet give kunden et ‘heads-up’ på, hvilke gaver der var populære, således at der ikke opstod en mangelsituation, hvor den pågældende gave var udsolgt.

For at foregå at én gave blev udsolgt før en anden, kunne systemet ændrer på, i hvilken rækkefølge gaverne blev vist på, da det var antagelsen at rækkefølgen ville påvirke tilstrækkeligt mange medarbejdere til at vælge ‘den rigtige’ gave og dermed nivellere fordelingen af gaver.

Systemet var testet til 1.000 brugere (dog ikke samtidige) og var et rent WordPress-projekt.

Dette var et ret komplekst system. En lokalradio ønskede at have et system der kunne varetage den ugentlige radiobanko, der var radiostationens primære indtægtskilde.

Systemet skulle håndtere såvel udstedelse af bankoplader, salg og abonnement af samme, udtrækning af vindernumre, oplæsning af tal i radioen, forkontrol af plader med gevinst i stationens telefonsluse, statistik til studiet (hvor mange spillere der er med, hvor mange spillere der mangler 1 nummer for at have pladen fuld etc.), teaser-funktion (funktion til at trække spillet ud så lang tid som muligt, bl.a. ved gradvist at opskrue pausen mellem tal med 5 ms. pr. tal, (startende fra 4500 ms) samt bevidst udtræk af sikre numre, dvs. numre der med meget stor sandsynlighed ikke ville ændre på, hvem der fik gevinst, etc.).

Systemet kunne opdeles i fire dele:

  • Systemopstart
  • Før spil
  • Under spil
  • Efter spil

Systemopstart

Som en engangsfornøjelse skulle systemet sættes igang, hvilket bl.a. indebar generering af bankokort(dvs. spilleplader), samt udtrækning af samtlige trækninger i systemets levetid (plus 5000 år (som i femtusinde år), for at være på den sikre side). Dette skete ved at benytte et specielt kryptografisk modul, der kunne generere mere tilfældige tal, end C# normalt kan. Når man under normale forhold skal lave tilfældige tal, sker det ved at give computeren et seed, og herefter begynde at trække tal ud. Problemet med denne fremgangsmåde er, at hvis man giver computeren samme seed, får man den samme talrække – der er nemlig slet ikke tale om ægte tilfældige tal, men et pseudotilfældige, hvilket altså betyder at det kun tilsyneladende er tilfældige tal. Forskellen er naturligvis, at hvis man skal være sikker på at der ikke er opstår tvivl om rigged game, er man nødt til at tage tilfældighed ganske alvorligt. Når spillet så skal til at starte, kan man nemlig nøjes med at udtrække ét (kryptografisk) tilfældigt tal, der udpeger den sekvens der skal oplæses. Hele denne omvej skyldtes, at det ikke var nok at der var tale om tilfældige tal, det skulle også opfattes som tilfældige tal. Derfor var der også opstillet regler for, f.eks. hvor mange tal i rad der måtte komme. 45, 46, 47 er i orden, men 45, 46, 47, 48 ville ikke blive opfattet som tilfældige, selvom rækkefølgen 1-90 er nøjagtig så sandsynlig som alle mulige andre kombinationer – det får man bare ikke folk til at tro på, og da det jo var meningen at folk skulle hygge sig og have lidt spænding ud af spillet, måtte lykkens gudinde lige have et par retningslinjer at holde sig til…

Før spil

Før spillet gik i gang, skulle spillerne sørge for at have mindst ét spillekort (bankoplade), plader købt efter spillets start ville automatisk blive kort til den følgende spilledag. Dette kunne enten ske gennem genkøb af spilleplade eller ved køb af ny plade. Da der var en del spillere der fik et personligt forhold til deres plade, var det et ufravigeligt krav at systemet skulle kunne håndtere, at folk fik den samme plade fra spilledag til spilledag. Gevinster i form af gavebeviser på spilleplader fra en tidligere trækning, såvel som SMS-betaling og VDK var mulighederne for at betale.

Under spillet

Under spillet skulle systemet udtrække et kryptografisk nummer til selektion af, hvilket talsekvens der skulle læses op. Når disse (fem) sekvenser var udvalgt, blev de markeret som værende brugt (hvilket betød, at hvis spillet blev afbrudt ville disse sekvenser være tabt, men da der som nævnt ovenfor var lidt at trække af, var det ikke det store tab). Når spillet var igang, ville studie-PCen afspille mp3-samples med radioværternes oplæsning af de enkelte tal, hvilket gennem speaker-udgangen blev ført ind i stationens apparatur (dér fik jeg så lige afsløret at jeg ikke er radiomand…) og videre ud i broadcast. På skærmen kunne radioværterne hele tiden holde øje med, hvilke tal der allerede var trukket ud samt statistik vedr. spillet der var i afvikling. Når der var en spiller der ringede ind og havde 1-, 2- eller 3 rækker, kunne telefonslusen afbryde spillet, hvilket ville 1) pause oplæsningen af tal og 2) afspille en mp3-jingle, så lytterne vidste at der (formodentligt) var gevinst. Radioslusen kunne, vha. spiller-ID og pladenummer med det samme afgøre om der var gevinst eller ej. Hvis ikke, blev spilleren afvist, en ny jingle afspillet og sidst-oplæste tal ville blive oplæst igen, hvorefter den almindelige oplæsning af tal ville fortsætte. Hvis der der i mod var gevinst, ville spilleren blive stillet igennem til studiet og der læse sine tal op (som jo allerede var godkendt, men en del af fornøjelsen ved spillet var jo også at være i radioen, så det gjaldt om at give vinderen så meget radiotid som muligt).

Efter spil

Når de fem spil var afsluttet, ville systemet opdaterer spillerne med deres gevinster. Alle der ringede ind (og kom  igennem til studiet), ville få deres konto godskrevet med deres gevinst (gavebevis på spilleplade til fremtidigt spil) samt gavebevis på deres gevinst, der typisk var sponseret af lokale erhvervsdrivende.

For en kunde lavede jeg en white-label løsning (dvs. som en ikke-kendt underleverandør) til aggregering af data i hhv. Excel-regneark og komma-separeret fil, med henblik på at populere en eksisterende template med data, der sidenhen ville kunne eksporteres til f.eks. PDF og sendes med mail til leverandøre. Løsningen blev udviklet i Visual Studio/C#/WinForms med Office-modulerne, således at output’et ville blive en ny Excel workbook der levede op til alle krav fra Microsoft. For at holde udviklingsomkostningerne nede, blev en automatiseret løsning fravalgt, men denne vil på sigt kunne tilføjes, skulle fjernkunden finde dette ønskeligt.

Kontakt mig
  Bliv synlig på Google med 17 SEO tips
VIL DU VÆRE SYNLIG PÅ GOOGLE?

Du ved, dér hvor kunderne leder efter dig, dine produkter og din service.

Tilmeld dig vores nyhedsbrev med tips, tricks og tilbud

Samtidig får du e-bogen med 7 SEO tips du kan gå i gang med i dag

×