Загуглите LimitedConcurrencyLevelTaskScheduler - это стандартная реализация от майков (в общем коде правда её нет). Ставите 1 поток и можно запускать в нем стандартные Task'и, которые так же будут друг за другом выполняться в пуле.
Что-то мне кажется, что не прокатит такая задумка. Проблема в том, что нельзя однозначно сказать, кто будет тем самым "предъявителем". К примеру, у вас есть контроллер, который запрашивает ISomeService и IControllerDependService, при этом ISomeService так же запрашивает IControllerDependService. Как вы будете резолвить нужный вашему контроллеру IControllerDependService, если первым его запросит ISomeService?
То, что вам нужно, это скорее возможность создавать дочерние провайдеры с заменой сервисов. И по идее можно реализовать собственный IControllerActivator, где как раз и делать подмену в зависимости от типа контроллера.
Тут точно не скажешь. Эта виндовая служба любит отжирать под 80-100% от свободного места в оперативке под кэш (у меня прям сейчас 18 из 20Гб свободного съело). Правда, что оно туда кладёт - фиг его знает.
Если сортировка строк подразумевает именно сортировку по коду каждого символа, то вроде как UTF-8 можно напрямую как массив байт сортировать - выйдет то же самое. Так можно избавится от лишних преобразований в string.
А про какую плотную интеграцию речь-то? Судя по примеру, просто добавили профиль публикации (PublishProfile, см. pubxml). Это по сути кастомный набор правил и команд для сборки и dotnet publish знать не знает, что этот DefaultContainer делает.
Проблема не в щелочной батарейке, а в литий ионном аккумуляторе.
Я вот сразу обратил внимание на слишком высокие показатели удельной ёмкости по объёму — 900 Вт*ч/л. У меня в голове всегда висела цифра 400. Сейчас специально проверил и действительно, многие источники про литий ион говорят до 600, ну максимум 700 Вт*ч/л в лабораторных условиях. Проверил по источнику, который вы ниже дали, там около этой цифры есть указатель на источник, но ссылки в статье нет. Да и переход на первоисточник этого источника не дал результата.
Откуда взяли эту цифры (900) я честно говоря не могу понять. Если цифра реальная, то это же должно быть прорывом в мировом масштабе.
Мне кажется, что тут просто очень формально к проверке подошли. В приложении вполне конкретно указано, что и куда должно выводиться. А судя по коду там в консоль лишние данные выводятся (ConsoleWriter не забыл убрать?) и ещё непонятно, как в json пишется (на рабочий стол нужно + в lowerCamelCase). Им может не хочется заморачиваться: что-то лишнее или не так в выводе - не прошёл. Тут задание всё-таки на джуна, наверняка ждут чёткую реализацию поставленной задачи.
Так-то задание в принципе подходит джуну: недолгое, проверяет базовые знания, а главное способность следовать ТЗ.
А по коду, может быть проблема в какой-то излишней переусложнённости. От джуна ожидаешь решение в лоб, а не класс под каждое действие.
Про Faker - в принципе хорошо, но, кажется, это не принципиально было для них, хватило бы любых рандомных значений, подходящих под типы. PersonsGenerator, генерирующий в конструкторе один раз - не очень решение, если уж генератор, то нужен метод типа Generate возвращающий список без сохранения в поле класса. Про сериализацию/десериализацию сложно что-то сказать. Как я понял JsonWriter|JsonReader - это кастомные классы? Не вижу, чтобы пути к файлу указывал. Если уж решил в ООП, то нужно передавать путь к файлу в них извне. ConsoleWriter даже не требовался по заданию. ValueCounter как-то тоже кажется лишним, там два простых Linq запроса. Это из того, что увидел (ссылки на исходники я чёт не нашёл).
Полностью согласен. ThenBy проще воспринимается, особенно, когда ты в мыслях у себя читаешь код: "сначала отсротировать по..., затем по...".
Я и сам, если так подумать, никогда двух OrderBy не писал, как раз из-за того, что оно тупо в мыслях нечитаемо. Но два OrderBy - всё равно рабочий вариант, хотя и не очевидный.
Разве OrderBy(...).OrderBy(...) - это паттерн ошибки?
OrderBy совершает устойчивую сортировку, т.е. не меняет относительное положение в последовательности при совпадении ключа. В итоге при двух OrderBy сначала будет проведена сортировка по первому ключу, а после, сортировка по второму и при этом относительный порядок первой сортировки сохранится.
У ThenBy отличие в том, что она совершает сортировку внутри ключа от предыдущей сортировки.
К примеру, взять второй пример из Unity. Там сначала сортировка идёт по priority, а после по наличию provider. В итоге такой сортировки получается, что сначала стоят элементы без provider, а после - с provider. При этом, в каждой из групп элементы отсортированы по priority.
Я не знаю, что делает данный код, но такая группировка по provider с последующей сортировкой "по весу" очень похоже на что-то вполне рабочее...
Чтобы получить аналогичный результат с ThenBy, нужно вообще говоря вызовы поменять местами:
Если простыми словами описывать, OrderBy().ThenBy() - это своего рода группировка по первому ключу с последующей сортировкой по этому ключу, а потом с сортировкой по второму ключу внутри группы.
Кроме того, в UWP появился Composition API для визуально богатых, но экономичных с точки зрения ресурсов анимаций.
На самом деле это очень крутая часть UWP.
Как-то на работе рассматривали UWP, как целевую платформу для нашего клиентского приложения. Песочница, конечно, сразу сильно расстроила - много ограничений, а обход их частенько не самый тривиальный. Впрочем, на это многие указывали. Всякие API - это конечно местами удобно, но похожее и различными либами добивается в WPF. Но вот когда потыкали UI - это конечно бомба.
Как бы песочница, различные API - это всё круто, но когда UI подтормаживал в WPF - это сильно огорчало. Жаль, что в WPF архитектурно такое не завести.
Кстати, кто-нибудь в курсе: как в Avalonia работают анимации (чисто рендерные)? Изменения в UI пробрасываются (как WPF) или в отдельном потоке (как UWP)?
Действительно, удивили… Впервые слышу об этом.
Инициатива действительно здравая: дать возможность без юридических проволочек создавать мини-детсады «для своих». Но шум есть шум. Печально, что сказать.
Как по мне случай тут проще, чем кажется.
Если они работают неофициально, то это уже повод прикрыть их деятельность.
Если они работают официально, то как бы нарушается Ст. 288 ГК РФ — нельзя размещать в жилых помещениях организации.
А если вдруг они официально и помещение нежилое, то это уже крупный залёт: согласно п.3 ст. 22 ЖК РФ нельзя переводить жилые помещения в нежилые, если под ними расположены жилые.
Есть правда ещё один вариант: Вы живёте в нежилом помещение. Тогда… сами уже виноваты.
Только многоядерность не решает проблему энергопотребления.
Пока стремительно уменьшался техпроцесс было возможно увеличивать количество транзисторов без повышения энергопотребления (как раз это самая многоядерность). Сейчас с этим стало сложнее. Просто так увеличить количество ядер без вреда для энергопотребления уже не выйдет, а пихать в телефон процессор с TDP 100W никто не будет.
А разве у вас в итоге получился не TaskSheduler?
Загуглите LimitedConcurrencyLevelTaskScheduler - это стандартная реализация от майков (в общем коде правда её нет). Ставите 1 поток и можно запускать в нем стандартные Task'и, которые так же будут друг за другом выполняться в пуле.
Что-то мне кажется, что не прокатит такая задумка. Проблема в том, что нельзя однозначно сказать, кто будет тем самым "предъявителем". К примеру, у вас есть контроллер, который запрашивает ISomeService и IControllerDependService, при этом ISomeService так же запрашивает IControllerDependService. Как вы будете резолвить нужный вашему контроллеру IControllerDependService, если первым его запросит ISomeService?
То, что вам нужно, это скорее возможность создавать дочерние провайдеры с заменой сервисов. И по идее можно реализовать собственный IControllerActivator, где как раз и делать подмену в зависимости от типа контроллера.
В том-то и прикол, что ошибки здесь не будет, будет warning. Такая проверка спокойно скомпилируется и запустится.
Это я придираюсь. Так-то понятно, что в такого рода задачах подразумевается класс, но всё же тип в данном случае влияет на решение.
Ну, в задаче не указан тип, так что если там структура, то null быть не может.
Ну если придираться к деталям, то мы ничего не знаем о типе в первом примере. Если это структура, то исправление будет совершенно иным.
Тут точно не скажешь. Эта виндовая служба любит отжирать под 80-100% от свободного места в оперативке под кэш (у меня прям сейчас 18 из 20Гб свободного съело). Правда, что оно туда кладёт - фиг его знает.
То это уже другая задача. В рамках этой можно и массивы сравнить.
Я не говорю, что вы неправильно делаете. Просто указываю на интересный момент.
Если сортировка строк подразумевает именно сортировку по коду каждого символа, то вроде как UTF-8 можно напрямую как массив байт сортировать - выйдет то же самое. Так можно избавится от лишних преобразований в string.
А про какую плотную интеграцию речь-то? Судя по примеру, просто добавили профиль публикации (PublishProfile, см. pubxml). Это по сути кастомный набор правил и команд для сборки и dotnet publish знать не знает, что этот DefaultContainer делает.
Я вот сразу обратил внимание на слишком высокие показатели удельной ёмкости по объёму — 900 Вт*ч/л. У меня в голове всегда висела цифра 400. Сейчас специально проверил и действительно, многие источники про литий ион говорят до 600, ну максимум 700 Вт*ч/л в лабораторных условиях. Проверил по источнику, который вы ниже дали, там около этой цифры есть указатель на источник, но ссылки в статье нет. Да и переход на первоисточник этого источника не дал результата.
Откуда взяли эту цифры (900) я честно говоря не могу понять. Если цифра реальная, то это же должно быть прорывом в мировом масштабе.
Ну что? Теперь посмотрел в сторону .NET? :)
Мне кажется, что тут просто очень формально к проверке подошли. В приложении вполне конкретно указано, что и куда должно выводиться. А судя по коду там в консоль лишние данные выводятся (ConsoleWriter не забыл убрать?) и ещё непонятно, как в json пишется (на рабочий стол нужно + в lowerCamelCase). Им может не хочется заморачиваться: что-то лишнее или не так в выводе - не прошёл. Тут задание всё-таки на джуна, наверняка ждут чёткую реализацию поставленной задачи.
Так-то задание в принципе подходит джуну: недолгое, проверяет базовые знания, а главное способность следовать ТЗ.
А по коду, может быть проблема в какой-то излишней переусложнённости. От джуна ожидаешь решение в лоб, а не класс под каждое действие.
Про Faker - в принципе хорошо, но, кажется, это не принципиально было для них, хватило бы любых рандомных значений, подходящих под типы. PersonsGenerator, генерирующий в конструкторе один раз - не очень решение, если уж генератор, то нужен метод типа Generate возвращающий список без сохранения в поле класса. Про сериализацию/десериализацию сложно что-то сказать. Как я понял JsonWriter|JsonReader - это кастомные классы? Не вижу, чтобы пути к файлу указывал. Если уж решил в ООП, то нужно передавать путь к файлу в них извне. ConsoleWriter даже не требовался по заданию. ValueCounter как-то тоже кажется лишним, там два простых Linq запроса. Это из того, что увидел (ссылки на исходники я чёт не нашёл).
Полностью согласен. ThenBy проще воспринимается, особенно, когда ты в мыслях у себя читаешь код: "сначала отсротировать по..., затем по...".
Я и сам, если так подумать, никогда двух OrderBy не писал, как раз из-за того, что оно тупо в мыслях нечитаемо. Но два OrderBy - всё равно рабочий вариант, хотя и не очевидный.
Разве OrderBy(...).OrderBy(...) - это паттерн ошибки?
OrderBy совершает устойчивую сортировку, т.е. не меняет относительное положение в последовательности при совпадении ключа. В итоге при двух OrderBy сначала будет проведена сортировка по первому ключу, а после, сортировка по второму и при этом относительный порядок первой сортировки сохранится.
У ThenBy отличие в том, что она совершает сортировку внутри ключа от предыдущей сортировки.
К примеру, взять второй пример из Unity. Там сначала сортировка идёт по priority, а после по наличию provider. В итоге такой сортировки получается, что сначала стоят элементы без provider, а после - с provider. При этом, в каждой из групп элементы отсортированы по priority.
Я не знаю, что делает данный код, но такая группировка по provider с последующей сортировкой "по весу" очень похоже на что-то вполне рабочее...
Чтобы получить аналогичный результат с ThenBy, нужно вообще говоря вызовы поменять местами:
.OrderBy(s => string.IsNullOrEmpty(s.provider)).ThenBy(s => s.priority)Если простыми словами описывать, OrderBy().ThenBy() - это своего рода группировка по первому ключу с последующей сортировкой по этому ключу, а потом с сортировкой по второму ключу внутри группы.
Аналогия такая, если я правильно помню вызовы:
.GroupBy(s => string.IsNullOrEmpty(s.provider)).OrderBy(g => g.Key).SelectMany(g => g.OrderBy(s => s.priority))P.S. Извиняюсь, не туда...
Как раз сейчас WinUI 3 уже тыкаем (ну как тыкаем, приложение почти перенесено). Правда сыроват ещё фреймворк, хоть и говорят, что он production-ready.
На самом деле это очень крутая часть UWP.
Как-то на работе рассматривали UWP, как целевую платформу для нашего клиентского приложения. Песочница, конечно, сразу сильно расстроила - много ограничений, а обход их частенько не самый тривиальный. Впрочем, на это многие указывали. Всякие API - это конечно местами удобно, но похожее и различными либами добивается в WPF. Но вот когда потыкали UI - это конечно бомба.
Как бы песочница, различные API - это всё круто, но когда UI подтормаживал в WPF - это сильно огорчало. Жаль, что в WPF архитектурно такое не завести.
Кстати, кто-нибудь в курсе: как в Avalonia работают анимации (чисто рендерные)? Изменения в UI пробрасываются (как WPF) или в отдельном потоке (как UWP)?
Инициатива действительно здравая: дать возможность без юридических проволочек создавать мини-детсады «для своих». Но шум есть шум. Печально, что сказать.
Если они работают неофициально, то это уже повод прикрыть их деятельность.
Если они работают официально, то как бы нарушается Ст. 288 ГК РФ — нельзя размещать в жилых помещениях организации.
А если вдруг они официально и помещение нежилое, то это уже крупный залёт: согласно п.3 ст. 22 ЖК РФ нельзя переводить жилые помещения в нежилые, если под ними расположены жилые.
Есть правда ещё один вариант: Вы живёте в нежилом помещение. Тогда… сами уже виноваты.
Только многоядерность не решает проблему энергопотребления.
Пока стремительно уменьшался техпроцесс было возможно увеличивать количество транзисторов без повышения энергопотребления (как раз это самая многоядерность). Сейчас с этим стало сложнее. Просто так увеличить количество ядер без вреда для энергопотребления уже не выйдет, а пихать в телефон процессор с TDP 100W никто не будет.