Tjekditnet version 2: En prototype fødes

Som bekendt har Kviknet nu fået arrangeret et møde med Energistyrelsen, hvor vi vil fremlægge vores bud på en bedre version af tjekditnet.dk. Energistyrelsen har siden mit sidste blogindlæg fået Kviknet på listen over udbydere, men vi stopper ikke her.

Tjekditnet.dk har nemlig potentiale til at blive et rigtig godt forbrugerværktøj, hvis vi gør det rigtigt, og vi mener, at gennemsigtighed på markedet vil forbedre situationen for både forbrugerne og de fleste udbydere, heriblandt os.

Til mødet med Energistyrelsen har vi tænkt os at præsentere en prototype af et nyt tjekditnet.dk, og jeg indbyder hermed version2's læsere til at komme med input og feedback, mens vi udvikler prototypen.

Data er nøglen til det hele

Websitets fornemste opgave er at formidle retvisende data mellem udbyderne og forbrugerne. Derfor har vi brug for en database, der kan håndtere de data, vi har brug for.

Glem alt om dyre Oracle-licenser og mainframes - vi skal bygge et website, der kan skalere til ca. 5.000 brugere pr. dag ved normal drift, og muligvis et par hundrede tusinde på en dag, hvis noget ekstraordinært sker.

Det er ikke raketvidenskab, og opgaven kan klares med en helt almindelig LAMP-stack bestående af Linux, Apache, MySQL og PHP.

Apache kan i øvrigt udskiftes med nginx uden at det gør nogen forskel for opbygningen af vores website. PHP kan også erstattes af Hack på HHVM, en videreudvikling af Facebooks HipHop for PHP, hvis det skal køre rigtig hurtigt, men da dette er en prototype, kører vi det på en helt almindelig LAMP-stack.

Vi anvender selvfølgelig opcode caching når websitet går i produktion.

Vi starter med en MySQL-database. I princippet kunne man godt bruge MariaDB, men jeg har ikke sat mig ind i, om der er nogen væsentlige forskelle. Den primære årsag til valget af MySQL er, at det er et modent, velfungerende produkt, der tillige er gratis.

Hurra for Geodatastyrelsen

For hver adresse i kongeriget skal vi kunne vise en liste over tilgængelige internetforbindelser fra udbyderne på markedet.

Når vi skal arbejde med fysiske adresser i Danmark giver det rigtig god mening, at vi læner os op ad det gode arbejde, folkene hos Geodatastyrelsen har gjort, og derfor vil vi tage udgangspunkt i adressedata fra aws.dk.

AWS har tillige den fordel, at det ser ud til at være udviklet med henblik på integration i andre websites og services - IP-adresserne afslører, at det er hosted hos Amazon, og selve opslags-servicen dawa.aws.dk kører tilsyneladende round robin DNS, hvor loadet fordeles over p.t. 8 forskellige nodes.

Det lugter lidt af kompetent arbejde, så vi har ingen skrupler over at bruge dawa.aws.dk i produktion.

Hver eneste adresse i landet har et unikt ID hos AWS, og derfor behøver vi ikke gemme en liste over adresser i systemet, men kan i stedet nøjes med at referere til adressens ID.

Når en internetudbyder skal indberette data til os, skal vi derfor bruge følgende oplysninger:

  • Adressens ID
  • Udbyderens ID
  • Udbyderens unikke nøgle, der giver adgang til opdatering af API'et
  • Den teknologi, forbindelsen leveres på (DSL, Coax, Kobber, Fiber, Wifi, FWA osv.)
  • URL til produktside hos udbyder
  • En varedeklaration:
    • Max download speed
    • Max upload speed
    • Global IPv4 tilgængelig
    • Global IPv6 tilgængelig

Vi kunne godt finde på flere data, men det vigtige spørgsmål er: Er det relevant her?

Vi kan ikke inkludere priser på forbindelserne, da der findes et hav af forskellige prismodeller, og desuden skal vi ikke opmuntre udbyderne til at manipulere med priserne for at se mere attraktive ud, det klarer de fint selv.

En udbyder må oprette et produkt pr. teknologi pr. adresse. Om de opretter deres bedste produkt eller ej, blander vi os ikke i, men det kan være, Energistyrelsen har en holdning til dette.

Hvor stor bliver tabellen, hvis vi gemmer alle produkterne samme sted? Well, hvis vi antager, at der i gennemsnit vil være ca. 10 leverandør/teknologi-kombinationer pr. adresse, og vi har 2,6 mio. adresser i Danmark, vil der være 26 mio. rækker i databasen. Piece of cake for en MySQL-database.

Feltet med adressens ID skal naturligvis indekseres, så opslag tager så kort tid som muligt. Vi konfigurerer innodb_buffer_pool_size passende, så vores indeks holdes i maskinens RAM, da det vil få en betragtelig størrelse.

Indberetning via API eller webinterface

En udbyder kan indberette data via et API eller via et webinterface. Webinterfacet er medtaget, da mange små udbydere i form af antenneforeninger og boligforeninger ellers vil have svært ved at være med.

Af princip bør vi anvende HTTPS, især på en side, hvor der foretages adresseopslag, og da der ikke er behov for server side caching på tjekditnet.dk, er der ikke rigtig noget, der taler imod. Vi skal selvfølgelig ikke betale beskyttelsespenge til en CA, når der er bedre muligheder, så vi anvender et gratis SSL-certifikat fra letsencrypt.org.

Da vi arbejder med simple data, er der ingen grund til at gøre vores API mere besværligt end højst nødvendigt. Ideelt set skal API'et kunne kaldes fra et bash-script, hvis man måtte have de lyster.

