Forem: Juanda Martínez

I built the ultimate Pokédex and would love you to try it!

Juanda Martínez — Fri, 05 Sep 2025 21:10:59 +0000

Four years ago, while playing Pokémon, I realized that I could memorize a lot of stuff like my SSN or my EIN... but not the Pokémon type chart. Every match, I had to pause, open a wiki, search weaknesses, check evolution chains, among all crappy useless information that only made me waste more time scrolling down to the exact info I wanted.

So as a web dev, I decided that I could build my own tools for my personal use, so why not create a web app that solve this issue for me? having this kind of information I cared about in a single place, without wasting too much effort on Googling a Pokémon → Open a wiki link → Scroll up/down many times → Find the info I wanted → Click more links bc I needed more info → Repeat

And that's how Pokémon Stats was born: a small MVP using PokéAPI + Bootstrap, quickly fetching Pokémon's evolution chains, evolution details, a type chart, and a basic search bar to enter the Pokémon name. Nothing fancy if you ask me, and made for casual players (just like me).

So I bought a domain and hosted the site directly with Vercel, because I wanted to feel this like a sophisticated web app, and from that I just've been pushing small updates with stuff that I wanted to improve in the user experience while playing Pokémon games.

Fast-forward to today: I’ve completely redesigned the project from the ground up. Same idea, but cleaner, faster, and built with the stack I actually enjoy using: Next.js, React, Tailwind, shadcn/ui).

What changed?

A redesigned type effectiveness chart (interactive, mobile-friendly).
A search system with suggestions and keyboard navigation.
Improved evolution chains, including special cases (stones, time of day, trades, etc.).
Support for regional forms and variants (Alola, Galar, etc.).
High-quality official artwork with fallback sprites.
A roadmap and contributors page, because now it’s open source!

Why it matters to me

This project isn’t the most complex I’ve ever built, but it’s the one I’ve loved the most. It started as a personal tool, grew through trial and error, and turned into something I still actively use while playing. I’ve put a lot of effort (and coffee) into making it not just functional but actually enjoyable to look at and use.

It’s free, it’s open, and if you’re a Pokémon fan (or just like checking out passion projects), I’d love for you to try it: pokemonstats.com

You can also peek at the source, file an issue, or even contribute: GitHub - juandadev/pokemonstats

📬 My First Waitlist: Lessons From a Side Project Experiment

Juanda Martínez — Fri, 25 Jul 2025 00:59:17 +0000

Not gonna lie, creating a waitlist for my side project wasn’t strictly necessary, but it was fun, insightful, and a great excuse to learn something new.

This post isn’t about building a revolutionary app (not yet). It’s about using your side projects as a sandbox to experiment, explore, and grow.

How It All Started

Lately, I’ve been quite active on X/Twitter. I follow a lot of indie devs who build amazing projects and share everything publicly, what we now call building in public. I’ve always wanted to do the same, so I even bought the blue checkmark to commit to this journey.

One trend I kept seeing was the use of waitlists, where users can leave their email to get notified when a product launches. It's like a teaser trailer for a movie or the release announcement of a huge videogame like GTA VI, it builds hype.

Two stories really inspired me:

Athas.dev, an open source code editor that even caught the attention of the one and only Guillermo Rauch, CEO of Vercel.
Maze, who built an open source CapCut alternative. His waitlist blew up to over 500k signups (including a massive bot attack!).

So, What Did I Do?

Even though I’m not working on a fancy SaaS or groundbreaking tool for devs, I decided to make a waitlist for an app I started 4 years ago: Pokémon Stats, a simple tool to check Pokémon evolutions and type weaknesses. I originally made it for myself to avoid bouncing around wikis while playing.

Every time I picked up a new Pokémon game, I’d tweak the app and add improvements. This time, as I returned to my dusty Pokémon Let’s Go save file, I set myself the challenge of:

Redesigning the app from scratch.
Temporarily shutting down the old version and replacing it with a landing page + waitlist.
Using this commitment to learn new things and hold myself accountable (even if just two people sign up, I can’t let them down!).

Now the Fun Part, How I Protected the Waitlist

I didn’t want just another form. I learned from others' mistakes and added real protections against spam and bots. Here's a quick breakdown:

1. CSRF Token Protection

I generate a unique CSRF token server-side, only if the request comes from an authorized host.
The token is signed using a secret key stored in an environment variable.
It’s saved in a cookie and expires after 1 hour.
Every POST request must include and validate this token. If it’s missing or invalid, the server throws an error.

