bookmark_borderHow to get div height to auto-adjust to background size?

Problem: when we set a background image on div the div size doesn’t adjust to background image size.

Solution:

height: calc(imageRatio * 100vw);

Explanation:

First, we need to get the ratio from the background image. We simply divide one dimension by another. Then we get something like for example 66.4%

When we have image ratio we can simply calculate the height of the div by multiplying the ratio by viewport width: calc(0.664 * 100vw)

A height of a div is automatically updated when the window is resized.

See also: my answer on StackOverflow – https://stackoverflow.com/a/61990449/3775079

bookmark_borderHey Google, could you please add a .gitignore-like option to Google Drive?

Google products are awesome. Gmail, Android, and Google search engine itself. Whoever used Duckduckgo or Baidu knows how awesome Google search engine is… There’s however one thing which drives me crazy: it’s Google Drive.

In particular, the sync engine of Google Drive app. It’s far from perfect, but the worst thing is when you, as a developer, accidentally leave some node_modules inside the synced directory. Then the whole thing literally explodes. As all of the devs know node_modules directory is the heaviest object in the universe…

When Google Drive tries to sync it we can go and grab a coffee. We can grab it from the plant in South America by swimming in a canoe through the ocean, wait until it grows, pick it, bring it to the USA or Europe or wherever we live, wash the beans, burn them, design our custom coffee machine, make a coffee, and then if we’re lucky we can go back to our computer and see the sync finished.

I tried to find a solution. I found this crazy discussion for example https://superuser.com/questions/820145/google-drive-with-a-gitignore-like-option. Poor admins build some custom scripts to make symlinks to the directories which they want to exclude from syncing. Or they remove the directories before running the syncing engine.

Therefore I’d like to pray to Google itself. Please, I beg you, oh mighty – add the exclusion mechanism to the Google Drive sync app so we can exclude the directories, files, anything, just like we can simply do it with .gitignore file. I know you’re busy, I know it might take a long time, but please. It will make the world a bit better place to live. Thanks in advance, Google 🙂

bookmark_borderDevelopers, developers, developers, developers!

You are a dev. You find a job. You get a PC. It’s slow. It lacks the software which allows you to be productive. Half of the internet is blocked. You can’t choose your favorite keyboard or mouse or chair. Sounds familiar?

5S

Japan has a fascinating culture. Esthetics, order, industriousness are its strengths. One of the biggest achievements of modern Japan is its automotive industry. American car manufacturing companies, with the great Detroit and Ford’s assembly line, have been one of the landmarks of USA industrial power. These enterprises had decades of experience, America won the war but despite this in the 80s Japanese took over the automotive industry. Toyota production system became famous and the whole world looked at Japanese organizational techniques to find inspiration.

One of the elements of Japanese culture in this field is 5S. Long story short, it’s the organization of a workplace where:

  • useless tools and items are removed
  • unnecessary move and effort of workers is minimized
  • workplaces are kept tidy and organized

Implementing these principles helps to create a safe and effective workplace. It improves the efficiency of a whole company without putting a strain on workers.

Alcoa

Alcoa is one of the biggest aluminum producers in the world. Charles Duhigg in his famous book, the Power of Habit, described an interesting story about the company. Once upon a time, the new CEO has been nominated. His name was Paul O’Neill. He shocked stakeholders on his inauguration speech because instead of describing his plan to increase effectiveness, profit, and reduce cost, he gave a talk about increasing workplace safety.

 O’Neill managed Alcoa from 1987 to 1999. During that time period, the market capitalization skyrocketed from 3 to 27 billion USD, while net income went up from 200 million to almost 1.5 billion USD.

Was it money saved on industrial accidents?

Obviously not. The money was wasted because of bad organization. Workplaces have been badly organized, they posed risk for workers, reporting the problems was far from perfect and the whole organization suffered. O’Neill has introduced the pressure for improvement of the production process. Workplace safety was metrics of perfection. As we can see from the results – it was a proper one.

The workplace of software engineer

Software development and IT industries obsessed with optimization. New frameworks which allows us to work faster. New processors, more RAM, more storage. Faster algorithms. CPUs generating more FPS. We continuously believe that we can make anything better, quicker, cheaper and more efficient.

A software engineer, when confronted with the job, tries to optimize it. If the tasks are repeatable, a developer will try to automate it. If something takes too long, the engineer will figure out how to do it quicker, using a different approach.

