DEV Community: Jeff Jakinovich

How To Count Strings With Emojis In JavaScript

Jeff Jakinovich — Fri, 09 Aug 2024 16:40:15 +0000

I love emojis. Who doesn’t?

I was polishing off a highly intellectual X post a few days ago when I realized something.

Emojis aren’t counted the same as regular characters

When typing out emojis in the new post section of X, you can see how regular characters count less than emojis.

After a quick search, I found out it has something to do with how they are encoded in the Unicode system.

Essentially, emojis are made of multiple code points, and length only counts code points, not characters.

Regardless of why it happens, I thought about all the text counters I’ve created and how many exist in SaaS land.

Emojis are not getting their fair shake 😢.

Simply taking the length of the string isn’t an accurate count. Take, for example, something like this:

import { useState } from "react";

export default function App() {
  const [text, setText] = useState("");

  function countString() {
    return text.length;
  }

  function handleChange(e) {
    setText(e.target.value);
  }

  return (
    <div className="App">
      <h1>Make the emojis count 👍</h1>
      <textarea value={text} onChange={handleChange} />
      <small>Characters: {countString()}</small>
    </div>
  );
}

This is a simple React component that tracks the characters typed into a text field. It is the most common implementation of this feature.

But the output gives us the same problem as my X post:

Modern web development makes it easy to count characters accurately

You can use a built-in object called Intl.Segmenter.

There is a much broader use case for the object, but it essentially breaks down strings into more meaningful items like words and sentences based on a locale you provide. It offers more granularity than simply using code points.

To fix our example above, all we have to do is update our countString function like this:

import { useState } from "react";

export default function App() {
  const [text, setText] = useState("");

  function countString() {
    return Array.from(new Intl.Segmenter().segment(text)).length;
  }

  function handleChange(e) {
    setText(e.target.value);
  }

  return (
    <div className="App">
      <h1>Make the emojis count 👍</h1>
      <textarea value={text} onChange={handleChange} />
      <small>Characters: {countString()}</small>
    </div>
  );
}

We create a new instance of the Intl.Segmenter object and pass our text to it. We put that output into an array and then finally take the length, which will be far more accurate than simply taking the length of the original string.

Here is the result:

So why doesn’t X count an emoji correctly?

Short answer: I have no idea.

I’ve been programming far too long to delude myself into thinking there is a simple answer.

But Intl.Segmenter has good browser support, and any performance or memory constraints would be negligible.

My best guess is that the codebase is so large and so old that it isn’t worth the side effects of a refactor.

I’d be happy to learn more if anyone has better insight into this.

I hope this helps 😄.

Happy coding 🤙.

How To Stop Form Bots With Honeypot Fields

Jeff Jakinovich — Thu, 01 Aug 2024 01:48:31 +0000

Spam bots are the worst.

They can ruin a good contact form in a heartbeat.

While getting rid of spam bots requires a lot of strategy and technology, simple honeypots are quite effective for their low effort.

What is a honeypot?

In the world of cybersecurity, there are many types of honeypots, but they are all essentially bot traps.

Today we are talking about honeypots used in frontend forms.

When bots spam your contact form, they must read the page source to “see” what to fill out. The good news is bots don’t “see” like humans.

This is precisely what a honeypot exploits.

The process will look a little something like this:

Create a fake input inside a form
Hide it from the human users but not the bots
Filter for the field in your backend

It would look something like this.

Setting up the honeypot field

Let’s pretend we have a basic contact form:

<form action="/submit" method="POST">
  <label for="name">Name:</label>
  <input type="text" id="name" name="name" required>

  <label for="email">Email:</label>
  <input type="email" id="email" name="email" required>

  <label for="message">Message:</label>
  <textarea id="message" name="message" required></textarea>

  <button type="submit">Send</button>
</form>

Bots will fill out every input and submit our form, so we need to add our honeypot.

