День 1256. #Книги
10 Книг Для Разработчика-Сеньора. Начало
Разработчики - прирождённые читатели, которые получают удовольствие, узнавая о новых вещах. А книги — идеальное средство для глубокого раскрытия сложных идей. Этот список содержит как классические, так и современные публикации, предназначенных для старших разработчиков.

1. Кент Бек «Экстремальное Программирование»
90-е были определяющей эпохой для разработки ПО. Бум доткомов создал огромное давление, заставляющее выпускать продукты раньше и чаще. Никогда прежде производительность не была столь важна для успеха в ИТ-индустрии.
Книга Кента Бека представила и усовершенствовала все agile-практики, которые сегодня считаются само собой разумеющимися: парное программирование, автоматизированное тестирование, разработка через тестирование и непрерывная интеграция.
Второе издание (насколько я знаю, его нет в переводе) уточняет первоначальную идею: быть в курсе, адаптироваться и меняться. Меняться не стыдно. Наоборот, быть готовым к изменениям — хорошая привычка для инженера.
Кент не углубляется в технические детали. Он обсуждает социальные аспекты разработки: взаимодействие с коллегами и руководством, трудовую этику, которой должны следовать программисты, и то, как плоская иерархия помогает всем работать над достижением общей цели.
Зачем читать: эта книга изменит ваше представление о разработке ПО всего на 200 страницах.

2. Джез Хамбл, Дэвид Фарли «Непрерывная Разработка ПО»
В этой книге Фарли и Хамбл выводят принципы непрерывной интеграции, представленные в книге «Экстремальное программирование», на новый уровень. Непрерывная доставка научит вас, как сделать выпуск и развёртывание простыми, как нажатие кнопки.
Посыл Джеза и Дэвида на первый взгляд может показаться нелогичным: «если это больно, делай это чаще и акцентируйся на боли». Заманчиво откладывать сложные части цикла разработки, но это не сделает их проще. Если интеграция болезненна, делайте её при каждом коммите. Если тестирование болезненно, делайте его постоянно, а не только в конце. Акцентируйтесь на боли: сначала делайте сложные вещи, и вам придётся столкнуться с трудностями и найти решения.
В книге очень подробно рассказывается о построении, структурировании и обслуживании конвейера доставки, в том числе о том, какие виды тестов использовать, как обрабатывать данные и как их развивать по мере роста проекта. Хотя некоторые инструменты, использованные в книге, немного устарели, её идеи и принципы вне времени. Это исчерпывающее руководство по DevOps, которое поможет вам перестать беспокоиться о развёртывании.
Зачем читать: любая команда, которая не читала эту книгу, ещё не достигла своего максимального потенциала.

3. Джейсон Фрайд, Дэвид Хайнемайер Хенссон «Remote. Офис не обязателен»
Если пандемия что и продемонстрировала, так это то, что удалённая работа — это не будущее, а настоящее. Мы были вынуждены работать из дома, и у нас было мало времени на адаптацию. Авторы показывают, как Basecamp стала полностью удалённой компанией.
Книга призвана побороть распространённые оправдания против удалённой работы: личное общение не незаменимо, а людям можно (и нужно) доверять, чтобы они продуктивно работали из дома.
Зачем читать: книга покажет руководителю, как выглядит успешная удалённая команда, а работнику - методы, которые помогают работать удалённо, избегая при этом ловушек, которые могут возникнуть в домашних офисах.

Продолжение следует…

Источник: https://semaphoreci.com/blog/books-every-senior-engineer-should-read

День 1257. #Книги
10 Книг Для Разработчика-Сеньора. Продолжение
Начало 1-3

4. Фредерик Брукс «Мифический человеко-месяц»
Можно прочитать о десятках историй успеха, а как насчёт историй неудач? Книга Брукса показывает опасности, с которыми приходится сталкиваться всем сложным проектам. Понятие «человеко-месяц» представляет собой ошибочную идею о том, что вы можете ускорить проект, добавляя людей в команду. Будучи менеджером проекта IBM OS/360, автор заметил, что вместо этого дополнительные люди привели к дальнейшей задержке проекта. Закон Брукса гласит, что «добавление рабочей силы к опаздывающему программному проекту задерживает его ещё больше».
Хотя вы можете быстрее вырыть канаву, добавив больше рабочих рук, некоторые задачи не выигрывают от добавления большего количества людей. По сути, чем сложнее задача, тем труднее разделить её на отдельные, распараллеливаемые задачи. Наблюдения автора и его понимание человеческой природы предлагают бесценные уроки по управлению жизненным циклом сложного проекта, управлению общением в команде, планированию и оценке рабочих графиков.
Зачем читать: прошло почти 50 лет с момента публикации этой книги, а мы всё ещё совершаем те же ошибки при управлении программными проектами. Эту поучительную историю должен прочитать хотя бы один раз каждый инженер.

5. Getting Real
Getting Real — бесплатная электронная книга о том, как сделать проекты простыми. Она побуждает пропускать многие этапы проектирования и приступать к созиданию как можно скорее, несмотря на призывы «создавать меньше, создавать проще», «быть минималистом» и «создавать инструмент, который соответствует вашим потребностям».
Книга делает упор на создание единых команд, разрушение разрозненности, доверие к самостоятельной работе людей и избегание собраний. Это набор правил, который сработал для Basecamp и может сработать для вас. Но даже если это не так, основные ценности, лежащие в основе этих принципов, стоит изучить.
Зачем читать: это серьёзная, но краткая книга о создании продуктов с помощью удалённой команды. Ещё и бесплатная!

6. Мартин Клеппман «Высоконагруженные приложения. Программирование, масштабирование, поддержка»
Знаменитая книга с кабанчиком. Данные — это кровь каждого приложения. Знание того, как проектировать большие наборы данных и управлять ими, является жизненно важным навыком для любого старшего инженера, которому рано или поздно придётся масштабировать систему. Книга Клепманна — это подробное руководство, охватывающее всё, начиная от моделей данных и баз данных SQL и NoSQL до очередей сообщений, распределённых систем и больших данных.
Основа книги – теория. Вы не найдёте ни кода, ни примеров. В то же время это практический текст, в котором рассматриваются компромиссы между несколькими типами технологий обработки данных.
Зачем читать: если вы разрабатываете приложения, потребляющие или обрабатывающие данные любого типа, эта книга поможет вам сбалансировать плюсы и минусы доступных технологий.

