26. En djup kris i Therése relation
lyssna! 
Anton har bytt uppdrag och har i sin reflektion insett hur mycket han älskar Prettier. Med det som utgångspunkt diskuterar vi “developer experience” (DX), trailing commas, copy paste-utvecklings styrka och att automatisera så mycket som möjligt. Dessutom lite snack om en djup kris i Therése relation, för tidiga abstraktioner och den skavande känslan när React-importen ej är överst.
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:
Vilket är webbutvecklarens favorit-te?
URL Grey
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Vilket är webbutvecklarens favorittte?
Jag dricker ju ändå te, men jag kommer inte på ett enda te sort just nu.
Grönt te.
Urle Grey.
Fan, det där har jag till och med hört förut.
Fan också. Åh, vad dåligt.
Jag är helt hundra av att jag har hört det här förut.
Kanske till och med sagt den till någon för länge sedan.
Ja men säkert. Det här är nog någon som har passerat förbi mig på internet.
Ja, det var bra tycker jag. Bästa på länge.
För att jag inte har kommit på den själv.
Det kanske är det som är temat varje gång jag säger det. Det här var ett bra skämt, så har du inte kommit på det själv.
Ja. Nej det tror jag inte.
Välkommen till ett nytt avsnitt av ASDF.
Idag så... Jag ska byta uppdrag kan jag börja med, typ på måndag.
Och då har jag reflekterat lite grann över vad jag har gjort senaste året, typ.
Och en av de största grejerna till och med mig tror jag, för jag är ju suttit i ett projekt
där jag vill bygga om en frontend-plattform från grunden, typ.
Och den gamla är liksom en plattform från 2016 eller något, så det är ganska gammalt.
Men en grej som har slagit mig så jäkla mycket är att fan vad bra Prettier är.
Ja, jag vet.
Alltså för i det gamla projektet finns inte Prettier.
Och i det nya så finns det.
Alltså vet du, det är kul för jag håller ju inte på att byta uppdrag idag.
Men jag tänkte precis det här om dagen.
Jag hade till och med en liten diskussion på jobbet om det.
att vi fasen var Prettier är fantastiskt.
Ja, alltså jag minns tillbaka till innan Prettier kom
och det var diskussioner om syntax.
Alltså inte syntax, utan formatering.
Ja, man samlade sitt rum alla frontändare i en timme
och så bråkade man lite om vilken rad saker skulle ligga på.
Ja, nu ska vi skapa en style guide för teamet
där vi bestämmer om vi ska ha mellanslag eller tomrad efter funktion eller inte.
Det är mycket så här konstiga grejer som man bara, det här måste vi komma överens om.
- Ja och sen typ, vi måste verkligen i code reviews och sånt påpeka när vi inte följer Styleguide.
Så det blir små kommentarer och små fixar för att fixa bara utseendemässig syntax.
Och jag var faktiskt väldigt skeptisk första gången då Prettier skulle dras in i projektet jag satt i.
För jag var så här, nej det ser ju ut som skit när Prettier formaterar.
Speciellt om man bara har typ 80 tecken per line.
Så jag var faktiskt ganska skeptisk, plus att jag fann ändå någon typ av charm i att sitta och bråka om dubbel förnutt eller enkel förnutt på möten.
Men jag är verkligen omvänd där, för att Prettier är så jäkla skönt.
- Ja, jag tycker att deras filosofi är så sjukt bra, att det är så här, det här är "the false end".
Det här är så vi tycker och vi kommer inte att ändra oss.
Sen är det klart att de har en massa regler man kan overrida där också.
Men det känns som att de flesta som jag känner har sagt att "ja men okej, vi kör default".
Ja, det var ju det med trailingkomma va? Men det ändrar ju dem.
Ja, precis. Det är väl en grej. Det var väl sista raden på en array med saker.
Förut så tog de bort trailing-kamera på den sista raden, men nu läggs det väl på då?
- Ja, för det kommer jag ihåg för att det var en update.
Så plötsligt en dag så ändrade jag i varje fil jag var inne i så ändrade jag på saker.
Och det var det att de hade bytt ifrån till inställningen.
- Ja, den ändringen tycker jag ändå är vettig i det.
Det blir bättre till exempel när man kollar skillnader när man har gjort någon ändring.
För då behöver du inte ändra på den raden som egentligen inte berörs.
Så här lägger du på en ny rad i en array så behöver du inte visa i diffen vad som...
Att den raden ovanför ändras bara för att du lär på dig komma egentligen.
- Nej, alltså jag älskar trailing commas också.
Så att vi behöver inte övertala så att säga.
Nej men exakt. Och sen tycker jag också att det finns andra saker som jag tror att jag brukar ändra så att det inte är 80 i bredd.
Alltså 80 karaktärer i bredd.
Utan brukar det vara lite högre.
Och jag kommer inte ihåg vad deras default nu för tiden är på semicolon.
Jag tror det är inga semicolon.
Ja, det känns också som att det är det. För det är det jag föredrar.
Och när jag tänker efter så tror jag inte att jag brukar overrida det på nya projekt.
För det är ju så sjukt skönt.
För där var jag, liksom,
tidigt, det kanske är överdrivet,
men hyfsat tidigt ute med att förespråka
inga semicolon.
Och många bara "men man måste ju ha semicolon!"
Vilket gjorde det så jäkla skönt.
Men Preacher bara "nej, vi rekommenderar inga semicolon".
- Jag var fan team semicolon alltså.
(skratt)
Och jag vet verkligen inte varför.
Hatar väl förändring eller något sånt?
- Ja, men du är lite liksom konventionell av dig.
Du vill inte ha förändring.
Nej, Gud. Herregud, vad gör vi här? Varför kodar vi ens ES5?
Jag tycker inte det är ett sådant här verktyg som kommer och...
Jag skulle ändå säga att 99% av utvecklare tycker att det är positivt.
Att det här förbättrar upplevelsen som vi har, alltså Developer Experience, eller DX.
att den blir mycket bättre bara för att vi kör det här lilla verktyget?
Ja, för att vissa kan ju dock vara så här att
okej, jag tycker det har sina fördelar i ett projekt där det är många personer
men skriver jag egen kod så vill jag absolut inte ha det för att jag vill kanske inte att
något ska bestämma över hur jag vill formatera saker och det blir fult och grejer.
Och det kan jag ändå förstå.
Men för mig har jag blivit så sjukt van vid, och jag är ett vanlig djur, men att trycka "Ctrl" eller "Command" "Save" och så formateras hela min fil.
Ja.
Och det vill jag ju ha kvar.
För jag vill inte hålla på, alltså fasen vad mycket man har suttit och tabbat eller spacat och flyttat fram och tillbaka och grejer.
Det tar ju bara tid. Det är helt magiskt att jag vill ha den här koden, det ser ut som skit nu. Jag trycker "Save" och det blir bra.
Ja, verkligen. Tittar man på ett av projekten som jag har med Prettory så är det några filer som jag ignorerade av Prettory.
Men varje gång man ska göra något i de filerna så försöker man spara och så händer ingenting. Då tror jag att jag inte har sparat.
Jag tror att saven har misslyckats för att Prettory inte körs. Så det är en jäkla muskelminne på något sätt.
att det är en sån visuell cue på att "ja, nu har det sparat" att den ändrar min fula formatering.
Så där brukar jag sluta med att typisar jag tar den koden jag skrivit, kopierar ut den i en annan fil som inte är ignorad
och så sparar jag den där en gång och så kopierar jag in den igen. Så det är perfekt.
- Gud, vad jobbigt.
- Man skulle kunna ta den pragmatiska vägen att faktiskt undersöka varför de här filerna är ignorade
och kanske lösa det, men det har jag inte riktigt blivit av.
Jag är i och för sig inte någon som gör fiffiga lösningar heller, jag gör ganska mycket manuella saker. Men just Prettier också när man ska sätta upp ny miljö och så.
Det är alltid, alltså ska jag trycka in i, för nu kör jag VS Code och då har jag gjort i två uppdrag nu. Jag var lite sen på att gå över till VS Code men det har också blivit riktigt skönt.
Jag förstår vad alla pratar om, jag ska sluta vara en "old man" gällande Cloud.
Varje gång jag ska stoppa in i JSON att jag vill formatera on save, då har jag av någon outgrundlig anledning fortsatt att göra det per språk.
Ja, "script", "format on save". Sen sitter jag bara i TypeScript-filer.
Lite pitsur för att ingenting funkar.
Och så kommer man in i en CSS-file och så fortsätter det så att jag måste skriva upp alla filer.
Men man borde ju bara köra format on save på allt.
Ja, det tror jag att jag gör faktiskt.
Jag vet inte, det var någon som sa någon gång att det var dåligt att göra så. Jag kommer inte ihåg varför.
Nej, det kan ju vara en lyssna fråga. Om ni tycker att det är dåligt att göra och säga format on save på allt så berätta gärna varför.
Jag såg också att det var någon som gjorde ett projekt, undra om det var någon som jobbar på Spotify kanske, om jag inte minns helt fel.
Som har gjort ett projekt som heter "Betterer".
Alltså... "Bettre"?
Eller... Alltså...
Det är väl någon halv kombination av det och "Prettier", att det ska styras upp på samma sak.
Som är...
Jag körde det i... Vad var det? Jag körde det nog i ett privat projekt, tror jag.
Det är i alla fall att man kan ställa in saker, att nu vill vi inte använda det här biblioteket längre.
Så därför disallarar vi nya imports av den.
Så alla gamla finns kvar fortfarande och de är helt okej.
Men lägger du på en ny så kommer du få en varning för det, eller en linting error.
Det tycker jag också är ett bra sätt att...
Då behöver man inte göra allting på en gång.
Och du kan bara rekommendera att från och med nu, om vi ska byta från Moment till Dejjs eller vad som helst.
Då kan man lägga in att istället för Moment rekommenderar vi DayJS.
Vad är det om man importerar en Moment på nya ställen?
Då får du en varning som säger att importera DayJS istället.
Och det är ju sjukt smidigt.
Ja, men det är superbra för att så många, speciellt om det kommer in nya personer i projektet.
Ibland hoppar man ju bara runt och copy/pastar.
Har man gjort det här förut? Ja, men de drar in Moment och antar att det är det vi kör.
Så det där är ju otroligt hjälpsamt.
Ja, men exakt. För det är ju väldigt mycket, man driver ju med copy-paste-utveckling, men när man sätter sig in i nya projekt så är det ganska mycket som är copy-paste i den mån att man tittar hur lösningar är gjorda på andra ställen i kodbasen.
Så jag tycker att det är sjukt vettigt.
Men det handlar ju också lite om att inte bara copy-pasta för att man inte pallar att göra.
Men ibland så copy-pasta man ju lite för att bara hålla kod konsekvent och lösningar konsekventa in i nya projekt.
Eller om man vet att den där jävla skiten löste jag för en vecka sedan och det här är exakt samma sak så copy-pasta man lite.
Det är väldigt viktigt att man ändå sätter regler för att förhindra att kodbasen spretar åt en och olika håll.
Att man går in och tittar på ett ställe med formulär som är löst på ett sätt och på ett annat ställe med formulär så är det ett helt annat sätt att lösa.
Då kan det ändå vara väldigt vettigt att man kan copy-paste det lite grann.
Sen kanske man vill abstrahera det så småningom.
Men ett litet sidospår på det här är att jag tycker att man copy/pasta för lite egentligen.
Det är för lätt att sträcka sig efter att nu ska jag skriva en smart abstraktion här som vi kan återanvända i hela kodbasen.
Medan att man då gör det för tidigt ofta leder till att det blir bara en jättedålig abstraktion som inte passar på de användarfallen man har.
Det är så jävla lätt att fastna i. Alltså jag fastnar i det här så himla lätt för att det är typ att jag tänker att
här hade någon annan gjort någon smart lösning så nu måste jag göra en smart lösning för att bevisa att jag kan göra en smart lösning
men egentligen så vill jag inte göra en smart lösning. Egentligen vill jag göra en så här tydlig, bara make it work-kod.
Men jag fastnar ändå i det. Sjukt starkt.
Jag är starkt förespråkade för att ska du ha ett formulär med lite olika fält på, skriv ut alla inputs och labels och divvar och allting som du vill ha.
Även om de liknar varandra, de här fälten så att säga.
eller grupperna, istället för att försöka göra något objekt och sen loopa över det, eller mappa över det, och försöka göra något smart så.
Alltså hellre att man till att börja med gör en dum lösning, där det är en jättelång return, med jättemycket J60,
för att annars så tror jag att den abstraktionen kan bli helt fel.
Men om man ska komma tillbaka till Pricker, jag har inte superkoll på det, men det finns väl på andra språk också?
För jag har bara suttit med det i JavaScript-världen.
- Ja, det tror jag. Jag tror att det finns för de flesta språk, eller vad säger jag nu, men många språk i alla fall.
Jag vet att det finns för Markdown till exempel, bara för att ta ett exempel på, inte kanske ett programmeringsspråk,
Men det finns väldigt många olika textfiler.
- Jag tänker att det finns också för Java och sånt.
Jag vet inte om det heter Prettier, men det finns samma typ av opinionated formatting.
- Ja, exakt. Just Prettier-biblioteket vet jag inte hur många språk det kör på.
Men det känns ju som att det finns en så många språk. Jag vet inte hur det är med sådana där språk som är
det som jag tycker är, typ objektorienterade språk, typ Java eller C# eller vad det nu kan vara.
Det känns mer som att det är rena webbfronten språk som de har fokuserat på.
- Ja, man kanske inte ska ut och vifta i saker man har noll koll på här.
Jag googlade lite snabbt nu faktiskt, bara för att jag kände att vi var inte alls med.
Och det är som du säger, det är webbgrejer.
Så det är typ JavaScript, JSX, Angular, Vue, Flow, TypeScript, CSS, HTML, JSON, GraphQL, Markdown och YAML.
Just det. Jag tror jag pratade med någon när vi införde det som satt i Java och pratade om att det finns den typen av opinionated formatters i Java.
Och liksom .net och dem också. Men det är väl inte Pritter då?
Nej, precis. Undra om inte, är det Go eller Rust, slänga ur mig nu utan att egentligen veta, som har det här inbyggt?
Alltså det följer med i språket på något sätt. Jag får för mig att det är Go.
Att du kan typ skriva så här Go format och så formaterar den enligt deras opinionated style liksom.
-Måste jag säga stort pass? -Ja, men jag tycker ändå, oavsett vilket språk det är som har det, så tycker jag det är ganska spännande att idén har spridit sig så pass mycket att det byggs in som en grundsten i ett språk eller i ett ramverk kanske då.
För det är ju inte själva språket som kör formateringen.
- Nej, men det är intressant när man tänker på hur mycket energi man kan ha lagt på något som egentligen spelar noll roll som börjar skönt att bli av egentligen.
För att jag har börjat med importer i filer.
Jag har ju varit väldigt länge såhär, "ja men React ska vara överst i en J6-komponent"
och sen så typ externa bibliotek ska vara såhär, blablabla, och så har jag ändrat om ordningen och grejer.
Och nu på Mac-VS Code så har jag ju bara hittat "Option Shift O" som tar bort alla unused imports och sorterar dem.
Så det blir ju fel. React är ju inte överst och det blir så här helt huller om buller.
Men jag är så här "fuck it" det är ju så jäkla skönt att bara kunna trycka på det där, det jag inte vill ha och sen så är det så.
Jag vinner ju mer på det.
Ja, men gud, för egentligen så borde man ju kunna dölja alla importer.
Man borde kunna kollapsa alla importer och sen inte bry sig om vad det står där.
Så länge du kan veta om att jag tar bort de som är oanvända och de som jag behöver finns där.
Ja.
För det är det enda man bryr sig om egentligen.
Precis.
Det känns som att jag har lagt alldeles för mycket tid och mitt liv på att ordna importer till ingen nytta mer än min egna hjärnas belåtenhet.
Ja, exakt. Jag håller helt med. Det känns helt onödigt egentligen. När du säger det här så kände jag direkt att React ska vara överst.
Vi kan ju inte gå ifrån att React ska vara i överst.
Nu är det inte lika stort problem längre när man inte behöver importera React längre.
Men fortfarande, det kändes i själen nästan att jag "Åh, nej, nej".
Även om jag skulle automatiskt sortera och gå in och redigera så att vi flyttade React i överst.
Nej, jag släppte. Jag släppte.
Ja, jag tror att i nuvarande projektet så har vi också massa ESLint-regler.
Jag kommer att tänka på det nu för att vi har någon regel att vi måste gruppera våra importer, tror jag.
Att de som är från bibliotek måste ligga högst upp i en grupp.
Och sen kanske de som är från...
Jag vet inte hur den grupperar riktigt, om det är typ per nivå i filstrukturen, eller i mappstrukturen.
Om det är där som den grupperar.
Att de som ligger i samma mapp som den här ska ligga i en grupp.
Och den som ligger några nivåer upp i trädet ska ligga i en grupp med en tomrad emellan i stort sett.
Men det är inte heller så stor problem, för där kan man bara köra fix och så fixar den det åt dig.
Och det är också väldigt skönt att slippa bry sig om.
Ja, sådana regler har jag också varit med och satt upp.
Och det är det ju liksom. Men det är ändå så här, då måste du fixa det.
Ja, absolut.
Det är inte så jobbigt att köra dashdash fix, men det blir på något sätt lite jobbigt att man inte får någon överblick på vad som faktiskt kommer fixas.
Det är lite läskigare.
Ja, men du kan ju köra, jag tror att jag har något, undrar om det är ett VS Code Extension kanske som gör det?
Eller om det är inbyggt? Att du kan fixa i den här filen som du är i.
Och att den gör det inline för dig, så att säga, i editorn.
Mm, nice.
Det är ju ganska skönt.
Ja, men det är lite kul när man tittar på det här med en sådan
developer experience, hur stor skillnad det ändå kan göra.
För om man drar upp ett nytt projekt eller ett hobbyprojekt,
eller om jag drar upp och sitter i Atom, eller inte har
konfatt alla paket som jag vill ha och allt sådant,
Man måste ju lägga mycket mer tid på allt möjligt.
Bara en sån sak som jag har i VS Code, den här Rainbow Colorizer-paketet.
Jag kommer inte ihåg vad det heter exakt.
Men det sätter färg på brackets och parenteser så att det är lättare att se vilka som hör ihop.
Det är ju också magiskt för jag har ju suttit på en felaktig måsvinge både en och annan dag i mitt liv.
Ja, exakt.
Hur allt det här verkligen förbättrar.
Alltså det går ju snabbare och jag har ju varit anti sånt här för jag är ju kanske lite manuell och rädd för att om jag inte får göra allt manuellt så kommer det se ut som att jag inte jobbar.
"Varför jag kan inte göra något annat än små uppgifter?"
Men så är det ju inte.
- Nej, men jag tycker också det är sjukt ändå vilken impact det kan få.
Alltså om vi pratar lite så här ES-Lint till exempel.
Jag är så jävla för att så fort man springer på någonting som kan automatiseras i ES-Lint
som man har en diskussion om och säger så här.
Man kan springa på det i en pull request eller vad som helst.
"Borde vi inte göra så här? Borde vi inte göra så här?"
Eller så är det en liten diskussion fram och tillbaka.
Om man tar ett beslut på att "Vi kör så här"
och det går att lägga in en ES-lintregel på det
så borde man göra det.
För att då slipper ha diskussionen igen.
- Ja, absolut.
Och du behöver inte ha diskussionen med nya som kommer in.
Eller ja, det kanske du behöver ha.
Men då har man i alla fall en historia och en redan satt sak.
Men det är också intressant om man tänker på
vissa saker som att
Att köra alla lintregler i en pre-commit-hook eller en pre-push.
Speciellt på projekt som är live och du pushar till master.
Det är ofta att man känner att det bara tar tid att köra igenom.
Vad är det här?
Men det har ju räddat den ett par gånger.
Jo, definitivt. Vi kör typ alla tester och linting på Commit.
Det tar ju lite längre tid att Commita, men det är inte så att det påverkar mig jättemycket.
Man kan ju fortsätta annat medans. Det är bara att låta den fortsätta köra.
Om man ska pusha och skapa en PR så kanske man sitter och väntar på att det där är klart.
Men man slänger inte bort hela dagen.
- Nej, men det är också så att gör det någonting att sitta och vänta en minut extra.
Måste dagen vara så pureffektiv att du inte kan låta hjärnan bara glo ut i tomheten?
Nu är det inte hjärnan som glor, men ni förstår vad jag menar.
- Ja, exakt. Jag håller helt med.
Sen är det ju så här, så länge det inte hindrar en när det behövs, typ commit-grejer.
Jag vet inte om vi kör Haski eller något sånt där tror jag det heter.
Då kan man skicka in en flagga som heter "No Verify" eller vad fan det nu är.
- Ja, det är det. - Och så bypassar man det där.
- Det är jag inte bekant med. - Ja.
Så länge det finns sådana escape hatches, för du skulle ju kunna sitta i en stressig situation
och bara "Shit, det här är alltid paj i prodd, vi måste få ut det här nu".
Då är den här minuten jävligt lång helt plötsligt.
Ja, så är det ju absolut. Men det kan ju också vara så att du måste få ut det här nu men du har pajat andra saker.
Ja, definitivt. Så är det.
Men jag menar då kanske man hellre, för vi kör ju också alla test och grejer på varje pullrequest.
Så då kanske man inte behöver köra den lokalt utan kanske man behöver pusha upp det här så snabbt som möjligt så att man kan
köra, se i pipen istället för att göra det lokalt också.
Ja, absolut. Det är skillnad på vad man gör. Nu till exempel sitter jag i ett projekt som inte är live än.
Där det fortfarande är mycket utveckling som går, refaktorering och det är verkligen inte färdigt.
Och där är ju inte poängen lika stor att ha den. Jag testade faktiskt att lägga in den bara för att få köra "no unused locals".
Men det funkar inte ordentligt om man körde bara "no verify" för det är bara en "whip commit" och det kommer ännu inte igen.
Så det är verkligen så här, man ska vara i ett visst state, tror jag.
Ja, exakt. Det krävs nog att man har någonting att verifiera, så att säga.
Du måste ha någonting som du bara "Okej, men nu har vi det här, vi vill inte att den här ska vara trasig".
Man måste vara säker på det.
Medan om det är i ett halvt trasigt state från början så spelar det inte så stor roll.
Nej.
Jag tycker det är spännande. För det här är också en grej som jag tänkte på.
Det är svårt att motivera oftast, det beror lite på organisationen, att vi ska förbättra utvecklarexperiensen.
Det är svårt att få tid till att göra sådana saker.
Ja, men det är också kul hur man tänker på det, att vi tänker på det som utvecklar experience för att om man börjar tänka på det och faktiskt att det här med ESLint och även om man har typning och sånt som TypeScript som kör och sådana saker att det faktiskt är egentligen i test sfären mer än det är i bara så här user experience världen.
Jag har alltid tänkt på det som user experience.
Sen har jag gluttat lite på vilka tester vi behöver för att få en komplett testning av ett system.
Då nämner man just det här "static test" som är den här typen av syntakstest som en del av det.
Det har inte jag riktigt tänkt på tidigare.
Nej, jag tror att det är extremt lätt att missa.
Om någon tänker test, då tänker folk enhetstester eller integrationstester.
Eller användartester om man ska gå ännu högre upp.
Men det tidigaste eller enklaste, som kanske är enklast att sätta upp också, är ju just statiskt.
Att du har typat någonting, om du kör Flow eller TypeScript eller IS-Lint som fångar lite fel.
Eller vad heter den andra? JS Hint finns det väl också.
Jag vet inte hur populärt det är längre. Jag har inte kört på någon projekt på länge.
Men den är väl typ lite mer "hitta code smells" typ.
Ja, det var väldigt länge sedan jag sprang förbi det tror jag.
Ja, det kanske har försvunnit ganska mycket tror jag.
Ja, för nu känns det ju verkligen som så här.
Uppsättningen är Prettier och så är det ES-Lint.
Och då kör du Prettier och sen kör du ES-Lint.
Ja.
Ja, det känns verkligen som att det har blivit en extremt stor standard.
En sak som jag ska prata om i ett annat avsnitt som jag tänkte på och läste en artikel om häromdagen
var typ att just syntax-highlightning är en lite, vad får man säga, en
outnyttjad möjlighet för att förbättra DX.
Ur perspektivet att "Okej, nu highlightar vi bara efter vilken
typ av "keyword" där.
Är det en variabel så får det en specifik färg.
Är det en måsvinger får den en specifik färg till exempel.
Men att det finns möjligheter där att man skulle kunna bygga något mycket mer avancerat.
Alltså att du kan ha olika linser på som du byter mellan i din highlighting.
Typ att du skulle kunna ha en vanlig syntax-highlighting när du skriver din kod.
Men sen kan du byta en annan lins när du debuggar som visar
komplexitet i olika färger eller olika concerns, alltså typ så här
kod som hör ihop får en färg. Det är ju säkert såklart superavancerat, men
ju mer vi kommer med AI och ML och allt möjligt däremellan så blir det
möjligt att göra sådana här coola grejer och det tror jag kommer bli
extremt coolt när det väl kommer, för jag tror definitivt det kommer komma.
Ja, det är också spännande för att det här med att ha olika färg på olika delar i kodbasen, det tar jag för givet, det är så jag tycker att det ska vara.
Och det är helt sjukt att det inte är så.
Vilket leder mig till att tänka på en i min relation djup kris
när jag en dag såg min sambo arbeta och jag kom in i hans rum
såg att han satt i VIM med vit bakgrund och bara svart text.
Det var det sjukaste.
Ja, jag förstår att det kan leda till en kris faktiskt.
Nu får alla såklart ha den typ av syntax-highlightning och teman de vill.
Men jag förstår inte ens hur... Jag hade aldrig kunnat lösa ett enda problem i temat.
Men variablerna är ju fetstilt. Jag bara, vad?
Nej, jag är helt på din sida här. Jag ser inte heller med att kunna sitta utan syntaxalärning.
Däremot kanske att man kan byta vilka färger man får utifrån vilken kontext man är i.
Men aldrig att det bara är svart på vitt. Det låter så jävla hemskt.
- Det kanske bara är "level up a thousand" att kunna göra det.
Men jag kommer aldrig nå dit, tror jag.
- Ja, det känns som att man måste... Jag vet inte.
Man måste förstå koden mycket djupare.
Det är nånting som gör att det är mycket lättare.
För det är på något sätt undermedvetet.
Det är inte så att jag aktivt tänker att nu ska jag till en röd kodsnutt.
Nej, nej.
Utan det blir bara undermedvetet.
Man vet att det är variabler i den här färgen och därför kan jag hoppa dit.
Ja, för om någon skulle fråga mig vilken färg har dina funktioner?
Jag tror inte jag skulle kunna svara på det på rak arm bara.
Nej, jag håller helt med.
Det skulle nog vara jävligt svårt faktiskt.
Nu kan inte jag fatta att jag har trog ner min sambo i skiten i den här podden.
Det får han stå ut med faktiskt.
Men jag kan också passa på att han ska få en shoutout för att han har sponsrat
podden genom att han gav mig i förutsatt present den här mikrofonen som jag kan använda nu.
Han gav dig någonting i förutsatt present och får ändå en shoutout.
- Ja, det är ju inte så stort. - Eller hur? Men han var tvungen att bli dragen i skiten först.
- Ja, exakt. Så det går jämt ut. - Ja, men med det så kanske vi ska runda av så att säga.
- Ja, det kanske är dags. Det gick jäkligt snabbt den gången. Jag tror att det finns mycket mer att säga om allt det här.
Men vi återkommer väl dit i ett framtida avsnitt helt enkelt.
Vi finns på Twitter, om det är något, ge en recension i iTunes, hör av er om det finns skämt eller ni vill rätta oss eller tipsa oss av något.
Annars så hörs vi i nästa avsnitt.
Det gör vi.
Hej då.
Bye bye.
[OUTRO]
