DEV Community: Ori Volfovitch

All (or just most) of what you need to know about handling Promises

Ori Volfovitch — Sun, 06 Oct 2019 09:06:05 +0000

I Don't use Promises on a daily basis. But when I do, all I need is a simple usage example of how to handle them. What I find instead are over complex examples, many articles about async programming and the theory behind Promises in JavaScript.
I end up re-learning Promises for a few minutes to realize that in most cases there are only 2 - 3 main ways I actually handle the Promises.

So, I made a Github repository called "Promise Sandbox" with the 3 main usages that I need, and made sure that the code will be as short and as simple as possible.
In this example, I only execute 2 Promises. A long one and a short one.
You can add more but it will only make the code longer and more complex, and it will not get you any more insights.

Let's dive straight into code!

Promise execution

So, I am executing 2 simple Promises here. currently set to resolve (you can flip the annotations if you would like them to be rejected).
longPromise - set to be resolved after 10 seconds.
shortPromise - set to be resolved after 2 seconds.

var longPromise = ()=>{
    return new Promise(function(resolve, reject) {
        setTimeout(function() {
            resolve('longPromise resolved');
            // reject('longPromise rejected');
        }, 10000);
    })
};

var shortPromise = ()=> {
    return new Promise(function (resolve, reject) {
        setTimeout(function () {
            resolve('shortPromise resolved');
            // reject('shortPromise rejected');
        }, 2000);
    })
};

Handling Options

Classic chaining

The good old way to handle Promises.
This is a shortcut to find yourself in callback hell.

longPromise()
    .then((data)=>{
        console.log(data); // logs: longPromise resolved
        shortPromise()
            .then((data)=>{
                console.log(data) // logs: shortPromise resolved
            })
            .catch((data)=>{
                console.log(data) // logs: shortPromise rejected
            })
    .catch((data)=>{
        console.log(data) // logs: longPromise rejected

        // shortPromise is unhandled in case longPromise was rejected
    });
});

Edited:

As bloggers Eugene Karataev and Joel Ruiz suggested, we can dodge callback hell simply by returning the following Promise, instead of just calling it.
This will flatten our nesting and make the code much more readable:

longPromise()
    .then((data)=> {
        console.log(data); // logs: longPromise resolved
        return shortPromise();
    })
    .then((data)=>{
        console.log(data) // logs: shortPromise resolved
    })
    .catch((error)=> {
        console.log(error); // One catch to reject them all!
    });

Promise all

Batching all promises into an array. Handling all at once.
If you are using Node, i suggest you JSON.stringify the logged data.

Promise.all([longPromise(), shortPromise()]).then(function(data) {
    console.log(data);
});

Async await (Thank you ES6!)

Or actually ES8, to be more accurate.
If you don't want to deal with the async quirks of JS, let the new async-await functionality to take care of it. make sure you wrap your awaits in an async function.
In this example, i made the async function to be an IIFE to make sure that it invokes Immediately.

(async ()=>{
    let long = await longPromise();
    let short = await shortPromise();
    console.log(long);   // logs: longPromise resolved
    console.log(short);  // logs: shortPromise resolved
})();

This should work fine on any browser (Except IE. IE is not a browser!).

All the rest that was not mentioned

If you don't care whether the promise is resolved or reject, when handling a single promise use .finally() instead of .then() and/or .catch().
In addition to Promise.all() you also have Promise.race() which is like Promise.all(), but will be invoked once the first promise is fulfilled.
There is also the Promise.allSettled() which is still new, and not yet supported by most browsers and Node below version 12.9.

Entering a new developer’s position: how to do it right?

Ori Volfovitch — Thu, 03 Oct 2019 06:04:39 +0000

A developer's roadmap to a new job

Entering a new job, any job, is exciting. It could be a positive or a negative experience, depending on your personality, dynamics with the new colleagues, understanding your new responsibilities and many other factors.

TL;DR – Try the pro-active approach.
Integration is faster for those who take initiative.

As a developer you also have the pressure to learn the product quickly, and know your whereabouts in the code, while learning your responsibilities.
Your employer is aware that while he is paying you a salary (high salary, you are a developer!), it will take a while before you actually become productive and worth the pay you get.

Your learning curve, and the time it will take you to become lucrative for the company, is crucial to your success in this company. Being an easy adapter can never be underestimated, and whether you are a good coder and an experienced developer, this skill is not granted.

