Basic personligt

Daniel Brahneborgs blogg

Testning utan droger

För ungefär 15 år sedan hamnade jag för första gången på ett företag som hade en speciell grupp människor som primärt arbetade med att testa den kod som vi programmerare producerade. Efter att ha fixat koden så att de inte längre hittade några fel, rapporterades exakt noll buggar i fält. Det var uppenbart att det inte bara handlade om slump vilket data man testade med, men längre än så kom jag inte. Jag hade länge en misstanke om att det involverade droger.

Till min framtida Master-examen behöver jag ytterligare två kurser (eller 15 hp, mer exakt) i datavetenskap på avancerad nivå, så nu under våren går jag en kurs i just testing hos MDH i Västerås. Några månader med föreläsningar, vetenskapliga artiklar och egna uppgifter har bilden klarnat rejält. Istället för att hela området är en vit yta har jag åtminstone en översiktlig karta nu.

Första pusselbiten är att se utvecklingsprojekt ur tre perspektiv. Först har man omvärldens önskemål på systemet. De formaliseras i en specifikation, som i sin tur implementeras i kod. De tre har en exakt överlappning varje gång som en enhörning och en flygande gris tillsammans får en fertil avkomma.

Nästa pusselbit är synen på program som funktioner som omvandlar indata till utdata. Att skapa testfall handlar då om att hitta bra och minimala subset av det där indatat. T.ex. brukar det vara mer intressant att skicka in -1, 0 och 1 än 2, 3 och 4. Testar man med 2 och 3, behöver man förmodligen inte testa med 4 och 5 också.

Även processen att skapa testfall kan ses som en sådan här funktion. När indatat är kod, består funktionen av verktyg som Valgrind och kompileringsvarningar. De är enkla att använda, och är en bra början. För mig är de också den lägsta nivån som är acceptabel. Program kan ha buggar, men om Valgrind gnäller så är programmet opålitligt. Då får man saker som Heartbleed.

När indatat är omvärldens önskemål blir funktionen att se hur slutanvändarna faktiskt använder systemet, hur blicken rör sig över skärmen, om det finns funktionalitet som fattas, osv. Här börjar det gränsa till psykologi och beteendevetenskap, så det är lite för långt utanför min kompetens.

Min senaste besatthet är istället området däremellan. Om specifikationerna är tillräckligt formaliserade (XML, tillståndsdiagram i UML och liknande), finns det några olika typer av verktyg man kan köra för att få ut serier med testdata. Antingen har man sedan ett annat program som tar det testdatat och matar den riktiga applikationen med, eller så har man det som protokoll för mer manuella tester. Poängen är att man får minimalt med testfall som täcker maximalt med kombinationer av indata.

Antag att man har 10 parametrar som kan vara 0 eller 1. Att testa alla kombinationer av dessa ger 1024 testfall. Med fler parametrar som kan ha fler värden, växer det där antalet snabbt. Istället börjar man med 0 överallt, så blir testfall 2-11 när man ändrar en parameter i taget till 1. På 11 testfall har man då täckt in samtliga värden av samtliga parametrar. Skapar man testfallen manuellt är det ungefär här man hamnar. Dags att levla upp.

Det finns flera verktyg som kan ge en lista med testfall där alla värden på alla parametrar minst en gång kombineras parvis med alla värden på alla andra parametrar. För 3 parametrar får man t.ex. serierna 0-0-0, 0-1-1, 1-0-0, 1-1-1, 0-0-1, och 0-1-0. För 10 parametrar blir det totalt 20 testfall. Det är fler än 11, men enormt mycket färre än 1024. Många buggar behöver bara att 2-3 variabler har en viss kombination av värden för att triggas, så effektiviteten är förvånansvärt hög. Om själva testandet kan automatiseras blir det en utmärkt testsvit att köra efter varje incheckning, varje natt eller vad som nu är lämpligt.

