Two-stroke bikes

Let’s get one thing straight: I’m not a mechanic and will unlikely become one. I’m not a racer and will unlikely become one, either. That doesn’t prevent me from adoring state-of-the-art machines, namely the two-stroke race motorcycles.

Two-stroke engines are up to two times more powerful than equally-sized four-stroke engines (used in all cars and most motorcycles), but their power is only available at a narrow range of revolutions per minute. Their beauty comes in the form of powerful but smaller, lighter, and more agile motorcycles which are complex to drive. Two-strokes have a steep learning curve, but I didn’t get into bikes to get from point A to point B in the most convenient manner, so I don’t mind.

Here is a power graph of two-stroke and four-stroke motorcycles of the same engine size at different rotation speeds.

Yamaha YZ250F four-stroke dynamometer test, property of dirtrider.com

Beta 250RR two-stroke dynamometer test, property of dirtrider.com

This post is a short guide on hosting a privacy-focused comment system Remark42 on a virtual machine in the cloud for free or a small monthly fee.

Prague, Riegrovy sady, June 2022: photo by Ksenia Gulyaeva

Obtaining a virtual machine instance in the public cloud

Follow one of the instructions below to obtain an instance. At the end of the setup process, generate an SSH key and download it to your machine. The default location to store the private part of the key on Mac and Linux is ~/.ssh/id_rsa. You’ll need to connect to that instance using SSH during the next step.

Oracle Cloud, free

Register (requires credit card details) first. Then, create an instance there: you should pick a machine type Ampere “VM.Standard.A1.Flex” with 4 CPUs and 24GB of RAM. Initially, you would have a free trial for many resources, but that machine would be free and remain free for you for the time being.

In case you need more machines for other purposes, you can run up to four with 1 CPU and 6Gb of RAM each, as long as the total number of CPUs and RAM amount fits the number above. Oracle Linux is the default OS there, but you can pick something else like Ubuntu if you wish.

Sporadically, I have to provide written technical feedback to my colleagues, some of whom I didn’t interact with much but used their services regularly, or I happen to have just the right expertise to estimate their work quality and impact.

I review the traces of their work I can find for the period a colleague requested the feedback (six or twelve months usually) and try my best to identify the work’s scope, intention, and impact. Here is a list of things I take into consideration:

1. Pull Requests made by the person:
   • https://gitlab.com/dashboard/merge_requests?scope=all&state=merged&author_username=USERNAME for GitLab
   • https://github.com/pulls?q=is%3Amerged+archived%3Afalse+is%3Apr+author%3AUSERNAME for GitHub
2. Pull Requests reviewed by the person:
   • https://gitlab.com/dashboard/merge_requests?scope=all&state=merged&approved_by_usernames[]=USERNAME for GitLab
   • https://github.com/pulls?q=is%3Apr+reviewed-by%3AUSERNAME for GitHub
3. Wiki\documentation changes made by the person. In particular, checking the difference between the document before and after the changes is extremely useful for the review.
4. If the above information is not enough, the ticket system like Jira, as a last resort. Usually, filtering resolved tickets assigned to the person is enough.

Written artefacts play a significant role in performance evaluations and promotions in the Big Tech (Meta, Google, Microsoft). Providing feedback is a great way to help a colleague receive deserved recognition from the company.

Amsterdam, Walenpleintje street, June 2022: photo by Ksenia Gulyaeva

Recently I was asked to help prepare for the developer to SRE transition by two people, and here is the list of resources I recommended to them:

1. The System Design Primer - I propose going through the Readme starting with a section “System Design topics start here”, and then going into examples. That way, you’ll know which components can be used as building blocks and their tradeoffs.

2. Monitoring Distributed Systems and Service Level Objectives chapters of Site Reliability Engineering book

3. Crack the System Design Interview

4. Back of the Envelope Calculation for System Design Interviews

