Ruby *

Привет, Хабр!

Давайте сразу начистоту: я не профессиональный программист. Я системный администратор и DevOps-инженер. Мой день состоит из автоматизации процессов, настройки серверов, написания скриптов и бесконечной рутины. И, конечно же, работы с тикет-системами, главная из которых — Jira.

Если есть необходимость взаимодействовать с Jira из Ruby-кода, то обычно выбирают гем jira-ruby — заслуженный стандарт индустрии.

Однако, попробовав использовать его для простых скриптов автоматизации в админской экосистеме, я понял: этот инструмент слишком избыточен и тяжел для сисадминских нужд. Мне хотелось чего-то простого, легкого и понятного. Так родилась rujira — моя собственная легковесная библиотека для работы с Jira REST API.

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

Решили мы добавить Rate Limit заголовки к ошибкам SubscriptionRequiredError, чтобы фронт понимал, какие лимиты превышены. Но внезапно при обработке ошибки пропал request. А значит — нет ни headers, ни current_user. Куда он делся и как это починить?

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

У меня было Falcon-приложение на Async, и в нём накопились задачи, которые надо было выполнять где-то рядом: cron-задачи, интервалы, отложенные джобы. Классический ответ — Sidekiq + Redis. Но ради трёх задач в минуту тащить в проект Redis с отдельным контейнером, отдельным процессом и отдельной точкой отказа казалось перебором. А альтернативы либо тянули за собой Postgres (который в большинстве проектов уже занят бизнес-логикой и плохо реагирует, когда на него вешают ещё и очередь задач), либо не дружили с Async event loop.

Так родился async-background — лёгкий планировщик, у которого нет внешних зависимостей кроме SQLite, который живёт в том же event loop что и Falcon, и в котором я смог реализовать ещё одну важную для меня штуку — управляемую утилизацию воркеров: можно явно сказать «эти два воркера только cron, эти два только очередь», или прибить конкретную задачу к конкретному процессу, без переписывания кода.

В статье — история создания гема: какие альтернативы я смотрел и почему они не подошли, какие принципы я зафиксировал на берегу, какие технические находки получились по ходу (min-heap вместо тиков, две шкалы времени, CRC32-шардинг для multi-process safety, UNIX-сокеты для мгновенного wake-up очереди), и какие гочи я нашёл лбом — включая историю про то, как Docker overlay2 ел мою SQLite базу под нагрузкой на staging.

Это адаптация моей англоязычной статьи на Medium

Всем известный Ruby on Rails, как самый яркий пример использования DSL, позволяет разработчикам абстрагироваться от низкоуровневых деталей реализации и сосредоточиться на бизнес-логике. Написание кода выглядит очень лаконично и выразительно, но как это работает? Давайте разберемся на простом примере.

"Loom" означает "ткацкий станок" - так назывался проект по добавлению асинхронности в джаву. Тяжёлые системные потоки заменили легковесными виртуальными потоками. Потоки и нити в английском называются одинаково - thread - отсюда название.

Проект успешно внедрили пару лет назад, и я, к сожалению, это полностью пропустил. Основная причина, конечно - что я в принципе не ожидал от джавы никаких прорывов (и оказался на 100% неправ!) Ну и, как бэкенд-разработчик на питоне, я не очень-то слежу за развитием JVM-языков.

Но исправляюсь: Project Loom - это блестящая идея. Учитывая, что его внедрили совместимым образом, и почти не было ломающих изменений. Я считаю, это оптимальная реализация асинхронности для высокоуровневого серверного языка.

Уже почти все использующие JVM языки переехали на новую версию JVM, и, таким образом, на проект Loom: деваться им некуда. Так что, есть надежда, что это изменение откроет новую главу для некоторых из них. Есть также предположение, как оно может повлиять на скриптовые языки, такие как питон. Гипотеза только.

Также, вы узнаете, почему Гвидо ван Россум не ошибся, когда добавлял async/await в питон, а Мацумото — создатель Ruby — тоже угадал, когда, наоборот, отказался от async/await.

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

В Ruby‑разработке ActiveRecord давно стал стандартом: он интуитивно понятен, встроен в Rails и позволяет быстро проводить CRUD‑операции. По мере роста проекта его «удобство» нередко начинает оборачиваться скрытыми проблемами.

Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.

Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.

Я решил написать серию статей о том, как мы проходили этот путь: что сработало, какие ошибки допустили и какие решения реально помогли. Этот текст — первый из серии.

Некоторые считают Java раздутым монстром, а Rust — чемпионом производительности. Но что, если взглянуть на современную Java с Vector API и многопоточностью? 

В новом переводе от команды Spring АйО посмотрим на запуск масштабной симуляции частиц и сравним результаты. Правда ли, что бывалая Java всё ещё умеет удивлять? 

Сравнение performance-а языков всегда было холиварной темой. Рекомендуем расценивать статью как приглашение к конструктивной дискуссиии, а не как призыв к конкретному действию.

Я 10 лет был клиентом AWS и контрибьютором проектов с открытым исходным кодом, а они удалили мой аккаунт и все данные без какого‑либо предупреждения. Ниже — история о том, как «верификация» у AWS превратилась в цифровую казнь и почему нельзя доверять облачным провайдерам, если у вас нет копий данных вне облака.

На 23 июля 2025 года AWS удалил мой аккаунт, которому было 10 лет, и каждый байт данных, который я там хранил. Без предупреждения. Без льготного периода. Без возможности восстановления. Произошла полная цифровая аннигиляция.