Derfor definerer vi følgende adresser til vores API:

Når man kalder update, anvendes følgende parametre:

  • address_id
  • provider_id
  • auth_key
  • technology_id
  • url
  • max_dl_speed
  • max_ul_speed
  • global_ipv4
  • global_ipv6

Alle parametre escapes, så specialtegn ikke får kaldet til at mislykkes - i PHP kan det gøres med urlencode(). Hvis en indberetning ikke findes i forvejen, oprettes den.

Delete-funktionen tager følgende parametre:

  • address_id
  • provider_id
  • auth_key
  • technology_id

Hvis kaldet lykkes, returnerer API'et en passende tekst:

OK

Hvis kaldet mislykkes, returnerer API'et en passende HTTP error code og en tekst, der passer til.

ERROR Wrong credentials

På den måde kan man simpelt scripte sig ud af opgaven stort set uanset valget af scriptsprog. I bash vil man kunne bruge wget, og i PHP vil man kunne bruge file_get_contents() eller curl, hvis det skal være helt pænt.

Vi kunne godt have valgt et full blown REST-API, men så skal klienten understøtte PHP-verberne GET, POST, PUT, DELETE osv. Det gør det besværligt at debugge i en terminal, og vi nøjes derfor med GET.

Kan det virkelig passe, at der ikke skal mere til? Kan vi klare en sådan opgave uden XML-filer, SOAP, NemID/Funktionssignatur fra DanID eller andre besværligheder?

I næste indlæg gennemgår vi den visuelle præsentation af data, som vores webdesigner p.t. sidder og arbejder på.

Yoel Caspersens billede
Yoel Caspersen er direktør hos Kviknet, har en baggrund som udvikler og har gennem en længere årrække beskæftiget sig med udvikling af hostede PBX-løsninger, internetbutikker og software til online video- og tv-distribution. Dagbog-bloggen er en stafetblog for iværksættere.

Kommentarer (55)

Yoel Caspersen Blogger

Hvad med et offentligt API til virksomheder og borgere?

Jeg havde egentlig tænkt mig at tage det i næste indlæg, men det er en oplagt god ide, og derfor har vi indbygget dette i API'et - se fx:

https://tjekditnet.kviknet.dk/api/v1/list?address_id=9f378c19-0743-4626-...

Vi er dog p.t. nødt til at nøjes med at vise en enkelt adresse ad gangen. Det skyldes, at Energistyrelsen ikke ønsker at offentliggøre hele datasættet af hensyn til de udbydere, primært TDC, der mener, at de har ophavsret til databasen.

Jeg synes ideelt set, at den slags data bør være offentlige, også i komplet form, og hvis du har nogle gode argumenter for dette, tager vi dem gerne med til Energistyrelsen.

Emil Stahl

Ikke dårligt! :)

Hvad med mulighed for kalde et endpoint der returnerer alle ISP'er og deres IPv4 og IPv6 support? Sådan helt generelt og ikke pr. adresse?

Husk forresten
header('Content-Type: application/json');
når I retunerer JSON.

Jeg forstår heller ikke hvorfor I ikke laver det bare lidt mere "REST like". Det er meget flottere/nemmere at arbejde med.

Debugging er nemt med Paw til Mac og/eller Postman til Chrome, der er fantastiske værktøjer til at arbejde med (REST) API'er.

Hvis man absolut vil gøre det i terminalen er det jo heller ikke super kompliceret.
curl -X DELETE 'https://tjekditnet.kviknet.dk/api/v1/...'

Jens Jönsson

•max_dl_speed
•max_ul_speed

Når man ikke har en max ?

Jeg har nævnte det før Yoel, du er farvet af at arbejde med "op til" hastigheder :-)

Hos Skywire får du det forbindelsen kan trække. Det er typisk en del mere end det minimum vi garanterer.
Vi kan derfor komme ud for at nogle adresser kan få > 50 Mbit/s, nogle omkring 40 Mbit/s osv. uden vi specifikt kan sige hvilke....

Yoel Caspersen Blogger

Husk forresten
header('Content-Type: application/json');
når I retunerer JSON.

Det var en smutter - den er hermed tilføjet!

Debugging er nemt med Paw til Mac og/eller Postman til Chrome, der er fantastiske værktøjer til at arbejde med (REST) API'er.

Hvis man absolut vil gøre det i terminalen er det jo heller ikke super kompliceret.
curl -X DELETE '
https://tjekditnet.kviknet.dk/api/v1/...'

Jeg er enig med dig i, at det er en pæn måde at gøre det på - og hvis man er webudvikler, er det også sådan, man ville gøre det. Men det komplicerer tingene en smule, og vi frygter, at det vil gøre setup'et mere kompliceret for de mange forskellige internetudbydere, der skal indberette, da nogle af dem må forventes at skulle køre deres eksport fra forskellige obskure legacy-platforme.

Husk, det er ikke en større webapplikation, vi bygger, og denne prototype har til opgave at vise, hvor simpelt det kan gøres, hvis man skærer opgaven benhårdt til.

Men samtidig er formålet selvfølgelig også, at vi skal ende med et godt produkt, der kan bruges, så lad os få noget mere input fra læserne - skal vi gøre vores API mere RESTful, eller skal vi holde fast i den helt simple model?

Og hvis I argumenterer for en mere RESTful tilgang, så lad os få nogle eksempler på command line opdatering (PUT), så vi kan få klarlagt præcist, hvor meget det komplicerer indberetningen.

Den ligger lige på vippen mellem de to valg, så gode argumenter er velkommen :-)

Yoel Caspersen Blogger

Hvordan angives....
•max_dl_speed
•max_ul_speed

Når man ikke har en max ?