När kursen började sa jag till lärarna att jag ville ha nya mentala verktyg, för att kunna testa program på ett mer strukturerat sätt. Det kan man ju lugnt säga att jag har fått. Kursen pågår två månader till, men av det jag sett av det återstående innehållet är det inget som riktigt slår steget från “det kräver hallucinogena droger” till “testdata kan genereras automatiskt från kravspecifikationer”.

pixelstats trackingpixel

March 16th, 2016 Posted by Daniel Brahneborg | blogg | no comments

There and back again

Att låta ett program hoppa mellan olika programspråk var visst inte så enkelt. Från C kan man öppna filer med kompilerad C-kod och anropa funktioner där utan större problem. Funktionerna där kan använda externa bibliotek, liksom anropa funktioner i det ursprungliga programmet. Av någon konstig anledning verkar folk tyvärr inte gilla det språket, så vi ville erbjuda fler alternativ.

Jag hade kört en del Ruby, och tänkte att det kunde vara ett trevligt språk att erbjuda. Tyvärr fick jag aldrig minneshanteringen att bli rätt där, och när jag nu kollade några år senare så verkar det som om språket fortfarande är helt enkeltrådat, och inte ens fungerar som del av en multitrådad applikation.

Numera fanns även mruby, som klarade trådar. Tyvärr så använde den inte rubys normala “gem”-hantering, vilket gör den ointressant.

Det gick att anropa funktioner i Perl från C, så länge som man lät varje Perl-motor ligga i en egen tråd. Dokumentationen var ganska bra (även om det råder delade meningar om vad SvPOK() faktiskt testar), och minneshanteringen gick att få stabil. Anrop tillbaka till C var däremot en helt annan sak. Hela upplägget där bygger på att C-koden är en del av en Perl-modul, med sina egna byggregler och annat. Varianten att C-koden är en del av programmet som anropade Perl, hittar jag ingen dokumentation för. Antingen skriver man en mod_perl som anropar perl, eller så gör man en mysql-adapter. Inte båda.

Python kändes lockande, med bra api-er åt båda håll, ända tills jag såg listan med minnesläckor. Nej, tack.

För PHP hittar jag bara dokumentation för när PHP anropar C, inte tvärtom. Det lockar inte att sno källkoden till mod_php, även om den gör väldigt nära det vi vill ha. Dessutom framgår inte hur trådsäkert det är.

Det finns en reimplementation av PHP som heter PH7. Där är det enkelt att göra anrop åt båda håll, den är trådsäker, men den verkar inte ha något stöd för externa standardpaket. Allting måste därför finnas antingen i PHP-koden eller i applikationen som anropar den.

Javascript kändes också lockande, speciellt med Googles V8-motor. Den är trådsäker, man kan göra anrop åt båda håll, men så var det ju det där med externa moduler. De enda javascriptmoduler jag hittar är byggda ovanpå node.js. Att köra sådan kod skulle kräva en egen reimplementation av ungefär hela node, eller att vi skrev om hela vår app att också köras inuti node. Inget av det lockar överhuvudtaget.

Python, PH7 och V8 är onekligen en generation senare än de andra. Mycket renare API än Perl, och i V8-fallet dessutom med massor med coola features från de nyare varianterna av C++ (framför allt C++11) för att undvika minnesläckor. Det är irriterande att det verkar vara så svårt att kombinera det här med språkens övriga ekosystem, så som Perl lyckas med.

Är det något språk jag har missat, som faktiskt uppfyller alla krav? Java?

pixelstats trackingpixel

February 12th, 2016 Posted by Daniel Brahneborg | blogg | no comments

Testade Python

Ett klassiskt sätt att låta användarna göra egna tillägg till ett program är att stödja ett eller flera skriptspråk. Istället för att starta en ny process för interpretatorn som kör användarens kod, görs den till en del av huvudprogrammet. Det är så webbservrarna kör perl och php, t.ex. Jag tänkte göra detsamma nu, men för python.

