RubyRussia

Puma de facto является стандартом в индустрии, но имеет свои ограничения - особенно при сотнях RPS. При невозможности заливать приложение ресурсами приходится изобретать способы утилизировать имеющиеся как можно больше. Расскажу о нашем опыте перехода на fiber-based веб-сервер Falcon и о том, с какими проблемами мы столкнулись при его эксплуатации.

ActiveRecord - один из немногих фреймворков, где схема базы живет отдельно от описания моделей в коде. Из-за такого разделения вытекает куча специфических проблем, когда описанные в модели ограничения и связи не соответствуют тому, что на самом деле происходит в базе. У нас в Toptal очень большая база и следить за корректностью использования ActiveRecord вручную не вариант. Поэтому в 2018 году я сделал инструмент, который проверяет типовые ошибки автоматически. За годы использования количество проверок выросло, инструмент стал open source, а я выступаю на этой конференции, чтобы рассказать его историю и показать, как появились все эти проверки, и чем они могут помочь вашему коду.

В наш цифровой век технологии развиваются стремительно, языки программирования не исключение. Вероятно, каждому из нас закрадывалась мысль "а не посмотреть ли мне новую альтернативу моему языку?". Периодически эта мысль побуждает действия, и, иногда, даже приводят к смену изрядной части стека разработки. Я расскажу об одном из таких случаев, когда Ruby разработчик несколько лет вынашивал идею перейти на Elixir. Финал счастливый.

Выбрать API в 2022 году не проще, чем двадцать лет назад. За наше внимание конкурируют GraphQL, gRPC, JSON API, JSON:API (нет, это не то же самое), OpenAPI и другие. Можно выбирать одно, можно использовать несколько разных, и в любом случае будут проблемы и недовольные разработчики. В докладе я расскажу, как мы несколько лет экспериментировали с разными подходами к API, чему научились и какие выводы сделали. Путь еще не окончен, но нам уже есть что обсудить!

В мире тестирования много разных инструментов, и когда приходишь в компанию, не знаешь, что там найдешь. Многие языки приходят вслед за популярными тулзами. Например, Ruby часто приходит вслед за puppet. Или за Cucumber. В докладе я расскажу, как мы в Альфа-Банке используем Cucumber для тестирования большого и сложного внутреннего проекта. Какие модификации нам понадобились и к каким практикам мы пришли. Авторы Cucumber пишут, что это решение не для тестирования, а для коммуникации. Я покажу, как мы создаём сотни сценариев на русском языке, которые используем не только для автотестов, но и для общения с другими командами.

Все знают, что бизнес–логику в Rails лучше держать подальше от моделей и контроллеров: паттерн «service object» и все его многочисленные родственники давно и плотно вошли в обиход. Результатом работы такого примитива является некий результат: либо успешный (содержащий некие данные внутри), либо не очень (обычно там одна или несколько ошибок). Как известно, если вам нужна некая новая абстракция — нужно почитать книжку по функциональному программированию, и она там обязательно найдется. Этот самый результат не стал исключением: для нашей задачи подойдут монады Either или Maybe (пользователи dry-monads не дадут соврать). Однако, если копнуть чуть глубже, то выяснится, что, кроме монад, нам подойдет еще одна абстракция: аппликативные функторы. Они более ограничены, но более просты. В докладе мы выясним, что же такое функтор, как сделать его аппликативным, как превратить его в монаду, и в чем же, черт возьми, разница между ними!

Есть ли рецепт качественного гема - клиента для API? Мы в Домклик постарались ответить на этот вопроc. Собрали лучшие наработки и подходы за 4 года, приправили частичкой души наших коллег - рубистов и создали инструмент для генерации новых API-гемов. Я расскажу, как мы готовили наш фирменный “Гем для гемов” - Gemfather, какие ингредиенты он в себя вобрал и почему не всегда можно применить генерацию API-клиентов по документации.

