Ruby *

Привет! Меня зовут Фёдор Засечкин. С 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, такое, что можно просто поднять на локальной машине и организовать сборку из проектов, которых не так много и которые не такие монструозные, требующие несколько билдеров.

Один из самых вредоносных принципов в разработке, когда-либо получивших широкую известность — YAGNI. Его озвучил Рон Джеффрис в 1998, а спустя более двадцати лет — еще и Кармак подлил керосин в огонь со своим: «Неопытным разработчикам трудно оценить, как редко разработка архитектуры с учетом будущих требований приводит к успеху».

Вообще говоря, в нашем разнообразном мире ни одна максима не может быть без оговорок применима всегда. Насколько могу судить, будучи сформулированным столь безжалостно афористично, принцип YAGNI привел к тому, что у лентяев появилась отговорка на все случаи жизни.

— Давай предусмотрим передачу конфигурационных параметров в эту функцию? — YAGNI.
— Инъекция зависимости здесь уместнее приколоченной гвоздями реализации хранилища. — YAGNI.
— Черный кофе без сахара, пожалуйста. — YAGNI!

Всем привет! На связи 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 как фреймворка от зарождения до последних достижений.

В последнее время я часто видел обсуждения репозитория сравнения языков. В нём CRuby был третьим снизу, обгоняя по скорости только R и Python.

Автор репозитория @BenjDicken создал забавную визуализацию производительности каждого из языков. В одной из визуализаций из визуализаций Ruby по бенчмаркам Ruby оказывается третьим с конца.

Всем привет, думаю, читатель, нажавший на данный заголовок, уже догадывается, о чем примерно пойдет речь. Данная статья рассчитана на тех, у кого уже есть какое-либо понимания языков программирования (лучше если именно Ruby), а также хотя бы общие сведения о HTML, работе ОС и сети.

Для тех, кто не в курсе в мире веб разработки существует фреймворк Ruby on Rails. Фреймворк горячо любим автором и сообществом и используется для создания полнофункционального сайта или по-другому веб приложения. Но все ли знают и понимают, как оно там вообще работает?

Микросервисная архитектура — это новый черный: кажется, уже все бигтехи пилят монолиты на сервисы и и ищут гошников в штат. Спрос рождает предложение — всё больше ребят переходят с других бэкенд-языков на Golang. 

Мы попросили наших разработчиков поделиться своим опытом перехода на Go и рассказать, почему они решили освоить новый язык программирования, какие плюсы и минусы видят в нём, дал ли переход на Go буст в новых карьерных возможностях и кому и в каких случаях они бы они советовали освоить golang. 

Эта статья может быть полезна тем, кто тоже хочет добавить Go в копилку знаний, но пока не решился. Приступим!

Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby...

Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб.

Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис. 

Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!

На примере простых алгоритмов (вычисление расстояния между точками, сумма членов геометрической прогрессии, формирование массива простых чисел по алгоритму Эратосфена, числа Фибоначчи) сравниваются три языка программирования - Lisp, Python и Ruby. Сравнение проходит по следующим параметрам: компактность и читаемость кода, скорость работы.