как раз по блоксхеме

одно и тоже в if и elsif

блин

точно)

это раз. второе - можно вынести условие в отдельный метод, если возможно как-то адекватно его назвать

и сократить до: data = method? ? calculate_delivery(address.distance, setting) : 0

но тернарки - это вкусовщина, ИМХО ) мне такие простенькие тернарки нравятся

лучше не использовать def data @data = ... end

но видел людей, у которых жёстко пылает от тернарных операторов

@data ||= и обращаться к ней как data везде

@data ||= ок, пока нам не понадобится присвоить nil

понял, большое спасибо за отзыв)

сомнительно что calculate_delivery возвращает nil

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

решил заранее обозначить )

я бы написал как-нибудь так: def delivery_cost sum = checked_params[:sum] return 0 if free_delivery?(sum, setting, address) calculate_delivery(address.distance, setting) end def free_delivery? sum, setting, address sum < setting.st_order_min_sum && address.distance < 40_000 end

я бы написал как-нибудь так: def delivery_cost sum = checked_params[:sum] return 0 if free_delivery?(sum, setting, address) calculate_delivery(address.distance, setting) end def free_delivery? sum, setting, address sum < setting.st_order_min_sum && address.distance < 40_000 end

выглядит непонятнее чем изначальный вариант

ну, на вкус и цвет все карандаши разные ) мне так намного понятнее, что происходит: в первом методе мы сразу видим, что цена 0, если соблюдено условие бесплатной доставки, а если нет, то используется какая-то формула расчета. а во 2-м методе вычисляется условие, по которому доставка будет бесплатной. если добавятся новые условия для беспл. доставки, то их будет так удобнее добавлять в отдельный метод.

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

что мешает эти условия в calculate_delivery перенести?

Ojab, все верно, я уже переписываю нормально, занесу условия в метод

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

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

давай

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

Например проектирование стоит Х денег. Если бизнес теряет при возникновании ошибки 10Х он сразу соглашается

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

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

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

закон Мерфи же )

Не соглашусь. Каждый риск можно оцифровать. Именно на этом строиться банковский бизнес

Собственно задача бизнеса в том и заключается что бы балансировать риски. Число рисков в стартующем проекте всегда больше, чем сил проекта по закрытию этих рисков. И тут речь не только о кривом проектировании ПО, но и о принимаемых бизнес-решениях, глубине проработки договоров итд.

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

Правда в том, что бы находить баланс

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

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

если что-то сложное, то лучше попробовать какой-нибудь валидатор типа dry-validation приделать

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

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

там когда от REST уходишь всякие косяки вылезают

он не слишком гибкий

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

а мне хочется пачкой деревья категорй создавать

Чем strong parameters не устроили?

strong params не умеет гибкую валидацию

где там какая-то гибкая валидация?

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

я хз что делает check_params, например

в примере ее нет, но если пишется api, то скорее всего рано или поздно она понадобится

...и откдуда уверенность что check_params что-то из этого делает?

а человек совета просил

и я посоветовал grape )

вместо check_params

Валидацию куда нибудь в before_action бы убрать. Бизнес логику завернуть в сервис

Вызов одного метода в сервис завернуть?

вызов сервиса в сервис не надо заворачивать, надеюсь?

вызов сервиса в сервис не надо заворачивать, надеюсь?

куда ж без этого

Почему одного метода? Там три строки как минимум

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

в контроллерах не должно быть никакой логики. только вызовы команд (сервисов) и что рендерить

а мне хочется пачкой деревья категорй создавать

а что мешает json в параметрах передавать?

или hash

Фраза "не должны быть" на самом деле плохо воспринимается. И всегда есть исключения. Я обычно привожу такой пример. Иногда нужно делать одинаковые вещи, и при сетевом запросе, и по крону. Т.е. есть событие и действие. Контроллер - это триггер на http события. Действие должно быть вынесно в сервис, что бы иметь возможность его совершать в том числе и по событию из крона или любого другого источника

а что мешает json в параметрах передавать?

валидировать надо

a grape entity не хочет нормально работать с рекурсивной структурой

а руками - влом

А grape - ещё год назад был той ещё пакостью. То утечки, то сломают чего с обновлением

ERROR: S client not available

а не надо его обновлять )

работает - не трогай

валидировать надо

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

Так вот одно время память утекала, обновили, сломалось в другом месте )

там особенно генератор документации для свагера крутой — просто песня

Сейчас может grape стабилизировали, но трогать его уже боюсь

я хоте одну фичу туда вкрутить, так я просто сделал форк и все переписал

по-другому там просто никак

аж трисет как вспомню

уже второй проект на грейпе делаю. До этого был trailblazer - монстроуозная вещь

я хоте одну фичу туда вкрутить, так я просто сделал форк и все переписал

без PR?

так трейлблейзер это не о том

так трейлблейзер это не о том

дайте базз-вордами покидаться)

без PR?

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

и это про PR не нужно мне тут намеков

и это про PR не нужно мне тут намеков

каких намёков?

что типа нужно было контрибьютить

так трейлблейзер это не о том

согласен. это надстройка над рельсами.

согласен. это надстройка над рельсами.

не только над рельсами

что типа нужно было контрибьютить

не, мне просто интересно, как поступил и почему. не принуждаю и не подбиваю

не, мне просто интересно, как поступил и почему. не принуждаю и не подбиваю

ну ок :)

У ActiveRecord есть сериализованные поля, если использовать JSON, то по умолчанию ключи не будет превращаться в символы. Такое решение велосипед или имеет права на существование? https://gist.github.com/ZurgInq/f135c31625a9d409d4e0c9f58f61a041 Возможно есть штатный способ без костылей?

Всем привет! В связке React + Rails API не совсем понимаю, как обрабатывать результат коллбека аутентификации через oauth2: клиент обращается к рельсам, которые его перенаправляют при помощи джема omniauth-oauth2 на сторонний ресурс, после аутентификации внешний ресурс перенаправляет клиента на страницу коллбэка. После этого шага, как мне правильно поступать: осуществить редирект с рельс обратно на клиента и в урл указать, например, токен?

https://developers.google.com/identity/sign-in/web/reference

получай id_token и обрабатывай его через api к своему бекенду

omniauth-oauth2 тут нафиг не нужен

https://developers.google.com/identity/sign-in/web/backend-auth

^правильная ссылка

Спасибо, сейчас изучу.

У ActiveRecord есть сериализованные поля, если использовать JSON, то по умолчанию ключи не будет превращаться в символы. Такое решение велосипед или имеет права на существование? https://gist.github.com/ZurgInq/f135c31625a9d409d4e0c9f58f61a041 Возможно есть штатный способ без костылей?

штатный способ без костылей, для начала — использовать в базе для храниния json тип json[b], а не строки

Подскажите, как сделать includes со скоупом / условием для заинклуженных ассоциаций?