<form action="/submit" method="POST">
  <label for="name">Name:</label>
  <input type="text" id="name" name="name" required>

  <label for="email">Email:</label>
  <input type="email" id="email" name="email" required>

  <label for="message">Message:</label>
  <textarea id="message" name="message" required></textarea>

  <div class="phone">
   <label for="phone">Phone:</label>
   <input type="text" id="phone" name="phone">
  </div>

  <button type="submit">Send</button>
</form>

We added an extra field called phone. This field should not be visible to the user but should be visible to bots. To hide the field, we can add a simple CSS rule.

.phone {
    display: none;
}

The user will not be able to see our honeypot, but bots will. And when they see it, they will most likely fill it out, which means we have them trapped.

Make sure you pick a good name for the honeypot

Before we discuss how to deal with this extra field in our backend, I want to point out one thing.

The name of our honeypot shouldn’t be random.

These bots are aware honeypots exist.

They have logic that filters out any irrelevant inputs when completing forms.

So if we create a field called random or, even worse, honeypot, we tell the bot the field is a trap, so they should avoid it.

Instead, we should consider related topics or fields related to the form.

In most contact forms, that means we’d add anything related to contact details like:

Trap the bot and kick it out

Now that we have the honeypot set up on the frontend we need to handle it in our backend.

I set up a pseudo-express route to show the basic logic of handling this extra field.

app.post('/submit', (req, res) => {
    const { name, email, message, phone } = req.body;

    if (phone) {
        // If the honeypot field is filled, it's a bot
        console.log('Potential bot detected');
        res.status(400).send('Bad request');
    } else {
        // Process the legitimate submission
        console.log('Legitimate submission:', { name, email, message });
        res.send('Thank you for your submission!');
    }
});

We pull the honeypot off the body and then check if there is a value.

If there is, we caught the bot!

Send back a 400 error and sit back as your form zaps bot after bot.

More than one honeypot

In the last few years, I’ve noticed the effectiveness of one honeypot isn’t what it used to be.

The good news is we can add more honeypots.

This is a bit more effort but can bolster the strategy’s effectiveness.

Remember to keep all honeypot names related to the other fields in the form, and we should be good to go.

I’ve been using three honey pots per form, which seems to be the sweet spot.

Let me know if you have questions.

Happy coding 🤙

I Scoured Udemy For The Best Developer Courses: Here Are The 3 Teachers That Are Worth Your Time

Jeff Jakinovich — Tue, 23 Jul 2024 01:56:52 +0000

I’ve used books, YouTube, Coursera, Udacity, CodeCademy, Treehouse, and several other platforms while learning to code.

The platform that is most responsible, however, for taking my abilities from the basics to building functional apps is Udemy. Udemy is underrated mostly because of the ranging level of quality. It is sort of the wild west. It can be hard to know what is worth your time and what isn’t.

Say no more. I’ve tested tons of different courses on Udemy so you don’t have to.

Here are the top 3 developer teachers on Udemy that are worth your time:

Angela Yu: Best for beginner web and app developers. She has a couple of great bootcamps that can get you up and running creating web apps, iOS apps, and Android apps. Her ability to use stories and visuals makes it super easy to follow along and learn fast.

Stephen Grider: Best for deep dives into the latest tools for web app development. Stephen is prolific. The amount of information he is able to cover in one course is amazing. And he has a ton of courses. Everything ranging from getting started with web app development to more advanced things like micro-services architectures. He balances nitty-gritty details with high-level visual overviews.

Jose Portilla: Best for Python developers and aspiring data scientists. Jose’s content shares a lot of the same traits as Angela and Stephen: comprehensive courses that take the complex and make it simple. If you’ve wanted to learn Python or if you know Python and want to take the next steps into data science and machine learning, I don’t know of an easier way to make that jump. You’ll be up and running in no time.

Let me know if you try out any of these teachers or have other favorites on Udemy.

Happy coding!

The Key To Growing As A Programmer? Getting Really Good At This 1 Thing

