это railway?

это railway?

это обработка результата railway

вот про такое https://github.com/davydovanton/cookie_box/blob/master/lib/decks/operations/create.rb#L16-L19

сам railway вот тут

сам railway вот тут

ну, а если в месте, которое вызывает эту операцию (например другая операция), надо знать как именно зафейлились? тогда блок Failure обрастет кучей ифов или большим кейсом

ну, а если в месте, которое вызывает эту операцию (например другая операция), надо знать как именно зафейлились? тогда блок Failure обрастет кучей ифов или большим кейсом

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

Что делает метод сюрреализировать?

Что делает метод сюрреализировать?

https://github.com/nesaulov/surrealist

Прикольно

удобная штука, я из него сделал отличные презентеры

только там мелкий баг есть, который поправить было бы круто

Прост раньше до руби 2.0 jruby попроизводительней была

в 12 раз шустрее

ждите 2.6

в 12 раз шустрее

ого

шутка же такая была

а шо за шутка?

типа руби 3 будет в 3 раза быстрее,но все еще в 4 раза медленнее jruby

аа

только там мелкий баг есть, который поправить было бы круто

что за баг?

что за баг?

https://github.com/nesaulov/surrealist/issues/114

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

выглядит хорошо, но по-моему это идентично хэндлингу эксепшенов. я бы наверное вместо метода save_user_from_url создал бы объект, который бы подтягивал сам что надо и хэндлил бы эксепшены, например, сохраняя в свой аррэй @errors. Далее у этого объекта бы проверял были ли ошибки и какие. Ну примерно

стой погодь

выглядит хорошо, но по-моему это идентично хэндлингу эксепшенов. я бы наверное вместо метода save_user_from_url создал бы объект, который бы подтягивал сам что надо и хэндлил бы эксепшены, например, сохраняя в свой аррэй @errors. Далее у этого объекта бы проверял были ли ошибки и какие. Ну примерно

не, это разные штуки идеологически, хотя похожи по коду

выглядит хорошо, но по-моему это идентично хэндлингу эксепшенов. я бы наверное вместо метода save_user_from_url создал бы объект, который бы подтягивал сам что надо и хэндлил бы эксепшены, например, сохраняя в свой аррэй @errors. Далее у этого объекта бы проверял были ли ошибки и какие. Ну примерно

ну например у этого object был бы метод perform, где например както вызывались бы приватные методы, которые могли бы вызвать эксепшен. дальше в perform стоял бы например rescue => err, а внутри блока @error = err

и так мы ни один эксепшен не упустили к юзеру

сразу прервали выполнение где пошло не так

имеем полное описание того что пошло не так + стактрейс

который можно залогировать напоимер

вот. я не знаю что можно сказать против такого подхода

не, это разные штуки идеологически, хотя похожи по коду

моя идеология - ооп)

моя идеология - ооп)

так как раз это ближе к ооп, чем кидать эксепшены

ну что я предложил - не ооп?

который можно залогировать напоимер

так ты можешь сделать тоже самое и тут

ну что я предложил - не ооп?

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

и ловить все это дело

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

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

так при этом ты мешаешь логику между

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

почему? вот обьект, он фетчит юзера. это у него либо получилось, либо нет

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

не обязательно

почему? вот обьект, он фетчит юзера. это у него либо получилось, либо нет

да, почему бы не оборачивать результат в нормальные абстракции? а не юзать тут ошибки

это из разряда использования try в коде

ты можешь if object.success? object.payload else object.error_messages end

в месте где надо зафетчить юзера например

не понял к чему пример

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

к этому

ну то есть тот кто вызывает

не обязан знать ошибки того класса

не, ты не понял

не обязан знать ошибки того класса

как раз обязан в эксепшен флоу

потому что ты вызываешь, ты и ловишь

в моем варианте нет

ты внутри себя можешь конечно контроллировать их

и это нормально

как раз обязан в эксепшен флоу

глянь выше, они в переменную инстанса засовываются

и дальше можно def ok? @error.nil? end к примеру

def error_message @error.message end

как раз обязан в эксепшен флоу

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

наверное

я еще пока не пришел к однозначному мнению

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

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

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

а зачем их кидать, если можно без них?

типа resorce = UserResource.new('http://...') resource.fetch if resource.fetched? resource.payload else resource.error_message

а зачем их кидать, если можно без них?

как без них и без статуса в методе контролировать флоу?

типа resorce = UserResource.new('http://...') resource.fetch if resource.fetched? resource.payload else resource.error_message

даже так: raise resource.error_message чтобы и из того места сразу ливнуть

