Beste av 2018 i teknologiske samtaler

I løpet av de siste to årene har jeg publisert en liste over mine favoritt tech-samtaler fra året før (her er 2016-utgaven av dette innlegget og her er 2017-utgaven).

Denne listen er ikke på noen måte omfattende, og jeg er sikker på at det er mange teknologisnakk fra 2018 som jeg bare vil oppdage mye senere. Men blant samtalene jeg deltok eller så på, var dette noen av de beste (i ingen spesiell rekkefølge).

  1. Framtiden til mikroprosessorer, Sophie Wilson

Sophie Wilson, den kjente pioneren for den originale ARM-brikken, ser ut til å ha troen på at Moores lov kommer til en slutt (sammen med visse andre som er oppført senere i dette innlegget). Dette var en fenomenal samtale fra JuliaCon som går inn i mikroprosessorers historie, evolusjon og fremtid.

video

2. The Hurricane's Butterfly: Feilsøke patologiske systemer, Bryan Cantrill

To av samtalene som kom til listen over forrige år var sebraer helt nede og avlusing under ild: Hold hodet når systemer har mistet tankene. Dette var en snakkis på lignende måte og levert med den typiske Cantrillian teft, vim og handlekraft vi har forventet. Programvare er bygd som en bunke abstraksjoner, med tilsynelatende mindre problemer i ett lag (sommerfuglene) som har potensial til å forvandle seg til systemiske patologiske ytelsesproblemer i et annet (orkanen). Gitt en slik orkan, hvordan finner man sommerfuglene?

Lysbildevideo

3. Lukk løkker og åpningsminner: Hvordan ta kontroll over systemer, store og små, Colm MacCarthaigh

Jeg har riktignok ikke sett alle samtalene fra AWS re: Oppfinne, men av de jeg så, var dette muligens favorittpraten min. Den fastsetter noen designprinsipper for å bygge svært stabile og pålitelige systemer (for eksempel kontrollplan).

  1. Kontrollsum alle tingene
  2. Kryptografisk autentisering
  3. Celler, skjell og "Poison Tasters"
  4. Asynkron kobling
  5. Lukkede tilbakemeldingsløkker
  6. Små skyv og store trekk (for konfigurasjon)
  7. Unngå kaldstarter og kaldt-cache
  8. throttles
  9. deltaer
  10. Modalitet og konstant arbeid

Det var fascinerende å lære hvordan visse antimønstre og uintuitive design faktisk kan bidra til å forbedre stabiliteten til systemer. Den kanskje mest interessante delen av samtalen var ideen om at stabile kontrollsystemer krever en "PID-loop" - proporsjonale, integrerte, derivatkomponenter, og at det å kunne se på systemets design og plassere om det mangler noe av dette er en supermakt. Dette er første gang jeg hører om denne "PID-loopen"; foredraget anbefaler boken Designing Distribuerte Kontrollsystemer for å lære mer om hvordan prinsipper for kontrollteori kan gjelde for distribuert systemteknikk.

Det var også interessant å lære hierarkiet eller prioriteringene ved AWS: sikkerhet, holdbarhet, tilgjengelighet, hastighet.

Videobilder

4. A Golden Age for Computer Architecture, David Patterson og John Hennessy

Dette var en fantastisk snakk om mikroprosessorers historie og utvikling, overgangen fra CISC til RISC-maskiner til slutten av Moore's Law og Dennard-skalering, som igjen gir enestående muligheter for fremskritt i det "domenespesifikke arkitekturen" -rommet. "Domenespesifikk arkitektur" inkluderer begge fremskritt innen maskinvare (nevrale nettverksprosessorer for maskinlæring som TPU, til NVIDIAs GPUer til FGPA) sammen med domenespesifikk programvare (som Swift for TensorFlow). Foredraget avsluttes med historien om begynnelsen og veksten av RISC V ISA.

For de som foretrekker en skrevet artikkel fremfor en video, har denne månedens Communications of ACM en artikkel forfatter av Hennessy og Patterson (forfattere av den berømte boken Computer Architecture) om nettopp dette emnet. Moores lov for transistorer kan være avsluttet, men det ser ut til å være en Moore lovlig vekst i antall maskinlæringsartikler som er publisert de siste årene.

Video [Hennessy at Stanford, ~ 1 time]

Video [Patterson på Facebooks @ Skala-konferanse ~ 30 minutter]