För att vara säker på att mitt program inte har några minnesläckor eller klantar sig på andra sätt, testas varje ny version med Valgrind. Den hittar saker som att man läser värden innan de är skrivna, använder minne efter att det är återlämnat, och massa annat. Jag började nu med ett minimalt program som traditionsenligt bara skrev ut “Hello World”. Valgrind blev synnerligen irriterad, och skrev ut hundratals varningar. Ok, jag kanske hade missat någonting?

Jag testade med den riktiga interpretatorn, och körde samma sak där. Jo då, hundratals varningar även nu, både minne som glömts bort och som försöks återlämnas flera gånger. Det senare felet är allvarligt, för det kan göra att programmet kan krascha helt slumpmässigt. Om man råkar ha någon fil öppen så kan även innehållet där skrivas över. Det är verkligen en “all bets are off”-situation. I Unix-världen är det därför ganska vanligt att man struntar i att lämna tillbaka minne när programmet avslutas, eftersom allt ändå tas om hand av operativsystemet. Det är onödigt att flyttstäda i ett hus som ska rivas. Ändå störde det mig.

Man kan bygga python med en speciell flagga, som gör att den funkar bättre med just Valgrind. Sagt och gjort. Jo då, alla dubbla återlämningar försvann. Tyvärr fick jag då bara ännu fler varningar om bortglömt minne. Att få reda på om den läcker lika mycket oavsett vad man gör, eller om den läcker lite grand varje gång ens program körs, är inte helt lätt att få reda på. Det går säkert, men kräver större kunskap om python-källkoden än vad jag har tid och lust att skaffa mig. Att få överblick på en halv miljon rader C-kod är inte gjort i en handvändning.

Å andra sidan spelar det ingen roll. Att lämna tillbaka minne i rätt ordning är ibland väldigt svårt. Antingen glöms vissa bitar bort, eller så trampar man sig själv på tårna och lämnar tillbaka saker för tidigt. Jag har haft samma problem med min egen kod mer än en gång. Poängen är att anledningen till de problemen, är exakt alltid i samtliga fall att jag inte har haft kontroll på vad koden egentligen gör. Saker körs, men jag vet inte i vilken ordning. I ett sådant läge är det lätt att bara ge upp, eftersom man inte riktigt behöver bry sig. När programmet avslutas, kommer operativsystemet ju ändå städa upp. Om det alltid läcker lika mycket minne oavsett hur länge programmet har körts eller vad det har gjort, är det i praktiken inte ett problem.

Från mitt perspektiv är det ändå inte ok. Om problem med minneshantering kan bero på bristande kontroll, betyder det att mitt förtroende för koden minskar. Om programmerarna har problem här, har de förmodligen problem med andra saker också. Omvänt gäller också. Har man stenkoll på vad koden gör och vilken del av koden som äger vilket minne, är det en kakbit att se till att minnet återlämnas på rätt sätt och i rätt ordning.

Det hela blev ännu sämre av att flera filer måste vara skrivbara när man kompilerar python, eftersom de genereras på vägen. Ändå måste de finnas från början, annars går bygget sönder med en gång. Återigen, brist på kontroll på sakers livscykel.

Så nej, det blir ingen python just nu.

pixelstats trackingpixel

February 8th, 2016 Posted by Daniel Brahneborg | blogg | one comment

Falsifierbarhet

Jag är ett stort fan av konceptet falsifierbarhet. Om det för en naturvetenskaplig modell inte går att designa ett test med ett förutsägbart resultat, så är det helt enkelt inte vetenskap, utan svammel. Om resultaten sedan inte hamnar inom ett tillräckligt snävt intervall, så är modellen felaktig. I Simon Singhs bok om Big Bang beskrevs en modell där experimenten träffade rätt med 6 värdesiffror, så den modellen var förmodligen ganska korrekt. En bra effekt av det här är att området hålls rent. Även om ingenting ju går att bevisa, så är det väldigt mycket som går att motbevisa. Linjen mellan sanning och fantasi blir stegvis allt tydligare.

