День четыреста шестой. #ЧтоНовенького
Краткое сравнение Newtonsoft.Json и System.Text.Json
Я думаю, что важно понять причины написания совершенно новой библиотеки JSON, когда у нас уже есть
Кроме того,
- Имена свойств, которые имеют другой регистр
- Имена свойств в JSON с одинарными/двойными кавычками или без кавычек
- Значения
- Десериализацию свойств JSON по именам в том же регистре
- Имена свойств с двойными кавычками
- Десериализацию свойств JSON в аналогичные типы C# (только
Есть много различий в поведении, которые вы можете найти в этой статье, но главный вопрос в следующем: нужно ли переходить с
Ответ: почти наверняка нет. Между ними есть много тонких различий, которые могут вызвать ошибки во время выполнения. Newtonsoft.Json по-прежнему хорошая абстракция для .NET.
Источник: https://schneids.net/comparing-newtonsoft-json-with-system-text-json
Краткое сравнение Newtonsoft.Json и System.Text.Json
System.Text.Json - это новая библиотека JSON для .NET, отличающаяся по назначению от своего предшественника, Newtonsoft.Json. Если вы уже используете Newtonsoft.Json в существующем проекте, вам скорее всего не нужно переходить на новую библиотеку. Но если для вас критична высокая производительность сериализации/десериализации JSON, используйте System.Text.Json.System.Text.Json был выпущен в прошлом году, и, поскольку он интегрирован в ASP.NET Core 3, я подумал, что нужно кратко сравнить его с наиболее используемым NuGet пакетом - Newtonsoft.Json.Я думаю, что важно понять причины написания совершенно новой библиотеки JSON, когда у нас уже есть
Newtonsoft.Json. System.Text.Json был спроектирован в первую очередь с учётом высокой производительности. Команда .NET (в которую входит Джеймс Ньютон-Кинг, который написал Newtonsoft.Json) обнаружила, что не может реорганизовать Newtonsoft.Json для удовлетворения некоторых из этих требований без внесения несовместимых изменений.Кроме того,
System.Text.Json строго придерживается спецификации JSON RFC 8259, поэтому то, что вы раньше могли делать в Newtonsoft.Json (т.к. она не соответствует спецификации), теперь не разрешено в System.Text.Json. Например, Newtonsoft.Json десериализует:- Имена свойств, которые имеют другой регистр
- Имена свойств в JSON с одинарными/двойными кавычками или без кавычек
- Значения
null для свойств полей, не допускающих null (например, null в свойство типа int).System.Text.Json из коробки поддерживает только:- Десериализацию свойств JSON по именам в том же регистре
- Имена свойств с двойными кавычками
- Десериализацию свойств JSON в аналогичные типы C# (только
int в int, а не null в int).Есть много различий в поведении, которые вы можете найти в этой статье, но главный вопрос в следующем: нужно ли переходить с
Newtonsoft.Json на System.Text.Json?Ответ: почти наверняка нет. Между ними есть много тонких различий, которые могут вызвать ошибки во время выполнения. Newtonsoft.Json по-прежнему хорошая абстракция для .NET.
System.Text.Json гораздо ближе к строгому JSON.Источник: https://schneids.net/comparing-newtonsoft-json-with-system-text-json
День четыреста седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
30. Не Повторяйтесь
Из всех принципов программирования “Don’t Repeat Yourself” (DRY), пожалуй, один из самых фундаментальных. Этот принцип был сформулирован Энди Хантом и Дейвом Томасом в книге «Программист-прагматик» и лежит в основе многих других известных практик разработки ПО и паттернов проектирования. Разработчик, который учится распознавать дублирование и понимает, как его устранить с помощью соответствующих практик и создания правильной абстракции, может писать гораздо более чистый код, чем тот, кто постоянно захламляет приложение ненужными повторениями.
Дублирование - это мусор
Каждая строка кода приложения должна поддерживаться и является потенциальным источником будущих ошибок. Дублирование излишне раздувает кодовую базу, в результате чего повышается риск возникновения ошибок и добавления случайной сложности в систему. Это также затрудняет понимание системы разработчиками и вносит неуверенность из-за того, что изменения, сделанные в одном месте, возможно нужно внести в других местах. DRY требует, чтобы «каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы».
Повторение в процессе призывает к автоматизации
Многие процессы в разработке ПО повторяются и легко автоматизируются. Принцип DRY применяется и в этих случаях. Ручное тестирование является медленным, подверженным ошибкам и трудным для повторения, поэтому следует по возможности использовать наборы автоматизированных тестов. То же касается интеграции ПО: процесс сборки следует запускать как можно чаще, в идеале при каждом внесении изменений. Все болезненные ручные процессы, которые можно автоматизировать, должны быть автоматизированы и стандартизованы. Цель состоит в том, чтобы гарантировать, что есть только один способ выполнить задачу, и он настолько беспроблемный, насколько это возможно.
Повторение в логике призывает к абстракции
Повторение в логике может принимать разные формы. Копирование и вставка логики if-then или switch-case является одной из самых простых для обнаружения и исправления. Многие шаблоны проектирования имеют явную цель - уменьшить или устранить дублирование в логике. Если объект требует, чтобы произошло несколько вещей, прежде чем его можно будет использовать, это можно сделать с помощью абстрактной фабрики или фабричного метода. Если объект имеет несколько вариантов поведения, они могут быть внедрены с помощью Стратегии. Появление самих паттернов проектирования - это попытка уменьшить дублирование при решении стандартных проблем. Кроме того, DRY может применяться к структуре данных, например, в базах данных – это процесс нормализации.
Дело принципа
Другие программные принципы также связаны с DRY. Принцип «Один и только один раз», который применяется к функциональному поведению кода, может рассматриваться как подмножество DRY. Принцип «Открыт/Закрыт», который гласит, что «программные объекты должны быть открыты для расширения, но закрыты для модификации», работает на практике только тогда, когда соблюдается DRY. Аналогично, известный принцип единственной обязанности, который требует, чтобы у класса была «только одна причина для изменения», основан на DRY.
Принцип DRY обеспечивает фундаментальное руководство для разработчиков ПО и помогает создавать более простые, удобные в обслуживании и качественные приложения. Хотя существуют сценарии, в которых повторение может быть необходимо, например, для удовлетворения требований производительности, его следует использовать только в тех случаях, когда дело непосредственно касается реальной проблемы.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Steve Smith
97 Вещей, Которые Должен Знать Каждый Программист
30. Не Повторяйтесь
Из всех принципов программирования “Don’t Repeat Yourself” (DRY), пожалуй, один из самых фундаментальных. Этот принцип был сформулирован Энди Хантом и Дейвом Томасом в книге «Программист-прагматик» и лежит в основе многих других известных практик разработки ПО и паттернов проектирования. Разработчик, который учится распознавать дублирование и понимает, как его устранить с помощью соответствующих практик и создания правильной абстракции, может писать гораздо более чистый код, чем тот, кто постоянно захламляет приложение ненужными повторениями.
Дублирование - это мусор
Каждая строка кода приложения должна поддерживаться и является потенциальным источником будущих ошибок. Дублирование излишне раздувает кодовую базу, в результате чего повышается риск возникновения ошибок и добавления случайной сложности в систему. Это также затрудняет понимание системы разработчиками и вносит неуверенность из-за того, что изменения, сделанные в одном месте, возможно нужно внести в других местах. DRY требует, чтобы «каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы».
Повторение в процессе призывает к автоматизации
Многие процессы в разработке ПО повторяются и легко автоматизируются. Принцип DRY применяется и в этих случаях. Ручное тестирование является медленным, подверженным ошибкам и трудным для повторения, поэтому следует по возможности использовать наборы автоматизированных тестов. То же касается интеграции ПО: процесс сборки следует запускать как можно чаще, в идеале при каждом внесении изменений. Все болезненные ручные процессы, которые можно автоматизировать, должны быть автоматизированы и стандартизованы. Цель состоит в том, чтобы гарантировать, что есть только один способ выполнить задачу, и он настолько беспроблемный, насколько это возможно.
Повторение в логике призывает к абстракции
Повторение в логике может принимать разные формы. Копирование и вставка логики if-then или switch-case является одной из самых простых для обнаружения и исправления. Многие шаблоны проектирования имеют явную цель - уменьшить или устранить дублирование в логике. Если объект требует, чтобы произошло несколько вещей, прежде чем его можно будет использовать, это можно сделать с помощью абстрактной фабрики или фабричного метода. Если объект имеет несколько вариантов поведения, они могут быть внедрены с помощью Стратегии. Появление самих паттернов проектирования - это попытка уменьшить дублирование при решении стандартных проблем. Кроме того, DRY может применяться к структуре данных, например, в базах данных – это процесс нормализации.
Дело принципа
Другие программные принципы также связаны с DRY. Принцип «Один и только один раз», который применяется к функциональному поведению кода, может рассматриваться как подмножество DRY. Принцип «Открыт/Закрыт», который гласит, что «программные объекты должны быть открыты для расширения, но закрыты для модификации», работает на практике только тогда, когда соблюдается DRY. Аналогично, известный принцип единственной обязанности, который требует, чтобы у класса была «только одна причина для изменения», основан на DRY.
Принцип DRY обеспечивает фундаментальное руководство для разработчиков ПО и помогает создавать более простые, удобные в обслуживании и качественные приложения. Хотя существуют сценарии, в которых повторение может быть необходимо, например, для удовлетворения требований производительности, его следует использовать только в тех случаях, когда дело непосредственно касается реальной проблемы.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Steve Smith
День четыреста восьмой.
Сертификат Microsoft. Экзамен 70-486. Шаг второй
Брейкинг ньюс, при чём во всех смыслах брейкинг. Подписчик прислал ссылку на статью Microsoft Learning Blog:
Сертификаты MCSA, MCSD, MCSE отменяются. Внимание Microsoft к ролевому обучению и сертификации может помочь вам развить необходимые навыки и опыт. Обучение на основе ролей и сертификаты постоянно обновляются благодаря новым функциям и услугам, которые Microsoft постоянно добавляет в области облачных решений.
Поскольку в сентябре 2018 года мы объявили о своем внимании к ролевому обучению и сертификации, мы добавили в общей сложности 34 сертификата для Azure, Modern Workplace и Business Applications. Поскольку мы продолжаем расширять предложения по обучению на основе ролей, все остальные экзамены, связанные с Microsoft Certified Solutions Associate (MCSA), Microsoft Certified Solutions Developer (MCSD), Microsoft Certified Solutions Expert (MCSE), будут отменены 30 июня 2020 года. Если вы работаете над сертификацией MCSA, MCSD или MCSE, вы должны сдать все необходимые экзамены до того, как они будут отменены.
Собственно, в список отменяемых входит и тот сертификат, на который я нацелился, MCSA: Web Applications, и экзамены 70-483: Programming in C# и 70-486: Developing ASP.NET MVC Web Applications.
В принципе, нет ничего плохого в смене парадигмы сертификации. Другое дело, что я в списке новых сертификатов не нашёл ничего даже более-менее близко относящееся к веб-разработке. Есть сертификат по разработке веб-сервисов в Azure Microsoft Certified: Azure Developer Associate, но это не совсем то. В общем, на получение сертификата – ВНЕЗАПНО – осталось примерно 3 месяца. Придётся ускорить подготовку.
Сертификат Microsoft. Экзамен 70-486. Шаг второй
Брейкинг ньюс, при чём во всех смыслах брейкинг. Подписчик прислал ссылку на статью Microsoft Learning Blog:
Сертификаты MCSA, MCSD, MCSE отменяются. Внимание Microsoft к ролевому обучению и сертификации может помочь вам развить необходимые навыки и опыт. Обучение на основе ролей и сертификаты постоянно обновляются благодаря новым функциям и услугам, которые Microsoft постоянно добавляет в области облачных решений.
Поскольку в сентябре 2018 года мы объявили о своем внимании к ролевому обучению и сертификации, мы добавили в общей сложности 34 сертификата для Azure, Modern Workplace и Business Applications. Поскольку мы продолжаем расширять предложения по обучению на основе ролей, все остальные экзамены, связанные с Microsoft Certified Solutions Associate (MCSA), Microsoft Certified Solutions Developer (MCSD), Microsoft Certified Solutions Expert (MCSE), будут отменены 30 июня 2020 года. Если вы работаете над сертификацией MCSA, MCSD или MCSE, вы должны сдать все необходимые экзамены до того, как они будут отменены.
Собственно, в список отменяемых входит и тот сертификат, на который я нацелился, MCSA: Web Applications, и экзамены 70-483: Programming in C# и 70-486: Developing ASP.NET MVC Web Applications.
В принципе, нет ничего плохого в смене парадигмы сертификации. Другое дело, что я в списке новых сертификатов не нашёл ничего даже более-менее близко относящееся к веб-разработке. Есть сертификат по разработке веб-сервисов в Azure Microsoft Certified: Azure Developer Associate, но это не совсем то. В общем, на получение сертификата – ВНЕЗАПНО – осталось примерно 3 месяца. Придётся ускорить подготовку.
День четыреста девятый. #Оффтоп #ЗадачиНаСобеседовании
Давненько у нас не было задачек с собеседований. Сегодня относительно простая.
Дан массив длины N, который содержит числа в диапазоне от 1 до N, найдите число, дубликат которого встречается первым. Другими словами, если имеется более 1 дублированного числа, нужно вернуть число, для которого второе вхождение имеет наименьший индекс. Если таких элементов нет, вернуть -1.
Например:
Для
Для
Есть 2 дубликата: числа 2 и 3. Второй вхождение числа 3 имеет меньший индекс, чем второе вхождение числа 2, поэтому ответ 3.
Усложнённый вариант: Написать решение со сложностью
Как обычно, приглашаю всех предлагать варианты решения в чате @netdeveloperschat
Давненько у нас не было задачек с собеседований. Сегодня относительно простая.
Дан массив длины N, который содержит числа в диапазоне от 1 до N, найдите число, дубликат которого встречается первым. Другими словами, если имеется более 1 дублированного числа, нужно вернуть число, для которого второе вхождение имеет наименьший индекс. Если таких элементов нет, вернуть -1.
Например:
Для
[2, 4, 3, 5, 1] вывод должен быть -1.Для
[2, 3, 3, 1, 5, 2] вывод должен быть 3.Есть 2 дубликата: числа 2 и 3. Второй вхождение числа 3 имеет меньший индекс, чем второе вхождение числа 2, поэтому ответ 3.
Усложнённый вариант: Написать решение со сложностью
O(n) по времени и O(1) по памяти.Как обычно, приглашаю всех предлагать варианты решения в чате @netdeveloperschat
День четыреста десятый. #ЗадачиНаСобеседовании
Ответ на задачу
Как я и говорил, задача была довольно простая, и в чате быстро предложили решение. Поэтому давайте на этом примере рассмотрим советы, которые помогут решать такие задачи.
1. Найдите решение «в лоб» (brute-force).
Чаще всего это не должно быть проблемой. В нашем случае можно для каждого элемента перебирать массив (после этого элемента) и искать индекс следующего за ним дубликата. Ищем наименьший индекс дубликата. В конце выдаём элемент по найденному индексу. Это вполне рабочее решение, но его сложность по времени будет O(n!): для первого элемента перебираем N-1 элементов, для второго N-2 и т.д.
2. Рассмотрите более простой вариант проблемы.
В данном случае это уже есть в задании. Допустим, у нас нет ограничения по использованию памяти.
3. Изучите (хотя бы в общих чертах) алгоритмы и структуры данных.
Например, знание того, что коллекция HashSet вне зависимости от размера имеет постоянное время на поиск вхождения элемента, очень поможет в данном случае. Мы можем перебирать массив и добавлять найденные элементы в коллекцию HashSet. Одновременно проверяем, есть ли текущий элемент уже в коллекции. И если есть, то первый найденный в коллекции элемент и будет ответом. Сложность этого алгоритма O(N) по времени и O(N) по памяти, т.к. нам нужно будет хранить дополнительную коллекцию элементов.
4. Визуализируйте проблему.
Изобразите проблему на рисунке. Убедитесь, что вы правильно понимаете задание. Например, что в данном массиве
5. Придумайте несколько простых примеров и попытайтесь найти закономерность.
В этом конкретном случае этот совет мало полезен. Но в других задачах, например, про лестницу, очень может помочь. Рассмотрите простейший вариант, затем чуть более сложный, ещё более сложный. Что изменилось? Заметна ли закономерность? Изобразите решения графически, возможно, это поможет.
6. Перечитайте условие задачи, учли ли вы все нюансы?
В условии задачи сказано, что значения элементов находятся в диапазоне от 1 до N. Значит мы можем использовать для «запоминания» индексы элементов массива, которые тоже в диапазоне от 1 до N. Идея в том, чтобы, двигаясь по массиву «помечать» элемент по индексу, равному значению текущего элемента. Допустим, для массива
Посмотрим дальше: второй элемент 3 (по модулю), элемент с индексом 3 положительный, значит «помечаем» его
Замечания:
- в коде, конечно, нужно будет учесть, что индексы начинаются с 0 и отнимать 1 при обращении по индексу.
- в реальных условиях мы изменяем элементы массива, поэтому после нахождения ответа, возможно, нужно будет пройтись по массиву ещё раз сменить знак отрицательных элементов обратно.
7. Испытайте ваше решение на нескольких примерах, чтобы убедиться в его правильности.
Источники:
- Видео с подробным объяснением решения
- Видео с советами и ещё одной задачей и решением
Ответ на задачу
Как я и говорил, задача была довольно простая, и в чате быстро предложили решение. Поэтому давайте на этом примере рассмотрим советы, которые помогут решать такие задачи.
1. Найдите решение «в лоб» (brute-force).
Чаще всего это не должно быть проблемой. В нашем случае можно для каждого элемента перебирать массив (после этого элемента) и искать индекс следующего за ним дубликата. Ищем наименьший индекс дубликата. В конце выдаём элемент по найденному индексу. Это вполне рабочее решение, но его сложность по времени будет O(n!): для первого элемента перебираем N-1 элементов, для второго N-2 и т.д.
2. Рассмотрите более простой вариант проблемы.
В данном случае это уже есть в задании. Допустим, у нас нет ограничения по использованию памяти.
3. Изучите (хотя бы в общих чертах) алгоритмы и структуры данных.
Например, знание того, что коллекция HashSet вне зависимости от размера имеет постоянное время на поиск вхождения элемента, очень поможет в данном случае. Мы можем перебирать массив и добавлять найденные элементы в коллекцию HashSet. Одновременно проверяем, есть ли текущий элемент уже в коллекции. И если есть, то первый найденный в коллекции элемент и будет ответом. Сложность этого алгоритма O(N) по времени и O(N) по памяти, т.к. нам нужно будет хранить дополнительную коллекцию элементов.
4. Визуализируйте проблему.
Изобразите проблему на рисунке. Убедитесь, что вы правильно понимаете задание. Например, что в данном массиве
[2, 3, 1, 3, 5, 2]ответом будет 3 (дубликат с наименьшим индексом), а не 2 (дубликат элемента с наименьшим индексом).
5. Придумайте несколько простых примеров и попытайтесь найти закономерность.
В этом конкретном случае этот совет мало полезен. Но в других задачах, например, про лестницу, очень может помочь. Рассмотрите простейший вариант, затем чуть более сложный, ещё более сложный. Что изменилось? Заметна ли закономерность? Изобразите решения графически, возможно, это поможет.
6. Перечитайте условие задачи, учли ли вы все нюансы?
В условии задачи сказано, что значения элементов находятся в диапазоне от 1 до N. Значит мы можем использовать для «запоминания» индексы элементов массива, которые тоже в диапазоне от 1 до N. Идея в том, чтобы, двигаясь по массиву «помечать» элемент по индексу, равному значению текущего элемента. Допустим, для массива
[2, 3, 1, 3, 5, 2]первый элемент 2, тогда мы «помечаем» элемент с индексом 2. Это будет первая тройка. Проще всего сделать значение отрицательным. Получим
[2, -3, 1, 3, 5, 2]Двигаясь дальше, проверяем, не «помечен» ли уже элемент с индексом равным текущему значению. И если он помечен, значит такое число уже встречалось ранее, и это первый дубликат.
Посмотрим дальше: второй элемент 3 (по модулю), элемент с индексом 3 положительный, значит «помечаем» его
[2, -3, -1, 3, 5, 2]Третий элемент 1. Первый элемент положительный, «помечаем»:
[-2, -3, -1, 3, 5, 2]Четвёртый элемент 3. Третий элемент отрицательный (уже помечен), значит первый дубликат 3. Таким образом мы решили задачу за один проход массива - O(N) по времени и не используя дополнительную память – O(1) по памяти.
Замечания:
- в коде, конечно, нужно будет учесть, что индексы начинаются с 0 и отнимать 1 при обращении по индексу.
- в реальных условиях мы изменяем элементы массива, поэтому после нахождения ответа, возможно, нужно будет пройтись по массиву ещё раз сменить знак отрицательных элементов обратно.
7. Испытайте ваше решение на нескольких примерах, чтобы убедиться в его правильности.
Источники:
- Видео с подробным объяснением решения
- Видео с советами и ещё одной задачей и решением
День четыреста одиннадцатый. #DesignPatterns
Паттерны проектирования
16. Паттерн «Декоратор» (Decorator)
Хорошо спроектированный класс отвечает за определенную функциональность, не распыляясь на решение второстепенных задач. Но что делать, если второстепенные задачи, такие как логирование, кэширование, замеры времени исполнения, проникают в код класса и непомерно увеличивают сложность реализации? Можно выделить эти аспекты поведения во вспомогательные классы, но все равно останется проблема их координации. Паттерн «Декоратор» элегантно решает задачу нанизывания одних обязанностей на другие.
Назначение: динамически добавляет объекту новые обязанности. Является гибкой альтернативой порождению подклассов с целью расширения функциональности.
Причины использования:
Идея паттерна «Декоратор» в том, что у интерфейса появляется два вида реализаций: основная реализация бизнес-функциональности и набор классов-декораторов, которые реализуют тот же интерфейс, но довольно специфическим образом. Декоратор принимает в конструкторе тот же самый интерфейс, а в реализации делегирует работу декорируемому объекту с присоединением некоторого поведения до или после вызова метода. При этом клиенты интерфейса будут работать с ним, как и раньше, не замечая наличия дополнительного поведения.
Классическая диаграмма приведена на рисунке ниже:
-
-
-
-
-
Применимость
Декораторы применяются для добавления всем методам интерфейса некоторого поведения, которое не является частью основной функциональности. Они отлично подходят для решения следующих задач:
- кэширования результатов работы;
- замера времени исполнения методов;
- логирования аргументов;
- управления доступом пользователей;
- модификации аргументов или результата работы методов упаковки/распаковки, шифрования и т. п.
Недостатки декораторов
1. Чувствительность к порядку. Код инициализации декораторов очень важен, поскольку именно в процессе создания определяются вложенность и порядок исполнения разных декораторов. Наличие декораторов делает процесс инициализации компонентов более сложным. Если есть ряд предустановленных конфигураций создания объекта, можно выделить их в фабричный метод.
2. Сложность отладки. Разработчику, незнакомому с этим паттерном, замер времени исполнения или кэширование результатов декораторами может показаться чёрной магией. Отлаживать проблемы, которые возникли внутри декоратора, может быть довольно сложно.
3. Увеличение сложности. Декоратор является довольно тяжеловесным паттерном, к которому стоит прибегать тогда, когда выделяемый аспект поведения достаточно сложен. Если нужно кэшировать результаты в одном из десяти методов, то сложность, привнесенная декоратором, будет неоправданной.
Источник: Тепляков С. "Паттерны проектирования на платформе .NET." — СПб.: Питер, 2015. Глава 14.
Паттерны проектирования
16. Паттерн «Декоратор» (Decorator)
Хорошо спроектированный класс отвечает за определенную функциональность, не распыляясь на решение второстепенных задач. Но что делать, если второстепенные задачи, такие как логирование, кэширование, замеры времени исполнения, проникают в код класса и непомерно увеличивают сложность реализации? Можно выделить эти аспекты поведения во вспомогательные классы, но все равно останется проблема их координации. Паттерн «Декоратор» элегантно решает задачу нанизывания одних обязанностей на другие.
Назначение: динамически добавляет объекту новые обязанности. Является гибкой альтернативой порождению подклассов с целью расширения функциональности.
Причины использования:
Идея паттерна «Декоратор» в том, что у интерфейса появляется два вида реализаций: основная реализация бизнес-функциональности и набор классов-декораторов, которые реализуют тот же интерфейс, но довольно специфическим образом. Декоратор принимает в конструкторе тот же самый интерфейс, а в реализации делегирует работу декорируемому объекту с присоединением некоторого поведения до или после вызова метода. При этом клиенты интерфейса будут работать с ним, как и раньше, не замечая наличия дополнительного поведения.
Классическая диаграмма приведена на рисунке ниже:
-
Component — базовый класс компонента, чьё поведение будет расширяться декораторами;-
Client — работает с компонентом, не зная о существовании декораторов;-
ConcreteComponent — конкретная реализация компонента;-
Decorator — базовый класс декоратора, предназначенный для расширения поведения компонента;-
ConcreteDecoratorA, ConcreteDecoratorB — конкретные декораторы, которые добавляют декорируемому объекту специфическое поведение.Применимость
Декораторы применяются для добавления всем методам интерфейса некоторого поведения, которое не является частью основной функциональности. Они отлично подходят для решения следующих задач:
- кэширования результатов работы;
- замера времени исполнения методов;
- логирования аргументов;
- управления доступом пользователей;
- модификации аргументов или результата работы методов упаковки/распаковки, шифрования и т. п.
Недостатки декораторов
1. Чувствительность к порядку. Код инициализации декораторов очень важен, поскольку именно в процессе создания определяются вложенность и порядок исполнения разных декораторов. Наличие декораторов делает процесс инициализации компонентов более сложным. Если есть ряд предустановленных конфигураций создания объекта, можно выделить их в фабричный метод.
2. Сложность отладки. Разработчику, незнакомому с этим паттерном, замер времени исполнения или кэширование результатов декораторами может показаться чёрной магией. Отлаживать проблемы, которые возникли внутри декоратора, может быть довольно сложно.
3. Увеличение сложности. Декоратор является довольно тяжеловесным паттерном, к которому стоит прибегать тогда, когда выделяемый аспект поведения достаточно сложен. Если нужно кэшировать результаты в одном из десяти методов, то сложность, привнесенная декоратором, будет неоправданной.
Источник: Тепляков С. "Паттерны проектирования на платформе .NET." — СПб.: Питер, 2015. Глава 14.
День четыреста тринадцатый. #ЧтоНовенького
Анонс .NET5 Preview 1
.NET5 продолжит объединение .NET в единую платформу: ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin и ML.NET. Впервые вся платформа будет использовать унифицированные BCL (Библиотеки Базовых Классов) для всех моделей приложений. Версия 5, которая выше, чем версии .NET Core и .NET Framework, даёт понять, что .NET5 - это будущее .NET, как единой унифицированной платформы для создания приложений любого типа.
.NET Core, а затем .NET5 - это .NET для создания НОВЫХ приложений. .NET Framework будет поддерживаться до тех пор, пока поддерживается Windows. Будет продолжаться обеспечение безопасности и исправление ошибок, а также обновление сетевых и крипто API. Он будет оставаться безопасным и поддерживаться для поддержки существующих приложений на .NET Framework.
16 марта выпущена первая предварительная версия .NET5, релиз которого запланирован на ноябрь. В Preview 1 впервые включена поддержка Windows ARM64. Версия включает в себя среду выполнения .NET Core. Ожидается, что в Preview 2 будет включен SDK (ядро ASP.NET, но не WPF или Windows Forms, которые войдут в более поздние версии). Поддержка Windows ARM64 также будет перенесена в .NET Core 3.1.
Основные цели выпуска .NET5
1. Унифицированный SDK
- Одна BCL для всех приложений .NET5. Сегодня приложения Xamarin используют Mono BCL, но перейдут на использование .NET Core BCL, улучшая совместимость между моделями приложений.
- Интеграция мобильной разработки (Xamarin) в .NET 5 вместо Mono.
2. Нативные приложения, поддерживающие несколько платформ, например Windows Desktop, Microsoft Duo (Android) и iOS, с использованием нативных элементов управления, поддерживаемых на этих платформах.
3. Веб-приложения, поддерживающие несколько платформ: приложения на Blazor, которые могут работать в браузерах, на мобильных устройствах и как нативные настольные приложения (например, в Windows 10).
4. Нативные высокопроизводительные облачные приложения, микросервисы и поддержка создания нескольких проектов (API, веб-интерфейсов, контейнеров) как локально, так и в облаке.
5. Постоянные улучшения: более быстрые алгоритмы в BCL, улучшенная поддержка контейнеров во время выполнения, поддержка HTTP3.
Preview 1 пока не содержит всего этого но этот функционал будет выходить в будущих предварительных версиях.
Улучшения в Preview 1
1. Улучшения производительности регулярных выражений.
2. Улучшение качества кода в RyuJIT
- улучшены паттерны проверки на null
- улучшена оценка распространённых выражений
- оптимизировано свойство “строка”.Length
- изменён порядок применения оптимизаций в JIT, так что ключевые оптимизации применяются раньше
3. Диагностика нагрузки сборки добавлена в канал событий (Event Pipe)
4. API для профилировщиков в канале событий
Канал событий был добавлен в .NET Core 2.2 для диагностики производительности в любой операционной системе. В .NET5 добавлена возможность профилировщикам писать события в канал событий.
5. Консолидация GitHub репозиториев с кодом пакетов .NET
В .NET Core 1.0 было более 100 репозиториев для ASP.NET, EF и .NET Core. Теперь их можно сосчитать по пальцам одной руки, и почти все перемещены в общий репозиторий dotnet.
Источник: https://devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-1/
Анонс .NET5 Preview 1
.NET5 продолжит объединение .NET в единую платформу: ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin и ML.NET. Впервые вся платформа будет использовать унифицированные BCL (Библиотеки Базовых Классов) для всех моделей приложений. Версия 5, которая выше, чем версии .NET Core и .NET Framework, даёт понять, что .NET5 - это будущее .NET, как единой унифицированной платформы для создания приложений любого типа.
.NET Core, а затем .NET5 - это .NET для создания НОВЫХ приложений. .NET Framework будет поддерживаться до тех пор, пока поддерживается Windows. Будет продолжаться обеспечение безопасности и исправление ошибок, а также обновление сетевых и крипто API. Он будет оставаться безопасным и поддерживаться для поддержки существующих приложений на .NET Framework.
16 марта выпущена первая предварительная версия .NET5, релиз которого запланирован на ноябрь. В Preview 1 впервые включена поддержка Windows ARM64. Версия включает в себя среду выполнения .NET Core. Ожидается, что в Preview 2 будет включен SDK (ядро ASP.NET, но не WPF или Windows Forms, которые войдут в более поздние версии). Поддержка Windows ARM64 также будет перенесена в .NET Core 3.1.
Основные цели выпуска .NET5
1. Унифицированный SDK
- Одна BCL для всех приложений .NET5. Сегодня приложения Xamarin используют Mono BCL, но перейдут на использование .NET Core BCL, улучшая совместимость между моделями приложений.
- Интеграция мобильной разработки (Xamarin) в .NET 5 вместо Mono.
2. Нативные приложения, поддерживающие несколько платформ, например Windows Desktop, Microsoft Duo (Android) и iOS, с использованием нативных элементов управления, поддерживаемых на этих платформах.
3. Веб-приложения, поддерживающие несколько платформ: приложения на Blazor, которые могут работать в браузерах, на мобильных устройствах и как нативные настольные приложения (например, в Windows 10).
4. Нативные высокопроизводительные облачные приложения, микросервисы и поддержка создания нескольких проектов (API, веб-интерфейсов, контейнеров) как локально, так и в облаке.
5. Постоянные улучшения: более быстрые алгоритмы в BCL, улучшенная поддержка контейнеров во время выполнения, поддержка HTTP3.
Preview 1 пока не содержит всего этого но этот функционал будет выходить в будущих предварительных версиях.
Улучшения в Preview 1
1. Улучшения производительности регулярных выражений.
2. Улучшение качества кода в RyuJIT
- улучшены паттерны проверки на null
- улучшена оценка распространённых выражений
- оптимизировано свойство “строка”.Length
- изменён порядок применения оптимизаций в JIT, так что ключевые оптимизации применяются раньше
3. Диагностика нагрузки сборки добавлена в канал событий (Event Pipe)
4. API для профилировщиков в канале событий
Канал событий был добавлен в .NET Core 2.2 для диагностики производительности в любой операционной системе. В .NET5 добавлена возможность профилировщикам писать события в канал событий.
5. Консолидация GitHub репозиториев с кодом пакетов .NET
В .NET Core 1.0 было более 100 репозиториев для ASP.NET, EF и .NET Core. Теперь их можно сосчитать по пальцам одной руки, и почти все перемещены в общий репозиторий dotnet.
Источник: https://devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-1/
👍1
День четыреста четырнадцатый. #ЧтоНовенького
Вышла VS 2019 версии 16.5
Вот некоторые новые функции для разработки в С#:
1. Конвертация if в операторы или выражения switch. Наведите курсор на ключевое слово if, нажмите
2. Упрощение интерполированных строк поможет сделать строку более понятной и лаконичной. Поместите курсор на строку, нажмите
3. Извлечение в локальную функцию позволяет превратить фрагмент кода существующего метода в локальную функцию. Выделите код, который вы хотите извлечь, нажмите
4. Изменение членов на статические. Поместите курсор на имя члена, нажмите
5. IntelliSense теперь поддерживает завершение для не импортированных методов расширения. Включить эту опцию можно в Tools > Options > Text Editor > C# > Intellisense и выбрать Show items from unimported namespaces(experimental).
Источник
Вышла VS 2019 версии 16.5
Вот некоторые новые функции для разработки в С#:
1. Конвертация if в операторы или выражения switch. Наведите курсор на ключевое слово if, нажмите
Ctrl+., и выберите Convert to ‘switch’ statement/expression.2. Упрощение интерполированных строк поможет сделать строку более понятной и лаконичной. Поместите курсор на строку, нажмите
Ctrl+. и выберите Simplify interpolation.3. Извлечение в локальную функцию позволяет превратить фрагмент кода существующего метода в локальную функцию. Выделите код, который вы хотите извлечь, нажмите
Ctrl+. и выберите Extract local function.4. Изменение членов на статические. Поместите курсор на имя члена, нажмите
Ctrl+. и выберите Make static.5. IntelliSense теперь поддерживает завершение для не импортированных методов расширения. Включить эту опцию можно в Tools > Options > Text Editor > C# > Intellisense и выбрать Show items from unimported namespaces(experimental).
Источник
День четыреста пятнадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
31. Не Трогайте Этот Код!
Это случалось с каждым из нас в какой-то момент. Ваш код перенесен на демо-сервер для тестирования системы, и тестировщик пишет, что столкнулся с проблемой. Ваша первая реакция: «Я знаю, что не так, дай я быстро поправлю».
Проблема здесь в том, что вы думаете, что у вас как у разработчика должен быть доступ к демо-серверу.
В большинстве сред веб-разработки архитектура может быть примерно следующей:
- Локальная разработка и юнит-тестирование на машине разработчика
- Сервер разработки, на котором выполняется ручное или автоматическое интеграционное тестирование
- Демо-сервер, на котором команда QA и заказчики проводят приёмочное тестирование
- Производственный сервер
Да, есть и другие сервера и сервисы, такие как система контроля версий и тикеты, но идея понятна. В этой модели разработчик - даже старший разработчик - никогда не должен иметь доступа за пределы сервера разработки. Большая часть разработки выполняется им на локальной машине с использованием его любимого набора IDE, виртуальных машин и чёрной магии.
После внесения в систему контроля версий код автоматически или вручную должен быть перенесён на сервер разработки, где его можно протестировать и при необходимости настроить, чтобы убедиться, что вся система работает. Но с этого момента разработчик может лишь следить за процессом.
Менеджер по тестированию должен разместить код на демо-сервере для команды QA. Точно так же, как разработчикам не нужно иметь доступ к чему-либо, кроме сервера разработки, так и команде QA и заказчикам не нужно ничего трогать на сервере разработки. Если код готов к приёмочным испытаниям, выпустите его на демо-сервер и не просите пользователя «просто быстро взглянуть на кое-что» на сервере разработки. Помните, что, если вы пишете проект не один, у других людей на сервере разработки есть код, который может быть не готов к просмотру пользователем. Менеджер релизов - единственный человек, который должен иметь доступ к обоим серверам.
Ни при каких обстоятельствах, вообще никогда, разработчик не должен иметь доступ к производственному серверу! Если возникает проблема, служба поддержки должна решить её или попросить, чтобы разработчик её исправил. После того, как исправление внесено в систему контроля версий, служба поддержки возьмёт его оттуда. Одни из самых больших программных катастроф, которые я видел, произошли потому, что какой-то… э-э-эм… ну, в общем, я… нарушал это правило. Если что-то сломалось, производственный сервер не место, чтобы это исправлять.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Cal Evans
97 Вещей, Которые Должен Знать Каждый Программист
31. Не Трогайте Этот Код!
Это случалось с каждым из нас в какой-то момент. Ваш код перенесен на демо-сервер для тестирования системы, и тестировщик пишет, что столкнулся с проблемой. Ваша первая реакция: «Я знаю, что не так, дай я быстро поправлю».
Проблема здесь в том, что вы думаете, что у вас как у разработчика должен быть доступ к демо-серверу.
В большинстве сред веб-разработки архитектура может быть примерно следующей:
- Локальная разработка и юнит-тестирование на машине разработчика
- Сервер разработки, на котором выполняется ручное или автоматическое интеграционное тестирование
- Демо-сервер, на котором команда QA и заказчики проводят приёмочное тестирование
- Производственный сервер
Да, есть и другие сервера и сервисы, такие как система контроля версий и тикеты, но идея понятна. В этой модели разработчик - даже старший разработчик - никогда не должен иметь доступа за пределы сервера разработки. Большая часть разработки выполняется им на локальной машине с использованием его любимого набора IDE, виртуальных машин и чёрной магии.
После внесения в систему контроля версий код автоматически или вручную должен быть перенесён на сервер разработки, где его можно протестировать и при необходимости настроить, чтобы убедиться, что вся система работает. Но с этого момента разработчик может лишь следить за процессом.
Менеджер по тестированию должен разместить код на демо-сервере для команды QA. Точно так же, как разработчикам не нужно иметь доступ к чему-либо, кроме сервера разработки, так и команде QA и заказчикам не нужно ничего трогать на сервере разработки. Если код готов к приёмочным испытаниям, выпустите его на демо-сервер и не просите пользователя «просто быстро взглянуть на кое-что» на сервере разработки. Помните, что, если вы пишете проект не один, у других людей на сервере разработки есть код, который может быть не готов к просмотру пользователем. Менеджер релизов - единственный человек, который должен иметь доступ к обоим серверам.
Ни при каких обстоятельствах, вообще никогда, разработчик не должен иметь доступ к производственному серверу! Если возникает проблема, служба поддержки должна решить её или попросить, чтобы разработчик её исправил. После того, как исправление внесено в систему контроля версий, служба поддержки возьмёт его оттуда. Одни из самых больших программных катастроф, которые я видел, произошли потому, что какой-то… э-э-эм… ну, в общем, я… нарушал это правило. Если что-то сломалось, производственный сервер не место, чтобы это исправлять.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Cal Evans
Новые даты DotNext 2020 Piter!
Из-за действующего запрета на проведение массовых мероприятий мы переносим конференцию
на 18-19 июня в «Park Inn by Radisson Пулковская».
Билеты
Купленный вами или вашей компанией билет остается действительным на новые даты.
Если новая дата вам подходит, менять билет не нужно, всё будет работать.
Если новая дата вам не подходит — обратитесь в наш саппорт [email protected] или @JUGConfSupport_bot. Мы поможем вам с возвратом денег, заменой билета на осеннюю конференцию или заменой участия на онлайн с частичным возвратом.
Новая площадка меньше изначально запланированной, поэтому дополнительно мы готовим большой пакет обновлений для онлайн-участников.
Программа
Сейчас мы договариваемся со спикерами на новые даты. Не всем спикерам подойдут новые даты, и программа немного изменится. Но мы приложим все усилия, чтобы программа стала интереснее и полезнее.
Одно из новшеств конференции — добавление онлайн-трека: один зал будет специально оборудован для того, чтобы мы могли проводить доклады и дискуссионные зоны с удаленными спикерами. Будем держать вас в курсе.
На случай продления карантина и ограничений
Мы прорабатываем разные форматы участия в конференции (онлайн и смешанные) на случай, если введенные недавно ограничения не позволят нам собраться вместе и летом. Будем оперативно сообщать вам обо всех изменениях в наших каналах и на сайте https://bit.ly/3940lZV
Стоимость билетов заморожена до июня, промокод также действителен: NetDevDiary20pc
По всем оставшимся вопросам — пишите в саппорт ([email protected] или @JUGConfSupport_bot).
Из-за действующего запрета на проведение массовых мероприятий мы переносим конференцию
на 18-19 июня в «Park Inn by Radisson Пулковская».
Билеты
Купленный вами или вашей компанией билет остается действительным на новые даты.
Если новая дата вам подходит, менять билет не нужно, всё будет работать.
Если новая дата вам не подходит — обратитесь в наш саппорт [email protected] или @JUGConfSupport_bot. Мы поможем вам с возвратом денег, заменой билета на осеннюю конференцию или заменой участия на онлайн с частичным возвратом.
Новая площадка меньше изначально запланированной, поэтому дополнительно мы готовим большой пакет обновлений для онлайн-участников.
Программа
Сейчас мы договариваемся со спикерами на новые даты. Не всем спикерам подойдут новые даты, и программа немного изменится. Но мы приложим все усилия, чтобы программа стала интереснее и полезнее.
Одно из новшеств конференции — добавление онлайн-трека: один зал будет специально оборудован для того, чтобы мы могли проводить доклады и дискуссионные зоны с удаленными спикерами. Будем держать вас в курсе.
На случай продления карантина и ограничений
Мы прорабатываем разные форматы участия в конференции (онлайн и смешанные) на случай, если введенные недавно ограничения не позволят нам собраться вместе и летом. Будем оперативно сообщать вам обо всех изменениях в наших каналах и на сайте https://bit.ly/3940lZV
Стоимость билетов заморожена до июня, промокод также действителен: NetDevDiary20pc
По всем оставшимся вопросам — пишите в саппорт ([email protected] или @JUGConfSupport_bot).
DotNext 2021 Piter. Конференция для .NET-разработчиков. 20-23 апреля, онлайн.
.NET-конференция. 20-23 апреля, онлайн. 4 дня и несколько десятков технических докладов.
День четыреста шестнадцатый. #Оффтоп
Как Работать Удалённо?
В связи с последними событиями многих разработчиков переводят на удалённую работу. И для тех, кто никогда до этого не работал удалённо, это может вызывать опасения.
Коммуникация
Как общаться с коллегами, когда ты привык, что они за соседними столами? Правильная коммуникация между членами команды играет едва ли не главную роль. Множество проектов потерпели неудачу не по причине плохого кода, а именно по причине плохой коммуникации и недопонимания. Теперь важнейший элемент коммуникации – прямое живое общение – отсутствует.
В этом случае чрезвычайно важно уделить внимание письменной коммуникации, т.к. она в любом случае будет основной. Главная задача – снизить возможность недопониманий до минимума.
1. Постарайтесь выражать мысли наиболее подробно и чётко:
- выделяйте главные мысли жирным или курсивом
- составляйте списки задач или условий (отформатированные как списки 1…, 2…, 3…)
2. Если вы менеджер проекта, получили задание от заказчика и составляете подробное ТЗ для программиста, имейте в виду, что многим программистам очень помогает наличие исходного задания. Возможность взглянуть на общую картину невероятно полезна. Вдруг вы что-то упустили. Может быть программист предложит более эффективный способ реализовать задачу.
3. Не предполагайте, что имел в виду ваш собеседник. Если вам что-то непонятно, лучше потратить несколько минут и переспросить, чем тратить несколько часов, реализовывая не то, что нужно. Перескажите собеседнику то, как вы поняли, что он имел в виду (если это какая-то логика работы программы, опишите её по шагам), и спросите, правильно ли вы поняли.
4. Очень помогают программы, захватывающие область экрана и позволяющие сделать скриншот или видео с описанием последовательности действий при возникновении бага или для теста функциональности. Это гораздо проще, чем описывать словами. Мы в компании используем Jing, но есть и более современные инструменты.
5. Письменная коммуникация в большинстве случаев лишена эмоционального окраса. Наверное, каждый сталкивался с тем, что собеседник внезапно обижался на ваше сообщение, хотя вы ничего оскорбительного не имели в виду. Поэтому очень важно для всех участников переписки воспринимать сообщения в нейтральном или положительном ключе. Спокойно перечитайте сообщение, которое вы посчитали обидным или агрессивным с предположением, что отправитель не хотел вас задеть (что чаще всего так).
6. Ваши сообщения тоже должны содержать как можно меньше эмоций. Здесь прелесть переписки в том, что в лицо можно много наговорить, не подумав, а пока пишешь сообщение, есть время всё исправить.
7. В некоторых случаях очень важно понимать, чем занимаются ваши коллеги. Чтобы не делать ту же работу, что и они, и опять же снизить риск недопонимания. В этом случае помогут как специализированные инструменты, вроде багтрекера, так и обычные «ежедневные апдейты». Простое, не сильно формализованное сообщение всем членам команды (например, в отдельном общем чате) о том, чем вы занимаетесь сегодня, когда планируете это закончить и что планируете делать завтра или в ближайшие пару дней.
8. Иногда переписки, даже в чате, недостаточно. Тогда на помощь приходят телефон, Skype, видеоконференции, TeamViewer и множество других инструментов.
Продуктивность
Лично для меня не составляет проблемы работать из дома, однако многим недостаёт «рабочей атмосферы», есть множество отвлекающих факторов и соблазнов (хочется вздремнуть, а кровать так близко). В этом случае потратьте время и создайте для себя настолько рабочую атмосферу, насколько возможно:
1. Выберите удобное место (отдельный кабинет, спальня, кухонный стол, балкон).
2. Создайте рабочую атмосферу: уберите со стола лишние и отвлекающие вещи (см. пункт 6. Политика чистого стола), повесьте список задач, включите фоновый шум офиса (их куча на ютубе), скажите домашним, что вы «на работе» и беспокоить вас нельзя.
3. Выберите подходящий для вас график: чётко в рабочие часы с 9 до 5, либо несколько интервалов в течение дня.
Источник: https://youtu.be/HTcbWifD5v0
Как Работать Удалённо?
В связи с последними событиями многих разработчиков переводят на удалённую работу. И для тех, кто никогда до этого не работал удалённо, это может вызывать опасения.
Коммуникация
Как общаться с коллегами, когда ты привык, что они за соседними столами? Правильная коммуникация между членами команды играет едва ли не главную роль. Множество проектов потерпели неудачу не по причине плохого кода, а именно по причине плохой коммуникации и недопонимания. Теперь важнейший элемент коммуникации – прямое живое общение – отсутствует.
В этом случае чрезвычайно важно уделить внимание письменной коммуникации, т.к. она в любом случае будет основной. Главная задача – снизить возможность недопониманий до минимума.
1. Постарайтесь выражать мысли наиболее подробно и чётко:
- выделяйте главные мысли жирным или курсивом
- составляйте списки задач или условий (отформатированные как списки 1…, 2…, 3…)
2. Если вы менеджер проекта, получили задание от заказчика и составляете подробное ТЗ для программиста, имейте в виду, что многим программистам очень помогает наличие исходного задания. Возможность взглянуть на общую картину невероятно полезна. Вдруг вы что-то упустили. Может быть программист предложит более эффективный способ реализовать задачу.
3. Не предполагайте, что имел в виду ваш собеседник. Если вам что-то непонятно, лучше потратить несколько минут и переспросить, чем тратить несколько часов, реализовывая не то, что нужно. Перескажите собеседнику то, как вы поняли, что он имел в виду (если это какая-то логика работы программы, опишите её по шагам), и спросите, правильно ли вы поняли.
4. Очень помогают программы, захватывающие область экрана и позволяющие сделать скриншот или видео с описанием последовательности действий при возникновении бага или для теста функциональности. Это гораздо проще, чем описывать словами. Мы в компании используем Jing, но есть и более современные инструменты.
5. Письменная коммуникация в большинстве случаев лишена эмоционального окраса. Наверное, каждый сталкивался с тем, что собеседник внезапно обижался на ваше сообщение, хотя вы ничего оскорбительного не имели в виду. Поэтому очень важно для всех участников переписки воспринимать сообщения в нейтральном или положительном ключе. Спокойно перечитайте сообщение, которое вы посчитали обидным или агрессивным с предположением, что отправитель не хотел вас задеть (что чаще всего так).
6. Ваши сообщения тоже должны содержать как можно меньше эмоций. Здесь прелесть переписки в том, что в лицо можно много наговорить, не подумав, а пока пишешь сообщение, есть время всё исправить.
7. В некоторых случаях очень важно понимать, чем занимаются ваши коллеги. Чтобы не делать ту же работу, что и они, и опять же снизить риск недопонимания. В этом случае помогут как специализированные инструменты, вроде багтрекера, так и обычные «ежедневные апдейты». Простое, не сильно формализованное сообщение всем членам команды (например, в отдельном общем чате) о том, чем вы занимаетесь сегодня, когда планируете это закончить и что планируете делать завтра или в ближайшие пару дней.
8. Иногда переписки, даже в чате, недостаточно. Тогда на помощь приходят телефон, Skype, видеоконференции, TeamViewer и множество других инструментов.
Продуктивность
Лично для меня не составляет проблемы работать из дома, однако многим недостаёт «рабочей атмосферы», есть множество отвлекающих факторов и соблазнов (хочется вздремнуть, а кровать так близко). В этом случае потратьте время и создайте для себя настолько рабочую атмосферу, насколько возможно:
1. Выберите удобное место (отдельный кабинет, спальня, кухонный стол, балкон).
2. Создайте рабочую атмосферу: уберите со стола лишние и отвлекающие вещи (см. пункт 6. Политика чистого стола), повесьте список задач, включите фоновый шум офиса (их куча на ютубе), скажите домашним, что вы «на работе» и беспокоить вас нельзя.
3. Выберите подходящий для вас график: чётко в рабочие часы с 9 до 5, либо несколько интервалов в течение дня.
Источник: https://youtu.be/HTcbWifD5v0
День четыреста семнадцатый. #ЗаметкиНаПолях
Эмоджи и String.Length в C#
Вы используете
Однако вам нужно количество символов, а не фактическая длина массива
Источник: https://schneids.net/emojis-and-string-length
Эмоджи и String.Length в C#
Вы используете
String.Length для вычисления длины строки, которая может включать эмоджи? Попробовав вычислить String.Length для такой строки, можно получить не совсем то, что вы ожидаете. Как думаете, что будет выведено на консоль?var str = "👶👶👶👶🍼🍼";Выведется
Console.WriteLine(str.Length);
12. Это происходит потому, что строки C# по умолчанию имеют формат UTF-16, а символы Юникода, выходящие за пределы 16-разрядного UTF, сохраняются в виде суррогатных пар, т.е. двух символов, представляющих один 32-разрядный символ.Однако вам нужно количество символов, а не фактическая длина массива
char, и в этом случае можно использовать System.Globalization.StringInfo для вычисления длины строки:var str = "👶👶👶👶🍼🍼";Это выведет искомое число
var stringInfo = new System.Globalization.StringInfo(str);
Console.WriteLine(stringInfo.LengthInTextElements);
6.Источник: https://schneids.net/emojis-and-string-length
День четыреста восемнадцатый. #Оффтоп
На канале Visual Studio Toolbox вышло новое видео «Введение в gRPC». В получасовом ролике рассказывается, что это, с чем его едят и как это реализовано в .NET и Visual Studio.
gRPC - это независимая от языка высокопроизводительная среда удаленного вызова процедур (RPC).
Основными преимуществами gRPC являются:
- Современный, высокопроизводительный, легкий RPC фреймворк.
- Разработка API по контракту с использованием Protocol Buffers, позволяющая создавать независимые от языка реализации.
- Инструменты для разных языков, позволяющие создавать строго типизированные серверы и клиенты.
- Поддержка клиентских, серверных и двунаправленных потоковых вызовов.
- Снижение использования сети благодаря двоичной сериализации Protobuf.
Эти преимущества делают gRPC идеальным для:
- Легких микросервисов, где эффективность имеет решающее значение.
- Многоязычных систем.
- Point-to-point сервисов реального времени, которые должны обрабатывать потоковые запросы или ответы.
Для тех, кому сложно воспринимать английскую речь (с индийским акцентом), примеры описаны в документации:
- Введение в gRPC в .NET Core
- gRPC сервисы в C#
- Руководство по созданию простого сервиса gRPC
На канале Visual Studio Toolbox вышло новое видео «Введение в gRPC». В получасовом ролике рассказывается, что это, с чем его едят и как это реализовано в .NET и Visual Studio.
gRPC - это независимая от языка высокопроизводительная среда удаленного вызова процедур (RPC).
Основными преимуществами gRPC являются:
- Современный, высокопроизводительный, легкий RPC фреймворк.
- Разработка API по контракту с использованием Protocol Buffers, позволяющая создавать независимые от языка реализации.
- Инструменты для разных языков, позволяющие создавать строго типизированные серверы и клиенты.
- Поддержка клиентских, серверных и двунаправленных потоковых вызовов.
- Снижение использования сети благодаря двоичной сериализации Protobuf.
Эти преимущества делают gRPC идеальным для:
- Легких микросервисов, где эффективность имеет решающее значение.
- Многоязычных систем.
- Point-to-point сервисов реального времени, которые должны обрабатывать потоковые запросы или ответы.
Для тех, кому сложно воспринимать английскую речь (с индийским акцентом), примеры описаны в документации:
- Введение в gRPC в .NET Core
- gRPC сервисы в C#
- Руководство по созданию простого сервиса gRPC
YouTube
Introduction to gRPC
In this episode, Robert is joined by Sourabh Shirhatti, who shows how to build a gRPC service with Visual Studio. Sourabh starts with an introduction to gRPC, a language agnostic, high-performance Remote Procedure Call (RPC) framework, and reviews why it…
День четыреста девятнадцатый. #АтакиНаСайты
ASP.NET MVC 5. Безопасность Веб-Приложений
4. Оверпостинг
Привязка модели ASP.NET MVC - это мощная функция, которая значительно упрощает процесс обработки пользовательского ввода, автоматически сопоставляя входные данные со свойствами модели на основе соглашений об именовании. Однако она открывает ещё один вектор атаки, позволяющий злоумышленнику заполнить свойства модели, которые вы не указывали в форме ввода. Допустим, мы создаём систему отзывов о товарах магазина:
Атака оверпостингом использует общую для MVC веб-сред функцию. В марте 2012 года такой атаке подвергся GitHub.com. Атакующий создал новый открытый ключ администратора и вручную добавил его в скрытое поле формы. После отправки формы он получал административные привилегии.
Предотвращение оверпостинга
1. Самый простой способ предотвратить атаку оверпостингом - использовать атрибут BindAttribute, чтобы явно контролировать, какие свойства должны получать значения через связыватель модели. Можно использовать либо белый список:
2. Можно использовать одну из перегрузок UpdateModel или TryUpdateModel, которая принимает список полей для привязки:
Источник: Jon Galloway “Professional ASP.NET MVC 5”. – John Wiley & Sons Inc., 2014. Глава 7.
ASP.NET MVC 5. Безопасность Веб-Приложений
4. Оверпостинг
Привязка модели ASP.NET MVC - это мощная функция, которая значительно упрощает процесс обработки пользовательского ввода, автоматически сопоставляя входные данные со свойствами модели на основе соглашений об именовании. Однако она открывает ещё один вектор атаки, позволяющий злоумышленнику заполнить свойства модели, которые вы не указывали в форме ввода. Допустим, мы создаём систему отзывов о товарах магазина:
public class Review {
public int ReviewID { get; set; } // Первичный ключ
public int ProductID { get; set; } // Внешний ключ
public Product Product { get; set; } // Внешняя сущность
public string Name { get; set; }
public string Comment { get; set; }
public bool Approved { get; set; }
}
У нас есть простая форма с двумя полями, доступными для пользователя Name и Comment:Name: @Html.TextBox("Name") <br />
Comment: @Html.TextBox("Comment")
Несмотря на то, что в форме открыты только имя и комментарий, злонамеренный пользователь может легко вмешаться в отправляемые данные формы, используя инструменты веб-разработчика, добавив «Approved=true» в строку запроса или POST-данные формы. Связыватель модели не знает, какие поля вы включили в форму, и установит для свойства Approved значение true.Атака оверпостингом использует общую для MVC веб-сред функцию. В марте 2012 года такой атаке подвергся GitHub.com. Атакующий создал новый открытый ключ администратора и вручную добавил его в скрытое поле формы. После отправки формы он получал административные привилегии.
Предотвращение оверпостинга
1. Самый простой способ предотвратить атаку оверпостингом - использовать атрибут BindAttribute, чтобы явно контролировать, какие свойства должны получать значения через связыватель модели. Можно использовать либо белый список:
[Bind(Include="Name, Comment")]либо чёрный
[Bind(Exclude="ReviewID, ProductID, Product, Approved"]При этом можно разместить
BindAttribute либо в классе модели, либо в списке параметров метода действия контроллера.2. Можно использовать одну из перегрузок UpdateModel или TryUpdateModel, которая принимает список полей для привязки:
UpdateModel(review, "Review", new string[] { "Name", "Comment" });
3. Возможно, лучший способ справиться с оверпостингом - это избегать привязки непосредственно к модели данных. Это можно сделать, используя модель представления, содержащую только те свойства, которые пользователю разрешено устанавливать:public class ReviewViewModel {
public string Name { get; set; }
public string Comment { get; set; }
}
Привязка к модели представления намного надёжнее привязки к модели данных. Вместо того, чтобы помнить о включении новых полей в белый или черный списки, в подходе с моделью представления единственный способ использовать привязку к свойству - это включить его в модель представления.Источник: Jon Galloway “Professional ASP.NET MVC 5”. – John Wiley & Sons Inc., 2014. Глава 7.