JS Academy #1: Scope 101

Wed, 16 May 2018 00:00:00 +0000

Welcome traveller! The journey to JS-Land begins here. In this episode we will try to make sense of what scope is. You know, the word you hear thrown around here and there, but that you never actually wrapped your head around.

This post is part of a JS Academy series:

Compiled? Me?

Okay, let’s get into it. There is a high probability that you think JavaScript is an interpreted language. WRONG! It’s actually compiled!

The reason we often think it’s interpreted is because its compilation takes place just before execution. So it’s actually very different from the “traditional” compiled languages, such as C, C++, Java or C#, where compilation and running of the code are separate processes and can happen at different times.

I don’t want to get into details as they are not that important for understanding scope, but if you want to dig deeper I found this interesting thread on StackExchange that you can check out.

Why are you telling me this?

The reason I’m mentioning compilation is because scope is involved in this process, which consists of 3 steps:

Tokenizing / lexing: dividing a string of words into meaningful chunks (tokens)
Parsing: transforming a stream of tokens into an Abstract Syntax Tree (AST), which is the grammatical representation of the program’s structure
Code generation: spitting out executable code on the basis of the AST

Let’s say we have the following simple program:

var niceRoundNumber = 64;

In order to be able to run it, a JavaScript “engine” will first compile it, which will result in executable code.

I came here to learn about the scope…

I know, I know! Bear with me, I’m getting there.

So far I mentioned engine, which is the Big Boss that handles the whole execution of our JS program. Next up we have the compiler, which handles all the dirty compiling work. And finally there is the star of the show, the scope.

So what does it do exactly?

Scope has a look-up list of all the declared variables and a set of rules on how they are accessible to the executing code.

Two statements

Let’s analyze what happens with our program step by step. First of all we need to realize that var niceRoundNumber = 64; are, in fact, two distinct statements.

The compiler first looks at var niceRoundNumber and knows it has to determine the location of this variable. It asks scope if variable niceRoundNumber already exists for that scope collection. If yes, then this statement is ignored. Otherwise the compiler declares new variable niceRoundNumber fot that scope collection.

Next the compiler looks at niceRoundNumber = 64 and generates code for this assignment. When engine later executes this code, it will look the variable up in scope and assign the value to it, if found.

LHS / RHS lookup

In fact there are 2 kinds of scope lookups: left-hand side (LHS) and right-hand side (RHS). With a dose of simplification we can say that LHS happens when the variable appears on the left side of an assignment, and RHS when… you guessed it, when it’s on the right side.

In LHS the idea is: we need to find the container of the variable, to assign it a new value. It cares about who is the target of the assignment. Example of LHS: myVar = 2

In RHS we are trying to lookup the value of a variable. We care about who is the source of the assignment. Example of RHS: console.log(myVar)

Nested scopes

The thing about scopes is they can be nested. Just like birds. Well, maybe not, but still… Nested scopes are scopes inside scopes. Like in that movie “Inception”, you know? Okay, enough with the comparisons…

Anyway, what you need to know is that if a value cannot be found in the immediate scope, the engine will continue searching in the outer scope and so on and so forth, until it reaches the global (outermost) scope.

And this brings us to…

Not everyone can handle an undeclared variable

If a variable has not yet been declared, i.e. is not found in any scope, the LHS and RHS lookups behave differently:

RHS - a ReferenceError is thrown:

> console.log(b)
ReferenceError: b is not defined

LHS - if not in strict mode the global scope will create a new variable in that global scope and hand it back to engine:
```
> c = 3
3
```

One caveat is that if we are in “strict mode” (more on that in future articles) a ReferenceError will similarly be thrown in the case of LHS:

> "use strict"; e = 4;
ReferenceError: e is not defined

In the next episode

Thanks for reading and come back next week! We’ll talk about lexical scope ;)

Disclaimer:

This article is based on a series of great books by Kyle Simpson available for free on Github.

I present the same concepts in a simplified manner using my own words with the occassional addition of (un)funny comments.

If you want to dive deeper I encourage you to read the original books.

JS Academy #0: Introduction

Sat, 05 May 2018 00:00:00 +0000

Hi there, folks! I’ve recently decided to dive deeper into the intricacies of how JavaScript actually works. I had been using it for many years, learning “as I went”, without really understanding what was going on under the hood.

