Archive | mai 2020

Relasjoner – OSS

Etter at jeg la ut serien med innlegg om relasjonsdatabaser her på Rosabloggen har jeg fått en del spørsmål, og jeg tenkte at det kunne være greit å samle de ofte stilte spørsmåla i et eget innlegg.

«Hva hvis en pasient har flere leger?». Det det spørres om her kalles en mange-til-mange-relasjon. I praksis betyr det at en lege kan ha mange pasienter, og en pasient kan ha mange leger. Jeg skal nå vise hvordan dette kan løses i lege/pasient-databasen vår. For at man skal ivareta normaliseringen må det innføres det som kalles en koblingstabell. For å gjøre det oversiktlig for meg selv så pleier jeg å navngi koblingstabellene med et navn som viser hvilke to tabeller jeg knytter sammen. I dette tilfellet er det tabellene «lege» og «pasient» som skal knyttes sammen i en koblingstabell, og gir den derfor enkelt og greit navnet: «lege_pasient». Koblingstabellen «lege_pasient» har det som kalles en sammensatt primærnøkkel. Den består av de to primærnøklene til tabellene «lege» og «pasient». Siden man nå ikke lenger trenger fremmednøkkelen «l_id» i tabellen «pasient» så kan denne slettes. Denne ble kun brukt til å knytte en pasient til en lege, og har derfor ingen funksjon lenger. De 3 involverte tabellene i databasen ser nå slik ut:

Under er SQL-spørringa for å hente ute en liste som viser pasienter knyttet mot leger.

SELECT pasient.navn AS pasient,
       lege.navn AS lege
  FROM pasient
  INNER JOIN lege_pasient on lege_pasient.personnr = pasient.personnr
  INNER JOIN lege on lege.l_id = lege_pasient.l_id;

Resultatet av spørringa ser slik ut:

Ser man på tabellen over så har hver lege 2 pasienter hver, og «Gunnar Åm» han har 2 leger. Nå kan det kanskje virke litt søkt at en pasient har flere leger, men mange-til-mange-relasjoner er ganske vanlig. La oss ta et enkelt ordresystem. Vi har en ordretabell og en produkttabell. Dette er en mange-til-mange-relasjon da en ordre kan inneholde mange produkter, og et produkt kan være på mange ordrer. Koblingstabellen «ordre_produkt» (et bedre navn hadde kanskje vært «ordrelinjer») vil også gjerne inneholde antallet av de respektive produktene.

«Hvordan legger jeg inn leder til en ansatt?». Der er flere måter å løse dette på. Man kunne brukt en avdelingstabell som de ansatte knyttes mot, og de ulike avdelingene har en leder knyttet mot seg. Men nå skal vi gjøre ting enklere enn som så. Problemet kan løses ved hjelp av rekursive forhold. Enkelt forklart så har man en fremmednøkkel som peker til primærnøkkelen i en og samme tabell. Jeg har laget et enkelt organisasjonskart med 10 ansatte for den fiktive bedriften Rakett AS.

Jeg har laget en enkel tabell «ansatt» for alle de ansatte. Ansattnummeret er unikt for alle ansatte i bedriften og blir primærnøkkelen «ansattnr» i tabellen «ansatt». Videre så har vi navnet og stillingen til de ansatte, og til slutt fremmednøkkelen «leder» som peker til primærnøkkelen «ansattnr» i samme tabell. Tabellen ser slik ut:

Som man ser av tabellen (og av organisasjonskart) så har alle en leder bortsett fra daglig leder. Verdien NULL betyr at der ikke eksisterer en fremmednøkkel. Skal man hente ut en liste over ledere og sine ansatte så kan SQL-spørringa skrives slik:

SELECT leder.navn AS leder,
       medarbeider.navn AS ansatt 
FROM ansatt medarbeider
INNER JOIN ansatt leder ON leder.ansattnr = medarbeider.leder;