Окончание следует…

Источник: https://semaphoreci.com/blog/books-every-senior-engineer-should-read

День 1258. #Книги
10 Книг Для Разработчика-Сеньора. Окончание
Начало 1-3
Продолжение 4-6

7. Бетси Бейер, Крис Джоунс «Site Reliability Engineering»
У разработки ПО есть скрытая сторона, которую игнорирует большинство технических книг: как поддерживать работоспособность системы после её создания. Эта книга - сборник эссе сотрудников Google, исправляет это упущение.
Инженеры по надёжности обслуживания (SRE) поддерживают работоспособность систем, выявляют проблемы до того, как они возникнут, проводят анализ, когда происходит что-то ужасное, и выполняют всю работу, необходимую для того, чтобы это никогда не повторилось.
Даже если SRE не входит в ваши обязанности, навыки, которые вы можете получить из этой книги, помогут вам создавать более устойчивые продукты. В этой книге приводятся советы, которые со временем помогут обеспечить надёжные сервисы и устойчивые рабочие нагрузки.
Зачем читать: это бесценное руководство о том, как крупнейшая в мире компания-разработчик ПО управляет рисками и поддерживает работу систем.

8. Джин Ким, Кевин Бер «Проект "Феникс"»
Это история вымышленной компании Parts Unlimited и ее пути к agile-практикам. Книга начинается с кризиса. Генеральный директор уходит в отставку после резкого падения курса акций; компания теряет деньги и отстаёт от конкурентов. В условиях этого кризиса Биллу Палмеру (главному герою) поручают заняться проектом, который всё исправит: многообещающей «Программой Феникс». Авторы создали захватывающую историю с занимательными диалогами и удовлетворяющей концовкой.
Зачем читать: это современная ИТ-басня, которая должна найти отклик у любого опытного инженера. Если вы устали читать сухие технические книги, это идеальный выбор.

9. Сэм Ньюмен «Создание микросервисов»
Облачные приложения сделали изучение микросервисов обязательным. Новые проекты начинают широко использовать микросервисы, и монолит часто разбивается на распределённые системы. Книга расскажет вам, как сделать и то, и другое. В ней полно конкретных примеров организаций, использующих микросервисы для масштабирования своей деятельности, рассказывается, как спроектировать, построить, развернуть, защитить и контролировать распределённую систему.
Зачем читать: это всеобъемлющее руководство по микросервисам и распределённым системам, которое не содержит модных словечек, зато раскрывает суть дела.

10. Dave Farley «Modern Software Engineering: Doing What Works to Build Better Software Faster»
Разработка ПО и программирование кажутся взаимозаменяемыми. Реальность такова, что разработка — это гораздо больше, чем просто код. Книга пытается восстановить первоначальное значение этого термина: «применение эмпирического научного подхода к поиску эффективных и экономичных решений практических проблем в ПО».
В книге ставится задача найти рациональную, практичную и устойчивую основу для разработки ПО. Автор использует итеративный экспериментальный подход, напоминающий предложение Фреда Брукса «выбросить прототип». Дэвид показывает, как принимать дизайнерские решения на конкретных примерах. Книга охватывает основные аспекты ремесла, такие как абстракция, разделение задач и модульность для управления сложностью.
Зачем читать: это книга, о которой вы мечтали, когда начинали заниматься разработкой ПО.

Источник: https://semaphoreci.com/blog/books-every-senior-engineer-should-read

День 1259. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало 1-4
Продолжение 5-9
Продолжение 10-13

14. Подделка межсайтовых запросов (Cross-Site Request Forgery – CSRF)
CSRF — это техника атаки на других пользователей веб-приложения, используемая на стороне клиента. С помощью CSRF злоумышленники могут отправлять HTTP-запросы, которые якобы исходят от жертвы, выполняя нежелательные действия от имени жертвы. Например, злоумышленник может изменить ваш пароль или перевести деньги с вашего банковского счета без вашего разрешения. См. пример.
В отличие от открытых перенаправлений, существует надежный способ предотвратить CSRF: использовать комбинацию токенов CSRF и SameSite-куки, а также избегать использования запросов GET для действий по изменению состояния.

15. Подделка запроса на стороне сервера (Server-Side Request Forgery – SSRF)
SSRF — это уязвимость, которая возникает, когда злоумышленник может отправлять запросы от имени сервера. Она позволяет злоумышленникам «подделывать» сигнатуры запросов уязвимого сервера, тем самым занимая привилегированное положение в сети, обходить средства управления брандмауэром и получать доступ к внутренним службам.
В зависимости от разрешений, предоставленных уязвимому серверу, злоумышленник может читать конфиденциальные файлы, выполнять внутренние вызовы API и получать доступ к внутренним службам, таким как скрытые инструменты администратора. Самый простой способ предотвратить уязвимости SSRF — никогда не делать исходящие запросы на основе пользовательского ввода. Если их приходится делать, необходимо проверять эти адреса перед инициированием запроса.

16. Нарушение границ доверия
«Границы доверия» относятся к тому, где ненадёжные пользовательские данные входят в контролируемую среду. Например, HTTP-запрос считается ненадёжными данными до тех пор, пока он не будет проверен сервером.
Должно быть чёткое различие между тем, как вы храните, транспортируете и обрабатываете доверенные и ненадёжные входные данные. Нарушения границ доверия происходят, когда это различие не соблюдается, а надёжные и ненадёжные данные смешиваются друг с другом. Например, если доверенные и недоверенные данные хранятся в одной и той же структуре данных или базе данных, приложение начнёт их путать. В этом случае ненадёжные данные могут быть ошибочно приняты за проверенные.
Хороший способ предотвратить нарушение границ доверия — никогда не записывать ненадёжные входные данные в хранилища, пока они не будут проверены.

