Having children warps your perspective. Totally. And last summer I spent an unhealthy amount of time being annoyed at cars racing up our narrow residential street while rambling incoherently, “Heathens! Think of the children!”

So what does one do? I think some friendly automated neighborhood traffic surveillance would go a long way. So a while back I therefore got hold of a Pocket Radar. While it does evoke the stray ‘is that a radar in your pocket’-joke it is in fact a precise, yet tiny unit. The interface is admirably simple – one big red button (BRB) which starts metering and upon release displays the speed of anything substantial hurtling towards you to within a couple of km/h. So how does it interface?

HEED THIS JOURNEYMAN: According to Pocket Radar the device is very sensitive to static discharge – mostly the pins on the RF board – so if you intend to poke around one of these you should consider an ESD work mat and proper grounding. I did my probing in winter, wearing wooly socks while sliding around on hardwood floors with nothing for protection apart from my sanguine temperament. Stupid luck, most probably.

Promisingly the unit breaks out a few pins right over the battery compartment behind a little sticker. These however proved not to actually carry data, and are probably just diagnostics. Meh.

So here we go.

Broadly the front of the board carries:

• 1 16-bit TI microcontroller – MCU MSP430F21x2
• 1 TI programmable DSP – TMS320LF2401A
• 4 8-bit shift registers for driving the display – "SN74AHC595PW":http://focus.ti.com/lit/ds/symlink/sn74ahc595.pdf
• A slew of analog electronics for powering and filtering whatever comes back from the antenna.
• 2 L324 op-amps

The back has fat pads connecting to the LCD and a light sprinkling of analog components. The bold 7 segment LCD display seems pure oldskool as do the shift registers. It doesn’t have hidden vias or mutiple layers. It’s a USPS truck. It’ll keep on truckin’ till long after the apocalypse.

Photoshop grants me x-ray specs:

Anyways, poking about a bit reveals that the DSP does signal acquisition from the op-amp / RC grid while the shift registers hang off the other MCU and do display refresh. So given:

RADAR → DSP → MCU → SHIFT REGISTERS → DISPLAY

we might just be lucky and find an available digital signal between the DSP and the MCU. Unfortunately finding out what the unit is doing could be somewhat difficult as the antenna is affixed to the back plate of the unit. The same back plate you remove in dissasembling it. Doh. But hey, the unit still powers up and pressing the BRB still still produces a random speed reading every once in a while. I’m guessing this is just noise from the hanging pins usually connected to the antenna.

Probing the DSP while staying far away from the sensitive op-amps reveals that pin 3, SCITXD, unsurprisingly sends something digital and serial to the MCUs RX pin. The TIs support normal UART, but after doing 3 captures I’m left with this:

2 different lengths of signal. Yet a total of 12 changes in sign for all of them.

The display can be set to meters/sec, feet/sec, km/hour and mi/hour. For all we know the data is coming off the DSP in a fifth intermediate format. Hoping that it’s one of the four above and counting.

The width of each pulse is 122µs = 0.122ms = 8196,7 baud. Now, 8196,7 / 2 is 4098 which seems just too much of a coincidence.

Transcribing the bits as clocked out gives us:

1. low -> 1010101011100010101000 -> high
2. low -> 10101010111011100010001110 -> high
3. low -> 1010101000101110001010 -> high


While the display readings in binary are:

1.
86m/s –– 1010110 / lsb 0110101
283f/s –– 100011011 / lsb 110110001
311km/h –– 10011011 / lsb 11011001
193mi/h –– 11000001 / lsb 10000011

2.
81m/s –– 1010001 / lsb 1000101
267f/s –– 100001011 / lsb 110100001
293km/h –– 100100101 / lsb 101001001
182mi/h –– 010110110 / lsb 01101101

3.
136m/s - 10001000
446f/s
489km/h
304mi/h - 100110000


The repeats seem to be carrying information, but how? I stare unblinkingly at it for half an hour to grok pattern, but give up at 1:30AM. Next day I give Simen a call. He remembers a blog post he happenend upon describing an unclocked serial protocol where the recipient meters the baud-rate, by looking at the initial pulses. The repeats then carry a specific truth value regardless of their being high or low. This very quickly gets results.

1. low -> 1010101 011100010101000 -> high
mi/h 0 0 0 0 1 100000 1

2. low -> 1010101 0111011100010001110 -> high
mi/h 0 0 0 0 10 1 10 1 10


3. low -> 1010101 000101110001010 -> high
mi/h 0 0 0 1 00 1 10000


The protocol starts with 7 bits of toggling, presumably to establish a bit rate, 9 bits of data follow. Repeats are signal true, any other toggle is false. The data is in miles per hour.

This snippet of ruby will run the decoder for you – raising an error for repeats that aren’t threes is left as an exercise to the reader:

pulses = ["1010101000101110001010", "10101010111011100010001110", "1010101011100010101000"]
should_equal = [304, 182, 193]

