День шестьсот восемьдесят первый. #ЧтоНовенького
Критические Изменения в .NET5. Библиотека Базовых Классов (BCL)
В .NET5 внесено несколько критических изменений. Подавляющее большинство из них связано с редкими случаями использования или некорректным поведением в прошлом. Но некоторые могут застать разработчиков врасплох. В первой части этой серии, рассмотрим изменения в BCL.
1. Информация о версии .NET
Некоторые разработчики используют строковое представление версии, а не числовую форму. В случае .NET у разработчиков не было выбора. Отчасти из-за путаницы в нумерации приходилось полагаться на строковое представление, вроде «
В .NET5 моникер представляет из себя просто «
2. Информация о версии ОС
Раньше
3. Расположение файлов в однофайловых приложениях
Когда приложение собрано в один файл вместе с его зависимостями, поведение некоторых API рефлексии перестаёт быть очевидным. В .NET5 все зависимости загружаются прямо из памяти, то есть физического файла сборки не существует. Ниже представлены новые варианты поведения для связанных сборок:
4. Логи
Следующие параметры
5. Сериализация через BinaryFormatter заблокирована
6. UTF-7 заблокирована
Этот формат уже запрещён многими стандартами, такими как HTML5, потому что легко вставить вредоносные строки в приложение, заставив часть приложения думать, что данные находятся в формате UTF-8, в то время как другие части будут обрабатывать данные как UTF-7. Если необходима обработка устаревших данных, UTF-7 можно включить с помощью флага
7. Пакет Microsoft.DotNet.PlatformAbstractions устарел
Разработчикам настоятельно рекомендуется прекратить использование пакета
=>
=>
Критические Изменения в .NET5. Библиотека Базовых Классов (BCL)
В .NET5 внесено несколько критических изменений. Подавляющее большинство из них связано с редкими случаями использования или некорректным поведением в прошлом. Но некоторые могут застать разработчиков врасплох. В первой части этой серии, рассмотрим изменения в BCL.
1. Информация о версии .NET
Некоторые разработчики используют строковое представление версии, а не числовую форму. В случае .NET у разработчиков не было выбора. Отчасти из-за путаницы в нумерации приходилось полагаться на строковое представление, вроде «
.NET Framework #.#» или «.NET Core #.#».В .NET5 моникер представляет из себя просто «
.NET #.#». Приложения и библиотеки, зависящие от определения версии среды выполнения, необходимо обновить.2. Информация о версии ОС
Раньше
Environment.OSVersion могла лгать. Вместо возврата фактической версии ОС могла возвращаться эмулируемая ОС на основе настроек режима совместимости Windows. Теперь будет возвращаться фактическая версия, что больше соответствует ожиданиям разработчиков.3. Расположение файлов в однофайловых приложениях
Когда приложение собрано в один файл вместе с его зависимостями, поведение некоторых API рефлексии перестаёт быть очевидным. В .NET5 все зависимости загружаются прямо из памяти, то есть физического файла сборки не существует. Ниже представлены новые варианты поведения для связанных сборок:
Assembly.Location - возвращает пустую строку,Assembly.CodeBase - выбрасывает исключение,Assembly.GetFile(String) - выбрасывает исключение,Environment.GetCommandLineArgs()[0] - возвращает имя исполняемого файла,AppContext.BaseDirectory - возвращает каталог, в котором находится исполняемый файл.4. Логи
Следующие параметры
ConsoleLoggerOptions отмечены как устаревшие: DisableColors, IncludeScopes, TimestampFormat, UseUtcTimestamp, Format. Они заменяются одним из нескольких подклассов ConsoleFormatterOptions.5. Сериализация через BinaryFormatter заблокирована
BinaryFormatter в .NET существует с самого начала. Предполагалось, что он будет быстрее и компактнее, чем SoapFormatter, основанный на XML. К сожалению, в нём есть ряд проблем, самая важная из которых - невозможность безопасного использования. В .NET 5 BinaryFormatter по умолчанию отключен в приложениях ASP.NET и выдает предупреждение компилятора в других платформах. Если вам нужно его использовать, можно включить его с помощью флага EnableUnsafeBinaryFormatterSerialization.6. UTF-7 заблокирована
Этот формат уже запрещён многими стандартами, такими как HTML5, потому что легко вставить вредоносные строки в приложение, заставив часть приложения думать, что данные находятся в формате UTF-8, в то время как другие части будут обрабатывать данные как UTF-7. Если необходима обработка устаревших данных, UTF-7 можно включить с помощью флага
EnableUnsafeUTF7Encoding.7. Пакет Microsoft.DotNet.PlatformAbstractions устарел
Разработчикам настоятельно рекомендуется прекратить использование пакета
Microsoft.DotNet.PlatformAbstractions для получения информации об операционной системе. Ниже показаны устаревшие методы и их альтернативы:ApplicationEnvironment.ApplicationBasePath=>
AppContext.BaseDirectory
HashCodeCombiner
=>
System.HashCode
RuntimeEnvironment.GetRuntimeIdentifier=>
RuntimeInformation.RuntimeIdentifier
RuntimeEnvironment.OperatingSystemPlatform=>
RuntimeInformation.IsOSPlatform(OSPlatform)
RuntimeEnvironment.RuntimeArchitecture=>
RuntimeInformation.ProcessArchitecture
RuntimeEnvironment.OperatingSystem=>
RuntimeInformation.OSDescription
RuntimeEnvironment.OperatingSystemVersion =>
RuntimeInformation.OSDescription
и Environment.OSVersion
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes/День шестьсот восемьдесят второй. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
69. Читайте код
Мы, программисты, - странные создания. Мы любим писать код. Но когда дело доходит до чтения кода, мы обычно стесняемся и уклоняемся от этого. В конце концов, писать код намного веселее, а читать код сложно, а иногда почти невозможно. Особенно сложно читать чужой код. Не обязательно потому, что этот код плохой, а потому, что они, вероятно, думают и решают проблемы иначе, чем вы. Но задумывались ли вы когда-нибудь о том, что чтение чужого кода может улучшить ваш собственный код?
В следующий раз, когда вы прочитаете какой-нибудь код, остановитесь и подумайте на мгновение. Код читается легко или трудно? Если его трудно читать, то почему? Плохое форматирование? Названия непоследовательны или нелогичны? Один фрагмент кода решает несколько проблем? Возможно, выбор языка мешает читаемости кода. Постарайтесь учиться на ошибках других людей, чтобы не совершать их в вашем коде. Вы можете обнаружить несколько сюрпризов. Например, методы устранения зависимостей могут быть хороши для слабой связи, но иногда они также могут затруднить чтение кода. И то, что одни называют элегантным кодом, другие назовут нечитаемым.
Если код легко читается, остановитесь и посмотрите, есть ли что-то полезное, что вы можете извлечь из него. Возможно, используется какой-то шаблон проектирования, о котором вы не знаете или который раньше вызывал у вас затруднения при реализации. Возможно, методы короче и их названия более выразительны, чем ваши. Некоторые проекты с открытым исходным кодом полны хороших примеров того, как писать блестящий, читаемый код, в то время как другие служат примерами прямо противоположного!
Чтение вашего собственного старого кода из проекта, над которым вы в настоящее время не работаете, также может быть полезным опытом. Начните с самого старого кода и продвигайтесь к более свежему. Вы, вероятно, обнаружите, что его совсем не так легко читать, как когда вы его писали. Ваш ранний код также может немного вас позабавить, вроде рассказа обо всём, что вы говорили, когда пили в пабе прошлой ночью. Посмотрите, как вы развили свои навыки за эти годы, - это может действительно мотивировать. Обратите внимание на то, какие области кода трудно читать, и подумайте, не пишете ли вы код так же сегодня.
Итак, в следующий раз, когда вы почувствуете необходимость улучшить свои навыки программирования, не читайте ещё одну книгу. Читайте код.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Karianne Berg
97 Вещей, Которые Должен Знать Каждый Программист
69. Читайте код
Мы, программисты, - странные создания. Мы любим писать код. Но когда дело доходит до чтения кода, мы обычно стесняемся и уклоняемся от этого. В конце концов, писать код намного веселее, а читать код сложно, а иногда почти невозможно. Особенно сложно читать чужой код. Не обязательно потому, что этот код плохой, а потому, что они, вероятно, думают и решают проблемы иначе, чем вы. Но задумывались ли вы когда-нибудь о том, что чтение чужого кода может улучшить ваш собственный код?
В следующий раз, когда вы прочитаете какой-нибудь код, остановитесь и подумайте на мгновение. Код читается легко или трудно? Если его трудно читать, то почему? Плохое форматирование? Названия непоследовательны или нелогичны? Один фрагмент кода решает несколько проблем? Возможно, выбор языка мешает читаемости кода. Постарайтесь учиться на ошибках других людей, чтобы не совершать их в вашем коде. Вы можете обнаружить несколько сюрпризов. Например, методы устранения зависимостей могут быть хороши для слабой связи, но иногда они также могут затруднить чтение кода. И то, что одни называют элегантным кодом, другие назовут нечитаемым.
Если код легко читается, остановитесь и посмотрите, есть ли что-то полезное, что вы можете извлечь из него. Возможно, используется какой-то шаблон проектирования, о котором вы не знаете или который раньше вызывал у вас затруднения при реализации. Возможно, методы короче и их названия более выразительны, чем ваши. Некоторые проекты с открытым исходным кодом полны хороших примеров того, как писать блестящий, читаемый код, в то время как другие служат примерами прямо противоположного!
Чтение вашего собственного старого кода из проекта, над которым вы в настоящее время не работаете, также может быть полезным опытом. Начните с самого старого кода и продвигайтесь к более свежему. Вы, вероятно, обнаружите, что его совсем не так легко читать, как когда вы его писали. Ваш ранний код также может немного вас позабавить, вроде рассказа обо всём, что вы говорили, когда пили в пабе прошлой ночью. Посмотрите, как вы развили свои навыки за эти годы, - это может действительно мотивировать. Обратите внимание на то, какие области кода трудно читать, и подумайте, не пишете ли вы код так же сегодня.
Итак, в следующий раз, когда вы почувствуете необходимость улучшить свои навыки программирования, не читайте ещё одну книгу. Читайте код.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Karianne Berg
День шестьсот восемьдесят третий. #ЧтоНовенького
Критические Изменения в .NET5. Исторические Технологии
Начало. BCL
Во второй части нашего обзора .NET 5 рассмотрим исторические технологии .NET, которые не были перенесены в .NET Core.
Глобальный кэш сборок
Теория, лежащая в основе глобального кэша сборок (GAC), заключалась в том, чтобы все библиотеки .NET могли храниться в одном централизованном месте с возможностью хранить несколько версий каждой библиотеки, что позволило избавиться от «ада DLL». Но проблемы с версиями остались. К моменту выпуска .NET 4.5 лишь несколько приложений использовали GAC для библиотек сторонних разработчиков. Поэтому неудивительно, что в .NET Core все зависимости развёртываются вместе с приложением, что позволяет изолировать приложение от других. Тем не менее частично API GAC по-прежнему существуют в .NET Core. Они мало полезны, например, свойство, указывающее, содержится ли сборка в GAC, всегда возвращает
Удалённое взаимодействие
Основная идея .NET Remoting в том, что одно приложение могло использовать прокси-объект для управления реальным объектом, запущенным внутри другого приложения. Хотя технически это работало, .NET Remoting никогда не пользовался популярностью из-за трудностей с его правильным использованием и нестабильности. В .NET Core API .NET Remoting не были реализованы. Как и API GAC, они имели только неработающие заполнители. Они также помечены устаревшими и будут в итоге удалены.
Защита доступа к коду
Code Access Security - ещё одна технология .NET Framework, API которой помечены как устаревшие. CAS была создана в эпоху до изолированных контейнеров, таких как Docker. В .NET Framework несколько приложений размещались в одном экземпляре IIS. Теоретически каждое из них изолировано в отдельном домене приложения, но вырваться из него и помешать работе других приложений, работающих в IIS, несложно.
CAS использовался, чтобы ограничить размер возможного ущерба. Основная идея заключалась в том, что опасные API-интерфейсы помечались атрибутами, указывающими на риск. Такие хосты, как IIS, можно настроить для запуска приложений с различными уровнями «доверия», теоретически помещая их в песочницу.
Также CAS использовался для браузерных приложений. Задолго до Silverlight можно было запускать приложения Windows Forms в Internet Explorer. Уровень доверия к приложению частично определялся тем, откуда оно было загружено, при этом сайты интрасети предоставляли более высокие привилегии. Но, как и многие ранние технологии .NET, правильно реализовать CAS было сложно. У вредоносных приложений было множество способов обойти ограничения CAS, в то время как безобидные приложения часто сталкивались с трудностями. Браузерные приложения оказывались заблокированы, а уровни доверия CAS для IIS зачастую игнорировались.
Thread.Abort
Может показаться неожиданным, что Thread.Abort никогда не был реализован в .NET Core. Несмотря на то, что это считалось опасным, но оно было и неизбежным. Простой тайм-аут запроса или отключение клиента в ASP.NET приводило к вызову
К моменту создания ASP.NET Core
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-2/
Критические Изменения в .NET5. Исторические Технологии
Начало. BCL
Во второй части нашего обзора .NET 5 рассмотрим исторические технологии .NET, которые не были перенесены в .NET Core.
Глобальный кэш сборок
Теория, лежащая в основе глобального кэша сборок (GAC), заключалась в том, чтобы все библиотеки .NET могли храниться в одном централизованном месте с возможностью хранить несколько версий каждой библиотеки, что позволило избавиться от «ада DLL». Но проблемы с версиями остались. К моменту выпуска .NET 4.5 лишь несколько приложений использовали GAC для библиотек сторонних разработчиков. Поэтому неудивительно, что в .NET Core все зависимости развёртываются вместе с приложением, что позволяет изолировать приложение от других. Тем не менее частично API GAC по-прежнему существуют в .NET Core. Они мало полезны, например, свойство, указывающее, содержится ли сборка в GAC, всегда возвращает
false. Теперь все API GAC помечены как устаревшие.Удалённое взаимодействие
Основная идея .NET Remoting в том, что одно приложение могло использовать прокси-объект для управления реальным объектом, запущенным внутри другого приложения. Хотя технически это работало, .NET Remoting никогда не пользовался популярностью из-за трудностей с его правильным использованием и нестабильности. В .NET Core API .NET Remoting не были реализованы. Как и API GAC, они имели только неработающие заполнители. Они также помечены устаревшими и будут в итоге удалены.
Защита доступа к коду
Code Access Security - ещё одна технология .NET Framework, API которой помечены как устаревшие. CAS была создана в эпоху до изолированных контейнеров, таких как Docker. В .NET Framework несколько приложений размещались в одном экземпляре IIS. Теоретически каждое из них изолировано в отдельном домене приложения, но вырваться из него и помешать работе других приложений, работающих в IIS, несложно.
CAS использовался, чтобы ограничить размер возможного ущерба. Основная идея заключалась в том, что опасные API-интерфейсы помечались атрибутами, указывающими на риск. Такие хосты, как IIS, можно настроить для запуска приложений с различными уровнями «доверия», теоретически помещая их в песочницу.
Также CAS использовался для браузерных приложений. Задолго до Silverlight можно было запускать приложения Windows Forms в Internet Explorer. Уровень доверия к приложению частично определялся тем, откуда оно было загружено, при этом сайты интрасети предоставляли более высокие привилегии. Но, как и многие ранние технологии .NET, правильно реализовать CAS было сложно. У вредоносных приложений было множество способов обойти ограничения CAS, в то время как безобидные приложения часто сталкивались с трудностями. Браузерные приложения оказывались заблокированы, а уровни доверия CAS для IIS зачастую игнорировались.
Thread.Abort
Может показаться неожиданным, что Thread.Abort никогда не был реализован в .NET Core. Несмотря на то, что это считалось опасным, но оно было и неизбежным. Простой тайм-аут запроса или отключение клиента в ASP.NET приводило к вызову
Thread.Abort. И если код не был тщательно написан для обработки этого события, это могло привести к утечкам ресурсов, таким как блокировки или открытые транзакции базы данных.К моменту создания ASP.NET Core
CancellationToken стал безопасной и широко распространенной альтернативой Thread.Abort, поэтому не было необходимости реализовывать его в первой версии .NET Core. И хотя .NET Core расширился за пределы веба, ни одна из других основных платформ приложений не нуждалась в Thread.Abort, поэтому этот вызов генерировал исключение PlatformNotSupportedException. В .NET 5 этот метод помечен как устаревший.Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-2/
День шестьсот восемьдесят четвёртый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
1. Разносторонний Рост
Ко второму году работы я уже знал все основы. Я собрал все низко висящие плоды, и мой рост замедлился. Возник большой вопрос: «Как расти дальше?» Я мало что мог сделать, чтобы улучшить свои навыки программирования. Большинство статей и блогов про методы написания более чистого кода, KISS, DRY, YAGNI и т.д. - являются микрооптимизациями. Почти ничего из этого не приносит большой пользы для роста (хотя это не значит, что их не стоит изучать совсем).
Я обнаружил кое-что интересное. Я разрабатываю ПО, но жизненный цикл разработки ПО является частью более крупного жизненного цикла: разработки продукта. Я решил пойти вширь, а не вглубь. Удивительно, но это помогло мне глубже понять то, что я делаю. Я выбрал три основных направления:
1) Изучение того, что делают люди вокруг меня
Поскольку мы не закрыты от общения с коллегами, имеет смысл лучше понять работу менеджеров продукта, продавцов и аналитиков. В конце концов, бизнес зарабатывает на продукте. Цель не в том, чтобы писать код, а в том, чтобы приносить прибыль бизнесу. Большинство крупных компаний не делают что-то одно, а это означает, что в одной и той же компании есть разные пути для извлечения прибыли. Все работники находятся по крайней мере на одном из путей, иначе они бы не работали в компании. Отслеживание этих путей, а также исследование пути, на котором нахожусь я, было очень ценно. Это помогло мне понять, насколько я важен, и какие рычаги я могу использовать, чтобы стать более эффективным. Иногда нужно упростить работу продажникам, чтобы они могли увеличить продажи. В другом случае нужно создать новый функционал для клиентов. В третьем - исправить функцию, которая постоянно ломается.
Менеджеры продукта - лучший источник этой информации. Они знают, как бизнес зарабатывает деньги, кто их клиенты и что им нужно. За год я довольно много встречался с коллегами. Второе преимущество этого - знание контекста работы других. Это помогло мне в общении. Например, один разговор помог мне понять, почему Саре из отдела продаж нужен инструмент массового обновления. В некоторых компаниях много сотрудников, и обновлять их по одному - проблема. Код, который я в итоге написал, буквально избавил Сару от мучений.
2) Тренировка правильных мыслительных привычек
Разработка ПО требует правильного мышления и принятия правильных решений. Написание кода — это реализация этих решений. Мыслительная привычка — это то, что ваш мозг делает регулярно. Это может быть размышление о X всякий раз, когда случается Y, или применение инструмента X к проблеме Y. Короче говоря, мыслительные привычки помогают размышлению. Я предположил, что, если изучить общие принципы, их можно будет применить и в разработке ПО.
3) Правильное мышление
Разработка ПО - отличная область для практики правильного мышления. Циклы обратной связи короче, и оценка правильности решения не занимает много времени. Я погрузился в изучение когнитивных наук. Это полезный навык, который стоит изучить. Он поможет и тому, чем я занимаюсь по работе, и принесёт дивиденды в жизни вообще. Подробнее об этом позже.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd#d46c
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
1. Разносторонний Рост
Ко второму году работы я уже знал все основы. Я собрал все низко висящие плоды, и мой рост замедлился. Возник большой вопрос: «Как расти дальше?» Я мало что мог сделать, чтобы улучшить свои навыки программирования. Большинство статей и блогов про методы написания более чистого кода, KISS, DRY, YAGNI и т.д. - являются микрооптимизациями. Почти ничего из этого не приносит большой пользы для роста (хотя это не значит, что их не стоит изучать совсем).
Я обнаружил кое-что интересное. Я разрабатываю ПО, но жизненный цикл разработки ПО является частью более крупного жизненного цикла: разработки продукта. Я решил пойти вширь, а не вглубь. Удивительно, но это помогло мне глубже понять то, что я делаю. Я выбрал три основных направления:
1) Изучение того, что делают люди вокруг меня
Поскольку мы не закрыты от общения с коллегами, имеет смысл лучше понять работу менеджеров продукта, продавцов и аналитиков. В конце концов, бизнес зарабатывает на продукте. Цель не в том, чтобы писать код, а в том, чтобы приносить прибыль бизнесу. Большинство крупных компаний не делают что-то одно, а это означает, что в одной и той же компании есть разные пути для извлечения прибыли. Все работники находятся по крайней мере на одном из путей, иначе они бы не работали в компании. Отслеживание этих путей, а также исследование пути, на котором нахожусь я, было очень ценно. Это помогло мне понять, насколько я важен, и какие рычаги я могу использовать, чтобы стать более эффективным. Иногда нужно упростить работу продажникам, чтобы они могли увеличить продажи. В другом случае нужно создать новый функционал для клиентов. В третьем - исправить функцию, которая постоянно ломается.
Менеджеры продукта - лучший источник этой информации. Они знают, как бизнес зарабатывает деньги, кто их клиенты и что им нужно. За год я довольно много встречался с коллегами. Второе преимущество этого - знание контекста работы других. Это помогло мне в общении. Например, один разговор помог мне понять, почему Саре из отдела продаж нужен инструмент массового обновления. В некоторых компаниях много сотрудников, и обновлять их по одному - проблема. Код, который я в итоге написал, буквально избавил Сару от мучений.
2) Тренировка правильных мыслительных привычек
Разработка ПО требует правильного мышления и принятия правильных решений. Написание кода — это реализация этих решений. Мыслительная привычка — это то, что ваш мозг делает регулярно. Это может быть размышление о X всякий раз, когда случается Y, или применение инструмента X к проблеме Y. Короче говоря, мыслительные привычки помогают размышлению. Я предположил, что, если изучить общие принципы, их можно будет применить и в разработке ПО.
3) Правильное мышление
Разработка ПО - отличная область для практики правильного мышления. Циклы обратной связи короче, и оценка правильности решения не занимает много времени. Я погрузился в изучение когнитивных наук. Это полезный навык, который стоит изучить. Он поможет и тому, чем я занимаюсь по работе, и принесёт дивиденды в жизни вообще. Подробнее об этом позже.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd#d46c
Автор оригинала – Neil Kakkar
День шестьсот восемьдесят пятый. #Оффтоп
Перенесём разговоры по воскресеньям на разговоры по вторникам))) Судя по всему, на неделе обсуждения получаются активнее. Действительно, что ещё делать в течение дня, работать что ли?
Вчера вечером по Москве и сильно ранним утром по североамериканскому времени у Google случился массивный сбой, который привёл к перебоям в работе, судя по всему, всех сервисов, где требовалась аутентификация. По этому поводу бывший разработчик Google, наш старый знакомый, Клемент Михайлеску, выпустил видео о том, как такого рода проблемы решаются в крупных компаниях.
В двух словах, в компании есть «On Call»-инженеры (инженеры на вызове), которым могут позвонить в середине ночи в случае, если случается что-то серьёзное. Насколько я понял, эта роль передаётся по очереди всем разработчикам. Давайте обсудим. Есть ли такое в вашей компании? Случалось ли это с вами, что было (если не секрет), и что было за это вам?)))
Перенесём разговоры по воскресеньям на разговоры по вторникам))) Судя по всему, на неделе обсуждения получаются активнее. Действительно, что ещё делать в течение дня, работать что ли?
Вчера вечером по Москве и сильно ранним утром по североамериканскому времени у Google случился массивный сбой, который привёл к перебоям в работе, судя по всему, всех сервисов, где требовалась аутентификация. По этому поводу бывший разработчик Google, наш старый знакомый, Клемент Михайлеску, выпустил видео о том, как такого рода проблемы решаются в крупных компаниях.
В двух словах, в компании есть «On Call»-инженеры (инженеры на вызове), которым могут позвонить в середине ночи в случае, если случается что-то серьёзное. Насколько я понял, эта роль передаётся по очереди всем разработчикам. Давайте обсудим. Есть ли такое в вашей компании? Случалось ли это с вами, что было (если не секрет), и что было за это вам?)))
День шестьсот восемьдесят шестой. #Оффтоп
The API Book
Случайно наткнулся на довольно занятную книгу. Ну как книгу, она пока в стадии написания, но значительная часть её уже готова. "The API Book" за авторством Сергея Константинова. Найти её можно на гитхабе автора как в английском, так и в русском варианте.
Книга посвящена созданию API. Пока готов первый раздел, посвящённый проектированию. Я только начал читать, поэтому полного впечатления о книге пока не составил. Однако, судя по первым главам, довольно интересное, лёгкое теоретическое чтение. Автор не грузит техническими деталями, примеры на псевдокоде. Поможет как для приобретения практических навыков, так и для общего развития.
«Ключевой вопрос, который вы должны задать себе <при проектировании API>, выглядит так: какую проблему мы решаем? Задать его следует четыре раза с ударением на каждом из четырёх слов.»
Подробности в книге по ссылке выше.
The API Book
Случайно наткнулся на довольно занятную книгу. Ну как книгу, она пока в стадии написания, но значительная часть её уже готова. "The API Book" за авторством Сергея Константинова. Найти её можно на гитхабе автора как в английском, так и в русском варианте.
Книга посвящена созданию API. Пока готов первый раздел, посвящённый проектированию. Я только начал читать, поэтому полного впечатления о книге пока не составил. Однако, судя по первым главам, довольно интересное, лёгкое теоретическое чтение. Автор не грузит техническими деталями, примеры на псевдокоде. Поможет как для приобретения практических навыков, так и для общего развития.
«Ключевой вопрос, который вы должны задать себе <при проектировании API>, выглядит так: какую проблему мы решаем? Задать его следует четыре раза с ударением на каждом из четырёх слов.»
Подробности в книге по ссылке выше.
День шестьсот восемьдесят седьмой. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Начало 1/3
В третьей части нашего обзора .NET 5 рассмотрим ASP.NET.
- BCL
- Исторические технологии
1. Сериализация
Числа, которые отображаются как строки в кавычках
2. Заменённые пакеты
Были переименованы или заменены различные пакеты:
API
=>
- Незначащие пробелы будут удаляться из файлов .razor во время компиляции. Это может привести к устранению сотен пустых узлов, которые потребляют память и пропускную способность сети несмотря на то, что не влияют на отображаемый HTML. Тестирование Microsoft показало улучшение времени рендеринга до 40%.
- В структуре
- Авторам библиотек, поддерживающих как .NET Core 3.x, так и .NET 5, потребуется использовать условную ссылку на пакет
Blazor в .NET 5 требует дополнительных функций, которые недоступны в старых браузерах. Internet Explorer не будет поддерживаться вообще. Ранее IE 11 мог получить доступ к веб-сайтам на основе Blazor через polyfills и asm.js. Но, по словам Дэниела Рота, с этим «было много проблем, и опыт использования был не очень хорош», поэтому в Microsoft отказались от asm.js и сосредоточились на WebAssembly.
Никакой конкретной причины относительно Edge Legacy не было указано, но, похоже, это сделано потому, что браузер больше не будет поддерживаться с 9 марта 2021 года. Edge Legacy был официально заменён браузером на основе Chromium.
5. Логи в HttpClient
В .NET Core логи HttpClient записывались с именами кодов ответа HTTP:
Продолжение следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
Критические Изменения в .NET5. ASP.NET. Начало 1/3
В третьей части нашего обзора .NET 5 рассмотрим ASP.NET.
- BCL
- Исторические технологии
1. Сериализация
Числа, которые отображаются как строки в кавычках
{ "Number": "5" }, теперь могут быть десериализованы с помощью стандартного инструмента System.Text.Json.JsonSerializer в числовые свойства, как если бы они были обычными числами в JSON. Раньше это вызвало исключение JsonException.2. Заменённые пакеты
Были переименованы или заменены различные пакеты:
AzureAD.UI=>
Microsoft.Identity.Web,API
AzureADB2C.UI =>
Microsoft.Identity.Web,Microsoft.AspNetCore.DataProtection=>
.AzureKeyVault
Azure.Extensions.AspNetCore
.DataProtection.Keys,Microsoft.AspNetCore.DataProtection=>
.AzureStorage
Azure.Extensions.AspNetCore
.DataProtection.Blobs,Microsoft.Extensions=>
.Configuration.AzureKeyVault
Azure.Extensions.AspNetCore
.Configuration.Secrets
3. Изменения в Blazor для производительности- Незначащие пробелы будут удаляться из файлов .razor во время компиляции. Это может привести к устранению сотен пустых узлов, которые потребляют память и пропускную способность сети несмотря на то, что не влияют на отображаемый HTML. Тестирование Microsoft показало улучшение времени рендеринга до 40%.
- В структуре
RenderTreeFrame различные публичные поля только для чтения, были заменены публичными свойствами только для чтения. Это изменение нарушает двоичный код, но не нарушает исходный код. То есть код не нужно будет изменять, но нужно будет перекомпилировать для работы с новой версией.- Авторам библиотек, поддерживающих как .NET Core 3.x, так и .NET 5, потребуется использовать условную ссылку на пакет
Microsoft.AspNetCore.Components для учёта обеих версий:<PackageReference Include="Microsoft.AspNetCore.Components" Version="3.0.0" Condition="'$(TargetFramework)' == 'netstandard2.0'" />4. Blazor прекращает поддержку IE и Edge Legacy
<PackageReference Include="Microsoft.AspNetCore.Components" Version="5.0.0-rc.1.*" Condition="'$(TargetFramework)' != 'netstandard2.0'" />
Blazor в .NET 5 требует дополнительных функций, которые недоступны в старых браузерах. Internet Explorer не будет поддерживаться вообще. Ранее IE 11 мог получить доступ к веб-сайтам на основе Blazor через polyfills и asm.js. Но, по словам Дэниела Рота, с этим «было много проблем, и опыт использования был не очень хорош», поэтому в Microsoft отказались от asm.js и сосредоточились на WebAssembly.
Никакой конкретной причины относительно Edge Legacy не было указано, но, похоже, это сделано потому, что браузер больше не будет поддерживаться с 9 марта 2021 года. Edge Legacy был официально заменён браузером на основе Chromium.
5. Логи в HttpClient
В .NET Core логи HttpClient записывались с именами кодов ответа HTTP:
Received HTTP response after 56.0044ms - OKДля большей согласованности с другими частями .NET это поведение было изменено на использование числовых кодов:
End processing HTTP request after 70.0862ms – OK
Received HTTP response after 56.0044ms - 200Целью изменения было устранение несоответствия, из-за которого «затруднялось выполнение запросов через структурированные системы ведения логов, такие как Elasticsearch». Если вам нужно сохранить старое поведение, Microsoft рекомендует взять исходный код классов логирования для версии .NET Core 3.1 и включить их в свой проект. Возможно, это впервые, когда Microsoft используют открытый исходный код для решения проблемы обратной совместимости.
End processing HTTP request after 70.0862ms – 200
Продолжение следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
День шестьсот восемьдесят восьмой. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Продолжение 2/3
Продолжаем рассматривать изменения в ASP.NET в .NET5.
- BCL
- Исторические технологии
- ASP.NET. Начало
6. Исключение BadHttpRequestException заменено на BadHttpRequestException
Это странное изменение является результатом наличия в .NET трех классов
-
-
-
Поскольку все они означают одно и то же, это сочли избыточным. Теперь используется только версия Http, другие были отмечены как устаревшие. Для некоторой обратной совместимости они будут унаследованы от версии Http.
7. Повторное согласование сертификата HttpSys отключено
Чтобы повысить производительность, предотвратить взаимоблокировки и поддерживать совместимость с HTTP/2, HttpSys по умолчанию не будет повторно согласовывать сертификаты клиентов. Несмотря на то, что его можно включить, Microsoft не рекомендует этого делать.
8. MVC: ObjectModelValidator вызывает новую перегрузку ValidationVisitor.Validate
Исходная сигнатура этого метода:
В .NET 5 введена новая виртуальная перегрузка, и
9. Отменена кодировка имени файла cookie
В стандарте HTTP имена файлов cookie представляют собой ограниченный набор символов ASCII. Для удобства разработчиков многие платформы, включая ASP.NET Core, позволяют включать дополнительные символы и просто кодируют их. Эта возможность была удалена по соображениям безопасности. Если в имени есть не-ASCII символ, может возникнуть исключение. Значения файлов cookie будут по-прежнему кодироваться/декодироваться как обычно.
Окончание следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
Критические Изменения в .NET5. ASP.NET. Продолжение 2/3
Продолжаем рассматривать изменения в ASP.NET в .NET5.
- BCL
- Исторические технологии
- ASP.NET. Начало
6. Исключение BadHttpRequestException заменено на BadHttpRequestException
Это странное изменение является результатом наличия в .NET трех классов
BadHttpRequestException. Их полные имена:-
Microsoft.AspNetCore.Server
.Kestrel.BadHttpRequestException, -
Microsoft.AspNetCore.Server
.IIS.BadHttpRequestException и -
Microsoft.AspNetCore
.Http.BadHttpRequestException. Поскольку все они означают одно и то же, это сочли избыточным. Теперь используется только версия Http, другие были отмечены как устаревшие. Для некоторой обратной совместимости они будут унаследованы от версии Http.
7. Повторное согласование сертификата HttpSys отключено
Чтобы повысить производительность, предотвратить взаимоблокировки и поддерживать совместимость с HTTP/2, HttpSys по умолчанию не будет повторно согласовывать сертификаты клиентов. Несмотря на то, что его можно включить, Microsoft не рекомендует этого делать.
8. MVC: ObjectModelValidator вызывает новую перегрузку ValidationVisitor.Validate
Исходная сигнатура этого метода:
public virtual bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel)Разработчики могут перегружать его для выполнения своей логики проверки. Затем этот метод вызывается объектом
ObjectModelValidator.В .NET 5 введена новая виртуальная перегрузка, и
ObjectModelValidator теперь вызывает её:public virtual bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel, object container)При этом старая версия оставлена, и просто вызывает новую, передавая
null в последний параметр. Если разработчик переопределит исходный метод Validate, то в .NET5 это переопределение будет проигнорировано. Код будет компилироваться, но ObjectModelValidator вместо переопределённого разработчиком метода вызовет новую перегрузку, и переопределённая версия просто не будет работать без каких-либо объяснений. Если вы посчитали, что это редко используемый функционал, то заметьте, что переопределяет этот метод, например, пакет FluentValidation (хотя, его код уже, похоже, исправили)9. Отменена кодировка имени файла cookie
В стандарте HTTP имена файлов cookie представляют собой ограниченный набор символов ASCII. Для удобства разработчиков многие платформы, включая ASP.NET Core, позволяют включать дополнительные символы и просто кодируют их. Эта возможность была удалена по соображениям безопасности. Если в имени есть не-ASCII символ, может возникнуть исключение. Значения файлов cookie будут по-прежнему кодироваться/декодироваться как обычно.
Окончание следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
День шестьсот восемьдесят девятый. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Окончание 3/3
В этом посте завершим обзор важных изменений в ASP.NET, введённых в .NET 5.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
10. SignalR: протокол хаба MessagePack теперь использует MessagePackSerializerOptions
Ранее SignalR использовал MessagePack 1 для сериализации сообщений. В .NET 5 он был обновлен для использования MessagePack 2. Поскольку в MessagePack 2 было сделано критическое изменение (переход от
11. SignalR теперь требует маршрутизации конечных точек
Маршрутизация конечных точек появилась в ASP.NET Core 3. Подробнее о том, зачем она была введена, я писал в этом посте. SignalR в это же время добавил возможность использовать маршрутизацию конечных точек, но это было необязательно. Старый механизм настраиваемой маршрутизации все ещё был доступен, хотя и отмечен как устаревший. В .NET 5 старый метод был полностью удалён, и теперь необходимо использовать конечную точку. К счастью, изменения в коде минимальны. Вместо:
Последнее изменение, которое мы обсудим в этом блоке - это соответствие стандартам для файлов CSV. По странному недосмотру предыдущие версии ASP.NET Core обслуживали статические файлы CSV как
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
Критические Изменения в .NET5. ASP.NET. Окончание 3/3
В этом посте завершим обзор важных изменений в ASP.NET, введённых в .NET 5.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
10. SignalR: протокол хаба MessagePack теперь использует MessagePackSerializerOptions
Ранее SignalR использовал MessagePack 1 для сериализации сообщений. В .NET 5 он был обновлен для использования MessagePack 2. Поскольку в MessagePack 2 было сделано критическое изменение (переход от
IFormatterResolver к MessagePackSerializerOptions), в SignalR потребовалось внести аналогичное изменение в процесс обработки конфигурации. Это изменение повлияет только на тех, кто изменяет MessagePackHubProtocolOptions для SignalR.11. SignalR теперь требует маршрутизации конечных точек
Маршрутизация конечных точек появилась в ASP.NET Core 3. Подробнее о том, зачем она была введена, я писал в этом посте. SignalR в это же время добавил возможность использовать маршрутизацию конечных точек, но это было необязательно. Старый механизм настраиваемой маршрутизации все ещё был доступен, хотя и отмечен как устаревший. В .NET 5 старый метод был полностью удалён, и теперь необходимо использовать конечную точку. К счастью, изменения в коде минимальны. Вместо:
app.UseSignalR(routes =>надо использовать
{
routes.MapHub<SomeHub>("/path");
});
app.UseEndpoints(endpoints =>12. Статические файлы: тип содержимого CSV изменен на соответствующий стандартам
{
endpoints.MapHub<SomeHub>("/path");
});
Последнее изменение, которое мы обсудим в этом блоке - это соответствие стандартам для файлов CSV. По странному недосмотру предыдущие версии ASP.NET Core обслуживали статические файлы CSV как
application/octet-stream, вместо text/csv. Это может повлиять на то, как браузеры обрабатывают эти файлы, что раньше заставляло разработчиков использовать FileExtensionContentTypeProvider для переопределения этого поведения. Теперь будет использоваться правильный тип содержимого. Если же разработчикам, использующим ASP.NET Core 5, потребуется старое поведение, они могут использовать всё тот же FileExtensionContentTypeProvider, чтобы вернуться к application/octet-stream.Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
День шестьсот девяностый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
70. Изучайте Гуманитарные Науки
Практически в любом проекте разработки ПО, кроме самых маленьких, люди работают с другими людьми. Во всех областях исследований, кроме самых абстрактных, люди пишут для людей ПО, которое поможет им в достижении какой-либо цели. Люди пишут программы вместе с людьми для людей. Этот бизнес связан с людьми. К сожалению, в процессе обучения программистов очень мало внимания уделяется аспекту взаимодействия с людьми, с которыми они работают. К счастью, есть целая область исследований, которая может помочь.
Например, Людвиг Витгенштейн приводит очень хороший пример в «Философских исследованиях», что любой язык, который мы используем для общения друг с другом, не является – и не может быть – универсальным форматом для передачи мысли, идеи или изображения из головы одного человека в голову другого. Поэтому мы должны быть готовы к недопониманиям уже на этапе сбора требований. Витгенштейн также показывает, что наша способность понимать друг друга вовсе не возникает из общих определений, она возникает из общего опыта, образа жизни. Это может быть одной из причин, по которой программисты, стремящиеся разобраться в проблемах своей проблемной области, как правило, добиваются большего успеха, чем те, кто дистанцируется от неё.
Лакофф и Джонсон представляют нам сборник «Метафоры, которыми мы живем» (Дж. Лакофф, М. Джонсон - ЛКИ, 2008) предполагая, что язык в значительной степени метафоричен, и что эти метафоры дают представление о том, как мы воспринимаем мир. Даже такие, казалось бы, конкретные термины, как «денежный поток» (cash flow), используемый в разговоре о финансовой системе, можно рассматривать как метафору: «деньги как вода». Как эта метафора влияет на наше восприятие систем, работающих с деньгами? Или же часто используется метафора слоёв в стеке протоколов, где пользовательские слои «вверху», а детали технологии «внизу». Это влияет на то, как мы представляем структуру систем, которые мы строим. Это также может указывать на стремление мыслить шаблонно, от чего время от времени бывает полезно отказываться.
Мартин Хайдеггер внимательно изучил, как люди пользуются инструментами. Программисты создают, меняют, дорабатывают и используют инструменты. Инструменты – постоянный объект интереса программистов. Но для пользователей, как показывает Хайддегер в книге «Бытие и время», инструмент невидим, и понять его можно только при использовании. Для пользователей инструменты становятся объектами изучения только тогда, когда они не работают. Это различие в акцентах стоит иметь в виду всякий раз, когда обсуждается удобство использования.
Элеонора Рош пересмотрела модель категорий Аристотеля, согласно которой мы выстраиваем своё понимание мира. Когда программисты спрашивают пользователей об их желаниях относительно системы, они, как правило, просят дать определения на основе предикатов (некоторых утверждений о субъекте разговора). Например, делать что-то, если случаются события A, B или C. Для программистов это очень удобно. Предикаты могут легко стать атрибутами класса или столбцами в таблице. Эти категории чёткие, непересекающиеся и аккуратные. К сожалению, как показала Рош в работе «Естественные категории» ("Natural categories", Rosch, E. H. - Cognitive Psychology, 1973) и более поздних работах, обычные люди понимают мир иначе. Они постигают его на примерах. Некоторые примеры, так называемые прототипы, лучше других. Поэтому результаты могут получаться нечёткими, перекрываться с другими и иметь сложную внутреннюю структуру. Поскольку мы настаиваем на аристотелевских ответах, мы не можем задать пользователям правильных вопросов, отсюда и сложности в достижении взаимопонимания.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Keith Braithwaite
97 Вещей, Которые Должен Знать Каждый Программист
70. Изучайте Гуманитарные Науки
Практически в любом проекте разработки ПО, кроме самых маленьких, люди работают с другими людьми. Во всех областях исследований, кроме самых абстрактных, люди пишут для людей ПО, которое поможет им в достижении какой-либо цели. Люди пишут программы вместе с людьми для людей. Этот бизнес связан с людьми. К сожалению, в процессе обучения программистов очень мало внимания уделяется аспекту взаимодействия с людьми, с которыми они работают. К счастью, есть целая область исследований, которая может помочь.
Например, Людвиг Витгенштейн приводит очень хороший пример в «Философских исследованиях», что любой язык, который мы используем для общения друг с другом, не является – и не может быть – универсальным форматом для передачи мысли, идеи или изображения из головы одного человека в голову другого. Поэтому мы должны быть готовы к недопониманиям уже на этапе сбора требований. Витгенштейн также показывает, что наша способность понимать друг друга вовсе не возникает из общих определений, она возникает из общего опыта, образа жизни. Это может быть одной из причин, по которой программисты, стремящиеся разобраться в проблемах своей проблемной области, как правило, добиваются большего успеха, чем те, кто дистанцируется от неё.
Лакофф и Джонсон представляют нам сборник «Метафоры, которыми мы живем» (Дж. Лакофф, М. Джонсон - ЛКИ, 2008) предполагая, что язык в значительной степени метафоричен, и что эти метафоры дают представление о том, как мы воспринимаем мир. Даже такие, казалось бы, конкретные термины, как «денежный поток» (cash flow), используемый в разговоре о финансовой системе, можно рассматривать как метафору: «деньги как вода». Как эта метафора влияет на наше восприятие систем, работающих с деньгами? Или же часто используется метафора слоёв в стеке протоколов, где пользовательские слои «вверху», а детали технологии «внизу». Это влияет на то, как мы представляем структуру систем, которые мы строим. Это также может указывать на стремление мыслить шаблонно, от чего время от времени бывает полезно отказываться.
Мартин Хайдеггер внимательно изучил, как люди пользуются инструментами. Программисты создают, меняют, дорабатывают и используют инструменты. Инструменты – постоянный объект интереса программистов. Но для пользователей, как показывает Хайддегер в книге «Бытие и время», инструмент невидим, и понять его можно только при использовании. Для пользователей инструменты становятся объектами изучения только тогда, когда они не работают. Это различие в акцентах стоит иметь в виду всякий раз, когда обсуждается удобство использования.
Элеонора Рош пересмотрела модель категорий Аристотеля, согласно которой мы выстраиваем своё понимание мира. Когда программисты спрашивают пользователей об их желаниях относительно системы, они, как правило, просят дать определения на основе предикатов (некоторых утверждений о субъекте разговора). Например, делать что-то, если случаются события A, B или C. Для программистов это очень удобно. Предикаты могут легко стать атрибутами класса или столбцами в таблице. Эти категории чёткие, непересекающиеся и аккуратные. К сожалению, как показала Рош в работе «Естественные категории» ("Natural categories", Rosch, E. H. - Cognitive Psychology, 1973) и более поздних работах, обычные люди понимают мир иначе. Они постигают его на примерах. Некоторые примеры, так называемые прототипы, лучше других. Поэтому результаты могут получаться нечёткими, перекрываться с другими и иметь сложную внутреннюю структуру. Поскольку мы настаиваем на аристотелевских ответах, мы не можем задать пользователям правильных вопросов, отсюда и сложности в достижении взаимопонимания.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Keith Braithwaite
День шестьсот девяносто первый. #ЧтоНовенького
Нововведения в GitHub
Ручные Подтверждения в GitHub Actions
В GitHub Actions в бета версии появились функции развёртывания. Теперь вы можете:
1. Визуализировать пайплайн
2. Создавать среды, в которых можно устанавливать
- Рецензентов, которые подтверждают развёртывание вручную
- Время ожидания перед запуском развёртывания
- Секреты специфичные для каждой среды
Перейдите в Settings > Environments и создайте новую среду. Задайте имя среды и нажмите Configure environment. Добавьте требуемых рецензентов, установив флажок Required reviewers (вы можете добавить список людей и/или команд). После этого не забудьте нажать Save protection rules (см. картинку 1 ниже).
Теперь можно отредактировать файл YAML. В него нужно добавить блок:
Появится красивая визуализация пайплайна (см. картинку 2 ниже). Как видите, процесс прошёл стадии развёртывания и функциональных тестов, а затем остановился. Теперь он ждёт подтверждения от заданных рецензентов. У рецензентов, соответственно, появляется сообщение, что процесс развёртывания ждёт подтверждения. После получения подтверждения процесс продолжается.
Обсуждения
До сих пор GitHub предлагал только Issues и Pull Requests в качестве площадки для обсуждений. Проблема в том, что они имеют линейный формат и хорошо подходят для обсуждения изменений в коде, но не для создания базы знаний сообщества. Беседам нужно отдельное место - для этого и созданы GitHub Discussions.
Обсуждения привязаны к репозиторию вашего проекта. Их многопоточный формат позволяет легко начинать, отвечать и организовывать неструктурированные беседы. Вопросы могут быть отмечены как отвеченные, поэтому со временем база знаний сообщества будет расти естественным образом. А поскольку обсуждения не закрываются, как Issues, они могут легко служить местом для хранения часто задаваемых вопросов и другой совместной документации.
Источники:
- https://devblogs.microsoft.com/devops/i-need-manual-approvers-for-github-actions-and-i-got-them-now/
- https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/
Нововведения в GitHub
Ручные Подтверждения в GitHub Actions
В GitHub Actions в бета версии появились функции развёртывания. Теперь вы можете:
1. Визуализировать пайплайн
2. Создавать среды, в которых можно устанавливать
- Рецензентов, которые подтверждают развёртывание вручную
- Время ожидания перед запуском развёртывания
- Секреты специфичные для каждой среды
Перейдите в Settings > Environments и создайте новую среду. Задайте имя среды и нажмите Configure environment. Добавьте требуемых рецензентов, установив флажок Required reviewers (вы можете добавить список людей и/или команд). После этого не забудьте нажать Save protection rules (см. картинку 1 ниже).
Теперь можно отредактировать файл YAML. В него нужно добавить блок:
environment:Обратите внимание, что имя среды в YAML файле должно совпадать с именем среды, заданной в параметрах GitHub выше.
name: <имя среды>
url: <url развёрнутого в среде сайта>
Появится красивая визуализация пайплайна (см. картинку 2 ниже). Как видите, процесс прошёл стадии развёртывания и функциональных тестов, а затем остановился. Теперь он ждёт подтверждения от заданных рецензентов. У рецензентов, соответственно, появляется сообщение, что процесс развёртывания ждёт подтверждения. После получения подтверждения процесс продолжается.
Обсуждения
До сих пор GitHub предлагал только Issues и Pull Requests в качестве площадки для обсуждений. Проблема в том, что они имеют линейный формат и хорошо подходят для обсуждения изменений в коде, но не для создания базы знаний сообщества. Беседам нужно отдельное место - для этого и созданы GitHub Discussions.
Обсуждения привязаны к репозиторию вашего проекта. Их многопоточный формат позволяет легко начинать, отвечать и организовывать неструктурированные беседы. Вопросы могут быть отмечены как отвеченные, поэтому со временем база знаний сообщества будет расти естественным образом. А поскольку обсуждения не закрываются, как Issues, они могут легко служить местом для хранения часто задаваемых вопросов и другой совместной документации.
Источники:
- https://devblogs.microsoft.com/devops/i-need-manual-approvers-for-github-actions-and-i-got-them-now/
- https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/
День шестьсот девяносто второй. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День шестьсот девяносто третий.
Nuget Пакеты, с Которыми Должен Быть Знаком Каждый .NET разработчик
1. xUnit и NUnit
Пакеты для юнит-тестов. Ничего необычного.
2. Moq и NSubstitute
Также для написания юнит-тестов – пакеты для создания фиктивных объектов в тестах.
3. Polly
Пакет для осуществления повторных попыток. Если у вас есть API, который может быть недоступен какое-то время, вам необходимо реализовать механизм повторения запросов, и Polly очень облегчит вам жизнь.
4. FluentAssertions
Снова вернёмся к юнит-тестам. Этот пакет позволяет создавать утверждения, вызывая цепочку методов, что делает выражение близким к обычному английскому языку, например:
Один из самых известных пакетов вообще и для теста производительности вашего кода в частности.
6. Serilog
Пакет для ведения журналов. Хотя, здесь можно назвать и ещё несколько похожих. Да и логгер по умолчанию от Майкрософт в последнее время переписан и усовершенствован.
7. Autofixture и Bogus
Эти пакеты позволяют вам сгенерировать тестовые данные для вашей базы данных на стадии разработки, либо для тестов. По умолчанию Autofixture создаст случайные данные, тогда как Bogus больше ориентирован на домен, и создаст данные близкие к реальности.
8. Scrutor
Пакет, расширяющий встроенные в .NET возможности внедрения зависимостей. Работает на соглашениях об именовании. Также позволяет декорировать внедрённую зависимость.
9. Automapper
Очень широко используемый пакет для связи объектов передачи данных (DTO) с объектами бизнес-логики.
10. Dapper и Entity Framework Core
Описание ORM пакетов потянет на целую книгу. Здесь стоит отметить, что эти 2 пакета можно использовать совместно. Например, Dapper для чтения из БД из-за его скорости, а EF Core – для записи, поскольку он хорошо справляется со сложными запросами на модификацию данных.
11. MediatR
Очень широко используемый пакет для реализации паттерна CQRS.
12. FluentValidation
Аналогично FluentAssertions предоставляет интерфейс цепочки методов для валидации объектов.
13. Swagger, Refit и RestSharp
Пакеты, позволяющие вам создавать клиентов для ваших REST API. Первые два больше полагаются на созданные вами объекты модели, последний предоставляет fluent-интерфейс.
14. Json.NET
Пакет от Newtonsoft для сериализации/десериализации в JSON. Майкрософт довольно неплохо усовершенствовали стандартную сериализацию, но Json.NET всё ещё превосходит её во многих аспектах.
Какие полезные NuGet пакеты вы используете? Оставляйте варианты в комментариях.
Источник: https://www.youtube.com/watch?v=qapJwFY9y2Y
Nuget Пакеты, с Которыми Должен Быть Знаком Каждый .NET разработчик
1. xUnit и NUnit
Пакеты для юнит-тестов. Ничего необычного.
2. Moq и NSubstitute
Также для написания юнит-тестов – пакеты для создания фиктивных объектов в тестах.
3. Polly
Пакет для осуществления повторных попыток. Если у вас есть API, который может быть недоступен какое-то время, вам необходимо реализовать механизм повторения запросов, и Polly очень облегчит вам жизнь.
4. FluentAssertions
Снова вернёмся к юнит-тестам. Этот пакет позволяет создавать утверждения, вызывая цепочку методов, что делает выражение близким к обычному английскому языку, например:
actual.Should().Contain("EF").And.HaveLength(6)…
5. BenchmarkDotNetОдин из самых известных пакетов вообще и для теста производительности вашего кода в частности.
6. Serilog
Пакет для ведения журналов. Хотя, здесь можно назвать и ещё несколько похожих. Да и логгер по умолчанию от Майкрософт в последнее время переписан и усовершенствован.
7. Autofixture и Bogus
Эти пакеты позволяют вам сгенерировать тестовые данные для вашей базы данных на стадии разработки, либо для тестов. По умолчанию Autofixture создаст случайные данные, тогда как Bogus больше ориентирован на домен, и создаст данные близкие к реальности.
8. Scrutor
Пакет, расширяющий встроенные в .NET возможности внедрения зависимостей. Работает на соглашениях об именовании. Также позволяет декорировать внедрённую зависимость.
9. Automapper
Очень широко используемый пакет для связи объектов передачи данных (DTO) с объектами бизнес-логики.
10. Dapper и Entity Framework Core
Описание ORM пакетов потянет на целую книгу. Здесь стоит отметить, что эти 2 пакета можно использовать совместно. Например, Dapper для чтения из БД из-за его скорости, а EF Core – для записи, поскольку он хорошо справляется со сложными запросами на модификацию данных.
11. MediatR
Очень широко используемый пакет для реализации паттерна CQRS.
12. FluentValidation
Аналогично FluentAssertions предоставляет интерфейс цепочки методов для валидации объектов.
13. Swagger, Refit и RestSharp
Пакеты, позволяющие вам создавать клиентов для ваших REST API. Первые два больше полагаются на созданные вами объекты модели, последний предоставляет fluent-интерфейс.
14. Json.NET
Пакет от Newtonsoft для сериализации/десериализации в JSON. Майкрософт довольно неплохо усовершенствовали стандартную сериализацию, но Json.NET всё ещё превосходит её во многих аспектах.
Какие полезные NuGet пакеты вы используете? Оставляйте варианты в комментариях.
Источник: https://www.youtube.com/watch?v=qapJwFY9y2Y
День шестьсот девяносто четвёртый.
Microsoft вводит бесплатное продление сертификатов
За последний год в Microsoft Azure добавили более 1000 новых возможностей. Быстрые темпы технологических изменений меняют и картину востребованных навыков в цифровом мире.
В Microsoft Learn создали набор тренингов и сертификатов, призванных помочь техническим специалистам оставаться в курсе событий. В 2021 году вводится несколько обновлений в программы сертификации.
Во-первых, сертифицированным специалистам предоставляется возможность продлить свои сертификаты Microsoft, изначально полученные путём сдачи экзаменов. В начале февраля 2021 года можно будет продлить срок действия сертификатов, пройдя бесплатный аттестационный тест в Microsoft Learn. Вместо того, чтобы пересдавать экзамены, тест можно пройти онлайн в удобное для вас время в течение шести месяцев до истечения срока действия вашего сертификата. После прохождения аттестации сертификация продлевается ещё на один год с текущей даты истечения срока действия. И это можно делать ежегодно. Для помощи в подготовке будет доступна бесплатная коллекция учебных модулей для каждого аттестационного теста.
Во-вторых, срок действия сертификатов теперь ограничен годом, начиная с даты получения. С июня 2021 г. это изменение вступит в силу для новых сертификатов. Переход на одногодичный срок действия сертификации зависит от того, насколько быстро меняются облачные технологии. Ежегодное обновление сертификатов подтверждает, что навыки и способность выполнять свои должностные обязанности актуальны на рынке.
Этот новый подход побуждает специалистов оставаться на волне актуальных технологий, но в то же время позволяет снизить нагрузку и затраты на поддержание активности вашей сертификации.
Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/stay-current-with-in-demand-skills-through-free-certification/ba-p/1489678
Microsoft вводит бесплатное продление сертификатов
За последний год в Microsoft Azure добавили более 1000 новых возможностей. Быстрые темпы технологических изменений меняют и картину востребованных навыков в цифровом мире.
В Microsoft Learn создали набор тренингов и сертификатов, призванных помочь техническим специалистам оставаться в курсе событий. В 2021 году вводится несколько обновлений в программы сертификации.
Во-первых, сертифицированным специалистам предоставляется возможность продлить свои сертификаты Microsoft, изначально полученные путём сдачи экзаменов. В начале февраля 2021 года можно будет продлить срок действия сертификатов, пройдя бесплатный аттестационный тест в Microsoft Learn. Вместо того, чтобы пересдавать экзамены, тест можно пройти онлайн в удобное для вас время в течение шести месяцев до истечения срока действия вашего сертификата. После прохождения аттестации сертификация продлевается ещё на один год с текущей даты истечения срока действия. И это можно делать ежегодно. Для помощи в подготовке будет доступна бесплатная коллекция учебных модулей для каждого аттестационного теста.
Во-вторых, срок действия сертификатов теперь ограничен годом, начиная с даты получения. С июня 2021 г. это изменение вступит в силу для новых сертификатов. Переход на одногодичный срок действия сертификации зависит от того, насколько быстро меняются облачные технологии. Ежегодное обновление сертификатов подтверждает, что навыки и способность выполнять свои должностные обязанности актуальны на рынке.
Этот новый подход побуждает специалистов оставаться на волне актуальных технологий, но в то же время позволяет снизить нагрузку и затраты на поддержание активности вашей сертификации.
Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/stay-current-with-in-demand-skills-through-free-certification/ba-p/1489678
День шестьсот девяносто пятый. #ЧтоНовенького
Критические Изменения в .NET5. WPF/Windows Forms
В заключительной части нашего обзора критических изменений в .NET 5 рассмотрим WPF/Windows Forms.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
- ASP.NET Core. Окончание
Windows Forms, наряду с веб-формами, консолью и службами Windows, была одной из исходных сред приложений в первом .NET, вышедшем в 2002 году. Среда действует как тонкая оболочка для нативных элементов управления Windows. Это обеспечивает хорошую производительность, но довольно ограничено в настройках. Первое серьезное изменение в WinForms появилось в .NET 2.0 в 2005 году. Были заменены различные пользовательские элементы управления. С тех пор технология считается «завершённой». Единственные заметные изменения - это периодические обновления для поддержки мониторов с более высоким разрешением. Даже долго не решаемые ошибки обычно игнорировались, к большому раздражению разработчиков на WinForms.
Windows Presentation Foundation (WPF) была первой попыткой Microsoft создать полностью настраиваемую среду графического интерфейса. Несмотря на то, что он был выпущен всего через 4 года после WinForms, потребовалось время, чтобы стать общепринятым, поскольку шаблоны и концепции проектирования были более сложными. Производительность также может быть проблемой. Двумя ключевыми особенностями WPF были использование XAML для макета пользовательского интерфейса и шаблона MVVM для привязки данных. Как и WinForms, WPF долгие годы считался «законченным». Он даже не получил поддержки XAML-2009 после того, как спецификация XAML была выпущена в 2012 году. Такие проекты, как Avalonia, пытались сгладить недостатки WPF, например, позволяя привязку событий непосредственно к методу модели или модели представления.
1. Новый SDK
В .NET Core 3.x для WPF и WinForms требовался специальный SDK
2. Убран вывод в консоль
Хотя подавляющее большинство приложений WPF и WinForms не отображаются в консоли, на самом деле это не запрещено, это просто значение по умолчанию. Если нужно, вы можете установить для
3. Улучшенная обработка ошибок
В Windows Forms для .NET Core 3 большей части кода валидации просто не существовало. То есть переданный недопустимый аргумент мог вызвать исключение
4. Удалены элементы управления строки состояния
Одним из элементов управления, заменённых в .NET Framework 2, стал
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-windows/
Критические Изменения в .NET5. WPF/Windows Forms
В заключительной части нашего обзора критических изменений в .NET 5 рассмотрим WPF/Windows Forms.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
- ASP.NET Core. Окончание
Windows Forms, наряду с веб-формами, консолью и службами Windows, была одной из исходных сред приложений в первом .NET, вышедшем в 2002 году. Среда действует как тонкая оболочка для нативных элементов управления Windows. Это обеспечивает хорошую производительность, но довольно ограничено в настройках. Первое серьезное изменение в WinForms появилось в .NET 2.0 в 2005 году. Были заменены различные пользовательские элементы управления. С тех пор технология считается «завершённой». Единственные заметные изменения - это периодические обновления для поддержки мониторов с более высоким разрешением. Даже долго не решаемые ошибки обычно игнорировались, к большому раздражению разработчиков на WinForms.
Windows Presentation Foundation (WPF) была первой попыткой Microsoft создать полностью настраиваемую среду графического интерфейса. Несмотря на то, что он был выпущен всего через 4 года после WinForms, потребовалось время, чтобы стать общепринятым, поскольку шаблоны и концепции проектирования были более сложными. Производительность также может быть проблемой. Двумя ключевыми особенностями WPF были использование XAML для макета пользовательского интерфейса и шаблона MVVM для привязки данных. Как и WinForms, WPF долгие годы считался «законченным». Он даже не получил поддержки XAML-2009 после того, как спецификация XAML была выпущена в 2012 году. Такие проекты, как Avalonia, пытались сгладить недостатки WPF, например, позволяя привязку событий непосредственно к методу модели или модели представления.
1. Новый SDK
В .NET Core 3.x для WPF и WinForms требовался специальный SDK
Microsoft.NET.Sdk.WindowsDesktop. В .NET5 они используют Microsoft.NET.Sdk, как и любой другой проект. Однако целевой платформой должна быть net5.0-windows, а не просто net5.0.2. Убран вывод в консоль
Хотя подавляющее большинство приложений WPF и WinForms не отображаются в консоли, на самом деле это не запрещено, это просто значение по умолчанию. Если нужно, вы можете установить для
OutputType значение Exe вместо WinExe. В .NET5 параметр OutputType будет игнорироваться, если вы также не установите для DisableWinExeOutputInference значение true.3. Улучшенная обработка ошибок
В Windows Forms для .NET Core 3 большей части кода валидации просто не существовало. То есть переданный недопустимый аргумент мог вызвать исключение
NullReferenceException или просто вести себя неопределённым образом. В .NET5 будет выброшено более соответствующее исключение ArgumentException, ArgumentNullException или ArgumentOutOfRangeException. 4. Удалены элементы управления строки состояния
Одним из элементов управления, заменённых в .NET Framework 2, стал
StatusBar. Эквивалент в .NET 2 - StatusStrip. В Microsoft не объяснили, почему его нужно было удалить, возможно, затраты на обслуживание были слишком высоки для элемента, о существовании которого большинство людей даже не подозревает. StatusBar уже очень давно не отображается в панели инструментов дизайнера и полностью удалён в .NET5.Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-windows/
День шестьсот девяносто шестой. #Оффтоп
Доброй рабоче-нерабочей субботы, дорогие товарищи. На сегодня у меня для вас лёгенькое 3х-часовое интервью с 78-летним программистом от IT Бороды. https://www.youtube.com/watch?v=eqsg3Blzmdg Жёсткие диски бы делать из таких людей!
Доброй рабоче-нерабочей субботы, дорогие товарищи. На сегодня у меня для вас лёгенькое 3х-часовое интервью с 78-летним программистом от IT Бороды. https://www.youtube.com/watch?v=eqsg3Blzmdg Жёсткие диски бы делать из таких людей!
День шестьсот девяносто седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
День шестьсот девяносто восьмой. #MoreEffectiveCSharp
18. Предпочитайте Переопределения Обработчикам Событий
Многие классы .NET предоставляют два разных способа обработки событий. Вы можете подписать обработчик событий или переопределить виртуальную функцию базового класса. Внутри производных классов вы всегда должны переопределять виртуальную функцию. Ограничьте использование обработчиков событий реагированием на события в несвязанных объектах.
Рассмотрим код приложения WPF, где нужно реагировать на события нажатия мыши. Вы можете переопределить метод
Хорошо, но подписка на события зачем-то добавлена. Зачем?
1. Переопределения предназначены для производных классов. Но сторонние классы должны использовать механизм событий.
2. XAML поддерживает декларативную подписку на события. То есть дизайнер приложения в визуальном редакторе может выбрать действие при нажатии мыши, если оно доступно, и не добавлять работы программисту.
3. Это позволяет подписываться на события во время выполнения. Вы можете подключить разные обработчики событий, в зависимости от обстоятельств выполнения программы.
4. Возможно подключить несколько обработчиков к одному событию.
Итого
Когда у вас есть одна функция, которая обрабатывает одно событие в производном классе, переопределение является лучшим подходом. Это решение легче поддерживать, оно с большей вероятностью сохранит корректность с течением времени и более эффективно. Оставьте обработчики событий для других целей.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 18.
18. Предпочитайте Переопределения Обработчикам Событий
Многие классы .NET предоставляют два разных способа обработки событий. Вы можете подписать обработчик событий или переопределить виртуальную функцию базового класса. Внутри производных классов вы всегда должны переопределять виртуальную функцию. Ограничьте использование обработчиков событий реагированием на события в несвязанных объектах.
Рассмотрим код приложения WPF, где нужно реагировать на события нажатия мыши. Вы можете переопределить метод
OnMouseDown():public partial class MainWindow : WindowЛибо вы можете подписать обработчик события, что требует изменений как в файле C#, так и в файле XAML:
{
//…
protected override void OnMouseDown(MouseButtonEventArgs e)
{
DoMouseThings(e);
base.OnMouseDown(e);
}
}
<Window x:Class="WpfApp1.MainWindow"Следует предпочесть первое решение, и вот почему. При переопределении функции сначала вызывается ваш обработчик, а вызов функции базового класса отвечает за вызов любых обработчиков событий в цепочке. В некоторых редких случаях вам может потребоваться заменить поведение по умолчанию, чтобы другие обработчики не вызывались, но зачастую поведение по умолчанию – то, что вам нужно. Кроме того, в первом варианте нужно поддерживать изменение в одном месте, а во втором – в двух.
xmlns:local="clr-namespace:WpfApp1"
mc:Ignorable="d"
Title="MainWindow" Height="350" Width="525"
MouseDown="OnMouseDownHandler">
<Grid></Grid>
</Window>
public partial class MainWindow : Window
{
//…
private void OnMouseDownHandler(
object sender, MouseButtonEventArgs e)
{
DoMouseThings(e);
}
}
Хорошо, но подписка на события зачем-то добавлена. Зачем?
1. Переопределения предназначены для производных классов. Но сторонние классы должны использовать механизм событий.
2. XAML поддерживает декларативную подписку на события. То есть дизайнер приложения в визуальном редакторе может выбрать действие при нажатии мыши, если оно доступно, и не добавлять работы программисту.
3. Это позволяет подписываться на события во время выполнения. Вы можете подключить разные обработчики событий, в зависимости от обстоятельств выполнения программы.
4. Возможно подключить несколько обработчиков к одному событию.
Итого
Когда у вас есть одна функция, которая обрабатывает одно событие в производном классе, переопределение является лучшим подходом. Это решение легче поддерживать, оно с большей вероятностью сохранит корректность с течением времени и более эффективно. Оставьте обработчики событий для других целей.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 18.