Я часто замечал ещё одну печальную тенденцию, как человек который делает утилиты для игр.
Компании (и инженеры в них), которые делают или допиливают движки слишком поздно начинают задумываться об интеграции движка/игры с редакторами.
Из последнего - пришлось пару лет назад чинить производительность в некоторых местах редактора, одного из упомянутых в статье культового движка. И очень уж бросались в глаза места где решения принимались по принципу:
Пока производительность не важна, потом оптимизируем, лишь бы получить mvp
Сейчас куча задач по движку, давайте эту часть редактора отдадим на аутсорсинг или джуно-мидлам, пусть учатся, заодно и задачи закроем
Давайте наймём сеньоров, которые шарят в [framework_name] и сделают хорошо. Но «всё выкинуть и переписать» - это джуновский подход, мы так делать не будем, поэтому делайте костыли в тысячи строк, которые точечно решат некоторые проблемы, и, если повезет, не сильно ушатают редактор.
Да да, у нас редактор не запускается в debug сборке в принципе, потому что десяток лет назад, в п.1 мы внесли несколько UB и ключевые компоненты висят на соплях. И ещё куча аналогичных проблем.
Либо ещё ситуация, которую встречал в двух разных, никак не связанных между собой студиях:
Кладем болт на проектирование тулзов, ведь главное супер крутой и производительный движок, и хорошие программисты
Получаем пачку несвязанных инструментов. И чтобы поменять текстуру на объекте, дизайнерам надо запускать 2-3 программы и прогонять сверху питоновский скрипт.
Дальше так жить нельзя, давайте изобретем универсальный фреймворк, для разработки тулзов, который будет правильно интегрирован с движком и каждая команда будет самостоятельно и успешно делать всё в рамках единой концепции
Дизайнеры продолжают пользоваться старыми тулзами, ругаться на что они практически не поддерживаются в угоду нового супер-пупер-редактора, который либо ещё слишком глючный либо ещё не поддерживает все фичи старых редакторов.
Менеджмент начинает давить на команду тулзовиков, просить меньше думать об архитектуре, качестве кода и производительности, в угоду скорейшего выпуска mvp.
Ну и приходим к очередной итерации того, что было написано вначале.
Лично я смотрю на экран, камеры (балуюсь любительской сьемкой), автономность работы и надежность экосистемы. Всё. Зачем именно телефону ИИ - я без понятия. Максимум - нейросети для пост обработки фото.
Третий абзац статьи. Там говорится про QML. Так же как и в оглавлении книги.
А вообще, виджеты достаточно стабильная технология для десктопов и она поддерживается до сих пор, просто новых фичей не добавляют. Но у виджетов есть ряд фундаментальных проблем:
Виджеты жрут CPU на основном потоке и провоцируют на микс бизнес и UI логики. Из-за этого сложно чинить производительность в легаси системах.
Очень слабая и ресурсоёмка поддержка анимаций интерфейса.
Неудобная кастомизация (часто через тормознутый qss, который сами ребята из Qt не рвутся оптимизировать).
Непонятно из статьи, насколько глубоко в книге раскрыты современные практики по разработке интерфейсов на QML / QtQuick? Как я понял, основной упор делается на виджеты, а для современных проектов, где нужна нормальная поддержка dpi scaling или для мобильных систем / HMI это уже не особо подходит.
Я больше склоняюсь к тому, что это эффективные манагеры экономят за счет монополии Яндекса. Типа пофиг, что некоторые клиенты страдают, пока монополия - бизнесу это не повредит. И это очень грустно. С одной стороны я сейчас для своих проектов осваиваю userver, с ребятами из Яндекса общаться одно удовольствие, а с другой, конечные продукты обрастают толстым слоем всякого *****.
P.S. в моем случае была ситуация, что у меня отвалился семейный аккаунт в РБ: белорусская карта привязана, сам аккаунт на белорусской симке, впн с точкой выхода в РБ, но я так и не смог его восстановить и мой папа б не мог пользоваться моей картой. Причем отвязать карту от своего аккаунта и привязать карту к его аккаунту я не смог. «Поддержка» пол года кормила завтраками, но по существу так и не помогла.
Ну я пробовал только в РБ и Узбекистане. Последний - вообще тяжелый случай. А вот в Беларуси раньше было всё ок, попросишь проэскалировать и соединяли с следующей линией поддержки и действительно решали вопросы. Примерно года до 2022.
С вами общались примерно так же, как разговаривает типовая техподдержка Яндекса в РБ. То есть никак. Теперь мы знаем, что так общаться могут не только боты, но и люди (возможно, ботов на них обучали). С какого-то времени получить адекватный ответ на реальные проблемы с чёткими шагами воспроизведения просто невозможно. Всё сводится к методичке: почистите кэш на iOS, переустановите ОС, откройте карточку в другом банке, до свидания, мы больше ничем вам не можем помочь.
Правильная идиома: после std::moveотноситесь к объекту так, как будто он только что был создан конструктором по умолчанию.
Ни разу она не правильная. Объект после перемещения нельзя так трактовать. Таких гарантий нет, особенно для пользовательских типов. Есть лишь правило, что объект должен быть в корректном состоянии, чтобы нормально мог отработать деструктор - этого достаточно понимать.
А сырые указатели и ручной new / delete вообще не нужно использовать в подводящем большинстве случаев. Как правило, за исключением реализации собственных контейнеров или умных указателей.
Вы знаете, есть такая полезная штука - вычитка. С картинками глаз не так замыливается как с текстом и такие вещи должны легко отлавливаться. Конечно же, если вы уважаете комьюнити, а не просто раскручиваете аккаунт.
К примеру, на тех же код ревью, я всегда вычитываю свой код так, как будто я - ревьювер. И только потом отдаю это на проверку команде и далее по процессу.
У вас на первой картинке ошибка, порядок действий неверный: 1-2-3-4-7-6-5, а должно быть последовательно. Оплата налогов и успешный ввоз не может чисто логически произойти до пересечения товаром границы :)
Пользователь приходит сюда заказать еду или выбрать ресторан.
Как пользователь, когда я хочу сходить в ресторан, я открываю интересующий меня район в картах и уже там перебираю рестораны.
Но, к сожалению, это уже не новая тенденция Яндекса - делать «супер приложения» для втюхивания большего количества рекламы. Когда основному функционалу приложения отводится менее 50% а то и 80% места на экране.
Вот и приходится продираться сквозь все эти высоко оптимизированные слои спама, чтобы добраться до основной функциональности - доставки еды.
P.S. с технической точки зрения было интересно почитать, спасибо.
Таким не занимался, но все равно мне кажется, что раз уж перехватываем создание потока, то можно и проинициализировать всё нужное самим.
Я бы делал так, берём тот же detours, заменяем CreateThread на свой, где вначале делается инициализация ну и ждем по какому нибудь мьютексу (который в винапи CreateEvent) сигнала к запуску оригинальной функции потока.
Впрочем ок, пусть будет такой флаг. Для таких тонких вещей платформозависимый код это, как правило, необходимость.
А какой практический пример у этого флага? Если процесс ещё понятно (вдруг, что-то пропатчить налету надо, до первой команды), то с потоком - не понятно.
Я часто замечал ещё одну печальную тенденцию, как человек который делает утилиты для игр.
Компании (и инженеры в них), которые делают или допиливают движки слишком поздно начинают задумываться об интеграции движка/игры с редакторами.
Из последнего - пришлось пару лет назад чинить производительность в некоторых местах редактора, одного из упомянутых в статье культового движка. И очень уж бросались в глаза места где решения принимались по принципу:
Пока производительность не важна, потом оптимизируем, лишь бы получить mvp
Сейчас куча задач по движку, давайте эту часть редактора отдадим на аутсорсинг или джуно-мидлам, пусть учатся, заодно и задачи закроем
Давайте наймём сеньоров, которые шарят в [framework_name] и сделают хорошо. Но «всё выкинуть и переписать» - это джуновский подход, мы так делать не будем, поэтому делайте костыли в тысячи строк, которые точечно решат некоторые проблемы, и, если повезет, не сильно ушатают редактор.
Да да, у нас редактор не запускается в debug сборке в принципе, потому что десяток лет назад, в п.1 мы внесли несколько UB и ключевые компоненты висят на соплях. И ещё куча аналогичных проблем.
Либо ещё ситуация, которую встречал в двух разных, никак не связанных между собой студиях:
Кладем болт на проектирование тулзов, ведь главное супер крутой и производительный движок, и хорошие программисты
Получаем пачку несвязанных инструментов. И чтобы поменять текстуру на объекте, дизайнерам надо запускать 2-3 программы и прогонять сверху питоновский скрипт.
Дальше так жить нельзя, давайте изобретем универсальный фреймворк, для разработки тулзов, который будет правильно интегрирован с движком и каждая команда будет самостоятельно и успешно делать всё в рамках единой концепции
Дизайнеры продолжают пользоваться старыми тулзами, ругаться на что они практически не поддерживаются в угоду нового супер-пупер-редактора, который либо ещё слишком глючный либо ещё не поддерживает все фичи старых редакторов.
Менеджмент начинает давить на команду тулзовиков, просить меньше думать об архитектуре, качестве кода и производительности, в угоду скорейшего выпуска mvp.
Ну и приходим к очередной итерации того, что было написано вначале.
Это почему же ИИ - причина выбора телефона?
Лично я смотрю на экран, камеры (балуюсь любительской сьемкой), автономность работы и надежность экосистемы. Всё. Зачем именно телефону ИИ - я без понятия. Максимум - нейросети для пост обработки фото.
Короче, вообще ничего нового, если по Qt gRPC и QML лишь базовые вещи.
Все люди делятся на тех кто делает бэкапы важных данных и кто будет их делать.
[s]Конечно же виноваты массоны [/s], а не огромная нагрузка на GPU из-за Liquid Glass.
Мне кажется, вы ошиблись сайтом для таких публикаций.
Третий абзац статьи. Там говорится про QML. Так же как и в оглавлении книги.
А вообще, виджеты достаточно стабильная технология для десктопов и она поддерживается до сих пор, просто новых фичей не добавляют. Но у виджетов есть ряд фундаментальных проблем:
Виджеты жрут CPU на основном потоке и провоцируют на микс бизнес и UI логики. Из-за этого сложно чинить производительность в легаси системах.
Очень слабая и ресурсоёмка поддержка анимаций интерфейса.
Неудобная кастомизация (часто через тормознутый qss, который сами ребята из Qt не рвутся оптимизировать).
Непонятно из статьи, насколько глубоко в книге раскрыты современные практики по разработке интерфейсов на QML / QtQuick? Как я понял, основной упор делается на виджеты, а для современных проектов, где нужна нормальная поддержка dpi scaling или для мобильных систем / HMI это уже не особо подходит.
Я больше склоняюсь к тому, что это эффективные манагеры экономят за счет монополии Яндекса. Типа пофиг, что некоторые клиенты страдают, пока монополия - бизнесу это не повредит. И это очень грустно. С одной стороны я сейчас для своих проектов осваиваю userver, с ребятами из Яндекса общаться одно удовольствие, а с другой, конечные продукты обрастают толстым слоем всякого *****.
P.S. в моем случае была ситуация, что у меня отвалился семейный аккаунт в РБ: белорусская карта привязана, сам аккаунт на белорусской симке, впн с точкой выхода в РБ, но я так и не смог его восстановить и мой папа б не мог пользоваться моей картой. Причем отвязать карту от своего аккаунта и привязать карту к его аккаунту я не смог. «Поддержка» пол года кормила завтраками, но по существу так и не помогла.
Ну я пробовал только в РБ и Узбекистане. Последний - вообще тяжелый случай. А вот в Беларуси раньше было всё ок, попросишь проэскалировать и соединяли с следующей линией поддержки и действительно решали вопросы. Примерно года до 2022.
С вами общались примерно так же, как разговаривает типовая техподдержка Яндекса в РБ. То есть никак. Теперь мы знаем, что так общаться могут не только боты, но и люди (возможно, ботов на них обучали). С какого-то времени получить адекватный ответ на реальные проблемы с чёткими шагами воспроизведения просто невозможно. Всё сводится к методичке: почистите кэш на iOS, переустановите ОС, откройте карточку в другом банке, до свидания, мы больше ничем вам не можем помочь.
Вы забыли сказать, что когда её релизили, то обещали lifetime поддержку с инкрементальными апдейтами. И что новые версии больше будут не нужны.
Но нет, надо было сделать «пуск» по центру с менюхами на react native и всунуть кортану/копайлот везде куда надо и не надо.
Ни разу она не правильная. Объект после перемещения нельзя так трактовать. Таких гарантий нет, особенно для пользовательских типов. Есть лишь правило, что объект должен быть в корректном состоянии, чтобы нормально мог отработать деструктор - этого достаточно понимать.
А сырые указатели и ручной new / delete вообще не нужно использовать в подводящем большинстве случаев. Как правило, за исключением реализации собственных контейнеров или умных указателей.
Автор, что же вы удалили свою вторую статью? Или по ней стала более очевидна «глубина» ваших познаний в многопоточном программировании?
Вы знаете, есть такая полезная штука - вычитка. С картинками глаз не так замыливается как с текстом и такие вещи должны легко отлавливаться. Конечно же, если вы уважаете комьюнити, а не просто раскручиваете аккаунт.
К примеру, на тех же код ревью, я всегда вычитываю свой код так, как будто я - ревьювер. И только потом отдаю это на проверку команде и далее по процессу.
У вас на первой картинке ошибка, порядок действий неверный: 1-2-3-4-7-6-5, а должно быть последовательно. Оплата налогов и успешный ввоз не может чисто логически произойти до пересечения товаром границы :)
Увы, там нет упоминания вариантов для closed source проектов. Как я понял, для разработчиков-одиночек по прежнему нет вариантов за вменяемые деньги?
За возвращение студенческой подписки - спасибо.
Как пользователь, когда я хочу сходить в ресторан, я открываю интересующий меня район в картах и уже там перебираю рестораны.
Но, к сожалению, это уже не новая тенденция Яндекса - делать «супер приложения» для втюхивания большего количества рекламы. Когда основному функционалу приложения отводится менее 50% а то и 80% места на экране.
Вот и приходится продираться сквозь все эти высоко оптимизированные слои спама, чтобы добраться до основной функциональности - доставки еды.
P.S. с технической точки зрения было интересно почитать, спасибо.
Таким не занимался, но все равно мне кажется, что раз уж перехватываем создание потока, то можно и проинициализировать всё нужное самим.
Я бы делал так, берём тот же detours, заменяем CreateThread на свой, где вначале делается инициализация ну и ждем по какому нибудь мьютексу (который в винапи CreateEvent) сигнала к запуску оригинальной функции потока.
Впрочем ок, пусть будет такой флаг. Для таких тонких вещей платформозависимый код это, как правило, необходимость.
А какой практический пример у этого флага? Если процесс ещё понятно (вдруг, что-то пропатчить налету надо, до первой команды), то с потоком - не понятно.