DEV Community: Jordi

Where to deploy your node.js app [April 2022]

Jordi — Sat, 30 Apr 2022 14:52:31 +0000

These are some of the services I've been trying lately to deploy my backend applications.

Cloudflare Workers

Great DX, docs and community. Free course on egghead.io. Not compatible with all npm packages.

Begin

Begin deploys your app to AWS while offering a "vercel-like" frontend. Only compatible with npm for now. They respond quickly by email.

Railway.app

Railway is really promising. The web-app UX/UI reminds me of Linear. Really good docs.

Render.com

Vercel-like experience for backend apps. Kinda slow if you're on the free tier. Great developer experience and easy to use and get going.

Digital Ocean

Slightly higher learning curve but great option. Tons of tutorials and great documentation.

Heroku

Pretty much same as Digital Ocean. Really popular for beginners.

Honorable mentions

Flight Control

New tool I haven't had the chance to try yet but looks really promising :)

If you liked it consider following me on twitter :)

Best places to deploy your app in 2022

Jordi — Thu, 23 Dec 2021 13:21:05 +0000

A few days ago I wanted to deploy an app but didn't want to go through managing all the infrastructure on AWS. I wanted the same developer experience that I have with my frontend apps where I pick a repo in vercel and that's pretty much it. So here are some cloud providers that have a hundred times better developer experience than AWS/GC/Azure.

Fly.io

https://fly.io/

Pricing: Freemium (has free tier)

Description: Run your full stack apps (and databases!) all over the world. No ops required.

Render.com

https://render.com/

Pricing: Freemium (has free tier)

Description: Render is a unified cloud to build and run all your apps and websites with free TLS certificates, global CDN, private networks and auto deploys from Git.

Qovery

https://www.qovery.com/

Pricing: Freemium (has free tier)

Description: Deploy your apps on AWS Better, faster, simpler

I ended up choosing Render.com. There's also Heroku but I'm sure most people know about it already :)

Toolhunt.dev

This list was originally posted on Toolhunt.dev a website where I list great tools that help developers ship faster. You can find the original list here:

https://www.toolhunt.dev/where-to-deploy-backend-apps

Thank you for reading and have a great day ✌✌

jordienr

Questions YOU can ask during interviews

Jordi — Wed, 02 Jun 2021 07:07:04 +0000

Here are some of the questions I like to ask in interviews.

