DEV Community: 🦁 Yvonnick FRIN

I made my first game solo with Godot for a Game jam

🦁 Yvonnick FRIN — Thu, 14 Mar 2024 10:34:30 +0000

Hey 👋 During my holidays, I participated to a gamejam. The theme was aberration 👻

Here is my submission https://itch.io/jam/acerola-jam-0/rate/2582646. It is an action-adventure game based on a short novel by Grant Allen (19th century).

Feel free to rate and leave a comment 🤗

I open sourced the code and assets: https://github.com/frinyvonnick/pallinghurst-barrow

It was a cool experience. I had the opportunity to give a try to Procreate Dreams for the animations. It was my first time making a game with Godot. It is an easy-to-learn engine. I recommend it! In the past, I participated to a game jam with a mate. This time it was solo since it is the main rule of the jam. It lasted two weeks which was really intensive for me. I did most of the assets by myself except for audio. I don't know much about it.

I recommend participating to jams. It forces you to make choices and goes straight to the point (which I struggle with most of the time)!

You can contact me on Twitter @YvonnickFrin!

Setting up the development environment for js13k

🦁 Yvonnick FRIN — Mon, 24 Aug 2020 11:19:59 +0000

This article is the second entry of a devlog on my participation to js13k competition with MogSogeking

As we start developing our game, there are some tasks we want to avoid doing manually like:

reloading our game each time we do some change;
creating our submission file;
checking if we reach the 13k limit;
deploying our game to a public url (it is nice to gather feedback during development);

Before choosing a tool to help us achieve the tasks listed above it is important to know how our code must be structured. Here is the rule of js13k competition about the folder structure.

Your .zip package should contain index.html file in the top level folder structure

Our entry point must be an index.html file that loads our JavaScript files. Parcel is a web application bundler that works with a html file as entry point. It requires almost no configuration. It seems to fit our needs so let's give it a try.

Firstly, we install this new development dependency in our project.

Development server

npm install --dev parcel-bundler

As explained in the getting started section of the documentation, the default command of the cli launchs a development server. It will rebuild our game each time we change a file and refresh the JavaScript code opened in the browser (without reloading the whole page!). We add a dev script to avoid typing this command each time we need it.

  "scripts": {
    "dev": "parcel src/index.html"
  },

Let's create a few files to test it. Here is our folder structure:

.
├── package-lock.json
├── package.json
└── src
    ├── index.html
    └── index.js

Our index.html file import our JavaScript code with a script tag.

<html>
  <body>
    <script src="./index.js"></script>
  </body>
</html>

To begin we add the well known Hello world!.

console.log('Hello world!')

We start our dev server with the following command:

npm run dev

We should see a log Hello world! in our browser console. I change the message in our console.log parameter with my first name and save the file.

console.log('Hello Yvonnick!')

Our browser has reloaded our code automatically and display the updated log 🎉

Submission file

Our development server is set up. We need to generate our submission file which is a zip file containing our index.html, JavaScript files and other assets.

build

The js13k rules says we can optimize our JavaScript code.

You can use tools that minify JavaScript source code.

Parcel cli has a build command for this purpose. We add a few options to make it fill our needs.

  "scripts": {
    "dev": "parcel src/index.html",
    "build": "parcel build src/index.html --no-source-maps --experimental-scope-hoisting --public-url ./",
  },

Let's get some explanations about these options.

--public-url option

Parcel prefixes the filename of the bundled javascript file with public-url in the index.html script tag. This option defaults to /. It is fine for a website stored on a static server.

when unzipped should work in the browser.

If we try to open the built index.html we will see a blank page. Because the path of our JavaScript file is /src.9905d997.js. It will look for our JavaScript file at system root. Setting public-url to ./ will fix this issue since it will look for our JavaScript file in the current folder. Now, it works just fine when we open the built index.html.

--no-source-maps option

Source maps are files which reference a readable version of production that are most of the time minified. It helps us tracking bugs in our production bundle. Since our final zip size matters we don't want to include unnecessary files in it so we disable this feature.

--experimental-scope-hoisting option

This option enables tree shaking during the build process. Tree shaking is a feature that prevents unused code of our dependencies being part of our production bundle. You can find out more in this article of Devon Govett.

zip

At last, we add a zip script which creates a zip file with the content from dist folder that is the output of our build command.

  "scripts": {
    "dev": "parcel src/index.html",
    "build": "parcel build src/index.html --no-source-maps --experimental-scope-hoisting --public-url ./",
    "zip": "zip -r submission.zip dist"
  },

Now, we can create our submission file using scripts 👌

Adding a CI/CD

There are two last points to deal with:

checking if we reach the 13k limit
deploying our game to a public url (it is nice to gather feedback during development)

We don't want to figure out at the end of the competition that our submission file doesn't not fit the requirements. We don't want either to type our commands manually each time we commit some change. Since we need to host our source code on Github we will use GitHub Actions to automate it.