What then can be more annoying and demotivating for a developer than the situation where something slows him down and he can’t get rid of it!

The amount of these obstacles is surprisingly substantial in most corporate workplaces. Let me give you a few examples:

  • our development workstation has too less memory / too slow processor / too small hard drive
  • the internet connection is slow (for example due to proxy)
  • antivirus software dramatically slows down our computer
  • company policy blocks some pages (for example youtube, where we can find a tutorial to solve the technical issue)
  • granting access rights takes ages (for example, to perform some task we need access to system X, but it must be accepted by three managers, which takes three weeks and blocks our)
  • the company does not buy some tools or does it very slowly (for example we need a new testing tool in a week when we start the project, but we can order only during next fiscal year starting next few months)
  • repairing broken hardware takes very long (personally I waited two weeks until my workstation has been fixed)

I remember one manager in a big company wondering how it’s possible that startups are more efficient while they have smaller budgets so theoretically they should have worse engineers. My experience tells me the reason is the corporate inertia, when all the procedures mentioned above slow down everything sometimes to gargantuan extent.

Flow

Except for technical aspects, we need to remember also about the ergonomics of the developer’s workplace. Many companies buy the same chairs, keyboards, desks, monitors, and other gear for all employees. It’s understandable and usually, these things are of good quality. However, there always be some amount of people – some unusually short, others obese, tall or sensitive – who will suffer from these default solutions. They will have headaches, sore eyes, the pain of their wrists. You can be sure they will have a problem doing the most important thing in the work of the developer – to focus.

The software engineer, who doesn’t focus, burns company money. Getting the flow is not as easy as going to the office every day. Talkative colleagues, lots of meetings interrupting our focus during the day, uncomfortable chair – all of this can ruin our flow.

Developer eXperience

User experience became big thing. Every company knows now how important UX is and almost all enterprises producing software have UX experts in their teams.

Analogically we should adopt the idea of developer experience, DX. The lower developer experience in the company and project, the more money will be burned, the staff turnover will be greater and the team’s output will be minuscule. On the other hand – awesome developer experience will bring us great experts at a lower price, will give us a productivity boost and we will not need to constantly recruit new team members because old ones decided to quit.

Last but not least, let’s remember – Microsoft always cared about developers 🙂

bookmark_borderHow to update feature branch from master in Git

If you want to update your git feature branch with the new changes from the master branch, you need to:

  1. Update master branch
  2. Merge or rebase the new changes

TL;DR: merging creates additional commit, rebasing rewrites history. Usually the team chooses the way to handle conflicts in repository so ask your colleagues first what your team approach is.

To merge

git checkout master
git pull
git checkout target_feature_branch
git merge master

To rebase

git pull --rebase origin target_feature_branch 
fix conflict and then → git add . 
git rebase --continue 
git push -f

bookmark_borderWhat is hoisting in JavaScript?

What is hoisting is one of the standard JavaScript recruitment questions. For some devs it’s one of the quirks of JavaScript, for others it allows understanding the language deeper. Let’s take a look at the example:

console.log(foo);  //returns undefined not ReferenceError exception 
var foo; 

Console.log will not throw the exception. It will print undefined.

Why?

In most of the programming languages, we should have some ‘variable undeclared’ exception. In JavaScript, when the code is executed, the declarations of the variables (declared using var keyword, but not let!) and functions are hoisted, moved to the top (of the scope).

Important thing to notice is that initializations are not hoisted.

console.log(foo);  //returns undefined  
var foo = “bar”; 

But why do we need it?

Well, if we need it or not is a good question, but let’s take a look at the example of how hoisting can be useful. As I said before – declarations of functions are also moved up. Therefore we can use the function before it’s declared:

sayHello("Mark");

function sayHello(name) {
  console.log("Hello " + name);
}

To read more about the hoisting see: https://developer.mozilla.org/en-US/docs/Glossary/Hoisting

bookmark_borderWhat does question mark and dot operator ?. mean in C# 6.0?

C# 6.0 introduced new operator – null conditional operator ?.

The way it works is very simple. It checks if the left part of the expression is null and if it’s not it returns the right part. Otherwise, it returns null.

Simple example:

var thisWillBeNulll = someObject.NullProperty?.NestedProperty;
var thisWilllBeNestedProperty = someObject.NotNullProperty?.NestedProperty;

Executable example:

//Rextester.Program.Main is the entry point for your code. Don't change it.
//Compiler version 4.0.30319.17929 for Microsoft (R) .NET Framework 4.5

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text.RegularExpressions;

