Как у тебя может не оказаться ключей?

Не вписал в файл / не передал в енв?

Ну значит ArgumentError при загрузке

Нет, проверяется Б, если нет его -- заглушка. Можно сократить, это просто мой кейс с почтой конкретный

Ясно. Ну это еще один подход.

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

Ибо места где это реально должно быть конфигурируемо - редки.

Класс который хранит глобальное состояние - это синглтон, и это антипаттерн.

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

http://stackoverflow.com/questions/12755539/why-is-singleton-considered-an-anti-pattern

Фабрика в том числе может создавать и инстансы класса

http://stackoverflow.com/questions/12755539/why-is-singleton-considered-an-anti-pattern

спасибо

Захотелось эксперементов. создал в корне руби прожекта файл tst.rb думаю сейчас с pry буду экспеременитрвать на хешах. А оно не летит. https://gist.github.com/lbvf50mobile/8b743a5b1b7a01bd479d6086b6391995

puts в конце добавь

вот тут вот все летало: https://gist.github.com/lbvf50mobile/24808c255e95549bd3d56ffac80caff7

puts в конце добавь

щас добалвю

puts в конце добавь

вот это да!

оно работает

puts в конце добавь

а почему?

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

там дальше в тонкости в ойдем

Потому что binding.pry останавливается на следующей инструкции после своего вызова

а следующая инструкция находится за пределами текущего scope

Гденибудь в kernel

Продолжаю борьбу с простынями за ruby way. Зача из большого массива параметров получить саб массив ключи которого начинаются с from. https://gist.github.com/lbvf50mobile/7ecf274d318fea1b80c700ccd3c55606/5e30019f29b396a9dcc7ff17e9fb3323351e608b#file-get_from-rb-L29

как это делается коротко?

hash.select { |k, v| k.to_s.start_with?('from_') }

Мне вчера дали массу советов, и про select и про map, Алекс предложил решение params.permit(:from, :blah).map(&:strip) . Загвоздка в том что надо же выберать по ключам, а вот select он как я понимаю работает с значенями хеша

hash.select { |k, v| k.to_s.start_with?('from_') }

гениально. спасибо

Мне вчера дали массу советов, и про select и про map, Алекс предложил решение params.permit(:from, :blah).map(&:strip) . Загвоздка в том что надо же выберать по ключам, а вот select он как я понимаю работает с значенями хеша

Ну так отфильтруй по ключам

ты из params должен выбрать все params которые ты разрешаешь

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

Ну так отфильтруй по ключам

такое ощущнече что я имею что то против))

и уже с ним работать.

Так ты фильтруешь через select а не permit

в permit ты жестко задаешь список ключей которы еразрешены и остальные отсекаешь

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

select не изменяет текущий массив а создает новй

то что изменяет текущий объект обычно заканчивается на !

ага точно, спасибо

например reject!

reject != reject!

hash.select { |k, v| k.to_s.start_with?('from_') }

1. Лучше не называть переменные 1 буквой 2. Неиспользуемые переменные лучше называть с `_`

|key, _val|

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

reject != reject!

это что значит?

а понял

функция reject != функции reject!

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

Почему?

Почему?

а зачем делать однострочник на полстраницы?

если и так очевидно что там делается

k, v это вполне очевидные названия.

а зачем делать однострочник на полстраницы?

Полстраницы?) ты наркоман?

|key, _val|

почему _val, а не _value?

k, v это вполне очевидные названия.

Вообще — да. Но есть такие вещи как приучение и дисциплина, а ещё эстетика, ну и конвенция в конце концов. Очевидность не теряем, а только увеличиваем

k, v это нормальная практика

именно k, v

А пихать принцип там где он мешает это плохая идея.

почему _val, а не _value?

value лучше, но val для меня минимально допустимое

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

А пихать принцип там где он мешает это плохая идея.

Не вижу чем мешает: улучшает читабельность

Читабельность k, v против key, value?

серьезно?

наоборот k,v повышают читабельность если однострочник длинный

1. key val может поместиться в строку (не 10 символов длина же) 2. Методы можно переносить: hash .select .reject

key val это ненужная расшифровка в даннм случае

просто своим размером оно ухудшает читабельность.

а почему key полностью, а val - обрезано? Несправедливость

просто своим размером оно ухудшает читабельность.

Не соглашусь. Anyway, это моё имхо, я не насаждаю, а просто аргументирую

ERROR: S client not available

а почему key полностью, а val - обрезано? Несправедливость

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

Например, так же несправедливо, что переходы и дверные проёмы строят без учёта роста 190+

несправедливо

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

value лучше, но val для меня минимально допустимое

А где ваш стайл-гайд можно почитать?

??

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

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

Зачем? в чем смысл расшифровывать очевидную вещь?

чтобы сделать код длиннее?

А где ваш стайл-гайд можно почитать?

Rubocop + Reek

чтобы сделать код длиннее?

Ещё очевиднее

Он теряет в читабельности от этой бесполезной очевидности.

Особенно если у тебя пара таких в цепочке.

Да используйте k+v, пожалуйста, я просто высказал своё мнение на основе опыта, как с Module.configure

Он теряет в читабельности от этой бесполезной очевидности.

Не согласен

configure заменить на c тоже норм вполне.

Особенно если у тебя пара таких в цепочке.

Перенос методов, писал выше

К тому же config в блоке configure не так страшен как длинные аргументы в однострочнике.

Rubocop + Reek

это не стайлгайд, к тому же ни rubocop, ни reek не ругаются на |k, v| в конфигурации по умолчанию.

К тому же config в блоке configure не так страшен как длинные аргументы в однострочнике.

+4 символа (5%) — как жить-то теперь, ага

+4 символа в первом блоке, +4 символа во втором блоке, и вот внезапно однострочник становится хуже читаемым.

это не стайлгайд, к тому же ни rubocop, ни reek не ругаются на |k, v| в конфигурации по умолчанию.

Уверен? Я не сам придумал, поверь) сейчас не у компа, потом могу проверить

Причем k, v обозначение понимают все, это нормальная практика.

Как раз reek вроде ругается

Так вот, смысл то в чем?

слепое следование правилам хуже чем их отсутствие.

+4 символа в первом блоке, +4 символа во втором блоке, и вот внезапно однострочник становится хуже читаемым.

Да перенеси его на вторую строку — это только улучшит читаемость, не городи анаконду

Уверен? Я не сам придумал, поверь) сейчас не у компа, потом могу проверить

https://gist.github.com/ojab/b475f1e1e00f86b4c741447bded32037

слепое следование правилам хуже чем их отсутствие.

Почему слепое? Читаемость

В чем читаемость то?

ты k, v не понимаешь что такое?

k, v читабельнее потому что короче.