У начинающих обычно проблемы с царапинами при въезде в гараж и всякое там сожженное сцепление.
И эти проблемы отлично решаются парктрониками, камерами и автоматической коробкой передач, которые есть в комплектациях даже самых дешевых европейских авто.
Провод вполне себе можно использовать с согласия пользователя/владельца ПК. Более того, его можно использовать для тестирования своей системы безопасности.
Только вот если убить вхлам дешевую тачку, типа 99, то есть шанс убить вхлам и себя вместе. А с нормальной, безопасной, комфортной машиной есть вообще шанс не попасть в аварию, потому что есть ABS и куча других систем стабилизации, а в случае аварии есть и нормальный деформируемый кузов, и подушки безопасности.
Если у вас, например, один маленький магазин - то да. А если у вас сеть из десятков и сотен точек в разных странах, то эта задача становиться не такой уж и дорогой.
и было бы странно при просмотре видосиков вводить номера кредитных карт
Вполне себе типичный юзкейс для многих пользователей, когда в соцсети находиться какой-нить товар или магазин и открывается это зачастую встроенным WebView. Лучше, конечно, ссылки открывать внешним браузерам, но многим пользователям это объяснить довольно сложно.
Например, те же бухгалтера не смогут проводить счета по ночам, так как рабочий день банков никто не отменял
Почему? Это вопрос софта. У нас бухгалтер на удаленке уже давно, многие документы проводятся в нерабочее время, система их посылает уже утром ближайшего рабочего дня.
А то все сразу давай защищать наш неприкосновенный и священный обед
Видимо, у вас проблем с ЖКТ не было, а они точно появятся, если не есть по 8 часов (или сколько вы хотите рабочий день, если релиз нужно срочно закрыть, как вы говорите). Очень весело потом бегать по врачам, потому что менеджеру нужно релиз сделать сегодня, да еще и программистом на рабочем месте полюбоваться, конечно же.
Сваливать все на не эффективного менеджера, когда вы в установленные (а самое главное УТВЕРЖДЕННЫЕ вами) сроки не выполнили поставленную задачу.
А зачем вы, как проектный менеджер, нанимаете таких исполнителей и даете им такие сроки, которые приводят к постоянным срывам? Это же на проектном менеджере лежит планирование? А именно оно и провалено.
во втором - раздуваем сроки и бюджеты для заказчика.
У нас в компании такая практика и была. При этом заказчик нашей работы - наша же компания, то есть бюджет устраивал - главное чтобы все релизилось четко в установленные сроки и релизы были стабильными.
воспользоваться той процедурой, которую (как считается) ты знать должен.
Можно, конечно, написать на все случаи жизни инструкции размером в книгу, которые люди (которые могут меняться раз в пару месяцев, например в кол-центре, или на складе) должны знать, и при этом жаловаться, что постоянно приходят жалобы на "ошибки", так как пользователь забыл/не знал что делать дальше.
А можно на каждую такую жалобу изменять UX и функционал так, чтобы у пользователя и вопроса не возникало, что делать дальше (предоставлять функционал для исправления ошибки, или передавать задачу другому исполнителю/начальству).
Второй способ у нас, конечно, занял много времени - но очень разгрузил отдел разработки, так что появилось больше времени на внедрение полезного функционала и меньше времени стало уходить на объяснение сотрудникам, что делать при очередной ошибке. При этом возросла эффективность и самих сотрудников - они теперь в большинстве ситуаций сразу решают проблему компании, или клиентов - без ожидания ответа от IT в несколько дней. Но да, такой подход требует если не отдельного аналитика в разработке, то как минимум очень грамотного подхода к ней и выделения на это финансов.
И эти проблемы отлично решаются парктрониками, камерами и автоматической коробкой передач, которые есть в комплектациях даже самых дешевых европейских авто.
Можно, как и убиться на дорогой машине с хорошей безопасностью. Просто сложнее.
Провод вполне себе можно использовать с согласия пользователя/владельца ПК. Более того, его можно использовать для тестирования своей системы безопасности.
Зато убить компанию, ее данные, или потерять кучу денег/клиентов из-за простоя - вполне возможно.
Потому же, почему разработчики корпоративного софта слежения с кейлоггерами, скриншотами экранов, прослушкой микрофонов не арестованы.
Только вот если убить вхлам дешевую тачку, типа 99, то есть шанс убить вхлам и себя вместе. А с нормальной, безопасной, комфортной машиной есть вообще шанс не попасть в аварию, потому что есть ABS и куча других систем стабилизации, а в случае аварии есть и нормальный деформируемый кузов, и подушки безопасности.
Для .NET Core вполне может подойти AWS Lambda (на нем есть бесплатный лимит), или аналог на Azure, а для фронта - GitHub Pages.
С этим неплохо и GitHub Pages справляется.
Как правило, после допуска еще несколько лет ездить за границу нельзя будет...
Если у вас, например, один маленький магазин - то да. А если у вас сеть из десятков и сотен точек в разных странах, то эта задача становиться не такой уж и дорогой.
В которой точно нет сторонних трекеров (не от авторов приложения, а от модификации), и точно нет никакого вредоносного кода...
Вполне себе типичный юзкейс для многих пользователей, когда в соцсети находиться какой-нить товар или магазин и открывается это зачастую встроенным WebView. Лучше, конечно, ссылки открывать внешним браузерам, но многим пользователям это объяснить довольно сложно.
Можно сразу планировать автоматический перевыпуск сертификата, сейчас это решается без каких-либо проблем.
Кэшировать 404 тоже можно, но тогда нужно инвалидировать кэш при добавлении страниц отдач.
Почему? Это вопрос софта. У нас бухгалтер на удаленке уже давно, многие документы проводятся в нерабочее время, система их посылает уже утром ближайшего рабочего дня.
Видимо, у вас проблем с ЖКТ не было, а они точно появятся, если не есть по 8 часов (или сколько вы хотите рабочий день, если релиз нужно срочно закрыть, как вы говорите). Очень весело потом бегать по врачам, потому что менеджеру нужно релиз сделать сегодня, да еще и программистом на рабочем месте полюбоваться, конечно же.
А зачем вы, как проектный менеджер, нанимаете таких исполнителей и даете им такие сроки, которые приводят к постоянным срывам? Это же на проектном менеджере лежит планирование? А именно оно и провалено.
У нас в компании такая практика и была. При этом заказчик нашей работы - наша же компания, то есть бюджет устраивал - главное чтобы все релизилось четко в установленные сроки и релизы были стабильными.
Вы именно для контроля того, что обед откладывается на завтра, так убеждаете, что визуальный контроль и надзор за сотрудниками жизненно необходим для успешного завершения проектов?
Можно, конечно, написать на все случаи жизни инструкции размером в книгу, которые люди (которые могут меняться раз в пару месяцев, например в кол-центре, или на складе) должны знать, и при этом жаловаться, что постоянно приходят жалобы на "ошибки", так как пользователь забыл/не знал что делать дальше.
А можно на каждую такую жалобу изменять UX и функционал так, чтобы у пользователя и вопроса не возникало, что делать дальше (предоставлять функционал для исправления ошибки, или передавать задачу другому исполнителю/начальству).
Второй способ у нас, конечно, занял много времени - но очень разгрузил отдел разработки, так что появилось больше времени на внедрение полезного функционала и меньше времени стало уходить на объяснение сотрудникам, что делать при очередной ошибке. При этом возросла эффективность и самих сотрудников - они теперь в большинстве ситуаций сразу решают проблему компании, или клиентов - без ожидания ответа от IT в несколько дней.
Но да, такой подход требует если не отдельного аналитика в разработке, то как минимум очень грамотного подхода к ней и выделения на это финансов.