T
при желании и карандашом можно человека убить
голыми руками можно
Size: a a a
2019 October 16
ЧП
голыми руками можно
ну все, опять из дома не выходить
ЧП
дома безопаснее всего
MB
голыми руками можно
переполнением буфера даже можно
SP
дома безопаснее всего
интересно, а есть статистика где чаще умирают люди, в здании или на улице
Т
В больнице
DT
Коллеги, подскажите какой md5 модуль можно поюзать если в системе fips включен? чтото все гугление упирается в переход на sha но ищу какойто более простой путь (ruby 2.2)
O
Я же правильно понял, что dry-validation добавляет в dry-schema возможность добавить кастомные правила? Просто если нет, то чем они различаются? С моего уровня я не могу понять.
IM
В общем-то, в этом и задача, да
IM
dry-schema довольно тупа и занимается только валидацией данных и преобразование типов, а dry-validation ещё могёт в высокоуровневые бизнес-валидашки
O
dry-schema довольно тупа и занимается только валидацией данных и преобразование типов, а dry-validation ещё могёт в высокоуровневые бизнес-валидашки
О, спасибо.
IM
я пока не понял, как лучше эти бизнес-валидашки писать и использовать у себя
но понял, что если в проекте есть dry-validation, то лучше юзать его везде — даже где достаточно dry-schema
просто потому что делаешь один базовый класс для контракта, запихиваешь в него конфиг для проекта, и юзаешь повсюду
но понял, что если в проекте есть dry-validation, то лучше юзать его везде — даже где достаточно dry-schema
просто потому что делаешь один базовый класс для контракта, запихиваешь в него конфиг для проекта, и юзаешь повсюду
IM
там тебе и кастомные типы, и i18n, и ещё всякие настройки. а то бесит пару строк носить с собой из схемы в схему
AD
Я же правильно понял, что dry-validation добавляет в dry-schema возможность добавить кастомные правила? Просто если нет, то чем они различаются? С моего уровня я не могу понять.
Все так, да
O
я пока не понял, как лучше эти бизнес-валидашки писать и использовать у себя
но понял, что если в проекте есть dry-validation, то лучше юзать его везде — даже где достаточно dry-schema
просто потому что делаешь один базовый класс для контракта, запихиваешь в него конфиг для проекта, и юзаешь повсюду
но понял, что если в проекте есть dry-validation, то лучше юзать его везде — даже где достаточно dry-schema
просто потому что делаешь один базовый класс для контракта, запихиваешь в него конфиг для проекта, и юзаешь повсюду
Не понял про контракт.
С прикладной точки зрения - это базовая схема с
С теоретической - я не понимаю и иду читать про контрактное программирование.
С прикладной точки зрения - это базовая схема с
configure и методами для кастомных правил?С теоретической - я не понимаю и иду читать про контрактное программирование.
IM
Не понял про контракт.
С прикладной точки зрения - это базовая схема с
С теоретической - я не понимаю и иду читать про контрактное программирование.
С прикладной точки зрения - это базовая схема с
configure и методами для кастомных правил?С теоретической - я не понимаю и иду читать про контрактное программирование.
с теоретической не знаю, но с прикладной — да, я вот так и использую
O
Пасеба
IM
т.е. даже если мне нужно провалидировать схему, я просто использую контракт просто потому что написать
проще, чем таскать из раза в раз конфиг
class Schema < Dry::Schema::JSON
config.types = MyProject::TypeContainer
config.messages.namespace = :...
...
end
class Schema < MyProject::Contract
json do
..
end
end
проще, чем таскать из раза в раз конфиг
class Schema < Dry::Schema::JSON
config.types = MyProject::TypeContainer
config.messages.namespace = :...
...
end
Т
а есть типа мма но на мечах?
Да. Историческое фехтование называется