Fredrik snackar testning med Adam Sernheim och Emil Rosendahl.

Vilken är Detroitskolan kring TDD, och vilken är Londonskolan?

Varför kan tester få det att kännas svårare att refaktorera sina system? Borde det inte vara tvärt om?

Är enhetstester ett dåligt begrepp vi borde ersätta?

Vad är målet för ens testning?

Behöver man ens spara alla tester?

Tester som designverktyg.

Tester som dokumentation.

Tester garanterar inte att programmet gör vad det ska.

Testprestanda.

Ord betyder saker.

Finns det tillfällen då man inte bör ha tester?

Code coverage kan vara förrädiskt!

Integrationstester - jobbiga mer av organisatoriska än tekniska anledningar?

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik.

Länkar

• Adam
• Diskussionstråden i Slack som gav uppslag till avsnittet
• TDD
• Enhetstester
• Londonskolan (mockist) och Detroitskolan (klassicist)
• Improving your test-driven development in 45 minutes
• Does TDD really lead to good design? och A case for outside-in design - föreläsningar av Sandro Mancuzo
• Jay Rainsberger
• Integration tests are a scam
• Max IV
• Cucumber
• Gary Bernhardt
• Boundaries
• Wat
• Diamant-TDD-stil, del ett och del två
• Hexagonarkitektur
• Testing vs checking
• Rich Hickey
• Clojure
• Simple made easy
• Mutationstester
• Pitest
• Oskar Wickström
• Egenskapsbaserad testning
• Avsnitt 386
• Fuzzing
• Gos fuzzingstöd
• Kontraktstester
• BIST - built-in self-test

Titlar

• Två skolor inom TDD
• Lasten av omskrivningen
• Sjok med systemtester
• Frihet undertill
• Det ska kännas jobbigt
• Bygga in kunskap om problemområdet
• Kärnan i programmet
• Mocka hela världen
• Enkelt och lätt och komplext och svårt
• Man utökar sin cirkel
• Samtidigt som allting rör på sig

Fredrik snackar Log4shell med Johan Boger, IT-säkerhetschef på GleSYS.

Vi inleder ganska naturligt med att diskutera vad Log4shell är, och den klassiska undran hur ett sådant fel kunnat finnas där så länge. Bara för att något använts av många länge är det inte mer säkert.

När kommer TV-serien där hjältarna sitter och läser loggar för att skydda mot dataintrång?

Borde man ändra sitt sätt att jobba som en reaktion på problem som detta? Borde Fredrik läsa mer källkod? Johan är inte övertygad.

Avsnittet sponsras av Länsförsäkringar, som kraftsamlar och investerar för ett digitalt kundmöte i landslagsklass. Surfa in på Lf.se/itjobb för mer information om att jobba på Länsförsäkringar!

Fler rader kod kommer bara att ge oss fler fel i samtiden. Kan det bli trendigt med minimalism i framtiden?

Slutligen diskuterar vi lite att hitta balansen mellan att hantera akuta problem och att kommunicera om dem. Vi kommer även in en del på fördelarna med att säkerhetsproblem får coola namn och stiliga (eller mindre stiliga) loggor.

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik.

Länkar

• Log4shell
• GleSYS
• Johan
• Original-kvittret om Log4shell-problemet
• Original-pull-requesten för att lösa problemet på Github
• Log4shell-varianter på Github (originalet verkar inte finnas kvar)
• Memes om Log4shell
• Log4j
• Graylog
• JNDI - Java naming and directory interface
• Shellshock
• Rensa bort klasser ur Log4j-jarfilen (under sjunde sektionen)
• Versioner av Log4j
• Lunasecs “vaccin” mot Log4j
• Mr Robot
• Fuzzer
• Honggfuzz - Googles fuzzer
• Avsnittet med Snyk - som bygger verktyg för att hitta säkerhetsproblem
• Defcon
• Moxie Marlinspike
• Länsförsäkringar - veckans sponsor
• Lf.se/itjobb - för mer information om att jobba på Länsförsäkringar
• Mikael Nyman
• Unixfilosofin
• Elastics inlägg om Log4shell

Bonuslänk

• Säkerhetspodcasten om Log4shell

Titlar

• Något enkelt
• Det pyr lite i kanten på världen
• Korrekt strängformattering
• Det kommer inte att tolkas som en sträng
• Raka motsatsen till vad man vill ha
• Finess från internets barndom
• Tillverkaren loggar allt jag skriver
• En form av trampolin
• Alla ficklampor på det här området
• Med all välvilja i världen
• Dagsfärsk information
• Samhällsklimat kring säkerhet
• Att få backning av ledningen
• DDOS:ad av tiotusen glödlampor i Borås
• Källkritiska mot källkod
• Foliehatts-Johan på säkerhetsavdelningen

Fredrik snackar vidare med Olle Westergård om assembler, att skaffa sig kompetens kring vad man jobbar med, och om att ersätta system när det behövs. Avsnittet är en direkt fortsättning och avslutning på avsnitt 433 och 438. Det skadar inte att ha lyssnat på dem innan, men det är inte livsnödvändigt.

