Программирование[8]

найс рубисты, че

или руби

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

 

а, вейт

разве не сто тебе команду даёт?

расскажи плс как у тебя устроена иерархия

Я в компании начал работать за год с копейками до того как там появился текущий CTO. Он как бы на уровне менеджера для меня. То есть я его слушаю, если это какие-то базовые поручения. Но если я с чем-то не согласен, то тогда начинаются дебаты. Если продвигают совсем уж хуйню, что иду в боссу напрямую (с которым я всегда был в расслабленных отношениях со первого же дня на работе). Конкретно сейчас к боссу рано идти, ибо фронтенд изменения на уровне "мы так хотим", и грузить начальника техническими детали, не предлагая никаких адекватных решений, это просто трата времени и драма на пустом месте.

Если у босса есть какая-нибудь новая йоба идея, то он зачастую обсуждает её прямо со мной, минуя всяких там продакт манагеров. Если фича мелкая, я могу её сделать за день-два, даже не создавая тасков в джире. Если кто-то чего спросит, я просто скажу что вот делаю хуйню для босса. Хотя таких приколов сейчас конечно куда меньше, продакты и СТО его постоянно пинали за все эти ниндзя-тактики (а меня за ninja-pushing), так что он теперь пытается отыгрывать пай мальчика и юзать иерархию (а мне в свою очередь ебут мозги унылыми PR Review, где челики дрочат на юзлесс детали), если речь не идет о какой-то мелочи, которую можно сделать за 15 минут.

новый виток бюрократии, лол

  Причем все дискассы с бэкендерами заканчивались тем, что они чекали что запрос и прием данных с базы занимает менее секунды, а все остальное время руби делает хуй пойми что на уровне сериализации и изменений в JSON (дабы приготовить финальный контент). То есть tl;dr таков, что они тупо не знают что конкретно там сжирает все время.

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

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

Причем все дискассы с бэкендерами заканчивались тем, что они чекали что запрос и прием данных с базы занимает менее секунды, а все остальное время руби делает хуй пойми что на уровне сериализации и изменений в JSON (дабы приготовить финальный контент). То есть tl;dr таков, что они тупо не знают что конкретно там сжирает все время.

 

Не понял, а как они это чекали не через руби? SQL запросами чтоль?

Причем все дискассы с бэкендерами заканчивались тем, что они чекали что запрос и прием данных с базы занимает менее секунды, а все остальное время руби делает хуй пойми что на уровне сериализации и изменений в JSON (дабы приготовить финальный контент). То есть tl;dr таков, что они тупо не знают что конкретно там сжирает все время.

Неужели там столько бизнес логики что невозможно понять почему все так медленно (перед этим уже исключив проблемы с запросом)?

 

Причем все дискассы с бэкендерами заканчивались тем, что они чекали что запрос и прием данных с базы занимает менее секунды, а все остальное время руби делает хуй пойми что на уровне сериализации и изменений в JSON (дабы приготовить финальный контент). То есть tl;dr таков, что они тупо не знают что конкретно там сжирает все время.

 

Неужели там столько бизнес логики что невозможно понять почему все так медленно (перед этим уже исключив проблемы с запросом)?

 

им просто похуй. Это же из текста ясно.

 

Причем все дискассы с бэкендерами заканчивались тем, что они чекали что запрос и прием данных с базы занимает менее секунды, а все остальное время руби делает хуй пойми что на уровне сериализации и изменений в JSON (дабы приготовить финальный контент). То есть tl;dr таков, что они тупо не знают что конкретно там сжирает все время.

 

 

Не понял, а как они это чекали не через руби? SQL запросами чтоль?

 

дык они не чекали свой код, он идеален по дефолту.

 

 

 

кто-нибудь связывал django-channels и celery? Есть channel_layer, через него отсылаются сообщения, которые асинхронные консюмеры отсылают по вебсокету. Можно ли сделать так, чтобы  из метода консюмера вызывался таск сельдерея, и после, допустим asyncio.sleep(10), отсылал сообщение в channel_layer? какие подводные камни?

зачем asyncio.sleep(10) если у тебя сельдерей.

зачем asyncio.sleep(10) если джанга работает в один поток.

запустить сельдерей можно.

replyChannel может принимать ответ.

 

слип для того, чтобы через определенный промежуток времени отдавать на фронт информацию, мне приходит json с 'type': 'start_round' от главного в чате, я начинаю раунд в инстансе его консюмера, и слипаю там, после слипа шлю 'type': 'end_round', при таком подходе, если главный закроет вкладку чата, таймер слетает, поэтому и думаю сделать таймер где-то в фоне

 

не ебись с этим.

Заюзай пушер(пушер.ком) и будет счастье.

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

Если у тебя это чатик, то текущую сессию храни в редисе (лог чата), когда чат закрывается дампи это все в базу.

 