def decode pulse
# chop first 7 bits. sync pulse
pulse = pulse[7..-1]
result = "" and cnt = 0
while cnt < pulse.length do
if pulse[cnt] != pulse[cnt+1]
result << "0"
cnt += 1
else
result << "1"
cnt += 3
end
end
return result.to_i(2)
end

pulses.each_with_index do |pulse, index|
puts "= #{decode(pulse)} // #{should_equal[index]}"
end


When my first daughter was born 2.5 years ago I attempted shielding her from the insiped, trite garbage that is marketed to their bracket. Pink was not to be worn. Unisex garb in earth tones mandated. And indeed, as resistance proves to be futile, today I milled her a Hello Kitty stencil. So she can wield a clone army of pink little kitties and bomb her way to day care.

Shot and edited on my phone. The volume tends to vary.

Hei alle sammen, etter å ha avklart litt med de andre vertene satte jeg med ned sammen med Otto et par timer i kveld for å kikke litt på LINF med henblikk på å gjøre sidene litt enklere å finne fram i. I korte trekk er endringene:

• En stikkordsklynge i høyremargen som viser stikkord som er mye i bruk. Vanlige stikkord er større.
  For at dette skal bli skikkelig bra må man gå igjennom og legge stikkord på de gamle sakene. Muligens en liten dugnad er på sin plass.
• Relaterte saker – når man ser på én enkeltsak får man relaterte saker i høyremargen, også dette basert på stikkord
• En alfabetisk oversiktsside med alle bidragene til dags dato lenket fra blokken på toppen av forsiden
• Søkeboks heist til toppen av høyremargen på forsiden og på oppslag på enkeltsak
• Ny banner og litt finpuss på hvordan sidene fremstår sånn rent visuelt

Håper dere liker det. Det er selvfølgelig opp til vertskapet å tilbakestille endringer som ikke skulle falle i smak.

Jeg har akkurat sparket igang skoleporten.bengler.no. Der kan du undersøke hvordan skolene gjør det på de nasjonale prøvene. Det er bare resultatene fra 2008 som er tilgjengelig, men jeg jobber med å skaffe til veie settene fra de siste to årene.

Sammen med nye tenner, soverutiner og mulige fall i boligmarkedet er skolekvaliteten et vanlig samtaletema blant foreldre i Oslo Øst. En kveld forsøkte jeg å finne noen tall på det, men kom bare tilbake fra Google med et excel-ark fra Dagbladet og minner om et lite behjelpelig utdanningsdirektorat. Jeg tenkte derfor at det hadde vært en fin liten øvelse å gjøre denne informasjonen mer tilgjengelig.

Så hvorfor sitte oppe om natten for å gjøre disse resultatene tilgjengelige? De nasjonale prøvene brukes allerede av utdanningsdisrektoratet til å belønne skolene. Så viktig har det blitt for skolene at de holder svake elever hjemme. De eneste som ikke har god tilgang til tallene er vi som ikke har skolen som arbeidsplass. Jeg synes man burde se lenge og hardt på hvorvidt man skal måle skolene på denne måten, men når informasjonen først eksisterer kan jeg ikke se noen grunn til at den ikke skulle være allment tilgjengelig på en god måte.

Man skal være forsiktig med hva man måler ettersom måling ofte endrer adferd på utilsiktede måter. Incentivene du trodde skulle effektivisere og forenkle, perverterer prosessene du forsøkte å styre. I USA har de senket nasjonale krav for læreplaner samtidig som de har lagt vekt på nasjonale prøver. Den angrende Diane Ravitch som innførte dette systemet har skrevet om hvordan det gikk i The Death and Life of the Great American School System: How Testing and Choice Are Undermining Education.

Om noen har forslag til forbedringer kan hvem som helst sjekke ut kildekoden og datagrunnlaget fra Github.

De siste par ukene har jeg satt av litt tid hver kveld til å lage en liten tjeneste som viser resultatene fra de nasjonale prøvene geografisk på en skikkelig oversiktelig måte. Siden dette er en uformell øvelse i datadreven borgerjournalistikk tenkte jeg selve prosessen kunne være interessant å dokumentere for meg selv og muligens også for andre.

Det tok 15 kvelder og én arbeidsdag. Gitt at jeg har to små barn hvor den yngste gjerne skal bæres en timer hver kveld og den eldste våkner i 0600-tiden kan jeg umulig tenke meg at jeg har klart å bruke mer enn 2 timer i snitt per dag. Så rundt regnet gikk det en arbeidsuke.

Tjenesten står nå live på skoleporten.bengler.no.

Merk: Dette er ikke en spisset, gjennomarbeidet tekst, men heller en slumsete prosjektdagbok

Kveld 1

Skoleporten skal kjøre på:

• Sinatra – Minirammeverk skrevet i Ruby
• MongoDB – NoSQL database
• JQuery – Fint Javascript hjelpebibliotek
• CSS3 / HTML5

Jeg har ikke brukt noe av dette før så jeg leser dokumentasjon og setter opp prosjektet med Sinatra og MongoDB, en ny og artig database som kjører Javascript (wot). Til slutt spar jeg dataene fra excel-arket til Dagbladet inn i MongoDB.

Kveld 2

Så, hvor ligger disse skolene? Sånn på kartet.

Skoleporten har en asp.net løsning (i 2010, omg) som noen nisser har bygd for de. Den er så langt unna REST man kommer og når du søker etter Kampen Skole får du en URL på formen:

http://skoleporten.utdanningsdirektoratet.no/skolesoktreff.aspx?sokestreng=a2FtcGVu0&url=http://skoleporten.utdanningsdirektoratet.no/skolesoktreff.aspx%3fsokestreng%3d%26url%3dhttp://skoleporten.utdanningsdirektoratet.no/enhet.aspx%3fenhetsid%3d974589788%26vurderingsomrade%3dResultatoversikt%26skoletype%3d0%26enhetsid%3d974589788&enhetsid=974589788

OMG

Det er sikkert mulig baklengsengineere javascriptene deres for å finne ut hvordan de lager disse kaudervelske søkestrengene. Men hei, vi betaler for disse skolene. Noen må da kunne fortelle oss hvor de er.

Joda, på den superhjelpsomme portalen norge.no finner jeg dette i FAQen:

Hvor finner jeg adresser til skoler og barnehager?

Adresser til barnehager, grunnskoler og andre skoleslag finner du på Pedlex Norsk Skoleinformasjon

Så bra! Jeg tar meg en tur dit.

Fett, men hei, vent. Ser ikke adressen litt annerledes ut? Nei! Neeei! NEEEEEI! De har rendret teksten som grafikk. Men hvorfor?! Ah, selvfølgelig. De har en bok til salgs til kroner 215,- som de har lyst til å selge oss. Prisen for dette produkt i digital form må jeg maile de for å få. Bra saker. Takk norge.no for at dere lenket meg til denne uselviske og nyttige kilden.

Kanskje jeg skal skrape disse bildene ut av sidene til PedLex og kjøre OCR på de. Så hvordan får jeg kjørt OCR da? Hm, Tesseract, en urgammel open source OCR-maskin finnes i macports. Google finansierte open sourcingen av den for et par år siden så den er sikkert ikke helt ute. Om man gjør bildene litt likere innscannede dokumenter ved å skalere bildene til det tredobbelte, thresholde de og kjører Tesseract med en norsk treningsfil så ser det faktisk ut som det funker relativt bra. Men vent, det må være en bedre måte enn å gjøre tegngjenkjenning på 3000 GIFer.

Hva med Google Places? Som et ledd i sin katalogisering av det norske samfunnet vet jo Google faktisk hvor disse skolene er. Faktisk.

Så hvordan ser Places APIet ut? Det viser seg at Google har begynt å stramme inn litt i APIene sine og krever her at man er en slags ‘kunde’ av Google og søker om å få tilgang hvorpå man må skrive under på blant annet:

• All developers wishing to use the service must already have an Adsense account, or must create one prior to applying.
• Applications that wish to use the API must only issue queries in response to end user actions.
• The results of every search made by applications using this API must be shown to a user.
• Applications may not reorder or manipulate Search results.
• Applications may not store any Place data permanently except References and IDs.
• Place information collected using this API, or any data derived from it, such as Place location corrections, can not be distributed in any way, such as through an API, without the express permission of Google.

Så kanskje ikke det, siden jeg bryter mot 90% av vilkårene. Jeg kunne alltids skrapt det ut av Place-søkene, men det er garantert et brudd på de samme vilkårene det også. Vi vet heller ikke om Places vet om absolutt alle skolene.

Ok, en annen strategi. Hva med Google-søk på skolenavn avgrenset til skoleporten.utdanningsdirektoratet.no, oppslag i skoleporten med påfølgende skraping av adresse som vi slår opp i Googles geokoder? Det er skjøre saker og om noen bestemmer seg for å endre noe på skoleporten eller slenge disse sidene i robots.txt går det i dass, men er kanskje hakket bedre enn å OCRe 3000 GIFer. Får vi treff? Jada=. Holla!

Kveld 3 – Skrap skrap

Det første forsøket ser slik ut:

puts "\nGeocoding #{School.count} schools. Plz wait.\n\n"
School.find(:all)[0..1].each do |s|
puts "-- #{s.name} / #{s.county} / #{s.municipality} (#{s.normalized_tests.length} tests)"
url = "http://www.google.no/search?hl=en&q=" + CGI.escape("site:skoleporten.utdanningsdirektoratet.no -oversikt \"#{s.name}\"")
doc = Nokogiri::HTML(open(url))
address = doc.css('#ires .s')[0].text.match(/.*?\.(.*?\..*?)\./)[1].strip.gsub('.',',')
puts "School address: #{address}"
bounds = Geokit::Geocoders::GoogleGeocoder.geocode(s.municipality, :bias => 'no').suggested_bounds
res = Geokit::Geocoders::GoogleGeocoder.geocode("#{address}", :bias => bounds)
puts res.inspect
puts "\n\n"
sleep 0.8
end


Og visst gir det oss ikke:

-- Holla ungdomsskole / Telemark / Nome (3 tests)
School address: Kirkebakken 18, 3830 ULEFOSS
Provider: google
Street: Kirkebakken 18
City: Ulefoss
State: Telemark
Zip: 3830
Latitude: 59.2793002
Longitude: 9.2633128
Country: NO
Success: true


Holla! Bare 1 av de 5 første feiler. Nå på en enkodingsfeil i geokodingsbiblioteket jeg brukte for å gjøre livet mitt litt enklere. Herlig. Det er litt gammelt og har noen problemer relatert til Ruby 1.9 og Unicode. Som gode internettborgere rapporterer vi feilen, forker koden på github og legger inn de bittesmå fiksene våre.

Det er selvfølgelig noen flere små snags, men med litt taktisk wrangling er det stort sett bare skoler som:

81. BELGIUM – SHAPE International School Norwegian Sec / Utland / Utland (6 tests)
82. BELGIUM – Scandinavian school in Brussels (Ecole R / Utland / Utland (6 tests)
83. BOLIVIA – Colegio Noruego / Utland / Utland (6 tests)

som feiler og det ser ut som det er under 1% som ikke får noen adresse. Bolivia! Disse kan vi håndslå i excel etterpå om vi gidder. Fest!

Kveld 4 – Geokodeagogo

Dette gikk jo ganske bra. Det er sansynligvis et TOS-brudd å gjøre disse søkene og Google sperrer meg etter rundt 256 søk (noen hos Google må ha estetisk sans for 2^n). Det er noen skoler med utenlandsadresser og noen navn med stor diskrepans mellom navnet i nasjonale prøver og i den nåværende versjonen av SKoleporten. Men det er fortsatt ikke mer enn 50 etter å ha kjørt de første 2100 skolene. I tillegg feiler Google en del på adresser av typen Sandshamn, 6089 SANDSHAMN. Disse virker fint på maps.google.com, men feiler i APIet. Kanskje jeg får noe om jeg har en fallback som bare bruker stedsnavn. Det er virkelig stas å sjekke treffene jeg får. Ofte står det en skole plantet midt i satelittbildet. For småsteder mangler skoleporten gateadresser. Kanskje kommer posten fram uansett, men jeg får litt dårlig treff. Det får vi leve med.

Man får tårer i øynene av å tenke på at den danske staten leverer geokoding som en tjeneste på lik linje med ferskt vann i springen, mens vi her i landet må lene oss på Google eller aktører vi må skrive kontrakter med oppsigelsestid for å finne ut hvor en adresse er.

Mens jeg venter på en av-svartelisting fra Google bygger jeg en liten eksport til CSV slik at jeg kan gi dere disse dataene tilbake på Google Spreadsheet så snart det er ferdig.

Kveld 5 – Jern i skapet

Alle har rett noe de kan kalle et eget hjem. Vi har en urgammel maskin (2.6Ghz Xeon / 2 cores) som det for tiden ikke kjører noe tungt på. Den sitter i skapet sitt på coloc-rommet til snill snille Domeneshop nede ved Akerselva. Det står i andre enden av en fiber som går rett til NIX. Det bør holde. Eneste problemet er at den ikke har vært brukt til noe nytt på evigheter og kjørte inntil ikveld Ubuntu Hardy Heron 8.04 . For å brukes til noe nyttig må den oppgraderes til en moderne Ubuntu.

Det går med tre kvarter mens Ubuntu tålmodig river ifra hverandre og setter sammen et system bestående av en en bunke pakker og deres utallige avhengigheter. Med ett grep bygger den det om slik det står og presenterer det i ny støpning. Millioner av kodelinjer, et utall ørsmå tannhjul som griper inn i hverandre. Resten av kvelden går dermed med til å oppgradere og avknekke ting som faller i gulvet i prosessen.

Kveld 6 – These are not the schools you are looking for.

Kjære dagbok. M har trent i kveld. Begge barna gråt hele tiden. Nå sover alle sammen. Titter litt på resultatene fra geokodingen. 10 sprø verdier. Rundt 90 mangler ellers. Det er bare to som er store: Max Tau og Steinern i Oslo. Resten ligger i Bolivia eller på små nes langs kysten. Jeg forsøkte å geokode 10 av de manuelt og det er en royal rumpesmerte. Mange av de finnes hverken av Google Places, 1881.no eller andre kilder. Man ender opp med å søke etter kommunene eller stedsnavnene og det hele blir heller omtrentlig. Lurer på om jeg skal la disse ligge.

Kveld 7 – Tidlig i seng

Tidlig i seng, men stod opp klokken 0200 og la til alle markørene på et Google-kart.

Kveld 8 – Første pass GUI

Mens jeg får det minste barnet til å sove leser jeg meg opp på:

• AJAX med JQuery siden jeg stort sett har brukt Prototype før
• Canvas tegning av GMaps markører siden jeg skal rendre disse programmatisk

Jobber litt med stiling. Drar opp GMaps til fullskjerm og ser på CSS3.

Kveld 9 – Markører over AJAX I

Kikker på Google Table Fusion etter å ha kommet over denne sørgelige anvendelsen? hos the Guardian. Tenker det er et fint verktøy for noen, men knapt komplett for oss med tanke på at jeg ikke har ensartede markører og trenger å tegne fine markører for skolene. Det er synd, siden det er superfint at Google kan rendre digre datamengder som overlays på GMaps for oss med to linjer kode. Sikkert nyttig til noe annet.

Man kan tross alt ikke hente 2980 markers til Google maps så det må skrives noe javascript AJAX for å hente markører når man drar på kartet. Bruker litt tid på å finne ut av Geo2D within søket til Mongodb og banke dette inn i jQuery sitt getJSON kall.

Tror jeg trenger elevantall på hver skole. For det vil jeg vel visuelt indikere? Ser at Google har et JSON-kall som jeg kan bruke istedenfor denne skrapingen av googlesøk med Nokogiri. Det ser lurt ut. Siden Google sikkert ikke er like illsinte på svartelisting i et offisielt API.

Kveld 10 – PLZ WAIT, OK – Normalizing test results.

Nå begynner det å bli relevant å se på de faktiske testdataene. Jeg normaliserer de på en skala fra 0 til 1 i forhold til årstrinn (5. klasse løper fra 1-3, mens 8. løper fra 1-5) slik at vi kan slå sammen resultater for skoler som både er ungdomsskoler og barneskoler. I tillegg skriver jeg snittverdien inn i hver skole, kommune og fylke. Takket være en del kål med Mongoid, MongoDB-abstraksjonen for Ruby som jeg har valgt å bruke, tar dette 2 timer istedenfor 0.5. Kildekoden må ingen lese.

Kveld 11 – Size of school, size of problem may be.

Vi trenger å finne ut hvor store skolene er. Det å gjøre vanlige Google søk fikk meg svartelistet rundt hvert 256. kall hvorpå det tok rundt en halvtime for Google å tillate søk igjen. Ser derfor på JSON-APIet isteden. Ser fint ut. De viser seg imildertid at skoleporten AJAXer inn tabellen med elevantall. Gaargh. Who are these people? Må derfor Google, gjøre oppslag på skoleporten, finne tak i AJAX-kallet, hente HTML-fragmentet fra URLen den bruker og parse ut verdien av tabbelen i den siste cellen på andre linje. Takkskarruha.

Det virker, men tar litt tid. Med en del feilsøking og presisering av søket er det alt som blir gjort ikveld. Det er grenser for hvor nøyaktige det blir på denne måten. Om noe blir denne prosessen et slags langtrukkent argument for å sette APIer på offentlige tjenester.

Kveld 12 – Markører over AJAX II – The Revenge of Front End

Vi kan ikke hente 2930 kartmarkører og sette de på kartet. Det er altfor tungt. Vi kan bare vise de som er innenfor kartet til enhver tid. For utzoomede bilder må vi vise kommuner og fylker. Dette krever at Google Maps må snakke med serveren hver gang du flytter på kartet. Vi må også fjerne markører som detter utenfor delen av kartet vi ser på. Gmaps har en del fine funksjoner som forenkler dette, men vi må fortsatt skrive en liten MarkerManager som holder orden på markørene vi har satt.

Kveld 12 – Tegne kartmarkører med HTML5 canvas

Starter med en modifisert utgave av dette eksempelet. På kort tid har jeg for første gang fargelagte små infoboller for hver skole. Begynner med en mapping i HSL-fargerommet. Skolene legges i farge mellom rødt og grønt. De som ligger midt på treet blir gulbrune. I tillegg legger jeg på en sigmoid-kurve av dette slaget for å aksentuere forskjellene. Lurer på om ikke blått til oransj hadde vært en like effektiv, og litt mindre rotete fremstillingen av resultatene.

Kveld 13 – Estetisk frobbing av markører og kart.

Fjerner gradientene på markørene og legger til skalering på elevantall. Sørger for at markørene faktisk er sentrerte koordinatene sine. Elevantallet er ganske random vise seg. Det er små skoler i distriktene som dukker opp med 500 elever presumptivt fordi jeg har sanket tall fra hele kommunen eller fylket de ligger i. Håper utdanningsdirektoratet kan gi meg en fin liste over hvor store disse skolene er.

Markørene på kartet må bli tydeligere. Forsøker meg på å få tak i DOM-elementet som holder selve kart-flakene til Google for å gjøre de transparente mot en mørk bakgrunn. Viser seg å være mulig, men litt involvert og flaky om Google skulle oppdatere måten kartkomponenten er pakket på. Men hei, Google har laget stiling av kartene. Jeg har nesten ikke sett dette i bruk selv om det har vært live i månedsvis. Man kan skru av og på innholdstyper og bestemmer fargene deres helt etter eget forgodtbefinnende. Stas. Kartet blir mørkt og nattklubbaktig for å vise fram markørene. Går over og gjør markørene enda mer Walter Gropius-aktige.

Legger også ut prosjektet offentlig på Github. Koden, databasedumper, grunnlagsdataene, alt sammen.

Kveld 14 – Klargjøring av prodmiljø, visning av kommuner, twitter

Aftenposten ledet med nasjonale prøver i dag. Saken handlet om hvordan Oslo-skolene unntar de svakeste elevene fra prøvene for å heve resultatene. Det hadde vært interessant å se denne informasjnen sammen med prøveresultatene, men det får vente.

Klargjør produksjonsmiljøet med rvm og riktig ruby versjon (1.9.2) og ser på måter å kjøre sinatra sammen med lighttpd. Ser greit ut.

Når noen zoomer ut må vi gå over til å vise kommuner istedenfor skoler. Skriver støtte for dette. Tar en halvtime.

Oppretter en twitterkontoen @skoleporten. :)