Alla måste inte vara assemblerexperter. Det tar mellan tre och fem år att bli expert. Och oavsett system måste du ju ha systemkompetens, det spelar ingen roll hur gammalt eller nytt systemet är. Och om du bara köper in kompetensen är det ju inte ditt system. Det kanske passar om det inte är ett kärnsystem och du inte vill kunna vara innovativ.

Olle berättar om andra system han varit med om att lägga ner - varav ett handlade om att flytta från ett tekniskt sett nyare system till ett äldre.

Varför tror folk att det ska vara så mycket bättre att köpa in generella system som försöker lösa mycket fler och större problem än de man själv har, om man istället kan bygga något som passar en, och som man har en massa kunskap om?

Avsnittet sponsras av Länsförsäkringar, som kraftsamlar och investerar för ett digitalt kundmöte i landslagsklass. Surfa in på Lf.se/itjobb för mer information om att jobba på Länsförsäkringar!

En stordator kan undvika många problem - och slippa dela upp system, få kapacitets- och konsistensproblem och en massa annat. Vad måste man göra för att kunna växa?

Folk i omgivningen kan tycka att det är jobbigt att man håller långa perspektiv, ingen vill ha tioårsperspektiv i sin tvåmånaderssprint. Safe och andra agila processer får det inte att gå fortare, och låter en inte ta genvägar heller. Däremot kanske man bli fegare och bara tar sig an saker man är säker på att man kan leverera? Det handlar inte om pessimism, det handlar om att göra ett bra jobb.

Olle förespråkar att fokusera på de svåra problemen - vad är det som faktiskt är svårt i det man ska lösa?

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik.

Länkar

• Olle Westergård
• 433 och 438 - tidigare avsnitt i serien
• Köp oss en kaffe på Ko-fi
• Advent of code
• Vårt repo för Advent of Code på Github
• Vår Slack-kanal
• IMS
• Första sparbanken
• Föreningsbanken
• Tink
• Buy before build
• Mats Törnblom och avsnitt han gästat
• Not invented here
• Konsistens
• MQ - meddelandekö
• Länsförsäkringar - veckans sponsor
• Lf.se/itjobb - för mer information om att jobba på Länsförsäkringar
• Mikael Nyman
• Safe

Titlar

• Så få man vågar riskera
• Sedan går man i pension
• En migrationsresa
• 60-talssystem
• En tillbakagång
• Vi har ju inget system vi ska flytta till
• Det är ju bara att utbilda
• Inte bankens banksystem
• Du kan inte vara innovativ
• När man köper system
• Så länge man pratar med andra mainframes
• Man får inte tappa saker i en bank
• Jag var med och räknade på det
• Vad måste man göra för att kunna växa?
• Vi är inte färdiga
• Fortfarande inte i produktion
• Det handlar inte om pessimism

Fredrik snackar med Tomas och Dennis från Undeco om Youtubes API:er, musiklicenser, och standarder däromkring. Undeco har byggt en tjänst som hjälper till att hantera musiklicenser på Youtube, vilket tvingat dem ner i åtskilliga kaninhål. Till exempel Youtube-API:er med dokumentation som var aktuell 2013, standarder där fält är obligatoriska men inga regler finns för värdena, och mycket mer. Allt inom områden såpass nischade att Stack overflow inte är till någon som helst hjälp.

Mot slutet berättar Tomas och Dennis lite om miljön man valt att utveckla i - vad sägs om PHP ihop med serverless på Amazon lambda? Det funkar bra trots att ingen pratar om det, och läskiga räkningar har inte uppenbarat sig. Det svåra tänket är att sluta förutsätta ett filsystem.

Avsnittet sponsras av Länsförsäkringar, som kraftsamlar och investerar för ett digitalt kundmöte i landslagsklass. Surfa in på Lf.se/itjobb för mer information om att jobba på Länsförsäkringar!

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik.

Länkar

• Tomas
• Dennis
• Undeco
• Stim
• Cora music - licensierar musik till privatpersoner
• Youtubes CMS/Youtube studio
• Content ID - Youtubes grunka som kollar om man innehåller musik under copyright
• ISRC-koder - international standard recording code
• DDEX
• IWK - ICE work key - som STIM använder för att identifiera verk. Fascinerande ogooglingsbart, så länken går till organisationen bakom nyckeln
• Youtubes partner-API - ibland känt som Content ID API, kärt barn har många namn
• SOAP
• Länsförsäkringar - veckans sponsor
• Lf.se/itjobb - för mer information om att jobba på Länsförsäkringar
• Mikael Nyman
• PHP
• Serverless
• Amazon lambda
• S3
• Object keys - S3:s “filnamn”
• PHPspreadsheet
• Laravel
• Jobs i Laravel
• Taylor - som utvecklar Laravel
• Hiphop VM
• Octane - Hiphop för Laravel, typ

Titlar

• Jag bjöd in mig själv
• Den stora frågan
• Är det någon som äger den här låten?
• Musikrättigheter
• Någon har inte angett rätt information någon gång i tiden
• När Youtube försöker vara smarta
• De tänker på allting som att det är fysiskt
• Ett Exceldokument och en mapp
• Du kan glömma att du kan googla det här
• Aktuell ifrån 2013
• Youtubes hörn
• Youtubes källare
• Ungefär tusen
• En MP3-fil med licenser
• Lokalt har vi ju ett filsystem
• En liten monolit
• En serverlös monolit