Forem: Łukasz Żarski

Trailblazer is back, better then ever!

Łukasz Żarski — Fri, 03 Jul 2020 13:09:49 +0000

For those who know Trailblazer - you know that for the last 6 years TRB evolved a few times, introduced a lot of great ideas but also had it's problems: missing documentation, lack of communication with the community, and inconsistent approach to some problems. We strongly believe the current version, along with the support of the core team and the new landing page (with complete documentation) is worth working with.

For those who somehow haven't hear about Trailblazer - check it out. Probably for some complex projects where Rails aren't sufficient that tool could be really helpful and efficent.

The main changes coming with the new version of TRB relate to:

Major API change,
Autoloading,
New website with complete documentation,
Tracing.

API CHANGES

The updated version 2.1 contains some necessary and sound improvements in the method signatures. One of these changes is the replacement of the automatic merging of params part and additional options with the possibility to pass one hash to the call and do the merging. Second major change in API is that ctx elements are now accessible both as strings and symbols like in a hash. It’s worth noticing that ctx object is now documented in its own section.

# old style
result = Memo::Create.(params, "current_user" => current_user)

# new style
result = Memo::Operation::Create.(params: params, current_user: current_user)

AUTOLOADING

The significant change to autoloading is return to Rails file and class naming structure for operations. This change allowed removing the trailblazer-loader gem, which was responsible for causing some issues and inconsistencies.

NEW WEBSITE

The goal behind creating a new website was to make it as simple as possible. A lot of pages accessible through the top navigation, and then the documentation behind the DOCS link.

The documentation has been structured in such a way as to ensure the fastest possible access to consistent information. There's even added a new search function - something that TRB user base has repeatedly asked for. Just press the / (or Shift+7) button in the docs.

TRACING

The 2.1 version comes with the ability to track the operations - something that was missing in all the prior releases. This change makes debugging deeply nested operations way more pleasant.

Either you know TRB already or you never heard about it, check out the blog post about the history and changes of trailblazer 2.1 and give the core team some feedback!

The Art of Project Management - part 2

Łukasz Żarski — Thu, 14 May 2020 11:34:20 +0000

INTRODUCTION

In the first part of the cycle, we talked about initial estimations (in our case project concept) and characteristics of a good leader based on the first chapter of Sun Tzu’s TAoW. Since we established that the preparation for the upcoming new challenges is crucial in terms of accomplishing success, we can now move to adopt a strategy and adjust tactics to our situation while still focusing on our ancient guidance. So let’s try to examine in this light the second and third TAoW chapters!

Waging War - Strategy

The second chapter of TAoW is focusing solely on a concept of waging war, estimating available resources, and how to avoid weakening your army by running out of them. Of course, we don’t have to gather a thousand swift chariots or a hundred thousand mail-clad soldiers, thankfully. Nevertheless, we have to be able to predict how many resources will be needed to complete our campaign - we need to create a project cost estimation.

"He who wishes to fight must first count the cost"

The key to estimating it properly is to prepare beforehand, just like we said in the previous part. The knowledge of what to expect is crucial. It allows us to evaluate how many troops we need to assign for the whole operation and also how to provide for their subsistence. In our case, the base of estimation should be an in-depth discussion with our client. It’s not uncommon that our customer can table indispensable cornerstones of the project that are reasonable, but it’s getting harder for him to describe the smaller elements that might not seem important at first sight (or even unnoticeable). It’s our job to extract as much information as possible, mainly by asking a lot of questions. Those questions are intended to enable us to better understand his expectations and the amount of work that will be required. It’s worth keeping in mind that this estimation won’t be certain. It’s more about predicting the cost than counting the actual cost.

After getting all the information that we could get from our client, we could now prepare some scenarios of how using the actual app would look like. I mean, of course, well-known user stories. Those are short descriptions of functionality told from the user's perspective - user cases. The idea behind them is to organize work - basing on them it is easier to section off smaller parts of tasks from the entirety of a project. “Ok, but why are user stories important while estimating resources?” - you might ask. Well, I believe that they allow specifying all of the moving parts within a project, their inner connections, and the order of completion. They help to ensure that none of the aspects of a project are overlooked and every one of them is properly tested. From the customer’s perspective, those initial user stories could be helpful after the project is given to him, simply because he can recreate any of them to find out if requested features are present and are working as they should be.

But user stories are not everything we need to prepare accurate estimations for - we need to go deeper. For example, one of our use cases could be the need to log in to the app by our user. It’s pretty simple, right? But what has to be done to make this possible while making it a pleasant experience? It’s required to design the UX interface, prepare the graphic design of the site, and implement code responsible for the validation of data put by the user in the given fields (at least). So basically we have to divide all of the use cases for smaller tasks and THEN we can think about estimating one case after another. This approach allows us to make predictions that are closest to reality. Without focusing on all the smallest factors it’s possible, that we could draw our estimations right out of the hat as well.

As I said in the previous part of the cycle, we can also align ourselves by using different methods like building BPMN diagrams or creating a schema of the project. Finding the right tools shouldn’t be a problem - there are already plenty of them all over the Internet, and many more still emerging (just like GraphQL Editor mentioned in a previous post for creating GraphQL schema, documenting it etc.).

But even if we manage to prepare a lot of information and ancillary materials there is always a risk of a huge under/overestimation. It’s a human factor. That’s why it is always safer to go through initial estimation with other members of your team. Sure, the estimation of every task won’t need to be double-checked but look from other perspectives will allow us to minimize the aforementioned risk.

All of the above sound nice and easy, right? Almost ideal. It is, but it requires almost ideal conditions as well - time and budget, that could be strictly limited. For example, our client knows what he wants from his potential app, but has little to none idea what should this app contain and how to execute this. On the other hand, he seeks to apply for donation and there are just a few days left to present the cost predictions to the granter.
So what when the customer that wants to engage in a project does not have enough time or other factors are in the way of preparing complex estimation? Well, assuming that our customer has limited resources, skipping estimation altogether would be a mistake because it could lead to stretching his budget a lot in the future and not meeting the set deadlines. Instead, we could make use of our experiences with other projects and try to guide our customers with propositions based on them. A whole lot of projects have some similarities.

Let’s take the previous example of a user's login into an app - that’s pretty common so most PMs and their team members know how to handle that. The same goes for things like online payments, placing an order, etc. Using those experiences might let us focus more on unique parts of the project while not letting those other parts slow our progress down.

But it is possible to make the process of estimating simpler and shorter. It won’t be as accurate of course, but it will give us the overall picture. In this scenario, it is very important to determine as many general aspects of the project as possible by communicating with the client. It’s even more important than in our close-to-ideal scenario before. Why? Simply because we now should be focusing on the bigger parts of the project and we can assume that we will have to take care of the details. At this stage of the project, it might not be important, for example, how something will look like or how, let’s say, restoring a forgotten password would work. Based on information acquired from the client we can now prepare, you guessed it, user stories. The difference here is that we won’t be splitting those user stories into smaller tasks to estimate them individually, saving us some time. And doing that shouldn’t be that hard - a whole lot of projects have some similarities between them, just like logging into an app in the example mentioned before.