Frågan som dök upp på Twitter för ett tag sedan var huruvida det finns någon motsvarande mekanism inom humaniora. Jag är övertygad om att någon form av “tryck” behövs även där, för att behålla någon form av kvalitet och undvika total urspårning. Annars blir det ju bara en massa “enligt källa X så Y”, vilket ju inte har något värde överhuvudtaget. Ingen lär sig någonting.

Att försöka använda falsifierbarhet inom humaniora funkar inte speciellt bra, med minimala undantag som “om man byter plats på DE och DEM så är det fler läsare som blir förvirrade och tycker det är svårt att läsa”, men det betyder ju inte nödvändigtvis att all humaniora är svammel. Att tillämpa “vetenskap är att samla fakta” på naturvetenskap funkar inte heller, då går det ju inte att förstå varför homeopati är trams.

Så, vad använder humaniora för gränsdragningsmetod?

pixelstats trackingpixel

January 27th, 2016 Posted by Daniel Brahneborg | blogg | no comments

Magisterexamen

(Borde kanske ha publicerat det här inlägget för typ ett halvår sedan…)

För att få tillräckligt med poäng till min magisterexamen, tog jag under förra våren en kurs i PHP på bth.se. Det var lämpligt att sikta på några tämligen säkra poäng, eftersom det inte kändes acceptabelt att förlora examen på grund av en missad kurs i det här läget. Jag sökte flera kurser för säkerhets skull, vilket slutade med att jag även läste en grundkurs i affärsredovisning.

PHP-kursen var relativt smärtfri. Jag hade kodat en del i det under hösten innan, så grunderna hade jag redan. Däremot var det kul att få en mer heltäckande genomgång, prova fler api’er, osv. På sista uppgiften fick jag en kommentar om att “lite mer ansträngning hade kunnat lagts på layouten”. Hallå, ser jag ut som en designer kanske? Multicolor lorem ipsum på dig själv, liksom. Sammantaget fick jag betyg B, på en skala A-F. Alternativt VG, på den mer normala VG/G/U-skalan. Även om det kanske hade varit kul att få ett A, hade det krävt mer tid än vad jag tyckte var motiverat.

Ekonomikursen var klart värre. Jag lusläste varenda rad i boken flera gånger om, gjorde alla övningar, och skickade ganska många mail till läraren med funderingar. En och annan frustration nådde både Facebook och Twitter. Till slut började saker få ett sammanhang, så på inlämningsuppgifterna fick mina grupper alltid kommentaren “mycket bra”. Tentan kändes bra, och sedan kom resultatet: 16 poäng av 20, dvs VG där också.

Exjobbet som helhet var nog något av de roligaste projekt jag har gjort. Den prestandaförbättring som jag såg i början försvann när jag hade rättat buggarna, men i vilket fall som helst lärde jag mig massor om multitrådning. Jag fick svar på de frågor jag hade haft som utgångspunkt, men upptäckte även en massa aspekter som jag inte hade tänkt på innan. Jag visste av erfarenhet att det skulle hända, men att veta att något oförutsett kommer dyka upp, och att se vad det där oförutsedda faktiskt består av, är ju två helt olika saker. Vi hade en lång dialog under månaderna som gick, jag och koden. Jag påstod och frågade saker, och fick svar och ibland missnöjda muttranden tillbaka. Vissa lösningar blev å andra sidan riktigt snygga, varpå koden glatt tackade mig och tuggade på lite snabbare.