2. Bot Detection with Vercel BotID

Works like an invisible reCaptcha.
Analyzes user interaction to determine if it’s a bot, validated both on the frontend and backend.

Would love to say I understand how BotID works under the hood, but honestly… I just followed the docs. Might write a deep-dive post in the future once I get it.

3. (Missing) Rate Limiter

Didn’t implement it... yet. But it’s something I’d like to explore, even if I don’t expect much traffic. It’s all part of the learning process.

Final Thoughts

Was it necessary? Nope.

Did I learn something? Absolutely.

Was it fun? Totally.

Your side projects don’t need to change the world. They just need to teach you something new.

So if you’re into Pokémon, feel free to join the waitlist, star the repo, or check out the code (yep, it’s open source). I’d love to hear your thoughts and feedback!

Building pagination with Prisma felt… unnecessarily complex

Juanda Martínez — Thu, 19 Jun 2025 15:49:00 +0000

This is a translated version of the original post published in my Spanish blog. The translation was generated using ChatGPT and manually reviewed for clarity and accuracy.

Recently, I decided to revisit my fullstack side and start building small projects again — each one with increasing technical complexity. Motivated by development speed and convenience (and because I really wanted to get my self-hosted blog launched ASAP), I asked chatGPT for some tech stack suggestions. I went ahead with Prisma, a very popular ORM for working with databases in JavaScript.

Everything was going pretty well… until it was time to implement a very basic feature: result pagination.

I didn’t have much time to dedicate to that feature at that moment, so I went into vibe coder mode and asked chatGPT for help. It generated a query using Prisma that included some properties I wasn’t familiar with, and the code looked a bit suspicious. So, I did what I always do — I checked the official docs to verify everything and to see how to properly get the total record count.

To my surprise, I discovered something unexpected: Prisma doesn’t have a built-in method to return both the data and the total count in a single query!

Yes, you read that right. If you want to paginate and also show the total number of records, you have to run two separate queries — one to get the paginated results and another to count the total number of items. Something like this:

const data = await prisma.model.findMany();
const count = await prisma.model.count();

Now imagine the mess this becomes when you start adding filters, joins, and other conditions... it's a nightmare!

This really caught my attention — especially coming from frontend development, where we're always thinking about performance and keeping things snappy for the user. I dug a little deeper and found this issue, where people have been asking for a findManyAndCount feature.

For a second I felt that nostalgic happiness from the old days of googling your errors and landing on a StackOverflow thread where someone had the exact same problem... but that joy quickly faded when I saw the issue was still marked as Open 😣 — and even worse, it’s been open since 2021 💀

Reading through the comments, I realized I wasn’t alone. Many users with larger systems and more complex pagination needs were also frustrated. Some of the workarounds mentioned include using prisma.$transaction, which is better organized but executes sequentially and is slower (especially with big datasets):

const [data, count] = await prisma.$transaction([
  prisma.model.findMany(),
  prisma.model.count(),
]);

A faster alternative would be using Promise.all to execute both queries in parallel:

const [data, count] = await Promise.all([
  prisma.model.findMany(),
  prisma.model.count(),
]);

However, someone pointed out an important detail in the issue thread: while those approaches work for simple use cases, there’s a data consistency risk. What if an INSERT or DELETE happens between those two queries? You could end up with mismatched results:

- Total count = 5
- Returned elements = 4

That reminded me of something I read a while ago: no matter how friendly an ORM is, it will never fully replace raw SQL — especially when you need full control and optimization. (Unfortunately, I couldn’t find the tweet again, but that idea stuck with me.)

This whole experience also got me wondering: have Prisma and similar tools actually become more popular lately, or is this just the classic illusion where once you start using something, you start seeing it everywhere? Kind of like when you buy a car and suddenly that same model is on every street corner. Funny how that works.

In the end, this doesn't affect me too much for my current use case since I’m just paginating a small dataset for my blog. But it definitely made me think more carefully about the tools I choose — and how even seemingly basic features should never be taken for granted.

💭 This reminded me of a similar story: a while ago, we had to pick a tool for unit testing on the frontend. I pushed for React Testing Library because I was more familiar with it, but for various reasons, we ended up using Cypress.

The project involved heavy use of iframes... and turns out, Cypress has no elegant way of handling those in tests. And guess what? I found this issue dating back to 2016, filled with people also disappointed to find out how hard it is to test iframes.

That was the first time I learned the importance of checking tool limitations. Prisma’s pagination problem is officially my second reminder. So I'm obliged not to make the same mistake a third time!

