Вы не любите Powershell? Да вы просто не умееете его готовить! ;-)
Вам не нравится расхлябанность с неописанными переменными? Включите строгий режим (Set-StrictMode -Version Latest).
Вам не нравится, что Powershell по-разному работает с последовательностями из 0, 1 и нескольких элементов? Используйте операцию @(...)
Вам не нравится, что Powershell передает результаты функций через конвейер? Да, отучить его от этого нельзя — потому что он все-таки shell. Идеология у него такая. Но к этому можно приноровиться — просто привыкните сразу выбрасывать все лишнее: ставьте [Void] перед вызовами внешних команд, функций и в прочих местах, где значение результата надо проигнорировать.
И тогда вы наверняка перестанете бояться и полюбите Powershell. Потому что он позволяет ещё много чего. В частности — с легкостью пользоваться практически всей библиотекой времени выполнения .NET (мне, как человеку, хорошо знакомому с C#, это очень полезно).
PS Лично я полюбил Powershell, потому что много работал с MS Exchange, а там, начиная с Exch2K7, альтернатив просто не было.
PPS Вы, AFAIK давно работаете с MS SQL. Не поделетесь, чем вы пользовались для написания скриптов до появления в нем Powershell? vbscript/jscript+ADO? Или — isql/osql с последующим мучением разбора текстового вывода средствами cmd? Это я чисто для себя интересуюсь — потому что я в те давние времена этот вопрос для себя так и не решил.
20% — это по явно нерепрезентативной выборке, о чем написано прямо в статье по приведенной вами ссылке:
По словам Полякова, никаких отличий в статистике ложного отцовства в России по сравнению со всем миром нет: «Во всем мире процент отцов, воспитывающих не своих детей и не знающих об этом, составляет 5-8%. У нас то же самое, и этот процент не меняется. Да, в статистике нашей компании происходят некоторые изменения — раньше у нас было 10% отрицательных результатов, сейчас примерно 20%. Но это свидетельствует лишь о том, что к нам стали обращаться не с пустыми и глупыми подозрениями, а те, кому это действительно нужно».
Процесс увеличения доли рецессивных генов в таком сценарии — он не одномоментный, а довольно медленный: при более-менее реалистичных предположениях он займет не одно поколение и не два. А там в процессе отбор придет — порядок наведет ;-): отбор начнет снижать эту самую растпространенность генов — по крайней мере, тех, которые вызывают действительно серьезные наследственные заболевания, препятствующие достижению брачного возраста.
И все это — не говоря уж о том, что люди — существа разумные, а потому могут создать какой-нибудь "медико-генетический совет", который будет принимать надлежащие меры. Хотя лично мне идея таких мер (их AFAIK принято именовать "евгеникой") сильно не нравится, но возможность введения таких мер от моего отношения не зависит, увы.
— Проблема в разнице сексуальных стратегий. Начнем с постановки задачи. Женщине нужно 10 лет, чтоб передать свой геном. Мужчине хватит 10 секунд. Согласись, что подобная разница в сроках воспроизводства приводит к диаметрально разным стратегиям поиска партнера? Женщина обязана выбирать лучшего из возможных партнеров. Просто потому, что цена её ошибки несоизмеримо выше.
Само по себе это не проблема. То есть, это, само по себе - не причина для нарушения воспроизводства человечества. Потому что при такой постановке задачи совершенно непонятно, почему один мужчина, который нравится многим женщинам, не может стать для этих многих женщин отцом их детей: в конце концов, от него много усилий на это не требуется.
Причина - в чем-то другом, хотя бы частично. Но без диалектико-материалистического анализа ;-) ее не установить. Так что, требуется продолжение.
Спасибо что рассказли новичкам, что аргументы, которые выглядят как методы, передаются в виде объектов, которые, если их специально не создавать заранее, действительно будут создаваться каждый раз заново, и если это происходит часто - излишне грузить сборщик мусора.
Жаль, что не рассказали, что этот сорт объектов (к нему, в частности, относятся определенные в библиотеке времени выполнения обобщенные типы Func и Action с различным числом аргументов-типов) в C# называется "делегаты" (delegates): знание правильных имен сущностей языка сильно помогает при поиске в документации. Ну, и что можно встретиться с другими типами-делегатами, не толкько со специализациями Action/Func: например, при реализации самодельных объектов-обработчиков (middleware) для конвейера веб-приложения на ASP.NET Core обязательно придется столкнуться с делегатом типа RequestDelegate
Краткий ваш ответ я понял так: что вместо материальной компенсации повышенной (по сравнению со средней по рынку) интенсивности труда работников поддержки вы применяете моральное стимулирование. Что ж, я - родом из СССР, и я на такое успел насмотреться более чем: конкурсы, "Доска почета" и прочее ездение по ушам вместо денег.
Однако если будет новая заметка, то я ее обязательно прочитаю, и, не исключено, что по прочтении поменяю свое мнение согласно изложенным фактам. Но пока что остаюсь при таком.
Все это здорово, но у меня возникает вопрос: а как вы боретесь с текучкой персонала самой техподдержки? Ведь требования к работнику техподдержки у вас явно выше среднерыночных, и при среднерыночной зарплате текучка у вас должна быть неслабая.
Намекать - это понятие тонкое. А что до "как рекомендуется", то сразу вспоминаются разные учебники по ASP.NET Core - там, наверное, в каждом первом тексте, где есть глава про конвейер обработчиков запросов (AKA middleware) и самописные(custom) обработчики, есть пример такого обработчика на базе делегата (обычно - стрелочной функции). И там контейнер сервисов, если используется, то используется через Service Locator, потому что DI в самописные обрабочики-делегаты не завезли.
Но Dependency Injection - он, таки да, раскручен: "четыреDependency Injection - хорошо, двеService Locator - плохо"
От того, что данная реализация IServiceProvider умеет использовать DI, возможность использовать этот контейнер для Service Locator никуда не делась. Так что название, не упоминающее про альтернативную возможность реализации IoC не является точным.
Нет. Точнее - не совсем. Потому что реализация интерфейса, передаваемого как параметр конструктора, ищется перед вызовом метода в контейнере сервисов явным образом, через GetRequiredService:
var runner = serviceProvider.GetRequiredService<IApplicationRunner>();
runner.Run();
Это - Service Locator pattern. Вот если бы он сделал программу на основе шаблона WorkerService - там бы такого вызова не было. А вот разрешение зависимостей где-то внутри контейнера сервисов таки да, можно считать DI. Но вообще этот спор теоретический.
А еще проще - выкинуть async и await, переименовать ExecuteAsync в Execute и сменить его тип возврата на void ;-) Ну, или вообще убрать класс WorkerService а код из этого метода перенести прямо в top-level statements
Имеет. В примере из статьи Dependency Injection отсутствует, да? А почему тогда подключаемое пространство имен (и сборка, содержащая соответствующие классы) называtтся DependencyInjection?
Да, наверное - этот термин встречается сильно чаще. Хотя он и не совсем точный, но людям так будет понятнее. Лично я, однако, предпочитаю называть эту сущность контейнером сервисов (но это совсем не общепринято, да).
Хорошо. Но почему тогда ключевой для реализации IoC интерфейс IServiceProvider описан не в этом пространстве имен, а прямо в System, а?
На самом деле, мы все знаем правильный ответ: "так сложилось исторически". В частности, IServiceProvider пришел в IoC во всех ее видах - хоть DI, хоть Service Locator - откуда-то из компонентной модели организации приложений. А эту модель MS начала развивать ещё с самого начала разработки .NET, потому что ноги этой модели растут из OLE/OLE2/COM, которая еще лет на десять старше, чем .NET и которую MS активно пропагандировала еще в 90-е.
Короче, такими вопросами IMHO лучше себе вообще голову не забивать.
Ужасы PowerShell
Вы не любите Powershell? Да вы просто не умееете его готовить! ;-)
Вам не нравится расхлябанность с неописанными переменными? Включите строгий режим (Set-StrictMode -Version Latest).
Вам не нравится, что Powershell по-разному работает с последовательностями из 0, 1 и нескольких элементов? Используйте операцию @(...)
Вам не нравится, что Powershell передает результаты функций через конвейер? Да, отучить его от этого нельзя — потому что он все-таки shell. Идеология у него такая. Но к этому можно приноровиться — просто привыкните сразу выбрасывать все лишнее: ставьте [Void] перед вызовами внешних команд, функций и в прочих местах, где значение результата надо проигнорировать.
И тогда вы наверняка перестанете бояться и полюбите Powershell. Потому что он позволяет ещё много чего. В частности — с легкостью пользоваться практически всей библиотекой времени выполнения .NET (мне, как человеку, хорошо знакомому с C#, это очень полезно).
PS Лично я полюбил Powershell, потому что много работал с MS Exchange, а там, начиная с Exch2K7, альтернатив просто не было.
PPS Вы, AFAIK давно работаете с MS SQL. Не поделетесь, чем вы пользовались для написания скриптов до появления в нем Powershell? vbscript/jscript+ADO? Или — isql/osql с последующим мучением разбора текстового вывода средствами cmd? Это я чисто для себя интересуюсь — потому что я в те давние времена этот вопрос для себя так и не решил.
Тюрьма, состоящая из одиноких мужчин
Не вижу, чтобы вы что-то пооправили: как было у вас
так и осталось.PS Лично я бы вообще на статью в Коммерсанте как на источник не ссылался
Тюрьма, состоящая из одиноких мужчин
Тюрьма, состоящая из одиноких мужчин
Процесс увеличения доли рецессивных генов в таком сценарии — он не одномоментный, а довольно медленный: при более-менее реалистичных предположениях он займет не одно поколение и не два. А там в процессе отбор придет — порядок наведет ;-): отбор начнет снижать эту самую растпространенность генов — по крайней мере, тех, которые вызывают действительно серьезные наследственные заболевания, препятствующие достижению брачного возраста.
И все это — не говоря уж о том, что люди — существа разумные, а потому могут создать какой-нибудь "медико-генетический совет", который будет принимать надлежащие меры. Хотя лично мне идея таких мер (их AFAIK принято именовать "евгеникой") сильно не нравится, но возможность введения таких мер от моего отношения не зависит, увы.
Тюрьма, состоящая из одиноких мужчин
Не факт. Ибо существует немало видов млекопитающих, у которых процесс размножения AFAIK устроен сходным образом - см. тему про иерархию доминирования.
Тюрьма, состоящая из одиноких мужчин
Само по себе это не проблема. То есть, это, само по себе - не причина для нарушения воспроизводства человечества. Потому что при такой постановке задачи совершенно непонятно, почему один мужчина, который нравится многим женщинам, не может стать для этих многих женщин отцом их детей: в конце концов, от него много усилий на это не требуется.
Причина - в чем-то другом, хотя бы частично. Но без диалектико-материалистического анализа ;-) ее не установить. Так что, требуется продолжение.
Сказка про Method as Parameter
Спасибо что рассказли новичкам, что аргументы, которые выглядят как методы, передаются в виде объектов, которые, если их специально не создавать заранее, действительно будут создаваться каждый раз заново, и если это происходит часто - излишне грузить сборщик мусора.
Жаль, что не рассказали, что этот сорт объектов (к нему, в частности, относятся определенные в библиотеке времени выполнения обобщенные типы Func и Action с различным числом аргументов-типов) в C# называется "делегаты" (delegates): знание правильных имен сущностей языка сильно помогает при поиске в документации. Ну, и что можно встретиться с другими типами-делегатами, не толкько со специализациями Action/Func: например, при реализации самодельных объектов-обработчиков (middleware) для конвейера веб-приложения на ASP.NET Core обязательно придется столкнуться с делегатом типа RequestDelegate
Как так получилось, что техподдержка занялась самопиаром внутри компании
Краткий ваш ответ я понял так: что вместо материальной компенсации повышенной (по сравнению со средней по рынку) интенсивности труда работников поддержки вы применяете моральное стимулирование. Что ж, я - родом из СССР, и я на такое успел насмотреться более чем: конкурсы, "Доска почета" и прочее ездение по ушам вместо денег.
Однако если будет новая заметка, то я ее обязательно прочитаю, и, не исключено, что по прочтении поменяю свое мнение согласно изложенным фактам. Но пока что остаюсь при таком.
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Вы бы показали, что ли, куда это сложность всталвяться будет. А то я в вашем примере это не увидел.
Как так получилось, что техподдержка занялась самопиаром внутри компании
Это - про подготовку и подбор. А я про удержание поинтересовался. В статье по ссылке этого нет.
Или вы в режиме кузницы кадров работаете?
Как так получилось, что техподдержка занялась самопиаром внутри компании
Все это здорово, но у меня возникает вопрос: а как вы боретесь с текучкой персонала самой техподдержки?
Ведь требования к работнику техподдержки у вас явно выше среднерыночных, и при среднерыночной зарплате текучка у вас должна быть неслабая.
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Намекать - это понятие тонкое. А что до "как рекомендуется", то сразу вспоминаются разные учебники по ASP.NET Core - там, наверное, в каждом первом тексте, где есть глава про конвейер обработчиков запросов (AKA middleware) и самописные(custom) обработчики, есть пример такого обработчика на базе делегата (обычно - стрелочной функции). И там контейнер сервисов, если используется, то используется через Service Locator, потому что DI в самописные обрабочики-делегаты не завезли.
Но Dependency Injection - он, таки да, раскручен: "
четыреDependency Injection - хорошо,двеService Locator - плохо"Гайд по настройке IoC-контейнера в консольном приложении .NET core
От того, что данная реализация IServiceProvider умеет использовать DI, возможность использовать этот контейнер для Service Locator никуда не делась. Так что название, не упоминающее про альтернативную возможность реализации IoC не является точным.
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Я увидел, где вы увидели DI. Но Service Locator в примере тоже есть.
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Я, пока вы отвечали, уже поправил свой комментарий.
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Нет. Точнее - не совсем. Потому что реализация интерфейса, передаваемого как параметр конструктора, ищется перед вызовом метода в контейнере сервисов явным образом, через GetRequiredService:
Это - Service Locator pattern. Вот если бы он сделал программу на основе шаблона WorkerService - там бы такого вызова не было.
А вот разрешение зависимостей где-то внутри контейнера сервисов таки да, можно считать DI. Но вообще этот спор теоретический.
Гайд по настройке IoC-контейнера в консольном приложении .NET core
А еще проще - выкинуть async и await, переименовать ExecuteAsync в Execute и сменить его тип возврата на void ;-)
Ну, или вообще убрать класс WorkerService а код из этого метода перенести прямо в top-level statements
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Имеет. В примере из статьи Dependency Injection отсутствует, да? А почему тогда подключаемое пространство имен (и сборка, содержащая соответствующие классы) называtтся DependencyInjection?
Правильный ответ см. выше.
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Да, наверное - этот термин встречается сильно чаще. Хотя он и не совсем точный, но людям так будет понятнее. Лично я, однако, предпочитаю называть эту сущность контейнером сервисов (но это совсем не общепринято, да).
Гайд по настройке IoC-контейнера в консольном приложении .NET core
Хорошо. Но почему тогда ключевой для реализации IoC интерфейс IServiceProvider описан не в этом пространстве имен, а прямо в System, а?
На самом деле, мы все знаем правильный ответ: "так сложилось исторически". В частности, IServiceProvider пришел в IoC во всех ее видах - хоть DI, хоть Service Locator - откуда-то из компонентной модели организации приложений. А эту модель MS начала развивать ещё с самого начала разработки .NET, потому что ноги этой модели растут из OLE/OLE2/COM, которая еще лет на десять старше, чем .NET и которую MS активно пропагандировала еще в 90-е.
Короче, такими вопросами IMHO лучше себе вообще голову не забивать.