El pago en criptomonedas debería ser idéntico a cómo hacemos las cosas en Asia: Método 1: El comerciante muestra un código QR que tiene el monto del pago y el destino incrustados. Yo escaneo, autenticación biométrica, listo. También funciona al comprar cosas en línea. Método 2: Yo creo un código QR (requiere autenticación). El comerciante escanea, y el dinero se retira automáticamente de la cuenta (esto solo funciona para compras en persona). Es realmente molesto rastrear de quién provino cada pago usando hashes de transacción, y a veces, si el RPC es lento, se pierde una transacción.

Vale la pena dedicar tiempo a aprender estos lenguajes de programación, incluso si no los usas: 1/6 C C está un paso alejado de escribir en ensamblador. Te obliga a entender la diferencia entre "pila" y "montón". También debes lidiar con punteros, y entrenar tu cerebro para manejar la indirección te ayudará a comprender problemas más difíciles más adelante, ya que casi cada problema "difícil" debe ser modelado con algún nivel de indirección.

Uniswap v3 es simple: un montón de piezas cortadas de Uniswap v2 pegadas juntas. Pero, vaya, explicar eso y hacerlo claro, es difícil.

Esto es cierto. Nuestra serie de Solana solo necesitó 5 capítulos sobre "lo justo necesario de Rust para hacer Solana y boilerplate para todo lo demás." Sin Anchor, eso habría sido al menos 15 capítulos, y eso habría sido un verdadero desánimo para los lectores. Anchor hace un gran trabajo ocultando los aspectos más complejos de Rust (por ejemplo, la serialización y deserialización) mientras mantiene la seguridad. Sí, en algún momento deberías escribir un programa de Solana en Rust puro por el aspecto educativo, pero eso es muy intimidante para alguien que no ha usado Rust/C++ antes. Sin embargo, puedo decir que si todos dedicaran solo 15 minutos al día a @RareCodeAI, la maestría en Rust sería la norma. (Y porque sigo recibiendo preguntas — más contenido de Solana llegará pronto).

Lo más importante que puedes hacer por tu progreso profesional no es: - escuchar a la gente hablar en un panel ❌ - acercarte a personas al azar para tener la misma conversación una y otra vez ❌ - ir de fiesta en un evento secundario ❌ Es encerrarte y mejorar tus habilidades en algo muy rápido. ✅ De eso se trata RareWeek.

El próximo artículo de Uniswap V3 que salga va a dejar a la gente boquiabierta. No solo porque las animaciones son geniales, sino porque lo que normalmente sería una matemática aterradora se siente extremadamente digerible. Esta es una de las cosas que hace que RareSkills sea increíble como empresa editorial. No solo reciclamos la documentación o tutoriales existentes y los orientamos ligeramente hacia un cierto público. Reformulamos los conceptos subyacentes desde los primeros principios y descubrimos la mejor representación en mapa conceptual del tema, luego lo convertimos en un artículo. Cuando las derivaciones existentes no son lo suficientemente buenas, no las mejoramos. Las desechamos y las re-derivamos nosotros mismos.

Según los primeros datos que estoy viendo de @RareCodeAI, se necesitan entre 20 y 30 horas de práctica dedicada en Rust para llegar al punto de "dominar" Rust. Por "dominar" Rust me refiero a: - Puedes encontrar una solución a un problema común (digamos, encontrar cadenas en un conjunto que son anagramas entre sí) sin esforzarte demasiado. - Puedes intuir qué sintaxis está disponible para ti en una situación desconocida. - La mayoría de los errores del compilador no te asustan y puedes reconocer de inmediato la solución a los más comunes. Estas 20-30 horas NO incluyen: - leer tutoriales - pasar tiempo averiguando qué practicar y revisar - decidir si deberías aprender algo nuevo o practicar algo de antes Sin RareCode, sospecho que el tiempo requerido sería más cercano a 40 u 80 horas. Así que antes de obligar a los desarrolladores a aprender Rust para usar tu producto, considera el hecho de que la mayoría de las personas no quieren pasar por 80 horas agotadoras.

