Сейчас active model в чистом виде использует только ленивый, его плотно покрывают сервисами и формами

Колбэки, добавляющие неопределенности, цеетрализация логики в одном месте, в связи с этим отсутствие гибкости

Ещё про валидации забыл

Но тут надо разделять, АР паттерн или АР рельсы, потому что это разное

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

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

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

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

ну вот и можно же критиковать то, что он говорит, а не самого dhh?

ээээ... я не знаю как это делать ?

нууу типа смотришь подкаст и говоришь такой - вот на пятой минуте уважаемый автор несет чушь потому-то и потому-то)

ну если автор несет чушь, то автор несет чушь, не важно на какой минуте это и не плохо и не хорошо, это факт

Антон Давыдов уже наверное каждого рубиста убедил что несоблюдение DI - плохо, а dhh все упирается в колбеки и процедуры в контроллерах

dhh в моих глазах как люцифер, он пал, от него только имя осталось

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

это не конструктивная критика

Антон Давыдов уже наверное каждого рубиста убедил что несоблюдение DI - плохо, а dhh все упирается в колбеки и процедуры в контроллерах

А что такое DI?

это не конструктивная критика

ну у нас есть пророк, которому все поклонялись и на проповедях этого пророка создана инфраструктура какого конструктива не хватает?

ну у нас есть пророк, которому все поклонялись и на проповедях этого пророка создана инфраструктура какого конструктива не хватает?

чувак я не пророк

А что такое DI?

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%B8%D0%BD%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9

я думал вы мне как божеству поклоняетесь

тебя тогда еще не было, ты из сверхнового завета

мы не в том чате, сорян, я сворачиваюсь - все сказал

dhh в моих глазах как люцифер, он пал, от него только имя осталось

Вот кстати да. Я тут соглашусь

А что такое DI?

Dependency injection

а я думал он из солида ?

dhh в моих глазах как люцифер, он пал, от него только имя осталось

Мне даже кажется, что его проблема не в том, что он сделал, а сейчас не делает. Скорее проблема в том, что он застрял в 2010 году + лично мне не нравится, что вместо решения реальных проблем в рельсе - он наворачивает новый, никому не нужный функционал

active_job тому яркий пример

а я думал он из солида ?

Не, ты что. Это просто способ закинуть зависимости в функцию/объект/метод/что угодно

active_job тому яркий пример

Дв это уже старый примеряясь вот Active Storage шикарный пример

Кому это надо вообще? Какие проблемы оно решает?

Разве до этого файлы нельзя было аплоадить нормально?

Не, ты что. Это просто способ закинуть зависимости в функцию/объект/метод/что угодно

иннертность Dependency injection -> dependency inversion

Антон Давыдов уже наверное каждого рубиста убедил что несоблюдение DI - плохо, а dhh все упирается в колбеки и процедуры в контроллерах

Ну кстати, наверно только в контроллерах колбэки заходят. И то не все и не без мутаций. Всякие авторизации и прочее

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

никто и не парится

Вот не понимаю, почему коллбэки это плохо, если юзать их хорошо и в меру?

например?)

Ну кстати, наверно только в контроллерах колбэки заходят. И то не все и не без мутаций. Всякие авторизации и прочее

ну я так понял, что речь об ар колбэках, которые нужно выпилить с рельсы

Уточняю, ар колбеки, это обычные колбеки в модели?

да

Вот не понимаю, почему коллбэки это плохо, если юзать их хорошо и в меру?

1. Сложно тестировать, надо делать кучу данных, что бы все прошло 2. Не явность выполнения. Тут две проблемы, ты не уверен какой колбэков выполнится когда, вторая проблема: 3. Очень сложно все это дебажить

1. Сложно тестировать, надо делать кучу данных, что бы все прошло 2. Не явность выполнения. Тут две проблемы, ты не уверен какой колбэков выполнится когда, вторая проблема: 3. Очень сложно все это дебажить

Вообще, об этом уже столько говорили и писали, что проще в интернете найти информацию

и иногда эти колбэки работают ну вообще не так, как ты ожидаешь, что он отработает

ну это скорее ко 2 пункту Антона относится

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

Коллбэки это ведь как и оружие. Им можно пользоваться во вред, а можно и во имя добра.) Но это ведь не значит что нужно их запретить.

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

Ты можешь сделать нормальный метод save, сделать специальный объект, который сохранять будет как надо

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

Потому что тебе не придётся на каждый вызов метода save у модели думать что там произойдёт (что в коде, что в тестах)