I have stated before (twice already and I can’t promise that I won’t do that in the future) that using other tools, like:

creating a schema,
BPMN diagrams,
preparing mockups.

All of above could help us to guide our project from the beginning and estimate the costs. I stand by it, but it is worth saying that using those is not essential. When the circumstances aren’t as we hope for them to be, we can skip them and go back to them at later stages. It will allow us to create a faster, but slightly less precise estimation.

“Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays.”

According to TAoW a country never takes advantage of prolonged warfare. It can exhaust the country's resources to a minimum and bring many to a fringe of poverty. Maybe poverty itself is not a real issue in our case, but it definitely could influence the financial state of our company. That’s why we should prevent stagnation in our project - this includes preparing estimation. Sure, the first approach that I talked about in this article will prolong the process somehow, but the key is to try our hardest to make this swift. For example, an email exchange with our customer that was supposed to bring us more light on the project could take days, taking into account that it is not our and our customer's only seizure. I know from my experience that setting up a call or meeting with a customer in person might be way more efficient than sending a bunch of questions and waiting for a response from the other side. The key here is to come prepared, so before the said meeting ask yourself a bunch of questions about the specific parts of the project. For example, if the user of an app should be able to create an account in it, then those questions could look like: “What data user is supposed to fill-in? All of that data is supposed to be editable or just only some fields?”. This will help us to stay on topic instead of conducting a meeting about every small piece or the subjects that are not that relevant (at the moment at least). Also, a lot of the previously unspoken issues can come up during such a short meeting so we could say that profit coming with them is double. If that’s not an option, then try to make your emails to be as precise as they can be and point out those aspects of a new project that need to be discussed more further. While asynchronous work is the approach to go with by default, it is worth realizing that there are some scenarios when actual talking live could be more fruitful.

So, to conclude, how exactly should we choose “strategy to adapt and tactics to adjust to”? Well, it depends. Just like a commander of an army, in the face of a new challenge, we have set goals to accomplish while making sure that those goals are achievable. That’s why we need to be fully aware of the resources to our disposal and tailor our plans according to that knowledge. By following the same approach in every situation we expose ourselves to a risk of losing otherwise winnable battles and, in the long term, even a war.

Keep in mind that's my interpretation of a second and third chapters of TAoW. I'm aware that many of you will have different thoughts about the subject and I'm really looking forward to read about them in the comments section!

Synchronous and Asynchronous JavaScript for Beginners

Łukasz Żarski — Tue, 24 Sep 2019 10:35:10 +0000

This article was created by our dev Bartosz. It is also the next part of the bigger series, all the previous parts you can find here :).

A lot of water in the river has passed since my last posts about Javascript. It was not easy to find time for the next part. But ... I succeeded and would like to share something that has been bothering me for quite some time.

If you read my posts, you might remember that I mentioned that javascript works synchronously and is a single-threaded language. And what about this asynchronicity? What about AJAX requests? What about fetching data from external APIs asynchronously? I decided to go over all of this and break it down to the smallest pieces to present it in a most approachable way. In a way that I would love to learn from. Let's get started.

Single-threaded Synchronous

I know that I have already written about it but I would like everything to be at hand. I hope that after reading what I want to tell you, you will not feel the need to look elsewhere to find out about the basics of the synchronous and asynchronous facets of your Javascript.

So what about this single-threadedness and the synchronicity of Javascript? It all boils down to two very essential functionalities of the language. Namely, no matter how many lines our code has, everything we wrote will be done one line after another and one command at a time. Javascript has one thread in which the commands written by us are executed and the next one will be performed only when the previous one is completed. The end. Hey, but the asynchroninicity... - you might ask. I know, I know, but please wait a bit. Now it's time for my favorite console.logs.

Even in this case, when we do not perform complicated tasks, the command console.log('World') will be executed only when the first one - console.log ('Hello') is completed. One thread, synchronous. However, my most beloved example is below, which although when looking at it, it seems that it should return the true, it does not.

This is because the JavaScript engine does not look at this expression (3 > 2 > 1) as a whole. Of course, in the first step, it estimates 3 > 2 which returns true thanks to basic math. This true is parsed to the number of 1 because we do not know if a true is greater than the number of 1. In the end, the engine looks at the 1 > 1 which is false therefore result of the whole expression is false.
So once again in a nutshell - one thread, synchronous.

After this thrilling introduction, which was really just a reminder, we are moving to ... another repetition of what I have already written in previous posts (Execution Context: Execution Phase, Hoisting, Execution Context: Creation Phase, Invocation, Execution Stack). Execution Context and Execution Stack (also known as Call Stack). The first one appears every time we invoke the function and has its information about for example variables. The latter is simply the stack on which the Execution Contexts of the called functions are pushed. In this case, however, no words depict it as well as a few lines of code.

Why so many console logs? Well, I think that nothing will present it better than just logging what happens at the moment. When we run the script, all variables and function statements will be stored in memory (hoisting ladies and gentlemen), and then the code will start to execute (Execution Phase). I will use chrome dev tools and put in a few breakpoints, thanks to which we will be able to pause the execution of the script at any time.

As you can see, I set them at the beginning and end of each function and the logs will inform us when the function code began to execute and when it ends.
As the code is executed from top to bottom, nothing will happen until the line 23 ... and then boom, the first console.log appears.

Breakpoint set at the beginning of the function one (attention! Breakpoints pause BEFORE the marked line, in this case BEFORE console.log!) informed us that console.log('Im about to invoke one function!') and one(myNumber) was executed. On the other hand, console.log('I just finished everything!') did not show even though it is a line below. Why? Why does it look like if we were at the 4th line? Because the Execution Context of invoked function was pushed on the stack and everything after that does not matter to the JavaScript engine at the moment.

Here we have a blue arrow that shows us in which Execution Context currently executing code is. Ok, now let's get to the next breakpoint. Will it be in line 7?

Well, it turns out that we are already in the function two and nothing that was after the invocation of this function has been called. So…

... must wait. On the other hand, the Execution Context of function two lands on the stack.

In it, the function three is called and everything works the same as in the first case. The last console.log has to wait because we have arrived in the Execution Context of function three.

The matter here is simple. We do not invoke anything (in function three), so the whole thing is over now. In the console we have:

Ok, what about the rest of the code? Do we forget about it? Of course not. Since we will not create a new Execution Context at this stage, when everything is done in it, it will automatically be poped from our stack and...

... we will come back to …

So we are back in the Execution Context of function two, and it turns out that there is still something to do. The closing console.log is printed and as above, we pop the Execution Context from the stack. The last one remains.

Here, everything that's left is getting done.

And since everything has been done, the stack is empty! Phew, lots of pictures behind us so maybe now is the time for something that is not a repeat?!

I mentioned above that I wanted everything to be in one post but there is one more reason why I decided to do this "small" reminder. Now imagine that when visiting various websites, the example discussed above is the only way the websites operate. Something must be done for the next thing to be started. You probably agree that it would be very burdensome from the user's perspective. A good example is something like that.