namespace Rextester
{
    public class Person
    {
        public string Name { get; set; }
    }
	
    public class Dog 
    {
        public Person Owner { get; set; }
    } 
    
    public class Program
    {
        public static void Main(string[] args)
        {
            Dog dog = new Dog();
            Console.WriteLine(dog.Owner?.Name == null);
            // this will print True
            dog.Owner = new Person() { Name = "Fred" };
            Console.WriteLine(dog.Owner?.Name); 
            // this will print Fred
        }
    }
}

The above example can be executed here: https://rextester.com/TBC19437

Documentation: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators–and-

bookmark_borderDaily at 9 AM

A software house is not a convenient store. The work can start pretty much at any time. What’s important is that people who perform the tasks together can communicate, meet, and share their thoughts. This flexibility is important because the chronotype is said to be like a human height – you can’t change it without breaking a bone.

What is chronotype?

Chronotype is being a night owl or the morning bird – it’s the preference of the organism to wake up early or stay late. Apparently, in traditionally living tribes it breaks down so that about 25% of the population likes nightlife, 25% morning, and the rest something in between. This would serve the survival of the group because at every moment of the night and day there is someone who watches.

So we have Mark, who gets up at 5 AM and Bill, who falls asleep at 1 AM. Theoretically, they both have flexible working hours and must meet from time to time on a call.

Then scrum master sets up the daily scrum meeting at 9 AM.

Mark is cool, he comes at 7 AM, he will eat breakfast, he will poop, he will browse cat pictures on the Internet and he is ready and fresh for confession from yesterday’s tasks.

Bill, on the other hand, gets up sleepy every business day, because he would like to come at 12 and cannot sleep earlier. Frustration grows, and IQ decreases. He sleeps well only on weekends and holidays. Every morning he’s in a hurry, sleepy at this damn daily and the whole day too. In addition, the team looks at him crookedly. Lazy, late, sleepy, cursed black sheep!

Meanwhile, research suggests that the night owls are more intelligent, not lazy: https://www.psychologytoday.com/us/blog/the-scientific-fundamentalist/201005/why-night-owls-are-more-intelligent-morning -larks

This seemingly unimportant organizational habit – organizing daily at 9 AM – drives the significant part of the team inefficient. How much of it depends on luck, but statistically around a quarter. There’s no reason why daily meetings can’t be scheduled at the end of the day or in the middle of it. It is simply a habit, a ritual that has spread and is mimicked in a reckless way.

To sum up: when organizing a scrum team, it is worth paying attention to the preferences of its members regarding the hours in which the meetings are to take place. This also applies to meetings at around lunchtime, when some people may simply die of hunger because of discussions lasting several hours.

Early daily scrum meetings can reduce the performance of the team as long as any night owls are the members. It is worth remembering.

bookmark_borderSenior developers’ greenfield

You have a million dollars to spend and an idea for a product. What would you do?

You would recruit the best people and believe that their experience will make the team effective in creating high-quality software, right?

But…

You come after three months and you see that:

  • the first month passed on discussions about branching strategy, test architecture, deployment, application, cloud selection, CI / CD technology stack and the application itself, choice of linter and code formatting standard and several other similar topics
  • one and a half months it took to implement the infrastructure in the cloud, automatic deployments, application architecture and refinement of tasks
  • in the last two weeks, the team have delivered the header and footer as well as user login and registration

You feel hypertension pressing against the walls of your arteries, your kidneys are itching from adrenaline production, and tooth enamel creaks from nervous tension. However, you also learn that:

  • Max is going to quit because he disagrees with Peter regarding the chosen infrastructure of the application
  • Anne has hardly spoken for two weeks and nobody knows what she is doing, but apparently she is configuring the cloud
  • Half of the code was written by Xi
  • Matt is hated because he does not accept pull requests
  • Mark wants to be a team leader even though you have agreed that there will be no team leader

You return home, open 18-year-old Glenfiddich and with each sip, you become more and more convinced that IT is a swamp.

What went wrong?

Of course, the described situation is exaggerated, but there is a lot of truth in it. There are two problems – greenfield and seniority.

Greenfield is a new, fresh, pristine project – one that is built from scratch, where devs have the freedom to choose technology, practices, architecture, practically everything. This is the dream of many programmers locked in the cages of maintenance of legacy systems.

