How To

For the last year, strange things were happening with Medium. Many people complained that Medium hides everything behind the paywall, but I didn’t get it, until recently… but let us start from beginning.

My first blog was a static page on GitHub, written in Markdown. They were deploying through Jekyll. I love everything about Jekyll and GitHub Pages, but when you need to make drafts, share them with your technical editor, got comments on your writing style, etc… it becomes harder to handle all of that, since these are just plain Markdown files.

While looking for other solutions, I’d found Medium a few years ago. It was a breakthrough. It has a WYSISYG editor, you can make drafts and share them with people, getting the feedback as comments to your lines. You were fixing those issues and “Publish”. Decent!

Everything was great until they had introduced paid membership. They were selling this with a motto “let your posts make you money” or something like that. It was optional, so I just refused and forgot about it. You still can read other’s people posts, write your own, so what is the difference, right?

Read Full Article

Recently, I have published an article where I describe a few tricks about how to migrate your project from multi-repository to mono-repository. Some of you really appreciated the topic:

However, some of you wanted more details about the build process itself. So, I have written about that in depth.

Read Full Article

We had a lot of repositories for different services. There are 20K+ commits in 15+ repositories. Each repository has its own Dockerfile, tests, lint rules, etc.

Turns out, it’s hard to maintain, especially when you have dependent repositories across. I.e. you have repository api that is using a package from another repository, let’s say commons. If you publish an update in commons, you need to go through all the dependent repositories and update commons there.

Now, just imagine how long it takes, to make a clone of each repository, make an update there and push changes back to remote. It’s hard to say for me, but these kinds of updates were leading to half a day work just for updating the changes in other repositories. Therefore, we allocated resources for changing that.

But, before I started migration to a mono repository, I spent some time investigating the pros and cons of other alternatives.

Read Full Article

Last time, we created a working boot sector, the BIOS can find with the help of magic numbers. You can read more about it here (if you didn’t, I highly recommend doing that now, as you may miss some important details).

The question here is “Why do we need a second stage boot loader?”. We can implement all of it in the boot sector, using Assembly, so… why?

The problem is… size limits. You can’t store over 512 bytes of code in the boot sector, so if you want to make a super-duper boot loader (like GRUB or similar) you need to store all of it somewhere else, but not in the boot sector itself.

And that is one of reasons, we need to have a second stage boot loader.

Read Full Article

Some of you want to or thought about contributing into Node.js core but don’t know how to do it or don’t have enough confidence. Well, I’ll try to help you out with that.

I am an outside collaborator in Node.js and sometimes I look into issues and take some. Also, I already have a few pull requests successfully landed into Node.js core, so I will tell you about my experience.

Let’s start with running it locally.

Read Full Article