prefix = %w(office shoppingArea warehouse freeAppointment)[block.appointment_code + 1] cat = [prefix, type.capitalize].joins

так так такдавайте ещё

prefix = { 1 => "office", 2 => "shoppingArea", 3 => "warehouse", 4 => "freeAppointment" }[block.appointment_code] cat = "#{prefix}#{type.capitalize}" выриант выше, но для любителей хэшей и интерполяции

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

prefix = { 1 => "office", 2 => "shoppingArea", 3 => "warehouse", 4 => "freeAppointment" }[block.appointment_code] cat = "#{prefix}#{type.capitalize}" выриант выше, но для любителей хэшей и интерполяции

хэшик в константу положить и вообще отлично

http://npmplease.com/

какие у кого рюкзаки?

какие у кого рюкзаки?

Боби

ссылку?

какие у кого рюкзаки?

Фирма sriynka

https://www.xd-design.com/bobby

надо попробовать его украсть ?

надо попробовать его украсть ?

Вместе с хозяином?

просто пентест )

Xiaomi

Xiaomi

они уже и рюкзаки начали делать?

они уже и рюкзаки начали делать?

Ага, и еще много всего)

Кроме шуток - хороший рюкзак, и весьма не дорогой

я свой в капсуле покупал. там норм выбор

какие у кого рюкзаки?

Thule 15л

какие у кого рюкзаки?

разные) есть беговой, велосипедный, и просто большой

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

модули можешь писать и инклудить их

https://relishapp.com/rspec/rspec-core/v/3-7/docs/helper-methods/define-helper-methods-in-a-module

никто не сталкивался с такой проблемой: редис отвечает ошибкой SocketError: getaddrinfo: Name does not resolve

https://stackoverflow.com/questions/9654350/socketerror-getaddrinfo-name-or-service-not-known-sunspot-solr-rails-develo

да я много гуглил :(

https://relishapp.com/rspec/rspec-core/v/3-7/docs/helper-methods/define-helper-methods-in-a-module

спасиб!

никто не сталкивался с такой проблемой: редис отвечает ошибкой SocketError: getaddrinfo: Name does not resolve

это не редис отвечает, это твой код отвечает это в докере все или прям на машине?

это не редис отвечает, это твой код отвечает это в докере все или прям на машине?

в докере, я уже решил

ему не нравилось имя хоста, поменял на redis и все норм

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

как тестить приватные методы(send)? и надо ли?

как тестить приватные методы(send)? и надо ли?

send, не надо

если расписывать подробнее

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

имя хоста такое же как имя сервиса в docker-compose.yml

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

имя хоста такое же как имя сервиса в docker-compose.yml

ааа, вот в чем суть, я прям прозрел

send, не надо

ну я бы не был столь категоричен на счет "не надо". я обычно разделяю тесты, чтоб было проще

публичный метод покрыт 1-2 кейсами

можешь ковереджем покрыть чтобы видеть что код вызывался

а приватные тестирую на все edge cases

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

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

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

за send разве по рукам не хуярят?

схуяли?

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

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

потому что есть public_send

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

это совсем другой вопрос =)

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

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

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

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

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

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

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

так то юзать

а, ты про send

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

зависит от того, что ты делаешь

ну короче это нормальный инструмент языка

нет прямо 100 кейса, который всегда надо использовать

зависит от того, что ты делаешь

вот у меня совсем недавно был метод который превращает строки типа "1.1" или "v1.1" в "V1_1". это был приватный метод, на который я набросал 5-6 кейсов

ты его в одном месте юзаешь?

да

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

у меня для таких кейсов есть transproc

шойта?

который изолированно можно заинклюдить

и изолированно протестировать

https://github.com/solnic/transproc/

либа для трансформации данных

аа прикольно

функциональщина

ну

не совсем

просто штука для трансформации данных

Transform Ruby objects in functional style =)

ну я понял, хороший вариант да

ну и тогда у тебя логика трансформации данных будет в одном месте

и все довольны

ну

минусы тоже есть

ну для того случая я бы все равно такое не юзал. слишком много чести =)

например, надо это вызывать примерно так f(:func_name).call(something)

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

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

будет элементарно

у меня будет на это отдельный describe в тестах

и если я решу что-то вынести отдельно - я как раз этот describe и унесу

преждевременная оптимизация в виде миллиона классов-сервисов - тоже зло

так то можно и тесты для либ писать(на всякий случай)

это другое

Key is already in use - почему мне гитхаб такое пишет, когда я пытаюсь ссш ключ добавить? я его использовал только в гитлабе, но не в гитхабе

заговор гитлаба и гитхаба