На демонстрации так и было, но это была демонстрация возможностей. Судя по этой статье, технология вообще не предназначена для старых игр, dlss5 это замена почти всей части пайплайна DirectX и Vulkan которая выполнялась на видеокарте и в теории отказ от шейдеров и кучи настроек. А может до хейта они и в серьёз пытались скормить людям нейрослоп в 6000 серии, а теперь выкручиваются. Вообще не исключено. Опять же если это первый вариант, то первые нормальные игры с этим чудом мы увидим года через 3.
Люди просто не понимают что тут написано, единственное что понятно большинству это то что работать будет только начиная с 5000 серии и опять нужно денег. Они не знают что такое рендеринг как он работает, даже те кто много в игры играет. А по факту dlss5, это революция в том самом рендеринге сравнить которую можно разве что с появлением 3д графики в кино и играх. Многие ждут этого очень давно. А вообще это маркетологи обосралась, нефиг было это dlss5 называть, тем более с учётом того что эта технология не имеет ничего общего с dlss как и калечный фреймген которые до появления в видеокартах и так 15 лет работал на мобильных процессорах в тв с такими же задержками.
На текущий момент 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 мес, наладить скрам процессы (как правило написать расписание митингов, объяснить менеджеру что он должен вести продакт лог и делить проект на спринты) и покинуть компанию.
На демонстрации так и было, но это была демонстрация возможностей. Судя по этой статье, технология вообще не предназначена для старых игр, dlss5 это замена почти всей части пайплайна DirectX и Vulkan которая выполнялась на видеокарте и в теории отказ от шейдеров и кучи настроек. А может до хейта они и в серьёз пытались скормить людям нейрослоп в 6000 серии, а теперь выкручиваются. Вообще не исключено. Опять же если это первый вариант, то первые нормальные игры с этим чудом мы увидим года через 3.
Люди просто не понимают что тут написано, единственное что понятно большинству это то что работать будет только начиная с 5000 серии и опять нужно денег. Они не знают что такое рендеринг как он работает, даже те кто много в игры играет. А по факту dlss5, это революция в том самом рендеринге сравнить которую можно разве что с появлением 3д графики в кино и играх. Многие ждут этого очень давно. А вообще это маркетологи обосралась, нефиг было это dlss5 называть, тем более с учётом того что эта технология не имеет ничего общего с dlss как и калечный фреймген которые до появления в видеокартах и так 15 лет работал на мобильных процессорах в тв с такими же задержками.
На текущий момент 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 мес, наладить скрам процессы (как правило написать расписание митингов, объяснить менеджеру что он должен вести продакт лог и делить проект на спринты) и покинуть компанию.