What stack would I be working on?
What stack is the backend written on? (I'm front)
How is the relationship with the backend teams or design teams?
Would I be able to participate in design decisions?
What is the design / frontend development process like?
How do you measure developers performance?
What is the best and worst part of working there?
What are the biggest challenges in this project?
What can you tell me about the project?
What would you expect from me in X time?
Do you give access to education tools / platforms (Egghead, - Pluralsight, Frontend Masters)?
Why are you looking for more people, are you understaffed or want to start new projects?

If you can come up with more, please share them in the comments!

Find me on Twitter

How to get your first job as a Software Developer

Jordi — Tue, 25 May 2021 13:37:15 +0000

Lately I've been reviewing junior frontend CVs and technical tests at my current job to help with the hiring process. They kinda remind me of me when I started and I realize now all the things I could've done better.

First of all, there's a problem with people applying to jobs. Junior Frontend job offers can easily get 100+ sign-ups. It's impossible to check them all. If you don't have a degree or have no experience, or both, it's really easy for your CV to be ignored. I know it sucks, I've been there. But that's the reality.

Maybe Netflix, Google and Apple can afford to hire enough people to check all the CVs but most businesses don't.

What I recommend you do is cultivate a network so you don't have to rely on this process to find jobs. I did this without realizing.

Building your network

I know most developers despise LinkedIn but without it, I probably wouldn't have made it. I wouldn't say I have a LinkedIn strategy but here's what I believe works best.

Find job-offers you want to apply to.
Connect with people from that company (use the LinkedIn search to find them)
Ask someone, recruiters or engineers, questions about the offer. Be polite. Let them know you know they are busy, and it's okay if they can't respond.
Ask them who can you contact to ask more questions about the offer (whoever is in charge of the process)
Add them through LinkedIn and pitch them (politely) why you think you're a good fit for the job.

You'll probably have to do this a bunch of times until you get a job, but in the process you're cultivating a pretty good LinkedIn network.

With a LinkedIn network when you share stuff about what you're learning and building they will see it and most (in my experience) will like it. Eventually you'll start getting connection requests and messages from people that are looking for Junior Developers.

In my experience, most people are pretty cool with you contacting them and will try to help you somehow if you let them know you're looking for a job. Specially developers.

Some will be assholes, forget about it and move on.

Follow me on twitter for more

How to write more content when you don't have time

Jordi — Sun, 23 May 2021 18:49:25 +0000

Photo by Glenn Carstens-Peters on Unsplash

If you have a full time job, and you've tried writing before, you'll find it's a really time-consuming process. After work, I don't want to jump on the keyboard again and start writing about things related to my job. But I've decided to try and write one article a week, and I've started to develop a system that makes it easy to write.

In this article I'm going to show you my system and how I've organized it so that writing articles is faster and more rewarding.

1. Keep a bank of ideas

I have a bank of ideas in a notion page. When I have an idea for an article I add a title (that later I might change) to this list so that I always have fresh ideas to pick from.

2. Outlines

When I write an article I start first with an outline with stuff I'm going to talk about. Usually to come up with the outline I ask questions about the subject, or I google what people are asking about the subject. When you have questions you basically have the sections of your article, for example, let's say you're writing an article about Frontend Testing with Jest.

"How do I install jest in my React project?" could be a question someone could have. So the first point in my article would be:

"How to install Jest in your React Project"

Sometimes I leave the question as the title of the section since it could help with SEO.

3. Batching tasks

When you sit down to write an outline what you can do is, instead of trying to write an outline and an article in a sitting, try and create 3 or 4 outlines for different articles. That way next time you sit down to write it will be easier.

4. Research when you have the outlines

Once you have the outline, you just have to do the research for the sections you've decided that will go in the article. You don't have to become an expert on the whole topic. Just search and learn about the things you've decided will go in the article.

What I also do is take a lot of notes when I do courses, read docs, learn new things by building them. Usually my notes make their way into articles.

5. Writing

If you have a few titles and outlines, writing 2 or 3 articles in one sitting is usually faster than trying to start from scratch and do the whole process for one article.

Conclusion

Try to batch your tasks and keep a stash of ideas, outlines and notes so that when you sit down to write you're 100% ready and just have to put the words together.

Follow me on Twitter for more :)

Vue Quick Tip #01: SFC Structure

Jordi — Thu, 20 May 2021 06:42:08 +0000

If you've been writing SFC (Single File Components) in Vue you're probably familiar with this structure:

<template></template>

<script></script>

<style></style>

Which is totally right and if you're comfortable using it, it's 100% ok.

But if you think about it, when you're working on a component, you're rarely working with the script and style tags at the same time, right?

You're always working between template/style or template/script, rarely ever script/style.

That's why I recommend you start using this structure instead:

<script></script>

<template></template>

<style></style>

This way you have less scroll distance between your targets and the template works as a clear visual "wall" between your script and your style. Once you get used to it, you won't want to go back!

That's my quick tip for today, follow me on twitter if you enjoyed it :)

Have a good day!

Everything I use daily as a Senior Frontend Engineer

Jordi — Sun, 09 May 2021 08:30:22 +0000

VSCode

I use these extensions:

Utilities

Auto Close Tag: Automatically add HTML/XML close tag, same as Visual Studio IDE or Sublime Text
Auto Rename Tag: Auto rename paired HTML/XML tag
Better Comments: Improve your code commenting by annotating with alert, informational, TODOs, and more!
Better TOML: Better TOML Language support
Bracket Pair Colorizer: A customizable extension for colorizing matching brackets
DotENV: Support for dotenv file syntax
ESLint: Integrates ESLint JavaScript into VS Code.
Firebase: Firestore Security Rules syntax highlighting
GitLens: Supercharge the Git capabilities built into Visual Studio Code — Visualize code authorship at a glance via Git blame annotations and code lens, seamlessly navigate and explore Git repositories, gain valuable insights via powerful comparison commands, and so much more
Gremlins Tracker: Reveals some characters that can be harmful because they are invisible or looking like legitimate ones. Inspired by Sublime Gremlins.
Import Cost: Display import/require package size in the editor
Intellisense for CSS class names in HTML: CSS class name completion for the HTML class attribute based on the definitions found in your workspace.
Jest: Use Facebook's Jest With Pleasure.
Jest Test Explorer: Run your Jest tests in the Sidebar of Visual Studio Code
Markdown Preview Enhanced: Markdown Preview Enhanced ported to vscode
markdownlint: Markdown linting and style checking for Visual Studio Code
Material Design icons Intellisense
npm Intellisense
Path Intellisense
Prettier
Project Manager: Easily switch between projects
Rainbow CSV: Highlight CSV and TSV files, Run SQL-like queries
Random Everything: Generate random ints, floats, strings, words, etc.
SCSS Intellisense: Advanced autocompletion and refactoring support for SCSS
Todo Tree: Show TODO, FIXME, etc. comment tags in a tree view
TS QuickFixes: Quick fixes for typescript
TS

