Интересно, не знал о таком. Замечания хорошие, учту. Но я больше .NET программист чем DevOps или системник, поэтому пошел по тому пути, где имею наибольшую компетенцию :)
Но справедливости ради - это не продакшен крупной компании, это мой "домашний проект", и мне намного проще сделать так чтобы приложение работало в разных условиях, чем разные условия готовить под приложение.
В идеале конечно было бы сделать небольшого отдельного юзера на локальной машине, разделить домены по отдельным проектам, с аккуратными sitemap и прочим, в проде взять линукс, настроить все порты, вынести БД на отдельный сервер без внешних дыр, ну и так далее, но если делать это все в одиночку - скорее раньше выгоришь чем добьешься MVP.
Но вы правы что с Postgres я накостылил, но у меня ситуация такая, что я параллельно использую другие виртуальные окружения, из-за чего виртуализация докера, а точнее фичи виндовс которые он требует - конфликтуют с теми, что я использую в других проектах, и в выборе накостылить postgres или другие проекты, для личного удобства разработки, я выбрал пустить под нож докер :)
Согласен, тут ещё просто. У нас пояс один (Ташкент, +05 без DST), поэтому вся боль свелась к границе суток и фолбэку на фиксированное смещение. Планировщик с повторяющимися событиями через DST-переходы - это мрак, на одной из прошлых работ похожие проблемы решал, там и «время, которого не существует» при переводе стрелок, и «9 утра по чьему времени» при переезде пользователя. Как раз поэтому я намеренно не стал строить свой шедулер, а напоминания считаем в одном фиксированном поясе фермы. Если знакомый рассказывал детали про Auslogics - с удовольствием почитал бы в виде статьи :)
История из другого проекта
Еще стартап один веду - blinking-box, реклама в Узб. на курьерах. Там со временем были шарады. Из-за того что не ясно в каком времени показывать отчеты, геометки и прочее по показанной рекламе - все превращалось в сумбур. Допусти ситуация: заказчик из США хочет рекламу с 9:00 до 12:00, вот и проблема: в каком времени рекламу эту показывать и какое время им в отчеты вставлять, учитывая что все участники еще разбросаны по разным часовым поясам (головной офис в одном, представитель в другом, пользователь в третьем, ну и т.д.). Решили проблему в итоге на чисто бизнес-уровне, дороговорились на UTC, через UI универсального и главное удобного решения не нашлось. Поэтому да, тема времени очень глубокая.
Задача слишком простая и от этого вариантов много :) К примеру можно использовать MVVM из UI фреймов, таких как MAUI к примеру. Суть его в том, что есть View - то что видит пользователь, Model - то, что управляет VIew т.е. непосредственно контентом, и ViewModel - данные, с которыми работает Model:
Вот реализация MVVM в крайне грубом варианте :) (Правда называть это MVVM - неправильно, т.к. это View-Model или View-ViewModel) View здесь это - Console.
И как писал funca выше - это хорошая (хоть и нечестная) задача заставляющая изучить тему, и вы как учитель сильно подстегнули аудиторию :)
Решение - смерть для читаемости кода. Если мы не работаем с высоконагруженными система, то основная наша задача - читаемость кода, чтобы если после тебя кому-то придется это исправлять ему не приходилось решать "третью" часть задачи.
Как по мне - хорошим решением будет следующее: Раз появилась задача на изменение поведения, то можно предположить, что в будущем придет другое изменение, поэтому, чтобы поддерживать разные варианты и сохранить читаемость - можно использовать паттерны. Ввести тип, который генерирует задачу и проверяет ответ и передавать его во вью, в нашем случае - тип, работающий с консолью.
Это позволит не только добавить деление и умножение, а так же и другие вычисления, без необходимости по 10 раз переписывать то, что уже работает :)
Добавлю ваши замечания, но с небольшими корректировками:
Корутины не являются асинхронными, они выполняются в основном потоке приложения, в том же, что и отрисовка кадров, инстансирование объектов и т.д., если заблокировать поток в корутине, то остановится все приложение, корутины с асинхронностью использовали бы "IAsyncEnumerator", который Unity не поддерживает. Но вы правы, что корутина позволяет растянуть выполнение на несколько кадров, что бы не нагружать 1 кадр большими вычислениями. Unity предоставляет тип UnityWebRequest для Http запросов, которые можно выполнять "асинхронно" в несколько кадров, что может показаться "асинхронностью", на самом деле же это обертка над нативным асинхронным HttpClient, которая предоставляет некоторую информацию синхронно, по типу поля isDone, которое отображает - закончился ли запрос или еще ожидается ответ, но сам запрос идет асинхронно.
Поэтому Unity корутины, в рамках программирования, не реализуют асинхронность.
async\await существует с C# 5, которая, согласно гуглу, вышла в 2012 году, вряд ли за 10 лет команда Unity не обновила бы свой движек, учитывая, что появление async\await было самым главным событием для языка, поэтому смысл корутин в другом, а именно - разделить выполнение на несколько кадров в основном потоке, что написано в документации.
Применение для асинхронных корутин мне сложно придумать, если есть Async\Await.
Здравствуйте, это хорошее замечание, для поддержки разных соотношений можно использовать подобный скрипт, дублировать интерфейс нецелесообразно, т.к. это удваивает работу, если только, конечно, речь не идет о кардинально другом лэйауте, в этом случае сама задача подразумевает "дублирование" работы. Но если такой задачи не стоит, то правильная верстка и этот скрипт будет достаточным решением, пример можно увидеть в приложении, которое стало основой статьи, оно поддерживает как планшеты, так и мобильные устройства, без дополнительных скриптов, кроме представленного, с небольшой доработкой на смену анимации. Ссылка на приложение есть в начале статьи и в конце этого ответа.
Насчет анимаций: в большинстве случае анимации перемещения интерфейса длятся <1 сек, а при смене ориентации проигрывается анимация поворота длиной 0.5 сек, за это время можно сменить набор анимаций и перевести элемент в конечную точку запущенной анимации, пример можно увидеть в приложении.
Насчет перемещения: если задача подразумевает перемещение без анимаций, то необходимо доработать скрипт, согласно вашему случаю, универсальное решение тут сложно придумать.
Здравствуйте, если я правильно вас понял, что вы посмотрели код типа SavedRect, то инкапсулировать поля будет лишним, т.к. их изменение не сломает логику, и позволяет дизайнеру править данные без необходимости менять ориентацию в редакторе, и к тому же делает данные открытыми и следовательно простыми для проверки. Если вас неустраивает большой контроллер с кучей значений, то Unity предоставляет возможность свернуть эти поля типа SavedRect.
Интересно, не знал о таком. Замечания хорошие, учту. Но я больше .NET программист чем DevOps или системник, поэтому пошел по тому пути, где имею наибольшую компетенцию :)
Но справедливости ради - это не продакшен крупной компании, это мой "домашний проект", и мне намного проще сделать так чтобы приложение работало в разных условиях, чем разные условия готовить под приложение.
В идеале конечно было бы сделать небольшого отдельного юзера на локальной машине, разделить домены по отдельным проектам, с аккуратными sitemap и прочим, в проде взять линукс, настроить все порты, вынести БД на отдельный сервер без внешних дыр, ну и так далее, но если делать это все в одиночку - скорее раньше выгоришь чем добьешься MVP.
Но вы правы что с Postgres я накостылил, но у меня ситуация такая, что я параллельно использую другие виртуальные окружения, из-за чего виртуализация докера, а точнее фичи виндовс которые он требует - конфликтуют с теми, что я использую в других проектах, и в выборе накостылить postgres или другие проекты, для личного удобства разработки, я выбрал пустить под нож докер :)
Согласен, тут ещё просто. У нас пояс один (Ташкент, +05 без DST), поэтому вся боль свелась к границе суток и фолбэку на фиксированное смещение. Планировщик с повторяющимися событиями через DST-переходы - это мрак, на одной из прошлых работ похожие проблемы решал, там и «время, которого не существует» при переводе стрелок, и «9 утра по чьему времени» при переезде пользователя. Как раз поэтому я намеренно не стал строить свой шедулер, а напоминания считаем в одном фиксированном поясе фермы. Если знакомый рассказывал детали про Auslogics - с удовольствием почитал бы в виде статьи :)
История из другого проекта
Еще стартап один веду - blinking-box, реклама в Узб. на курьерах. Там со временем были шарады. Из-за того что не ясно в каком времени показывать отчеты, геометки и прочее по показанной рекламе - все превращалось в сумбур. Допусти ситуация: заказчик из США хочет рекламу с 9:00 до 12:00, вот и проблема: в каком времени рекламу эту показывать и какое время им в отчеты вставлять, учитывая что все участники еще разбросаны по разным часовым поясам (головной офис в одном, представитель в другом, пользователь в третьем, ну и т.д.). Решили проблему в итоге на чисто бизнес-уровне, дороговорились на UTC, через UI универсального и главное удобного решения не нашлось. Поэтому да, тема времени очень глубокая.
Задача слишком простая и от этого вариантов много :)
К примеру можно использовать MVVM из UI фреймов, таких как MAUI к примеру. Суть его в том, что есть View - то что видит пользователь, Model - то, что управляет VIew т.е. непосредственно контентом, и ViewModel - данные, с которыми работает Model:
Вот реализация MVVM в крайне грубом варианте :) (Правда называть это MVVM - неправильно, т.к. это View-Model или View-ViewModel) View здесь это - Console.
И как писал funca выше - это хорошая (хоть и нечестная) задача заставляющая изучить тему, и вы как учитель сильно подстегнули аудиторию :)
Решение - смерть для читаемости кода. Если мы не работаем с высоконагруженными система, то основная наша задача - читаемость кода, чтобы если после тебя кому-то придется это исправлять ему не приходилось решать "третью" часть задачи.
Как по мне - хорошим решением будет следующее:
Раз появилась задача на изменение поведения, то можно предположить, что в будущем придет другое изменение, поэтому, чтобы поддерживать разные варианты и сохранить читаемость - можно использовать паттерны. Ввести тип, который генерирует задачу и проверяет ответ и передавать его во вью, в нашем случае - тип, работающий с консолью.
Это позволит не только добавить деление и умножение, а так же и другие вычисления, без необходимости по 10 раз переписывать то, что уже работает :)
Можно через CancellationToken. https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.cancellationtoken?view=net-6.0
А так корутины и асинхронность хороша под разные задачи, нельзя сказать, что что-то лучше всегда.
I am glad that the article was useful, I'll correct the article.
Спасибо за дополнение, но статья не про Async в Unity.
Искренне рад, что вам понравилась статья!
Добавлю ваши замечания, но с небольшими корректировками:
Корутины не являются асинхронными, они выполняются в основном потоке приложения, в том же, что и отрисовка кадров, инстансирование объектов и т.д., если заблокировать поток в корутине, то остановится все приложение, корутины с асинхронностью использовали бы "IAsyncEnumerator", который Unity не поддерживает. Но вы правы, что корутина позволяет растянуть выполнение на несколько кадров, что бы не нагружать 1 кадр большими вычислениями. Unity предоставляет тип UnityWebRequest для Http запросов, которые можно выполнять "асинхронно" в несколько кадров, что может показаться "асинхронностью", на самом деле же это обертка над нативным асинхронным HttpClient, которая предоставляет некоторую информацию синхронно, по типу поля isDone, которое отображает - закончился ли запрос или еще ожидается ответ, но сам запрос идет асинхронно.
Поэтому Unity корутины, в рамках программирования, не реализуют асинхронность.
async\await существует с C# 5, которая, согласно гуглу, вышла в 2012 году, вряд ли за 10 лет команда Unity не обновила бы свой движек, учитывая, что появление async\await было самым главным событием для языка, поэтому смысл корутин в другом, а именно - разделить выполнение на несколько кадров в основном потоке, что написано в документации.
Применение для асинхронных корутин мне сложно придумать, если есть Async\Await.
Да, Вы правы, но видимой проблемы или преимущества это изменение не дает.
Здравствуйте, это хорошее замечание, для поддержки разных соотношений можно использовать подобный скрипт, дублировать интерфейс нецелесообразно, т.к. это удваивает работу, если только, конечно, речь не идет о кардинально другом лэйауте, в этом случае сама задача подразумевает "дублирование" работы. Но если такой задачи не стоит, то правильная верстка и этот скрипт будет достаточным решением, пример можно увидеть в приложении, которое стало основой статьи, оно поддерживает как планшеты, так и мобильные устройства, без дополнительных скриптов, кроме представленного, с небольшой доработкой на смену анимации. Ссылка на приложение есть в начале статьи и в конце этого ответа.
Насчет анимаций: в большинстве случае анимации перемещения интерфейса длятся <1 сек, а при смене ориентации проигрывается анимация поворота длиной 0.5 сек, за это время можно сменить набор анимаций и перевести элемент в конечную точку запущенной анимации, пример можно увидеть в приложении.
Насчет перемещения: если задача подразумевает перемещение без анимаций, то необходимо доработать скрипт, согласно вашему случаю, универсальное решение тут сложно придумать.
Ссылки на приложение:
https://apps.apple.com/de/app/россети-центр-книга-достижений/id1498965479
https://play.google.com/store/apps/details?id=com.NexusStudio.mrskglorybook&hl=af&gl=US
Здравствуйте, если я правильно вас понял, что вы посмотрели код типа SavedRect, то инкапсулировать поля будет лишним, т.к. их изменение не сломает логику, и позволяет дизайнеру править данные без необходимости менять ориентацию в редакторе, и к тому же делает данные открытыми и следовательно простыми для проверки. Если вас неустраивает большой контроллер с кучей значений, то Unity предоставляет возможность свернуть эти поля типа SavedRect.