So, I’d really love open a discussion and hear from others:

Have you experienced something similar with Prisma or any other ORM? Do you think raw SQL is still necessary for cases like this? How do you evaluate tradeoffs when choosing your stack?

Drop your thoughts in the comments — these small (but critical) engineering decisions deserve more discussion.

⚛️ When React Context API Turns Against You: A Late-Night Debugging Story

Juanda Martínez — Fri, 06 Jun 2025 23:31:00 +0000

This is a translated version of the original post published in my Spanish blog. The translation was generated using ChatGPT and manually reviewed for clarity and accuracy.

It was 2:41 AM. Procrastination had sneaked into my sprint without warning, and suddenly, the night before the deadline, I found myself buried under a mountain of work. The reason? A massive refactor that, to be honest, no one asked for.

Just like the meme, I had big dreams of refactoring the component I’ve been working on. The opportunity came when someone on my team proposed building a "Generic Framework" to speed up the integration of third-party tools (I can’t share details, but it’s probably been the most ambitious project of my career). So, I jumped at the chance and proposed several long-overdue refactor tickets.

What I didn’t realize was that I was setting a trap for myself… Yes, these refactors solved real problems, but they also included extra steps to fix the messy techniques I used back when I joined the company and was a bit more inexperienced. I was also finally tackling a lot of the technical debt that only I knew existed 😅. Still, I’ve learned a lot and feel like I leveled up, so I wanted to document the experience.

At that moment, I was hating my life, struggling to stay awake, and also struggling with React’s Context API. I had created multiple contexts, nested Providers like there was no tomorrow, and packed complex logic into reducers. Everything looked clean, sure, but that infamous ✨gut feeling✨ kicked in: something wasn’t right.

Am I abusing context? I asked myself. Do I really need to have almost **everything* in global state?*

Half-asleep and in need of external validation, I turned to AI instead of Reddit (time crunch). Spoiler: yes, it’s a problem in most cases. As it turns out, no surprise here: any component that consumes a specific context will re-render—even if it doesn’t directly use the value that changed. I had forgotten all about that. I was just trying to avoid prop-drilling at all costs, but overusing any technique will always come with side effects.

So to back up my suspicion, I needed visual proof. I knew what the outcome would be, but still—always question everything, even your own assumptions. Like any seasoned dev, I debugged the re-renders with a trusty console.log.

Yep, it’s React 🚬⚛️

Here’s the deal: my component manages a list of items, renders them in different sections, and sometimes accesses them individually. That’s why I used context. The issue started when I decided that the form state used to add new items should also live in global state… out of laziness and simplicity.

So I put those values in the same context. Big mistake. Every time onChange fired to update the form state, it triggered a re-render of the component that only renders the list — completely unnecessary.

💡 Why not use form libraries or state helpers?

This component is meant to be shared across multiple apps in our org, so our top priority is to keep it lightweight and minimize dependencies. Using a library is a heavier decision I don’t have control over — and, well, you know what they say: "give the client what they want."

You could say it’s just part of working with React. One of the reasons it gets hate is because of how hard it is to avoid unnecessary re-renders (and the endless “Angular vs. Vue vs. React” debates, blah blah). Maybe they’re right. What I’ve learned is that those unnecessary re-renders aren’t always a problem—until they are. That’s when experience and instinct help you decide: let it slide, or prevent a bigger performance issue down the road.

Unfortunately, I didn’t have the energy to restructure everything. The sprint ended the next day, and I had promised my manager there wouldn’t be any carry-over. Maybe I didn’t need a full restructure either. So my short-term fix was to split the context into smaller, more specific ones. Turns out my mistake was cramming too many properties into a single context for convenience.

Lessons Learned

I always wondered why people use external libraries for global state management when React already has the Context API. But now I get it. Even in seemingly “simple” scenarios, popular libraries like Zustand might help solve these performance issues with a much cleaner and lighter API.

🤯 This kind of realization is exciting.

That’s why this meme hits harder now. I’m pretty sure I’ll use the Context API again in the future… or maybe I’ll ditch React entirely. Who knows?

So, my next steps? I want to explore state libraries like Zustand, and revisit other design patterns too — like Observer — that might better fit some of my use cases (or maybe they’re the same thing and I just don’t know it yet).

In any case, today I almost became the villain of my own refactor. It would’ve been easy to leave things as they were… but I’m glad I caught it in time and shipped something cleaner.

😵‍💫 Server Components in Next.js 15: What I got wrong (and right)

