Привет! Mail.ru ищет спикеров по курсу вебинаров по Ruby и RoR. Удаленно, в свободном графике. ЗП 15000 руб. Пишите кому интересно l.karamysheva@corp.mail.ru

ээээ.... я ещё не проснулся или там только 3 нулика?

а, спикеров...

тьфу

Привет! Mail.ru ищет спикеров по курсу вебинаров по Ruby и RoR. Удаленно, в свободном графике. ЗП 15000 руб. Пишите кому интересно l.karamysheva@corp.mail.ru

Mail.ru заинтересован только в проведении вебинаров или целится на найм рубистов?

render json: Hash[TpPleaReg::DETAL_TYPES.map { |t| [t[0], t[2]] if t[1] == type_id } ].to_json что тут не так?

warning: wrong element type nil at 3 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release warning: wrong element type nil at 4 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release

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

Забыл написать: Тестирую метод b в классе A (A#b), который внутри вызывает приватный метод A#c, и в тестах мне нужно убедиться, что он вызывает его один раз. Боюсь, с помощью прокси такого не сделаю

warning: wrong element type nil at 3 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release warning: wrong element type nil at 4 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release

Ну, первое у тебя про то, что внутри блока иногда nil (когда условие не срабатывает), а он всегда ожидает Array

warning: wrong element type nil at 3 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release warning: wrong element type nil at 4 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release

Второе что-то про содержание, как я понимаю

warning: wrong element type nil at 3 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release warning: wrong element type nil at 4 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release

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

warning: wrong element type nil at 3 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release warning: wrong element type nil at 4 (expected array) warning: ignoring wrong elements is deprecated, remove them explicitly warning: this causes ArgumentError in the next release

Четвёртое тоже про nil, но на другой позиции

Вообще, английский знаешь?)

Привет! Mail.ru ищет спикеров по курсу вебинаров по Ruby и RoR. Удаленно, в свободном графике. ЗП 15000 руб. Пишите кому интересно l.karamysheva@corp.mail.ru

где полноценный рубический обвес для тарантула? :)

Вообще, английский знаешь?)

Английский почти знаю но не понимаю почему ему аткая констуркция кода не нравиться у меня там тупо массив массивов с 3 элементами

и NIL я там никогда не сделаю

TYPES = [ [1, 1, 'qweqw'], [2, 1, 'qweqw'], [3, 2, 'qweqw'], [4, 2, 'qweqw'], ]

и NIL я там никогда не сделаю

Ты дебагом проверил это? Полагаю, нет

Ты дебагом проверил это? Полагаю, нет

кажеться map делает nil, мне надо фильтровать по второй колонке

|t| [t[0], t[2]] if t[1] == type_id

кажеться map делает nil, мне надо фильтровать по второй колонке

Значит, используй метод фильтрации, а не преобразования

Значит, используй метод фильтрации, а не преобразования

о чем и вопрос

о чем и вопрос

Поучи методы Array) пригодится

И Enumerable, который он в себя включает

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

ты это скажи моему работодателю :)

тут вообще все тупые

тут вообще все тупые

У тебя два пути - синяя или красная пилюля?

ты понимаешь, что ты и себя таким образом оскорбляешь?

ты понимаешь, что ты и себя таким образом оскорбляешь?

я про своих коллег :) и начальника наверно

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

типа того

типа того

В таком случае сначала Гугл, потом чат

Ну и в твоих силах было отказаться, если не хочешь ?‍♂

нет смотрите там у меня 3 колонок я должен фильтровать и оставить только 1 и 3 колонку чтобы передать к HaSH

нет смотрите там у меня 3 колонок я должен фильтровать и оставить только 1 и 3 колонку чтобы передать к HaSH

Ну код не соответствует этой задаче

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

сделал так Hash[TpPleaReg::DETAL_TYPES.select { |t| t[1] == type_id }.map {|t| [t[0],t[2]]} ].to_json мне просто не очень нравиться такой вариант

неужели нельзя при map сразу фильтровать? вроде можно, но рельц ругает

неужели нельзя при map сразу фильтровать? вроде можно, но рельц ругает

нет, не стоит

map преобразует и только, он нужен когда кол-во элементов не меняется

чтобы не делать двойной обход — можно корячить each_with_object

либо двойной обход) вполне читаемый

вместо Hash.[] можешь использовать .to_h, полагаю

после вторых рубей

после вторых рубей

надеюсь, < 2.0 нигде не осталось. это неудобно и небезопасно

+

И медленнее

И медленнее

относительно неудобства и небезопасности — это мелочь ? но да

вместо Hash.[] можешь использовать .to_h, полагаю