Look & feel

Fluent Icons: Fluent product icons for Visual Studio Code
GlassIt-VSC: VS Code Extension to set window to transparent on Windows and Linux platforms.
Peacock: Subtly change the workspace color of your workspace. Ideal when you have multiple VS Code instances, and you want to quickly identify which is which.
Yi Dark & Yi Light Themes

Git Bash Terminal

I use it to CRUD between folders & files. Open projects in VS Code, manage Git in projects, use VIM, etc.

I recommend you set up some aliases for the most common commands you type.

For example, I have aliases to quickly move to folders like:

alias cdhp="cd h:/projects"

Or run npm commands:

alias nr="npm run"

Screen to GIF

I'm a frontend developer, so most of my work can be screenshotted or screengiffed (I made this word up) which is really useful when working remotely. I use Screen to GIF to quickly create GIFs of parts of the UI to show how it's going or working. This tool is really helpful to have better async conversations with different teams.

Todoist

Even tho at work I use Azure I like to keep a personal to-do list to keep track of tasks I'm working on. I pay the todoist subscription which is pretty reasonable to have everything in one place. There are other free alternatives like trello, notion and more.

Notion

I use Notion only for documentation and taking notes. I find it pretty slow but haven't found any alternatives that I like.

Figma

Even tho I usually don't participate in design processes Figma is really useful to create graphics for documentation. I used to do freelance UI Design, so I'm pretty comfortable with the tool. I'd recommend anyone who is working in Frontend development to get comfortable with Figma.

Conclusion

These are all the tools I use on a daily basis. Only with these I can do my job 100% no problem. I believe that having more tools adds complexity to your day, so I try to keep it simple. I'd recommend you don't have too many tools in your belt and have a clear goal for each.

I could keep track of tasks in Notion, but I prefer to use Notion only for documentation so that it doesn't get too messy.

So, what are your tools? Leave a comment and share them!

Follow me on Twitter for more.

Create CSS Gradient Animations Effortlessly 🌌

Jordi — Tue, 04 May 2021 07:42:08 +0000

Here's a preview of what we'll make 👇

1. Create a gradient

I'll save mine in a variable for easy reuse.