17. Удалённое выполнение кода (Remote Code Execution - RCE)
RCE, представляют собой класс уязвимостей, которые возникают, когда злоумышленники могут выполнить свой код на вашем компьютере. Один из способов — уязвимости внедрения команд, когда пользовательский ввод объединяется непосредственно с системной командой. Приложение не может различить, где находится пользовательский ввод, а где системная команда, поэтому приложение выполняет пользовательский ввод как код. Злоумышленник сможет выполнять произвольные команды на машине.
Самый простой способ предотвратить удалённое выполнение кода — убедиться, что код, представленный в виде строки, и предназначенный для исполнения, получен только из надёжных источников, или внедрить надёжную проверку ввода в виде списка разрешений.

Продолжение следует…

Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet

День 1260. #TypesAndLanguages
5. Чистые и «Нечистые» Функции
Чистые функции — функции, возвращающие один и тот же результат для одних и тех же входных данных, не полагаясь на внешнее состояние. Некоторые любят их. Некоторые утверждают, что все функции должны быть чистыми. Некоторые языки борются с нечистыми функциями или даже вообще не позволяют вам их создавать. Правильно ли говорить, что чистые функции лучше?

Вся аргументация относительно того, какие функции лучше, сводится к влиянию функций на код в целом. У чистых функций меньше «радиус поражения», что упрощает доказательство гипотез относительно них.

Чистые функции принимают входные параметры I и производят выходные данные O. Нечистые функции принимают входные данные в форме (I, S), где I — входные параметры, а S представляет внешнее состояние, подобное глобальным переменным. Нечистые функции также производят результат O, однако при этом O может влиять на S (и даже на I).

Как S меняет ситуацию? Мы можем утверждать, что S представляет состояние приложения, которое является неявными входными данными для функции. Имея это в виду, как чистые, так и нечистые функции возвращают один и тот же результат O для полученных входных данных. Однако чистые функции используют (I, null) в качестве входных данных, а нечистые используют (I, S). С этой точки зрения оба типа функций на самом деле чистые. В чём же разница?

Разница в том, что отследить I намного проще, чем S. Обычно нужно просто проанализировать место вызова и место, где I было задано значение. Нам не нужно смотреть на остальной код. Аналогично мы можем отследить входные данные вызывающей функции, и т.д. вверх по стеку вызовов.

Однако мы не можем так просто отследить S. Чтобы доказать что-либо об S, нам нужно не только показать, как было задано значение S, но также и доказать, что оно не было изменено ничем за пределами стека вызовов. Другими словами, чтобы что-то доказать гипотезу об I, нам нужно просто показать пример, подтверждающий нашу гипотезу. Например, что Math.Sqrt(4) = 2. Однако, чтобы доказать что-то об S, нам нужно показать, что нет никаких «контраргументов» (кода, изменяющего состояние S неожиданным образом), опровергающих нашу гипотезу. Последнее, как правило, намного сложнее, так как нам нужно проанализировать гораздо больше кода, чтобы доказать это. Кроме того, поиск такого кода может быть нетривиальным, так как это может быть рефлексия, параллельно выполняемый код и т.п. Или код может быть вообще недоступен, как какой-то динамически загружаемый плагин.

Однако до тех пор, пока мы можем поддерживать I и S небольшими по размеру, всё остальное не имеет значения. Дело не в том, чистая функция или нет. Всё дело в способности отследить входные данные (I, S). Это зависит от ваших когнитивных навыков, опыта и навыков программирования в целом. Некоторые функции могут быть ужасны и с тремя входными параметрами и без глобального состояния, тогда как другие функции могут отлично работать без параметров, но с пятью глобальными переменными.

А что насчёт изменчивости? В большинстве случаев это не имеет значения. Давайте рассмотрим пример функции double.TryParse. По определению она нечистая, так как 1) изменяет входной параметр и 2) использует глобальное состояние (символ десятичного разделителя). Однако является ли эта функция «неправильной» или «плохой»? Нет, потому что её «радиус поражения» обычно сильно ограничен.

Примечание: на самом деле все функции принимают ещё один параметр E. Параметр представляет собой среду, такую как память, используемую операционную систему, тип процессора, электрические помехи или даже космические лучи. Разница между S и E заключается в том, что мы контролируем. Мы можем контролировать S, поскольку это состояние выполняемого нами приложения, но мы не можем контролировать E. Вы можете косвенно повлиять на память, используемую операционной системой, но, скорее всего, вы не сможете повлиять на космический луч.

Источник: https://blog.adamfurmanek.pl/2022/07/09/types-and-programming-languages-part-14/

День 1261. #Testing
E2E-тесты с Помощью Playwright в .NET
Playwright – это система end-to-end тестирования, поддерживающая тесты, написанные на NodeJS, Java, Python и C#. Допустим, нам нужно протестировать следующий сценарий:
- Учитывая, что я на https://www.google.com
- Когда я набираю "netdeveloperdiary" в поле поиска
- И нажимаю кнопку "Поиск в Google"
- Тогда первым результатом будет ссылка https://t.iss.one/NetDeveloperDiary

Очевидно, что результат может не всегда быть одинаковым. Но это простейший пример. Playwright – это просто NuGet пакет, который можно использовать в MSTest, NUnit, XUnit или любой другой тестовой среде. В данном случае используем MSTest и пакет Microsoft.Playwright.MSTest. Вот тестовый класс:

[TestClass]
public class MyUnitTests : PageTest
{
  [TestMethod]
  public async Task TestGoogleSearch()
  {
    //Учитывая, что я на https://www.google.com
    await Page.GotoAsync("https://www.google.com");
    //Когда я набираю "netdeveloperdiary" в поле поиска
    await Page.FillAsync("[title=\"Поиск\"]", "netdeveloperdiary");
    //И нажимаю кнопку "Поиск в Google"
    await Page.ClickAsync("[value=\"Поиск в Google\"] >> nth=1");
    //Тогда первым результатом будет https://t.iss.one › NetDeveloperDiary
    var firstResult = await Page.Locator("//cite >> nth=0").InnerTextAsync();
    Assert.AreEqual("https://t.iss.one › NetDeveloperDiary", firstResult);
  }
}