SQL-spørringa over kalles gjerne en «self join». Man kan se på en «self join» som om at man slår sammen to kopier av samme tabell, men tabellen er selvsagt ikke kopiert. «medarbeider» og «leder» er alias til tabellen «ansatt» og navnene på de to «kopiene». Resultatet av spørringa blir som dette:

Relasjoner – SQL

Når man skal hente, legge til, oppdatere eller slette data fra en relasjonsdatabase så er det naturlig å snakke om SQL. SQL står for Structured Query Language og er et spørrespråk for databaser. Nå skal ikke dette innlegget være noe SQL-kurs for sånt finner man mye bra av på nett. Jeg tenkte heller at jeg skulle vise hvordan noe spørringer vil se ut mot en SQLite-versjon av lege/pasient-databasen fra innlegget «Relasjoner – Normalisering«. Jeg brukte forresten SQLiteStudio til å opprette databasen, til å legge data inn i tabellene og for å kjøre de aktuelle spørringene. Her er den første og den enkleste SQL-spørringa:

SELECT navn, tlf FROM pasient;

SQL-spørringa over henter enkelt og greit navnet og telefonnummeret til alle pasientene. SQL-spørringer avsluttes med semikolon. Resultatet er som følger:

Vi skal nå kikke på en mer avansert spørring hvor vi henter data fra flere tabeller.

SELECT pasient.personnr AS personnr,
       pasient.navn AS navn,
       pasient.adresse AS adresse,
       pasient.postnr AS postnr,
       poststed.poststed AS poststed,
       pasient.tlf AS telefon,
       lege.navn AS lege
  FROM pasient
  INNER JOIN poststed on poststed.postnr = pasient.postnr
  INNER JOIN lege on lege.l_id = pasient.l_id;

Vi tar en stegvis gjennomgang av SQL-spørringa over.

  1. «SELECT pasient.personnr AS personnr,» betyr hent personnummeret til pasienten. I spørringer som dette som involverer flere tabeller (her: pasient, lege og poststed) så spesifiserer man gjerne tabellnavnet for feltet. Altså betyr «pasient.personnr» personnr-feltet fra tabellen pasient. «AS» betyr gi kolonneoverskrifta i utlistingen navnet «personnr».
  2. «pasient.navn AS navn,» er en fortsettelse fra linja før (legg merke til kommaet i slutten av linje 1) og betyr hent navnet til pasienten og kall kolonna «navn».
  3. «pasient.postnr AS postnr,» er postnummeret til pasienten og kall kolonnna «postnr».
  4. «poststed.poststed AS poststed,». Her henter man poststedet fra tabellen «poststed» og kaller kolonna ikke uventet «poststed».
  5. «pasient.tlf AS telefon,» som betyr telefonnummeret til pasienten og kall kolonna «telefon».
  6. «lege.navn AS lege» gir navnet til legen fra tabellen «lege» og kolonneoverskrifta blir «lege».
  7. «FROM pasient» betyr at dataene hentes fra tabellen «pasient».
  8. «INNER JOIN poststed on poststed.postnr = pasient.postnr» betyr at man henter data fra tabellen «poststed» hvor postnummeret (postnr) er likt i tabellene «poststed» og «pasient». Til informasjon så finnes flere typer med «JOINs». «poststed.postnr» er primærnøkkel i tabellen «poststed» og «pasient.postnr» er fremmednøkkel i tabellen «pasient».
  9. «INNER JOIN lege on lege.l_id = pasient.l_id;» henter data fra tabellen «lege» hvor ID-nummeret (l_id) er likt i tabellene «lege» og «pasient». «lege.l_id» er primærnøkkel i tabellen «lege» og «pasient.l_id» er fremmednøkkel i tabellen «pasient». SQL-spørringa avsluttes med et semikolon.

Resultatet som listes ut av spørringa blir slik:

Spørring nummer 3 skal hente ute en adresseliste, som inneholder navn, adresse, postnummer og poststed, for alle pasientene til legen «Petter Olsen».

