А почему оно должно находить константу в области каллера? Метод инстанса это не лямбда.

а почему оно должно находить константу вообще? и если находит — почему не у коллера?

А каллер тут причем вообще?

ну тогда из так не получится

да, self.FOO не работает

А каллер тут причем вообще?

а константы в экземпляре класса при чём? экземпляр ищет метод экземпляра самый ближайший, в том числе caller'а. а константу — нет. обновил гист: https://gist.github.com/AlexWayfer/cf90f2bc18d69477899b8731ccdecc7b

да хватит мешать в кучу method lookup и constatant lookup это 2 разные темы

Я думал он по предкам гоняет

если уж сделали константу доступной из экземпляра класса (зачем?) — то почему логика с наследованием не такая же, как с методами инстанции? приходится дописывать self.class::

да хватит мешать в кучу method lookup и constatant lookup это 2 разные темы

ну вот да, похоже на то. но хотелось бы общей логики у них.

Ребят, я понимаю что мало ещё понимаю в рельсах, да да да надо купить ману, ну никто не поделится опытом, что делать если во вьюхах становиться слишком много логики... Куда вы не выносите обычно?

Ее*

курить*

Ребят, я понимаю что мало ещё понимаю в рельсах, да да да надо купить ману, ну никто не поделится опытом, что делать если во вьюхах становиться слишком много логики... Куда вы не выносите обычно?

какая у тебя там логика?

Я думал он по предкам гоняет

поиск метода именно в этом и заключается. смотрим на какой класс сылается наш объект -> ищем в этом классе метод -> идем в суперкласс -> ипродолжаем бродить по суперклассам пока не найдем метода

во вьюхах не должно быть логики

Ребят, я понимаю что мало ещё понимаю в рельсах, да да да надо купить ману, ну никто не поделится опытом, что делать если во вьюхах становиться слишком много логики... Куда вы не выносите обычно?

зависит от логики и архитектуры, но чаще всего ответ во view objects

Ну что то на подобии unless train.nil? Делать что то

в папку helpers

Ребят, я понимаю что мало ещё понимаю в рельсах, да да да надо купить ману, ну никто не поделится опытом, что делать если во вьюхах становиться слишком много логики... Куда вы не выносите обычно?

Вся логика в контроллере, во вьюхе только отображение этих данных

Если контроллер толстый - выносишь в сервис объекты например

Ну я снова чтьал что в контроллерах не должно быть логики тоже

Если контроллер толстый - выносишь в сервис объекты например

view objects же

Ну много

либо бей вьюху на партиалы, но следи за производительностью. Либо хелперы

Ну что то на подобии unless train.nil? Делать что то

чёт мне кажется, что это никуда не вынесешь

view objects же

А, декораторы самое главное да.

Посмотри на drapper

либо бей вьюху на партиалы, но следи за производительностью. Либо хелперы

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

Или вот мне надо было посчитать количество плацкартных вагонов

Ну тут просто нет универсального ответа.

Или вот мне надо было посчитать количество плацкартных вагонов

view objects определённо

Вьюха может быть толстой по разным причинам и надо код смотреть.

ну можно ещё контроллер или модель засорить

Вообще всю такую логику в контроллере надо делать

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

Вообще всю такую логику в контроллере надо делать

не-а(

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

да

Дя. Шаблоны не очень подходят

Ну окей, просто где не прочтёшь то везде говорят что контроллеры не должны иметь много логики

Типа это противоречит

Идее

но контроллер должен выполнять роль «получил данные — отдал данные — получил ответ — отобразил ответ», то есть не более 10 строк кода на action (можно приватные методы раздувать, но начинается мусор)

Ну окей, просто где не прочтёшь то везде говорят что контроллеры не должны иметь много логики

правильно, есть целый термин «fat controllers»

«разжёвыванием данных для view» занимаются как раз view objects. либо можно выносить это в модель / контроллер, но не очень хорошо

Контроллер может дернуть специальный класс который будет сложную логику считать

это нормально вполне.

условно говоря, ты отдаёшь view object экземпляры, она составляет Hash (или имеет публичные методы) _только_ нужных для view данных и скармливаешь её для view

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

Оба подхода одинаково хороми на мой взгляд.

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

Контроллер может дернуть специальный класс который будет сложную логику считать

это — да. всякие «сумма чисел из массива объектов» — уже не очень.

Но если дергать во вьюхе слишком много view object то можно потерять какие из них актуальны а какие нет.

в контроллере нагляднее видно зависимости.

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

он может из контроллера инициализироваться и скармливаться контроллером же вьюхе

Ну не просто может, должен имхо.

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

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

«модели» могут быть разными. в хороших приложениях у тебя есть модель для БД без логики. от неё несколько моделей наследуются с логикой, необходимой им (для разных случаев). если не ошибаюсь

ну или service objects и всё такое

Окей) просто главный вопрос который меня мучает