5. Safe Client Atferd, Ariel Goh

Dette må være åpenbart for gamle hender med distribuerte systemer, men det er verdt å gjenta at klienter er en viktig del av et distribuert system og dermed må delta i resiliensinnsats. Dette er en fantastisk snakk fra SRECon Asia / Australia om beste praksis for klientdesign for å forbedre elastisiteten i hele systemet. Teknikker som foreslås inkluderer jitterende klientforespørsler, legge til tilfeldighet slik at alle klienter ikke ved en tilfeldighet ender opp med å synkronisere når de fremsetter forespørsler, når de ikke skal prøve på nytt, jittering prøver på nytt, prøver på nytt med eksponentielle tilbakeslag (og samtidig gotchas), "prøve på nytt budsjetter" (som feilbudsjetter ), flytte noe av kontrollen til serveren og etablere en tilbakemeldingssløyfe mellom serveren og klientene, tilpasningsfull throttling på klienter og mye mer.

video

6. Hvordan tjene og beskytte (med klientisolasjon), Frances Johnson

Dette er nok en utmerket samtale fra SRECon Asia / Australia om å beskytte en tjeneste som Google Maps (med en mengde interne og eksterne klienter) mot overbelastning. Foredraget berører problemer som systemoverbelastning (og tilhørende problemer som nedstrømmer som ikke glemmer systemets overbelastning), fallende feil, fallgruvene til statiske kvoter, fordeler og ulemper med å implementere grasiøse nedbrytningsteknikker på forskjellige lag i stabelen (klient, kant, frontend, backend).

video

7. Applied Performance Theory, Kavya Joshi

Dette er en utrolig snakk (som alltid) av Kavya fra QCon London om hvordan man bruker ytelsesmodelleringsteknikker for å kunne svare på spørsmål som hvilken tilleggsbelastning et system kan støtte uten å forringe responstid og hvordan å oppdage et systems bruksflaskehalser. Foredraget fører oss først gjennom et typisk eksempel på webserver for å demonstrere hvordan man kan analysere ytelse i “åpne systemer” etterfulgt av et eksempel på “lukkede systemer”, og hvordan begge henger på forskjellige forutsetninger og krever forskjellige teknikker for å analysere.

Lysbildevideo

8. Amazon Aurora: Designhensyn for skybaserte relasjonsdatabaser med høyt gjennomstrømning, Sailesh Krishnamurthy

Dette var en absolutt knakende tale fra Facebooks @Scale-konferanse om noen av designvedtakene og avveiningene som ligger til grunn for Amazon Aurora, lagringsmotoren som driver mange populære AWS-databasetilbud. Det påstås at Aurora skalerer automatisk opptil 64 TB per databaseforekomst og leverer høy ytelse og tilgjengelighet med opptil 15 lese-kopier med lav latens, gjenoppretting av punktum, kontinuerlig sikkerhetskopiering til S3 og replikering i tre tilgjengelighetssoner.

Det er to [1] [2] medfølgende meldinger utgitt av Amazon om Aurora. Foredraget refererer spesielt til mange punkter fra andre artikkel, med den viktigste takeawayen at den distribuerte konsensus dreper ytelsen og at lokal stat faktisk kan være en god ting. Med bruk av en uforanderlig logg som sannhetens kilde, unngår Aurora distribuert enighet for medlemskapsendringer ved å utnytte noen "oaser av konsistens" med bruk av epoker som vakter som en form for skrivekvorum og unngår å gjøre quorum som helt lest. Det er interessant i en tid der transaksjonssystemer gjør noe av et comeback og Googles forkynnelse om hvorfor vi bør velge sterk konsistens, når det er mulig, Amazon plukker forskjellige avveininger.

video

9. Future of FoundationDB Storage Layer, Steve Atherton

Dette var en spennende foredrag om fremtiden til Storage Layer for FoundationDB fra FoundationDB Summit. FoundationDB er en distribuert, bestilt nøkkelverdi-butikk, men selve lagringslaget er ikke-distribuert og får tilgang til ved en enkelt prosess fra en enkelt tråd. Praten går inn på kravene til en ny lagringsmotor, ikke-krav (samtidige skribenter, lav forpliktelsesforsinkelse), deretter utforsker fordeler og ulemper ved flere datastrukturer du jour (B + trær, LSM-trær) og årsakene bak å plukke Redwood versjonert B + tre.

