String eller Int? Script-smutter får Netto til at sende sms til forkerte numre

Nettos leverandør kom til at lægge +45 til som et tal til telefonnumrene i stedet for at sætte det foran numrene.

Skal mobilnummeret være et heltal eller en tekststreng? Typen er i hvert fald ikke ligegyldig, hvis man som Nettos leverandør skal rydde op i databasen og sørge for, at alle numrene har en landekode foran.

På Nettos Facebook-side klagede en bruger over, at Netto havde sendt en sms, hvori Netto reklamerede for en igangværende kampagne. Da brugeren ikke havde givet Netto lov til at sende sms'er, mente han, at det var spam eller misbrug af numre fra en anden liste.

Nettos forklaring peger imidlertid på en fejl i et script, som skulle rense data i Nettos database. Der var angiveligt en del mobilnumre, som ikke havde landekoden "+45" foran, og det skulle Nettos leverandør rette op på.

Men i stedet for at eksempelvis nummeret 85 40 40 40 blev registreret som +45 85 40 40 40, så blev de 45 i lagt til telefonnummeret som et heltal. Listen ændrede altså 85 40 40 40 til 85 40 40 85 - et nummer som peger på en helt anden abonnent.

Tilføjelse af heltal

Det lugter af, at der i det script, som er skrevet for at tilføje landekoden, er sket en addition af heltal frem for en konkatenering af to tekststrenge. Altså at både +45 og telefonnummeret er opfattet som heltal og lagt sammen, i stedet for "+45" + "85404040" = "+4585404040".

En anden forklaring kunne være, at scriptet har fortolket udtrykket som normal polsk notation, hvor den matematiske operator skrives før operanderne, så 3 + 4 skrives som + 3 4. I programmering er det mere normalt at benytte omvendt polsk notation, hvor man i stedet skriver operatoren til sidst, altså 3 4 +, fordi det kan implementeres ved hjælp af en stak.

Nettos forklaring:
Vi har fået følgende udredning fra vores leverandør som varetager udsendelse af vores SMS beskeder:

Fejlen skyldes en manuel data-rensning på en enkelt udsendings-pulje af sms´er. Rensningen skulle have skrevet +45 foran alle numre, men der er fejlagtigt blevet tillagt 45 til selve nummeret. I udsendingen er der dermed opstået helt nye telefon-numre. Som eksempel er her et fiktivt nummer på 20 20 20 20 som så ville være ændret 20 20 20 65.

Det er altså ikke ulovligt indsamlede telefon-numre, og ej heller numre fra en anden database som vi har sendt sms´er til – men alene en fejl i indlæsning og rensning af telefon-numre fra databasen.

Vi beklager fejlen og der er iværksat nye procedure der sikrer at dette ikke sker igen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (13)

Peter Christiansen

Total begynder fejl og total 0 test af proceduren,
ved bare en enkel test ville man kunde finde fejlen.

Man bliver lidt bange over den inkompetence der hersker,
selv helt basale ting som dette bliver der lavet fejl i og tilmed
bliver der ikke testet noget som helst.

Og selvfølgelig skal telefonnumre lægges i databasen som en
string type. Man bruger jo ikke et telefonnummer til beregning
eller anden summering.

Ole Kaas

"Læg lige +45 på alle numre i kolonnen mobnum"

Endnu bedre hvis opgaven er outsourced:

"Please add +45 til the numbers in column mobnum"

Opgaven beder næsten selv om at blive kørt som en one-liner SQL (hvis databasen er en sådan) . Resultatet af operationen er så forskelligt fra det ønskede, at enten har man virkelig ikke gidet checke resultatet eller også har man ikke forstået opgaven.

Torben Mogensen Blogger

Implicitte konverteringer kan give overraskende resultater. Se f.eks. http://www.2ality.com/2013/04/quirk-implicit-conversion.html

Lige præcis "+45" + "20202020" burde give en konvertering, men hvis anførselstegnene er glemt (+45 + "20202020"), så bliver andet argument konverteret.

Moralen er: Sprog bør ikke implicit konvertere værdier til andre typer.

Man kan til nød implicit konvertere heltal til kommatal, men det er ikke voldsomt irriterende for programmøren at gøre det eksplicit -- og så kan man undgå fejl.

Baldur Norddahl

Ikke "normal polsk notation".

Åh - opn er f. eks. 45 40 +

Det er ikke det, der bliver brugt i eksemplet

Den han skriver i artiklen om polsk notation er helt korrekt. Polsk notation er at skrive beregningerne som funktions kald: plus(45,40) giver 85. Eller skrevet med tegn og uden parenteser: "+ 45 40 = 85".

Omvendt polsk notation er at det samme som polsk notation men med funktionen angivet efter parametrene. "+ 45 40" bliver til "45 40 +".

Stig Robertsen

... og intet om hvor mange der har fået den - er en fejlagtiv modtaget SMS ikke til indløsning i Netto for en plade 'undskyld' chokolade :-)
/Stig

Yoel Caspersen Blogger

Der er ingen tvivl om, at det er en pinlig begynderfejl, som skulle have været fanget under en simpel test.

Men mon ikke, de fleste af os engang har prøvet at lave en type fejl af den slags en sen aften, hvor man havde lige lovlig travlt? I den ideelle verden laver man ikke den slags fejl, men så kan man til gengæld bruge adskillige timer på trivielle opgaver, såsom at tilføje +45 til et telefonnummer.

Men Netto skal have ros for at fortælle, hvad der gik galt - og så er problemet jo ikke større. Har man modtaget en SMS, kan man jo bare slette den og komme videre i livet :-)

Morten Christensen

Havde de brugt Excel, havde de kunnet se hvad der skete. Det kan være sværere med en oneliner shell kommando.
Jeg tror nu snarere på en for dårlig opgavebeskrivelse, hvor hverken danskeren som har skrevet mailen eller inderen, som har læst den, har engelsk som modersmål.

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Affecto Denmark reaches highest Microsoft Partner level

Affecto Denmark, a leading provider of data-driven solutions, has reached the highest level in the Microsoft partner ecosystem: Managed Partner.
22. jun 13:45

Innovate your business with Affecto's IoT Explorer Kit

Are you unsure if Internet of Things fits your business strategy?
31. maj 2017

Big Data Lake Summit: Fast and Trusted Insights

If you want to outpace, outsmart and outperform your competition in a digital world, you need trusted data that can be turned into actionable business insights at speed.
24. apr 2017