Ниже я расскажу историю о катастрофической внутренней ошибке в AWS MENA, 20 днях кошмарного общения с поддержкой, в ходе которого я так и не получил прямого ответа на вопрос «Мои данные ещё существуют?», и о том, что всё это показывает в отношении доверия облачным провайдерам.

Вы когда-нибудь сталкивались с плагинами, которые лезут в чужие папки, перезаписывают файлы ядра и превращают git status в ад?

Я — да. И вместо того чтобы мириться с ручным копированием, гигантскими .gitignore и вечными конфликтами, написал dmp — инструмент, который:
 Отслеживает, откуда взялся каждый файл,
 Автоматически разрешает конфликты (или даёт контроль),
 Не ломает IDE (никаких симлинков!),
 Работает с любыми языками и фреймворками.

Для кого:
— Разработчики плагинов/модулей,
— Те, кто устал от git-submodules и rsync,
— Все, кто хочет чистый workflow без монрепозитория.

В последние месяцы я всё чаще сталкиваюсь с одним и тем же выводом: внедрение LLM-систем (особенно с использованием RAG-подхода) тормозится не из-за самой модели, а из-за отсутствия качественных данных. Самое дорогое в процессе — это не запуск пайплайна, не подбор архитектуры, а подготовка структурированных, очищенных и корректных данных, пригодных для обучения или дообучения моделей. Всё чаще этот подход называют AI-Ready Data.

Что происходит, когда GitHub берётся за собственную безопасность? Они пишут код для защиты кода — и активно используют для этого CodeQL. В этой статье команда Product Security Engineering рассказывает, как настроить масштабный автоматический анализ уязвимостей, зачем создавать свои пакеты запросов и как с помощью CodeQL находить ошибки, которые невозможно поймать обычным поиском по коду.

Есть множество сервисов и программ по сборке программных пакетов: OpenSuse Build Service (OBS), koji. Fedora copr, rpmbuild, mock.

Все они позволяют организовать сборку программных пакетов, релиз пакетов в репозиторий и пр. Большинство систем обладают обширным функционалом, например тот же OBS позволяет собирать как deb пакеты, так и rpm, так и AppImage и т. д. Koji позволяет разбить сборку по разным машинам и управляя билдерами организовать сборку огромного числа тяжелых пакетов, многие комплексы типа OBS и Copr вообще организованы в виде сервисов в сети и позволяют различным пользователям собирать пакеты и публиковать их в публичных репозиториях.

Зачем же еще понадобилось дополнительное средство по организации сборки rpm пакетов и репозиториев?

Объясню - хотелось бы что-то простое в установке и настройке, как например gitea, такое, что можно просто поднять на локальной машине и организовать сборку из проектов, которых не так много и которые не такие монструозные, требующие несколько билдеров.

Всем привет! На связи Speach (ex. IT-People). В прошлом году мы сменили имя, но не изменили своей любви к конференциям. И продолжаем организовывать самые душевные и классные мероприятия для айтишников. Приглашаем принять в них участие.

25 апреля, DUMP EKB, Екатеринбург

Крупнейшая конференция разработчиков на Урале, куда приезжают более 2000 человек! Конференция, которая традиционно собирает топовых IT-экспертов со всей страны. В 12 секциях прозвучат десятки докладов ТОЛЬКО на актуальные темы. Впервые в этом году — новая секция: TechLead. А также — Backend (2), Frontend, Testing&QA, Team, Product, ML&DS, BA&SA, DevOps, Design, Science, круглые столы, воркшопы, нетворкинг и афтепати.

С версии 3.0 в руби появились неблокирующие файберы, с помощью которых писать код с асинхронным вводом-выводом стало заметно удобнее. В данной статье мы напишем свой простой планировщик для файберов, чтобы лучше разобраться, как работают более сложные планировщики, типа socketry/async.

Программирование — это не только алгоритмы и логика, но и удивительное разнообразие синтаксиса языков. Работая над новым средством подсветки синтаксиса для llamafile, разработчик Justine Tunney* исследовала 42 языка программирования — от классического C и экзотического Tcl до мощного Ruby. 

Justine делится своими открытиями о том, насколько причудливым и непредсказуемым может быть лексический синтаксис. Например, триграфы в C — устаревший инструмент для поддержки клавиатур с ограниченными символами, фиксированные длины строк в FORTRAN, вложенные комментарии в Haskell или строки с двойными квадратными скобками в Lua. Ruby вообще оказался чуть ли не самым сложным языком для подсветки из-за его контекстно-зависимого синтаксиса.

Под катом вы найдете описание разработки инструмента подсветки и исследование того, как языки программирования решают одни и те же задачи по-разному. Если вам интересны синтаксис, языковые особенности и сложности лексического анализа – эта статья для вас.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

Язык Crystal каждый раз удивляет меня. Я думал что язык с синтаксисом Руби не может быть быстрым как Си. Я думал что учитывая что его авторы сидят на Маке или Линуксе его никогда не портируют на винду. Я думал что не справятся с многопоточностью учитывая насколько это усложняет шедулер. И уж совершенно точно я был уверен что портировать его на микроконтроллеры нереальная задача - большой рантайм, ориентированная на GC стдлиба.

Сейчас я покажу как можно писать для микроконтроллеров на Crystal.

Ruby On Rails был краеугольным камнем в веб-разработке с момента своего основания, позволяя разработчикам создавать масштабируемые и поддерживаемые веб-приложения. С эволюцией Rails каждая версия вводила новые функции, улучшения производительности и безопасности. Поскольку Rails имеет открытый исходный код, разработчики постоянно решали существующие проблемы и добавляли улучшения, поддерживая фреймворк в соответствии с новыми трендами. Итак, давайте рассмотрим путь Rails как фреймворка от зарождения до последних достижений.