Ruby *

В этом дайджесте:

• Обновление популярных гемов.
• Митапы, где засветился Ruby.
• Интересные open-source проекты на GitHub.
• Ruby 3.1.0
• Подборка полезных гемов.
• Интересный контент, связанный с Ruby.

В этом дайджесте:

• Обновление популярных и не очень, гемов
• Седьмые рельсы?
• Конференции/Митапы
• "From Node to Ruby on Rails" - Откровение матерого JS разработчика-стартапера после открытия Ruby on Rails

Привет! Публикуем полезные материалы по Ruby с нашего митапа. Из видео узнаете:

— Как СберМаркет решает проблему нехватки Ruby-специалистов.

— Как на Ruby реализовать модель, сопоставимую по возможностям целому компьютеру.

— Плюсы и минусы новой серии библиотек smart-rb и уже известной в Ruby-коммьюнити dry-rb.

А еще бонус: мы приглашали Стеллу Миранду, старшего разработчика в Shopify и организатора RubyConfCo и сообщества Rails Girls Vancouver. Она ответила на вопросы о RoR, работе в Shopify, карьерном росте ruby-разработчиков и развитии лидерских качеств, а также о том, как устроены сообщества в Колумбии и Канаде.

Для удобства везде проставили таймкоды, залетайте на нужные темы!

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

Вопреки слухам на пространствах девелоперских комьюнити, Rails не становится устаревшей технологией, он не собирается умирать, и остается отличным инструментом для разработки вашего нового проекта. И одна из причин заключается в том, что у Rails имеется достаточно инструментов, чтобы покрыть базовый функционал типичного веб-приложения. Вам не нужно думать о том, как обрабатывать НТТР запросы, что использовать для ввода и получения данных из базы, как отрисовать HTML, который пользователи увидят в своих браузерах, и даже как "вдохнуть жизнь" в пользовательский интерфейс.

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

Максимально переложив ответственность за онлайн своего приложения, ты сможешь сфокусироваться на других задачах, думать больше о новых фичах и новых приложениях. Ведь попробуй просто представить себе, как ты с утречка начинаешь поднимать 20 ботов на своём бедном Lenovo в надежде, что сегодня ни свет, ни интернет не выключится? Представил? А теперь представь если 20 ботов висят на сервере и ты с утра заходишь, смотришь какой у них статус с помощью удобного дашборда. Так и 21е приложение не за горами будет :)

Понимаю, всё звучит так классно, но ты возразишь, а деньги на сервер зачем выбрасывать? Тебе кажется, что твой бот только тебе и интересен, зачем же тратиться. А если я скажу что есть сервис, бесплатный, качественный, функциональный, который в начале кажется сложным, но как всё сложное, его нужно лишь понять и станет простым и отличным помощником.

Выглядит как промо за 50$, но на самом деле я был поражен лишь тем фактом, что если зайти на цены, то там есть раздел Hobby. Это на моей памяти первый случай, когда сервис есть в бесплатном виде, чтобы поддерживать начинания разработчиков, и потом, когда идея окажется работоспособной, тут же можно понемногу увеличивать возможности своего сервиса. Только за это уже можно читать дальше, разве нет?

“Твою ж мать, какая же это хтонь!”. Примерно так можно было охарактеризовать все наши инфраструктурные скрипты до недавнего времени. Нужно было что-то менять, и мы сделали это. 

Меня зовут Павел Стрельченко, я – Android-разработчик компании hh. Я расскажу вам как эволюционировали наши CI скрипты на протяжении трех лет, с какими проблемами мы сталкивались, как анализировали их и пытались изменить, а также что вообще делали и к чему в итоге пришли. 

Это текстовая расшифровка выпуска нашего влога, поэтому если вам удобнее смотреть, а не читать, добро пожаловать на наш Youtube-канал. В статью получилось добавить множество дополнительных ссылок, так что можно почитать ещё и их. 

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

Во время разработки своего приложения в качестве проекта внутри компании, поступил запрос на постройку графика по некоторой выборке данных, чтобы по команде Slash Command происходила постройка графика и его публикация в чат.

Первым делом я обратился к уже существующим решениям, графики через API Google, готовые гемы для Ruby. Основной минус в том, что не было возможности убрать или добавить легенду в том формате, который мне нужен, сложно кастомизировать внешний вид этих графиков и, к примеру, нет возможностей строить график по значению timestamp, а выводить уже значения в формате DateTime.