Juanda Martínez — Tue, 27 May 2025 18:23:53 +0000

This is a translated version of the original post published in my Spanish blog. The translation was generated using ChatGPT and manually reviewed for clarity and accuracy.

When I set out to build my personal blog with Next.js 15, I was excited to finally take advantage of the famous ✨ Server Components ✨. I had never really given them a proper try before, and I thought, “This is the future.” What I didn’t know is that I was about to step into a world of bugs, broken builds, missing sessions, and documentation that was… confusing?

This post isn’t a tutorial — it's more of a story about how not to lose your mind when things don’t go as expected with Server Components, and how (unsurprisingly) AI can be overly agreeable unless you steer it toward the actual solution. Spoiler: I ended up learning more than I thought.

The first problem: the fetch that never came

It all started when my homepage, where I wanted to show the latest five blog entries, just… didn’t render anything. For context, I was using Next.js API routes with the App Router to handle the "backend" side of things.

The homepage is a server component generated statically at build time. It tries to fetch the latest posts via an internal API… but when I deployed it to Vercel, the build logs threw this error:

❌ Internal Server Error

Error: Internal server error
    at a (.next/server/app/page.js:1:5127)
    at async p (.next/server/app/page.js:1:3031)

The build didn’t fail entirely, but the log was concerning. When I checked the live site, the list of posts was completely empty.

I thought this project would be "simple", but here I was — asking ChatGPT, then Grok because ✨ free tier ✨, taking a coffee-break ☕️ when I finally remembered that I do have a brain, and that back in the day we used Google and StackOverflow to solve things. Then came the eureka moment:

How can I expect a static page to fetch posts from an API that **isn’t running yet?

It made total sense. Locally, the Node server is always running, so API routes are available. But during a deploy, when npm run build executes, there’s no server running yet — there’s nothing to fetch from.

The solution: I had to query the database directly from the Server Component. It feels like I’m breaking an abstraction, but it worked.

Session confusion

On another page, I needed to fetch an individual post. In this case, fetching from the internal API worked fine — it was also a Server Component, but the key difference is that this route is dynamic. It fetches data when someone visits the post. The server handles the query and sends back the full page. So far, so good.

The issue came when I needed to validate some logic based on the user's session. I kept trying different approaches, but the session inside the API routes always came as null.

And again… failed attempts asking an AI to solve my life. Something I could’ve solved if I had just read the official docs 😅