Kveld 15 – Visning av resultater fra enkeltskoler i popups

Setter opp henting av data med JSON over AJAX for hver skole. Interessant informasjondesignsoppgave. Hva er den enkleste måten å vse informasjonen på. Gruppering, klare hierarkier og fargekoder som overenstemmer med hovedvisningen er sikkert klokt. Hey, JQuery har en liten templating engine så jeg kan kjøre JSON rett over i templates jeg har skrevet i HAML. Boggle.

Dag 16 – 3. november 2010

Setter av et par tre timer på jobben til å ferdigstille stiling av popups og skrive en about-tekst. Noier ut da jeg ser at ruby på serveren bruker rundt 200ms på serveren på å pakke 400 markører i JSON. Bruker en time på å se etter optimeringsforslag og roer meg ned da Alex foreslår et JSON-bibliotek med det poetiske navnet Yajl (yeah, Yet Another Json Library – om det hadde stått som et onematopoetikon i en tegneserie hadde det vært dødsralling) som kutter tiden ned til mellom 1/2 og 1/3 på benchmarkene. Laptopen min gjør dette på 1/5 av tiden forresten. Som før nevnt, gammel hardware.

Anways, vi står nå live på skoleporten.bengler.no.

Det kan innimellom se ut som offentlig sektor ikke er så opptatt av faktisk bruk av nettløsningene de lager (mer om dette her), men heller at de skal kunne si at informasjonen er tilgjengelig på nett.

Folk som drifter webservere kan legge fra seg et lite tekstdokument som Google og andre roboter titter på for å finne ut om det er noen kataloger man vil at de ikke skal tråle. Robots.txt heter den og ligger alltid på http://eksempel.no/robots.txt. Her har dere f.eks vår egen. Her finner man gjerne søkesider, automatisk generert innhold og annen nettkompost som man ikke vil ha treff på. Men noen ganger legger organisasjoner sider i robots.txt som de av en eller grunn vil at vi helst ikke skal finne.

Forskjellen mellom dokumenter som er tilgjengelige på internett og indeksert av google illustreres kanskje best gjennom nyhetsmedienes bruk av skattelistene da de gikk fra å presentere de som søk på sine egne sider til å rulle de ut som trålbare sider. Det var da vi begynte å få treff på inntekt da vi egentlig bare var på jakt etter et telefonnummer.

Anyways, det er en fin sport å se på robots.txt ettersom det kan gi et bilde av hva noen helst ikke vil at du skal se på. Ofte er det bare meningsløst, andre ganger er det interessant.