Вот на что стоит обратить внимание.
1. Тестовый класс наследует от PageTest
Пакет PlayWright.MSTest содержит код настройки объекта браузера, а также поддерживает параллельные тесты. Без использования этого пакета мы могли бы настроить объект браузера сами, и получить большую свободу:

IPage Page;
[TestInitialize]
public async Task TestInitialize()
{
  var plwrt = await Playwright.CreateAsync();
  var brw = await plwrt.Chromium.LaunchAsync(
   new BrowserTypeLaunchOptions
   {
     Headless = false
   });
  Page = await brw.NewPageAsync();
}

2. Мы не используем таймауты и все методы асинхронные.
Нам не нужно ожидать запуска браузера и момента, пока элементы отобразятся на экране. Всё это берёт на себя Playwright. Например, когда вы хотите заполнить поле для ввода, Playwright предполагает, что оно должно появиться на странице, и ждёт его появления (по умолчанию 30 секунд). Помимо этого, то, что всё происходит асинхронно означает, что вы не столкнётесь с замиранием экрана во время ожидания следующей операции.

В остальном тесты должны быть понятны. Мы заполняем поле для ввода, нажимаем на кнопку поиска и проверяем первый результат.

Примечание. При первом использовании Playwright на вашей машине, нужно выполнить следующую команду из вашего проекта для установки движков браузеров:

bin\Debug\net6.0\playwright.ps1 install

Playwright содержит множество методов управления браузером и анализа результатов, а также может выполнять и более сложные действия, вроде снимка экрана, который можно сохранить для последующего анализа или сравнения.

Источник: https://dotnetcoretutorials.com/2022/05/20/using-playwright-e2e-tests-with-c-net/

День 1262. #Оффтоп
2022й год. Вы всё ещё пишете регулярные выражения из головы или гуглите? Автору этого сайта так надоело это делать, что он заморочился и, с помощью GPT-3 (который используется в Copilot), создал ИИ, генерирующий RegEx за вас на основе человеческого запроса!

Представляю https://www.autoregex.xyz/

Сайт, правда, быстро положили, а чуть позже израсходовали все лимиты доступа к ИИ у автора. Поэтому не могу гарантировать, что он работает в данный момент. Но мне самому удалось немного попробовать, и это очень круто.

День 1263. #Оффтоп
Сегодня посоветую вам интересный доклад Скотта Хансельмана с NDC Conferences, которая прошла в апреле в Порто. Тема доклада – «Перемещение 17-летнего легаси кода и сайтов в облако». Скотт рассказал, как создавал свой веб-сайт в качестве хобби. Как важно иметь свой небольшой проект, работать над ним и пробовать всё, что вы изучаете. Особенно важно попробовать себя в работе с производственной средой и потренироваться в развёртывании. Потому что, будем честны, совсем немногие из нас имеют много такого опыта.

Скотт рассказывает, как создавал свой сайт, как развёртывал его, буквально копируя dllки со своего компьютера на сервер, и как перешёл (точнее вынужден был перейти) в облако с полноценной системой CI/CD.

Помимо этого, он даёт несколько советов по поводу выбора архитектуры и функционала. Например, записи в его блоге – это просто статичные файлы, названные по порядку. А информация о спонсорах, которая меняется очень редко, - вообще в JSON файле.

В общем, много полезных советов и с юмором. Приятного просмотра.

https://youtu.be/mE-DGW0CcAk

День 1264. #ЗаметкиНаПолях
Используем Span Для Производительности. Начало
Сегодня рассмотрим Span в C#, как он реализован и как мы можем использовать его для повышения производительности.

Span<T> — это типобезопасное и безопасное по памяти представление непрерывной области памяти. Span<T> реализован как ref-структурa (подробнее о ref-структурах), которая содержит ссылку на объект T и длину для чтения. Т.е. Span в C# всегда будет размещаться на стеке, а не в куче. Рассмотрим упрощённую реализацию Span<T>:

public readonly ref struct Span<T>
{
  private readonly ref T _pointer;
  private readonly int _length;
}

Использование Span<T> повышает производительность за счёт размещения на стеке, т.к. сборка мусора не тормозит выполнение приложения. Операции со Span<T> аналогичны операциям с массивами: индексация в Span не требует вычислений для определения адреса памяти.

Другой реализацией Span является ReadOnlySpan<T>. Его отличие от Span в том, что индексатор возвращает ссылку на T только для чтения. Это позволяет использовать ReadOnlySpan<T> для представления неизменяемых типов данных, таких как string.

Span может использовать типы значений, такие как int, byte, ref struct, bool и enum. Span не может использовать такие типы, как object, dynamic или интерфейсы.

Ограничения
Реализация Span ограничивает его использование в коде. Объекты ссылочного типа размещаются в куче, поэтому мы не можем использовать Span в качестве полей в ссылочных типах. Также ref-структуры не могут быть упакованы, и Span нельзя использовать в лямбда-выражениях и асинхронном коде с await, а также с yield. Кроме того, т.к. мы выделяем память в стеке, мы должны помнить, что памяти в стеке меньше, чем в куче.

Span-подобный класс можно использовать в асинхронном коде. Это классы Memory<T> и ReadOnlyMemory<T>.

Примеры
Мы можем использовать Span для работы с массивами и другими типами коллекций:

int[] arr = new[] { 0, 1, 2, 3 };
Span<int> intSpan = arr;
var otherSpan = arr.AsSpan();

C# предлагает неявное приведение от T[] к Span<T>, но мы также можем вызвать AsSpan() для массивов. Как ReadOnlySpan<T>, так и Span<T> предлагают знакомые по работе с массивами функции, не выделяющие дополнительную память.

Теперь рассмотрим на аналогичный пример с List<T>:

List<int> intList = new() { 0, 1, 2, 3 };
var listSpan = CollectionsMarshal.AsSpan(intList);