Still, I kept trying with Grok, trying to guide it toward the right idea. Here’s the prompt I used (don’t judge my broken English — I promise that I can do better, but since this thing is smarter than me, I don't bother to correct my grammatical issues 🤣):

it didn't work, still coming as null, but doesn't this have to do that I am using an internal API route to fetch a post, but this post is being fetched in a server component. I just tried to get the session data in the fetch itself and not inside my API routes and it worked

I know what you're thinking—I should’ve told the AI all of this context from the start. But in my experience, if you throw too much info at once, it ignores half of it and replies with whatever it wants anyway...

The solution: When doing fetch from a Server Component, the browser’s cookies 🍪 are not sent automatically. And without cookies, there’s no session. You have to pass them manually—and thankfully, Next.js has the tools to do just that.

Note: This depends on the type of authentication your app uses. I use JWT (JSON Web Token) along with NextAuth.js, which stores session data in cookies.

import { cookies } from "next/headers";

const cookieStore = cookies();
const cookieString = cookieStore
  .getAll()
  .map((cookie) => `${cookie.name}=${cookie.value}`)
  .join("; ");

const response = await fetch(`http://localhost:3000/api/post/${params.id}`, {
  headers: {
    Cookie: cookieString,
  },
});

⚠️ Docs - 1 | AI - 0

Since I'm apparently becoming a pseudo "vibe coder", let me highlight this moment where AI didn’t give the best answer.

In Grok’s response, it built a cookie string using .map and .join, which works. But if you look at the official Next.js docs, you’ll see the cookies() method already has a built-in .toString() that does this for you. So yeah... always double check 👁️

So… what did I learn?

Server Components are great, but full of gotchas. You need to understand where and how your code runs.
Fetching your own API vs. querying the DB directly from Server Components is a nuanced decision. Context matters.
Cookies aren't sent automatically with server-side fetch. If you need session data, pass cookies manually.
Don't blindly rely on AI. Sometimes the old-school way (reading docs) saves you hours.

Things I could improve

It still feels a bit off to query the DB directly from a Server Component. If you also feel that ✨ itch thing ✨ when something seems wrong… trust it.

Every time I’ve ignored that gut feeling, I get code reviews or manager feedback pointing out exactly what I already suspected. I’m working on that — and this is a great chance to put it into practice.

💬 I was looking through my Twitter bookmarks and found this tweet from @asidorenko_ explaining why you should separate your DB calls. I knew I’d read that somewhere.

Pro tip: when it comes to frontend, anything can be exposed—so be careful.

Uncle Juan's final thoughts

I remember when Server Components first showed up, the very nice and not-at-all toxic Twitter / X community was comparing them to old-school PHP, calling it a step backwards.

Personally (as with most tech trends), I didn’t jump on the hype train right away. I resisted Tailwind, daily AI use, search engine replacements, and Server Components (yep—my old Next.js projects always started with use client at the top). But eventually, I gave in. I tried them. And I liked them.

My point is: trying new things expands your understanding and helps you face real challenges. It's a good practice to reflect on the why behind what you're doing. Push yourself — try applying a design pattern or avoid using libraries for everything.

I once read (maybe on Reddit or Twitter) that a common question is: “When should I use use client?” The answer was simple: use server components by default, and only move the interactive parts to client components when absolutely necessary — even if it feels silly.

That advice stuck with me. And building my blog from scratch gave me the chance to follow it. It helped me write better component compositions (funny enough, there’s a React pattern called Composition that aligns perfectly with this approach). If I had just slapped use client everywhere, I wouldn’t have run into these issues — or learned from them.

That’s why experience matters when companies hire. It’s not just about knowing the concepts — it’s about the challenges you’ve faced and how you solved them. And that only comes from working on real-world projects that go beyond a JS calculator or a basic React to-do list.

💬 While writing this post, I found another tweet by @asidorenko_ explaining how to separate the interactive part into a new component. I swear I’m not sponsored by him — go follow him if you're into Next.js content.

Also, look into the Composition pattern. Now that you've made it this far, you know it exists. You’ve probably already used it without realizing it. Being aware of it, studying it, and applying it consciously will score you points in interviews. 😉

At the end of the day, this post is more of a war diary than a tutorial. But if I helped you save even a couple of hours of debugging, then it was all worth it.

Have you also wrestled with Server Components? Let me know—I’d love to hear your experience 😅

Suggestions and corrections are welcome—I'm far from perfect, but I’m not afraid to be transparent and show my thought process when tackling problems.

Level Up Your Object Oriented Programming Knowledge with Nintendo Switch 🎮👾

Juanda Martínez — Wed, 18 Oct 2023 03:55:48 +0000

Imagine for a moment that Object Oriented Programming (OOP) is like the inner workings of your favorite gaming console, the Nintendo Switch. Just as the Switch combines different components to bring your favorite games to life, OOP unites data and functions to create efficient and organized code. In this article, we'll embark on a journey to explore the four fundamental principles of OOP through the lens of the Nintendo Switch, will try my best to teach you this powerful programming paradigm with examples that are as enjoyable as a game of the great N. Get ready to level up your coding skills and game on as we unlock the secrets of OOP with the Nintendo Switch as our guide.

OOP relies on two major concepts: Classes and Objects. These concepts can be applied in code to enable us to build applications. Object Oriented Programming was created to guide the creation of better software, by achieving easier maintenance and reusability.

DISCLAIMER: The following examples are just an attempt to explain my point, there may be inconsistencies according to reality

CLASSES AND OBJECTS

Let's say that we want to create a brand new console, shall we? :) It comes in many colors, we have the ability to play videogames anywhere, it has a battery life of 6 hours that drains every time you play a game, and you can install many games on its internal storage! We decided to name it ✨Nintendo Switch✨

If we translate this in code, we can create a Class named NintendoSwitch and we list the principal attributes and its methods, think of a class as it were a template or blueprint that will specify how the console looks and the way it's going to perform some actions (I would like to explain this class/object stuff with Typescript first):

class NintendoSwitch {
  private color: string;
  private screenSize: number = 5.5;
  private storageCapacity: number = 8;
  private batteryLife: number = 6;
  private gamesInstalled: string[];

  constructor(color: string, gamesInstalled: string[]) {
    this.color = color;
    this.gamesInstalled = gamesInstalled;
  }

  playGame(game: string): void {/.code logic./}

  installGame(game: string): void {/.code logic./}

  checkBatteryLife(): void {/.code logic./}
}

Here we have the principal attributes like color, screenSize, storageCapacity, batteryLife, gamesInstalled. Then we have the constructor, a function that serves to initialize the attribute's values when we create an instance of NintendoSwitch class.

Note that our class already has storageCapacity, batteryLife, and screenSize initialized, because it will be the same for all the new instances instead of color and gamesInstalled, those can be set at the moment we create the instance of the current class.

An Instance is equal to an Object, we create as many objects as we want from a Class, in most languages we use the new keyword in order to create a new object, every object can be different one from another, because we can have many NintendoSwitch objects with different colors and different games installed!

In this case, none of our instances have games to play with :( but the good part is that you can now understand what Classes and Objects are, so let's move on!

In order to achieve mastery, we need to understand the ✨four principles of Object Oriented Programming✨ starting with the first one:

📦 ENCAPSULATION

Is the need to separate your code in independent pieces for a single purpose, think of it like a box 📦 that holds data (properties, attributes) and the things that can be done with that data (methods, functions). This way, you can ensure that your data is safe and it's used correctly.

This principle can define the reason for having classes, we encapsulate a set of attributes and the things we can perform with those attributes as methods, with the purpose of hiding the internal process and just showing what matters to the public, it's up to us if we want to set some attributes or methods as public, or keep it private just for internal use.

If you want to explain this in a more technical way:

Encapsulation is a way to restrict the direct access to some components of an object, so users cannot access state values for all of the variables of a particular object. Encapsulation can be used to hide both data members and data functions or methods associated with an instantiated class or object.

INHERITANCE

Is the idea that you can inherit perks and abilities from your parents 👨‍👩‍👦, like eye color or hair type.

Let's go back to the Nintendo Switch; Now we want to create a new console by taking all the things inside of the Nintendo Switch but with additional features. If we talk in terms of coding, maybe some newbie developer may think of copying and pasting the Nintendo Switch class and creating a new one to add the desired new features... easy, right? But what if I told you that instead of re-write the code again, we can create our new model from what we already have 😱 Yes! you heard it right! we can extend from the Nintendo Switch class and then create the Nintendo Switch Pro class without copying all the code from scratch, we will have all the features of the original Nintendo Switch, and then we can just add the new code for the features! on this new model, we want detachable controllers and also the ability to connect the Nintendo Switch to a dock and be able to play on a TV! how awesome is that?

So we proceed to create our new class for the Nintendo Switch Pro, extending from NintendoSwitch class, like this:

class NintendoSwitchPro extends NintendoSwitch {  
  constructor(props) {
    this.super(props);
  }

  detachJoycons() {/../}

  connectToTV() {/../}
}

We can see that its composition it's similar, but now we can detach the controllers (detachJoycons) to play with them wireless, and we can also connect it to the TV! (connectToTV)

Maybe this is a vague example but in the big picture this is ✨inheritance✨ we take the NintendoSwitch class, and extend this in a new class NintendoSwitchPro that inherits all the NintendoSwitch attributes and methods, and additionally we have two more methods that can do new things!

This approach makes things more organized and saves you from doing the same things over and over again.

POLYMORPHISM

Polymorphism means many shapes, in OOP we can modify the properties and methods that we inherited to have different behavior in a way that makes sense for each class. This makes our code flexible and easy to adapt to many use cases.

Going back to our previous example, our first class, Nintendo Switch, as we know has a little screen of 5.5in, its size makes you able to even fit in your pocket and the battery lasts 6 hours of continuous play! But then when we created the Nintendo Switch Pro, and decided that this new model would have a screen of 7in, bigger than his parent!! and Thus we have a larger size of the whole console that can barely fit in your jeans pocket, we increment the battery life up to 10 hours of continuous play, and the rest remains the same, so now our new class will end like this:

class NintendoSwitchPro extends NintendoSwitch {
  private screenSize: number = 7;
  private batteryLife: number = 10;

  constructor(props) {
    this.super(props);
  }

  detachJoycons() {/../}

  connectToTV(game: string) {/../}
}

super() is another keyword that most languages adopt to refer to the super class or parent class, in the case above, we are using the same exact constructor of the parent class because we don't need to add anything new to it.

As you can see, we set a couple of attributes that are named the same as some of the parent models but modified their values to fit the new necessity. This is called Overriding and it is a valid practice, even with methods! is like taking the inherited abilities and leveraging them with superpowers 💪🏻

ABSTRACTION

Abstraction means simplifying complex things by breaking them into smaller and more manageable parts. Think of it like driving a car 🚗 we don't need to know all the technical details of how the engine works, we just need to understand how the basic controls like the steering wheel, gas pedal, and breaks work. With that being said, our methods contained in the NintendoSwitch class can tell us WHAT it does, without caring much about HOW it does.

For example, the method checkBatteryLife() can tell us what it does just by its own name! but internally works like this:

// NintendoSwitch class file
checkBatteryLife(): void {
  console.log(`This Nintendo Switch has ${this.batteryLife} hours of battery life remaining.`);
}

//Our main script
const myFirstSwitch = new NintendoSwitch('Blue', []);

myFirstSwitch.checkBatteryLife(); // Console output: This Nintendo Switch has 6 hours of battery life remaining.

As you can see, the batteryLife attribute on its own doesn't say much about it, it's just 6, but 6 what?? then checkBatteryLife() gives us more context, and the result is that the logged message in the console specifying that the battery life attribute is meant to be the hours left of battery life!

Sometimes we can find getters and setters functions inside classes, we won't focus on these things right now, but think of them as functions that help us to set/modify the value of an object's attribute (setters), and functions to read those values (getters). At first sight, this may seem useless, but sometimes this can keep our attributes safer, like by adding a validation layer, so no one can set a null-ish value that can break our app, or set that abstraction layer like in the example above to give a meaning to our attributes values.

In OOP we can hide complicated pieces of code and provide a simple interface, so we can focus on what our code does rather than how it does it, this makes our code easier to understand and maintain.

And that's all, folks!

I hope that you can understand better the OOP principles with these examples :) Let me know in the comments your thoughts, this is an important topic in software development, and can even get you an opportunity to get a job in a big tech company! they often opt for developers with this kind of general knowledge instead of looking for someone with a specific language, because if you know all of this stuff you are more likely to adapt to any technology.

This is the first of a three-part series that I'm about to write, because I want you to understand from my perspective, how OOP, Javascript Prototypes, and SOLID principles can be related ✨

Should You Lower Your Possibilities When Looking For a Job?

Juanda Martínez — Thu, 05 Oct 2023 20:59:54 +0000

Photo by Andrew George on Unsplash

These past days I decided to focus my energies on doing some research and studying for a position I really wanted to be part of as a Node.js developer (Back-end). As some of you would already know, my expertise lies in Frontend development, especially with React, Redux, and Graphql, or at least that's what I thought at the beginning...

I was afraid to apply for full-stack or back-end positions, I thought that I couldn't perform well in these areas because of my professional experience, but after some time of self-retrospective, I just realized that I always have been a full-stack developer without knowing it. The thing is that although in my last job I was given the title of Web UI developer, to be honest, I feel the industry always leans towards full-stack somehow, and in my last project we managed a Node.js server with Apollo server to extend the usability of GraphQL in our front-end with React, and it was something of our daily tasks to code in both repos after all. So that's it!! I already know Node.js so I can say that I have experience in the field, right?

Discover your hidden abilities!

After realizing this, it was an eureka moment for me! How can you be biased about your capabilities just because of the title some company gives to you? This also includes the seniority of course.

I started to detect those back-end skills and gain more confidence about it. Tried to analyze what and how do we managed in that Node.js repo. We were in charge of the API layer by collecting all the external APIs the Java team brought to us, like an API for users, another one for bag items, and so on, then we made the proper functions and logic to use that data and transform it to be consumable by our front-end project.

Does that sound familiar to you? Of course it is, because without knowing we were interacting every day in a MICROSERVICES ARCHITECTURE, I know it doesn't sound like a big deal, but for me it was like founding the one piece 💰

Why I'm so sure about this? well, after some research about microservices, a lot of things started to make sense to me, we had a Java team that created separate projects for each service, and those services were split by the business needs, being the case of an e-commerce. Then the DevOps team is in charge of all the infrastructure layer, to finally us getting all of those APIs to be consumed on a single Node.js server with Apollo.

Then I asked ChatGPT to give me some topics to study for a back-end position with Node.js, microservices being one of them, followed by understanding HTTP protocol and other stuff, stuff that I already knew and it was just a matter of time to research, and remember all of those things!

DON'T close yourself to the possibilities!

The point of all of this is to make you rethink your skill set and be able to know what you are capable of! don't close yourself just because someone told you that you're just a frontend or backend dev, junior or senior!

You always work with data structures, so do your research about it! get to know how you interact with those and search for examples, I'm sure you've been working with a lot of these, and even you can start thinking about your further solutions by applying data structures specifically.
Learn about algorithms! it is a topic you probably applied in some of the techniques in your daily problem-solving process. You will start to know about the complexity of a piece of code or function and you will start to think differently, seek how to improve performance, and solve memory leaks in your apps!

So, the sooner you start to discover your hidden skills, the sooner you can start to open your range of possibilities when looking for a job!

I stopped saying that I'm just a front-end developer, I know that I can perform well in a back-end position with Node.js, and I know that I can also apply for full-stack and backend positions without hesitation. So what are you waiting for? Go for it 💪🏻

Recently, I applied for a Node.js position, it went very well and I was even surprised of myself in both HR and Technical interviews that they loved my profile and knowledge, but unfortunately, they rejected me because the client didn't like my solution for a code challenge, it was easy but I made the mistake to work on that challenge when I was too tired after three interviews and a lot of study before it! I was in zombie mode 🧟 I could get to the solution but made a mess with the code because I wasn't thinking with a fresh mind

Yes, this is a reminder to all of you that rest is important, other than rushing your work and making a mess.

So that's it! this was the proof that I was able to apply to other positions. I would love to read your thoughts on this, I know it may vary depending on the role and technology, but sometimes there are core concepts and some experiences you had in the past that can make you able to get into other fields and succeed ✅

How I Got Fired From my Dream Job

Juanda Martínez — Wed, 27 Sep 2023 23:45:11 +0000

Cover photo by Clem Onojeghuo on Unsplash

Well, I'm not proud to say that I got fired two weeks ago. It was the hardest thing that could happened to me because I loved that company, but at the same time, I realized that I was too comfortable and felt like my job would last forever.

After two years working for a clothes store e-commerce, my skills in React grew exponentially. I learned a lot of stuff because it was my first huge project, working along with a lot of people with higher seniority and experience, it was pleasant to experience a lot of real problems that can come in a business and get rid of them, but then in my final days I realized that I was being like a robot just writing code and not understanding it at all, I was like in a rabbit hole for several months, then suddenly the business started to having budget problems, and guess what? we got laid off :)

