DEV Community: Oleg Gromov

How Much is a Year of Your Life?

Oleg Gromov — Mon, 29 Aug 2022 22:44:03 +0000

Hello amazing dev.to community!

A disclaimer: this is an article cross-posted from my website. Posting it here for a broader discussion and, hopefully, some insights for you as well.

Cheers,
Oleg

It must be priceless, right? So thought I, until I realised I've been putting money first for over a decade.

In 2022, a year of my life is $200k. It was about $110k in 2021, $175k in 2020, $90k in 2019.

Here's a brief story of my life 👇

Everything starts with the family

I am from a poor one. When I was young, we had troubles buying clothes, I never had a nice computer to play latest games. We had enough food but god knows what my parents did for that!

I don't blame them. But it's certainly shaped my perception.

I started earning at 14 as a "computer master".

I helped people with hardware and software issues, advertising my services in a local free newspaper.

Not because I loved it but because I wanted to escape poverty.

I did not. But I kept trying.

I started climbing the company ladder

As a web developer, I worked for an outsourcing firm, a game company, finally Yandex.

I don't call it "career" ladder because I wasn't actually pursuing a career. I was pursuing money.

Then Klarna, Toptal, Facebook, Hook, now Sourcegraph.

Each year or two, my income had increased

And it became very natural to expect it to keep growing.

But after 3 years at Yandex, I quit my job. And went to study in the US for 6 months!

Even though I rationalised this decision, it was partly emotional too.

I decided to go to the US to improve my English so that I could continue my career abroad.

That's on the conscious level. But I also felt that something wasn't right.

I didn't necessarily want more of what I already had. I wanted something different.

But I kept chasing money

I had already solved the most pressing problems. I had enough food, a nice flat, a car. I could afford traveling.

But the momentum of the habit was so high that I couldn't stop.

This was 5 years ago. But only this year I realised this was a habit.

A habit that grew in my childhood

When I didn't have enough essentials. I was poor and I was embarassed.

What the habit of chasing money was supposed to solve, had been already solved long ago!

And I began thinking about my life in general. I started looking into the future.

What do I want?
Why?
How?
With whom?

Lots of questions like that. And I don't have most of the answers yet.

But I know for sure that time is more valuable than money once the existential threats are figured out.

It's still valuable, of course, and can buy me lots of freedoms.

But I no longer can go only on money

I want to use my life wisely. Explore, have fun, try things on my own. Have an adventure. Decide what's the next turn.

Having a career and building a business used to seem incompatible to me. But juxtaposing them doesn't make any sense!

There's plenty of happy people that are employed.

There must be even more entrepreneurs who struggle.

And even though I had my first business idea probably around 15 years ago, the shape of what I do just cannot be the answer.

What is the answer then?

Well, I don't know. But I am setting off to find out.

What I definitely know that once you've solved your physiological and safety needs, time becomes infinitely more valuable than money.

This is probably the most personal thing I have ever posted on internet. Thank you for reading! 🤩

And what's your take on the money vs time problem?

How to use bitwise operations to compactly store small values in a single number

Oleg Gromov — Fri, 14 May 2021 12:08:23 +0000

Computer science is full of magic, which is often obscured from our eyes these high-level days. And rightly so: usually to implement features needed by our users we don't need any fancy CS knowledge.

Yet sometimes you may get something from knowing basics of computer science, such as bitwise operations and binary code in general.

I won't go into much detail about how decimal, binary and other numeral systems work. Instead, I'll show you how to compactly store small values needed by our web applications in a single 32-bit unsigned integer.

32 bits as a cap aren't selected randomly. This is the limit for a JS interpeter to perform binary operations.

Why store something in a compact form?

Let's start with a typical single page web application. For instance, a spreadsheet editing app with multiple panels and windows sprinkled all over the screen.

We will also assume our users may benefit from sharing links to the documents they create and restoring exact UI configuration so that it's easier to resume work from the state we left it off at.

So our app has 10 panels, and we need to encode state of these panels (open or closed for simplicity) in URLs they share.