High seniority is good, valuable, almost priceless, but in everything you need balance, and good is never pure – there is always a flaw in it. The flaw of the senior developer is his ego. Many experienced programmers are convinced that they have seen so much that they think they are always right. The truth is, however, that everyone is sometimes wrong, and that many opinions in IT do not matter – or they do, but the profit is less than the cost of not making a decision.

Gathering many seniors in a greenfield project is a risky venture. The ability to choose technology and architecture inevitably creates a discussion in the first phase of the project. The more seniors, the more frenetic this discussion will be. Juniors or mids will rather adapt – seniors will usually stubbornly defend their opinions. This is understandable, of course, but it is disastrous for this type of project.

A ‘self-organizing team’ is an additional source of the problem. When there is no official leader, there is a fight for power. When there are no obedient sheep, because we selected only old stagers – we have a problem.

Seniors devs’ greenfield is a synonym for failure. During the selection of the team members for the greenfield project, let’s not be tempted to choose only experienced professionals. The selection of an official leader is also a good idea – this will speed up the building of the hierarchical structure, reduce the struggle for power and give clearly defined responsibilities to team members.

bookmark_borderThe naming problem in programming

Reading source code is more difficult than writing it. Inherently. Everybody who worked with a legacy system and needed to understand the authors’ intent knows what I mean. Browsing through thousands of lines of function definitions, variables and figuring out what’s the point is a daunting task.

But why, actually?

Is reading a recipe difficult?

Is it more difficult than writing it?

Is reading a hundred years old recipe more difficult than understanding thirty days old recipe?

I don’t think so.

Why then reading source code gets more difficult as the code matures? What can be the reason for software decay and common hatred towards legacy systems?

Let us think of the action of reading source code. What do we do when we try to understand the flow of the computer program?

We are a bit like computers, but less effective. We go through the code and read the variables and functions. Because we are not as fast as machines we can’t remember the value of each variable and we are unable to memorize the body of each function or subroutine. Our “understanding” is based on approximation. We read the name of the variable and try to guess its usage, its meaning. We read the name of a function and without reading its body we try to figure out what the function can do.

It’s exactly the same as in the real world. When we read about “a carrot” in the recipe we imagine a carrot. We can understand the concept of carrot without receiving a lengthy list of details about the carrot, such as its genetic code, mass, temperature, color and so on.

But source code – even with the entire effort of object-oriented paradigm – is not like the real world.

In the real world we have a huge, but a limited amount of words in our vocabularies. Natural language is processed by human brains in a completely different manner than source code by the compiler. For example “a chair” to a human being is not a particular chair but an idea of a chair. In most cases, we don’t need detailed definitions to process natural language. On the contrary – in rare cases like the law we have big problems with the definitions.

A very good example illustrating what would happen to the natural language if we process it as literally as computers process the source code is this video:

Let’s go back to the process of reading source code by software engineers. We take the name (of function or variable) and guess. As long as the code is “clean” and not old enough to match our instinctive understanding of the definition our guess is somehow correct. In this situation, the process of reading is smooth and painless.

The issues pop up when we can’t guess properly.

But the real issue is far greater. It’s one of the fundamental problems of software development. Partly it’s described by a quote by Phil Karlton

There are only two hard things in Computer Science: cache invalidation and naming things

Phil Karlton

I mean naming things.

Naming things is the point of incompatibility between the world of humans and computers. In the real world, where the language is processed by human minds, which are able to process ideas, classes of objects we rarely invent new words. In the realm of a computer program, we constantly do it.

What happens when we invent a new word in a natural language? We learn it. There comes the new word “computer” and all the people learn that it’s a kind of computing machine. But it doesn’t matter if’s MacBook Pro or new Dell XPS or ENIAC or PC. We don’t have a new word describing computers slightly differently in every company or even the company’s department.

But in the software world, we do. “User” means something different in every single program written so far. In one it’s just user name and surname. In other, it’s also the date of birth. In other, it’s only sex and nickname.

We simply can’t name anything properly in a computer program. Every construct within code does not match the real-world meaning of the world.

We can be too vague – let’s say naming the user “user”, or too precise “userWithNameAndSurnameAndSexAndDateOfBirth”. Almost never we will be able to fully express the object by its name. That’s why reading source code is so difficult. The words, the names of variables and functions never mean what we believe they mean. We always need to go to definition and check. Every time we check we learn the new language of a particular software project. Learning thousands of new words is difficult. Therefore reading source code is difficult…