<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>CodeWithBotina</title>
    <description>Technical insights on software development, programming tutorials, and best practices</description>
    <link>https://blog.codewithbotina.com/en/</link>
    <language>en</language>
    <lastBuildDate>Tue, 07 Apr 2026 15:51:34 GMT</lastBuildDate>
    <atom:link href="https://blog.codewithbotina.com/en/rss.xml" rel="self" type="application/rss+xml"/>
    
    <item>
      <title><![CDATA[Goodbye Static Images! Now on CodeWithBotina: Interactive Mermaid Diagrams]]></title>
      <link>https://blog.codewithbotina.com/en/posts/goodbye-static-images-now-on-codewithbotina-interactive-mermaid-diagrams</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/goodbye-static-images-now-on-codewithbotina-interactive-mermaid-diagrams</guid>
      <pubDate>Mon, 06 Apr 2026 18:30:05 GMT</pubDate>
      <description><![CDATA[Goodbye Static Images! Now on CodeWithBotina: Interactive Mermaid Diagrams Welcome to a special update from CodeWithBotina. If you are a regular reader, you know we are passionate about explaining com...]]></description>
      <enclosure url="https://www.mermaidonline.live/imgs/features/mermaid-editor.png" type="image/jpeg"/>
      <content:encoded><![CDATA[# Goodbye Static Images! Now on CodeWithBotina: Interactive Mermaid Diagrams

Welcome to a special update from [CodeWithBotina](https://blog.codewithbotina.com/). If you are a regular reader, you know we are passionate about explaining complex architectures and data flows. However, sometimes a static image isn't enough to capture the essence of a dynamic system.

Today, we are thrilled to announce that **CodeWithBotina now supports Mermaid diagram rendering**.

What does this mean for you?
1. **Interactivity:** You can hover over diagrams to highlight specific flows.
2. **Downloadable:** You can now export these diagrams for your own notes or projects.
3. **Clarity:** Diagrams that are always crisp, regardless of your screen resolution.

Here are some examples of what you will see in our future articles:

---

### 1. Flowchart (Authentication Logic)
Ideal for understanding decision-making processes in code.

```mermaid
graph TD
    A[User Login] --> B{User exists?}
    B -- No --> C[Error: User not found]
    B -- Yes --> D{Correct Password?}
    D -- No --> E[Error: Invalid credentials]
    D -- Yes --> F[Generate JWT Token]
    F --> G[Access Granted]
````

### 2\. Sequence Diagram (API Request)

Perfect for visualizing how your microservices interact.

```mermaid
sequenceDiagram
    participant Client
    participant API_Gateway
    participant AuthService
    participant Database

    Client->>API_Gateway: POST /login
    API_Gateway->>AuthService: Validate Credentials
    AuthService->>Database: Fetch User
    Database-->>AuthService: User Data
    AuthService-->>API_Gateway: Token Created
    API_Gateway-->>Client: 200 OK (JWT)
```

### 3\. Architecture Diagram (Our 3 Layers)

Recalling our previous post about layered architecture:

```mermaid
graph BT
    subgraph Data_Layer
        DB[(Database)]
    end
    subgraph Business_Layer
        Logic[Domain Logic]
    end
    subgraph Presentation_Layer
        UI[User Interface]
    end
    
    UI --> Logic
    Logic --> DB
```

-----

## How does it work?

We are using **Mermaid.js**, a JavaScript-based tool that renders simple text definitions into Scalable Vector Graphics (SVG). This makes the blog load faster and ensures the information is accessible to screen readers.

We hope this new tool makes your software development journey much more visual and straightforward. Try it out now by downloading any of the diagrams above\!

**Sources to learn more about Mermaid:**

  * **Mermaid Live Editor:** [mermaid.live](https://mermaid.live/)
  * **Official Documentation:** [mermaid-js.github.io](https://www.google.com/search?q=https://mermaid-js.github.io/mermaid/)

-----

*Visualize the code, master the system. Only at [CodeWithBotina](https://blog.codewithbotina.com/).*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[The Art of Separation: Layered Architecture in Web, Mobile, and Desktop]]></title>
      <link>https://blog.codewithbotina.com/en/posts/the-art-of-separation-layered-architecture-in-web-mobile-and-desktop</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/the-art-of-separation-layered-architecture-in-web-mobile-and-desktop</guid>
      <pubDate>Mon, 30 Mar 2026 22:55:13 GMT</pubDate>
      <description><![CDATA[The Art of Separation: Layered Architecture in Web, Mobile, and Desktop Welcome back to CodeWithBotina. If you've ever felt like your code is a labyrinth where a tiny database tweak breaks the UI, you...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/el-arte-de-separar-arquitectura-en-capas-en-web-mobile-y-desktop-1774911500209.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# The Art of Separation: Layered Architecture in Web, Mobile, and Desktop

Welcome back to [CodeWithBotina](https://blog.codewithbotina.com/). If you've ever felt like your code is a labyrinth where a tiny database tweak breaks the UI, you are likely missing "layers."

**Layered Architecture** is the most common pattern in the software world. Its core principle is **Separation of Concerns (SoC)**: each piece of code has one job and only communicates with the layer directly below it.

---

## 1. The 3 Core Layers

While there can be more, most systems are divided into these three:

1.  **Presentation Layer (UI):** What the user sees and interacts with. It captures events and displays data.
2.  **Business Logic Layer (Domain):** The brain. Rules, calculations, and validations live here.
3.  **Data Layer (Infrastructure):** Where databases, external APIs, or the file system reside.

---

## 2. Adaptation by Platform

### 🌐 Web (APIs)
In a REST API (Node.js, Spring Boot, .NET), layers usually look like this:
* **Controllers:** Receive HTTP requests and validate parameters.
* **Services:** Execute the logic (e.g., "If user is VIP, apply a 10% discount").
* **Repositories:** Perform SQL queries or interact with an ORM.

### 📱 Mobile Apps (Android/iOS)
Here, architecture evolves into patterns like **MVVM (Model-View-ViewModel)** or **Clean Architecture**:
* **UI (Activity/SwiftUI):** Only displays states.
* **ViewModel/Use Cases:** Act as the logic that survives configuration changes like screen rotation.
* **Remote/Local Data:** Handles whether data comes from an API or internal storage (SQLite).

### 🖥️ Desktop Applications
In environments like WPF or JavaFX, separation is vital for performance:
* **View:** XAML or FXML files.
* **Business Logic:** Classes that process local files or hardware (sensors).
* **DataAccess:** Drivers for local databases or network connectors.

---

## 3. Why use it in 2026?
* **Maintainability:** You can switch your database from MySQL to PostgreSQL without touching a single line of your UI.
* **Testability:** You can test your business logic without needing to open a browser or an emulator.

---

## Trusted Sources for Further Reading:
* **Martin Fowler (Patterns of Enterprise Application Architecture):** The go-to reference for software organization. [martinfowler.com](https://martinfowler.com/eaaCatalog/layeredArchitecture.html)
* **Microsoft Learn:** Guide on architecture styles (N-tier applications). [learn.microsoft.com](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier)
* **Google Developers:** Guide to mobile app architecture (Android). [developer.android.com](https://developer.android.com/topic/architecture)

---
*Build solid software, not houses of cards. See you in the next [CodeWithBotina](https://blog.codewithbotina.com/) post.*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[When the engine stops: A chronicle of demotivation and the power of discipline]]></title>
      <link>https://blog.codewithbotina.com/en/posts/when-the-engine-stops-a-chronicle-of-demotivation-and-the-power-of-discipline</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/when-the-engine-stops-a-chronicle-of-demotivation-and-the-power-of-discipline</guid>
      <pubDate>Fri, 27 Mar 2026 17:01:53 GMT</pubDate>
      <description><![CDATA[I’ve been there. I’ve been the student feeling the weight of an intense workload. I’ve been the entrepreneur watching a project struggle to take off. I’ve been the worker just counting down the minute...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/cuando-el-motor-se-apaga-cronica-de-la-desmotivacion-y-el-poder-de-la-disciplina-1774630540932.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[I’ve been there. I’ve been the student feeling the weight of an intense workload. I’ve been the entrepreneur watching a project struggle to take off. I’ve been the worker just counting down the minutes until I can close my laptop. Demotivation isn't laziness; it is an emotional and cognitive burnout that happens when the gap between the effort you put in and the results you get becomes too wide.

Science backs this up. It’s not that you "lack willpower." When chronic stress hits, our brains enter a state of fatigue that affects the prefrontal cortex—the area responsible for decision-making. This is what psychologists call the **Burnout Effect**, and it can't be fixed by a one-minute motivational video.

#### The "Spark" Trap
We've been sold the idea that to create amazing things, we need to be "inspired." The truth is that motivation is a biological impulse (driven by dopamine) designed to get us started, not to keep us going. If you rely on motivation to work on your blog or your assignments, you are at the mercy of your mood—and moods are treacherous.

#### Discipline: The Emergency Crew
This is where discipline comes in. It’s not that rigid, military word that sounds like punishment. Discipline is simply **keeping a promise to your past self**. It’s saying: "Yesterday I decided I would write this post today, and even though I don't feel like it now, I’m going to do it because I trust the judgment I had yesterday."

When motivation runs dry, discipline is what keeps the building standing. It’s what makes you open your IDE when you’d rather be sleeping. The funny thing is, motivation often returns *after* you start working through discipline, not before.

**Sources for further reading:**
* *Duhigg, C. (2012). The Power of Habit.* Explains how habits and brain discipline replace the need for constant motivation.
* *Maslach, C., & Leiter, M. P. (2016). Understanding the burnout experience.* A deep dive into how exhaustion impacts professional and academic performance.]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[2026 AI Wars: Which is the Most Powerful Coding AI and Who Has the Best Free Plan?]]></title>
      <link>https://blog.codewithbotina.com/en/posts/2026-ai-wars-which-is-the-most-powerful-coding-ai-and-who-has-the-best-free-plan</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/2026-ai-wars-which-is-the-most-powerful-coding-ai-and-who-has-the-best-free-plan</guid>
      <pubDate>Wed, 25 Mar 2026 21:47:07 GMT</pubDate>
      <description><![CDATA[2026 AI Wars: Which is the Most Powerful Coding AI and Who Has the Best Free Plan? Welcome back to Code With Botina. Coding in 2026 without an AI assistant is like trying to build a skyscraper with a ...]]></description>
      <enclosure url="https://www.extrasoft.es/wp-content/uploads/2026/03/AGENTES-IA-03.jpg" type="image/jpeg"/>
      <content:encoded><![CDATA[# 2026 AI Wars: Which is the Most Powerful Coding AI and Who Has the Best Free Plan?

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). Coding in 2026 without an AI assistant is like trying to build a skyscraper with a hand saw. However, with so many options like **GitHub Copilot**, **Cursor**, **Claude**, and **Gemini**, it’s easy to get overwhelmed.

Today, we’re analyzing which AI is currently the most powerful for writing code and, most importantly for our community: **Which one offers the most generous free plan?**

---

## 1. The Most Powerful: Claude 3.7 Sonnet (Anthropic) & Cursor Indexing

As of today, according to the latest benchmarks from **LiveCodeBench** and **SWE-bench**, the **Claude 3.7 Sonnet** model stands as the undisputed leader in logical reasoning and clean code generation.

However, "power" isn't just the model; it's how it integrates. This is where **Cursor** (the VS Code fork) wins the battle. Its ability to index your entire local repository allows the AI to understand not just the file you have open, but how your API connects to your database and your TypeScript types across the whole project.

## 2. The Most Generous Free Plan: Gemini 3 Flash (Google)

If we’re talking about "getting the most for zero dollars," Google is taking the crown in 2026. While others limit their free plans to small models or a few requests per day, **Gemini 3 Flash** offers:

* **Massive Context Window:** Up to 1 million tokens in its free tier via Google AI Studio. This means you can upload a framework’s entire documentation plus 50 files from your project, and the AI will still remember everything.
* **Native Integration:** Its integration with **Project IDX** and **Android Studio** plugins allows for a frictionless workflow for students.
* **Usage Quotas:** It is, by far, the one that allows the most messages per minute before asking you to upgrade.

---

## 3. Quick Comparison of Free Plans (2026)

| Tool | Power (Model) | Free Plan Advantage |
| :--- | :--- | :--- |
| **Cursor** | Extremely High (Claude 3.7 / GPT-5o) | 20 "Premium" model uses per month + unlimited basic model uses. |
| **Gemini (Google AI Studio)** | Very High (Gemini 3 Flash) | **The Winner:** Immense context (1M tokens) and very high message quotas. |
| **GitHub Copilot** | High (GPT-5o / Claude) | Limited. Requires the *GitHub Student Developer Pack* to be free. |
| **Codeium** | Mid-High (Proprietary) | Unlimited individual use forever (excellent Copilot alternative). |

---

## Conclusion & "Botina's" Recommendation

If you want **raw power** to solve a complex bug: Use **Cursor** with Claude 3.7. It is surgical.

If you want **economy and analysis capacity** for large university projects: Use **Gemini 3 Flash**. Having the AI read your entire project at once without paying a cent is an unfair advantage.

Sources: *State of AI Report 2026, LiveCodeBench, IEEE Spectrum Top Programming Assistants.*

What about you? Which one are you using for this semester's projects? Share your experience in the comments!

---
*Optimize your workflow and code smarter at [Code With Botina](https://blog.codewithbotina.com/).*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[The Technology Behind Anohana and Japanese Animation]]></title>
      <link>https://blog.codewithbotina.com/en/posts/the-technology-behind-anohana-and-japanese-animation</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/the-technology-behind-anohana-and-japanese-animation</guid>
      <pubDate>Tue, 24 Mar 2026 14:27:35 GMT</pubDate>
      <description><![CDATA[Tears and Code: The Technology Behind Anohana and Japanese Animation Welcome back to Code With Botina. This weekend, I stepped away from servers and databases to watch Anohana: The Flower We Saw That ...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/the-technology-behind-anohana-and-japanese-animation-1774362453648.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# Tears and Code: The Technology Behind Anohana and Japanese Animation

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). This weekend, I stepped away from servers and databases to watch **Anohana: The Flower We Saw That Day**. If you haven't seen it yet, get your tissues ready because it’s an incredibly emotional story (highly recommended!).

While I was trying to process my feelings, my developer brain couldn’t help but wonder: **What technology achieves this level of detail? What programming languages power the animation engines used in Japan?**

Today, we’ll explore the tech stack the anime industry uses to turn lines of code into pure emotion.

---

## 1. The Industry Standard: RETAS Studio and CLIP STUDIO PAINT

Unlike Western animation, which has moved almost entirely to 3D, anime remains faithful to its 2D roots. The standard software in Japan for years has been **RETAS Studio** (specifically *Stylos* and *PaintMan*).

What is it written in? These legacy programs were primarily developed in **C++**. Why? Because of direct memory management and the speed required to handle thousands of high-resolution hand-drawn layers.

## 2. Toonz and the Open Source Magic

Did you know that **Studio Ghibli** helped develop its own version of software? It’s called **OpenToonz**.
* **The Language:** It is mostly written in **C++**.
* **Technical Fact:** It uses libraries like **Qt** for the user interface and complex image processing algorithms to make scanned drawings look naturally digitally painted.

## 3. 3D Integration: Blender’s Rise in Japan

Lately, studios like *A-1 Pictures* (the creators of Anohana) use **Blender** heavily for complex backgrounds or vehicles.
* **Languages:** Blender is a powerful mix of **C, C++, and Python**.
* **Usage:** Python is used for scripts and custom tools that animators create to automate repetitive tasks, while C++ handles the rendering engine that calculates light and shadows.

## 4. Compositing Engines: After Effects

The final "magic" (light effects, sentimental blurs, and rain) usually happens in **Adobe After Effects**.
* **Under the Hood:** Although it's commercial software, its architecture allows for plugins written in **C++ (Adobe SDK)**. Japanese studios often program their own filters to give it that warm, "analog" look that made us cry in Anohana.

---

## Conclusion

Behind every scene that makes us weep, there are thousands of lines of **C++** code optimizing processes and **Python** scripts automating colors. Japanese animation is the perfect marriage between traditional hand-drawn art and high-performance software engineering.

If you love anime and code, you have a new motivation: learn C++ to optimize the brushes of the future!

What other anime has made you wonder how it was created? Let me know in the comments!

---
*Exploring the intersection of art and engineering at [Code With Botina](https://blog.codewithbotina.com/).*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[Deconstructing the Giant: The Backend Architecture and Databases Behind ChatGPT]]></title>
      <link>https://blog.codewithbotina.com/en/posts/deconstructing-the-giant-the-backend-architecture-and-databases-behind-chatgpt</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/deconstructing-the-giant-the-backend-architecture-and-databases-behind-chatgpt</guid>
      <pubDate>Mon, 23 Mar 2026 17:06:45 GMT</pubDate>
      <description><![CDATA[Deconstructing the Giant: The Backend Architecture and Databases Behind ChatGPT Welcome to a new post on Code With Botina. We all use ChatGPT daily to debug code, write emails, or understand complex c...]]></description>
      <enclosure url="https://s.13.cl/sites/default/files/styles/manualcrop_850x475/public/13c/articulos/field-imagen/2025-08/chatgpt.JPG.jpeg?h=31857ea2&amp;itok=-Q7PG7nE" type="image/jpeg"/>
      <content:encoded><![CDATA[# Deconstructing the Giant: The Backend Architecture and Databases Behind ChatGPT

Welcome to a new post on [Code With Botina](https://blog.codewithbotina.com/). We all use ChatGPT daily to debug code, write emails, or understand complex concepts. But, as software engineers, we cannot just stop at the user interface; we must ask ourselves: **What on earth is happening in the backend when I press "Enter"?**

Today, we are going to dissect the architecture of ChatGPT. We will talk about how their services are distributed, what databases they use to remember your conversations, and how they achieve that famous "real-time typing" effect.

---

## 1. The Base Infrastructure: The Azure Empire

OpenAI does not have its own traditional data centers; they run entirely on **Microsoft Azure** infrastructure.

To handle the massive amount of global traffic, the entire architecture is containerized and orchestrated with **Kubernetes (Azure Kubernetes Service - AKS)**. This allows them to scale horizontally: if half a million students suddenly log in at the same time to do their homework, Kubernetes instantly spins up hundreds of new containers (pods) to handle the load.

The real physical "muscle" comes from gigantic clusters of thousands of NVIDIA GPUs (like the A100 or H100), connected by ultra-high-speed networks called *InfiniBand*.

---

## 2. The Best Kept Secret: LLMs are Stateless

This is where the concepts we've discussed on the blog come together. Just like the JWTs we explained before, **AI models have no memory**. They are stateless systems.

If you tell ChatGPT "Hi, my name is Botina" and then in another message you ask "What is my name?", the model itself has no idea. For the AI to remember, **the backend has to send the entire chat history with every new HTTP request**.

### How do the microservices flow then?
1. **API Gateway / Load Balancer:** Your request comes in and is routed to the least busy server.
2. **Session/History Service:** Before touching the AI, this microservice goes to the database, fetches your latest messages from that session, and concatenates them with your new prompt.
3. **Moderation Service:** All that text passes through a secondary security API that checks that you are not asking for illegal or dangerous things.
4. **Inference Fleet:** Finally, the full text reaches the servers with the GPUs running the model (GPT-4), which process the response and send it back.

---

## 3. What Databases does ChatGPT use?

To maintain this flow at the speed of light, a traditional relational database (like MySQL) would collapse under the weight of millions of global reads and writes per second. Their data strategy is divided into layers:

* **Cache Layer (Redis):** Used to store the context of the active conversation. Redis lives in RAM, so the *History Service* can retrieve your latest messages in milliseconds to build the prompt.
* **Persistent Database (Distributed):** To permanently save your chat history (that sidebar you see on the left), they use highly distributed NoSQL databases (most likely Azure's **Cosmos DB** or a Cassandra-style database). These databases replicate information across multiple regions of the world, ensuring that if a server in the US goes down, your chats remain safe.

---

## 4. The "Typewriter" Effect: Server-Sent Events (SSE)

If ChatGPT used a normal HTTP request (`GET` or `POST`), you would have to stare at a blank screen for 10 or 20 seconds until the AI finished thinking of the entire response to send it all at once.

To avoid that bad user experience, they use **Server-Sent Events (SSE)**. It is a one-way data stream. The client opens an HTTP connection and keeps it alive. As the GPU guesses the next word (token), the server immediately pushes it to the client.

Here is what a basic example of an endpoint simulating this would look like in a Node.js/Express backend:

```javascript
// Streaming (SSE) Endpoint Example
app.get('/api/chat/stream', (req, res) =&gt; {
    // Set headers to keep the connection open
    res.setHeader('Content-Type', 'text/event-stream');
    res.setHeader('Cache-Control', 'no-cache');
    res.setHeader('Connection', 'keep-alive');

    const aiResponse = ["Hello, ", "I am ", "ChatGPT ", "and ", "I am ", "typing."];
    let iteration = 0;

    // Simulate the AI generating tokens every 500ms
    const interval = setInterval(() =&gt; {
        if (iteration &lt; aiResponse.length) {
            res.write(`data: ${aiResponse[iteration]}\n\n`);
            iteration++;
        } else {
            res.write('data: [DONE]\n\n');
            clearInterval(interval);
            res.end();
        }
    }, 500);
});
```

---

## Conclusion

Behind the "magic" of Artificial Intelligence, there is a classic microservices architecture taken to the extreme. Load balancers, in-memory databases, state management, and persistent connections. Everything you learn today about backend development is the foundation for building the systems of the future.

What part of ChatGPT's architecture do you find most fascinating? Let me know in the comments!

---
*If you are passionate about backend engineering and want to keep discovering how real-world applications are built, keep reading [Code With Botina](https://blog.codewithbotina.com/).*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[The Ultimate English Verb Guide to Surviving Your Scrum Ceremonies]]></title>
      <link>https://blog.codewithbotina.com/en/posts/the-ultimate-english-verb-guide-to-surviving-your-scrum-ceremonies</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/the-ultimate-english-verb-guide-to-surviving-your-scrum-ceremonies</guid>
      <pubDate>Sat, 21 Mar 2026 01:37:50 GMT</pubDate>
      <description><![CDATA[The Ultimate English Verb Guide to Surviving Your Scrum Ceremonies Welcome back to Code With Botina. Today, we are taking a break from pure code to talk about another fundamental tool in our tech stac...]]></description>
      
      <content:encoded><![CDATA[# The Ultimate English Verb Guide to Surviving Your Scrum Ceremonies

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). Today, we are taking a break from pure code to talk about another fundamental tool in our tech stack: **the English language**.

If you work in the software industry, chances are you use agile methodologies like Scrum. And if you aspire to work in international teams or open-source projects, you will need to communicate in English. Sometimes the issue isn't a lack of programming skills, but rather not knowing how to explain what you did yesterday, what you will do today, or what is blocking you.

To help our community level up, I have compiled this extensive and definitive list of the most commonly used English verbs during Scrum ceremonies. I have included the present tense, the past tense (to report what you already did), and the future tense (to commit to what you will do).

Bookmark this post for your next meeting!

---

## 1. Sprint Planning
In this ceremony, you define what will be done and how. Here you need verbs for estimating, committing, and organizing.

* **Estimate** (Past: *Estimated* | Future: *Will estimate*)
  * *Usage:* When you assign story points or time to a task. *"We estimated this task at 5 points."*
* **Allocate** (Past: *Allocated* | Future: *Will allocate*)
  * *Usage:* To assign resources, time, or capacity to a specific task.
* **Prioritize** (Past: *Prioritized* | Future: *Will prioritize*)
  * *Usage:* When you order the Backlog, deciding what is most important to deliver first.
* **Commit** (Past: *Committed* | Future: *Will commit*)
  * *Usage:* To express that the team promises to deliver a set of user stories by the end of the Sprint.
* **Break down** (Past: *Broke down* | Future: *Will break down*)
  * *Usage:* When a user story is too large and you need to split it into smaller technical tasks.
* **Define** (Past: *Defined* | Future: *Will define*)
  * *Usage:* When establishing Acceptance Criteria or the Definition of Done.
* **Assign** (Past: *Assigned* | Future: *Will assign*)
  * *Usage:* When a task is linked to a specific developer's name.
* **Clarify** (Past: *Clarified* | Future: *Will clarify*)
  * *Usage:* When you ask the Product Owner to explain a confusing requirement in more detail.
* **Forecast** (Past: *Forecasted* | Future: *Will forecast*)
  * *Usage:* To predict how much work the team believes they can complete based on past velocity.
* **Scope** (Past: *Scoped* | Future: *Will scope*)
  * *Usage:* To define the exact extent and boundaries of a feature you are going to develop.

---

## 2. Daily Scrum (The Daily Stand-up)
The 15-minute meeting where you answer: What did I do yesterday? What will I do today? What is blocking me? Here you need pure action verbs.

* **Work on** (Past: *Worked on* | Future: *Will work on*)
  * *Usage:* The most common verb. You use it to say which task you were coding. *"Yesterday, I worked on the login API."*
* **Block** (Past: *Blocked* | Future: *Will block*)
  * *Usage:* Crucial for raising your hand when something prevents you from making progress. *"I am blocked by the database migration."*
* **Complete** (Past: *Completed* | Future: *Will complete*)
  * *Usage:* To report that you finished a task 100%.
* **Tackle** (Past: *Tackled* | Future: *Will tackle*)
  * *Usage:* A very professional way to say you are going to "face" or start working on a difficult problem.
* **Update** (Past: *Updated* | Future: *Will update*)
  * *Usage:* When you refreshed a library, changed the status of your Jira ticket, or modified documentation.
* **Sync** (Past: *Synced* | Future: *Will sync*)
  * *Usage:* When you need a quick chat with another developer after the Daily to align your work. *"I will sync with John regarding the JWT implementation."*
* **Resolve** (Past: *Resolved* | Future: *Will resolve*)
  * *Usage:* When you fix a bug or a code conflict.
* **Implement** (Past: *Implemented* | Future: *Will implement*)
  * *Usage:* When you translate business logic into code (e.g., "I implemented the payment gateway").
* **Investigate** (Past: *Investigated* | Future: *Will investigate*)
  * *Usage:* When you aren't coding yet, but reading logs or researching why something is failing.
* **Review** (Past: *Reviewed* | Future: *Will review*)
  * *Usage:* Widely used to say you were checking a teammate's code (Pull Requests).

---

## 3. Sprint Review
Here you show working software to the stakeholders (clients/owners). It's time to show off.

* **Demonstrate / Demo** (Past: *Demonstrated / Demoed* | Future: *Will demonstrate / Will demo*)
  * *Usage:* When you share your screen and show how the new feature works live.
* **Present** (Past: *Presented* | Future: *Will present*)
  * *Usage:* Similar to demo, but more focused on explaining the business value of what was delivered.
* **Deliver** (Past: *Delivered* | Future: *Will deliver*)
  * *Usage:* To talk about the value or features the team successfully finished in this Sprint.
* **Accept** (Past: *Accepted* | Future: *Will accept*)
  * *Usage:* Used by the Product Owner when they review your work and confirm it meets the criteria.
* **Reject** (Past: *Rejected* | Future: *Will reject*)
  * *Usage:* When the work does not meet the requirements and must go back to the backlog.
* **Gather** (Past: *Gathered* | Future: *Will gather*)
  * *Usage:* Usually used with "feedback." It means you are collecting the clients' opinions.
* **Showcase** (Past: *Showcased* | Future: *Will showcase*)
  * *Usage:* To proudly display the work accomplished by the development team.
* **Release** (Past: *Released* | Future: *Will release*)
  * *Usage:* When the feature being shown is already available for real users to interact with in production.
* **Inspect** (Past: *Inspected* | Future: *Will inspect*)
  * *Usage:* To analyze the delivered software increment to see if it aligns with the product goal.

---

## 4. Sprint Retrospective
The ceremony to talk about us, the team. What we did right, what we did wrong, and how to improve our processes.

* **Improve** (Past: *Improved* | Future: *Will improve*)
  * *Usage:* The core of the retrospective. Talking about which technical or human processes we will do better.
* **Reflect** (Past: *Reflected* | Future: *Will reflect*)
  * *Usage:* To take a moment to think deeply about the last work cycle.
* **Identify** (Past: *Identified* | Future: *Will identify*)
  * *Usage:* When the team finds the root cause of an issue or a bottleneck in their workflow.
* **Brainstorm** (Past: *Brainstormed* | Future: *Will brainstorm*)
  * *Usage:* To generate a quick flow of ideas among everyone to solve a specific problem.
* **Propose** (Past: *Proposed* | Future: *Will propose*)
  * *Usage:* When you suggest a new tool, a new team rule, or an architectural change.
* **Adapt** (Past: *Adapted* | Future: *Will adapt*)
  * *Usage:* To change our behavior or processes in response to the issues we identified.
* **Iterate** (Past: *Iterated* | Future: *Will iterate*)
  * *Usage:* To apply continuous, small changes to our work process to perfect it step by step.
* **Fail** (Past: *Failed* | Future: *Will fail*)
  * *Usage:* It is healthy to talk about mistakes. You use this to admit what went wrong during the Sprint.
* **Learn** (Past: *Learned* | Future: *Will learn*)
  * *Usage:* The consequence of failing. The knowledge we extract from the mistake.
* **Celebrate** (Past: *Celebrated* | Future: *Will celebrate*)
  * *Usage:* To acknowledge achievements, congratulate a teammate for their help, and applaud good work.

---

## 5. Backlog Refinement
The meeting where we prepare future work so it is ready when Planning arrives.

* **Refine** (Past: *Refined* | Future: *Will refine*)
  * *Usage:* To clean up, clarify, and detail user stories so they are ready for development.
* **Detail** (Past: *Detailed* | Future: *Will detail*)
  * *Usage:* To add technical information, mocks, or exact descriptions to an empty ticket.
* **Split** (Past: *Split* [irregular] | Future: *Will split*)
  * *Usage:* To divide a gigantic user story (Epic) into smaller stories that fit into a single Sprint.
* **Discard** (Past: *Discarded* | Future: *Will discard*)
  * *Usage:* To remove tickets from the backlog that no longer make business sense or are obsolete.
* **Analyze** (Past: *Analyzed* | Future: *Will analyze*)
  * *Usage:* To study the technical requirements before committing to coding them.
* **Revise** (Past: *Revised* | Future: *Will revise*)
  * *Usage:* To look back at an old estimate or requirement because business rules have changed.
* **Reorder** (Past: *Reordered* | Future: *Will reorder*)
  * *Usage:* To change the priority order of the tickets on the board.

---

Technical English doesn't have to be a blocker in your career. Take these verbs, write them on sticky notes, or use them as a template for your next Daily. The more you use them, the more natural they will become.

Is there any other verb you use a lot in your meetings that isn't on the list? Leave it in the comments and let's grow this guide!

---
*Keep scaling your technical (and language) skills with [Code With Botina](https://blog.codewithbotina.com/).*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[Java is Not Dead, It’s Evolving: The Top 10 Libraries and Frameworks for Building APIs in 2026]]></title>
      <link>https://blog.codewithbotina.com/en/posts/java-is-not-dead-its-evolving-the-top-10-libraries-and-frameworks-for-building-apis-in-2026</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/java-is-not-dead-its-evolving-the-top-10-libraries-and-frameworks-for-building-apis-in-2026</guid>
      <pubDate>Thu, 19 Mar 2026 15:56:11 GMT</pubDate>
      <description><![CDATA[Java is Not Dead, It’s Evolving: The Top 10 Libraries and Frameworks for Building APIs in 2026 Welcome back to Code With Botina. If you have ever had to build a Java backend for a university project, ...]]></description>
      <enclosure url="https://www.tatvasoft.com/outsourcing/wp-content/uploads/2025/01/Best-Java-Frameworks.jpg" type="image/jpeg"/>
      <content:encoded><![CDATA[# Java is Not Dead, It’s Evolving: The Top 10 Libraries and Frameworks for Building APIs in 2026

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). If you have ever had to build a Java backend for a university project, you have probably faced endless configurations, giant XML files, and brutal memory consumption. It is completely normal to end up exhausted, thinking that languages like Node.js or Go are the only way out.

But the reality of the tech industry is completely different. Java remains the undisputed king of enterprise architectures, and its ecosystem has evolved incredibly. Today, we are going to explore the top 10 most used tools to create APIs in Java, what kind of projects they actually shine in, and what a basic endpoint looks like in each of them.

Forget about spaghetti code; it is time to talk about modern architecture.

---

### 1. Spring Boot (The Undisputed King)
If there is one standard in the industry, it is Spring Boot. It was born to eliminate the configuration nightmare of the old Spring Framework. It comes with "batteries included": security, data access, metrics, and embedded servers.
* **Best for:** Complex microservice architectures, enterprise monolithic applications, and projects where you need a massive ecosystem with integrations for absolutely everything (databases, message queues, cloud).
* **Endpoint Example:**

```java
@RestController
@RequestMapping("/api")
public class HelloController {
    
    @GetMapping("/greeting")
    public String greet() {
        return "Hello from Spring Boot!";
    }
}
```

### 2. Quarkus (Supersonic Subatomic Java)
Created by Red Hat, Quarkus is Java's answer to the Edge Computing and Serverless era. It uses GraalVM to compile your Java code into a native binary. The result? It boots up in milliseconds and consumes a fraction of the RAM that Spring uses.
* **Best for:** Serverless environments (like AWS Lambda), massive Kubernetes deployments, and cloud-native architectures where resource consumption costs real money.
* **Endpoint Example:**

```java
@Path("/api/greeting")
public class HelloResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String greet() {
        return "Hello from Quarkus!";
    }
}
```

### 3. Micronaut
Very similar to Quarkus in its philosophy. Micronaut is designed from the ground up for microservices. Unlike Spring (which uses runtime reflection and slows down startup times), Micronaut does all its dependency injection magic at compile time.
* **Best for:** Lightweight microservices, Serverless applications, and Internet of Things (IoT) projects where hardware has limited memory.
* **Endpoint Example:**

```java
@Controller("/api")
public class HelloController {

    @Get(uri="/greeting", produces="text/plain")
    public String greet() {
        return "Hello from Micronaut!";
    }
}
```

### 4. Javalin (Express.js-style Simplicity)
If you come from the JavaScript/Node.js world and love the simplicity of Express.js, you are going to love Javalin. It doesn't use magic annotations (`@`). It is a purely programmatic framework, incredibly lightweight, and written in Kotlin (but 100% interoperable with Java).
* **Best for:** Fast projects, prototypes (MVPs), simple REST APIs, and developers who are learning and don't want to deal with the black magic of heavy frameworks.
* **Endpoint Example:**

```java
import io.javalin.Javalin;

public class App {
    public static void main(String[] args) {
        Javalin app = Javalin.create().start(8080);
        app.get("/api/greeting", ctx -> ctx.result("Hello from Javalin!"));
    }
}
```

### 5. Eclipse Vert.x (The Reactive Beast)
Vert.x is not a traditional framework; it is a *toolkit* for building reactive applications on the JVM. It uses an "Event Loop" (just like Node.js), meaning it can handle tens of thousands of concurrent connections using very few CPU threads.
* **Best for:** Real-time applications (chats, live financial dashboards with WebSockets), video streaming, and systems with extremely high network loads.
* **Endpoint Example:**

```java
import io.vertx.core.Vertx;

public class App {
    public static void main(String[] args) {
        Vertx vertx = Vertx.vertx();
        vertx.createHttpServer().requestHandler(req -> {
            if (req.uri().equals("/api/greeting")) {
                req.response().end("Hello from Vert.x!");
            }
        }).listen(8080);
    }
}
```

### 6. Dropwizard
Dropwizard was one of the pioneers in packaging a Java application with an embedded web server (Jetty) into a single `.jar` file. It is highly "opinionated", meaning it forces you to use the libraries they consider the best (Jersey for REST, Jackson for JSON, Metrics for monitoring).
* **Best for:** Production-grade RESTful services where stability is paramount and you need operational metrics from minute zero.
* **Endpoint Example:**

```java
@Path("/api/greeting")
@Produces(MediaType.APPLICATION_JSON)
public class HelloResource {

    @GET
    public String greet() {
        return "{\"message\": \"Hello from Dropwizard!\"}";
    }
}
```

### 7. Helidon (Oracle’s Contender)
Helidon is a collection of libraries for writing microservices, backed by Oracle. It comes in two flavors: *Helidon MP* (for those who like classic enterprise standards) and *Helidon SE* (its reactive, ultra-lightweight version that doesn't use annotations).
* **Best for:** Migrating legacy applications to microservices within the Oracle ecosystem or building high-performance reactive APIs.
* **Endpoint Example (Helidon SE):**

```java
import io.helidon.webserver.Routing;
import io.helidon.webserver.WebServer;

public class App {
    public static void main(String[] args) {
        Routing routing = Routing.builder()
                .get("/api/greeting", (req, res) -> res.send("Hello from Helidon!"))
                .build();
        WebServer.create(routing).start();
    }
}
```

### 8. Spark Java (The Minimalist)
*Note: Not to be confused with Apache Spark (which is for Big Data).*
Spark Java is another micro-framework inspired by Sinatra (Ruby). It was created to make building web applications in Java as easy as possible with minimal effort and zero XML configurations.
* **Best for:** Students, quick proofs of concept (PoCs), and extremely small services that don't require a complex architecture.
* **Endpoint Example:**

```java
import static spark.Spark.*;

public class App {
    public static void main(String[] args) {
        get("/api/greeting", (req, res) -> "Hello from Spark Java!");
    }
}
```

### 9. Play Framework
Play was designed to solve the performance deficiencies of traditional web frameworks. It is built on Akka (a very powerful concurrency tool) and is "Stateless," making it perfect for horizontal scaling.
* **Best for:** Full-Stack web applications (with integrated frontend), high-traffic portals, and architectures requiring heavy asynchronous processing.
* **Endpoint Example:**

```java
import play.mvc.*;

public class HelloController extends Controller {
    public Result greet() {
        return ok("Hello from Play Framework!");
    }
}
```

### 10. Jersey (The JAX-RS Standard)
Jersey is not a full framework, but a library that implements the official Java specification for RESTful APIs (JAX-RS). Many tools (like Dropwizard or Helidon) use it under the hood.
* **Best for:** Developers who need to strictly adhere to Jakarta EE (formerly Java EE) standards and traditional corporate environments.
* **Endpoint Example:**

```java
@Path("/api")
public class HelloResource {

    @GET
    @Path("/greeting")
    @Produces(MediaType.TEXT_PLAIN)
    public String greet() {
        return "Hello from Jersey!";
    }
}
```

---

### Conclusion

Learning to code shouldn't be about suffering through the configuration of obsolete tools; it's about choosing the right piece of technology to solve a specific problem.

If you need the industry heavyweight, go for **Spring Boot**. If you want to modernize and save money on cloud hosting, learn **Quarkus** or **Micronaut**. And if you just want to test an idea this weekend without stressing out, give **Javalin** a try.

Which of these have you used in your projects, or which one are you forced to use at university? Let's talk about code and architecture in the comments!

---
*Stay tuned to [Code With Botina](https://blog.codewithbotina.com/) to master real-world backend development and leave bad practices behind.*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[Goodbye Over-fetching: What is GraphQL and Why It Is Revolutionizing APIs]]></title>
      <link>https://blog.codewithbotina.com/en/posts/goodbye-over-fetching-what-is-graphql-and-why-it-is-revolutionizing-apis</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/goodbye-over-fetching-what-is-graphql-and-why-it-is-revolutionizing-apis</guid>
      <pubDate>Wed, 18 Mar 2026 16:23:43 GMT</pubDate>
      <description><![CDATA[Goodbye Over-fetching: What is GraphQL and Why It Is Revolutionizing APIs Welcome back to Code With Botina. In our previous posts, we highly praised Client-Server architecture and the HTTP requests th...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/adios-al-over-fetching-que-es-graphql-y-por-que-esta-revolucionando-las-apis-1773751500919.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# Goodbye Over-fetching: What is GraphQL and Why It Is Revolutionizing APIs

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). In our previous posts, we highly praised Client-Server architecture and the HTTP requests that bring REST APIs to life. But let's be honest: REST has its flaws, especially when applications grow and become complex.

Today we are going to talk about **GraphQL**, the technology created by Facebook (Meta) that came to change the game and solve the biggest headaches for Frontend and Backend developers.

---

## The Problem with REST: Too much or too little information

Imagine you are building a user profile screen for your mobile app. You only need to show their **name** and **profile picture**.

In a traditional REST API, you would make a `GET` request to `/api/users/1`. 
The problem? The server returns a giant JSON file containing their name, picture, email, address, date of birth, purchase history, and phone number.

This is called **Over-fetching**. You are downloading a bunch of data you don't need, wasting bandwidth and draining the user's battery.

On the flip side, if you also want to show the last 3 posts from that user, the REST API might force you to make *another* request to `/api/users/1/posts`. This is called **Under-fetching**, because a single request wasn't enough to build your interface.

---

## The Solution: What is GraphQL?

**GraphQL** is a query language for your API. Instead of having multiple endpoints like in REST (`/users`, `/posts`, `/comments`), **GraphQL has a single endpoint** (usually `/graphql`).

The magic lies in the fact that the Client (the Frontend) has absolute control. Instead of the server deciding what data to send, **the client tells the server exactly what data it needs, and the server returns only that. Nothing more, nothing less.**

### Practical Code Example

Following our previous example, if we only want the name, picture, and titles of the last posts, we would send this Query to the GraphQL server:

```graphql
query {
  user(id: "1") {
    name
    profilePicture
    posts(limit: 3) {
      title
    }
  }
}
```

And what does the server return? The exact same structure in JSON format:

```json
{
  "data": {
    "user": {
      "name": "Botina",
      "profilePicture": "[https://img.com/photo.jpg](https://img.com/photo.jpg)",
      "posts": [
        { "title": "What is an API" },
        { "title": "Edge Computing Explained" },
        { "title": "The damage of fake teachers" }
      ]
    }
  }
}
```

Boom! A single request, zero garbage data downloaded.

---

## Why is GraphQL so relevant today?

1. **Mobile Performance:** By downloading only what is strictly necessary, applications load much faster and consume less mobile data.
2. **Agile Development:** In REST, if the Frontend team needs a new piece of data on the screen, the Backend team has to modify the endpoint. In GraphQL, the Frontend simply adds one more field to their query and they are good to go. Total independence!
3. **Strongly Typed:** GraphQL has a strict Schema. The Frontend knows exactly what data types exist (String, Int, Boolean), which makes tools like autocomplete in your code editor work wonderfully and prevents thousands of bugs.

---

## Conclusion

REST isn't going anywhere; it is still excellent for simple services or internal microservices. But for complex, modern, user-facing applications, GraphQL is the undisputed king. It gives us back control and optimizes our applications to the max.

Have you ever struggled fighting with a REST API that returned too much garbage data? Let me know in the comments!

---
*If you are passionate about software architecture and clean code, make sure to keep exploring [Code With Botina](https://blog.codewithbotina.com/).*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[The Hidden Language of the Web: HTTP Requests Explained and the Methods Nobody Teaches You]]></title>
      <link>https://blog.codewithbotina.com/en/posts/the-hidden-language-of-the-web-http-requests-explained-and-the-methods-nobody-teaches-you</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/the-hidden-language-of-the-web-http-requests-explained-and-the-methods-nobody-teaches-you</guid>
      <pubDate>Fri, 13 Mar 2026 14:57:48 GMT</pubDate>
      <description><![CDATA[The Hidden Language of the Web: HTTP Requests Explained and the Methods Nobody Teaches You Every time you open your browser, like a photo, or send a message, your device is having an invisible convers...]]></description>
      <enclosure url="https://parzibyte.me/blog/posts/peticion-http-php-json-formulario/Petici%C3%B3n-HTTP-en-PHP-M%C3%A9todo-POST-con-datos-de-formulario_hu_c65c2db43953336b.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# The Hidden Language of the Web: HTTP Requests Explained and the Methods Nobody Teaches You

Every time you open your browser, like a photo, or send a message, your device is having an invisible conversation with a server somewhere in the world. That conversation happens thanks to the HTTP protocol.

Today, we are going to dive into the core of web architecture: **HTTP requests**. We will cover what exactly they are, how they work, the most popular methods, and those "rare" methods that almost no one mentions but are vital to the network.

---

## What is an HTTP Request and how does it work?

HTTP stands for *HyperText Transfer Protocol*. It is the set of rules that defines how messages are formatted and transmitted between a Client (your browser or app) and a Server.

Think of an HTTP request as sending a formal letter in the mail. For the server to understand what you want, your letter must have a very specific structure:

1. **The URL (The destination):** Where you are sending the letter (e.g., `https://api.website.com/users`).
2. **The Method (The intent):** What you want the server to do with that letter (e.g., "give me data" or "save this").
3. **The Headers (The metadata):** Extra information like "I speak English," "here is my security token," or "my message format is JSON."
4. **The Body (The payload):** The actual content of your message. (Note: not all requests have a body).

When the server receives this "letter", it processes it and sends back an **HTTP Response**, which includes a Status Code (like the famous `404 Not Found` or `200 OK`) and the requested data.

---

## The Main Cast: The Day-to-Day Methods (CRUD)

If you are building a REST API, you will spend 95% of your time using these five methods, which align perfectly with database operations (Create, Read, Update, Delete):

* **GET:** Used to **Read** or retrieve data. It is a read-only request and should never modify anything on the server. *Example: Loading your news feed.*
* **POST:** Used to **Create** a new resource on the server. The data travels inside the request Body. *Example: Registering a new user or publishing a tweet.*
* **PUT:** Used to completely **Update** a resource. If the resource doesn't exist, it might create it. It replaces the entire entity. *Example: Updating your entire user profile.*
* **PATCH:** Used to **Modify** only a part of a resource. It is more efficient than PUT if you only want to change a small detail. *Example: Changing only your profile picture, leaving the rest intact.*
* **DELETE:** As the name implies, used to **Remove** a resource from the server.

---

## The Dark Side: The Lesser-Known HTTP Methods

The HTTP protocol has highly specific tools that often escape basic tutorials. Knowing them will give you a massive technical edge:

### 1. OPTIONS (The Pre-flight)
Before your browser makes a complex request to a server on a different domain (something called CORS), it first secretly sends an `OPTIONS` request. It basically asks the server: *"Hey, what methods and configurations am I allowed to use?"*. If the server gives the green light, the browser sends the actual request.

### 2. HEAD (Ghost Mode)
It is identical to `GET`, but with one key difference: **the server responds without the Body**. It only returns the Headers.
* *What is it used for?* To check if a file exists, see when it was last modified, or find out its file size before deciding if it's worth downloading (saving a lot of bandwidth).

### 3. TRACE (The Echo)
Mainly used for diagnostics. It tells the server to return the exact same request it received.
* *What is it used for?* To see if intermediary servers (like proxies or firewalls) are altering your request along the way. (Note: this is usually disabled in production for security reasons).

### 4. CONNECT (The Tunnel)
This method is used to ask a proxy server to open a two-way communication tunnel with another destination. It is the magic that allows encrypted traffic (HTTPS) to pass through a regular HTTP proxy.

---

## Conclusion

Understanding HTTP methods means you stop seeing the web as simple "magic" and start understanding it as the well-oiled machine it truly is. The next time you use an API or inspect the "Network" tab in your browser's developer tools, you will know exactly what is happening behind the scenes.

Did you know about the HEAD or OPTIONS methods? Leave a comment with your experience!]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[JWT Explained: The Modern Authentication Standard and How We Survived Before It]]></title>
      <link>https://blog.codewithbotina.com/en/posts/jwt-explained-the-modern-authentication-standard-and-how-we-survived-before-it</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/jwt-explained-the-modern-authentication-standard-and-how-we-survived-before-it</guid>
      <pubDate>Fri, 13 Mar 2026 00:14:26 GMT</pubDate>
      <description><![CDATA[JWT Explained: The Modern Authentication Standard and How We Survived Before It Welcome back to Code With Botina. If you’ve been building APIs or modern applications, you’ve almost certainly run into ...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/jwt-explicado-el-estandar-moderno-de-autenticacion-y-como-sobreviviamos-antes-de-el-1773319559354.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# JWT Explained: The Modern Authentication Standard and How We Survived Before It

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). If you’ve been building APIs or modern applications, you’ve almost certainly run into the great dilemma: *"How do I securely know who the user making this request is?"*.

Today we are going to demystify one of the most used (and sometimes misunderstood) technologies in web architecture: **JWT (JSON Web Tokens)**. We’ll see what they are, how they are used in real life, and what the dark world of authentication looked like before they existed.

---

## The Past: How did we authenticate before JWT? (Stateful Sessions)

To understand why JWT is so popular, we first need to understand the problem it solved. Before, the undisputed king was **Stateful Session-Based Authentication**.

It worked like this:
1. You logged in with your username and password.
2. The server verified your data and created a record in its own memory (or database) saying: *"Session ID `abc-123` belongs to Zeus."*
3. The server returned that ID (`abc-123`) saved in a **Cookie**.
4. On every future request, your browser sent that Cookie. The server had to look it up in its memory: *"Let's see, who owned `abc-123`? Ah yes, Zeus. Let him through."*

**What was the problem? Scalability.**
If your app grew and you needed to have 5 servers (Microservices), server number 2 had no idea who you were because your session was saved in the memory of server 1! You had to implement shared databases just for sessions (like Redis), which added a lot of complexity and latency.

---

## The Present: What is a JWT? (Stateless Authentication)

JWT (pronounced "jot") stands for **JSON Web Token**. It is an open standard that allows information to be securely transmitted between two parties as a JSON object.

The magic of JWT is that it is **Stateless**. The server no longer needs to save *anything* in its memory to know who you are. All the necessary information travels inside the token itself.

A JWT looks like a meaningless string of text, but it is actually composed of three parts separated by dots (`.`):
1. **Header:** Tells what type of token it is and what algorithm was used to sign it.
2. **Payload:** This is where your data goes (called *claims*). For example: your user ID, your role (admin or user), and when the token expires.
3. **Signature:** This is the most important part. The server takes the Header, the Payload, and a **Secret Key** that only it knows, and generates a cryptographic signature.

If a hacker tries to change their role from "user" to "admin" in the Payload, the signature will no longer match mathematically, and the server will reject the token instantly.

---

## How is a JWT used in practical life?

JWTs are mainly used for **API Authentication**. This is the modern flow when you log into an SPA (Single Page Application) or from your phone:

1. **The Login:** You enter your username and password. The server verifies in the database that you are who you claim to be.
2. **Token Creation:** The server takes your basic data (your ID, your email, when the session expires) and signs it with its secret key, creating a JWT.
3. **The Token travels to the Client:** The server returns that token to you like a digital "boarding pass."
4. **Client Storage:** Your browser or mobile app saves that token (usually in `localStorage`, or ideally in an `HTTPOnly Cookie` for security).
5. **Future Requests:** On every request (e.g., viewing your profile or buying something), the client sends this token to the server, usually in the request header called **`Authorization: Bearer `**.
6. **Verification (Without a Database):** The server receives the token and uses its secret key to mathematically verify the signature of the JWT. **It does not need to query any database to know who you are or what your role is.** It knows everything it needs just by reading the payload.

---

## Conclusion

JWT has saved us from the nightmare of synchronizing servers and creating massive databases just to remember who was logged in. Its "Stateless" nature makes it perfect for Microservices architectures, REST APIs, and Serverless environments.

But be careful: **JWTs are encoded, not encrypted**. Anyone can read the Payload of a token! NEVER put sensitive information like passwords in your token's payload.

Have you implemented JWT in your projects yet, or are you still using stateful sessions? Let me know in the comments!

---
*Subscribe to [Code With Botina](https://blog.codewithbotina.com/) to keep scaling your knowledge in backend development, APIs, and security.*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[If You Lack the Vocation, Leave: The Damage of Fake "Teachers" and Why Students Must Speak Up]]></title>
      <link>https://blog.codewithbotina.com/en/posts/if-you-lack-the-vocation-leave-the-damage-of-fake-teachers-and-why-students-must-speak-up</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/if-you-lack-the-vocation-leave-the-damage-of-fake-teachers-and-why-students-must-speak-up</guid>
      <pubDate>Tue, 10 Mar 2026 14:57:11 GMT</pubDate>
      <description><![CDATA[If You Lack the Vocation, Leave: The Damage of Fake "Teachers" and Why Students Must Speak Up Here at Code With Botina, we usually talk about code, architectures, and methodologies. But knowledge is n...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/if-you-lack-the-vocation-leave-the-damage-of-fake-teachers-and-why-students-must-speak-up-1773154629275.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# If You Lack the Vocation, Leave: The Damage of Fake "Teachers" and Why Students Must Speak Up

Here at [Code With Botina](https://blog.codewithbotina.com/), we usually talk about code, architectures, and methodologies. But knowledge is not acquired in a vacuum; it is transmitted. And today, I need to pause the technical talk to address something that is affecting thousands of students worldwide: **the crisis of true teaching.**

Today, I want to raise my voice for everyone who has sat in front of a screen or in a classroom, feeling the absolute frustration of trying to learn from people who, quite simply, do not want to teach.

---

## The Wall of Fake "Professionalism"

We have all encountered them. People severely underqualified in pedagogy who call themselves "teachers." They hide behind a wall of arrogance and a misunderstood sense of "professionalism" to justify their mediocrity in the classroom.

They have degrees, sure, but no one knows where they got the credentials to stand in front of a group of human beings. They genuinely believe that reading slides out loud, assigning absurdly long workloads, and answering legitimate questions with arrogance counts as teaching. In the way they speak, in their tone of voice, and in their attitude, you can feel an absolute disdain for their own job and for their students.

Being an expert in your field does not make you a good teacher. Teaching requires a gift, it requires patience, it requires empathy, and above all, **it requires a vocation**. If you lack all of this, you are not an educator; you are just an obstacle in the path of those of us who actually want to learn.

---

## A Direct, Unfiltered Message

To those "professors" who look down on us and blame us for not understanding their non-existent explanations, we need to say this without mincing words:

**If you don't like teaching, leave.** Go to the farthest place possible, where no one recognizes you and where you don't hold the future, mental health, and aspirations of any student in your hands. Education is not a shelter for fragile egos, nor is it a place to collect a paycheck at the expense of frustrating the next generation of professionals. If you hate being in the classroom, we are doing you a favor by asking you to step aside. Leave the space to the true masters who actually have the gift of transforming lives.

---

## To My Fellow Students: Do Not Stay Silent

Despite the anger this situation generates, this is not a message of defeat. Quite the opposite.

To you, who is reading this after a class where they made you feel like you weren't good enough: **you are not the problem.** Do not let the bitterness of a person without a calling extinguish your passion for your career.

We have to stop normalizing academic mistreatment. It is time to speak up.
* Evaluate your professors honestly.
* Complain formally when the teaching is deficient.
* Unite as a group and demand the quality education for which you are investing your time and effort.

We are not alone in this. We are the generation that has the tools to learn on our own, to build communities like this one, and to demand respect. **Do not stay silent.** Your education is your right, not a favor they are doing for you.

Have you had to deal with these kinds of "teachers" during your studies? Share your experience in the comments. Let's make this space a place where we can support each other and raise our voices together.

---
*Thank you for being part of [Code With Botina](https://blog.codewithbotina.com/). We keep learning, we keep coding, and above all, we keep demanding what we deserve.*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[Edge Computing Explained: What is a "Worker" and How to Deploy Your APIs for Free]]></title>
      <link>https://blog.codewithbotina.com/en/posts/edge-computing-explained-what-is-a-worker-and-how-to-deploy-your-apis-for-free</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/edge-computing-explained-what-is-a-worker-and-how-to-deploy-your-apis-for-free</guid>
      <pubDate>Mon, 09 Mar 2026 18:13:01 GMT</pubDate>
      <description><![CDATA[Edge Computing Explained: What is a "Worker" and How to Deploy Your APIs for Free Welcome back to Code With Botina. In our previous posts, we discussed APIs and the traditional Client-Server architect...]]></description>
      <enclosure url="https://cf-assets.www.cloudflare.com/slt3lc6tev37/6elch54Rkrp0HUB7UJNNLd/0dd12730b17615dc97513c618b164973/Improving_Developer_Experience_for_Framework_Users.png" type="image/jpeg"/>
      <content:encoded><![CDATA[# Edge Computing Explained: What is a "Worker" and How to Deploy Your APIs for Free

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). In our previous posts, we discussed APIs and the traditional Client-Server architecture. But the internet is evolving fast. What if I told you that you don't always need a traditional server running 24/7 to host your backend? 

Enter the era of **Serverless Edge Computing** and the star of the show: **The Worker**. 

Today, we are going to explore what a Worker is, why it is revolutionizing the way we deploy code, the most famous platforms to use them, and how you can launch your own API for completely free.

---

## What exactly is a "Worker"?

In traditional backend development, you rent a server (like an AWS EC2 instance or a DigitalOcean Droplet), install Node.js or Python, and keep it running constantly waiting for requests. 

A **Worker** (specifically an Edge Worker) is a small, lightweight piece of code that runs in the cloud *only* when an event triggers it (like an HTTP request). 

Instead of running on a single server in one specific location (e.g., Virginia, USA), your Worker code is copied and distributed across hundreds of data centers worldwide (the "Edge" of the network). When a user from Colombia makes a request, the code executes in a data center in Colombia. When a user in Japan makes the same request, it executes in Japan.

### How is it so fast? (V8 Isolates)
Traditional servers or Docker containers take time to start up (known as "cold starts"). Workers bypass this by using **V8 Isolates**—the same engine that Google Chrome uses to run JavaScript. Instead of booting up an entire operating system, a Worker just spins up a tiny execution environment in milliseconds.

---

## Famous Platforms to Run Workers

Several tech giants are leading the Serverless Edge revolution:

1. **Cloudflare Workers:** The absolute king of the space. They have servers in over 300 cities globally. Their platform is incredibly fast and developer-friendly.
2. **Vercel Edge Functions:** Built on top of Cloudflare's infrastructure but heavily optimized for modern frameworks like Next.js and Nuxt.
3. **Deno Deploy:** Created by the original creator of Node.js. It runs TypeScript natively and is extremely fast.
4. **AWS Lambda@Edge:** Amazon's solution. It is powerful but notoriously complex to configure compared to the others.

---

## How to use them for FREE (With Code Example)

Let's build a simple API using **Cloudflare Workers**. They offer a ridiculous free tier: **100,000 requests per day, completely free.**

Here is how simple the code looks. You don't need Express.js, you don't need routing libraries. You just need standard JavaScript:

```javascript
// index.js - A simple Cloudflare Worker
export default {
  async fetch(request, env, ctx) {
    // 1. Check the request URL
    const url = new URL(request.url);

    // 2. Create a simple API route
    if (url.pathname === "/api/hello") {
      const data = {
        message: "Hello from the Edge!",
        timestamp: new Date().toISOString(),
        blog: "Code With Botina"
      };

      // 3. Return a JSON response
      return new Response(JSON.stringify(data), {
        headers: { "Content-Type": "application/json" },
        status: 200
      });
    }

    // 4. Fallback for other routes
    return new Response("Not Found", { status: 404 });
  },
};

```

**How to deploy it:**

1. Install their CLI tool: `npm install -g wrangler`
2. Login to your free account: `wrangler login`
3. Deploy your code to the world: `wrangler deploy`

In less than 5 seconds, your API will be live globally. No server maintenance, no Linux configuration, no scaling worries.

---

## Conclusion

Workers are changing the game. They force us to write leaner, faster, and more efficient code. While they aren't perfect for every single use case (heavy, long-running background tasks still need traditional servers), they are the ultimate tool for modern APIs, microservices, and webhooks.

Have you ever deployed a project using Serverless architecture? Let's discuss it in the comments below!

---

*Keep scaling your knowledge with [Code With Botina](https://blog.codewithbotina.com/). See you in the next post!*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[The Digital Glue of 2026: What is an API, Protocols, and Why They Rule the World]]></title>
      <link>https://blog.codewithbotina.com/en/posts/the-digital-glue-of-2026-what-is-an-api-protocols-and-why-they-rule-the-world</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/the-digital-glue-of-2026-what-is-an-api-protocols-and-why-they-rule-the-world</guid>
      <pubDate>Sun, 08 Mar 2026 21:47:03 GMT</pubDate>
      <description><![CDATA[The Digital Glue of 2026: What is an API, Protocols, and Why They Rule the World Welcome back to Code With Botina. If you've been following our posts about client-server architecture, you already know...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/el-pegamento-digital-del-2026-que-es-una-api-protocolos-y-por-que-dominan-el-mundo-1773005979872.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# The Digital Glue of 2026: What is an API, Protocols, and Why They Rule the World

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). If you've been following our posts about client-server architecture, you already know that the internet is a massive conversation between different machines. But how exactly do these machines understand each other? The answer is simple: **APIs**.

Today, we are going to break down what an API is, the types that exist, how they communicate, and why in 2026, you simply cannot build modern software without them.

---

## What is an API?

API stands for **Application Programming Interface**. 

Imagine you are sitting at a restaurant. You (the client) want to order food from the kitchen (the server). However, you can't just walk into the kitchen and cook it yourself. You need a waiter. You tell the waiter your order, the waiter takes it to the kitchen, and then brings your food back to your table. 

In the digital world, **the API is the waiter**. It is a set of rules and mechanisms that allows one software application to talk to another. 

**Real-world example:** When you use an app like Uber, the app doesn't have its own mapping system. Instead, it uses an API to talk to Google Maps, asking: *"Hey, show the map for these coordinates,"* and Google Maps returns the image to your screen.

---

## Types of APIs (By Access)

Not all APIs are open to everyone. Depending on who can use them, they are divided into three main categories:

1. **Private (Internal) APIs:** Used exclusively within a company to connect their own internal microservices. For example, a company's HR system talking to their payroll system.
2. **Partner APIs:** Shared only with specific business partners. You need a special license or agreement to access them.
3. **Public (Open) APIs:** Available for any developer to use. Think of the X (Twitter) API, weather APIs, or the Stripe API for processing payments.

---

## How do they communicate? (Protocols and Architectures)

For two systems to talk, they need to agree on how to format the messages. Here are the most dominant architectures in 2026:

* **REST (Representational State Transfer):** The undisputed king of the web. It uses standard HTTP requests (GET, POST, PUT, DELETE) to manage data. It’s lightweight, stateless, and mostly uses JSON to send data. 
* **GraphQL:** Created by Facebook. Unlike REST, where the server decides what data to send, GraphQL allows the client to ask for *exactly* what it needs—nothing more, nothing less. It solves the problem of downloading too much unnecessary data.
* **gRPC:** Developed by Google. It is lightning-fast and uses a format called Protocol Buffers instead of JSON. It is heavily used in 2026 for internal microservices communication where speed is critical.
* **WebSockets:** We talked about this before! While REST is a one-time request, WebSockets keep a permanent two-way connection open, perfect for live chats or real-time trading dashboards.

---

## Why are APIs so critical in 2026?

You might wonder why we are talking about APIs right now. In 2026, the tech landscape has evolved, and APIs are the center of it all:

1. **The AI Integration Boom:** Every application now wants to include AI features. Developers aren't training massive language models from scratch; they simply connect to the APIs of models like Gemini or OpenAI to instantly add intelligence to their apps.
2. **The Microservices Standard:** Monolithic applications (where everything is a single block of code) are a thing of the past. Today, an app is a puzzle of 50 small services (authentication, database, UI) talking to each other constantly via APIs.
3. **The "Headless" Web:** Frontends (React, Vue) and Backends (Node, Python) are completely separated now. The only bridge between a beautiful user interface and the database is a robust API.

---

## Conclusion

APIs are the invisible threads holding the modern digital world together. Whether you are building a simple blog or a complex AI-driven platform, mastering API integration and design is a mandatory skill for any developer today.

What is your favorite API to play around with? Let's discuss it in the comments!

---
*Subscribe to [Code With Botina](https://blog.codewithbotina.com/) for more deep dives into software architecture and networking!*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[Stop Guessing, Start Testing: Why TDD (Test-Driven Development) Will Save Your Projects]]></title>
      <link>https://blog.codewithbotina.com/en/posts/title-stop-guessing-start-testing-why-tdd-test-driven-development-will-save-your-projects</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/title-stop-guessing-start-testing-why-tdd-test-driven-development-will-save-your-projects</guid>
      <pubDate>Sat, 07 Mar 2026 20:52:00 GMT</pubDate>
      <description><![CDATA[Stop Guessing, Start Testing: Why TDD (Test-Driven Development) Will Save Your Projects Welcome back to Code With Botina. Have you ever fixed a bug in your code, deployed it to production, and immedia...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/deja-de-adivinar-empieza-a-testear-por-que-el-tdd-desarrollo-guiado-por-pruebas-salvara-tus-proyectos-1772923728435.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[# Stop Guessing, Start Testing: Why TDD (Test-Driven Development) Will Save Your Projects

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). Have you ever fixed a bug in your code, deployed it to production, and immediately broken three other completely unrelated features? We've all been there. That sinking feeling of deploying on a Friday afternoon is a universal developer experience.

But what if I told you there is a methodology that practically eliminates that fear? Today, we are talking about **TDD (Test-Driven Development)**, what it is, and why you need to start applying it to your projects right now.

---

## What exactly is TDD?

TDD stands for Test-Driven Development. Unlike traditional programming where you write your code first and *maybe* write some tests later (if you have time), TDD flips the script. **You write the test before you write the code.**

It relies on a very short, strict, and highly effective cycle known as **Red-Green-Refactor**:

1. 🔴 **Red (Write a failing test):** You write a test for a feature that doesn't exist yet. Naturally, if you run it, it fails.
2. 🟢 **Green (Make it pass):** You write the minimum amount of code required—even if it's ugly—just to make that test turn green.
3. 🔵 **Refactor (Make it clean):** Now that the test is passing, you clean up your code, optimize it, and apply Clean Code principles, confident that if you break something, the test will catch it.

---

## Why will TDD change your life as a developer?

### 1. Fearless Refactoring
This is the biggest superpower TDD gives you. When you have a solid suite of tests, you can rewrite entire functions or upgrade libraries without the paralyzing fear of breaking the system. If the tests are green, you are good to go.

### 2. It Forces Better Architecture
Have you ever tried to write a test for a massive, 500-line function? It's impossible. TDD forces you to write small, modular, and decoupled code (following SOLID principles) because decoupled code is the only code that is easy to test.

### 3. Tests are Living Documentation
Comments get outdated; documentation gets lost. But tests? Tests run every day. If a new developer joins your team, they can just read the tests to understand exactly what a function is supposed to do and what edge cases it handles.

### 4. Less Debugging, More Coding
Yes, writing tests upfront takes extra time. But think about the hours (or days) you spend debugging spaghetti code in production. TDD catches bugs exactly when you write them, saving you countless hours in the long run.

---

## Conclusion

TDD isn't just a testing strategy; it's a **design strategy**. It shifts your mindset from "Let's code this and see if it works" to "What exactly does this need to do, and how will I prove it?"

If you haven't tried it yet, start small. Write one test for your next utility function. The peace of mind you'll get is addictive.

Do you use TDD in your current job, or is your team still doing manual testing? Let me know in the comments!

---
*Stay tuned to [Code With Botina](https://blog.codewithbotina.com/) for more insights on software architecture and clean code practices.*]]></content:encoded>
    </item>
    <item>
      <title><![CDATA[The High-Performance Training Dilemma: Education or Exploitation in the AI Era?]]></title>
      <link>https://blog.codewithbotina.com/en/posts/high-performance-vs-burnout-software-engineering-education</link>
      <guid isPermaLink="true">https://blog.codewithbotina.com/en/posts/high-performance-vs-burnout-software-engineering-education</guid>
      <pubDate>Fri, 06 Mar 2026 02:45:51 GMT</pubDate>
      <description><![CDATA[The High-Performance Training Dilemma: Education or Exploitation in the AI Era? Welcome back to Code With Botina. Today, we’re stepping away from technical tutorials to discuss a reality many software...]]></description>
      <enclosure url="https://fnxnsgtdbswvuqeuvgio.supabase.co/storage/v1/object/public/blog-images/la-trampa-de-la-universidad-bootcamp-por-que-instituciones-como-jala-necesitan-un-golpe-de-realidad-sobre-la-ia-y-el-burnout-1772909674469.webp" type="image/jpeg"/>
      <content:encoded><![CDATA[## The High-Performance Training Dilemma: Education or Exploitation in the AI Era?

Welcome back to [Code With Botina](https://blog.codewithbotina.com/). Today, we’re stepping away from technical tutorials to discuss a reality many software engineering students are currently facing: the thin line between **high-performance academia** and **academic burnout**.

### The Illusion of "Extreme Rigor"

There is a growing trend in tech institutions to adopt a constant "bootcamp" mentality. The promise is enticing: "We prepare you for the real world with unprecedented intensity." However, in practice, we sometimes mistake **academic demand** for **operational saturation**.

When the volume of mechanical and repetitive tasks—such as manually writing thousands of lines of boilerplate code—exceeds the physical time available for architectural analysis or deep logic, we stop forming engineers and start training code operators. An engineer is not defined by how many hours they can go without sleep, but by the quality and scalability of their solutions.

### The Artificial Intelligence Gap

We are at a turning point. Many institutions maintain restrictive policies toward AI, arguing that they are protecting "authentic learning." It is a noble intention, but it crashes against two unavoidable realities:

1. **The Workload:** You cannot demand industry-level output while banning the very tools the industry uses to achieve that speed. It’s like asking an architect to design a skyscraper in a week while forbidding the use of CAD software.
2. **Market Reality:** In the professional world, efficiency is key. AI doesn't replace the engineer, but it empowers the one who knows how to use it with professional judgment. Modern education should focus on how to audit, refactor, and validate AI-generated code, not on pretending it doesn't exist.

### Quality vs. Quantity

Clean Code, SOLID principles, and design patterns are the first things to die when a student is in "survival mode" just to submit a project before 11:59 PM. If we only write code "to make it work" and pass a module, we are sacrificing technical excellence for simple compliance with volume metrics.

**What kind of professionals do we want to be?** Those who understand the "why" behind every technical decision, or those who simply survive a week of artificial crunch culture.

---

### A Message to My Community (and a Final Reflection)

To my fellow students who feel exhausted today: your concerns are valid. However, I have also learned that in our career, **prudence** is a tool just as important as code.

Being a professional means knowing when and how to raise your voice. This isn't about attacking the institutions that train us—to whom we are grateful for the opportunities and the space—but about fostering a constructive dialogue that allows us all to improve. **Staying silent is not an option when something isn't working, but speaking with respect and strategy is what truly drives change.**

Let’s learn to be prudent to protect our path, but let’s never stop being critical to improve our industry.]]></content:encoded>
    </item>
  </channel>
</rss>