DEV Community: Ondrej Sevcik

My Use Cases for Advanced Github Search

Ondrej Sevcik — Thu, 22 Feb 2024 19:05:57 +0000

I’ve been overseeing many different repositories at Lokalise and that means also knowing and keeping track of what libraries are in use and in what version.

I always knew that GitHub has a search functionality, but until recently, I didn’t realize that I can use it exactly for this purpose.

Here are a few use cases, I use GitHub Search for lately.

Find out what versions of package X do we use in different repositories

In my case, the package X is React. I was trying to find out what React versions we still use. This search command gave me the answer.

org:lokalise path:**/package.json react-dom NOT is:archived

Find out how many files with extension X do we have

Github Search returns also the amount of files that match the search. With that, you can also easily find out how many files of certain type you have in your organization.

In my case, I was looking for how many React components we have.

A small problem is that once you get over 1000s, it will give you just an approximate number, but in my case, that was still good enough.

org:lokalise path:**/*.tsx NOT is:archived

Find out how many files use styled-components

We’re in a process of migrating from styled-components to native CSS (which is more web friendly). With this search, I can track easily how the migration is going.

org:lokalise "from 'styled-components'" NOT is:archived

Using Performance API to Measure Front-End Interaction Times

Ondrej Sevcik — Wed, 07 Jun 2023 18:01:02 +0000

TL;DR

Performance API is a great (native) way to measure how long certain Front-End interactions take.
Its Observable API allows for easy plug-in of existing monitoring tools.
It’s only a few lines of code and you’re good to ship.

To measure the performance of your app’s functionality, you will need to add Markers and Measures into your code.

Ideally, you add those into critical parts of your application where you want to ensure that they stay performant over time.

What is a Mark and Measure?

Working with Performance API, you will see Mark and Measure mentioned a lot. Understanding the difference between those two is essential.

Mark is an object that represents an event on a timeline. It’s created using performance.mark() call.
The measure is a measurement between two of those marks. It’s created using performance.measure() call.

Basic use case

Let's measure how long it takes to show the next image after clicking the button.

For that, we will have to add two markers - one for button clicked and one for image loaded. With marks in place, we can then measure the time between them.

(Full example in Codesandbox).

button.addEventListener('click', () => {
  performance.mark("button-clicked") // <-- mark button click

  let response = await fetch('...').then(r => r.json())
  let imgEl = document.querySelector('#img')

  imgEl.addEventListener("load", () => {
    performance.mark("image-loaded") // <-- mark image loaded

    let measure = performance.measure(
      "load-next-image-duration", // measure name
      "button-clicked", // start mark
      "image-loaded" // end mark
    )

    console.log(`${measure.name}'s duration: ${measure.duration}`)
  }, {once: true})

  imgEl.src = response.url
});

The benefit of using the native API is that it also shows up your markers and measures in DevTools.

Sending measures to external monitoring tools

One last step is to actually log those performance measures into external systems, where you can then analyze your performance trends over time.

The Measure object has name and duration properties that are ideal candidates to be sent.

With PerformanceObserver API, it’s just a few lines of code.

function perfObserver(list, observer) {
  list.getEntries().forEach(entry => {
    // replace with monitoring tool of your choice
    newrelic.addPageAction(entry.name, { duration: entry.duration })
  })
}

const observer = new PerformanceObserver(perfObserver)
observer.observe({ entryTypes: ["measure"] })

And that’s it. I hope this short introduction helped you to understand how easy it is to use Performance API to monitor your app.

For advanced use cases, visit the MDN docs for Performance API.

How to Increase CSS Class Selector Specificity to Beat the ID Selector Without Using Important

Ondrej Sevcik — Thu, 27 Apr 2023 14:53:13 +0000

Recently, while working on some legacy code, I had to figure out how to overwrite ID selector styles without using !important.

The CSS was similar to this

<div id="parent">
  <div class="child">Content</div>
</div>

<style>
  /* specificity 100 + 10 = 110 */
  #parent .child {
    color: red;
  }

  /* specificity 10 */
  .child {
    color: yellow;
  }