The function waitFiveSeconds does what it's called - it waits five seconds. Because JavaScript is single-threaded and synchronous, it does not matter how many time we would click the mouse in the first 5 seconds. In the end, the result would be:

Believe me, I tried very hard. As I wrote above - it would be very tedious. However, fortunately, JavaScript activity in the browser is more complex and what happens in the main and only JavaScript thread is not the only thing that actually takes place in the browser. It would be too boring right?

However, what did the above example show us? Mainly that blocking what is supposed to happen in the main JavaScript thread is very dangerous. If something that takes some time to execute would land on the stack, it could easily break the user's experience of visiting our website. Since we already know that it should not be done, what can we do instead? The answer is simple - Asynchronous Callbacks.

In the above example, we have two functions. One is invoked on click (onClick) and calls setTimeout(). setTimeout in our case accepts two parameters. The first is the function (also called a callback function) that we want to invoke. The second tells how long will it take to invoke the passed callback. This time, clicking on the browser window will result in this:

In the above example, we have two functions. One is invoked on click (onClick), which implies setTimeout(). setTimeout in our case accepts two parameters. The first is the function (also called a callback function) that we want to invoke. The second tells how long will it take to invoke the passed callback. This time, clicking on the browser window will get something like that:

As I mentioned above, many things can happen in the browser, some of them being the event loop, the task queue, and web APIs. The latter, eg ajax requests, setTimeout or DOM (document itself) communicate with the stack and task queue. Let's take the last piece of code as an example. Some might have been surprised that the code seemed to go away without waiting for the waitFiveSeconds function. This is because setTimeout uses the timer API. The whole action is put away from the stack for the time equivalent of the number of ms we gave as the second parameter. Besides, setTimeout callbacks are asynchronous. Of course, not all callbacks in JavaScript act like that. Even more so, most of them are synchronous. For example callbacks that we pass to array methods like map() or filter(). However, some behave asynchronously. The simplest and most often used in examples is setTimeout. It lets us simulate fetching data from the server.

As the function waitFiveSeconds was temporarily released from the stack, "I was clicked!" appeared in the console. After 5s, the function waitFiveSeconds will be pushed from the web APIs to the task queue

Task queue is nothing more than a queue on which tasks are pushed. Nothing prevents you from queuing up more than one task. Of course, we do not want the asynchronous functions to be forgotten, so we have to somehow redirect them back to the stack. Fortunately, we do not have to solve it personally - if our stack is empty (meaning nothing is to be done, no execution context has been created) and our task queue is not empty, the first thing is pushed out of the task queue. As the function waitFiveSeconds was temporarily released from the stack, "I was clicked!" appeared in the console. After 5s, the function waitFiveSeconds will be pushed from the web APIs to the task queue.

The most common example of using setTimeout is when we set the second parameter to 0. After a slight change in the last code, what do you think will happen?

Precisely, the result is very similar to the previous one.

This is because function waitZeroSeconds has been postponed and will only be executed when our stack becomes empty. Considering that, after a click, our stack cannot be empty because the Execution Context of the function onClick lands on top of it. Only after everything that has been initialized in it is popped off the stack (in our case - console.log ('I was clicked')), the function waitZeroSeconds will be performed.

Since we already know about things like JavaScript asynchronicity in the browser and how synchronous JavaScript deal with this, let's look at an example in which we have two simple queries to an external API, and two console.logs outside them.

Fetch is a modern replacement for the XMLHttpRequest and takes place asynchronously. It is used to send requests to API to retrieve data.

The matter is simple. At the beginning in the console we get:

Since we know that fetch works asynchronously, we'll get a console.logs after the stack is cleared. The question is, however, in what order? (hint: check the number that indicates the amount of data fetched).

So?

Everything nice and easy, right? Almost. In the example above, a thought arises - what if we would like to get the data first and use it in the second query? Let's take a look at another case.

Note that we do not know the id of the post and send the request to endpoint ... / posts / 1 to actually get it. Then we want to use the saved id and retrieve all comments belonging to this id.

Unfortunately, we did not succeed. This is due to the fact that what landed on our stack was a query without information about the id. Now we will modify the above code a bit.

Consolidating knowledge is the basis, so I describe the order once again.

before getComments
inside getId
id in getComments function
after getComments
all comments

What can we do to properly get data about comments? There are few solutions but the newest / most popular is using async / await.

Simple and pleasant right? The only thing we did was add two keywords - async / await. However, what really happened? Here we will have to enter the territory called Promise in Javascript.
What are the Promises? First of all, these are objects, and secondly, they are quite specific objects.
Most importantly, they are simply promises that occur in a similar form as in everyday life. Each of us has promised something at some point of our lives. To the parents, that we will clean the room, the employer, that we will be on time in the office. Every promise has two stages. The first stage is the stage that I like to call transient. It looks like we made a promise that we'll take out the trash before the end of the day. Since we still have time, our promise is in the state

that is waiting for the final result. In this case, the value will be undefined. The next stage will tell us whether we were able to take out this unfortunate trash before the end of the day or not. If yes and our mission has been successful, then the status will be easy to guess -.

Here, for example, the value is simply an empty string. If, however, we have forgotten and we have failed to fulfill the promise, then the status will be (also an empty string used).

Depending on the status, different things can happen. Let's start with a simple example.

"What the hell is going on here" - you might ask? Well, through new Promise, we create a new object that accepts the callback function with two parameters - resolve and reject, which we later use depending on whether we are above or below 18 years. As you can easily guess, the resolve will serve us to handle the variant when we fulfill the promise and reject when we do not fulfill this promise. It seems pretty simple, right? Now let's move on. If you promise something then ... Well, then what? Here the keyword "then ()" sneaks in. Promises that are fulfilled will be a resolved promise object. "then ()" takes this value and uses a callback function to process it in some way. Let's modify the code a bit and then use then ().

Look. In then() we used a callback with the msg parameter. Because we already know that the promise will be fulfilled, msg will accept the value of the argument we have in resolve (). In our case, it will be a string - "I am old enough to ...". Thanks to that we will get

Now let's see what happens when we change the age in a variable to less than 18, let's say 17.

We got a mistake. This is because then() is used to handle your resolved promises. If, on the other hand, we want to catch a promise that we have not been able to fulfill (was rejected), we will use catch(). So let's add catch() to the code and keep the age of 17.

It will look like this. Of course, the principle is the same. In the error parameter, we get an argument but this time with reject() string "What a shame". Yes, the result will be:

As I suggested. Everything is fairly simple and transparent. Ok, let's add one promise..

As you can see, we have created the order function that will return us a Promise. It's the same Promise as the previous one, the only difference is that it's always resolved in this case, so its value is an argument in resolve(). But what more interesting is what is at the bottom. In the 17th line, we called the function order. Thanks to the fact that in then() we return Promise, we can use again then() (at the end we return the promise), but this time the result of fulfilling the promise will be the argument given in resolve (), which is in the function order.

So what about all of this? What does this give us? Well, thanks to this, we can chain Promises and pass the results from previous Promises to the next ones. Also, the result will always be passed (resolved or rejected Promises) which is very helpful in communicating with external APIs. I will modify the previous code a bit, add some functions that return Promises and chain them.

