En Delcom Engineering lampe

Vi har kjøpt inn et par eminente Delcom USB lamper i generasjon 2. Se forøvrig forrige blogginnlegg om Lampestyring (generasjon 1).

Det følger med eksempelkode for å styre lampen, men ikke ferdig kompilert kommandolinjeverktøy – så vi brukte det medfølgende eksempelet, la på noen parametere og kompilerte det.

c:\usblamp\usblamp.exe
Delcom USB Lampekontroll - Logistikk Utviklingsteam
Bruk:
usblamp FARGE MODUS FREQLOW FREQHIGH INTENSITY
 - FARGE: 0=Gronn, 1=Rod, 2=Gul
 - MODUS: 0=Av, 1=På, 2=Blink
 - FREQLOW: Hvor lenge den skal lyse (f.eks: 5)
 - FREQHIGH: Hvor lenge den skal være av (f.eks.: 20)
 - INTENSITY: Lysstyrke

Eksempel:
Grønn lampe på: usblamp 0 1 0 0 10
Blinkende gul lampe: usblamp 2 2 1 100 4

Last ned her (zip)

Fraktmodulene benytter Bring Fraktguide som gir priser, dekningsområde, transporttider og produkttekster.

Eksempel på hvordan fraktalternativer ser ut i Zen Cart. I dette tilfellet er A-Post borte da innholdet i handlekurven er for tungt. Dersom man sender varene til et postnummer utenfor dekningsområdet for På Døren vil også dette alternativet automatisk tas bort

Merk! Disse modulene er et privat initiativ og “kick” fra min side. Det er på ingen måte et Bring eller Posten produkt. Modulene brukes helt og holdent på eget ansvar. Finner du feil – meld tilbake til forumene som er nevnt under, eller aller helst involver deg (jeg kan gi deg tilgang til prosjektet på Google Code) slik at modulene blir bedre!

Merk2! Du er velkommen til å bidra på modulene. De blir best av samarbeid!

• Fraktmodul for osCommerce:
  • Direkte download
  • Forum på www.oscommerce.no
    
• Fraktmodul for Zen Cart:
  • Direkte download
  • Forum på www.zen-cart.no
    

Om integrasjonen med Bring Fraktguide

Fraktmodulene benytter Bring Fraktguide XML API som er et åpent RESTful grensesnitt som er svært lett å ta i bruk. Modulene benytter seg av prisberegning og produkttekster.

Koden under sender HTTP request til Fraktguiden og returnerer et SimpleXMLElement eller en feiltekst. Dette må man teste for i koden utenfor. Dette er et utdrag av en felles includefil som ligger både i modulene for Zen Cart og osCommerce. Lenke til hele filen i Google Code.

function getXmlForProducts($productCode, $from, $to, $weightInGrams) {
    $http = new httpClient();
    $http->timeout = 2;

    $request = join('&', array('from=' . $from,
                               'to=' . $to,
                               'weightInGrams=' . $weightInGrams));
    if ($http->Connect('fraktguide.bring.no', 80)) {
        $http->addHeader('Host', 'fraktguide.bring.no');
        $http->addHeader('User-Agent', 'Zen Cart');
        $http->addHeader('Connection', 'close');

        if ($http->Get('/fraktguide/products/' . $productCode . '/all.xml?' . $request)) {
            $body = $http->getBody();
            if ($http->reply == 200) {
                $result['xml'] = new SimpleXMLElement($body);
            } else {
                if (strpos($body, "FG_INPUT_021")) {
                    $result['error'] = "Oppgitt postnummer er ikke gyldig";
                } elseif (strpos($body, "FG_INPUT_021")) {
                    $result['error'] = "Vekt eller volum ikke oppgitt";
                } elseif (strpos($body, "FG_INPUT_002")) {
                    $result['error'] = "Feil format på oppgitt postnummer";
                } else {
                    $result['error'] = "Ikke tilgjengelig til oppgitt postnummer";
                }
            }
        }
        $http->Disconnect();
    }
    return $result;
}

httpClient er en klasse som følger med butikkløsningene. Bør raskt kunne byttes ut med alternativ klasse dersom du trenger koden til annet bruk

Tips til forbedringer av modulene

