А насколько сложно/интересно/быстро на го писать бекенд с апи

Сложнее, чем на ноде или рельсах; интересно, но неудобно, долго. Необходимо понимать, что тебе на самом деле нужен го на бэке и зачем.

вот, а с эликсиром все очень просто. Его делал Хосе, тот, который в кор рейлс был

очень много общего с руби в эликсире, а в фениксе с рельсами

это мой первый фп язык, так что было сложновато психически и морально, но “разработать” навык - пошло на ура. Только вот я в большенстве делал то, что можно и вполне сносно на рельсе сделать. Ничего необычного, дескать. Но делал приложение для импорта около 5млн записей из кауча в постгрес - это как боженька пить принес. Никакой боли с конкуренси, никаких тебе семафор и мыслей о дедлоке (были шейред состояния) - просто береш и пишешь. Разница во времени исполнения (сначала пытался на руби делать) - ~3 часа на руби против ~15 мин на эликсире

Занятно, спасибо :)

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

крутой парень

@Okamit окстить. С go что-то неладное происходит. Его во все дыры пихать начали. Друг в гугле работает, говорит видел go только в обработке логов и аналитике. Друг, конечно, не видел всего гугла, но все же и не только свой отдел. Еще можешь на продукты hashicorp посмотреть - системные решения на go тоже хорошо идут. По сравнению с elixir (+ OTP) go дает меньше гарантий безопасности и отказоустойчивости из коробки.

> ~3 часа на руби против ~15 мин на эликсире Сталкивался с подобным, но спас celluloid :) Вместо 3х часов на руби получилось 15 минут на руби )

> ~3 часа на руби против ~15 мин на эликсире Сталкивался с подобным, но спас celluloid :) Вместо 3х часов на руби получилось 15 минут на руби )

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

Согласен, плюс это для прикладных задач ок, а в полноценном приложении -- не панацея.

Get Your Conference Proposal Accepted https://t.co/hZzyRaAhPi

Long-term TCP socket monitoring in Ruby https://t.co/yHse59BcQl

может лучше на свифте беки писать?

Привет Можно ли в собственных функциях в моделях использовать стандартные методы валидации?

Просто я понимаю, что писать 7 if это полный бред

Или можно ли в валидациях прописать :on контроллер#функция? Чтобы работало только для этого контроллера и функции

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

можно

все это есть в мануле

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

http://dry-rb.org/gems/dry-validation

вот тебе либа для валидаци

Привет Можно ли в собственных функциях в моделях использовать стандартные методы валидации?

скорее всего ты делаешь что-то не то

Can anyone help me extract the apple emojis to png using Ruby? https://t.co/jMiV0kKmGa

How to exclude the modules of a class here https://t.co/iBKygfGtoI

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

А что не нашел? Как валидацию обьекта запустить вручную?

Вчера показал пример кода техническому директору известной компании. Его разочаровало что код не в одну строку и без сахара. А то, что он оптимизирован под обработку больших данных и использует кэшированные запросы к базе данных даже не заметил. Рельсы стали слишком сладкими. И на ревью от твоего кода ждут красоты, а не производительности. Видимо пора переходить на Erlang :)

Если при первом взгляде на код (без комментариев) нельзя понять, что он делает - тогда разочарование оправдано

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

Вчера показал пример кода техническому директору известной компании. Его разочаровало что код не в одну строку и без сахара. А то, что он оптимизирован под обработку больших данных и использует кэшированные запросы к базе данных даже не заметил. Рельсы стали слишком сладкими. И на ревью от твоего кода ждут красоты, а не производительности. Видимо пора переходить на Erlang :)

выложи gist посмотреть)

В том то и дело, что я сначало описал стоявшую передо мной задачу, как я ее решил и что можно еще сделать. Код аккуратный и читаемый. Но если использовать сахар, то он будет отрабатывать вместо 10 минут несколько часов. Например, я сделал запрос к базе с использованием include зависимых данных. Потом загнал их в массивы чтобы подсчитать и сравнить. Но на первый взгляд по rails best practice приходит на ум другое решение - использовать pluck(:id) и все записать в одну строчку. Но возникнет проблема n+1 и один запрос превратится в несколько миллионов.

https://gist.github.com/weazar/81fec7d442638c409fbc1e546be8b7ae

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

В том то и дело, что я сначало описал стоявшую передо мной задачу, как я ее решил и что можно еще сделать. Код аккуратный и читаемый. Но если использовать сахар, то он будет отрабатывать вместо 10 минут несколько часов. Например, я сделал запрос к базе с использованием include зависимых данных. Потом загнал их в массивы чтобы подсчитать и сравнить. Но на первый взгляд по rails best practice приходит на ум другое решение - использовать pluck(:id) и все записать в одну строчку. Но возникнет проблема n+1 и один запрос превратится в несколько миллионов.

Была подобная проблема, при переписывании запроса на SQL сократили затраты и памяти (с 4 гигов), и времени (с 3 часов до 7 минут). Не могу назвать SQL нечитаемым, главное, как оно оформлен и написан. Гист пока посмотреть не могу

Гист посмотрел, хорошо написан

Если разница - 10 минут против нескольких часов - такой код очень хорош однозначно

Согласен

почему все через each и <<, а не просто map(&:id)?