By capturing values in the parameters of callback functions, we can pass everything down the line. Let me also mention that it is worth remembering that we should always use catch() to be sure when something unexpectedly fails. Thanks to using Promises we do not have to call catch() for each function then(). It's enough to add 1 catch() at the end of any chain of Promises.
Ok, after this brief description of Promises, let's go back to async / await thanks to which we were able to firstly get the post's id and then use it to fetch further information from the API. So what does async / await do? Let's go back to the previous example.

Why did it work? We have received the desired result because await stops the execution of the further part of the function until the moment we get the response. For this reason, only when the function getId is able to return the id, console.log from line 11 and everything that is in the function will be completed. This is a very important thing. We should only use it when we know that action would block the main javascript thread, which would prevent the user from interacting with the application. Okay, but what else does it give us? Well, async / await introduces several facilities that make the code more readable.

Here we have an earlier code with some changes. We removed all then() and the code looks somehow nicer, right? Using await, we not only stopped further execution of the function's code but also obtained immediate access to the answer that Promise returns from fetch.

As you can see, I did as I promised. I tried to include all relevant information in one post. Of course, you could add a bit more to it but in the end, I think that if someone as a novice developer would like to learn more about how the asynchrony works in Javascript, then he has almost all of the needed information here.

The Art of Project Management - part 1

Łukasz Żarski — Mon, 09 Sep 2019 09:44:42 +0000

INTRODUCTION

“The Art of War” by Sun Tzu is already well-known East Asian ancient warfare guide. It contains complex advice on how to approach an upcoming war, how to conduct the reconnaissance of the enemy, how to turn the enemy's weaknesses into our advantage, how to manage the army and, generally, how to succeed with massive military operations. “Ooook, but what all of this has to do with Project Management?” - you might ask. Well, a lot. Project Manager, just like the Commander of an army, should be able to properly set the initial concept, choose adjusted strategy and tactics, estimate available resources, manage those resources wisely, attain previously set objectives, gather information and recognize the risk bound to the planned procedures. For some of you, It may sound easy, but for sure it can be tricky - it gets a lot harder with a big scale project, simply because those require a lot more attention. But the bits of advice given in TAoW is as useful even when the project that you’re leading isn’t that big.

This article is my interpretation of TAoW related to comparison of conducting a war to efficient Project Management for a web or mobile app. I’m pretty sure that your opinions and reception of TAoW may be a lot different, that’s why I'm inviting you to discuss this subject in the comment section.

So, let’s jump to the first chapter!

Initial Estimations - Project Concept

“Now the general who wins a battle makes many calculations in his temple where the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to win or lose.”

According to TAoW, preparations for war are the best way to enter the conflict without chaos, randomness or insecurity. Many different factors are crucial in each battle and could overwhelm the scales of victory. For every commander it’s very important to be aware of those factors beforehand - after the war has started it is probably already too late to investigate them. We can see an obvious parallel to Managing Projects right there. When we know that there is a possibility of “war” (in our case - a new project) on the horizon, we should be prepared and we should be familiar with all of those factors, that could make an impact on our project in one way or another. But how could we define them? According to TAoW, five elements are important while pursuing a success: the Moral Law, Heaven, Earth, The Commander, Method and Discipline that might be useful. Let’s talk about each of them some more.

The Moral Law factor is responsible for willingness, that subordinates manifest about following their ruler. On the Moral Law depends, whether those subordinates will follow him undismayed. For this, the ruler has to earn their trust by showing that he is competent, reliable and, of course, trustworthy. Accomplishing complete accord between ruled (your team members) and their ruler (you, as PM) is always a great starting point to perform any complex maneuvers. The best way to accomplish that is to, simply, practice. When we and our team are put in the state of standby, we must have full clarity as to what actions should be taken, in what order and it’s nearly impossible without prior training. But how to train without having a new project already? Well, there are some possibilities. In our company, we started our project for learning purposes (assuming, however, that this project may bring more tangible benefits in the future, both for us and for others). It was a project of a web app, responsible for the efficient management of the football (soccer if you’re American ;) ) pitches in our city. The goal was making those pitches more available for residents and making the whole process of booking of sports facilities more organized. We approached this project just like we would approach any “real” project. We’ve designed basic functionalities, we prepared mockups for most of them, created documentation and we started to work on them. It was a bit challenging to coordinate because there was no permanent team of developers working on the project - those who had some spare time jumped in and those who were given new tasks in "real" projects were moving away from it. But we gained some experience and learned how to effectively organize ourselves - our practice exercise paid off.

Heaven described by Sun Tzu means the cycle of night and day, times, seasons and weather - all of the surroundings considerations. In our case seasons may respond to things like summertime, when a lot of people want to go on holidays - the time when developing a project could slow down. The same could be true in a winter holiday season, especially considering Christmas and New Year’s Eve (or different holidays, depending on the region). All of this could influence our estimations in a major way, so it is important to keep this in mind. The other crucial factor connected to Sun Tzu’s Heaven is the cycle of night and day. Your team members don’t have to necessarily work in the same place, they could be spread out all around the world. That’s why you must be prepared to coordinate their work while having in mind different time zones, which might not be an easy task. Those considerations won’t always be the same to you as a PM of course, but the ability to know your surroundings, limitations and making certain predictions about what is going to happen is extremely important.

Earth mentioned in the first chapter of TAoW refers to distances, different terrains that might decide on success or defeat. As PM’s we, thankfully, don’t have to study topography, but we have to realize what kind of technology should be used in our project and what are the benefits and risks resulting from it. Just like good commander should predict how marching through narrow passes, steep hills or moldy swamps will impact mobility and safety of his army, you should predict how chosen technology - designated “path” - will impact maintaining the project or its expansion.

The Commander factor stands for all of the characteristics of a leader, that makes easy for subordinates to entrust management - his wisdom, honesty, strictness. When a Commander can display them, it shouldn’t be hard to believe that he is capable of leading others to success. It's worth noticing that wisdom and sincerity are considered more important than other Chinese cardinal virtues while courage and strictness are replacing uprightness of mind and self-respect, self-control. This means that, as the PM's, we should place particular emphasis on the correct interpretation of the information available to us, a reliable assessment of the current state of affairs, integrity and, at the same time, a certain and firm approach to the circumstances encountered, whether favorable or not.

Method and discipline refer to proper management of the available human resources, hierarchy and structure, provision of tools and adequate environment. It’s pretty simple really - just like in managing army, you have to manage your team working on project: determine the chain of command and responsibilities assigned to each member while providing everything that will be needed for your team members to be able to solely focus on their goals without any distractions - within reason that’s it.

“The art of war, then, is governed by five constant factors, to be taken into account in one’s deliberations, when seeking to determine the conditions obtaining in the field.”

Those five factors are the pillars of good preparation, but keep in mind that it is possible to gather more information before the beginning of the huge operation than covered in those factors. This information or occurrence of other circumstances should result in adjusting our approach to operation accordingly, even independently of adopted rules.

