там определяется api, transport и.т.д.

в рельсе это обычно все завернуто через elasticsearch_proxy, кторое работает через модель

ок

буду разбираться

да

??

https://www.chewy.com/

)))

:D

https://habrastorage.org/webt/59/dd/d6/59ddd6467ea2f175840109.jpeg

@davydovanton а подскажи по архитектуре дра транзакций. допустим мне надо сделать create но там будут создавать 3 зависимые модели. post, comments, author например. как это лучше описать в шагах. или может это будут три транзакции обединенные в цепь?

я бы на самом деле посоветовал бы обернуть все в один метод (#call) а потом уже понять, что и как на шаги разбивать. что бы интерфейс выглядил как транзакция, можешь вот такую штуку заинклюдить в класс: include Dry::Matcher.for(:call, with: Dry::Matcher::EitherMatcher) тогда, если твой сервис будет возвращать either монаду, передавая с вызовом call блок - сможешь работать как с "транзакцией"

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

ну, я во всяком случае обычно так и делаю, если явно не знаю ничего

ааааа.... сложна!!!! то есть сначала сделать одну транзакцию со стандартными шагами(validate, persist итд) а потом уже будет видно? просто я не понял зачем там нужна Either монада, когда уже есть право и лево

https://gist.github.com/davydovanton/d8e9bd390b2f2e496a49011a7be32913

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

и переписать его на транзакции

+ у тебя тесты не поломаются, потому что интерфейс не поменяется

ну собственно. в чем беда обычно? не знаешь требований и не знаешь какой код напишешь. Плюс тебе проще разделять уже существующий код на какие-то шаги. Вот таким подходом ты: 1. сначала изолируешь логику в один объект с одним интерфейсом 2. написав логику, начинаешь разделять ее (интерфейс объекта основного не меняется) 3. когда какой-то шаг становится слишком большим (сам поймешь), изолируешь его в отдельный объект ... PROFIT

ну собственно. в чем беда обычно? не знаешь требований и не знаешь какой код напишешь. Плюс тебе проще разделять уже существующий код на какие-то шаги. Вот таким подходом ты: 1. сначала изолируешь логику в один объект с одним интерфейсом 2. написав логику, начинаешь разделять ее (интерфейс объекта основного не меняется) 3. когда какой-то шаг становится слишком большим (сам поймешь), изолируешь его в отдельный объект ... PROFIT

ок. спасибо. я сам так обычно и делаю. просто пока не понял как это сделать в рамках транзакция. ща поразбираюсь и пример посмотрю

Ребят, почему валидация рельсы в случае с uniqueness + scope не может смотрит уникальный индекс, а делает запрос в базу SomeModel Exists (0.3ms)

теперь сайдкик. например мне надо поднять один сайдкик с канкаренси 25 и другой с 15, это как нызвается в рамках сайдкика? как нагуглить?

теперь сайдкик. например мне надо поднять один сайдкик с канкаренси 25 и другой с 15, это как нызвается в рамках сайдкика? как нагуглить?

pool же

pool же

что то я не нашел такого

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

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

скорее всего.

сайдик думаю вполне себе аргументы принимает

нужно больше сайдкиков богу сайдкиков

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

что то я не нашел такого

https://github.com/laurynas/sidekiq-pool

серьезно? не нашел? :)

https://github.com/laurynas/sidekiq-pool

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

> я искал внутри документации

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

Ребят, почему валидация рельсы в случае с uniqueness + scope не может смотрит уникальный индекс, а делает запрос в базу SomeModel Exists (0.3ms)

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

grape-swagger + rails api mode выдает мне на страницу со сваг докумментацией просто жсон. что я делаю не так?

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

Ты можешь при старте процесса сайдкика указать файл с конфигом. И логично завести два независимый файла, для разных процессов сайдкика UPDATE В файле конфига уже управлять concurrency

Ребят, кто знает, как в Capfile получить значение environment, который передается при вызове CLI команды капистрано cap staging deploy? Т.е. в Capfile нужно понять staging или production передается параметром

fetch вроде

по крайней мере в сценариях он был насколько я помню

можно внутри сценария посмотреть где fetch определен.

Вроде stage если юзается capistrano/ext/multistage

спасибо, посмотрю

вот так вот еще можно: ARGV[0]

пацнацы

делали с эмбером чего?

не могу понять как наш фронт работает вообще

Да...а в чем вопрос?

не могу понять как наш фронт работает вообще

В чем вопрос?

Да чет не могу ща понять вообще как Эмбер работает

Типа на базовом уровне

Ну типа вот апи вот эмбер

Вот стукнулись получили джсон

Что дальше

дальше магия

Примерно так и я вижу

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

Документацию почитай, хз что ещё посоветовать ))

посоны, а pry работает в production?

лооооллл

а зачем?

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

забыл

пхах _)

а зачем?

Чтобы забыть его там и повесить сервак

ща нашел

он должен отключаться в проде

так-то

посоны, а pry работает в production?

Убери его из Production в геме

ну он должен быть в дев тест групе

Убери его из Production в геме

binding.pry будет работать?

если гем в общей группе, то остановится

лол ну короче в общей

ладно

иначе в проде нельзя было б дебажить

а без этого как жить-то

*табличка сарказм*

puts debugging

посоны, а pry работает в production?

если в гемах прода не присутствует - кинет эксепшон что не может binding.pry найти

в докере - binding.pry если не терминал напрямую то не отрабатывает

если в гемах прода не присутствует - кинет эксепшон что не может binding.pry найти

ну оно видимо просто в эту логическую ветку не заходило)))00))

выкидывает в отладочную сессию и сразу из нее выходит

но хер знает, может и зависнет

а

у нас докер

у меня в docker up оно показывало отладочную сессию и сразу заканчивало

а вот в docker run все как надо.

у нас докер

Звучит как приговор

Звучит как приговор

*диагноз

Или так, да

в докере - binding.pry если не терминал напрямую то не отрабатывает

а как ты это понял?

а как ты это понял?

запускаешь binding.pry в docker up

а потом в docker run