In December 2025, I was able to finish watching One Piece, and it was an amazing experience. I loved the story, the references, the characters, and the world created by Eiichiro Oda.

So, maybe you're wondering, why build a RAG system for One Piece? Let me tell you why:

• When I started the anime, I had a lot of questions. What did I do? Research, ask friends, fall into wiki rabbit holes. And I thought, what if I could build my own nakama - a virtual crewmate who's seen every episode, read the wiki, and can answer anything I ask?

Could I just Google everything? Sure. But I wanted something more - a companion for my One Piece journey. Someone who knows the lore, understands the terminology, and is always there when I need answers. That's why I decided to build this RAG system: my own nakama.

What we will cover in this blog post:

• How I gave my nakama a brain (data pipeline and chunking)
• RAG best practices that actually matter
• The Buccaneer problem
• What I learned
• Going to production
• When a nakama is (and isn't) the answer
• How you can build your own

Let's start with: What is RAG? RAG comes from Retrieval-Augmented Generation, and what does that mean?

• R: Retrieval: We have a knowledge base (in this case, One Piece data) that we can search for relevant information.
• A: Augmented: We use the retrieved information to augment the input to a language model.
• G: Generation: The language model generates a response based on the augmented input.

Giving My Nakama a Brain

Before my nakama could answer anything, I needed to give them knowledge. Where do you get One Piece data? The internet has plenty of sources. I started with three (you can always add more, but be careful - data quality matters more than quantity):

The Data Sources

1. Subtitles from One Pace One Pace is a fan project that removes filler from the anime. I grabbed subtitles from 400+ episodes - every line of dialogue, every scene. This became the core of my nakama's memory.

2. Wiki Pages The One Piece Wiki has detailed information about characters, races, Devil Fruits, and lore. I scraped key pages and translated them (the Spanish wiki often has more recent info).

3. Manga Transcripts For the latest arcs not yet in the anime, manga transcripts fill the gaps.

The Chunking Challenge

You can't just dump entire episodes into a database. The text needs to be split into chunks small enough to search effectively, but large enough to preserve context.

# My chunking config
chunk_size: int = 500      # Max characters per chunk
chunk_overlap: int = 50    # Overlap between chunks

Why overlap? Imagine a sentence gets cut in half at a chunk boundary. With overlap, the important context carries into the next chunk.

Cleaning the Data

Subtitles are messy. Music markers, formatting codes, speaker tags - all noise that confuses the search:

# Before cleaning
"♪ We Are! ♪ [LUFFY] I'm gonna be King of the Pirates!"

# After cleaning
"I'm gonna be King of the Pirates!"

The result? 136,000+ clean chunks of One Piece knowledge, ready to be searched.

The Architecture

User asks a question → the query gets embedded → we search the vector database for similar chunks → rerank the results → feed the best chunks + question to the LLM → get an answer with context.

RAG Best Practices (What I Actually Implemented)

Building this nakama taught me that generic RAG tutorials skip the important stuff. This is what worked for me:

1. Hybrid Search: Don't Choose Between Semantic and Keyword

Most tutorials tell you to use vector search OR keyword search. I use both:

# Combine vector similarity (70%) with keyword matching (30%)
combined_score = vector_score * 0.7 + keyword_score * 0.3

Why? Vector search understands meaning ("Who is the rubber pirate?" finds Luffy), but misses exact terms. Keyword search catches specific names and techniques. Together, they cover more ground.

2. Two-Stage Retrieval: Fast First, Accurate Second

Searching 136K chunks needs to be fast. But accuracy matters too. So I split it into two stages.

# Stage 1: Fast bi-encoder retrieves 3x more candidates
retrieval_top_k = final_top_k * 3  # Get 24 candidates if we need 8

# Stage 2: Slower cross-encoder re-ranks for precision
reranked = reranker.rerank(candidates, top_k=final_top_k)

The bi-encoder (embedding search) is fast - milliseconds to scan thousands of chunks. The cross-encoder is slower but more accurate - it compares the query directly against each candidate. You get speed AND accuracy.

3. Overlapping Chunks: Don't Lose Context at Boundaries

When building a RAG, overlapping is easy to ignore - until you lose answers you know are in your data. Here's what happens without overlap:

# Chunk 1 ends here:
"...Luffy ate the Gomu Gomu no Mi which is actually"

# Chunk 2 starts here:
"the Hito Hito no Mi Model: Nika, a mythical zoan fruit..."

Someone asks: "What is Luffy's real Devil Fruit?" Neither chunk answers it. The connection between them got split at the boundary.

With 50 characters of overlap:

# Chunk 1:
"...Luffy ate the Gomu Gomu no Mi which is actually the Hito Hito no Mi"

# Chunk 2:
"which is actually the Hito Hito no Mi Model: Nika, a mythical zoan fruit..."

Now both chunks contain the connection. The search can find it.

chunk_size: int = 500
chunk_overlap: int = 50  # 10% overlap - don't skip this

4. Lazy-Load Heavy Models

Embedding models are big. Loading them blocks your application startup. Instead, load on first use:

@property
def model(self) -> SentenceTransformer:
    """Lazy-load the embedding model on first access."""
    if self._model is None:
        self._model = SentenceTransformer(self._model_name)
    return self._model

Your API starts instantly. The model loads when someone actually asks a question.

5. Cache, But Be Smart About It

Repeated questions? Cache the response. But conversational follow-ups need fresh context:

# Cache standalone questions
if not conversation_history:
    cached = cache.get(question)
    if cached:
        return cached

# Skip cache for conversations (context-dependent)

The Buccaneer Problem

Someone asked: "Is Whitebeard a buccaneer?"

My nakama said yes.

"Yes, Whitebeard is considered a buccaneer in the One Piece universe..."

Wrong. In One Piece, "Buccaneer" isn't just a pirate term - it's a race. Kuma is the last confirmed Buccaneer. Whitebeard is human.

(There's a fan theory that Whitebeard might have Buccaneer blood - similar build to Kuma, and Oda dropped some hints in Chapter 1100. Not confirmed though.)

So what happened? The retrieval found chunks about Whitebeard, not about the Buccaneer race. And without that context, the LLM fell back to what it knows: "buccaneer" = pirate. Technically correct in the real world, completely wrong in One Piece.

This is the thing about domain-specific terminology. One Piece has its own dictionary - Devil Fruits, Haki, specific races. If your data doesn't cover these terms explicitly, your RAG will hallucinate real-world meanings.

I fixed it two ways.

More data. I scraped wiki pages specifically about One Piece races:

WIKI_PAGES = [
    "Buccaneer",
    "Lunaria",
    "Gyojin",  # Fishmen
    "Bartholomew_Kuma",
    # ...
]

Better prompts. Your system prompt isn't just instructions - it's context the LLM always sees, regardless of what gets retrieved. I added a terminology section:

SYSTEM_PROMPT = """You are an expert on One Piece...

CRITICAL ONE PIECE TERMINOLOGY:
- "Buccaneer" is a RACE of people, NOT just a pirate term.
  Bartholomew Kuma is the last known Buccaneer.
- "Lunarian" is a race from the Red Line (King is a Lunarian)
- "Fishmen" and "Merfolk" are aquatic races
...
"""

Now when someone asks about Whitebeard and buccaneers:

"No, Whitebeard (Edward Newgate) is not a Buccaneer. In the One Piece universe, Buccaneers are a specific race of people, with Bartholomew Kuma being the last known representative..."

Much better.

What I Learned Building This

Domain vocabulary will break your RAG. One Piece has its own dictionary - Devil Fruits, Haki, races like Buccaneers. If your data doesn't define these terms, your RAG will hallucinate real-world meanings. Before building, list the weird terms your users might ask about.

Your system prompt is part of your knowledge base. I used to think prompts were just instructions. They're not - it's context the LLM always sees. The terminology section in my prompt catches stuff that retrieval misses.

Easy questions won't expose problems. "Who is Luffy?" works on day one. "Is Whitebeard a buccaneer?" breaks on day 30. Build a test set of weird questions early.

You're never done. I thought I'd build it, deploy it, move on. Nope. Data → Test → Fail → Fix → Repeat. The Buccaneer problem showed up weeks after I thought I was finished.

Going to Production

Building a RAG that works on your laptop is one thing. Putting it in front of real users? Different game.

Monitor what fails. Track which questions get weird answers. The Buccaneer problem? I only found it because someone told me. In production, you need logs. What queries returned low-relevance chunks? What made users ask again? That's your debugging goldmine.

Teach it to say "I don't know". A confident wrong answer is worse than admitting ignorance. I added a relevance threshold - if the best chunks score below 0.3, my nakama says it doesn't have enough info instead of guessing.

Plan for data updates. One Piece isn't finished. New episodes, new manga chapters, new lore. How do you add data without re-embedding everything? I batch new content separately and merge it. Not perfect, but it works.

Watch your costs. Every question = embedding call + LLM call. At scale, this adds up fast. Caching helps (I mentioned this earlier), but also consider: do you really need GPT-4 for every query? Sometimes a smaller model is enough.

Rate limit everything. Someone will try to break your system. Rate limiting isn't just about costs - it's about not letting one curious user crash your database with 1000 queries.

136K chunks sounds like a lot, but you can always add more. Just be careful - bad data creates bad answers. Quality > quantity, always.

When a Nakama Isn't the Answer

Could I just Google my One Piece questions? Yes. Is this over-engineering? Maybe.

When Google is enough:

• Simple factual lookups ("When did Ace die?")
• Checking episode numbers
• Finding character images

When a nakama shines:

• Questions that span multiple sources ("What connections exist between Joy Boy and the Buccaneers?")
• Conversational follow-ups ("What about his Devil Fruit?")
• Domain-specific terminology (the Buccaneer problem!)
• Having a companion who understands context

I didn't build this just to answer questions. Using One Piece made it fun to show how RAG actually works - and how it fails. The Buccaneer problem says it all.

And honestly? It's fun having a nakama who knows One Piece as well as I do.

Build Your Own Nakama

Want to try it yourself? The code is open source.

Tech Stack:

• FastAPI + Python (Backend)
• PostgreSQL + pgvector (Vector DB)
• sentence-transformers (Embeddings)
• Next.js (Frontend)

git clone https://github.com/codeanding/onepiece-rag
cd onepiece-rag
docker-compose up -d
# Visit http://localhost:3000

Check the README for detailed setup instructions.

Final Thoughts

Building this showed me the best way to explain RAG - use a domain you love. The Buccaneer problem wasn't a bug; it was the perfect example of how RAG fails.

Every question it can't answer is a chance to teach it something new. That's the fun part.

If you're thinking about building a RAG system, my advice: pick a domain you love. You'll be debugging it at 2am, and you should at least enjoy the data.

Now if you'll excuse me, I need to go ask my nakama about the Void Century.

In the next entry, we'll explore a more real use case - RAG for the healthcare industry. Stay tuned!

Keep coding and learning!

In my previous post, I covered how I use ElevenLabs to generate personalized music. Today, let's dive into the backend.

What is Supabase?

Supabase is an open-source Firebase alternative that provides backend services for developers. I chose it for this project because:

• Free tier: Generous limits for side projects (500MB database, 1GB storage, 50K monthly active users)
• Framework support: Official SDKs for JavaScript, Flutter, Python, and integrations with Next.js, Astro, SvelteKit, etc.
• All-in-one: Database, auth, and storage in one platform - fewer services to manage

For this project, I used three of its core features:

• Database: PostgreSQL with real-time subscriptions and auto-generated APIs
• Authentication: Email/password, magic links, and OAuth providers
• Storage: File storage with CDN delivery, perfect for serving audio files

Database Design: Thinking in Layers

Before writing any code, I had to think about how to structure my data. The key insight was separating user input from AI output.

Here's what I came up with:

┌──────────────────────────────────┐
│   profiles (credits, settings)   │
└────────────────┬─────────────────┘
                 │
                 ▼
┌──────────────────────────────────┐
│  soundtracks (title, year)       │
└────────────────┬─────────────────┘
                 │
        ┌────────┴────────┐
        ▼                 ▼
┌───────────────┐  ┌───────────────┐
│    moments    │  │    tracks     │
│  (user input) │─▶│  (AI output)  │
└───────────────┘  └───────────────┘

Why this separation matters:

1. Re-generation: If a track generation fails, I can retry without losing the user's original moment description
2. Partial success: 3 out of 5 tracks can succeed while 2 fail
3. Audit trail: I store the exact prompt used for each track, so I can debug or reproduce results

Pro tip: Supabase can generate TypeScript types from your schema (similar to what Prisma does). It's been really helpful for catching errors early.

Authentication with Magic Links

The frontend is built with Astro using SSR mode. For Supabase auth in SSR frameworks, you need cookie-based sessions. The @supabase/ssr package handles this.

A Note on API Keys

Supabase recently introduced a new API key system. You'll see two types:

• Publishable key (sb_publishable_...): Safe for client-side code. Security comes from Row Level Security (RLS) policies, not from hiding the key.
• Secret key (sb_secret_...): Server-side only. Bypasses RLS - never expose this in client code.

The older anon and service_role keys still work but are being phased out.

Row Level Security (RLS)

RLS is what makes the publishable key safe. It controls what each user can access at the database level:

-- Users can only read their own soundtracks
create policy "Users read own soundtracks"
on soundtracks for select
using (auth.uid() = user_id);

Without RLS enabled, your data is exposed to anyone with the publishable key. Supabase shows security alerts in your dashboard if tables are missing RLS policies - pay attention to them!

Setting Up the Clients

For browser-side:

// src/lib/supabase/client.ts
import { createBrowserClient } from '@supabase/ssr';

export const supabase = createBrowserClient<Database>(
  import.meta.env.PUBLIC_SUPABASE_URL,
  import.meta.env.PUBLIC_SUPABASE_PUBLISHABLE_KEY
);

For server-side (Astro), you need to manage cookies manually with getAll() and setAll() handlers. See the @supabase/ssr documentation for the full implementation.

Middleware for Protected Routes

To protect routes, I use Astro middleware:

// src/middleware.ts
export const onRequest = async ({ locals, url, cookies, redirect }) => {
  const supabase = createServerSupabaseClient(cookies);
  const { data: { user } } = await supabase.auth.getUser();

  const protectedRoutes = ['/create', '/profile'];
  const isProtected = protectedRoutes.some(route =>
    url.pathname.startsWith(route)
  );

  if (isProtected && !user) {
    return redirect(`/auth/login?redirect=${url.pathname}`);
  }

  locals.user = user;
};

File Storage for Audio

After ElevenLabs generates an MP3, I upload it directly to Supabase Storage:

// Upload to Supabase Storage
const fileName = `${user.id}/${soundtrackId}/track_${orderIndex}.mp3`;

const { error: uploadError } = await supabase.storage
  .from('soundtracks')
  .upload(fileName, audioBuffer, {
    contentType: 'audio/mpeg',
    upsert: true,
  });

// Get public URL for playback
const { data: { publicUrl } } = supabase.storage
  .from('soundtracks')
  .getPublicUrl(fileName);

The path structure {user_id}/{soundtrack_id}/track_{index}.mp3 makes it easy to:

• Find all tracks for a soundtrack
• Clean up when a user deletes their data
• Set bucket policies per user

Bucket Policies

Storage buckets also need policies. I configured mine to allow public reads (so anyone can play shared soundtracks) but restrict writes to authenticated users:

-- Allow public read access
create policy "Public read access"
on storage.objects for select
using (bucket_id = 'soundtracks');

-- Allow authenticated users to upload
create policy "Authenticated users can upload"
on storage.objects for insert
with check (bucket_id = 'soundtracks' and auth.role() = 'authenticated');

Rate Limiting

Supabase doesn't include built-in rate limiting for the Data API. Common options:

• Cloudflare: Free rate limiting rules if your domain is proxied through them
• Redis (Upstash): Best for high-traffic apps with atomic operations
• Database table: Simple approach for smaller projects

For this project, I use Cloudflare at the DNS level (my domain is proxied through them), plus a simple usage_logs table for app-level tracking:

async function checkRateLimit(userId: string, action: string) {
  const windowMs = 60 * 60 * 1000; // 1 hour
  const maxRequests = 10; // 10 tracks per hour
  const since = new Date(Date.now() - windowMs);

  const { count } = await supabase
    .from('usage_logs')
    .select('*', { count: 'exact' })
    .eq('user_id', userId)
    .eq('action', action)
    .gte('created_at', since.toISOString());

  return { allowed: (count || 0) < maxRequests };
}

For more options, see Supabase's guide on securing your API.

That's how I integrated auth, database, and storage with Supabase. For a side project, having everything in one platform with a free tier made it easy to go from idea to deployed app.

You can try the app at soundtrack.codeanding.com/en. Have you used Supabase with Astro or another SSR framework? I'd love to hear about your experience!

This is part 2 of a 2-part series. Part 1 covers how I use ElevenLabs Music API to generate personalized songs from life moments.

What if you could hear those moments as songs?

That's exactly what I built: a Year Soundtrack Generator that transforms your life moments into personalized AI-generated songs. Before we dive into the code, here's what we're building: soundtrack.codeanding.com/en

Why ElevenLabs Music API?

Earlier this year, I participated in a hackathon where we received ElevenLabs credits. Most people know them for voice cloning and text-to-speech, but they also have a Music API that generates complete songs with vocals. With the year ending and credits still available, I wanted to build something meaningful before they expired.

ElevenLabs stood out because:

• It generates music with actual vocals (not just instrumentals)
• The API is straightforward to integrate
• It supports multiple languages for lyrics

Here's the breakdown of how it works:

const response = await fetch('https://api.elevenlabs.io/v1/music', {
  method: 'POST',
  headers: {
    'xi-api-key': this.apiKey,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    prompt: request.prompt,
    music_length_ms: Math.min(Math.max(durationMs, 3000), 300000), // 3s to 5min
    model_id: 'music_v1',
    force_instrumental: false, // Allow vocals based on prompt
  }),
});

The key parameters are:

• prompt: A text description of what you want the song to be about
• music_length_ms: Duration between 3 seconds and 5 minutes
• model_id: Currently music_v1
• force_instrumental: Set to false to include vocals

Credits-wise, expect around 500 credits per minute of generated audio.

The Challenge: Turning Text into Music

Now comes the fun part - how do you tell an AI to make a song about "I got promoted at work"?

My first attempts were... not great. When I just passed the user's moment description directly, the AI would generate very literal lyrics like "I went to the office and got a promotion." Not exactly the emotional soundtrack I was going for!

I needed a smarter approach. Here's my 3-layer prompt system:

Layer 1: Emotion → Music Theory

First, I map emotions to actual music characteristics. A happy moment should sound different from a triumphant one:

const EMOTION_TO_MUSIC: Record<string, string> = {
  happy: 'upbeat, major key, bright instrumentation, energetic tempo around 120-140 BPM',
  sad: 'melancholic, minor key, slow tempo 60-80 BPM, piano and strings, emotional',
  nostalgic: 'warm, analog feel, vintage production, reverb-soaked, mid-tempo',
  triumphant: 'epic, orchestral swells, powerful drums, anthemic, building crescendo',
  peaceful: 'ambient, soft, acoustic, gentle, relaxing, 70-90 BPM',
  energetic: 'high energy, driving beat, electronic elements, 130+ BPM, punchy',
};

Layer 2: Genre → Style Modifiers

Next, users select their preferred music style. Each genre has specific production characteristics:

const STYLE_MODIFIERS: Record<string, string> = {
  pop: 'catchy hooks, polished production, radio-friendly pop',
  rock: 'electric guitars, drums, raw rock energy',
  'lo-fi': 'lo-fi hip hop, vinyl crackle, mellow beats, chill',
  electronic: 'synthesizers, electronic beats, modern EDM production',
  'j-rock': 'Japanese rock, anime soundtrack style, visual kei influences',
  'k-pop': 'Korean pop, bright synths, catchy hooks, polished K-pop production',
  // ... 10 more genres
};

Layer 3: Language → Vocal Direction

Since the app supports Spanish, English, and Portuguese, I also direct the AI on vocal style:

const LANGUAGE_VOCAL_DIRECTION: Record<string, string> = {
  en: 'English vocals, clear pronunciation',
  es: 'Spanish vocals, Latin influence',
  pt: 'Portuguese vocals, Brazilian or Portuguese influence',
};

The Secret Sauce: Artistic Transformation

Here's what I learned after experimenting with different prompts: the model tends to generate very literal lyrics. If your moment is "Beach vacation with friends," you'll get lyrics about sand and waves.

The fix? Explicit instructions for poetic, metaphorical writing:

const prompt = [
  styleDesc,
  emotionDesc,
  vocalLang,
  `Song about: "${safeTitle}"`,
  `Core emotion to convey: ${emotionContext}`,
  `Context for inspiration (transform into poetry, NEVER copy literally): ${safeDescription}`,
  'IMPORTANT: Write artistic, metaphorical lyrics using imagery and symbolism',
  'Focus on the emotional journey and transformation, not literal events',
  'Use universal themes like light/dark, rise/fall, storms/calm to express feelings',
  '30-45 second track with vocals, clear intro and outro',
].join('. ');

The key phrases that changed everything:

• "Transform into poetry, NEVER copy literally"
• "Artistic, metaphorical lyrics using imagery and symbolism"
• "Universal themes like light/dark, rise/fall, storms/calm"

Now instead of "I went to the beach," I get lyrics about "waves carrying yesterday's promises" and "salt-kissed memories fading into golden horizons."

Multi-language Support

Additionally, for this to work in Spanish and Portuguese, I had to think about cultural context too. The LANGUAGE_VOCAL_DIRECTION doesn't just specify the language - it adds cultural flavor:

• English: Clear pronunciation for accessibility
• Spanish: Latin influence for rhythm and warmth
• Portuguese: Brazilian/Portuguese influence for that saudade feeling

What I Learned

After building this, here are my key takeaways:

What works well:

• Emotional mapping creates genuinely different-sounding tracks
• The "artistic transformation" instruction dramatically improves lyrics
• 45-second tracks are the sweet spot for individual moments
• Multi-language vocals work surprisingly well

What could be better:

• The model sometimes doesn't follow style instructions closely (especially for niche genres)
• Very specific prompts can confuse the model
• No control over specific instruments or arrangements

Cost breakdown for a typical soundtrack:

• 5 moments × 45 seconds = ~3.75 minutes of audio
• ~1,875 credits per soundtrack
• Plus optional 2-minute "global" track combining all moments

Try It Yourself

I hope you found this guide helpful! If you want to try generating your own year soundtrack, check out the live app: soundtrack.codeanding.com/en

The ElevenLabs Music API documentation is here: ElevenLabs Docs

I'd love to hear your thoughts - have you experimented with ElevenLabs Music API? What creative uses have you found for AI-generated music?

Let's keep coding and learning together!

This is part 1 of a 2-part series. In part 2, I'll cover how I used Supabase for authentication, database, and audio file storage.

Bienvenidos a esta nueva entrada donde recopilo las preguntas más frecuentes de la comunidad sobre Claude Code. Si alguna vez te has preguntado cómo empezar, cómo optimizar tu flujo de trabajo, o simplemente quieres saber qué diablos es MCP… ¡estás en el lugar correcto!

Este post nació como material de apoyo para el meetup de Claude Code en Santiago, pero decidí expandirlo para que sirva como referencia para cualquiera que quiera sacarle el máximo provecho a esta herramienta.

¿Qué encontrarás aquí?

• Primeros pasos con Claude Code
• Workflows y mejores prácticas
• Optimización de tokens y contexto
• Manejo de proyectos grandes
• Integraciones (Figma, MCP, GitHub)
• Seguridad y privacidad
• Novedades recientes
• Cursos gratuitos para seguir aprendiendo
• Preguntas para el meetup

¡Vamos a ello!

1. Primeros pasos

¿Cómo empezar a usar Claude Code?

La instalación es desde la terminal. Necesitas Node.js 18+ y una cuenta de Claude (Pro, Max, Team, Enterprise) o créditos en la API.

npm install -g @anthropic-ai/claude-code
claude

Al ejecutar claude por primera vez, se abre el proceso de autenticación. Después, navega a cualquier directorio de proyecto y ejecuta claude para empezar.

Recursos:

• Quickstart oficial
• Guía de instalación

¿Y si soy principiante en programación?

Claude Code tiene un modo llamado Learning que convierte la experiencia en colaborativa. En lugar de solo generar código, Claude te pide que implementes pequeñas piezas tú mismo, marcándolas con TODO(human).

Para activarlo: /output-style learning

También existe el modo Explanatory que agrega "Insights" educativos mientras trabaja, explicando decisiones de implementación y patrones del codebase.

Recursos:

• Output styles

2. Workflows y mejores prácticas

¿Cómo estructurar flujos de desarrollo end-to-end?

La clave está en usar Claude Code para tareas donde pueda iterar contra un objetivo claro: tests, mocks visuales, o especificaciones.

Flujo sugerido (TDD):

1. Pedir a Claude que escriba tests basados en inputs/outputs esperados
2. Verificar que los tests fallen
3. Pedir que implemente el código sin modificar los tests
4. Iterar hasta que todos los tests pasen
5. Commit cuando estés satisfecho

Para trabajo visual (Figma → Código):

1. Dar a Claude acceso a screenshots (via MCP Puppeteer o manualmente)
2. Pasar el mock visual (imagen o path)
3. Pedir que implemente, tome screenshots, e itere hasta que coincida

Recursos:

• Best practices for agentic coding

Tips rápidos:

• Prompt suggestions: Claude ahora sugiere prompts mientras escribes. Presiona Tab para aceptar o Enter para enviar
• Cambiar modelo: Alt+P (Linux/Windows) u Option+P (macOS) para cambiar de modelo mientras escribes
• Thinking mode: Viene activado por defecto para Opus 4.5. Configúralo en /config

¿Cómo configurar contexto por proyecto?

Hay dos formas principales de darle contexto persistente a Claude Code:

1. CLAUDE.md — El archivo de memoria del proyecto. Claude lo lee automáticamente al iniciar sesión. Puedes incluir convenciones de código, estructura del proyecto, comandos comunes e instrucciones de resumen para /compact.

# Proyecto X

## Stack
- React 18 + TypeScript
- PostgreSQL + Prisma

## Convenciones
- Usar functional components
- Tests con Vitest
- Commits en español

## Comandos útiles
- `npm run dev` - desarrollo
- `npm run test` - tests

2. .claude/rules/ — Directorio para reglas modulares del proyecto. Útil cuando tienes muchas convenciones y quieres organizarlas en archivos separados (ej: frontend.md, testing.md, api.md). Claude carga todas las reglas automáticamente. Más info en memory docs.

También puedes crear slash commands personalizados en .claude/commands/:

echo "Analiza el performance de este código y sugiere 3 optimizaciones:" > .claude/commands/optimize.md

Después usas /project:optimize en Claude Code.

Recursos:

• Common workflows
• Slash commands

3. Optimización de tokens y contexto

¿Cómo evitar perder contexto en sesiones largas?

El problema principal es que cuando el contexto se llena, Claude Code hace un resumen automático (compaction) y puede perder detalles importantes.

Estrategias:

1. Usar /compact manualmente antes de que se llene, con instrucciones específicas:

   /compact Enfócate en los cambios de código y resultados de tests
   

2. Configurar instrucciones de resumen en CLAUDE.md:

   # Summary instructions
   Cuando uses compact, enfócate en:
   - Output de tests
   - Cambios de código
   - Decisiones de arquitectura
   

3. Dividir tareas complejas en sesiones más pequeñas y enfocadas

4. Usar subagents para tareas específicas (cada uno tiene su propio contexto)

5. Limpiar entre tareas: /clear reinicia el contexto

Gestión de sesiones:

• Named sessions: Usa /rename para nombrar tus sesiones y /resume <n> desde la terminal (claude --resume <n>) para reanudarlas después
• /stats: Muestra estadísticas interesantes de tu uso (modelo favorito, gráfico de uso, streak)

¿Cuánto cuesta usar Claude Code?

Depende del tipo de suscripción:

Para usuarios de API/Console, el costo promedio reportado es ~$6/desarrollador/día, pero varía según el modelo usado (Opus es más caro que Sonnet/Haiku) y la intensidad de uso.

Usa /cost para ver estadísticas de uso de la sesión actual (solo aplica para usuarios de API).

Recursos:

• Manage costs

4. Proyectos grandes y código legacy

¿Cómo maneja Claude repositorios con múltiples servicios?

Claude Code usa agentic search para entender la estructura del proyecto. No requiere que selecciones archivos manualmente — analiza dependencias y estructura de forma autónoma.

Para proyectos muy grandes, puedes trabajar en paralelo usando git worktrees:

git worktree add ../project-feature-a -b feature-a
cd ../project-feature-a
claude

Cada worktree tiene su propio estado de archivos aislado, permitiendo múltiples instancias de Claude Code trabajando en paralelo sin interferir.

Background agents: Claude Code ahora soporta agentes que corren en segundo plano mientras tú sigues trabajando en otras cosas. Ideal para tareas largas como refactoring o generación de tests.

¿Cómo hacer reverse engineering y documentar sistemas existentes?

1. Navega al proyecto y ejecuta claude
2. Pregunta: "Explícame este codebase" o "¿Cuál es la arquitectura de este proyecto?"
3. Claude analizará archivos y proporcionará un resumen

Para documentación continua, el equipo de Security de Anthropic recomienda usar Claude para ingerir múltiples fuentes de documentación, crear runbooks en markdown, y guardar estos documentos condensados como contexto para debugging.

¿Cómo busca Claude en el codebase?

Claude Code usa búsqueda agéntica, no es puramente semántica ni puramente léxica. Claude decide qué archivos examinar basándose en la tarea, ejecuta búsquedas, y profundiza según necesite.

Internamente usa ripgrep para búsquedas de texto. Si tienes problemas con búsquedas, instala ripgrep en tu sistema:

# macOS
brew install ripgrep

# Ubuntu/Debian
sudo apt install ripgrep

5. Integraciones

¿Cómo funciona la integración con Figma?

Hay varias formas:

1. Copiar/pegar imágenes: Arrastra un screenshot del diseño directamente a Claude Code
2. Path de archivo: "Implementa el diseño en /path/to/mock.png"
3. MCP con Figma: Conecta el servidor MCP de Figma para acceso directo a tus archivos de diseño

El workflow recomendado:

1. Alimentar archivos de Figma a Claude Code
2. Configurar loops autónomos donde Claude escribe código, corre tests, e itera
3. Revisar soluciones antes de refinamientos finales

Recursos:

• Connectors directory
• How Anthropic teams use Claude Code

¿Qué es MCP y cómo se usa?

Model Context Protocol (MCP) es un estándar abierto para conectar aplicaciones de IA con sistemas externos. Piensa en MCP como un puerto USB-C para aplicaciones de IA.

Con MCP puedes conectar Claude Code a issue trackers (Jira, Linear, GitHub), bases de datos (PostgreSQL), herramientas de diseño (Figma), servicios de comunicación (Slack, Gmail), y cientos más.

Configuración básica:

# Agregar un servidor MCP
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Listar servidores configurados
claude mcp list

# Ver estado
/mcp

Recursos:

• MCP en Claude Code
• MCP Overview

¿Qué otras integraciones hay disponibles?

Claude in Chrome (Beta): Una extensión que te permite controlar tu browser directamente desde Claude Code. Claude puede leer, hacer click y navegar websites junto contigo. Útil para workflows de testing visual y scraping.

Ver más en: claude.ai/chrome

Claude Code in Slack: Lanzado en diciembre 2025, permite delegar tareas de coding directamente desde threads de Slack. Claude analiza mensajes recientes para determinar el repo correcto, postea actualizaciones de progreso, y comparte links para revisar PRs.

Esto representa un shift importante: los coding assistants están migrando de IDEs hacia herramientas de colaboración donde ya ocurre la comunicación del equipo.

6. Seguridad y privacidad

¿Cómo se protege la información privada?

Safeguards de Claude Code:

1. Sistema de permisos: Por defecto es read-only. Pide permiso antes de modificar archivos o ejecutar comandos
2. Detección de inyección de comandos: Comandos bash sospechosos requieren aprobación manual
3. Verificación de confianza: Primera ejecución en un codebase y nuevos servidores MCP requieren verificación
4. Blocklist de comandos: Bloquea comandos riesgosos como curl y wget por defecto

Sandboxing:

Claude Code incluye sandboxing a nivel de OS que proporciona aislamiento de filesystem (solo lectura/escritura en el directorio de trabajo) y aislamiento de red (acceso a internet solo a través de proxy controlado).

Para activar: /sandbox

Privacidad de datos:

• Los datos se encriptan en tránsito y en reposo
• Por defecto, empleados de Anthropic no pueden acceder a tus conversaciones
• Puedes desactivar el uso de tus datos para entrenamiento en Privacy Settings
• Chats en modo Incognito no se usan para mejorar modelos

Recursos:

• Security
• Claude Code Sandboxing
• Privacy Center

¿El código que genera Claude sigue buenas prácticas de seguridad?

Claude está entrenado para seguir buenas prácticas, pero como con cualquier herramienta:

1. Siempre revisa el código antes de ejecutar o hacer commit
2. Usa el sistema de permisos, no actives "Accept all" para todo
3. Considera usar VMs para scripts que interactúan con servicios externos
4. En producción, implementa hooks de validación y testing automatizado

7. Futuro de Claude Code

¿Qué viene próximamente?

Basado en los anuncios recientes:

• Claude Agent SDK: El SDK de Claude Code se está expandiendo para construir agentes de propósito general, no solo coding
• Mejoras en MCP: Expansión continua del ecosistema de integraciones
• Claude Code Web: Ya disponible como research preview — ejecución en sandbox aislado en la nube, sin necesidad de CLI local
• Tool Search Tool: Descubrimiento dinámico de herramientas para reducir uso de contexto

¿Usaron Claude Code para construir Claude Code?

Sí. Anthropic usa Claude Code extensivamente en su desarrollo interno. El equipo de Product Engineering lo describe como su "first stop" para cualquier tarea de programación.

8. Claude vs Competencia

¿Por qué elegir Claude Code sobre otras herramientas?

Diferenciadores clave:

1. Terminal-first: No es otro IDE ni chat window. Trabaja donde ya trabajas
2. Agnóstico: No impone workflows específicos. Flexible, scriptable, componible
3. Unix philosophy: Diseñado para ser compuesto con otras herramientas
4. MCP: Estándar abierto para integraciones (no lock-in)
5. Transparencia: Siempre pide permiso, muestra su razonamiento

Modelos disponibles:

• Opus 4.5 (más inteligente)
• Sonnet 4.5 (balance)
• Haiku 4.5 (más rápido)

9. Novedades: Agent Skills (18 dic 2025)

¿Hay planes para mejorar el versionado de skills?

¡Justo ayer Anthropic anunció varias mejoras!

1. Agent Skills es ahora un estándar abierto — La especificación está disponible en agentskills.io, permitiendo portabilidad entre plataformas (incluso fuera de Claude)

2. Nuevo endpoint /v1/skills — Control programático para versionado y gestión de skills custom. Puedes referenciar "latest" durante desarrollo y fijar versiones específicas para producción

3. Gestión organizacional — Administradores de Team y Enterprise pueden gestionar skills desde una ubicación central

4. Directorio de skills de partners — Skills preconstruidos de Atlassian (Jira, Trello), Figma, Canva, Stripe, Notion, Zapier y más

5. Quick-create flow — Crear skills describiendo lo que quieres en lenguaje natural

Recursos:

• Agent Skills Announcement
• Agent Skills Open Standard

10. Cursos gratuitos para seguir aprendiendo

Si quieres profundizar más en Claude Code, estos cursos gratuitos son un excelente punto de partida:

Claude Code in Action (Anthropic Academy)

El curso oficial de Anthropic. Cubre desde la arquitectura de coding assistants hasta integraciones avanzadas con MCP y GitHub.

Lo que aprenderás:

• Arquitectura de Claude Code y sistema de herramientas
• Gestión de contexto y recursos del proyecto
• Custom commands y automatizaciones
• Integración con GitHub workflows
• Hooks y el SDK de Claude Code

Prerrequisitos: Familiaridad con terminal y Git básico

Ver más en: anthropic.skilljar.com/claude-code-in-action

Claude Code: Software Engineering with Generative AI Agents (Coursera)

Curso de Vanderbilt University impartido por Dr. Jules White. Este es más extenso (~5 horas) y va desde cero hasta workflows avanzados con múltiples agentes en paralelo.

Lo que aprenderás:

• Patrón "Best of N" para generar múltiples versiones de features
• CLAUDE.md files para contexto persistente
• Git worktrees con múltiples instancias de Claude
• Subagents trabajando en paralelo
• Prompting multimodal (de boceto a código)

Prerrequisitos: Experiencia básica en desarrollo de software y Git

Ver más en: coursera.org/learn/claude-code

Claude Code: A Highly Agentic Coding Assistant (DeepLearning.AI)

Curso corto (~2 horas) de Anthropic en colaboración con DeepLearning.AI. Muy práctico, con tres proyectos hands-on.

Proyectos incluidos:

• Explorar y desarrollar el codebase de un RAG chatbot
• Refactorizar un Jupyter notebook de e-commerce y convertirlo en dashboard
• Crear una web app desde un mockup de Figma

Lo que aprenderás:

• CLAUDE.md y gestión de contexto
• Testing, debugging y refactoring
• Git worktrees para desarrollo paralelo
• GitHub integration y hooks
• MCP servers (Playwright, Figma)

Prerrequisitos: Familiaridad con Python y Git

Ver más en: deeplearning.ai/short-courses/claude-code-a-highly-agentic-coding-assistant

11. Preguntas para el Meetup

Las siguientes preguntas serán respondidas durante el meetup y este post se actualizará con las respuestas:

• ¿Cómo anticipa Anthropic la evolución de agentic systems en mercados con infraestructura fragmentada (LatAm)?
• ¿Cuál será el impacto en el trabajo de ingenieros a mediano/largo plazo?
• ¿Habrá programas de internship para latinoamericanos?
• ¿Cómo se proyecta Claude Code a futuro?
• ¿Cómo ven el desarrollo de software en 5-10 años?
• ¿Cuándo habrá más uso de tokens por semana?

Recursos adicionales

Documentación oficial:

• Claude Code Overview
• Claude Code Best Practices
• Common Workflows

Directorio de herramientas:

• claude.ai/directory

Comunidad:

• Discord - Claude Developers
• GitHub - Claude Code

Post actualizado: 19 de diciembre del 2025

¿Tienes más preguntas? Déjalas en los comentarios y las agregaremos al post.

This month I had a very special experience: I participated as a speaker at React Miami 2025, an event that wasn't just a technical opportunity, but also a moment to step out of my comfort zone. In this post, I want to share how it went from application to stage — with nerves, learnings, and moments that I'll treasure for a long time.

It All Started with an Application

After giving a talk at AWS Community Day Argentina, I saw that the Call for Speakers was opened for an event called React Miami. I wanted to try something different, so I submitted a talk about a stack I had been using recently: React + Serverless + Terraform.

At work, I had been building solutions that automate infrastructure with Terraform, and I thought it would be a good opportunity to share how this can help frontend teams focus on creating amazing experiences for users, without having to worry about the infrastructure part.

A few months later, I received an email from Michelle Bakels: my talk had been accepted! The mix of nerves and excitement I felt at that moment was incredible.

Day Before the Event: Equipment Check and First Connections

The event was held at the Hyatt Regency. The day before the event, Wednesday, April 16th, we did the speaker test check — a session to test our equipment, adapters, slides, and make sure everything was ready for the stage. While other speakers were doing their tests, a relaxed atmosphere developed where we could meet and exchange experiences.

That's where I met Aileen Villanueva, also a speaker. I had written to her before the event after seeing her name on the agenda, and that's when we discovered that we had already coincided at events like Google Community Nation and Google I/O, although we had never spoken. It was really nice to meet in person at React Miami. (Spoiler: Her talk was fantastic!).

These preliminary moments were key to helping me feel more confident. There's something very special about connecting with other people who share the same nervousness and excitement.

A Message That Marked the Beginning

The first official day of the event, Thursday, April 17th, opened with an important message about something that isn't always mentioned in these types of spaces: mental health in technology.

Gabe Greenberg, CEO of G2i, presented Developer Health, an initiative focused on emotional well-being for people working in software development. It was refreshing to hear from the start that we are more than just code, and that it's okay to talk about how we feel.

This initiative particularly resonated with me. Seeing an event of this caliber prioritize emotional well-being seemed like an important step for our industry. The organization that Gabe formed with G2i is creating a necessary space where we can talk about code and also about how we feel while writing it. I hope more events incorporate this approach.

Throughout the day, there were many interesting talks on different topics, and I found a lot of value in the presentations. Check out the G2i YouTube channel so you can see them for yourselves.

Swag, Community, and Many Conversations

The opening day was also when I got to explore the booths. I learned about new tools, talked with various teams, and of course, got some nice swag for the community 😄

At the speakers and sponsors meetup, I met Samhitha Rama Prasad, who mentioned that this was her first time as a speaker. I was really happy to hear that because she did a great job. Kudos to her!

This networking between talks and events was one of the most enriching parts. There's as much learning in informal conversations as there is in official presentations.

The 5K Run... That Inspired Me Anyway

On the morning of Friday, April 18th, a 5K run was organized to start the day with energy. I couldn't attend due to insomnia the night before 🙈, but I loved the idea. It would be great to do something like this in the city where I am now, as a way to combine community, technology, and movement. I'm keeping this idea for later.

My Talk

That same Friday the 18th, at 10:05 a.m., I gave my talk: "React, Serverless, Terraform: The Dream Team for Fullstack Wizards". Although I had given other talks before, this was my first time giving a technical talk in English, which made the preparation more intense.

Since I didn't want to risk technical problems, I decided to record the demo on video. It was a calm decision that allowed me to focus on the message.

I started out quite nervous, but decided to break the ice with some jokes to connect with the audience. I heard some laughter (or at least that's what it seemed like from the stage!), which helped me relax a bit. As the presentation progressed, I felt it flowing better. With the stage lights, it was difficult to see the audience clearly, but the talk moved forward, and I was able to share everything I had prepared.

When it finished, I felt great relief and satisfaction. Giving a technical talk in another language was quite a challenge, but it was also an enriching experience that helped me grow both professionally and personally. Seeing that I could communicate complex ideas in English and hold the audience's attention confirmed that stepping out of your comfort zone is truly worth it.

If you want to see the presentation and more, they're here:
👉 codeanding.com/react-serverless-terraform-the-dream-team-for-fullstack-wizards

What I Liked About the Content

One of the things I enjoyed most was seeing how other speakers approach topics that I use daily. I was particularly struck by:

• The use of Zustand to manage state in a clear and simple way, without unnecessary complications. I found it especially interesting because I've seen Zustand implemented in production projects, and confirming its benefits in the presentations gave me ideas to optimize how we're currently using it.

• The practical explanations about React 19 updates, which left me with ideas to apply in my next projects.

If you want to see the talks, they'll be uploaded soon to the G2i channel:
📺 youtube.com/@g2i_co
And the complete schedule is here:
🗓 reactmiami.com/schedule

The Miami Experience

Something I didn't expect was how good I felt in Miami (the weather was very similar to Lima 🇵🇪 in summer). The city has a special vibe, relaxed but energetic at the same time. I loved finding so much Latino community – hearing Spanish in the streets made me feel a little closer to home.

Between event sessions, I was able to walk along the waterfront and see the impressive yachts in the bay. One of my favorite moments was trying a Cuban cafecito at a small local cafe – that shot of sweet, strong coffee was the perfect boost to keep going with energy.

The kindness of the people was notable, from the hotel staff to the event attendees. That warm atmosphere definitely contributed to making the experience even more special.

Some Tips If You're Thinking of Applying

If you're considering applying to an international event or one in another language, here's what helped me:

• Do it even if you're afraid. The worst that can happen is that you don't get selected... and even then, you'll have already learned a lot.

• Record your demo if you can. It gave me peace of mind and allowed me to focus on speaking clearly.

• It's okay if you don't sleep perfectly. Sometimes nerves win, but what's important is to be present when the moment arrives.

• Connect with the community. It's easier than it seems, and you form beautiful connections.

• Use humor to break the ice. A small joke can help you connect with the audience and relax.

What's Next?

Tickets are already available for the 2026 edition:
🎟 tickets.joinshowup.io/event/react-miami-2026-oloikn

If you have the opportunity to attend or apply, do it! You never know what might happen when you dare to step out of your comfort zone.

For me, this experience has been a turning point. Now I feel ready to continue applying to more international Call for Papers in English. I discovered that language is not as big a barrier as I imagined, and that sharing knowledge in global communities is a tremendously enriching experience.

Thanks for reading this far :)
Let's keep coding and learning together 💻🌴

Modern React applications often start simple, but quickly become complex as user bases grow. The traditional deployment process introduces significant challenges:

• Managing server infrastructure becomes increasingly time-consuming

• Scaling becomes difficult and expensive

• Configuration drift makes environments inconsistent

• Deployment processes become brittle and error-prone

A Fullstack Alternative

The combination of React, Serverless, and Terraform creates a powerful solution to these challenges.

React: Frontend Excellence

React continues to dominate frontend development with good reason. Its component-based architecture and robust ecosystem make it ideal for building interactive interfaces. But its greatest strength lies in allowing developers to focus on UI logic without worrying about infrastructure.

Serverless: Backend Simplicity

Serverless architecture removes the need to provision and manage servers. AWS Lambda functions, API Gateway, DynamoDB, and S3 provide everything needed for a backend that:

• Automatically scales with demand

• Reduces operational overhead

• Enables usage-based cost efficiency

• Supports rapid development through modular services

Terraform: Infrastructure Automation

Terraform brings infrastructure into the same development lifecycle as your application code. Here's a quick example:

resource "aws_lambda_function" "api_function" {
  function_name = "api_handler"
  runtime       = "nodejs18.x"
  handler       = "index.handler"
  role          = aws_iam_role.lambda_role.arn
  s3_bucket     = aws_s3_bucket.lambda_bucket.id
  s3_key        = "lambda.zip"
}

This declarative approach ensures that your infrastructure is:

• Version-controlled alongside your code

• Consistent across environments

• Self-documenting

• Reproducible with a single command

Slide Deck from the Talk

You can view the full presentation below:

Implementation Guide

For those who want to implement this architecture, I’ve published the exact example used in the demo from my React Miami talk. It’s a simple card exchange app built with React, connected to a serverless backend — deployed and managed entirely with Terraform.

GitHub Repository: https://github.com/codeanding/exchange-tcg.git

The repository includes:

• A complete React application

• Serverless backend functions

• Terraform configuration files

• Deployment scripts and CI/CD templates

Key Benefits for Development Teams

Teams implementing this architecture typically see:

• 75% reduction in deployment time

• Significant decrease in infrastructure management overhead

• Improved consistency between development and production

• Faster onboarding for new team members

Common Challenges and Solutions

While this approach solves many problems, it introduces some new considerations:

Cold Starts: Lambda functions can experience latency on first execution. This can be mitigated through provisioned concurrency or careful function design.

State Management: With distributed serverless functions, state management requires different approaches than traditional monoliths.

Local Development: Testing the full stack locally requires special tooling like AWS SAM or localstack.

Final Thoughts

If you found the conference talk helpful, please share your feedback and let me know how you're implementing these patterns in your own work!

Until the next post, let's keep coding and learning together!

Spoiler: No más clics infinitos en la consola de AWS... ¡Solo código que puedes versionar y reutilizar!

Repositorio del proyecto

Ver en GitHub

Incluye:

• Infraestructura modular con Terraform

• Backend en NestJS + Prisma

• Scripts listos para despliegue y destrucción

• Buenas prácticas para ECR, ECS, ALB, RDS y más

Presentación de la charla

Puedes revisar las slides aquí:
Infraestructura como Código con Terraform - Presentación

Demo y cómo usarlo

En el repo encontrarás todo lo necesario para:

• Desplegar toda la infraestructura con un solo script

• Generar un diagrama visual de tu arquitectura

• Construir y subir tu imagen Docker a ECR

• Probar tu backend con Swagger

• ¡Y destruir todo cuando terminas sin complicaciones!

Recursos útiles

• Terraform AWS Provider

• Guía oficial de ECS Fargate

• NestJS

• Prisma

• Graphviz para Terraform

Gracias

Gracias a quienes estuvieron en la charla y a quienes siguen aprendiendo y compartiendo. ¡Espero que esto te inspire a automatizar tu infraestructura sin miedo!

¡Nos vemos!

Join me to see how I spent some time doing what we like most: automating something we can do daily in 1 minute.

For this we need:

• An Amazon AWS account

• A Slack account

• A reliable source of anime news (in my case I'll use Crunchyroll)

Solution Architecture

Before starting to write code, let me tell you how I thought about this solution. The idea is quite simple: we need something that periodically checks the news and sends it to Slack. But why did I choose these specific AWS services?

The Data Flow

Here's how a news item flows through the system:

1. EventBridge acts as our alarm clock, triggering every morning at 10 AM

2. This "alarm clock" triggers our Lambda function

3. Lambda does the heavy lifting:

   • Connects to Crunchyroll's RSS to get the latest news

   • Processes the information and formats it nicely

   • Sends everything to Slack through a webhook

What is AWS Lambda?

Lambda is like having a small program that sleeps until you need it. The great thing is:

• You only pay when it runs (and the free tier is super generous)

• No need to worry about servers or infrastructure

• It can handle everything from simple tasks to complex processes

• It integrates perfectly with other AWS services

In our case, Lambda is perfect because:

• The task is relatively simple and quick

• We don't need a server running 24/7

• RSS processing and sending to Slack takes seconds

What is AWS SAM?

SAM is like having a personal assistant that handles all the tedious parts of configuring AWS services. Instead of clicking around in the AWS console:

• We write everything in a YAML file

• SAM takes care of creating and configuring everything needed

• Makes development and deployment much simpler

• If something goes wrong, it's easy to destroy everything and start over

What is AWS EventBridge and why use it?

EventBridge is the service that makes all of this automatic. It's like having a cron job in the cloud, but on steroids:

• Can schedule tasks with second-level precision

• Natively integrates with Lambda

• Highly reliable (you won't miss news because the server went down)

• Allows schedule modifications without touching the code

In our case, we configure it to run every day at 10 AM, but we could easily change it to run every hour or even every 5 minutes if we wanted to stay super updated.

Why this architecture?

You might ask yourself, why not use a simple script on a server? Well, this architecture has several advantages:

• Zero-maintenance: No need to worry about operating system updates or dependencies

• Scalable: If we wanted to add more news sources or Slack channels, it's trivial

• Cost-efficient: With the free tier, this will probably be free for a good while

• Reliable: AWS ensures everything works, you only worry about the code

Getting Started

1. Project Structure

Our project will have this structure:

eventbridge-with-sam/
├── src/
│   ├── helpers/
│   │   ├── slack.helper.ts
│   │   ├── xml.helper.ts
│   ├── services/
│   │   └── news.service.ts
│   ├── tasks/
│   │   └── fetch-news.ts
│   ├── interfaces/
│   │   └── news.ts
├── template.yml
└── package.json

2. Code Implementation

Let's go step by step, explaining each part of the code and why we structured it this way. First, our Slack helper (slack.helper.ts). This will handle all communication with Slack:

import axios from 'axios';

export class SlackHelper {
  // Sends formatted messages to Slack using webhook
  static async sendMessage(message: string) {
    try {
      await axios.post(process.env.SLACK_WEBHOOK_URL!, { text: message });
      console.log('Message sent to Slack:', message);
    } catch (error) {
      console.error('Error sending message to Slack:', error);
      throw error;
    }
  }
}

Now, we need a helper to handle the RSS XML (xml.helper.ts):

import { parseStringPromise } from 'xml2js';

export class XMLHelper {
  // Parses XML data into a structured format
  static async parseXML(xml: string) {
    try {
      return await parseStringPromise(xml);
    } catch (error) {
      console.error('Error parsing XML:', error);
      throw error;
    }
  }
}

To keep our code well-typed, we define the interface for our news:

export interface AnimeNewsItem {
  title: string;
  link: string;
}

The main service (news.service.ts) is where the magic happens. This is where we fetch the news and process it:

import axios from 'axios';
import { SlackHelper } from '../helper/slack.helper';
import { XMLHelper } from '../helper/xml.helper';
import { AnimeNewsItem } from '../interfaces/news';

export class NewsService {
  // Main function to fetch and process news
  async fetchAndSendNews() {
    try {
      // Fetch RSS feed
      const response = await axios.get(process.env.CRUNCHYROLL_RSS_URL!);
      const xmlData = response.data;

      // Parse XML to JSON
      const newsJson = await XMLHelper.parseXML(xmlData);
      const rawItems = newsJson.rss.channel[0].item;

      if (!rawItems || rawItems.length === 0) {
        console.log('No news found for today.');
        return;
      }

      // Transform raw items into our NewsItem format
      const items: AnimeNewsItem[] = rawItems.map((news: any) => ({
        title: news.title[0],
        link: news.link[0],
      }));

      // Format message for Slack
      let message = `📰 *Latest News Update:*\n\n`;
      items.forEach((news) => {
        message += `🔹 *${news.title}*\n🔗 ${news.link}\n\n`;
      });

      await SlackHelper.sendMessage(message);
    } catch (error) {
      console.error('Error in news processing:', error);
      throw error;
    }
  }
}

Also, we add our Lambda task (fetch-news.ts) which will be the entry point when EventBridge invokes it:

import { EventBridgeEvent } from 'aws-lambda';
import { NewsService } from '../services/news.service';

export const fetchAndSendNews = async (event: EventBridgeEvent<'Scheduled Event', {}>) => {
  console.log('[Scheduled Task] Fetching news...');
  await new NewsService().fetchAndSendNews();
  console.log('[Scheduled Task] News sent.');
};

Finally, our configuration file (template.yml) that defines all the infrastructure:

AWSTemplateFormatVersion: 2010-09-09
Description: >-
  news-automation

Transform:
  - AWS::Serverless-2016-10-31

Globals:
  Api:
    Cors:
      AllowMethods: "'*'"
      AllowHeaders: "'*'"
      AllowOrigin: "'*'"

  Function:
    CodeUri: ./dist
    Runtime: nodejs18.x
    MemorySize: 128
    Timeout: 10
    AutoPublishAlias: Live

    Environment:
      Variables:
        CRUNCHYROLL_RSS_URL: !Sub '{{resolve:ssm:/services/shared/CRUNCHYROLL_RSS_URL}}'
        SLACK_WEBHOOK_URL: !Sub '{{resolve:ssm:/services/shared/SLACK_WEBHOOK_URL}}'

Resources:
  fetchAndSendNews:
    Type: AWS::Serverless::Function
    Properties:
      Handler: tasks/fetch-news.fetchAndSendNews
      Description: Fetch news from RSS feed and send to Slack
      MemorySize: 300
      Timeout: 900

      Events:
        DailyTrigger:
          Type: Schedule
          Properties:
            Schedule: cron(0 10 * * ? *)
            Enabled: true
            Description: Runs every day at 10:00 AM UTC

The cron expression 0 10 * * ? * will run our function every day at 10:00 AM UTC. Here's the breakdown of the expression:

Additionally, for the template to work, we need to configure some additional resources. First, we'll create the parameters in AWS Systems Manager Parameter Store (SSM):

# Create parameters in SSM
aws ssm put-parameter \
    --name "/services/shared/CRUNCHYROLL_RSS_URL" \
    --value "https://www.crunchyroll.com/newsrss" \
    --type "String"

aws ssm put-parameter \
    --name "/services/shared/SLACK_WEBHOOK_URL" \
    --value "your-slack-webhook-url" \
    --type "SecureString"

We also need a samconfig.toml file for deployment configuration:

version = 0.1
[dev]
[dev.deploy]
[dev.deploy.parameters]
stack_name = "eventbridge-with-sam"
s3_bucket = "your-deployment-bucket"
s3_prefix = "eventbridge-with-sam"
region = "us-west-2"
confirm_changeset = true
capabilities = "CAPABILITY_IAM"
parameter_overrides = "Env=dev"
image_repositories = []

3. Slack Configuration

Now comes the fun part - we'll configure Slack to receive our news. Whether you're familiar with creating Slack apps or not, here's a step-by-step guide to get you started:

1. First, go to api.slack.com/apps and click on "Create New App":

2. See that green "Create New App" button? Click it and select "From Scratch":

3. Now you need to give your app a name - I called mine "AnimeNewsBot" and added it to my "Codeanding" workspace:

4. Once the app is created, go to "Incoming Webhooks" in the side menu and activate the option:

   • Click on "Add New Webhook to Workspace"

   • Select the channel where you want to receive the news

   • Save the webhook URL that Slack provides, we'll need it later!

Your configured webhook should look something like this:

4. Deployment

Now comes the exciting part. Let's deploy our application step by step:

1. First, make sure you have all dependencies installed:

yarn install

2. Build the project (this transpiles TypeScript to JavaScript):

yarn build

3. Deploy the application:

yarn deploy

During deployment, SAM will:

• Create an S3 bucket if it doesn't exist

• Package your code

• Create/update resources in AWS

• Show you a summary of changes

If everything goes well, you should see something like this in the terminal:

Successfully created/updated stack - eventbridge-with-sam

To verify that everything works, wait until the next scheduled time (10:00 AM UTC), and you should see the news appear in your Slack channel:

5. Resource Cleanup

When you want to remove everything created (to avoid charges or just clean up), run these commands:

# Delete the CloudFormation stack
sam delete --stack-name eventbridge-with-sam

# Delete SSM parameters
aws ssm delete-parameter --name "/services/shared/CRUNCHYROLL_RSS_URL"
aws ssm delete-parameter --name "/services/shared/SLACK_WEBHOOK_URL"

Ideas for Improvement

Liked the project? Great! But there's always room for improvement. Some ideas if you want to keep practicing:

• More messaging platforms: Why stick with just Slack? You could add support for Discord or Telegram. Each platform has its own API and would be an excellent abstraction exercise.

• Better messages: Current messages are functional, but you could make them more attractive. How about adding news preview images or using Slack blocks for a more elaborate format?

• Custom filters: Interested in only certain types of news? You could add filters by keyword or categories. You could even allow each user to configure their own filters.

• On-demand commands: Sometimes you don't want to wait for the daily update. How about adding a /news command to get the latest news whenever you want?

If you implement any of these improvements or come up with another interesting idea, don't hesitate to make a PR to the repo! It would be interesting to see what happens.

Source Code

Want to see the complete code, or contribute? Find it on GitHub! EventBridge with SAM

Common Troubleshooting

1. Error: "Cannot find webhook URL"

   • Verify that you've correctly configured the SLACK_WEBHOOK_URL environment variable

   • Make sure the webhook is active in Slack

2. Not receiving messages in Slack

   • Verify that the webhook has permissions to post in the channel

   • Check CloudWatch logs for errors

I hope you found this guide helpful! If you have any questions or suggestions, please leave your comments below - I'd love to hear your thoughts and experiences.

Until the next post, let's keep coding and learning together!

Are you using AWS SAM and haven't tried Prisma yet? After working with Prisma for a while, I can't imagine going back to working without its type safety. If you're interested in adding it to your Lambda functions, I'll show you how to integrate it using layers - it's simpler than you might think.

To begin, let's look at what we'll learn in this post:

• What is AWS SAM?

• What is AWS Lambda?

• What is Prisma?

• What is a Layer?

• Why use Prisma as a layer?

What is AWS SAM?

Looking at AWS documentation, we'll find that AWS SAM is a framework for building serverless applications. It supports various programming languages and significantly simplifies the serverless development process.

What is AWS Lambda?

In AWS documentation, it's described as a serverless computing service that runs code in response to various events. It's perfect for APIs, data processing, and task automation.

What is Prisma?

It's an open-source ORM that has 3 fundamental parts:

• Prisma Client (auto-generated for Node.js and TypeScript)

• Prisma Migrate (migration system)

• Prisma Studio (GUI for viewing and editing data in your database)

What is a Layer?

Layers are a means by which we can optimize our AWS Lambda functions. It's an excellent strategy for sharing code, libraries, and other resources across lambda functions.

Why use Prisma as a layer?

Using Prisma as a layer in AWS Lambda offers several key benefits:

1. Resource optimization: By sharing the Prisma library across multiple functions, you significantly reduce the size of each individual function.

2. Consistency: You ensure that all your functions use the same version of Prisma and the same configuration.

3. Maintainability: Prisma updates can be managed centrally in the layer.

4. Better performance: Being in a layer, Prisma can be cached between function invocations.

What do we need to achieve this?

To reproduce this, we need:

• An AWS account

• A basic project for testing

• AWS CLI installed and configured

• Node.js and npm/yarn installed

Let's Get Started

Initial AWS Configuration

First, let's create a new profile on our machine (if you already have one, you can skip this step). Using AWS CLI, we'll use the following command, which will ask for your AWS Secret Key, AWS Secret Access Key, Default AWS Region, and output format.

aws configure --profile codeanding

Project Structure

Once our AWS profile is configured, the next step will be to start the project with a simple structure:

prisma-lambda-layer/
├── layers/          # where we'll include our new layer
├── scripts/         # where we'll include deployment scripts
└── src/            # where we'll include handlers to use prisma
    ├── handlers/
    └── services/

Installing Dependencies

Let's install the necessary dependencies for the project:

Prisma Configuration

When we add Prisma, it will generate a new folder called prisma with a schema.prisma file inside. Here are the changes we'll make:

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "rhel-openssl-1.0.x", "linux-arm64-openssl-1.0.x"]
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Country {
  id        Int      @id @default(autoincrement())
  name      String   @unique
  dishes    Dish[]
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model Dish {
  id          Int          @id @default(autoincrement())
  name        String
  description String
  countryId   Int
  country     Country      @relation(fields: [countryId], references: [id])
  ingredients Ingredient[]
  createdAt   DateTime     @default(now())
  updatedAt   DateTime     @updatedAt
}

model Ingredient {
  id        Int      @id @default(autoincrement())
  name      String
  dishes    Dish[]
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

Services Implementation

In our services folder, we'll add a class to expose Prisma:

import { PrismaClient } from '@prisma/client';

let prisma: PrismaClient | undefined;

export function getPrismaClient(): PrismaClient {
    if (!prisma) {
        try {
            prisma = new PrismaClient({
                log: ['query', 'error', 'warn'],
                errorFormat: 'minimal',
            });
        } catch (error) {
            console.error('Error initializing Prisma:', error);
            throw error;
        }
    }
    return prisma;
}

Next, we'll add a class to handle operations related to the country model:

import { getPrismaClient } from './prisma';

export class CountryService {
    async findAll() {
        return getPrismaClient().country.findMany();
    }

    async findById(id: number) {
        return getPrismaClient().country.findUnique({ where: { id } });
    }

    async create(data: { name: string }) {
        return getPrismaClient().country.create({ data });
    }

    async update(id: number, data: { name: string }) {
        return getPrismaClient().country.update({ where: { id }, data });
    }

    async delete(id: number) {
        return getPrismaClient().country.delete({ where: { id } });
    }
}

Handlers Implementation

In the handlers folder, we'll add the class that exposes the country-related handlers:

import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
import {
    badRequest,
    formatHttpResponse,
    internalServerError,
    notFound,
} from '../helper/response';
import {
    CreateCountryDTO,
    UpdateCountryDTO,
} from '../interfaces/country.interface';
import { CountryService } from '../services/country';

export class CountriesHandler {
    static async getAllCountries(
        event: APIGatewayProxyEvent
    ): Promise<APIGatewayProxyResult> {
        try {
            const service = new CountryService();
            const countries = await service.findAll();
            return formatHttpResponse(200, countries, event);
        } catch (error) {
            console.error(error);
            return internalServerError(event);
        }
    }

    static async getCountryById(
        event: APIGatewayProxyEvent
    ): Promise<APIGatewayProxyResult> {
        try {
            const service = new CountryService();

            const id = parseInt(event.pathParameters?.id || '');
            if (isNaN(id)) return badRequest(event, 'Invalid ID');

            const country = await service.findById(id);
            return country
                ? formatHttpResponse(200, country, event)
                : notFound(event, 'Country not found');
        } catch (error) {
            return internalServerError(event);
        }
    }

    static async createCountry(
        event: APIGatewayProxyEvent
    ): Promise<APIGatewayProxyResult> {
        try {
            const service = new CountryService();

            const body: CreateCountryDTO = JSON.parse(event.body || '{}');
            if (!body.name) return badRequest(event, 'Name is required');

            const newCountry = await service.create({ name: body.name });
            return formatHttpResponse(201, newCountry, event);
        } catch (error) {
            return internalServerError(event);
        }
    }

    static async updateCountry(
        event: APIGatewayProxyEvent
    ): Promise<APIGatewayProxyResult> {
        try {
            const service = new CountryService();

            const id = parseInt(event.pathParameters?.id || '');
            const body: UpdateCountryDTO = JSON.parse(event.body || '{}');

            if (isNaN(id) || !body.name) return badRequest(event, 'Invalid data');

            const updatedCountry = await service.update(id, { name: body.name });
            return formatHttpResponse(200, updatedCountry, event);
        } catch (error) {
            return internalServerError(event);
        }
    }

    static async deleteCountry(
        event: APIGatewayProxyEvent
    ): Promise<APIGatewayProxyResult> {
        try {
            const service = new CountryService();

            const id = parseInt(event.pathParameters?.id || '');
            if (isNaN(id)) return badRequest(event, 'Invalid ID');

            await service.delete(id);
            return formatHttpResponse(204, {}, event);
        } catch (error) {
            return internalServerError(event);
        }
    }
}

Deployment Scripts

In the scripts folder, we'll add the following files to facilitate deployment:

prisma-layer.sh:

#!/bin/sh

set -e
LAYERS_DIR="layers"
PRISMA_LAYER="$LAYERS_DIR/prisma-layer"
NODEJS_PATH="$PRISMA_LAYER/nodejs"

echo "🧹 Cleaning previous layer directory..."
rm -rf "$PRISMA_LAYER"
mkdir -p "$NODEJS_PATH/prisma"

echo "📋 Creating specific package.json for layer..."
cat > "$NODEJS_PATH/package.json" << EOF
{
  "name": "prisma-layer",
  "version": "1.0.0",
  "dependencies": {
    "@prisma/client": "6.3.0"
  },
  "devDependencies": {
    "prisma": "6.3.0"
  }
}
EOF

echo "📝 Copying schema.prisma to layer..."
cp prisma/schema.prisma "$NODEJS_PATH/prisma/"

echo "📦 Installing dependencies in layer..."
cd "$NODEJS_PATH"

# install dependencies
yarn install
echo "⚙️ Generating Prisma client in layer..."
NODE_ENV=development yarn prisma generate

echo "🧹 Cleaning devDependencies..."
yarn install --production

echo "📁 Verifying directory structure..."
mkdir -p node_modules/.prisma/client

echo "🗜️ Creating layer ZIP file..."
cd ..
zip -r "../prisma-layer.zip" nodejs/

echo "↩️ Returning to main directory..."
cd ../../

echo "✅ Prisma layer successfully prepared"

deploy.sh:

#!/bin/sh

set -e  # Stop script if there's an error

echo "🧹 Cleaning previous directories..."
rm -rf dist
rm -rf layers/prisma-layer/nodejs/node_modules

echo "📦 Installing project dependencies..."
yarn install

echo "🔄 Running prisma generate for main project..."
npx prisma generate

echo "🔄 Preparing Layers..."
sh $(dirname "$0")/prisma-layers.sh

echo "🔨 Compiling TypeScript code..."
yarn build

echo "📦 Building with AWS SAM..."
sam build --use-container

echo "🚀 Deploying to AWS..."
sam deploy --profile codeanding \
  --template-file template.yml \
  --s3-bucket codeanding \
  --stack-name sample-api \
  --capabilities CAPABILITY_IAM \
  --no-confirm-changeset

echo "✅ Deployment successfully completed."

Required Permissions

Before proceeding, we need to ensure that the user we're using has the following permissions:

• S3

• Secrets Manager

• API Gateway

• IAM

• CloudFormation

• Lambda

A quick disclaimer here: the recommendation is to start with basic permissions, following the "least privilege" principle.

Testing the API

Now, let's verify that our API works correctly. We'll use Postman to test each of the endpoints.

First, we'll test creating a country using the POST method on the /v1/countries resource:

Then, we'll verify that we can retrieve all countries using the GET endpoint:

Finally, we'll check that we can retrieve a specific country using its ID:

Next Steps

For production projects, consider:

• Adding authentication and authorization

• Implementing cache to optimize performance

• Setting up CI/CD to automate deployments

Remember to evaluate the use case for which you need to use lambdas, considering aspects such as cold start and other performance factors.

Resource Cleanup

If you've been following along with this tutorial, don't forget to clean up your resources to avoid unnecessary charges. You can remove all the resources using:

sam delete --stack-name sample-api --profile codeanding

Get Involved

Want to explore the complete code? You can find the entire project in this repository: GitHub - AWS Lambda Prisma Layer

I hope you found this guide helpful! If you have any questions or suggestions, please leave your comments below - I'd love to hear your thoughts and experiences.

Until the next post, let's keep coding and learning together!

Have you ever wondered how to accelerate your professional growth in tech? Whether you're starting in technology or already have experience, you've probably heard the word mentor at some point. You might have even received or given mentorship. If you'd like to know how to get started (either as a mentor or mentee), this post is for you. We'll cover basic concepts and tips to make the most of mentorship.

In my case, when I started my tech career, I was fortunate to meet people who were key to my personal and professional growth. Although I didn't have formal mentorship initially, interactions with these people served as guidance that added tremendous value, helping me direct my efforts and advance in my career.

What is mentorship?

Mentorship is a space to learn and get guidance from an expert in a particular field. The main roles are:

• The mentor: responsible for guiding the session and sharing their experience

• The mentee: who receives and benefits from the mentorship

Common activities include:

• Portfolio and CV review

• Interview preparation

• Career planning and goal setting

Each mentorship is unique and adapts to the mentee's needs.

What's the difference between a mentor, coach, and sponsor?

Although these roles are often confused, each has a distinct purpose:

• Mentor: Shares experience and knowledge to guide your professional development

• Coach: Helps you find your own answers through questions and reflection. Doesn't necessarily have direct experience in your field

• Sponsor: Uses their position of influence to advocate for you and create concrete opportunities in spaces where you're not present

For example:

• A mentor might help improve your portfolio

• A coach would guide you to identify your strengths

• A sponsor could recommend you for a key position

Do all mentors follow the same path?

Not at all! Some people become mentors after leading teams, facing unique challenges, or simply learning directly from experience. What's valuable about these mentors is that they perfectly understand the challenges of learning without formal guidance and can share practical strategies that really work.

Why is it a game-changer?

In my experience, mentorship can make a significant difference in your career by helping you:

• Avoid common mistakes others have faced

• Focus your time and energy on truly beneficial areas for your goals

• Accelerate your professional development with experience-based advice

Where can I find a mentor?

There are several ways to find mentors in technology:

1. LinkedIn: Contact professionals politely and respectfully. Introduce yourself, your goals, and why you think they can help you

2. Tech communities: Connect with people passionate about sharing knowledge at meetups, annual events like DevFest, International Women's Day, AWS Community Day, and others

3. Specialized platforms: ADPList or Topmate

If you know others, share them in the comments to help others!

What are the next steps?

Working on your personal plan can help you get more out of mentorship:

1. Define your specialization area. If you're not sure yet, check platforms like roadmap.sh, where you'll find different paths with relevant topics. If this doesn't help clarify, don't worry, a nice project is coming to help you discover what someone does in specific roles!

2. Set clear and measurable objectives. For example, if you want to get into Data Science, start by learning Python, studying basic algorithms, finding interesting challenge repositories, and participating in Kaggle competitions

3. Prepare specific questions. Having clarity about what you want to learn will make sessions more productive

4. Keep track of your progress. Use GitHub, note apps, or even a physical notebook to document your progress. Remember, everyone's progress is unique, so go at your own pace and enjoy the process

What if I think I'm ready to mentor others?

First, congratulations on making this decision! Being a mentor is a great opportunity to give back to the community and continue learning. Some recommendations:

• Review feedback techniques, such as:

  • Radical Candor: balance showing you personally care with directly challenging

  • Hamburger Technique: start with something positive, then constructive criticism, and end with another positive aspect

• Learn to ask the right questions to guide the mentee and encourage reflection

• Ask for feedback regularly to identify areas for improvement and know your strengths as a mentor

Resources

• Mentors vs Coaches vs Sponsors

• Radical Candor

• Hamburger Technique

If you have any additional tips, share them in the comments! I'd love to hear about your experiences and learn from them.

Until the next post, let's keep coding and learning together!

Are images piling up in your ECR repositories? Is storage reaching numbers you're not comfortable with? Don't worry! Let's look at some tips that can help us keep our Docker images under control. This post is aimed at people who are starting with Docker around image generation and AWS's great service, ECR. If you're already experienced, you probably know much of what you'll read here.

What is Docker?

Docker presents itself as a platform designed to help developers build, share, and run containerized applications. Basically, it helps mitigate that famous phrase we've all heard at some point: "It works on my machine" - sounds familiar?

What is ECR?

Amazon presents ECR as a secure, scalable, and reliable container image registry service managed by AWS. The best part is that it supports both public and private repositories and supports Docker images, Open Container Initiative, and OCI-compatible artifacts. It's like having your own DockerHub but with AWS's security and scalability!

Why is this important?

When using cloud services, we must be aware of their costs (nobody wants surprises in their bill!). In Amazon ECR's case, the cost is associated with incoming and outgoing image transfers, as well as their size. Therefore, it's important to consider this in the projection and planning of our projects.

And this is where optimization plays a super important role. Let's see how we can do it!

Optimization Tips

• Let's use lightweight and specific base images, minimalist versions like alpine or slim to reduce image size. Always making sure they are official images.

• Minimize the number of layers whenever possible:

  • Combine instructions to reduce the number of layers created:

      RUN apt-get update && apt-get install -y \
          curl
    

  • Avoid separating redundant instructions:

      RUN apt-get update
      RUN apt-get install -y curl
    

    Instead of the above, combine them into a single line.

• Use .dockerignore to reduce the build context, speeding up builds and excluding unnecessary files:

    .git
    node_modules
  

• Don't forget to set the working directory to avoid problems with relative paths:

    WORKDIR /app
  

• Use COPY instructions instead of ADD, as it is more predictable and secure. Only use ADD if you need to extract a compressed file or download something from a URL:

    COPY . .
  

• Remove unnecessary dependencies. Install and remove packages within the same layer to avoid incorporating them in the final image.

• Properly tag the image, using latest for the most recent version along with semantic versioning (Learn more here).

• Only expose what's necessary (e.g., expose only the ports you need):

    EXPOSE 4002
  

• Use tools like trivy, snyk, and the docker scan command to detect security issues. You can also leverage AWS:

    aws ecr start-image-scan \
        --repository-name my-ecr-repo \
        --image-id imageDigest=sha256:5a587965e4428d4fe318113e402d25145db6c261eb3a64ec13dbe186367ebf8b
  

  The output should look something like:

    {
        "registryId": "012345678910",
        "repositoryName": "my-ecr-repo",
        "imageId": {
            "imageDigest": "sha256:5a587965e4428d4fe318113e402d25145db6c261eb3a64ec13dbe186367ebf8b"
        },
        "imageScanStatus": {
            "status": "IN_PROGRESS"
        }
    }
  

  Then check the results with:

    aws ecr describe-image-scan-findings \
        --repository-name my-ecr-repo \
        --image-id imageDigest=sha256:5a587965e4428d4fe318113e402d25145db6c261eb3a64ec13dbe186367ebf8b
  

  This will provide detailed security analysis results, including detected vulnerabilities, severity, and recommendations.

What to do with the scan results?

The security scan results are pure gold for keeping our images secure. Here's what to do with them:

• Identify critical vulnerabilities and prioritize their solution.

• Update your Dockerfile dependencies to secure versions.

• Integrate scanning into your CI/CD pipeline to prevent deployments with vulnerabilities.

Let's Automate Tagging!

Now, we mentioned tagging, what else can we do? As I always say: why not invest a bit more time in automating something that would take us less than a minute? It's not a very complex script, but by including it in our continuous deployment pipelines, we can tag our images without worries. Automation is your friend!

#!/bin/sh

# Exit immediately if a command exits with a non-zero status
set -e

# Trap errors for better debugging
trap 'echo "Error occurred at line $LINENO. Aborting."; exit 1;' ERR

# Ensure required tools are available
command -v jq >/dev/null 2>&1 || { echo "jq is required but not installed. Aborting." >&2; exit 1; }
command -v aws >/dev/null 2>&1 || { echo "AWS CLI is required but not installed. Aborting." >&2; exit 1; }
command -v docker >/dev/null 2>&1 || { echo "Docker is required but not installed. Aborting." >&2; exit 1; }

# Read the version property from package.json
VERSION=$(jq -r '.version' package.json)
[ -z "$VERSION" ] && { echo "Version could not be retrieved from package.json. Aborting."; exit 1; }

# Define environment variable (change this to match your deployment environment)
ENVIRONMENT="staging"

# Declare variables for tagging the image
REGION="my-region"
ECR_REGISTRY="111111111.dkr.ecr.$REGION.amazonaws.com"
IMAGE_NAME="my-ecr-image"

# Log in to Amazon ECR
echo "Logging in to Amazon ECR..."
aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin "$ECR_REGISTRY"

# Build the Docker image
echo "Building Docker image..."
docker build -t "$IMAGE_NAME" .

# Tag and push the Docker image with all tags
for TAG in latest "$ENVIRONMENT" "$VERSION"; do
  FULL_TAG="$ECR_REGISTRY/$IMAGE_NAME:$TAG"
  echo "Tagging image as $FULL_TAG"
  docker tag "$IMAGE_NAME" "$FULL_TAG"

  echo "Pushing image $FULL_TAG to ECR..."
  docker push "$FULL_TAG"
done

echo "Docker image successfully pushed to ECR."

Version Control and Lifecycle

Now, let's imagine the following scenario (quite common, by the way):

Given our current git flow, when we incorporate changes to our develop branches, the images will be tagged and uploaded to ECR. And so on... the result? If we don't have adequate policies, our repository will have n versions of our project (versions that have probably gone through breaking changes or maybe not).

But don't worry! Implementing a lifecycle for images in Amazon ECR is easier than it seems. Let's see how to do it with Terraform:

resource "aws_ecr_repository" "api" {
  name = "${var.app_name}"
}

resource "aws_ecr_lifecycle_policy" "api_lifecycle_policy" {
  repository = aws_ecr_repository.api.name

  policy = jsonencode({
    rules = [
      {
        rulePriority = 1
        description  = "Retain only last 5 images"
        selection = {
          tagStatus     = "tagged"
          countType     = "imageCountMoreThan"
          countNumber   = 5
        }
        action = {
          type = "expire"
        }
      }
    ]
  })
}

Note: While this part only shows how to create a new resource, we can import existing resources using Terraform from version v1.5.0 or using the terraform CLI.

Conclusion

We've reached the end! Optimizing Docker images in ECR is not just a good practice, it's a necessity to keep our services efficient and costs under control. With the tips we saw today, we can:

• Significantly reduce storage and transfer costs.

• Improve the security of our images (super important!).

• Automate those repetitive processes that bore us so much.

• Maintain a clean and organized repository (your future self will thank you).

Additional Resources

Want to dive deeper? Here are some super useful resources!

• Official Docker Documentation

• Docker Best Practices Guide

• Amazon ECR User Guide

• Terraform AWS Provider - ECR

• Docker Security Scanning

• Semantic Versioning

Have you tried any of these tips before? Do you have any other tricks up your sleeve you'd like to share?

Share it in the comments! I'd love to hear about your experiences and learn from them.

Until the next post, let's keep coding and learning together!

Is Docker Desktop being detected as malware on macOS? If this has happened to you, join me in this post where I'll document the migration process to OrbStack, a tool that promises to be lighter and more efficient. This post will be updated with new findings as I continue using it.

How did this start?

On January 7th, 2025, reports began to emerge about malware detected on macOS (You can read more about it here). Docker Desktop started being reported as malware, affecting various users, including members of my team (M1, M2, and M3 users). Due to recent macOS updates, some didn't experience this issue, but it was eventually documented in the Docker forum.

In search of alternatives, we discovered OrbStack and decided to try it.

What is OrbStack?

OrbStack isn't just presented as an alternative to Docker Desktop, but as a more versatile solution, allowing you to run Linux in different environments, similar to what WSL offers on Windows.

Why Consider OrbStack?

While you can find a detailed comparison in the resources section, the key benefits that made me switch include:

• Significantly lower resource usage (my MacBook's fans finally stopped spinning)

• Faster container startup times

• Better integration with Apple Silicon

• A more modern and responsive interface

What is WSL?

While it's not the focus of this post, it's worth mentioning. For Windows users, Windows Subsystem for Linux (WSL) is an excellent alternative for using Linux tools within Windows.

Installing OrbStack on Mac

There are two main installation methods:

1. Using homebrew

    brew install orbstack
   

2. Downloading the installer directly from orbstack.dev/download (make sure to select the correct installer for your processor)

Installation Process

Once installed, you'll follow these steps:

1. Welcome screen

2. 

   Tool selection: we'll choose Docker (for now), but you can add K8s or Linux later

3. 

   You'll see the following screen

4. 

   To migrate existing Docker Desktop data:

   • Go to the File menu

   • Select "Migrate docker data"

The "Migrate Docker Data" option simplifies the transition, ensuring all your containers, images, and volumes are ready to use in OrbStack without data loss.

5. The migration process will take a few minutes depending on the amount of data

6. Docker Desktop will stop during the process

7. When everything is finished, we'll see all containers, volumes, and images successfully migrated

8. Now, let's run a (test) project to confirm everything is working normally

First Impressions

• I was able to run projects normally, without needing to change anything.

• The interface is intuitive, and the migration process was quite smooth.

• Although I've been using it for a short time, I've noticed that memory and CPU consumption is lower compared to Docker Desktop, especially when working with multiple containers.

• Integration with existing development tools (VS Code, terminal) works quite well.

Technical Considerations

• OrbStack's architecture differs from Docker Desktop in its virtualization approach, which explains the performance improvement. (See more at https://docs.orbstack.dev/architecture)

• It's important to mention that environment variables and network configuration remain consistent after migration.

• Volumes and bind mounts work similarly, maintaining compatibility with existing docker-compose files.

Useful Resources

• Official OrbStack Documentation

• Orbstack vs Docker Desktop

• OrbStack Community on Discord

Have you tried OrbStack or are you considering the switch? What do you think about this tool?

Share your experience in the comments, I'd love to learn from your findings!

Until the next post, let's keep coding and learning together!

Bienvenidos a esta nueva entrada donde compartiré los recursos y detalles de mi charla en el DevFest Lima 2024 sobre "Desplegando APIs Serverless con Terraform en Google Cloud Functions".

Sobre la charla

En esta sesión exploramos la poderosa combinación de Terraform y Google Cloud Functions para desplegar APIs de manera serverless. Cubrimos conceptos fundamentales como:

• Introducción a Serverless y sus beneficios

• Fundamentos de Terraform para Infrastructure as Code (IaC)

• Implementación práctica usando Google Cloud Functions

• Demostración en vivo de un despliegue automatizado

📚 Recursos

Presentación

La presentación completa está disponible aquí. En ella encontrarás:

• Conceptos básicos de serverless

• Ventajas y casos de uso ideales

• Introducción a Terraform

• Workflow básico de implementación

• Arquitectura de la solución

Código fuente

Todo el código demostrado durante la sesión está disponible en GitHub: https://github.com/julissarparco/demo-devfest-2024

Próximos pasos

Si quieres comenzar con Terraform y Google Cloud Functions, te recomiendo:

1. Revisar la documentación oficial de ambas tecnologías

2. Empezar con proyectos pequeños

3. Practicar los comandos básicos de Terraform mostrados en la demo

¿Preguntas o comentarios?

No dudes en dejar tus preguntas en los comentarios o contactarme a través de mis redes sociales @codeanding.

¡Gracias por tu interés en el tema y espero que estos recursos te sean útiles en tu viaje de aprendizaje! 🚀

Bienvenidos a una nueva entrada, donde aprenderemos paso a paso cómo configurar un dominio con un repositorio en Github. Si alguna vez te has preguntado cómo darle un toque más profesional a tu sitio web, ¡estás en el lugar correcto!

¿Qué aprenderemos a lo largo de este post?

• Entenderemos los conceptos básicos de: GitHub, GitHub Pages, GoDaddy y DNS.

• Manos a la Obra

¿Qué necesitaremos?

• Una cuenta de GitHub

• Un dominio, en este caso usaremos GoDaddy

¿Qué es GitHub?

Es una plataforma de desarrollo colaborativo basada en la nube que permite a los desarrolladores almacenar, gestionar y compartir código. Funciona como un sistema de control de versiones, facilitando la colaboración en proyectos de software al permitir que múltiples personas trabajen en el mismo código y hagan un seguimiento detallado de los cambios a lo largo del tiempo.

¿Qué es GitHub Pages?

Es parte de GitHub y nos permite alojar sitios web estáticos directamente desde un repositorio en GitHub. Podemos usar GitHub Pages para crear sitios personales, de proyectos, o de organizaciones, y se integra fácilmente con Git para automatizar el despliegue de los cambios a tus proyectos. No requiere servidores externos, ya que GitHub se encarga del alojamiento y la entrega de contenido.

¿Qué es GoDaddy?

Es una de las empresas más grandes y conocidas en el mundo del registro de dominios y alojamiento web. Imagina que tener un dominio es como tener una dirección en internet para tu casa o negocio. GoDaddy te permite comprar y administrar esa dirección.

¿Qué es un DNS?

DNS viene de las siglas en inglés de “Domain Name System”, que significa “Sistema de nombres de dominio”. Es un directorio que traduce los nombres de dominio, como “www.google.com”, en direcciones IP, como “74.125.19.147”.

Habiendo repasado esta información vamos a poner manos a la obra y empezar con la configuración.

Manos a la Obra

Empecemos con el repositorio en GitHub. Si ya tienes uno, ¡genial! Puedes saltar al siguiente paso. Si no, vamos a crearlo:

Paso 1: Preparando nuestro repositorio

Seleccionamos el owner correspondiente, colocamos el nombre que se ajuste a lo que busquemos y la visibilidad.

• Nombre: Portfolio

• Visibilidad: Público

Paso 2: Agregando archivos base

En caso partamos de cero, agregaremos archivos como: index.html (para definir una estructura inicial) y styles.css (para agregar estilos relacionados con la temática). El index.html de este proyecto contiene un mensaje que indica que el sitio está en construcción, ya que iremos iterando sobre este proyecto en siguientes entradas 👾

¡En mi caso agregué un Psyduck porque me encanta Pokémon! 😀 No teman personalizar sus proyectos con cosas que les gusten.

Paso 3: Configurando GitHub Pages

Vamos a la pestaña “Settings” o “Configuración” para habilitar Github Pages.

⚠️ En caso hayas creado el repositorio como privado, antes de continuar no olvides cambiar la visibilidad del repositorio, ya que es necesario para GitHub Pages

Por ahora usaremos el despliegue clásico de GitHub Pages, (¡dejaremos GitHub Actions para otra aventura! 👀)

• En Source, seleccionamos “Deploy from a branch” o “Desplegar desde una rama“

• En Branch, seleccionamos la rama que queramos usar, en este caso main y en el folder elegimos root.

GitHub generará una URL muy similar a: https://@nombreUsuario.github.io/@nombreRepositorio, para efectos del ejemplo tenemos: https://julissarparco.github.io/portfolio/

Paso 4: Configurando nuestro dominio

Ahora viene la parte emocionante. Vamos a agregar las siguientes IPs en GoDaddy como registros tipo A:

• 185.199.108.153

• 185.199.109.153

• 185.199.110.153

• 185.199.111.153

Luego agregaremos un record del tipo CNAME del nombre www con el valor de nombreUsuario.github.io.

Cuando esté listo, confirmamos los cambios y se verá un mensaje muy parecido a este:

Paso 5: Conectando todo

Volvamos a nuestro repositorio en GitHub para configurar el Custom domain y agregamos nuestro dominio. En el ejemplo tenemos a julissa.dev, un nuevo dominio para mostrar un portafolio más allá del blog actual @codeanding. Hacemos clic en “Save” o “Guardar“.

Esto agregará el archivo CNAME al repositorio automáticamente. Y deberías ver algo muy parecido a esto:

Cuando el chequeo del DNS termine, deberías ver el mensaje “DNS check successful” o “Chequeo exitoso de DNS”.

Puedes verificar que todo esté funcionando usando herramientas como DNS propagation checker.

¡Y listo! 🎉 – deberíamos ver el nuevo dominio apuntando a tu repositorio en GitHub.

Referencias

• Acerca de Git y GitHub

• Acerca de GoDaddy

• ¿Qué es DNS?

¿Qué te pareció? ¿Te resultó útil? ¡Cuéntamelo en los comentarios!

Hasta la próxima entrada, ¡sigamos codeando y aprendiendo juntos!

Bienvenidos a esta nueva entrada donde compartiré mi experiencia durante el AWS Community Day Argentina edición 2024 en la ciudad de Buenos Aires.

A lo largo de este post, compartiré:

• Una breve explicación de qué es AWS Community Day

• Mi experiencia asistiendo al evento

• Mi experiencia como speaker

• Reflexiones finales

Así que, ¡prepárate para un viaje lleno de tecnología, aprendizaje y comunidad!

¿Qué es AWS Community Day?

El AWS Community Day es un evento anual que se organiza en colaboración con distintas comunidades locales de AWS, en la que se discuten temas relacionados con los servicios de AWS. Los eventos son gratuitos y están dirigidos a cualquier persona interesada en aprender sobre AWS.

¿Cómo fue asistir al evento?

El evento se llevó a cabo el sábado 14 de septiembre en la UADE (Universidad Argentina de la empresa) y fue organizado por distintas comunidades de Argentina como: AWS User Group Patagonía, AWS User Group Buenos Aires, AWS User Group Córdoba y AWS Girls Argentina.

Al llegar al evento procedí con el registro para recoger las credenciales y recibir algunos stickers de la comunidad (¡sí, aquí amamos el swag!). Al ingresar nos encontramos con desayuno gratis para todos los asistentes (también amamos la comida 👾), así como la exhibición de distintas empresas que brindaban desde swag hasta ofertas laborales. Este espacio fue bastante valioso, no solo para divertirse, sino para conectar con otros entusiastas.

La jornada comenzó con una inspiradora Keynote a cargo de Jeff Barr, titulada “Create Your Own Luck”. Su presentación fue memorable no solo por el contenido (donde compartió su fascinante trayectoria desde sus inicios hasta su rol actual en AWS), sino por algo que me pareció especialmente significativo: su manera de presentarse. A diferencia del típico “soy [cargo] en [empresa]” que solemos escuchar, Jeff comenzó identificándose con sus roles más personales y duraderos: esposo, padre y abuelo, dejando para el final su título de “Vice President & Chief Evangelist”. Este pequeño detalle, aparentemente simple, transmitió un mensaje poderoso sobre la importancia de reconocernos primero como personas antes que como profesionales. Si te interesa experimentar esta inspiradora charla por ti mismo, gracias al excelente trabajo del equipo organizador, puedes encontrar la grabación completa aquí.

Después las charlas en sus respectivos tracks iniciaron: Main Stage – Track 1, Main Stage – Track 2, DevOps & SRE, Security & Compliance, The Zone y Empleabilidad.

Permanecí en el Main Stage (Track 1 y Track 2) donde Farrah Campbell compartió la charla “Unlocking Cloud Career Success: Embrace Bravery, Positivity, and Connections“, una presentación llena de inspiración. Y algunos de los aprendizajes que me gustaría compartir son:

• Superar las dudas sobre uno mismo: No se trata de pretender que no tenemos miedo, sino de reconocer nuestros miedos y elegir actuar a pesar de ellos. Este enfoque nos permite avanzar y crecer.

• Salir de la zona de confort: Las investigaciones han demostrado que los profesionales que asumen riesgos calculados tienen un 32% más de probabilidades de ser reconocidos y avanzar en sus carreras. Tomar riesgos no solo es necesario, sino que es una oportunidad para ser más visibles y aportar más valor.

• Practicar la valentía: Enfrentar los miedos, practicar la autocompasión, celebrar pequeñas victorias y buscar apoyo son cuatro pilares fundamentales para cultivar la valentía en nuestra vida personal y profesional.

• Los desafíos como oportunidades: Cada reto que enfrentamos puede ser una oportunidad de crecimiento. En lugar de ver los obstáculos como barreras, debemos adoptarlos como momentos para aprender y mejorar.

• Mentalidad de crecimiento: Adoptar una mentalidad de crecimiento significa creer que nuestras habilidades se pueden desarrollar con dedicación y esfuerzo. Es fundamental desafiarnos a salir de nuestra zona de confort, persistir ante los obstáculos, aprender de la retroalimentación y encontrar inspiración en los demás.

• El poder de las conexiones: El 85% de los trabajos se consiguen a través de networking. Farrah subrayó la importancia de construir una red de confianza, rodeándonos de personas que nos apoyen y eleven.

• Puntos clave para llevarnos: Tomar riesgos, creer en nuestras habilidades, responder a los obstáculos con resiliencia, enfocarnos en ser resistentes y construir una red de confianza son acciones fundamentales que nos ayudarán a avanzar tanto en lo personal como en lo profesional.

Finalmente, si quieres revivir la charla, puedes verla aquí.

Las horas transcurrieron y a la hora del almuerzo pude aprovechar en encontrarme con Vani Moreno, también embajadora del programa Women Techmakers de Google con quien pude compartir un momento bastante agradable. Contamos historias, actividades en las que estamos y como siempre, aprovechando la oportunidad para realizar sinergias en futuros proyectos. Vani fue demasiado amable y linda, ¡no solo por darme recomendaciones sobre la ciudad de Buenos Aires, sino por acompañarme durante la charla y darme ánimos!

El momento de subir al escenario

Esta fue la primera charla presencial que daba fuera de Perú, anteriormente lo había hecho de forma virtual a través de LATAM y en algunas ciudades fuera de Lima de forma presencial. Sin embargo, debo decir que fue fantástica. ¡Principalmente por el apoyo de personas como Vani y personas de la comunidad de AWS Argentina, que me guiaron en el setup de micrófonos, transmisión vía streamyard para grabar la charla y recomendaciones, ya que, estuve en el main stage y el escenario fue compartido!

Sí, era la primera vez que participaba en un escenario compartido y aunque al iniciar fue un tanto complicado porque me costó concentrarme con la voz del speaker de al lado 🤭, a medida que fuimos avanzando la comodidad nos encontró y pudimos fluir.

Los recursos de la charla los dejo en este post que creé previamente para hacer más sencillo el compartir referencias y papers que pueden resultar interesantes para quien quiere profundizar.

Reflexiones finales

Ser parte del AWS Community Day Argentina 2024 ha sido una aventura que comenzó mucho antes del evento en sí. Todo empezó con ese momento de “¿y si…?“, cuando vi la convocatoria para speakers. Postular una charla para un evento internacional parecía intimidante, pero decidí atreverme – ¡y debo decir que lo valió 100%!

Esta experiencia me enseñó que las mejores oportunidades suelen estar del otro lado de nuestra zona de confort. No solo me lancé a dar una charla internacional, sino que me animé a explorar una nueva ciudad, conocer personas increíbles y sumergirme en una comunidad tech vibrante y acogedora.

Y hablando de comunidad… ¡Wow! Ver la sinergia entre todos los user groups de Argentina fue simplemente inspirador. La manera en que estos grupos se unieron para crear un evento de tal magnitud demuestra el verdadero poder de la colaboración. Cada detalle estaba cuidadosamente pensado: desde el registro hasta las sesiones técnicas, desde el networking hasta el swag – ¡todo fluía y esto es algo que solo se logra cuando hay pasión + dedicación detrás!

Me llevo de esta experiencia varios aprendizajes clave:

• El poder de decir “sí” a nuevas oportunidades, aunque den un poquito de miedo.

• La magia que sucede cuando diferentes comunidades unen fuerzas.

• La importancia de rodearnos de personas que nos impulsan a crecer.

• Que los mejores eventos tech no solo son sobre tecnología, sino sobre las conexiones humanas que creamos

Esta experiencia me ha dejado no solo con nuevos conocimientos técnicos, sino también con amistades valiosas, momentos memorables y una renovada motivación para seguir contribuyendo a la comunidad tech. Como dice el dicho, “si quieres ir rápido, ve solo; si quieres llegar lejos, ve acompañado” – y después de este AWS Community Day, puedo dar fe de que el camino en comunidad es mucho más enriquecedor.

¡Gracias AWS Community Day Argentina por una experiencia inolvidable! Y a todos los que están leyendo esto: no duden en participar en eventos de comunidad, ya sea como asistentes o speakers. A veces, todo lo que necesitamos es dar ese primer paso valiente, y las oportunidades empiezan a fluir.

¡Gracias al equipo, se tienen muchas de las charlas grabadas! Por lo que te invito a visitar la lista de reproducción en youtube.

Hasta la próxima entrada, ¡sigamos codeando y aprendiendo juntos!

Bienvenidos a esta nueva entrada donde compartiré mi experiencia personal como asistente al Google I/O 2024 y mi participación como speaker en el Google I/O Extended organizado por la comunidad Google Developer Groups (GDG) Cloud Lima en julio. Aunque el evento principal se llevó a cabo en mayo, no quería dejar pasar la oportunidad de compartir con ustedes cómo fue vivirlo en primera persona.

A lo largo de este post, compartiré:

• Una breve explicación de qué es Google I/O

• Mi experiencia personal asistiendo al evento, incluyendo detalles de las actividades previas y durante el evento

• Un resumen de los anuncios más destacados del Google I/O 2024

• Mi experiencia como speaker en el Google I/O Extended en Lima

• Reflexiones sobre la importancia de participar en comunidades tech locales

Así que, ¡prepárate para un viaje lleno de tecnología, aprendizaje y comunidad!

¿Qué es el Google I/O?

Para quienes no estén familiarizados, Google I/O es la conferencia anual que organiza Google para presentar los últimos anuncios y actualizaciones en tecnología, tanto para desarrolladores como para entusiastas del ecosistema Google. Es como la Navidad para los amantes de la tecnología, ¡pero en mayo!

Mi experiencia en Google I/O 2024

Este año, la conferencia tuvo lugar en el Shoreline Amphitheatre en Mountain View, California, durante los días 14 y 15 de mayo. ¡Y déjenme decirles, fue una experiencia increíblemente inspiradora!

Actividades previas y registro

El evento oficialmente comenzó el 14 de mayo, pero las actividades arrancaron desde el día anterior. El lunes 13 de mayo, se organizaron dos cenas en paralelo: una para el programa Women Techmakers y otra para los Google Developer Experts. Como embajadora de Women Techmakers, estaba invitada a la cena, pero lamentablemente no pude asistir porque aún estaba en vuelo hacia California.

El día 14 por la mañana, comenzamos con el proceso de registro. Fue emocionante ir a buscar nuestras credenciales para ingresar al evento. Y por supuesto, ¡no podía faltar el swag tech! Recibimos algunos obsequios geniales que hicieron la experiencia aún más especial.

Durante el evento

No solo fue mi primera vez asistiendo en persona, sino que también tuve la oportunidad de conectar con profesionales talentosos y probar los lanzamientos más recientes a través de workshops. Compartí esta experiencia con mi gran amiga Katherine Chauca, también embajadora del programa Women Techmakers.

El evento arrancó con una apertura divertidísima a cargo de Marc Rebillet, quien no solo hizo un pre-show entretenido, sino que también presentó MusicFX AI, demostrando cómo la IA está transformando incluso el mundo de la música.

Highlights del Google I/O 2024

Aquí les dejo un resumen rápido de los anuncios más emocionantes:

1. Gemini 1.5: Google anunció la nueva versión de su modelo de IA Gemini, con mejoras significativas en rendimiento y capacidades.

2. Gemini API: Se lanzó oficialmente la API de Gemini, permitiendo a los desarrolladores integrar las capacidades de Gemini en sus aplicaciones.

3. Google AI Studio: Una nueva plataforma para desarrolladores que facilita la creación y prueba de aplicaciones de IA.

4. Avances en Project Starline: Google mostró los últimos avances en su tecnología de telepresencia 3D.

Recaps recomendados

Si quieren revivir el evento o profundizar en los anuncios, aquí les dejo algunos excelentes recaps:

1. Google Developers Blog: Resumen oficial de Google I/O 2024

2. The Verge: Google I/O 2024 – Todo lo que necesitas saber

3. TechCrunch: Google I/O 2024 – Here’s everything Google just announced

Compartiendo la experiencia: Google I/O Extended en Lima

Mi última charla presencial había sido con Perú .Net Development en marzo y ahora en julio, tuve la oportunidad de compartir mi experiencia en el I/O Extended organizado por GDG Cloud Lima. Fue emocionante regresar a un escenario local y conectar con la nueva generación de la comunidad tech en Lima.

Durante la charla, surgieron preguntas interesantes que me gustaría compartir con ustedes:

• ¿Qué es el programa Women Techmakers de Google?

  Es un programa organizado por Google para dar visibilidad, generar y aportar comunidad, así como recursos a las mujeres en tecnología. Todos los años este programa abre convocatorias nuevas para recibir nuevas embajadoras. Sí, te gustaría ser parte regístrate como miembro aquí y mantente atenta para la convocatoria del próximo año. También, puedes buscar embajadores locales en tu ciudad para buscar mentoría y consejos para aplicar al siguiente año.

• ¿Qué es un Google Developer Group?

  Son comunidades que con el apoyo de Google están presentes en muchos países con el objetivo de conectar desarrolladores locales para adquirir nuevas habilidades en eventos, ya sean presenciales o virtuales, aquí en Perú tenemos distintos capítulos, por mencionar algunos aquí en Lima: GDG Open, GDG Lima y GDG Cloud Lima. Si quieres encontrar el más cercano a ti, puedes buscarlos aquí.

• ¿Cómo puedo asistir al evento?

  La transmisión en vivo está abierta a todos a través del canal de YouTube de Google. Sin embargo, para asistir al evento presencialmente, debes estar atento a ciertas invitaciones. Este año, por ejemplo, se invitó a Women Techmakers Ambassadors, organizadores de Google Developers Group (GDG), Google Developer Experts (GDE), y algunos partners de Google.

Reflexiones finales

Participar en el Google I/O y luego compartir esa experiencia con mi comunidad local ha sido increíblemente enriquecedor. Me ha recordado la importancia de mantenerse actualizado en tecnología, pero también de compartir el conocimiento y construir comunidad.

Los animo a todos a que se involucren en comunidades tech locales. Ya sea asistiendo a eventos, compartiendo sus conocimientos o incluso organizando meetups, cada aporte cuenta y ayuda a crear un ecosistema tecnológico más fuerte y diverso.

Referencias:

1. https://deepmind.google/technologies/gemini/

2. https://ai.google.dev/gemini-api?hl=es-419

3. https://aistudio.google.com/

4. https://starline.google/

5. https://sustainability.google/

6. https://developers.google.com/womentechmakers

7. https://io.google/2024/

¿Has asistido alguna vez a un evento tech? ¿Qué te pareció? ¿O tal vez estás pensando en unirte a una comunidad local? ¡Puedes dejar tus ideas/aportes en los comentarios!

Bienvenidos a esta nueva entrada, donde compartiré todos los recursos y enlaces mencionados durante mi presentación “La IA a tu Servicio: Mejorando la Salud con AWS HealthScribe”.

El objetivo es proporcionar un acceso fácil y organizado a la información que puede ayudar a entender mejor cómo la inteligencia artificial (IA) y las tecnologías de AWS están revolucionando el sector de la salud.

📚 Recursos organizados por sección:

1. ¿Por qué la IA puede ser tu nuevo mejor amigo en la salud?

   • Estudio sobre la precisión diagnóstica de la IA: Artificial Intelligence in Healthcare: Past, Present and Future – PubMed Central (PMC).

   • Informe de ahorro en costos con IA: Accenture Report on AI in Healthcare.

   • Revisión sobre precisión diagnóstica de la IA en enfermedades oculares: Artificial intelligence versus clinicians: systematic review – The Lancet Digital Health.

2. Problemas médicos que necesitan soluciones épicas

   • AI in diagnostic imaging: Revolutionising accuracy and efficiency

   • Intelligent Clinical Documentation: Harnessing Generative AI for Patient-Centric Clinical Note Generation

   • Assessment of Natural Language Processing of Electronic Health Records to Measure Goals-of-Care Discussions as a Clinical Trial Outcome

3. Material de Referencia

   • Aws Community

   • Aws Documentation: HealthScribe

   • Libros recomendados:

     • AI and Healthcare: A Comprehensive Guide

4. Material Complementario

   • Accede a la presentación completa aquí

   • Accede al repositorio de la demo – https://github.com/aws-samples/aws-healthscribe-demo

🤝 ¿Quieres Contribuir?

¡Tu feedback es valioso! Si tienes preguntas o quieres compartir tu experiencia con AWS HealthScribe, déjame un comentario abajo.

📅 Próximos Pasos

Estaré actualizando este post con nuevos recursos y casos de uso. ¡No olvides seguirme para estar al tanto!

Hasta la próxima entrada, ¡sigamos codeando y aprendiendo juntos!

¡Bienvenidos a @codeanding!

Estoy emocionada de compartir este espacio con ustedes, donde iré publicando entradas sobre mis aventuras en mi camino ninja en tecnología.

¿Qué puedes esperar aquí?

Este blog nació durante la pandemia y, aunque tuvo una pequeña pausa debido a algunas decisiones un poco "peculiares", las entradas anteriores a 2024 se han perdido. Pero ¿sabes qué? Veámoslo como una oportunidad para empezar de nuevo, actualizar el contenido y explorar nuevos temas juntos.

Aquí encontrarás desde tutoriales y proyectos, hasta reflexiones sobre los retos y logros que se presentan en este fascinante mundo de la tecnología. Me comprometo a compartir al menos un post mensual, para mantener este espacio activo y en constante crecimiento.

Quiero que este sea un espacio para aprender y compartir en conjunto. ¿Qué temas te gustaría explorar? ¿Hay alguna área específica de la tecnología que te intrigue especialmente? ¡Me encantaría conocer tus ideas en los comentarios!

¡Gracias por estar aquí y ser parte de esto!

¡Nos leemos pronto!