Ok, so - thanks to TAoW - we established that it’s crucial to identify those important pillars and adjust our planning to relying on this identification. This seems easier to say than do. But no worries - there are many, many tools that could be valuable in the process of identifying some of the pillars mentioned above. One of them is creating BPMN diagrams, depicting the processes that will take place in your app and the whole logic beneath. You can think of them as strategic maps, helpful while planning the next move of your army. Those diagrams (or maps) are supposed to help you with setting directions, plan resource management and shell out possible difficulties that may occur on the way of your subordinates to a set goal. You can also pair your BPMN diagrams with mockups of the app, or even use tools like GraphQL Editor (I wrote one post about it some time ago, you can read it here - it's even related to the training project in our company that I mentioned before). With the combined force of those, you can achieve a level of transparency in your project between you, your team members and your client that would be extremely hard to accomplish without those tools. One of your team members isn’t sure how something should work? Ok, here’s a diagram that explains it. Your customer has a hard time to figure out how something should look? Ok, no problem - there's a mockup for it, that we agreed upon earlier. Building diagrams and mockups will help you to predict potential difficulties, the impact of the chosen technology. They will help you choose the right “path” for your project.

It is pretty simple to compose flow and look of your app using tools like that, and using them could eliminate a lot of major or minor issues that could occur otherwise. This approach will save you a lot of potential stress in the next stages of the project implementation as well. So in this case, with small contribute comes a huge profit. And I mean HUGE.

So, we already talked about defining the five pillars of preparation leading to success and the way to translate those pillars mentioned in a book for our real-life projects. Is there anything more that we could extract from the first chapter of TAoW that could help us be a little more self-aware while starting a new project? I would say “yes”, and that's why: the following parts of TAoW’s first chapter advice identification of the enemy’s weak spots and exploiting them. While we, PMs, are approaching a new project there is no literal “enemy”. But still, we could gain a lot from that advice. Just think about all of the unforeseen circumstances, unexpected problems, lack of funding, lack of time and every other negative aspect of developing a new project that could sneak in, and try to perceive all of this as one - this is our true enemy. He is built from those factors. Our job is to investigate those and fix them (or even better - prevent them from happening), instead of exploiting. Defeating this enemy by good management will allow you to create a state when your team members will be 100% sure what they are doing and why they are doing it. Believe me, once you experience that state you will never want to go back.

This is the first article of the series. I hope that at least some of you will enjoy it, and some of you will express your opinion on it in the comment section :). Thanks!

ES6 for beginners - Part 6 (Destructuring, Template Strings)

Łukasz Żarski — Fri, 14 Jun 2019 11:23:44 +0000

This is the sixth part of ES6 tutorial, created by our dev Bartosz. All of the previous parts you can find here :).

destructuring

In the current post, we will start with the code using ES5 syntax.

Imagine we have a simple code like that somewhere in the project.
Now comes the time that later in our code we want to refer to our object and extract some data from it. We would probably do it this way. A simple dot notation allows us to get data from the object.

Is this a good way? Of course. Could we do better? Since the ES6, there is a way. You've probably heard about DRY a lot, which means Don't Repeat Yourself. In the example above, as you can see it yourself, we repeat ourselves several times. Two vars, two expenses, two types, two amounts. This is a place where ES6 comes handy to let us simplify writing a bit.

What we wrote with ES6 is completely equal to what we used before. This way of writing means that from the expanse object, we want to extract type and amount then assign them to const variables with the same name. We must remember that we need to specify exactly what we want to refer to by using the same variable name.
But aren't there still any duplicates in the example above? Of course, there are. So let's modify our code even more.

As you can see, we completely got rid of the duplicates. Let's check the console if everything works as it should.

Cool. If it works now, will it work if we change the name of the variable to another one that does not exist in the object?

Unfortunately, but no. The convention of this says clearly that the variable name has to be the same as it is in the object. But what if we really really what to use a different name of the variable? Well, there is also a solution for that but try to solve it yourself (a small hint, use a colon and the name of the new variable).

What else can we do using destructuring? For example, we can extract a parameter passed to a function. We will start as above from the script written using ES5.

Ok, hold on. And what is this notation ?! Here we are dealing with another feature from ES6, template strings.

template strings

For a moment we will leave destructuring to see what template strings are.
Template strings, or otherwise template literals, are nothing more than syntactic sugar in JavaScript. Here, we will also use two examples. The first one will be something you probably used to do using JavaScript.

We've all expected this. Once again, however, the question arises whether you can write it a little more elegantly. And the answer is once again that you can.

Everything works correctly. Additionally, we do not have to limit ourselves to the year variable. We can put any expression in { }. If we would like to receive a previous year, just change it to {year - 1}, etc. It is possible that it is not visible enough but we use backticks to write the template string. We can find them on the keyboard next to the number 1 (on the left). And that's all you need to know. It is not complicated, and I think that it will often help with the code readability.

destructuring

We are going back to the previous example.

If we know what the template strings are, we can go further. And what are we doing next? Of course, we try to use destructuring to make our code more beautiful.

Once again everything works correctly. Instead of writing the name of the object every time we want to refer to one of its property. All you need to do is invoke the function with an argument, which will be the object. In the function, we will pass the properties to which we want to refer in the body.
Everything is beautiful and nice but shortening the code is not the only thing for which destructuring is used. Often destructuring of an array is also used. When we were destructuring objects, we were pulling off properties. Destructuring arrays is about pulling off individual elements.

Here is another way to use destructuring. The difference between destructuring of an array and an object is that { } has been replaced by [ ]. I am encouraging everyone to play around with it a bit now. After that, we will take a look at the destructuring the mix of arrays and objects.

In the example above, we have an array with 3 objects. We know that using destructuring we can extract data from both, first and second. Now let's see how it is done.
Of course, we start with the array, as it is "outside" our objects. firstElementOfArray will be our first object and in the first console.log. Of course, we will get the whole object back. If we add to this { } and change the name firstElementOfArray to the name of the one object's property, in our case name, we will get its value. Simple right? If we would like to gain access to the name but the other company, we would do it in the following way.

It probably looks a little more confusing, but it is not that complicated. Let's start from the beginning. In the beginning, as the object is "outside", we start with { }. Now, to get to the location property, we have to type the variable exactly with the same name, i.e. location { location }. Leaving it this way, we would get all the values, i.e. ["USA", "Poland", "Germany"]. However, when our goal is to obtain only "USA" we must use destructuring once again, { locations: [ locationOne ] }. This way, we'll gain access to the first location of Google. Here I also encourage you to play ... rest.

Thank you all for reading :). In the nex post, I'll be talking about asynchronous javascript. All your feedback will be appreciated :).

ES6 for beginners - Part 5 (Array Helper Methods)

Łukasz Żarski — Fri, 07 Jun 2019 14:56:13 +0000

This is the fifth part of ES6 tutorial, created by our dev Bartosz. All of the previous parts you can find here :).

In the past, we had to have access to external libraries to use most of these methods. They were very popular and therefore it was decided to enter the ES6 standards.
Now we have 7 Array Helper Methods available.

forEach
maps
filter
find
every
some
reduce