Den magisterexamen som var mitt mål hade en hård deadline på sista juni, så sista veckorna var lite stressande medan jag väntade på att godkännandena skulle trilla in. Från handläggaren i Umeå fick jag veta att det räcker att en av kurserna (PHP eller ekonomi) rapporteras in med ett godkännandedatum senast sista juni. Om det skulle dröja in i juli innan Ladok blev helt uppdaterad hade inte gjort någonting, eller om själva examensbeviset inte hade hunnat skickas iväg innan dess. Eftersom kurserna var godkända den 17:e respektive 26:e juni, var jag hemma. Sedan var det bara att vänta medan databaserna synkade ihop sig.

Att få VG på båda kurserna med 0 poängs marginal och allt klart för en examen med knappt två veckors marginal efter 20 års velande, är kanske lite väl mycket “marginaler är för fegisar” även för min smak. Däremot känner jag mig lite nöjd med att exjobbet, som alltså skulle räcka i ungefär 20 veckor gånger 40 timmar, blev klart på ungefär en tredjedel av det.

När jag ändå hade några poäng för mycket, tänkte jag att det var lika bra att fortsätta plugga. Annars gör ju de där överblivna poängen ingen nytta. I somras läste jag därför Androidprogrammering, i höstas evolutionsbiologi, och framöver tänkte jag fylla på med fler kurser inom datavetenskap och annat för att förr eller senare komma upp på en masterexamen (dvs 2 år efter kandidat, totalt 5 år, till skillnad från den 4-åriga magister som jag får nu).

pixelstats trackingpixel

January 17th, 2016 Posted by Daniel Brahneborg | blogg | no comments

Embedded perl vs php

För några år sedan lade jag till möjligheten att köra pluginer skrivna i perl, i en av våra produkter (tänk “mod_perl”, typ). På det sättet kan kunderna skriva sina egna filter och annat, utan att behöva kladda ner grundprodukten med funktioner som bara en enstaka kund använder. Implementationen blev ganska rakt på sak: Läs in perlscriptet i början av programmet, kolla vilka funktioner som är implementerade, och via diverse magiska anrop kopiera visst data till perl-strukturer, och anropa perl-koden. Med ytterligare magi plockas data tillbaka från perl-världen till C. Kunder kan skriva egen kod, ingenting behöver kompileras, och det går tämligen snabbt. Alla har varit glada.

Sedan hittade vi en motor för embedded php. Tyvärr kunde den bara köra hela filer och inte enstaka funktioner, men det löstes genom att helt enkelt låta varje funktion ligga i en separat fil. För att komma åt datat från C-världen visade det sig vara enklast att registrera en callback. När php-koden anropar funktion X, så anropas funktion Y i C-världen. Den gör det den ska, och så återvänder man till php-världen. Data kunde skickas i båda riktningar, så vi kunde få både get-funktioner och set-funktioner. Det hela fungerade klockrent, och benchmarking visade att det gick snabbare än perl. För perl-pluginer byggde man nämligen ihop allt data i förväg, medan man för php bara gjorde det vid behov.

Den uppenbara tanken blev ju då att försöka göra samma sak för perl. Hej “perl xs“. Hahaha. Nej, det blir ingen perl xs. Visst, det är svårt att hoppa mellan C och scriptspråk med garbage collection, men det finns gränser för vad jag vill utsätta mig för.

pixelstats trackingpixel

January 11th, 2016 Posted by Daniel Brahneborg | blogg | no comments

Barnlös med syskonbarn?

Höstens kurs i evolutionsbiologi ger fortfarande nya insikter och frågeställningar. Idag började jag fundera lite mer på barnlöshet.

Bakgrund: För några decennier sedan så bytte evolutionsbiologerna perspektiv. Från att det var individer som förde gener vidare, gjorde man en 180-graderssväng och började se det som att det var gener som replikerade sig själva. Denna replikering består av en lång kedja med instruktioner för att först bygga ihop en individ, därefter få individen att å ena sidan överleva själv och å andra sidan visa sig lämplig som förälder för individer av det andra könet, för att slutligen se till att det uppstår en eller flera avkommor. Viss energi läggs också på att se till att andra individer överlever, vilket är den huvudsakliga payoffen för homosexualitet (de konkurrerar inte med heterosexuella om att få para sig, men kan ta hand om föräldralösa barn när dessas föräldrar dör).