¿Por qué deberías aprender recursión incluso si nunca la usarás? Las soluciones recursivas te entrenan en algunas mentalidades: 1. En lugar de intentar generar la solución, a menudo comienzas con "¿cuál es la estructura de una solución válida?" y trabajas hacia atrás. Para algunos problemas, trabajar hacia atrás es mucho más fácil. 2. Cuando estás resolviendo el problema, es fácil distraerse con todos los "¿y si...?". Al resolver un problema de forma recursiva, a menudo te ves obligado a "ignorar" el 90% de los problemas y concentrarte en hacer bien solo una parte. 3. Lo que a menudo sería un caso "extremo" en una solución imperativa es un "caso base" en una recursiva. Pensar de forma recursiva a veces te obliga a no ignorar los casos extremos. Además, las soluciones recursivas hacen un uso intensivo de la coincidencia de patrones, por lo que te ves obligado a pensar en todas las situaciones que podrías encontrar. Aquí hay un muy buen ejemplo: Leetcode 335 Cruce de sí mismo (problema difícil). Viajas en una trayectoria espiral en una cuadrícula (es decir, siempre giras a la izquierda después de viajar cierta distancia hacia el norte, sur, este u oeste). La pregunta es: "dada la distancia de cada 'segmento' de la espiral en orden, ¿se cruzó la espiral a sí misma o no?" Aunque la solución a esto no necesita ser una función que se llame a sí misma, la solución "bonita" utiliza propiedades recursivas: 1. si aún no hemos encontrado un cruce, entonces podemos asumir que no hay cruces o espirales inválidas en el pasado. Además, notamos que no importa si estamos viajando a la izquierda, a la derecha, hacia arriba o hacia abajo porque solo podemos girar a la izquierda. Lo único que nos importa es si los segmentos anteriores son paralelos a nuestro giro anterior y qué tan lejos están. 2. cuando giramos a la izquierda, hay un número extremadamente limitado de "segmentos" en la espiral con los que podemos chocar, lo cual es "recursivamente" cierto sin importar cuán grande se vuelva la espiral. Hay muchos datos pasados sobre la espiral que podemos ignorar. 3. Hay un número limitado de escenarios en tu giro anterior que afectan tu lógica: a) ¿viajaste lo suficientemente lejos como para no chocar con nada?, b) si no, ¿con qué podrías chocar potencialmente? (también limitado). Lo molesto de los problemas difíciles de Leetcode es que de repente se vuelven fáciles si encuentras la clave. Pero esos conocimientos clave te llegarán de forma más natural si te has entrenado en programación recursiva. No se trata solo de diseñar funciones que se llamen a sí mismas, sino de obligarte a descomponer el problema de tal manera que pueda resolverse con una función que se llame a sí misma. Cuantas más formas encuentres de descomponer un problema, más probable es que encuentres una solución "aha". Obviamente, no necesito hacer Leetcode en mi profesión, pero sí necesito encontrar formas creativas de descomponer problemas para que se vuelvan comprensibles, y el entrenamiento en recursión definitivamente ha ayudado con eso.

Usar IA para programar es como ser un astronauta en la luna. De repente, puedes saltar mucho más alto y levantar objetos que normalmente serían demasiado pesados. Pero en realidad, te estás volviendo físicamente más débil debido a la atrofia. Para contrarrestar esto, los astronautas necesitan ser extremadamente disciplinados en cuanto al ejercicio para mantener la masa muscular. Así lo veo, los programadores pasarán la mayor parte del día usando IA para construir, pero entrenando — no solo para evitar la atrofia — sino para aumentar sus habilidades usando @RareCodeAI y/o @RareSkills_io. En RareCode, la IA pasa de hacer el trabajo por ti a convertirse en un entrenador para entrenarte de manera eficiente y evitar la frustración improductiva y la atrofia.

Puedes aprender a usar Uniswap v4 sin entender cómo funciona Uniswap v3, pero saber cómo usarlo es diferente de saber cómo funciona. En Rareskills, aprendes cómo funciona.