За семь лет в IT я повидал многое: и большие задачи, и экстренные багфиксы ночью, и не совсем понятные требования от бизнеса, но всегда это были готовые проекты с уже выстроенной архитектурой, где знаешь, что и как работает. Год назад, в конце августа, ко мне пришел знакомый и сказал примерно следующее: у меня есть команда, мы занимаемся P2P платежами, сейчас работаем с одной известной площадкой, но хотим сделать свой продукт, можешь с этим помочь?

Экспертизы в сфере P2P платежек у меня не было, поэтому первоначально пошел гуглить, что это вообще такое, где и как работает. После изучил схему, которую он мне прислал. В голове обрисовалась картинка как это можнно реализовать на практике, я ему рассказал свои мысли, сильные и слабые (на мой взгляд) стороны его идеи. После чего он выдал: а сделать сможешь? Деньги на реализацию есть, ТЗ — напишу, всё как полагается.

Опыт создания проектов с нуля у меня практически нулевой. Конечно на работе я занимался и настройкой деплоя, и созданием новых сервисов, но чтобы и разработать, и задеплоить, и потом еще работоспособность поддерживать - такого еще не было. Внутри мелькнула мысль: это же новый уровень, вполне рабочий вызов. Чтож, пора попробовать. Что из этого вышло - под кат

Как сейчас помню, понедельник 25е октября, я заступаю на дежурство по проду и с самого утра мне прилетает задача: сегодня в ночь с 24 на 25 ноября, наблюдалась проблема с недоступностью приложения. Глянув сентри я увидел кучу ошибок от базы со statement timeout, а так же непонятные ActiveRecord::ConnectionNotEstablished: No connection pool with 'primary' found С мыслью "база не отвечала, проблема не на нашей стороне" я спокойно отдал задачу на разбирательство админам, а сам параллельно глянул графики, может там был всплеск каких-нибудь джобок или запросов, но ничего криминального в графане небыло: тяжеловесных джобок в 12 не запускается, а те, что запускаются отработали очень быстро.

В прошлой статье я разбирался с тем как работает GIL, а сегодня меня захватила идея узнать насколько дорого обходится этот GIL для кода, который исполняется у нас на бэкенде. Для этого я решил пропатчить MRI и добавить пару переменных, в которые буду засекать сколько времени поток реально выполнял код, а сколько ничего не делал и ждал пока ему удастся завладеть локом.

Давным давно уже уже была написана статья о том что такое GVL (или GIL, кому как привычнее) и как он работает, однако с того времени некоторые вещи поменялись (к примеру, , а так же в Ruby 3.0 завезли Ractor'ы - новую абстракцию для реальной параллельной работы тредов. Мне стало интересно узнать что поменялось в планировщике ruby для реализации множества GVL. В этой статье я попытаюсь понять алгоритм, по которому GVL передается от одного треда к другому, как блокирующее IO позволяет продолжить работать другим тредам, а так же выяснить до сих пор ли операция добавления элемента в массив является атомарной операцией

Очень часто разработчики на Rails для извлечения заведомо одной записи из базы используют один из методов first/last из ActiveRecord. Это рабочее решение, но есть одно НО: чтобы извлечь всего одну запись база данных должна найти все, подходящие по условию, отсортировать их и вернуть только одну. Если вы подумали "Сортировка одной записи? Да это же легко!", то не будте так оптимистичны, я постараюсь показать, что это важно.

Есть много туториалов, которые рассказывают как хранить логи Rails приложения в ELK, большинство сводится либо к парсингу логов, либо сохранению краткой статистики запроса по UDP в logstash. В этой статье я бы хотел сосредоточиться на переносе абсолютно всех логов приложения в ELK по UDP.