This post is part of a JS Academy series:

It worked fine, sure, but sometimes there were strange bugs in my code, this binding was always a “Russian roulette”, magic terms like “closure”, “hoisting”, “callback queue” or “event loop” didn’t ring a bell, and so on and so forth. I mostly managed to copy-paste from StackOverflow and get it working, but the cause of the problem, and usually the nature of the fix, were beyond my understanding.

Ending the misery

Because the influence of JavaScript on the industry keeps on growing, both on the frontend and in the backend, and because of the growing frustration of my mediocre knowledge of the language, I decided to sit down and finally get to the bottom of how JS works.

I was recommended a series of free e-books titled “You Don’t Know JS”, available for free on Github, which are really well-written and informative.

I will release a series of articles that will roughly correspond to the books, where I will be explaining these topics in my own words. Should you, however, find the need to dive deeper, I strongly encourage you to read the original books.

How? When? Where?

I plan on releasing a new post every week on a Sunday.

If you don’t want to miss it, make sure to subscribe to my feed using your favourite RSS reader. (Psst! I use Feedly, by the way)

P.S.

I wrote this post on a Macbook Pro, sipping coffee from an orange mug, just like in the picture. How crazy is that?!

*Photo by Artem Sapegin on Unsplash

IntelliJ IDEA: multiple configurations at once

Mon, 12 Mar 2018 00:00:00 +0000

I’ve just recently come across a problem where I wanted to run 2 configurations in IntelliJ IDEA with a single keystroke.

The matter at hand was that I had a Spring Boot application with a React frontend, created using create-react-app. The Spring Boot was handled by Gradle and React with Webpack and Node.

Both the backend and the frontend were able to reload themselves upon changes in code and I didn’t want to forgo that during development by building the frontend and then serving it from the backend controller. Therefore I wanted to run them independently.

Both were in the same project so I created a configuration in IDEA for each of them. The problem was: I had to manually run each configuration to get the application app and running!

That being extremely inefficient I started searching for a way to run them “together”.

Unfortunately a quick Google search revealed that IDEA does not support such behaviour out-of-the-box. You can define a “Before launch” action, but that would not work here, as neither of the configuration terminates! They both run for as long as you want the application to run.

Fortunately, I found this StackOverflow answer mentioning an IDEA plugin called Multirun.

Sure enough, the plugin works perfectly! You can set the order of configurations and even introduce delays between them.
Now a single Shift + F10 does the trick ;)

Presentation tips for developers

Sat, 04 Nov 2017 00:00:00 +0000

Recently I’ve had the chance to watch many technical presentations as well as give a few of them myself. These experiences have led me to some conclusions regarding giving tech talks and I wanted to share my observations.

I will not discuss the general rules of presenting. Instead, I will focus on aspects that are key to programming or technical presentations.

Keep the terminal up

Very often when several commands have already been executed, the terminal prompt ends up at the bottom of the screen, which makes it difficult for the audience to see. Either you as the presenter are blocking its view, or it simply is too low for people in the farther rows to see.

Therefore make sure to press that “Enter” a few times after each command to push it up. Or simply configure your terminal not to take up the whole height of the screen, but, for example, the upper half only.

Make the code big and visible

The code in your IDE or text editor open with your normal, everyday configuration will likely be too small for the audience. The same applies to the terminal window.

Make sure to increase your font size or even enter a “presentation mode”, which some IDE’s natively have (e.g. IntelliJ IDEA).

You can also ask your audience if the code is big enough to be seen comfortably from the last rows. Make sure you know the shortcut keys for increasing and decreasing font size in your editor to be able to quickly adjust it.

If you present code in slides, just make sure the font is big enough, as it would be inconvenient to change it during the talk.

The color scheme of your editor is also important. If you are in a dark room, a dark color scheme will do, but it will be less readable if there is sunlight coming through windows or when the lights are on. Therefore it is usually safer to go will light color schemes.

Let the code unfold

It is common to simply copy-paste the code from the editor to your slides. However, such a block of code can be difficult for the audience to grasp all at once and can leave them overwhelmed. They will usually either read the code and not follow you, or they will not have understood the code.

I learned that it is much better to show code in small increments and let it “unfold”, as if you were writing it on the go. It is much easier to understand code this way.