#вакансия #backend #ruby #go #офис #москва м.Бауманская, полная занятость Белая з/п до 180.000 руб. на руки (компенсация проезда и материальная помощь для переезда иногородним). Middle/Senior Ruby on Rails/Go developer Описание вакансии: Мы — команда разработки Level.Travel, сложного продукта в сфере путешествий. За последние пять лет мы с нуля создали и продолжаем развивать решение для онлайн-продажи путешествий. Сегодня половина российскиих туроператоров работает на основе наших технических регламентов. Ядро нашей компании — GDS-система для поиска и бронирования пакетных туров. Нашу платформу используют лидеры рынка – Яндекс (сервис «Яндекс.Путешествия» полностью построен на ней), TripAdvisor, Kayak, АК Барс Банк, Евросеть, OneTwoTrip и многие другие. Level.Travel является резидентом Инновационного центра «Сколково». По задачам: Разработка серверных приложений на Ruby on Rails; Разработка API; Покрытие кода тестами; Разработка микросервисов на Go. От нас: белая зп, официальное трудоустройство, больничные, отпуска. Помимо оклада есть бонусная система по результатам проектов. Оплата 50% стоимости посещений профессиональных форумов. Ну и еще у нас много возможностей дешево путешествовать)

ERROR: S client not available

даже так: raise resource.error_message чтобы и из того места сразу ливнуть

Вообще, почитай ссылки с канала моего

#вакансия #backend #ruby #go #офис #москва м.Бауманская, полная занятость Белая з/п до 180.000 руб. на руки (компенсация проезда и материальная помощь для переезда иногородним). Middle/Senior Ruby on Rails/Go developer Описание вакансии: Мы — команда разработки Level.Travel, сложного продукта в сфере путешествий. За последние пять лет мы с нуля создали и продолжаем развивать решение для онлайн-продажи путешествий. Сегодня половина российскиих туроператоров работает на основе наших технических регламентов. Ядро нашей компании — GDS-система для поиска и бронирования пакетных туров. Нашу платформу используют лидеры рынка – Яндекс (сервис «Яндекс.Путешествия» полностью построен на ней), TripAdvisor, Kayak, АК Барс Банк, Евросеть, OneTwoTrip и многие другие. Level.Travel является резидентом Инновационного центра «Сколково». По задачам: Разработка серверных приложений на Ruby on Rails; Разработка API; Покрытие кода тестами; Разработка микросервисов на Go. От нас: белая зп, официальное трудоустройство, больничные, отпуска. Помимо оклада есть бонусная система по результатам проектов. Оплата 50% стоимости посещений профессиональных форумов. Ну и еще у нас много возможностей дешево путешествовать)

А переезжать-то в какую страну/город?)

А, Москва. Понятно

Москва да

default city на то и default city чтоб не спрашивали ))

А default country что тогда?)

А default country что тогда?)

Россия

Может я вообще из Африки и не знаю где находится город Москва ?

В России смысле

А default country что тогда?)

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

В Африке тоже на русском говорят)

Иногда

Ну ладно, холодно у вас... Ташкентское солнце морально не готова променять

Есть ли подводные камни у этого? Foo.call(params: 'baz') ведь лучше чем Foo.new(params: 'baz').call class Foo def self.call(params:) new(params: params).call end def initialize(params:) @bar = params end def call @bar end end

Ну ладно, холодно у вас... Ташкентское солнце морально не готова променять

даже на вашингтонское?)

Есть ли подводные камни у этого? Foo.call(params: 'baz') ведь лучше чем Foo.new(params: 'baz').call class Foo def self.call(params:) new(params: params).call end def initialize(params:) @bar = params end def call @bar end end

поздравляю, ты изобрел callable object

Есть ли подводные камни у этого? Foo.call(params: 'baz') ведь лучше чем Foo.new(params: 'baz').call class Foo def self.call(params:) new(params: params).call end def initialize(params:) @bar = params end def call @bar end end

не, что то, что то не очень

не, что то, что то не очень

а что не так?

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

Есть ли подводные камни у этого? Foo.call(params: 'baz') ведь лучше чем Foo.new(params: 'baz').call class Foo def self.call(params:) new(params: params).call end def initialize(params:) @bar = params end def call @bar end end

поэтому выбор андеграуда: Foo.new(dependencies).call(params)

яснопонятно, спасибо (:

да, тоже считаю что лучше аля Foo.new.call(params)

я делаю как раз через self.call

который просто прокся к initialize

обычно мои сервис объекты не принимают параметров в сам call

то есть нет такого Foo.new(dependencies).call(params)

а есть просто Foo.new(dependencies_and_params).call

а есть просто Foo.new(dependencies_and_params).call

ну и ты каждый раз инициализируешь объект один и тот же?

а теперь представь, что ты можешь инициализировать объект со всеми зависимостями 1 раз за время жизни приложения и просто вызывать call с параметрами

мне обычно такое не надо

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

ну если такое и понадобится - то тогда можно сделать исключение