video

En annen stor foredrag fra FoundationDB-toppmøtet var den på dokumentlaget, videoen av denne finner du her.

10. Autonom Testing and the Future of Software Development, Will Wilson

Først av alt, Will er muligens en av de beste foredragsholderne jeg noensinne har sett snakke (hans forrige foredrag om Testing Distribuerte Systemer med Deterministic Simulation fra Strangeloop 2014 er en av mine favoritter til alle tider).

Dette er en fenomenal samtale fra det stiftelsesmøte FoundationDB Summit som gjør en ganske overbevisende sak for en AI-drevet tilnærming til testing. Praten identifiserer tre hovedproblemer med testing: skjørhet (testen din bygger på egenskapene til systemet ditt som er tilfeldige - det er ikke de du trodde du testet), mangel på uttømmendehet og flakiness.

Foredraget argumenterer for at tester er bra for å få opp regresjoner, men nesten helt ubrukelige for å oppdage ukjente. Samtalen anser alle de nevnte problemene som symptomene, og det virkelige underliggende problemet er at testing fremdeles er helt manuell. Selv “automatisert testing” innebærer bare at Jenkins kjører en testsuite manuelt forfattet av mennesker. Praten legger deretter opp drømmen om autonom testing som behovet for automatisert oppretting av tester, i tillegg til automatisk utførelse av tester.

video

11. Designing Distribuerte Systemer med TLA +, Hillel Wayne

Dette var en fantastisk tilgjengelig foredrag fra CodeMesh om bruk av formell spesifikasjon for utforming av distribuerte systemer. Tenk på det som en skånsom introduksjon til TLA +. Tilbudelige inkluderer inkluderer:

Gi et system nok tid, og det vil gjøre alt, inkludert mislykkes.
Kode er ikke design. Koden viser ikke hvordan systemet ditt fungerer. Det er bare implementeringen; det er ikke meningen at det skal være ditt design, det kan ikke være ditt design. Og hvis du tror du kan designe et system og forstå et system med bare koden, har jeg en bro for å selge deg, og jeg skal selge det deg to ganger, samtidig.

video

12. Hva vi gjorde feil: Leksjoner fra fødselen av mikroservices hos Google, Ben Sigelman

Dette var en hvirvlende snakk om hovedkomponenten til distribuert databehandling hos Google, som berørte alt Google fikk rett til praksis som ikke var helt, men som hadde sterke paralleller til det vi i dag kjenner som ”mikroservices”. Praten belyser hvor den brede bransjen faktisk gjør visse ting bedre enn hvordan Google gjorde det (for eksempel servicenettverk), når og hvorfor emulering av Googles teknologiske valg og praksis ikke fungerer bra for resten av oss og hvorfor det blir spesielt viktig å kunne svare på visse typer spørsmål før du tar i bruk arkitektoniske paradigmer du jour (for eksempel “serverløs”).

Videobilder

13. Distribuert Log-Processing Design Workshop, Laura Nolan, Phillip Tischler, Salim Virji

Dette er en helt utrolig samtale om praktiske forhold ved arkitektering av et distribuert system i stor skala, inkludert hvordan man skal nærme seg skalering, hvordan man kan evaluere avveininger langs forskjellige akser samt tonnevis med baksiden av konvoluttberegningene for å rettferdiggjøre hver beslutning.

SRE-arbeidsboka (gratis tilgjengelig på nettet) fra Google har et helt kapittel kalt Non-Abstract Large System Design dedikert til nettopp dette emnet, og jeg har hørt at det er det avgjørende intervjuet i hele Google SRE-intervjusløyfen, ettersom det er det som er statistisk mest sannsynlig å reise opp en kandidat etterfulgt av kodingsintervjuene. Personlig tror jeg at dette ikke bare er relevant for SRE-er, men bør kreves lesning for alle som bygger og drifter distribuerte systemer.

Dessverre har jeg ikke klart å finne en video til dette.

lysbilder

14. Lastbalancing på Hyper Scale, Alan Halachmi og Colm MacCarthaigh

Dette er en virkelig fascinerende tale fra Facebooks Networking @Scale-konferanse om utviklingen av belastningsbalansering på AWS. Det kaster lys over HyperPlane, et system som ligger til grunn for AWS S3 Load Balancer, VPC NAT Gateway og PrivateLink, og mer. Jeg likte spesielt godt å lære om det foreslåtte sjokkprinsippet (Self Healing eller Constant Work), som antyder at når du bygger et system, skulle det være spenstig til og med store støt. Eller sagt annerledes, "hvis noe stort endres, bør systemet kunne fortsette som normalt". Praten foreslår at:

1. Konstant innsats og utvinning fra fiasko er de naturlige tilstandene
2. Bruk alltid i reparasjonsmodus. Når en node mislykkes, gjør faktisk Hyperplan mindre arbeid!
3. Når vi designer systemer i stor skala, ønsker vi ikke at de skal være sammensatte. Vi vil at de skal være så enkle som mulig. For dette formål ønsker vi så få driftsformer som mulig (Hyperplane har for eksempel ingen forsøksmodus. Den piggybanks på TCPs medfødte forsøksmekanisme). Hoper på forskjellige driftsformer resulterer i en kombinatorisk eksplosjon av kompleksitet som resulterer i at systemet er utrolig vanskelig å teste. Vi ønsker et system som er konsistent og alltid utfører slik vi forventer.
4. Praten introduserer også ideen om shuffle-sharding, en DDoS-begrensningsteknikk (hvor isolasjon er den primære avbøtningsteknikken) som nå er utbredt på tvers av mange AWS-tjenester.

video

15. Isolasjon uten containere, Tyler McMullen

Et av mine interesseområder er det jeg har beskrevet for venner som "spekteret av beregning" - VM-er, microVM-er, nestede VM-er, containere (og smaker av "sandkassebeholdere" som Kata-containere) og "serverløse" (eller funksjoner som en tjeneste). Jeg er spesielt interessert i "spekteret av isolasjon" disse tilbudene - fra streng prosessnivåisolasjon til isolasjon via en sandkasse som en V8. Flere teknologier har dukket opp de siste årene i virtualiseringsrommet som gVisor (en hypervisor som implementerer en delmengde av Linux-kjernen API på brukerområdet) til Firecracker - en virtuell maskinmonitor som er bygget for å kjøre lett og serverløs arbeidsmengde i mikro-VM-er , selv bygget på toppen av crosvm (Chrome OS's Virtual Machine Monitor). En av de mest fascinerende utviklingen på dette rommet er WebAssemble. Opprinnelig designet som et mål for native code å kjøre på nettlesere, blir WASM nå utnyttet av CDN-leverandører til å kjøre vilkårlig kode uten noen form for prosessbasert isolasjon. Selv om jeg fremdeles tror at juryen er inne på om denne formen for isolasjon virkelig passerer mønstre, var dette en fascinerende tale fra Strangeloop om akkurat dette emnet som forklarer funksjonene i WASM som til og med gjør dette noe holdbart.

video

16. Hvordan C ++ Debuggers fungerer, Simon Brand

Tittelen er ganske selvforklarende. Samtalene forklarer alt fra hva ELF-binærfiler er, DRAWF-symboler, mekanikken i hvordan bruddpunkter fungerer, hva du går gjennom koden virkelig innebærer, arbeider med flertrådede applikasjoner i en debugger og mye mer. Dette er definitivt en av de tre beste samtalene mine på denne listen over utrolige samtaler.

video

17. A Philosophy of Software Design, John Ousterhout

Boken A Philosophy of Software Design var den beste tekniske boka jeg leste i 2018. Hvert eneste kapittel i boken er verdt sin vekt i gull, men kapittelet om dype moduler er sannsynligvis det jeg har sitert mest. Foredraget berører noen av de viktigste ideene og de røde flaggene som ble introdusert i boken, men hvis jeg var deg, ville jeg bare kjøpe boken og være ferdig med den.

Video Book

18. Clangd: arkitektur av en skalerbar C ++ språkserver, Ilya Biryukov

En av de mest interessante utviklingen fra Microsoft de siste årene har vært Language Server Protocol. 5.0-utgivelsen av clang-kompilatoren introduserte Clangd, LLVMs implementering av Language Server Protocol. Clangd er en implementering av Language Server Protocol, for å gi funksjoner som fullføring av kode, fix-its, goto-definisjon, døpe om osv. For klienter som C / C ++ kildeditorer. Dette var en god tale fra CPPCon som berørte noen av begrensningene til libclang, og forklarer motivasjonene bak utviklingen av Clangd så vel som den generelle arkitekturen.

19. Coroutine Representations and ABIs i LLVM, John McCall

Coroutines i LLVM ble først lagt til av Microsofts Gor Nishanov og ble designet rundt behovene til C ++ coroutines TS. Dette var en utrolig snakk fra LLVM Developer's Meeting som går inn på noen av fordeler og ulemper med ulike implementeringshensyn som for eksempel ceding-kontroll (kontekst-switching, coroutine-splitting med delt gjenopptak og per-yield-gjenopptaksfunksjoner), til å lagre lokal tilstand (stabile coroutines , sidetildeling, stabling av samliv) for å gi data, samt utfordringene med å generere kode for språkfunksjoner drevet av koroutiner som generatorer. Foredraget tar deretter opp noen av detaljene om en annen type senking kalt "returned continuation flavour" for Swift-programmeringsspråket, der noen av optimaliseringene skjer på Swifts SIL-lag og ikke direkte på LLVM-nivå.

video

PS: Alle foredrag fra LLVM Developer's Meeting er dypt lærerike. Jeg har bare sett denne foredraget, men jeg er sikker på at jeg med glede vil anbefale alle de andre også når jeg først er ute og ser på dem.

20. Utvikling av Kotlin / Native infrastruktur med LLVM / Clang, Nikolay Igotti

Kotlin Native er en superinteressant utvikling de siste årene som gjør at Kotlin-kode kan samles ned til plattformbinarier (ELF, Mach-O, WASM osv.), Så den kan kjøres innfødt i tillegg til å kunne løpe inne i en JVM. Dette var en veldig god foredrag fra European LLVM Developer's Meeting om mekanikken til Kotlin / Native, inkludert noen av utfordringene med å implementere minneledelse utenfor JVM, håndtere unntak og porting til WASM (som ikke har noen kjøretid, ingen minnetildeling, ingen unntak osv.), så vel som noen av de generelle problemene som oppstår med LLVM (langsom koding og kobling, mangler offentlig LLDB-plugin API osv.).

Lysbildevideo

21. Fresh Async With Kotlin, Roman Elizarov

Spekteret av asynkron programmering er bredt og variert. Dette var en fantastisk snakk fra Goto Copenhagen om utfordringene som ligger til grunn for noen av disse paradigmene med asynkron programmering, spesielt den tilbakeringingsbaserte tilnærmingen til Futures. Foredraget fortsetter deretter med å ta opp hvordan Kotlin har som mål å løse dette problemet med koroutiner ved å gi et synkront grensesnitt til brukeren (via suspend primitiv) mens han er under panseret ved å bruke fortsettelser og suspensjonspunkter for å konstruere en tilstandsmaskin. Den mest fascinerende delen av samtalen var sammenligningen mellom Kotlins tilnærming og C # -tilnærmingen til asynk / avvente, mens hovedkomponentene bak Kotlins designvalg var at samtidighet er vanskelig og ergo må være eksplisitt. Foredraget avsluttes med hvordan til og med CSP-esque mønstre kan implementeres ved å bruke de coroutine primitivene til Kotlin.

video

22. Kotlin Native Concurrency Model, Nikolay Igotti

Kotlin har ingen samtidige primitiver på språknivå. Kotlin coroutines som beskrevet i en tale ovenfor er en bibliotekbasert konstruksjon som er rettet mot JVM. Kotlin / Native eschews JVM-stil delt objektheap og låsing ved å opprettholde en invariant om at et objekt enten er eid av en enkelt utførelseskontekst, eller at den er uforanderlig (delt XOR-mutabel). Dette var en flott samtale fra KotlinConf som går inn på hvordan dette oppnås med "ikke eksternt henviste objektundergrafer"

Videre har ikke Kotlin som språk uforanderlighet innebygd i typesystemet. Uforanderlighet oppnås ved frysebegrepet, som gjør den transitive lukkingen av alle objekter tilgjengelig fra en gitt gjenstand uforanderlig. I tillegg tillater Kotlin / Native også overføring av eierskap til objekter på tvers av utførelseskontekster. Praten introduserer de grunnleggende trygge samtidige primitivene levert av Kotlin / Native, for eksempel “avtakbare objektgrafer”, atomikk og “arbeidere” i skuespillerstil, hvordan referansetelling basert minnehåndtering fungerer i Kotlin / Native, samt hvordan det oppnår interoperabilitet med andre runtimes.

Lysbildevideo

23. Er det på tide å skrive et operativsystem i Rust, Bryan Cantrill

Jeg har ofte vært underlagt noen eller andre lenestolteorier om at Rust er "et språk designet for å skrive en kjerne i".

Er det vel?

Dette er en flott samtale fra den fremste eksperten om temaet om hvorfor Rust er spesielt godt egnet til å skrive systemprogramvare, samt noen av utfordringene med å potensielt skrive en hel kjerne i Rust. Hvis du liker turer i databehandlingshistoriene og det sjeldne merkevareproduktet som faktisk understøttes av velinformert og begrunnet tenking, kan dette være snakk for deg.

Lysbildevideo

24. Hva mener du "trådsikker" ?, Geoffrey Romer

Dette var en fantastisk snakk fra CPPCon som tar sikte på å utvetydige begreper som “trådsikker” eller mer presise termer som “datarase” og “rasetilstand” som ofte fungerer på feil abstraksjonsnivå. Praten foreslår å bruke forestillingen om et "API-løp" og invarianter som kan bygges rundt et "API-løp", etterfulgt av anbefalinger for både C ++ bibliotek og applikasjonsforfattere rundt

video

25. Fast Safe Mutable State, Ben Cohen

Når det gjelder mutbar tilstand, er det viktig å huske at den delte mutable tilstanden er dårlig, og ikke mutbar tilstand i seg selv. Dette var en fantastisk foredrag fra Functional Swift-konferansen om når og hvordan man bruker lokal mutbar tilstand uten å ofre sikkerhet eller ytelse. Praten går gjennom noen av språkfunksjonene i Swift som gir den en viss funksjonell smak ved å forhindre visse kategorier av feil som er mulige i mutasjonsfunksjoner.

video

26. The Dos and Donts of Error Handling, Joe Armstrong

Jeg hadde gleden av å se denne praten live på GOTO Copenhagen. Hovedstøtten til denne samtalen er at det er umulig å oppnå feiltoleranse ved bruk av en enkelt maskin; meldingsoverføring blir dermed uunngåelig. Bygningsfeil tolerante distribuerte systemer koker ned for å oppdage og handle på feil. Filosofien om feilhåndtering anses som mest forsvarlig er en der programvare kan bevises riktig på kompileringstidspunktet og der programvare antas å være de facto feilaktig og forventet å mislykkes ved kjøretid. Store samlinger av små ting er umulig å bevise riktig; dermed blir det viktig å kunne definere “feilkjernen”, som er en delmengde av systemet som må være riktig. Hvis du som programmerer ikke vet hva du skal gjøre, krasjer du. Da blir programvaren enklere.

Du vil bli tilgitt for å tenke på det som en 45 minutters forklaring på eksistensen av Erlang programmeringsspråk.

video

27. QUIC: Utvikle og distribuere en TCP-erstatning for nettet, Ian Swett og Jana Iyengar

Dette var en flott snakk fra NetDev som gir en introduksjon til QUIC-protokollen utviklet hos Google, designvedtakene (hvorfor lag den på toppen av UDP, bedre tapsgjenoppretting, fleksibel overbelastningskontroll), det er evolusjonen samt myriade opplevelser som skalerer QUIC på Linux .

Lysbildevideo

28. Introduksjon av Network.framework: Et moderne alternativ til Sockets, Josh Graessley, Tommy Pauly, Eric Kinnear

Stikkontakter kan være vanskelige å bruke når det gjelder tilkoblingsetablering eller dataoverføring (selv med ikke-blokkerende stikkontakter) eller mobilitet.

Network.framework er et moderne transport-API som er et alternativ til stikkontakter på Apple-plattformer. Dette var en flott spasertur fra WWDC 2018 som gikk en gjennom anatomi fra en første tilkoblingsetablering til livssyklusen til en forbindelse, sammen med de utallige optimaliseringene som ble gjort i forskjellige stadier. Det er muligens den best presenterte samtalen på denne listen.

video

29. Kubernetes and the Path to Serverless, Kelsey Hightower

Det er en tale av Kelsey Hightower.

Trenger jeg å si noe lenger? Jeg tror ikke.

video

30. Bruker Rust for spillutvikling, Catherine West

Praten starter med å si "Dette er sannsynligvis den kjedeligste praten ..."

Det er ikke.

Det kan faktisk være den aller beste samtalen på denne listen.

video