DEV Community: Holy-Elie Scaïde

The usage of React Hooks

Holy-Elie Scaïde — Mon, 07 Feb 2022 20:25:01 +0000

Functional components were a part of React before the introduction of Hooks. But their usage was restricted to creating pure components, as they did not possess the more complex lifecycle and state management of a class component. Hooks add these to functional components and allow us an easier way to reuse functionalities.

What are hooks? Hooks are functions. And like all functions, you provide them with arguments, and they return values. To understand the usage of hooks is to understand where your arguments and the returned values fit into your component usage.

Let's start with the basic: the function component. It accepts props as parameters and return a component tree. You can take the following as an example.

const Message = (props) => {
  return <p>{props.text}</p>
}

A bare component should be pure. If the props object does not change — by altering the text prop —, neither should the returned component tree. The lifecycle is the stages a component goes through from creation to deletion. For a functional one, the lifecycle is another execution of the component’s code. Mutating the props can trigger this new execution.

What if you want to change the color of the text when the user clicks on it? You could add a new prop called color, but the parent component will then be responsible for updating this new prop. The consequence is a tight coupling — one depends on the other — between the two components. The parent will have the code to declare and update the prop, while our component is the one using it and is responsible for triggering the change. To resolve the situation, we shall use the state concept.

To explain state, we can take water as an analogy. Water can have multiple aspects: liquid, vapor, and ice. Which all depends on the same measure inherent to the water — temperature. In other words, the temperature of the water determines the current state of the water. And if we know the current value of the temperature, it’s easy to know its aspect. Like temperature, our above component can have a variable called color which will always be the current color of the text. But, this has its limitations.

If we create the variable inside the function of the component, it will be deleted when the function returns. And props are currently the only way we're able to update the component. This is where useState comes in. ** useState** will provide you with a value that will not be destroyed when the function ends and, when changed, will trigger an update for the component — the function of the component will be executed again. useState returns an array: The first element is our value, the second is the function to update the value. Assigning a new value directly will not work. This is our updated component:

 const Message = (props) => {
    const [color, setColor] = useState('blue');
    const handleClick = () => {
        setColor(color === 'blue' ? 'red' : 'blue');
    }
    return (
        <p style={{color: color}} onClick={handleClick}>
            {props.text}
        </p>
    );
}

Note that I set an initial value for the color. A rough overview on what happens under the hood:

For the initial execution of our code, we called useState with the initial value we want. It returns this value, and we store it in color. The second element is the update function, and we store it in setColor. React guarantees that the function will never change.
On the subsequent runs of the code, useState returns the same value. If the update function was called, the modified value will now be the one returned. The initial value will no longer be used.
If the component is unmounted — removed from the webpage —, we go back to step one on the next mounting.

Now, every time we click on our message, its color will alternate between blue and red. This feature is self contained, making the component reusable. But right now, our state changes only when we act on it. Why not make it evolve by itself? Let’s make it update the color when the text changes.

Remember that our component started pure, always returning the same tree when provided with the same props. We added state, but to manipulate it, we need an external event. To link state and props together, and to react to changes to both, we need a way to detect when they’ve been modified. And that’s what useEffect give us. With useEffect, you can have a piece of logic that will run once the component is mounted — created and added to the web page — and when any element of a provided set of state variables and props — the dependencies — is updated. For our component, we have a unique element to observe — the text prop. Here is the new code:

const Message = ({ text }) => {
    const [color, setColor] = useState(null);
    useEffect(() => {
        if (color == null) setColor('blue');
      else setColor(color === 'blue' ? 'red' : 'blue');
    }, [text])
    return (
        <p style={{color: color == null ? 'blue' : color}}>
            {text}
        </p>
    );
}

That’s when it’s got tricky. We now have multiple stages:

The component is created, returning an initial component tree and registering our effect.
Our effect is run once for the creation of the component.
Then it will run for every change to its dependency.

That’s why we started with null as the value of the color state. The main logic is to alternate between two colors, we need a third value to detect when it’s the initial run. In the component tree, we then alleviate for this third value, as it’s not a correct value for the specifications of our component. A special note: If you return a function inside your effect, it will be executed when the component is destroyed. And if the dependencies is an empty set, the effect will be executed only once, right after the component is created, which is useful for initialization.

With these two hooks, you can replicate the majority of the features that were only possible with class component. Another two hooks I find useful are useRef and useMemo.

useRef comes in when you want to store a value after the code of the component is executed for the next execution, but you don’t want its mutation to trigger a new execution. It acts like a global variable in respect to the component. If we take the following code:

const Message = ({ text }) => {
    const interval = useRef(null)
    const [color, setColor] = useState('blue');
    useEffect(() => {
        interval.current = setInterval(() => {
            setColor(color === 'blue' ? 'red' : 'blue')
        }, 1000);
      return () => {
          if (interval.current) clearInterval(interval.current);
      }
    }, [])
    return (
        <p style={{color: color == null ? 'blue' : color}}>
            {text}
        </p>
    );
}