Jeg har nævnte det før Yoel, du er farvet af at arbejde med "op til" hastigheder :-)

Du har ret, og du har en valid pointe, så derfor har jeg ændret følgende:

  • max_dl_speed => dl_speed
  • max_ul_speed => ul_speed

Derudover har jeg tilføjet:

  • guaranteed_speed

som angiver, hvorvidt hastigheden er garanteret eller ej. Garanterede hastigheder vises altid først i listen.

Opfylder det jeres behov?

Yoel Caspersen Blogger

Hvad med mulighed for kalde et endpoint der returnerer alle ISP'er og deres IPv4 og IPv6 support? Sådan helt generelt og ikke pr. adresse?

Vi kan godt tilføje det som en option på de enkelte ISP'er, men hvilke værdier giver mening her? Fuld understøttelse, delvis eller ingen understøttelse? Er det relevant for en bruger, om ISP'en tilbyder IPv6 til nogle af kunderne, hvis han ikke selv kan få det på sin egen adresse?

Vi kunne selvfølgelig godt lave en "list of shame" hvor vi opsummerer fordelingen af IPv6- / non-IPv6-nodes på hver enkelt ISP, men er det relevant for en slutbruger?

Henning Wangerin

Hvad vil du bruge url-parameteren til?

Jeg har lidt svært ved at se hvad en url på hver enkelt adresse skal bruges til.

At der er en url til udbyderens side over forbindelstypen giver god logik, men på alle de adresser hvor TDC kan levere fx 20/2 giver det i min optik ingen mening at have den samme url stående. Eller er der en dybere mening med det?

Emil Stahl

Og hvis I argumenterer for en mere RESTful tilgang, så lad os få nogle eksempler på command line opdatering (PUT), så vi kan få klarlagt præcist, hvor meget det komplicerer indberetningen.

curl -X "PUT" "https://tjekditnet.kviknet.dk/api/v1/address" \  
    -H "Cookie: PHPSESSID=n7hj5ds7cc5t91gs2t2j3e4385" \  
    -H "X-AUTH-KEY: 5225db0d3feff8b7ce6f3c48068644fd" \  
    -H "Content-Type: application/json" \  
    -d "{\"address_id\":\"9f378c19-0743-4626-bcaf-ea10a10f2eba\",\"provider_id\":\"c3cfb7c0f76e2b5bc9d129452c7e2061\",\"technology_id\":1,\"url\":\"http://www.kviknet.dk/produkt/1\",\"dl_speed\":100000,\"dl_speed\":10000,\"guaranteed_speed\":0,\"global_ipv4\":1,\"global_ipv6\":0}"

Jeg tillod mig at flytte auth til en header. Jeg skrev det ikke i hånden, men eksporterede fra Paw. Screenshot

Se her hvordan det ser ud "på den anden side"

Yoel Caspersen Blogger

At der er en url til udbyderens side over forbindelstypen giver god logik, men på alle de adresser hvor TDC kan levere fx 20/2 giver det i min optik ingen mening at have den samme url stående. Eller er der en dybere mening med det?

Det er en gulerod, der give ISP'en til at have lyst til at levere gode data: Unikke landing pages.

Hvis man fx har en landing page URL, der hedder:

https://www.kviknet.dk/oprettelse/produkt/1?address_id=xyz&technology=fiber

kan man lade sin landing page præ-udfylde adresse og teknologivalg (fx DSL, fiber eller coax).

Dermed får brugeren en bedre oplevelse og kan gennemføre sit køb med det samme.

