Как же мне нравиться когда unit тесты делают чуть ли не серебрянной пулей того что твоя логика работает. Видел кучу раз проекты где они не то что помогают, а только мешают. Особенно когда надо за юниттесть метод где вызываеться 100500 других сервисов. Юнит тест не особо поможет, а вот интегрейшн тест поможет. В общем гарантия работающего решения это тестирование, а не юнит тест.
В доисторические времени типа bool не существовало. Его симулировали на макросах брав за основу тип int. Любое число отличное от нуля было true, а если ноль то false.
Что интересно, есть бесплатный плагин от SonarQube — SonarLint. Недавно его опробовал, и в целом доволен, до этого я использовал Roslynator у которого довольно простые анализаторы. У PVS-Studio гораздо более сложные анализаторы, и это объяснят причину почему они предпочитают иметь stand-alone приложение для анализа. Это позволяет более тщательно проанализировать проект не нагружая основной процесс VS. Что касаеться лицинзий, то SonarLint находиться под лицинзией GPLv3, что позволяет его спокойно использовать в комерческих проектах с закрытым исходным кодом (поправьте если я ошибаюсь, не пробовал пока). PVS-Studio тоже можно бесплатно использовать но надо везде указывать комментарии. Честно говоря с удовольствием бы поставил PVS-Studio, но писать, или добавлять везде комментарии как по мне это слишком. Но это выбор разработчиков, и его надо уважать.
Есть так называемые AzureResourceManager шаблоны с помощью которых можно задеплоить проект в облоко. Вся конфигурация делается в json. Благо примеров много, но если попытаться сделать что-то нестандартное, то становится туго. Другими CI/CD не пользовался. Но мое мнение делать и составлять этим шаблоны неудобно. Причем здесь Azure DevOps? Добавляя таски, за кулисами создается AzureResourceManager шаблон.
Если асинхронный метод выполняется синхронно, то возникают следующие издержки в использовании памяти: для методов async Task издержек нет, а для методов
async Task<T>
перерасход составляет 88 байт на каждую операцию (для платформ x64).
Не совсем, у обычного таска тоже есть оверхед. Потому в .NET Core появился ValueTask (да, не дженерик).
Нет не будет одинаковым. Из-за уязвимости, блок будет сохранен в первоначальном варианте [1,2,3,4,5,6], то есть в другом месте добавлена проверка на этот случай. Ведь имея [1,2,3,4,5,6] нам все равно придется достраивать его до полного дерева, а значит получиться в конечном итоге [1,2,3,4,5,6,5,6]. Вот только если отправить в блокчейн [1,2,3,4,5,6,5,6], то это будет означать, что транзации 5,6 были потрачены два раза, а мы должны это исключить. Поэтому мы не храним повторяющиеся транзакции в блокчейне, а дерево мы достраиваем по мере необходимости. Пусть меня поправят коллеги, если я не прав.
Попробуйте BenchmarkDotNet. Я уверен что он даст гораздо более точные результаты, к тому же он удобен и у него большой функционал. Ну и замерять в Debug режиме смысла много нету, так как финальное приложение в любом случае будет работать в Release.
Я был на севере (Гроннинген), там со вторника, числа 15, было + 13. Мне из солнечной Болгарии из +30 как-то холодно было. Это не говоря о том, что постоянное дует ветер. А целый день хоть и светло, но солнца совсем не было видно. Как вернулся обратно, заболел, собственно всю прошлую неделю провалялся больным дома.
Диалог выглядит как полноценное воссоединение семьи, я думаю можно смело подавать на визу :D
А если серьезно, ездил в командировку неделю назад в Нидерланды, климат совсем не понравился. Люди довольно сдержанные(я бы сказал холодные), что довольно хорошо в проффесиональном плане, но не в личностном.
Хотелось бы увидеть статью об Нидерландах если есть возможность.
1. Локализовать на английском
2. Выставить исходни локализации на гитхаб
3. Принимаем пуллреквесты от людей желающих локализовать для своего родного языка
4. Профит
P.S. Если смотреть правде в глаза, то локализации на английском языке будет более чем достаточно
Не совсем понял суть задачи. Если дело в организации хранения, то было бы неплохо организовать хранение всех менеджеров пучками(группами). Из моей практики, выглядит как довольно подходящий кейс для использования AzureTable. Там как раз можно организовать такое хранение. Плохо то, что там индекс как таковой, только один, и он распространяется на PartionKey, что в данном случае является регионом. А если у вас критерии организации данных постоянно меняются, то это точно не ваш случай. А и зачем вам два микросервиса? Один достает данные другой обрабатывает?
Ну про СУБД вы немного заблуждаетесь, на малых объемах данные её возможно будет достаточно, но как только данные станут более существенны прибегают к созданию ещё одной подобной БД — OLAP. При этом проектируют её оптимизированной под специальные запросы.
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.
Не совсем, у обычного таска тоже есть оверхед. Потому в .NET Core появился ValueTask (да, не дженерик).
А если серьезно, ездил в командировку неделю назад в Нидерланды, климат совсем не понравился. Люди довольно сдержанные(я бы сказал холодные), что довольно хорошо в проффесиональном плане, но не в личностном.
Хотелось бы увидеть статью об Нидерландах если есть возможность.
2. Выставить исходни локализации на гитхаб
3. Принимаем пуллреквесты от людей желающих локализовать для своего родного языка
4. Профит
P.S. Если смотреть правде в глаза, то локализации на английском языке будет более чем достаточно
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.