SELECT pasient.navn AS navn,
       pasient.adresse AS adresse,
       pasient.postnr AS postnr,
       poststed.poststed AS poststed
  FROM pasient
  INNER JOIN poststed on poststed.postnr = pasient.postnr
  INNER JOIN lege on lege.l_id = pasient.l_id
  WHERE lege.navn = 'Petter Olsen';

SQL-spørringa over er ganske lik spørring nummer 2 så jeg går ikke i detalj gjennom hver linje, men den har fått en ny linje på slutten av spørringa. «WHERE lege.navn = ‘Petter Olsen’;» betyr enkelt og greit at spørringa skal begrenses til bare å inneholde pasientene til legen «Petter Olsen».

Legg merke til at navnet til legen ikke er med i utlistinga. Skulle det vært med så måtte man lagt «lege.navn AS lege» til i spørringa før «FROM pasient». Pass på at man har kommaene på rett plass. For de som nå fikk litt panikk så finnes det verktøy med fine grafiske grensesnitt hvor man kan bruke mer eller mindre «dra og slipp»-funksjoner (f.eks. Microsoft Access) for å generere SQL-spørringene.

Relasjoner – Verktøy

I innlegget «Relasjoner – Normalisering» gikk jeg gjennom en del av teorien bak design av en relasjonsdatabase. Vi skal nå kjapt kikke på noen systemer og applikasjoner man gjerne kommer borti i forbindelse med relasjonsdatabaser. Vi begynner med en applikasjon som kanskje mange allerede har på PCen gjennom Office-pakken. Microsoft Access er en applikasjon hvor det er mulig å lage relasjonsdatabaser. Microsoft Access har veldig mange muligheter og en del av de overlapper med Excel. Det er vanlig å bruke Access-databaser som datakilder til Excel, Power BI og for den del Word (f.eks. en adressedatabase for fletting av brev). Microsoft Access har noen begrensninger (maksgrense på 2GB og 32.768 objekter i databasen.), men for de fleste er dette ikke noe problem. De som er vant til Office-pakken og klassiske Microsoft arbeidsflater vil kjenne seg godt igjen. Applikasjonen har gode veivisere og designverktøy. Som sagt for de som allerede har denne applikasjonen så er dette et bra sted å begynne. Siden vi snakker om Micrsoft så må man nevne Microsoft SQL Server Express. Systemet som kjører som en egen tjeneste har en begrensning på databasen på 10GB, maksimalt minne på 1.4GB og kjører på 1 socket eller 4 kjerner. Det kan være at noen allerede har en Microsoft SQL Server Express installert da den gjerne installeres som databasesystem i andre applikasjoner. Det finnes en rekke andre versjoner av Microsoft SQL Server men de blir gjerne altfor kostbare for privat bruk. Det er komplett umulig å ikke nevne MySQL (uttalt ˌmaɪˌɛsˌkjuːˈɛl) når man snakker om databasesystemer. MySQL er lisensiert som åpen kildekode (GPL-lisens). Det skal sies at det har vært en del diskusjon rundt lisensieringen og Oracle som vedlikeholder MySQL i dag. Dette resulterte i 2009 at kodegrunnlaget til MySQL ble tatt videre til MariaDB i bekymring av at Oracle kjøpte Sun Microsystems som eide MySQL. MySQL er svært utbredt og brukes av veldig mange også store selskaper som Airbnb, Uber, Netflix og Dropbox. Rosabloggen kjører WordPress med nettopp MySQL i bunnen. Personlig så er dette det databasesystemet jeg har mest kunnskaper om utenom Microsoft SQL Server. Hvis man ikke har noen spesielle preferanser til MySQL så anbefaler jeg at man kikker på MariaDB som på mange måter er lik MySQL, men er gratis og garantert å forbli åpen kildekode. Selskap som Google, Wikipedia og WordPress.com bruker MariaDB. Jeg nevnte selskapet Oracle (egentlig heter det Oracle Corporation). Oracle er et gammelt selskap (grunnlagt i 1977) med titusenvis av ansatte. Selskapet er regnet som en kjempe i databasemiljøene med sitt system som har det ikke overraskende navnet Oracle Database eller bare Oracle. Det er lite trolig at man kommer borti Oracle systemer uten at man er del av et større driftsmiljø. Det er også en kjensgjerning at en del firma migrerer til andre systemer pga. kostnadene knyttet til det å ha en Oracle installasjon. Videre må jeg også nevne PostgreSQL. Utvikligen av dette systemet startet på 1980-tallet og er i dag et åpen kildekode-prosjekt, med en svært liberal lisens. Denne gjør at PostgreSQL kan brukes, modifiseres og distribueres av såvel private som kommersielle foretak uten noen som helst økonomisk kompensasjon til de originale utviklerne. Til slutt skal jeg si noen ord om SQLite. SQLite er kanskje verdens mest utbredte databasemotor. Den kjører på de fleste mobiler og datamaskiner. Den er del av utallige apper/applikasjoner som folk bruker hver dag. Vi snakker om hundrevis av milliarder av SQLite databaser i verden. Dette burde være en indikasjon på at kanskje SQLite er en god plass å begynne. Nå er ikke SQLite direkte sammenlignbart med klient/server systemer som MySQL, MarieDB, Oracle, PostgreSQL, Microsoft SQL Server osv. som egentlig skal løse litt andre problemstillinger, men for «hjemmebruk» er SQLite helt genialt. Når man laster ned SQLite fra nettsiden så bør man også laste ned pakken med kommandolinje-verktøy hvis man ikke velger et tredjepartsverktøy som SQLiteStudio. Jeg bruker selv SQLiteStudio og er veldig godt fornøyd med det. Jeg oppfordrer å donere noen kroner til utvikleren hvis man bestemmer seg for å bruke programmet. Noe av det fine med SQLite er at man kan flytte databasen mellom ulike datamaskinarkitekturer. Jeg har f.eks. tatt en SQLite database fra en Raspberry Pi og jobbet med den på en Microsoft Windows PC. Da er det bare å bestemme seg for hvilket teknisk nivå man vil legge seg på og laste ned et databasesystem.