The component is now flashing between blue and red every second. When we unmount the component, we need to remove the interval to stop setColor being called. The long-lived aspect that useRef provides is useful in that case. Notice that we don’t update the object returned by useRef, but its property current. We removed the text prop from the dependencies set, as our effect role is to initialize the interval. Additionally, it returns a function to be executed when the component is unmounted, clearing the interval.

useMemo is for improving the performance of our code. Sometimes, we have to do computation on our state and props, resulting in a new value. If we add the code to the body of our component, it will be run each update. useMemo allows us to run the computation when the dependencies set changes and not on every render. Let’s take a look at an example:

const Message = ({ text }) => {
    const [color, setColor] = useState(null);
    useEffect(() => {
        if (color == null) setColor('blue');
      else setColor(color === 'blue' ? 'red' : 'blue');
    }, [text])
    const bgColor = useMemo(() => getInvertedColor(color), [color])
    return (
        <p style={{color: color == null ? 'blue' : color, background: bgColor}}>
            {text}
        </p>
    );
}

getInvertedColor is our heavy computation code. useMemo, takes a function and a dependencies array. The body of that function should be statements that we could have put inside the body of the component, and should follow the same pure paradigm — no side effect. The return value is returned directly by useMemo. The function executes on the mounting stage and when the dependencies update. But the return value will be stored — memoized — and return directly otherwise. We can mention the useCallback hook, which memoizes a function instead.

Tehe most important part is that you can refactor the above code to create your own hook, making it possible to share functionalities between components.

const useColorFromText = (text) => {
 const [color, setColor] = useState(null);
    useEffect(() => {
        if (color == null) setColor('blue');
      else setColor(color === 'blue' ? 'red' : 'blue');
    }, [text])
    return color == null ? 'blue' : color;
}
const Message = ({ text }) => {
    const color = useColorFromText(text);
    return (
        <p style={{color: color}}>
            {text}
        </p>
    );
}

Original posted on hescaide.me

A day with Ansible

Holy-Elie Scaïde — Mon, 31 Jan 2022 22:58:04 +0000

While my work has been focused on frontend, I had to interact with backend systems on a few projects where I was either the most knowledgeable person on the team or working alone. In these cases, my usual solution was either serverless (Firebase Functions, AWS Lambda) or write an API using Node with Express and Laravel and hosting it with Heroku. I like the container paradigm of Heroku, starting fresh at every deployment and everything happens automatically upon pushing the changes.

But costs with Heroku ramp up quickly when scaling. I'm working on a side project and I decided to explore less expensive options, settling on a VPS at the end. I then quickly set it up one and my project was online.

I found that I'm not comfortable with manual operations, when there is a non-zero chance that I will have to redo them in the future. Which, I assume, will be in a more stressful situation. I looked into automation tools and I found Chef, Ansible, and Puppet among others. I settled on Ansible due to being less complex to get started with.

So, Ansible?

Installing Ansible was straightforward on both my M1 MBA and my Linux box. I needed something to test it with, so I used my Linux server as my learning environment because Vagrant (with VirtualBox) does not support M1 processors. A quick Vagrantfile later, and my virtual machine was ready.

As I learned more quickly by doing, I cloned a project that was doing the same thing I was aiming for, creating a deployment environment for Laravel. The project was last updated in 2018, so I figured there will be ample stuff to update in it.

The first thing I learned was “Inventory”. Inventory files lists all the hosts that you need to interact with, alongside their connection parameters. You can assign a name to them and group them. When using that inventory files, you can filter the particular hosts you want by using a pattern. When using Ansible to provision the virtual machine(s) created by vagrant, the latter will generate an inventory files that will automatically be used when provisioning.

The second thing I learned was “Roles”. Roles are collections of tasks and other related things (Variables, Templates, …) inside a common directory, which can later be shared if needed. Tasks are action items that will be executed against the hosts. I had one single host that has everything, but if you wanted a more modular architecture, you could have roles for the web servers, the database servers, the storage servers, including a shared role that contains the common tasks.

The third thing I learned was “Playbooks”. Playbooks are instruction manuals describing policies or executing a particular set of tasks. Inside the project I was using as a reference, there were playbooks for each particular server type, which included the common role and the role for that particular server and targeted a specific set of hosts inside the inventory. There was another playbook that included the others that could be used to provision a whole site.

In the end

I've written a few bash and python scripts before. But, I was amazed by the possibilities that Ansible offered. My first use case was writing a playbook that will update my web application using git and install the new dependencies using composer when needed (which I used a lot as I'm actively developing it). There are numerous modules built by the community that will make the process a breeze (the above playbook only has two tasks). The documentation aspect alone is worth it when in a team context.

Originally posted on hescaide.me

Writing native modules

Holy-Elie Scaïde — Sat, 08 Jan 2022 23:11:04 +0000

