Skip to content
šŸ° Svetlana Zaiats
Blog

Blog

Want to learn Russian? Curated list of resources

My American colleague recently asked me for recommendations on how to self-study Russian. I reached out to a friend of mine who teaches Russian as a foreign language professionally in Taipei, and now Iā€™m happy to share a list of useful resources:

Free resources

Textbooks

Also here you can find a collection of free tools and materials https://gratisglobal.com/learn-russian-free/#news-media, but this list wasnā€™t tested personally by me, my friend or her colleagues. But there is definetely a lot of interesting and useful things.

Apps

  • Babbel+ is surprisingly good for Russian.

Youtube

Books

Do you want to be a team lead? You might have to

I just listened to an episode of The Pragmatic Engineer podcast with Laura Tacho, CTO at DX - itā€™s a great conversation that I recommend to anyone in the industry.

It advocates for something I truly believe in: measure before making conclusions. But the part that resonated with me the most that probably in 2 years, every developer will operate like a team lead ā€” managing a team of AI agents. So if youā€™re not aiming to become a lead, you might still need to think like one. Now is a good time to start sharpening your technical depth, code review skills and coordination abilities (actually thereā€™s never a bad time for this).

P.S. And they also shared a great use case for AI: code migrations. Like unit tests, migrations are something most developers donā€™t enjoy (I believe) ā€” but here AI can really make a difference.

Solved all React challenges on Hackerrank and not satisfied

I read that hakerrank has challenges organized by domain ā€” for example, the React domain ā€” and decided to solve them as part of my interview preparation.

I completed all of them, but not satisfied. Hereā€™s why:

  1. The challenges donā€™t feel like real interviews. They give you a lot of code, while in actual interviews you often write components almost from scratch.
  2. The tests are not reliable. In one case, I had to remove the key from react element just to make their test pass. Test kept a reference to the element at the start and didnā€™t update it after re-render. In another challenge, tests used hardcoded outdated dates, so I had to add a weird condition just to pass.
  3. The platform itself has issues. Sometimes my progress wasnā€™t saved. A couple of times I submitted a solution, saw the ā€œCongratulationsā€ screen, went back to the challenge list ā€” and it showed the challenge as unsolved. I had to redo the solution. Eventually, I started double-clicking the submit button just in case, because I didnā€™t want to retype everything again.

Overall, I regret the time spent a little, because mostly I fought with tests, not with solving problem. Moreover, challenges turned out to be not so interesting. I liked leetcode experience more.

Hakerrank page with completed challenges

Don't use display:none without serious reasons

Two days before release ā€” and guess what? Suddenly, all popovers with information about meeting rooms in our app broke and stopped displaying. We hadnā€™t even changed anything related to this functionality ā€” how could this happen?

Situation

It turned out that the popovers were broken in all browsers except Chrome. And after the latest Chrome update, they stopped working there too.

What happened?

Four years ago, someone decided it was fine to hide a <g> element using display: none, but still call node.getBoundingClientRect() on its child elements to calculate the popoverā€™s position.

It workedā€¦ until it didnā€™t. Now, all modern browsers correctly return zero for the coordinates and size of any child inside a display: none element.

To be honest, I didnā€™t want to refactor much, so I replaced display: none with opacity: 0. In this case, the element is still invisible to the user but remains in the document flow and keeps its size.

When a backend developer tells you to parse a JWT token for user information...

I hadnā€™t parsed a JWT token on the client before, but this week our backender said that he didnā€™t have time to create a new endpoint like /user, and that I should extract user information from the JWT token in a cookie.

My first thought was: is this okay? On all projects that Iā€™ve seen backend gave me endpoint like /user, /me, /current ā€” and these endpoints were created for a reason, werenā€™t they?

Yes, there are reasons:

  • you cannot store sensitive, confidential information in JWT payload
  • you should be mindful of the size of the JWT (it is transmitted with cookies in every request)

For example, it is not a good idea to store in JWT permissions for user and rely on it in your UI. Because someone can modify the token, and your application could be at risk.

However, this means you can use a JWT to store some basic user information. In my current situation, I only need name, email and photo of the authorized user, so I started parsing JWT for this data and backend developer took another task.

What do you need for parsing JWT on client?

JWTs are Base64 encoded and contain of three parts: header, payload, and signature. You can write your own decoding function or use one of the ready-made solutions. I checked what is there on the internet for handling JWT tokens on the client-side:

  • jsonwebtoken ā€” very popular library for Node.js. It is used for generating and verifying JWTs on the server-side, can be used on the client side. Itā€™s a good library, but overkill for my case.
  • jose ā€” another library for implementing JWT, it provides functionality for signing and verifying tokens and set of utility functions. Again: good, but overkill for my case.
  • jwt-decode ā€” lightweight library only for decoding tokens. Single-purpose, easy to use, zero dependencies ā€” thatā€™s the winner for today.