By understanding what each of them does you're going to find that you can work with data collection more easily and the vast majority of web application out there is, you guessed it right working with a collection of data. But before we start, I want to mention quite an important thing. All these methods are themed around avoiding working with a manual for a loop. The entire goal of these methods is to stay away from the for loops. Ok, enough talking, it's time for the first one, forEach.

forEach

As this is the first method, I will spend the most time with it. Considering that all methods work in a very similar way, the next ones will be discussed for a shorter time.

Let's start with the fact that for the last time we will write an ordinary and simple for loop, which will console all array values.

Of course, we got all the colors that are in the array.
Then, let's do the same, only using the news from ES6, forEach.

Ok, we received the same. This is half of the success. The other half is to understand what is really happening here, and it is not complicated.
The forEach method, which is called on an array, takes the parameter, which is the Iterator Function. The function is invoked each time when the code in the function's body is executed. Then, our Iterator Function also accepts one parameter, in our case color, which will have an equal value starting from the first, up to the last value from the array. By convention, this parameter should have a singular form of the name of our array.
Additionally, to run the code, we can create the Iterator Function elsewhere lexically at the same level and simply pass it to the forEach method. It would look like this way.

As you can see, we've passed both function statement, function expression, and arrow function.

The main thing you need to remember while using forEach method is that it mutates the array we are iterating over. What if we would like to add string "color" after each of the array's item in our case? Then we would do it by simply concatenating every variable which holds value of the color with the "color" string. Since we are not returning anything but only modify already existing array there is no need for a return statement in the forEach method.

maps

How is this method different from forEach ? Mainly that after we do it we will get a new array.

In the example above, I wanted to demonstrate two things at the same time. First of all, as you can see the way we use the map method is identical to the forEach method. Secondly, and it is more important, so I repeat, using the map method, we create a completely new array. This function is used really often when we want to keep the old version of an array. For example, if the array has some numbers and in one place we would want them to be divided by 2 and in second place we would want them to be divided by 3. By using map method we keep the old version of the array. And since we are creating new array we need to include return statement in the map method.

filter

Another method for iterating over the array. However, it is used in a strictly defined case. Let us assume that we have an array full of objects. As in the example below. Thanks to this method, we will be able to filter the results of our iteration. The main thing to remember using filter method is that it needs return statement and only conditions that are fulfilled are returned.

As you can see, we quickly and efficiently obtained data on the topic that interested us. We do not need to even use the if statements when using the filter method. In addition, we do not have to limit ourselves to one condition. If we want to add a condition that the name equals "Tom" we will do it in this way.

find

The purpose of find helper method is to look through an array. As soon as that element is found with given criteria in the array, a helper will return that record. It is really useful in a situation where we have a massive database with for example unique ids. Since ids are unique and iterating over just a part of the database is faster than everything we could use find a method to force iterating to stop when conditions are met (we found an id).

We changed a bit the array from the previous example and replaced Greg with another Mark. As you can see here, the way of using the method is identical. The only thing to keep in mind when using the find method is that when the JavaScript engine hits the first value that returns true, it will stop iterating further. So the second Mark, which is at the very end, will not be included in the returned value. Also, the entire object was returned, not as in the filter method which was an array.

every / some

As you can see, the value returned by every and some methods is boolean. For every method, the value will be true if everything matches the condition. When it comes to the some method, it is enough that one value will be matched with the condition. As you probably already figured it out, we use it to check if the conditions we check will return true.

reduce

The best way to explain reduce is an example of adding values to an array. The reduce method takes two parameters. The first is the Iterator Function as in the previous examples. The second is the initial value that we can set. As you can see in the above example, we set the initial value to 100 and added all elements to it.

Finally, I would like to say one more thing. It was not hard to see that the old syntax was used to create functions. Here, I encourage everyone to try and replace everything so that everything works according to ES6 standards.

In the next post, we will find out what destructuring is so stay tuned. :)

ES6 for beginners - Part 4 (Rest, Spread)

Łukasz Żarski — Wed, 05 Jun 2019 13:17:32 +0000

This is the fourth part of ES6 tutorial, created by our dev Bartosz. All of the previous parts you can find here :).

REST

What is rest in ES6? The rest parameter syntax allows us to represent an indefinite number of arguments.
We know that in JavaScript functions can have any number of parameters. Besides, we do not have to give everyone an argument. This was mentioned in JavaScript Part 17.
Now let's say that we have a function that takes an unknown number of parameters for us. Example of simple addition of several arguments by the user when we do not know about its number. Using the standard before ES6, we could do it in the following way.

Since the arguments are not stored in the array but in array-like format, we had to create a new array consisting of arguments. ES6 makes it easy for us to do the job using the rest parameter.

Using the myAdd function, we can add an unlimited number of arguments. The reason for this is that by using the three dots ... and the nameOfparameter, all arguments will be thrown into the array.

Also, we must take care that the rest parameter is used correctly, always at the end of the parameters passed. This is since, it will not just work. The error we receive will certainly remind us of it.

SPREAD

It allows an array of arguments for elements calls (for array calls) or elements (for array literals) are expected or an object expression to be expanded in places where zero or more key-value pairs (for object literals) are expected. Sounds complicated? Let's look at a few examples of how we will use it.

As you can observe with great ease we can combine the arrays.

In the next post, I will talk about array helper methods so stay tuned! Thank's for reading and don't hesitate to express your opinion on this post - all of your feedback will be appreciated :).

Top project management tools

Łukasz Żarski — Thu, 09 May 2019 13:53:59 +0000

As I mentioned in one of the previous articles, managing projects is not an easy task. Thankfully, there are plenty of project management tools out there which can be really helpful in organizing work. But the huge amount of different options could make it hard and confusing to choose the tool that will fit your's team the best. That's why I made this list of best (in my opinion) tools for project management.

1. Pivotal Tracker

A Pivotal Tracker is a simple story-based tool that helps prioritize tasks with customer participation. Through a joint vision of priorities, it allows creating a work process that favors collaboration. A huge strength of Pivotal Tracker is the ability to monitor your project's analytics (it's velocity, done stories, story cycle time and story rejection rate). Pivotal Tracker calculates the velocity on the basis of the average number of story points completed during the last one to four iterations. Based on those, Pivotal Tracker predicts the number of repetitions of the story that will be completed. That's my personal favorite, but there are many more that I find useful.

2. Trello

Trello is a tool for organizing project using boards. Its visual representation of tasks helps to see what your current assignment is, who is doing what and where individual tasks are placed in the process and it does it really well. This easily enables the coordination of a project. Trello could be used for collaboration within a wide range of different projects, from work projects to holiday planning, thanks to its accessibility and user-friendly interface.

3. Insightly

Insightly is a robust CRM software. While it focuses the most on developing stronger client relationships (of course), this tool includes a really comprehensive set of project and business management systems. Insightly allows you to manage your around-sales operations and schedule deadlines and easily track progress. Your assignments may take whatever form you want - reminders, checklists, call lists, etc.

4. Workzone