Jeff Jakinovich — Tue, 23 Jul 2024 01:39:51 +0000

This is boring advice but simple: read more documentation.

You will never memorize everything when learning to code. There is too much information. Fortunately, programmers already know this. So they created tons of documentation for the languages, libraries, and tools they built. There are literal instruction manuals for how to get better at using these technologies.

Now you just have to get comfortable reading them.

Learning to read documentation will push you to grow fast for three reasons:

1. Learning to read documentation is the equivalent of learning the rules so you can break them later

You don’t know what you don’t know when starting out.

It is hard to build things when you don’t even know what your tools or raw materials can do. After reading your programming language’s documentation for a few hours, you’ll start to get an idea of how little you know.

Don’t let this discourage you.

Instead, write down all the questions you have when you come across things that are new or don’t make sense. Then go and Google those questions.

Rinse and repeat. You’ll start to see all the new and useful ways you can use different technologies which will compound into more learning.

2. Learning to read documentation will help you write better documentation

One day you will write a useful app or tool that others are going to want to use.

How are you going to make sure they know how to use it?

Whether you are working by yourself or in a team, being able to document code in a way that is succinct and easy to understand is critical.

As you read more documentation you start to pick up on things that are helpful to you and things that are not. Remember the helpful stuff and duplicate it when writing your own documentation.

3. The more advanced you get, the fewer tutorials there are to learn from

When you start learning to code it seems like there are YouTube videos for everything you need to know.

This is true up until a point. The more advanced you get with your programming, the more complicated some of the problems become. You reach a point where there isn’t any other way to solve your problem but to scour various documentation websites for any possible hints.

One way or another, if you program long enough, you will get comfortable with documentation. So it is best to start early.

Learn to read documentation and watch your programming abilities grow fast.

Automate Lighthouse Reports For Max App Performance

Jeff Jakinovich — Mon, 22 Jul 2024 21:57:36 +0000

Imagine you build an incredible app that solves all your user’s problems. Your entrepreneur dreams are coming true. Then, one day, a line of code finds a way into your codebase that plummets page speeds. Users are waiting several seconds for each page. Users start to leave. And never come back. Your dreams are dead.

That sounds dramatic. But no one likes a poor-performing web page.

Good thing I have a solution for you.

I’m not a huge fan of setting up needless systems or automations on projects before you know whether the project has legs. But there is always one automation I add to every single repo:

Automated Lighthouse reports.

What is a Lighthouse report?

A Lighthouse report is an automated tool to help you improve your web pages. You give it a URL, and it gives you a report on key metrics that affect the quality of your web pages. The high-level report looks like this:

Each section also has more details with links to articles by Google to help you fix things that might be wrong.

You can run this report as many times as you want. But it can get annoying to run the report too often. The good news is there is a way you can automate the reports and make sure no code gets added to your repo that hurts your scores.

How to run a Lighthouse report from the command line

Install the Lighthouse CI package.

In your project, install the NPM package that helps you run the Lighthouse reports from your terminal.

npm install @lhci/cli

Create the NPM script.

Now, create a script in your package.json to run the reports locally and in the GitHub action.

"scripts": {
  "ci:lighthouse": "lhci autorun"
  },

Create the file that gives Lighthouse the instructions for what to run.

This is where all the customizations happen. You can tell Lighthouse where you want the reports to live, what type of reports to run, assertions to avoid or pay attention to, and even set benchmarks.

I’ll show you how to add all the above later, but let’s get a basic version working first.

Create a lighthouserc.js file at the root of your project.

Copy the following contents into the file. One thing to note is that the Lighthouse report will always run on the local build. So, if you haven’t built anything yet, you will need to do that first. And if you made changes, you’ll want to build again before running the reports. We will automate all this later, but it is good to be aware.

I’m using Next.js, so in the “collect” section, I set it up so Lighthouse runs the production build of my app on localhost:3000, and it runs 3 times. Then I have Lighthouse dump the reports in a directory on my root.