это ещё без гемов, которые тащат свои колбеки

Особенно остро это встаёт, когда тебе надо слать емейл после создания юзера, но вот когда юзера делаешь в админке - слать ничего не надо

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

и иногда эти колбэки работают ну вообще не так, как ты ожидаешь, что он отработает

это проблема скорее не колбеков, а условности и явности их исполнения

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

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

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

ага, или как доп.условия по договору, о которых вы и не знали

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

Так можно и про любую другую плохую технику говорить. Например: goto это норм, если использовать нормально. Только никто никогда не использует это нормально

Аналогично с колбэками. Сколько видел проектов на рельсе, ни разу не видел проект без лапши колбэков в какой-нибудь user моделе

И дело не а том, что разработчики плохие/хорошие

Добрый день, у меня приложение на хероку. Веб сервер был пассажир, перешел на пуму, с переходом на пуму заметил некоторые странности в фоновых задачах. К примеру, у меня есть шедулер который каждый день тянет рейк задачу, так вот, выполняется задача и потом где-то теряется иногда, то есть не завершается. Подскажите пожалуйста, у кого какие мысли? пуму настраивал по мануалу в девцентре хероку

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

а можно подробнее?

например тоже самое происходит и с сукер панч

что делает шедулер?

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

Хм. Нет. Не согласен

Если инструмент позволяет отрезать себе палец

Ну например я использую коллбэки только если есть условие "всегда". Тоесть если мне независимо от места, где я провожу или буду проводить действие над объектом нужно выполнить какое-то допдействие всегда, я его заношу в коллбэки. Только в этом случае. Если там какае-то бизне-логика, выношу ее в интеракшн. И путаницы нет, и польза

И при этом создатель инструмента в инструкции рекомендует отрезать себе палец

То что-то тут не то )

Ну например я использую коллбэки только если есть условие "всегда". Тоесть если мне независимо от места, где я провожу или буду проводить действие над объектом нужно выполнить какое-то допдействие всегда, я его заношу в коллбэки. Только в этом случае. Если там какае-то бизне-логика, выношу ее в интеракшн. И путаницы нет, и польза

а че метод нельзя сделать?

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

Но для бизнес-логики я зарекся

Если хочется написать коллбэк - я бью себя по рукам, убиваю лень и пишу логику в другом месте

В зависимости от того, что эта логика должна делать

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

Можно взять какой-нибудь виспер или dry-events и на этом навернуть логику нотификаций. Она не будет в моделе и все будет в одном месте

что делает шедулер?

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

Можно взять какой-нибудь виспер или dry-events и на этом навернуть логику нотификаций. Она не будет в моделе и все будет в одном месте

Да, согласен

ага только это не логика модели что то куда то слать

Но зачастую это оверкилл

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

так, а при чем вэб сервер к рейк задаче?

так, а при чем вэб сервер к рейк задаче?

это стало происходить после смены веб сервера

ага только это не логика модели что то куда то слать

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

это стало происходить после смены веб сервера

ну, а логи есть какие-то?

И при этом создатель инструмента в инструкции рекомендует отрезать себе палец

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

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

Ведь коллбэками можно пользоваться и хорошо

Ну например я использую коллбэки только если есть условие "всегда". Тоесть если мне независимо от места, где я провожу или буду проводить действие над объектом нужно выполнить какое-то допдействие всегда, я его заношу в коллбэки. Только в этом случае. Если там какае-то бизне-логика, выношу ее в интеракшн. И путаницы нет, и польза

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

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

Про интерактор?

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

Active interaction. Gem. На практике я такого практически не делал, потому что очень редко нужно исполнять какуето-то бизне-логику "всегда". Но если есть необходимость, то можно засунуть ее в интеракшн и с коллбэка его вызывать

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

https://t.me/pepegramming/16

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

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

Active interaction. Gem. На практике я такого практически не делал, потому что очень редко нужно исполнять какуето-то бизне-логику "всегда". Но если есть необходимость, то можно засунуть ее в интеракшн и с коллбэка его вызывать

Вызывать интерактор из колбэка - это уже совсем перебор ?

https://t.me/pepegramming/16

так это не рельсы? или суть одна

так это не рельсы? или суть одна

Суть одна и та же

Какая разница то

Вызывать интерактор из колбэка - это уже совсем перебор ?

Да почему? Это только в случаях, где исполняется условие "всегда".

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

Да почему? Это только в случаях, где исполняется условие "всегда".

Ну а в тестах как это мокать будешь?