Куда девать логику

Уже который день, и нигде не нашёл где это описано

контроллер дёргает service object, который знает о моделях (доступ к БД) и содержит логику некоторую, возвращает ответ, ты его во view object, и view object в template примерно такой подход есть, если не путаю

чаще конечно встречается больше грязи. но, повозившись в грязи, начинаешь сам осознавать что зачем и почему

«логика приложения» просто правда размытое понятие, и оно в любом случае (кмк) размазывается по приложению. вот есть у тебя if в шаблоне. вроде бизнес-логика. однако выноси - не выноси — всё равно останется if. ну там партиал может быть, генерация, и т.д. и т.п., но if будет, разве что вёрстку из шаблона вытянешь куда-нибудь в рубишный код, что тоже нехорошо, имхо

а логика тип «получить вот эти модельки с такой фильтрацией в таком порядке» — это тоже бизнес-логика, но её уже точно не в шаблоне хранить. кто-то в модель методы пихает, кто-то в service objects, кто-то в контроллере. зависит от ситуации, опыта, взглядов и т.д.

Понял, ну самое простое для меня это конечно в контроллере

Раньше я засовывал все методы в application controller

Уже который день, и нигде не нашёл где это описано

кое-что стоит держать уме: если для компании %COMPANY_NAME% удобен инструмент %LIBRARY_NAME% — это не значит, что ты должен бежать его использовать в своём проекте. у всего есть контекст. то же с построением приложения. есть общие принципы, есть спорные и гибкие. не стоит находить какую-то компанию с каким-то проектом и пытаться у себя повторить в совершенно другом проекте их опыт.

ERROR: S client not available

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

Просто я знамаюсь рельсами по 7 часов в день и что то туплю блин )

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

Просто я знамаюсь рельсами по 7 часов в день и что то туплю блин )

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

Ну как бы, есть желание, и тяга к знаниям, интерес

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

Хотя мне кажется я никогда не устроюсь ROR разработчиком

Хотя мне кажется я никогда не устроюсь ROR разработчиком

с такой низкой уверенностью вполне вероятно, что нет.

?

Ну как бы, есть желание, и тяга к знаниям, интерес

ставь задачу и решай ее

желательно каждый день

Так и делаю, каждый день

привет! кто-нибудь сталкивался с такой проблемой при деплое на AWS EC2 через капистрано?

01 Git error: command git fetch --force --quiet --tags 01 'git://github.com/activeadmin/activeadmin.git' "refs/heads/*:refs/heads/*" in 01 directory 01 /var/www/easierlife.de/shared/bundle/ruby/2.3.0/cache/bundler/git/activeadmin-c24fcef949b2f1bbdf6b5a17650dcd86d73f2528 01 has failed. 01 If this error persists you could try removing the cache directory 01 '/var/www/easierlife.de/shared/bundle/ruby/2.3.0/cache/bundler/git/activeadmin-c24fcef949b2f1bbdf6b5a17650dcd86d73f2528'

удалял этот несчастный “activeadmin-c24fcef949b2f1bbdf6b5a17650dcd86d73f2528”. выдает “не могу найти эту директорию” -.-

Дамы и господа, в этом чате есть рубисты?

А есть ли поклонники языка Crystal, мне интересно?

Дамы и господа, в этом чате есть рубисты?

чистяков, ты наркоман?

Нет

Я просто издалека начал

Наркоманы вот:

If you want to contribute then you might want to install Crystal from sources. But Crystal is written in Crystal itself! So you first need to use one of the previous described methods to have a running compiler.

Что мы знаем о рекурсии?

Вот, сука

Попробуйте забутстрапить кристал на платформе, где его никогда не было

Давай, теперь расскажи как скомпилить C компилятор без C компилятора.

Вопрос же не в этом

Вопрос в том, что у Crystal отсутствует повторяемость сборки

Сначала это был просто gem

Который сам себя не бутстрапил

А потом - фигак

Ты предлагаешь писать tiny-crystal чтобы формально верифицировать что с crystal все ок?