Workzone is project management and document collaboration app which helps people and companies achieve enhanced scrutiny and visibility in their work management. It allows users to arrange projects by tasks, delegate duties, and announce when they are finished. This tool gives an option to join together tasks to learn about how a modification in one area changes the rest of the work process. Workzone will notify you when tasks are delayed and allows project managers to rapidly recognize projects that demand urgent action.

5. nTask

nTask is a relatively new project management tool but it stands its ground by assembling most of the utilities used by the teams on a daily basis into one agile platform for cooperation like a project, time, resource, issue, risk and meetings management. A big advantage of this tool is also a comparatively low price (and a complex free plan), which can be significant in the case of small teams or companies.

6. JIRA

It would be a sin not to mention JIRA in this article. JIRA is very popular and very powerful project management software used by many companies worldwide. It makes it easy to create user stories, to plan tasks assigned to your team members, and to prioritize the order in which they are being implemented while maintaining full visibility. Its usage is not complicated, so you can just jump into JIRA and start managing your projects right away - regardless of whether your project is quite simple or complex.

7. Teamwork Projects

Teamwork Projects is an intuitive, feature-rich project management tool that lets you reduce the complexity of collaboration. It takes care of the everyday details so you can focus on the work that matters — and own the big picture. Whether you need task lists, Kanban boards or Gantt charts, Teamwork Projects has all the features you need to empower your team, optimize your resources and deliver results that make a difference to the big picture.

8. Milanote

Milanote is a tool for organizing creative projects into beautiful visual boards. By design, it feels a lot like working on the wall in a creative studio - visual, tactile and sometimes a bit messy - Milanote is a great fit for designers who work in teams remotely.

Key Features:

Write notes & to-do lists, upload images & files and save things you find on the web
Organize visually using the flexible drag and drop interface.
Boards by default are a private place to think, but with a single click you can create a shared workspace for collaboration with your team
Milanote is filled with hundreds of built-in templates to help you get started with a variety of different projects, from creating a mood board to writing that perfect creative brief.

Of course, there are many, many more of other project management tools. A lot of them might prove to be useful for you and your team or fit your's company needs better. It's all about knowing available options and finding the one that works the best for you.

ES6 for beginners - part 3 (Classes)

Łukasz Żarski — Fri, 12 Apr 2019 14:04:42 +0000

I want to present the third part of the series "ES6 for beginners" created by one of our devs, Bartosz. You can find the previous parts here.

Before we start discussing Classes in JavaScript, one thing needs to be explained. Classes in JavaScript are more like syntactic sugar than the new feature. Nevertheless, as in the case of Arrow Function about which I wrote in the previous section, this is a facility worth remembering.

One of the worst parts in JavaScript is undoubtedly the inheritance system. JavaScript does not really have object inheritance, but something called prototypal inheritance. Class inheritance has been introduced to JavaScript due to the fact that it occurs in the vast majority of programming languages.

So what are Classes in JavaScript except for syntactic sugar, which leads to a more readable syntax? The answer is simple and the same as in other object-oriented programming languages. They are to create objects. They are like blueprints, on the basis of which objects are created. In addition, JavaScript classes are basically special functions.

The class declaration consists of two parts. The expression class and class declaration. Example below.

Nothing complicated. But now let's look at what will happen as in the console typeof Dog.

Exactly as I mentioned. Our class is a function by which we will later create objects.

There are still a few things missing in our Dog class. The first one will be a Constructor. This is a special keyword used to initialize the object data. A Constructor can accept any number of parameters. In our example, we will create two (name and height). Then, using variable this, we will ensure that the arguments passed in the parameters will be saved in the variables. In our case, also with the same names. Of course, it is possible to name the classy property differently than the parameter, as in the example below, however, it is not very legible and not recommended.

But let's return to the normal way of doing things.

Once we have a created class, we can boldly create any number of objects/instances of this class. The way we do it is as follows.

The name of our object in this example will be Staffie. Next, we pass to parameters that we defined in the constructor two arguments. The first "Bur" will be our name, the second 60 will be the height.
Also, we can create methods in classes. The method is just a function that is placed inside the class. So let's add a method that will return the sound of barking.

Now our Staffie has the option of using this method. When we call the barking method in the console, we get:

Since we know how to create classes, let's look at the inheritance. Since the dogs are divided not only by races but also groups, let's create a Terrier class that will inherit from the Dog class. It is also not complicated.

In the above example, we see that to be able to inherit from another class, we use the word extends + the name of the class from which we want to inherit. Besides, we see keyword super. It allows us using the special variable this and have access when creating an instance of the Terrier class to the name and height parameters which are inherited from Dog class.
Another thing that is often encountered is when we want to use our method barking in the case of Terriers. However, the returned value would be something different than in a regular dog.

As you can see, there is no magic in it. Now our terrier Tommy will be barking in a way that any self-respecting terrier does.

Generally, convention from languages like Java in which there is an object-oriented programming model also assumes holding classes in different files. Namely, instead of just like in our example one file with two classes, a better solution would be to transfer them to two separate files. Thanks to such a procedure, our code would become much more readable which is a great advantage when writing.

Dog class

Terrier class

As you can see we used two keywords. Import and Export. As you probably already figured out what they are used for. I will only mention that you can export functions, objects, or primitive values from the module so other programs with the import statement can use them.

Another topic worth mentioning in this part is the static methods. So what are they exactly? First of all, they are created with a keyword static. The most important thing about them is that they are called directly on the class and are not callable on an instance of the class. Their purpose is to create a utility function.

We created an instance of Dog class and named it Staffie once again. Let's try to invoke both methods.

Ok, the method barking works as intended. Now let's invoke the second one.

As you can see it works as intended too. We can't invoke a static function on the object. On another hand is it possible to invoke it on the class as its supposed to?

Great, it does.

So, did JavaScript after the introduction of the ES6 standard start to belong to languages that use the Object-Oriented Programming (OOP) model? The answer is, it does not. JavaScript is still based on the Prototypal inheritance model.

In the next post we'll talk about rest & spread.

ES6 for beginners - part 2 (Arrow Functions)

Łukasz Żarski — Fri, 05 Apr 2019 13:49:56 +0000

I want to present to you the second part of the blog posts series "ES6 for beginners" written by our dev, Bartosz. You can find the previous part here.

We all wrote a lot of functions but let's start with a simple one that adds two arguments.

Of course, everything is correct and compliant with ES5 standards. At the outset, I will also point out that if someone liked a syntax in how the functions in JavaScript were created so far, they do not have to change everything. The ES5 way is as correct as it was but ES6 has some facilities that can make life a bit easier.

Now a code sample on how we would write it following with ES6 standards.

As you can see, two things have changed. First of all, we took out the keyword function, and secondly, we added the Arrow Function ( => ) after the parameters. By some people, it is also called the Fat Arrow Function. This indicates that the arrow is created using an equal sign. An interesting fact is also that there is a so-called thin-arrow in CoffeeScript. It differs in that instead of the equal sign it appears as you probably guess the dash.
We could end here, and I would try to encourage everyone to switch to the new ES6 version. However, if someone wants to know quite an important difference, I encourage you to read a few more lines.

We could try to do it in even more fancy way