Ønsker udbyderen ikke at have unikke URLs, skal de blot lade være med at angive dem, så vil systemet bruge fallback-adressen (fx http://www.tdc.dk/).

Michael Rasmussen

Det har måske ikke særlig relevans for fiber, men for kobber er afstanden til centralen en vigtig oplysning, så derfor kunne det være en ide, om udbyderne kunne indberette koordinater for deres centraler, som brugerne kunne plotte ind på google maps eller lignende.

Baldur Norddahl

Alle adresser i Danmark kan få fiber og det er muligt at levere en vilkårlig hastighed (100 Gbit/s er ikke et problem hvis du vil betale).

Det er også et problem ved den nuværende Tjekditnet. Nogle adresser viser eksempelvis 10 Gbit/s på fiber fordi en udbyder føler det er en adresse de vil melde dette ind på. Typisk fordi de ser det som en erhvervsadresse, men dette er helt arbitrært.

Men det er jo ikke særligt nyttigt bare at indmelde 10 eller 100 Gbit/s på samtlige BBR adresser i Danmark.

Og for private er det ikke et reelt valg. Private kan ofte vælge mellem 100, 500 eller 1000 Mbit/s på fiber, alt efter hvor de bor og hvem der udbyder i det område.

Som minimum bør det fremgå om der er tale om privat eller erhvervsfiber. Og husk at mange adresser kan få begge dele og der skal derfor være mulighed for at rapportere flere produkter per adresse.

En anden ide er at tage prisen med i betragtning. Det er sandt at man kan få erhvervsfiber på alle adresser, men der er mange adresser hvor det er prohibitivt dyrt. Hvorfor ikke indsamle priser, eller i det mindste prisgrupper?

Priser for private kan være total udgift over de første 6 måneder og den vedvarende månedsudgift når opstarts rabatter er udløbet. For erhverv oprettelse, bindingsperiode, månedsleje.

Baldur Norddahl

Det har måske ikke særlig relevans for fiber, men for kobber er afstanden til centralen en vigtig oplysning, så derfor kunne det være en ide, om udbyderne kunne indberette koordinater for deres centraler, som brugerne kunne plotte ind på google maps eller lignende.

Der er kun én udbyder der har centraler (med kobber) i Danmark og det er TDC. Så det er ikke så nyttigt. TDC er også de eneste der har fremskudte punkter. En alternativ operatør kan vælge at benytte rå kobber, som så går hele vejen tilbage til centralen (som er en TDC central hvor operatøren har samhusning). Eller han kan vælge at benytte TDCs fremskudte DSLAM. På den måde er det nærmest en boolean.

Der er til gengæld flere muligheder for den anvendte teknologi (ADSL, ADSL2, VDSL, vectoring, pair bonding etc). Men igen så kan alle stort set levere det samme, da alle operatører i praksis har en aftale om at anvende TDCs udstyr. Man anvender sit eget når det ikke er nødvendigt at anvende TDC, fordi kunden har bestilt en lavere hastighed eller der ikke er et fremskudt punkt.

Emil Stahl

Det har måske ikke særlig relevans for fiber, men for kobber er afstanden til centralen en vigtig oplysning, så derfor kunne det være en ide, om udbyderne kunne indberette koordinater for deres centraler, som brugerne kunne plotte ind på google maps eller lignende.

Her er er kort med alle TDC centraler, fremskudte centraler, teknikhuse, teknikskabe, fremskudte indkoblingspunkter mm.

NetMAP (klik med musen uden for post nr. feltet, hvis du bruger det - enter virker ikke)

Lavet af min gode ven, med data fra TDC Wholesale (der kan man finde meget spændende)

Yoel Caspersen Blogger

Her er er kort med alle TDC centraler, fremskudte centraler, teknikhuse, teknikskabe, fremskudte indkoblingspunkter mm.

Tak for delingen af kortet - det er en super lækker måde at bruge offentligt tilgængelige data på, og for mig som ISP er det også et relevant værktøj. Jf. sagen med tingbogs-kopien håber jeg ikke, din ven får problemer med myndighederne fordi han strukturerer og viser data, der allerede ligger offentligt tilgængeligt - det ville i hvert fald være dybt urimeligt.

Yoel Caspersen Blogger

Det har måske ikke særlig relevans for fiber, men for kobber er afstanden til centralen en vigtig oplysning, så derfor kunne det være en ide, om udbyderne kunne indberette koordinater for deres centraler, som brugerne kunne plotte ind på google maps eller lignende.

Selv om jeg som ISP selv kan se relevansen af disse data, har jeg svært ved at se, hvad slutbrugerne skal bruge det til. Og her mener jeg, vi skal være klare i spyttet omkring hvem der er vores målgruppe på tjekditnet.dk. Hvis vi skal henvende os til andre end slutbrugere, bør det som minimum ske på et subdomain som fx isp.tjekditnet.dk eller på en underside, der ikke umiddelbart fylder op på forsiden af tjekditnet.dk.

Jonas Andersen

Jeg ved ikke om jeg har overset noget, men hvad med enheder?
Skal alle udbydere bare angive i bytes per sekund?

Jeg kunne måske også forvente at nogle af de større virksomheder ikke vil ændre i deres format (hvis de allerede har XML). Vil dette være noget som I laver i prototypen eller vil det være en opgave mellem Energistyrelsen og de enkelte udbydere?

Yoel Caspersen Blogger

Alle adresser i Danmark kan få fiber og det er muligt at levere en vilkårlig hastighed (100 Gbit/s er ikke et problem hvis du vil betale).

Og alene af den grund mener jeg ikke, at erhvervsfiber har noget at gøre på en adressesøgning på tjekditnet.dk.

Men hermed en ide til en løsning, der tilgodeser erhvervsvirksomheder: Når man går ind på tjekditnet.dk, kan der være et menupunkt, der hedder "Fiber til erhverv". Når man klikker på dette, indtaster man sin virksomheds adresseoplysninger, herunder e-mail og telefonnummer, og så sender systemet en mail afsted til alle de internetudbydere, der har indikeret at de er interesseret i at sælge erhvervsfiber i det givne postnummer. I mailen er der en opfordring til at give et tilbud til slutkunden.

Kunne det være en løsning?

Yoel Caspersen Blogger

Jeg ved ikke om jeg har overset noget, men hvad med enheder?
Skal alle udbydere bare angive i bytes per sekund?

Det skal selvfølgelig fremgå af dokumentationen, hvad enheden er. Mit udgangspunkt er Kbit/s - så får vi en tilpas god opløsning til at den også viser rigtigt ved lave hastigheder, mens det stadig kan passe ind i en unsigned INT i MySQL (grænsen for en unsigned INT er ca. 4 mia., dvs. 4 Gbit/s hvis det skulle holdes i bits/s, og det er for lidt - 10 Gbit/s kommer til private før eller siden).

Yoel Caspersen Blogger

En anden ide er at tage prisen med i betragtning. Det er sandt at man kan få erhvervsfiber på alle adresser, men der er mange adresser hvor det er prohibitivt dyrt. Hvorfor ikke indsamle priser, eller i det mindste prisgrupper?

Priser for private kan være total udgift over de første 6 måneder og den vedvarende månedsudgift når opstarts rabatter er udløbet. For erhverv oprettelse, bindingsperiode, månedsleje.

Problemet ved 6 måneders priser er, at de opmuntrer udbyderne til at manipulere med priserne for at fremstå billige. De store udbydere kører ofte med stærkt reducerede priser de første par måneder netop for at fremstå billige over 6 måneder, selv om de efterfølgende har højere abonnementspriser, der fordyrer abonnementet væsentligt, hvis kunden bliver hængende. Og det gør de fleste, sandsynligvis et sted mellem 24 og 42 måneder i gennemsnit.

Derfor bør en pris vises som gennemsnit over fx 36 måneder i stedet, men det lukker op for alle mulige diskussioner og indvendinger fra udbydere, der føler sig trådt på. Så derfor er vores udgangspunkt at eliminere problemet helt ved at undlade at angive priser.

Kan denne gordiske knude løses på en pæn måde?

Esben A Black

Webinterfacet er medtaget, da mange små udbydere i form af antenneforeninger og boligforeninger ellers vil have svært ved at være med.

Det vil være en god ide at tilbyde bulk upload i csv og excel.

Jens Jönsson

Det har måske ikke særlig relevans for fiber, men for kobber er afstanden til centralen en vigtig oplysning, så derfor kunne det være en ide, om udbyderne kunne indberette koordinater for deres centraler, som brugerne kunne plotte ind på google maps eller lignende.

Problematikken er at adressen nødvendigvis ikke er på den nærmeste central. To adresser tæt på hinanden kan sagtens være på forskellige centraler, det har jeg set flere gange. F.eks. er den ene side af vejen på én central og den anden side på en anden central. Så skal TDC melde ind, hvilken (mikro)central adressen er tilsluttet, det tror jeg ikke du får dem til....

Mener altså også at Erhvervsstyrelsen har sat krav til TDC om at indberette korrekte hastigheder for kobberet pr. adresse. Mener det hedder "Teknisk mulig hastighed".

Klavs Klavsen

Fedt initiativ.

Det er lidt for for anti-REST.. ting bliver efter min erfaring så meget simplere hvis man forsøger at holde sig til REST.. dvs. json i post.. så har man en lang liste af ting - sendes det i et json format.. f.ex. et json array. Det er også nemt at parse og checke i jeres ende.. og i slipper for parsing af csv filer der kan have "alt muligt" sjovt indhold. Det får du foræret, når de sender i json.

Det fede ved at bruge REST url'er (istedet for GET parametre) er også at din accesslog afspejler præcis hvad der er sket.. og som Emil fint viste - er det rimelig simpelt at sende en put eller lign. vha. curl.

Og hvis du koder i PHP - så vil jeg tillade mig at anbefale SLIM php frameworket.. dejligt småt og simpelt, og gør det uhyggeligt nemt at skrive et REST api - der er meget overskueligt at arbejde med. Skriv bare hvis du godt vil have en "start stump" - så du bare kan tilføje "routes" (dvs. url mønstre du vil håndtere af én bestemt funktion).

Martin Poulsen
Baldur Norddahl

Kan denne gordiske knude løses på en pæn måde?

Jeg foreslår prisgrupper eller alternativt, en definition baseret på pris for hvornår en adresse er dækket.

Det kan være at 36 månedersprisen inklusiv oprettelse for levering til adressen skal være mindre end 5000 kr ex moms.

Hvis det er prisgrupper, så kan det være noget med 0-1000, 1000-2000, 2000-5000, 5000-10000.

Og ja, erhverv skal kun vises hvis man trykker på en erhverv knap. Ellers har vi forvirrede forbrugere, der bliver skuffet når de ikke alligevel kan få fiber.

Teknisk mulig hastighed for fiber bør præciseres til at gælde for det udstyr udbyderen aktuelt har sat op, og ikke for selve fiberen. Men selv det er utilstrækkeligt. TDC har opsat GPON udstyr der kører 2,4 Gbit/s på fiberen. TDC markedsfører højest 50/10 Mbit/s på denne platform. Men de har herudover begrænset de alternative operatører til 100/10 selvom teknikken tillader 1000/1000.

Så du har tre kategorier:

1) Teknisk hastighed som begrænset af switch/DSLAM
2) Højest tilladt hastighed som begrænset politisk af infrastrukturejer
3) Højest markedsført hastighed

