Вообще, принципиально подход конечно правильный: упала производительность — снижай нагрузку, и наоборот. Только сам этот автоподстраиватель тоже надо настраивать. И насколько я знаю, в современных играх стараются сразу делать сцены такими, чтобы фреймрейт был «хорошим». Потом тестируют и исправляют, так что у пользователей уже никакой автомагии не происходит.
Очевидно, это не сработает. Фреймрейт не очень стабильная величина, и может ненадолго снизиться по куче разных причин. Может быть что-то ещё запустилось в системе, и вам не хватило ресурсов. Или, бывает, это происходит в начале сцены, пока остальное ещё догружается.
Фронт -это ui, переиспользование примерно схожих контролов, сложности тут до бесконечности просто нет причины расти.
Для этого изобрели React, а потом решили его выбросить и сейчас в моде Flux. Через год ещё что-то будет новое. Так что всё в порядке на фронте со сложностью.
По моему опыту, на самом деле можно было бы просто обсудить все эти вопросы в чатике: где брать сервер, кто настроит доступы, кто поднимет базу и тд. И на этом бы тестовое задание закончилось успешно, но YMMW.
В смысле, разработчик из компании А на инфре компании А (которую он должен бы знать) делает тестовое задание для компании Б, чтобы перейти в компанию Б.
Конечно, я не изобретал свой язык программирования, и не делал свою СУБД. Но пришлось выбрать хостера, чтобы не дорого, но и не погано. Потом решал на какой ОС это будет все жить, куда бэкапиться, какая база там будет, и какие у неё права доступа будут. Веб-сервер, балансировщик, DNS. Надо как-то деплоить, обновлять базу, заходить туда, в конце-концов так, чтобы никто кроме меня не мог этого делать. Куча проблем, и это ещё до того, как начнёшь выбирать шаблон для кода и язык программирования.
Где-то год назад я подумал, а что это у всех есть свой REST API, а у меня нет. И решил сделать, никакого ноу-хау, пару примитивных эндпоинтов, просто чтобы из интернета было доступно и какую-никакую нагрузку держало. И чтобы не пользоваться всей инфраструктурой компании, а все с нуля своими руками собрать.
В итоге, спустя год таки допилил, по дороге наступив на адову кучу граблей. И вот сейчас у меня есть инфраструктура, чтобы такое тестовое задание сделать за, скажем, вечер.
Собирать такую инфраструктуру с нуля чтобы просто показать что могу и потом всё выбросить — я бы наверное тоже не стал.
Чтобы использовать эту архитектуру, SigRed включает в себя настройку записей ресурсов NS домена («deadbeef.fun») для указания на вредоносный сервер имен («ns1.41414141.club») и запрос целевого DNS-сервера для домена, чтобы последний анализировал ответы от сервера имен для всех последующих запросов, связанных с доменом или его поддоменами.
Проблема в том, что вы не прочитали ветку, на которую я отвечал. А именно, пропустили заявление хабраюзера о том, что в современном С++ перемещение (почти всегда) заменяет мутирующие методы.
Если вам нужна копия, то придется явно это написать
Проблема в том, что вы же не думали об оптимизации заранее, сервис был маленький, ресурсов вагон и программист из комментария выше уже написал такой код:
auto image = getImage();
auto mirrorImage = image.mirrored(); // хороший метод, состояние не модифицируется, но есть копирование
setImage(mirrorImage);
В этом случае ему, на самом деле, копия была не нужна, исходную картинку можно было выбросить. В другом случае он же написал похожий код, вроде такого:
auto image = getImage();
auto flippedImage = image.flip(); // хороший метод, состояние не модифицируется, но есть копирование
setAnotherImage(flippedImage);
Только здесь ему уже надо было сохранить исходную картинку и получить перевернутую.
Эта история повторилась еще много-много раз. И когда вдруг поняли, что надо бы пооптимизировать лишние копирования, придется каждый такой кейс изучать заново и смотреть — где копирование было необходимым, а где можно и move. Считай, всю работу с картинками придется переписать.
Так проблема в том, что если в апи Image::getMirrored, то как ни расставляй референсы, а все равно в результате получишь две картинки: исходную и перевёрнутую. Может быть, что мутирующая операция отражения очень дешевая (просто преключает флаг внутри), а операция копирования не такая дешевая и ресурсов не дофига. И вот в такой ситуации, оптимизация с заменой апи на мутирующий Image::mirror() может оказаться очень дорогой с точки зрения разработки, придётся переписывать вообще всё. Так что лучше сразу стараться дизайнить оптимально.
Если возраст нужен, то сайт может и спросить. Остальное — вообще не проблема пользователей ни разу. А вот то, что их частную жизнь кому-то продают — проблема. И ещё большая проблема то, что продают без согласия и даже уведомления.
Я правильно вас понял, что пока игру делают, никто не бегает по локациям и не смотрит где тормозит?
Вот! Сразу чувствуется мощная хватка акулы devops.
По моему опыту, на самом деле можно было бы просто обсудить все эти вопросы в чатике: где брать сервер, кто настроит доступы, кто поднимет базу и тд. И на этом бы тестовое задание закончилось успешно, но YMMW.
В смысле, разработчик из компании А на инфре компании А (которую он должен бы знать) делает тестовое задание для компании Б, чтобы перейти в компанию Б.
Да, потому я и написал, что «не используя инфраструктуру компании».
Очень сомнительно, что компания разрешит запилить новый эндпоинт на ее инфраструктуре, чтобы разработчик мог сделать тестовое задание для конкурентов.
Конечно, я не изобретал свой язык программирования, и не делал свою СУБД. Но пришлось выбрать хостера, чтобы не дорого, но и не погано. Потом решал на какой ОС это будет все жить, куда бэкапиться, какая база там будет, и какие у неё права доступа будут. Веб-сервер, балансировщик, DNS. Надо как-то деплоить, обновлять базу, заходить туда, в конце-концов так, чтобы никто кроме меня не мог этого делать. Куча проблем, и это ещё до того, как начнёшь выбирать шаблон для кода и язык программирования.
Где-то год назад я подумал, а что это у всех есть свой REST API, а у меня нет. И решил сделать, никакого ноу-хау, пару примитивных эндпоинтов, просто чтобы из интернета было доступно и какую-никакую нагрузку держало. И чтобы не пользоваться всей инфраструктурой компании, а все с нуля своими руками собрать.
В итоге, спустя год таки допилил, по дороге наступив на адову кучу граблей. И вот сейчас у меня есть инфраструктура, чтобы такое тестовое задание сделать за, скажем, вечер.
Собирать такую инфраструктуру с нуля чтобы просто показать что могу и потом всё выбросить — я бы наверное тоже не стал.
Ух! Умеют же люди писать!
Проблема в том, что вы не прочитали ветку, на которую я отвечал. А именно, пропустили заявление хабраюзера о том, что в современном С++ перемещение (почти всегда) заменяет мутирующие методы.
Проблема в том, что вы же не думали об оптимизации заранее, сервис был маленький, ресурсов вагон и программист из комментария выше уже написал такой код:
В этом случае ему, на самом деле, копия была не нужна, исходную картинку можно было выбросить. В другом случае он же написал похожий код, вроде такого:
Только здесь ему уже надо было сохранить исходную картинку и получить перевернутую.
Эта история повторилась еще много-много раз. И когда вдруг поняли, что надо бы пооптимизировать лишние копирования, придется каждый такой кейс изучать заново и смотреть — где копирование было необходимым, а где можно и move. Считай, всю работу с картинками придется переписать.
Если возраст нужен, то сайт может и спросить. Остальное — вообще не проблема пользователей ни разу. А вот то, что их частную жизнь кому-то продают — проблема. И ещё большая проблема то, что продают без согласия и даже уведомления.