аналог - .reduce({}, :merge) (или наоборот аргументы, не помню)

:merge! только, или :update

:merge! только, или :update

почему :merge! ?

:merge будет создавать новый хэш на каждой итерации, а :update — нет, у тебя в качестве аккумулятора стоит пустой хэш в аргументах, он точно никем за пределами reduce еще не использовался, значит его можно безопасно мутировать

почему :merge! ?

ну типа один хэш вместо N хэшей, где N = размер массива

:merge будет создавать новый хэш на каждой итерации, а :update — нет, у тебя в качестве аккумулятора стоит пустой хэш в аргументах, он точно никем за пределами reduce еще не использовался, значит его можно безопасно мутировать

годно, спасибо. Никогда не задумывался.

нашел простое изящное решение TpPleaReg::DETAL_TYPES.map { |t| [t[0],t[2]] if t[1] == type_id }.compact.to_h

[1, nil, 3, nil, nil].compact => [1, 3]

Лучше разделите map на select и map

зачем

читабельнее

Hash[TpPleaReg::DETAL_TYPES.select { |t| t[1] == type_id }.map {|t| [t[0],t[2]]} ].to_json вот так чтоли так не изящно

Hash[ TpPleaReg::DETAL_TYPES .select { |t| t[1] == type_id } .map { |t| [t[0], t[2]] } ].to_json

нашел простое изящное решение TpPleaReg::DETAL_TYPES.map { |t| [t[0],t[2]] if t[1] == type_id }.compact.to_h

тоже не сойдет

.select { |_, foo, _| foo == type_id } .map { |foo, _, bar| [foo, bar] } .to_h

ERROR: S client not available

.select { |_, foo, _| foo == type_id } .map { |foo, _, bar| [foo, bar] } .to_h

3 итератора будет :)

Lucifer а скажи пожалуйста, сколько у тебя данных в DETAL_TYPES?

и если можешь дай начальные условия

вообще, я бы сделал вот так hash = {} TpPleaReg::DETAL_TY.each { |a, b, c| hash[a] = c if b == type_id } hash

это был бы самый быстрый вариант

это был бы самый быстрый вариант

Либо я что-то не так делаю, либо не всегда

https://gist.github.com/droptheplot/705a271a775857a07df07ffa06d48b2f

вообще, я бы сделал вот так hash = {} TpPleaReg::DETAL_TY.each { |a, b, c| hash[a] = c if b == type_id } hash

идиоматичный руби - each_with_object

https://gist.github.com/droptheplot/705a271a775857a07df07ffa06d48b2f

плохой бенчмарк, во-первых данные в разных запусках разные, во-вторых все подмассивы одинаковые, в-третьих == type_id везде false

https://gist.github.com/droptheplot/705a271a775857a07df07ffa06d48b2f

данные не так генерируешь

ну и вообще, есть benchmark-ips. который лучше

Либо я что-то не так делаю, либо не всегда

вот, правильный бенчмарк https://gist.github.com/droptheplot/705a271a775857a07df07ffa06d48b2f#gistcomment-2115904

идиоматичный руби - each_with_object

да, только его лучше вообще никогда не юзать

плохой бенчмарк, во-первых данные в разных запусках разные, во-вторых все подмассивы одинаковые, в-третьих == type_id везде false

Да, точно

В итоге все равно получилось быстрее

В итоге все равно получилось быстрее

что быстрее получилось? :)

да, только его лучше вообще никогда не юзать

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

вообще, я бы сделал вот так hash = {} TpPleaReg::DETAL_TY.each { |a, b, c| hash[a] = c if b == type_id } hash

чем лучше each_with_object, предложенного мною выше? помимо лишних строк)

да, только его лучше вообще никогда не юзать

почему?

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

с чего ты взял, что он аллоцирует больше, чем твой вариант с объявлением переменной заранее?

что быстрее получилось? :)

А, он в другом порядке пишет

чем лучше each_with_object, предложенного мною выше? помимо лишних строк)

тем что это вкусовщина? :)

тем что это вкусовщина? :)

так вкусы или аллокация объектов?

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

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

как отличается аллокация между твоим подходом и each_with_object?

static VALUE enum_each_with_object(VALUE obj, VALUE memo) { RETURN_SIZED_ENUMERATOR(obj, 1, &memo, enum_size); rb_block_call(obj, id_each, 0, 0, each_with_object_i, memo); return memo; } где тут лишние аллокации?

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

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

как отличается аллокация между твоим подходом и each_with_object?

ну ок, смотри

есть GC.stat который показывает тебе количесво аллоцированных объектов, так?

если быть точным, вот такой ключ GC.stat(:total_allocated_objects)