• Bedre håndtering av volumberegnet vekt. Prisen på en pakke er mye avhengig av det fysiske volumet av pakken og ikke bare hvor mange fysiske kilo pakken er. Det fysiske volumet blir regnet om til volumvekt. Det høyeste av fysisk vekt og volumvekt blir benyttet som vekt når man slår opp prisen. Det er viktig at de som driver nettbutikker er oppmerksomme på dette
  • Alternativ 1 (quickfix): Benytt volumvekt og ikke fysisk vekt på varer som har stort volum. Noen issues her med dagens implementering av modulen da den kan tro at du kommer over 35 kilo. Grensen for å sende pakker 35 kilo fysisk vekt, men du kan selvfølgelig sende en pakke på 20 kilo fysisk vekt og 40 kilo volumvekt.
  • Alternativ 2 (best): Legg inn lengde, bredde og høyde på alle varene dine og modifiser fraktmodulen til å kalkulere pakkestørrelse og sende dette til Fraktuiden.
• Benytte transporttider til noe fornuftig i Zen Cart og osCommerce. F.eks. vise det, oppgi forventet leveringsdato i leveringsbekreftelse e.l.

Bring Fraktguide - http://fraktguide.bring.no/

Vi ønsker å levere funksjonalitet hyppig og har nå kommet inn i en god rytme med produksjonssetting 1-2 ganger i måneden.

Teamet kjører etter smidige metoder som for det meste er inspirert av Scrum og XP, men aller mest; er smidig. Dvs. vi har den metodikken vi trenger for å gjennomføre våre oppgaver. Hverken mer eller mindre… Dette har også den konsekvensen at måten vi jobber på kontinuerlig revideres.

Faste rammer i hver iterasjon

• Klart fokus for iterasjonen slik at vi jobber for et felles mål
• Iterasjonsworkshop og daglige 5-minutters stå-oppmøter ved tavlen
• Fast 15 minutters iterasjonsdemo som avslutning
• Raske, men effektive refleksjonsworkshop etter demo. Prioritere tre forbedringer for kommende iterasjon og følger disse opp i neste refleksjonsworkshop
• Resultatet fra iterasjonen leveres til produksjonssetting første eller andre dag i begynnelsen av påfølgende iterasjon.
• Gå opp trappen etter lunsj (ca. 75 høydemeter…)

Tekniske fokusområder

• Automatisert bygging og deploy av applikasjonen (Hudson)
• Lampestyring for å reagere raskt på introdusering og reintrodusering av feil
• Slideshow på monitor over funksjonalitet for å synliggjøre applikasjonen internt og visuelt reagere på feil i grensesnittet
• Testdrevet utvikling. Kravtester i Fitnesse og utviklers enhetstester i JUnit. 90% dekningsgrad.
• Knallhardt fokus på kvalitet i kjernen
• Strebe etter å ikke påta oss teknisk gjeld. Aktiv refactoring

Vi ønsker alltid å bli bedre – på listen over forbedringspunkter

• Automatiserte web tester
• Automatiserte web services tester (fokus på bakoverkompabilitet)
• Automaisterte ytelesetester

De fleste applikasjoner hadde ingen eller manglende eiere. Mange av applikasjonene slo vi rett og slett av etter å ha sjekket om vi kunne finne noen som var interessert i det som kjørte…

I ett tilfelle hadde det vært en DataEase applikasjon som hadde gått ut på dato i den forrige oppgraderingen. Dette var en enkel database med innhold som måtte beholdes av historiske grunner. Dvs. det var read only. I forrige oppgradering hadde det blitt laget et Java-webgrensesnitt på en kommersiell databasemotor. De som brukte dataene visste ikke om denne Java-applikasjonen (dvs. ingen hadde noensinne brukt den…). Heldigvis hadde de ikke trengt dataene siden DataEase applikasjonen ble skrudd av. Teoretisk sett kunne de trenge de og da var det viktig. Vi eksporterte dataene til en strukturert samling Excel filer og slo av applikasjonen…

For gode intensjoner om gjenbruk

En applikasjon for bugtracking var først benyttet til det store BEHOVET (bug tracking). Deretter hadde man intensjoner om å gjenbruke applikasjonen (som var ganske rigid…) til marginale behov som tenderte til å ligne på en bug tracking database. Egentlig var dette prioritering av krav og en enkel database med rapporteringsmuligheter. Det var også mye annet man hadde brukt applikasjonen til, men alt dette var nå ikke lenger i bruk.

Bug tracking var forlengst flyttet til en mer moderne plattform. De applikasjonene med mindre fokus var ikke det. Systemet rullet og gikk og kostet et betydelig antall tusen i året. Systemet var selvfølgelig så gammelt at “supporten” var gått ut. Dvs. man kunne velge mellom en oppgradering til et sekssifret beløp og fortsatt driftskostnader, eller…