Relasjoner – Normalisering

I innlegget «Relasjoner – Intro» ble ordet «normaliseringsformer» brukt i forbindelse med databasedesign. Teorien og spesielt ordlyden bak normalisering kan fort bli tung og vanskelig å forstå så jeg vil i dette innlegget forklare hva det er gjennom bruk av eksempler. Dessverre så vil der være noen ord og uttrykk vi ikke kommer rundt så det er bare å bite tenna sammen. Vi begynner med noen data i en tabell. Vi kaller den «universalrelasjonen». Universalrelasjonen har ingen spesielle regler utover at man har rader og kolonner. Under har jeg et eksempel på en universalrelasjon. På grunn av plassmangel har jeg brukt en del forkortelser i kolonnene overskriftene. «l_» står for «lege_». «l_navn» blir da «lege_navn». «p_» står for «pasient_» og da er f.eks. «p_navn» det samme som «pasient_navn». Til informasjon så er primærnøkler merket med grønt i kolonneoverskrifta. Universalrelasjonen viser 2 leger som har 3 pasienter og en del annen informasjon.

For å oppfylle 1. normalform (1NF) så kan tabellen ikke inneholde ikke-atomære verdier eller repeterende grupper. Med «ikke-atomære verdier» menes verdier som inneholder flere delverdier. Tabellen inneholder ikke-atomære verdier i feltene «l_adr» og «p_adr» som består av gateadresse, postnr og poststed. Med «repeterende grupper» menes at det finnes mer enn en verdi i krysset mellom rad og kolonne. De repeterende gruppene i tabellen er: «p_personnr», «p_navn», «p_adr» og «p_tlf». Når man deler opp «l_adr» og «p_adr» i sine respektive kolonner («l_adr», «l_postnr», «l_poststed» og «p_adr», «p_postnr», «p_poststed»), og legger den ekstra pasienten i den repeterende gruppa på en egen rad så oppfyller man 1NF. Tabellen under viser hvordan det vil se ut. Legg merke til at «l_id» og «p_personnr» nå er primærnøkkel siden man ikke unikt kan identifisere den riktige raden for en pasient basert på «l_id» alene.