Please provide two sources of your game - first one should be minified and zipped to fit in the 13 kB limit (sent via the form) and the second one should be in a readable form with descriptive variable names and comments (hosted on GitHub).

I wont explain how GitHub Actions works but you can find a lot of nice articles on dev.to on this topic.

Checking our submission file size

First of all, we need to add a script that checks our submission file size. We will use bundlesize to achieve it. It needs a bit of configuration (the file path to test, the max size it must not reach). We add it directly in our package.json file.

"bundlesize": [
  {
    "path": "submission.zip",
    "maxSize": "13 kB"
  }
],

Then, we add a size script that calls bundlesize. It will throw an error if the zip file weight more than 13 kB.

"scripts": {
  // ...
  "size": "bundlesize"
}

We create a first action in the file .github/workflows/ci.yml that will call our freshly created size script with the following content:

name: CI
on:
  pull_request:

jobs:
  size:
    runs-on: ubuntu-latest
    env:
      CI: true

    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: npm ci
      - run: npm run build
      - run: npm run zip
      - run: npm run size

We trigger this action only on pull request.

on:
  pull_request:

We create the zip file.

      - run: npm ci
      - run: npm run build
      - run: npm run zip

Finally, we run our size script which will prevent us to merge if it fails.

      - run: npm run size

Now, our CI checks for us our submission file size at each commit on pull request.

Deploying our game

Cherry on the cake, we want to deploy our game on a public url so we can share it with friends to gather feedback during development. We create our second action in the file .github/workflows/deploy.yml with the following content:

name: Deploy
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
        - uses: actions/checkout@v1
        - run: npm ci
        - run: npm run build
        - uses: JamesIves/github-pages-deploy-action@3.5.9
          with:
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            BRANCH: gh-pages # The branch the action should deploy to.
            FOLDER: dist # The folder the action should deploy.

We trigger this action only on master branch.

on:
  push:
    branches:
      - master

We use the action github-pages-deploy-action from James Ives which deploy our code on GitHub Pages. Our app will be available at the url https://[your-handle].github.io/[repository-name] in my case https://frinyvonnick.github.io/js13k-2020.

We are all set 🙌 We can now develop our game at peace!

Follow me on dev.to or twitter if you want to be informed when a new blogpost of this serie is published!

I participate in js13k this year

🦁 Yvonnick FRIN — Fri, 21 Aug 2020 07:45:21 +0000

I'm glad to announce I will participate in js13k this year with my buddy MogSogeking.

What is js13k?

js13k is a game jam! But, what is a game jam? It is a competition where participants try to create a game from scratch in a limited time. js13k lasts a whole month and has a specific limitation. Your game must not weight over 13kb. Each year edition has a theme. This year's theme is 404.

Why do I say it to you?

I plan to share with you things I learn during this journey here on dev.to. It will be mostly things on programming but also water cooler topics on graphism and music.

Where can you track our progress?

One rule of js13k competition is to share a readable form of your code on Github. Here is our repository. We will work with pull requests so feel free to sneak around and leave comments 😉

The first blogpost on this journey will be about our project's development environment. Follow me on dev.to or twitter if you want to be informed when a new blogpost is published!

node-html-to-image v1.2 is out 🎉

🦁 Yvonnick FRIN — Fri, 27 Mar 2020 11:03:54 +0000

Sometime ago, I wrote a small module called node-html-to-image. It generates images from HTML in Node.js. For more information, here is an article that explains how to use it. This week, it has been featured in NodeWeekly 🎉

This week, I also released version 1.2. Let's see what's new in node-html-to-image.

✨ Transparency support

This feature was asked by jordan314. It wasn't possible to have a transparent background for png images. Here is an example to achieve it with the new transparent option:

const nodeHtmlToImage = require('node-html-to-image')

nodeHtmlToImage({
  output: './image.png',
  type: 'png',
  transparent: true,
  html: '<html><body>Hello world!</body></html>'
})
  .then(() => console.log('The image was created successfully!'))

📝 Improve documentation

Users frequently asked me two questions about node-html-to-image usage:

How to use locally stored images?
How to set my image resolution?

I added two sections directly in the README that answer these questions (image resolution and dealing with images).

I hope it will help 🙏

♻️ Simplify test setup

I use tesseract to test the module works fine. It was tricky to install the engine on your computer in order to run tests. I moved to tesseract.js which is a Javascript port of this OCR engine. Running yarn installation command is now enough to setup the project before running tests.

💻 The CLI has been released too!

node-html-to-image has its own CLI. I think it is a good way to quickly give a try to the module.

What's new in `node-html-to-image-cli` v1.1:

Add an option to provide content

It is now possible to use handlebars with the CLI too. Here is an example:

npx node-html-to-image-cli ./index.html ./image.png --content ./content.json

index.html:


<!DOCTYPE html>
<html>
  <body>
    <h1>Hello {{you}}</h1>
  </body>
