Kryptobetaling skal være identisk med hvordan vi gjør ting i Asia: Metode 1: Selgeren viser en QR-kode som har betalingsbeløpet og destinasjonen innebygd i. Jeg skanner, biometrisk autentisering, ferdig. Fungerer også når du kjøper ting på nett. Metode 2: Jeg lager en QR-kode (krever godkjenning). Selgeren skanner, og pengene trekkes automatisk fra kontoen (dette fungerer bare for personlig shopping). Det er veldig irriterende å spore hvilken betaling som kom fra hvem ved hjelp av transaksjonshasher, og noen ganger hvis RPC er treg, går du glipp av en transaksjon.

Det er verdt tiden din å lære disse programmeringsspråkene, selv om du ikke bruker dem: 1/6 C C er på trinn fjernet fra skrivesamlingen. Det tvinger deg til å forstå forskjellen mellom "stabel" og "haug". Du må også floke deg sammen med pekere - og å trene hjernen din til å håndtere indirection vil hjelpe deg med å håndtere vanskeligere problemer senere, da nesten alle "vanskelige" problemer må modelleres med en viss grad av indirection.

Uniswap v3 er enkel: en haug med kuttede biter av Uniswap v2 limt sammen. Men gutt, å forklare det og gjøre det klart, det er vanskelig.

Dette er sant. Solana-serien vår trengte bare 5 kapitler om "akkurat nok Rust til å gjøre Solana og standardlage alt annet." Uten Anchor ville det ha vært minst 15 kapitler – og det ville ha vært en skikkelig turn-off for leserne. Anchor gjør en god jobb med å skjule de mer komplekse aspektene ved Rust (f.eks. serialisering og deserialisering) samtidig som sikkerheten opprettholdes. Ja, du bør på et tidspunkt skrive et rått Rust Solana-program for det pedagogiske aspektet, men det er veldig skremmende for noen som ikke har brukt Rust/C++ før. Jeg kan si at hvis alle bare ville bruke 15 minutter om dagen på @RareCodeAI, ville rustmestring vært normen. (Og fordi jeg stadig blir spurt - mer Solana-innhold kommer snart).

Det viktigste du kan gjøre for din karriereprogresjon er ikke: - lytte til folk som kjemper på et panel ❌ - henvende seg til tilfeldige personer for å ha den samme samtalen om og om igjen ❌ - feste på et sidearrangement ❌ Det er å bli låst inne og oppgradere noe veldig raskt. ✅ Det er det RareWeek handler om.

Den neste Uniswap V3-artikkelen som kommer ut kommer til å blåse folks sinn. Dette er ikke bare fordi animasjonene er kule, men fordi det som normalt ville vært skummel matematikk føles ekstremt fordøyelig. Dette er en ting som gjør RareSkills utrolig som forlag. Vi re-hasher ikke bare eksisterende dokumentasjon eller opplæringsprogrammer og gjør dem litt mer orientert mot et bestemt publikum. Vi omarbeider de underliggende konseptene fra de første prinsippene og oppdager den beste konseptkartrepresentasjonen av emnet, og gjør det deretter om til en artikkel. Når eksisterende avledninger ikke er gode nok, gjør vi dem ikke bedre. Vi skraper dem og henter dem på nytt selv.

Basert på tidlige data jeg ser fra @RareCodeAI tar det omtrent 20-30 timer med dedikert Rust-øvelse for å komme til punktet med å "mestre" Rust. Med å "mestre" Rust mener jeg: - Du kan piske opp en løsning på et vanlig problem (la oss si finne strenger i et sett som er anagrammer av hverandre) uten å anstrenge deg. - Du kan føle hvilken syntaks som er tilgjengelig for deg i en ukjent situasjon. - De fleste kompilatorfeil skremmer deg ikke, og du kan umiddelbart gjenkjenne løsningen på de vanligste. Disse 20-30 timene inkluderer IKKE: - Veiledning for lesing - bruke tid på å finne ut hva du skal øve på og gjennomgå - bestemme om du skal lære noe nytt eller øve på noe fra tidligere Uten RareCode mistenker jeg at tiden som kreves ville vært nærmere 40 til 80 timer. Så før du tvinger utviklere til å lære Rust for å bruke produktet ditt, bør du vurdere det faktum at de fleste ikke ønsker å gå gjennom 80 utmattende timer.