Christian Nobel

Er Excel-filer komplicerede for antenneforeningen eller for udvikleren? :-)

Det er kompliceret at modtage Excel filer, og automatisk indlæse dem i en database.

En ting er at selve formatet er bøvlet at rode med, men hvad værre er at når folk får friheden til at lave et Excel ark, så laver de altid et eller andet galt, så der er noget der skrider - og husk at i et regneark er data og præsentation rodet sammen.

Hvorimod det er meget mere rigidt (hvilket er hensigten) at bruge et CSV format - og så er det ikke vendor specifikt.

Der findes værktøjer der nemt læser Excel-filer.

Ja, og jeg kan også læse hollandsk, men jeg forstår bare ikke ret meget af det, selv om det umiddelbart ligner en blanding af dansk og tysk.

Yoel Caspersen Blogger

Jeg tillod mig at flytte auth til en header. Jeg skrev det ikke i hånden, men eksporterede fra Paw.

Det ser jo besnærende simpelt ud, men hvordan JSON-encoder du dine data command line, hvis du sidder på en Windows-server og skal uploade data?

Eller kan vi tillade os at gå ud fra, at alle vores leverandører af data sidder i et miljø, hvor de har adgang til et rigt script-sprog, der kan håndtere JSON og REST?

Yoel Caspersen Blogger

Så du har tre kategorier:

1) Teknisk hastighed som begrænset af switch/DSLAM
2) Højest tilladt hastighed som begrænset politisk af infrastrukturejer
3) Højest markedsført hastighed

Af disse tre kategorier er det vel dybest set kun kategori 3, der er relevant for slutbrugere?

Højest markedsført hastighed vil altid være < teknisk hastighed som begrænset af switch/DSLAM (og hvis ikke, er det en sag for forbrugerombudsmanden eller lignende, da det er falsk markedsføring). Og hvis fx TDC ikke vil levere mere end 50/10 på en adresse, vil der lige ovenover stå en linie, der fortæller at Gigabit gerne leverer 100/100 (eller 1000/1000 for den sags skyld).

Overser jeg noget?

Yoel Caspersen Blogger

Det er lidt for for anti-REST.. ting bliver efter min erfaring så meget simplere hvis man forsøger at holde sig til REST.. dvs. json i post.. så har man en lang liste af ting - sendes det i et json format.. f.ex. et json array. Det er også nemt at parse og checke i jeres ende.. og i slipper for parsing af csv filer der kan have "alt muligt" sjovt indhold. Det får du foræret, når de sender i json.

Jeg er enig i, at det er meget pænere med JSON + REST. Jeg vil bare gerne undgå, at det er for besværligt for de udbydere, der måske ikke har en tidssvarende LAMP-stack at køre deres indberetning fra.

Et alternativ kunne måske være at tilbyde begge løsninger - så er det op til udbyderen at vælge indberetningsformatet.

Vi slipper nok ikke for at skulle tage imod CSV-filer. Nogle af udbyderne, der skal indberette, vil være antenneforeninger med måske et par tusinde adresser, og jeg føler mig ikke overbevist om, at de har in-house ressourcer til at indberette via API.

Anders Pallisgaard

Det er kompliceret at modtage Excel filer, og automatisk indlæse dem i en database.

Det er ikke mere kompliceret end at modtage og indlæse en CSV-fil.

En ting er at selve formatet er bøvlet at rode med

Brug et værktøj som kan læse Excel - så behøver du ikke kende til formatet.

når folk får friheden til at lave et Excel ark, så laver de altid et eller andet galt

Det er langt fra min erfaring.

i et regneark er data og præsentation rodet sammen

Ja, men i praksis er det min erfaring at det yderst sjældent giver problemer. Jeg oplever ofte større udfordringer når du siger CSV til folk, da mange ikke ved hvad det er.

Anders Pallisgaard

Jeg er enig i, at det er meget pænere med JSON + REST. Jeg vil bare gerne undgå, at det er for besværligt

Det er egentlig samme indvending jeg har mod CSV.

Et alternativ kunne måske være at tilbyde begge løsninger

Helt enig - men nu begynder prototypen at tage om sig :-)

Hvis målet er en prototype, og forventningen er "at det tager et sted mellem to dage og en uges tid at kode for en enkelt udvikler", så ville jeg skære igennem og understøtte GET samt CSV-filer.

Emil Stahl

Det ser jo besnærende simpelt ud, men hvordan JSON-encoder du dine data command line, hvis du sidder på en Windows-server og skal uploade data?

Eller kan vi tillade os at gå ud fra, at alle vores leverandører af data sidder i et miljø, hvor de har adgang til et rigt script-sprog, der kan håndtere JSON og REST?


Godt spørgsmål med Windows, jeg har absolut ingen erfaring. Men mon ikke der er en løsning.

Men mon ikke vi kan gå ud fra, at dem der har lyst til at bruge API og ikke web interface/CSV har adgang til ordentlige værktøjer. Næsten alle API'er er jo REST(-like) i dag, så det ikke noget"vildt".

Hvis målet er en prototype, og forventningen er "at det tager et sted mellem to dage og en uges tid at kode for en enkelt udvikler", så ville jeg skære igennem og understøtte GET samt CSV-filer.


REST(-like) tager altså ikke meget længere tid end GET løsningen, og man kan lige så godt lave det ordenligt fra start. Det er de facto her i 2016 tør jeg næsten sige.

Anders Vind Ebbesen

Vi er dog p.t. nødt til at nøjes med at vise en enkelt adresse ad gangen. Det skyldes, at Energistyrelsen ikke ønsker at offentliggøre hele datasættet af hensyn til de udbydere, primært TDC, der mener, at de har ophavsret til databasen.

Protuck anvendte Geodatastyrelsens adresseliste til at høste Tingbogen. Med samme fremgangsmåde kan man ret nemt også høste hele databasen på tjekditnet.dk, nu hvor I også bruger samme database som grunddata.

Det har I formentligt allerede tænkt over, så jeg antager også, at I allerede har overvejet en form for throttling af "scraper-brugsmønstre"?

Alternativt kan man også vælge at se gennem fingre med det. Bare det sker på et oplyst grundlag :)

Yoel Caspersen Blogger

Hvad med to felter:

Totalprisen for de første 6 måneder.
Den aktuelle månedspris for produktet fra 7. måned, inkl. eventuelle BS-/kortgebyrer og andet fus^H^H^H^H^H^H^H^H^H andre skjulte gebyrer.
Så skulle det vel være rimelig gennemskueligt og sammenligneligt?

Det er da en mulighed, men hvad skulle forhindre udbyderne i at lave julenumre med prisen i 7. måned? Fx den 7. måned gratis.

Og inden du siger "Det tosseri kunne ingen da finde på!", så tag et kig på Telia. De kører med "hver 6. måned gratis".

Christian Nobel

Det er ikke mere kompliceret end at modtage og indlæse en CSV-fil.

Javel ja, der kan man bare se.

Brug et værktøj som kan læse Excel - så behøver du ikke kende til formatet.

Javel ja, et magisk Excel læse værktøj - jamen det er da fint, host, host.

Og det får jeg så måske også på magisk vis til at virke helt sømløst med den platform jeg har valgt?

Det er langt fra min erfaring.

Nå, men sjovt nok så har jeg en hel del erfaringer på det modsatte - og når der bare er den ringeste chance for at noget kan gå galt, så gør det det også.

Ja, men i praksis er det min erfaring at det yderst sjældent giver problemer. Jeg oplever ofte større udfordringer når du siger CSV til folk, da mange ikke ved hvad det er.

