но я бы xpath вообще не трогал. если это чистый селениум то driver.find_element(:css, '.product-man .product-name')[:title]

капибара

ой какая капибара

nokogiri

q

nokogiri

Аналогично: https://stackoverflow.com/questions/7107642/getting-attributes-value-in-nokogiri-to-extract-link-urls

ой спасибо!) счас попробую!

Аналогично: https://stackoverflow.com/questions/7107642/getting-attributes-value-in-nokogiri-to-extract-link-urls

Чтото у меня ругает на value

Чтото у меня ругает на value

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

category_page_links.xpath('//div[@class= "product-man"]/a[@class = "product-name"]/@title').first.value NoMethodError: undefined method `value' for nil:NilClass

category_page_links.xpath('//div[@class= "product-man"]/a[@class = "product-name"]/@title').first.value NoMethodError: undefined method `value' for nil:NilClass

Ниже пример, в комментариях

category_page_links.xpath('//div[@class= "product-man"]/a[@class = "product-name"]/@title').first.value NoMethodError: undefined method `value' for nil:NilClass

не нашло значит этот элемент

https://en.wikipedia.org/wiki/YaST написан на Ruby

https://en.wikipedia.org/wiki/YaST написан на Ruby

homebrew тоже написан на руби

и chef

Че это за назойливая хня?

Я хочу добавить возможность запуска на mri модульного рельс приложения(настроено под jruby) . Я вытащил все зависимости (бд и небольшой кусок джава кода), уже работает. Для каждого модуля были два гемспека под mri и jruby. В jruby он такой же, только добавлено s. platform ='java'. Босс говорит это важно) вопрос: чтобы на jruby ничего не поломалось имеет ли смысл добавить такой код в один гемспек: s. platform = 'java' if RUBY_ENGINE =='jruby'

Привет! А есть что-нить почитать, чтобы сделать верный выбор между return 1 или raise "ololo" ? Вопрос шире вопроса по языку, но в каждом языке есть свои предпочтени, инстурменты, традиции. Как дела с этим в Ruby?

Привет! А есть что-нить почитать, чтобы сделать верный выбор между return 1 или raise "ololo" ? Вопрос шире вопроса по языку, но в каждом языке есть свои предпочтени, инстурменты, традиции. Как дела с этим в Ruby?

в Ruby return 1 это явный путь к проблеммам. Потому что 0 и 1 это truly. Falsy только nil и false puts "Bam" if 0

Привет! А есть что-нить почитать, чтобы сделать верный выбор между return 1 или raise "ololo" ? Вопрос шире вопроса по языку, но в каждом языке есть свои предпочтени, инстурменты, традиции. Как дела с этим в Ruby?

Вообще рекомендовал бы вам начать с ruby koans а еще взять книжку well grounded rubist. David Black вы этим себе столько проблемм синмите. Что я вам говорю как человек набивший мозолей.

Привет! А есть что-нить почитать, чтобы сделать верный выбор между return 1 или raise "ololo" ? Вопрос шире вопроса по языку, но в каждом языке есть свои предпочтени, инстурменты, традиции. Как дела с этим в Ruby?

в чем суть то

Привет! А есть что-нить почитать, чтобы сделать верный выбор между return 1 или raise "ololo" ? Вопрос шире вопроса по языку, но в каждом языке есть свои предпочтени, инстурменты, традиции. Как дела с этим в Ruby?

1) в Ruby нет дихотомии на методы и свойства, как в C++ или JS ил PHP. Есть сообщения к объекту. 2) в Ruby нет операций языка. Есть сообщения обратаываемые методами для объекта. 2+2 => 2.+(2) 3) в Ruby 0 это truly Так что почитайте книжку Well Grounded Rubist (c) David Black с экономите много времени.

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

Спасибо за развёрнутый ответ!

Привет! А есть что-нить почитать, чтобы сделать верный выбор между return 1 или raise "ololo" ? Вопрос шире вопроса по языку, но в каждом языке есть свои предпочтени, инстурменты, традиции. Как дела с этим в Ruby?

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

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

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

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

Логика мешается, тестировать сложно

Есть шанс потерять эксепшен и уронить продакшен

Ну и ловля эксепшенов в руби прямо ОЧЕНЬ медленная

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

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

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

и тестировать такой метод еще сложнее

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

не согласен

Только «не могу дальше» и «не валидные данные» это разное

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

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

Railway обычный используешь и радуешься жизни. Благо есть просто дофига всего для имплементации его

Привет. Кто-нибудь знает, есть ли способ определить, что запись была создана внутри незакоммиченной транзакции?

Railway обычный используешь и радуешься жизни. Благо есть просто дофига всего для имплементации его

типа функция возвращает success или failure?

это и есть ad-hoc загрязнение логики

это и есть ad-hoc загрязнение логики

щитоуууу?

типа функция возвращает success или failure?

Скорее она возвращает объект со стейтом, в котором ещё данные хранятся

это и есть ad-hoc загрязнение логики

А подробнее?

Привет. Кто-нибудь знает, есть ли способ определить, что запись была создана внутри незакоммиченной транзакции?

тебе надо например внутри транзакции получить id созданного объекта? потому что если транзакция не закоммитися этот объект удалится

Скорее она возвращает объект со стейтом, в котором ещё данные хранятся

ну типа хэш и в нем стейт

ну типа хэш и в нем стейт

И?

ну суть в том что в итоге получается такой код def a result = method if result.status == 'ok' result.body elsif result.status == 'err' # something end end

ну суть в том что в итоге получается такой код def a result = method if result.status == 'ok' result.body elsif result.status == 'err' # something end end

Ты можешь воспользоваться case как минимум

вместо def a method rescue A # something rescue B # somthing else end

ну это синтаксический сахар

сути не меняет

ну суть в том что в итоге получается такой код def a result = method if result.status == 'ok' result.body elsif result.status == 'err' # something end end

Но в этом случае ты не завязываешься на логику работы бизнес логики (Сорян за тафтологию). Тебе достаточно соблюсти, что бы возвращался объект с нужным интерфейсом

К тому же, можно забить на ифы, если посмотреть на функциональщину и на нормальный railway

ERROR: S client not available

Даже в руби

на работу method ты имеешь в виду?

на работу method ты имеешь в виду?

Это не обязательно метод того же класса может быть

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

А вообще вот, ссылка #1

https://t.me/pepegramming/24

#2

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

в случае с той штукой, тебе надо будет знать какие ошибки бывают

что равнозначно

https://t.me/pepegramming/76

ок, потом гляну

что равнозначно

Нет, потому что видов твоих ошибок по любому больше будет, чем 1 интерфейс объекта. + ты по любому начнёшь АР эксепшены ловить и тут начнётся интересное. Где грань между контролем бизнес логики и вообще всего подряд?

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

реально валидации в контроллере удобнее и я не догоняю?

Нет, потому что видов твоих ошибок по любому больше будет, чем 1 интерфейс объекта. + ты по любому начнёшь АР эксепшены ловить и тут начнётся интересное. Где грань между контролем бизнес логики и вообще всего подряд?

Ну и у тебя пропадает такая штука как «единая точка выхода из логики» (придумал из головы термин), суть в том, что вместо завершения в одном месте и возвращения результата, твоя программа может упасть вообще где угодно. Это увеличивает издержки на поддержку, потому что приходится помнить что и где ловилось

Нет, потому что видов твоих ошибок по любому больше будет, чем 1 интерфейс объекта. + ты по любому начнёшь АР эксепшены ловить и тут начнётся интересное. Где грань между контролем бизнес логики и вообще всего подряд?

про АР я не понял

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

если валидаций много и они зависят от условий то удобнее вынести в форм обжект/сервис.

это да

но валидация базовая

реально валидации в контроллере удобнее и я не догоняю?

Ох, походу спор за контроль флоу пора заканчивать тоже. Просто это либо пережил, либо нет. Как валидации всего в моделе. Если по твоему вопросу отвечать, у тебя есть такой флоу: Пользователь запрос шлёт -> бизнес логика выполняется -> вызывается логика персистенс уровня (в базу положить). Что бы продукт было проще поддерживать, надо возвращать проблему как можно раньше. Те если юзер отправил не валидные данные - их желательно быстрее отдать ему обратно, а не тянуть до модели. Это просто рассуждения. На практике, валидируя в контроллере ты пишешь схему валидации сугубо под каждый вызов. А не одну здоровую схему с кучей условий в моделе

погодь, это да

но если валидация базовая

не зависит ни от чего

и всегда должна выполняться

то нафига её убирать из модели?

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