You typically would create a URL similar to this: ?panel1=on&panel2=off&panel3=on and so on. It's easy to see how wordy this becomes even with 10 panels, and what if other parts of our URLs are important too? So we don't want to end up sharing something like this:

What if instead, we could use a single URL parameter, say ?panels=626 to encode all these values at once, in a single number?

This is possible, thanks to the bitwise operations magic, and I'll show you how exactly.

Basics of bitwise operations

If you paste parseInt('1001110010', 2) into a JavaScript interpeter prompt and hit enter, you'll see the decimal number - 626. This is how these 10 bits are encoded into a numeric value in decimal numeral system.

By definition, a bit is a value represented by two possible states - 1 and 0. Exactly what we need to encode a true or false in the most compact form. So we can use these mechanics to store panel states (visible or hidden)!

Let's try doing so by hand.

We will count bits from right to left, first bit having the index of 0 and last having 9. These are, not coincidentally, powers to which you have to raise the binary base 2^n or Math.pow(2, n) to get numbers represented by these bits.

Using exponentiation and binary shifts to store and restore values

So to store the state of panels, we may use the following code:

const panelStates = [
  false,
  true,
  false,
  false,
  true,
  true,
  true,
  false,
  false,
  true,
];

let result = 0;

for (let i = 0; i < panelStates.length; i++) {
  const bit = panelStates[i] ? Math.pow(2, i) : 0;
  result = result | bit;
}

console.log(result);

You may paste the code above into any JS interpreter and see that this code, indeed, prints the expected number 626.

But why? In the loop, we applied the binary OR operation represented in JavaScript by the pipe sign | to the result. As the second operand, we used 2 raised to the power of index, which is, not coincidentally, the number of bit when counting from right to left, starting from zero.

Magic? No, it's binary encoding in all its beauty.

But hey, you should say now, we don't need to only to encode, we need to get our values back too! Let's do so.

const panelStatesEncoded = 626;
const panelStates = [];

for (let i = 0; i < 10; i++) {
  const mask = panelStatesEncoded & Math.pow(2, i);
  const bitValue = mask >> i;
  panelStates.push(Boolean(bitValue));
}

console.log(panelStates);

So the last line of this code will expectedly print an array with the same values we started from.

Why? Well, this code includes a few more binary operations we have to understand. But there is nothing impossible for a computer science magician, isn't it?

First, we start with looping from 0 to 9, inclusive, as we know exactly how many boolean values we're looking for in a number.

The operation we need to perform next is binary masking using a logical AND operator represented by & in JavaScript. So we know that a particular bit in our panelStatesEncoded number represents state of an N-th panel. Therefore, we need to somehow choose it and only it.

This is done by the AND operator: when we do Math.pow(2, 3) for the 3rd panel state, for example, we get 8, which is 1000 in binary code. 1000 & 1011, where the first number is a mask and the second one is our encoded panels state's first 4 bits, we get 1000.

This is because logical AND only leaves the bits that are present in both values on. Had we used 0011 as our second operand, AND would yield 0000, which is simply 0.

But then 1000 we get from the operation is 8, not true or false, or anything else meaningful. So we have to shift it to the right using binary shift operator >> 3 times (our index, the power of 2 that is 8) to get a single bit.

A single bit, a 0 or 1, is easily converted into a boolean value using the Boolean conversion, and we can push it to the array of values.

Our puzzle is now complete. We can toggle right bits by doing Math.pow(2, n) or actually simply doing binary shift to the left 1 << n, which is the exact equivalent of raising 2 to the power of n. Then we can decode, applying a bitmask and shifting it back to the right n times.

Abstracting complexity away

Hopefully at this point you're as much thrilled as I am. Even decades after getting into computers, I am still excited to make them do what I want speaking the same language they do. The almighty binary.

But isn't it too tedious to write by hand and, perhaps, even too error-prone and complicated to be used in production-ready applications?

