Ionică Bizău

Web Developer, Linux geek and Musician

The Joy of Being a Mentor

Helping our fellow developers—or generally speaking, helping each another—is an important part of society. We all work and struggle on this planet, so offering a helping hand is always welcome. :heart:

It's been more than one year since started teaching people to code. I do it on Codementor—an open marketplace for code instructors. In general, we set up 1:1 live sessions and start talking. :smile: Then after we get everything fixed and finally both of us are happy.

What I really like about Codementor is that it connects a diversity of people around the planet. Each mentee is unique (cultures, lifestyle, accent, beliefs etc.), but they all have one single goal: to learn—and that's one of the facts that make us happy.

While I do teach people to do stuff, I keep an open eye on things I can learn as well. For instance, I learned how to use Firebase by working with one of my favourite mentees! :blush: Thanks! :cake:

Obviously, that means I can now take care of people wanting to learn Firebase as well.


:zap: Here's how I do it! :zap:

I'm blessed to live in a small, peaceful, and friendly village from Romania, far enough from the noise of the cities and still have great people around, and of course, a great internet connection! :earth_africa:

In the morning I enjoy the birds singing (if I wake up early enough, sometimes there are few owls hooting too) and in the evening I listen to the crickets' songs.

:bulb: Tip: If you will ever need help in programming during the summer time, and we talk either in the morning or evening, you will have the opportunity to see the big crowd of cows going or coming back to and from the hill. It happens every sunny day, during the summer time. :cow2:

Even though I'm a remote developer working mostly from home, it's still a lot of hard-work. Rest and relaxation are important as well. I find that taking a few days break from work and hiking up the mountains helps a lot.

Often I take my bike and ride it to my little house between two hills—to be alone, hiding in the mountains for a while, after which I go back. There, I don't have internet nor phone signal. Being in a place where you can be alone with your thoughts for a good while is where great ideas are born. I note each one somewhere, and when I get the chance to implement them, I just do it. :sparkles:

Being in the middle of nature, listening to the flowing water, birds happily chirping all day is definitely something special—it's closer to our roots. I believe that if we want to be productive developers, be a good person to talk to, or just be human, we should take a look at the values that our Creator implanted in us.

Is what we eat and drink important?

There is a strong relation between the food we eat and the way we think. We should have our brains clean and agile when teaching others. That's done by knowing what, when, how, and how much to eat. As mentors, we should know the laws of life and health.

Not all of us work remotely, but I do recommend to get out of the cities and purchase a land in the countryside and start cultivating your own garden. Eat plants, not animals. We were designed to have a vegetarian diet.

There are so many things going on in the cities. Noise, crimes, immorality, pollution, and other unfortunate events. We can avoid all these. Faith, hope, love, happiness can be cultivated way better in the countryside, away from the cities.

Rest is important

While working is definitely important, rest is equally as important—if not, more so. Sleep 8 hours a night (sometimes before midnight) and wake up early in the morning.

:bulb: Tip: Bugs are much easier to fix in the morning than in the evening/night! :joy:

We were designed to work the first six days of the week (Sunday to Friday), and then rest on the seventh day: Saturday. One of the secrets to be productive is to value each moment of our lives. :hourglass_flowing_sand:


Summarizing, I always recommended: leave the cities as soon as possible, stand for good principles, eat and drink healthy stuff, work six days a week and rest on the seventh one, help the people around you and love them. We have no time to waste! :rocket:

PS: Most parts of this post were written near a forest, somewhere in the western part of Romania. :evergreen_tree:

Read more »

How I npm

I write a lot of code every day, publishing my code on GitHub and npm. Each tiny package I create does something, and in most of the cases it's a module which can be used in other applications. :four_leaf_clover:

:thought_balloon: What is npm?

In case you don't know, npm is the default package manager for Node.js. Note that there we can publish modules which are not Node.js specific.