Sergey Zinoviev, да active record сейчас здесь слабое место. Я сначала на чистом sql написал. Но столкнулся с тем, что sidekiq вылетает с ошибкой, что соединение с базой уже используется. Пришлось вернуться к AR.

У меня проблема даже была не в самом запросе, а в сериализации полученных данных.

Проще сразу было получить хэш.

Sergey Zinoviev, да active record сейчас здесь слабое место. Я сначала на чистом sql написал. Но столкнулся с тем, что sidekiq вылетает с ошибкой, что соединение с базой уже используется. Пришлось вернуться к AR.

А коннекты все по максимуму уже забиты?

Артем Нистратов, да кстати хорошее замечание)

На самый худой момент можно и ActiveRecord::Base.connection заиспользовать

все ругают сахар просто потому, что не умеют его применять

надо знать, что стоит за очередной "красивой" конструкцией

Сервер слабый у заказчика. Я пробовал 250, но память уходила в своп и сайт переставал отвечать. Сейчас нашел оптимальное значение 70 - 25 на sidekiq, 32 для puma и запас небольшой

тоже пара вопросов есть: 13 строка: Что, если сделать next if <условие>; и избавиться от вложенного условия? 32 строка и далее: Что, если использовать в одну строку map или inject или find_each вместо each? 44 строка и далее: Что, если использовать case when вместо if elsif? Те же строки: Что, если вынести это в приватные методы? Например, def genres_count(genres_size) и обращаться к ним

Мне после беглого взгляда показалось, что там большая часть нагрузки приходится на инициализацию AR объектов. Как доберусь до дома посмотрю подробнее. )

Артем Нистратов, сахар  хорош, но не на больших объемах. Производительность Active Record например. Один разработчик пытается увеличить ее производительность, но все на том же месте.

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

Хороший SQL запрос может ускорить процесс в разы :)

вроде по логике код довольно неплохой, а вот по оформлению можно во многих местах сделать короче и читаемее (хотя тут кому как). написали выше - next if, map, в некоторых местах case, и всё это без вреда для итогового sql. и еще в глаза бросились присвоения в конце методов

но это всё косметика

Nick Itch, а если заказчик хочет через админку этим делом управлять, то приходится выкручиваться. Конечно можно было бы это на crystal в несколько потоков запилить с чистым sql. Но задача стоит сделать на рельсах.

Параметризировать sql тоже никто не мешает. Если задача про рельсы, вопросов нет :)

Dmitriy Ushkov, ну да это уже косметика, которую сейчас и ждут от разработчика. А за лесом деревьев не видят)

Ну по сути эта косметика не требует лишних затрат времени, тут скорее дело в привычке. Может, ищут тех, кто пишет код, красивый как по сути, так и косметически.

Sergey Zinoviev, я изначально делал через ActiveRecord::Base.connection и sql, но в sidekiq вылетала ошибка что соединение уже занято.

Но это всё грустно, если честно

здесь хоть кто-нибудь слышал про arel?

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

здесь хоть кто-нибудь слышал про arel?

+1 :)

любой sql запрос можно написать в рамках rails

и быстро и читаемо

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

sequel? rom?

Да, sql раз в 10 быстрее

ты потом hash будешь в страницу отображать?

Быстрее возвращать json из БД :D

ты потом hash будешь в страницу отображать?

Так это ж вроде вписывается в рамки задачи

тогда зачем ruby? делайте запросы прямо в теле страницы) как в php образца 2000-х

Тут таска в бэкграунд

ну вот, то вы о AR в общем, то снова прыгаете к конкретике

Я вроде в контексте задачи оставался )

Vitaliy Emeliyantsev, find_each по моему вызовет прямой запрос к базе. А case when там надо будет городить громоздкую конструкцию, потомучто сравнения есть >= а не просто булевы значения.

Крайности -- тоже плохо. Технологии надо использовать там, где они нужны

Это расчет коэффициента близости между фильмами для рекомендательной системы. На странице ничего не выводится. Только в результате похожие фильмы.

Да, sql раз в 10 быстрее

быстрее чего?

Active Record

Пример можно?

А почему бы #genres_count вот так не написать: genres_size = @film.genres.count + comparison.genres.count ...

нет, это вызовет запрос к бд

когда все данные уже в памяти

Это примерно, я сравнивал работу этого алгоритма на sql и AR. Тут разница от кода зависит, но она существенная. Вот кстати статья в тему ее производительности https://www.netguru.co/blog/back-to-thinking-sql-ruby-rails

И if ... elsif выглядит не менее громоздким, чем case ... when

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

сохранилась ли версия на AR?

нет, это вызовет запрос к бд

genres_size = @film.genres.to_a.count + comparison.genres.to_acount ... ? )

так лучше)

я например тоже скептически относился к производительности AR

но на настоящих данных сравнил rom и AR... rom к слову использует sequel

вот там разница и правда имеет место быть

В общем рефактор каунт методов в таком ключе без потери читаемости сократит количество кода процентов на 40 )

rom выиграл только на bulk insert

Примерно, потомучто факт в том, что AR слабое звено в рельсах на высоких нагрузках. И если посмотреть код оптимизированных приложений, то там sql. По крайней мере в моей практике с legacy кодом так было почти всегда.

в остальных тестах до 3х потеря производительности

На миллионе запросов разница в 3 раза превращается в тысячи лет.

на миллионах*