Dances with Yaks

yaks Image by Dmitry Sumin

Meet Erik. Very proactive and always ready to help Node.js developer.


Erik got a task to add GeoJSON validation to the REST service they are working on in the project right now. He decided to write his own piece of validation because not a single NPM package covers all the edge cases he needs to cover.


How to become a better over-engineer

React Image by Ant Rozetsky

During your career, you will be often asked to code something that may look like a simple functionality. A simple HTML form or some piece of code that is sending emails. You will feel this urge to hack and ship it ASAP. They just wanted to keep it simple, right?

But deep inside you feel it’s wrong. Don’t you? Sometimes you have to do better and over-engineer a little.


13 things you need to know about React

React Image by Franco Folini

I’ve been using React for over a year now. I’m also conducting training to help people learn it from scratch. I noticed that on every training session I’m explaining the same set of concepts over and over. I think those concepts are essential if you want to “speak React”. If you are in a middle of learning it right know, you might be interested in reading this post.


How to learn JavaScript and leave fatigue behind

React Image by Kevin Harber

Learning JavaScript is a pretty good choice these days. It can do a lot of things for you:

Some friends asked me how to get started with JS. Well, I learned JS not so long ago and I talked with some dev-people about their experience of learning JS. Based on that I will describe what in my opinion seems to be a good approach.


316 days of code - lessons learned

Last year on 25th of December I decided that I will code every day starting from then. The reasoning behind that was “I will learn new things and become a more proficient programmer”. I decided to use GitHub for that because it has a cool contribution overview. I was able to code for 316 days and for me it’s a great result. It was a deliberate decision to stop this experiment after so long and I am going to tell you why.


The superpower of making mistakes

When I was studying at the university there were a few people really interested in getting the scholarship. The money was decent and only ten best students could get it. So people began to compete for it very quickly. In the beginning I wasn’t interested in such things as I was not sure if I would be able to hold up on the semester. I wasn’t good at math so I just focused on studying more than the others. But when I started getting better grades my chances to get the scholarship increased considerably. And the race began.


ESLint - keep your JavaScript on a leash

I am a fan of JavaScript. I love how unopinionated it is. Funny thing is that 2 years ago this was the reason why I’ve been hating it. But I wrote some code since then, I got bored of strongly typed C# (writing custom class for every small DTO - annoying!), fell in love with the simplicity of Node.js and now I see world in different colors.

It’s common knowledge that writing JS can be tricky. Without types, interfaces and proper code hints making mistakes is inevitable. Also JS has its specific pitfalls like global variable scope, messed up this scope, variables shadowing and so on. There are some ways to solve those issues:

  • most obvious one - getting yourself better at JS by reading JS books and articles
  • practicing
  • learning ES6, a new version of JS that fixes some of the biggest JS problems
  • taking help from the JS community

I would like to focus on the last one.


Smuggling good practices

Every devoted software developer has his private super sexy side-project on the private computer where the code is good and where magic unicorns live. We love those projects. We are proud to present them to other people.

Why do we have those projects? Well, I don’t know all of the reasons but:

  • some people are excited about how cool things can be (for me this thing is React)
  • some are tired of their boring projects they need to implement at work (for me - constantly writing CRUD apps in Angular)
  • some just want to have fun because they love to code in their favorite language (for me this thing is JavaScript)

When working on this #notworkrelated code there is less pressure and we have time and energy to focus on writing complicated things the easy way, to communicate through code in the most elegant way, to use design pattern that is the best in this one specific case. We can feel like Neo after loading up the Kung fu program - we know things.

And then we come back to work. Often that is not a place for magic unicorns.


3 monitors won't solve your problems

There is a team in my company where people steal each other’s monitors. Everyone already has 2 monitors, by default. But still, after 2 week holidays you can be sure your monitors won’t be where they used to be.

“Why do they need 3 monitors?”, you may ask. Maybe to feel more comfortable. To have separate monitor just for Spotify or for writing e-mails. Maybe to be more productive. To put unit tests window on the first monitor, test class on the second one, and the thing that is being implemented on the third.

I had an opportunity to work on three monitors. And I lasted in that state for about 4 days. Now, I’m pretty sure that it is one of the best things you can do to lower your productivity and I would never do that again.


Material Design: Part I

Modern CSS frameworks like Bootstrap or Foundation are currently on the crest of a wave. Thanks to CSS language preprocessors like SASS or LESS it is a lot easier to build and maintain this kind of software.

I like using Bootstrap. It was a little bit hard to learn and use it at the beginning but I didn’t give up. Right now my approach to creating websites is simplified. I don’t need to reinvent the wheel and I can focus on delivering products to the client.

But there is something new, something different. It’s called Material Design.


Object calisthenics - Game Of Life Kata

Object calisthenics is a group of rules for software development exercises (like code katas) that - when followed - should boost code readability and overall maintainability.

There are 9 of these rules:

  1. Only One Level Of Indentation Per Method
  2. Don’t Use The ELSE Keyword
  3. Wrap All Primitives And Strings
  4. First Class Collections
  5. One Dot Per Line
  6. Don’t Abbreviate
  7. Keep All Entities Small
  8. No Classes With More Than Two Instance Variables
  9. No Getters/Setters/Properties

Today I was a participant in Game Of Life code kata and the main rule was to use object calisthenics. We worked in 3 groups of 4 people. After implementing the whole thing we switched in groups and reviewed each other code providing comments about mistakes and failures in following calisthenics rules.