Значит, вокруг вас не сформировано окружение, где было бы комфортно откровенно разговаривать. И это ведет нас снова к тому, что отсутствуют навыки формирования такого окружения.
Человеки не очень умеют просить, зато умеют требовать. Не умеют благодарить, зато умеют обесценивать
Как по мне, это говорит только об одном - отсутствии навыков искать нужных людей и заводить хорошие знакомства. Отсюда выливается все остальное. Когда нет навыков по социализации с людьми, с которыми комфортно, тогда действительно нужен суррогат.
В том же и идея, что код работает как надо. Если код пропускает часть вычислений, то он не работает как нужно, а значит, код не выполняет свою задачу. Если же код выполняет свою задачу, никому не интересно, работает ли он быстрее ожидаемого.
"Что бы вы сделали, если бы обнаружили, что ваш код работает быстрее, чем ожидалось?"
Цель: Проверить понимание оптимизации и потенциальных проблем, связанных с чрезмерной оптимизацией.
Каким образом этот вопрос связан с пониманием оптимизации и чрезмерной оптимизацией вообще? Тут варианта всего два - либо код корректно выполняет возложенную на него задачу, либо не выполняет. Если он корректно выполняет задачу, то о какой оптимизации вообще может идти речь? Или это какой-то очень странный способ вытащить кандидата на разговор о поддержке оптимизированного кода?
Официальная документация говорит, что любой проект на Android обязан AndroidManifest.xml содержать в корневом каталоге. И это не по чьему-то субъективному мнению, а по вполне объективным требованиям проектов для Android
Опрос мне показался несколько ограничивающим. Я считаю, что все эти пункты важны и вносят свой вклад в общую атмосферу. Невозможно создать атмосферу без синергии музыки, визуала, наличия некоторых философских элементов, нарратива, визуала и геймплея.
Конкретно в случае Firefly III радует то, что к нему есть некоторый API, который позволяет даже в случае прекращения поддержки реализовать свои пайплайны обработки данных даже на том же питоне. Плюс он self-hosted, что не может не радовать. Кажется, что Ваша идея финансовой аналитики с помощью своих скриптов хорошо ложится на возможности этого инструмента. Звучит как тема для следующей статьи. В любом случае, спасибо за статью!
Краткий поиск показал, что на форумах Unity, вики посвященной самой игре и многих других ресурсах указано, что Unity был использован для клиента игры. Так же на форумах видел, что EA лицензировали исходники движка. Возможно, поэтому в вики не указан Unity.
Существует Firefly III. На мой взгляд, достаточно удобный инструмент для ведения личной бухгалтерии и некоторого рода аналитики (в основном, связанной с выходом за бюджет). Пробовали им пользоваться? Если да, какие для себя обнаружили минусы?
Для этого можно использовать базовую аналитику банка, приложения для учета финансов, но у них есть минусы.
Тема минусов и плюсов не раскрыта. Понятно, что у готовых систем может не быть той гибкости, которая будет у пачки скриптов на питоне, но все-таки интересно было бы провести сравнение и более подробно остановиться на преимуществах и недостатках решений.
Оптимизация - это более широкое понятие, чем улучшение кода по времени/памяти, поэтому это вполне себе оптимизация (инфраструктуры)
Изначально некорректно понял Ваш посыл. В такой постановке согласен.
это будет стоит очень дорого, а по сути превращаться в клауд-гейминг
Все верно. В целом, интересна судьба облачного гейминга - судя по тому, на что мы уже можем посмотреть, спрос на это пусть и есть, но не такой масштабный, если смотреть на игровой рынок в целом.
Почему ничего не делают? Все симуляции, перемещения и любые другие операции выносят на сторону сервера. Помимо этого существуют разные механизмы дополнительной верификации, включая, но не ограничиваясь античитами. Почему Вы считаете, что с этим ничего не делают?
Технически, помогает, просто не со 100% эффективностью. Часть читеров отсеивается банально на уровне сканирования памяти приложения, часть читеров будет отсеяна серверными проверками, часть поймает античит и статический анализ. Читеры и разработчики игр похожи на то, что происходит в информационной безопасности - обороняющаяся сторона всегда в догонябщем положении. Поэтому я сомневаюсь, что когда-либо в принципе настанет время совсем без читеров.
Дополню так же, что сервер и так обложен всеми проверками. Есть отдельные типы читов, создатели которых пытаются отреверсить логику работы сервера и находят разного рода уязвимости. Где-то это связано с ошибками обработки параметров от клиента, где-то находятся специфичные параметры, позволяющие проверки обойти и т.п. Не все так просто. Будь это так легко - античитов бы не было. Большая часть мультиплеерных игр и так не дает выполнять никаких операций на клиенте и все симуляции, включая перемещение, делаются на сервере.
Это никак не связано с оптимизацией. Это называется listen server и этот подход используется для того, чтобы не было необходимости хостить выделенный сервер, он же dedicated server. Довод про то, что в этом случае античиты не помогут - это спорное заявление. Сильно зависит от типа античита, на каком уровне он работает (на уровне приложения или в kernel mode) и прочих параметрах. В целом, отследить использование читов в listen сервере возможно. Эффективно ли - вопрос. upd: не указал еще про самый очевидный способ защиты - в клиентах игр очень часто используют так называемые "защищенные" значения, которые шифруются в памяти по определенным правилам, чаще всего используются обычные xor и сдвиги. Это позволяет в разы усложнить поиск значений в памяти приложения и, как следствие, ограничить использование программ навроде Cheat Engine. Но, опять же, это зависит от того, насколько хотят взломать - такие приемы уже давно научились распознавать и обходить по-своему.
Почему в Unity это не уместно? Чем Unity отличается от других областей разработки? Потому что для Unity, как и других движков, существуют некоторые рекомендации, которые применяются на существенно большем числе проектов. И этот вариант, который используется в индустрии, становится своего рода "стандартом". Отсюда возникает резонный вопрос - для чего делать не стандартными способами? Касательно MonoBehaviour и AActor - это механизм, предовращающий прямой контроль над временем жизни объектов. Поэтому конструкторы вынесены на сторону движка, а наружу торчат только несколько методов, которые можно определить для инициализации. Насколько мне известно, этот способ актуален как минимум для UE и Unity, но лично видел еще в двух проприетарных движках.
Со сборкой мусора возникает резонный вопрос - зачем и по каким причинам ему отдается предпочтение, а не более, на первый взгляд, маловесной системе из умных указателей. Я не видел статей, которые бы сравнивали эти два варианта менеджмента памяти на каких-то реальных или около реальных кейсах. Насчет нуля абстракций и простоты логики - это все зависит сильно от проекта, на самом деле. Где-то да, это даст максимальную простоту, а где-то это в итоге приведет к ненужным усложнениям во имя "оптимизации". К тому же важно помнить, что игровые студии предпочитают экономить не ресурсы компьютера, а время сотрудников. Так что вопрос такой, не самый простой и от случая к случаю можно получить очень разные мнения и результаты. Я работал с чем-то отдаленно похожим на ECS. В плане производительности нареканий не было совершенно, но иногда уходило прилично времени на то, чтобы найти нужный компонент и нужную систему для того, чтобы внести в них правки. Но т.к. проект требовал множества сущностей одномоментно, это был разумный компромисс. В целом, так уж получается, что подходы подстраивают под нужды и цели бизнеса, а не наоборот. Отсюда, в общем-то, появляются всякие абстракции, библиотеки (и движки тоже) и все движется к тому, чтобы можно было взять любого программиста на стеке Х и безшовно заменить его на другого из этого же стека. Мое личное мнение, что именно на этом все завязано. Именно отсюда идут корни всяких книг навроде "Чистый код" Роберта Мартина, именно поэтому мы начинаем жертвовать ресурсы машины во имя бизнес-процессов.
Если коротко суммировать то, что я написал - все зависит от конкретного проекта, его специфики, масштабов, конкретной студии, которая его разрабатывает и итоговых целей этого проекта. Где-то можно пожертвовать половину бюджета кадра ради того, чтобы студии было проще жить, где-то предпочтение нужно отдать производительности проекта. Отсюда выбирается уже методология и подходы работы.
Значит, вокруг вас не сформировано окружение, где было бы комфортно откровенно разговаривать. И это ведет нас снова к тому, что отсутствуют навыки формирования такого окружения.
Как по мне, это говорит только об одном - отсутствии навыков искать нужных людей и заводить хорошие знакомства. Отсюда выливается все остальное.
Когда нет навыков по социализации с людьми, с которыми комфортно, тогда действительно нужен суррогат.
Нет времени вдумчиво читать статью, нужно работать.
В том же и идея, что код работает как надо. Если код пропускает часть вычислений, то он не работает как нужно, а значит, код не выполняет свою задачу.
Если же код выполняет свою задачу, никому не интересно, работает ли он быстрее ожидаемого.
Не знаком с OpenCV, но, кажется, со стороны C# можно было вызывать методы из DLL?
Каким образом этот вопрос связан с пониманием оптимизации и чрезмерной оптимизацией вообще? Тут варианта всего два - либо код корректно выполняет возложенную на него задачу, либо не выполняет. Если он корректно выполняет задачу, то о какой оптимизации вообще может идти речь?
Или это какой-то очень странный способ вытащить кандидата на разговор о поддержке оптимизированного кода?
>На чистом ассемблере
А вот это я бы с удовольствием почитал
Официальная документация говорит, что любой проект на Android обязан AndroidManifest.xml содержать в корневом каталоге. И это не по чьему-то субъективному мнению, а по вполне объективным требованиям проектов для Android
Опрос мне показался несколько ограничивающим.
Я считаю, что все эти пункты важны и вносят свой вклад в общую атмосферу. Невозможно создать атмосферу без синергии музыки, визуала, наличия некоторых философских элементов, нарратива, визуала и геймплея.
Конкретно в случае Firefly III радует то, что к нему есть некоторый API, который позволяет даже в случае прекращения поддержки реализовать свои пайплайны обработки данных даже на том же питоне. Плюс он self-hosted, что не может не радовать.
Кажется, что Ваша идея финансовой аналитики с помощью своих скриптов хорошо ложится на возможности этого инструмента. Звучит как тема для следующей статьи.
В любом случае, спасибо за статью!
Краткий поиск показал, что на форумах Unity, вики посвященной самой игре и многих других ресурсах указано, что Unity был использован для клиента игры. Так же на форумах видел, что EA лицензировали исходники движка. Возможно, поэтому в вики не указан Unity.
Существует Firefly III. На мой взгляд, достаточно удобный инструмент для ведения личной бухгалтерии и некоторого рода аналитики (в основном, связанной с выходом за бюджет).
Пробовали им пользоваться? Если да, какие для себя обнаружили минусы?
Тема минусов и плюсов не раскрыта.
Понятно, что у готовых систем может не быть той гибкости, которая будет у пачки скриптов на питоне, но все-таки интересно было бы провести сравнение и более подробно остановиться на преимуществах и недостатках решений.
Изначально некорректно понял Ваш посыл. В такой постановке согласен.
Все верно. В целом, интересна судьба облачного гейминга - судя по тому, на что мы уже можем посмотреть, спрос на это пусть и есть, но не такой масштабный, если смотреть на игровой рынок в целом.
Почему ничего не делают?
Все симуляции, перемещения и любые другие операции выносят на сторону сервера. Помимо этого существуют разные механизмы дополнительной верификации, включая, но не ограничиваясь античитами. Почему Вы считаете, что с этим ничего не делают?
Технически, помогает, просто не со 100% эффективностью.
Часть читеров отсеивается банально на уровне сканирования памяти приложения, часть читеров будет отсеяна серверными проверками, часть поймает античит и статический анализ. Читеры и разработчики игр похожи на то, что происходит в информационной безопасности - обороняющаяся сторона всегда в догонябщем положении. Поэтому я сомневаюсь, что когда-либо в принципе настанет время совсем без читеров.
Дополню так же, что сервер и так обложен всеми проверками. Есть отдельные типы читов, создатели которых пытаются отреверсить логику работы сервера и находят разного рода уязвимости. Где-то это связано с ошибками обработки параметров от клиента, где-то находятся специфичные параметры, позволяющие проверки обойти и т.п. Не все так просто. Будь это так легко - античитов бы не было. Большая часть мультиплеерных игр и так не дает выполнять никаких операций на клиенте и все симуляции, включая перемещение, делаются на сервере.
Это никак не связано с оптимизацией. Это называется listen server и этот подход используется для того, чтобы не было необходимости хостить выделенный сервер, он же dedicated server.
Довод про то, что в этом случае античиты не помогут - это спорное заявление. Сильно зависит от типа античита, на каком уровне он работает (на уровне приложения или в kernel mode) и прочих параметрах. В целом, отследить использование читов в listen сервере возможно. Эффективно ли - вопрос.
upd: не указал еще про самый очевидный способ защиты - в клиентах игр очень часто используют так называемые "защищенные" значения, которые шифруются в памяти по определенным правилам, чаще всего используются обычные xor и сдвиги. Это позволяет в разы усложнить поиск значений в памяти приложения и, как следствие, ограничить использование программ навроде Cheat Engine. Но, опять же, это зависит от того, насколько хотят взломать - такие приемы уже давно научились распознавать и обходить по-своему.
Почему в Unity это не уместно? Чем Unity отличается от других областей разработки?Потому что для Unity, как и других движков, существуют некоторые рекомендации, которые применяются на существенно большем числе проектов. И этот вариант, который используется в индустрии, становится своего рода "стандартом". Отсюда возникает резонный вопрос - для чего делать не стандартными способами?
Касательно MonoBehaviour и AActor - это механизм, предовращающий прямой контроль над временем жизни объектов. Поэтому конструкторы вынесены на сторону движка, а наружу торчат только несколько методов, которые можно определить для инициализации. Насколько мне известно, этот способ актуален как минимум для UE и Unity, но лично видел еще в двух проприетарных движках.
Со сборкой мусора возникает резонный вопрос - зачем и по каким причинам ему отдается предпочтение, а не более, на первый взгляд, маловесной системе из умных указателей. Я не видел статей, которые бы сравнивали эти два варианта менеджмента памяти на каких-то реальных или около реальных кейсах.
Насчет нуля абстракций и простоты логики - это все зависит сильно от проекта, на самом деле. Где-то да, это даст максимальную простоту, а где-то это в итоге приведет к ненужным усложнениям во имя "оптимизации". К тому же важно помнить, что игровые студии предпочитают экономить не ресурсы компьютера, а время сотрудников. Так что вопрос такой, не самый простой и от случая к случаю можно получить очень разные мнения и результаты.
Я работал с чем-то отдаленно похожим на ECS. В плане производительности нареканий не было совершенно, но иногда уходило прилично времени на то, чтобы найти нужный компонент и нужную систему для того, чтобы внести в них правки. Но т.к. проект требовал множества сущностей одномоментно, это был разумный компромисс.
В целом, так уж получается, что подходы подстраивают под нужды и цели бизнеса, а не наоборот. Отсюда, в общем-то, появляются всякие абстракции, библиотеки (и движки тоже) и все движется к тому, чтобы можно было взять любого программиста на стеке Х и безшовно заменить его на другого из этого же стека. Мое личное мнение, что именно на этом все завязано. Именно отсюда идут корни всяких книг навроде "Чистый код" Роберта Мартина, именно поэтому мы начинаем жертвовать ресурсы машины во имя бизнес-процессов.
Если коротко суммировать то, что я написал - все зависит от конкретного проекта, его специфики, масштабов, конкретной студии, которая его разрабатывает и итоговых целей этого проекта. Где-то можно пожертвовать половину бюджета кадра ради того, чтобы студии было проще жить, где-то предпочтение нужно отдать производительности проекта. Отсюда выбирается уже методология и подходы работы.