День 1205. #ЗаметкиНаПолях
Профессиональное Документирование Кода
Все мы (надеюсь) документируем свои классы и методы с помощью XML комментариев <summary>, которые можно добавить с помощью тройного слеша (///) над заголовком метода/класса. Однако далеко не все используют все возможности этой документации, редко выходя за описание собственно элемента, параметров в <param> и возврата в <returns>. Вот некоторые полезные теги, позволяющие сделать подсказки более информативными.

1. Секция <remarks>
Добавит новый абзац текста после текста описания в summary, в котором можно указать дополнительную информацию. Кстати, можно добавить только один блок <remarks>, остальные просто игнорируются. Однако можно разделить текст внутри <remarks> на параграфы с помощью тега <para>.

2. Секция <exception>
Позволяет описать исключения, которые может выбросить метод:

<exception cref="класс">описание</exception>

Класс исключения должен быть доступен из текущего кода при компиляции.

3. Тег <inheritdoc/>
Позволяет унаследовать описание из другого элемента (класса, интерфейса или метода).
- <inheritdoc/> для класса наследует все описания всех членов.
- <inheritdoc cref="сигнатура"/> - позволяет указать, из какого члена унаследовать описание. Существующие теги на текущем члене не будут перезаписаны.
- <inheritdoc [cref=""] path="путь"/> - позволяет указать путь XPath к тегам, которые нужно унаследовать. Таким образом можно отфильтровывать ненужные или только нужные теги.

4. Тег <paramref/>
Позволяет в описании сослаться на параметр метода, выделив его в тексте: <paramref name="параметр"/>.

5. Тег <see/>
Позволяет добавить ссылку на другой объект или внешний источник в тексте.
- <see cref="сигнатура"/> - ссылка на член или поле, доступное для вызова из текущей среды компиляции.
- <see href="ссылка" /> - кликабельная ссылка на указанный URL. Например, <see href="https://github.com">GitHub</see> создаёт кликабельную ссылку с текстом GitHub, которая ссылается на https://github.com.
- <see langword="слово" /> - ключевое слово языка, например true или одно из других допустимых ключевых слов. Кроме того, правильно отображает ключевое слово в подсказке (например, true в C# и True в VB).

6. Тег <seealso/>
Аналогично тегу <see/> позволяет добавлять кликабельные ссылки на другой объект или внешний источник в секции «См. также». Нельзя использовать внутри <summary>.

7. Тег <include/>
Позволяет ссылаться на комментарии в отдельном файле, описывающие типы и элементы в исходном коде:

<include file='путь к файлу' path='путь к элементу' />

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

Источник: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/recommended-tags

День 1206. #ЗаметкиНаПолях
Упрощаем Работу с Данными
Если вы работаете с двоичными данными и используете byte[], можно упростить себе жизнь, используя класс BinaryData, который представляет собой облегчённую абстракцию для работы с двоичными данными, поддерживающую преобразование между строкой, потоком, JSON и байтами.

Замечание: Чтобы работать с классом BinaryData, нужно установить NuGet пакет System.Memory.Data.

Допустим, у нас есть следующий объект:

record Person(string FirstName, string LastName);
var person = new Person("John", "Smith");

Преобразуем в JSON-строку:

var personData = new BinaryData(person);
Console.WriteLine(personData.ToString());
// Вывод:
// {"FirstName":"John","LastName":"Smith"}

Преобразуем JSON в объект:

var person2 = personData.ToObjectFromJson<Person>();
Console.WriteLine(person2.ToString());
// Вывод (стандартный ToString для типа record):
// Person { FirstName = John, LastName = Smith }

Теперь рассмотрим работу со строками и двоичными данными:

var stringData = new BinaryData("Hello World!");

Преобразуем строку в массив байт:

byte[] bytes = stringData.ToArray();
var bytesData = new BinaryData(bytes);

Преобразуем массив байт в поток:

Stream stream = bytesData.ToStream();

Читаем из потока:

var streamData = BinaryData.FromStream(stream);
Console.WriteLine(streamData.ToString());
// Вывод:
// Hello World!

Источник: https://twitter.com/MarusykRoman/status/1521256457630535680

День 1207. #Карьера
Как Выработать Привычки и Сохранять Мотивацию. Начало
Вам бывало сложно работать над проектом? Бывали моменты, когда ничто не кажется захватывающим? В этом посте обсудим, что делать, когда у вас нет мотивации, и как справиться с прокрастинацией.

Мотивация проявляется по-разному. То как тяга что-то создавать, то как желание заняться спортом, то как просто рвение работать изо всех сил.

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

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

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

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

Как разработчик, подумайте, какие цели вы перед собой поставили? Например:
- На этой неделе: создать функционал для проекта.
- В этом месяце: изучить Blazor.
- В этом квартале: релиз проекта.
- В этом году: овладеть MAUI, выступить на конференции и писать в блог по одному посту каждый месяц.

Теперь подумайте, как разбить эти цели на задачи и к какому сроку вы надеетесь их выполнить. Двигаясь назад от этого дедлайна, посмотрите, какие задачи вы можете выполнить в краткосрочной перспективе для достижения этой цели.

Например:
Цель: создать функционал для проекта.
Срок: 1 неделя с сегодняшнего дня.
Шаги:
1. Исследовать, что необходимо: зависимости, активы, вовлечённые люди.
2. Разбить создание функционала на этапы.
3. Какие есть нерешённые вопросы?
4. Кто может помочь?
График:
День 1: Исследования
Дни 2-3: Разработка + тестирование
День 4: Сквозное тестирование + исправление ошибок.
День 5: Развёртывание в тестовой среде и подготовка к презентации.

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

Далее создайте систему «настройки вашего ментального состояния». Изучите, что вам помогает концентрироваться на выполнении работы и делайте это перед необходимым «периодом концентрации».

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

Источник: https://www.freecodecamp.org/news/create-a-habit-system-and-stay-motivated-as-a-developer/
Автор оригинала: Shruti Kapoor

День 1208. #Карьера
Как Выработать Привычки и Сохранять Мотивацию. Продолжение
Начало

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

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

Как создать настроение
Создайте рабочую атмосферу, которая лучше подойдёт для вас. Здесь важно всё: звуки, запахи, вид.
Звук: звуки офиса, природы, фоновая музыка для работы или любимый плейлист.
Запах: согласитесь, запах еды не очень мотивирует к работе (хотя, кому как, наверное). Поэтому откройте окно, установите ароматизатор воздуха с любимым запахом и т.п. Найдите, что работает в вашем случае.
Вид: я чувствую мотивацию, когда кто-то ещё работает рядом или когда я на природе. Поэтому мой рабочий стол обращён к окну, из которого видны деревья, слышно шелест листьев и щебетание птиц. Либо на YouTube есть видео, где парень тоже работает, что вдохновляет меня на работу. Как вариант, можно пойти в кафе или парк.

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

Как добиться успеха
Если хотите, используйте «помидорный график». Когда всё готово, ставим таймер и начинаем печатать. Печатаем всё, что приходит в голову. Главное не красота контента или кода с первой попытки. Главное для начала – сдвинуть с мёртвой точки, привести всё в движение, заставить ваш разум выплеснуть идеи на страницу (на экран).

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

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

Источник: https://www.freecodecamp.org/news/create-a-habit-system-and-stay-motivated-as-a-developer/
Автор оригинала: Shruti Kapoor

День 1209. #ЗаметкиНаПолях
Полиморфизм в C#: Override и New
В чём разница между созданием виртуального/переопределяемого метода и простым сокрытием метода с помощью ключевого слова new в C#?

Во-первых, в отличие от переопределения, при использовании ключевого слова new вы можете изменить тип возвращаемого значения. Однако, это ещё не всё.

Допустим, у нас есть родительский класс и два потомка. Один потомок использует override, другой – new:

class Parent
{
  public virtual void WhoAmI() =>
    Console.WriteLine("Parent");
}

class Child : Parent
{
  public override void WhoAmI() =>
    Console.WriteLine("Child");
}

class ChildNew : Parent
{
  public new void WhoAmI() =>
    Console.WriteLine("ChildNew");
}

Тогда что выведет следующий код?

Parent child = new Child();
child.WhoAmI();

Parent childNew = new ChildNew();
childNew.WhoAmI();

На первый взгляд кажется, что в обоих случаях случае он выведет одно и то же. В конце концов, в обоих случаях производный тип приводится к родительскому. При таком кастинге важно учитывать, что объект «всегда помнит, кто он». То есть Child можно привести к Parent или даже к object, и он всё равно помнит, что он Child. Так что же выведет код выше?

Child
Parent

Итак, Child с переопределённым методом запомнил, кто он есть, и, следовательно, был вызван тот же метод WhoAmI(), но переопределённый. В случае с ChildNew… это не совсем так. На самом деле, если подумать, объяснение довольно простое. Когда вы используете ключевое слово override, оно переопределяет базовый класс, и между двумя методами существует своего рода «связь». То есть известно, что дочерний член является переопределением базового.

Когда вы используете ключевое слово new, вы говорите, что эти два метода никак не связаны между собой. И что ваш новый метод существует только в дочернем классе, но не в родительском. Между ними нет «связи». Поэтому при приведении к родительскому классу переопределённый метод известен, а «новый» метод — нет.

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

Источник: https://dotnetcoretutorials.com/2022/05/13/override-vs-new-polymorphism-in-c-net/

День 1210. #ЧтоНовенького
Централизованное Управление Пакетами
Управление зависимостями — основная функция NuGet. В одном проекте это может быть просто, а в многопроектных решениях могут возникать трудности. Если вы управляете общими зависимостями для нескольких различных проектов, теперь можно использовать функции централизованного управления пакетами NuGet.

Исторически зависимости пакетов NuGet управлялись в двух основных местах:
- packages.config – XML-файл, используемый в старых типах проектов для хранения списка пакетов, на которые ссылается проект,
- <PackageReference /> — элемент XML, используемый в новых типах проектов, который управляет зависимостями NuGet непосредственно в файлах проекта.

Начиная с NuGet 6.2, вы можете централизованно управлять своими зависимостями в своих проектах, добавив файл Directory.Packages.props. Функционал доступен во всех последних версиях инструментов разработки.

Создайте файл Directory.Packages.props в корне решения и установите ManagePackageVersionsCentrally в true. Далее вы можете определять версии пакетов, необходимых для вашего решения:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.1" />
  </ItemGroup>
</Project>

В проектах решения используйте тот же синтаксис <PackageReference /> для ссылок на пакеты, но без атрибута Version (можно переопределить версию в конкретном проекте с помощью атрибута VersionOverride):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>
</Project>

Для простоты для каждого проекта оценивается только один файл Directory.Packages.props. Если в вашем репозитории их несколько, будет выбран файл, ближайший к каталогу вашего проекта.

Предупреждение
При использовании централизованного управления пакетами вы увидите предупреждение NU1507, если в вашей конфигурации определено более одного источника пакетов. Чтобы это исправить, добавьте файл nuget.config в корень проекта с сопоставлением источников пакетов:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>

  <packageSourceMapping>
    <packageSource key="nuget.org">
      <package pattern="*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

Можно добавить дополнительные источники и конфигурацию при необходимости. См. подробнее тут

Замечание
В Visual Studio 2022 возникает проблема при обновлении пакетов через NuGet Package Manager. После обновления меняется версия пакета в файле .csproj проекта (добавляется атрибут Version="…", вместо обновления его в файле Directory.Packages.props), что приводит к ошибке компиляции. Приходится исправлять это, вручную редактируя оба файла. Надеюсь, в будущем это исправят. Ишью им отправил :)

Источник: https://devblogs.microsoft.com/nuget/introducing-central-package-management/

День 1211. #ЗаметкиНаПолях
SQL Последовательности для Создания Уникальных Значений
Для создания уникального номера, например заказа в системе продаж, вы можете:
- использовать автогенерацию первичного ключа из базы данных,
- выбирать максимальный номер заказа из базы и добавлять единицу,
- использовать свой код, генерирующий уникальные числа.
– использовать SQL-последовательность.

Последовательность (sequence) - простой и эффективный способ создания уникальных упорядоченных значений потокобезопасным способом.

SQL код для создания очень прост:

CREATE SEQUENCE TestSeq
START WITH 1
INCREMENT BY 1

Начальный номер и число инкремента могут быть любыми.
Выбрать следующее значение можно так:

SELECT NEXT VALUE FOR TestSeq

Entity Framework также поддерживает последовательности… ну, более-менее. Создать последовательность можно в OnModelCreating вашего DbContext:

protected override void OnModelCreating(ModelBuilder mb)
{
  mb.HasSequence("TestSeq",
   x => x.StartsAt(1000).IncrementsBy(2));
  …

А вот простого метода получения следующего значения нет. Большинство документации сводится к использованию значения по умолчанию через вот такую конструкцию:

mb.Entity<Order>()
  .Property(o => o.OrderNo)
  .HasDefaultValueSql("NEXT VALUE FOR TestSeq");

Ограничения
При принятии решения об использовании последовательностей, необходимо иметь в виду некоторые их ограничения:
1. Когда вы запрашиваете число, независимо от того, что происходит с этого момента, последовательность увеличивается. Последовательности не являются частью транзакций. Если вы откатите транзакцию с выбранным числом последовательности, это число «потеряется».

2. Последовательности не могут быть «разделены» каким-либо образом. Если вам требуется генерировать уникальные номера в течение года, а с 1 января «сбрасывать» нумерацию, вы не сможете создать заказ «задним числом». 1 января последовательность сбросится, и получить номер для заказа от 31 декабря прошлого года не удастся. Вариант решения – иметь несколько последовательностей на текущий год и несколько предыдущих, в которых ещё требуется продолжать нумерацию.

3. Аналогично если нескольким потребителям требуется отдельная нумерация, для каждого придётся создать свою последовательность.

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

Источник: https://dotnetcoretutorials.com/2022/03/22/using-sql-server-sequences-to-generate-unique-values/

День 1212. #ЗаметкиНаПолях #AsyncTips
Потокобезопасные словари

Задача
Имеется коллекция «ключ/значение» (например, кэш в памяти), которая должна поддерживаться в синхронизированном состоянии, даже если несколько потоков выполняют с ней операции чтения и записи.

Решение
Тип ConcurrentDictionary<TKey, TValue> является потокобезопасным гарантирует быстрый доступ в подавляющем большинстве сценариев. Его API сильно отличается от стандартного типа Dictionary<TKey, TValue>, поскольку он должен иметь дело с конкурентным доступом из многих потоков.

Запись
Чтобы задать значение для ключа, используйте метод AddOrUpdate:

var d = new ConcurrentDictionary<int, string>();
string newValue = d.AddOrUpdate(
  0,
  key => "Zero",
  (key, oldValue) => "Zero"
 );

Метод AddOrUpdate выглядит сложно, так как должен делать несколько вещей в зависимости от текущего содержимого словаря.
Аргументы:
- ключ,
- делегат, преобразующий ключ (в данном случае 0) в значение, которое будет добавлено в словарь (в данном случае "Zero"). Вызывается, только если ключа не существует в словаре.
- делегат, преобразующий ключ (0) и старое значение в обновлённое значение, которое должно быть сохранено в словаре ("Zero"). Вызывается, если ключ уже существует в словаре.
AddOrUpdate возвращает новое значение для этого ключа (значение, которое было возвращено одним из делегатов).

Чтобы конкурентный словарь работал правильно, может оказаться, что метод AddOrUpdate должен вызвать один (или оба) делегата несколько раз. Такое бывает очень редко, но это возможно. А значит, делегаты должны быть простыми и быстрыми и не должны иметь побочных эффектов, т.е. должны только создавать значение, не изменяя никакие другие переменные в приложении.

Добавить значение в словарь можно и через индекс:

// Добавляет (или обновляет) ключ 0, 
// связывая с ним значение "Zero".
d[0] = "Zero";

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

Чтение

bool keyExists = d.TryGetValue(0, out string current);

TryGetValue вернёт true и задаст значение current, если ключ был найден в словаре. Если ключ не найден, TryGetValue вернет false. Прочитать значение можно и через индекс, но при отсутствии ключа будет выдано исключение.

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

Удаление
Аналогично чтению:

bool keyExisted = d.TryRemove(0, out string removed);

Хотя ConcurrentDictionary<TKey, TValue> является потокобезопасным, это не означает атомарности его операций. Если несколько потоков вызывают AddOrUpdate конкурентно, может оказаться, что два потока обнаружат отсутствие ключа, а затем оба одновременно выполнят своего делегата, создающего новое значение.

ConcurrentDictionary<TKey, TValue> хорошо работает при чтении и записи со стороны нескольких потоков в общую коллекцию.
Если обновления относительно редки, возможно, ImmutableDictionary<TKey, TValue> будет более подходящим вариантом.

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

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

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

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

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

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

5. Последующие звонки не ускорят найм
Когда интервью прошло, а работодатель молчит, это неприятно. Хорошая новость, что зачастую ничего личного, и это связано с другими интервью или внутренней бюрократией.
Но не стоит перезванивать или слать email с вопросами. Это не изменит мнение интервьюеров об их решении. Никому не нравится это получать. Ещё никого не принимали после повторного email. Если прошло слишком много времени, просто примите это и двигайтесь дальше. Лучше иметь вариант в запасе.

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

7. Независимо от того, как прошло собеседование, посоветуйтесь с людьми, которые там работают
Никогда не соглашайтесь на работу, не поговорив с будущими коллегами. Это
даст вам гораздо более чёткое представление о корпоративной культуре, чем любой ответ менеджера на собеседовании. Никто не скажет: «Да, я ужасный менеджер.» Но если вы спросите своих потенциальных коллег, и они нелестно отзовутся о менеджере, это будет разницей между походами на работу с удовольствием и подсчитыванием дней до выходных.

Источник: https://www.huffpost.com/entry/unspoken-job-interview-rules-everyone-needs-know_l_627aaa57e4b00fbab634c2bd

День 1214. #Юмор
10 Стереотипных Типов Программистов
Согласно стереотипам, все программисты делятся на 10 типов:

1. Техногик
Всегда в тренде. У него последний мак, огромный кривой монитор, умный дом, которым он управляет со смартфона, и он использует только самый модный на данный момент язык программирования. На его книжной полке руководства по всем бывшим модным языкам, но про них он вспоминать не любит.

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

3. Интроверт
Самый распространённый тип. До сих пор живёт в родительском доме. Локдауна он не заметил, потому что его повседневная жизнь никак не изменилась. Он напишет любую программу, не гугля, зато не сможет поддержать разговор, даже если на кону будет его жизнь.

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

5. Женщина
Редкий вид, особенно учитывая, что на заре программирования женщины доминировали. Кэтлин Бут создала первый ассемблер, Грейс Хоппер – первый компилятор, а Маргарет Хемильтон возглавляла команду, написавшую код посадки Апполона на Луну. Код настолько безупречный, что некоторые приводят это как доказательство фейковости лунной миссии. Этот код был вершиной программирования, с тех пор всё полетело в …

6. Кодфлюенсер
Основное место обитания этого вида – не IDE, а соцсеть (чаще всего твиттер). После того, как кодфлюенсер узнаёт, как написать «Hello World» на PHP, его ЧСВ взлетает до небес, и он спешит поделиться с миром этим сокровенным знанием. Так он делает мир чуточку лучше. А поскольку он профи в умении себя продать, его должность лучше, а ЗП выше, чем у вас. Смиритесь.

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

8. 10x-Инженер
Настоящий единорог среди программистов. Умеет писать код так же быстро, как 10 обычных программистов. Многие считают, что это мифические существа, но некоторые действительно рождаются с даром к решению задач. Если вы встретите такого, вы его узнаете, потому что при общении с ними у вас сразу возникнет чувство собственной некомпетентности и жгучей зависти. Вот тут про них подробнее.

9. Ленивый Богатей
Если вы последите за его работой, то кажется, что всё, что он делает, это копирует код со Stackoverflow. На самом деле он создаёт ПО для многомилионного стартапа, чтобы выйти на пенсию к 30. А ещё у него есть подработка с ЗП в 300КК. При этом он питается дошираком и живёт в однушке с четырьмя такими же как он. Весь его гардероб – футболки с конференций, и то, что ему купила мама.

10. Усталый Старик
Его вы узнаете по седой бороде. Он пишет на C (не C++), и уж точно не использует весь этот ваш хипстерский новомодный мусор. На самом деле, он скорее всего написал компилятор для этого вашего модного игрушечного языка. Глубина его знаний выходит за границы понимания обычных приматов. С помощью психоделиков он узнал, что на самом деле мы все – одна большая сущность, разделённая на множество тел для познания вселенной. А компьютеры – инструмент, который поможет нам снова воссоединиться.

Узнали себя? Давайте посмотрим, кого среди нас больше. Только честно. Не беспокойтесь, опрос ниже анонимный.

Источник: https://youtu.be/_k-F-MMvQV4

День 1215. #ЧтоНовенького
Закрытый Превью Туннелирования Портов в Visual Studio
В Visual Studio 2022 17.3 Preview 1.1 добавлена поддержка туннелирования (переадресации) портов для веб-проектов ASP.NET Core.

Туннелирование портов обеспечивает соединения между машинами, которые не могут напрямую подключаться друг к другу. Вот некоторые варианты использования:
- Разработка API, используемого Power Platform.
- Разработка веб-хука для внешнего сервиса.
- Тестирование веб-приложения на внешнем устройстве.

Чтобы попробовать эту функциональность, выполните следующие действия:
1. Подпишитесь на закрытый превью
Чтобы начать работу, зарегистрируйтесь на превью здесь. Вы должны войти в систему с той же учетной записью, которую вы используете в Visual Studio. Пока туннелирование портов не будет работать без подписки на превью.

2. Загрузите обновление Visual Studio 17.3 Превью 1.1
Вы можете скачать его здесь.

3. Включите предварительный просмотр в Visual Studio
В Visual Studio выберите Инструменты > Параметры > Предварительный просмотр функций (Tools > Options > Preview Features) и установите флажок Включить туннелирование портов для веб-приложений (Enable port tunneling for Web Applications).

4. Настройте свой проект
При разработке проектов ASP.NET Core в Visual Studio параметры запуска приложения хранятся в файле launchSettings.json. Этот файл содержит один или несколько профилей запуска для вашего веб-приложения. Чтобы разрешить создание или подключение туннеля при запуске приложения, добавьте свойство createTunnel: true в профиль запуска. Например:

{
  …
  "profiles": {
    "MyWebApp": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:7130",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "createTunnel": true
    }
  }
}

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

Когда веб-приложение запущено, браузер переходит не на URL локального хоста, а использует URL общедоступного туннеля вида https://<…>tunnels.api.visualstudio.com. Доступ к этому URL возможен извне вашей локальной среды. Вы можете поделиться URL с другом или коллегой, либо перейти на него с внешнего устройства (телефона или планшета). Чтобы упростить это, вы можете сгенерировать QR-код для URL-адреса в браузере Edge (если встать в поле URL в Edge, справа появится иконка для генерации QR-кода) и отсканировать код с телефона или планшета.

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

Среди известных проблем:
- Пока не поддерживаются аккаунты GitHub.
- Если у вас несколько аккаунтов в VS, доступ будет дан первому из них.
- Пока поддерживаются туннели только с анонимной аутентификацией.
- Иногда, когда клиент не следует перенаправлениям, могут возникать ошибки 302.

Источник: https://devblogs.microsoft.com/visualstudio/introducing-private-preview-port-tunneling-visual-studio-for-asp-net-core-projects/

День 1216. #ЗаметкиНаПолях #DesignPatterns
Абстракции в Разработке ПО. Начало
Разработчики ПО имеют дело с абстракциями каждый день. Но что такое абстракция?

Википедия определяет абстракцию, как…
Процесс удаления физических, пространственных или временных деталей или атрибутов при изучении объектов или систем, чтобы сосредоточить внимание на более важных деталях.

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

Когда мы говорим об абстрагировании, мы обычно подразумеваем процесс моделирования путём обобщения и сосредоточения внимания на важных (в данном контексте) деталях, отбрасывая при этом менее важные детали. Когда мы говорим об абстракции, мы имеем в виду артефакты, созданные в процессе моделирования или абстрагирования. Далее поговорим об этих артефактах.

Абстракции в C# и .NET
Многие языки программирования, такие как C#, определяют абстракцию как часть своей системы типов. В рекомендациях по проектированию .NET Framework есть несколько полезных рекомендаций по правильному использованию абстракций (абстрактных типов и интерфейсов), которые включают очень простое определение:
Абстракция — это тип, описывающий контракт, но не обеспечивающий полную реализацию контракта. Абстракции обычно реализуются как абстрактные классы или интерфейсы...

Альтернативой абстракции в C# является конкретный тип. В C# можно изучить любой тип и, на основании возможности создания его непосредственного экземпляра, определить, является ли этот тип абстрактным или конкретным.

Качества абстракций
Некоторые абстракции более полезны, чем другие. Согласно цитате статистика Джорджа Бокса: «Все модели ошибочны, но некоторые из них полезны.» Мы можем посмотреть на тип в C# и определить, является ли он абстрактным, но он всё равно может быть не очень полезной абстракцией. Хорошие абстракции обладают определёнными свойствами, многие из которых описаны принципами SOLID.

Хорошие абстракции не зависят от деталей
Принцип инверсии зависимостей (DIP) гласит: «Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций».

Обычно мы можем посмотреть на абстракцию изолированно и определить, следует ли она этому принципу:

public interface IOrderDataAccess
{
  SqlDataReader ListOrders();
}

По определению, это абстракция. Вы не можете создать экземпляр этого типа; .NET считает его абстрактным. Он предоставляет модель для работы с данными, предположительно для получения информации о заказах. Но он явно не следуют DIP, потому что зависит от низкоуровневых деталей (очевидно, будет использоваться только для запросов к базам данных SQL)

Хороший интерфейс не должен ограничивать детали своей реализации. Интерфейсы определяют, что должно произойти; реализации определяют, как это сделать.

Мы можем заменить эту плохую абстракцию, следуя DIP, устранив зависимость от низкоуровневых деталей в определении интерфейса:

public interface IOrderDataAccess
{
  IEnumerable<Order> ListOrders();
}

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

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

Источник: https://ardalis.com/what-are-abstractions-in-software-development/
Автор оригинала: Steve “Ardalis” Smith

День 1217. #ЗаметкиНаПолях #DesignPatterns
Абстракции в Разработке ПО. Продолжение
Начало

Хорошие абстракции сфокусированы
Ещё два принципа SOLID помогают нам писать более качественные абстракции:
- Единственной обязанности (SRP)
- Разделения интерфейса (ISP)
SRP обычно применяется к классам, но помните, что когда класс реализует интерфейс, он должен реализовать его весь (если он этого не делает, то он нарушает другой принцип SOLID, принцип подстановки Лисков). Таким образом, абстракции, не соответствующие SRP, приводят к классам, не соответствующим SRP.

Один из способов «сфокусировать» интерфейс — посмотреть, как он потребляется. ISP говорит, что классы «не должны зависеть от методов, которые они не используют». Если у вас есть большие интерфейсы с множеством методов, вполне вероятно, что некоторым клиентам потребуется только их подмножество, и, таким образом, нарушится ISP.

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

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

Если вы обнаружите, что ваш дизайн требует регулярного обновления определённых абстракций, ищите лучший дизайн.

Принцип стабильных зависимостей (SDP) гласит, что зависимости между пакетами должны быть направлены в сторону более стабильных пакетов. То есть пакет должен зависеть только от более стабильных пакетов, чем он сам. Аналогично принцип стабильных абстракций предполагает, что самые стабильные пакеты должны быть самыми абстрактными. То есть абстрактность пакета должна меняться пропорционально его стабильности.

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

Также стоит отметить, что эти принципы не являются чисто субъективными. Для пакета можно рассчитать такие вещи, как стабильность и абстрактность. Нестабильность (Instability) определяется на основании входящих (или «афферентных» Ca) и исходящих («эфферентных» Ce) зависимостей:

I = (Ce / (Ca + Ce))

Компонент, у которого нет исходящих зависимостей (он ни от чего не зависит), полностью стабилен; нестабильность = 0. Компонент, который зависит от многих других компонентов (и, возможно, не имеет компонентов, зависящих от него, что характерно, например, для многих точек входа приложений), будет иметь нестабильность, равную 1 или близкую к ней.

Абстрактность пакета можно рассчитать, используя аналогичное соотношение абстрактных и конкретных классов:

A = Сумма(абстрактные классы)/Сумма(абстрактные + конкретные классы)

В C# к абстрактным классам надо добавить и интерфейсы.

Такие инструменты, как NDepend, могут быстро рассчитать стабильность и абстрактность для любого приложения .NET.

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

Источник: https://ardalis.com/what-are-abstractions-in-software-development/
Автор оригинала: Steve “Ardalis” Smith

День 1218. #ЗаметкиНаПолях #DesignPatterns
Абстракции в Разработке ПО. Окончание
Начало
Продолжение

Запутанные (или откровенно ложные) правила абстракций
Есть некоторые «правила» абстракций, которые могут привести к путанице, если их вырвать из контекста, хотя изначальный их посыл правильный.

1. Интерфейсы — это не абстракции
Это правило Марка Симэна, автора книги «Внедрение зависимостей на платформе .NET». Марк описывает множество причин, по которым интерфейс может быть плохой абстракцией. Однако согласно всем определениям, которые мы рассмотрели в первой части, интерфейсы таки являются абстракциями. Просто некоторые из них - плохие абстракции. Значит правило стоит уточнить:
«Интерфейсы не всегда являются хорошими абстракциями»

2. Интерфейсы с одной реализацией не являются абстракциями
Это утверждение Владимира Хорикова, автора книги «Принципы юнит-тестирования» и курсов на Pluralsight. Аналогично сказанному выше, это правило стоит уточнить:
«Интерфейсы с одной реализацией не являются хорошими абстракциями».

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

Вот отрывок из книги Хорикова:
«Настоящие абстракции обнаруживаются, а не изобретаются. Открытие по определению происходит постфактум, когда абстракция уже существует, но не имеет чёткого определения в коде».

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

Но ничто из этого не говорит о том, являются ли интерфейсы абстракциями или даже хорошими абстракциями, исходя из количества их реализаций.

В лучшем случае мы можем сказать:
Интерфейсы с единственной реализацией в рабочем коде — это код с запашком (code smell), потому что они могут быть плохими абстракциями из-за слишком тесной связи с их единственной реализацией.

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

Итого
Существует несколько определений абстракций. Некоторые аспекты могут оцениваться как истинные/ложные, например, является ли тип в C# абстрактным или конкретным. Другим может потребоваться некоторая субъективная оценка, чтобы определить, является ли данная абстракция хорошей, подлинной, полезной и т. д. А некоторые правила, претендующие на оценку того, является ли что-то абстракцией или нет, на самом деле просто говорят о том, является ли эта вещь хорошей абстракцией (или нет).

Источник: https://ardalis.com/what-are-abstractions-in-software-development/
Автор оригинала: Steve “Ardalis” Smith

День 1219. #ЧтоНовенького
Транскодинг JSON в gRPC для .NET
gRPC — это современный способ связи между приложениями. gRPC использует HTTP/2, потоковую передачу, двоичную сериализацию и контракты сообщений для создания высокопроизводительных сервисов реального времени. .NET поддерживает создание приложений gRPC.

Однако, как и при выборе большинства технологий, при выборе gRPC по сравнению с альтернативой, такой как REST + JSON, есть компромиссы. К сильным сторонам gRPC относятся производительность и продуктивность разработчиков. Между тем, REST+JSON можно использовать везде, а его удобочитаемые сообщения JSON легко отлаживать.

Транскодинг JSON в gRPC — это расширение для ASP.NET Core, которое создаёт RESTful API для служб gRPC. После настройки транскодинг JSON позволяет вызывать методы gRPC со знакомыми HTTP концепциями:
- HTTP-глаголы
- Привязка параметров URL
- Запросы/ответы в JSON

Начало работы
1. Создайте службу gRPC. Вот здесь руководство.
2. Добавьте на сервер ссылку на пакет Microsoft.AspNetCore.Grpc.JsonTranscoding и зарегистрируйте его в коде запуска. Например:

services.AddGrpc().AddJsonTranscoding();

3. Добавьте аннотации файла .proto для привязки и маршрутов HTTP. Для этого сохраните себе файлы annotations.proto и http.proto в папку google/api вашего проекта и добавьте в ваш файл .proto строку

syntax = "proto3";

import "google/api/annotations.proto";

package greet;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {
    option (google.api.http) = {
      get: "/v1/greeter/{name}"
    };
  }
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

Транскодинг JSON или gRPC-Web
Оба варианта позволяют вызывать службы gRPC из браузера. Различаются способы достижения этого:
- gRPC-Web позволяет браузерным приложениям вызывать службы gRPC из браузера с помощью клиента gRPC-Web и Protobuf. Он требует, чтобы приложение создавало клиент gRPC, и имеет преимущество в отправке небольших и быстрых сообщений Protobuf.
- Транскодинг JSON позволяет приложениям вызывать службы gRPC как RESTful API с JSON. Приложению не нужно создавать клиент gRPC или знать что-либо о gRPC.

Реализация
Транскодинг JSON не является новой концепцией. grpc-gateway — это еще одна технология для создания RESTful JSON API из служб gRPC. Он использует те же аннотации .proto для сопоставления концепций HTTP со службами gRPC. Однако grpc-gateway использует генерацию кода для создания обратного прокси-сервера, который переводит вызовы RESTful в gRPC+Protobuf и отправляет их через HTTP/2 в службу gRPC. Преимущество этого подхода заключается в том, что служба gRPC не знает о RESTful API. Любой сервер gRPC может использовать grpc-gateway.

Транскодинг JSON выполняется внутри приложения ASP.NET Core. Он десериализует JSON в сообщения Protobuf, а затем напрямую вызывает службу gRPC. Это даёт преимущества для разработчиков приложений .NET:
- И службы gRPC, и сопоставленный RESTful JSON API выполняются из одного приложения ASP.NET Core.
- Транскодинг JSON десериализует сообщения JSON в Protobuf и напрямую вызывает службу gRPC. Выполнение этого в процессе даёт значительные преимущества в производительности по сравнению с новым gRPC-вызовом на другой сервер.

Что дальше
Транскодинг JSON в gRPC доступен в .NET 7 Превью 4. Это первый выпуск. Будущие версии .NET 7 будут сосредоточены на повышении производительности и поддержке OpenAPI.

Подробная информация доступна в документации. Также можно посмотреть пример приложения или видео с демонстрацией функционала.

Источник: https://devblogs.microsoft.com/dotnet/announcing-grpc-json-transcoding-for-dotnet/

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

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

Понимание эффекта Зейгарник и того, как он работает, даёт вам возможность повысить свою продуктивность.

1. Начните хоть с чего-нибудь
Вы знаете, что дедлайн через неделю, поэтому можно отложить дела до обеда. Нет. Просто начните с чего-нибудь. Выделите 20-30 минут. Не нужно начинать со сложного, попробуйте что-нибудь простое. Как только вы приступите к выполнению задачи, какой бы тривиальной она ни была, она поселится в глубине вашего сознания и будет подталкивать вас сделать ещё немного… и ещё немного… пока вы не закончите.
Вы также можете сдвинуть дело с мертвой точки, создав краткий план того, что нужно сделать. Мотивация завершить задачу тем выше, чем яснее мы понимаем, что нужно сделать для её завершения. Это назвали эффектом Хемингуэя, которого спросили: «Сколько вы должны писать в день?» Он ответил: «Лучший способ всегда останавливаться, когда дела идут хорошо и когда вы знаете, что произойдёт дальше. Если вы будете делать это каждый день, пока пишете роман, вы никогда не застрянете».

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

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

4. Завершайте день списком дел
Чрезмерное беспокойство о незавершённых задачах приводит к бессонным ночам. Составьте четкий план того, что вам осталось сделать. Важно, чтобы план был конкретным. Мысль «мне следует заняться спортом» беспокоит подсознание, потому что привлекает внимание к неудовлетворенным целям и оставляет подсознание в неуверенности, как действовать дальше. Мысль «Я пойду на пробежку завтра утром перед работой» позволяет подсознанию точно знать, как действовать дальше, и ему больше не нужно беспокоить сознание навязчивыми мыслями о занятиях спортом. Чтобы отключить мысли о незавершённой работе, посвящайте некоторое время в конце каждого дня обзору достижений за день, и плану, что ещё нужно сделать и как. Ваше подсознание любит, когда план складывается воедино. Хоть как-нибудь.

Источник: https://scitechdaily.com/boost-your-productivity-with-the-zeigarnik-effect/

День 1221. #ЗаметкиНаПолях
Добавляем Startup.cs в Минимальные API
С минимальными API в .NET 6 просто начать, но по мере роста проекта какие-то части из Program.cs лучше всё-таки вынести. Рассмотрим, как вернуть файл Startup.cs в проект минимальных API.

Вот пример файла Program.cs с использованием минимальных API:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment()) {
  app.UseExceptionHandler("/Error");
  app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();

Здесь всё написано в одном классе Program.cs. Мы создаём построитель приложения, регистрируем зависимости, строим приложение и добавляем промежуточное ПО.
Startup.cs содержит 2 метода: ConfigureServices() для регистрации зависимостей и вызова промежуточного ПО в методе Configure().

Соответственно, всё, что идёт до строки

var app = builder.Build();

должно попасть в ConfigureServices. А всё, что после – в Configure.

public class Startup {
  public IConfiguration configRoot { get; }
  public Startup(IConfiguration configuration) {
    configRoot = configuration;
  }

  public void ConfigureServices(IServiceCollection services) {
    services.AddRazorPages();
  }

  public void Configure(WebApplication app, IWebHostEnvironment env) {
    if (!app.Environment.IsDevelopment()) {
      app.UseExceptionHandler("/Error");
      app.UseHsts();
    }
    app.UseHttpsRedirection();
    app.UseStaticFiles();
    app.UseRouting();
    app.UseAuthorization();
    app.MapRazorPages();
    app.Run();
  }
}

Теперь нужно вызвать класс Startup из Program.cs:

var builder = WebApplication.CreateBuilder(args);
var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services);
var app = builder.Build();
startup.Configure(app, builder.Environment);

Заметьте, что называть методы именами ConfigureServices и Configure вовсе не обязательно. Тем более, что они похожи и часто путают (особенно новичков). Вы можете задать любые имена.

Источник: https://www.c-sharpcorner.com/article/how-to-add-startup-cs-class-in-asp-net-core-6-project/