О, у нас в школе стояли мк88 в начале 2000-х, грузились с 5 дюймовых дискет. Огромный респект нашей учительнице по информатике, что в 8 классе дала нам основы паскаля.
У вас статья про то, как просто скомпилировать проект на линуксе. Зачем для этого статья и причём тут userver?
У userver неплохая документация. И если рядовой разработчик не справляется со сборкой (или даже установкой из готовых пакетов), то именно userver вам не нужен.
Если вы не согласны - расскажите про ваш опыт использования userver в реальных проектах.
P.S. я пока только начал изучать возможности userver и собираю его на маке, подтягивая все зависимости через vcpkg, без cpm. Мои фиксы для cmake еще пока сыроваты для публикации пуллреквеста, но я уже близок к тому чтобы полностью завезти userver через vcpkg. Но я не вижу никакого смысла оформлять очевидные инструкции по сборке в виде статьи на Хабре.
На самом деле компилятор может выкинуть memcpy который под капотом у бит каста. А вот start_lifetime_as позволит, к примеру, кастануть флоат к инту и наоборот - собственно про это и вопрос в контексте быстрого обратного корня из начала статьи.
Прикольно. Про обучение на «крестиках ноликах» я писал на рсдн в виде сообщения.
Интересно, это совпадение или за основу взяли мою идею? :)
Скопирую сюда, если рсдн ляжет от хабраэффекта:
Можно сделать с базовыми знаниями программирования, гуглом и трудолюбием (и с которым вас наверняка возьмут, например, на Junior C#/С++ позицию):
Написать сетевой морской бой (или крестики-нолики), в котором история матчей сохраняется в базу данных. Причём делать по пунктам:
1) Сначала научиться отображать доску с кораблями. Хотя-бы 10х10 кнопок, где корабли/выстрелы отображаются символами 'O' 'X' '.'. В качестве исходных данных — обычный двумерный массив.
2) Научиться обрабатывать клики по доске — при нажатии на кнопку менять значение ячейки в массиве.
3) Написать примитивную игровую логику: 2 поля, 2 окна, 2 игрока, ходят по очереди, при выстреле по ячейке выполнять п.2.
4) Доработать логику в соответствии с правилами "морского боя" — после попадания по врагу повторить ход. Научиться проверять, закончилась ли игра. Научиться валидировать расстановку кораблей.
5) Сделать несколько стадий игры: 1 — расстановка кораблей, 2 — игра, 3 — объявление победителя
6) Отделить логику игрового поля от логики рисования игральной доски.
7) Вынести логику в отдельный процесс и сделать сетевое взаимодействие. Тупо на сокетах, без каких-либо проверок корректности и т.п. Уже получится клиент-серверное приложение
8) Научить сервер записывать в базу последовательность ходов. Любая реляционная СУБД на одну таблицу.
9) Научиться восстанавливать игру из базы
10) Научиться писать в базу несколько игр. Т.е. табличка с названием игры + двумя именами игроков.
Задача потянет на средний курсач для 1-2 курса БГУИР. И на фоне любого джуна с профильной специальностью, у которого в резюме будут только лабораторные работы, возьмут того, кто сам сделал минимальный проект. Который, кстати, отлично зайдёт и вместо тестового задания.
Это пока эффективный менеджмент и руководство не захотят начать спасать ситуацию путём продажи бизнеса или выхода на биржу.
А потом «внезапно», после независимого аудита, выясняется что говнокода (пусть и прекрасно работающего в продакшене) больше чем кода. И что люди, которые изначально делали очень крутые решения уже давно свалили, просто потому что им не подымали зарплату, мол зачем, если всегда можно нанять новых. И после такого аудита начинают ходить слухи, мол дешевле переобучить всех на анрил, чем продолжать поддерживать на плаву то что есть.
И самая главная проблема - кривая обучения работы с движком улетает в космос и если просто новой команде захотеть делать игру на таком движке, то это оказывается дороже, чем написать и движок и игру с нуля (а лучше - взять что-то более стабильное и документированное).
Так что если движок где-то работает, то это вовсе не означает что он хороший и может быть кем-то еще переиспользован.
Современный геймдев это почти всегда поиск компромиссов между стоимостью, качеством и скоростью разработки.
Я часто замечал ещё одну печальную тенденцию, как человек который делает утилиты для игр.
Компании (и инженеры в них), которые делают или допиливают движки слишком поздно начинают задумываться об интеграции движка/игры с редакторами.
Из последнего - пришлось пару лет назад чинить производительность в некоторых местах редактора, одного из упомянутых в статье культового движка. И очень уж бросались в глаза места где решения принимались по принципу:
Пока производительность не важна, потом оптимизируем, лишь бы получить mvp
Сейчас куча задач по движку, давайте эту часть редактора отдадим на аутсорсинг или джуно-мидлам, пусть учатся, заодно и задачи закроем
Давайте наймём сеньоров, которые шарят в [framework_name] и сделают хорошо. Но «всё выкинуть и переписать» - это джуновский подход, мы так делать не будем, поэтому делайте костыли в тысячи строк, которые точечно решат некоторые проблемы, и, если повезет, не сильно ушатают редактор.
Да да, у нас редактор не запускается в debug сборке в принципе, потому что десяток лет назад, в п.1 мы внесли несколько UB и ключевые компоненты висят на соплях. И ещё куча аналогичных проблем.
Либо ещё ситуация, которую встречал в двух разных, никак не связанных между собой студиях:
Кладем болт на проектирование тулзов, ведь главное супер крутой и производительный движок, и хорошие программисты
Получаем пачку несвязанных инструментов. И чтобы поменять текстуру на объекте, дизайнерам надо запускать 2-3 программы и прогонять сверху питоновский скрипт.
Дальше так жить нельзя, давайте изобретем универсальный фреймворк, для разработки тулзов, который будет правильно интегрирован с движком и каждая команда будет самостоятельно и успешно делать всё в рамках единой концепции
Дизайнеры продолжают пользоваться старыми тулзами, ругаться на что они практически не поддерживаются в угоду нового супер-пупер-редактора, который либо ещё слишком глючный либо ещё не поддерживает все фичи старых редакторов.
Менеджмент начинает давить на команду тулзовиков, просить меньше думать об архитектуре, качестве кода и производительности, в угоду скорейшего выпуска mvp.
Ну и приходим к очередной итерации того, что было написано вначале.
Лично я смотрю на экран, камеры (балуюсь любительской сьемкой), автономность работы и надежность экосистемы. Всё. Зачем именно телефону ИИ - я без понятия. Максимум - нейросети для пост обработки фото.
Третий абзац статьи. Там говорится про QML. Так же как и в оглавлении книги.
А вообще, виджеты достаточно стабильная технология для десктопов и она поддерживается до сих пор, просто новых фичей не добавляют. Но у виджетов есть ряд фундаментальных проблем:
Виджеты жрут CPU на основном потоке и провоцируют на микс бизнес и UI логики. Из-за этого сложно чинить производительность в легаси системах.
Очень слабая и ресурсоёмка поддержка анимаций интерфейса.
Неудобная кастомизация (часто через тормознутый qss, который сами ребята из Qt не рвутся оптимизировать).
Непонятно из статьи, насколько глубоко в книге раскрыты современные практики по разработке интерфейсов на QML / QtQuick? Как я понял, основной упор делается на виджеты, а для современных проектов, где нужна нормальная поддержка dpi scaling или для мобильных систем / HMI это уже не особо подходит.
Я больше склоняюсь к тому, что это эффективные манагеры экономят за счет монополии Яндекса. Типа пофиг, что некоторые клиенты страдают, пока монополия - бизнесу это не повредит. И это очень грустно. С одной стороны я сейчас для своих проектов осваиваю userver, с ребятами из Яндекса общаться одно удовольствие, а с другой, конечные продукты обрастают толстым слоем всякого *****.
P.S. в моем случае была ситуация, что у меня отвалился семейный аккаунт в РБ: белорусская карта привязана, сам аккаунт на белорусской симке, впн с точкой выхода в РБ, но я так и не смог его восстановить и мой папа б не мог пользоваться моей картой. Причем отвязать карту от своего аккаунта и привязать карту к его аккаунту я не смог. «Поддержка» пол года кормила завтраками, но по существу так и не помогла.
Ну я пробовал только в РБ и Узбекистане. Последний - вообще тяжелый случай. А вот в Беларуси раньше было всё ок, попросишь проэскалировать и соединяли с следующей линией поддержки и действительно решали вопросы. Примерно года до 2022.
С вами общались примерно так же, как разговаривает типовая техподдержка Яндекса в РБ. То есть никак. Теперь мы знаем, что так общаться могут не только боты, но и люди (возможно, ботов на них обучали). С какого-то времени получить адекватный ответ на реальные проблемы с чёткими шагами воспроизведения просто невозможно. Всё сводится к методичке: почистите кэш на iOS, переустановите ОС, откройте карточку в другом банке, до свидания, мы больше ничем вам не можем помочь.
Как побочный продукт, появился опенсорсный проект Google Agones, который до сих пор развивается и используется в продакшене различными студиями.
О, у нас в школе стояли мк88 в начале 2000-х, грузились с 5 дюймовых дискет. Огромный респект нашей учительнице по информатике, что в 8 классе дала нам основы паскаля.
Использование юникодных флагов в коде - явный признак того, что код писал человек. Не говоря уже об общей организации кода. /s
У вас статья про то, как просто скомпилировать проект на линуксе. Зачем для этого статья и причём тут userver?
У userver неплохая документация. И если рядовой разработчик не справляется со сборкой (или даже установкой из готовых пакетов), то именно userver вам не нужен.
Если вы не согласны - расскажите про ваш опыт использования userver в реальных проектах.
P.S. я пока только начал изучать возможности userver и собираю его на маке, подтягивая все зависимости через vcpkg, без cpm. Мои фиксы для cmake еще пока сыроваты для публикации пуллреквеста, но я уже близок к тому чтобы полностью завезти userver через vcpkg. Но я не вижу никакого смысла оформлять очевидные инструкции по сборке в виде статьи на Хабре.
На самом деле компилятор может выкинуть memcpy который под капотом у бит каста. А вот start_lifetime_as позволит, к примеру, кастануть флоат к инту и наоборот - собственно про это и вопрос в контексте быстрого обратного корня из начала статьи.
Так это же перевод. Я думаю, может кто-то из хабравчан просветит меня.
Небольшой вопрос, а почему std::bit_cast из цпп20 вместо std::start_lifetime_as из цпп23?
Прикольно. Про обучение на «крестиках ноликах» я писал на рсдн в виде сообщения.
Интересно, это совпадение или за основу взяли мою идею? :)
Скопирую сюда, если рсдн ляжет от хабраэффекта:
Можно сделать с базовыми знаниями программирования, гуглом и трудолюбием (и с которым вас наверняка возьмут, например, на Junior C#/С++ позицию):
Написать сетевой морской бой (или крестики-нолики), в котором история матчей сохраняется в базу данных. Причём делать по пунктам:
1) Сначала научиться отображать доску с кораблями. Хотя-бы 10х10 кнопок, где корабли/выстрелы отображаются символами 'O' 'X' '.'. В качестве исходных данных — обычный двумерный массив.
2) Научиться обрабатывать клики по доске — при нажатии на кнопку менять значение ячейки в массиве.
3) Написать примитивную игровую логику: 2 поля, 2 окна, 2 игрока, ходят по очереди, при выстреле по ячейке выполнять п.2.
4) Доработать логику в соответствии с правилами "морского боя" — после попадания по врагу повторить ход. Научиться проверять, закончилась ли игра. Научиться валидировать расстановку кораблей.
5) Сделать несколько стадий игры: 1 — расстановка кораблей, 2 — игра, 3 — объявление победителя
6) Отделить логику игрового поля от логики рисования игральной доски.
7) Вынести логику в отдельный процесс и сделать сетевое взаимодействие. Тупо на сокетах, без каких-либо проверок корректности и т.п. Уже получится клиент-серверное приложение
8) Научить сервер записывать в базу последовательность ходов. Любая реляционная СУБД на одну таблицу.
9) Научиться восстанавливать игру из базы
10) Научиться писать в базу несколько игр. Т.е. табличка с названием игры + двумя именами игроков.
Задача потянет на средний курсач для 1-2 курса БГУИР. И на фоне любого джуна с профильной специальностью, у которого в резюме будут только лабораторные работы, возьмут того, кто сам сделал минимальный проект. Который, кстати, отлично зайдёт и вместо тестового задания.
Это пока эффективный менеджмент и руководство не захотят начать спасать ситуацию путём продажи бизнеса или выхода на биржу.
А потом «внезапно», после независимого аудита, выясняется что говнокода (пусть и прекрасно работающего в продакшене) больше чем кода. И что люди, которые изначально делали очень крутые решения уже давно свалили, просто потому что им не подымали зарплату, мол зачем, если всегда можно нанять новых. И после такого аудита начинают ходить слухи, мол дешевле переобучить всех на анрил, чем продолжать поддерживать на плаву то что есть.
И самая главная проблема - кривая обучения работы с движком улетает в космос и если просто новой команде захотеть делать игру на таком движке, то это оказывается дороже, чем написать и движок и игру с нуля (а лучше - взять что-то более стабильное и документированное).
Так что если движок где-то работает, то это вовсе не означает что он хороший и может быть кем-то еще переиспользован.
Современный геймдев это почти всегда поиск компромиссов между стоимостью, качеством и скоростью разработки.
Я часто замечал ещё одну печальную тенденцию, как человек который делает утилиты для игр.
Компании (и инженеры в них), которые делают или допиливают движки слишком поздно начинают задумываться об интеграции движка/игры с редакторами.
Из последнего - пришлось пару лет назад чинить производительность в некоторых местах редактора, одного из упомянутых в статье культового движка. И очень уж бросались в глаза места где решения принимались по принципу:
Пока производительность не важна, потом оптимизируем, лишь бы получить 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, переустановите ОС, откройте карточку в другом банке, до свидания, мы больше ничем вам не можем помочь.