Sjekk f.eks Utdanningsdirektoratet sin på http://www.udir.no/robots.txt:
User-agent: * Disallow: /postjournal/ *Disallow: /Upload/postjournal/* *Disallow: /upload/Postjournal/*
Ikke overraskende vil de at vi ikke skal kikke på postjournalen deres!

Helsedirektoratet vil helst at vi ikke kikker nærmere på informasjon om Pandemien:

Disallow: /fri *Disallow: /pandemi* Disallow: /vp/multimedia/archive/00011/Kriseplan_A-divisjon_11902a.doc Disallow: /Internet/htdocs/navigation/navigationtxtMainMenu.jsp Disallow: /portalHelp Disallow: /portal/page

Forsvaret ser alle helst at vi av en eller annen grunn ikke skal kunne Google oss fram til pressemeldingene deres:

1. /robots.txt file for http://www.mil.no The Norwegian armed forces Internett site

User-agent: *
Disallow: /pubs/fnett/template
Disallow: /pubs/fnett/error
Disallow: /pubs/fnett/incoming
Disallow: /pubs/fnett/multimedia
Disallow: /pubs/fnett/forsvarsnett/start/aktuelt/pressemeldinger
Disallow: /pubs/fnett/forsvarsnett/start/aktuelt/nyheter
Disallow: /pubs/fnett/forsvarsnett/felles/fms/start/artikler/nyhetsbrev
Disallow: /multimedia/archive


UiO sin publiseringsløsning for open access vil på sin side at Google helst ikke skal indeksere de publiserte avhandlingene:

1. robots.txt for http://www.digbib.uio.no/

User-agent: *

#DUO
#Oppdatert 17.10.04 av Reidun Kringstad

Disallow: /publ/
Disallow: /internt/

Så ja, kanskje man skulle laget en søkemotor for offentlig virksomhet her til lands som bare indekserer det som er unntatt vanlige søk.

After seeing Doug McCune’s playful visualization of public data, If San Fracisco Crime were Elevation I was tempted to do the same for a Norwegian data set.

After casting about for something to make heat maps out of I came upon KOSTRA, the official statistics from Norwegian municipalities. While not exactly as spectacular as prostitution in the Tenderloin, Norwegian road spending per capita is a political hot potato (or at least, a semi-lukewarm potato). Here follows a few renders from last night. Like Doug I have to emphasize that this is close to useless as strict infoviz, but it does make for nice eye candy.

ABM-sektoren har rikholdige arkiver med fantastisk materiale. Men det kommer ikke befolkningen til gode i den grad man kanskje skulle forvente.
Presentasjonen under (som er laget på oppdrag for ABM utvikling) forsøker å finne svar på noen av disse spørsmålene og komme med noen anbefalinger om hvordan ABM-sektoren kan gjøre seg relevante gjennom bruk av samlingene i de digitale allmenningene.

Da ABM-utvikling spurte om jeg kunne komme og snakke om hvordan de burde forholde seg til sosiale medier brukte jeg en del tid på å lure på hva som ville det nyttigste perspektivet. Ofte dreier slikt seg om hvordan organisasjoner skal stokke beina i forsøket på å forholde seg til dialog og brukermedvirkning. Men da jeg fikk satt meg ned og brukt litt tid på tjenestene de har lansert ble det fort tydelig at det var andre temaer som kunne være vel så nyttige.

I møte med delingskulturen vil samlingene ofte være råstoffet når folk skal sette seg ned og snekre sine egne ytringer. For samlingene må dermed møtet med sosiale medier handle om hvordan de kan få samlingene i bruk. Hvordan kan man finne materialet? Når man først har funnet det, hvilken bruksrett har man?

Noen konklusjoner:

• Belønn institusjoner som får samlingene i bruk
• Man må kunne finne materialet igjennom vanlige søkemotorer
• Gi slipp på enerett. CC-lisensiering bør innføres der det er mulig
• Dokumenter som er falt i det fri må for all ikke merkes som om de er beskyttet
• Ikke lag egne sosiale tjenester. Integrer med de eksisterende
• Lag åpne grensesnitt til samlingene så vi kan bruke dem der vi ønsker

ABM-sektoren har rikholdige arkiver med fantastisk materiale. Men det kommer ikke befolkningen til gode i den grad man kanskje skulle forvente.
Presentasjonen under (som er laget på oppdrag for ABM utvikling) forsøker å finne svar på noen av disse spørsmålene og komme med noen anbefalinger om hvordan ABM-sektoren kan gjøre seg relevante gjennom bruk av samlingene i de digitale allmenningene.

Da ABM-utvikling spurte om jeg kunne komme og snakke om hvordan de burde forholde seg til sosiale medier brukte jeg en del tid på å lure på hva som ville det nyttigste perspektivet. Ofte dreier slikt seg om hvordan organisasjoner skal stokke beina i forsøket på å forholde seg til dialog og brukermedvirkning. Men da jeg fikk satt meg ned og brukt litt tid på tjenestene de har lansert ble det fort tydelig at det var andre temaer som kunne være vel så nyttige.

I møte med delingskulturen vil samlingene ofte være råstoffet når folk skal sette seg ned og snekre sine egne ytringer. For samlingene må dermed møtet med sosiale medier handle om hvordan de kan få samlingene i bruk. Hvordan kan man finne materialet? Når man først har funnet det, hvilken bruksrett har man?

Noen konklusjoner:

• Belønn institusjoner som får samlingene i bruk
• Man må kunne finne materialet igjennom vanlige søkemotorer
• Gi slipp på enerett. CC-lisensiering bør innføres der det er mulig
• Dokumenter som er falt i det fri må for all ikke merkes som om de er beskyttet
• Ikke lag egne sosiale tjenester. Integrer med de eksisterende
• Lag åpne grensesnitt til samlingene så vi kan bruke dem der vi ønsker

We still haven’t received the bits we’re waiting for, but today we at least managed to make some fine cuts. The micRo is excellent and whenever our incompetence gets out of the wait for a few minutes it really shines.

Today we painstakingly milled out a triangle of 20mm HDPE (with a dremel plywood bit with 2 straight shears and 10mm of cutting action). We plowed some furrows into HDPE playing feed rates, cut depths and bits. We found a couple of sweet spots that produced perfect cuts (350mm/minute, 2 flute rotozip bit – yet the tool was about 5cm long so we saw massive deflection in the range of 1-2mm. Useless!). We also cut a really encouraging knife sharp slot into Amfitop (a local dialect of Corian) with the same “useless” plywood bit mentioned above. This was done at 25mm/min rate.

After that we made a sharp small test cut into a 2mm aluminum sheet. We then prepared a small machine part to cut about whereupon the chuck promptly fell out of the spindle with a nasty screech. This has happened to us before and expect to just pound it back on like we did the last several times.

Our toolchain currently consists of TurboCAD for modelling, Cut2D for CAM and Simen’s own GRBL for motion control.

Our time in world as millers now spans all of 8 hours, and we’re pretty happy about the rate that our n00bness is dwindling.

Last Thursday was spent driving around Oslo buying the equipment to set up our humble workshop in the back room of our office. Today we finally got around to powering up the CNC and making our first few cuts.

Ok so:

1. We’ve never in our lives milled anything
2. Simen has waited a year for his Lumenlab micRo and spent the time building an Arduino compatible motion controller:GRBL

We’re still waiting for proper bits to arrive from Victor Machinery Exchange, but achieved OK-ish results on a cheap cutting board (LDPE) with random bits picked from the bargain bin at our local hardware shop. GRBL worked tirelessly for an entire evening without the need for a single rewrite, cutting both line segment and arcs. We’re pretty ecstatic about this as the code has never been run on an actual milling machine before, just in software simulation. The micRo also seems like a really solid piece of hardware, effortlessly snapping our steel bits when we made an erronous moves with the bit at standstill.

Har du kunnskaper om og er du involvert i offentlig og privat nyskaping? Er du opptatt av borgerinvolvering og hva slags muligheter web 2.0-verktøy representerer i samfunnsutviklingen? Da er denne workshopen som Origo.no arrangerer på vegne av Fornyingsdepartementet på Litteraturhuset noe for deg.

Sett av 9. desember kl 10-14 i kalenderen din og meldt deg på så fort som mulig, vi har begrenset med plasser.

I tillegg til fire foredrag og en workshop med 5 forskjellig tema, kan du komme med innspill på FADs konkurranseutlysning. Neste år skal FAD dele ut prosjektstipend til aktuelle prosjekter som tar i bruk sosiale medier og web 2.0-verktøy.

Du får med deg fire foredrag som vil gi deg nye ideer:

Håkon Wium Lie – teknologisjef i nettleserselskapet Opera. Wium Lie vil fortelle oss hva hvordan norsk IT-politikk kan gjøre næringslivet mer nyskapende.

Simon Dickson – UK-basert politisk innovatør som var en av skaperne av Downing Streets nettside og som er webkonsulent for flere britiske departement. Dickson skal fortelle oss hvordan politikere og det offentlige kan bli mer innovative.

Nikki Timmermans – konsulent i Knowledgland som har organisert innovasjonskonkurranser for nederlandske myndigheter siden 2002. Hun vil vise oss de beste eksemplene.

Olav Anders Øvrebø – journalist og redaktør for Vox Publica. Øvrebø har kartlagt offentlig datakilder i Norge og vil fortelle oss hva han har funnet.

Etter foredragene er det lunsj og workshop. Vi deler alle deltakerne inn i grupper som rullerer innom ulike bord med disse temaene:

1. Digitalt demokrati – verktøy for deltakelse
2. Hvilke behov kan man best løse med web 2.0-teknologi ? Om nye tjenester basert på viderebruk av offentlige data
3. Hvilke kriterier bør FADs konkurranseutlysning inneholde?
4. Hva er utfordringer og fallgruver ved bruk av sosiale medier og web 2.0?
5. Nettdugnad- hvordan bruke engasjementet fra brukerne til å løse oppgaver

Om du vil, kan du foreslå andre temaer.

(Vi tar forbehold om at det kan oppstå endringer i programmet.)

Vi har nå lukket påmeldingen fordi mer enn 60 personer har meldt seg på.
Meld deg på. Vi har plass til ca. 60 personer, så meld deg så raskt som mulig.