44. Nyårsquiz
lyssna!
Vi rundar av året med att ställa varandra frågor inom diverse kategorier från hemsidan 30 Seconds of Interviews. Det blir allt från CSS selektorer, portaler, Ordo, stenhögsspråk, livscykelmetoder och higher order components.
Mest av allt vill vi tacka alla som lyssnat, kommenterat, frågat och stöttat. Utan er vore vi ingenting. Vi ses igen 2022!
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Avsnittets skämt:
Varför måste utvecklare ha självdistans?
Standup varje morgon.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att
klicka precis här :)
Varför måste utvecklare ha självdistans?
Det här kändes som att jag skulle kunna klura ut, men jag vet inte.
Stand up varje morgon?
Den går vi vidare snabbt ifrån, känner jag.
Vad sa vi nu då? Välkomna till ASTFs nyårskarameller.
[Skratt]
Kanske inte riktigt.
Vi satt och funderade på vad vi skulle prata om och insåg att vi hade någon gång långt tillbaka i tiden pratat om att vi skulle ställa varandra frågor från 30secondsofinterviews.org
Som är någon hemsida där de har samlat, alltså de ska väl föreställa intervjufrågor inom lite olika programmeringsrelaterade ämnen.
Så vi tänker väl att vi kör på den och så får vi se hur det går.
Vi har sagt att vi ska sortera på de svåraste först och så hoppas vi att det funkar bra.
Jag tänker också att det här, det är nu vi kommer bestämma om, som vi i förra avsnittet pratade om senior vs junior.
Det är nu vi bestämmer vilken vi hamnar på.
[Skratt]
– Då vill jag ha easy och vara på juniörssidan.
– Okej, så på den här hemsidan så kan man välja kategori och så kan man sortera.
Vilken kategori vill du ha? Det finns HTML, CSS, JavaScript, React, Node och Security.
Oj, ska man välja någonting man absolut inte kan eller ska man välja någonting som man hoppas att man kan?
Vi kan göra så här då, du får välja till mig så väljer jag till dig.
Jag kommer välja samma sak.
Nej, det tror jag inte. Du får välja till mig först då, så väljer jag inte annat än dig.
Nej, men välj till mig först.
Nej, du får välja först nu.
Varför ska jag välja först?
För att jag bestämde det.
Ja, jag väljer CSS.
Till mig?
Till dig.
Okej, då kan du få React då.
Fan.
Jag höll på att säga att de här svåra frågorna såg inte så svåra ut.
Men jag ska inte säga något innan jag börjar.
Junior direkt.
Okej, vill du börja eller ska jag börja?
Börja med vad då?
Ställa frågan tänkte jag, men jag inser att det var lite oklart där.
Okej, jag kan börja med att ställa frågan.
What is the difference between PLUS and TILDE sibling selectors?
Okej, nu ska vi se. Jag kanske tar tillbaka det här lite grann med att det var inte så svårt.
Vi kan också börja med att säga att jag är ganska säker på att jag inte kommer...
Jag kommer tycka att många av de här frågorna är ganska dåliga intervjufrågor.
Har jag en känsla av.
Men med det sagt så tror jag att skillnaden är att den ena tar...
Alltså, den ena tar bara direkta syskon, alltså om de ligger bredvid varandra.
Och den andra tar om de är syskon överhuvudtaget, även om det är saker emellan.
Vilken som är vilken är en jävligt bra fråga.
Kanske att plus är den som är direkta.
Om jag fissar. Tillde är allt.
- Alltså Tillde...
Ska jag svara här nu? - Ja, nu kör vi. Jag vill ha ett facit.
- Jag är inte ens säker på att jag förstår svaret.
Men Tillde väljer alla element som är som är syskon till det specificerade elementet.
Som jag har divit tillde P.
Då kommer den välja alla P som är syskon till diven.
- Ja, men det var väl typ vad jag sa.
- Fast tvärtom på dem.
- Ja, det kanske det var. - Eller vad landade vi?
- Jag kommer inte ihåg.
- Och plus tar alla element som är...
...närliggande syskon till det specificerade elementet.
- Jag tror fan jag hade rätt. Jag tror till och med jag sa rätt.
- Jag ska träna på det här till nästa fråga, men jag tror att jag kanske försökte läsa svaret
Samtidigt så hade jag liksom missat det.
Ja, men det är lätt hänt.
I vilket fall, jag tror att jag hade rätt.
Det här är självsäkerheten som talar.
Jag tror att jag hade rätt.
Absolut, du får poäng.
Ja, vad bra.
Vi ska definitivt räkna poäng i det här också.
Okej, vi ska se.
Jag ska hitta någon roligare fråga än de här som var högst upp här.
Vad ska du, ska du inte gå i turordning?
Nej, det är skitviktigt.
-Va? -Jag måste välja ut lite grann så det blir bra content.
Okej, "What are portals in React?"
-Oj, det vet inte jag. Är det inte någonting som är väldigt använt i det här med React Native?
-Vet ej, kan inte React Native faktiskt.
- Ja, precis. - React Portal. Vad är Portal? Jag har ingen aning.
Jag tänker bara på sådär "möjlighet" en portal är, att du kan flytta ett specifikt element till ett annat ställe.
- Ja, det var det vi närmast nått. Det finns en API där "react-dom.createportal" och sen tar den emot en "child" och en "container".
Ja, precis. Men att barnet ska visas i en annan container än där man lägger in den.
Så är det.
Det är exakt vad du säger.
Att man ska kunna...
Du kanske har en modal eller något.
Och säg att du har en modal-knapp som också renderar
där du kanske vill hantera själva modal-elementet även i samma komponent.
Men du vill i verkligheten rendera den i body, fast den inte ska ligga nästa i trädet.
Då kan du skapa en portal där du renderar din child i body eller root, eller vad du vill kalla den.
Så det var helt rätt.
– Typ. – Ja, men det var ju samma sak.
– Jag vill inte ha poäng. – Jo, du får poäng.
Jag ska välja roliga frågor, men nej, vad jobbigt.
Ta vilken fråga som helst.
"Can you describe how CSS specificity works?"
Det här känns som en fråga som man kan blaja lite.
Får man det på en intervju så kan man ändå så här...
Jag tror jag klarar mig, men jag kanske inte kan det enligt specen.
Men det är väl att varje selektor har typ en poäng på sig.
Så om man tar ett klassnamn och sen kör man "tilde" och sen kör man "div"
Då kanske den har en poäng av 3, för det är tre olika saker
Och då är det dess specificitet, vilket är ett jävligt svårt ord att säga
Och sen kanske en annan har klassnamn "tilde"
"Klassnamn"
Eller något
Och då kanske den har specificitet på fyra för att klassnamn är värt två.
Men det går inte riktigt ihop nu när jag säger det här.
Men det är att vissa olika selektorer har olika värden och då blir specificiteten högre.
Vilket gör att den skriver över den första selektorn.
Typ så.
– Ja, men alltså attributet ju mer specifikt riktat till ett element det är, desto mer tar det över.
– Ja, det var den väldigt korta förklaringen. Jag gillar den mer.
[Skratt]
[Skratt]
Ja, men...
Absolut. Poäng.
Jag tycker den var bra.
Men sen finns det väl massa sådana här
regler runt omkring, tror jag, som man var inne på.
Typ så här, ja men en klass är ju mer specifik
än ett elementselektor.
Och en
id-selektor är mer specifik än en
klassselektor, till exempel. Och massa grejer.
Ja, du har så här, inline rules,
number of id-selectors,
"Number of class, pseudo class and attribute selectors, number of tags and pseudo element selectors."
Just det.
Och då har du "Specificity matrix, inline ID, class, pseudo class, attribute, tag, pseudo element."
Så det var i den ordningen jag läste upp dem.
"In cases of equal specificity, last rule is applied."
Så det blev nog någon cascading då.
Ja, men just det. Ja, men det är ju varandra jag är nöjd ändå. Jag hade hyfsat koll.
Jag har en annan fråga. En lite "blast from the past" nästan inför tiden.
Också "intermediate" ska sägas, inte "hard".
"What are the lifecycle methods in React?"
Component will mount, component did mount, component will unmount.
Component did update.
Ja, jag har tagit fyra.
Det finns sju totalt.
Finns det sju då?
Jag hade inte heller tagit alla.
- "Component will receive props." - Den har väl bytt namn nu va?
- "Component did receive props." - Nej, den heter "Get derived state from props" nu för tiden.
- Just det. - Två till finns det.
- Jag trodde det var sju när det var "way back". Det fanns sju, men de var nya.
Det är någonting "Will receive state" också.
Ja, det kanske är...
"Get the right state from props".
Ja, det var den du pratade om nyss.
Jaha, ej då.
Minnet är så jävla kort.
För det första har du inte skrivit en ny life cycle-grej på länge, för du sitter ju ändå i ett modernt React-projekt, eller hur?
Så är det.
Så det är inte så lätt att komma ihåg. Och jag tror inte jag hade heller kunnat rabbla dem.
men de du missade var bara Shudd Component Update och Get Snapshot Before Update.
Get Snapshot Before Update vet jag inte om jag har använt en enda gång i mitt liv.
Nej, samma. Men Shudd Update borde jag väl tagit?
Jag tror jag hade tagit färre än vad du tog faktiskt.
Det var en resa.
Ja, precis. Det var de.
Bara för att rabbla de här sista gångerna.
"Get derived straight from props. Component did mount. Should component update. Get snapshot before update. Component did update. Component will unmount."
Ja, just det. Det var en till också. "Component did catch."
Ja, men det är ju Error Boundary.
Det är Error Boundaries.
Just det, men det var ju någonting där också för att det var de gamla liksom och sen gjorde man om
de här och det var ändå ganska kort tag innan Hux kom.
Ja, ja men verkligen.
Så att helt klart poäng.
Nej.
[Skratt]
Okej, Hit Me.
Jag vet inte varför jag tog CSS.
Du kan få byta ämnen om du vill. Det finns ju någon javascript.
Det var så långa förklaringar.
Det orkar vi inte med.
Då tar jag javascript då.
Det här kommer att vara svårt känner jag.
Vad är Big O notation?
Är det inte javascript?
Jag har ändå pluggat Big O en gång i tiden.
Så det borde kunna det här.
Men det är ju ordo i alla fall.
Det har väl att göra med att man räknar ut komplexiteten på olika algoritmer
Så att typ en O1, oavsett input, tar det lika lång tid att köra den algoritmen
Och sen finns det typ O1, och då är det en 1 till 1-relation mellan input och hur lång tid den tar att köra
Och sen finns det typ OlogN och massa såna här grejer som gör att ju större input så ökar tiden att köra exponentiellt.
Typ.
- Ja, nice.
- Ja, det här kommer jag ihåg från universitetstiden för en fan. Det är typ sju år sedan nu eller något. Det är fan sinnessjukt.
- Ja, jag vill dock säga att det är inte OlogN, det är ONlogN.
Fan! Ingen poäng till mig.
Sen har vi också Ardo Array 1 till 1.
Det är att det kan variera.
Ardo 1 uppöjt till 2.
Och Ardo 1 utropstecken.
"The execution time rises extremely fast with even just one addition to the array."
Ja, den kanske man ska undvika då.
Ja, där kom jag också, men jag tror att jag lärde mig Ordo 1.
Att det var fint, och sen gick jag vidare i livet.
Jag minns inte om det var på den här kursen, eller om det var en annan kurs, så hade vi en professor i Uppsala som...
Eller han kanske inte var professor, vi hade inte hann med det, men i alla fall, den hette Algoritmisk Datastrukturer.
och då pratade vi om stenhögar.
Så det var allt som fanns.
Det fanns bara tre saker man kunde göra.
Man kunde lägga till en sten i en hög.
Man kunde flytta en sten till en ny hög.
Och man kunde göra nånting mer.
Hela kursboken var bara stenhögspråket som man sen byggde på.
Så här i efterhand kändes det som att det var ett ganska vettigt sätt att prata om det.
Men där och då var man så jävla förvirrad varför vi pratade om stenhögar.
Jag skulle ändå vilja gå tillbaka till och läsa lite av de här grejerna som jag förstod absolut noll av när det skedde.
Och se nu hur pedagogiskt det hade känts att lära mig det nu. Eller läsa det.
Ja, nämen verkligen. Jag tror också att det hade varit rätt kul faktiskt.
Okej, vill du ha en till fråga?
Ja, antar det.
Ska vi ta den här då? Ja, den här känns bra.
"What are higher-order components?"
"Higher-order components" är komponenter som tar in komponenter,
returnerar en kombinerad komponent.
Det var nästan ord för ord första meningen på förtalingar faktiskt.
[Skratt]
Det känns också som att det inte är en sån här grej som inte är lika populärt längre sen Hoogs kom.
Nej, det var väl en jävla sväng med det där med massa Redux va?
Ja, Redux gjorde det väl skitpopulärt även fast folk ofta inte vet kanske.
Jag tror att många som använder Redux inte fattade vad...
Om man skulle fråga folk som använder Redux så vet kanske inte vad Higher-Order-Components är ändå.
Man pratade inte om det på samma sätt.
Men typ Connect-funktionen till exempel är ju en higher order component.
Får jag för mig? Eller om jag glömde bort något, den returnerade en komponent. Men ni gör det väl?
- Jag kommer inte ihåg, men det är väl här Maps, Date to Props också.
- Ja, just det. Connect returnerar väl en higher order component? Får jag för mig nu?
För man kör ju så här Connect och så skickar man in någonting i den och sen anropar man en funktion på den.
Så det blir två parenteser på rad, vilket var jävligt förvirrande i början.
Jag kan inte påstå att jag saknar higher-order-components dagligen i mitt liv.
Nej, det kan jag verkligen hålla med om.
Men det kom väl in också som ett sätt att dela kod när man inte använder mixins.
Ja, precis. Det var väl ett bättre alternativ än mixins och därför blev det populärt.
Typ så.
Men ja, nu har vi hux.
Nu har vi hux. Det är en dröm.
Okej, kör en till fråga på mig.
Det här tyckte jag var kul.
Kul nyår hörru.
Toppen.
Jaha, det här kändes som en så öppen fråga.
Men du kan få shine.
Vad vet jag?
How can you avoid callback health?
Det var en lite näppig fråga.
Det känns som att det finns jättemånga sätt att göra det på.
Men typ att använda Promises istället.
Är mitt svar.
Och sänka weight på det.
Det var precis det.
Jag tänkte inte att det var så lätt.
Det tror jag är mitt svar.
Att istället för att du har massa koll på verksamheten.
Det var också en grej som har gått ur i tiden.
Jag minns när man skrev Angular 1, alltså innan Angular 2.
Då var det väldigt mycket callbacks.
Allt var callbacks.
Så det kunde bli enorma pyramider om man tittade åt sidan i koden.
Det var inte supernärligt.
Inte heller något jag saknar.
Absolut saknar inte, men känns ändå lite skärmigt att ha gjort.
Ja, det är ju så här, vad är det, survival bias? Nej, det kanske är något helt annat. Men liksom vi överlevde och då var det nice.
Nej, det var inte nice, jag säger bara att det är gjort. Jag förstår varför det är nice att det inte är så.
Ja, men vi tappade många på vägen så att säga.
Men det finns många sätt att lösa problemet med "callback-health".
Dels "promises" speciellt med Async/Await-syntaxen.
Det är så himla "cleant".
Och sen "modularization" - "break callbacks into independent functions".
"Use a control flow library like Async".
"Use generators with promises".
Man säger som om man använder generators.
Jag menar, jag tyckte kanske...
Använd Async/Await, people.
Ja, den kan jag stå bakom.
Men beroende av den här "generators" är man inne på...
Alltså det känns som att ingenting är bättre av generators.
Ja, dålig erfarenhet. Eller vad säger jag? Lite erfarenhet av generators.
Men det är ju typ Sagas i Redux, till exempel.
Är ju generators.
Aldrig stött på det faktiskt.
Skattare är lycklig.
Man ska bygga Redux-sagor för att transportera state.
Ja, de kan anropa sig själv och vara långlivade.
Det är så jävla mäckigt.
Det kommer väl från ombackend-idéer från början.
Sen tog de in det i Redux.
Jag har aldrig stött på en bra implementation av det.
Jag bara backar.
Ja, det tycker jag. Som Homer Memen när han backar in i häcken.
Precis.
Okej, vill du ha en till fråga?
Sure.
Vad ska vi ta?
Det känns spontant, ska jag säga det nu innan jag fortsätter, att de här frågorna inte är superuppdaterade.
Nej, verkligen inte. Och i JavaScript-frågorna så kommer även React-frågor, tror jag.
Jaha, det är ju spännande i alla fall.
Okej, den här då.
"Why does React use class name instead of class, like in HTML?"
För att det inte ska krocka.
Ja, det här kanske är en fråga du inte kan.
Det här är en fråga jag inte kan...
Jag tror jag kanske har kunnat...
Är det någonting...
Är det inte för att differentiera ut någonting så att det inte blir krockar när de bygger om det till HTML eller JavaScript?
Ja, det finns egentligen flera anledningar och du är väl lite inne på en, skulle jag säga.
Den ena är ju som du säger, till exempel förr i tiden så krockade typ så här, då kunde du inte använda reserverade ord i objekt.
Så class till exempel, du kunde inte skapa ett objekt som hade en property som hette class i det här fallet.
– Ja, då blir det problem när de kompilerar det.
Ja, precis. När det går från JSX så blir det ju ett React.createElement.
Bla, bla, bla.
Och sen blir det ju...
Propsen blir ju ett objekt som skickas in till det, anropade till den funktionen.
Och då kunde det inte heta "class".
Så det är liksom en anledning.
Men en annan anledning var också att de försökte
aligna det här med DOM-APIet.
Alltså inte med HTML, utan med DOMen som finns bakom.
Så till exempel när du kör "document create element div"
då sätter du "element.classname" för att sätta klassnamn.
Du sätter inte "element.class" om du gör det via JavaScript.
– Ja, just det. Så de ville återspegla det.
– Ja.
Sen vet jag att det har varit diskussioner skitlänge om att de ska stödja "class" istället för "classname".
Eller att det ska bytas ut.
Och har varit så här "ja men nu är det dags att göra det" och så "ja men nu när vi skjuter lite till på det"
Så får vi se, det kanske händer någon gång.
Jag har inte hört om det i Reacta 18 vilket skulle vara ett bra tillfälle men
förmodligen så vill de väl kanske lägga till att man kan stödja båda.
Och sen deprecera liksom Classname så att längden kan ha bytt ut.
Men vem vet.
- Just det. - Ja.
Ja, men det satt väldigt lång tid. Det känns som att jag kunde mer förr.
Men jag vet inte, de här frågorna, som sagt.
Skulle någon fråga mig, "Varför använder du React Class när vi ställer för klass på en intervju?"
Och liksom bara ha där sådana jävla måttstock, det skulle ju vara katastrof.
Ja, men alltså jag var ju typ... Ja, det skulle vara katastrof.
Men just de här grejerna, jag tror att jag var bättre på React-specifikationen förr.
När jag lärde mig React.
Okej, vart kommer allt ifrån? Vart är det här?
Och sen har det bara rullat på.
Jag har ju inget minne.
Det är så dåligt.
Så jag tänker bara skylla på mitt dåliga minne.
Ja, men det är helt okej, tycker jag.
Ja. Vill du ha en till fråga?
Absolut.
Okej. "What is the event loop in Node.js?"
Vad är det här för skit?
Ja, vad fan, det ska vi se. Här kan man ju kille-isa sig till.
Eventlopen...
Jag har faktiskt ingen aning om hur jag ska förklara det här på ett enkelt sätt.
Jag har inte suttit så mycket på Node.
Jag har ju stött på eventlopen när jag har skrivit Node backends.
Men aldrig orkat riktigt lära mig exakt vad det är.
Jag är helt med på att man kan skicka events i Node och så plockas de upp och så körs de och grejer.
Men jag vet inte om det är event-loopen eller om event-loopen är mer att Node kör, det är det som kör Node-processen så att säga.
Om det är det som är event-loopen. För det skulle det lika gärna kunna vara också. Så jag har ingen aning.
Men jag tänker att det inte bara är en node, det är väl liksom i browsern också?
Eller är det väl en node som kör?
Du får klicka på "show answer" och ge oss den korta versionen.
Jaha, men det här kan jag faktiskt.
Ja, titta vad bra, snyggt.
Ja, men det är ju den som kör alla typ av asynkrona callbacks egentligen.
För att stacken blir full.
Och då är det ju så, eftersom det är singeltrådat så är det ju inte så att den vill köra allting till rådning hela tiden.
Speciellt då när man vill typ ut och anropa web-app-bis och sådana grejer, då lägger den en call queue istället.
Och sen är event-loopens jobb att putta in jobbet från call back queue in i stacken igen och exekvera det när det finns plats.
Över.
Just det.
Så det är den som ser till att "Okej, men nu finns det ledig plats här, så då kan vi putta in dig".
Det låter ju bekant faktiskt och väldigt vettigt.
Vi kan öppna här också.
"The event loop handles all async callbacks. Callbacks are queued in a loop while other code runs and will run one by one when the response for each one has been received."
Oj, vad läste jag precis?
Det var typ exakt vad du sa, eller?
Ja, typ.
"The event loop allows Node.js to perform non-blocking I/O operations despite the fact that JavaScript is single-threaded."
Just det. Ja, men det är bra. Nu har jag en ny fråga till dig här.
- Varför är du så glad? - Det var ett brett leende som inte kunde underslapp mina läppar.
"Just the differences between an HTML specification and a browser's implementation thereof."
- Det är en lång beskrivning, varsågod.
- HTML-specken är ju specifikationen för språket, hur det är uppbyggt och hur tanken är bakom den.
Det är specifikationen för språket.
Sen så väljer browsers att implementera tekniken, att hantera koden på eget sätt.
Så det är därför det kan skilja sig åt från browsers, att de kan tolka det olika.
Eller att den här browsern och den här versionen tog in funktionen för det här HTML-grejen som bara var ett draft.
Så därför skiljer det sig jämt emot hur den andra browsern gör det.
Guldstjärnan tycker jag. Applåder.
[Applåder]
Det är ju bara en fly.
Det var ändå rätt.
På höftet, eller skjutet från höften kanske.
Men utan förberedelse så att säga.
[Skratt]
Så det tycker jag du gjorde väldigt, väldigt bra.
Jag vet inte, vill du ta en fråga till eller ska vi...
Ja, eller ska vi packa upp. Vem började?
Jag vet inte faktiskt.
Nej, jag vet inte heller. Vi kan ta den här.
Bara för att jag själv hatar det.
"What is Coors?"
Ja, där lägger vi ner.
Nu tar vi nytt år.
Vi kan väl runda av med att säga
tack till alla som har lyssnat.
Jag tycker att det var jävligt kul
Det var jävligt kul att få feedback och få frågor.
Jag har haft jävligt kul att göra den här podden i år med dig, Therese.
– Ja, verkligen. Tack så jättemycket allihopa.
Det är jättekul att höra feedback som är så här att...
Det känns verkligen som att det är lite som att hänga med.
Just den "vi vill ha"-pitchen, bara hänga med oss i ett vardagsrum.
Exakt. Så vi får hoppas att även om vi gick ifrån det här lite grann att bara prata och ställde varandra lite hårda frågor idag så kanske ni står ut med oss.
Vi är såklart tillbaka igen om två veckor med kanske något annat vettigt eller ovettigt.
Tills dess så säger vi väl tack för oss.
Gott nytt år och vi hörs snart igen.
Gott nytt år, glad vinter och sånt.
Vi ses då.
Bye bye.
Hej då.
[Musik]