Имея на вооружении тот метод, который освещает эта статья, любой сможет строить какую угодно страницу полностью на сервере, получать фото этой страницы и использовать её в коде. В будущем можно приспособить этот подход для, например, для предпоказа тем на своем движке, генерации каких-то изображений с подвязкой к внешнему API и заключении всего в html документ. В целом, применений реально много, собственно поэтому и решил поделится solution'ом.

Поэтому предлагаю вам скорее ознакомится с материалом, мы научимся сначала делать график с использованием своего js скрипта, а потом поймём как его рендерить в коде.

Представляю содержание.

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

Всё, что кладёт прод, делает тебя умнее. © программист, положивший прод

Привет! Я — Женя, рубист из Каруны. В этой статье расскажу, как мы получили, на первый взгляд, тривиальную задачу по работе с индексами, набили кучу шишек и пришли к не очень тривиальному и эффективному решению.

Уже больше 20 лет я пишу код на разных языках программирования. Так как многие из этих языков считаются мертвыми, то сегодня я буду говорить о высоком искусстве некромантии — о том, как якобы мертвые языки используются в больших и иногда высоконагруженных проектах. Обрабатывая тысячи веб-запросов в секунду и не порождая необходимости писать свой компилятор PHP или переходить на Go или Rust.

Я расскажу про специфику Ruby и Python при высоких нагрузках, про их мейнстрим, который вы можете встретить в выживших проектах. Я не буду и не хочу говорить про спортивное программирование, где делают миллион запросов в секунду на одной ноде, выжигая из Python или Ruby всё и оставляя голый С. Python и Ruby действительно медленные, у них есть GIL, но при правильном использовании это не проблема, а статья расходов — и я расскажу, что мы можем получить за эти деньги.

Если вы предпочитаете слушать или смотреть (у меня там забавные крылья!) — видео моего выступления на конференции HighLoad++ Весна 2021.

Slack Ruby App. Часть 1. Написания приложения локально через Sinatra и ngrock

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

Сам я прошёл путь создания приложения по англоязычным бредням, вырваным кускам из Stack Overflow, и очень многих проб, ошибок, и исследований. Не имея понимания о том что можно сделать, как то сложно хотеть что-то делать.

Было бы круто если бы каждый умелый разраб (или не разраб) мог сделать приятно для коллектива или для себя любимого и добавить автоматизацию в свой один или несколько Slack Workspace

Так что я опишу этапы создания своего Slack бота для многих Workspace!

Я Ruby-программист. Язык почему-то теряет популярность, несмотря на своё интенсивное развитие. Лично я ему альтернатив [для себя] не вижу, поэтому готовясь к очередному собеседованию, решил составить шпаргалку с вопросами и ответами по Ruby. Шпаргалка за время подготовки превратилась в Android-приложение, которые я всегда хотел научиться делать, и о котором расскажу.

Дисклеймер: для профессионалов мобильной разработки в статье не будет ничего нового, это рассказ о том, как я столкнулся с разработкой под Android впервые в жизни.

Изучать Kotlin / Java я не стал. Близкий моему сердцу C# имеет технологию Xamarin, но, как пишут, у неё не всё так удобно в части создания интерфейсов, как хотелось бы. Поэтому было решено сделать шпаргалку на HTML / CSS, и обернуть в приложение с помощью Apache Cordova. В качестве CSS-фреймворка я рассматривал такие варианты: Bootstrap, Phonon, Framework7. Первые два показались неудобными, остановился на последнем.

Framework7 понравился тем, что ориентирован на создание мобильных интерфейсов (Android / iOS / своя тема Aurora), заявлена интеграция с Cordova, предлагает много разных виджетов, и обеспечивает высокий уровень контроля за функционалом с помощью JavaScript (поддерживает Vue.js и прочие, мне хватило старого доброго jQuery).

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

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

Кейс из жизни, когда удалось на порядки повысить производительность сервиса. Показываю на реальном примере, как можно искать "узкие места" в работающем, казалось бы, коде. И как много профита порой можно получить от минимальных правок. В данном случае весь фикс потребовал замены всего одной строки. Но самое интересное - эту строку найти...

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

• actions/cache — это популярное решение для кеширования гемов Ruby.
• ruby/setup-ruby — это решение, направленное на установку конкретной версии Ruby и на кеширование гемов Ruby с помощью бандлера. Фактически, речь идёт о двух возможностях одного «экшена» (того, что в терминологии GitHub Actions называется «action»).