Depending on your tech stack and preferences, feel free to change any of these settings.

module.exports = {
  ci: {
    collect: {
    // change to however you build and run a production version of your app locally
      startServerCommand: "npm run start",
      startServerReadyPattern: "ready on",
      url: ["<http://localhost:3000>"],
      numberOfRuns: 3,
      settings: {
        preset: "desktop",
      },
    },
    upload: {
      target: "temporary-public-storage", // change to where you want the reports to live
    },
  },
};

Make sure everything is working locally.

At this point, you should have enough set up to test everything locally. Make sure to build your project, then call your NPM script we created earlier.

npm run build && npm run ci: Lighthouse

Your terminal should look something like this:

You should notice a few things:

You can see the names of any errors. You can click the link next to the name to read more about the errors so you can fix it.
If you have errors (you most likely will), your code should exit with a status code 1. When we customize our assertions next, we can make sure specific assertions don’t force our script to fail.
The final thing the report will tell you is where these reports live. You can take the HTML file and copy it into your URL, and you should be able to see the full report. All reports should live in a directory called .lighthouseci if you used the same outputs command I used when setting up the Lighthouse instructions.

Optional: make sure the Lighthouse reports don’t get added to your repo

If you want to keep these reports in your repo for any reason, feel free to skip this. Usually, these reports are short-term checks, so I never want to add them to my repo. To make sure they don’t get added to your commit, go ahead and add the .lighthouseci directory to your .gitignore

...
.lighthouseci

Customize the assertions you want in your report.

Now that we have the reports working locally, there is one more thing we can customize: assertions.

When starting a project, I primarily use Lighthouse to ensure I’m not doing anything dumb. Especially things that would cause massive performance or UX issues for the users.

This means I don’t need to address everything Lighthouse finds wrong with my web pages. But I also want to remember them.

This is where I set any assertions that need more work or more learning to warn so they don't stop my progress in building the app. Then, when things are more stable, I can come back to address any deeper issues.

To do this, review all the errors you received when running the report locally. If any of them seem like something you’d want to address later, take the name of the error, add it to your lighthouserc.js, and set it to warn.

Take, for example, this error:

I should pay attention to the total-byte-weight but I'll need to investigate further. I'd rather move on for now so I can launch my project, but I also want to remember this error. So setting it to warn allows the report to succeed while still reminding me every run.

module.exports = {
  ci: {
    collect: {
      startServerCommand: "npm run start",
      startServerReadyPattern: "ready on",
      url: ["<http://localhost:3000>"],
      numberOfRuns: 3,
      settings: {
        preset: "desktop",
      },
    },
    upload: {
      target: "temporary-public-storage",
    },
    assert: {
      preset: "lighthouse:recommended",
      assertions: {
        // add your customizations for assertions here
        "total-byte-weight": "warn",
      },
    },
  },
};

Set benchmarks to check against future changes.

This is the last step needed to set up your Lighthouse reports, and then we will automate everything.

By adding benchmarks to our setup, you can set minimum scores that must always pass. Otherwise, the Lighthouse report will give us an error.

This is critical to ensuring new code doesn’t affect the quality of your web pages.

module.exports = {
  ci: {
    collect: {
      startServerCommand: "npm run start",
      startServerReadyPattern: "ready on",
      url: ["<http://localhost:3000>"],
      numberOfRuns: 3,
      settings: {
        preset: "desktop",
      },
    },
    upload: {
      target: "temporary-public-storage",
    },
    assert: {
      preset: "lighthouse:recommended",
      assertions: {
        // add your customizations for assertions here
        "total-byte-weight": "warn",
        "categories:performance": ["error", { minScore: 0.93 }],
        "categories:accessibility": ["error", { minScore: 0.93 }],
        "categories:best-practices": ["error", { minScore: 0.9 }],
        "categories:seo": ["error", { minScore: 0.9 }],
      },
    },
  },
};

Run the Lighthouse report in GitHub actions

