Тоже предпочитаю избегать использования моков, но иногда приходится мокать внешние контролируемые зависимости (БД для серверных тестов, api для ui тестов), поскольку иначе может сильно замедляться выполнение тестов, поскольку нет возможности параллельно выполнять тесты без их влияния друг на друга.
Легко говорить «не доволен работой — меняй», вот только за пределами IT всё не так просто. Мало кого в других сферах HR-ы заваливают предложениями.
Да и если у работодателя большая часть сотрудников хватаются за любую возможность отдохнуть от работы, то тут есть и вина работодателя. Если рабочие отношения выстроены нормально, то найдутся сотрудники, готовые поработать в такой ситуации, ведь им ещё предстоит работать в этой компании, и действия в подобных ситуациях будут учитываться дальше. Если таких сотрудников почти нет, то, работодатель, ты сам создал такую рабочую атмосферу.
Не совсем. Если метод должен вернуть int, я не могу объявить функцию как async int. Исключение async void доступно только за счёт того, что возврат из метода происходит до завершения асинхронного тела функции. Так что если мне нужно дождаться завершения асинхронного метода или же получить результат, то других вариантов нет
Увы, иногда интерфейс диктует синхронную реализацию, и приходится прибегать к Wait/Result. Радует, что в .Net Core эта проблема решена не приводит к блокировке
А какие варианты реализации этого на сервере? Просто зачастую то, в каком виде данные хранятся и то, в каком виде они возвращаются, совершенно разные вещи. Поэтому непонятно, как реализовать такой универсальный обработчик. Ведь в зависимости от того, какие поля нужны, приходится сильно варьировать запрос, чтобы не убить производительность. Плюс если какие-то поля вернуть в списке — не проблема, то другие вычислять для каждого элемента — дорого и имеет смысл только при запросе деталей одного элемента
Возможность формировать структуру и объем данных на клиенте
Я правильно, что на практике сервер всё равно поддерживает предопределённые запросы и наборы полей под конкретные кейсы? Если да, то в чём тут преимущество?
Если речь об интеграции Angular Universal с ASP.Net Core, то существующее решение вызывает node для рендеринга шаблона. Если всё же есть решение без нода, то тут не обойтись без дублирования шаблонов для двух платформ
Порой возникает необходимость совместить SPA-подход на клиенте (навигация без перезагрузки страницы) с серверным рендерингом (для SEO), с нодом это сделать проще. Angular Universal как раз решает эту задачу
К сожалению, Xamarin выдаёт очень жирные бинарники. И если на iOS ещё удаётся добиться нативной производительности приложения, то с андроидом хуже, в частности из-за необходимости взаимодействия двух рантаймов. Не подскажете, актуальны ли подобные проблемы для RN и NativeScript?
Проприетарной и небезопасной она будет первое время, пока эта сфера только развивается. По мере её популяризации будут появляться более открытые и безопасные решения
Похожая ситуация. Причём если работаю в офисе, то чаще трудней сосредоточиться, а если удалённо из дома, то как правило наоборот с музыкой лучше работа идёт.
Если разработка коммерческая, то в основном CMS, т. к. это ощутимо ускоряет процесс, да и админский пользовательский интерфейс в CMS как правило целиком готов.
Если для себя, то либо самописный фреймворк, либо вообще без фреймворка. Хоть времени на разработку уйдёт больше, работать оно будет на порядок быстрей. Да и с точки зрения безопасности такой подход мне нравится больше.
Конечно такой способ лучше, но к сожалению не на всех хостингах у пользователя есть возможность править его, поэтому лучше держать на готове способ с отключением вывода прямо в коде
Тоже предпочитаю избегать использования моков, но иногда приходится мокать внешние контролируемые зависимости (БД для серверных тестов, api для ui тестов), поскольку иначе может сильно замедляться выполнение тестов, поскольку нет возможности параллельно выполнять тесты без их влияния друг на друга.
Да и если у работодателя большая часть сотрудников хватаются за любую возможность отдохнуть от работы, то тут есть и вина работодателя. Если рабочие отношения выстроены нормально, то найдутся сотрудники, готовые поработать в такой ситуации, ведь им ещё предстоит работать в этой компании, и действия в подобных ситуациях будут учитываться дальше. Если таких сотрудников почти нет, то, работодатель, ты сам создал такую рабочую атмосферу.
iOS же не разрешает сторонние движки, там под капотом сафари?
Но в целом тенденция радует, жизнь веб-разработчика становится проще
Я правильно, что на практике сервер всё равно поддерживает предопределённые запросы и наборы полей под конкретные кейсы? Если да, то в чём тут преимущество?
Гуглу тоже тяжко под хабраэффектом?
Если для себя, то либо самописный фреймворк, либо вообще без фреймворка. Хоть времени на разработку уйдёт больше, работать оно будет на порядок быстрей. Да и с точки зрения безопасности такой подход мне нравится больше.