:root {
  --main-gradient: linear-gradient(-66deg, #15162a, #000, #291a33, #000, #381a2c, #000, #121e42);
}

2. Create a container div and add the background

We use background-size to zoom into the gradient.

.container {
  background: var(--main-gradient);
  background-size: 400%;
}

3. Create the animation

This is a basic animation that changes the background-position. Since we zoomed into the gradient it will look like it's moving.

@keyframes gradient {
  0% {
    background-position: 0% 50%;
  }
  50% {
    background-position: 100% 50%;
  }
  100% {
    background-position: 00% 50%;
  }
}

4. Add the animation to our container!

.container {
  background: var(--main-gradient);
  background-size: 400%;
  animation: gradient 8s ease infinite;
}

You can check the codepen here

And that's it!

Follow me on twitter for more!

7 pieces of advice I wish I knew when I started as a Junior Software Engineer

Jordi — Tue, 04 May 2021 07:38:46 +0000

Photo by Corina Rainer on Unsplash

Someone asked this question recently and this are my thoughts about it.

Write more & take notes

Writing is a really valuable skill for developers, the sooner you start developing it the better. Take notes so you have stuff you can write about later.

Teach what you learn

The best moment to teach something is when you just learned it. Apply to do workshops with other developers, write articles, create videos. Teach what you learned and you will solidify that knowledge.

Show your work

You'll feel imposter syndrome every time. Publish articles, create websites, try to get people to use them. You'll only find the things you can improve at when you see people reacting to your work.

Connect with people

Try not to be just a lurker and participate in conversations about topics you're interested in. Give your opinion and your thoughts. Learn from others.

Ask more questions, even the stupid ones

Specially the stupid ones. Asking questions will start conversations that will make you learn 100% times more than tutorials and books.

Asking good questions is a great skill, and you develop it by asking stupid questions.

Chill, you don't have to know everything by tomorrow

Learn things as you need them. Don't rush it or you'll burn out of tutorials, books and making projects for the sake of learning technologies.

A healthy lifestyle will make you more productive

5 hours of work a day, exercise and healthy diet will get more done than 12 hours of work a day. If it's not sustainable don't do it.

Follow me on twitter for more.

I gave my first workshop yesterday. Here's what I learned.

Jordi — Sat, 01 May 2021 09:48:23 +0000

Hello! Yesterday I gave my first ever workshop, about frontend testing principles. Lasted 2 hours and 20+ people showed up. I learned a ton. Here are the things I'll do better next time:

Only write bullet points of stuff I want to talk about and improvise more. I had notes that didn't help me because they were paragraphs.
Prepare possible questions people might have since asking "anyone has any questions?" doesn't seem to work. I think most people don't have time to process the info + come up with questions. Thankfully I had 2 very engaged participants in the workshop that asked questions.
Ask participants by email a few days before the workshop how much experience do they have with the thing I'm going to teach. I did this too late, and I had to change stuff the day before the workshop.
Prepare real life examples and stories of real life situations where whatever I'm explaining is used / helps. People will not remember technical stuff but will remember stories. I'll try to make these stories funny if I can.

Any tips you'd like to share?

Follow me on Twitter for more!

Learn to create your own mini testing library in 5 minutes

Jordi — Mon, 26 Apr 2021 15:30:29 +0000

Before you start

Create a testing.js file and run it with node testing.js to try your library.

This article is aimed at beginners who just started using jest and want to have a better grasp on how it works behind the scenes.

How to create our library

If you've used jest you've probably seen the test() - expect() - toBe() methods.

I'm going to teach you how to build your own "mini" testing library, so you can have these methods and test your app without installing jest, just using Node.

First let's create a method we can test

const sum = (a, b) => a + b

Now let's create a function to test this method

if (sum(1, 2) !== 3) {
    console.error('Test failed. Sum function is broken!')
}

Now if we ever break our sum function our if statement will send an error to the console.

This works, but we want to test our other methods too and writing if statements would be repeating too much code. Remember, keep your code DRY! (Don't Repeat Yourself)

Let's turn that logic into a reusable function. We'll call it expect and it will return a function called toBe

function expect(actual) {
    return {
        toBe(expected) {
            if (actual !== expected) {
                throw new Error('Test failed')
            }
        }
    }
}

Now we can test our function like this:

expect(sum(1, 2)).toBe(3)

This is what we call an assertion.

If our sum function works, we'll get nothing in the console. If it's broken however, we'll get an error.

Now let's create a test suite! We want to test our sum function with different numbers to make sure it always works.

For this we'll create a function called test

function test(title, callback) {
    try {
    callback()
    console.log(title + ' tests passed!')
    } catch(error) {
    console.error('Some tests failed!')
    }
}

Now we can test our sum function or any other function like this:

test('Sum', () => {
    const result1 = sum(1, 4)
    const result2 = sum(2, -1)
    const result3 = sum(10, 10)

    const expected1 = 5
    const expected2 = 1
    const expected3 = 20

    expect(result1).toBe(expected1)
    expect(result2).toBe(expected2)
    expect(result3).toBe(expected3)
})

Now we'll get "Sum tests passed" if our function works correctly or "Some tests failed" if we break it.

Conclusion

The idea behind this article is showing the simplicity behind some basic functionalities of testing libraries. If you understand how they're built you'll have a better time using them. If you've followed the code in this tutorial you'll probably get some ideas on how to improve it.

You could try adding more functions like notToBe or equals

I decided to not use newer JS syntax in this article to make it easier to understand for those starting out.

Find me on twitter

I'm also working on a website & newsletter with resources, tools and cool stuff for frontend developers, you can find it here: https://zerotofrontend.dev/ it's currently on "soft launch" mode and I haven't started sending the letters yet. Subscribe now to get the first one in May!

How to exit vim & learn vim in 5 minutes

Jordi — Mon, 26 Apr 2021 10:19:30 +0000

Press Escape, this puts vim in "normal mode".
write :q! to quit without saving.
write :wq to quit while saving the file.

That's it. Vim is pretty cool and fast once you learn how to use it.

Check this if you want to learn the basics of Vim in 5 minutes:
Vim in 5 minutes

Follow me on twitter for more.
I'm building a newsletter with tools, resources and news about frontend development here if you're interested in that 🙂