I’m assuming you already know what GitHub actions are. So, let’s get right into setting them up.

First, make a .github directory in your root folder with a workflows directory inside. Then, add a lighthouse.yml file to the workflows directory. It should look something like this:

Inside the lighthouse.yml file, create an action that looks like this:

name: Lighthouse CI

on: [push]

jobs:
  lighthouseci:
    name: Run Lighthouse report
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Install dependencies
        run: npm ci

      - name: Bundle and build
        run: npm run build

      - name: Run Lighthouse CI
        run: npm run ci:lighthouse

The main jobs of the action are to set up the Lighthouse report, build the code, and run the report every time you push code to the main branch.

The great thing about the benchmarks is they act as gatekeepers. If you change the trigger of the action to PRs, you can ensure any code meets the benchmarks before approval.

The output of the action should look like this:

My Lighthouse report looks like it failed. That is because my benchmarks for the main categories aren’t high enough.

Since it was only triggered on pushing to my main branch, it doesn't stop any code from merging, but at least I know what the issues are, so I can address them at some point. If the trigger was on PR, then this PR wouldn't allow the code to merge into the branch.

Wrap up

Setting all this up once makes it super easy to repeat for every project you start. It offers tons of upsides with minimal downsides or time investments.

Happy coding! 🤙

From Idea to Impact: How To Validate SaaS Product Ideas

Jeff Jakinovich — Mon, 22 Jul 2024 21:48:22 +0000

When it comes to validating product ideas, there isn’t a one-size-fits-all approach. You can’t automate it. You can’t set it and forget it.

But you can still create systems and principles to speed up the process.

Like a trail of breadcrumbs, you can create shortcuts so you don’t start from scratch every time.

What does a validation process look like?

The process of validating a product idea follows predictable steps:

Identify a specific problem
Package the problem into a solution
Distribute the solution to an audience
Collect feedback and repeat

Each step has the potential for full automation or tedious manual work. It is a spectrum.

While my system won’t look like your system (and probably shouldn’t), there are principles you can use to customize it for your situation.

What and who is validation for?

Before we get to the systems, I want to highlight an assumption and some key points.

The point of validation is to save time and money by making sure you build something people want.

Nothing more. Nothing less.

But this leads to an important distinction.

On the surface, validation is a one-way street. You create a product that gets validated in the market to figure out if it can make money.

But it is a two-way street. You may not realize it, but you are also validating whether you want to work on the product with potential customers or with the people you’d need to collaborate with to build the product for the customers.

The list of potential validations is endless. But the more time I spend on building products, the more I’ve realized how important it is to validate a product from both sides of the street.

The majority of the systems I’ve built address this framing.

Step 1: Identify a specific problem

Let’s get the bad news out of the way. Finding problems is a game of pattern recognition.

To find patterns in high-leverage problems, you must get your reps in. Have conversations, Scour Reddit, read blogs, and attend conferences and other networking events.

In short, go where your audience is and listen.

The work is simple but requires a lot of effort.

The good news is once you get your reps in, there are some helpful frameworks for making the most of them.

How to create a quality problem statement

One of the most important things is how you craft your problem statement.

Going from identifying a problem in your head to writing a clear problem statement a customer can understand can be a giant leap.

The best framework I know for how to do that is using a mix of:

Once you know both things, you can concisely describe the problem.

Here’s an example:

Job Title: Director of Customer Success
Jobs-To-Be-Done: Needs to reduce customer churn
Biggest pain point: Struggles with identifying at-risk customers early due to lack of data

As a problem statement:

Directors of Customer Success need to reduce customer churn but struggle identifying at-risk customers early due to lack of data.

Forcing the problem into a single statement means your scoping is concise enough to make meaningful progress on the rest of the steps. And it makes it a super easy thing to share with potential customers to kick off the validation process.

Pain killer vs. vitamins

The final thing to think about is the leverage of a problem. Some things an audience complains about are nice-to-haves. Other things are so painful they will throw their money at you. We want the latter.

