O pagamento em criptomoeda deve ser idêntico ao que fazemos na Ásia: Método 1: O comerciante mostra um código QR que tem o valor do pagamento e o destino incorporados. Eu escaneio, autenticação biométrica, feito. Também funciona ao comprar coisas online. Método 2: Eu crio um código QR (requer autenticação). O comerciante escaneia, e o dinheiro é automaticamente retirado da conta (isso só funciona para compras presenciais). É realmente irritante rastrear de quem veio cada pagamento usando hashes de transação, e às vezes, se o RPC estiver lento, você perde uma transação.

Vale a pena dedicar tempo a aprender estas linguagens de programação, mesmo que não as utilize: 1/6 C C está um passo afastado de escrever em assembly. Obriga-o a entender a diferença entre "stack" e "heap". Você também deve lidar com ponteiros — e treinar seu cérebro para lidar com indireção ajudará você a compreender problemas mais difíceis mais tarde, uma vez que quase todo "problema difícil" deve ser modelado com algum nível de indireção.

Uniswap v3 é simples: um monte de pedaços cortados do Uniswap v2 colados juntos. Mas, meu Deus, explicar isso e torná-lo claro é difícil.

Isto é verdade. A nossa série sobre Solana só precisou de 5 capítulos sobre "apenas o suficiente de Rust para fazer Solana e boilerplate tudo o resto." Sem o Anchor, isso teria sido pelo menos 15 capítulos — e isso teria sido um verdadeiro desincentivo para os leitores. O Anchor faz um ótimo trabalho em esconder os aspectos mais complexos do Rust (por exemplo, serialização e desserialização) enquanto mantém a segurança. Sim, em algum momento você deve escrever um programa Solana em Rust puro para o aspecto educacional, mas isso é muito intimidante para alguém que nunca usou Rust/C++ antes. Posso dizer, no entanto, que se todos apenas passassem 15 minutos por dia no @RareCodeAI, a maestria em Rust seria a norma. (E porque continuo a ser questionado — mais conteúdo sobre Solana está a chegar em breve).

A coisa mais importante que você pode fazer pela sua progressão na carreira não é: - ouvir pessoas falarem em um painel ❌ - abordar pessoas aleatórias para ter a mesma conversa repetidamente ❌ - festejar em um evento paralelo ❌ É se concentrar e aprimorar suas habilidades em algo muito rapidamente. ✅ É isso que a RareWeek representa.

O próximo artigo sobre Uniswap V3 que será publicado vai surpreender as pessoas. Isso não é apenas porque as animações são legais, mas porque o que normalmente seria uma matemática assustadora parece extremamente digerível. Isso é uma das coisas que torna a RareSkills incrível como empresa de publicação. Não apenas reprocessamos a documentação ou tutoriais existentes e os tornamos ligeiramente mais orientados para um determinado público. Reformulamos os conceitos subjacentes a partir dos primeiros princípios e descobrimos a melhor representação em mapa conceitual do assunto, para depois transformá-lo em um artigo. Quando as derivações existentes não são boas o suficiente, não as melhoramos. Nós as descartamos e as re-derivamos nós mesmos.

Com base nos dados iniciais que estou a ver do @RareCodeAI, leva cerca de 20 a 30 horas de prática dedicada em Rust para chegar ao ponto de "dominar" Rust. Por "dominar" Rust, quero dizer: - Você consegue criar uma solução para um problema comum (digamos, encontrar strings em um conjunto que são anagramas umas das outras) sem se esforçar muito. - Você consegue perceber qual sintaxe está disponível para você em uma situação desconhecida. - A maioria dos erros do compilador não o assusta e você pode reconhecer imediatamente a solução para os mais comuns. Essas 20-30 horas NÃO incluem: - ler tutoriais - passar tempo a descobrir o que praticar e rever - decidir se deve aprender algo novo ou praticar algo de antes Sem o RareCode, suspeito que o tempo necessário seria mais próximo de 40 a 80 horas. Portanto, antes de forçar os desenvolvedores a aprender Rust para usar o seu produto, considere o fato de que a maioria das pessoas não quer passar por 80 horas extenuantes.