You can present it in consequent slides, adding new lines of code to each of them. Alternatively, if you are showing it from an IDE, you can set up git aliases to move between commits (as described here).

Of course the best way is usually to…

Prefer live coding to already prepared code

If you feel confident in your skills I recommend doing a live coding session rather than presenting already prepared code.

This way it is much more engaging for the audience, as they can see the code as it is being created. It is also the easiest for them to follow and understand.

Of course for it to be effective you need to practice a lot beforehand, be able to type quickly and know your editor / IDE well (e.g. shortcuts). It would be very boring to watch you search for some option in the menu with a mouse ;)

To minimize any potential risks (i.e. code is not compiling due to a silly mistake which you are now unable to trace because of the stress of being in front of 200 people… you get my point) make sure to combine this method with setting up git aliaseses and having your code ready just in case. This way if something goes wrong you can just skip to the nearest commit and continue from there.

Prepare and test

If you are showing the code, always make sure it compiles and produces the desired output. Don’t make the changes directly in the slides - always copy and paste from an IDE. It would look very unprofessional if someone spotted a compile-time error in your code during the talk.

If you are doing live coding, prepare yourself well. Write all the code from scratch at least twice, ideally more. Try to hardwire it into your “muscle memory” - there will be a lot of stress during the presentation so being able to code “without thinking” is very helpful.

Make sure to test your prepared commits - does switching between them work as expected? Is their order correct? Does every commit produce a working example?

Do not assume your audience knows what you’re talking about

In every presentation on any topic your audience will certainly contain people who have no knowledge in that field. It is always a good idea to sacrifice a small part of the presentation to present the basics of the topic, even if you are going to talk about advanced concepts.

For example, if I were to speak about advanced features of React, Redux etc., I would always begin with a slide or two about what React is, what are its basic principles and why people use it. It will take 2 minutes but this way you make sure everybody in the room can follow your talk (even if they don’t uderstand everything that comes next).

Conclusions

Tech talks are usually all about the code - so make it a centerpiece! Make it big, let it unfold and seduce your audience :)

And don’t let any pesky errors ruin your talk - so prepare yourself and your code beforehand.

I hope my small tips will help you deliver even more awesome presentations!

Introduction to React - video [PL]

Wed, 23 Aug 2017 00:00:00 +0000

I recently had the pleasure to give an internal talk at my company about React. Unfortunately the talk is in Polish (even though the slides are in English - just in case…) and there are no English subtitles yet.

It was an introduction to the JavaScript UI library created by Facebook, along with a live coding example where me and my coworker we built a “tic-tac-toe” game.

If you are interested in this topic I strongly encourage you to watch the video. All feedback appreciated! :)

Pair programming - to do or not to do?

Thu, 27 Jul 2017 00:00:00 +0000

Pair programming is the activity of two developers cooperating to write code using a single computer. In this post I will share my thoughts about the pros and cons of this approach.

The technique originates from the practices of Extreme Programming (XP) defined by Kent Beck in his book Extreme Programming Explained over 15 years ago.

The rules

Usually one developer assumes the role of “driver” and uses the keyboard to write code, just as in solo programming. The other becomes the “navigator” - observing the process and making sure the driver doesn’t “drift off” and sticks to the gist of the task at hand.

If you’re developers you must know this feeling when you’ve spent an hour implementing a certain solution, only to find out five minutes later that it should have been done completely differently. When we’re in the “flow” state it’s easy to get lost on the technical details forgetting about the business context. The navigator is there to look at the “bigger picture”, making sure the driver doesn’t get lost on particularities of a certain implementation when they shouldn’t be doing it that way at all.

These roles should be changed every now and then - some propose fixed time intervals, i.e. every 10 minutes, others, such as TDD advocates, suggest that switching should happen according to the “red-green-refactor” cycle (e.g. one person writes a failing test and the other one fixes it by writing the appropriate code).

Changing roles is important for staying focused on the task. Our attention span is quite short and a person being “hands-off” as the navigator for too long could lose their focus. On the other hand it is also beneficial for the driver who gets to rest.

The setup

The ideal hardware setup for pair programming is as follows:

a big desk - so that two people can comfortably sit at it,
one computer,
two keyboards and mice - it’s impractical to pass them to each other when switching roles - it’s better to have two sets,
two monitors with mirrored screens - it’s much easier to look right in front of you than to look to the side on a single, common monitor.