Här finns en intressant grej. Gener vill att de själva ska få replikeras. Gener som inte vill replikeras dör ju av uppenbara skäl ut (duh). Dessutom finns mekanismer som gör att de helst stödjer andra individer som är så lika dem själva som möjligt. Ju mer lika individerna är, desto mer lika är deras gener. Individer hjälper varandra, men mer ju närmare släkt och mer lika de är.

Frågan som slog mig var hur syskonbarn påverkar individernas drift att föröka sig. Förekomsten av egna barn påverkar föräldrarnas hormoner och därmed hur de värderar saker i omgivningen, vem de vill para sig med, om de vill få fler barn alls, osv. Det borde då inte vara orimligt att anta att även syskonbarn och till viss del kusinbarn har en liknande, fast självklart svagare, effekt. För egen del har jag syskonbarn på ena förälderns sida och kusinbarn på den andres, så de flesta av “mina” gener har redan replikerat sig. Begäret att skaffa egna barn är lågt (förvisso har det aldrig varit speciellt högt).

Samma mönster ser jag hos allt fler. Personer som är enda barnet, skaffar egna barn. Ju fler syskon som har barn, desto större verkar sannolikheten vara att något annat syskon är frivilligt barnlös. Resurserna som skulle krävas för att skaffa egna barn, läggs istället på att hjälpa syskonen, ens “by” eller arten som helhet.

Är det någon som har undersökt det här mer i detalj? Pluralformen av “anekdot” är ju inte “data”, som sagt. Samtidigt finns ju massa kulturella faktorer här som ställer till det, men det kanske går att kompensera bort.

pixelstats trackingpixel

January 10th, 2016 Posted by Daniel Brahneborg | blogg | no comments

Plex

Att kunna ladda ner film och tv-serier från internet är kul. Att se dem på en liten datormonitor, not so much. För ganska många år sedan var lösningen att koppla två sladdar, en för bild och en för ljud, mellan datorn och tv’n. Det är ok med en stationär dator, men har man en laptop eller vill komma åt sambons filer, blir det en massa trasslande med sladdar fram och tillbaka.

Nästa steg blev då att lagra filerna på en Linux-server, så slapp man frågan om vem som hade laddat ned vad. Med en liten mediaspelare typ WDTV, eller Apple TV om man är på det humöret, blev även ens vanliga dator fri. Numera pratar allting HDMI, så det bara behövs en sladd istället för två. Det funkade bra ganska länge, tills WDTV’n inte bara tappade kontakten till servern då och då, utan även totalhängde sig ibland så det enda som hjälpte var en full powercycle. Exemplar nummer två betedde sig likadant. En Apple TV löser ungefär samma problem, men hanterar färre filformat. Det är osäkert hur stor roll det spelar i praktiken.

Linux-servern hade nu blivit utbytt mot en Synology DS414 (“4” = 4 diskar, “14” = modellen kom 2014), vilket gjorde att saker flöt på bättre. Att konfigurera upp en Sambaserver i Linux var visst inte så enkelt.

Vi tröttnade till slut på WDTV’n och dess hängningar och lät en hallonpaj få bli tv-dator. Synologyn fick server-delen av Plex, och hallonpajen körde klienten. Med en liten flirc-plopp som låtsas vara ett usb-tangentbord gick det att fortsätta använda WDTV’ns fjärrkontroll. Plex tar över hela hallonpajen, så för att kunna fortsätta ha en att leka med köpte jag en till, och satte båda i ett fint chassi (förevigad hos Instagram).

Hallonpajer vill ha 2A, och efter att ha jagat runt lägenheten efter tillräckligt bra USB-adaptrar gav jag upp och köpte en grej med 6 portar från r-pi.se. Egentligen borde jag köpa en till för att ha med på semestrar.