Ok, let me use the function I have already shown in the previous series (JavaScript Part 16).

As you can remember (or not) that for our last console.log to return a changed name for the second time, we had to use a trick that looked like this.

Another way would be to use the bind function, which I wrote about in the last part of the previous series. It would look like this.

In both of them, we would get what theoretically we want and theoretically how it should be.

Before I show you how simple and easy it is to get the desired effect (this pointing to the object a function is in) let's modify primary code a bit .

I know, I know that's a lot of consoles.logs, but I find it as the best way to figure out what is happening at a given moment. Let's go. First console.log after invoking a doSomeNameMagic method ( myObject.doSomeNameMagic(); ) on the myObject will log us new value of myName. Since a doSomeNameMagic function is attached to the object (same way as myName), this variable will point to the object it is attached. In our case - myObject.

Inside the doSomeNameMagic function, we are doing a little bit more. The changeName function is created and invoked with an argument - "I changed myName once again !". So since we are invoking it let's check the results of 3 console.logs inside it.

The first thing that catches the eye (first line) is that the value this points to a global object, not a myObject. This is how the so-called standalone functions behave. In our case, it will be a browser window object. Since this indicates the window object where there is no information about the variable myName, it should be obvious that the value we get is undefined. The last console.log, however, simply returns the value of the argument passed to changeName.

The next console.log (in IIFE) will also point to the global object for the same reason as above - standalone function, which is simply the so-called IIFE (first picture below). Since in the changeName of the function there was no information about the variable myName, the change failed and the last console.log will simply return the old value (the second image below).

Although in a moment we will go to Arrow Function, it is worth remembering how this works in javascript before introducing Arrow Functions. Often you will want to use the old syntax (for example Vue.js, but about that maybe next time).

The third and most on-time way is to use just the Arrow Function.

When we decide to solve it using ES6, it is worth knowing how special variable this works. Well, it is quite simple, the Arrow Function does not have its own this value. This value takes on the value of what the Arrow Function is in. So for example, if We wrote a doSomeNameMagic function as an Arrow Function, this would point to ... You guessed - window object. Arrow Functions shine exactly in those moments when anything that requires this to be bound to the context and not the function itself.

In the next post, we will talk about Classes in ES6.

ES6 for beginners - part 1 (Let, Const)

Łukasz Żarski — Thu, 28 Mar 2019 15:43:28 +0000

I want to present to you the first part of the blog posts series "ES6 for beginners" written by our dev, Bartosz. Next parts coming soon!.

Introduction

In the beginning, I would like to congratulate everyone who has read some of my posts about JavaScript!

Of course, there is nothing to prevent you from starting from here, but I think that understanding the previous parts is much more important than reading about the new features in ES6. However, if you would like to start right away from this place, nothing stands in the way

Topics that I will touch are:

let / const
arrow functions
classes
spread operator/rest parameter
destructuring
array helper methods
promises/fetch

Ok, for starters, what ES6 is?

ES6 is basically ECMAScript 6 / ECMAScript 2015. ECMAScript is not any scripting language instead of a standard that Javascript is based upon. So, ES6 is a new version or new standard of JavaScript. ES6 brings many new features like the concept of classes, arrow functions etc. Almost all the modern browsers support ES6 but for the old browsers, there are many transpilers e.g. Babel.js those we need to include at top of our code to transpile ES6 to ES5 (JavaScript with old standards). All of the popular JavaScript libraries and frameworks like Node.js, ReactJS follow ES6.

**We will start with something very simple but also very useful. Let and Const.**

We all know what the var keyword is. We have used it many times. New variable? var, new Function Expression? var etc. ES6 introduces two additional keywords, which are let and const. This does not mean that var will stop working now, but you are very encouraged to use the new ones.

let

Short, It is really a new var. Let is encouraged to be used everywhere instead of the mentioned var. By everywhere I mean anywhere except when we want to use const (explanation is few lines below). Use let for example if you want to create a simple variable.

As you can see in this example, there is no difference. A logical question now would be, if there is no difference, why was it introduced to JavaScript?

Let's follow another example. Here we can see the function which contains two for loops. The only difference is exactly the var and the let. However, if we want to check the values of I and j in the console, outside the block where the code is executed, we will get two different results.

When var i = 0, our i variable will be visible.

However, if we use let j = 0, our j variable will not be visible.

const

The main reason we want to use the const keyword is when we don't want a variable to be re-declared in later code. For example, I strongly recommend using treat const like an old var and change to let when it is needed. Let's see what will happen when we decide to change the variable that we declared using a const keyword.

Error :)

Of course, it is still possible to use methods such as push etc, but as shown above, any "manual" change of the previously declared value will end with an error.

Our array has been modified.

In the next article, we will discuss another topic from the list: Arrow Functions.

Next Post will be published soon!

JavaScript - Bind, Call, Apply

Łukasz Żarski — Thu, 21 Mar 2019 13:13:13 +0000

That's actually a 20 part of blog posts series "JavaScript for beginners" created by our dev Bartosz. All of the parts are available at 2n.pl.

The function is a special type of object and has several properties. We already discussed it in one of the previous parts. To better understand what we are going to deal with today, let's start with an example.

After invoking a function, we will receive:

What's wrong here?
Of course, the fact that in invoking the logName function, the JavaScript engine does not see the getFullName method, which is assigned to the person object. In that case, wouldn't it be nice and pleasant to have such access?

bind

In the example above, we used the bind function.

Thanks to this function, all we did was that we combined Function Expression logName with the person Object, and the whole thing was saved in the logPersonName variable. But how does it really work? Well, the bind function creates a new copy of the logName function. By passing the object, person, we have an influence on what we want our copy to "combine" with. The this variable in the logName Function Expression will refer to the object that we passed. As it is really only a copy, we can invoke it, as we do in the eighteenth line.

As you can see, this is quite useful when you want to access the object in a function outside that object.

call

This function is very similar to the bind.

As you can see, we called the call function on logName and passed the person. The result will be identical but in this case, no copy of the logName function is created, but the logName function itself is invoked. In fact, logName.call is the same as logName(), which is invoking a function. However, using the call function we have a greater ability to influence what we want to achieve, we have an influence on whether this variable is. Of course, we can also pass two arguments to the parameters part1 and part2.

apply

Here we have another function that is similar to the rest. Using it, we also control what the special variable this is supposed to be, but we pass the arguments in an array. Probably now the question comes to mind, what is the actual use of it in real life?

The first case is the so-called function borrowing.

Here you can observe that despite using the getFullName method on the person object, we received "Tom Goe". This is because we have manipulated what the special variable this is. As the return value from the getFullName method is the variable fullName, and in it, we indicate through variable this that firstName and lastName are to refer to the object on which it is called.

The next case is the function currying.

This example is related to bind, because then a copy of the function is created.

It is also not complicated. In the bind function, first of all, we pass to what the special variable this is supposed to refer to. Then we set permanently what will be the first parameter, in our case a. As the result a * b is returned, and a is always equal 2. At the time of the invocation of the function, we give only what b parameter should be equal to.

Of course, if we passed 10 instead of 5, we would get 20. And so on :).