Разработкой сцены занимался дизайнер, который ранее не имел дело с UE. А разработчик помогал доработать логику и устранял проблемы с тенями. Если брать процентное соотношение, то работа Алексея занимала 30% от всего объема.
Попробовали — все работает. Возможно, просто соединение слабое. Рекомендуем все-таки попробовать открыть через ПК, там и поиграться с машинкой можно. На Android этого не сделать)
Не обесценивается, в большинстве случаев воспринимается положительно. Если взять, например, концепцию, то здесь свои нюансы: мы не прорабатываем на пресейле дизайн целиком. Можем отрисовать несколько экранов с нашим видением. Но так как на этом этапе мы еще не выясняем предпочтения заказчика, то шанс попасть в точку примерно 50 на 50. Иногда видения могут сойтись. Но и шанс нарисовать бублик, на который у заказчика хроническая аллергия, тоже есть.
Привет, нет, не всегда. Кроссплатформа тоже неплохо справляется с финтеховскими приложениями. Уровень безопасности Flutter, например, даже выше, чем у нативных решений. Dart во Flutter компилируется в нативный код, который не читается человеком. Это повышает его безопасность, потому что усложняет обработку данных. Злоумышленники не смогут понять принцип работы приложения.
Тут скорее дело привычки. Нам удобнее сразу сделать библиотеку, хотя бы из основных элементов (после утверждения главной страницы заказчиком). Хотя на старте было сложно, долго привыкали к такому подходу, плюс много времени уходило на погружение в нюансы.
Скрывать недостатки, чтобы их просто не было видно? ಠ_ಠ
При ограниченном бюджете внимание уделяется больше критичным местам, это да, но и о не критичных тоже нельзя забывать. Это как минимум не профессионально.
У багов есть критичность, это понятно. Посыл был рассказать, почему 100% багов не убрать и что можно сделать, чтобы их было меньше. А не упарываться в детали, уводя читателя от сути. Ну и логично было дополнить тем, что делают QA, чтобы багов было меньше.
"мы облажались, но если вы нам дадите больше денег - мы исправимся"
Не совсем понятно, где и кто облажался. Речь шла о том, что можно сделать, чтобы багов было меньше: выделить больше ресурсов и провести предпроектную аналитику. Но так как предпроектную аналитику мы проводим практически на всех проектах, то и нет такого, что "мы облажались, дайте нам больше деняк, исправимся"
Поделитесь, если не трудно :)
Здравствуйте. Хорошо, подумаем, как эту тему лучше преподнести. Может есть какие-то тезисы, о которых стоит рассказать отдельно?
Разработкой сцены занимался дизайнер, который ранее не имел дело с UE. А разработчик помогал доработать логику и устранял проблемы с тенями. Если брать процентное соотношение, то работа Алексея занимала 30% от всего объема.
Попробовали — все работает. Возможно, просто соединение слабое. Рекомендуем все-таки попробовать открыть через ПК, там и поиграться с машинкой можно. На Android этого не сделать)
Да, F5 — это для рестарта. В остальном учтем пожелания для дальнейших проектов. Спасибо :)
Здравствуйте! Просто висит, без ошибок? Попробуйте перезагрузить. Мы перепроверили — все работает.
Не обесценивается, в большинстве случаев воспринимается положительно. Если взять, например, концепцию, то здесь свои нюансы: мы не прорабатываем на пресейле дизайн целиком. Можем отрисовать несколько экранов с нашим видением. Но так как на этом этапе мы еще не выясняем предпочтения заказчика, то шанс попасть в точку примерно 50 на 50. Иногда видения могут сойтись. Но и шанс нарисовать бублик, на который у заказчика хроническая аллергия, тоже есть.
Из головы совсем вылетело :))
Ну почти :) В начале (под картинкой) есть расшифровка
Привет, нет, не всегда. Кроссплатформа тоже неплохо справляется с финтеховскими приложениями. Уровень безопасности Flutter, например, даже выше, чем у нативных решений. Dart во Flutter компилируется в нативный код, который не читается человеком. Это повышает его безопасность, потому что усложняет обработку данных. Злоумышленники не смогут понять принцип работы приложения.
Тут скорее дело привычки. Нам удобнее сразу сделать библиотеку, хотя бы из основных элементов (после утверждения главной страницы заказчиком). Хотя на старте было сложно, долго привыкали к такому подходу, плюс много времени уходило на погружение в нюансы.
Такие уведомления — лишь дополнительный инструмент для планирования графиков.
https://github.com/volga-volga/react-native-yamap, а по второму вопросу не подскажем
Да, к несчастью, есть такое, если читать кейс с телефона
Спасибо!
P.S. Больше уже не влазит :))
Благодарим :)
Если есть понимание, что этот код значит, то да, белый. Если этого понимания нет, то можно всякого наворотить.
Скрывать недостатки, чтобы их просто не было видно? ಠ_ಠ
При ограниченном бюджете внимание уделяется больше критичным местам, это да, но и о не критичных тоже нельзя забывать. Это как минимум не профессионально.
У багов есть критичность, это понятно. Посыл был рассказать, почему 100% багов не убрать и что можно сделать, чтобы их было меньше. А не упарываться в детали, уводя читателя от сути. Ну и логично было дополнить тем, что делают QA, чтобы багов было меньше.
"мы облажались, но если вы нам дадите больше денег - мы исправимся"Не совсем понятно, где и кто облажался. Речь шла о том, что можно сделать, чтобы багов было меньше: выделить больше ресурсов и провести предпроектную аналитику. Но так как предпроектную аналитику мы проводим практически на всех проектах, то и нет такого, что "мы облажались, дайте нам больше деняк, исправимся"
Ага, надо бы еще и программистов уволить, надо только придумать, чем их подменить.