видимо ты работал еще с первой версией channels, а так вроде все интегрируется норм, проверено

 

 

 

 

кто-нибудь связывал django-channels и celery? Есть channel_layer, через него отсылаются сообщения, которые асинхронные консюмеры отсылают по вебсокету. Можно ли сделать так, чтобы  из метода консюмера вызывался таск сельдерея, и после, допустим asyncio.sleep(10), отсылал сообщение в channel_layer? какие подводные камни?

зачем asyncio.sleep(10) если у тебя сельдерей.

зачем asyncio.sleep(10) если джанга работает в один поток.

запустить сельдерей можно.

replyChannel может принимать ответ.

 

слип для того, чтобы через определенный промежуток времени отдавать на фронт информацию, мне приходит json с 'type': 'start_round' от главного в чате, я начинаю раунд в инстансе его консюмера, и слипаю там, после слипа шлю 'type': 'end_round', при таком подходе, если главный закроет вкладку чата, таймер слетает, поэтому и думаю сделать таймер где-то в фоне

 

не ебись с этим.

Заюзай пушер(пушер.ком) и будет счастье.

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

Если у тебя это чатик, то текущую сессию храни в редисе (лог чата), когда чат закрывается дампи это все в базу.

 

видимо ты работал еще с первой версией channels, а так вроде все интегрируется норм, проверено

 

да с первой.

Ребята, хелп. 

Короч нужна помощь с подходом, агоритмом и т.д. Нужно предсказать приход груженного вагона(полувагона) на определённую станцию. Что я имею: всего есть четыре заранее известных маршрута и база данных, которая обновляется 5 раз в день. В этой базе данных инфа(за последние семь лет) о том где поезд находился/находится на станции, сколько осталось км до станции, какая операция на станции(приход, отход, отцепление, выгрузка)(операции это один из самых влиящих факторов) и к какому поезду прицеплен. Написал самый тривиальный алгоритм, без машинного обучения, который высчитывает сколько минут занимает время от станции до станции, и потом высчитывается среднее значение, вагонов несколько тысяч. Выборка была за последний месяц. Потом  вагонам, которые в пути, докидываю средние минуты и так считаю во сколько придёт и строю отчёт. Оч хуево работает алгоритм. Разница с фактом больше 8 часов что критично. Думаю всякие нейронные сети машинное обучение, мб привязать какую нить погоду.  Может и без МЛ, просто статистику ещё какую нить. Я хз в общем как к этой задачи подходить. Конкретно в машинном обучении я не особо шарю. Это и не совсем типичный временной ряд, чтобы делать стандартные АРИМА САРИМА, ведь данные категориальны. Как я понимаю, это задача регрессии(если поставить задачу как предсказание минут, часов), и сейчас думаю какой регрессионный алгоритм применить. Есть идеи мысли куда глядеть? 

Ребята, хелп. 

 

Короч нужна помощь с подходом, агоритмом и т.д. Нужно предсказать приход груженного вагона(полувагона) на определённую станцию. Что я имею: всего есть четыре заранее известных маршрута и база данных, которая обновляется 5 раз в день. В этой базе данных инфа(за последние семь лет) о том где поезд находился/находится на станции, сколько осталось км до станции, какая операция на станции(приход, отход, отцепление, выгрузка)(операции это один из самых влиящих факторов) и к какому поезду прицеплен. Написал самый тривиальный алгоритм, без машинного обучения, который высчитывает сколько минут занимает время от станции до станции, и потом высчитывается среднее значение, вагонов несколько тысяч. Выборка была за последний месяц. Потом  вагонам, которые в пути, докидываю средние минуты и так считаю во сколько придёт и строю отчёт. Оч хуево работает алгоритм. Разница с фактом больше 8 часов что критично. Думаю всякие нейронные сети машинное обучение, мб привязать какую нить погоду.  Может и без МЛ, просто статистику ещё какую нить. Я хз в общем как к этой задачи подходить. Конкретно в машинном обучении я не особо шарю. Это и не совсем типичный временной ряд, чтобы делать стандартные АРИМА САРИМА, ведь данные категориальны. Как я понимаю, это задача регрессии(если поставить задачу как предсказание минут, часов), и сейчас думаю какой регрессионный алгоритм применить. Есть идеи мысли куда глядеть?

Описание очень тяжелое если честно, потому что не понятно какая статистика есть изначально и что требуется. По описанию МЛ нужно конечно, иначе нужна куча статистики по категориям что за вагоны/сколько они грузятся/цепляются по типу, желательно погода, время работы(ночью грузят или утром/днем) и.т.д. Короче нужно понять какие данные точно есть.

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