You’ll be able to pick up on cues over time, and the more you look for problems, vitamins generally sound like “it would be nice if…” and pain pills sound like “a new compliance rule is forcing us to…”.

A key distinction is that vitamins are usually requests triggered by a user, while pain pills are requests triggered by the environment.

Step 2: Package the problem into a solution

This is the most important step.

Most of the “hidden” validation will happen here because it will force you to go from vague solutions to packaged realities.

I don’t complete everything in the list below for each idea, but I always do the first two items and then pick and choose others depending on the idea.

Things you can do to create a packaged solution

Option 1: Run the solution you have through a series of copywriting frameworks

To keep the piece short, I won’t dive into the details of the frameworks. But these frameworks are the first step to figuring out if your solution is enticing to another human.

If you struggle running your solution through these frameworks. Or if you produce copy that no other human finds interesting, it is time to move on or change your solution.

Option 2: Create an offer the user can’t say no to

As Alex Hormozi says, “The key to sales is making an offer so good people will feel stupid saying no.”

That is all I focus on here. Can I create an offer (or several) that would put one person in my persona in a position to feel stupid saying no?

I’ll focus on packaging up unique features, different pricing models, and adding incentives from different growth strategies.

If I can’t make an offer that guarantees an imaginary person says yes to my offer, why would a real person say yes once I launch it?

Option 3: Create your most emotive assets

Anyone can complete the first two exercises regardless of skill, but this is the first one that is dependent on your skillset.

I’m a developer with plenty of experience using Figma and other Adobe tools. For me to put together a quick UI flow in those tools takes almost no time. So I always start creating wireframes with a technical eye towards what is possible.

But I struggle sketching things. So, someone with more drawing ability can create sketches that could be useful to potential customers.

Or, a graphic designer can create ads to test the idea on Meta, Google, or other platforms.

Either way, the goal is simple. Producing assets is another filter to figure out if the idea has legs. And those assets can live on their own to do some of the validating for you in later steps.

Option 4: Create a landing page with a CTA for your offer

If all the other steps look promising, I will move on to this step. I understand this could sound daunting, but think loosely about the term “landing page.”

You can use services like Carrd to build legit landing pages but I’ve seen Notion pages served up and get the job done just fine.

Don’t overthink it.

The goal is to take make a place where you can take everything you completed in the earlier steps and place them all under one roof. Then have one ask where you are either asking for a sign up to a waitlist or to complete a survey about the problem. Both of which offer great signals for validation.

Now, in the distribution step, you have something you can distribute, scale, and sell for yourself. This is where the automation part of the system can start to take off.

Step 3: Distribute the solution to an audience

You need to get your copy, assets, or landing page in front of as many people in your audience as possible.

Feel free to email, text, or call anyone you know who can react to what you have but there are tools that help to speed this process up.

Here are some that I use:

LinkedIn sales navigator
Database tools with leads like Apollo
Reddit
Use advanced Google searches like: “Name of job title” forum or “Name of job title” community

Whatever tool you use, remember your problem statement in step 1. You want to search for job titles and only reach out to those job titles.

Find as many emails as possible and present your assets or problem statement. When you reach out, it’s important to be upfront with where you are in the process. Please don’t promise full-fledged platforms when you only have a logo and some copy.

If the pain is strong enough, they will be happy to build with you, which is a great sign for idea validation.

Step 4: Collect feedback and repeat

If you create a simple feedback form for the solution or the problem, it is the perfect pairing to the assets you already have.

Your CTA can be asking people to complete the form to get feedback on how you defined the problem and the solution.

Plus, like some of the other steps, writing the survey is a form of validation. If you can’t think of the most potent questions to ask about the problem or your proposed solution, it might be time to revisit step 1.

The simplest way to set this up is to create a Google Form and connect it to your assets or landing page. You can also use Zapier to connect form submissions to other tools you use to track all the responses.

I will update these tools and systems as I come across new ideas.