</html>

content.json:

{ 
  "you": "world"
}

Thanks to Julien Tanguy 🙏

Add an option to support transparency

I also added an option transparent to enable support of transparency in the CLI too:

npx node-html-to-image-cli --type png --transparent ./index.html ./image.png

Feel free check out the GitHub repositories if you are interested:

Want to support ? Don't forget to leave a ⭐️

Feedback or ideas are appreciated 🙏 Please tweet me if you have questions @YvonnickFrin!

A guide on commit messages

🦁 Yvonnick FRIN — Wed, 29 Jan 2020 13:11:00 +0000

The comic is from Daniel Stori. It is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

The time you had an archive file on your disk called "version 1" should be far away. I bet you use some tool for version control like GitHub, Gitlab, Bitbucket, ... So you must write commits everytime you want to add your code to a project. Have you ever wondered if your commits messages are good? Maybe you don't like writing them and wonder why you have to do it every time you want to push code. After all, isn't the change sufficient enough?

In this article, we will talk about writing good commit messages, and not good commits, even if these two subjects are closely linked (here is a good article from Tobias Günther that summarize well best practices about version control).

Why commit messages are important?

So, is the change sufficient? Obviously, the answer is no. But why?

Commit messages have a lot of uses. This is the first way to communicate with your fellow developers on a project. The change defines how you achieve something but the commit message explains why you are doing it. It must give enough context to avoid a developper to wonder why some code is written like that. With proper explanations you won't spend precious time asking yourself why a developer pushed this code. In some cases like open source projects, busy maintainers won't even read your code if you don't give them a minimum of information like a nicely written commit message.

Commit messages are not only for your coworkers but also for your future self as Peter Hutterer said in this great article On commit messages.

Any software project is a collaborative project. It has at least two developers, the original developer and the original developer a few weeks or months later when the train of thought has long left the station.

Peter Hutterer - On commit messages

A project is designed to be maintained in the long term. Sometimes years after a piece of code was written, you may ask yourself why it has been written like that. It happened to me this week with a function I coded only 6 months ago. With a well written commit message, it is easier to get back in the state of mind at the time you wrote this change.

Taking care of your commit messages can also simplify your daily life. Some tools becomes more interesting with a meaningful commit history like a few git commands log, rebase, cherry-pick, ... When you come back from holidays a simple git log --pretty will give you a lot of information about what your coworkers did while you were away. Writing good commit messages forces you to split your change, making it easier to review with git log -p.

Speaking of review, did you ever struggle rebasing your code on some change a developer made? It becomes easier to know why a change was made if the commit message carries real meaning. It makes rebase result much more predictible. Another example is git blame command which, by the way, isn't there to make fun of your colleagues, but to give you context on a specific line of code. It can be pretty useful when you want to refactor a piece of code.

Last but not least, a well structured commit history allows changelog generation between two versions of your project to inform your users what changed.

This is a huge amount of reasons to start taking time to write good commit messages.

How to write a good commit message

Now that you are convinced commit messages are important, let's talk about how to write good ones. I picked commit messages from a project I work on called immutadot. As you can see, these commit messages are not consistent, which makes them hard to read.

fix #72 unnecessary object copies
Fixing unshift documentation examples
seq.chain path parameter fix #18
Remove built files
Add tests
Add Circle CI base config
Rename es -> src
Add lang package with toggle, fix exports
Core package

In these commit messages, we can see a few mistakes in term of style, content and metadata. Chris Beams accurately describes these three points in his article How to Write a Git Commit Message.

Style. Markup syntax, wrap margins, grammar, capitalization, punctuation. Spell these things out, remove the guesswork, and make it all as simple as possible. The end result will be a remarkably consistent log that’s not only a pleasure to read but that actually does get read on a regular basis.

Content. What kind of information should the body of the commit message (if any) contain? What should it not contain?

Metadata. How should issue tracking IDs, pull request numbers, etc. be referenced?

Chris Beams - How to Write a Git Commit Message

We can see there are capitalized messages, metadata for only two commits... Eventually, some messages content are so light we can't figure out what the commit does. In the same article, Chris goes through 7 rules to write a good commit message :

Separate subject from body with a blank line

Limit the subject line to 50 characters

Capitalize the subject line

Do not end the subject line with a period

Use the imperative mood in the subject line

Wrap the body at 72 characters

Use the body to explain what and why vs. how

Chris Beams - How to Write a Git Commit Message

I personnally apply a subset of these rules:

Limit the subject line to 50 characters
Capitalize the subject line
Use the imperative mood in the subject line

Not only does the character limit force you to be concise, which is a great skill, but it fits well with a lot of tools as explained in Tim Pope article A Note About Git Commit Messages.

I tend to think the perfect is the enemy of the good. That is why I omitted talking about commit messages body. I think we have enough work to do on the summary line. But I would add one rule as counterpart:

Add a pull request/merge request tracking ID

