Вариаций реализации монолитов/микросервисов много. Ругать или хвалить стоит конкретные решения, но зачастую это будут субъективные плюсы и минусы для определенного проекта/задачи.
А вообще делайте как хотите и что хотите. Ведь неважно хороший или плохой вы сапожник, всё равно вы сделаете сапог и получите опыт. Теория тоже важна, но опыт сложнее получить.
PS. Я не говорю что не нужно учиться, Я за то, чтобы набивались шишки, а когда не будет хватать теории (будут конкретные проблемы), то её можно будет гораздо легче получить, нежели находиться в фрустрации и искать идеальное решение.
У меня к вам вопрос немного не по теме. Вы работали с монгой? А то мимо меня как-то она прошла стороной и на проде ни в каком проекте не использовали...
Монга советует придерживаться денормализации данных для избегания джойнов. Но в то же время имеет ограничение на размер документа (16мб, вроде и не мало). Но если у нас приложение (бл) основывается на пользовательском вводе, то в теории пользователь будет упираться в лимит документа при сохранении данных.
Было ли у вас такое? И если изначально нет никаких ограничений на размер документа (связей), не является ли реляционная база тогда лучшим выбором?
Просто сколько не видел примеров использования монги, везде данные нормализуются, из-за чего появляются джойны...
Вот и у меня при прочтении сложилось впечатление что написана теоретиком для теоретиков. Всё описано слишком абстрактно, без конкретики, без примеров...
Курсы преподносят себя именно как её. И много скама по заработку преподносят себя как волшебную таблетку с доходностью 500% в месяц.
Т.е. как по мне, проблема не в курсах, а в том, что люди начинают считать что кроме курсов ничего не надо. Могут спрашивать "А какие видео на Ютубе посмотреть?", будто после просмотра научится всё делать... Но важен не сам контент, а то, как обрабатывает человек полученную информацию.
Джун, Мидл, Сеньор - бессвязный набор слов, если их использовать без спецификации.
К тому же я написал, что наиболее сравнимое, а не точь-в-точь. Как минимум, IT до сих пор развивается, а медицина — уже развитая отрасль. И стоит смотреть не только на текущее положение дел, но и на весь путь развития других отраслей.
Джун, Мидл, Сеньор - бессвязный набор слов, если их использовать без спецификации.
В жизни нужно быть проще, а не меряться лычками, т.к. иной раз "Джун" может принести больше пользы, чем "Сеньор". Как минимум "Джун" в одной области может оказаться гораздо смышленее в другой, которая как раз и будет полезнее в конкретной ситуации.
Опыт это не просто про время. Смысл сравнивать разработчика лендингов со стажем 10 лет, и, допустим, разработчика бд? Это разные весовые категории, но они все нужны (Все профессии важны, все профессии нужны). Даже если брать двух разработчиков с одинаковым стэком, то окажется, что опыт за года у них был разный.
Я не понимаю зачем унифицировать друг-друга, если это не даёт бенефитов. Ещё до недавнего времени "разработчики" и "программисты" в глаза общественности были гиками, которые могут починить утюг. А при помощи таких унификаций создаётся только иллюзия. Т.к. упрощение сложного (комплексного) не ведёт ни к чему хорошему.
Для меня наиболее сравнимое с IT это система здравоохранения. Есть терапевты, хирурги, медсестры, бухгалтера, администраторы и т.д., которые в этих больших группах делятся на ещё мельче (кардиохирург, нейрохирург и т.д.). Да, есть в медицине что-то смежное, что-то базовое, что знают вне зависимости от конкретной профессии. И каждая профессия важна. А в IT будто решили изобрести велосипед и пройтись по всем граблям, вместо того, чтобы взять и использовать лучшие практики из других отраслей.
Вообщем весь коммент сводится к тому, что упрощение всего опыта человека до банальных "Джун", "Мидл", "Сеньор" не даст ничего, кроме какой-то иллюзии.
Я не говорю, что системный подход не нужен, Я говорю про то, что учебная программа для 5 летних и 12 летних будет разной. И если в 5 лет обучать чему-то более общему, нежели конкретно программированию, то это не означает, что более общее не относится к обучению программированию.
Так же как и в программировании важно не только уметь программировать, но и уметь обучаться, т.к. каждый день появляются новые технологии которые окажут влияние через год-два-три и т.д., игнорирование которых поставит в слабую позицию.
Вообщем мой тезис сводится к тому, что обучение программированию это не только про сам код/анализ/проектирование.
Смотря что понимать под обучением. Есть комп игры, которые обучают логике в игровой форме. Да, это развивающие игры более общего плана, а не конкретно программированию, но всё же помогут и в изучении программированию в дальнейшем.
До сих пор помню бесящий уровень с рыболовной сетью из Медвежонка Плюма... Эту игру мне дали, когда было 5-6 лет.
Он нужен только для оптимизации запроса данных из других сервисов, только тогда выигрыш производительности нивелирует проблемы безопасности.
Если вы в JWT храните недостаточно данных (id пользователя и, допустим, роль) и затем запрашиваете все остальные данные в бд, то совокупного выигрыша нет.
Тут скорее вопрос о том, в каких конкретных случаях использовать jwt выгодно. Т.к. в подавляющем большинстве случаев в jwt просто хранится id текущего пользователя (и ещё какие-то идшники), что не решает проблему с запросами к бд.
Я нашел только один случай, когда в jwt есть смысл - кэширование не секретных данных, чтобы разгрузить бд. Но это не нужно, либо хранится только id в 99%.
Как по мне, указанный вами пример с монолитом/распределенной системой не является аргументом за jwt, т.к. описанный случай решается гейтвеем.
Тот же вопрос и про jwt. Как по мне, jwt самая переоцененная вещь. Если мы хотим меньше делать запросов к бд, то возникают проблемы с принудительной инвалидацией токенов. Или как в данном случае общение происходит в доверенной сети и непонятно для чего jwt в принципе пихать...
Это приложение не для знакомств (в плане отношений), а чисто для мужской дружбы. Как я это понял?
Прошёл тесты, в совпадениях чуть больше десяти девушек возрастом 35-52 и совпадением в районе 73%. Поменял пол на Ж, сменил поиск на М, появилось куча парней 25-35 с совпадением 85% =)
По поводу "опыта" и "проекта в породе". Можно же новичкам наработать опыт и получить проект в портфолио на фрилансе. Помимо фриланс платформ есть форумы с заказами (они ещё живы).
Оплата скорее всего будет не велика, ровно как и нет 100% вероятности что вы найдете проект под свой стэк, но всё же для веба (в т.ч. и бэка) найти не сложно. А с учётом, что на бэке можно использовать любой ЯП (не приходит на ум ЯП, который бы нельзя было использовать на бэке), то велика вероятность, что у вас появится проект в портфолио.
Насколько знаю, сейчас относятся скептически к фрилансе в резюме, но всё же если речь про джуна, тем более с прикрепленным проектом, то пойдёт только в плюс.
Вы не поняли или специально манипулируете.
https://pb.nalog.ru/company.html?token=AC2879BD80122C12CC3453EEAE7FF047CF748340226450522836B8CB6F677DEC93FB39E34F6A0E9AA167A6B67AD309EF
Как видно, задолженность 200к появилась 11.23, а уже 02.24 была 2кк. Т.е. задолженность появилась не после его выступления.
Если вы посмотрите какие компании должны, а так же посмотрите когда образовалась задолженность, то увидите, что задолженность появилась не вчера.
Вариаций реализации монолитов/микросервисов много. Ругать или хвалить стоит конкретные решения, но зачастую это будут субъективные плюсы и минусы для определенного проекта/задачи.
А вообще делайте как хотите и что хотите. Ведь неважно хороший или плохой вы сапожник, всё равно вы сделаете сапог и получите опыт. Теория тоже важна, но опыт сложнее получить.
PS. Я не говорю что не нужно учиться, Я за то, чтобы набивались шишки, а когда не будет хватать теории (будут конкретные проблемы), то её можно будет гораздо легче получить, нежели находиться в фрустрации и искать идеальное решение.
https://github.com/web-infra-dev/rspack/releases/tag/v1.1.8
Я вроде не консерватор, но каждая подобная новость добавляет баллы "старому и проверенному".
@evgeniyrruвы не подхватили?)
Я как минимум 3 расшифровки DDD знаю, о каком именно идеи речь?)
@TldrWiki @yurchenko_oleg
У меня к вам вопрос немного не по теме. Вы работали с монгой? А то мимо меня как-то она прошла стороной и на проде ни в каком проекте не использовали...
Монга советует придерживаться денормализации данных для избегания джойнов. Но в то же время имеет ограничение на размер документа (16мб, вроде и не мало). Но если у нас приложение (бл) основывается на пользовательском вводе, то в теории пользователь будет упираться в лимит документа при сохранении данных.
Было ли у вас такое? И если изначально нет никаких ограничений на размер документа (связей), не является ли реляционная база тогда лучшим выбором?
Просто сколько не видел примеров использования монги, везде данные нормализуются, из-за чего появляются джойны...
Как я понял, у вас проблема в том, что вы говорите о разных уровнях абстракции согласованности. На уровне бл и на уровне бд.
Вот и у меня при прочтении сложилось впечатление что написана теоретиком для теоретиков. Всё описано слишком абстрактно, без конкретики, без примеров...
При чем тут перекрытие?
Вот перекрытие.
Это вечная проблема "волшебной таблетки".
Курсы преподносят себя именно как её. И много скама по заработку преподносят себя как волшебную таблетку с доходностью 500% в месяц.
Т.е. как по мне, проблема не в курсах, а в том, что люди начинают считать что кроме курсов ничего не надо. Могут спрашивать "А какие видео на Ютубе посмотреть?", будто после просмотра научится всё делать... Но важен не сам контент, а то, как обрабатывает человек полученную информацию.
см первый абзац.
К тому же я написал, что наиболее сравнимое, а не точь-в-точь. Как минимум, IT до сих пор развивается, а медицина — уже развитая отрасль. И стоит смотреть не только на текущее положение дел, но и на весь путь развития других отраслей.
Джун, Мидл, Сеньор - бессвязный набор слов, если их использовать без спецификации.
В жизни нужно быть проще, а не меряться лычками, т.к. иной раз "Джун" может принести больше пользы, чем "Сеньор". Как минимум "Джун" в одной области может оказаться гораздо смышленее в другой, которая как раз и будет полезнее в конкретной ситуации.
Опыт это не просто про время. Смысл сравнивать разработчика лендингов со стажем 10 лет, и, допустим, разработчика бд? Это разные весовые категории, но они все нужны (Все профессии важны, все профессии нужны). Даже если брать двух разработчиков с одинаковым стэком, то окажется, что опыт за года у них был разный.
Я не понимаю зачем унифицировать друг-друга, если это не даёт бенефитов. Ещё до недавнего времени "разработчики" и "программисты" в глаза общественности были гиками, которые могут починить утюг. А при помощи таких унификаций создаётся только иллюзия. Т.к. упрощение сложного (комплексного) не ведёт ни к чему хорошему.
Для меня наиболее сравнимое с IT это система здравоохранения. Есть терапевты, хирурги, медсестры, бухгалтера, администраторы и т.д., которые в этих больших группах делятся на ещё мельче (кардиохирург, нейрохирург и т.д.). Да, есть в медицине что-то смежное, что-то базовое, что знают вне зависимости от конкретной профессии. И каждая профессия важна. А в IT будто решили изобрести велосипед и пройтись по всем граблям, вместо того, чтобы взять и использовать лучшие практики из других отраслей.
Вообщем весь коммент сводится к тому, что упрощение всего опыта человека до банальных "Джун", "Мидл", "Сеньор" не даст ничего, кроме какой-то иллюзии.
Я говорил именно про обучение с 5-6 лет.
Я не говорю, что системный подход не нужен, Я говорю про то, что учебная программа для 5 летних и 12 летних будет разной. И если в 5 лет обучать чему-то более общему, нежели конкретно программированию, то это не означает, что более общее не относится к обучению программированию.
Так же как и в программировании важно не только уметь программировать, но и уметь обучаться, т.к. каждый день появляются новые технологии которые окажут влияние через год-два-три и т.д., игнорирование которых поставит в слабую позицию.
Вообщем мой тезис сводится к тому, что обучение программированию это не только про сам код/анализ/проектирование.
Смотря что понимать под обучением. Есть комп игры, которые обучают логике в игровой форме. Да, это развивающие игры более общего плана, а не конкретно программированию, но всё же помогут и в изучении программированию в дальнейшем.
До сих пор помню бесящий уровень с рыболовной сетью из Медвежонка Плюма... Эту игру мне дали, когда было 5-6 лет.
От JWT нет пользы в большинстве проектов.
Он нужен только для оптимизации запроса данных из других сервисов, только тогда выигрыш производительности нивелирует проблемы безопасности.
Если вы в JWT храните недостаточно данных (id пользователя и, допустим, роль) и затем запрашиваете все остальные данные в бд, то совокупного выигрыша нет.
Ну и зачем тогда jwt? Чтобы лишний раз парсить и валидировать?
А чёрное где хранить? А нельзя ли было там просто хранить строковую сессию?
https://habr.com/ru/articles/502702/comments/#comment_21636220
Кто жалуется на технологию? Я написал, что она переоценена, разве это не правда?
Тут скорее вопрос о том, в каких конкретных случаях использовать jwt выгодно. Т.к. в подавляющем большинстве случаев в jwt просто хранится id текущего пользователя (и ещё какие-то идшники), что не решает проблему с запросами к бд.
Я нашел только один случай, когда в jwt есть смысл - кэширование не секретных данных, чтобы разгрузить бд. Но это не нужно, либо хранится только id в 99%.
Как по мне, указанный вами пример с монолитом/распределенной системой не является аргументом за jwt, т.к. описанный случай решается гейтвеем.
Тот же вопрос и про jwt.
Как по мне, jwt самая переоцененная вещь. Если мы хотим меньше делать запросов к бд, то возникают проблемы с принудительной инвалидацией токенов. Или как в данном случае общение происходит в доверенной сети и непонятно для чего jwt в принципе пихать...
Вот даже откопал:
https://habr.com/ru/articles/502702/comments/#comment_21636220
Это приложение не для знакомств (в плане отношений), а чисто для мужской дружбы.
Как я это понял?
Прошёл тесты, в совпадениях чуть больше десяти девушек возрастом 35-52 и совпадением в районе 73%.
Поменял пол на Ж, сменил поиск на М, появилось куча парней 25-35 с совпадением 85% =)
По поводу "опыта" и "проекта в породе".
Можно же новичкам наработать опыт и получить проект в портфолио на фрилансе. Помимо фриланс платформ есть форумы с заказами (они ещё живы).
Оплата скорее всего будет не велика, ровно как и нет 100% вероятности что вы найдете проект под свой стэк, но всё же для веба (в т.ч. и бэка) найти не сложно. А с учётом, что на бэке можно использовать любой ЯП (не приходит на ум ЯП, который бы нельзя было использовать на бэке), то велика вероятность, что у вас появится проект в портфолио.
Насколько знаю, сейчас относятся скептически к фрилансе в резюме, но всё же если речь про джуна, тем более с прикрепленным проектом, то пойдёт только в плюс.