Indeed, it is! So I created a library to abstract unnecessary complexity away (yet I'd still argue you have to know how it works under the hood). Make some noise for bitwise-options. Yay!

Not only does it allow you name your options and then read them from and write to a single 32-bit integer, it also makes it possible to store multiple unsigned integer values in a single number.

For example:

import BitwiseOptions from 'bitwise-options';

// Configure available options
const options = new BitwiseOptions([
  {name: 'boolean'}, // single-bit boolean by default
  {name: 'uint_single', type: 'uint'}, // single-bit unsigned int
  {name: 'uint_3bit', type: 'uint', size: 3}, // 3-bit unsigned integer in range of [0, 7]
]);

options.read(26); // 11010 in binary

console.log(
  options.get('boolean'), // false
  options.get('uint_single'), // 1
  options.get('uint_3bit'), // 6
);

options.set('uint_3bit', 0);
console.log(
  options.get('uint_3bit'), // 0
);

console.log(
  options.toNumber(), // 2
);

You can find the library on GitHub and npm.

Yes, I was too lazy to implement signed integer support but will be happy to do so if you:

enjoyed reading the article as much as I enjoyed writing it
give the library a star on github so that more people get to know about it
follow me on Twitter, where I write about things worth knowing as a software person if you seek independence and satisfaction

Thank you for you attention and let me know in the comments if you found this useful and why?

The simplest and most detailed CSS flex-box layout tutorial

Oleg Gromov — Wed, 20 Jan 2021 22:45:15 +0000

Hi folks,
Hope you find this small tutorial useful.

I am now working on a web app prototype and need a panel-like full-screen layout for it.

My first intention was to look into React component libraries but that's actually an overkill.

Let's see how to create a simple layout like that with pure CSS and flex-box.

1/ pic.twitter.com/agTGAX1dmr
— Oleg GROMOV (@oleggromov) January 20, 2021

First, let's do basic HTML. We'll keep it as simple as possible and also use semantic HTML5 elements.

Although completely irrelevant when you make a web app and not a content site to be indexed by search engines, it's still good practice to add semantics to your markup.

2/ pic.twitter.com/VsqVxjM6uF
— Oleg GROMOV (@oleggromov) January 20, 2021

Let's go over the need for each element.

Layout is needed to fill viewport vertically.

<header> and <main> designate corresponding layout areas.

<aside> and <section>s all mean columns, although aside gets additional touch of exclusivity.

Ignore contents though 😜

3/
— Oleg GROMOV (@oleggromov) January 20, 2021

With only background styling it looks something like this.

Let's continue with CSS step-by-step.

4/ pic.twitter.com/5OpAsBFYhS
— Oleg GROMOV (@oleggromov) January 20, 2021

We need to stretch our outermost body and html elements to 100% of height initially with the according property . Note that it won't make elements cut content if you go over the height limit.

Also let's set margin: 0 so that we don't have any annoying paddings at the edges.

5/ pic.twitter.com/0VBQSdAhWP
— Oleg GROMOV (@oleggromov) January 20, 2021

Now let's nudge our div.layout into being a good container for the future columns.

For that, we'll make it display: flex, set flex-direction and 100% height.

You see that the annoying green flooded entire screen, meaning that layout has stretched but not the columns yet.

6/ pic.twitter.com/a7FsYYyA1m
— Oleg GROMOV (@oleggromov) January 20, 2021

Remember `panel` classes I set to header, aside, and section-s? This was no mistake. Panel is an important UI concept I want to have in my vocabulary. Let's make all panels have equal padding of 12px.

It's not the best for a11y to use pixels, but we're playing here, right?

7/ pic.twitter.com/cLxjstP2m2
— Oleg GROMOV (@oleggromov) January 20, 2021

Next let's make them stretch. For that, we need to add `flex: 1` rule to .panel. It's a shorthand, check out this tutorial to learn more https://t.co/LaFqABmLlU

Meanwhile, panels stretched to fill the screen but not in the way I wanted. Fixing it next step.

8/ pic.twitter.com/L9dT2YhkIR
— Oleg GROMOV (@oleggromov) January 20, 2021

There's flex-grow and flex-shrink in addition to usual width, min-, and max-width properties to control size of flex-ed boxes.

Using flex-grow (its shorthand flex) and setting .columns { flex: 100 } we make them attempt take 100x more space than another flex child.

9/
— Oleg GROMOV (@oleggromov) January 20, 2021

Another child, <header>, inherited its flex: 1 from .panel that I conveniently set in one of the previous steps.

At this point we have almost entirely working layout without one simple thing: width restriction for the aside.

To have it, let's add max-width: 16em to it.

10/ pic.twitter.com/fovYEft1R7
— Oleg GROMOV (@oleggromov) January 20, 2021

So now we have a layout that:
- fills entire viewport
- accommodates as many columns as needed
- is super simple, pure CSS

You can grab the code and play with it here: https://t.co/O4W1CxuBEO

Was this useful? Let me know in comments. Good luck hacking your CSS! 🤘

11/ pic.twitter.com/dxkrRNDQ1k
— Oleg GROMOV (@oleggromov) January 20, 2021

Refactoring is not Rewriting Code

Oleg Gromov — Tue, 17 Sep 2019 09:10:33 +0000

Hello, folks,

How do you distinguish between refactoring and rewriting code?

Would you usually refactor code because you have to implement a new feature or just because it smells?

What's your justification for spending time on refactorings for those who prioritize, be it your engineering manager or PM?

I have made my short notes about Refactoring vs Rewriting but I would love you to share your experience, too.

Understand What You Want

Oleg Gromov — Wed, 11 Sep 2019 19:14:12 +0000

Hello, the amazing Dev.to community member,

Whether you’re a seasoned software engineer or just an aspiring developer, every time you engage with some project, you make a decision. A decision to dedicate your precious time and attention to something. It may be that you’ve barely thought of this or spent hours joggling those thoughts, as I have.

Anyways, any decision to spend your time on something entails an implicit decision to give up on something else. Opportunity costs, as the economic theory names it.

Either you start contributing to another open-source project, or assume a promotion at work, or anything else like pursuing a degree or dedicating more attention to your health, you implicitly decide to abandon, at least temporarily, something else.

And there’s nothing wrong with the fact.

What may be wrong, though, is if you make decisions like that based not upon your true values, principles, and objectives but upon something that just casually captured your attention.

On memes floating around, similar to “Launch a startup to get free from office routine” or “Pick up a remote work to travel”. On psychology complexes that may originate in your childhood. Or on purely material motivation like getting a raise for performing better at work.

These things, of completely different nature each, together with other stimuli form our behavior and drive our decisions. And ultimately define who we are and how proud we are of what we're doing and have done so far.

For me, having achieved something I’m proud of and being a person I would admire myself, is important. For you, something else may be important.

Despite this possibly huge difference, I truly believe each of us shall be conscious and skeptical enough when it comes to deciding what to do. How to spend our time. How to live the life.

If that subject resonates with you, please take a look at my approach to How to understand what you want, where I cover things listed below.

Introspecting into your past.
Taking small steps from where you are.
Discarding shallow and embracing helpful memes.
Getting inspired by the right examples.
Establishing a healthy examination routine of your values and progress.

In case you find the approach I describe to be controversial, please also share your experience and thoughts. I hope to get a good discussion around this. And thanks for reading up to this point 🤘

Treeker - fake JSX generator 🤖

Oleg Gromov — Mon, 29 Oct 2018 22:42:48 +0000

Hi guys!

Have you ever wanted to generate a fake yet looking like real JSX tree for some testing purposes?

I faced the issue when I decided to work on a server-side renderer that works with React and understood that I need some fake components with either deep nesting or large number of children. Quick look-up on the internet yielded nothing so I decided to create a simple tool on my own.

It's easy to install, that is simply yarn global add treeker or npm i -g treeker, and easy to use. Please check with the readme in oleggromov/treeker repo.

And in case it helps you and/or you like the idea, give me a 👍 here r a ⭐️ on github and share your thoughts here in the comments.

Thanks for your time 🙏

Observing Style Changes 👁

Oleg Gromov — Sat, 24 Feb 2018 16:12:08 +0000

While working on one of my inspirational OSS projects, I found out that there's currently no way to observe element style changes. At least I couldn't find any mentions of library-like solutions for that. I assume that the reason for that might be the fact it's hard to understand whether or not the styles have changed.

So, I decided to write my own library and called it SauronStyle. Please take a look and give it a try if you need anything like that for your project.

How to Observe

Leaving the why? behind the scene, let's jump right to how. There're a few ways to update element styling I could remember:

update its class or style directly
update its parents' attributes, respectively
insert or remove style or link elements anywhere in the document

In order to watch any of those, we need MutationObserver support - a DOM change observing interface supported in modern browsers (IE11+). I suppose that's the same that allows you to watch subtree or attribute modification in Elements pane of your favorite DevTools.

So what does it provide us with? Simply the ability to listen to attribute changes (class and style fall in this category) as well as subtree modifications (external stylesheet insertion on removal lives here).

How to Check for a Difference

When we know something has changed, we should check if there are any actual changes since the changes we noticed might be totally unrelated. To do so, we will use getComputedStyle - a useful method on window supported by any modern browser starting IE9. What it does, is it returns a flat object of all CSS properties with values in a similar to CSS computed tab in Chrome.

Importantly, it returns a live CSSStyleDeclaration instance, which changes over time forcing us to keep a copy of it.

Implementation sneak-peek

The actual source code lives in the repository, being rather compact by the way, but it might be interesting for you to see some details.

First of all, I want to observe the watched element attributes changes. This is achieved easily:

this.mutationObserver = new window.MutationObserver(this.checkDiff)
this.mutationObserver.observe(this.node, {
  attributes: true,
  attributeFilter: ['style', 'class']
})

What this code does, is it creates a new instance of MutationObserver class and sends it a callback, this.checkDiff, as the only argument. Then it says: watch this.node for the changes in style and class attributes only and invoke the callback on these changes.

Later, in this.checkDiff we want to see if the actual styles have changed:

checkDiff () {
  const newStyle = this.getStyle()
  const diff = getDiff(this.style, newStyle)

  if (Object.keys(diff).length) {
    if (this.subscriber) {
      this.subscriber(diff)
    }
    this.style = newStyle
  }
}

The code above gets the current style and compares it against the stored copy. Then, if there's any difference, we store the new one for the future and invoke a subscriber function if it has been set already.

this.getStyle returns a shallow copy of this.computedStyle.

getStyle () {
  return getCopy(this.computedStyle)
}

Where this.computedStyle which is a reference to the mentioned above CSSStyleDeclaration instance:

this.computedStyle = window.getComputedStyle(this.node)

Observing Other Elements

It would be more or less it if we didn't care about other elements like parents' attribute changes or style/link[rel=stylesheet] insertion on removal. To do so, we need another entity, which I called DocumentObserver, to watch document subtree modifications including attribute changes. It looks like this in the class constructor:

this.observer = new window.MutationObserver(mutations => mutations.forEach(this.observe.bind(this)))
this.observer.observe(window.document, {
  attributes: true,
  attributeFilter: ['class'],
  childList: true,
  subtree: true
})

It's quite similar to the other MutationObserver use case but here we treat every mutation separately and watch changes on window.document. Here we say roughly this: observe class attribute modifications and children insertion/removal for window.document and its children. Then call this.observe for any relevant mutation.

Observation code is very simple:

observe (mutation) {
  if (mutation.type === 'childList') {
    this.checkElements(mutation)
  } else if (mutation.type === 'attributes') {
    this.invokeAll()
  }
}

Essentially, it checks the type of the mutation and proceeds to a corresponding branch. It's either call to this.invokeAll, which just invokes all subscribers, or a few additional checks aimed to call this.invokeAll only when a link or a style element is inserted.

This part, the DocumentObserver, is used from within SauronStyle like that:

this.documentObserver = getDocumentObserver()
this.listenerId = this.documentObserver.addListener(this.checkDiff)

First, we use it as a singleton because we only have one document. Second, we subscribe the same this.checkDiff to relevant changes to the document.

Issues

Well, this seems to work decently well but are there any problems?

First of all, the performance is low. We often call getComputedStyle and a call takes a few milliseconds, from 1 to 5-6 on my MacBook '2013. It's slow. Imagine a few thousand elements on a page which you want to observe. Will it take a few seconds to react to a DOM change? Yes, it will.

Second, the algorithm is more of proof-of-concept quality rather than production-ready. We call checkDiff method extensively, for any change in DOM that sometimes won't be related at all to the element we observe. I guess this additional computational complexity can be eliminated by computing and storing element styles outside DOM. But this could lead to more mistakes in difference detection and much bigger comprehension complexity.

I'm also not quite sure that I haven't forgotten any other ways to affect element styles.

How to Help

tell me if you have ever needed anything like that
think and share your thoughts about any other possible ways of detecting style changes
give the library a star on GitHub
actually use it in one of your projects! 👻

Thanks for your attention!

P.S. There's also a cross-posting of this article to my personal blog. Please take a look if you're interested in other development-related articles or just want to get in touch with me.

Declarativity Comes at a Price

Oleg Gromov — Sun, 02 Jul 2017 21:35:16 +0000

There is a widely held notion, and I agree, that declarative code is better than imperative. It is less error-prone, usually much more eloquent and neat and thus much more maintainable. It is a good principle to follow on a day-to-day basis when you use existing declarative libraries like the JavaScript standard library (Array/Object methods etc.), underscore/lodash or React. However, when it comes to making a decision to either write some declarative code (and therefore much more generalized) or just leave an imperative ad hoc solution, I suggest thinking at least twice.

Every algorithm has specific complexity; not only does it have computational complexity (declared by means of time/memory it takes to run on different input sizes), but also a complexity of writing and understanding the code that implements it. The latter primarily falls to programmers who work with the code, and in the world of budgets and deadlines is also a valid point of concern.

What I state in this article’s title, declarativity comes at a price, can be split in a few theses.

Implementation Cost Might Be Higher

Whenever you decide to write something declaratively and have already implemented required primitives, like map or filter for arrays, you might be fine. Someone has already spent time writing and debugging it, and the only thing is left to do is understand how these primitives work and build your own algorithm of these small pieces. What is even better, once you understand how these building blocks work you acquire a rare skill of writing concise code with ease, which must be appreciated by virtually any good programmer in the world.

On the other hand, when a problem you’re solving or a solution you’re picking is not so common and you cannot find needed “blocks”, you might be facing a tough decision of implementing them on your own. Sometimes generalization and abstraction require much more effort you will or can make.

Comprehension and Debugging Price Might Be Higher

Declarative code looks clearer at first glance but this impression is likely to change when it comes to deep comprehension and debugging. Simple things like map or filter are relatively well known and understood, more complex things like React’s component lifecycle are much more sophisticated, and self-implemented and likely not documented and/or tested primitives can be your worst nightmare. You might end up unraveling abstractions your coworker came up with a long time ago or even rewriting them in order to make it work as you expect.

Generalized solutions of abstract problems, which declarative code comprises in essence, are hard. When you generalize an idea and explain it to your friend you might simplify it as well for sake of understanding; when you generalize algorithm, on the other hand, you likely create more and more edge cases because otherwise the code won’t work. It leads to more complications compared to an original smaller issue, more tests to be written and more time to be spent comprehending.

And furthermore, we love eloquence and neatness in our code. A generalized solution might be not so good in the first place and you’ll spend hours to make it look better, whereas the original problem’s solution could have taken only a few minutes.

Conclusion

Don’t get me wrong, I agitate neither against declarative code nor for it. Just be aware of the costs. When you’re lucky to have necessary tools, go ahead and use them. When you encounter a stinky imperative code in your shiny declarative React app, you most likely have a reason to be concerned. Just try to think twice and make a deliberate decision. We won’t get closer to good and working code just echoing dogmas that are being said on every corner. Considering implementation and comprehension and debugging costs, on the other hand, might help to come up with the right decision, whether it is leaving the code as is or paying the price for making it declarative and more generalized.

This article was originally posted in my blog oleggromov.com