Most of the time, we use tools to discuss during a code review process like GitHub, Gitlab, ... All pieces of information about the change will be at least described there. I added this rule about tracking ID so it becomes easy to find related pull/merge request. Writing a commit body is better than adding tracking IDs because if you change your repository manager solution, you will lose all this precious context information and your tracking IDs will be useless.

Here is a more recent example from a project I work on called gitmoji-changelog that follow these rules:

Make core independent from the git client (#171)
Upgrade Docker image version (#167)
Add maven preset (#172)
Add a generic preset using configuration file (#160)
Improve error messages for preset system (#161)
Publish Canary version on master push (#141)

Having a consistent style makes it much more easier to read. You can figure out the context of the change, and metadata are directly accessible. The most important thing is to find common rules in your team to ensure having a well structured commit history. There are some conventions that can help you finding these but we will be back on this subject later.

If you have difficulties to find out what message you should write, maybe you should split your commit in smaller parts. Peter Hutterer listed in his article On commit messages a few examples where it is difficult to find out a good commit message because your commit patch may not be logical.

Bonus

If you use practices like pair or mob programming, don't forget to add your coworkers names in your commit messages:

$ git commit -m "Refactor usability tests.
>
>
Co-authored-by: name <name@example.com>
Co-authored-by: another-name <another-name@example.com>"

Commit conventions

As written in the previous section, you should define a commit convention for your team. It exists open source commit conventions that could be a good source of inspiration. They also come with a whole ecosystem that includes tools to help you write commit messages, generate changelog, create releases, ... A lot of things that can take a large amount of time. There are well documented so you don't have to write documentation about your own commit message convention.

We will talk about two of them Conventional Commits and gitmoji.

Conventional Commits

It is a specification inspired from Angular commit message guidelines. It features a few interesting rules like:

Commit must be prefixed with a type (feat, fix)
A scope may be provided to point out a specific section of a the codebase (really interesting for monorepos)
Breaking changes must be included in a footer section

Here is how a commit message must be structured using this specification:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Read more in their specification section.

gitmoji

I'm fond of gitmoji commit convention. It lies on categorizing commits using emojies. I'm a visual person so it fits well to me but I understand this convention is not made for everyone.

I was not totally honest in my previous commit examples from gitmoji-changelog. There is a missing part as you should have guessed now.

:recycle: Make core independent from the git client (#171)
:whale: Upgrade Docker image version (#167)
:sparkles: Add maven preset (#172)
:sparkles: Add a generic preset using configuration file (#160)
:recycle: Improve error messages for preset system (#161)
:construction_worker: Publish Canary version on master push (#141)

These text aliases are widely used in tools like Slack, Discord, ... Most of the repository manager tools like GitHub or GitLab interprets them and display it well in their UI:

♻️ Make core independent from the git client (#171)
🐳 Upgrade Docker image version (#167)
✨ Add maven preset (#172)
✨ Add a generic preset using configuration file (#160)
♻️ Improve error messages for preset system (#161)
👷‍♂️ Publish Canary version on master push (#141)

I like this convention because I know at first glance what kind of change do a commit. It comes with a cli called gitmoji-cli that helps you write your commit messages and I made a changelog generator for it.

There are more of them. Keep in mind that these are guidelines, you can mix them to get something that fills your need. For example, using gitmoji convention with the scope notion of conventional commits if you work on a monorepo.

Feedback is appreciated 🙏 Please tweet me if you have any questions @YvonnickFrin!

Share good resources to start with Ember.js

🦁 Yvonnick FRIN — Wed, 22 Jan 2020 12:46:42 +0000

Hi 👋

Next month, I will start to work for a new customer. Their project is made with Ember.js so I need to learn developing with this framework. When I learn something new I like to have a side project that keeps me motivated. So yesterday, I bootstrapped a website with ember-cli for my project gitmoji-changelog. In a couple of hours, I made a working MVP 🎉 (if you are interested in making a code review here is the pull request). Here is the result (this is still a work in progress):

I only used the documentation to achieve it which is really nice! I don't like to look for basics in a search engine when I start learning a new framework. The work done on documentation is really impressive. There are still a lot of things I need to read in it. But... I want more!

I'm looking for more resources to learn about good practises, architecture, ... I found an awesome-ember repository but there are a lot of links! I don't know where to start.

What are your recommended resources for beginners that want to learn more about advanced topics on Ember.js?

react-simple-infinite-loading v1 is out 🎉

🦁 Yvonnick FRIN — Wed, 15 Jan 2020 12:47:53 +0000

react-window is an awesome tool but it can be a bit verbose when implementing infinite loading list. Here is an example. react-simple-infinite-loading is a component that handles code complexity for you. It is a wrapper around three libraries from Brian Vaughn:

react-window is made to display efficiently large lists. It only creates components for the visible elements and reuse nodes.
react-window-infinite-loader is a HOC that loads elements just-in-time as user scrolls down the list
react-virtualized-auto-sizer helps you displaying your list so it fits the space available in its parent container.

v1 is out!

The component now have a complete set of features:

Load items as the user scrolls down
Use internal methods to scroll programmatically or reset cached items
Override default scrollbar style

Usage

Let's go through the minimal example.

import React from 'react'

import InfiniteLoading from 'react-simple-infinite-loading'

function Example({ items, fetchMore, hasMore }) {
  return (
    <div style={{ width: 300, height: 300 }}>
      <InfiniteLoading
        hasMoreItems={hasMore}
        itemHeight={40}
        loadMoreItems={fetchMore}
      >
        {items.map(item => <div key={item}>{item}</div>)}
      </InfiniteLoading>
    </div>
  )
}

react-simple-infinite-loading requires four properties:

children: It should be an array of JSX nodes.
hasMoreItems: this property determine if the user reached the end of the list so it prevents him to scroll further.
itemHeight: it is mandatory to optimize number of elements rendered and determine if more rows need to be loaded.
loadMoreItems: a callback function the component will call when more rows need to be loaded.

I hide loadMoreItems function implementation on purpose since it depends on your context. It may be a fetch call, GraphQL query, database access, whatever you want. You can see a complete example using Star Wars API in the documentation.

Override default scrollbar style

react-simple-infinite-loading use react-custom-scrollbars under the hood to override native scrollbar style. You need to add the prop customScrollbar to enable it.

import React from 'react'

import InfiniteLoading from 'react-simple-infinite-loading'

function Example({ items, fetchMore, hasMore }) {
  return (
    <div style={{ width: 300, height: 300 }}>
      <InfiniteLoading
        hasMoreItems={hasMore}
        itemHeight={40}
        loadMoreItems={fetchMore}
        customScrollbar
      >
        {items.map(item => <div key={item}>{item}</div>)}
      </InfiniteLoading>
    </div>
  )
}

Display a placeholder while loading more rows

You can set a placeholder property that will be displayed while the rows are loading. By default it adds an extra row at the end of the list with the placeholder node as content.

import React from 'react'

import InfiniteLoading from 'react-simple-infinite-loading'

function Example({ items, fetchMore, hasMore }) {
  return (
    <div style={{ width: 300, height: 300 }}>
      <InfiniteLoading
        hasMoreItems={hasMore}
        itemHeight={40}
        loadMoreItems={fetchMore}
        placeholder={<div>Loading...</div>}
      >
        {items.map(item => <div key={item}>{item}</div>)}
      </InfiniteLoading>
    </div>
  )
}

If you want to have a placeholder by row that will be loaded you need to provide the optional property itemsCount (It only works if you know the number of rows in advance). There is a counterpart, you will need to have a more fine-grained implementation of loadMoreItems callback. This function takes as parameter a start index and a end index of rows that need to be loaded.

Call internal methods

react-window and react-window-infinite-loader exposes a few methods to manipulate the list programmatically. You can use it through a ref.

You have access to three methods:

scrollTo(scrollOffset: number): void - Scroll to a specified offset.
scrollToItem(index: number, align: string = "auto"): void - Scroll to a specified item.
resetloadMoreItemsCache(): void - Clear previously loaded items from cache.

Here is an example with the scrollTo method.

function Example({ items, fetchMore, hasMore }) {
  const ref = React.useRef()
  const scrollToTop = () => {
    if (ref.current) {
      ref.current.scrollTo(0)
    }
  }

  return (
    <>
      <button onClick={scrollToTop}>Scroll to top</button>
      <div style={{ width: 300, height: 300 }}>
        <InfiniteLoading
          hasMoreItems={hasMore}
          itemHeight={40}
          loadMoreItems={fetchMore}
          ref={ref}
        >
          {items.map(item => <div key={item}>{item}</div>)}
        </InfiniteLoading>
      </div>
    </>
  )
}

If you are interested feel free to give it a try!

Repository: https://github.com/frinyvonnick/react-simple-infinite-loading

Feedback and contributions are appreciated 🙏 Please tweet me if you have any questions @YvonnickFrin!

Hope it will help!

Shutdown correctly Node.js app

🦁 Yvonnick FRIN — Thu, 09 Jan 2020 12:19:23 +0000

Photo by Aleksandar Cvetanovic on Unsplash

It is important to shutdown correctly your apps to handle well processing requests and prevent it to accept new ones. I'll take a web server as example.

const http = require('http');

const server = http.createServer(function (req, res) {
  setTimeout(function () {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
  }, 4000);
}).listen(9090, function (err) {
  console.log('listening http://localhost:9090/');
  console.log('pid is ' + process.pid);
});

As we see our server doesn't shutdown properly and processing requests don't get right responses. First of all we need to understand how a Node process is terminated in order to fix it.

A process receives a signal when it is about to be killed. They are different kind of signals. We will focus on three of them in particular:

SIGINT: Quit from keyboard (Ctrl + C).
SIGQUIT: Quit from keyboard (Ctrl + \). It also produce a core dump file.
SIGTERM: Quit from operating system (using kill command for example).

Node.js emits events when the process receives signals. You can write a handler for these events. In this one we will close our server so it deals with pending requests and prevent getting new ones.

// ...
function handleExit(signal) {
  console.log(`Received ${signal}. Close my server properly.`)
  server.close(function () {
    process.exit(0);
  });
}

process.on('SIGINT', handleExit);
process.on('SIGQUIT', handleExit);
process.on('SIGTERM', handleExit);

Now our server handles well the request then shutdown correctly. You can read more in Nairi Harutyunyan's nice article. It explain in details how to shutdown properly a server with a database.

It also exists an node module that handles this logic for you called death (made by JP Richardson).

const ON_DEATH = require('death')

ON_DEATH(function(signal, err) {
  // clean up code here
})

Sometimes it is not enough

I ran into a situation recently where my server needed to accept new requests in order to shutdown properly. I'll give some explanations. My server subscribed to a webhook. This webhook has a limited quota of subscriptions. So if I don't want to exceed this quota I need to unsubscribe properly when my server shutdown. Here is the unsubscription workflow:

Send a request to the webhhook to unsubscribe
The webhook sent a request to the server to confirm unsubscription
The server must respond with a specific token to validate the unsubscription

A Node.js process will close automatically if its event loop is empty. As you can see between 1. and 2. the event loop is empty so the process will be terminated and we won't be able to unsubscribe successfully.

Here is the new server codebase we will use:

const server = http.createServer(function (req, res) {
  const params = qs.decode(req.url.split("?")[1]);
  if (params.mode) {
    res.writeHead(200);
    res.write(params.challenge);
    res.end();
  } else {
    let body = "";
    req.on("data", chunk => {
      body += chunk;
    });
    req.on("end", () => {
      console.log('event', JSON.parse(body))
      res.writeHead(200);
      res.end();
    });
  }
}).listen(9090, function (err) {
  console.log('listening http://localhost:9090/');
  console.log('pid is ' + process.pid);
  fetch('http://localhost:3000/webhook?mode=subscribe&callback=http://localhost:9090')
});

There are two changes. When the server starts listening on port 9090 we send a first request to subscribe our server to the webhook.

// ...

fetch('http://localhost:3000/webhook?mode=subscribe&callback=http://localhost:9090')

// ...

We also changed our server's request handler to let him confirm the subscription to the webhook by responding with the token called challenge.

// ...

if (params.mode) {
  res.writeHead(200);
  res.write(params.challenge);
  res.end();
} else {
 // ...
}

// ...

Let's change the handleExit function's implementation to send a request to our webhook. We ask the webhook to unsubcribe our server.

function handleExit(signal) {
  console.log(`Received ${signal}. Close my server properly.`)
  fetch('http://localhost:3000/webhook?mode=unsubscribe&callback=http://localhost:9090')
}

We need to update the code that responds with the challenge to kill our server's process when the webhook confirms the unsubscription.

// ...

if (params.mode) {
  res.writeHead(200);
  res.write(params.challenge);
  res.end();
  if (params.mode === 'unsubscribe') {
    server.close(function () {
      process.exit(0);
    });
  }
} else {
  // ...
}

// ...

When the webhook confirms the unsubscription, we close our server so it stops getting new requests and exits our process properly. This is how the Twitch API webhooks subscription/unsubscription works.

Let's see how our server acts when we try to shut it down. I added some logs to make it more visual.

As you can see, it doesn't shutdown properly. The server's process is terminated before we get the webhook request that confirms unsubscription. So the webhook keeps sending events to our server.

To fix this we need to prevent the Node.js process from exiting. We can use the method process.stdin.resume that causes the process to pause and override disable default behavior like exiting on Ctrl+C.

const http = require('http');

process.stdin.resume();

// ...

And now?

Nice, it now waits for the confirmation before exiting the process.

I made a repository with all the sources presented in this article.

Hope it will help 🙌

Feedback is appreciated 🙏 Please tweet me if you have any questions @YvonnickFrin!

What would you like to learn in 2020?

🦁 Yvonnick FRIN — Wed, 01 Jan 2020 15:04:47 +0000

As developers we have to learn new things on a daily basis. It is a being a while since I want to learn something not related to my current work. I'm interested in the idea of learning a new language. I mainly code in JavaScript it could be refreshing to see other syntaxes. I guess it will be my main goal this year.

What is the thing you absolutely want to learn in 2020?

OCR in JavaScript with Tesseract.js

🦁 Yvonnick FRIN — Tue, 24 Dec 2019 09:21:30 +0000

Photo by Mark Rasmuson on Unsplash.

While making node-html-to-image I came across a small problem. How to test it actually works? node-html-to-image is a Node.js module that generates images (png, jpeg) from HTML. If you want to learn more about it I wrote a small article about this module. The simplest test I could imagine to ensure it works was creating an image from an HTML string containing "Hello world!". Then I could check the image really contains this string using OCR.

What is OCR?

OCR stands for optical character recognition. This technology let you extract text from an image. It can be handrwritten or printed text. OCR involves a lot a complex steps to actually get text from an image but it isn't the prupose of this article. You can learn more reading its wikipedia's article.

We will focus on how to use it with the most popular open source OCR engine, Tesseract. As a lib it is available for C/C++ developpers. Fortunately, it exists a port in JavaScript.

Installation

Tesseract.js doesn't need you to install anything on your computer unlike node-tesseract-ocr. It also means it doesn't work offline. node-tesseract-ocr is only a wrapper around tesseract so you need to install tesseract and tesseract-lang on your computer. While Tesseract.js downloads languages and core scripts on the go.

The only thing you need to do is installing npm package Tesseract.js using your favorite package manager:

# With yarn
yarn add tesseract.js
# With npm
npm install tesseract.js

How to use

Here is the image we will try to extract text from.

Let's go through it step by step.

First of all we need to import the createWorker function.

const { createWorker } = require('tesseract.js')

We call it to create a new tesseract worker which is a Child Process in Node.js and a Web Worker in the browser (yes, Tesseract.js also work in the browser).

const worker = createWorker()

A worker instance have several methods. The first we need to call is the load function. It loads core scripts and prepare tesseract worker for what's coming next.

// ...

async function getTextFromImage() {
  await worker.load()
}

Then, we need to load the language of the text in our image. We can achieve it with loadLanguages method. I will download a file with trained date for the language in it. In our example, it will be a file called eng.traineddata. We can load more than one language using + character (ex: eng+fr).

// ...

async function getTextFromImage() {
  await worker.load()
  await worker.loadLanguage('eng')
}

Time to make our worker ready to do OCR tasks. We do it with the initialize method. It takes language we want to use as parameters. It can be a subset of the languages we loaded earlier.

// ...

async function getTextFromImage() {
  await worker.load()
  await worker.loadLanguage('eng')
  await worker.initialize('eng')
}

Let's do OCR! Our worker has a recognize method that takes an image as parameter. It can be an url, a path on the file system or a buffer. It returns a object with a data property that also is an object with a text property in it containing the final result.

// ...

async function getTextFromImage() {
  await worker.load()
  await worker.loadLanguage('eng')
  await worker.initialize('eng')

  const { data: { text } } = await worker.recognize('./hello-world.png');
}

Last step we need to clean up our worker using the method terminate.

// ...

async function getTextFromImage() {
  await worker.load()
  await worker.loadLanguage('eng')
  await worker.initialize('eng')

  const { data: { text } } = await worker.recognize('./hello-world.png');

  await worker.terminate()

  return text
}

Let's test it! we call our function and print the result to the output.

getTextFromImage()
  .then(console.log)

As you call your script you should get the following result.

~ ❯ node tesseract.js                                                                                                                                                   ⏎
HELLO WORLD!

Nice, but it didn't find all the text from our image...

By default, Tesseract works in SINGLE_BLOCK mode. A worker instance has a setParameters that let you change Tesseract default behavior. In our case we want to change the tessedit_pageseg_mode parameter value. Before doing it we need to import the PSM enumeration (this is an acronym for page segmentation mode).

const { createWorker } = require('tesseract.js')
const PSM = require('tesseract.js/src/constants/PSM.js')

// ...

Finally, we call setParameters method with the wanted mode. For the example, we will use AUTO mode and let the engine find all lines.

// ...

async function getTextFromImage() {
  await worker.load()
  await worker.loadLanguage('eng')
  await worker.initialize('eng')
  await worker.setParameters({
    tessedit_pageseg_mode: PSM.AUTO,
  })

  const { data: { text } } = await worker.recognize('./hello-world.png');

  await worker.terminate()

  return text
}

// ...

By calling your should get a different result.

~ ❯ node tesseract.js                                                                                                                                                   ⏎
HELLO WORLD!

made with € by node-html-to-image

As you can see it find the whole text. It seems to have difficulties to identify the emoji character but it is a pretty impressive result.

Here is the final code:

const { createWorker } = require('tesseract.js')
const PSM = require('tesseract.js/src/constants/PSM.js')

async function getTextFromImage() {
  await worker.load()
  await worker.loadLanguage('eng')
  await worker.initialize('eng')
  await worker.setParameters({
    tessedit_pageseg_mode: PSM.AUTO,
  })

  const { data: { text } } = await worker.recognize('./hello-world.png');

  await worker.terminate()

  return text
}

getTextFromImage()
  .then(console.log)

There are a lot more examples in Tesseract.js documentation with extra features like:

progress
multi languages
whitelist char
And more...

If you are curious to see how I tested node-html-to-image. You can find the source here.

You're set 🙌 Hope it will help you!

Happy Holidays 🎉

Feedback or ideas are appreciated 🙏 Please tweet me if you have questions @YvonnickFrin!

Generate images from HTML in Node.js

🦁 Yvonnick FRIN — Wed, 18 Dec 2019 08:45:35 +0000

As developers, we don't have great skills with image manipulation softwares, but we still need it. In my case I had to generate Twitter cards for social media and flyers for the meetup I co-organize. An important point for use is automation. So I wanted a solution that let me make a template and generates a lot of images without extra work.

That is why I created node-html-to-image. A Node.js module that generates images from HTML.

Here is the simplest example, you provide an output path and a HTML string. That's all!



const nodeHtmlToImage = require('node-html-to-image')

nodeHtmlToImage({
  output: './image.png',
  html: '<html><body>Hello world!</body></html>'
})
  .then(() => console.log('The image was created successfully!'))

I talked about automation earlier. It comes with a templating engine, Handlebars. It enables creating multiple images using the same template.

In the following example, we changed world by a placeholder and inject its value with the content option.



const nodeHtmlToImage = require('node-html-to-image')

nodeHtmlToImage({
  output: './image.png',
  html: '<html><body>Hello {{name}}!</body></html>',
  content: { name: 'you' }
})
  .then(() => console.log('The image was created successfully!'))

You want to generate images from HTML without writing a line of code? No problem, I also made a cli that use node-html-to-image underneath called node-html-to-image-cli.



npx node-html-to-image-cli index.html image.png

Generated image:

Feel free check out the GitHub repositories if you are interested:

Want to support ? Don't forget to leave a ⭐️

Feedback or ideas are appreciated 🙏 Please tweet me if you have questions @YvonnickFrin!

DevTips: Use early returns to avoid nested conditions

🦁 Yvonnick FRIN — Thu, 12 Dec 2019 12:41:10 +0000

As a developper, you will encounter some patterns you should identify as code smells. Most of them have well known solutions. Today I want to talk about using early returns to avoid else statements and nested conditions.

Let's take a example. I need to call a server to know if a person already exists in my database. The function that makes the call also return a loading indicator so I can inform the user.

render() {
  const personToLookFor = 'Thierry'
  const [result, loading] = doesPersonExists(personToLookFor)

  if (!loading) {
    let message
    if (result) {
      message = `${personToLookFor} already exists.` 
    } else {
      message = `${personToLookFor} doesn't exist.`
    }
    return message
  } else {
    return 'Loading...'
  }
}

As you can see the nested conditions and if/else statements are hard to read. You don't really understand what does this piece of code at first glance. I bet you already run into this pattern before. Let's refactor this a bit to make it more maintainable!

If the call is still pending we can directly quit the function and display the loading indicator.

render() {
  const personToLookFor = 'Thierry'
  const [result, loading] = doesPersonExists(personToLookFor)

  if (loading) return 'Loading...'

  let message
  if (result) {
    message = `${personToLookFor} already exists.` 
  } else {
    message = `${personToLookFor} doesn't exist.`
  }
  return message
}

Isn't it a bit clearer? We can also get rid of the else statement by returning directly the message in the if statement.

render() {
  const personToLookFor = 'Thierry'
  const [result, loading] = doesPersonExists(personToLookFor)

  if (loading) return 'Loading...'

  if (result) {
    return `${personToLookFor} already exists.` 
  }
  return `${personToLookFor} doesn't exist.`
}

It also removes the necessity to have a message variable. You're set 🙌

Hope it will help you!

Feedback is appreciated 🙏 Please tweet me if you have any questions @YvonnickFrin!

DEV Community: 🦁 Yvonnick FRIN

I made my first game solo with Godot for a Game jam

Setting up the development environment for js13k

Development server

Submission file

build

--public-url option

--no-source-maps option

--experimental-scope-hoisting option

zip

Adding a CI/CD

Checking our submission file size

Deploying our game

I participate in js13k this year

What is js13k?

Why do I say it to you?

Where can you track our progress?

node-html-to-image v1.2 is out 🎉

✨ Transparency support

📝 Improve documentation

♻️ Simplify test setup

💻 The CLI has been released too!

What's new in node-html-to-image-cli v1.1:

Add an option to provide content

Add an option to support transparency

A guide on commit messages

Why commit messages are important?

How to write a good commit message

Bonus

Commit conventions

Conventional Commits

gitmoji

Share good resources to start with Ember.js

react-simple-infinite-loading v1 is out 🎉

v1 is out!

Usage

Override default scrollbar style

Display a placeholder while loading more rows

Call internal methods

Shutdown correctly Node.js app

Sometimes it is not enough

What would you like to learn in 2020?

OCR in JavaScript with Tesseract.js

What is OCR?

Installation

How to use

Generate images from HTML in Node.js

DevTips: Use early returns to avoid nested conditions

What's new in `node-html-to-image-cli` v1.1: