Om Netflix og Comcast

I Techsistens episode 21 snakker @rankenberg og @damsted om aftalen mellem Comcast og Netflix. Jeg synes deres diskussion lider lidt under mangel på indsigt i, hvordan livet er for en ISP. Selvom jeg på ingen måde er ekspert på området, vil jeg gerne kaste bringe nogle flere problemstillinger til bordet for at vise, at det ikke er så sort og hvidt.

Som jeg ser det, er der to årsager til konflikten:

For det første, så handler det om ISPernes forpligtelser overfor kunderne – eller rettere mangel på samme. Når en kunde køber en internetforbindelse på f.eks. 10 Mbit, betyder det ikke, at kunden kan forvente 10 Mbit til enhver tid (men det er der bare ingen der fortæller kunden). Når ISPen køber sig ind på et geografisk område, har området en maksimal samlet båndbredde. ISPen regner derfor ud, at de kan have så og så mange kunder i det område med den båndbredde. Formlen for det er noget i retning af, at hvis alle kunder udnytter 100% af sin linje på samme tid vil de i praksis kun få 70% kapacitet. ISPerne oversælger med andre ord sine forbindelser. Det kan de, fordi typisk internettrafik ikke vil kunne mærke det. Det antages ganske enkelt, at alle kunder aldrig vil udnytte sin forbindelse fuldt ud på samme tid. Problemet opstår, når alle begynder at benytte meget kapacitetstunge (er det et ord?) tjenester som Netflix. Så viser det sig nemlig, at ISPerne er nødt til at øge kapaciteten i området for at kunne holde det de lover, mens de ikke kan øge prisen overfor kunderne.

For det andet er ISPerne nødt til at sende trafikken videre ud i verden (og modtage, naturligvis). Det foregår ved, at man forhandler sig til aftaler med andre netværksejere om prisen pr GB data, der flytter sig (routes) til og fra ISPens netværk. Når data skal fra Netflix til Hr Jensens hus vil det gå via adskillige netværk med forskellige ejere. Hver gang en datapakke går fra et netværk til et andet, skal nogen betale for det. Problemet her er lidt det samme som i første problemstilling: Trafikken øger og koster mere for ISPen, men de kan ikke sende regningen videre til kunderne.

Siden tjenester som Netflix, Spotify og HBO er dukket op nærmest over natten, kan jeg forestille mig, at det må være smertefuldt for ISPerne. Man kan argumentere for, at ISPerne har sovet i timen, bør tage konsekvensen, og leve op til det, de har lovet sine kunder, men det hjælper ikke meget, hvis budgetterne ikke holder. I tilfældet Comcast er problemet ekstra finurligt idet de er nogle røvhuller og bevidst har begrænset trafikken fra Netflix (siges det). Hvis det er sandt, er det i mine øjne den største grund til at være skeptisk overfor aftalen, der er indgået.

Jeg er stor tilhænger af netneutralitet og synes aftaler som Netflixs med Comcast er et skråplan. Men jeg kan også godt se, at det er et problem for ISPerne, og at regningen må betales. Jeg har ikke løsningen, men jeg er overbevist om, at den ikke består af individuelle aftaler. Måske må vi som forbrugere også bide i det sure æble og acceptere, at ændringerne i vores internetadfærd har en pris.

Gør det selv regnmåler

Når man bor i regnvåde Bergen, frister det ikke altid at bevæge sig udenfor. Man kan lige så godt prøve at få det bedste ud af det, så hvorfor ikke prøve at måle nedbøren?

Man kan selvfølgelig stille en beholder ud i regnvejret og måle, hvor meget vand der ender i den, men hvor kedeligt er det ikke? Nej, der skal være strøm og internet involveret, før det er noget ved.

Udgangspunktet var at tage en Raspberry Pi og lave en vejrstation. Den skal måle forskellige vejrdata med jævne mellemrum og gemme dem i en database. Ovenpå det skal der være en webside, hvor data kan læses – både her & nu samt historiske data.

Regnmåleren er i bund og grund ret simpel: En tragt leder vandet ned i et af kamrene i en todelt beholder. Beholderen står på en akse og vipper, når det ene kammer er fuldt, så kammeret tømmes mens nyt vand løber ned i det andet kammer. Siden man kender arealet på tragten og hvor mange milliliter vand kamrene kan rumme, kan man beregne hvor mange millimeter regn et vip svarer til. Dette kaldes også en tipping bucket rain gauge.

Når man bygger regnmåleren, bør man være nøje med at kalibrere rigtigt, så begge kamre rummer lige meget vand. Siden det er ret små mængder, vi snakker om, er det en god ide at gå på apoteket og købe den mindste sprøjte, de har. Med den kan man fylde små mængder vand i et kammer ad gangen og på den måde finde ud af, hvor meget vand der skal til, før beholderen tipper.

Vores regnmåler endte med en overflade med en diameter på 9cm, og hvert kammer kan indeholde 5ml vand. Det betyder, at hvert vip svarer til omtrent 0,8mm regn.