I 2. normalform (2NF) må alle verdier være fullt funksjonelt avhengig av primærnøkkelen. Med «full funksjonell avhengighet» menes at man ikke har noen partielle avhengigheter. Partiell avhengighet betyr at en verdi er avhengig av kun deler av primærnøkkelen (i tabellen over består primærnøkkelen i grønt av «l_id» og «p_personnummer»). «l_navn» er partiell avhengig av «l_id», men ikke «p_personnummer». På samme måte er «p_navn» partiell avhengig av «p_personnummer», men ikke «l_id». For å fikse dette må tabellen splittes i to. Jeg har kalt tabellene «lege» og «pasient». Legg merke til kolonnen «l_id» i tabellen «pasient». Dette er en fremmednøkkel og brukes til å koble pasientene mot riktig lege.

For at en tabell skal kunne være i 3. normalform (3NF) så kan man ikke ha noen transitive avhengigheter. Transitiv avhengighet betyr at en verdi er avhengig av en annen ikke-primærnøkkel-verdi. I de to tabellene over så er «l_poststed» transitivt avhengig av «l_postnr» og «p_poststed» transitivt avhengig av «p_postnr», men verken «l_postnr» eller «p_postnr» er noen primærnøkkel. For å fikse dette så flyttes poststedene ut i en egen tabell (poststed) hvor postnr er primærnøkkelen. Tabellene under oppfyller nå 3NF.

Til slutt skal vi se på Boyce-Codd normalform som også omtales som BCNF eller 3.5NF. For at en tabell skal kunne være i Boyse-Codd normalform, må alle determinanter være kandidatnøkler. En determinant er en attributt eller gruppe attributter som en annen attributt er fullt funksjonelt avhengig av. Et eller flere attributter som sammen identifiserer en entitet unikt kalles en «supernøkkel». Minimalistiske supernøkler, dvs. at man kan fjerne et attributt fra en supernøkkel og så er det fortsatt unikt kalles en kandidatnøkkel. Kandidatnøkler er sikre identifikatorer for en rad, og kan brukes som primærnøkler og som referanser for fremmednøkler. I vår tabell er det ingen brudd på Boyce-Codd normalform. Determinantene er: personnr(pasient), postnr(poststed) og l_id(lege). Kandidatnøklene er: personnr(pasient), postnr(poststed) og l_id(lege). Dersom en tabell er normalisert til 3NF, vil den i de fleste tilfeller også innfri kravene til BCNF. Brudd på BCNF er sjeldne og litt vanskelige å håndtere på en god måte, så derfor stopper man ofte normaliseringen når tabellen er på 3NF. Da har vi vært gjennom den tyngste og viktigste teorien når man skal lage en relasjonsdatabase. Men hvor skal man lage en relasjonsdatabase? Innlegget «Relasjoner – Verktøy» vil kunne gi noen svar på det.

 

Relasjoner – Intro

Som min del av det kollektive ansvaret med å gjøre verden en bedre plass å være så tenkte jeg å slå et slag for relasjonsdatabaser. Jaja, kanskje ikke bedre for de aller fleste andre mennesker, men det kan gjøre hverdagen betydelig bedre for deg selv. Til informasjon så blir ikke dette noe omfattende kurs i databasedesign for det finnes det allerede mye av på nett, skrevet av folk som er langt flinkere enn meg på dette området. Så hva er en relasjonsdatabase? Relasjonsdatabaser bygger på relasjonsmodellen som ble utviklet av Edgar Frank Codd på 1960-tallet og presentert i den banebrytende artikkelen «A Relational Model of Data for Large Shared Data Banks» tidlig på 1970-tallet. Oppsummert så handler relasjonsmodellen om at data er lagret i tabeller eller relasjoner, og det er satt opp regler for hvordan relasjoner kan utformes. I en relasjonsdatabase som følger normaliseringsformene (se innlegget «Relasjoner – Normalisering» for mer informasjon) så bidrar unike identifikatorer til å beskytte dataene, og de sikrer at ingen to rader (eller poster) inneholder de samme dataene i en tabell. Du kan også bruke disse identifikatorene til å relatere poster i en tabell til en eller flere poster i en annen tabell. En relasjonsdatabase kan kreve at nye poster i en tabell har en eksisterende og tilsvarende verdi i en annen tabell. F.eks. så kan man ikke opprette en ny ordre i en ordretabell uten at det finnes en tilsvarende kunde i en kundetabell. Vi snakker om referanseintegritet. Neste innlegg handler om normalisering og det innlegget finner du her.

Velkommen

Jeg går ut i fra at du aldri har vært her før siden du leser dette. Jeg setter selvsagt umåtelig stor pris på at du velger å bruke av din tildelte tid på denne planeten til å lese bloggen min. Når jeg tenker meg om så er det kanskje litt snevert å skrive «planeten». Det kan jo være at en astronaut og/eller en av de andre nautene leser bloggen og de er jo teknisk sett ikke på planeten. Tror jeg endrer teksten til: «Jeg setter selvsagt umåtelig stor pris på at du velger å bruke av din tildelte tid i dette universet til å lese bloggen min.». Vent nå litt! Universet blir kanskje også for snevert for denne bloggen. Hva med alle multiversa!? Hmm… nok om det. Jeg får til stadighet spørsmål om hvorfor en gammal gris som meg har en «rosablogg» gjerne etterfulgt av hånlatter eller mistro. Jo, nå skal jeg fortelle om akkurat det. Man må helt tilbake til 21. januar 2015. Ja, i gamle dager før ungdommen fant ut at ho mor posta festligheter og strikkeoppskrifter på SoMe (sosiale media) og bytta fra Face til Snap og Insta i ei snøkave. Når folk flest posta middag og dobesøk på Facebook så posta jeg gjerne lange avhandlinger om mer eller mindre helt uvesentlige ting, kidnappa tråder, høvla ned skrytemeldinger og en og annen hypokonder. Jeg tvang informasjon på andre i den ene posten etter den andre. Dette genererte selvsagt en del støy blant middag- og lunsjbilde puristene. Det hele kulminerte i det ei ung og matlei kvinne forslo at jeg burde poste mer matoppskrifter på en egen «rosablogg». Selvsagt må jeg ha en «rosablogg», og et par timer senere så var Rosabloggen slik vi kjenner den i dag kreert. Rosabloggen er med andre ord en monologisk kommunikasjonsplattform etablert av allmenne hensyn. Legg merke til ordet «monologisk», for her på bloggen har du nemlig ikke muligheten til å kommentere noe som helst. Enjoy!

This entry was posted on 25. mai 2020, in Blogg.

Fargen er avklart

Etter ikke altfor mange runder med oss selv har vi kommet fram til fargen vi skal ha på hytta. Valget landet på en beis fra Tyrilin. Beisen heter Tyrilin Matt Beis og fargen har det kledelige og ikke overraskende navnet «1206 Svarthatten» med tanke på den faktiske fargen. Tyrilin Matt Beis er spesialutviklet for å gi et vakkert matt utseende, og det var dette som var avgjørende for oss når vi valgte beisen. Vi har vært ganske så samstemte i heimen på at vi ikke skal ha en blank, glinsende farge. Beisen kan benyttes på både behandlede og ubehandlede overflater, og trenger ingen grunning. Påføring er som for annen vanlig beis. Beisen er basert på alkydolje og er forsterket med akryl, og gir panelet et langvarig transparent og helmattutseende. Med andre ord ingen glansrefleksjon og dermed ingen glansforskjeller. Beisen inneholder filmkonserverende midler som motvirker vekst av svertesopp, og er meget luktsvak. Da mangler vi bare hytta.