One of the milestones of being a React Native developer is writing your first native module. At first, it may appear a daunting task, but the module part is easy to wrap your head around. Here are a few important points to keep in mind. The same applies to Cordova.

The Bridge

The bridge concept is not a unique to React Native. It is a common occurrence when you’re dealing with many languages or multiples platforms. It is how two different layers in a single system communicate with each other.

The main logic of the application resides usually in one of the layer, while the feature will be implemented in the other layer. The first will be the caller and the second will be the callee. For the two to communicate, there should be a common ground between the two, which we can call the host.

The host can be the same as one of the layers. In game engines, which often need to add a scripting layer, the host is the caller and the callee will be the scripts that are written to customize components’ behaviors. In our case (React Native and Cordova) the host is the callee. Our code reside in the JavaScript interpreter (custom engine or web view).

As the host is the one running the layers, it is trivial for it to customize their engine or interpreter. It will provide new functions in addition to the standard ones, which will be how the layer will get back to the host. Those functions may be arranged in a more cohesive set for a more intuitive use. It will replicate the caller layer’s data types in the callee layer.

A module is a plugin

Occasionally, the callee layer will need to execute before getting called, or even before the main layer is executed. In those cases, there will be a general framework to follow with hooks. The framework is to tell the host the functions to call, initialize or destroy the module. The hooks are there to add new features to the host without the other layer intervention (which can not access these parts directly in our case). These hooks are why we normally need a module in the first place.

A module is a library

But, how do we architect the module in the first place? From the host's perspective, it needs to be executable logic. While the host is initializing, it may run initialization code in the module. The same when the host is terminated. Logic in the module will mirror the host lifecycle. But from the perspective of the caller layer, it needs to be a library.

Ordinarily, the module purpose is to provide a new feature to the caller layer. It needs to be architected the same way as the libraries native to the caller layer. Which is to provide a consistent set of functions (API) for the caller layer to use. At the callee side, we need to mark those functions, and they need to follow the same signature (using the replicated data types).

In conclusion

The above is my mental model when writing a native module. The implementation will differ based on the platforms, but it provides a quick way to pick the relevant parts to learn from the documentation and example codes.

Originally published on hescaide.me

My React Native Architecture Template

Holy-Elie Scaïde — Wed, 14 Oct 2020 20:06:56 +0000

I've been working with React Native for about 3 years now. I've built applications mainly for small businesses and entrepreneurs as a freelancer during this time. As the months go by, I find myself using pretty much the same architecture again and again.

My coding has been influenced heavily by Laravel's framework principles as well as "Clean architecture" from Robert C. Martin. One of the core principles I follow is loose coupling. As I work mostly alone, it allows me to quickly replace modules I've implemented for another one.

Main files

The most important files for me are the following:

index.js,
App.js,
config.js, These reside mostly at the root of the project folder. I consider index.js as the loading logic. I rarely modify it from the default that is generated when creating the project using react-native-cli.

App.js Is the super container. It represents the root of the React root and it is where I integrate any React Native library that deals with context, like Theme, Navigation and Redux. It is the only React files that depends on non-react modules.

I seldom use a config file. It mostly reserved if I have constants in the business logic that can be modified later or any temporary service configurations.

Navigation

react-navigation library has been enough for my needs so far. I usually configure it inside one file name navigator.js. It is the interface between the screens and the main App component. It does not handle navigation logic, just the configuration.

Screens

I'm a big fan of the functional paradigm. Now I'm using functions for every React components I write. I think it is better for handling side effect from a readability point of view. My preferred method is using files directly like Screen.js instead of Screen/index.js I've seen people do. Styling is written at the end of the file and I use flow for specifying the type of the props.

Screens are the main containers or smart components. That is where I write business logic and side effect code (like asynchronous code that deals with services). The UI is handled mostly by the components.

Components

Most of the components are dumb. They display data or accept input from the user and hand out the result to the main container. They follow the same template as screens. I often write component in the same file of the screen that will host them (Row in a list). But reusable ones are stored under the components subfolder of the project.

Services

Services are for everything that interacts with the outside world. REST API, BaaS, Persistent Storage, ... all fall under that category. The key is to decouple the service from the main code. Apart from that file, there shouldn't be any mention of the service anywhere else (Apart from config.js). It is mostly the configuration logic that will be inside the file and a collection of functions to use elsewhere.

Utility functions

These are small functions that contains logic you find yourself reusing throughout the app. Things like concatenating the first name and last name of the user, formatting strings, calculating various values... I just group them by category (user.js, format.js) and put them inside a util folder.

State Management

This is an optional one. I mostly use Redux for caching API responses. It permits me to go from an asynchronous paradigm to a reactive one. I found myself not using it with Firebase and Apollo GraphQL as the latter ones have their own caching mechanism. When I do use Redux, I used the rematch library is it eliminates a lot of the boilerplate.

Utility Libraries