Использовать Span с коллекцией не так просто, как с массивами. В этом случае мы должны использовать метод CollectionMarshal.AsSpan(), чтобы получить коллекцию в виде Span. Для этого нужно импортировать пространство имён System.Runtime.InteropServices.

Окончание следует…

Источник: https://code-maze.com/csharp-span-to-improve-application-performance/

День 1265. #ЗаметкиНаПолях
Используем Span Для Производительности. Окончание
Начало

Используем ReadOnlySpan вместо строки
Рассмотрим пример, где нам нужно разобрать строку построчно:

public int ParseWithString()
{
  var prev = 0;
  var curr = 0;
  var rows = 0;
  foreach (char c in _text)
  {
    if (c == '\n')
    {
      curr += 1;
      var line = _text[prev..curr];
      if (line.Equals(Environment.NewLine))
        rows++;
      prev = curr;
      continue;
    }
    curr++;
  }

  return rows;
}

В первом примере мы используем строки. Мы пытаемся определить, сколько пустых строк в нашем файле. Текст хранится в строковой переменной _text. Мы перебираем каждый символ строке, если находим символ новой строки, с помощью Substring() проверяем предыдущую строку. Если эта строка пустая, увеличиваем счётчик. Ключевым моментом здесь является то, что Substring() создаёт строку в куче. Сборщику мусора потребуется время, чтобы уничтожить эти строки.

Теперь тот же процесс с использованием Span:

public int ParseWithSpan()
{
  var textSpan = _text.AsSpan();
  var prev = 0;
  var curr = 0;
  var rows = 0;
  foreach (char c in textSpan)
  {
    if (c == '\n')
    {
      curr += 1;
      var slice = textSpan[prev..curr];
      if (slice.Equals(Environment.NewLine, StringComparison.OrdinalIgnoreCase))
        rows++;
      prev = curr;
      continue;
    }
    curr++;
  }

  return rows;
}

Здесь процесс такой же, за исключением того, что мы не создаем дополнительные строки. Мы преобразуем текстовую строку в ReadOnlySpan, вызывая метод AsSpan(). Кроме того, вместо Substring() мы используем метод Slice, который создаёт ReadOnlySpan, представляющий подстроку. В этом случае в куче ничего не выделяется.

Вспомним, что сборка мусора напрямую влияет на производительность приложения. Используя ReadOnlySpan вместо строк везде, где возможно, мы можем сильно повысить производительность приложения. ReadOnlySpan поддерживает множество функций, знакомых по работе со строками: Contains(), EndsWith(), StartsWith(), IndexOf(), LastIndexOf(), ToString(), Trim() и т.п.

Тестирование
Оценим результаты теста производительности двух примеров выше:
ParseWithSpan - 23.55 us, без аллокаций.
ParseWithString - 36.12 us, аллоцировано 70,192 B

Результаты ожидаемы. Span работает быстрее и не выделяет дополнительной памяти (но см. ограничения в предыдущем посте).

Итого
Использование Span повышает производительность. Важно отметить, что команда разработчиков .NET активно использует Span во внутренних библиотеках и максимально упрощает их использование для разработчиков. Команда .NET уже имеет поддержку Span<T> для DateTime, TimeSpan, Int32, GUID, StringBuilder, System.Random и многих других типов. Важно понимать, как использовать Span, потому что они будут больше и больше присутствовать в будущем коде .NET и в некоторых случаях могут стать стандартом.

Источник: https://code-maze.com/csharp-span-to-improve-application-performance/

День 1266. #ЧтоНовенького
AWS Упростили Развёртывание Приложений .NET
Теперь развёртывание в AWS доступно в Visual Studio в виде нового мастера "Publish to AWS" (Опубликовать в AWS), либо через интерфейс командной строки .NET после установки AWS Deploy Tool для .NET.

Одной из основных новых функций являются проекты развёртывания. Эта новая концепция позволяет настраивать развёртывания внутри Visual Studio или CLI и делиться ими с остальными членами вашей команды. Проекты развёртывания позволяют командам разрабатывать собственные сценарии и по-прежнему использовать интерактивные развёртывания или развёртывания с использованием сценариев.

Новый интерфейс развёртывания поддерживает ASP.NET Core, Blazor WebAssembly, консольные приложения и задачи, которые необходимо выполнять по расписанию. В настоящее время функции .NET Lambda не поддерживаются. Существующий мастер развёртывания Lambda и .NET CLI Amazon.Lambda.Tools по-прежнему являются рекомендуемыми вариантами развёртывания для приложений .NET Lambda.

В Visual Studio установите последнюю версию AWS Toolkit для Visual Studio. После установки инструментария и настройки учетных данных AWS можно щелкнуть правой кнопкой мыши на проект в обозревателе решений и выбрать пункт "Publish to AWS…". Новый мастер предложит сервис AWS, который лучше всего подходит для вашего приложения.

В .NET CLI выполните следующую команду для установки инструмента из NuGet:

dotnet tool install --global Aws.Deploy.Tools

После установки можно выполнить следующую команду для начала развёртывания:

dotnet aws deploy

Команда deploy поможет вам выбрать правильный сервис AWS для развёртывания и настроить параметры. Развёртывание через CLI и через Visual Studio очень похоже, что позволяет развёртывать один и тот же проект из любой среды. Вы также можете составить список своих развёртываний с помощью команды dotnet aws list-deployments или удалить развёртывание с помощью dotnet aws delete-deployment. Используйте команду dotnet aws --help, чтобы найти дополнительные сведения о других доступных командах.

Подробности о работе инструмента есть в документации AWS.

Источник: https://aws.amazon.com/blogs/developer/aws-announces-a-streamlined-deployment-experience-for-net-applications/

День 1267. #ЗаметкиНаПолях #AsyncTips
Выборка в очередях

Задача
Есть очередь «производитель/потребитель», но производители могут работать быстрее потребителей, что может привести к неэффективному использованию памяти. Сохранять все элементы из очереди не обязательно; необходимо отфильтровать элементы очереди так, чтобы более медленные потребители могли ограничиться обработкой самых важных элементов.

Решение
Библиотека Channels предоставляет самые простые средства применения выборки к элементам ввода. Типичный пример — всегда брать последние n элементов с потерей самых старых элементов при заполнении очереди:

var queue = Channel.CreateBounded<int>(
  new BoundedChannelOptions(1)
  {
    FullMode = BoundedChannelFullMode.DropOldest,
  });
var writer = queue.Writer;
// Операция записи завершается немедленно.
await writer.WriteAsync(7);
// Операция записи тоже завершается немедленно.
// Элемент 7 теряется, если только он не был
// немедленно извлечен потребителем.
await writer.WriteAsync(13);

Это самый простой механизм контроля входных потоков и предотвращения «затопления» потребителей.

Есть и другие режимы BoundedChannelFullMode. Например, если вы хотите, чтобы самые старые элементы сохранялись, можно при заполнении канала терять новые элементы:

var queue = Channel.CreateBounded<int>(
  new BoundedChannelOptions(1)
  {
    FullMode = BoundedChannelFullMode.DropWrite,
  });
var writer = queue.Writer;
// Операция записи завершается немедленно
await writer.WriteAsync(7);
// Операция записи тоже завершается немедленно
// Элемент 13 теряется, если только элемент 7 не был
// немедленно извлечен потребителем.
await writer.WriteAsync(13);

Пояснение
Библиотека Channels отлично подходит для простой выборки. Во многих ситуациях полезен режим BoundedChannelFullMode.DropOldest. Более сложная выборка должна выполняться самими потребителями.
Если выборка должна выполняться по времени (например, «только 10 элементов в секунду»), используйте System.Reactive. В System.Reactive предусмотрены естественные операторы для работы со временем.

См. также
- Асинхронные очереди
- Блокирующие очереди
- Регулировка очередей

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.

День 1268. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
1-4
5-9
10-13
14-17

Инъекции. Начало
Проблемы с инъекциями возникают, когда приложение не может правильно отличить ненадёжные пользовательские данные от кода.

18. SQL-инъекции
При атаке с SQL-инъекцией злоумышленник вводит данные для управления командами SQL. Когда приложение не проверяет пользовательский ввод должным образом, злоумышленники могут вставлять спецсимволы языка SQL, чтобы нарушить логику запроса; тем самым выполняя произвольный код SQL.
Это позволит злоумышленнику изменять структуру SQL-запросов для кражи или изменения данных, или потенциального выполнения произвольных команд в операционной системе. Лучший способ предотвратить SQL-инъекции — использовать параметризованные запросы, что делает SQL-инъекции практически невозможными.

19. NoSQL-инъекции
Относятся к атакам, которые внедряют данные в логику языков NoSQL (Not Only SQL) баз данных. Современные базы данных NoSQL, такие как MongoDB, Couchbase, Cassandra и HBase, уязвимы для атак путем инъекций. Синтаксис запросов NoSQL зависит от базы данных, и запросы часто пишутся на языке приложения. По той же причине методы предотвращения NoSQL-инъекций в каждую базу данных также зависят от базы данных.

20. LDAP-инъекции
Облегчённый протокол доступа к каталогам (Lightweight Directory Access Protocol - LDAP) — это способ запроса к службе каталогов о пользователях и устройствах системы. Например, он используется для запросов к Microsoft Active Directory. Когда приложение использует ненадёжные входные данные в запросах LDAP, злоумышленники могут отправлять специально созданные данные и обходить аутентификацию или портить данные, хранящиеся в каталоге.

21. Инъекции в журналы
Вы задумывались когда-нибудь о том, что записи в файле журнала могут вам лгать? Файлы журнала, как и другие системные файлы, могут быть изменены злоумышленниками (например, чтобы замести следы во время атаки). Инъекции в журналы происходят, когда злоумышленник обманом заставляет приложение записывать поддельные записи в ваши файлы журналов.
Часто они происходят, когда приложение не экранирует символы новой строки «\n» во входных данных, записываемых в журналы. Злоумышленники могут использовать символ новой строки для вставки новых записей в журналы приложений. Другой способ заключается во внедрении вредоносного HTML в записи журнала, чтобы попытаться провести XSS-атаку на браузер администратора, который просматривает журналы.
Чтобы предотвратить атаки через инъекции в журналы, вам нужен способ отличить настоящие записи журнала от поддельных, введённых злоумышленником. Один из способов сделать это — добавить к каждой записи журнала дополнительные метаданные, такие как отметка времени, идентификатор процесса и имя хоста. Вы также должны относиться к содержимому файлов журналов как к ненадёжным входным данным и проверять их перед доступом к ним или операциями с ними.

22. Инъекции в почте
Многие веб-приложения отправляют электронные письма пользователям в зависимости от их действий. Например, если вы подписались на ленту новостей, веб-сайт может отправить вам письмо с подтверждением.
Инъекции в почте происходят, когда приложение использует пользовательский ввод, чтобы определить, на какие адреса отправлять электронные письма. Это может позволить спамерам использовать ваш сервер для массовых рассылок пользователям или позволить мошенникам проводить фишинговые кампании через ваш адрес электронной почты.

Окончание следует…

Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet

День 1269. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Окончание
1-4
5-9
10-13
14-17
18-22

Инъекции. Окончание
23. Инъекции в шаблоны
Шаблоны предоставляют разработчикам способ указать, как должна отображаться страница, комбинируя данные приложения с макетом страницы, тем самым отделяя бизнес-логику приложения от клиентского кода представления.
В зависимости от разрешений скомпрометированного приложения злоумышленники могут использовать уязвимость инъекции в шаблон для чтения конфиденциальных файлов, выполнения кода или повышения своих привилегий в системе.

24. Инъекции в регулярные выражения
Иногда приложения позволяют пользователям предоставлять серверу собственные шаблоны регулярных выражений. Атака с инъекцией в регулярное выражение – вид атаки на «отказ в обслуживании» (ReDoS – подробнее об этой атаке в будущих постах) - происходит, когда злоумышленник предоставляет механизму регулярных выражений шаблон, для оценки которого требуется много времени.

25. XPath-инъекции
XPath — это язык запросов, используемый в XML-документах для запроса и выполнения операций с данными, хранящимися в XML-документах. XPath-инъекция — это инъекция в выражения XPath, чтобы изменить результат запроса. Подобно SQL-инъекции, её можно использовать для обхода бизнес-логики, повышения привилегий пользователя и утечки конфиденциальных данных. Поскольку приложения всё ещё часто используют XML для передачи конфиденциальных данных между системами и веб-сервисами, именно эти места наиболее уязвимы для XPath-инъекций.

26. Инъекции в заголовки
Происходят, когда заголовки ответов HTTP динамически создаются из ненадёжных входных данных. В зависимости от того, на какой заголовок ответа влияет уязвимость, инъекция в заголовок может привести к межсайтовому скриптингу, открытому перенаправлению или краже сессии.
Например, если заголовком Location можно управлять с помощью параметра URL, злоумышленники могут вызвать открытое перенаправление, указав свой вредоносный сайт. Злоумышленники могут даже выполнять вредоносные сценарии в браузере жертвы или заставлять жертв загружать вредоносное ПО, отправляя жертве полностью контролируемые HTTP-ответы посредством инъекции в заголовок.
Вы можете предотвратить эту атаку, избегая записи пользовательского ввода в заголовки ответов, удаляя символы новой строки из пользовательского ввода (символы новой строки используются для создания новых заголовков ответов HTTP) или используя белый список для проверки значений заголовков.

27. Инъекции в сессии и небезопасные cookie
Если злоумышленник может манипулировать содержимым cookie-файла сессии или украсть чужие cookie, он может обмануть приложение, заставив его думать, что он является кем-то другим. Существует три основных способа, с помощью которых злоумышленник может получить доступ к чужой сессии:
1) Перехват сессии, когда злоумышленник крадёт чужой cookie-файл сессии и использует его как свой. Злоумышленники часто крадут cookie-файлы сессии с помощью атак XSS или MITM (man-in-the-middle).
2) Фальсификация сессии, когда злоумышленники могут изменить свой cookie-файл сессии, чтобы изменить то, как сервер интерпретирует их личность. Это происходит, когда состояние сессии передаётся в файле cookie, а он неправильно подписан или не зашифрован.
3) Спуфинг сессии – это «подделка» сессии, когда её идентификатор предсказуем. В этом случае злоумышленники могут подделывать настоящие cookie-файлы сессии и входить в систему как кто-то другой.

Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet

День 1270. #Оффтоп
А вы знали, что C# допускает out-параметры в конструкторе? То есть вы можете написать что-то вроде:

class MyClass
{
  public MyClass(out bool succeeded)
  {
    // что-то делаем        
    succeeded = true;
  }
}

Живите теперь с этим…

На Stackoverflow есть даже попытка объяснения:
«В некоторых случаях может быть необходимо при неудаче в конструкторе передать информацию о том, какие части операции были успешными, а какие нет. Рассмотрим, например, объект, конструктор которого принимает дескриптор неуправляемого объекта и должен его инкапсулировать. Если конструктор выдаёт исключение, может быть обязательно, чтобы вызывающий объект освобождал неуправляемый объект, если этого не сделал конструктор, и в равной степени обязательно, чтобы вызывающий объект не освобождал объект, если это сделал конструктор. Наличие в конструкторе параметра out или ref может быть наименее опасным способом для класса сообщить вызывающему объекту, что нужно будет очистить, если конструктор завершится ошибкой.

Хотя передавать конструктору параметры ref или out некрасиво, существуют некоторые типы, в которых попытки создать пригодный для использования экземпляр будут иметь побочные эффекты и могут завершиться неудачей после того, как некоторые из этих побочных эффектов уже произошли. Если невозможно создать допустимый объект, вот способы передать информацию вызывающей стороне:
- сохранение в поле ThreadStatic,
- инкапсуляция в выброшенном исключении,
- сохранение или передача в параметр в виде объекта или делегата,
- запись в параметр ref/out.
Из них только параметр ref/out делает очевидным наличие информации, с которой клиентский код должен что-то делать.

Существование параметров ref или out часто является признаком того, что конструктор должен быть помечен как protected, и что внешний код должен проходить через фабричные методы, которые гарантируют, что в случае возникновения исключения переданный объект будет использоваться соответствующим образом. Однако, чтобы класс мог разумно поддерживать наследование, он должен предлагать по крайней мере один конструктор, видимый вне его.»

Источник: https://stackoverflow.com/questions/19633251/constructor-with-output-parameter

День 1272. #Оффтоп
Github и Лицензирование

Вопрос
Код моего проекта на Github скопировали вместе с комментариями и выдали за свой. Я не указывал никакой лицензии в своём проекте. В будущем, если кто-то попытается скопировать мой проект, как быть? Означает ли наличие кода на Github, что любой может скопировать код, не указывая автора? Не хотелось бы просто закрывать свои репозитории.

Ответ на зависит от лицензии, которую вы применили к проекту.

1. Лицензия не указана
Технически, если вы не указали лицензию, а также явно не поместили работу в публичный домен, то никто, кроме вас, не может легально делать копии. Независимо от того, заявили ли вы это где-либо явно или нет, этот случай, по сути, является авторским правом, и все права защищены. Если в этом ваше намерение, то такой репозиторий лучше закрыть. Люди все время форкают и клонируют общедоступные репозитории, в том числе без заявленных лицензий. Многие ошибочно думают, что отсутствие лицензии означает разрешение на свободное использование, но на самом деле нет.

2. Лицензия MIT
Эта лицензия разрешает всё. Позволяет другим делать практически всё что угодно с вашим кодом: копировать, как есть, изменять, использовать в коммерческом программном обеспечении с закрытым исходным кодом, продавать с изменениями или без них и так далее. Единственное требование заключается в том, чтобы они сохраняли уведомление об авторских правах и уведомление о лицензии в неизменном виде во всех копиях, которые они распространяют, в том числе в «значительных частях». Однако они могут распространять код с изменениями или без под любой лицензией, под которой пожелают. Основная цель требования сохранения уведомления состоит в том, чтобы другие знали, как эта часть была первоначально лицензирована. Можно копировать несущественные части без включения вашего уведомления об авторских правах и лицензии.

