&w=3840&q=75)
Andreas beskrev ett mystiskt problem han stötte på där han skickade en PUT från front-end med statusen will_be_cancelled, såg att rätt status gick iväg och togs emot på backend, men när objektet sedan sparats och en GET kördes fick han tillbaka statusen active.
Efter lite undersökning kom jag fram till att det var django signals som orsakade problemet, en post save signal på modellen för det objekt jag försökte spara gjorde en koll på ifall objektet skulle räknas som aktivt — alltså icke cancelled — och i så fall sätt status till active. I och med att mitt objekt inte fick status cancelled, utan will_be_cancelled, räknades det som aktivt och fick fel status.
En bra diskussion om signaler vs handlers följde där vi diskuterade för- och nackdelar med att använda signaler, hur man skulle kunna göra koden lättare att förstå och mindre benägen att ge upphov till knepiga fel genom att inte använda signaler, samt vilka use cases som lämpar sig väl för signaler.
Faisal visade upp en REST tjänst som kan ta emot en URL och spotta tillbaka en preview per URL med en titel, beskrivning samt en bild. Tjänsten använder OpenGraph standarden för att parsea sidor som t ex artiklar för att extrahera metadata som kan användas för att skapa en “preview” av en sida när man klistrar in länkar t ex i en feed.
Tjänsten fungerar som en cache proxy så att skrapningen endast sker en gång och man kan med lätthet skapa dessa previews på olika klienter utan att behöva skriva om logiken per klient dvs samma JavaScript snippet kan användas på olika klienter.