У меня тут на работе рофлы, как всегда с ахуительным руби на бэкенде. В общем год назад, когда я получил вторую прибавку к зп, я стал частью нового проекта, суть которого сводилась к увеличению генерируемого контента (проще говоря репортов с чартами). Конкретно я сам ничего не генерировал, этим занимались поцаны, которые пилили хуйни связанные с Machine Learning, плюс у нас имеется проект для создания большого количества репортов, на основе хитровыебанных фильтров и шаблонов. То есть залез в команду с большим количеством датасорсов (1к+ и выше), заебенил фильтр, который по итогам выдал, допустим, 800 датасорсов, выбрал шаблон и создал 800 репортов, в каждом из которых будет пачка чартов (и другого контента) на основе шаблона, с данными на основе конкретного датасорса.

 

Дак вот, моя роль заключалась в том, чтобы все это новое добро показывать юзеру. Старая домашняя страница была говном, где в экран влезало полтора превью репорта и надо было долго и мучительно скроллить вниз или сразу юзать поиск с фильтрами. В итоге мы запилили рип-офф нетфликса (я тут постил видосики), который за один реквест грузил по 10 категорий, в каждой из которых было по 20 репортов. И вот ты скроллил вниз, он грузил больше и так далее. И все было заебись, работало более менее ок, и по началу загрузка этих репортов на главной странице занимала 1-3 секунды (причем загрузка была асинхронной, все остальные куски интерфейса интерактивны).

 

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

 

И вот на прошлой неделе, ВНЕЗАПНО выяснилось что в одной из команд, в которой через автоматизацию на протяжении полугода+ создавали сотни/тысячи репортов каждый месяц, стало реально дохуя репортов (я даже хз скока, но по меркам любых биг дата компани это явно копейки). И теперь там запрос на возврат 10 категорий (что в себя включает чуточку сортинга и категоризации, но ничего особо сложного) занимает БОЛЕЕ МИНУТЫ. И это если сервак не перегружен и интернет работает исправно. Иногда можно смотреть на экран 3-4 минуты, пока не появится контент, а иногда ты тупо получаешь ошибку после 4х минут. Причем все дискассы с бэкендерами заканчивались тем, что они чекали что запрос и прием данных с базы занимает менее секунды, а все остальное время руби делает хуй пойми что на уровне сериализации и изменений в JSON (дабы приготовить финальный контент). То есть tl;dr таков, что они тупо не знают что конкретно там сжирает все время.

 

И теперь собственно кульминация: после срачей с CTO и бэкендерами, их окончательная позиция такова, что оптимизация должна происходить НА КЛИЕНТЕ, за счет замены одного большого запроса на 10 маленьких. Что почти полностью убивает весь UX нетфликс-стайл контента, где ты как бы должен получить все отсортированные категории разом, вместо того чтобы наблюдать за гонкой между 10 рядами, каждый из которых заканчивает загрузку хуй знает когда. Я уж молчу про то, что пройдет еще полгода+, и этих репортов станет еще дохуя больше, после чего даже загрузка одной категории будет занимать вечность, учитывая какая там хуйня происходит.

 

(CTO и бэкендеров я конечно же сейчас все еще посылаю нахуй, ибо слава богу они не обладают правом просто говорить фронтенду чо и как менять, пока все команды не сойдутся на адекватном решении)

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

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

я правда не совсем понял проблемы того чтобы запрашивать не пачками по 10-20 а по 1му и иметь плейсхолдеры под контент который еще не успел загрузится.

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

а я еще про леса чето слышал

 

Ребята, хелп. 

 

Короч нужна помощь с подходом, агоритмом и т.д. Нужно предсказать приход груженного вагона(полувагона) на определённую станцию. Что я имею: всего есть четыре заранее известных маршрута и база данных, которая обновляется 5 раз в день. В этой базе данных инфа(за последние семь лет) о том где поезд находился/находится на станции, сколько осталось км до станции, какая операция на станции(приход, отход, отцепление, выгрузка)(операции это один из самых влиящих факторов) и к какому поезду прицеплен. Написал самый тривиальный алгоритм, без машинного обучения, который высчитывает сколько минут занимает время от станции до станции, и потом высчитывается среднее значение, вагонов несколько тысяч. Выборка была за последний месяц. Потом  вагонам, которые в пути, докидываю средние минуты и так считаю во сколько придёт и строю отчёт. Оч хуево работает алгоритм. Разница с фактом больше 8 часов что критично. Думаю всякие нейронные сети машинное обучение, мб привязать какую нить погоду.  Может и без МЛ, просто статистику ещё какую нить. Я хз в общем как к этой задачи подходить. Конкретно в машинном обучении я не особо шарю. Это и не совсем типичный временной ряд, чтобы делать стандартные АРИМА САРИМА, ведь данные категориальны. Как я понимаю, это задача регрессии(если поставить задачу как предсказание минут, часов), и сейчас думаю какой регрессионный алгоритм применить. Есть идеи мысли куда глядеть?

 