</style>

This results in a text with red color, but in my case, I needed to make the text yellow.

Normally, I would just refactor the CSS and HTML, but in this case, I couldn’t change the HTML and order of CSS due to some legacy code.

The easy solution would be to use an infamous !important keyword to overwrite everything, but I didn’t want to go that way.

Using attribute selector

The better way is to change the ID selector to the attribute selector. Instead of #parent it's possible to use [id="parent"]. This has the same specificity as a class selector.

Now instead of specificity 110, it is down to 20.

/* specificity 10 + 10 = 20 */
[id="parent"] .child {
  color: red;
}

/* specificity 10 */
.child {
  color: yellow;
}

Chaining the selector with itself

Now I had to increase the .child specificity above 20 to beat the [id="parent" .child" selector. One way to achieve that is to chain the class selector with itself.

The specificity of .child is 10. The specificity of .child.child.child is 30.

<div id="parent">
  <div class="child">Content</div>
</div>

<style>
  /* specificity 10 + 10 = 20 */
  [id="parent"] .child {
    color: red;
  }

  /* specificity 10 + 10 + 10 = 30 */
  .child.child.child {
    color: yellow;
  }
</style>

This is an easy way to bump up specificity without adding additional classes or knowing about the context where the item will be placed.

I find this better than using !important, but it is still a hack. If possible, try to avoid this.

The Reason Why I Don’t Use Gmail as My Primary Email Anymore

Ondrej Sevcik — Thu, 02 Mar 2023 07:18:20 +0000

It’s been 2 years since I realized that my whole online presence is built around Google.

It’s very convenient to build your whole life around Google Services - Gmail, Drive, Contacts, Photos, YouTube, save Passwords to Chrome, Login with Google, … the list goes on and on. Google services are free, easy to use, and they all work well together.

Your account has been suspended

The problem is that each service on Google has its own Terms & Conditions, and it’s not that uncommon to get your account suspended because you “breached something somewhere”.

Once you get suspended, you basically stop existing online, and you lose access to all your data. Everything. Gone. Immediately. And Google has no obligation to talk to you. After all, it’s free.

Centralizing all our online being into the hands of a single giant is not the best idea.

I did not like the idea of that. Not having an access to my email and my passwords could be existential.

There are many stories out there where people got locked out.

Portability is freedom

My email is now on my own domain, hosted at Fastmail. I’m using 1Passwords for logins and passkeys. I use Firefox for bookmark sync. And I never use social logins.

I pay for all of these services. It costs me around 12$ a month and it’s totally worth it. I feel good about supporting more independent internet, plus paying for service has so many other benefits (like a support that actually talks to you, better privacy, loads faster, and so on).

The point is not to avoid Google at all costs, but to minimize the impact of being suspended. If I would simply switch to Apple or Microsoft, it would be the same problem. The internet is meant to be decentralized.

I still use YouTube and Google Maps. But they are just yet another service I use. If I would get suspended, it would not be a big deal anymore.

If you’re in the same position as I was 2 years ago, now is the best time to reconsider your online being.

Improving the performance of styled components with native CSS features

Ondrej Sevcik — Sat, 28 Jan 2023 07:44:13 +0000

Styled components are slow. But can we improve its performance by using some of the native CSS features? I've decided to test it out.

The problem

The problem with styled components is that they recalculate styles based on runtime values. Every time the component is rendered, it needs to build up the stylesheet and insert it into the document. This is not an issue in small apps, but in larger applications, it affects performance.

What you want to avoid is dynamic components (a component that depends on theme or props).

Before a dynamic component is inserted into DOM, it needs to parse the template → generate CSS → preprocess styles → inject it into DOM. Static components on the other hand can skip some of these steps and are thus much faster.

Exploring alternatives

Given that, I’ve started exploring how could we rewrite dynamic components into static ones.

Here is a classic example of a dynamic styled component.

const Box = styled.div`
  padding: ${props => props.padding};
`

<Box padding="1rem">I'm a box</Box>

This could be easily rewritten as a static component with a help of CSS Variables.

const Box = styled.div`
  font-size: var(--padding);
`

<Box style={{--padding: '1rem'}}>I'm a box</Box>

But usually, in larger apps, we don’t use specific values directly, but rather design tokens from the design system.

Here’s a similar example, but this time with padding with three options.

const Box = styled.div<{padding: 'small' | 'medium' | 'large'}>`
  padding: ${props => {
      switch (props.color) {
        case "small":
          return "1rem";
        case "medium":
          return "2rem";
        case "large":
          return "3rem";
      }
    }};
`

<Box padding="medium">I'm a box</Box>

In this case, we can’t really use CSS variables. But we could use data attributes instead.

const Box = styled.div<{'data-padding': 'small' | 'medium' | 'large'}>`
  &[data-padding="small"] {
    padding: 1rem;
  }
  &[data-padding="medium"] {
    padding: 2rem;
  }
  &[data-padding="large"] {
    padding: 3rem;
  }
`

<Box data-padding="medium">I'm a box</Box>

This doesn’t look bad, and is much easier to read.

The only disadvantage of this approach is that it’s actually rendering the data-padding attribute into the DOM. Writing to DOM might affect the performance as well.

Performance

I’ve decided to test it out.

In this simple demo, I build a table with 1000 items in it using 3 different approaches. The first one is using dynamically styled-components, the second is using statically styled-components and the third one is using plain old CSS class names.

It turns out that using data-attributes is indeed a little bit faster than using dynamic props on styled-components. Not surprisingly the fastest was using CSS class names.

Using native CSS features can indeed improve the performance of styled-components. It makes the styles also more readable. Rather than writing CSS inside JS function inside CSS declaration inside JS file, you can just write CSS that everybody understands.

But using CSS in JS is still controversial. It improves DX while hurting the user experience.

As long as CSS in JS doesn't improve UX & DX at the same time, it's better to stick with plain old CSS and a some good CSS methodology.

How to detect AdBlock in plain JavaScript with a few lines of code

Ondrej Sevcik — Sat, 10 Sep 2022 08:04:15 +0000

Using analytics tools to measure the impact of your application is part of every website these days.

But measuring how many of your users block your analytics is probably even more important.

And luckily, it’s not that difficult to figure it out.

How it works

In a nutshell - you need to add a fake advertisement div to your website and check if it is visible or not.

In practice:

Add an empty div that’s positioned in the top right corner of your website. That way, it won’t bother users who don’t use AdBlock.
Preferably also add aria-hidden="true" to not show this fake ad to users who use accessibility tools.
Once the page is loaded, check whether this fake advertisement div is visible or not.

<div class="ad-box" style="position:fixed;top:0;left:0;" aria-hidden="true">
  &nbsp;
</div>
<script>
  setTimeout(function () {
    var adBoxEl = document.querySelector(".ad-box")
    var hasAdBlock = window.getComputedStyle(adBoxEl)?.display === "none"
    // ... save to DB
  }, 2000)
</script>

The way most AdBlocks work these days is that they target specific CSS classes (like class="ad-box") and apply display: none on it. That way, the Ad disappears in your browser.

Always double-check that you don’t break the experience for users that do not use AdBlock.

You can see all the CSS classes that are used for blocking in EasyList blocklist.

20 principles I learned from 10 years of developing software

Ondrej Sevcik — Thu, 25 Aug 2022 17:38:25 +0000

It's been 10 years since I started my first job in the software industry. Here are 20 principles that I have learned and try to follow in my day-to-day life.

Be humble - No engineer in the world knows everything, the same applies to you.
Make it work, make it right (and sometimes make it fast).
Optimize for change - Prefer duplication over the wrong abstraction.
Always write tests - If you're not writing tests, you're testing manually.
Solve 80% of use cases - You never gonna solve everyone’s problem.
Prefer functional programming - It's easier to understand. If your code requires a Ph.D. to understand, you’re most likely doing it wrong.
Delete as much code as you can
Good Enough is Better than Perfect - Don't discard meaningful improvement just because it's not perfect.
Criticize in private, praise in public
Make notes - If you think you will remember it, you're lying to yourself.
Talk to your users - The best software is built by engineers who have empathy for their users.
Learn with intention - Practice with a clear and specific goal in mind - what you want to improve and exactly how (deliberate practice).
Do not generalize early - Wait until you have at least 3 duplicates of code before you make an abstraction (aka. Rule Of Three).
Fix broken windows - One hack in code leads to another hack. Soon your code will become unmanageable.
Fix the problem - doesn't matter whose fault it is, it is your problem.
Do what works, not what's fashionable - Try it first with a small team. If it works, expand. If not, abort.
The best work requires a good rest - Regular time off is essential for top performance. You also don’t expect professional sprinters to sprint all the time.
Take small steps - Big rewrites don't work. You will lose motivation and focus along the way. Aim to release daily. It gives you the freedom to change focus when necessary.
Praise for good work - Something we've observed in animals, but works for people too. You will get better results when you praise people for good work rather than punishing them for a bad one.
Perfect code doesn't exist - It's better to accept this as a fact rather than wasting time and chasing the impossible.

6 rules I follow to get simple and stable tests

Ondrej Sevcik — Fri, 05 Aug 2022 14:19:00 +0000

It took me several years of trying and failing to figure out what does work when I write tests. Here are 6 rules that I always follow no matter what kind of tests I write.

Follow AAA pattern

Clean unit tests follow the AAA pattern:

Arrange: Setup the test scenario
Act: Execute the business logic
Assert: Make some expectations

This is the holy grail of simple tests.

Single concept per test

Test single concept in each unit test. If you follow the AAA pattern, this should feel natural.

Oftentimes, I see tests that cover a lot of different concepts in a single unit test. That’s a code smell. It’s better to split up such a test into multiple tests - each testing its own thing.

Rule of thumb - if there is an act after your assert, you should consider to splitting it out into two separate tests.

Your tests will be easier to understand, and easier to fix.

// Bad - mixing two concepts
it('should add new item into cart', () => {
  let cart = new Cart()
  cart.add(new Item('Shoes')) // <-- // Testing adding item into cart
  expect(cart.size).toBe(1);
  cart.removeAllItems(); // <-- Testing removing all items from cart
  expect(cart.size).toBe(0);
});

// Better - split it up
it('should add new item into cart', () => {
  let cart = new Cart();
  cart.add(new Item('Shoes');
  expect(cart.size).toBe(1);
});

it('should be possible to remove all items from cart', () => {
  let cart = new Cart([new Item()]);
  cart.removeAllItems();
  expect(cart.size).toBe(0);
});

Avoid logic in your tests

Avoid any if, else, switch, or ternary operator in your test code.

The moment you use any of the control flow statements - you added logic to your test and now you need a test for your test.

This often happens with a parametrized test where you expect slightly different behavior for different inputs, but also with tests where someone wanted to avoid failure for a flaky test.

In cases like these, it’s always better to split it up and keep it flat and simple.

// Bad
it("should have focus when clicked", () => {
  render(<Input />)
  const input = screen.getByRole("input")

  // this null check is pointless
  if (input !== null) {
    click(input)
    expect(input).toHaveFocus()
  }
})

// Better
it("should have focus when clicked", () => {
  render(<Input />)
  click(screen.getByRole("input"))
  expect(screen.getByRole("input")).toHaveFocus()
})

Optimize for simplicity

Good test is short, flat, simple, and delightful to work with. When you look at a test, you should get the intent immediately.

Do not nest tests. It adds unnecessary complexity. Each nesting level adds an extra cognitive complexity to your code.

Refactor common setup code into a fixture to avoid repetition.

Only public API

If your test is doing something that your user can’t, it's most likely testing implementation details.

This is a code smell. Any change in the underlying implementation will break your test.

Test only API that your user can use.

Use TDD to drive your coverage

10/10 times when I use TDD, my code coverage climbs over 80%.

Start with the happy path - make sure that code works for your primary use cases.

Continue with unhappy paths - Cover the error conditions, unexpected input, or any other edge cases.

You can skip testing trivial one-liners, getters, and setters.

With this, you should hit the 80% coverage mark easily.

Don’t obsess about code coverage - it only tells you what lines were executed, not if they work as intended. Focus more on writing meaningful tests.

That’s it

With these few rules, you can write tests that everybody will understand and it will be a pleasure to work with.

Let me know if you have some other rules that you follow, and why.

Writing tests after release is a mistake

Ondrej Sevcik — Wed, 27 Apr 2022 16:02:09 +0000

Writing tests in 2022 is more common than ever before, but more often than not, I see developers writing tests after the code is released to production. And that’s a big mistake.

What is wrong with that?

It seems obvious - writing tests takes time, so I will be faster if I don’t spend my time writing them before the code is released, right? Wrong!

Writing code is just one part of producing features, and developers often ignore all the other areas that get affected. You end up with almost all the same problems like not testing at all.

When you write tests after the release, you end up

Testing your code manually - You don’t ship untested code, do you? You either write automatic tests, or you test your code manually. Manual testing is the slowest. The bigger the change, the more time you spend on manual testing. It simply does not scale well.

Producing worse Architecture - TDD helps you organize your thoughts about the behavior and API design. Bad API accumulates and makes you even slower in the future.

Producing more bugs - Manual testing means you test less often. Bad architecture means the code is more complex than it should be. Combine those two, and you end up with more bugs in production code.

Longer code reviews - No tests, bad architecture, and more bugs will lead to more and longer discussions about the code itself. Check your Pull Requests for how many comments and changes are usually required before you get approval.

Producing code that's harder to test - Code that is not written with testing in mind is always more difficult to test. You will write more brittle tests or have to rewrite your code to make it testable. And that is, again, time-consuming.

Not testing all the edge cases - You wrote the code several weeks ago, so it's natural that you forget all the edge cases that should be tested. This will haunt you in the future in the form of bugs.

(Sometimes) Skipping the tests - Since the code is in production and is working, your manager wants you to work on the next feature, naturally. And so the tests never get written. Don't blame your manager for that.

All this adds up over time and makes you slower.

What to do instead?

If you want to write quality software that lasts, there is no way you can avoid writing tests. Writing tests after the release may be better than no tests at all, but it’s not good enough. Unless you write tests first, you will always struggle with quality, design, and delivering on time.

Testing is a skill, and you need to cultivate it. The more you do it, the better you become at it. And as you get better in TDD, you are likely to produce quality faster.

Start with TDD today. You won’t regret it, I promise.

Why I migrated from ProtonMail to Fastmail (and how)

Ondrej Sevcik — Sat, 29 Jan 2022 10:51:57 +0000

I’m a long-time fan of ProtonMail. Their mission is something that resonates with me. That’s why I had a hard time deciding whether I want to leave them or not.

What’s the problem?

ProtonMail is built as a completely zero-knowledge service. It means they don’t know anything about my data. That’s great, but it has also some major drawbacks.

You cannot use anything but their official apps. ProtonMail has a Mail app for iPhone. But there is no Calendar app and there is no way to synchronize contacts between your email and phone.

For some time I tried using mail and calendar through my mobile browser, but it wasn’t a good experience. Things that should take a few seconds took minutes and over time I was reluctant to do them at all. It was hurting my productivity and I felt disorganized. I started searching for an alternative.

Searching for an alternative

I was looking for some privacy-friendly alternative. I’ve also considered switching to Apple iCloud+ with a custom domain, but I quickly decided against it. It’s better to keep my data out of the Big Five gang.

Email contains who you know, where you go, and what you do.

After searching for some while, I’ve stumbled over Fastmail. The reviews were very positive and I’ve also recognized them from the 1Password podcast. I gave them a try and I don’t regret it since. It simply works. Scan a setup QR code on your phone, download configuration profile on your Mac, and you're done - amazing!

One feature that I’m particularly enjoying is Masked email. I didn't realize this until I've started using it. But being able to create an email alias exactly when you need it is great. More privacy and less tracking across the web.

Migration

Moving Contacts and Calendar was easy as downloading a file (.ics, vCard) from ProtonMail and uploading it back to Fastmail. But when it came to encrypted Mail, it wasn’t as straightforward as I would hope.

Since ProtonMail is zero-knowledge, it’s not possible to use the usual IMAP import to move your data directly between different mail providers. I had to download all my mails with an export tool to the .mbox package.

But even after that, the trouble didn’t end. Fastmail doesn’t support uploading the .mbox file. I used Apple Mail to import my emails from .mbox first and then connected it with my Fastmail account and drag&dropped my local mails to Fastmail inbox. A bit more work than expected.

The whole migration including changing DNS records took around 2 hours. Not bad.

Conclusion

I still support ProtonMail in their mission and I will still pay for their VPN. But for now, I’ve decided that I need to migrate somewhere where it fits better into my setup.

Fastmail turned out to be a perfect alternative. Their service simply works and I like their commitment to privacy and community.

Maybe one day, I will migrate back, maybe not. Ultimately I’m glad that I have my own domain and can switch between different providers in a few hours. Those 12$/year for a domain are worth the freedom. You simply switch where it makes the most sense for you.

Console.error or throw new Error?

Ondrej Sevcik — Sun, 21 Nov 2021 11:50:11 +0000

Recently, I was involved in a discussion about error handling. We couldn't agree on proper usage of console.error and when to use throw. So I've decided to write a short post on how I see it.

When to use console.error

Almost never. console.error is nothing else but console.log that outputs red in your developer tools. It can’t be really considered as an error handling tool.

Use console.error (or console.assert) to make assertions to prevent impossible. Anytime you think "this could never happen", add assertion on that.

Keep those assertions also in production code unless it is a performance issue. You will experience way more "impossible" scenarios in production and having assertions in your code will help you to discover them earlier.

When to use throw new Error

Anytime you have corrupted data or an impossible state - throw!

Dead program can do less harm than a program with corrupted data.

Consider following scenario

try {
  let today = new Date(‘orange’)
} catch (e) {
  // handle error
}

Since it’s impossible to create a date from orange, it’s better to throw an error.

What’s the alternative (future)?

Exceptions (throwing errors) are mostly used in OOP languages. Functional languages treat errors as a type rather than something special.

It's becoming more common to see this pattern also in non-OOP languages. But I would be careful to use it until it becomes standard.

let f = File::open("hello.txt");

let f = match f {
    Ok(file) => // do something with file
    Err(error) => // do something with error
};

The example above is from Rust. The method open() returns either File type or Error type. In either case, it’s just a type, no exceptions.

I find this error handling most straightforward. It makes it obvious what functions may return Errors, plus it forces you to handle them properly.

Conclusion

Don't use console.error for real error handling. Use throw new Error() when you can't satisfy your business needs. And treat all errors equally, no matter where they come from. It will make your life easier.

PS: Warning is just a future error.

On giving and receiving Feedback

Ondrej Sevcik — Thu, 22 Apr 2021 17:07:54 +0000

Without a doubt, one of the most difficult soft skills to develop. And though I don't claim to be an expert on the topic, here are some simple rules that worked well for me.

Giving feedback

Don’t delay giving feedback
Avoid anonymous feedback — It feels fake and dishonest.
Always give it in private
Actively prepare for one-on-one meetings
Write down questions you want to ask
Give concrete examples
Deliver the bad news
Avoid shit sandwich — It does not work. It feels dishonest.
Explain why you deliver given feedback — “I believe you can be great…, because …” is better than just dry feedback. But you also have to mean it, don't be fake.

When asking for a feedback

Get well with receiving difficult feedback — It's the view of the person delivering it.
Ask specific questions — Generic questions lead to generic answers.
Ask for advice rather than feedback — People tend to talk more when they are asked for advice. And it does not have a negative tone to it.

Other “hacks”

“When you do X, it makes me feel like Y” — Feels more genuine.
As a leader or manager always explain your decisions — No matter if you incorporated received feedback or ignored it. People want to know why.

Let me know which ones you like and whether you have some that work well for you.