• Prioritering av krav ble flyttet til Microsoft Access database (men kunne nok enda lettere vært håndtert i Excel)
• Den enkle databasen med rapporteringsmuligheter ble flyttet til Microsoft Access med spesialtilpasning av rapporter. Selve databasen ble liggende på et nettverksshare og tåler fint de 15-20 som teoretisk kan endre den samtidig.

Kostnader ble et ukesverk for etablere databasen og 0 i driftskostnader.

Moral: Tenk enkelt!

Det at det høres ut som et system, har vært et system og “burde” vært et system så betyr ikke det at det trenger å være et system…

Er det en enkel database som noen brukere skal dele?
-> Bruk Excel!
Må du ha rapportering og mer avansert funksjonalitet?
-> Bruk Access!

God bruk av Excel og Access faller mellom to stoler

Systemutviklere (som meg) tenker ofte på de større løsningene og applikasjonene som er viktig i en organisasjon. Det er disse som har prioritet. Her handler det om Java, Applikasjonsservere, .NET osv…

Driftsressurser og organisasjoner har en tendens mot å formalisere og outsource supporten fra forretningsbehovet. Man sitter ved siden av i n-linjer med support og svarer på henvendelser og endringsordrer. Man får lite kontakt med forretningsutviklingen i organisasjonen.

Forretningssiden sitter igjen med sine standardverktøy som er begynt å bli veldig kraftige saker… Dog sitter de fleste av de ikke med tilgang til kompetansen for å utnytte f.eks. Microsoft Excel og Access.

Konkret forslag til bedre utnyttelse av lisenser

• Identifiser 3-4 forretningsområder som trenger bistand til bedre bruk av standardverktøyer
• Etabler en task force med minst 2 utviklere med kjennskap til Access og Excel
• Jobb i iterasjoner av to ukers varighet.
  • Samlokaliser task force med forretningsområdet
  • Planlegg oppgavene i begynnelsen av iterasjonen
  • Sikre at task force holder tett kontakt med forretningsressurser underveis
  • Lever fungerende software (database, regneark) i slutten av iterasjonen.
  • Neste iterasjon? Nye utfordringer i nytt forretningsområde, eller fortsett der man slapp. Lever uansett fungerende software etter hver iterasjon.

La task forcen få 2-3 iterasjoner på å komme i gang. Når du vurderer at de har oppnådd det som er å oppnå i din organisasjon så avslutt og sett utviklerene på andre prosjekter.

(Excel og Access er brukt som konkrete eksempler her, det samme prinsippet gjelder uavhengig av hvilken software du har kjøpt – pass på utnytt din investering)

Jeg er overbevist om at denne tilnærmingen kan gi en positiv og selvforsterkende utnyttelse av allerede innkjøpt software!

Delcom Engineering sin USB lampe

Utviklere i dag har gjerne et automatisert byggemiljø. Koden bygges, testes og deployes automatisk… For å få ut effekten av dette er det viktig at utvikler får feedback når noe feiler. Til dette er det greit med en lampe. Det har jo også en gadget faktor…

Delcom Engineering sine USB lamper anbefales på det sterkeste. De får strøm og signaler via en USB kabel og finnes i flere varianter.

Bestill en på nettsidene deres ASAP (det tok en stund…). Det følger med CD med drivere og eksempelprogramvare. Vi har modifisert BAT-filene slik som f.eks. dette.

BothOff.bat
USBDOSAP 10 12 0 7

RedOn.bat
USBDOSAP 10 12 0 7
USBDOSAP 10 12 2 0

GreenOn.bat
USBDOSAP 10 12 0 7
USBDOSAP 10 12 1 0

YellowOn.bat
USBDOSAP 10 12 0 7
USBDOSAP 10 12 4 0

Videre må du få byggeserveren til å trigge lampen når det bygges…

• Det enkleste er å la den stå direkte på byggeserveren og la den kalle BAT scriptene når du ønsker å trigge lysene.
• Vi hadde lampen på en utvikler PC og hadde en Java listener som sjekket RSS filen med status over siste bygg på byggeserveren (Hudson) og styrte lampen via BAT scriptene over.
• Tidligere har jeg også praktisert HTTP kall fra byggeserver til utvikler-PC der man har et enkelt PHP script som kaller BAT-filene for å trigge lysene.

Vi bruker følgende farger:
Gul lampe: Bygging pågår
Grønn lampe: Siste bygg var vellykket. Ingen feil på enhetstester eller kravtester samt løsningen er deployet til utviklingsserver
Rød lampe: Siste bygg var ikke vellykket. Enten kompileringsfeil, feil på en eller flere enhetstester/kravtester eller feil med deploy