Your team leader will probably have an agenda ready for your first week, or so. If he made plans for you, that’s great! follow them. But, I would suggest to go for the pro-active approach (with no discrepancies to your team leader's agenda!).
If you want to prove yourself to your team leader, teammates and yourself, here are the actions that will help you fit in and deliver quickly:

Getting to know the colleagues and your interactions with them

On the first day, you are not going to write any code. In fact, it might take a few days. Developer’s mistakes are very expensive, and we don’t want to make any of those! We have to make sure we know what we are doing.
What you should do on your first days, is schedule 1 on 1 meetings with your new colleagues.
First and most important is to meet with you team leader and teammates. On that, I will expand in the next paragraph. But to get the bigger picture, you must go through a few more work mates.

Start the meetings with a short small talk to make the meeting pleasant and make a good first impression. Questions like - how long have they been working for this company, and how do they feel about it. Just to make the conversation flow.
Before asking any professional questions, let them lead the conversation and let them have their own take on your job and responsibilities. They might add important issues that you haven’t thought of. Then, make sure you went over these topics according to your colleague’s position:

Project manager - work flow (Scrum, Agile, Kanban), project management technologies (like Jira, TFS, etc…) and how to use them, who assigns you with tasks and bugs, who gives time estimations, who prioritizes your tasks. If there is no project manager in your team, the responsibilities are split between your team leader and product manager.
Product manager – The product (past, present and future plans), monetization (or better – how does the $money$ get in?), product pitfalls and work flow.
QA engineer – work flow and pitfalls.
CTO / R&D / Tech lead / any high ranking superior – the product, responsibilities, pitfalls, present and future challenges. Expectations.
Team leader – this is your direct superior. It will take more than just one meeting, and this is crucial to your success, thus, I will expand more about this in the next step.

Getting to know the team and work environment

First meeting with your TL, should start like the previous mentioned meetings (small talk, then let him lead). on your turn to ask questions, make sure you know the following:

Project architecture (there might be more then one project)
Frameworks in use (Angular/Vue/React for frontend, any CMS like Wordpress/ Drupal / SharePoint or MVC in the backend like Laravel/ Symphony / Springboot )
source-code management (GIT, SVN, etc…)
DB (MySQL , MongoDB, etc…)

You can and you should do a retake on this meeting with your teammates.

Getting to know the technologies

After talking to your TL, he might mention a technology you don’t know or don’t remember.
It’s very important to stop at this point and take a few days to learn it, before diving in to the actual code. If you are using a technology like Laravel, or Wordpress, take at least 3 – 6 days to learn the basics. Get your hands dirty and build a mini site with minimal functionality according to the guides you found on the web.
If it’s a frontend technology like React or Angular, take another 2 – 5 days to learn the basics and build a small project like a task manager. Again, try to apply the architecture you found in the web guides.

Getting to know the project architecture

Once you have acquired basic skills in the framework technologies, it’s time to dive into the projects files. Ask your TL and teammates to describe the architecture, and if you notice any differences from what you know about these technologies (ergo, how should a Laravel or React project look like), confront them in a professional manner. Ask why was it done this way, and not that way.

Ask for a description of the work folders. Approach this as if you are going into a library for the first time, and you are trying to learn its order. If in a library you would have categories like: science fiction, adventures, comedy, miscellaneous and etc…, in a typical dev project you would have categories like: framework core files, templates, classes, UI functions, services, general files and etc... You might also have files that are not where they belong, due to legacy issues. Also, know the location of the configuration files. You hardly get to make any changes in them, but knowing their whereabouts is very important.
Objects & Classes – it will probably take you more than a while to learn ALL the objects & classes, there would be only a few that you will make constant changes in them. Try to focus on them.
Routing – how does it work? Very important to find your way around inside the project.
Plugins - 3rd party software that you use in the project.
Debug - Understand where does the code starts. Get your hands dirty and start debugging. Have a look at the product, find something that catches your eye, and find it in the code. Make changes and revert.

Getting to know the coding style

One might say this is part of the architecture. I would like to give it an extra attention, this is the bits and bytes of your team’s work;

Naming conventions - does the functions and variables use camel case or underscores? Do the functions name make sense to you?
Design patterns - getting to know the applied design patterns in the code. How are they applied? Are there any design patterns that you are not familiar with? Stop and learn them.
Git messages convention.
Documentation – hopefully for you, your new team documents the code.

Get your credentials

Another reason that developer’s first days of work are slow is lack of credentials.
Without them you will constantly get stuck. Make sure your TL and IT manager give you all the credentials you need:

Email
Project management tool (Jira, TFS, etc…)
Cloud, Servers, DB
Server build tools
Dashboards or CMS access
Communication tools (Slack, Teams, etc…)

Getting your first task

The moment you solve your first task is crucial for the primal impression you give your superiors. Push your team leader to have a “mini-task” ready for you, and try to solve on the first week.
Just to get things going. Don’t make the “ignition” a long tedious process.

Summarize

Sitting on the fence, waiting to become an active and productive team member is a bad practice. Push yourself and show initiative. If it brings you joy, you are definitely on the right track!
Now, all that’s left is:

worker = new Worker();
worker.init();

// Any comments? Please share!

Installing Xdebug on PHPStorm for dummies

Ori Volfovitch — Sun, 15 Sep 2019 19:12:19 +0000

When I was asked to install Xdebug on my environment at work, I found multiple guides on the web. None of them were exactly what I needed.
At my workplace, we use PHPStorm as an IDE, and our local environment is Wamp (the headline says for dummies).

So, after scavenging information from multiple guides, I finally got it to work, and wrote it in a document for my teammates.

Lucky for you, I like to share!

Step by step:

Go to php.ini file, make sure that xdebug.remote_enable = 1.
if you are not sure where is your php.ini file is, and you are using Wamp, you have shortcut from your taskbar:

Then:
In PHPStorm, go to File | Settings | Languages & Frameworks | PHP and
choose:
- PHP level => 5.5 in my case. if you are not what is your PHP version, echo phpinfo().
- CLI interpreter => add a new interpreter from a Local Path with the following definitions: If you are using Wamp, I assume you have that file in the Wamp folder like i did.
In File | Settings | Languages & Frameworks | PHP | Debug
make sure the Xdebug definitions are as following:
Go to Run | Edit Configurations and add a new PHP Web Page
configuration with the following definitions:
- define a localhost server if needed
- Start URL is the address of the page you would like to start the debugging.
Go to Run | Web Server Debug Validation and make sure the
debugger is configured properly:
And finally, start debugging:
- Press the Start Listening for PHP Debug Connections:
- Press the Debug button, or Shift + F9

Happy Debugging!