Ruby on Rails *

В началье статьи хочу сразу заметить, что я не претендую на новизну, а только хочу поделиться/напомнить о такой возможности как IoC DI.

Также у меня почти нет опыта написания статей, это моя первая. Я старался как мог, если что не судите строго.

О чем вообще речь

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

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

Далее в голове программиста складывается логичная цепочка, а зачем мне вообще выносить код бизнес логики в другой слой, я же тут всего пару строк добавлю и все будет соответствовать требованиям заказчика.

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

Для решения в подобных задач в мире Java уже давно существует ряд библиотек и нет особого смысла изобретать велосипед, хотя, надо заметить, что эти решения весьма громоздкие и не всегда есть причина их использовать. Рубисты видимо как-то иначе решают подобные задачи, но я, честно говоря, так и не понял как. По этому я решил поделиться как это решил сделать я.

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

Одна из основных концепций ActiveRecord состоит в том, что база данных достаточно утилитарна и может быть изменена. Ну, вы такие сидите, пишете свои модельки с использованием MySQL и вдруг где-то прочитали, что можно вот так вот взять и заменить MySQL на MongoDB. Хорошо, не так радикально, но, скажем, на PostgreSQL у вас могут быть причины заменить MySQL. Или наоборот, ничего не имею против MySQL. Тут ActiveRecord утверждает, что сделать вам это проще простого, мол скоупы, before/after фильтры и ассоциации достаточно абстрактны, чтобы не переживать за формирование запросов к базе данных и заботится о логике приложения. Что вместо WHERE is_archived = TRUE вы с радостью напишете where(is_archived: true) и ActiveRecord сделает все за вас. Все примеры будут преведены для PostgreSQL, а не для MySQL, так что пользователи MySQL вынуждены будут изобретать свой собственный велосипед.

Но как бы не так! На практике оказывается, что этот слой абстракции вся напрочь дырявая, как корыто из сказки о Золотой Рыбке. И что многие базовые возможности использовать нельзя, вроде сравнения дат или работы с массивами. И получаются скоупы с вынужденными where("#{quoted_table_name}.finished_at >= ?", Date.current) или where("#{quoted_table_name}.other_ids <@ ARRAY[?]", ids). На что ActiveRecord дает вполне осознанный и логичный ответ: не используйте это. Вместо массивов используйте habtm-связь, а если надо сравнивать даты, живите с этим. Да, и не дай бог вам пропустить quoted_table_name в таком скоупе — первый же includes или joins расставит все на свои места. Проще везде и всегда писать, чтобы руку не сбивать.

Что бы далеко не ходить, сразу определимся с терминами.

• Инкапсуляция — упаковка данных и функций в единый компонент.
• Сокрытие — представляет собой принцип проектирования, заключающийся в разграничении доступа различных частей программы к внутренним компонентам друг друга.

Взято с вики. В языке программирования Ruby с инкапсуляцией вроде как всё хорошо. С сокрытием на первый взгляд тоже, нам доступны локальные переменные, переменные инстансов, разные уровни доступа к методам (public, protected, private). Но иногда этого может не хватать.

Это история о том, почему вы никогда не должны замалчивать ошибки, когда вы внутри транзакции в базе данных. Узнайте, о том как правильно использовать транзакции и что делать, когда их использовать — не вариант. Спойлер: речь пойдёт об advisory locks в PostgreSQL!

Я работал над проектом, в котором пользователи могут импортировать большое количество тяжёлых сущностей (назовём их товарами — products) из внешнего сервиса в наше приложение. К каждому товару при этом загружается ещё больше разнообразных связанных с ним данных с внешних API. Нередка ситуация, когда пользователю нужно загрузить сотни товаров вместе со всеми-всеми зависимостями, в итоге импорт одного товара занимает ощутимое время (30-60 секунд), а весь процесс может порядочно так затянуться. Пользователю может надоесть ждать результата и у него есть право нажать кнопку «Отмена» в любой момент и приложение должно быть полезным с тем количеством товаров, которые удалось загрузить к этому моменту.

• в Москве,
• профессионал в Java, C# (.NET), Cloud, C++, Ruby on Rails, Test Automation
• или менеджер разработки, специализирующийся на SaaS, Java, QA, Ruby on Rails или C# (.NET)

Оффлайновые турниры Crossover — это глобальные мероприятия, которые проходят в один день по всему миру. Если вы читаете «Хабр» из Киева, Варшавы, Будапешта, Бухареста, Буэнос-Айреса, Стамбула или Сан-Паулу — это значит, что завтра мы проводим турниры и в ваших городах.

Всем привет! Мы открываем набор на бесплатные курсы обучения для Ruby и Frontend-разработчиков. Для участия необходимо пройти конкурс. Пять лучших выпускников пройдут стажировку у нас и останутся работать в офисе. Заявки на обучение принимаются по 17 июня включительно. Подробности набора и программа обучения – под катом.

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

Доброго… Решил поделиться с сообществом опытом интеграции Vue.js v2 и Ruby on Rails на примере разработки чата. Для этого нам потребуется реализация websocket в Rails — ActionCable.

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

Одна из особенностей мессенджера Telegram — широкие возможности API (Bot API и Telegram API). Команда Telegram пошла ещё дальше и выпустила библиотеку TDLib (Telegram Database Library), позволяющую разрабатывать альтернативные клиенты Telegram и не задумываться о низкоуровневых деталях реализации (работа с сетью, шифрование и локальное хранение данных).


TDLib работает на Android, iOS, Windows, macOS, Linux, Windows Phone, WebAssembly, watchOS, tvOS, Tizen, Cygwin и других *nix системах, а так же интегрируется с любым языком программирования, поддерживающим выполнение C-функций.

В этой статье мы рассмотрим использование TDLib в Ruby и создание gem'а для взаимодействия с JSON-интерфейсом библиотеки.

Ruby — очень сложный язык программирования. Он невероятно красивый и читабельный, однако у него есть множество тем и особенностей, которые могут оставаться "темным лесом" даже для опытного Ruby-разработчика. Одной из таких тем является поиск констант.

Несмотря на заголовок, гнева в посте не будет.

От переводчика: Давид Хейнемейер Ханссон написал небольшой текст о том, почему он и его команда Ruby on Rails разработала свой собственный Javascript фреймворк. Оригинал текста размещен в репозитории нового проекта

обновлено 4 февраля: оригинал статьи был официально опубликован в блоге Basecamp. Обновил ссылку на оригинал и название

Мы пишем много Javascript в Basecamp, но мы не используем его для создания "JavaScript-приложений" в современном смысле. Все наши приложения рендерят HTML на стороне сервера, затем мы добавляем вкрапления Javascript, чтобы оживить их.

Это путь величественного монолита. Basecamp работает на множестве платформ, включая нативные мобильные приложения, с единым набором контроллеров, представлений и моделей, созданных под Ruby on Rails. Иметь общий интерфейс, который обновляется из единого места, — это ключ к тому, чтобы маленькая команда работала хорошо, несмотря на множество поддерживаемых платформ.

Это позволяет нам быть продуктивными, как и в старые добрые времена. Возвращение к тем дням, когда единственный программист мог обеспечить немалый прогресс, не застревая в слоях абстракций распределенных систем. Время до того, как каждый стал думать, что святым граалем является ограничение серверной стороны до только лишь производства JSON для Javascript-приложений на клиенте.