email = bill.user.try(:email) email ||= Setting['admin-email']

Какой смысл этого кода

Что-то туплю

@freecats email = bill.user.try(:email) - если у юзера есть эмейл - вернет его, иначе - nil email ||= Setting['admin-email'] - если email.nil? - присвоит какое-то дефолтное значение из конфига

если email не nil, то он пройдет далее, если nil, то email присвоится Setting['admin-email']

Спасибо

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

@freecats email = bill.user.try(:email) - если у юзера есть эмейл - вернет его, иначе - nil email ||= Setting['admin-email'] - если email.nil? - присвоит какое-то дефолтное значение из конфига

суть не в этом, а в том, что, если user сам nil, то не будет ошибки

@ialeksey это из-за try

я знаю :) но ты написал по-другому

ну я же выше написал, что try позволяет избавиться от лилшних провероку, типа: if bill.user && bill.user.email

что-то я не вижу, где ты это написал

а

я саму проверку не писал)))

но первоначально не совсем правильно было написано :)

ну если юзер не nil и мыло юзера не nil, то...

:enable_starttls_auto какие значения принимает в настройках smtp майлера? true, false?

У одного пользователя много счетов, у счета один пользователь. Как из объекта счета получить пользователя?

invoice.customer ищет в customer invoice_id

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

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

консистентность данных? зачем, есть же трай!

invoice.customer ищет в customer invoice_id

это плохо?

У меня has_many связь

В customer этого поля нет

customer has many invoices? invoice belongs to customer?

Да

должно работать перезагружал консоль? в трубу дул? форточка открыта?

выйди зайди

Перезагружали

Души

Дули

Открывали

Приходится юзать customer = Customer.find(invoice.customer_id)

Как-то должно же работать по другому

эту головоломку надо решить, иначе оно будет бить граблями

Покажи схему таблиц этих

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

>возьми себе на вооружение rescue , он позволяет избежать лишних ошибок

rescue => e ага

>возьми себе на вооружение rescue , он позволяет избежать лишних ошибок

лишние ошибки могут спасти много нервов и денег ? Конечно же лучше всего через rescue бросать исключения сразу куда-нить в роллбар/эйрбрейк/etc. Соглашусь в общем.

лишние ошибки могут спасти много нервов и денег ? Конечно же лучше всего через rescue бросать исключения сразу куда-нить в роллбар/эйрбрейк/etc. Соглашусь в общем.

У HB например ничего никуда бросать не надо, он в большинстве случаев сам вылетает на Exception и отправляет информацию

Bills это invoices

В коде тоже учтено

Сфоткай весь код сразу, чтобы была более полная картина

Модели

Код отправки

Где используется

Ошибка

Сфоткай весь код сразу, чтобы была более полная картина

И пластиковые карты, с cvv. Лишним не будет

Есть какие-нибудь мысли?

В коде тоже учтено

Тебя ни разу не смутило has_ в обоих моделях и ни одного belongs?

Точно

Спасибо

Решено

Решено

>еду в Гагры

Всем привет

мигрирую с 4 рельс на 5

после обновления выходит ошибка

ERROR: S client not available

в чем проблема может быть?

Всем привет, подскажите пожалуйста, есть hanami с graphql которые выступают как backend и есть фронт на react. Где лучше хранить мультиязычный текст ошибок? Если на фронте, то что лучше передавать с бэкенда на фронт если произошла ошибка: код ошибки или ключ в духе 'errors.email'? Может есть статьи на опыте как все это дело организовывать?

Всем привет, подскажите пожалуйста, есть hanami с graphql которые выступают как backend и есть фронт на react. Где лучше хранить мультиязычный текст ошибок? Если на фронте, то что лучше передавать с бэкенда на фронт если произошла ошибка: код ошибки или ключ в духе 'errors.email'? Может есть статьи на опыте как все это дело организовывать?

я прикручивал графкл к ханами, да

Всем привет, подскажите пожалуйста, есть hanami с graphql которые выступают как backend и есть фронт на react. Где лучше хранить мультиязычный текст ошибок? Если на фронте, то что лучше передавать с бэкенда на фронт если произошла ошибка: код ошибки или ключ в духе 'errors.email'? Может есть статьи на опыте как все это дело организовывать?

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

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

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

да не

ты больше времени потратишь на вкручивание локолизации в ханами + нормальную работу с пробросом локали с фронта на бэк

Всем привет. у меня такая проблема. есть модель User она sti делится на Student и TeamLead. так же есть связь многие ко многим с моделью Incident, для связи есть таблица incidents_users у которой 3 ключа student_id, team_lead_id, incident_id. И собственно проблема как сделать так чтобы при создание Incident, рельсы отправили все 3 ключа в incidents_users, сейчас отправляется только 2 ключа и все падает с ошибкой так как у всех полей null: false

зачем ты сделал sti с полиморфом, при этом влупил 3 разных ключа?

хотя да

я упоролся

Блин, недавно тут спрашивал по iptables. Решение нашлось, хз с чем связано, но авось кому поможет

iptables срать хотел на правило для специфического порта и протокола на ACCEPT

пока не было правила на ACCEPT просто по ip

выше в цепочке

я до сих пор не до конца понял, как я это пофиксил, но два дня позади, а фикс занял одну строку в iptables )

Очень плохо не понимать что-то в своем конфиге iptables

Может оказаться что ты просто дверь отрыл

Открыл, только для ip в приватной сети

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

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

Ну главное чтобы "приватная")

вообще я не до конца понимаю, в чём профит с этим iptables

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

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

чем усложнит жизнь iptables?

поясните нубу плиз

кроме кейса, с украденным ключом, там да, по идее усложнит

ты ж вроде напрямую не можешь подрубиться

вайт-блэк листы

Ojab