Jeg må indrømme at jeg tillægger ikke dine erfaringer om at lave dataindberetninger til automatisk opdatering ret megen værdi når du kan komme med sådan et postulat.

Og vi taler altså ikke om at Fru Hansen skal dele en strikkeopskrift med fru Jensen, men om at en ISP skal lave en indberetning til et standardiseret system.

Glem Excel, det er spild af alles tid (i denne sammenhæng).

Yoel Caspersen Blogger

Alternativt kan man også vælge at se gennem fingre med det. Bare det sker på et oplyst grundlag :)

Altså, hvis nu en udbyder stiller krav om det, kan vi jo blive nødt til at lave det. Men hvis man er uenig i hele grundpræmissen om, at data skal være offentlige, men kun hvis det er besværligt at få et overblik, så er der grænser for, hvor mange kræfter, man uopfordret vil lægge i denne del ;-)

Mit bud er også, at man kan høste hele tjekditnet.dk i dag. Men det får man bare ikke så meget ud af, når datakvaliteten er som den er.

Jesper Nielsen

Det er da en mulighed, men hvad skulle forhindre udbyderne i at lave julenumre med prisen i 7. måned? Fx den 7. måned gratis.

Og inden du siger "Det tosseri kunne ingen da finde på!", så tag et kig på Telia. De kører med "hver 6. måned gratis".

Ja, det har jeg faktisk set på et tidspunkt. Man kunne så kræve, at udbyderne oplyser "den normale månedspris inkl. alle gebyrer efter de første 6 måneder". Så kan Telia i hvert fald ikke angive 0 kr.

Det er selvfølgelig svært at gardere sig mod alle påfund, men det må kunne formuleres. Slutbrugeren skal selvfølgelig ikke præsenteres for en tekst som den, jeg foreslog ovenfor - men blot "Din pris efter 6 måneder" eller noget i den stil.

Yoel Caspersen Blogger

Og vi taler altså ikke om at Fru Hansen skal dele en strikkeopskrift med fru Jensen, men om at en ISP skal lave en indberetning til et standardiseret system.

Glem Excel, det er spild af alles tid (i denne sammenhæng).

CSV har også den fordel, at det kan genereres fra et hav af forskellige databaseværktøjer. Fx kan MySQL native skrive CSV-filer.

Derved kan en ISP, der ikke gider at udvikle en klient til vores API, nøjes med at skrive en SQL-sætning til CSV-export 1 gang, og så genbruge den hver gang de vil indberette opdateringer.

PHP indeholder også native værktøjer til håndtering af CSV - fx fgetcsv().

Anders Pallisgaard

Og det får jeg så måske også på magisk vis til at virke helt sømløst med den platform jeg har valgt

Dén her tråd handler ikke om, hvorvidt der findes Excel-læsere til alle platforme. Det gør der givetvis ikke. Tråden handler om LAMP-stakken og Yoel har angivet PHP som programmeringssproget, og jeg ved - af erfaring - at det er lige så nemt at læse en Excel-fil som en CSV-fil med PHP.

sjovt nok så har jeg en hel del erfaringer på det modsatte

Så er det nok forskellige typer af personer vi hver især har erfaringer fra :-)

en ISP skal lave en indberetning

Jeg har forstået "persontypen" som følgende:

da mange små udbydere i form af antenneforeninger og boligforeninger ellers vil have svært ved at være med

Så det er mere den lille antenneforening eller boligforening - og ikke en klassisk ISP - der er tale om her. Jeg har ingen ide om hvor teknisk kyndige antenneforeninger og boligforeninger er, men de har givetvis ikke samme tekniske kunnen som en klassisk ISP. Men ved Yoel og andre som arbejder med dette marked meget mere om end jeg gør :-)

Jeg må indrømme at jeg tillægger ikke dine erfaringer om at lave dataindberetninger til automatisk opdatering ret megen værdi når du kan komme med sådan et postulat.

Det er helt i orden. Jeg arbejder til daglig med almindelige mennesker i IT-sammenhæng, hvor jeg ofte hjælper med at importere data - som oftest fra Excel, men også nogle gange fra CSV. Der ligger derfor et stort erfaringsgrundlag bag mit input.

Baldur Norddahl

Af disse tre kategorier er det vel dybest set kun kategori 3, der er relevant for slutbrugere?

Det er min opfattelse at Tjekditnet ønsker at indsamle data til flere formål. Slutbrugerne skal kende den markedsførte hastighed. Men teknisk hastighed kan være nyttig for politikere og regulatorer. F.eks. kunne det måske åbne nogle muligheder, hvis det bliver udstillet hvor TDC begrænser konkurrenterne til 100/100, selvom TDC har installeret udstyr der kører 2,4 Gbit/s ud til kunden.

Kristian Klausen

Det ser jo besnærende simpelt ud, men hvordan JSON-encoder du dine data command line, hvis du sidder på en Windows-server og skal uploade data?


Python findes da til Windows? Personligt anser jeg det ikke som et problem, der findes mange forskellige muligheder at løse det på.
Men selvfølgelig hvis der ikke må installeres noget, bliver det en anelse kompliceret.

Claus Bruun

Altså, så er det heller ikke sværere!
Hvis der ikke er tale om historiske systemer, så har Powershell 5 native support for at kunne skrive data direkte i JSON og CSV.

Name Category Module Synopsis
---- -------- ------ --------
ConvertFrom-Json Cmdlet Microsoft.PowerShell.U... ...
ConvertTo-Json Cmdlet Microsoft.PowerShell.U... ...

Claus Bruun