Pimm´s

Siden det er vår (i alle fall på kalenderen) og sommer snart så tenkte jeg at jeg skulle legge ut en real britisk drink til å ha i solveggen. Jeg kaller den bare «Pimm´s» for den er basert på Pimm´s No. 1 Cup. Pimm´s er en gin-basert likør på 25%. Pimm´s er ikke noe nymotens greier må du tro. Pimm´s ble laget av James Pimm (1798–1866) første gang i 1823. «Pollista» skriver følgende om smaken: «Søtlig drikk med fint preg av sitrus og krydder, bitter ettersmak. Middels fylde.». Der er mange oppskrifter på en Pimm´s men min er som følger. Jeg har ikke noen eksakt oppskrift her, så jeg anbefaler at man prøver seg litt fram med mengden Pimm’s. Jeg bruker en god «dæsj». I en oppskift jeg fant på nett så opererer de med 4 cl Pimm’s og 12 cl sitronbrus, altså et blandingsforhold på 1:3, men man kan godt prøve seg med 1:4 først. Jeg har enda ikke klart å rote dette til for har man for lite så tilsetter man mer Pimm’s og har man for mye så kjører man på med mer sitronbrus.

  1. Mugge med en del is.
  2. Tilsett en «dæsj» Pimm’s.
  3. Skivet agurk (pass på mengden hvis man ikke er glad i agurk for det setter mye mer smak enn man skulle tro)
  4. Skivet jordbær. Ofte brukes appelsinskiver eller gjerne begge deler.
  5. Mynte
  6. Fyll på med sitronbrus (bruker ofte Sprite selv)
  7. Rør om

Pimm´s er sammen med champagne en av de to offisielle drinkene ved Wimbledon. Det selges faktisk 80.000 pints (1 imperial pint (Storbritannia) = 20 UK fluid ounces ≈ 568 milliliter) på Wimbledon hvert år. Hvis noen er skikkelig fine på det så kan man jo prøve seg på en «Pimm’s Royal Cup» hvor man blander Pimm´s og champagne. Skål!

Plata er ferdig støpt!

Endelig bestemte vinteren for å gi seg på fjellet. Vi har flere ganger denne våren hatt problemer med at været rett og slett ikke har vært på vår side. Det har enten regnet for mye eller så har det snødd. Ene gangen arbeidet skulle starte på en mandag bestemte plutselig moderjord seg for å legge ned 30 cm med snø i løpet av helga helt sånn ut av det blå. Vi var ikke trygge på at det skulle gå denne uka heller, men når de som hadde ansvaret for støpinga fjernet all snøen innenfor ringmurene på mandag (18.05.2020) så hadde vi et lite håp. Plata ble meldt ferdig fredag 22.05.2020. Avtalen med hytteleverandøren sier at fra man melder plata ferdig så har firmaet 30 uker på å gjøre den ferdig. For oss så betyr det uke 51. Vi håper selvsagt på at de blir ferdig før den tid. Vi har uansett aldri vært nærmere.

Spektrum data – Python

Jeg pleier ikke legge ut kildekode for de prosjektene jeg lager. Hovedgrunnen til dette er at jeg sjelden skriver kommentarer i koden og programmeringen kan være litt vel røff (les: komplett blottet for exception handling). Denne gangen gjør jeg et lite unntak siden jeg har fått en del spørsmål om hvordan jeg håndterte pakken med spektrum data som FM24-NP100-modulen sender. Her er Python-koden som kjøres på Raspberry Pien. Bruk den på eget ansvar!

This entry was posted on 22. mai 2020, in Blogg and tagged .