что вообще все запросы возвращают 200

у меня ~40 интеграций с партнерами 2-3 нормальных, остальные 200

— мы не получали — вот я вам отправлял, вот логи, вот время, вот payload — наверное ошибка, посмотрите, может вы что-то не правильно посылаете

но я просыпаюсь утром и мне кажется что мы в раю

отправь запрос любой рельсовой апишке - получишь 404 или 422 и расшифровку ошибки

луч света в темном царстве

я на свою апишку натравил activeresource а он возьми и заработай

1/2 работы сделана, я аж заплакал от счастья

Будет не скучно в поезде

termux?

когда себе ставлю 99% это оступы

Как узнал, ты же его отключаешь? А что мешает настроить код-стайл под проект? Другие коллеги тоже почти идеально пишут код? 1% полезных советов лишний?

Мешает то что настройка отнимет время а профита не принесет

так можно таскать настройку из проекта в проект

даже более того

https://github.com/SPBTV/spbtv_code_style

а еще полезно severity выставить

странно что в рубокопе этого по умолчанию не расставили

и превышение размера метода сразу идет в convention

а не в refactoring

ты тоже из ящика чтоли?

а зачем рефакторить, если можно сразу переписать при нарушении cop'a?

Привет все, подскажите как сделать валидацию поля url. К примеру если пользователь в поле ввел сайт без http:/ / то его нужно добавить

Я валидацию сделал

А вот как довлять не могу понять

а зачем рефакторить, если можно сразу переписать при нарушении cop'a?

вам шашечки или ехать?

Привет все, подскажите как сделать валидацию поля url. К примеру если пользователь в поле ввел сайт без http:/ / то его нужно добавить

before_save/before_validation callback

before_validation лучше не делать, потому что не очень хорошо когда валидация меняет данные

вам шашечки или ехать?

подход "коммитить плохой код, а потом рефакторить" более трудозатратен.

лучше исправление URL сделать на уровне контроллера

подход "коммитить плохой код, а потом рефакторить" более трудозатратен.

ага, плохой код при ошибке 11/10 method too long

ну никтож не заставляет оставлять дефолтные 10

началось торговля индульгенциями :)

мне тоже парочку пожалуйста

длинный метод хороший индикатор что там можно порефакторить

но не значит что там плохой код

такие дела

аналогичная хуйня с ABC-metrics

поэтому severity = refactor - это хороший компромис

ты тоже из ящика чтоли?

а то

сколько вас уже тут!

ojab: before_validation лучше не делать, потому что не очень хорошо когда валидация меняет данные Это я понял, а как добавить?

немного

Hpph

Http://

сколько вас уже тут!

трое вроде всего %)

ojab: before_validation лучше не делать, потому что не очень хорошо когда валидация меняет данные Это я понял, а как добавить?

self.site = "http://#{site}", очевидно

ой

termux?

Да

гуд А что за телефон Вроде дроид, какой-нибудь miui?

ojab: before_validation лучше не делать, потому что не очень хорошо когда валидация меняет данные Это я понял, а как добавить?

before_validation это не валидация меняет данные. Это до валидации выполняются действия. И если идет какая то обработка ничего страшного

before_validation это не валидация меняет данные. Это до валидации выполняются действия. И если идет какая то обработка ничего страшного

если валидация не прошла — объект должен оставаться неизменным

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

И последовательно в before_validation сбор не будет обрабатываться если данные в том виде, в котором нужны

wut

че ват

в бефор валидатион собираю поле из забитых полей, которое не указано в форме

нормально все с этим коллбеком

wtf "обработанный объект"?

wtf "сбор"?

ты зачем Дьячука включаешь

Есть модель

МОДЕЛ

У него есть аттрибут

ERROR: S client not available

допустим secret_field

в форме он не указывается но должен быть валидирован

и сохранен при создании

чем плох коллбек

зачем его валидировать, если мы его сами заполняем?

мы его не заполняем

а откуда он берётся?

ахахаха

он собирается и считается на основе например 3 введенных полей юзером

то есть мы его сами считаем

зачем его валидировать?

да

потому что не все сохраняется из формы

есть сиды, есть парс

есть куча бекграундов

где то можно пропустить

что мешает его поместить в before_save?

что мешает его поместить в before_validation?

то что в случае ошибки валидации мы получим не тот объект, который валидировали

это ок?

Мы валидируем аттрибут

и он должен быть заполнен до валидации

а в форме он заполнился или в коллбеке значения не имеет

он до валидации заполнился

ну ок

и если появится какой нибудь супер админ который МОЖЕТ это поле вводить ручками, то валидация будет кстати

и в before_validation return if attribute.present?

вот и все

любые поля которые пишешь в бд лучше валидировать

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

для фильтрация входящих данных есть strong params, непонятно зачем это проверять в валидации