Jeg synes at Baldurs forslag om TCO på en treårig periode er rigtig fint, da det er rigtigt svært at snyde på vægten, hvis man også vil overleve som firma.

Emil Stahl

Protuck anvendte Geodatastyrelsens adresseliste til at høste Tingbogen. Med samme fremgangsmåde kan man ret nemt også høste hele databasen på tjekditnet.dk, nu hvor I også bruger samme database som grunddata.

Det har I formentligt allerede tænkt over, så jeg antager også, at I allerede har overvejet en form for throttling af "scraper-brugsmønstre"?

Alternativt kan man også vælge at se gennem fingre med det. Bare det sker på et oplyst grundlag :)

Tjekditnet i dag (og rigtigt mange andre, både offentlige, store virksomheder og borgere) bruger jo samme data i dag. Du kan meget nemt scrape den nuværende version hvis du vil.

Både Kviknets og Energistyrelsens version bruger (fremragende) DAWA hvor du kan downloade alle adgangsadresser og det mest spændende… id og postnummer. Når du har dem er det bare at lave en masse requests til følgende URL:

http://tjekditnet.dk/pls/wopdprod/tdnutils.find_udbydere_html?i_adgadr_id=%7B0a3f5089-1d4d-32b8-e044-0003ba298018%7D&i_postnummer=5260

Yoel fortalte jo endda om "API'et" tidligere:

Jeg havde egentlig tænkt mig at tage det i næste indlæg, men det er en oplagt god ide, og derfor har vi indbygget dette i API'et - se for eksempel:
<span class="geshifilter"><code class="text geshifilter-text">
https://tjekditnet.kviknet.dk/api/v1/list?address_id=9f378c19-0743-4626-...;

Yoel Caspersen Blogger

Så er der kommet et par funktioner mere på vores API:

https://tjekditnet.kviknet.dk/api/v1/providers
https://tjekditnet.kviknet.dk/api/v1/technologies

Derudover har jeg tilføjet PairBondingPossible og AVGPrice på vores adressevisning:

https://tjekditnet.kviknet.dk/api/v1/list?address_id=9f378c19-0743-4626-...

AVGPrice skal betragtes som en gennemsnitlig månedspris inkl. moms målt over 42 måneder, som er det tidsrum, Erhvervsstyrelsens prisklemmetilsyn beregner en forbindelses totalpris over. Prisen er en realistisk minimumspris, der indeholder alle nødvendige gebyrer etc.

Jeg er usikker på, om AVGPrice kommer med i den endelige version, da jeg tror, fortolkningen af en gennemsnitlig pris bliver et stridsspørgsmål for mange udbydere.

Nu har vi faktisk byggestenene til en brugerflade til en forbruger-version af Tjekditnet. En liste over udbydere, en liste over teknologier, der udbydes, og en liste over teknologier, der udbydes på en specifik adresse.

Det smukke ved denne løsning er, at alle, der har lyst, nu kan bygge en tredjeparts brugerflade til det nye tjekditnet.dk.

Vi har fyldt databasen med live data fra Kviknets dækningsliste. Af gode grunde har jeg ikke data fra andre udbydere lige nu, men hvis der er en udbyder derude, der er frisk på at betateste en indberetning, siger I bare til.

Listen over internetudbydere er fyldt med de virksomheder, jeg lige kunne komme i tanke om. Der er med sikkerhed flere derude, og det er ikke af ond vilje, at de ikke er taget med. Skulle nogen føle sig trådt over tæerne, så sig ligeledes til, så kommer I med i prototypen.

Betatester gerne ;)

Til dig og andre gode udviklere derude - slå jer løs, og kom endelig med mere feedback :-)

Baldur Norddahl

Hermed en ide for at gøre det nemmere for operatører, specielt nye af slagsen:

Hvorfor ikke en knap så at man melde at ja, vi har købt os ind på infrastruktur ejer Xs net og kan levere overalt hvor X kan på teknology Y. Det er så primært X=TDC men man kan forestille sig at X med tiden også kan sættes til SydEnergi eller andre, som måske åbner deres net.

Det er relevant for Bredbånd Basic og BSA med POI3 på DSL og fiber platformen samt måske også coax.

Måske med mulighed for nogle filtre, f.eks. include eller exclude på ring navne for BSA og CMTS for coax.

Det er også muligt at ovenstående kan implementeres med et script som gøres tilgængeligt, så man selv kan køre det.

Yoel Caspersen Blogger

Hvorfor ikke en knap så at man melde at ja, vi har købt os ind på infrastruktur ejer Xs net og kan levere overalt hvor X kan på teknology Y. Det er så primært X=TDC men man kan forestille sig at X med tiden også kan sættes til SydEnergi eller andre, som måske åbner deres net.

Hvis du kigger på feedet med internetudbydere, kan du se at vi faktisk allerede har inkluderet en parameter kaldet "BB" (Bredbånd Basic). Ideen er, at hvis BB == 1, medtages udbyderen overalt hvor TDC dækker på DSL.

Udfordringen ved den her tilgang er, at den i sin simple form er inkompatibel med visning af priser, da vi så skal opfinde en mapping mellem forbindelsestyper og priser for den enkelte operatør, da operatøren så ikke længere vil indberette den enkelte adresse til systemet. En sådan mapping kan være ganske kompleks - hos Kviknet prissætter vi i dag forbindelserne efter downstream-hastighed i fastlagte intervaller, mens andre udbydere prissætter efter andre mønstre.

Fordelen ved en spejling af operatørers indberetninger er, at det ville nedsætte datamængden i databasen og gøre det hele meget nemmere. Hvis det kræver, at vi ofrer visningen af priserne, er det måske det værd.

Log ind eller opret en konto for at skrive kommentarer