Öppnar man uPNP i sin router kommer man åt filerna i Plex även utifrån. Det finns klienter för mobiler och surfplattor (om man har betalkonto), så man kan strömma musik till sin telefon eller vad man nu vill göra. Plex vill ha en primär användare, och sedan kan man lägga till fler personer i samma hushåll som kan ha sina egna inställningar. Dessutom kan man lägga till gästkonton, om man vill dela med sig filer till andra. En kul grej var autentiseringen mot servern. Istället för att behöva skriva in ens lösenord, som för tv-appar är ganska bökigt, visar klienten en kod som man skriver in på webinterfacet mot servern. Mycket smidigt.

För att inte behöva skicka onödigt mycket data över nätet kan Plex-servern koda om filerna i realtid beroende på vad det är för klient. Det var dock lite jobbigare än vad DS414 klarade av, och eftersom den dessutom började bli full byttes den ut mot en större och snabbare DS1815 (2015 års modell, 8 diskar internt plus 2 gånger 5 = 10 diskar i separata expansionslådor). Som bonus kan den även fungera som TimeMachine-server, så vi kan få våra datorer backupade utan att böka med glappande USB-kontakter. Det finns NAS-servrar från andra tillverkare som också kan köra Plex, men alla som har en åsikt i frågan verkar vara överens om att Synology är bäst.

Jag hade hoppats att 8 TB-diskar skulle hinna komma tills det var dags att shoppa, men sådan tur hade jag inte. Seagate har en “Archive”-variant, men de verkar vara allmänt värdelösa. Undvik dem. Istället blev det 4 diskar på 6 TB, som i Raid 6 (dvs checksummor på två diskar) ger ungefär 11 TB. Sedan är det bara att lägga till en eller två diskar i taget, så bygger Synologyn om raiden utan att ens behöva gå offline. Med hotswap dessutom. Det är fortfarande bara 2 diskar som används för checksumma, så man får 100% utväxling på de nya diskarna. Lagom till att vi har fyllt 33 TB vill man nog uppgradera NAS-burken ändå, så kan man börja om med nya diskar där. Det hade gått att behålla de tidigare diskarna och bara köpa fler till den nya servern, men då hade vi slagit i taket ganska snart igen. Dessutom kan den gamla servern nu få fortsatt liv på annan adress.

Lagom till att jag konstaterade att jag inte hade något mer att byta ut just på den här fronten dök Pine 64 upp. För halva priset av en hallonpaj får man där högre fart och 4K-video istället för “bara” 1080p, dessutom med lägre strömförbrukning. Förhoppningsvis i alla fall, den ligger nu på Kickstarter med beräknad leverans några månader framåt i tiden. Inte för att det finns någon tv i hushållet som klarar mer än 1080p, men ändå. Principen.

pixelstats trackingpixel

December 12th, 2015 Posted by Daniel Brahneborg | blogg | no comments

Rostfri stekpanna for the win

Jag har under lite för många år gått och suktat efter en Demeyere-stekpanna. Dels eftersom de ser så udda ut, och dels eftersom de ju på grund av sitt tämligen höga pris ju måste vara extremt bra. Av det jag har kunnat läsa om den sortens stekpannor så är de allmänt svåra att hantera, funkar bara för vissa saker, och en massa andra saker som gjorde att det inte längre kändes så lockande. För relativt länge sedan (i höstas?) hittade jag en rostfri stekpanna från Nordiq, som redan från början hade en helt annan prislapp, och då dessutom fanns till extrapris. Ändå har jag inte riktigt vågat använda den, mer än att ge (förvisso en fantastisk) stekyta åt en köttbit då och då. I med köttet, vänta lite, peta då och då jätteförsiktigt tills det helt har lossnat från pannan, vänd, repeat, klar. Bara den stekytan har nästan varit värd prislappen.