С лицензией MIT вы должны помещать уведомления об авторских правах и лицензии в комментариях вверху каждого исходного файла в дополнение к файлу лицензии в репозитории. Таким образом, если кто-то использует один или несколько файлов, но не весь репозиторий, ваше уведомление об авторских правах и заявление о лицензии останутся с вашим кодом, если только его не удалят преднамеренно. Имея только файл лицензии, вы рискуете, что любой из ваших исходных файлов может быть использован отдельно от остального кода без указания лицензии.

3. Лицензия Apache
Как и с MIT, здесь разрешено всё. Есть несколько отличий, но в основном она позволяет другим использовать ваш код так, как они считают нужным. Одно из отличий заключается в том, что Apache требует, чтобы любые изменения в вашем коде были идентифицированы, чтобы другие знали, что он был изменён и как. MIT не требует этого, хотя многие всё равно это делают.

Как и в случае с MIT, лучше помещать уведомление об авторских правах вверху каждого исходного файла, но не полную лицензию (слишком длинную для этого). В нижней части лицензии Apache есть сокращённое уведомление, которое следует включать в комментарий вверху каждого исходного файла. Причина та же, что и в случае с MIT.

Всеразрешающие лицензии, как MIT или Apache, близки к тому, чтобы сделать что-то общественным достоянием, не делая этого на самом деле. В некоторых странах это самое близкое к тому, чтобы сделать что-то общественным достоянием.

4. Лицензия «копилефт»
Если вы хотите сохранить больше прав на свою работу, можно использовать лицензию «копилефт». Если коротко, применение лицензии «копилефт» к коду, требует от любого, кто создаёт производную работу на основе вашего кода, применения той же лицензии. По сути, это сохраняет ваш код и всё, что из него происходит, открытым кодом. Лицензии MIT и Apache не накладывают таких обязательств. GPL 3.0 является наиболее распространённой лицензией «копилефт».

Источник: https://dev.to/sadeedpv/someone-copied-my-code-on-github-and-claimed-to-be-his-own-project-4dho

День 1273. #ЧтоНовенького
Обновления ASP.NET Core в .NET 7 Превью 6. Начало
Некоторые интересные новинки, которые выпустили для ASP.NET Core в очередном превью .NET 7.

1. Промежуточное ПО для распаковки запросов
Используется HTTP-заголовок Content-Encoding для автоматической идентификации и распаковки запросов со сжатым содержимым, чтобы разработчику серверной части не приходилось заниматься этим самостоятельно.
Это промежуточное ПО добавляется с помощью метода расширения UseRequestDecompression в IApplicationBuilder и метода расширения AddRequestDecompression в IServiceCollection.
Поддерживаются Brotli (br), Deflate (deflate) и GZip (gzip). Другие кодировки можно добавить, зарегистрировав собственный класс поставщика распаковки, который реализует интерфейс IDecompressionProvider вместе со значением заголовка Content-Encoding в RequestDecompressionOptions.

2. Промежуточное ПО для кэширования вывода
Помогает вам сохранять результаты вашего веб-приложения и обслуживать их из кэша, а не вычислять их каждый раз, что повышает производительность и высвобождает ресурсы для других действий.
Используйте метод расширения AddOutputCache в IServiceCollection и метод расширения UseOutputCache в IApplicationBuilder. После можно настроить кэширование на конечных точках:

app.MapGet("/notcached", 
  () => DateTime.Now.ToString());
app.MapGet("/cached", 
  () => DateTime.Now.ToString()).CacheOutput();

Запросы к /notcached вернут текущее время. А каждый запрос к /cached после первого будет возвращать кешированный ответ.
Существует множество более продвинутых способов:
- по параметру строки запроса

….CacheOutput(p => p.VaryByQuery("culture"));

- по заголовкам (VaryByHeader)
- по произвольному значению (VaryByValue).

Промежуточное ПО кэширования имеет встроенную защиту от некоторых распространённых ошибок. Например, при инвалидации значения кэша только первый запрос будет вызывать серверный код получения значения. Остальные запросы в это время будут ждать появления значения в кэше, чтобы не перегружать сервер избыточной работой. Вот здесь есть пример использования кэширования.

3. Обновления промежуточного ПО ограничений
Промежуточное ПО ограничений (rate limiting) теперь поддерживает ограничения на определённых конечных точках, которое можно комбинировать с глобальным ограничителем, работающим для всех запросов. Также теперь поддерживается добавление пользовательских политик ограничений с помощью новых методов AddPolicy в RateLimiterOptions.
Подробнее об ограничениях в этом посте (см. пункт 4).

4. Поддержка WebSockets через HTTP/2 в Kestrel
Использование WebSockets через HTTP/2 позволяет использовать преимущества новых функций, таких как сжатие заголовков и мультиплексирование, которые сокращают время и ресурсы, необходимые при выполнении нескольких запросов к серверу. Эта поддержка теперь доступна в Kestrel на всех платформах с поддержкой HTTP/2.
Согласование версии HTTP выполняется автоматически в браузерах и Kestrel. Вы можете использовать существующие примеры для ASP.NET Core.
Примечание: WebSockets в HTTP/2 использует запросы CONNECT, а не GET, поэтому ваши маршруты и контроллеры возможно придётся обновить.

5. Улучшения производительности Kestrel на многоядерных компьютерах
Разделение ConcurrentQueue, используемой в Kestrel, по связанному с ней сокету уменьшает конкуренцию и увеличивает пропускную способность на машинах с большим количеством ядер. В превью 6 пул памяти Kestrel теперь разделён так же, как и очередь ввода-вывода. Наблюдалось более чем 500% улучшение RPS в тестах TechEmpower на 80-ядерных виртуальных машинах ARM64 (доступных теперь в Azure) и почти 100-процентное улучшение на 48-ядерных виртуальных машинах AMD в тесте HTTPS JSON.

Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-6/