У нас есть свой костыль, который через RabbitMQ синхронизирует файлы между двумя серверами 😐

Поэтому везде место модуля fs используется своя над ним обёртка.

У нас есть свой костыль, который через RabbitMQ синхронизирует файлы между двумя серверами 😐

У нас две очереди кролик кладет задачу, редиска забирает ответ)

А ещё тут переодически попадается callback-hell больше чем на 2 FullHD монитора.

А ещё тут переодически попадается callback-hell больше чем на 2 FullHD монитора.

АХАХАХА У нас хотя бы async использовали)

Да, у нас тоже. async.waterfall -> async.series -> ...

Это все равно уебищно выглядит, но лучше, чем 3к пикселей в ширину)

А ещё они в global половину проекта кладут и переодически оттуда юзают.

А на новую ноду почему не переедете? На шестерку, например?

А, и да, тестов нет.

А ещё они в global половину проекта кладут и переодически оттуда юзают.

Ну это у нас тоже есть Рефакторить надо

А, и да, тестов нет.

Как можно больше переписать стоит задача?

А на новую ноду почему не переедете? На шестерку, например?

В конце сентября переедем. Но опять же, вопрос в том, что тут настолько дохрена кода, что его просто так не отрефакторишь. И непонятно как, потому что будет смесь callback'ов, промисов и генераторов.

В конце сентября переедем. Но опять же, вопрос в том, что тут настолько дохрена кода, что его просто так не отрефакторишь. И непонятно как, потому что будет смесь callback'ов, промисов и генераторов.

Я уже определился с тем, как рефакторить

Все банально, но работает

Как можно больше переписать стоит задача?

Неа. А когда будет - на неё людей не дадут. Говнокод - он в голове, его очень сложно выпилить своими руками из команды(

Неа. А когда будет - на неё людей не дадут. Говнокод - он в голове, его очень сложно выпилить своими руками из команды(

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

Да сколько им не выписывай, они всё равно рядом с h.js будут делать helper.js и папку helpers с хэлперами, и utils тоже рядом будут класть...

пацаны! а кто рельсы знает, вопрос есть

пацаны! а кто рельсы знает, вопрос есть

Иди в чат рельс

не, мне надо наших спросить 😀

Да сколько им не выписывай, они всё равно рядом с h.js будут делать helper.js и папку helpers с хэлперами, и utils тоже рядом будут класть...

Почему не бить по рукам и приговаривать "все хуйня, переделывай"? Или у вас тимлид такой?

Почему не бить по рукам и приговаривать "все хуйня, переделывай"? Или у вас тимлид такой?

Я тут 4 день работаю, всё ещё провожу археологические раскопки. Потом обзаведусь битой) Но опять же, уже есть 220к строк говнокода и никто их рефакторинг делать не даст за счёт продакшен-задач.

Ну и тимлид немного с уклоном в плюсы и математику, так что есть немного)

Неа. А когда будет - на неё людей не дадут. Говнокод - он в голове, его очень сложно выпилить своими руками из команды(

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

Я тут 4 день работаю, всё ещё провожу археологические раскопки. Потом обзаведусь битой) Но опять же, уже есть 220к строк говнокода и никто их рефакторинг делать не даст за счёт продакшен-задач.

Соболезную

Почему не бить по рукам и приговаривать "все хуйня, переделывай"? Или у вас тимлид такой?

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

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

да ну.

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

так что будут за

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

Но можно быть хитрым пи..человеком, который будет потихоньку навязывать что-то новое

Я вот начал затирать, как полезно вести логи нормально и мне поверили

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

Повторюсь, я только пришёл) Понятно, что учить будем, да и люди есть адекватные. Я вообще обожаю объяснять и обучать) Просто 220к строк сами себя не перепишут, как это всё рефакторить непонятно, потому что тестов нет и не предвидется (почти нет, их тут какой-то страдалец месяц пытался внедрять и всё на этом). Сама команда ярым желанием покрывать тестами не горит, начальство не давит, хотя и возмущается, что продакшен постоянно падает =) Есть волшебный админ, который потом это поднимает) Ести лид бэкенда, который чуть больше года пытается писать нормально и других учить, но получается у него это пока не очень)

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

зависит от позиции

зависит от позиции

От многого зависит, на самом деле)

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

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

Я вот начал затирать, как полезно вести логи нормально и мне поверили

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

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

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

Я сказал, что не могу исправить баги из-за того, что логов нет Недолго думая, в итерации выделили место на исправление логирования

зависит от позиции

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

подскажите рабочий валидатор для koa2. валидация полей в body, query и тд

Joi как вариант

в joi есть наследие схем да и в целом удобная либа

в joi есть наследие схем да и в целом удобная либа

загуглил joi: обычный использовать или какие-то настройки вокруг joi?

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

+ там еще неплохой вывод ошибок валидации

его тоже можно настроить

загуглил и сразу наткнулся на огромное количество модулей типа router joi, koa context joi и тд. они видимо немного облегчают жизнь, но вероятно не надежны

я использовал обычный joi с koa

я использовал обычный joi с koa

понял, спасибо

если есть сущность like(id, post_id, author_id) стоит ли хранить тут информацию об авторе поста чтобы потом проверить, что автор не может лайкать себе пост ИЛИ стоит делать еще один запрос в базу, чтобы узнать автора поста и сравнить с юзером, отправившим лайк ИЛИ лучше сделать leftJoin?