It's important to say that I was working for an IT consultant, so it didn't seem a big deal, because when a project comes to an end, you just need to find a new one and in the process, the company still pays your salary even though you are not being "productive" for them. The problem came when you also needed to take some interviews to see if they could ensure you're the best fit for the project, this means that is exactly like looking for a job outside, with the difference that you still get paid.

I got a reality hit when I arrived at my first interview after two years and I just got in blank with basic Javascript questions! I felt so dumb at that moment, how could be possible to forget how the event loop works? or asynchronism? some basic stuff. The thing ended awful and obviously, I didn't get the project, and I realized how important is not to take things for granted! even though you are developing the most complex stuff in the world, it is important to go back to the basics from time to time.

And if that was not enough, the industry now demands a lot of full-stack engineers! I have worked with PHP in the past, but it was in my beginnings doing "spaghetti code" all the way, then I jumped to Laravel without knowing too much about how PHP works behind the hood. Then I created a basic API with Node.js for my final project at university by just following a short course in a platform without knowing what was I doing, if it works it works, right? That was all the background I have for Backend development and for obvious reasons I didn't feel secure about my knowledge. So in my way to increase my tech stack, I spent a month and a half trying to learn Angular due to a lack of React projects, and also a bit of Node.js and looking for suitable projects, but then suddenly I got an HR call telling me that it was being hard to set me in a project, and they cannot afford to keeping me without being "productive" and... I got fired...

And now here I am, after about a week of being a bit depressed for losing my dream job, and another week to seek my next job, right now the industry is leaning toward full-stack development; React, Redux, Node.js & AWS are the most common stack I've seen through LinkedIn, at least the opportunities here in Mexico 🇲🇽

So, the whole point of this post is to take out in public what I have inside my chest because it makes me feel like a weight has been lifted off my shoulders and gives me motivation to keep going and compromise with this community (even though nobody reads me for the moment lol xD) to grow my tech stack and be the Software Engineer I always wanted to be. I feel like this is the perfect and emotive start for my #30DaysOfCode with Node.js which I found is critical for my career, so starting tomorrow I will post every day (Maybe skipping Sundays because everybody needs to rest) my learning process of Node.js from a Frontend developer's perspective, and hopefully, to get a job soon because I can only survive 5 months until I have to sleep under a bridge or end up in the streets.

I'm excited and happy though 🤩 Let me know in the comments if you guys have been through a similar situation and how you managed to succeed and find the light after the storm!

Come and connect with me (in Spanish) on Twitter/X: @juandadotdev