ну просто я слышал что beam настолько крут что ставится на голое железо без ОС - и из коробки умеет hot reload и красивый deploy по на голову круче чем docker, который выглядет неуместным костылем на фоне этого - но я может быть что-то путаю

есть erlang on xen, вот там ос не нужна

https://youtu.be/OMPfEXIlTVE?t=8m8s

да, это оттуда скриншот )

пропустил двоеточие между consumer и secret -- исправил, не помогло добавил user-agent и content-length -- не помогло

пропустил двоеточие между consumer и secret -- исправил, не помогло добавил user-agent и content-length -- не помогло

сначала разберись как через курл сделать запрос

потом делай через руби

Ребят а какой хук мне использовать если я хочу после того как происходит апдейт объекта модели вызывать функцию которая тоже апдейтит один параметр?

Ребят а какой хук мне использовать если я хочу после того как происходит апдейт объекта модели вызывать функцию которая тоже апдейтит один параметр?

правый

Суть в том что все хуки на апдейт будут зацикливаться и на афтер сейв тоже

я бы был поосторожнее с хуками

можно зафигачить update_column(attr, val) - тогда коллбеки не срабатывают (и валидации) но вообще это стремная идея - обновлять поле после обновления - а зачем это надо по задаче? http://www.davidverhasselt.com/set-attributes-in-activerecord/

может мы кошерный способ подскажем

Ребят а какой хук мне использовать если я хочу после того как происходит апдейт объекта модели вызывать функцию которая тоже апдейтит один параметр?

как вариант, after_action :method_name, only: :update

Ну у меня есть рилейшн полицейский - район, и в копе поле дистрикт_айди, когда я обновляю его мне нужно чтобы поле копа сити_айди менялось на дистрикт.сити_айди

тогда можно проще и красивее

если сити_айди можно вытащить из дистрикта, надо ли его пихать отдельно в копа?

А как это в контроллере описать

Чтобы в апдейт полем сити_айди приходило дистрикт.сиди_айди

А как это в контроллере описать

сделать service object

пихать кучу логики в модель или контроллер ну так себе идея.

так так так

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

куда если не в неё?

Так получится сервис на одну строчку

сервисы?

сделать service object

это лучше всего будет

Так получится сервис на одну строчку

а тебе жалко?

больше сервисов богу сервисов

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

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

так значит по сервисам?

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

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

Модель не для бизнес логики, а для логики работы с бд или данными

Так получится сервис на одну строчку

ты там хук хочешь вызвать, не?

уже не одна строчка.

так значит по сервисам?

По изоливанным объектам, там много вариантов

Модель не для бизнес логики, а для логики работы с бд или данными

ну в реилс стайл гайде написано что бизнес логику туда пихать

ну в реилс стайл гайде написано что бизнес логику туда пихать

в рельсах minitest еще юзают.

Я могу просто написать апдейт атрибут в сервисе

Он тебе врал

ну в реилс стайл гайде написано что бизнес логику туда пихать

ну в реилс стайл гайде написано что бизнес логику туда пихать

burn it with fire)

потом у тебя будет god модель на которой весь сервис крутится

ну в реилс стайл гайде написано что бизнес логику туда пихать

Ну, потом у тебя будет модель на 2к строк, оно надо тебе?

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

модель данные хранит.

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

сделать сервис на каждый случай

проснуться не успеешь а у тебя уже модель на 1.5к срок) - реальная ситуация между прочим

ну в реилс стайл гайде написано что бизнес логику туда пихать

Ну короче, не слушай гайды рельсы. Они часто плохому учат в угоду easy

если получится то сделать один сервис на несколько ОЧЕНЬ похожих случаев.

где тогда лучше знаний нахватываться?

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

где тогда лучше знаний нахватываться?

в продакшене

т.е. изолированые сервисы под каждый кейс

по возможности да.

у нас в проекте сделали сервисы на создание модели. Не самый лучший выход, но лучше модели имхо.

а что не так? по-моему норм

у нас и на update есть отдельные

а что не так? по-моему норм

ну там потом начинаются теже проблемы как если бы ты в модели все это хранил.

Этот сервис начинает обрастать кучей условий и т.д.

на update отдельные да

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

он наследуется от create :)))

у нас в проекте сделали сервисы на создание модели. Не самый лучший выход, но лучше модели имхо.

Это называется command object

где тогда лучше знаний нахватываться?

Посты, книги, каналы

ERROR: S client not available

Это называется command object

в чем разница от service object?

в чем разница от service object?

Ох, там очень много граней. Это как интерактор, оперейшен, функциональный объект и сервис

Посты, книги, каналы

книги и каналы читаю, посты с каких форумов\блогов? читаю dev.to

книги и каналы читаю, посты с каких форумов\блогов? читаю dev.to

подпишись на ruby weekly

По сути команда - это такая штука, которая знает как сохранять, обновлять или удалять данные из базы

много годноты

пасиб

у меня правда с января накопилось рассылок уже. Все руки не дойдут их прочитать.

По сути команда - это такая штука, которая знает как сохранять, обновлять или удалять данные из базы

Ну типо оно не должно валидировать, или же вызывать левые штуки. По сути, этот объект делает все то, что метод save из рельсы + колбэки

чойто оно валидировать не должно

у нас оно вызывает форму-валидатор

который reform форма

хотя мне чото не очень подход такой нравится, кривовато оно у нас )

я бы выкинул реформ, с ним больше проблем. И попробовал Active Model

чойто оно валидировать не должно

Ну потому что валидация - это вообще другая логика, которая в моделе (по хорошему) не должна быть

ну по сути валидирует форма

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

валидации.

Потому валидировать надо данные которые из вне пришли, а не в моделе

Ну потому что валидация - это вообще другая логика, которая в моделе (по хорошему) не должна быть

так стоп а как же validate

Потому валидировать надо данные которые из вне пришли, а не в моделе

валидировать надо конечные данные

извините что в разговор больших ребят вклиниваюсь но просто хочу как можно больше из этого понять

извините что в разговор больших ребят вклиниваюсь но просто хочу как можно больше из этого понять

ой, большие ребята. Я на третьем проекте всего лишь работаю.

валидировать надо конечные данные

Не, зависит от того, что делаешь. Я пришёл к выводу, что для меня лучший вариант такой: Получить данные -> провалидировать -> трансформировать валидные -> сохранить

ну смотри, я трансформирую данные и проецирую их на будущую версию модели. Если все ок - сейв

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

а только если оно неправильно работает.

так стоп а как же validate

в маленьких приложениях норм в больших стало некомильфо - на каждый чих все выносим в отдельный класс с единственным назанчением - Single responsibility principle - тут и куча архитектурных решений вроде Service Object, From Object, etc...

так стоп а как же validate

https://t.me/pepegramming/35

в маленьких приложениях норм в больших стало некомильфо - на каждый чих все выносим в отдельный класс с единственным назанчением - Single responsibility principle - тут и куча архитектурных решений вроде Service Object, From Object, etc...

понял

ого клёвый канал спасибо

> Модель вмещает в себя много логики. Это мешает в тестах Про тесты жиза вообще