Описание очень тяжелое если честно, потому что не понятно какая статистика есть изначально и что требуется. По описанию МЛ нужно конечно, иначе нужна куча статистики по категориям что за вагоны/сколько они грузятся/цепляются по типу, желательно погода, время работы(ночью грузят или утром/днем) и.т.д. Короче нужно понять какие данные точно есть.

 

@@pain~

 

У меня тут на работе рофлы, как всегда с ахуительным руби на бэкенде. В общем год назад, когда я получил вторую прибавку к зп, я стал частью нового проекта, суть которого сводилась к увеличению генерируемого контента (проще говоря репортов с чартами). Конкретно я сам ничего не генерировал, этим занимались поцаны, которые пилили хуйни связанные с Machine Learning, плюс у нас имеется проект для создания большого количества репортов, на основе хитровыебанных фильтров и шаблонов. То есть залез в команду с большим количеством датасорсов (1к+ и выше), заебенил фильтр, который по итогам выдал, допустим, 800 датасорсов, выбрал шаблон и создал 800 репортов, в каждом из которых будет пачка чартов (и другого контента) на основе шаблона, с данными на основе конкретного датасорса.

 

Дак вот, моя роль заключалась в том, чтобы все это новое добро показывать юзеру. Старая домашняя страница была говном, где в экран влезало полтора превью репорта и надо было долго и мучительно скроллить вниз или сразу юзать поиск с фильтрами. В итоге мы запилили рип-офф нетфликса (я тут постил видосики), который за один реквест грузил по 10 категорий, в каждой из которых было по 20 репортов. И вот ты скроллил вниз, он грузил больше и так далее. И все было заебись, работало более менее ок, и по началу загрузка этих репортов на главной странице занимала 1-3 секунды (причем загрузка была асинхронной, все остальные куски интерфейса интерактивны).

 

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

 

И вот на прошлой неделе, ВНЕЗАПНО выяснилось что в одной из команд, в которой через автоматизацию на протяжении полугода+ создавали сотни/тысячи репортов каждый месяц, стало реально дохуя репортов (я даже хз скока, но по меркам любых биг дата компани это явно копейки). И теперь там запрос на возврат 10 категорий (что в себя включает чуточку сортинга и категоризации, но ничего особо сложного) занимает БОЛЕЕ МИНУТЫ. И это если сервак не перегружен и интернет работает исправно. Иногда можно смотреть на экран 3-4 минуты, пока не появится контент, а иногда ты тупо получаешь ошибку после 4х минут. Причем все дискассы с бэкендерами заканчивались тем, что они чекали что запрос и прием данных с базы занимает менее секунды, а все остальное время руби делает хуй пойми что на уровне сериализации и изменений в JSON (дабы приготовить финальный контент). То есть tl;dr таков, что они тупо не знают что конкретно там сжирает все время.

 

И теперь собственно кульминация: после срачей с CTO и бэкендерами, их окончательная позиция такова, что оптимизация должна происходить НА КЛИЕНТЕ, за счет замены одного большого запроса на 10 маленьких. Что почти полностью убивает весь UX нетфликс-стайл контента, где ты как бы должен получить все отсортированные категории разом, вместо того чтобы наблюдать за гонкой между 10 рядами, каждый из которых заканчивает загрузку хуй знает когда. Я уж молчу про то, что пройдет еще полгода+, и этих репортов станет еще дохуя больше, после чего даже загрузка одной категории будет занимать вечность, учитывая какая там хуйня происходит.

 

(CTO и бэкендеров я конечно же сейчас все еще посылаю нахуй, ибо слава богу они не обладают правом просто говорить фронтенду чо и как менять, пока все команды не сойдутся на адекватном решении)

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

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

 

я правда не совсем понял проблемы того чтобы запрашивать не пачками по 10-20 а по 1му и иметь плейсхолдеры под контент который еще не успел загрузится.

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

а я еще про леса чето слышал

 

для базы размером больше 100 строк что 10, что 1 для плана запроса абсолютно одинаково

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

и даже если они криворукие уебаны, зачем делать с фронта 10 запрсов, если ничто не мешает внутри ебучего контроллера самим сделать 10 запросов по 1 штуке?

а если кто-то пойдет и руками по урлу дернет сразу 100, у них прога повесится или что?

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

и даже если они криворукие уебаны, зачем делать с фронта 10 запрсов, если ничто не мешает внутри ебучего контроллера самим сделать 10 запросов по 1 штуке?

А потом передать все эти 10 ответов в то место, которое непонятно почему долго думает и получить то же самое на выходе 

Кароче заебал js. Скиньте годные книги по c# или курсы. Хочу игоры делать на unity. Или приложухи всякие.

Кароче заебал js. Скиньте годные книги по c# или курсы. Хочу игоры делать на unity. Или приложухи всякие.