На текущий момент python в основном это для обучения и небольших скриптов, писать на нем крупные апи бизнесовых приложений не лучшая идея, не то что бы нельзя просто премуществ нет, одни недостатки.
Не совсем, на ноде прекрасно себя чувствуют большие проекты. А вот про не быстрое это да. Но скорость в реальности это тоже очень редкий кейс для бэкэнда. В большинстве бизнес приложений узким местом является БД. И по совокупности факторов у ноды очень много преимуществ. TypeScript высокоуровннвый язык и имеет много плюсов в плане времени разработки и при этом обладает типизацией что не типично для интерпритируемых языков но дает огромные плюсы в плане поддержки. Кроме того большинство разработчиков в вебе в какой то степени с ним знакомы. С точки зрения бизнеса на текущий момент, вряд ли какой либо язык обладает таким набором приемуществ. Поэтому на текущий момент, нода это мейнстрим. А вот для Go все очень туманно для хайлоада пришел Rust для скорости разработки Нода. Мне очень нравится Го как язык но к сожалению на мой взгляд для него просто нет места на рынке. Go очень дорогой не супер быстрый, количнство проектов не так велико, кроме того что он приятный в плане читаемости кода больше нечего выделить.
Проекты на python в целом не очень поддерживаются, да и среднее качество кода оставляет желать лучшего. Если вы пишите что то больше чем на 1000 строк кода, просто не делайте это на питоне. Это язык для студентов и дев опсов. В остальных случаях лучше его не использовать. Да на чем угодно можно писать качественный код но на python это гораздо сложнее.
Сейчас дизайнерам и художникам нужна видеокарта, что бы генерить картинки на локалке. NPU в процессоре позволят это делать на ультрабуках на которых они привыкли работать и в которых нет дискретных видеокарт. Уже тот же SDXL можно запустить на core i5 ultra без видеокарты. Когда раньше без дискретки на 8гб минимум твой пк шел лесом.
Так же как с цпу и гпу в том же тензорфлоу для цпу пишешь (CPU:0) для гпу (GPU:0), для нпу будет (NPU:0), в винду ,по крайней мере для интела, уже добавили мониторинг в диспетчер задач. Поставил драйвер и пользуйся никаких проблем. По сути еще одна видеокарта выбрал адаптер и в путь.
Перемудрили. Что вообще за UI shell и зачем. Просто было нужно развести роутами через nginx и все бы было круто, разные спа на одном домене, сборка через ci, хотите общий модуль залейте его в приватный package registry. Всегда все работает без проблем.
П.С. И что вообще за вакханалия с импортами. Из прочитаного кажется что все запускается в дев моде и тащит модули через инет ленивой загрузкой, пытаясь подключать их налету или собрать кучу разных фреймворков одним сборщиком. Если что то из этого то не делайте так.
Поможет только одно. Кэши и оптимизация запросов на стороне приложений.
В самих бд нет большого смысла что то менять, максимум репликацию при масштабировании добавить и следить за нагрузкой. Все ошибки ведущие к снижению скорости созданы на стороне приложений и решаются там же.
Проблема в том что, огромную часть контента на платформе создают контент менеджеры. За эффективностью работы которых следят маркетологи и раньше их работу можно было делать не качественно. А настоящие творцы думаю ждали этот функционал. А вот у фуфлогонов маркетологи мракобесы и возможность оценивать их работу это все от лукавого.
Странная реакция вызвана, нездоровым количеством бутафорного проплаченного контента от контент менеджеров компаний над реальным от авторов.
Ну дегарадируют они все по мере роста количества данных. А проблемы определяются метриками которые человек выше описал. Как правило узкое горлышко, упирается в потолок проц, память, диск.
Ну я из прочитаного понял, что ваша компания все так же имеет все те же роли и должности что и до этого. Нововведение в том что раз в пол года люди могут снять начальника который им не нравиться голосованием. И получить должность фразой 'если никто не хочет я попробую'. А круги это пафасное название набора руководящих ролей. На мой взгляд это обычная вертикаль, с парой особенностей.
И все же нестандартность подхода вызывает интерес.
Нет смысла искать недостатки в WP их список практически бесконен. Важно то что у тебя практически нет альтернатив, когда тебе нужно сео и контент менеджмент из коробки. Поисковики очень плохо работают с js фреймворками, практически никак, и даже если это решить костылями. Результат будет не тот. Так что только CMS в этих случаях, есть и другие походы но долго и дорого.
А среди цмс выбирать сильно не приходится они все ужасны.
Игры с дисков переехали в онлайн сервисы, баги стало возможно фиксить после релиза, а маркетологи с бюджетами геймдева, могут продать что угодно. Единого клиента который платит всю сумму и не примает работу с багами у них нет. Пока окупается можно лить говно в прод.
И повышенная сложность геймдева миф. Большая часть бюджета это 3д модели, заставки киношного уровня и маркетинг. А 2 десятка механик делается за месяц несколькими разрабами. Гемдизайнеры это потом просто как конструктор собирают. В общем самое дорогое в играх это контент который мало связан с разработкой.
Если рассматривать скрам как методологию то она хороша. Если как компанию то они моральные уроды которые впаривают скрам там где он не нужен и тем кому он не нужен, обещая что он решит их все их праблемы. Мало того остальные компании берут дезинформацию от скрам и желая приобщиться к мейнстриму начинают врать уже о своих продутках. А в итоге страдают разработчики которые даже не предусмотренны как роль в самой методологии.
Вы путаете проекты с продуктами. Продукты динамичны и постоянно развиваются. Проекты нет, они выполняются для достижения коннчных определенных целей и задачи проекта всегда известны заранее.
У водопада нет проблем, все адекватные команды его применяют уже больше 60 лет, он идеален для разработки т.к. создан именно для нее. А скрам предназначен для взаимодействия овнеров с подрядчиками. Это не конкурентные методологии они предназначены для разных вещей.
Но вообще проблема даже не в методологии а в ее понимании людьми, и в том что ее впаривают тем кому она совсем не нужна.
Скрам это методология развития своего продукта предназначенная для продуктовых компаний и не предназначенная для команд разработки. Роли в скрам всего 3 это Владелец продукта (тот кто пытается построить бизнес), Скрам менеджер (тот кому владелец продукта должен отдать деньги за то что тот научит его правильно взаимодействовать с внешними подрядчиками либо с отделом разработки) и команда (и тут главная проблема, многие понимают под этим команду целиком, хотя подразумевается Проджект менеджер и Архитектор).
И существуют компании и отделы разработки которые состоят из проджекта, архитектора, тимлида, дизайнеров, программистов, тестровщиков и девопсов. И из них только архитектор и пм должны взаимодействовать с овнером в рамках скрам. Сама же команда разработки должна реализовывать вотерфол. Т.е. на каждый спринт в рамках оценки по скрам должно быть написано ТЗ, и по нему должна производится разработка в формате вотерфола.
А идиоты пытаются натянуть методологию предназначенную для 2х ролей и временного помощника. На систему в которой 6+ и больше разных ролей и каждый раз терпят крах.
Для понимания скрам мастер по задумке не должен участвовать в бизнес процессе. Его задача прийти в компанию на 1-3 мес, наладить скрам процессы (как правило написать расписание митингов, объяснить менеджеру что он должен вести продакт лог и делить проект на спринты) и покинуть компанию.
Agile манифест, создан разработчиками и и говорит примерно следующее:
Давайте мы не будем называть сроки и стоимость, и не будем не за что отвечать. Все это во благо гибкости продукта конечно. Бизнес ответил, ну раз во благо продукта то ладно.
Потом пришли менеджеры и сказали, мы тоже хотим быть гибкими и представили скрам который говорит о следующем:
Давайте мы не будем ставить конкретных целей и менять их каждый день, и не будем не за что отвечать. Все это во благо гибкости продукта конечно. Бизнес ответил, ну раз во благо продукта то ладно.
Итог: бизнес умер. ПС: Agile это не методология а список влажных фантазий разработчиков. Scrum тоже не методология, это продукт инфоциган который замаскирован под методологию для продажи сертификатов. На эту хрень ведутся только только нерадивые руководители которые не способны наладить бизнес процессы в своей компании и ищут серебряную пулю, как следствие тут же попадают на мошенников в лице скрам.
ПС2: Все сказанное основано, на моем опыте, более 12 лет в разработке на разных позициях от разработчика до директора в компаниях заказной разработки. Я точно знаю что ни одна компания разработчик занимающаяся чем то сложнее разработки лэндосов не смогла решить свои проблемы при помощи Scrum и Agile. Все описанные выше проблемы легко решаемы внедрением риск менеджмента, объективных средств контроля и правильного KPI.
Проблема с оценкой была есть и будет. Эту проблему решает риск менеджмент, который как правило не упоминается в методиках разработки ПО. Для решения этой проблемы всего то требуется получить ТЗ с оценкой задач и заложить риски на весь проект 10-50% в зависимости от сложности проекта. И как результат менеджер просто спокойно выделяет время на задачи с которыми ошиблись в оценке. Ничего сложного.
Но к сожалению в ИТ об этом не говорят, там повсеместно либо scrum либо agile. Скрам это когда победил менеджмент, а agile когда победила команда разработки. В обоих случаях будут проблемы, это просто смещение фокуса. Хорошее ТЗ + менеджмент рисков являются решением этих проблем. Проблемы из статьи не имеют никакого отношения к методологии разработки, это некомпетентность руководства и не способность организовать бизнес процесс.
На текущий момент python в основном это для обучения и небольших скриптов, писать на нем крупные апи бизнесовых приложений не лучшая идея, не то что бы нельзя просто премуществ нет, одни недостатки.
Не совсем, на ноде прекрасно себя чувствуют большие проекты. А вот про не быстрое это да. Но скорость в реальности это тоже очень редкий кейс для бэкэнда. В большинстве бизнес приложений узким местом является БД. И по совокупности факторов у ноды очень много преимуществ. TypeScript высокоуровннвый язык и имеет много плюсов в плане времени разработки и при этом обладает типизацией что не типично для интерпритируемых языков но дает огромные плюсы в плане поддержки. Кроме того большинство разработчиков в вебе в какой то степени с ним знакомы. С точки зрения бизнеса на текущий момент, вряд ли какой либо язык обладает таким набором приемуществ. Поэтому на текущий момент, нода это мейнстрим. А вот для Go все очень туманно для хайлоада пришел Rust для скорости разработки Нода. Мне очень нравится Го как язык но к сожалению на мой взгляд для него просто нет места на рынке. Go очень дорогой не супер быстрый, количнство проектов не так велико, кроме того что он приятный в плане читаемости кода больше нечего выделить.
Проекты на python в целом не очень поддерживаются, да и среднее качество кода оставляет желать лучшего. Если вы пишите что то больше чем на 1000 строк кода, просто не делайте это на питоне. Это язык для студентов и дев опсов. В остальных случаях лучше его не использовать. Да на чем угодно можно писать качественный код но на python это гораздо сложнее.
Сейчас дизайнерам и художникам нужна видеокарта, что бы генерить картинки на локалке. NPU в процессоре позволят это делать на ультрабуках на которых они привыкли работать и в которых нет дискретных видеокарт. Уже тот же SDXL можно запустить на core i5 ultra без видеокарты. Когда раньше без дискретки на 8гб минимум твой пк шел лесом.
Так же как с цпу и гпу в том же тензорфлоу для цпу пишешь (CPU:0) для гпу (GPU:0), для нпу будет (NPU:0), в винду ,по крайней мере для интела, уже добавили мониторинг в диспетчер задач. Поставил драйвер и пользуйся никаких проблем. По сути еще одна видеокарта выбрал адаптер и в путь.
Перемудрили. Что вообще за UI shell и зачем. Просто было нужно развести роутами через nginx и все бы было круто, разные спа на одном домене, сборка через ci, хотите общий модуль залейте его в приватный package registry. Всегда все работает без проблем.
П.С. И что вообще за вакханалия с импортами. Из прочитаного кажется что все запускается в дев моде и тащит модули через инет ленивой загрузкой, пытаясь подключать их налету или собрать кучу разных фреймворков одним сборщиком. Если что то из этого то не делайте так.
На хабре любят минусить за здравый смысл.
Поможет только одно. Кэши и оптимизация запросов на стороне приложений.
В самих бд нет большого смысла что то менять, максимум репликацию при масштабировании добавить и следить за нагрузкой. Все ошибки ведущие к снижению скорости созданы на стороне приложений и решаются там же.
Проблема в том что, огромную часть контента на платформе создают контент менеджеры. За эффективностью работы которых следят маркетологи и раньше их работу можно было делать не качественно. А настоящие творцы думаю ждали этот функционал. А вот у фуфлогонов маркетологи мракобесы и возможность оценивать их работу это все от лукавого.
Странная реакция вызвана, нездоровым количеством бутафорного проплаченного контента от контент менеджеров компаний над реальным от авторов.
Ну дегарадируют они все по мере роста количества данных. А проблемы определяются метриками которые человек выше описал. Как правило узкое горлышко, упирается в потолок проц, память, диск.
Ну я из прочитаного понял, что ваша компания все так же имеет все те же роли и должности что и до этого. Нововведение в том что раз в пол года люди могут снять начальника который им не нравиться голосованием. И получить должность фразой 'если никто не хочет я попробую'. А круги это пафасное название набора руководящих ролей. На мой взгляд это обычная вертикаль, с парой особенностей.
И все же нестандартность подхода вызывает интерес.
Нет смысла искать недостатки в WP их список практически бесконен. Важно то что у тебя практически нет альтернатив, когда тебе нужно сео и контент менеджмент из коробки. Поисковики очень плохо работают с js фреймворками, практически никак, и даже если это решить костылями. Результат будет не тот. Так что только CMS в этих случаях, есть и другие походы но долго и дорого.
А среди цмс выбирать сильно не приходится они все ужасны.
Игры с дисков переехали в онлайн сервисы, баги стало возможно фиксить после релиза, а маркетологи с бюджетами геймдева, могут продать что угодно. Единого клиента который платит всю сумму и не примает работу с багами у них нет. Пока окупается можно лить говно в прод.
И повышенная сложность геймдева миф. Большая часть бюджета это 3д модели, заставки киношного уровня и маркетинг. А 2 десятка механик делается за месяц несколькими разрабами. Гемдизайнеры это потом просто как конструктор собирают. В общем самое дорогое в играх это контент который мало связан с разработкой.
Если рассматривать скрам как методологию то она хороша. Если как компанию то они моральные уроды которые впаривают скрам там где он не нужен и тем кому он не нужен, обещая что он решит их все их праблемы. Мало того остальные компании берут дезинформацию от скрам и желая приобщиться к мейнстриму начинают врать уже о своих продутках. А в итоге страдают разработчики которые даже не предусмотренны как роль в самой методологии.
Вы путаете проекты с продуктами. Продукты динамичны и постоянно развиваются. Проекты нет, они выполняются для достижения коннчных определенных целей и задачи проекта всегда известны заранее.
У водопада нет проблем, все адекватные команды его применяют уже больше 60 лет, он идеален для разработки т.к. создан именно для нее. А скрам предназначен для взаимодействия овнеров с подрядчиками. Это не конкурентные методологии они предназначены для разных вещей.
Но вообще проблема даже не в методологии а в ее понимании людьми, и в том что ее впаривают тем кому она совсем не нужна.
Скрам это методология развития своего продукта предназначенная для продуктовых компаний и не предназначенная для команд разработки. Роли в скрам всего 3 это Владелец продукта (тот кто пытается построить бизнес), Скрам менеджер (тот кому владелец продукта должен отдать деньги за то что тот научит его правильно взаимодействовать с внешними подрядчиками либо с отделом разработки) и команда (и тут главная проблема, многие понимают под этим команду целиком, хотя подразумевается Проджект менеджер и Архитектор).
И существуют компании и отделы разработки которые состоят из проджекта, архитектора, тимлида, дизайнеров, программистов, тестровщиков и девопсов. И из них только архитектор и пм должны взаимодействовать с овнером в рамках скрам. Сама же команда разработки должна реализовывать вотерфол. Т.е. на каждый спринт в рамках оценки по скрам должно быть написано ТЗ, и по нему должна производится разработка в формате вотерфола.
А идиоты пытаются натянуть методологию предназначенную для 2х ролей и временного помощника. На систему в которой 6+ и больше разных ролей и каждый раз терпят крах.
Оценка трудозатрат и оценка сроков это 2 разные оценки. Абстрактные единицы отражают стоимость а не сроки.
Для понимания скрам мастер по задумке не должен участвовать в бизнес процессе. Его задача прийти в компанию на 1-3 мес, наладить скрам процессы (как правило написать расписание митингов, объяснить менеджеру что он должен вести продакт лог и делить проект на спринты) и покинуть компанию.
Полностью согласен.
Agile манифест, создан разработчиками и и говорит примерно следующее:
Давайте мы не будем называть сроки и стоимость, и не будем не за что отвечать. Все это во благо гибкости продукта конечно. Бизнес ответил, ну раз во благо продукта то ладно.
Потом пришли менеджеры и сказали, мы тоже хотим быть гибкими и представили скрам который говорит о следующем:
Давайте мы не будем ставить конкретных целей и менять их каждый день, и не будем не за что отвечать. Все это во благо гибкости продукта конечно. Бизнес ответил, ну раз во благо продукта то ладно.
Итог: бизнес умер.
ПС: Agile это не методология а список влажных фантазий разработчиков.
Scrum тоже не методология, это продукт инфоциган который замаскирован под методологию для продажи сертификатов. На эту хрень ведутся только только нерадивые руководители которые не способны наладить бизнес процессы в своей компании и ищут серебряную пулю, как следствие тут же попадают на мошенников в лице скрам.
ПС2: Все сказанное основано, на моем опыте, более 12 лет в разработке на разных позициях от разработчика до директора в компаниях заказной разработки. Я точно знаю что ни одна компания разработчик занимающаяся чем то сложнее разработки лэндосов не смогла решить свои проблемы при помощи Scrum и Agile. Все описанные выше проблемы легко решаемы внедрением риск менеджмента, объективных средств контроля и правильного KPI.
Проблема с оценкой была есть и будет. Эту проблему решает риск менеджмент, который как правило не упоминается в методиках разработки ПО. Для решения этой проблемы всего то требуется получить ТЗ с оценкой задач и заложить риски на весь проект 10-50% в зависимости от сложности проекта. И как результат менеджер просто спокойно выделяет время на задачи с которыми ошиблись в оценке. Ничего сложного.
Но к сожалению в ИТ об этом не говорят, там повсеместно либо scrum либо agile. Скрам это когда победил менеджмент, а agile когда победила команда разработки. В обоих случаях будут проблемы, это просто смещение фокуса. Хорошее ТЗ + менеджмент рисков являются решением этих проблем. Проблемы из статьи не имеют никакого отношения к методологии разработки, это некомпетентность руководства и не способность организовать бизнес процесс.