Its name stands for need pray more (or nuclear pizza machine, or npm's pretty magical etc etc).

Whaaat?!

Well, if you are here and think that npm stands for Node Package Manager, I have to tell you that's also correct, but it's not complete. npm is not an acronym, but it's a recursive bacronym for npm is not an acronym. In short, npm is an bacronym, not an acronym like many people believe.

You can refer to npm/npm-expansions for a list of things npm stands for. :sparkles:

At this very moment while writing this post, I currently have 561 packages. You can view them here (npm/~ionicabizau).

:raised_hands: How I do it

I started learning Node.js at the end of the year 2012. I was enjoying using modules by others, but I published my first npm package in August 2013. It was youtube-api–a friendly Node.js wrapper for the YouTube API. :tv:

I liked the npm publishing workflow and I didn't stop there. I created more and more packages.

:rocket: How to create an npm package?

Assuming you have Node.js and npm installed, you have to generate a package.json file then write your code and publish it:

# Generate the package.json file
npm init

# Work on your magic
echo 'module.exports = 42' > index.js

# Publish the stuff
npm publish

But a good package should include good documentation as well as easy to use APIs and easy examples.

:crystal_ball: Automatization and Magic

From publishing new stuff on npm, I found that I was doing a bit of manual work every time. That included:

  1. Creating GitHub repositories
  2. Creating releases on GitHub
  3. Maintaing documentation in sync with the code
  4. Maintaining the same documentation format across the repositories

I started to analyze where I wasted time and created small tools to do the work for me. :construction_worker:

:memo: Blah: Fancy Documentation

I created a tool called blah which, since 2014, takes care of generating the documentation for me:

  • It generates README.md files based on my templates.
  • Handles custom stuff by looking at the blah field in package.json
  • Generates documentation by looking at the JSDoc comments from my code.
  • Bumps the package.json version
  • Creates the CONTRIBUTING.md, LICENSE (takes care of updating the year as well!), .travis.yml and .gitignore files

Pretty cool. Since then I didn't have to manually write Markdown files anymore.

:page_with_curl: Packy: package.json defaults

Every time you npm init a package, you have to write stuff like the author, git repository, license etc.

I created packy which takes static (e.g. author) and dynamic (e.g. git repository url) fields by looking at a configuration file.

After this, I was manually writing the name and description fields and then skipping the others. Then, I ran packy which was autocompleting the author, keywords, git-related stuff and so on.

Since blah can run custom commands for me, I decided to integrate packy in my blah configuration.

:tophat: np-init: Automagically create new packages

Because I was still lazy to create the files manually, I created np-init which creates a minimal npm module:

np-init my-super-package-name 'Some fancy description'

Then I just have to cd my-super-package-name and work on my code directly because everything is there for me (example/index.js, lib/index.js, package.json etc).

:dizzy: babel-it: Babelify the things

Because I started to use ES2015 features in my code and since many people use versions of Node.js which do not support ES2015, I started publishing transpilled versions of my code on npm.

After building babel-it, I replaced the npm publish command with babel-it! That is smart enough to babelify my code, publish it on npm and then rollback to my original code.

:ship: Ship Release

The publishing process was boring again. I decided to create a tool to take care of that: ship-release.

So that being said, I don't even need to take care of babelifying the things because ship-release does that (using babel-it).

After fixing a bug into a package, I simply do:

# Creates and switches on the new-version branch
ship-release branch -m 'Fixed some nasty bug'

# Bump the version
ship-release bump

# Publish
#  - generate docs using Blah
#  - push the changes on GitHub
#  - create and merge the pull request
#  - create a new release in the GitHub repository
#  - transpile the code
#  - publish the new version on npm
ship-release publish -d 'Fixed some nasty bug.'

That's the theory. Let's see all these running in the real world.

Example

Today I'm creating a small module called stream-data which will collect the data emitted by a stream and send it into a callback.

Creating the package

As mentioned above, I'm using np-init to do that:

np-init stream-data 'Collect the stream data and send it into a callback function.'

This created the following directory:

stream-data/
├── (.git)
├── example
│   └── index.js
├── lib
│   └── index.js
└── package.json

2 directories, 3 files

Write a minimal example

When building a house, you have to start with the base. When building an npm package, I like to start with the roof.

Even if the library doesn't do anything yet, I just set up an example the way I'm thinking I want the module to work.

So, I cd stream-data and write this (note that I already had something there created by np-init):

"use strict";

const streamData = require("../lib")
    , fs = require("fs")
    ;

// Create a read stream
let str = fs.createReadStream(`${__dirname}/input.txt`);

// Pass the stream object and a callback function
streamData(str, (err, data) => {
    console.log(err || data);
    // => "Hello World"
});

Write the functionality in the library

np-init generated a JSDoc comment, which initially looked like this:

/**
 * streamData
 * Collect the stream data and send it into a callback function.
 *
 * @name streamData
 * @function
 * @param {Number} a Param descrpition.
 * @param {Number} b Param descrpition.
 * @return {Number} Return description.
 */

I slightly changed the function parameters' names and updated the JSDoc comment:

"use strict";

/**
 * streamData
 * Collect the stream data and send it into a callback function.
 *
 * @name streamData
 * @function
 * @param {Stream} str The stream object.
 * @param {Function} cb The callback function.
 * @returns {Stream} The stream object.
 */
module.exports = function streamData (str, cb) {

    if (cb) {
        let buffer = []
          , error = null
          ;

        str.on("data", chunk => buffer.push(chunk));
        str.on("error", err => error = err);
        str.on("end", () => cb(error, buffer.join(""), buffer));
    }

    return str;
};

Run the example

Well, now we can see if it's really working.

$ node example/
Hello World!

Before publishing it, we need to set up some tests.

Tests

For testing I use tester. To add tester in my project I do tester-init.

$ tester-init
...
$ tree
...
└── test
    └── index.js

After writing a few tests, the module is ready to be published on GitHub and npm.

Publishing

We have to create a GitHub repository. I use ghrepo by @mattdesl (thanks! :cake: :grin:). It's smart enough to create the GitHub repository with the right data (taken from the local git repository url and package.json).

ghrepo --bare --no-open
ship-release bump
ship-release publish -d 'Initial release'

Looking in my directory now, I have a couple of new files (README.md, CONTRIBUTING.md, .gitignore etc).

Now my module is on GitHub and npm ready to be npm installed:

// After doing: `npm install --save stream-data`

const streamData = require("stream-data")
    , fs = require("fs")
    ;

// Create a read stream
let str = fs.createReadStream(`${__dirname}/input.txt`);

// Pass the stream object and a callback function
streamData(str, (err, data) => {
    console.log(err || data);
});

:mortar_board: Things I learned

Do not do manual work. Optimize things as much as you can. Otherwise, you'll waste your precious time. Create your team of bots to help you to optimize things.

Happy npming! :tada:


If you like to support what I do, here is how you can do it.

Read more »

What to Do When Your Website is Broken

Our job as developers is to break and fix stuff every day. Sometimes, some of us even do it on production servers. But during emergencies, they just tend to apply a quick fix which may not actually fix anything at all— in fact, it could even make things worse.

On some days, it works! But it's still very dangerous:

website is broken
This is a good example of fixing a bug on production with a happy ending. [source]

These things happen. But when they do, how can we address these issues with confidence and in the best way possible?

In this this article I will show you 7 general steps to fix your website, application, or code when it's broken.

1. Don't panic. Relax.

We are all humans. We make mistakes. When something gets broken, don't contribute to the mess by panicking. Try to settle down first before you do anything with it. Try drinking a glass of water and relax while trying to figure what's going on. Remember, think first before you code!

2. Reproduce the problem. Then reproduce it locally.

Let's suppose the website you're having a problem with is on production and users start complaining about a specific functionality.

Doesn't work is not enough. Ask your users to define what doesn't work means. Is there an error? What are the issue reproduction steps? Is it happening always?

Can you reproduce the bug on the production website? If yes, then try to reproduce it locally (or in your development environment). If you do this, however, you should be prepared to debug it. If you can't reproduce it locally, check out the machine-specific settings/resources. Here are few:

  • Database content: Maybe the bug appears only at a specific document that exists on production, but you don't have it locally.
  • Environment configuration: Maybe there are some environment variable or setting you need to change.
  • Make sure you're in sync with the production server code (including dependencies' versions).

But it's working on my machine!

Well, if you can't reproduce it on production, there is a high chance that it's a browser-specific issue. For example, maybe you used a function that doesn't exist on some old version of Internet Explorer, or maybe you shipped your ES2015 code directly, without transpiling it to ES5. In that case, if it's still unclear what's going on, ask for more information: Where does the issue appear? What operating system and what browser (including their versions) are they using?

If you're using the same OS and browser versions, ask them to clear the browser cache then retry. Also, you should also clear your own browser cache and retry.

Oh, yeah! Typos!

Before starting to reproduce the issue and debugging the actual code, make sure your input data is correct. You can't expect correct output if your input is incorrect (duh?).

Sometimes just by staring a bit at the code/urls/input content, you can easily fix things. As developers, we often waste lot of time debugging stuff which looks correct but turns out to be a typos in the end. And then we are like:

website is broken
After wasting a lot of time trying to fix a typo.

So, pay attention to typos. They are funny to fix, but developers often forget to think that well, maybe it's just a typo.

Read the full article on CodeMentor »

Read more »