День 2255. #ЧтоНовенького
AutoMapper и MediatR Станут Коммерческими

🔥 BRKNG!!! 🔥

В рядах бесплатного опенсорса на очереди ещё 2 потери. Джимми Богард объявил, что два его самых популярных творения AutoMapper и MediatR станут коммерческими.

Далее перевод поста от самого Джимми.

Как я до этого дошёл
Эти два проекта зародились, когда я работал в Headspring, консалтинговой компании, которой я отдал более 12 лет. Около 5 лет назад, в январе 2020, я решил уйти и попробовать себя в качестве индивидуального консультанта. Хотя это был пугающий переход, он оказался более полезным, чем я мог надеяться, почти во всех областях.

Область, в которой не всё было так хорошо, и совсем не намеренно, была работа с проектами с открытым кодом (OSS). В определённый момент количество моих контрибуций резко снизилось. Это не было намерением, но стало естественным побочным эффектом того, что я сосредоточился на своём консалтинговом бизнесе.

В Headspring моё время на OSS напрямую поощрялось и спонсировалось ими. Я мог использовать время между проектами, чтобы инвестировать в существующие или новые OSS, потому что это приносило пользу клиенту, компании и сотрудникам (мне и моим коллегам).

С уходом из этой компании, а затем после её продажи Accenture в том же году, у меня больше не было прямого крупного спонсора моей работы над OSS. Моё свободное время уходило на развитие и обеспечение успеха моей консалтинговой компании.

Уделив время, чтобы посмотреть, как идут дела на всех фронтах, я испытал небольшой шок, глядя на свою работу над OSS. Я понял, что эта модель не является устойчивой для долгосрочного успеха проектов, которые я по-прежнему поддерживаю и в которые верю. Мне нужно иметь возможность платить за своё время работы над этими проектами и получать прямую обратную связь от платящих клиентов, как это было раньше в Headspring.

Как это будет выглядеть?
Я точно не знаю. Сейчас я работаю над этими деталями и поделюсь ими, когда разберусь. У меня есть много примеров того, что работает хорошо, а что нет, по крайней мере с моей точки зрения, а также того, что, по моему мнению, будет хорошо работать для этих проектов.

В краткосрочной перспективе ничего не изменится. Я по-прежнему буду мало отзывчивым в GitHub Issues, я только что выпустил пару релизов текущей работы.

Моя цель — иметь возможность платить за время, которое можно потратить на фактическое улучшение этих проектов, создание сообществ, помощь большему количеству пользователей и, в целом, на то, что люди МНОГО раз просили меня сделать за эти годы, но я этого не делал, потому что это не было моей работой. OSS был, есть, но больше не будет для меня хобби. Я хочу, чтобы это хотя бы стало частью моей работы и финансировало настоящую работу.

Я не могу полагаться на донаты, я не хочу заставлять разработчиков платить что-либо или делать что-либо и я определенно не думаю, что это дело Microsoft — «платить мне деньги». <…>

Когда это произойдет?
Я не знаю. Я всё ещё использую своё свободное время, чтобы разобраться с этим, так как моя основная работа — всё ещё консультации. Но я планирую быть открытым во всём этом процессе. <…>

<…> Я не хочу, чтобы эти проекты завяли и умерли, я хочу, чтобы они росли, развивались и процветали. Но не только эти проекты — я хочу, чтобы ВСЕ мои проекты OSS (Respawn и т.д.) процветали.

Заключительные благодарности
Спасибо всем, кто внёс свой вклад за эти годы, и особенно Лучиану Баргаоану, который поддерживал AutoMapper после того, как я «выпал из игры». Также спасибо моим спонсорам на GitHub. И, наконец, спасибо сообществу, я никогда не надеялся, что что-то из того, что я создал, поможет кому-то, кроме моих клиентов, коллег и компании, но всегда приятно слышать, что это так.

UPD: MassTransit 9й версии тоже будет коммерческим.

Источник: https://www.jimmybogard.com/automapper-and-mediatr-going-commercial/

День 2256. #ЗаметкиНаПолях
Теорема CAP: Сложности Выбора в Распределённых Системах
Теорема CAP, сформулированная Эриком Брюэром в 2000 году и позже доказанная формально, гласит, что в распределённой системе можно добиться только двух из следующих трёх гарантий:
1. Согласованность (Consistency) — каждое чтение получает самую последнюю запись или ошибку. Это означает, что данные одинаковы во всём кластере, поэтому вы можете читать или писать с любого узла и получать те же данные.
2. Доступность (Availability) — каждый запрос получает ответ, даже если это не самые последние данные. Т.е. система остаётся доступной даже в случае отказа одного или нескольких узлов.
3. Устойчивость к фрагментации (Partition tolerance) — система продолжает функционировать, даже если между узлами происходит фрагментация сети (разрыв связи). Кластер должен по-прежнему отвечать, даже если некоторые узлы не могут общаться.

Почему нельзя иметь всё?
Распределённая система по своей сути нуждается в устойчивости к фрагментации, поскольку сети могут выходить из строя, а узлы могут терять связь. Это оставляет нам два варианта:
- CP (согласованность + устойчивость к фрагментации): система жертвует доступностью. Если происходит разделение, узлы могут отклонять операции чтения/записи для поддержания согласованного состояния. Пример: MongoDB
- AP (доступность + устойчивость к фрагментации): система жертвует строгой согласованностью, то есть она может обслуживать устаревшие или несогласованные данные во время фрагментации. Пример: Cassandra
- CA (согласованность + доступность): возможно только в системе без фрагментаций — по сути, в базе данных с одним узлом. Пример: PostgreSQL

Почему устойчивость к фрагментации не подлежит обсуждению?
Разрывы сети будут происходить, поэтому мы всегда должны учитывать устойчивость к фрагментации (P). Поэтому реальный выбор — между согласованностью (CP) и доступностью (AP) во время фрагментации:
- AP, узлы остаются в сети, даже если они не могут взаимодействовать друг с другом. Они повторно синхронизируют данные после разрешения фрагментации, но данные между узлами могут быть несогласованными.
- CP, данные остаются согласованными между всеми узлами, но некоторые узлы могут стать недоступными во время фрагментации.

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

За пределами CAP: теорема PACELC
CAP рассказывает нам о компромиссах во время фрагментации сети, но что происходит, когда её нет? PACELC гласит:
- Если есть фрагментация (P), система должна выбрать между доступностью (A) и согласованностью (C).
- В противном случае (Else) система должна выбирать между задержкой (L) и согласованностью (C).
Это расширяет CAP, учитывая производительность и объясняя, почему базы данных, такие как DynamoDB, предпочитают меньшую задержку строгой согласованности.

Выбор правильной БД для вашего варианта использования
- Нужна ли мне сильная согласованность (CP) или можно допустить некоторую несогласованность (AP)?
- Насколько критична доступность для приложения?
- Что произойдёт, если части системы временно отключатся?

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

Источник: https://dev.to/lovestaco/understanding-the-cap-theorem-choosing-your-battles-in-distributed-systems-26cl

День 2258. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 47. Не поддавайтесь уговорам руководителя или клиента сделать работу наспех

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

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

Спешка в программировании
Предположим, у вашей команды появляется новый проект. Ваши партнёры по бизнесу могут попытаться потребовать немедленно приступить к программированию, не имея экономического обоснования и чётких требований. Возможно, у них выделены финансы на проект, которые они хотят быстрее потратить, прежде чем потеряют их. IT-персонал тоже может испытывать желание как можно быстрее приступить к работе. Разработчики могут не захотеть тратить время на обсуждение требований, поскольку те, скорее всего, все равно изменятся.
В таких случаях пишется много бесцельного кода, а результат неясен. Слишком часто никто не несёт ответственности за отсутствие цели, поскольку она всё равно не была чётко определена. Не лучше ли IT-отделу попытаться противостоять давлению со стороны бизнеса и не «идти туда, не знаю куда»?

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

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

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.

День 2259. #ЗаметкиНаПолях
Почему GraphQL? Начало
Недавно мы коротко сравнили REST с GraphQL. Теперь подробно рассмотрим, почему существует GraphQL и когда его использовать.

GraphQL (создан Facebook в 2012, код открыт в 2015) предназначен для решения распространённых проблем неэффективности REST API.

Особенности:
- Точная выборка данных: клиенты указывают, какие данные им нужны, что снижает избыточную (получение слишком большого количества данных) и недостаточную (недостаточное количество данных) выборку.
- Единая конечная точка: в отличие от REST, который часто требует нескольких запросов к разным конечным точкам, GraphQL объединяет данные из нескольких источников в одном запросе.
- Строго типизированная схема: API самодокументируются с чётко определённой схемой, которая обеспечивает стабильность и предсказуемость.
- Данные в реальном времени: поддерживает подписки на обновления в реальном времени.
- Агрегация данных: легко объединяет данные из нескольких источников в один ответ.

Это приводит к более быстрым приложениям, более простому обслуживанию и в целом лучшему опыту разработчика.

Когда использовать?
1. Оптимизация производительности для мобильных и веб-приложений
- Никакой избыточной или недостаточной выборки.
- Более быстрое время загрузки: повышает производительность, особенно для мобильных приложений и сред с низкой пропускной способностью.

2. Панели мониторинга в реальном времени
GraphQL поддерживает подписки, которые позволяют клиентам получать обновления в реальном времени при изменении данных. Это идеально подходит для таких приложений, как чаты, панели мониторинга в реальном времени или уведомления.

3. Агрегация и управление версиями API
Вместо того, чтобы использовать различные конечные точки REST или параметры запросов, вы можете предоставить один API GraphQL, который извлекает данные из различных сервисов. Вы можете развивать схемы, не нарушая существующих клиентов, в отличие от строгого управления версиями в REST.

4. Опыт разработчика
- Самодокументирование: схема GraphQL действует как документация, упрощая разработчикам понимание и использование API.
- Мощные инструменты: такие инструменты, как Apollo Client и GraphiQL, обеспечивают превосходный опыт разработчика, включая автоматическое завершение, подсветку ошибок и тестирование запросов.

Ключевые отличия от REST
1. Получение данных
Одна общая конечная точка, в отличие от нескольких в REST.
2. Производительность
Один запрос GraphQL для получения всех данных снижает нагрузку на сеть.
3. Кэширование
В REST встроенный механизм HTTP-кэширования. В GraphQL такого нет, но можно использовать сторонние библиотеки (Apollo, Relay).
4. Схема
Строго типизированная, самодокументирующаяся схема.
5. Порог изучения
Более высокий, чем REST из-за уникальных концепций и языка запросов.
6. Загрузка файлов
Не поддерживается нативно, как в REST, требует обходных путей.
7. Обновления в реальном времени
Встроенная поддержка через подписки, в отличие от REST, где требуются дополнительные шаги, например, WebSockets.
8. Развитие API
Схема может меняться, не нарушая клиентов. В REST требуется версионирование.

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

Источник: https://dev.to/lovestaco/why-graphql-a-developer-friendly-guide-to-api-evolution-51j5

День 2260. #ЗаметкиНаПолях
Почему GraphQL? Окончание
Начало

Схема
Схема GraphQL определяет, какие данные могут запрашивать клиенты. Она служит контрактом между клиентом и сервером, гарантируя структурированный и эффективный поиск данных. Схемы обычно пишутся с использованием языка определения схем (SDL), что делает их простыми для чтения и понимания. Схема состоит из типов объектов, каждый из которых содержит поля, определяющие, какие данные доступны, например:

type Query {
  user(id: ID!): User
}

type User {
  name: String
  email: String
  bio: String
  posts(limit: Int): [Post]
  followersCount: Int
}

type Post {
  title: String
  content: String
}

Здесь:
- Query определяет доступные запросы.
- Тип User содержит такие поля, как имя, email, посты и количество подписчиков.
- Тип Post включает заголовок и тело поста.

Операции
1. Запросы
Запросы GraphQL эквивалентны запросам REST GET — они извлекают данные, не изменяя их.

2. Мутации
Мутации позволяют клиентам создавать, обновлять или удалять данные, аналогично методам REST: POST, PUT, PATCH, DELETE. Например:

mutation {
  updateUser(id: "123", bio: "Exploring GraphQL!") {
    name
    bio
  }
}

3. Подписки
Подписки GraphQL позволяют обновлять данные в режиме реального времени с помощью WebSockets. В отличие от запросов, которые требуют ручного опроса, подписки отправляют обновления при изменении данных:

subscription {
  newPost {
    title
    content
  }
}

Это позволяет обновлять клиента без выполнения повторных запросов.

Когда использовать REST?
- Простые API: если у API простые требования к данным, простота REST может быть более подходящей.
- Потребности в кэшировании: встроенное HTTP-кэширование REST более надежно, чем сторонние решения GraphQL.
- Загрузка файлов: REST изначально поддерживает загрузку файлов, в то время как GraphQL требует дополнительной настройки.
- Устаревшие системы: если вы работаете с существующим REST API, переход на GraphQL может не стоить усилий, если на то нет веской причины.

Итого
GraphQL предлагает современную альтернативу REST, позволяя клиентам получать именно то, что им нужно, из одной конечной точки. Это приводит к более быстрым приложениям, более простому обслуживанию и лучшему опыту разработки. Однако GraphQL требует обучения и внесения изменений в бэкэнд, поэтому важно оценить, подходит ли он для ваших потребностей API.

Источник: https://dev.to/lovestaco/why-graphql-a-developer-friendly-guide-to-api-evolution-51j5

День 2261. #SystemDesign101
Как работает gRPC?
RPC (Remote Procedure Call – Удалённый Вызов Процедур) называется «удалённым», потому что он обеспечивает связь между удалёнными сервисами, когда они развёрнуты на разных серверах в архитектуре микросервисов. С точки зрения клиента он действует как локальный вызов функции.

На схеме выше показан поток данных для gRPC.
1. Выполняется REST-запрос от клиента. Тело запроса обычно имеет формат JSON.

2–4. Сервис заказов (клиент gRPC) получает REST-запрос, преобразует его и выполняет вызов RPC к сервису платежей. gPRC кодирует заглушку клиента в двоичный формат и отправляет её на низкоуровневый транспортный уровень.

5. gRPC отправляет пакеты по сети через HTTP2. Благодаря двоичному кодированию и сетевой оптимизации gRPC примерно в 5 раз быстрее JSON.

6–8. Сервис платежей (сервер gRPC) получает пакеты из сети, декодирует их и вызывает серверное приложение.

9–11. Результат возвращается из серверного приложения, кодируется и отправляется на транспортный уровень.

12–14. Сервис заказов получает пакеты, декодирует их и отправляет результат клиентскому приложению.

Источник: https://github.com/ByteByteGoHq/system-design-101

День 2262. #TipsAndTricks
Применяем Естественную Сортировку в PowerShell
PowerShell не предоставляет встроенного способа использовать естественную сортировку. Рассмотрим, как это можно сделать при помощи простого скрипта.

Что такое естественная сортировка?
Естественная сортировка упорядочивает строки таким образом, чтобы это было более удобно для человека. Например, естественная сортировка следующих строк:

file1.txt
file10.txt
file2.txt

выдаст:

file1.txt
file2.txt
file10.txt

Как видите, естественная сортировка упорядочивает строки на основе чисел в строке, а не лексикографического порядка символов.

Простой способ получить естественную сортировку в PowerShell — использовать командлет Sort-Object с пользовательским блоком скрипта. Блок скрипта должен возвращать значение, по которому вы хотите выполнить сортировку. В этом случае вы можете использовать регулярное выражение для извлечения числового значения из строки и дополнить его нулями, чтобы гарантировать правильную сортировку чисел. Например, строка file1.txt будет преобразована в file00001.txt. Вы можете использовать столько нулей, сколько вам нужно, чтобы гарантировать правильную сортировку чисел.

Get-ChildItem | Sort-Object { [regex]::Replace($_.Name, '\d+', { $args[0].Value.PadLeft(100) }) }

Кстати, возможность естественной сортировки строк появится в .NET 10 с помощью нового компаратора строк.

Источник: https://www.meziantou.net/how-to-use-a-natural-sort-in-powershell.htm

День 2263. #SystemDesign
Нельзя Реализовать Доставку Ровно-Один-Раз
Люди часто имеют фундаментальные заблуждения о том, как ведут себя распределённые системы. Например, в распределённой системе вы не можете иметь доставку сообщения ровно-один-раз (exact-once). Браузер и сервер, сервер и БД, сервер и очередь сообщений - это распределённые системы. Невозможно реализовать семантику доставки exact-once ни в одной из них.

Существует три типа семантики доставки:
- максимум-раз (at-most-once),
- хотя-бы-раз (at-least-once)
- только-раз (exact-once).
Первые два осуществимы и широко используются.

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

Атомарные протоколы вещания гарантируют надёжную и упорядоченную доставку сообщений. Но мы не можем доставлять сообщения надёжно и упорядоченно из-за разрывов сети и сбоев без высокой степени координации. Эта координация имеет свою цену (задержка и доступность), при этом всё ещё полагаясь на семантику at-least-once.

Репликация состояний стейт-машины — хороший пример. Изменения состояния идемпотентны, и многократное применение одного и того же изменения состояния не приводит к несоответствиям, пока порядок применения соответствует порядку доставки. Т.е. гарантия семантики at-least-once достаточна и упрощает реализацию. Но, если у наших сообщений есть побочные эффекты, всё пропало.

Есть несколько вариантов отправки подтверждения получателем:
1. Перед обработкой
Отправитель получает подтверждение, и удаляет (отмечает доставленным) сообщение. Но, если получатель выходит из строя до или во время обработки, данные теряются навсегда. Это семантика доставки at-most-once.
2. После обработки
Если процесс сбоит после обработки сообщения, но до доставки подтверждения, отправитель выполнит повторную доставку. Это доставка at-least-once.

RabbitMQ пытается предоставить такие гарантии:
При использовании подтверждений производители, восстанавливающиеся после сбоя канала или соединения, должны повторно передавать любые сообщения, для которых не было получено подтверждение от брокера. Здесь существует вероятность дублирования сообщений, поскольку брокер мог отправить подтверждение, которое не достигло производителя (из-за сбоев сети и т.п.). Поэтому приложениям-потребителям необходимо будет выполнять дедупликацию или обрабатывать входящие сообщения идемпотентным образом.

На практике мы достигаем доставки exact-once, подделывая её. Либо сами сообщения должны быть идемпотентными, то есть их можно применять более одного раза без неблагоприятных последствий, либо мы устраняем необходимость в идемпотентности посредством дедупликации (проверяя, получали ли мы такое сообщение ранее). Идеально - если наши сообщения не требуют строгого упорядочения.

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

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

Источник: https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

День 2265. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 47. Стремитесь к тому, чтобы дефект нашли коллеги, а не покупатели

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

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

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

Разновидности ревью ПО
1. Проверка коллегой. Попросите одного из коллег просмотреть ваш код и внести предложения по улучшению или исправлению.

2. Круговое обсуждение. Передайте фрагмент своей работы нескольким коллегам и попросите каждого написать отзыв.

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

4. Командный обзор. Автор заранее передаёт продукт и вспомогательные материалы нескольким рецензентам, чтобы у них было время изучить его и обозначить любые проблемы. Во время встречи рецензенты высказывают замечания.

5. Инспекция. Наиболее формальный тип подразумевает участие нескольких персонажей: автор, ведущий (модератор), секретарь, инспектор и т.п. Лучше всего подходит для рецензирования продуктов с повышенным риском.

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

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

Рекомендации для отзывов:
- сосредоточьтесь на продукте, а не на авторе;
- формулируйте комментарии как замечания, а не обвинения;
- сосредоточьтесь на содержании недостатков, а не на стиле;
- если вы автор, отбросьте своё эго и будьте более восприимчивы к предложениям по улучшению.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.

День 2266. #ЧтоНовенького
Анализ Использования CPU Несколькими Процессами в Visual Studio
Инструмент использования CPU и профилировщик Visual Studio теперь поддерживают анализ нескольких процессов в едином представлении об активности CPU по всем процессам.

Анализ использования CPU для приложений по нескольким процессам традиционно был сложной задачей. Выявление узких мест производительности с несколькими процессами требует ручной корреляции данных по отдельным представлениям, что тормозит работу по оптимизации. Благодаря этому улучшению Visual Studio напрямую решает эти проблемы.

Новый инструментарий теперь предлагает:
- Использование CPU по процессам: диаграммы с областями и чёткими цветными дорожками позволяют легко увидеть использование CPU по всем процессам.
- Представление нескольких процессов в подробных представлениях, таких как вызывающий/вызываемый, дерево вызовов, функции, модули и график Flame.
- Чёткая идентификация процессов: мгновенно определяйте, какие процессы потребляют больше всего ресурсов.
- Фильтр процессов: опция фильтрации графиков и подробного представления, расположена в верхнем левом углу страницы сводки, позволяет сосредоточиться на отдельных процессах, важных для вашего сеанса профилирования.
- Повышенная эффективность диагностики: быстрее выявляйте проблемы между процессами с помощью унифицированного, оптимизированного представления.

Видео в хорошем качестве

Источник: https://devblogs.microsoft.com/visualstudio/multi-process-cpu-usage-analysis-in-visual-studio/

День 2267. #SystemDesign101
Что Такое Веб-Хук?
Допустим, мы управляем сайтом электронной коммерции. Клиенты отправляют заказы в сервис заказов через API-шлюз, а потом попадают в сервис платежей службу для платёжных транзакций. Сервис платежей обращается к внешнему поставщику платёжных услуг (PSP) для завершения транзакций.

Существует два способа общения с внешним PSP.

1. Поллинг (polling)
После отправки платёжного запроса в PSP сервис платежей постоянно опрашивает PSP о статусе платежа. Рано или поздно PSP вернёт статус.
Недостатки:
- Требует ресурсов от сервиса платежей.
- Прямое взаимодействие сервиса платежей с внешним поставщиком услуг создаёт уязвимости безопасности.

2. Веб-хук (webhook)
Мы можем зарегистрировать веб-хук во внешнем сервисе. Это означает: вызовите определённый мной URL, когда у вас появятся обновления по запросу. Когда PSP завершит обработку, он сделает HTTP-запрос для обновления статуса платежа.

Платёжному сервису больше не нужно тратить ресурсы на опрос статуса платежа.

Что, если PSP не вызовет URL? Можем настроить задание для проверки статуса платежа каждый час.

Веб-хуки часто называют обратными API или push-API, потому что сервер отправляет HTTP-запросы клиенту. При использовании веб-хука нужно обратить внимание на 3 вещи:
- Разработать правильный API для вызова внешнего сервиса.
- Настроить правила в API-шлюзе из соображений безопасности.
- Зарегистрировать правильный URL обратного вызова во внешнем сервисе.

Что использовать?
Поллинг — надёжный вариант, когда есть некоторые инфраструктурные ограничения, которые не позволяют использовать веб-хуки. Кроме того, при использовании веб-хуки существует риск пропуска уведомлений из-за проблем с сетью, поэтому необходимы надлежащие механизмы повторных попыток.

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

Источник: https://github.com/ByteByteGoHq/system-design-101

День 2268. #Книги
«System Design. Подготовка к сложному интервью» (Сюй А. — СПб.: Питер, 2025).

Я недавно писал о своей практике прохождения собеседований. В частности, отметил, что в последнее время очень много вопросов задают про распределённые системы, особенности их работы, а некоторые и предлагают создать «простенькую» систему прямо на собеседовании. Так вот, если у вас не было практики прохождения таких интервью, то «кабанчик» конечно заложит базу, но практическое задание вы скорее всего провалите.

Поможет вам книга Алекса Сюй «System Design». Она правильно названа «руководством», потому что призвана именно научить вас проходить практические интервью по архитектуре. Описаны общие принципы прохождения интервью: что делать по шагам, чего не делать, сколько времени это занимает и чего от вас ждут. А также представлены 11 примеров проектирования реальных систем от ограничителя трафика до ленты новостей и аналога YouTube, которые могут послужить отличной шпаргалкой на будущее, если вы таки получите работу и вам придётся что-то подобное проектировать.

Книга читается удивительно легко, изобилует картинками и схемами, поэтому материал усваивается прекрасно. Хотя базовые понятия распределённых систем всё-таки описаны довольно сжато, поэтому теорию придётся изучить отдельно. Но в конце каждой главы есть список источников (некоторые из них русскоязычные), если вы захотите углубиться в изучение какого-то понятия или инструмента.

В общем, отнесу к категории мастрид для прохождения современных техсобесов.

Кстати, книга была разобрана во втором сезоне книжного клуба DotNet.

Кроме того, недавно в открытый доступ выложили доклад Андрея и Дениса Цветцих «System Design Interview», где они также «разыгрывают» типичный собес.

День 2269. #ЧтоНовенького #CSharp14
Члены-Расширения
Типы-расширения хотели добавить ещё в .NET 9, но что-то пошло не так, и их релиз отложили. Теперь они вышли в третьем превью .NET 10. Пока поддерживаются статические методы, свойства экземпляров и статические свойства. Поддержка будет расширена в будущих превью.

Сегодня у вас может быть метод расширения вроде следующего:

public static class Extensions
{
  public static IEnumerable<int> 
   WhereGreaterThan(
    this IEnumerable<int> source,
    int threshold)
   => source.Where(x => x > threshold);
}

Расширяемый класс (интерфейс) — это параметр, которому предшествует ключевое слово this. В этом случае - source. Расширения были доступны только для методов.

C# 14 вводит блоки-расширения. Это блоки с областью действия, добавляющей классу(интерфейсу)-получателю члены, которые в ней содержатся. Метод расширения WhereGreaterThan в новом синтаксисе, а также свойство-расширения IsEmpty будут выглядеть так:

public static class Extensions
{
  extension(IEnumerable<int> source)
  {
    public IEnumerable<int> 
     WhereGreaterThan(int threshold)
       => source.Where(x => x > threshold);

    public bool IsEmpty
       => !source.Any();
  }
}

Чтобы использовать члены-расширения, просто вызовите их:

List<int> list = [1, 2, 3, 4, 5];
var large = list.WhereGreaterThan(3);
if (large.IsEmpty)
  Console.WriteLine("Нет чисел >3");
else
  Console.WriteLine("Есть числа >3");

Поддерживаются дженерики, а правила разрешения такие же, как и для методов расширения. Например, можно сделать WhereGreaterThan и IsEmpty дженериками:

extension<T>(IEnumerable<T> source)
 where T : INumber<T>
{
  public IEnumerable<T> 
   WhereGreaterThan(T threshold)
    => source.Where(x => x > threshold);

  public bool IsEmpty
    => !source.Any();
}

Ограничение INumber<T> позволяет нам использовать оператор «больше».

Статические методы и свойства не имеют получателя, поэтому блок-расширение может использоваться без имени параметра:

extension<T>(List<T>)
{
  public static List<T> Create() => [];
}

Блоки-расширения могут легко сосуществовать с методами расширения, которые у вас есть сегодня. Нет необходимости переключаться на новый синтаксис — оба выполняются одинаково. Просто добавьте блоки-расширения в статические классы, которые содержат ваши существующие методы расширения.

В будущих превью обещают больше видов расширений. А пока можете попробовать эти и оставить отзывы в обсуждении на GitHub.

Источник: https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview3/csharp.md#extension-members

День 2270. #Карьера
Почему Синдром Самозванца - Часть Пути Каждого Разработчика?
Вы когда-нибудь чувствовали, что просто притворяетесь разработчиком? Что в любой момент кто-то может разоблачить вас и уличить в том, что вы недостаточно хороши?

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

Ежедневно забываете синтаксис, делаете ошибки так часто, как будто они входят в ваши должностные инструкции… мы все так делаем.

И как можно не делать этого?

Со всей информацией, которую мы постоянно узнаём, и бесчисленными часами, потраченными на отладку, возможно ли ожидать, что мы запомним всё?

Каждый год фреймворки развиваются, появляются новые технологии, меняются требования к проекту. Это постоянная кривая обучения, и это ощущение самозванца — всего лишь часть процесса.

Когда у вас возникают такие мысли, как «Я не знаю, имеет ли смысл то, что я делаю» или «Я чувствую, что застрял на этой проблеме» выберите практичный подход. Разбейте проблему на более мелкие.

Если вы считаете, что вам нужно стать лучше, как разработчик, спросите себя: что на самом деле означает «лучше»?

Если вы новичок:
- Выберите область, на которой вы хотите сосредоточиться (веб-разработка, мобильные приложения, игры и т. д.).
- Выберите правильный язык программирования.
- Найдите дорожную карту и придерживайтесь её.

Если вы уже работаете над чем-то и чувствуете, что недостаточно хороши.
- Выясните, что именно доставляет вам проблемы: работа с БД, развёртывание, логика, архитектура?
- Поработайте над вашими конкретными недостатками.

Это гораздо меньше обескураживает — и определённо меньше угнетает. Ставит перед вами конкретные цели и конкретные пути их достижения.

Поэтому, если вы можете писать код, совершать ошибки, гуглить решение и начинать заново — вы делаете именно то, что делаем мы все. Вы не только становитесь лучше в гуглении (что, кстати, является настоящим навыком), но, что ещё важнее, вы растёте как разработчик.

Источник: https://dev.to/web_dev-usman/why-imposter-syndrome-is-part-of-every-developers-journey-2c0p

День 2271. #TipsAndTricks #Blazor
Пользовательская Страница 404 в Blazor
Иногда нужно иметь пользовательскую (дружелюбную к посетителю) страницу 404. Начиная с .NET 8 в Blazor Web App тег <NotFound> маршрутизатора (Router) больше не работает, поэтому создадим собственную страницу.

До Blazor Web App
Раньше можно было использовать следующий код внутри компонента маршрутизатора:

<Router AppAssembly="@typeof(Program).Assembly">
  <Found Context="routeData">
    <AuthorizeRouteView RouteData="@routeData"
     DefaultLayout="@typeof(MainLayout)"/>
  </Found>
  <NotFound>
    <LayoutView Layout="@typeof(MainLayout)">
     <p>Здесь идёт код, отображающийся когда страница не найдена.</p>
    </LayoutView>
  </NotFound>
</Router>

Это всё ещё будет работать со «старым» подходом, где вы выбираете либо Blazor WebAssembly, либо Blazor Server (с использованием файла <script src="_framework/blazor.server.js"></script>). Но в новых шаблонах веб-приложения Blazor это больше не работает. Вы всё ещё можете добавить дочерний элемент NotFound в разметку маршрутизатора, но он не будет использоваться. Всё потому, что сам маршрутизатор теперь другой. Новый шаблон проекта использует файл <script src="_framework/blazor.web.js"></script> в App.razor и имеет AddInteractiveServerComponents в контейнере сервисов.

Добавление страницы «не найдено»
Мы можем определить веб-страницу, которая будет отображаться с более низкой специфичностью, т.е. иметь наименьший приоритет. Назовём её NotFoundPage.razor:

@page "/{*route:nonfile}"

<p>Здесь идёт код, отображающийся когда страница не найдена.</p>

@code {
  [Parameter]
  public string? Route { get; set; }
}

Параметр Route не используется, но он обязателен. В противном случае Blazor выбросит исключение, что он не может связать маршрут со свойством.

Источник: https://steven-giesel.com/blogPost/38a4f1dc-420f-4489-9179-77371a79b9a9/a-custom-404-page-in-blazor-web-apps