These deserve their own section. The most notable examples are theming and localization libraries. They do not deal with the outside world but are important enough to not be relegated to the util folder. They are mostly stored alongside App.js as they will be integrated there.

Conclusion

This is my own internal template that I use when writing React Native app. There is not a linked GitHub repository as I modify parts of it when I'm working on a project depending on the requirements. It helps me switch whatever I want easily as the tight coupling is restricted to a few locations, everything else is connected together by conventions. Do you use something similar in your own React Native project?

Back to drawing

Holy-Elie Scaïde — Wed, 11 Dec 2019 17:58:10 +0000

I think I wrote a comment here explaining how drawing helped me be a better programmer. And it has the additional benefits of being a hobby outside coding. While you can be creative as a programmer, those moments can be rare and most of the time, you're just redoing the same thing every day.

I left drawing when I decided to learn to program full time. I was going through university and I couldn't handle the lectures, learning to code and drawing at the same time (gotta rest). I don't regret my decision as I'm now working full time as a programmer in a country where finding a good job is a rarity.

Why I'm going back? Programming can be a very taxing activity mentally. Often, at the end of the days, I don't have any energy to spend on my own personal projects. And I don't really like spending my evening in front of the TV. I do sometimes read, but it requires the same amount of concentration (I read high fantasy stuff like The Malayan Book of the Fallen). So I chose to draw because, while it requires some level of concentration, it's more about eye-hand coordination than abstract thinking. And that fits perfectly my needs of low-key activity to do in my free time (And I think it's a good thing to have another marketable skill).

And what about you? Any activities you like to do to get away from the programming world? Please share in the comments.

How to create a website: The easy part

Holy-Elie Scaïde — Fri, 01 Nov 2019 15:38:37 +0000

My previous article was about the core technologies one has to know to create a website from scratch or modifying an existing one. But it takes time before one can be comfortable in these and developing a website using just HTML, CSS and JavaScript can be a tedious process. For one that is not experienced, there are easier ways to build a website.

CMS: Easy Configuration

The first solution is to use a CMS (Content Management System). A CMS is a framework that does a lot of the heavy lifting for you, mainly the database. They come with a theme engine (allowing you to easily change the interface of the website), a plugin ecosystem (to add supplementary features to the built-in ones) and an admin panel for an easy configuration.

One of the most popular ones is WordPress. It is mostly used for blogging sites, but it is more versatile than that. There are also more specialised ones like Magento for eCommerce and Moodle for eLearning. There are a lot of CMSs and you only have to choose what fits more your needs.

But remember that although CMS are user-friendly tools, allowing a non-developer to manipulate the site, they are a development framework too. To get the most out of the CMS, you'd have to learn it fully and often you will see the need to develop some plugin to tie everything together or to rewrite a theme for visual that fits your brand.

Builder: For the non-dev

But maybe a full-fledged CMS is not needed, especially if your content does not change often and you only want a way to display them. So what you need is a site builder. Site builders come with a WYSIWYG (What you see is what you get) editor and a library of widgets. Some also provide you with a collection of templates to choose from and edit later. Some allow you to edit the style by adding custom CSS or setting the value of a subset of the styling properties.

An example of a site builder is Wix. Another one is Squarespace. They offer a no-code environment for people that do not need complicated features on their website and are fine with the default those platforms provide.

As you have seen, you do not always need to go the tedious way of writing everything from scratch. It's often faster to go to with a CMS or a website builder. As a developer, the most efficient solution is not always the one you implement by yourself.

How to create a website: The simple part

Holy-Elie Scaïde — Sun, 27 Oct 2019 21:51:37 +0000

Learning how to create a website is not the most difficult undertaking, but it can be tedious because of all the skills and technologies that may be required, especially if you're starting from scratch. And for beginners, it can be overwhelming. I remember getting stuck, my mind blank, not knowing what to do next. I'm here to give an overview of the different elements that go into creating your own site web.

A text editor: The tool of the trade

First, you need a text editor. If you're on Windows, you can use Notepad because you only want the basic text (other programs add a lot of stuff in the file). Or you can download Visual Studio Code or Sublime Text which is more powerful than Notepad. And you can use them on other platforms too (Mac and Linux). Open the text editor, type Hello, World! and save it as first.html. Double click on the file created and it should be opened in your default browser. Congratulations! You've just created your first webpage.

HTML : Creating elements

You may be wondering now how to add title or image (Who wouldn't?). For this, you need to use HTML (HyperText Markup Language). It allows you to specify elements and their properties (attributes) on your document. Let's start with a default template:

<!doctype html>
<html lang="en">
<head>
  <title>Greetings Page</title>
</head>
<body>
  <h1>Greetings</h1>
  <p>Hello, World</p>
</body>
</html>

The first line is a special one and it indicates that you will be writing HTML5 (There are multiple versions) which is the default on the web. The second line is the root tag. A tag is always written like these: <*>children</*> or <*\>. The * is the name of the element and the children can be other tags or text.

html is a special tag and represents your whole document. It always has two children: head and body. The first one is mostly for specifying the document metadata like the title as we're doing now. The second one is where you put the content that will be showing on your web page. Now we're displaying a level 1 heading, specified by h1, and a paragraph, specified by p.
You can learn more about the different tags with this interactive tutorial here.

CSS: Make it pretty

Your next question will be probably how to change the default styles for the text as we can do in a word processor (It's kinda boring now). You will be using another language called CSS (Cascading StyleSheet) for that. Your browser has already a set of default styles for the different HTML tags. To create your own, there are two different ways.
The first is to put it in the same HTML file. You will use the style tag for that.

<style>
h1 {
 color: red;
}
</style>

You can put this line of code inside the head tag or the body tag. The browser usually reads HTML files from top to bottom, so if you put your CSS after all elements, they will be briefly rendered with the default styles before the browser applies your own. So the usual way is to put them in the head tag.

<!doctype html>
<html lang="en">
<head>
  <title>Greetings Page</title>
  <style type="text/css">
    h1 {
      color: red;
    }
  </style>
</head>
<body>
  <h1>Greetings</h1>
  <p>Hello, World</p>
</body>
</html>

You should see that the heading text color is now red.

The other way is to write a new file (let's call it first.css) and reference it inside the HTML file. The content of the new file will be:

h1 {
 color: red;
}

And you will reference it inside the HTML file like this (still in the head tag):

<!doctype html>
<html lang="en">
<head>
  <title>Greetings Page</title>
  <link rel="stylesheet" href="./first.css" />
</head>
<body>
  <h1>Greetings</h1>
  <p>Hello, World</p>
</body>
</html>

When writing CSS, you will specify the targeted elements by using a selector (now we're using h1 which targets every h1 element on the page. Then you can specify the properties that you want to change for the elements targeted, like the text color as we do now. By using various combinations of selectors and properties, you can create almost every layout you want (People have implemented really awesome designs with it).
The same site has another tutorial just for CSS here.

JavaScript: Action, yeah!!!

So now, you know how to create elements and how to style them. But you have seen that a website is not only a document that presents information, but it can also have a lot of interactions (including those annoying popups). To interact with your web page, you will use a third language, JavaScript (Welcome to the Dev world, where almost everyone is a polyglot).
As for CSS, you can use a tag or a file to include JavaScript code. But it will usually be placed at the end of the HTML file (inside the body tag) to ensure that everything else has been created.

<!doctype html>
<html lang="en">
<head>
  <title>Greetings Page</title>
  <link rel="stylesheet" href="./first.css" />
</head>
<body>
  <h1>Greetings</h1>
  <p id="greeting">Hello, World</p>
  <script type="text/javascript">
    setTimeout(function() {
        document.getElementById('greeting').innerHTML = 'Hello JavaScript!';
    }, 3000);
  </script>
</body>
</html>

The same example using a JavaScript file (named file.js):

setTimeout(function() {
  document.getElementById('greeting').innerHTML = 'Hello JavaScript!';
}, 3000);

and the HTML will be:

<!doctype html>
<html lang="en">
<head>
  <title>Greetings Page</title>
  <link rel="stylesheet" href="./first.css" />
</head>
<body>
  <h1>Greetings</h1>
  <p id="greeting">Hello, World</p>
  <script type="text/javascript" src="./first.js"></script>
</body>
</html>

What we're doing in this code is wait 3 seconds (3000 milliseconds) then select the HTML element identified by greeting and change what's inside.
Here is the tutorial for JavaScript.

Wrapping Up

Those are the basics that you need to learn. Even with the advent of WYSIWYG tools, you need to be aware of these three in order to be proficient at using them.

Being a Better (and Lazier) Programmer

Holy-Elie Scaïde — Tue, 15 Oct 2019 15:22:47 +0000

House building is one of the most common analogies to developing software. While you're required to follow some constraints (hardware, business), you're also given some leeway in how you go about it. However, we, the developers, have two advantages over house builders, which is the only physical work we do is entering text. And while the latter is required it's only a minor part in developing good and practical solutions.

But often when beginning, we made the mistake that this is the only thing that matters. Writing code and the tools we use are more important than the solution that we use them for. I think most of our time should be devolved to planning and designing. And we can do so by reducing the time we take writing code. Here are some techniques that can help you do so.

Automation

When starting a new project, you often have only one file and just a few commands to run the code in this file. But as your project grows, more commands need to be entered and often they will have conditional parameters based on your current intent. And entering those commands manually takes time.

I believe that if I do something that is recurrent, it should be automated, even if it's only once per day. From shell scripts to specialized task runner, there are a plethora of solutions that you can use to reduce the time you spent compiling, testing and deploying things. The good news is that most of the online tools we use often provide a CLI equivalent which makes it more easier for us. And a lot of them can connect with each other easily or through third-party services.

Know your tools

The Pragmatic Programmer book dedicates a whole section to the tools that we use to develop software (And it's still relevant, even if you're using an IDE as the latter is just a cohesive structure for those tools). You have to know your tools, their capabilities as well as their limitations. From the shell to your text editor, you'll often find that your productivity increases along with your mastery of the tools you're using.

Even learning the shortcuts of your current editor can result in a huge productivity boost. It's faster using a sequence of keys that using the mouse. I use aliases for the commands that I find myself typing every day. I often read the manual just to explore in what new way I can use the tool. Being familiar with your tools is a necessary step if you want to reduce the time you spent using them and increase your productivity.

KISS

As a programmer, we must resist the urge to overengineer our solution. While design patterns are useful, they are not a silver bullet. Remember that you're writing code for humans, not the computer. What you're writing will be maintained in the future, and your job is to make it easy for the next person to do so. Strive for clarity and simplicity. This one-liner could make you look smart, but it may result in lost hours trying to understand its purpose. A simple solution is always better than clever in the business world. So don't spend the whole day trying to optimize that function if it already satisfies the performance criteria.

My belief as a programmer is that you don't have to work hard to bring value to your work. You're tasked with creating practical solutions to problems and your tools should not be a hindrance to that objective. And you should also keep in mind that your code (the physical aspect of your solution) will be the responsibility of another person in the future (or your future self). So you should make it easy for them to pick up where you left.

How I understand React

Holy-Elie Scaïde — Thu, 10 Oct 2019 13:32:59 +0000

Every time I learn a new language, library or framework, I like to form a mental image of how it works and why it works that way. It helps tremendously with being able to provide practical solutions to business problems if you can discern their pros and cons easily.

I don't learn the technical aspects by heart. You will retain them overtime by practicing regularly with the tool. Instead, I focus on the architectural level and I try to understand how everything fits together.

As for React, I think there are three major aspects that one needs to understand well to be proficient with it. They are the virtual DOM, the components and the component's lifecycle.

The virtual DOM

The DOM represents a document with a logical tree structure. Almost every UI library is represented with a tree structure because it helps with geometrical transformations and property inheritance. React's virtual DOM is a copy of that structure. Because modifying the real DOM is costly (Computing the new UI representation takes time), React executes the manipulation first on its copy, then compare the new and the old versions to determine the most performance effective way to update the real dom.

That means that what you are writing and updating is not the real dom. It does not have the same properties and you should not treat it the same way. That also means that the React philosophy is also universal as the DOM in the browser is very similar in representation to the UI library in other platforms (Which explains React Native). It is still a tree structure but with new types of nodes. Here is a post that explains the virtual DOM in more detail.

The components

The components are each responsible for a section of the virtual DOM, which may contain other components. There are two types of components: classes, and functions. I like the latter as it's often easier to manipulate. With hooks, you can use a function instead of a class as I do now.

As a developer, what you will be doing is create a tree of components that will include your owns and those provided by libraries. These components will accept props as inputs and will return the section of the tree they are responsible for. There are special components called HOC (Higher Order Components) which are functions that will return either your component with new additional props or a completely new component which will include your component as a child.

The component lifecycle

So where does the business logic fits? In the case of a class component, there are various stages and React.Component class provides you with methods that will be called at each one of the stages. You choose the correct stage based on what you want to do. Some are called only once upon the creation (mounting) and the destruction (unmounting) of your component, other will be called many times when your component updates (triggered by a lot of things). Here is a more detailed explanation.

Using functions make things cleaner. There is no more lifecycle to worry about. You are provided with the props as parameters and you need to return the tree's section. That's it. Now with hooks, you can do the same thing that the class component used to do. hooks are functions that will accept arguments based on the current props and optionally will return objects that can be used inside the functions. Those objects are not created inside the function scope so they won't be destroyed when the function return. I think they get destroyed when the section of the virtual DOM your component is responsible for is destroyed.

So that's it, that is my mental model of what React is. There are a lot of other things like the relation between refs and real DOM, Babel, and JSX. But I think these three are the most important concepts you need to wrap your head around.

Neovim after 2 years

Holy-Elie Scaïde — Tue, 08 Oct 2019 15:34:02 +0000

One of the most important things to being a developer is your development environment. Being productive depends a lot on what tools are available to you and how much are you familiar with them. As a coder, what software you use to write code will be one of your most important tools.

Why Neovim?

I strongly believe productivity is tied to comfort. And for me, being comfortable is being able to do more with less. I always tried to learn the keyboard shortcuts of every software I use as it's often the fastest and simplest way to do something. When I learned about the keyboard-driven nature of vim, it seemed perfect for me. It fitted with a goal I had at that time which was to lessen my usage of a mouse (I had a pretty bad trackpad so I had to use an external mouse).

My Needs

Another thing I believe is a tool should be adapted to your needs, not the other way around. My expectations were shaped by my experience with the Jetbrains' products. Things that were essential for me were auto-completion (mostly for variables' names), linting code (a real time saver when fixing syntax errors), project management (mostly for launching commands inside a directory, git (for basic stuff like viewing diffs and committing) and snippets (that came later).

Auto-Completion

For auto-completion, I started with youcompleteme inside of Vim. It was overly complex for me to install, so most of the time, I did not even bother and just use the default completion engine inside Vim. But after learning about deoplete, I made the switch to Neovim (it was easier to install in Neovim). Now, I'm using COC which is even easier to install and configure. The default completion engine would suffice, but using COC make it simpler for me.

Linting

There's nothing that can speed up your coding like linting. Being able to correct syntax errors as well as correctly formatting your files help greatly during the development process. At first, I didn't know about Vim's make system. I used Syntastic, then I switched to Ale when I moved to Neovim. Now, I know about the make system and understand the edit-compile-fix process, but it is easier for me to use Ale.

Project Management

I don't need project management as the IDEs do. What I needed was switching between files quickly and launching commands in the context of the directory I opened the editor in. For the first one, I started with CtrlP. But, as soon as I heard about FZF, I switched to it. As for file explorer, I started by using the default one, Netrw, then nothing for a long time (FZF was enough). A few months back, I tried to used Denite and [The NERD Tree)(https://vimawesome.com/plugin/nerdtree-red), but I could not feel comfortable with them so I moved back to FZF and Netrw.

Git

My needs for git within the editor are the basic ones. I only need to be able to see which files were modified, to select which ones I'd stage and to quickly write the commit message. Since starting, I've used fugitive. It fits perfectly within my process. I've added a couple of mappings to the most used commands.

Snippets

I don't use snippets that much. But I've installed UltiSnips and I've added a couple of snippets. It's very powerful and fast.

And that's it. Neovim does everything I want from a text editor. I also analyze my coding process from time to time to see what I could improve in it. You can find my config here init.vim.

I wanna hack my keyboard

Holy-Elie Scaïde — Wed, 25 Sep 2019 03:06:34 +0000

A while ago, I took the plunge and decided to buy a mechanical keyboard. I've settled on the Ducky One 2 Mini (I should have bought the TKL version). And I don't regret it (Except for the missing dedicated arrow keys). I don't even notice it when I type and the RGB lights can be mesmerizing when I'm thinking.

Last Saturday in the afternoon, I was updating the keyboard firmware when a thought struck me: Can I install custom firmware on it? I mean the default one is great, but I like to tinker with my devices at a lower level, not just with the options the manufacturer provided. I quickly searched on google to see if the firmware was open-sourced and unfortunately, it wasn't. But searching "ducky one 2 mini firmware" yielded promising results, particularly this post.

This was the first time I heard about the QMK project. It's a custom firmware for mechanical keyboards and has a bunch of cool features. I liked what I was reading in the documentation and I decided to give it a go.

I cloned the forked version of the guy (I still don't know his name) who worked on the version for Ducky and created a test branch. I first merged in the mbi5042gp branch which I think it's the driver interface to control the RGB lights. Then I merged in the duckyone2mini branch which contains the configuration for the keyboard.

The first build failed due to missing files in the lib/chibios-contrib folder. I recalled that this was a submodule and went in for the commit that may contain those missing files. Instead, I found a pull request made by the same guy (great work!). This pull request adds the missing files for the Microcontroller Unit included in the keyboard unit. So a quick git remote add, then a git checkout retrieved the needed files.

Another build failed, but that was due to some errors in the Makefiles and a constant's name (I should make a pull request for that). They were easy to fix and a final build generated the .hex file needed for the keyboard.

I would say that the QMK firmware was very enjoyable and that it was fun to use. But I did not flash the keyboard. It's the only one I have and it will be $100+ gone if I bricked it in the process. And I do not have the necessary tools to do a full recovery (JTAG anyone). So here I am with a compiled firmware and no courage to try it. But I learned a few things during the process and will learn more about the QMK project in the feature.

Programming a peanut butter mill.

Holy-Elie Scaïde — Mon, 23 Sep 2019 20:56:10 +0000

Introduction

One of the end-of-year projects given to us by our microcontroller teacher was creating the technical specifications for a peanut butter mill powered by an 8051 microcontroller as well as writing the program that was going to run on the latter (Simulated as we were not going to build the actual mill).

Hardware

The fictional mill should have a self-check process before starting and allows an optional second pass during milling. It should be able to self-clean at the end of the milling. Very much like this one, but where the container is enclosed as well as an additional container inside for the optional pass.

Requirements

After pressing the start button, the program should check that at least 1/4 of the first container (The one containing the peanut) is filled and that the last container is empty. If the latter is not, it should turn on a warning light. When all these conditions are met, the milling process starts and the peanut butter is poured in the second container to be milled if the user has chosen to do two passes or the final container if he has chosen only one pass. The first motor stops when the first container is empty and the second motor will stop 5 minutes later if it was running

The self-clean process is very simple. The first 2 containers are filled with water and start both motors. After 3 minutes, they are stopped and the containers are emptied into the final container. This is repeated one more time and the machine is reset.

Design

Even if we are not building the actual mill, we need to design the interfaces to the microcontroller. The 8051 microcontroller has 4 byte-sized I/O ports. We choose to use 2 for the purpose of this program.

Inputs

We have three switches and 3 sensors for the content's level of the containers. Two of the sensors are 2 bits wide because we needed 3 states:

00 -> Empty
01 -> 1/4
11 -> Full

The sensor for the final container is 1 bit, we only need to detect if it's empty. The three switches are

S -> On if the machine is started
A -> On if the cleaning process should be started
M -> On if two passes are requested

Outputs

All 3 outputs are control bits. They are

Mx -> Off if the motor x should be running
P -> Off to fill the containers with water.

Implementation

As for the implementation process, we have used the [edsim51[(https://edsim51.com) for simulating the program we wrote. We have not used interrupts because it will only make it more complex. If it was a real machine, we would have to make it more asynchronous. A lot of looping as used when the machine was idling and when using the timers in the microcontroller.

Setup and Verification

We start by setting the timer counter to be a 16 bits number (needed for later. We then read port 2 (inputs). We check if the final container is empty by reading its bit and light the warning light if it is set. if it's not, we check the first bit of sensor 1 (it's on if the first container is 1/4 full or more) and the start switch. We loop this part until all conditions are met.

mov tmod, #10h ; set timer 1 to 16bit
verif:
mov p2, #0ffh ; set p2 as input
mov acc, p2; read p2 into the acc
jb 0e4h, ll; jump if first bit of sensor 1 is not set (empty)
anl acc, #41h; isolate s and sensor 1 bits
xrl acc, #41h ; acc will clear if s and sensor 1 first bit is set
jz lm1 ; jump if acc is zero
jmp verif; loop verification
ll:
clr p1.0 ; light warning led
jmp verif ; loop verification

Milling

Milling is very simple. We launch the first motor first. If two passes were selected (M is on), we wait until the second container is at least 1/4 full. Then, another looping until the first container is empty.

lm1:
clr p1.4 ; launch motor 1
jnb p2.5, f1 ; jump if clapet is not on
jnb p2.2, $; loop until sensor 2 says it's at least 1/4
clr p1.5 ;launch motor 2 if clapet is on
f1:
jb p2.0, $ ; loop until sensor 1 says empty

As soon as the sensor reports that the container is empty, we stop the first motor, then wait 5 seconds (For the purpose of the simulation, we used seconds instead of minutes) to stop the second one. Then we loop until the clean process is instantiated (The switch A is on).

setb p1.4 ; stop motor 1
mov r0, #10 ; 5 seconds (5 * 20)
call secondsDelay ; delaying
setb p1.5 ; stop motor 2
jnb p2.7, $ ; loop until a is set

Cleaning

First, we open the water pump and check until that the first 2 containers are full to close it. Then we start both motors, wait 3 seconds, then stop them. This process is repeated one more time, then we stop everything.

mov r7, #2;  2 cycle
clean:
clr p1.7 ; open pump
checkEmpty:
mov acc, p2 ; load port 2
anl acc, #0fh ; isolate sensor 1 & 2
xrl acc, #0fh ; clear if all is set
jnz checkEmpty; loop until full
setb p1.7 ; close pump
clr p1.4; start motor 1
clr p1.5 ; start motor 2
mov r0, #10 ; 3 seconds (3 * 20)
call secondsDelay
setb p1.4 ; stop motor 1
setb p1.4 ; stop motor 2
djnz r7, clean
jmp finish

Timer

We decided to use the timer imperatively instead of via interrupts. We implemented it via a procedure. As the timer uses a 16 bits counter, we can only set it for a duration up to 65 536 us. We decided to go with 50 ms in and loop it to attain the expected duration. The number of loops is set in the r0 register (1 byte) before calling the timer subroutine.

; Setup Timer
fiftyMsDelay:
clr tr1 ; stop timer
; set up a 50 000 seconds delay by loading 65 536 - 50 000 = 15 536 (3CB0)
mov th1, #3ch
mov tl1, #0b0h
setb tr1 ; start timer
jnb tf1, $ ; loop until timer oveflow
clr tf1 ; clear overflow
clr tr1 ; stop timer
ret
secondsDelay:
; save processor state
push psw
loopTimer:
call fiftyMsDelay ; 50 ms
djnz r0, loopTimer ; loop until r0 equal zero
; restore processor state
pop psw
ret

Improvements

Our code is very simple and makes the milling process a very straightforward one. But in the real world, there are often edge cases that the programs would have to handle. Like whether the motor is actually running or pausing the milling process.

Conclusion

Writing this was very stressful, but enjoyable as we have not had much experience writing assembly code. But we learn a lot during the implementation and it had become easier over time. Assembly is actually very simple, but also tedious to write. Next step will probably be porting this to Arduino.