Когда распиливаешь монолит, остается база. Можно ее реплицировать, можно делать сервисы с общими данными. Но нам такие способы не подходили, поэтому мы реализоваи свой Open-Source инструмент. Я расскажу вам про технологию, которая позволяет в реальном времени синхронизировать части баз данных между микросервисами. Мы делаем сложные финансовые продкуты: много данных, сложные правила синхронизации, высокие требования к надежности. Инструмент получился гибким, и я покажу вам, как эта гибкость используется в наших реальных проектах.

По моему опыту, dry-rb или любят, или ненавидят. Новым рубистам из-за этого тяжело составить свое мнение об инструменте. Я видел, как dry-rb начинают использовать после почтения восторженной статьи или, наоборот, отказываются попробовать после разгрома на Хабре. Мой доклад о том, как я стараюсь нейтрально смотреть на dry-rb: какие-то части мне нравятся, какие-то выглядят странными, а для других я не вижу разумного применения. Приходите, и мы вместе обсудим разные грани dry-rb в 2022!

Долгое время в Uscreen мы вели фронтенд разработку в связке Vue.js + Inertia.js. Релиз Hotwire в конце 2021 года побудил нас пересмотреть то, как мы создаем клиентскую часть приложения и начать плавный переход с Vue.js на Hotwire. В докладе я расскажу не только о самом переходе, но и наших многолетних изысканиях: в чем мы видим сложность современного фронтенда, как разделяем работу бэкенд и фронтенд программистов и какие требования предъявляем к нашему стеку. Переход пока далек от завершения, но мы уже нащупали годные практики и готовы ими поделиться!

Что делать, если ваш сервис вырос в 14 раз за год? Радоваться! А как быть с нагрузкой на БД? Спрятать много реплик базы за proxySQL. Мы так и сделали, но обнаружили, что реплики отстают. Для большинства проектов это не критично, но не когда у вас магазин, корзина, покупки и вот это вот всё. В докладе я расскажу как обычно решается задача с репликами и каким путем пошли мы, чтобы не переделывать полностью архитектуру проекта. Покажу такие штуки как “stickiness context” и “time-tolerant endpoints”, расскажу как мы прошли путь от одной базы до 18 реплик, “тактик чтения” и чему научились.

В 2022 году, если мы хотим массово рассылать нотификации от сервера клиентам, то чаще всего используем вебсокеты вместе с ActionCable. Или AnyCable, если таких клиентов много. Но всегда ли это лучшее решение? В докладе я расскажу, какие подводные камни с вебсокетами есть сейчас и как себя чувствуют альтернативы: long polling (да, оно живо!) и server-sent events. Мы в Learning Tapestry делаем интерфейс отслеживания школьных автобусов в реальном времени, поэтому заморочились и разобрались во всех нюансах. И да, мы не используем вебсокеты. В докладе расскажу почему.

Так сложилось, что для push-уведомлений большинство разработчиков используют агрегаторы, у которых есть библиотеки для мейнстрим языков, и конечно же для Ruby. Недавно мы в igooods меняли такого агрегатора, и мне есть, что рассказать коллегам. Что агрегаторы не одинаково полезны. Что гемы конечно есть, но они странные и возможно нам хватит faraday с subrequest boundary. Что выбор агрегатора это не только поддерживаемые платформы (привет, Huawei!), но и тулзы, используемые вашими маркетологами. И много других штук, о которых мы не задумываемся, пока не придет время обновить push-токены на мобильных устройствах.

Что бывает, когда компания покупает node.js стартап? Рубистам приходится поддерживать вначале JavaScript, а потом и TypeScript код. В докладе я расскажу о наших впечатлениях от языка, что понравилось, а что не понравилось в инфраструктуре. Покажу, какие аналоги Rails и ActiveModel есть в мире node.js и чем они нам грозят. Можно ли разлюбить руби после ноды? Приходите, обсудим!