если есть сущность like(id, post_id, author_id) стоит ли хранить тут информацию об авторе поста чтобы потом проверить, что автор не может лайкать себе пост ИЛИ стоит делать еще один запрос в базу, чтобы узнать автора поста и сравнить с юзером, отправившим лайк ИЛИ лучше сделать leftJoin?

А лайк не добавляет в закладки?

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

нет

если есть сущность like(id, post_id, author_id) стоит ли хранить тут информацию об авторе поста чтобы потом проверить, что автор не может лайкать себе пост ИЛИ стоит делать еще один запрос в базу, чтобы узнать автора поста и сравнить с юзером, отправившим лайк ИЛИ лучше сделать leftJoin?

Оффтоп: А запрещать лайкать самому себе - это бизнес требование?

Оффтоп: А запрещать лайкать самому себе - это бизнес требование?

да, бизнес требование

А лайк не добавляет в закладки?

нет, просто сохраняется запись о лайке

да, бизнес требование

Лично я бы сделал, наверное, CONSTRAINT-ом в postgres

Лично я бы сделал, наверное, CONSTRAINT-ом в postgres

на клиент надо будет отправлять информацию о том, может ли текущий пользователь лайкать свой пост

Лично я бы сделал, наверное, CONSTRAINT-ом в postgres

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

на клиент надо будет отправлять информацию о том, может ли текущий пользователь лайкать свой пост

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

post < like^(2/3)- делать запрос и кешировать

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

Не знаю, если честно, не сталкивался пока с таким хайлоудом. Исхожу я из того, что по требованиям юзер не может лайкнуть свой контент. Т.е. в БД ни при каких условиях не должны добавиться неконсистентные данные. В случае использования вне-БД-проверок, такое возможно.

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

но получается что на каждый лайк мне нужно делать запрос на наличие лайка, плюс join на автора поста, чтоб провести валидацию. Плюс для показа лайка мне нужно сдеелать запрос на сам лайк, плюс join, чтобы узнать автора поста и выдать информацию может ли пользователь лайкать ---------- 4 запроса Если сохранять одно поле, то будет 2 запроса (один для показа, другой для валидации на наличие)

Не знаю, если честно, не сталкивался пока с таким хайлоудом. Исхожу я из того, что по требованиям юзер не может лайкнуть свой контент. Т.е. в БД ни при каких условиях не должны добавиться неконсистентные данные. В случае использования вне-БД-проверок, такое возможно.

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

Автор поста и так известен (аутентификация) В итоге два запроса- проверить наличие лайка и найти пост. Чтобы показать лайк- один запрос- лайкнул ли пользователь и все. Наличие лайка, скорее всего, приходит в ответе с постом, по посту узнаем кто пользователь и пляшем от этого

На все действия три запроса сверху

Автор поста и так известен (аутентификация) В итоге два запроса- проверить наличие лайка и найти пост. Чтобы показать лайк- один запрос- лайкнул ли пользователь и все. Наличие лайка, скорее всего, приходит в ответе с постом, по посту узнаем кто пользователь и пляшем от этого

автор поста неизвестен, если ты его не передаешь вместе c id

автор поста неизвестен, если ты его не передаешь вместе c id

К нам приходит пользователь, есть его айдишник Запрашиваем пост Совпадают автор поста и пользователь- это и есть автор

К нам приходит пользователь, есть его айдишник Запрашиваем пост Совпадают автор поста и пользователь- это и есть автор

пользователь ставит лайки на 10 постов, среди них 2 его, как без допольнительных обращений в базу отсечь самолайк? только таскать автора поста с постом или констрейнтом в БД

К нам приходит пользователь, есть его айдишник Запрашиваем пост Совпадают автор поста и пользователь- это и есть автор

Я в этом случае вообще делаю SELECT * FROM posts WHERE user_id=%1 (упрощенно, конечно же)

пользователь ставит лайки на 10 постов, среди них 2 его, как без допольнительных обращений в базу отсечь самолайк? только таскать автора поста с постом или констрейнтом в БД

А смысл в схеме новости автора не хранить?

пользователь ставит лайки на 10 постов, среди них 2 его, как без допольнительных обращений в базу отсечь самолайк? только таскать автора поста с постом или констрейнтом в БД

это же можно сделать множеством способов включая странный способ от tonsky на crdt

это же можно сделать множеством способов включая странный способ от tonsky на crdt

а конкретнее можно?

хранить set лайкнувших и анлайкнувших и выводить число фильтром

А смысл в схеме новости автора не хранить?

post(id, author_id, text) like(id, author_id, post_id) Любой пользователь делает лайк на любой пост, нужно каждый раз проверять принадлежит ли пост этому пользователю При выводе поста нужно выводить флаг, может ли пользователь лайкать пост

хранить set лайкнувших и анлайкнувших и выводить число фильтром

в памяти? он потенциально может быть очень большого размера

post(id, author_id, text) like(id, author_id, post_id) Любой пользователь делает лайк на любой пост, нужно каждый раз проверять принадлежит ли пост этому пользователю При выводе поста нужно выводить флаг, может ли пользователь лайкать пост

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

в памяти? он потенциально может быть очень большого размера

В редисе?

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

как в нормальный REST добавить автора? например PUT /posts/{id}/like, обязательным тело делать с ссылкой на автора, а если автора подсунули левого?

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

хм, хороший вопрос. Я к посту отправляю информацию post(id, text, author(id, first_name, last_name)) в виде графа. А id - это глобальный id из relay-js