Pros

Pair programming brings several improvements to solo programming:

Less time wasted - nowadays there are so many distractions that it’s easy to waste your time at work. All the social media, news sites, notifications from various apps - these are time-eaters. When pair programming, though, you cannot make a pause and check Facebook in the middle of a task, because your partner is right next to you! This gives you a great shield against time-wasters.
Working in a pair is more motivating - you want to ‘impress’ the other person, or at least not look dumb, so you try hard to be sharp and focused.
Constant progress - when one person gets tired, the other one can pick up the pace, allowing them to rest - all while making progress in the task!
Instant code review - you can catch a lot of potential bugs or eliminate mistakes because the code is being constantly reviewed by the navigator. It also reduces the need for back-and-forth code reviews afterwards.
Learning skills - especially if the pair consists of a junior and a senior developer, this is one of the best ways for the junior to learn. They have an experienced programmer at their side, whom they can observe, ask questions and get instant feedback from.
Knowledge sharing - if features are developed in a pair, the knowledge of the system is better “spread out” within the team, meaning it is less likely there will be “silos” of knowledge, where a lot of information is in the hands of one person only (bus factor = 1). It is also a great way to introduce a new team member to the project.
The task gets done better, and sometimes even quicker - because of the lack of time-wasters and constant focus on the task.
Raises team spirit - you get the feeling of ‘we solved it TOGETHER’ :)

Cons

Wow, all this sounds great, but… where’s the catch?
Below are the downsides of pair programming:

Very, very tiring - constant focus and the need to communicate are exhausting, making pair programming suitable only for rather short periods of time. As a rule of thumb I would say 3-4 hours maximum, and not every day.
Requires patience - your colleague may type or think slower, sometimes you may need to explain them something - it puts your patience to a test.
Seems to be a waste of resources (especially to some managers) - but it isn’t! Because of that it might be hard to get acceptance for pair programming from the management - but you can always use the ‘pros’ arguments to convince them ;)
Is less comfortable (depends on the setting) - unless you have a very large desk, two big monitors, two keyboards and two mice - but still you’re using one PC, so eg. holding back with some action while your colleague is working is still a slight discomfort.
Requires communication - some developers prefer to work on their own and are inherently reluctant to cooperate. It might be hard to convince them to ‘open up’.
Requires discipline - it is best done regularly and in a scheduled manner, eg. 1 day a week, 1 day every 2 weeks - otherwise it is easy to ‘skip it’, because of the aforementioned discomforts that it brings.

Overall

Despite the disadvantages I strongly recommend you try pair programming at work. From my experience everybody will benefit: the developers will learn more, the tasks will be done better and usually more quickly, knowledge will get spread out among team members, the code will be of a better quality and your team spirit will go up.

Just remember to practice it with caution: regularly, but not too often and not for too long at a time.

How about you - do you have any opinions on pair programming? Let me know in the comments!

Don't settle in your first job

Sat, 18 Mar 2017 00:00:00 +0000

Today I wanted to share my thoughts and experiences about why it is important not to work in one place for too long, especially at the beginning of your career as a software developer.

I have 3 years of commercial work experience and I currently work for my fourth company (including one internship). Even though I might get pigeonholed as a “job hopper” by some, I will tell you why this worked out well for me.

Below are several advantages of changing your job every now and then:

1. Work with different technologies

It is easy to get stuck working with a particular software stack encountered when joining the company. While it might be advantageous to become an expert in a specific language or framework, it might also set you up for failure if the technology happens to be on its way to extinction.

In my view at the beginning of the career it is good to be able to “touch” different areas: frontend, backend, SQL, maybe even some DevOps etc. It helps you understand how software works on all levels.
Also, it allows you to learn which type of programming you like best and what you can possibly later specialize in.
This way you also get out of your comfort zone by being exposed to new challenges, which makes you grow faster as a programmer.

If you can do all that in your job, it’s fine. But in many companies, especially the big ones, there are very clearly defined roles, i.e. “SQL Developer”

the guy who deals with the database code only. If that is your case I recommend you switch teams or even change jobs to try your hand at other areas of the software stack.

2. Experience diverse company cultures

If you switch jobs you will learn how different organizations operate and what suits you best.

