Хотя мне больше интересно как определение сложность поможет оценить скорость выполнения или затраты по мапяти, если детали реализации того или иного метода могут изменяться от версии к версии .NET, не считая использования векторизации в методах LINQ, которых прибавляется с каждой версией .NET?
Вы даже не представляете, что может твориться в западном стреднестатистическом не продуктовом энтерпрайзе...
Не очень давно была статья по внедрению Option Pattern в ASP.NET приложении, что вроде бы тоже азы (только уже фреймворка), но как показала практика даже люди с 10 годами опыта в программировании в солидных западных компаниях не знакомы не IOption не со способами их регистрации. Поэтому подобное и гораздо более «смешное» не то, что не может, а уже присутствует в кодовой базе довольно солидных корпорации.
Пятничный релиз для внутренних корпоративный приложений не то, что «нормально» явление, а часто единственно возможное решение, потому как пользователи на выходных и их работа ничем не прерывается. За пару дней можно выкатить и опробовать прод, может даже что-то пофиксить и избежать простоя целых отделов, работа которых суммарно дороже овертайма в выходные части команды разработки.
Сначала добавим файл: builder.Configuration.AddJsonFile("appsettings.json"); Затем переменные окружения с нашим префиксом: builder.Configuration.AddEnvironmentVariables("MY_");
Зачем добвлять файлы вручную, если сам ASP.NET Core добавляет их по-умолчанию?
Спасибо) Всё-таки под асинхронным ожиданием я имел в виду общение со сторонними ресурсами с использованием "асинхронного драйвера", то есть второй пример.
Под "долгой" задачей подразумевается задача выполняющаяся более 20 мс? Нужно ли учитывать время ожидания в асинхронных операциях, или же одна действительно асинхронная операция для ThreadPool представляет две операции до и после асинхронного ожидания?
Для MAUI есть C# Markup - можно как и во Flutter создавать представление через код. А вот Авалония поддерживает только очень своеборазные решения через F#.
Я сам за .NET и Java, но благодаря создавшемуся образу "самого простого типизированного" языка, Go часто тащат в стартапы, хотя большие облака в первую очередь поддерживают Java.
Ну это ж получается каша. Одно из ключевых и важнейших преимуществ у .NET перед, например, GoLang, это простота, удобство и скорость разработки.
Хм, помниться, что GoLang как раз продвигали именно за счёт большей простоты и скорости разработки по сравнению с типичными бекэнд языками, то есть Java и C#. Многие предлагают GoLang в качестве первого языка и считают наиболее выгодным для стартапов именно из-за его простоты, сухости и отсутствия «подводных камней». Но я не берусь это утверждать, просто впечатление на основе информации в интернете, с GoLang не возился.
было разработать идеи для новых продуктов и стратегию выхода на рынок
Они потом проверили какая доля из этих "+40%" стали успешными и провальными? Придумать что-то не так и сложно, а успешно внести новый продукт на рынок нужно ещё постараться.
Хотя мне больше интересно как определение сложность поможет оценить скорость выполнения или затраты по мапяти, если детали реализации того или иного метода могут изменяться от версии к версии .NET, не считая использования векторизации в методах LINQ, которых прибавляется с каждой версией .NET?
А от чего не упомянули FrozenDictionary<TKey,TValue> и FrozenSet<T>? Они же созданные именно для поиска элементов.
Код и текст моего авторства. Текст изначально написан на английском и частично переведён на русский при помощи DeepL.
Тесты сломались, потому как в оригинальном маппере потерялся формат даты при парсинге. Заодно добавил тесты на мапперы со структурами.
Нет, такой цели никогда не было, проект был на ручномапперах. Да и кода меньше точно не будет и работать оно быстрее не станет.
Вы даже не представляете, что может твориться в западном стреднестатистическом не продуктовом энтерпрайзе...
Не очень давно была статья по внедрению Option Pattern в ASP.NET приложении, что вроде бы тоже азы (только уже фреймворка), но как показала практика даже люди с 10 годами опыта в программировании в солидных западных компаниях не знакомы не IOption не со способами их регистрации. Поэтому подобное и гораздо более «смешное» не то, что не может, а уже присутствует в кодовой базе довольно солидных корпорации.
Пятничный релиз для внутренних корпоративный приложений не то, что «нормально» явление, а часто единственно возможное решение, потому как пользователи на выходных и их работа ничем не прерывается. За пару дней можно выкатить и опробовать прод, может даже что-то пофиксить и избежать простоя целых отделов, работа которых суммарно дороже овертайма в выходные части команды разработки.
Зачем добвлять файлы вручную, если сам ASP.NET Core добавляет их по-умолчанию?
Как вы соедините строки из коллекции элементов через String.Concat?
С вами не согласны я и все мои коллеги под .NET.
А вы в курсе о поддержке AVX инструкций методами LINQ?
Aggregate и StringBuilder отлично склеивают строки в очень лаконичном синтаксисе.
Спасибо) Всё-таки под асинхронным ожиданием я имел в виду общение со сторонними ресурсами с использованием "асинхронного драйвера", то есть второй пример.
Под "долгой" задачей подразумевается задача выполняющаяся более 20 мс? Нужно ли учитывать время ожидания в асинхронных операциях, или же одна действительно асинхронная операция для ThreadPool представляет две операции до и после асинхронного ожидания?
Для MAUI есть C# Markup - можно как и во Flutter создавать представление через код. А вот Авалония поддерживает только очень своеборазные решения через F#.
Это же прямо описано в документации.
https://learn.microsoft.com/en-us/aspnet/core/signalr/redis-backplane?view=aspnetcore-8.0
Похоже что ппечатка.
Я сам за .NET и Java, но благодаря создавшемуся образу "самого простого типизированного" языка, Go часто тащат в стартапы, хотя большие облака в первую очередь поддерживают Java.
Хм, помниться, что GoLang как раз продвигали именно за счёт большей простоты и скорости разработки по сравнению с типичными бекэнд языками, то есть Java и C#. Многие предлагают GoLang в качестве первого языка и считают наиболее выгодным для стартапов именно из-за его простоты, сухости и отсутствия «подводных камней». Но я не берусь это утверждать, просто впечатление на основе информации в интернете, с GoLang не возился.
Они потом проверили какая доля из этих "+40%" стали успешными и провальными? Придумать что-то не так и сложно, а успешно внести новый продукт на рынок нужно ещё постараться.
Наконец то! Хоть кто-то додумался до адекватных задач на собеседование программистов!