Så råkade jag snubbla förbi Anders Johanssons blogginlägg om en sådan där Demeyere-stekpanna, och bestämde mig för att testa lite mer. Blodpudding har tenderat att fastna i de flesta stekpannor jag har haft, förutom när de var helt nya. Även en hyfsat ny titanpanna blir lite upprörd. Nordiq-pannan bara flinade. Noll fastbränt. Lök plus korvbitar plus äggröra, inte heller några problem. Dessutom blir äggröran mjuk och fluffig på ett sätt jag inte varit med om förut. Efter alla år med stekpannor med beläggningar av titan och/eller keramik så känns det jättekonstigt att steka på en sådant här material, men det gick snabbt över. Rolig leksak.

När jag matade på ett dussin omgångar med både högrev, bacon och diverse annat till en chili, blev det förvisso massa skräp i botten. Å andra sidan var det bara att röra försiktigt med en diskborste under varmt vatten och avsluta med en vända Fix Universal, så blev den blank och fin igen. Även korv med ost i blir den sur på, något som titanpannan klarar utan större problem.

Det jag också har reagerat på är att den är vansinnigt långsam. Det tar femtioelva evigheter innan den blir varm och smöret har bubblat klart. Men, det betyder också att den är lika långsam åt andra hållet. Andra stekpannor kallnar märkbart när man fyller dem lite för mycket, och så står allting och kokar och blir tråkigt. Icke den här, den bara fräser på med ett “you silly human” och låtsas som ingenting.

Behovet av en Demeyere har därmed försvunnit, åtminstone tills den här dör. Om den nu alls gör det, vilket verkar tveksamt. Attans? Buhu?

pixelstats trackingpixel

September 13th, 2015 Posted by Daniel Brahneborg | blogg | no comments

Boken “Det sötaste vi har” av Ann Fernholm

Efter att ha vunnit Ann Fernholms bok “Det sötaste vi har” som en av Kostfondens månadsgivare, läste jag idag äntligen klart den. Jag konstaterar att nej, den här boken behöver man nog inte läsa.

Eller ja, förmodligen vill du läsa den om du har barn, för att få veta hur socker och olika typer av spannmål påverkar barnens tarmar, tänder, hormonnivåer och risker för övervikt, diabetes, cancer, ALS och andra problem. Kanske också om du är gravid, eftersom mammans matvanor har en stor effekt på barnets framtida hormoner, allergier och immunförsvar och annat.

Personer som själva vet med sig att de äter för mycket socker, är rejält överviktiga, och börjar känna av artros och galopperande synfel kanske också vill ta en titt i boken för att få lite bakgrund till hur de där sakerna hänger ihop.

Eller så tror du att fett i allmänhet och mättat fett i synnerhet, liksom kolesterol, är farligt, och är istället noga med att få i dig de där “nyttiga” fibrerna. Då har du fel, för att citera Hans Rosling.

Personer som jobbar på Livsmedelsverket bör oavsett ovanstående inte läsa den, för deras egna mentala hälsa. Det skulle inte vara så kul att få veta hur många saker man har haft fel om, exakt varför man har haft fel, och hur många personer, både vuxna och barn, som man har gett onödigt lidande och kanske till och med död. Jag skulle aldrig klara av en sådan smäll i alla fall.

Jag vill också utfärda en varning angående de första kapitlen om några experiment som gjordes för att ta reda på vad socker egentligen hade för effekt. Se till att ha många tuber tandkräm hemma, det kommer behövas.

Bokens referenslista på slutet är nästan 50 sidor lång, så det är inget flummigt eget fantiserande direkt. Dessutom görs det tydlig skillnad på vad som gäller för att förebygga problem, och vad som behövs för att hantera sjukdomar och symptom när de väl uppstår. Samma tydlighet finns för olika sorters kolhydrater.

pixelstats trackingpixel

September 6th, 2015 Posted by Daniel Brahneborg | blogg | no comments

« Äldre | Nyare »