Subscribe
Share
Share
Embed
En techpodd om allt förutom tech
Anders Arpi (00:01)
Hallå, hallå och välkomna till episode 6, tror jag, av denna podcast. Idag är jag här, som heter Anders och Patrik, vår resident MVP och vår tredje gäst, eller tredje medpratare som heter Adam idag. Välkommen!
Trollfursten (00:29)
Tackar, hallå hallå.
Anders Arpi (00:31)
Vi har sagt att vi ska prata om arkitektur. Jag tänker mycket jugent, kanske lite klassiskt, brutalism, lite klassiskt. Nej, tyvärr blir det mjukvaruarkitektur. Tråkigt nog. Nej, det är sant. Vi kan se vart det barkar helt enkelt. Jag öppnar mig en fråga. Nej, förresten, jag öppnar mig ett påstående så får jag prata lite längre.
Trollfursten (00:39)
Brutalism.
Patrik (00:48)
Det är inte för sent.
Trollfursten (00:50)
Vi kan ju fortfarande ändra oss.
Anders Arpi (01:00)
Mitt påstående är att arkitektur som koncept inom mjukvaruutveckling är
övervärderat, lite välhåsat för det mesta i alla fall.
Patrik (01:18)
Bra att du börjar med en positiv inledning. Som vanligt.
Trollfursten (01:20)
Jag skulle hålla med där, att arkitektur är ganska övervärderat, vi lägger för stor vikt vid det, tills att vi inte gör det och då är det för sent.
Anders Arpi (01:22)
Som vanligt.
Det är det svåra med det.
Patrik (01:36)
Ja, jag skulle kunna prata ett helt avsnitt tror jag om mina åsikter om det här. Men jag skulle låta er prata tänkte jag. Jag tror ni har en...
Trollfursten (01:42)
Det är det vi ska göra.
Anders Arpi (01:48)
Du menar att Pandoras box förlån locket på en kvart till eller så innan det är. Ja. Okej. Jag vill då direkt leda samtalet in på det som Adam introducerade mig för. Introducerade mig för företag sedan vilket är. Det är en person som är Barry O 'Reilly som är någon typ av arkitektlegendar.
Patrik (01:52)
Mm, jag tänkte det.
Anders Arpi (02:19)
som har ballat djur totalt och börjat läsa postmodern filosofi och nu kopplar ihop det med mjukvarusektur. Och jag tycker att det är underbart. Jag vet när jag kollade på det första tåket som du länkat för ett tag sedan så kände jag att jag fattar typ hälften. Men det jag fattar känns ganska intressant.
Trollfursten (02:40)
Men det är lite samma sak för mig, jag vet inte hur många gånger jag har sett hans förlösningar nu Varje gång så upptäcker jag flera saker som resonerar och som faller på plats Första gången så var det bara lite lätt att det här känns rätt, det här verkar vara rätt sätt att kunna angripa problemet med mjukvarararkitektur Och för varje gång som jag sätter sen efteråt så blir det mer och mer konkret och faller på plats Om man ska ta och sammanfatta vad han vill så är det ju
Att han vill säga att alla har fel. Allt är fel. Men det som vi gör blir ändå ibland rätt. Och hans frågeställning är varför är det så? Varför levererar vi saker som faktiskt funkar när vi inte har någon aning om vad vi gör?
Och istället för som andra tankledare inom våran bransch skapar något community och börjar med en certifiering om föreläsningsturné och stora tjocka böcker så tog han och började doktorerar på ämnet och hade sin utgångspunkt i Complexity Science. Och...
I hans arbete då när man ska sammanfatta vart man står filosofiskt inför att man ska skriva vetenskapliga artiklar så behöver man förklara vart man står, vad det är för någonting man utgår ifrån tankemässigt. Och det var ju de tankarna som man insåg att det här, det vi gör är ju inte riktigt hållbart i längden. Vi försöker lösa saker utan att ha en förståelse för vad vi gör.
Om man ska se hur jag ska försöka förklara det här. Man kan sammanfatta egentligen att vi tänker och fungerar på två olika sätt. Antingen så kan vi ha ett ganska lignärt tänkande där vi försöker vara korrekta hela tiden. Och det är som grunden egentligen för den vetenskapliga metoden och för matematiskt resonemang och logiskt resonemang.
Sen så finns det ett annat slags tänkande som kallas lateral thinking, eller att man tänker högt, eller att man provtänker, att man tillåts att vara vagare, att man tillåts att vara mer frånkopplad från de sakerna som man vet. Och när vi pratar mjukvaruarkitektur så jobbar vi ju med någonting som är väldigt konkret. Mjukvaru...
Anders Arpi (05:22)
Vi har.
Trollfursten (05:25)
projekt om djurkvaras system är ju det är ju logiska byggblock som vi tar och bygger och kodar. Det går ju nästan inte att bli mera linjärt och konkret matematiskt. Men direkt vi sätter det här systemet i produktion och när vi rör oss i en verksamhet som har med människor att göra så är det saker som rör på sig som inte vi kan tänka på. Och det gör att vi inte riktigt.
vet vad som kommer att ske. Ni har säkert hört talas om de här black swans och liknande grejer inom ekonomin. Ekonomiforskning. Så samma sak sker hela tiden för oss inom mjukvarufältet att det kommer någon ny vd som ska göra en omorganisation så hela företaget gör så och det påverkar hur vårt system bör fungera.
eller att det tillsätts en EU -kommission. EU -kommissionen kommer ett ny förordning som säger att vi måste hantera persondata på vissa sätt. Det är ingenting som egentligen kan förutsse. Och om vi då istället har det här laterala tänkandet när vi resonerar runt i kring vårt system och den miljön där vårt system ska fungera, så...
Skulle man kunna säga istället för att vi är korrekta hela tiden i varje steg när vi tar fram vår arkitektur så är vi fel och så är vi fel och så är vi fel och så är vi fel och sen är vi tillräckligt nära rätt för att kunna släppa någonting som kan funka i verkligheten.
Anders Arpi (07:04)
Det där är ju någonting jag har tänkt på, satt sedan imorse på sängkanten och tänkte på vårt kommande samtal idag.
Jag har arbetat professionellt med programmering och utveckling om man vill kalla det i 13 -14 år. Jag tror aldrig att jag har designat någonting korrekt från början. Jag tror inte jag har varit med i ett projekt där varken jag eller en grupp med tio duktiga utvecklare gjort rätt från början. Hur många man än har i mötet som spawnar fram olika vinklar. Har du tänkt på det här eller om man är bara en?
ett geni, inte jag då, men något geni som hade sin perfekta design från början. Så ändå!
Patrik (07:45)
Jag tror att du bara haft... Jag tror att du har haft otur bara. Det där låter ju jättekonstigt.
Trollfursten (07:48)
Allt Patrik har gjort är korrekt från början.
Anders Arpi (07:48)
Det kan vara... Wait, what? Nej. Nej, men jag tror aldrig att det har hänt. Jag tror aldrig att jag har så här, yes, där satt den. Vi spessade upp våra tankar, löst eller hårt, spelar ingen roll. Men vi har en idé om flödet, om detaljerna som faktiskt är korrekt. Och för mig är det typ kärnan i det som Adam börjar prata om.
Trollfursten (07:54)
Hahaha, hej. Hej.
Patrik (07:56)
Skål, jag var...
Anders Arpi (08:17)
Det är intressant för det är ju väldigt, det som Barry Riley pratar om, är ju väldigt komplexteoretiskt. Det är en väldigt gedigen, akademiskt underbyggd teoretisk grund. Men i slutändan känns det bara som att det är okej att höfta lite. Typ. Ja.
Trollfursten (08:31)
Ja, men det är ett sätt att förklara det här magkänslan. Det här känns rätt och bra i magen, men varför gör det? Det är det han försöker svara på.
Patrik (08:36)
Finns det?
Finns det en Barry och Riley for Dummies? För oss som inte... Det gör det.
Trollfursten (08:45)
Ja, det gör det. Han släppte sin första publikationen nu som inte är på akademiska. Och det har ett fantastiskt omslag som är ritad utav hans son. Den finns på Leanpub. Vi kan väl ta och lägga in den länken i show notes sen. Men den sammanfattar väldigt bra det här och tycker man att den känns intressant så kan man ju läsa hans underbara vetenskapliga artiklar också. Och sen så kommer det en
Patrik (09:04)
Mm, det vet jag tycker jag.
Trollfursten (09:15)
Han håller på med att lägga fram sin avhandling nu alldeles strax, efter det kommer han att göra en lite längre bok som sammanfattar det på akademiska. Men det är fantastiskt med en bok i mjukvaruarkitektur som kan lägga ett helt kapitel på den franska filosofen Deleuze.
Anders Arpi (09:38)
Det är mysigt. Vi kan säga att titeln på det jag håller på med är residuality theory.
Trollfursten (09:38)
Åh.
Precis.
Det som blir kvar när allt har brunnit ner.
Anders Arpi (09:48)
Precis. När allt har slagits mot varandra på det här slagfältet som är planeringsmöten och kravställningslistor och folk som löser en bugg och inser ett annat fel som det här är ingen tänkt på. Allt det där som står ett föranvändat ord som handlar om att stressa systemet, stressa designen, belastar vår initiala plan. Till slut finns det någonting kvar som är det fungerande systemet. Just då i alla fall. Om alla tur.
Trollfursten (10:16)
Det som är så intressant också tycker jag med den här teorin är att när du gör det här stressande jobbet och om du tar och skriver ner vad du gör för någonting så kan du visa att du har upp någonting som heter kritikalitet. Och det här kritikalitetsbegreppet är någonting som presenteras i den här boken.
Anders Arpi (10:38)
Stuart Kaufman, At Home In The Universe. Såg ut av en tjock bok.
Trollfursten (10:40)
Precis, Stewart Coffman, han var inte så tjock, det är inte en sån här amerikansk författare som får betalt persida. Men Stewart Coffman är en av dem som har presenterat teorier för hur livet har uppkommit, hur de här nätverken av aminosyrer kan forma liv. Och det är egentligen samma slags komplexa nätverk som vi kan ta och...
använda för att förklara vår mjukvara arkitektur. Sjörd Kaufman har visat att även om det är det här stora komplexa nätverket med jättemycket olika tillstånd som skulle teoretiskt sett kunna vara möjligt så att om den är lagom mycket begränsad så kommer det uppstå en struktur och kommer det när det gäller de här proteinerna, aminocylerna så kommer det uppstå någonting som är nästan som en... vad heter det?
självfrökande maskin, någonting som man skulle kunna kalla liv.
Anders Arpi (11:43)
Det är ju en provocerande tanke och provocerande hållpunkt som han har på många sätt. Men jag tror att det svåraste med vad gäller att sälja in den till en gängseorganisation är nog bristen på strukturalitet och spårbarhet och sätta upp mål och checklistor. För allt det där blir bara vad man kan göra det. Men det kan aldrig vara det som är processen med stort P.
Du kommer aldrig lyckas.
Trollfursten (12:14)
Men det är det som är problemet med mjukvarararistrikturen idag är att vi är så djupt rotade i strukturalismen att vi kommer från det här. Men vi kommer ju från ingenjörsmässiga som har sin grund i den vetenskapliga metoden och som har sin grund i strukturalismen i det positivistiska tänkandet. Det är grunden för hur vi gör våra saker och. När vi ska börja.
jobba med arkitekturen kring våra lösningar så måste vi ta ett steg ifrån det. Vi måste tillåta oss att vara fel för att komma rätt i slutändan.
Anders Arpi (12:51)
Ja, jag trycker tänka att om man hade haft absolut kunskap så hade man kunnat göra en design perfekt från början. Men med tanke på hur komplexa system man bygger, till och med en Hello World i ett enklare språk idag är ju egentligen extremt komplext under ytan och allt det gör. Om man då lägger på nätverkskommunikation och mänskliga idéer över tid och så vidare och så vidare. Så till och med ett ganska enkelt system växer ju till någon slags...
spretiga möbar ganska snabbt. Om man visste allt det här redan från början, då skulle man kunna göra en perfekt design från början. Och det är väl där man kommer ifrån, som du säger, man kommer ifrån den här vinkeln att det vi gör är strukturerat logiskt. Det går att verifiera, det går att testa, det går att bevisa att det här vill ni ha, här har ni det. Ja okej, för att ni vill inte ha exakt det här. Och det är ju där som det uppstår problem. Inte att man inte kan skapa ett test och sen säga att det blir grönt. Det kan vi göra.
Men samspelet mellan flera verifieringar och så vidare, det är där det blir liksom totalt kaos så att säga.
Trollfursten (13:59)
Men precis, och en av de sakerna som man kan se också som en, eller hur ska man, om man ser på de ramverk som finns för att jobba kring arkitektur så, ja men som TDD eller liknande, eller att man jobbar med TDD när man jobbar med utveckling så är det ingen som gör på samma sätt. Och kan man då säga att det är en strukturerad metod?
Vi jobbar safefish eller scrumish är ju samma sak i den agila världen.
Anders Arpi (14:21)
POP -HUB PRET!
Ja, det låter alltid så. Vi har vår egen take på det här.
Trollfursten (14:30)
Mm, mm. Precis.
Anders Arpi (14:34)
Okej, Patrik. Nu har det gått 14 .49 här. Ja.
Patrik (14:35)
Vem?
Trollfursten (14:36)
Det har väl gått 15 minuter här, nu är det dags. Nu öppnar vi lådan.
Patrik (14:39)
Oj! Nej, nej men det... Jag vet inte, jag tror inte jag ser värst mycket hot takes men det är väl mest så här... När jag tänker på det så... Jag vill mest så här...
Rent empiriskt, ett projekt man varit med i. Att ju mer uppstyrt någonting är, desto sämre blir det. Alltså, ju mer föreplanering som har gjorts. Och då tänker jag framförallt på... Jag har jobbat ganska mycket på olika försäkringsbolag. Och där har de ju ofta ett helt lag med arkitekter som beslutar kring olika saker. Och kanske till och med ett arkitekturråd som ska godkänna...
Det har aldrig blivit bra. Det har alltid varit jobbigt att jobba. Resultatet har inte blivit bra. Resultatet kanske inte har blivit det som beställarna ville ha.
Jag vet inte, de projekten som jag faktiskt har... Dels de projekten som varit mest lyckade och som jag haft mest roligt i. Det är de projekten som har haft nästan minimal styrning på något sätt. Alltså att man sitter väldigt nära de som beställer. Man vet, man förstår vad det är de är ute efter och så bygger man någonting ganska organiskt efter det och tar beslut.
eftervägen. Jag vet inte, jag har inte skrivit någon vetenskaplig avhandling på det här, utan det är bara min känsla att ju mer uppstyrt någonting är, ju mer diagram, ju mer så här ska vi göra, desto dåligare blir det.
Trollfursten (16:29)
De här diagrammen som man ofta tar fram, de är ju bara ett nutillstånd av hur det ser ut också. De kan ju aldrig riktigt spegla hur verkligheten är. Utan just precis i det här rummet när vi tog och ritade det här diagrammet, då stämde det okej. Men fyra timmar senare när man behöver koppla om mot en annan s3 -backet, eller jag vet inte vad det kan vara, då stämmer det inte längre. Eller att man behöver ta...
Patrik (16:39)
Exakt.
Trollfursten (16:58)
ett specialfall som gör att man måste gå och hämta någonting nån annanstans. Så de stämmer ju aldrig överens med hur det faktiskt ser ut.
Patrik (17:06)
Så är det. Och det blir extra illa när man har en organisation som inte tillåter en att avvika från de här diagrammen. Så man måste börja hitta sätt att arbeta sig runt problemet. Jag har sett ganska mycket Shadow IT. Jag önskar inte att jag nämner vilket företag det var, men det var ett företag med extremt... En it -avdelning som var väldigt, väldigt restriktiv. Folk tog alltså med sig egna burkar som de pluggade in.
Trollfursten (17:13)
Mm.
Patrik (17:36)
för byggservrar och sådana saker. Man kunde inte få någonting gjort.
Anders Arpi (17:44)
Jag har sett liknande också, inte egna burkar på den nivån, men däremot att man liksom har en en ordning från ett ordning från ett bestämt protokoll till exempel kring events eller payload struktur och så där och att man bara börjar liksom okej men i den här comments header där kör vi vara en JISON liksom för det är bara det som funkar på den nivån och det är ju för att det är så strikt att man inte får liksom avvika då och då man vill bara lösa problemet och gå hemåt och man vet att till och med
Det man tycker är för företagets bästa. Att man inte kommer få göra det här. Det kommer ta ett år att vara möten att få göra det här. Då skiter man ju bara. Då gör man ju bara som det är. Så att åtminstone man kan ha någon slags känsla att det här funkar. Jag har gjort det. Jag kan. Nu skiter jag det här. Men det jag tänker på när jag hör det här är också den här... Jag tror att alla kan känna igen sig i att om man varit någonstans... Om man varit ett tag någonstans. Så finns det alltid i liksom i teamet eller på arbetet en vetskap av att...
Det heter någonting heter det lived in knowledge, nej det är något annat men det är liksom den här tanken på att det finns vetskaper och kunskaper och insikter som bor i väggarna som bor i vissa människors huvuden och om man skulle bara liksom njuka kontoret, hyra en tio nya anställda som är jätteduktiga, som är skitduktiga utvecklare att de skulle inte vara rätt på allting även om det finns dokumentation, även om det finns jättebra kommenterad kod och sådär för att det finns insikter och detaljer som
ofta är anpassningar till verkligheten som bara vissa har koll på. Och där ses ju så någonting negativt, det är ju för att det är en risk såklart för företaget att det är så, men jag tror att det är en effekt av det här att man får passa in verkligheten i en fördefinerad struktur som inte alltid håller. Ibland ser man ju, jag tänker på gamla system, typ som vi säger personhummersystemet som är ganska gammalt i Sverige, relativt gammalt.
Att man har hittat ett plus där i stället för min, eller för ett mindre stekt då när man blir över 100 är det väl. I mitten. Det är en sådan lösning som ingen skulle få göra idag för den är alldeles för liksom hemlig och implicit och oklar och inte måste ha koll på den och inget system kommer stödja det och så där. Men det funkar ju när man inte har jättemycket it -system som ska kräva exakt struktur på allting. Det är bara människor som läser en perm och säger, okej den här personen är för då och då, det är för ett plus här, det är lugnt liksom. Eller om man har en, en, vad heter den, en konto.
En fysisk kontobok. Och det blir fel, man börjar utsträcka över den. Ja, det var fel. Man skriver ett rätt rad här. Och alla som läser det kommer att veta exakt vad det betyder. Men en dator förstår inte det här. Det är omöjligt för en dator att fatta såna grejer. Om man inte går in i massa exceptionella fall hela tiden. Och jag tror att det är de där små avviklingarna som man mellan människor så lätt kan kompensera för. Som system inte klarar av riktigt på ett sätt som inte är... Okej, vi lägger till en till abstraktion. Vi måste lägga till en revert transaktion typ här. PGA, bla bla bla.
Det där tror jag är extremt svårt att designa för i förhand. Nästan omöjligt att göra på ett bra sätt.
Patrik (20:47)
Preach!
Trollfursten (20:48)
Precis.
Anders Arpi (20:49)
Det är skönt. Alla håller med varandra och alla är negativa. Vad bra. Det är så det ska vara. Nej. Men det fanns ju någon föreläsning med Barry och Riley ihop med en DDD -fransås, såg jag. Jag har sett den tror jag också. Och där försöker de ju gifta lite, liksom, hands då, flum med något konkret arbetssätt och en arbetsdesignmetod, liksom. Kan inte du berätta lite mer om det, Adam, hur det är liksom vad som händer i verkligheten?
Patrik (20:50)
Hehehe
Trollfursten (21:01)
Yes, det gör du.
Jag har gått hans två av Barrys kurser och tycker att det är väldigt väldigt intressant. Och det sättet som han tycker att man ska kunna jobba med det här är att man ska göra en naiv arkitektur av det som man vill bygga. Och det kan man göra lite hur som helst. Det kan man göra med DDD eller så ritar man en låda som säger i systemet att det är en monolith som bara driftas på en Raspberry Pi.
Det spelar egentligen ingen roll hur denna naiver arkitekturen ser ut. Men sen efter att du har gjort denna arkitektur så ska du ta och lista stressorer. Det kan egentligen vara vad som helst som påverkar systemet. Ett av de exempel som man har är att det kommer en eldsprutande ödla och bränner ner Stockholm. Hur påverkar det systemet?
Patrik (22:11)
En klassisk stressor.
Trollfursten (22:12)
Precis. Och grejen med de här stressorerna är att det spelar ingen roll risken, sannolikheten att det ska inträffa, det spelar noll roll. För den här stressorn äldstbrytande ödla i Stockholm, om du har byggt din arkitektur för att kunna hantera det, då har du klarat att det blir översvämning i din datahall eller att det blir strömavbrott eller att du vill kunna...
Ja men ett datacenter i ett annat land eller någonting Så att oavsett vad du har för stressorer som du kommer på det kan ju vara att Finansinspektionen kräver att det kommer en ny rapport på alla transaktioner som börjar på G Hur påverkar det ditt system? Vad kommer du behöva röra på sig? Vad behöver du förändra för att du ska kunna ta och komma med den rapporten? Och utifrån en lista som du gör så kan du då se vad
Vilka delar i min arkitektur påverkas? Vad är det som går sönder? Vad är det som blir kvar? Och de delarna som blir kvar är då som man kallar en residual eller en rest. Askan efter att allting har brunnit ner. Och sen så tar du går igenom och kollar då på dina residuals och gör en ny arkitektur utifrån det. Förhoppningsvis så har du inte gått igenom alla dina stressorer utan du har ju varit förutsedande och gjort en jättelång lista så du har kanske tagit...
100 eller 50 som du har testat på din naiva arkitektur och de övriga som du har kvar, de kan du använda för att verifiera och se om din nya arkitektur är mer resilient mot de stressorerna.
Anders Arpi (23:55)
På ett sätt påminner det där mig om vad det nu heter. Det är liksom en DDD praktik där man sätter sig ner och utvecklar det och typ domän, experter och användare i ett möte och börjar snacka om vad de faktiskt gör på jobbet i sitt, sig vårdsystem, eventstorming precis. Jag har nog aldrig, jag har gjort det en gång tror jag men jag vet att det är många som tycker att det är bra i teorin men det är inte så många som gör det sedan i praktiken för det är jobbigt att få till och så där men det som...
Trollfursten (24:08)
Event storming eller?
Anders Arpi (24:23)
Man i alla fall kan få där att Janice in accounting säger att man måste ha stöd för negativa. Ja, för då behövs det ibland PGA, bla bla bla. Sådant som man aldrig vet som arkitekt. Man måste få verklighetens äldre drakare att komma in och förstöra för en. Just för att få någon som går och puttar på allting och slår hål i däcken på en. Det kanske är fyra däck för samma bil, det går inte. Tre däck skulle räcka.
Trollfursten (24:52)
De här sakerna som vi gör när vi tar fram de här stressorerna och när vi gör det här jobbet, för det är inte bara att ta fram den här stressorlistan utan det är även att vi ska kunna... att vi behöver ha en förståelse för företaget. Vi kanske börja med att göra en business model canvas för att analysera vad det företaget gör för någonting, vad är intäktsströmmarna, vad är kunderna. För det behöver vi ha en förståelse för att veta vilka stressorer som finns runt omkring oss. Vilka konkurrenter finns det. För det påverkar vilka arkitekturer som kommer vara livskraftiga.
På samma sätt att prata med... Eventstorm är ett jättebra sätt att fånga upp sådana här saker också. Och alla de här aktiviteterna som vi gör idag i de olika arkitekturomverken eller våra olika processer. Det kan man se som en repetition eller att man tar en promenad runt problemet. Den franska filosofen Deleuzian, han...
pratar någonting som heter Difference in repetition att varje gång vi tar och gör någonting så får vi en större förståelse för problemet eller området varje gång vi tar och går en promenad genom vårt hemmområde så lär vi oss någonting nytt och alla de här aktiviteterna som vi har de bidrar med någonting de bidrar med en större förståelse en större kunskap om problemområde som kommer
göra så att vi kan ta och komma fram med en bättre arkitektur i slutändan. Och det är inte för att DDD säger att ett ubiquitous language det måste vi ha för att vi ska kunna prata med varandra. Utan det är för att vi har pratat med varandra och fått en förståelse som är det som bidrar med. Inte att vi har en lång ordlista. Och samma sak med eventstorming. Det är att vi har pratat med varandra. Inte att vi har fått ut en lång lista med events. Utan att vi har fått vara i samma rum och pratat är det som är det viktiga.
Anders Arpi (26:50)
Jag får alltså på riktigt gåshud när du pratar om det här. För det slår an på någonting som jag tycker om så väldigt mycket och det är det här samtalet som det viktigaste man har som utvecklare och systemdesigner. Att prata med andra människor som designar system eller som kandomännen är så extremt viktigt och det finns ingen...
Det behöver inte vara en stressor -workshop enligt Barry O 'Reilly's 10 -stegsplan som han säljer online. Det gör han inte, utan det kan vara typ vad som helst. Det är inte så viktigt att man har en exakt plan utan att man bara börjar prata om någonting, om vad som helst kring det man ska göra. Det ger så mycket. Men ännu en gång är det svårare, för det är så svårt att då formalisera en process. Att anteckna för de här mötena.
Vad antecknar man? Vi kom på att den här kan vara ett svårt område. Den insikten kan vara extremt värdefull i praktiken. Alla vid teamet vet att den här grejen, när vi tar emot events, så kan det bli ett problem för att det är lite komplexa grejer här och där. Att veta det när man börjar bygga är jätteviktigt. Men att skriva på ett papper, det här kan bli svårt. Det är ju ett totalt meningslöst anteckning egentligen. Samtalet som vi...
som inte är en permanent logg, utan som förs här och nu. Och insikterna som inte heller kan på ett enkelt sätt permanentiseras är det mest värdefulla. Men det är också så svårt att förklara det här som en metod med stort M. För det är inte riktigt, det är min uppfattning i alla fall, det är inte riktigt en... Det är inte ett nytt SART man kan ta det här riktigt.
Trollfursten (28:44)
Det här är ett paradigmskifte i den underliggande filosofiska approachen till hur vi bedriver mjukvarararkitektur.
Det är inte att vi från det här korrekta till att kunna ha det här mer utforskande approachen. Den insikten fick ju mig att gå ner i det här kaninhålet. Som jag pratade med dig lite grann, R .P. Så jag har ju börjat köpa massa sådana här skumma franska filosoferböcker som bara ligger på hög och väntar på att få läsas för att jag vill komma till de här utbundsmaterialet i varför.
Anders Arpi (29:18)
Jag vill bara säga att Adam lyfte upp Simulacra och Simulacrum som ju faktiskt är grunden till The Matrix -filmenas flum. Bara en parentes.
Trollfursten (29:30)
Ja, men det är så intressant att kunna gå till de här källorna och materialet som Barry har utgått ifrån och se att det här går att koppla ihop i min vardag där jag jobbar. Att det här kan jag se är matchar mot vad som har formulerats här. Även om det är som han som har skrivit om Black Swan, Nasim Taleb, anti -fragile har han skrivit. I den boken så skrivs det om olika sätt för att kunna hantera den här...
Att vara antifragil, att inte system ska gå sönder, att inte saker ska sluta funka när det kommer saker som vi inte är beredda på, utan att vi ska kunna komma stärkta ur det. Och saker i den boken går att applicera i hur vi tar och bedriver våra nukvarustryck. Och det är samma sak i de andra äldreverken. Det går att hitta de här nycklarna för att få en förståelse för varför saker resonerar och känns rätt.
Anders Arpi (30:29)
Jag är väldigt förtjust i hans koncept med promenader. Jag tycker att det är en väldigt tilltalande liknelse i vad man gör med det här att man går och tittar på Löverken och går och funderar och går och petar lite och sparkar någon sten ner i en fors. Och att det är det som kan ge en ny insikt och förståelse för det man håller på med. Det låter ju väldigt flummigt men jag tycker det är något fint med...
När jag läste filosofi och det historier så var de här väldigt populära många gånger, de franska komplexa filosoferna. Men det fanns ju alltid en känsla att det här systembygge som saknar applicering. Nu är jag ju långt ifrån så fast kunnig som någon som doktorerar det här men som student då fick jag en känsla att det här är coolt, det är så komplext och intressant men det är inte så mycket verklighet här. Och jag tycker att det är härligt att känna att man...
Den här sättet att närma sig komplexitet som någonting svårgreppbart och som måste liksom skärskåras från många håll. Att den kommer tillbaka i detta tråkiga yrke som är systemutveckling. Jag tycker att det är väldigt fint. Det är något härligt med det för det är ett erkännande av just det här hur komplext det verkligen är. Det som man sitter med. I alla fall att göra det. Gör det rätt över lång tid. Många gånger om. Det är ju svårt.
Trollfursten (31:59)
Det är för man kan ju ha tur ibland.
Anders Arpi (32:03)
Kanske.
Trollfursten (32:05)
Jag gillar verkligen den här promenadmetaforen också för vad vi gör för någonting i den här insamlingen inför att vi ska bygga någonting eller även under processen när vi gör när vi sitter och kodar och börjar göra anpassningar. Alla de här promenaderna till kaffemaskinen och stöter på någon information eller till den här att promenera ut till kunden och sitta där. Det är också väldigt viktig informationskäll också för att kunna skaffa sig kunskap.
Patrik (32:34)
Nu ska vi inte överdriva här va?
Trollfursten (32:36)
Nej, vem har någonsin suttit och pratat med en kund eller en slutanvändare? Finns det sådana ens?
Patrik (32:40)
Puss.
Anders Arpi (32:43)
Jag kan vara lite jävelens advokat här och ställa lite motfrågor eller lite som vi själv haft lite funderingar kring det här. Om vi säger nu det jag pratar om tidigare det här om att det skapas en förståelse för system som bygger som finns mellan människor i huvuden på oss och i våra samtal. Hur, även om då vi har ett sådant team som genomgår ett sådant perfekt process enligt det här flummiga sättet att närma sig det här. Flummiga med positiv märkelse.
Man bygger ett system som blir okej. Hur... Hur traderar man den kunskapen på ett bra sätt? Som inte bara är att man måste ha ett års babbelmöten och promenader med nästa utvecklare i teamet för att de ska förstå också. Hur omsätter man det här i dokumentation eller i kod som är lättläsa? Var kan man kodifiera det här? Man kan alltid läsa all kod, men det är inte så bra sätt att ta till sig systemet.
Patrik kom igen nu du kan det här.
Trollfursten (33:41)
Hehehe
Patrik (33:45)
Jag vet inte.
Ja, de kanske vet.
Trollfursten (33:50)
Jag skulle säga att man behöver skriva ner de sakerna som man hittar i babbelmöterna. Man måste försöka identifiera vad det är för någonting som man har hittat. Har man tagit fram en lista med stressorer och testat att stressa sitt system så är det en bra beskrivning över varför man har fattat vissa beslut.
Men jag tycker det är jättesvårt att veta vad man ska skriva, hur man ska skriva, vad behöver man dokumentera?
Patrik (34:24)
Någonting som jag har upptäckt senare i tid är såna här Architecture Decision Records. De tycker jag är ganska smidiga. De blir ganska, som att säga, det är inte så formellt men man för ändå någon form av dagbok över de besluten man tagit när man byggt någonting. Så jag har till och med börjat köra på mina privata grejer och open source.
Trollfursten (34:47)
Och då har vi jävla jöksan.
Patrik (34:53)
och trylar senaste.
Ja, bara en tanke om vad det är man ska dokumentera.
Anders Arpi (35:00)
Jag ser framför mig från filmen Social Network, Mark Zuckerbergs live -bloggande när han bygger Facebook. Jag tänker ofta på det och genuint känner att jag önskar att jag gjorde det sådär mer just för att det kan ge ett värde efteråt. Att man kan förstå besluten. Inte perfekt, men ganska bra att få en bild av, okej, det var den här kontexten. Det var de här tankarna som styr det här beslutet. För det saknas det mest alltid tycker jag i dokumentation.
Trollfursten (35:24)
Hur mycket vikt lägger du när du skriver dem kring just den kontexten, det sammanhanget när du fattar beslutet? För oftast så finns det ju någon form av spårbarhet i vilket beslut som är fattat. Det går att se i ett diagram eller i att det finns en lista med vilka beslut som är fattade eller vilka tekniker som använda. Men just den här kontexten ser man ju inte där. Är det någonting som du ser som viktigt när du försöker skriva de här ADR -erna själv eller?
Patrik (35:24)
Khm.
Ja, men kontext... Det är väl extremt viktigt så här om man ska förklara varför man gör en viss ändring någonstans. Men det som jag gillar med det är att man får saker samlade på ett ställe. Det ligger inte så här... Ja... Det är som att säga. Vissa grejer kanske kommer som en giratickets, andra grejer kanske är nån som bara... Oh shit, den här grejen hade jag glömt av. Kan vi fixa det lite snabbt?
Kontext är väl jätteviktigt att få med när man beskriver varför man gjorde en viss ändring. Inte bara jag har gjort ändringen. Då kan du lika väl kolla på kommitthistorik eller nåt annat gira eller vad som helst. Försök att få ner orsak till ändringen och vad som ändrades.
Och jag har faktiskt redan fått anmälning för det för att det var en som kommer fråga mig bara för några veckor sedan. Varför har vi gjort den här ändringen? Hittade inte någon ticket för den. Och så. Men det var för att den här anledningen här.
Trollfursten (37:04)
Nice!
Patrik (37:05)
Och då hade jag glömt av det.
Trollfursten (37:08)
Vilken nivå lägger du dina architectural decision records på då? När du tar och skriver dem. Är det för både högt och lågt eller är det som...
Patrik (37:16)
Man kan använda dem lite hur man vill. Det finns ju hur många sådana olika mallar för ADR som helst. Men jag använder en jätte enkel mall.
Inte för... det är väl mer liksom...
Det är som att säga.
Jag lägger inte till vad som helst där i. Men när det är någonting så här liksom att... Den här grejen vill jag kanske kolla upp senare varför jag gjorde den här ändringen här.
Då kan jag skriva ner det. Men inte så här... Ja, vi... ...flyttar den här saken hit som inte har någon...
Jag flyttar det här dokumentet i mitt repository. Det är inte intressant.
Anders Arpi (38:08)
Det tycker jag återkommer när man diskuterar kommentarer i kod med folk. Många har ju åsikter om det eller i alla fall förr i tiden, det kanske inte är så aktuellt längre, men då har vi väldigt mycket åsikter om det förut om man ska aldrig ha kommentarer i kod för att koden ska vara dokumenterande eller testerna ska och så där. Men någonting som nästan alla håller med om är att det är okej då att lägga in en sådan här, det här ser konstigt ut, men det beror på det här och det här.
Och en mening, typ så här, we don't use Levenstein distance due to cross language difficulties typ. Det säger så mycket om varför en sak gjordes. Ja, och den meningen, precis den meningen kan ge så mycket mer än tester, än koden i sig och ens långt ticket där vi ska implementera det här liksom. Som någonstans kanske har ett varför, men att det är den centrala delen här, den här grejen.
Trollfursten (38:44)
Det ger en kontext utav någonting som inte syns i koden.
Anders Arpi (39:01)
Det är inte exakt samma sak som en ADR, men just det här när man gör konstiga grejer i koden, alltså även en konstig kommitt. Att veta att det kommer alltid stå där, eller ja, så länge ingen ändrar på det. Men det kommer alltid finnas där i kommitten att... En liten kommentar om varför det här dumma beslutet togs, liksom. För att det var därför och därför.
Trollfursten (39:17)
Om man inte riktigt vet vad ADR är så har jag läst en jättebra bloggpost av Mikael Nygaard som jag länkade till er här nu som jag tycker förklarar det på ett väldigt bra sätt och som är ganska kortfattat. Och sen är den formulerad som en ADR i sig själv också.
Patrik (39:17)
Men men.
Anders Arpi (39:34)
Jag blir alltid lite orolig när jag hör såna här termer som har tre bokstavsförkortningar att det kommer vara ett långt formulär som måste fyllas i likadant varje gång och så kommer jag sluta att göra det för jag pallar inte.
Patrik (39:44)
Du har rätt och du har fel för det kan vara ett jättelångt formulär. Det beror helt på vilken mall du väljer att använda.
Trollfursten (39:57)
Men det bästa är en fil vid Topsidian -valv.
Patrik (40:00)
Ja. Jag vet inte om det var ironiskt, men typ. Typ. Nej, men jag ser på ADR som är immutable. När de är väl skrivna så får man inte ändra i dem. Det har väl fördelen gentemot kod, om man skriver kommentarer i... Kring något kontext, kring en ändring. Det kan alltid vara så att någon...
Trollfursten (40:04)
Jag vet ju inte heller.
Patrik (40:28)
ta bort den kommentaren eller ändra beteendet en gång till efteråt. Då har man ett ställe som man kan gå och titta på.
Anders Arpi (40:40)
Det bästa är när man har en kommentar i ståget, we don't use Levenstein distance. Nästa rad, levenstein .comcalculate. Och så bara, va fan? Det har ju hänt några gånger. Så absolut. Ja, men det kanske kan summeras det här lite med ADR och potentiellt också kommentarer. Men speciellt kanske ADR, liksom sätt att tänka är att man hanterar dokumentation som en historisk artefakt alltid.
Patrik (40:45)
Hahahaha
Anders Arpi (41:05)
Det var väldigt sympatiskt till att det är utgångspunktet att all dokumentation, all mötes dokumentation är det här pratar vi om. Det här kom vi på då, det här sa vi då. Det här till och med bestämde vi då. Men att aldrig hantera det som att sen ett år senare det står ju här att ni gjorde det här. Varför inte så nu? Det var det vi sa då. Och att det får vara liksom dess mandat, att det är en historisk dokumentation.
att det inte är liksom en spess eller ett så här imperativ dokumentationen om hur man måste göra i framtiden utan att det är att förvara det. Det tycker jag kan vara bara liksom som en...
Ett framing, bara man tänker på det. Jag tycker det kan räcka med att bara tänka på det. Man ska inte tänka när man skriver det, men när man läst dokumentationen. Att tänka på att det här var skrevs då. Även om de som skrev det inte tänkte på att det skulle vara historiskt, så tänker jag det när jag läser det. Men det kan spara en ganska mycket huvudvärk och liksom... ...fnulande, onekligen.
Patrik (42:05)
Framförallt tycker jag att styrkan är att man samlar saker på ett ställe. Om man har Jira, GitaBishes eller Komits är det svårnavigerat om man letar efter en viss anledning till att någonting ändrades.
Trollfursten (42:05)
Helt klart.
Patrik (42:27)
För alla vet att efter att du färd med giraticket går du aldrig in och tittar på den. Samma sak med en issue i github eller andra system. Kommits kanske man kollar lite då och då. Så man går tillbaka och kollar någonting. Men ADRs i ett repo är perfekt för att allting bara är där. Det kan vara ett dokument eller fler dokument men liksom. Det är bara ett ställe att titta på. Alla förändringar som har skett.
Anders Arpi (42:55)
Och till och med i PR -en också kan det vara med dessutom. Vilket ju är jättesnyggt.
Patrik (42:59)
Exakt, du kan linka in den i en PR eller i en kommitt och nämna den där.
Trollfursten (43:00)
Mm.
Om man ska gå tillbaka till Barry, han pratade om det på den första kutchen som gick, så sa han att kring dokumentation och Software Architecture Descriptions saddar. Att när han börjar och kommer in på ett nytt ställe, ett nytt uppdrag där han ska göra någonting så öppnar han ett tomt Word -dokument och sen så skriver han ner, typ som ADR -er. Kontinuerligt i slutet på varje dag. Utifrån det här, det här blir hans, ja men som ett dagbok nästan över
projektet över vad han gör och utifrån den kan han sedan lyfta ut till att göra en sadd som ska kunna vara till något time eller någonting men där har han bilden formulerad och samlad för sig själv.
Patrik (43:50)
Smart.
Anders Arpi (43:52)
Jag tror att jag gör det för lite faktiskt. Det är nog någonting jag kanske ska öva på lite. Mest för att man är den här, man är alltid samma idiot att det här är uppenbart. Det här kommer jag att komma ihåg. Det är lugnt. Det här var ju bra beslut, tydligt. Vi skrev en chat här, det var typ bara så här, det är lugnt. Sedan en vecka senare var det vi sa om det här. Jag måste söka i Teams för att hitta en förklaring för att vi tog det beslutet. Det är liksom straffarbete nästan.
Patrik (44:15)
Man överskattar alltid sitt eget minne.
Trollfursten (44:17)
Mm, det är jag.
Patrik (44:19)
Stor aldrig fel.
Anders Arpi (44:22)
Men Adam, du som är indoktinerad i Barry O 'Reilly filosofiska och teoretiska modell. Hur har det påverkat dig på något sätt i jobbet? Försöker du applicera grejerna på något sätt? Går det än som man vill att göra det idag i ett normalt projekt? Eller det mer som ett sätt att tänka?
Trollfursten (44:44)
Sättet att tänka och sättet att resonera har jag helt klart tagit med mig och börjat använda mig av. De praktiska verktygen inte så mycket än. Men just den här approachen till varför vi gör saker har färgat ganska mycket av hur jag agerar och tänker. Och det är ju anledning till att jag har sökt mig till mer arkitekturella diskussioner efter att ha...
sett hans föreläsning och gått kurserna. Det har fått mig att tycka att det är ännu mer intressant än vad jag tyckte det var tidigare.
Anders Arpi (45:20)
Hur gör man ett bra jobb om man kommer in som arkitekt eller den typen av roll, om det är teknik eller vad det kallas, men när man ska få... Vi ska bygga något nytt eller bygga en ny aspekt eller vad det nu är i ett system och du ska... Det här är till alla, men vi är inte på att reda det. Men du ska liksom utreda och komma ett förslag om ni ska bygga. Vad gör man? Hur är det ett bra sätt att göra det på? Hur är det ett bra sätt att göra det?
Trollfursten (45:47)
Det beror ju på vilket ramverk som du arbetar enligt då. Togaff eller DDD eller... Nej men... Jag skulle ju börja med att försöka hitta en... En formförståelse för... Företaget och organisationen, vad det är för någonting. Dets plast i omgivningen. Skrissa upp en Business Model Canvas. Förstå... Inkomstströmmar, förstå kunder, förstå konkurrenter. För det behöver du ha med dig. När du ser vilken roll du har. Systemet har.
Och sen så se hur den här förändringen kommer att påverka och vilka försöka hitta stressorer som kan slå sönder det här. Jag tror att det är en ganska bra sätt att börja oavsett egentligen vilken skolning du har sen. Att använda det till de verktygen så har du en bra bas att kunna resonera vidare utifrån.
Anders Arpi (46:40)
PART 2
Patrik (46:42)
Jag.
Anders Arpi (46:44)
Hur gör du? Eller hur vill du göra?
Patrik (46:46)
Hmm...
Trollfursten (46:48)
Går ju in på start .spring .io Väljer javasheet JPA
Patrik (46:51)
Ja.
Anders Arpi (46:51)
Export.
Patrik (46:55)
Jag tror inte jag är så strukturerad som Adam. Generellt när jag jobbar är jag mycket på att käna. Det är inte så mycket... Jag vet inte vad jag ska säga riktigt.
Anders Arpi (47:10)
Mer av en Clint Eastwood approach. Du vandrar in, skjuter lite, går därifrån.
Patrik (47:12)
Exakt. Men jag går inte in i de roller som Adam gör. Utan jag ser mig själv som en ren programmerare.
Trollfursten (47:23)
Jag har ju inte gått in i sådana roller så mycket. Jag doppar tårna i vattnet och ser om det är farliga hajar.
Patrik (47:30)
Mm.
Anders Arpi (47:30)
Men när du säger sådana roller är det det man ibland med lite lite flin brukar kalla för powerpoint konsult eller architect eller är det närmare verkligheten än så?
Patrik (47:42)
Fugger med eller?
Anders Arpi (47:43)
Jag vet inte vem frågar.
Patrik (47:47)
Ehm...
Trollfursten (47:48)
Det blir nog, ja det är nog lite i random som man flinar på det sättet åt men jag vill ju inte vara en powerpoint -utvecklare utan jag vill ju kunna ha en koppling till verkligheten. Att jag vill kunna ha en förståelse för vad som byggs och hur det byggs. Och det tänker jag att en bra architekt måste ha.
Anders Arpi (48:04)
Men det där tycker jag är kul att höra att du inte säger, jag brukar fundera på ska vi ha redis? Ska vi lastbalansera här? För det där kan man ju snabbt hamna i liksom, vi måste ha event sourcing, det är viktigast av allt. Alltså vi har event sourcing, inget annat viktigt liksom. Och så bygger man utifrån det. Och sen kommer man på att vi inte alls behöver event sourcing för att ingenting är relevant historiskt för det här de gör, till exempel.
Trollfursten (48:16)
Mm.
Anders Arpi (48:29)
Men där tycker jag ju, jag är nästan lite tackigt att ta upp det här powerpoint -architektur men det har ju funnits, jag tror det finns ett värde i den typen av roller när de förmår att hålla sig just kring det här affärsmässiga flödena och att ha en beskrivning som är relevant både för sig då beställaren i termen av att säga att det är en vd eller högeroll eller vad det är som beställer någonting om man har någonting byggt. Att man kan beskriva...
delas affär för dem. Om man kan stäva av, visst är det det här, flödena ni har, visst är det så här ni ser på affären. Och att kunna ta det sen till ett mer konkret möte med IT -delarna, utvecklarna, systemet, arkitekterna och så vidare och prata om det här som all överens om det är det här som är systemet, det är det här vi ska bygga.
Trollfursten (49:19)
och egentligen då visa hur de värdeskapande flödena realiseras i arkitekturen. För det är ju det viktiga för den PowerPoint -arkitekten.
Anders Arpi (49:29)
Men om man pratar om tekniska lösningar då, nu är vi exakt sju minuter kvar säger vi på vår inspelning, men den tekniska aspekten, hur samspelar det med residualitets teori? Är det samma sak egentligen?
Trollfursten (49:29)
Tack för i dag.
Vad menar du då när du säger de tekniska aspekten? Vilket språk vi ska bygga det i eller? Eller vilken monstermaskin på Hertz vi ska köpa?
Anders Arpi (49:49)
Om vi bortse från... Ja, kanske inte så illa. Precis. Säg saker som... Behöver vi använda en databas? Hur ser det ut med uppdelningen i vertikaler eller i olika tiers av storage? Behöver vi använda en specifik domänmodell eller då en domänmodelleringsmetod eller TDD?
Det behöver inte vara ner på EC plus plutträtt eller inte men lite med de mer styrande tekniska besluten.
Trollfursten (50:26)
Men ganska ofta så är det ju så att en organisation har ett tekniskt bagage. Man har oftast någonting som man kan som man är bra på. Och det kan ju vara ganska dumt att göra avsteg från det oavsett vad man tycker om det eller inte. Ofta när vi bygger någonting så har vi någon slags känsla för vad som kan vara rätt nivå att lägga det på.
Vi skulle nästan alltid kunna börja med att hålla saker i en harshmap i minnet och sen så börja där. Men innan vi har landat där vi borde vara så måste vi gå på minor. Nej men om det kraschar så tappar vi all information. Det håller inte. Den sortens promenader runtomkring problemet gör vi också med det här. När vi diskuterar vad vi har för behov. Och i de här promenaderna vi pratar med
verksamheten eller vi pratar med företagsledning eller pratar med de som jobbar i teamen så lär vi oss om vad vi har för Det blir egentligen att vi fångar upp icke -funktionella krav i det och de icke -funktionella kraven tar ju och dikterar våran tekniska lösning mer än vad vi tror Om det är okej att vi tappar all information vid en crash, varför ska vi då ha en databas?
Anders Arpi (51:48)
Ja, det där slår an på en av mina käpphästar som är det här att när man pratar om teknisk arkitektur eller systemarkitektur, eller vad vi kallar det, men att det bästa man kan göra är att göra så lite som möjligt från början och ta beslut som går att backa så länge det bara går. Och skjuta upp alla beslut som inte går att backa så billigt i alla fall, så länge det går. Att bara putta fram den här gränsen för när man har gått för långt för att bara säga vi slänger allting, skitsamma.
För när man kommer utöver den gränsen så har man ju ändå ett jättemycket risk, ekonomisk risk för företaget att man kan inte backa ifrån. Vi får inte bygga ett skitsystem för dubbelt så mycket utgifter men vi hinner i alla fall bli klara innan vad det nu är. Så det där är nog det som jag brukar tänka på som är systemarsitektens viktigaste roll är att hålla tillbaka alla som, vi måste köra Redis, vi måste köra det här, nej skitsamma.
Det är inte viktigt än, och det kanske aldrig blir viktigt. Att skjuta fram de här besluten så långt det bara går. Och att ta beslut som går att backa på så länge det bara går istället. Det var min slutpläddering.
Trollfursten (53:00)
Där också tycker jag att vi kan ju, vi ska ju göra så enkelt men så bra som möjligt. Om vi har lite blick framåt vart vi kan landa någonstans, om vi har koll på de stressorer som finns, om vi har koll på vilka problem som vi kanske kan ställas inför så kan vi ju ha med det i vår lösning. Vi kanske kan börja med att ha en platt fil struktur eller en enkel JSON som vi använder för att lagra informationen i men
Om vi har byggt vårt system så att vi inte lagringen läcker in i resten av systemet så kan det ju vara relativt lätt att byta ut dem mot en databas eller mot ett annat system eller någonting. Så den där blicken framåt ska ju inte göra så att vi absolut tar använder Redis. Men vi ska ju inte bygga någonting så att vi inte kan koppla in Redis när vi behöver det.
Anders Arpi (53:58)
Nej, om man bygger ett system, säg transaktions tillbakarullning, en databas. Om det är centralt i det man designar, liksom, det kan man inte köra med flatfiler på disk. För då kommer man behöva, oh shit, transaktionen måste flyga med överallt, men inte ens finns det en som är i koden.
Trollfursten (54:06)
Nej, precis.
Patrik (54:13)
Hur tycker du om dålig fantasi? Det går väl alldeles utmärkt. Du behöver bara en databas som bara har en fil på en hårdisk någonstans. Så det är bara att man skriver sin egen databas. Men jag skojar ju bara.
Trollfursten (54:14)
Hahaha!
Anders Arpi (54:15)
Hahaha!
Ja, och ett mutex. Ett. Det räcker.
Ja, och det är därför Patrik är en K -dapa fortfarande.
Nej då, du måste ha två filer.
Trollfursten (54:36)
Nu måste jag ha två... två databaser.
Patrik (54:39)
En för varje rad i tabellen.
Anders Arpi (54:43)
Ja, jag håller ju på att gå en slags SQLite -frälsningsvandring i rivet men det kan bli ett annat samtal på tal om fila på disk.
Trollfursten (54:55)
Och jag är på vandring efter den ultimata textacken som sprider glädje i själen när man sitter i hobbyprojekt i den.
Patrik (55:01)
Tips inte spring webb.
Anders Arpi (55:04)
Vad är den då? Har du öbbatsar spontant? Du har 40 sekunder på dig. Vart är du nu i det sökandet?
Trollfursten (55:05)
Jag vet inte.
Just nu pendlar det mellan raw JavaScript in Node, Kotlin eller Golang. Kanske Index PHP.
Anders Arpi (55:24)
Fyra ganska lika lösningar. Det är skönt att höra.
Patrik (55:27)
Har du provat Swift?
Jag skojar inte, har du provat Swift? Alltså... Nej?
Trollfursten (55:33)
Nej, då inte.
Anders Arpi (55:34)
Det verkar ju rätt snyggt tycker jag, förutom att det inte finns så mycket i det. Fem sekunder kvar. Jag sa inget, jag ångrar mig, jag backar. Jag sa inget. Nej, vad skulle du säga Patrick?
Trollfursten (55:40)
Det är ju baserat...
Patrik (55:41)
Det finns ganska mycket i det.
Nej, nej, det är bara frågor.
Trollfursten (55:49)
När Swift kom så var det väldigt mycket syntax som var plånat från Groovy och Groovy var ju väldigt trevligt att jobba i tyckte jag.
Patrik (55:55)
Ja, jag vet inte, senast har jag lekt med väldigt trevligt språk, rent generellt. Och många tror att det bara är för iOS, och det är det inte. Det finns ju för Windows och Linux. Kan till och med bygga... Ja.
Anders Arpi (56:02)
Det kommer ju upp ett samtal... nej förlåt.
Trollfursten (56:10)
Jag får kika på det. Vi behöver kanske fler spår att gå här.
Patrik (56:14)
För jag tycker att syntexen är fantastisk och språket är ergonomiskt.
Anders Arpi (56:22)
Min bild av Swift är lite att det är det närmaste Rust man kommer utan att det är så jävla jobbigt som det är Rust. Stämmer det eller? Ja, skönt!
Patrik (56:29)
Ja, det måste vi göra.
Trollfursten (56:31)
är det sparkar glittrade om dig när du skriver det sparks joy det är en av de viktigaste delarna i min ultimata text tack
Patrik (56:37)
Exakt. Sparksjoy.
Anders Arpi (56:43)
Det är väl papper och penna i en bok man självbundit. Inte den ultimata textacken. Då säger vi så. Tack till Adam och Patrik och mig för dagens samtal. Hej då allihopa!
Trollfursten (56:47)
Det är en ultimata.
Tack själv, roligt att få vara med.