sidekiq[17823]: /bin/bash: bundle: command not found # If you use rbenv: ExecStart=/bin/bash -lc 'bundle exec sidekiq -e production -C config/sidekiq.yml' ручками из консоли сайдкик стартует, почему через systemd не работает?

потому что из консоли у тебя настроено окружение rbenv

а systemd запускает либо под рутом либо под своим юзером

который окружения не имеет

для чего тогда этот коммент If you use rbenv?

Понятия не имею чей это коммент и что он имел ввиду

/home/deploy/.rbenv/bin/rbenv exec bundle exec ...

такую байду добавил - заработало

я сдурел

sidekiq запущенный через systemd ругается PG::ConnectionBad: fe_sendauth: no password supplied хотя я настроил RACK_ENV=production, из консоли запустить если сайдкик то все работает

В датабейс.ямл чего у тебя в проде?

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

настройки зависящие от переменных окружения

переменные окружения в .bashrc юзера деплой

ясно, перенесу в /etc/environment

хотя в systemd в sidekiq.service указан юзер deploy

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

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

юзер, пароль, база данных

Хост попробуй, тип локалхост

плюс дефолты - адаптер, кодировка, пул

Добавь

Постгре вроде без явного хоста даёт только в пир авторизацию

host: 127.0.0.1?

щас нагуглю

надо было EnvironmentFile=/etc/environment прописать

Вопрос: Может ли Elasticsearch возвращать highlighted query with sentences? Если да, то как его настроить как тут?

Хочу сделать такую папку, с исходными данными в JSON для некоторых таблиц загрузка запускает через таски где лучше расположить эту папку?

Похоже на seed

Люди как можно в coffeescript передать переменную что-бы вывести ее во вьюхе? Мне надо вывести количество элементов в массиве Localstorage

Всем доброго дня. Какой call back использовать чтобы он вызывался после создания и сохранения объекта?

Всем доброго дня. Какой call back использовать чтобы он вызывался после создания и сохранения объекта?

http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html after_commit

Можно ли указывать метод? on: :create например?

коллбеки не советуют юзать

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

Всем привет вопрос такой. Как грамотно деплоить nuxt.js и rails-api на nginx?

Как будет пониматься какие запросы идут на nuxt и идут на его роутинг? А какие запросы идут на api?

Можно ли указывать метод? on: :create например?

Можно, но есть after_create

И это чушь про то что колбеки юзать не надо. Не надо туда все без разбору кидать. А событийный функционал только в колбеки и должен идти.

ребят, использовал кто данный гем для спри: https://github.com/vinsol-spree-contrib/spree_product_subscriptions ?

И это чушь про то что колбеки юзать не надо. Не надо туда все без разбору кидать. А событийный функционал только в колбеки и должен идти.

Придёт время и каждый познает боль колбэков. Когда колбэк из модели А, что-то меняет в модели Б, далее каскадоно вызывается колбэк в Б, который вызывает В, а В рекурсивно меняет А...

Придёт время и каждый познает боль колбэков. Когда колбэк из модели А, что-то меняет в модели Б, далее каскадоно вызывается колбэк в Б, который вызывает В, а В рекурсивно меняет А...

>то это значит что имбецил написал, а колбэки тут не причем

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

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

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

"Делегаторы" не альтернатива. Альтернатива - интеракторы\команда\сервисы. Но тут минус - дублирование кода.

как считаете - нужно ли делать валидацию в form_object, если такая же валидация в модели?

делай form_object на ActiveType

его можно отнаследовать от модели, и он потянет в себя все связи и валидации

его можно отнаследовать от модели, и он потянет в себя все связи и валидации

спасибо, попробую

плюс колбеки нихуя не очевидно

ты в коде вызываешь - обж.саве() и оно такое хуяк хуяк творит чёто

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

имхо явная логика более проще в долгосрочной поддержке

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

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

и предвидит всё

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

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

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

эм... ну вхуяривать логику в сейв это даже ну коллбеки рядом не стоят)

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

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

Тут такая штука, много какой то воды, умных слов про интеракторы когда по факту фантазии, херь и отсутствие понимания взаимосвязи структур данных в событийной модели

Ну ещё умные статьи где говорят что "Х плохо"

Какие операции разнести если процессы должны происходить по факту изменения структуры ?

ну например ордер и после сохранения создать инвойс

не ебашишь в афтер_саве, а делаешь ордер.саве; InvoiceService.new(order).perform;

ERROR: S client not available

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

Если он должен пересоздаваться каждый раз после изменения ордера, ты будешь делать update а потом touch и свой метод вызывать ?

Или это будет феноменальный tap! с локальным объявлением измененных атрибутов и последующим вызовом твоего метода ?

В каждом месте где это должно происходить

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

с ними надо очень осторожно обращаться

Окей , ты обманул систему. Твой метод не просто делает save и ещё что то , а принимает аргументы которые пойдут в апдейт . Нам надо создать вызвать что то в заказе и сгенерить ордер @ Ой вей, ну что делать , расширяем метод ещё и этим

Какие операции разнести если процессы должны происходить по факту изменения структуры ?

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

проблем - если начинаются хитрые кондишены

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

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

для себя решил, что коллбэк ок - пока это просто коллбэк

если появляются вские if или on

тогда это надо вынести к чертям собачьим

это как-то и ближе к single responsibility, если коллбэк выполняется всегда, то это можно считать частью поведения объекта

если же он делает это опционально - значит кто-то другой должен решать, когда это сделать

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

так дело же не во мне, я выше писал что мнение по поводу коллбеков не единичное

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

если появляются вские if или on

да причем тут даже кондишены. если в принципе есть логика, которая общается с внешним миром тупейший пример из вчерашнего дня: делаешь интеграцию со страйпом, впиливаешь виджет страйпа в логин форму, а в User добавляешь before_create :create_stripe_customer

и типа вроде работает

фабрики в опездосе, тесты в развале, но чё, коллбек можно ж отключить в тестах

не, это слишком комплексная логика

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

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

хреновый пример

угу, почта – так себе

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

ну и то, “которые проще сохранить” – тут нужно чувство прекрасного иметь

В колбэках нормально добавить логирование, инициализацию дефолтных параметров и т.п.

чтобы не перестараться)

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

Ассоциации сами по себе часто зло)

Ассоциации сами по себе часто зло)

ммм, это уже перебор, ИМХО )