ну а дальше просто пишешь что-то такое data = (1..100).map { [rand(10), 2, rand(10)] } GC.disable before = GC.stat(:total_allocated_objects) data.each_with_object({}) { |a, b, c, hash| hash[a] = c if b == 2 } p GC.stat(:total_allocated_objects) - before GC.start before = GC.stat(:total_allocated_objects) hash = {} data.each { |a, b, c| hash[a] = c if b == 2 } p GC.stat(:total_allocated_objects) - before

и в моем случае each_with_object создает на 2 объекта больше, это не сильно критично, и во всяких бенчмарках будет проскальзывать 10% разницы по выполнению

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

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

ну на 2 объекта больше это конечно не разница. вот если бы на 2*n :)

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

ну на 2 объекта больше это конечно не разница. вот если бы на 2*n :)

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

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

это просто пожелание, как стоит писать твой код. точно так же, как и рубокоп, который эти правила подводит под что-то

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

да, но разница статичная, не зависит от величины массива

интересно блин где ж там лишние аллокации. прям хз

да, но разница статичная, не зависит от величины массива

да, но ты не забывай, что у тебя есть еще одна велечина, как часто вызывается какой-то код

это да

да, но ты не забывай, что у тебя есть еще одна велечина, как часто вызывается какой-то код

кстати, сейчас будет смешно, но while будет быстрее ича

но это только для больших наборов данных

кстати, сейчас будет смешно, но while будет быстрее ича

а си быстрее руби)

и аллокаций поменьше ?

ну а дальше просто пишешь что-то такое data = (1..100).map { [rand(10), 2, rand(10)] } GC.disable before = GC.stat(:total_allocated_objects) data.each_with_object({}) { |a, b, c, hash| hash[a] = c if b == 2 } p GC.stat(:total_allocated_objects) - before GC.start before = GC.stat(:total_allocated_objects) hash = {} data.each { |a, b, c| hash[a] = c if b == 2 } p GC.stat(:total_allocated_objects) - before

спасибо, попробую. не знаю, насколько норм измерение, и насколько большие эти 2 объекта

а си быстрее руби)

да не

там не совсем в си дело, а в том, как ты с данными работаешь

кто-нибудь собирал kubernetes-кластер из docker-compose?

кто-нибудь собирал kubernetes-кластер из docker-compose?

есть же чатики по докеру

@ru_docker

#hanami Короче говоря, добил я в итоге пример, чтобы получить ошибку с i18n и dry-v. https://gist.github.com/jarosluv/b6868e13736fc4e1be1321a933adca92

Внёс ещё пару коррективов и стало ещё прикольнее puts FooSchema.(params[:foo]).errors # GOOD puts action.call(params) # FAIL

Если запрашиваем схему напрямую, то всё ок, если через контроллер, то схема не может найти перевод...

@flash_gordon @davydovanton мб вам будет интересно

пушто напами ни нужон

пушто напами ни нужон

все так, но сколько проектов ты сделал (хотя бы для себя) на ханами? :)

0, он же не нужен

0, он же не нужен

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

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

и как же? :)

типа "ура, спасибо рельсы что вы есть"

типа "ура, спасибо рельсы что вы есть"

ну, ты попробуй, а потом мне расскажешь :)

мне будет интересно, правда

ну собственно вот, не такой большой гайд

http://hanamirb.org/guides/getting-started/

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

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

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

например засунуть ненужный паттерн репозиторий, ага.

> - репозиторий паттерн вот это вот мне прям больше всего не нравится

> - репозиторий паттерн вот это вот мне прям больше всего не нравится

дай пять братишь

> - репозиторий паттерн вот это вот мне прям больше всего не нравится

почему он тебе не нравится?

??

ну, кроме того, что это не привычный АР?

а в чём его преимущества?

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

изолируется 2 разных логики

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

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

так что мешает указать как оно лежит явно?

изолируется 2 разных логики

ну т.е в базе трэш и неявное хранение данных, но разработчик этого не видит.

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

ну т.е в базе трэш и неявное хранение данных, но разработчик этого не видит.

почему?

а зачем эта прослойка? почему база не отображает бизнес логику?

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

а у тебя в АР на каждый чих не вызывается портянка кода?

я её не пишу

по мне так это заталкивание проблем поглубже.

а зачем эта прослойка? почему база не отображает бизнес логику?

потому что у тебя есть логика "достать/положить" в базу, есть логика "посчитать что-то, показать данные"

это так то разные вещи

как я в отрыве от базы буду считать большие данные?

я её не пишу

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

как я в отрыве от базы буду считать большие данные?

что тебя тут смущает то?

ты говоришь про какой-то отрыв от базы данных

можешь пояснить?

потому что у тебя есть логика "достать/положить" в базу, есть логика "посчитать что-то, показать данные"

ну ты можешь так же в АР вытащить в методы модели/квери обжекта это

ERROR: S client not available

можешь пояснить?

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

ну ты можешь так же в АР вытащить в методы модели/квери обжекта это

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

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

не совсем

у тебя есть репозиторий, который отдает тебе энтити (дата объекты)

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

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

что?

у тебя есть репозиторий, который отдает тебе энтити (дата объекты)

ну т.е у меня в памяти получается мульон дата объектов да?

ну т.е у меня в памяти получается мульон дата объектов да?

неа

ну, у тебя АР маппит данных больше

потому что там еще в кишках ты валидацию вызвать можешь и кучу всего

в общем, я думаю это спор в никуда, я попробовал подход с репозитори(в симфони2) и мне он не понравился(понравилось только что миграции генерятся автоматом)

ну в случае с AR у меня нет промежуточной прослойки, я точно знаю текущую схему базы

она не заизолирована, она часть приложения. Надо - выполнил голый или полуголый SQL.

ну в случае с AR у меня нет промежуточной прослойки, я точно знаю текущую схему базы

так почему ты думаешь, что репозиторий этого не знает?

что мешает сделать релейшен явный?

с АР проблемы что оно всё нахуй грузит при запросе

подожди, зачем мне репозиторий если я могу сделать голый SQL запрос?

например такое

это то, что забирается из таблицы, т.е. маппинг явный таблицы на твою модель

ты можешь еще замапить энтити на нужные данные из таблицы

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

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

да

ну, как ты это в АР делать будешь?

ты можешь еще замапить энтити на нужные данные из таблицы

т.е я обхожу изоляцию логики и оно снова у меня все связано?

какой-нибудь Use.exec_sql('...'), так?

че-то какой-то набор суеверий)

ну, как ты это в АР делать будешь?

Post.select('count views()') псевдокод

че-то какой-то набор суеверий)

именно

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

я же не скрываю что я с ром не работал.

Потому и интересуюсь как оно там устроено.