Hvorfor skal du lære rekursjon selv om du aldri kommer til å bruke det? Rekursive løsninger lærer deg opp i noen tankesett: 1. I stedet for å prøve å generere løsningen, starter du ofte med "hva er strukturen til en gyldig løsning"-arbeid baklengs. For noen problemer er det mye enklere å jobbe bakover. 2. Når du løser problemet, er det lett å bli distrahert av alle "hva hvis". Når du løser et problem rekursivt, blir du ofte tvunget til å "ignorere" 90 % av problemene og fokusere på å få bare én del riktig. 3. Det som ofte ville være et "hjørne"-tilfelle i en imperativ løsning er et "basistilfelle" i en rekursiv på. Å tenke rekursivt tvinger deg noen ganger til å ikke ignorere hjørnesakene. Videre gjør rekursive løsninger stor bruk av mønstermatching slik at du blir tvunget til å tenke på alle situasjonene du kan støte på. Her er et veldig godt eksempel: Leetcode 335 Self Crossing (Vanskelig problem). Du reiser på en spiralbane på et rutenett (dvs. svinger alltid til venstre etter å ha reist et stykke nord, sør, øst eller vest). Spørsmålet er, "gitt avstanden til hvert 'segment' av spiralen i rekkefølge, krysset spiralen seg selv eller ikke?" Selv om løsningen på dette ikke trenger å være en funksjon som kaller seg selv, bruker den "fine" løsningen rekursive egenskaper: 1. Hvis vi ikke har funnet et kryss ennå, kan vi anta at det ikke er noen kryss eller ugyldige spiraler i fortiden. Vi merker videre at det ikke spiller noen rolle om vi reiser til venstre, høyre, opp eller ned fordi vi bare kan svinge til venstre. Alt vi bryr oss om er om de forrige segmentene er parallelle med vår forrige sving og hvor langt unna de er. 2. Når vi svinger til venstre, er det et ekstremt begrenset antall "segmenter" i spiralen vi kan krasje inn i, noe som er "rekursivt" sant uansett hvor stor spiralen blir. Det er mange tidligere data om spiralen vi kan ignorere. 3. Det er et begrenset antall scenarier i din forrige tur som påvirker logikken din: a) reiste du langt nok til ikke å krasje inn i noe, b) hvis ikke, hva kan du potensielt krasje inn i? (også begrenset). Det irriterende med Leetcode-hards er at de plutselig blir enkle hvis du finner nøkkelinnsikten. Men disse nøkkelinnsiktene vil komme til deg mer naturlig hvis du har trent deg selv i rekursiv programmering. Det handler ikke bare om å designe funksjoner som kaller seg selv – det handler om å tvinge deg selv til å bryte ned problemet på en slik måte at det kan løses med en funksjon som kaller seg selv. Jo flere måter du kan bryte ned et problem på, jo mer sannsynlig er det at du finner en "aha"-løsning. Åpenbart trenger jeg ikke å leetcode i yrket mitt, men jeg trenger å finne kreative måter å bryte ned problemer slik at de blir forståelige – og trening i rekursjon har definitivt hjulpet med det.

Å bruke AI til å kode er som å være astronaut på månen. Du kan plutselig hoppe mye høyere og løfte gjenstander som normalt ville vært for tunge. Men i virkeligheten blir du fysisk svakere gjennom atrofi. For å motvirke dette må astronauter være ekstremt disiplinerte når det gjelder å trene for å beholde muskler. Slik jeg ser det, vil kodere bruke mesteparten av dagen på å bruke AI til å bygge, men trene – ikke bare for å unngå atrofi – men for å øke ferdighetene ved å bruke @RareCodeAI og/eller @RareSkills_io. I RareCode går AI fra å gjøre arbeid for deg til å bli en coach for å trene deg effektivt og unngå uproduktiv frustrasjon og atrofi.

Du kan lære hvordan du bruker Uniswap v4 uten å forstå hvordan Uniswap v3 fungerer, men å vite hvordan du bruker det er forskjellig fra å vite hvordan det fungerer. I Rareskills lærer du hvordan det fungerer.