DEV Community: Igor Duca

Taming GPT - How to take control of AI responses

Igor Duca — Tue, 11 Feb 2025 23:18:51 +0000

Me: "Hey, please help me to clean up this code"
AI: "Sure, there is the clean version of your code: "
Me: "OK. Now help me with this one, but only answer me with the cleaned code, do not add any commentaries "
AI: "Sure, there is the clean version of your code: "

See how this can be upsetting? I've lost my mind countless times while working because this happens ALL THE TIME when you're dealing with AI.

Band-aid solution

The first thing that may come to your mind is: I will just copy that instruction where I ask the AI to not add any commentaries to the response and pass it to each prompt I send.

That will work in this case, but let's imagine this situation:
Suppose you want to ask the AI to loop through an array you detail in the prompt and return a list with the object ids.

First response: The object ids are returned inside an array;
Second response: The object ids are returned in an array inside a JSON;
Third response: The object ids are returned as a string divided by commas.

If you are building an API or a service that works around the AI response, you'd have a lot of work to do in order to create patterns and parse each possible response from the AI.

Good practice

Now that you've learned what not to do, see how you could handle cases like this with mastery.

If you are using chat GPT, you'll be able to do this by creating a custom GPT and passing the following instructions:

You are an AI agent that is responsible for cleaning code for a software engineering company.
You must answer to every question with only the resultant code.
Do not add any comments to your response

Or, if you are building an API using AI, you can add the text above to the start of your prompt, being this the prefix of every prompt you enter in the model.

Even more customization

Going back to that product list example, here's how we can successfully create a response pattern:

You are an AI agent that is responsible for looking object arrays and returning only the object ids in a new array.
After going through the object list, separate all the ids and present them in the response following this structure:
{
    "ids": []
}
Do not add commentaries to the response, just return the JSON object.

See how easy that was? Now you can parse the response text safely knowing that it will always follow the same pattern.

Next Level

The example above isn't the most advanced one. See what we can do using AI without much complexity:

You are an AI responsible for answering SMS messages from a Tech Support company. You need to read the messages, interpret them and only answer the user with the mapped responses we provide you.

The known responses that you can use are: {faqList}

Make sure to treat the customer well. Call them by their first name, which is: {firstName}

If you need any additional info on the company, check this list: {companyInfo}

Our users usually don't enjoy reading long text messages, so make sure to break your text into many messages to make the conversation more dynamic and enjoyable for the user experience.
To determine whether a message has to start or end, add the tags <start-message> and <end-message> to your generated message, and the company API will parse correctly and divide the text into a group of messages.

After fetching all the data you need to return to the customer, present your answer using the following structure:

{
    "ticket-number": {ticketNumber},
    "message": "",
}

The example below illustrates a more advanced prompt, that needs to be feed with information before having a response. Patterns like this can prevent the following issues:

Hallucinations
AI using fake information or incorrect facts
AI deciding which is the better structure to respond (in this case, it will only use the structure you've specified)
Short messages without custom user data

Conclusion

AIs are really flexible. You need to understand that the generative engine will play your game, so you can dictate how it must work and input as much arguments as possible to the prompts.

Photo by Google DeepMind on Unsplash

How to write semantic HTML for SEO boosting

Igor Duca — Fri, 24 Jan 2025 04:30:11 +0000

Going back to the basics is a natural process for all developers. It is normal to skip steps while learning something, but you must be aware of its consequences: if you skip too many steps, your foundations will be undeveloped. Therefore, you won't have a solid background on how to do that thing.

How important is HTML for SEO?

Some may say it's hard not to know how to write a well-structured HTML, right? It is tough.

What are the headings?

Headings are tags mainly used to guide readers through your text. They make it explicit when a new section starts, ends, and develops through new topics. Also, it is important not only for users but for search engines. I mean, it is our main purpose SEO-wise, right?

During web scraping and crawling, search engines give considerably high weights to descriptive headings and well-structured content.

Text-to-HTML rate

The text-to-HTML rate is important for your website. It's a rate calculated by the search engine to determine how much content is available on your pages. If your page is rich in content, it will be considered a content-driven page, which means it is more worthy of scraping. A good text-to-HTML rate is between 25% and 70%. To maintain a good rate, it is important to remove unnecessary HTML or increase the text count.

Leveraging the available HTML tags

There are 100 HTML tags you can use to structure your website. The difference between a good and a bad SEO can be decided by the tags used in the website content. If you strategically leverage specific tags through your website's structure, you'll be able to give more context to the search engine. Therefore, your website will be better indexed than a website with a non-semantic HTML since the scraper knows more about your website because of the tags.

A practical example of how to leverage semantic tags:

Non Semantic Example:

<img src="https://example.com/image.jpg" alt="A beautiful sunset over the ocean" width="500" height="300">

Semantic Example:

<figure>
  <img src="https://example.com/image.jpg" alt="A beautiful sunset over the ocean" width="500" height="300">
  <figcaption>Fig. 1: A breathtaking view of the sun setting over calm ocean waters.</figcaption>
</figure>

Using <figure> and <figcaption> will give more context to the search engine. With this additional context, the search engine will be able to determine the subject of the present image, boosting the keywords of your website.

Aria label - attribute text to visual elements

A search engine isn't able to interpret icons or visual elements in your website. If you build a search bar with an input and a search button, the scraper will only identify your input - because of its tag and placeholder. But, the search icon would be completely ignored.

A practical example of the usage of aria labels

<button aria-label="Close" onclick="myDialog.close()">
  <svg
    aria-hidden="true"
    focusable="false"
    width="17"
    height="17"
    xmlns="https://www.w3.org/2000/svg">
    <path
      d="m.967 14.217 5.8-5.906-5.765-5.89L3.094.26l5.783 5.888L14.66.26l2.092 2.162-5.766 5.889 5.801 5.906-2.092 2.162-5.818-5.924-5.818 5.924-2.092-2.162Z"
      fill="#000" />
  </svg>
</button>

As you can see, this button has an SVG icon, but it also has an aria-label, which means that if your user is visually deficient, they can listen to "Close" when they're about to click on the close button. Without the aria label, the reader wouldn't be able to interpret the text of the icon, and the search engine wouldn't have the context of the icon, so it would be ignored in the scraping process.

Final consideration

In conclusion, one of the most important strategies to boost your SEO ratings is to write a more semantic SEO, which would be better interpreted by search engines and web scrapers. Every product needs to be well-indexed. If there are no users, there is no profit. If you don't have branding dominance, your product will be obfuscated by its competitors.

Photo by Souvik Banerjee on Unsplash

Preventing/Refactoring Conditional Chainings

Igor Duca — Thu, 01 Aug 2024 18:47:31 +0000

One of the most common code smells when developing JavaScript applications is the excess of conditional chaining. In this article, I want to argue about how to prevent these cases through architecture and code.

Introduction
Understanding Conditional Chains
The Problem with Conditional Chains
Refactoring Conditional Chains
Preventing Conditional Chains through Architecture
Best Practices for Front-end Development
Conclusion

What is a conditional chain?

Excessive conditional chaining is a common code smell in JavaScript applications. This article explores how to prevent and refactor these cases through improved architecture and coding practices.

Conditional chains are excessive logical operators used to express conditions in functions or methods. Let's look at an example using a React application:

As you can see in the example above, there is a chain of three conditions only to dictate the way this code should be rendered.
The conditions are:

If the list of sports has elements, the default element should be rendered;
If the loading state of the component is true, a loading skeleton should be rendered;
If there is no element in the sports list, an empty state should be rendered.

In this code, there are two main problems:

When we are checking the length of an array and using the "&&" operator, we are telling javascript that it should render the component if there is a value related to the array's length. If there is no array, this value should be null or undefined, but, if the array exists and its length is zero, the number zero will be rendered instead of the elements, because you're asking javascript to render the value linked to the array's length.
There is no need to use a chain to control the rendering of these two elements. Adding a condition before the render of the "default" state of the component will be a more elegant way to work with this situation.

Refactoring

That being said, the refactored version of the code above is:

This is one of the many ways to deal with conditional chainings using JavaScript's logical operators. As you can see in the code above, I've used a non-common approach to solve the conditional excess of the code.

The !! operator in JavaScript is used to coerce a value to a boolean. It takes advantage of the fact that JavaScript has truthy and falsy values. The first ! operator negates the value, turning truthy values into false and falsy values into true. The second ! negates it again, resulting in a boolean representation of the original value. This is often used to convert values like strings, numbers, or objects into a boolean value (either true or false), based on their truthiness or falsiness.

For example:

!!"Hello" evaluates to true because non-empty strings are truthy.
!!0 evaluates to false because 0 is falsy.

Preventing it from happening through architectural decisions

You must not take this as a rule, but in most of the cases where conditional chains are created, the excess of conditions are trying to parse and handle dynamic values, because if you're dealing with static values, the implementation tends to be much simpler and straightforward.

When you're modeling a database, you must have some concerns about the software's dependencies.

People typically learn this kind of dependency study through their IT college studies, but I'll illustrate it.

There are two kinds of dependencies on software:

Functional dependencies - these dependencies directly affect the user, since they are the features the users are interacting with, such as buttons, screens, inputs, forms, etc.
Non-functional dependencies - these dependencies are not commonly noticed by ordinary users since they are mainly the back-end ones, such as error handling, conditions, rules of business, validations, etc.

Preventing front-end excess control

Your back-end must be responsible for all the logic parts of your system, so, the majority of your functional dependencies must be handled by back-end functions, not by front-end screens or user interactions.

When you start to develop a new feature and to understand what it needs to work, such as props, interfaces, and parameters, you must have in mind what will be required, what will be optional, and what mustn't be used.

You must use the example above as an example of what not to do during your development sessions. As you can see, this interface has only optional parameters, but I doubt this component will only have "maybe" variables attached to it.

You need to understand how your component is supposed to work before developing it and pushing a lot of confusing code to your front-end application. Instead of dealing with a lot of conditions, it is easier if you just decide: what will be used by the component and what will not.

After considering it better, you will come up with something like this:

Now the interface only has required parameters that will certainly be used through the component's lifetime inside your app, not having a lot of optional parameters that could never be defined or used like the component from before.

Conclusion

Preventing and refactoring conditional chains leads to cleaner, more maintainable code. By understanding your component's requirements, shifting logic to the back-end where appropriate, and designing clear interfaces, you can significantly reduce the need for complex conditional chains in your front-end code.

Photo by Samsung Memory on Unsplash

Why is prisma orm bad?

Igor Duca — Tue, 16 Jul 2024 01:17:21 +0000

Today, I was discussing with a friend which PostgreSQL client (ORM) he should use. Choosing the best option is a challenging task, but there's a spicy take I always bring up in this conversation: avoid using Prisma as your ORM.

Introduction
Why Not to Use Prisma?
Why Is This a Problem?
Deep Diving into the Problem
Consequences
When Should I Stop Using ORMs?
Conclusion

Why Not to Use Prisma?

If you're unfamiliar, Prisma is a well-known TypeScript ORM for PostgreSQL and MongoDB. It was the first ORM I learned to use, and this decision led to some difficulties later on.

Prisma's primary issue is that its entity creation and database modeling only work with their own language.

Why Is This a Problem?

First, let's compare a Prisma entity with a TypeORM entity to understand what makes Prisma different from other ORMs on the market.

The code above represents a TypeORM implementation of a user entity.

As you can see, we're using TypeScript to validate all the fields based on their types or relationship references. In the code above, I used the library class-validator to apply the validation decorators.

The code above represents the same entity, but rewritten entirely using Prisma's own language.

Deep Diving into the Problem

What's the problem here?

At first glance, it might seem trivial, but it actually makes a lot of sense: with Prisma, you're forced to create all your logic using their programming language (or markdown language, I'm not sure what it's called).

This specifically prohibits you from using external libraries or JavaScript code to build more reliable logic in your entities.

Consequences

Since you can't use JavaScript in your code, you should expect to waste a lot of time trying to figure out how Prisma's scaffolding language works and how to create schemas using it.

There's also one very important detail: you can't use any external library or helper.

Imagine a situation where you need to customize the way your primary keys are generated. With TypeORM, you can simply use this approach:

However, to achieve the same result using Prisma, you will need to do something like this:

When Should I Stop Using ORMs?

There is an interesting discussion where developers argue that using ORMs is a mistake and they need to stop it as soon as possible.

I really disagree, but with some conditions.

I agree with freeing yourself from ORMs when they function like Prisma: they expect you to learn a completely new language or methods just to make it easier to write code.

"Wait, are you saying that creating an easier ORM is bad?"

No. I am saying that removing the flexibility of writing more raw-like queries to make the ORM easier can cause issues for developers, such as forgetting how to use SQL.

Conclusion

This article is clearly a matter of opinion, but I am trying to illustrate a straightforward point: you should not use ORMs that force you to be distant from SQL queries. Your ORM should help you better organize and formulate your queries, not write entire queries for you.

What do you think?

Photo by Milad Fakurian on Unsplash

understanding react hooks

Igor Duca — Thu, 27 Jun 2024 01:45:42 +0000

back in 2018, Sophie Alpert, Dan Abramov, and Ryan Florence did one of the most important talks of the history of web development.

they were at the ReactConf introducing the React Hooks to the developer community.

React Today and Tomorrow and 90% Cleaner React With Hooks

the motivation behind the creation of hooks

back in the day, react code used to look like this:

most of the react code was written using classes, so, its components were called class based components.

when you wanted for your application to be controlled and have states, you would need to make it a class, so a bunch of code should be added:

class extending a react component
a constructor with the component props
use super() to make the state and the props accessible through the component
bind all of the state writing methods

yeah, that's definitely a lot of unwanted code... the files were a mess and they used to have more then 1.000 lines

the wrapper hell

Sophie and Dan made sure that the new react features would fix a well known react issue. it was called: wrapper hell

do you remember this image?

yeah, this is wrapper hell

basically the OG react codes needed a lot of tags to access contexts, to display different themes, to get the users locale, etc.

and all of that was because the hooks did not existed - yet!

finally: the hooks

three hooks were introduced back in the day: useEffect, useState and useContext, and all of them had unique purposes and functions.

the useState

useState is the most used and some must say: must important react hook.

basically, useState is a hook used when you want to make sure that a component have a memory. when you want your component to store and remember a variable, you should have a state.

react applications are known for being personal and customizable since its very first beginning

To me, Next is not just about making fast sites. It's about making sites that are personal. - Guillermo Rauch, founder of Vercel and creator of Next.Js

and the useState was a real game changer for the web development

I wrote this OG class based component -- probably is inaccurate -- in order to illustrate how react components looked like before the hooks.

this is a react component that uses the react 16.8 version -- the version where the hooks were introduced.

as you can see, it is really noticeable how much code was turned unnecessary after the hooks. our DX have increased considerably and the components were more succinct and readable.

if you don't know why we use states, please read this

the useEffect

have you ever heard the phrase "the component did mount"?

componentDidMount(), componentWillUnmount(), componentDidUpdate() were methods very much used on the earlier versions of react to listen and interact with different stages of the component rendering and compiling process

after the introduction of the "listener" hook, the useEffect, those methods were happily replaced

basically what the useEffect hook does at the code above is to listen to all of the changes on the page and change the width state value through the setWidth method.

the main purpose of the useEffect is to listen to changes and run subsequent functions, BUT, this hook is definitely the most MISUSED hook.

today we are used to use the useEffect hook to perform changes based on everything, and this may cause a lot of issues such as:

infinite loops
duplicated values inside state arrays
unwanted code smell -- yeah, using a lot of useEffects should be considered as code smell

so, think about this: when you want something to change during a function, your first thought may look like this:

but, a bad logic at the API gateway or the user registration process could lead to:

but, there are some ways to fix it. this is the one I like the most:

instead of dumping a lot of logic inside your useEffect and your other methods to try and force some kind of idempotency, you could just go and replace it by a callback function that handles and sets the state accordingly to the component's needs. as simple as that.

be careful with the way your component handles effects.

useContext

the useContext is much easier to understand than the useEffect, because it has a lot to do with the useState.

basically, the useContext hook should be used to store global values or states

take a look at how contexts were managed before:

and after the useContext hook, it started to look like this:

as you can see, now we can simply import the context and wrap it with the useContext hook. there is no need for the context consumers no more.

if you don't know why we use contexts, please read this

conclusion + custom hooks

really understanding the react hooks will make your code work and look really better. sometimes we get so used to write code without thinking that some basic concepts run out of our mind.

it is important to always remember of the react foundation when writing code.

the React Core team did not wanted our code to be static and boring, so that is why they developed a whole new community experience through the Custom Hooks.

I now the Next developers would not be able to live without a useRouter(), or a useSearchParams(). also, what would the new React developers do if they did not had the useMemo()?

if you don't know how to mix the concepts explored through this article and come up with a custom hook, just wait until I publish the next article showing you how to.

thanks for reading!

Photo by Oskar Yildiz on Unsplash

why your content should be briefer

Igor Duca — Wed, 15 May 2024 21:48:53 +0000

one of the recent things I learned is: people like to read or watch relatable stuff. you will not want to spend your time watching some thing that is not offering you anything useful -- there are some exceptions for this, like the videos you watch to be entertained before taking a nap, for example.

being briefer will help you keeping the attention of those who you are trying to convince that you are capable of being useful to them.

no one likes to read boring explanations;
no one likes to watch a 30 min video to learn two lines of code;
no one likes to watch you talking without giving real-life examples;

use your time to show and solve real problems, so, this way, you will be used as reference for someone that solve things without wasting your time. and, that is precious.

Photo by Samura Silva on Unsplash

About selling a solution

Igor Duca — Mon, 13 May 2024 22:27:08 +0000

Learning how to sell and making your productive attractive are the main concerns you may have while designing a new commercial solution.

Breakthrough

The first thing you have to consider while designing something you want to sell, is: who are the first commerces, people or companies that you are willing to go after?

A product need to have users and customers to be able to survive and be useful.

Engineering was created with one main purpose: solving problems that ordinary people are not able to solve.

How to make something attractive

Attractiveness is all about offering something someone does not have. So let us follow this line and understand some things: there are a lot of products that does the same as yours, maybe some of them are even cheaper. How can you manage to have their customers or to make sure that the new customers of this specific market are going to follow yours instead of theirs?

I think you may have heard about the concept of "Skin in the game" -- basically, you need to insert yourself deeply into the subject you want to succeed -- so, let us apply the book fundaments into the product market.

If you are willing to sell a product to supermarkets, being able to go to actual supermarkets and take a look at their difficulties is a pretty smart way to only aim at the really important stuff and only develop solutions to what they are really trying to improve or solve. Working assertive is working smart.

About work subject

Choosing the right work subject is following one only path and not being dragged into others. Let me contextualize this: when you start to aim at one use case and then start to try to embrace a lot of others, your product will lose focus and will not be good at any of its features.

Choosing where and how to work previously will help you to know where your product working subject starts and where it ends.

Network. Talk to people

Talking to people about their work problems can be a good approach to understand what will your app be about. You may talk to a doctor to understand which tech is missing at hospitals. You may talk to a teacher to understand how you could make their job easier. You may talk to a e-commerce owner to understand what metrics or features he would like to have in order to sell more and easier.

You need to talk to people and you need to show them that you are concerned about their work and how it could be better.

Conclusion

Basically, the smartest way to sell your product is to talk to people and understand what they need, what they want their commerce to have, what issues are they facing daily and mainly: how your product can be useful.

This is the key to attract customers.

Photo by and machines on Unsplash

why to avoid onion-like architectures

Igor Duca — Mon, 04 Mar 2024 16:45:00 +0000

first things first, it is important for us to understand what onion-like stands for.

just like an onion, an architecture must have a lot of layers, but, at some point, the excess of layers may make the project be hard to maintain or have a poor performance.

the hexagonal issue

the hexagonal arch is known for being a well designed and resilient architecture, but, it have some serious issues.

almost every one of them issues are related to the amount of processes and changes that you need to perform in order to maintain that architecture.

let me give you an example: if you are willing to create an easy back-end application that must only feed some information to your front-end application without a lot of permissions or data parsing, you must go with the simpler approach possible.

but, let us imagine that you go and do a bad take and choose a ports & adapters architecture for this application that is supposed to be as simple as possible.

your first issues probably will be:

you will need to create a protocol for every one of your requests and make them resilient for other approaches, such as cli commands or webhooks
type inconsistencies: if you do not use a language that allows you to explicit types and create a type-safe application, you probably will suffer from inconsistencies between the layers of your application
amount of files needed to be changed in order to perform an endpoint rule change

I know that other problems may rise or some of the problems of the list above can be avoided using DTOs and other parsing features, but, would not it be easier if you just chose to use a simpler architecture since the start of the project?

taking the right option

it is not right to tell someone that a specific architecture will solve every structural problem, but, you need to have something in mind when you are thinking about architecture: its main purpose is to solve organizational problems, so, do not try to create more of them.

if you need to solve a small problem with a small crew, you must use a small and fast architecture

if you are willing to solve a complex problem with a larger and more mature crew, you must use an architecture that will be reliable for your infrastructure.

Photo by Nick Andréka on Unsplash

Observability with Express and Busgnag - In a easy way

Igor Duca — Mon, 19 Feb 2024 22:23:29 +0000

This article must be one of your first steps into learning what observability tools does and how you can start using them. During this article, we will be implementing Bugsnag on a Node.Js + Express project.

Check out the complete source code

What are middlewares
Setting up the project
Creating the middleware (Optional)
Testing the middleware (Optional)
Sending the errors to a observability tool (Bugsnag)
Final code
Testing how the logs work

What are middlewares

Imagine that you want something to do something everytime your application receives a signal -- this signal can be a new request, an error, a subscription, a webhook, etc. -- in order to do some parsing with the received information... you are probably needing a new middleware for your application.

A middleware's main function is to intercept new requests (or events) and run a callback function using the received parameters, so, this way, you can go and do something with that data.

Setting up the project

Go ahead and install the base dependencies for a express application:



npm install express body-parser cors



const express = require("express");
const bodyParser = require("body-parser");
const cors = require("cors");

const app = express();

app.use(bodyParser.json());
app.use(cors());

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

The code above is a base for you to start your new express server application with nodejs and javascript.

Creating the middleware (Optional)

To create a middleware with express, you need to use the .use() method. This method will make sure that everything that happens in your application will be covered in that function (the middleware one).



app.use((err, req, res, next) => {
    console.log("something broke");
});

// err -> If there is an error in the application, it will be stored on the err object.
// req -> The request object.
// res -> The response object.
// next -> The next middleware in the stack.

Testing the middleware (Optional)

We have not set any routes, so, if you go ahead and create a fake route to throw errors no matter what:



app.get("/", (req, res) => {
  throw new Error("something went wrong");
});

Now, if you go ahead and make a GET request with:



curl http://localhost:3000

(or it could be using your Postman or other HTTP agent), you should see this error:

Sending the errors to a observability tool (Bugsnag)

First things first, you must go ahead and create an account at Busgnag.

After creating your account, select Express as a technology for your project and you should see this example code:

So, let us go ahead and follow those steps.

First, install bugsnag in your project



npm install @bugsnag/js @bugsnag/plugin-express --save

After installing bugsnag, replace the sample code in your project:



const Bugsnag = require('@bugsnag/js')
const BugsnagPluginExpress = require('@bugsnag/plugin-express')

Bugsnag.start({
  apiKey: '<YOUR-API-KEY>',
  plugins: [BugsnagPluginExpress]
})

Bugsnag have their own middleware service that does a abstraction of express middleware (the one that we have created), so, let us go and replace ours with the one that Bugsnag provides.



// This must be the first piece of middleware in the stack.
// It can only capture errors in downstream middleware
app.use(middleware.requestHandler)

/* all other middleware and application routes go here */

// This handles any errors that Express catches
app.use(middleware.errorHandler)

Final code



const express = require("express");
const bodyParser = require("body-parser");
const cors = require("cors");
const Bugsnag = require("@bugsnag/js");
const BugsnagPluginExpress = require("@bugsnag/plugin-express");

Bugsnag.start({
  apiKey: '<YOUR-API-KEY>',
  plugins: [BugsnagPluginExpress],
});

const app = express();

app.use(bodyParser.json());
app.use(cors());

const PORT = process.env.PORT || 3000;

app.use(middleware.requestHandler);

app.get("/", (req, res) => {
  throw new Error("something went wrong");
});

app.use(middleware.errorHandler);

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

Testing how the logs work

Now let us go and hit that error endpoint again with:



curl http://localhost:3000

If you have done all of the steps, in a minute or so you will be able to see data at your Bugsnag dashboard:

And that's it! Now you are able to see all of your server errors at Bugsnag and have a pretty good free-tier observability tool. To know more about pricing features, check it out here.

Liked this article? Show some love in the comments and follow me at Twitter.

Photo by Vadim Bogulov on Unsplash

Failing fast, winning faster

Igor Duca — Wed, 31 Jan 2024 13:37:35 +0000

Recently I have been through some intrusive thoughts telling me to rethink my entire planning routine... After giving it some attention, I noticed that this was a real concern, I was using so much time planning things instead of starting them.

While studying for a solution, I found this one method that helped me thinking better about things.

About failing fast

The 'Fail Fast' method says that you does not need to be concerned about starting things when you are proficient on them nor starting a project while you have learned everything it will require to work, but starting things from scratch and learn them on your way to the end.

Failing fast is a pretty smart thinking path to teach you how you are wasting time on trying to make things look perfect until you release, trying to overthink social situations and making decisions a lot more difficult because of the simple fact that you are so afraid of failing.

About winning faster

Consistency is the key, but, who starts to try earlier have more time to fail, than, more time to try new things and be ready to win earlier than the ones that are waiting to be good before trying.

Photo by Uran Wang on Unsplash

Improving Figma DevMode outputs

Igor Duca — Sat, 27 Jan 2024 04:22:00 +0000

One of the major doubts of junior developers is how they can translate a UI into code. Some time ago this task was a bit more difficult than it is today thanks to the lack of developer-friendly tools.

But, in this article, let us take a deep dive on how Figma layers works with Dev Mode to help you code visual assets or screens a lot more quickly than before.

Introduction about Figma Dev Mode

Dev Mode is a new space in Figma for developers with features that help you translate designs into code, faster. -- Figma Dev Team

When you turn on the dev mode feature for the first time, I am pretty sure that your eyes will fill out with hope for a new front in the web development, praying for better days when CTRL + C and CTRL + V will be the only thing we need to replicate an UI... This is an utopia for now, but let me explain to you what good things we can get from this feature.

Design to tailwind

This is one of the coolest features that I ever used on Figma: you can easily select a section, group or element and see its code translated directly to tailwind classes

Result:

Using external variables

A premium tip about how to make it easier for you to translate your design and wireframes into code is using external variables.

Once you create a new Figma project, it will be a blank project with none variables, but, once you import components from ui kits, all of the kit variables will come alongside the component.

Let us practice this importing a random component from shadcn's ui kit:

Once you copy and paste this component into your Figma project, you should be able to see its sizing, spacing and color variables that were created on the shadcn project:

And, your DevMode output code will use the tailwind theme colors once they are also used by shadcn -- FYI shadcn colors and sizes are based on tailwind theme, so its Figma project contains a lot of tailwind's configurations and variables, which helps your code output to contain tailwind's known variables.

Help Dev Mode to output better code

Your layer organization and content disposing tells directly to the dev mode about how it needs to generate your code, and here are some tips that could help you making your output code cleaner and possibly more effective:

You should group all of your components that are nearby others in order to establish a div-like relation between multiple components, and this will help the dev mode to output a more semantic code.
Creating a frame for each one of your sections will help you having your design more organized like your html code should be, so your navigation will be more precise and the code output will also be more precise.

Previewing your outputs

If you don't have a project with tailwind and want to test if your outputs are correct, try Tailwind Play

Photo by Mads Schmidt Rasmussen on Unsplash

Front-end must be dumb

Igor Duca — Wed, 17 Jan 2024 02:03:23 +0000

One of the problems I faced recently was the need to make the front-end application I am working on more dumb.

Responsibilities

The main need that moves us to create a dedicated back-end is to separate its responsibilities and methods from the front-end.

Think about this: your front-end is messy almost every time, and this may be a red flag to make you rethink about how much do you trust in your front-end.

Personally: I do not trust a bit on mine front-end applications, and this is why we need to make sure that the back-end is the smart one with more responsibilities.

Splitting applications

Let us suppose this scenario: your front-end does not have a service API layer, which means that your requests are created directly on the page like this:

If you are creating these requests with no personalized service or a state machine and also using its response data in order to validate a rule or behavior, once you update your endpoint, entity or DTO, you will need to go at each one of the requisitions and change their behavior manually, so it can now work along with the new changes.

Yin-Yang

Your web application must have its responsibilities well stablished and more importantly: well divided in each one of the endpoints.

Your front-end must be concerned on rendering the visual aspects of the application and your back-end must be the source of the intelligence of the business.

Once you understand this, let us now try to make the axios request work as it should:

This may be a really silly example of how things should work, but you need to focus on the behavior of the front-end: it only receives the information and send it to the user, having zero concern or any further validation about the response.

The back-end side

There are some things you need to consider while creating a resilient back-end that will not allow any unwanted information or payloads to reach the front-end:

Early return - get rid of those elses. your code legibility will be much superior after using early return.
Try/catch - make sure that your back-end will be prepared for all of the known issues that could happen.
Observability - your unknown bugs or error reports must go somewhere, and this magical place should be some observability tools.

Final considerations

Knowing that your front-end has limitations and your back-end does it as well will change your way of thinking about how web applications should work, and this kind of concern will be very healthy for your development career.

DEV Community: Igor Duca

Taming GPT - How to take control of AI responses

Band-aid solution

Good practice

Even more customization

Next Level

Conclusion

How to write semantic HTML for SEO boosting

How important is HTML for SEO?

What are the headings?

Text-to-HTML rate

Leveraging the available HTML tags

Aria label - attribute text to visual elements

Final consideration

Preventing/Refactoring Conditional Chainings

Table of Contents

What is a conditional chain?

Refactoring

Preventing it from happening through architectural decisions

Preventing front-end excess control

Conclusion

Why is prisma orm bad?

Table of Contents

Why Not to Use Prisma?

Why Is This a Problem?

Deep Diving into the Problem

Consequences

When Should I Stop Using ORMs?

Conclusion

understanding react hooks

the motivation behind the creation of hooks

the wrapper hell

finally: the hooks

the useState

the useEffect

useContext

conclusion + custom hooks

why your content should be briefer

About selling a solution

Breakthrough

How to make something attractive

About work subject

Network. Talk to people

Conclusion

why to avoid onion-like architectures

the hexagonal issue

taking the right option

Observability with Express and Busgnag - In a easy way

What are middlewares

Setting up the project

Creating the middleware (Optional)

Testing the middleware (Optional)

Sending the errors to a observability tool (Bugsnag)

Final code

Testing how the logs work

Failing fast, winning faster

About failing fast

About winning faster

Improving Figma DevMode outputs

Introduction about Figma Dev Mode

Design to tailwind

Using external variables

Help Dev Mode to output better code

Previewing your outputs

Front-end must be dumb

Responsibilities

Splitting applications

Yin-Yang

The back-end side

Final considerations