Por que deverias aprender recursão mesmo que nunca a uses? Soluções recursivas treinam-te em algumas mentalidades: 1. Em vez de tentares gerar a solução, muitas vezes começas com “qual é a estrutura de uma solução válida” e trabalhas para trás. Para alguns problemas, trabalhar para trás é muito mais fácil. 2. Quando estás a resolver o problema, é fácil distrair-te com todos os “e se”. Ao resolver um problema recursivamente, muitas vezes és forçado a “ignorar” 90% das questões e focar-te em acertar apenas uma parte. 3. O que muitas vezes seria um caso “marginal” numa solução imperativa é um “caso base” numa recursiva. Pensar recursivamente às vezes força-te a não ignorar os casos marginais. Além disso, soluções recursivas fazem uso intensivo de correspondência de padrões, por isso és forçado a pensar em todas as situações que poderias encontrar. Aqui está um exemplo muito bom: Leetcode 335 Self Crossing (Problema difícil). Viajas numa trajetória espiral num grid (ou seja, sempre viras à esquerda após viajar uma certa distância para norte, sul, leste ou oeste). A questão é: “dada a distância de cada ‘segmento’ da espiral em ordem, a espiral cruzou-se a si mesma ou não?” Embora a solução para isto não precise ser uma função a chamar-se a si mesma, a solução “bonita” utiliza propriedades recursivas: 1. se ainda não encontramos um cruzamento, então podemos assumir que não há cruzamentos ou espirais inválidas no passado. Notamos ainda que não importa se estamos a viajar para a esquerda, direita, para cima ou para baixo, porque só podemos virar à esquerda. Tudo o que nos importa é se os segmentos anteriores são paralelos à nossa viragem anterior e quão longe estão. 2. quando viramos à esquerda, há um número extremamente limitado de “segmentos” na espiral com os quais podemos colidir, o que é “recursivamente” verdade não importa quão grande a espiral se torne. Há muitos dados passados sobre a espiral que podemos ignorar. 3. Há um número limitado de cenários na tua viragem anterior que afetam a tua lógica: a) viajaste longe o suficiente para não colidir com nada, b) se não, com o que poderias potencialmente colidir? (também limitado). A parte irritante dos problemas difíceis do Leetcode é que de repente se tornam fáceis se encontrares a chave de insight. Mas esses insights-chave virão a ti de forma mais natural se te tiveres treinado em programação recursiva. Não se trata apenas de desenhar funções que se chamam a si mesmas — trata-se de forçar-te a dividir o problema de tal forma que possa ser resolvido com uma função a chamar-se a si mesma. Quanto mais formas conseguires dividir um problema, mais provável é que encontres uma solução “aha”. Obviamente, não preciso de fazer Leetcode na minha profissão, mas preciso de encontrar formas criativas de dividir problemas para que se tornem compreensíveis — e o treino em recursão ajudou-me definitivamente com isso.

Usar IA para programar é como ser um astronauta na lua. Você pode, de repente, saltar muito mais alto e levantar objetos que normalmente seriam pesados demais. Mas, na realidade, você está se tornando fisicamente mais fraco devido à atrofia. Para contrariar isso, os astronautas precisam ser extremamente disciplinados em relação ao exercício para manter a massa muscular. Na minha opinião, os programadores passarão a maior parte do dia usando IA para construir, mas treinando — não apenas para evitar a atrofia — mas para aumentar suas habilidades usando @RareCodeAI e/ou @RareSkills_io. No RareCode, a IA passa de fazer o trabalho por você para se tornar um treinador que o treina de forma eficiente e evita frustrações improdutivas e atrofia.

Você pode aprender a usar o Uniswap v4 sem entender como o Uniswap v3 funciona, mas saber como usá-lo é diferente de saber como ele funciona. No Rareskills, você aprende como ele funciona.