5. Non-Abstract Large System Design from SRE Workbook is a very detailed example that thoughtfully explains the approach experienced SRE is supposed to follow during the system design process

Going through these five links with enough attention should be enough to get a decent System Design knowledge fundamentals in general and prepare for the interview.

WikiLinuz, CC BY-SA 4.0, via Wikimedia Commons

Troubleshooting

Here is a solid cheatsheet on troubleshooting based on a Meta (Facebook) interview for a Production Engineer position.

SRE checklist

mxssl/sre-interview-prep-guide is a complete checklist for everything you should know as an SRE, except for the coding part. If you learn something about each point in that (a pretty extensive) list, you’re good to go for interviewing as an SRE to any Big Tech company, passing the hiring bar for technical interviews at FAANG.

1. Big problems on a small scale

2. A year of SRE work on a small Bitrix site (this post)

In this post, you’ll learn what I learned over a year when I picked up responsibility for my father’s website commercial and technical success. Despite all my Site Reliability experience, I wasted plenty of time and effort due to not following two simple rules I already knew, which are don’t change the system without looking at the relevant data and graphs you identified as a target of a change in advance, and, the primary rule of any refactoring, avoid introducing multiple changes at once as they make results interpolation close to impossible.

Site speed

The website has a lot of decent content with SEO-friendly metadata, however, it did not have as good search engines positions as it deserved. One of the solid factors for search positions, especially for mobile users, is site loading speed. I thought it was the biggest problem I could fix to give the site an edge over competitors.

I assumed that replacing Apache with Nginx + php-fpm, enabling Nginx PageSpeed mod and upgrading the PHP version alongside checking the code for possible JS optimisations should speed the site up. The page readiness time graph below shows that part of the assumptions had the opposite effect of the desired one.

Percentiles: 50th | 75th | 90th | 95th

1. Big problems on a small scale (this post)

2. A year of SRE work on a small Bitrix site

My future is bright, but my present is dreadful. Aside from usual life problems, which I can’t do anything about, I’ve got a bunch I’m capable of resolving, and that turned out to be a challenge I could not cast away.

A bit of background

I’ve started helping my father’s small company of 13 people plus three contractors working on the site and its content when I’ve heard enough silly stories about problems with the company site. Three particular which enraged me the most were:

• sitemap.xml not renewed for two months after migration to the new platform causing massive search engines traffic decrease
• robots.txt for regional subdomains having Hostname directive pointing to the main site, effectively causing three sites to merge into a single one in the eyes of the search engines
• the cherry on the cake, the Google Lighthouse website performance benchmark reliably shows 25-30 points out of 100

Philadelphia City Hall, March 2020: photo by Ksenia Gulyaeva

Recently on many occasions, I’ve had to explain the difference between SRE and DevOps practitioners and thought it might be helpful to write it down.

DevOps are making developers happy by increasing development velocity.

Site Reliability Engineers are making business happy by providing meaningful and comprehensible visibility into technical systems’ health. The key is the ability to communicate risk in the same terms to both business and technical stakeholders.

Сегодня я хотел бы поделиться с вами видео Jordan Peterson’а, канадского преподавателя психологии и превосходного оратора, на которого я наткнулся пару дней назад. На канале Bite-sized Philosophy подобраны пяти-десятиминутные фрагменты его выступлений и лекций, в которых он отвечает на какие-либо вопросы или в рамках большой темы рассказывает про малую.

В видео ниже Питерсон рассуждает о том, что, чтобы стать тем, кем ты хочешь, необходимо отправиться в “путешествие”, начать двигаться к своей цели, даже зная, что в самом начале ты ничего не будешь понимать в новых для тебя областях, и будешь поразительно глупо и глубоко ошибаться. Это нормальная часть процесса, и её нельзя пропустить: невозможно выбрать более прямой путь с меньшим количеством ошибок сидя на месте и наблюдая, поскольку позиция цели уточняется в процессе путешествия. Из изначальной точки цель видна нечётко и совсем не там, где она на самом деле находится, только двигаясь, со временем ошибаясь всё так же часто, но с менее серьёзными последствиями, можно в конечном итоге её достигнуть, и само это путешествие будет частью интересной и достойной жизни, чего нельзя сказать о сидении на пятой точке в ожидании.

Следствие из предыдущего предложения: когда ты не двигаешься к цели и ожидаешь правильного момента и возможности, opportunity, которая позволила бы сразу достигнуть цели, ты не сможешь ею воспользоваться. Даже когда она будет перед твоим носом из-за отсутствия опыта побед и поражений ты никогда и не узнаешь, что эта возможность является правильной, поскольку глупость, отсутствие опыта помешают тебе.

«Вот то, ради чего, собственно, люди потребляют ЛСД, наркотики, идут на смерть, почему они прыгают с парашютом, почему они идут в наемные солдаты, в экстремальные точки едут и т. д., то есть ради определенного праздника, ради праздника с большой буквы, ради праздника экстремального, экзистенциального, мистического праздника, потому что если праздника нет, то эта жизнь […] не нужна».

«А, по мне, так… самое страшное это умереть заживо. Это самое чудовищное, что я могу себе представить… И вообще, мне кажется, что лучше уж (и, главное, красивее) яркое, горькое, испепеляющее и победное мгновение света, чем долгая косно-унылая и прозаично-параличная жизнь».

«Сытый индивидуум, существующий в липкой протяженности будней, надежд, желаний, ожиданий и т. д. и т. п., не сотворит чуда, не остановит мир. На это способен лишь тот, кому нечего терять».

Про это же трек Долгая счастливая жизнь из одноимённого альбома 2004 года.

Случалась ли когда-либо в вашей жизни ситуация, в которой от ваших действий сейчас буквально зависит ваша жизнь? Весьма маловероятно, если вы не военный, и тем интереснее мне было бы услышать эту историю.

У меня такая ситуация в последний раз была сегодня ночью — я укладывал парашют перед прыжком, который состоится в следующие выходные, а до этого делал это на аэродроме непосредственно перед прыжками. От моих действий зависит, откроется ли парашют мягко и даст нормально лететь под ним до приземления, или откроется слишком резко, отчего я потеряю сознание от перегрузки и сломаю позвоночник, или что угодно в промежутке между двумя этими сценариями. Когда занимаешься парашютным спортом, об этом толком не задумываешься — но пару недель назад на жёстком открытии на своей укладке я здорово ударил рёбра, и вспоминаю об этом каждый раз, когда пытаюсь глубоко вздохнуть.

Skydiving in a car

В 50 выпуске Radio Skydive UK (потрясный подкаст про парашютный спорт в UK и вообще) в рубрике “School of Hard Knocks” (школа жизни?) в отрывке 2:57:00 - 3:06:00 Dan Brodsky-Chenfeld рассказывает о том, как он выпрыгнул из самолёта, находясь на пассажирском сиденье кабриолета.

В какой-то момент полёта машина сделала сальто назад, без последствий выкинув трёх других пассажиров-парашютистов, а ему (поскольку ему не за что было держаться) сломала большой палец и нос, и здорово тряхнула по рёбрам. Из-за крови из разбитого носа он ничего не видел, и вынужден был улететь для открытия подальше от машины в наугад выбранном направлении, после чего раскрыл парашют и с горем пополам приземлился.

Самой сложной частью приключения оказалось объяснить врачам в госпитале, куда он приехал самостоятельно, каким образом он попал в такой серьёзный “car accident”, но его машина при этом в целости и сохранности стоит на парковке, и убедить их не вызывать шерифа. Описание прыжка показалось мне очень знакомым, и я по памяти нашёл видео, на котором он запечатлён:

Кто бы знал, что у этого видео из середины девяностых есть такая богатая история?