Udregningen er 5ml / ((4,5cm2 * π)/10) = 0,78mm.

En opløsning på 0,8mm per vip er lidt i overkanten. Man bør stræbe efter 0,1 – 0,2mm. Vi håber på at lave en version 2.0 med bedre opløsning.

For at aflæse regnmåleren bruger vi en fotoresistor, som lyses op af en diode. Fotoresistoren er koblet til en kondensator, som lades op af strømmen den får. Et lille “flag” på en arm på bægeret vil skiftevis skygge for fotoresistoren eller ikke. Et program vil jævnligt aflæse strømmen fra fotoresistoren ved at måle den tid, det tager at lade kondensatoren op. Tiden siger noget om, om der er lys på fotoresistoren eller ikke, og man kan dermed finde ud af, om armen har bevæget sig siden forrige aflæsning.

Selve aflæsningen kan gøres bedre, og vi kommer forhåbentligvis til at ændre det i version 2.0. I en perfekt verden sendes der et signal til computeren, når flaget bryder lysstrålen – ikke noget med at huske på hvad forrige status var. Siden en Raspberry Pi udelukkende har digitale indgange, kræver det at man laver et smart kredsløb, der kan sende strømmen videre til inputtet kun når lysstrålen brydes.

Pi’en har ikke alverden med diskplads eller CPU-kræfter, så jeg valgte at gemme dataene på en server – i dette tilfælde en EC2 hos Amazon. Der har jeg et lille REST API som tager imod aflæsninger fra Pi’en, og en webside viser aggregerede tal til min store fornøjelse.

Planen er at open source hele molevitten, men jeg vil gerne have modnet og strømlinet koden lidt mere, før jeg viser det frem.

Om typer af input

Når jeg skal udfylde en formular på nettet, ser jeg alt for ofte, at udviklerne bag ikke benytter sig af, at input-felter kan være andet end almindelig tekst. Udover typen text findes der blandt andet også url, email og number. Disse typer er utrolig nyttige, fordi de fortæller klienten mere om, hvad der forventes af inputtet. Det bruges specielt i to tilfælde:

  • synshandicappede som får læst sidens indhold højt
  • mobile enheder, der tilpasser tastaturets layout

Selv har jeg naturligvis mest erfaring med den sidste kategori. Når man skal indtaste en url eller en email kan det være irriterende, at skulle skifte frem og tilbage mellem tastaturlayout for at finde de rette tegn. Det kræver så lidt at bruge url og email til web- og emailadresser, og effekten er stor.

Eksempel på type=email

På iPad ændrer tastaturlayoutet sig, så @ er lettere tilgængelig, når type er sat til email.

Så hvis du laver websider, så husk på følgende:

  • brug number, url og email til inputfelter som falder indenfor de respektive kategorier
  • browsere, som ikke forstår typerne, falder tilbage til almindelig tekstinput, så det er ikke farligt at bruge

Der findes også mere eksotiske typer som “color,” “date” og “range” men de skal nok bruges med lidt større forsigtighed, siden de ikke er direkte undertyper af text som de andre er. Dem kan du læse mere om her.

Nem konvertering af farver – et sideprojekt

Et nyt sideprojekt har set dagens lys: The Friendly RGB to Hex Converter.

Som navnet antyder, er der tale om et værktøj til at konvertere RGB farver til hexadecimal. Hvis du ikke ved, hvad det er for noget, så er værktøjet sandsynligvis ikke for dig. Men læs gerne videre alligevel.

Men hvorfor lave sådan et værktøj? Der findes tusindvis af sider, der kan konvertere RGB til hex, så vi behøver vel ikke endnu et? Nej, det gør vi nok ikke, men jeg gjorde. De sites jeg testede syntes jeg manglede en oversigt over de farver, man allerede havde konverteret. Man skulle selv sørge for at kopiere farverne til et andet program, før man går videre til næste. Det virker fint for en farve, men skal man konvertere en hel palette, bliver det lidt omstændeligt.

Det, synes jeg, kan gøres bedre.

Derfor vil min konverter løbende opdatere en liste over alle farver, man har konverteret. På den måde kan man holde styr på dem og kopiere koderne efter behov.

Siden en RGB til hex konverter i udgangspunktet ikke er raketvidenskab, valgte jeg at fokusere lidt mere på inputfeltet. For det første er det gjort stort og nemt at komme til (ikke til at komme udenom, med andre ord). For det andet – og mest vigtigt – har jeg forsøgt at gøre det dynamisk på den måde, at så snart der skrives noget, som kan tolkes som en RGB kode, bliver den konverteret og vist i preview-feltet. På den måde kan man sidde og lege med farver bare ved at ændre tallene. Det virker ret godt, synes jeg. I hvert fald hvis man holder sig til komma eller mellemrum som separator.

Skulle jeg forbedre konverteren ville jeg nok tilføje drag-and-drop organisering af farverne i historikken. Det kan være behageligt at have dem sorteret på en bestemt måde.

Atter engang var det en bekræftende øvelse at lave noget konkret, som er kommet ud i æteren. Jeg håber du vil synes om det.