особенно со всякими if:

потому что они потом начинают противоречить новым фичам и в модель что то еще добавлять становится все сложнее.

особенно со всякими if:

никаких проблем не вижу со всякими if:

потому что они потом начинают противоречить новым фичам и в модель что то еще добавлять становится все сложнее.

это противоречие бизнес модели а не валидаций

зато я вижу, if: something, и так раз 5, и начинается пляска, как все эти if подружить с новым кейсом.

это противоречие бизнес модели а не валидаций

Не всегда.

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

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

так это общая проблема, а не проблема валидаций

чем больше кода, тем тяжелее править

Не совсем, в некоторых местах можно отключить ненужные валидации

просто это иногда проще когда в каждом месте приема/редактировании модели валидации свои.

чем подгонять одну модель под все кейсы.

потому что они потом начинают противоречить новым фичам и в модель что то еще добавлять становится все сложнее.

Как же я с тобой согласен. Господи.

чем подгонять одну модель под все кейсы.

это форм обджект против валидаций для разных состояний никто не выйграет

Алсо для валидаций давно юзаю dry-validation

добрый день. ребята, чем вы отслеживаете ошибки на продакшене??

Алсо для валидаций давно юзаю dry-validation

и в чем профит?

Они лучше стандартных + заметно легчает модель, если у валидаций сложная логика

добрый день. ребята, чем вы отслеживаете ошибки на продакшене??

rollbar

привет, у нас они в специальный канал в slack постятся, очень удобно

Они лучше стандартных + заметно легчает модель, если у валидаций сложная логика

не увидел

привет, у нас они в специальный канал в slack постятся, очень удобно

а с помощью чего реализовывали?

http://solnic.eu/2015/12/07/introducing-dry-validation.html статья старая, но в общем все также.

а с помощью чего реализовывали?

rollbar + slack integration

а с помощью чего реализовывали?

# Slack Exceptions gem 'exception_notification' gem 'slack-notifier'

вот кусок gemfile

ляпота

Антон @veldrin92 ясно, спасибо большое

ляпота

о, так даже круче

http://solnic.eu/2015/12/07/introducing-dry-validation.html статья старая, но в общем все также.

а в чем профит то?

давайте выучим новый DSL?

Статью прочитай

Статью прочитай

ну прочитал

по диагонали правда

там куча проблем описана которые выдуманы

1) информативность 2) больше возможностей 3) логика сложных валидаций уходит из моделей.

всмысле больше? другой язык чтоли? не руби?

3) форм обджекты

1) это что за зверь такой?

4) и животноводство

dry-v отлично заходит в форм обжекты

В общем попробуй dry-rb.com еще захочешь

dry-v отлично заходит в форм обжекты

ActiveModel::Validation отлично заходит в форм обжекты

В общем попробуй dry-rb.com еще захочешь

я не хочу учить новый DSL

не учи

Не учи

dry-* усложняет простые вещи увеличитвает стоимость поддержки проекта увеличивает время вхождения

dry-* упрощает сложные вещи уменьшает стоимость поддержи большого проекта уменьшает время вхождения в мелкие элементы большого проекта

+

dry-* упрощает сложные вещи уменьшает стоимость поддержи большого проекта уменьшает время вхождения в мелкие элементы большого проекта

ну вот ты берешь на работу человека которые не юзал dry-* кто будет платить за то что этот челвоек тратит время на вкуривание?

Вот ты береш человека на работу, который в глаза не видел твой проект. Кто будет платить за то что этот человек тратит время на вкуривание проекта?

Чот херовые аргументы

в руби можно упорядоченный массив перемешать?

Вот ты береш человека на работу, который в глаза не видел твой проект. Кто будет платить за то что этот человек тратит время на вкуривание проекта?

ну и ты еще увеличиваешь это время на dry-*

.shuffle ?

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

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

dry-* не стандарт

Только консерватизм, только хардкор

+

а что плохого в том, что я стандартными средствами делаю тоже самое и также драйно как в dry-validations?

Не используй гемы вообще кроме рельс. Слишком сложно всё.

Не используй гемы вообще кроме рельс. Слишком сложно всё.

давайте разберем проблемы 1) Validation logic lives in two layers, controller and persistence, you need to remember about both to properly validate parameters решили проблему теперь у нас два слоя, слой схемы и слой валидации упростили чтоли?

Давай не будем

Я просто поделился тем, что я использую этот гем

Давай не будем

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

ERROR: S client not available

Не хочешь использовать

Не используй

Все.

ну вот... чож все так сливаются быстро

Время дороже, сори

.shuffle ?

спасибо

> Антон Validation logic lives in two layers, controller and persistence, you need to remember about both to properly validate parameters решили проблему теперь у нас два слоя, слой схемы и слой валидации упростили чтоли? ШТА?!

ТА

ты не читатель что ли?

Два слоя это при использовании AM:V

ну я вижу что для разных состояний нужно будет две UserSchema создавать

Для разных валидаций? Ну логично

AM:V 1 слой второй имеется в виду в контроллере

Для разных валидаций? Ну логично

конечно логично, тогда в чем профит?

Профит в том что это именно валидация данных, не привязанная к персистентности

что это значит?

AM:V можео использовать без объекта AR

Какие валидации предпочитаете? ActiveModel Validation – 6 ??????? 50% Легко заюзаю любой вариант, я же не джун – 6 ??????? 50% Dry rb Validation ▫️ 0% Пишу свои костыли ▫️ 0% ? 12 people voted so far.

Пример: тебе приходит CSV файл. На, пускай, десять метров, который надо провалидировать и загрузить. И показать юзеру в каких строчках ошибки.

Как реализуешь?

все эти коллбэки и куча валидаций ведут к тому что основные модели становятся такими монструозными что их сложно обновлять.

разносить по сущностям?))

Как реализуешь?

lines.map { |line| object = object.create(line); object.valid? || object.errors }

бвахаха

разносить по сущностям?))

Они к одной сущности относятся

Часто бывает что в проекте есть большая модель вокруг которой все вертится

бвахаха

а что не так? :)

То есть для валидации ты будешь пытаться создавать объект?

Они к одной сущности относятся

ну это если примешать, а так то в разных)))

То есть для валидации ты будешь пытаться создавать объект?

ну это может быть не объект AR, это может быть AM:V объект

ватевар

object.errors? :)

и?