For instance, I worked in a software corporation, in a big public financial institution, at a small software house and at a startup.
I’ve experienced cubicles, open spaces and small team rooms.
I’ve reported to different types of managers, both technical and not.
I’ve seen a formal chain of command of a corporation and a much flatter structure of a small firm.
I’ve felt the difference between working on a software for a customer and developing your own product.
I’ve worked with contractors hired for a specific project and with employees devoted to their company.

In summary, by deliberately “trying out” different types of companies at the beginning of my career, I’ve been able to quickly define what works for me and what doesn’t. As a result I can now spend the rest of my career working in optimal conditions instead of wondering what it would be like someplace else.

3. See different attitudes to software development

I’ve seen different approaches to programming in general: the tools, the practices (code reviews, pair programming, CI) - or their lack, the methodologies (waterfall, scrum, kanban), the languages, the frameworks.

At my first internship we did not use version control, let alone any continuous integration or other fancy stuff.
When I collaborated on a project with a colleague, we would sit down at the end of the day for 10-15 minutes, sometimes even half an hour, and manually merge changes made by one person to the other person’s code. How did we copy the code? Well, with the mighty USB stick, of course!

Can you imagine what kind of software developer I would have been had I stayed there as an employee? I would probably have learned about Git at some point, but when? And what about other good practices that were not used there?

Thanks to the other jobs I had I’ve been able to learn about various good and bad practices and their effects on the teams and the software they produced.
With that experience I am able to help the teams I work in now by convincing them to adopt the good practices and eradicate the bad ones.

4. Get a big raise

When you negotiate with your current employer your raise will usually be determined in terms of a percentage of your current salary. This makes it very hard to make a big “leap” in compensation, say a 50% raise.

However if you apply for a new job, the company knows nothing about your previous salary. Therefore you start with a sort of a “clean sheet” and the numbers depend only on your experience and performance during the recruitment process. At least that’s the way it works in Europe - I know that in the US the potential employer may ask for your previous salary, which makes it similar to negotiating with your current company.
If you can successfully “sell yourself” and navigate the recruitment process correctly, your future salary usually comes down to your negotiation skills.

I know of people who quit company A for company B and then returned to company A several years later earning 100% more, which would have been impossible had they stayed in company A the whole time.
This is not to say that you should hop jobs just for the sake of earning more, but to show you that staying in one company for a long time can usually be financially disadvantageous.

Summary

These are just some of the benefits to switching jobs often at the beginning of your career. Obvoiusly, there are also downsides, such as having to actually search jobs and going to interviews, but in my opinion the merits outweight them.

Also, at the end of the day it does not matter if some recruiters qualify you as a job hopper. There is strong demand for programmers, IT is a candidate’s market and they will be recruiting you anyway. What matters is all the other gains for you as a result of having experience working in several different places.

Do you agree with my arguments? What are your experiences?
Make sure to let me know in the comments.

I created a programming joke that went viral... and found out about it 4 years later

Sat, 28 Jan 2017 00:00:00 +0000

Around 4 years ago I came up with a programming joke.

It was the spring of 2013 and I was at the University, listening to a lecture on Object Oriented Programming in Python when an idea sprung to my mind.
I presented it in the form of a comic strip that was very popular at the time.

It was a quick, spur-of-the-moment Paint job, but I got my message across. Satisfied with the result, I showed it to a friend sitting next to me. He laughed and said it was quite funny.

Encouraged by his approval I decided to share my cartoon with the world by posting it on the only big worldwide image-sharing site I knew at the time - 9GAG.

Within a day or two the joke got over 90 upvotes. I thought “Okay, there are some nerds on 9GAG”. After all the cartoon was extremely narrowly targeted.
I was quite happy about the upvotes and a bit dissapointed that there were no comments, but hey, it’s the XXI century and it’s really hard to break into the entertainment business! After that brief adventure I forgot about it completely.

Fast-forward to 2017.

About a month ago I started using Reddit which quickly became one of my most visited websites. Imagine the surprise when one morning I’m browsing my favourite subreddit, /r/ProgrammerHumor/, and I see this post.

Whoa! My joke is still alive and kickin’! But what surprised me most were some of the comments:

This meant that my joke must have gained some popularity after I originally posted it on 9GAG. A quick Google search later I found at least 3 posts on Reddit with my joke which had hundreds, over 1k and even almost 3k upvotes!

Okay, I was shocked… This is the first time that I had posted anything on the Internet that became so popular. And without me knowing about it for 4 years!

And look at this: somebody even printed the cartoon out and put it on their magnetic board!

But wait, there’s more. I also found a reference to the joke on a blog, with the description:

I’m usually posting these on Twitter, but this one is too good :)

and it got number 9 in an article titled Best Java Jokes on the Internet!

How cool is that? :)

Okay, enough basking in the glory of a small success of my younger self’s sense of humour crossed with some programming knowledge.

The point is: if you have something to say, share it with the world.
You never know who might dig it out and start upvoting.

How we held a company hackathon that was awesome

Sun, 25 Dec 2016 00:00:00 +0000

Recently we organized a company hackathon at my workplace. Being one of the organizers and a participant I wanted to share my experiences.

Our Goals

We had been tinkering with the idea of an internal coding event for quite some time. The main goals that we wanted to achieve were the following:

Have fun
Learn new technologies
Build team spirit and collaboration
Create something durable and useful

1. Have fun

This point is quite obvious. As the hackathon was organized in the employees’ free time, we wanted to make sure that the activity would be fun and rewarding. Nobody wants to sacrifice their personal time to do some tedious and boring coding tasks.

2. Learn new technologies

In our day jobs we tend to work with the same tech over and over - tech which can also be quite dated. Some of us are more fortunate and get to experiment, but most are not that lucky. With the hackathon we wanted to provide the participants with the opportunity to play with the most cutting-edge technologies to sharpen up their skills.

Although it is possible to experiment with new tools on your own, it certainly is more entertaining to do so with others.

3. Build team spirit and collaboration

Given that in our day jobs we tend to work with the same people all the time, we wanted to group participants randomly so they have a chance to work in other configurations. The benefits included learning to cooperate with other people as well as tightening bonds between employees who do not collaborate regularly.

Additionally, contrary to a typical hackathon where teams compete for the best solution, we wanted to enforce collaboration by making each team build a diffrent component of the final solution. Only all the parts working together would guarantee the success of the hackathon’s creation.

4. Create something durable and useful

We wanted to avoid a situation where the projects created during the hackathon would be dumped right after it’s finished. Therefore we decided to build a tool that would benefit us in our daily lives at the company.

We struggled with the topic for a bit, but at some point during a conversation over coffee an idea was born. Our company is situated in a big house and there is one toilet on each of the four floors. It often happens that one has to run up and down the stairs to find a toilet that is available.

As engineers we approached the problem pragmatically: let’s build a tool to monitor the availability of toilets! We would do that by placing a light sensor in each of the toilets (most of them don’t have windows). As ridiculous as it sounds the idea quickly gained traction and suddenly everybody was on board with it.

Execution

We had some fundamental ideas about the hackathon’s organization:

Make it during the day - too many hackathons are held at nights or as 24h events, thus disturbing our natural daily rhythm.
Make it short - we wanted to limit the time to 6 hours to incentivize simple solutions and prevent over-engineering.
Group everybody together - to avoid sitting at our regular desks and feeling like it was just another day at work we hung out in the chillout room instead with everybody sitting in sofas or poufs with laptops in their laps coding in a casual atmosphere.

Below is the diagram of the solution we set out to build:

There were 3 tasks:

Connect a light sensor to a Raspberry Pi, detect light level in a toilet and post the availability status to a server.
Create a server application that will collect data from Raspberries, expose a web gui and a REST endpoint.
Create a Slack bot that will respond with toilet statuses.

I will not get into technical details, but the Raspberry Pi was programmed in Python, the web server app was made with Java 8 in Spring Boot and the Slack bot uses JavaScript running in Node.js.

Moreover, to expose the participants to the cloud, the server app and the bot were deployed in Heroku using an automated build from GitHub.

Conclusion

All in all the hackathon was a great success - we achieved the desired functionality, had lots of fun and gained at least a glimpse into some of the most current technologies on the market. In fact our GitHub repositories are still being committed to even after the event with further upgrades to the components of the system. Even people who did not attend the hackathon are participating!

If you’ve never organized such an event in your company I totally recommend it. It will bring your developers together and help them remember that programming is fun!