День 1434. #ЧтоНовенького
Entity Framework 7. Пакетные Операции и Столбцы JSON
Версия 7 EF Core была выпущена в ноябре вместе с более широким выпуском .NET 7. В обновлённой версии улучшена производительность при сохранении данных, разрешены операции со столбцами JSON, реализованы эффективные пакетные операции, а также содержится множество мелких исправлений и улучшений. EF Core 7 доступен как для .NET 7, так и для .NET 6.

Согласно документации по критическим изменениям, наиболее важным изменением в EF Core 7 является обработка соединений SQL Server по умолчанию как зашифрованных. Разработчикам придётся настроить действительный сертификат на своих машинах или явно ослабить ограничение безопасности. В противном случае строки подключения допустимые в EF6 вызовут исключение в EF7.

Одним из уже известных улучшений в EF7 является повышение производительности при сохранении изменений в базе данных с помощью метода SaveAsync. В некоторых сценариях оно может составлять до 50% по сравнению с EF6 Core на том же компьютере.

В EF7 добавлена поддержка текстовых столбцов, содержащих документы JSON. Разработчики могут фильтровать и сортировать свойства JSON внутри документов как часть запроса к базе данных. EF7 содержит обобщённую поддержку столбцов JSON и конкретную реализацию для провайдера SQL Server.

Пакетные операции с базой данных, такие как массовое обновление или удаление, также были переработаны в EF7. Выполнение стандартного метода SaveChangesAsync может повлиять на несколько записей, но в итоге результаты выполнения SQL загружаются в память. В EF7 теперь есть два новых метода, ExecuteUpdateAsync и ExecuteDeleteAsync, которые немедленно выполняют пакетные операции на сервере и не загружают объекты обратно в память.

По умолчанию EF Core сопоставляет иерархию наследования типов .NET с одной таблицей базы данных в соответствии со стратегией, которая называется Table-per-Hierarchy (TPH). В EF Core 5 добавлена стратегия Table-per-Type (TPT), при которой каждый тип в иерархии получает таблицу базы данных. В EF Core 7 теперь добавлена стратегия Table-per-Concrete-Type (TPC), при которой каждый неабстрактный тип получает таблицу базы данных, а столбцы абстрактного типа добавляются в таблицы конкретных реализаций абстрактного типа.

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

Хотя исторически разработчики .NET воспринимали Entity Framework как громоздкую и полную недостатков, новые версии теперь признаны высокоэффективными, отказоустойчивыми ORM.

В выпуске EF7 уже есть дорожная карта для EF8 с дополнительными улучшениями для столбцов JSON, поддержкой объектов-значений .NET и возможностью возвращать несопоставленные типы в качестве результатов запроса.

Источник: https://www.infoq.com/news/2022/12/ef7-core-json/

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

Начнём с некоторой конфигурации, которую мы хотим проверить, и завершить работу в случае неудачи:

"WebHook": {
  "WebhookUrl": "https://example.com/event",
  "DisplayName": "DevOps",
  "Enabled": true
}

Как убедиться, что URL-адрес действителен? Мы можем создать строго типизированный класс и добавить проверку свойств, используя аннотации данных. Существует множество встроенных атрибутов, таких как StringLength, Range, EmailAddress и другие. Их можно найти в документации.

using System.ComponentModel.DataAnnotations;

public class WebHookSettings
{
  [Required, Url]
  public string WebhookUrl { get; set; }
  [Required]
  public string DisplayName { get; set; }
  public bool Enabled { get; set; }
}

Теперь всё, что нам остаётся, вызвать несколько методов расширения на построителе приложения:

using System.ComponentModel.DataAnnotations;
using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOptions<WebHookSettings>()
  .BindConfiguration("WebHook")
  .ValidateDataAnnotations()
  .ValidateOnStart();

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

builder.Services.AddOptions<WebHookSettings>()
  .BindConfiguration("WebHook")
  .ValidateDataAnnotations()
  .Validate(s =>
    {
      return s.WebhookUrl.StartsWith("https://");
    }, "WebHookUrl must start with https://")
  .ValidateOnStart();

Теперь если мы запустим приложение с такой конфигурацией:

"WebHook": {
  "WebhookUrl": "https://example.com/event",
  "DisplayName": "DevOps",
  "Enabled": true
}

то при старте получим ошибку

Unhandled exception. Microsoft.Extensions.Options.OptionsValidationException: WebHookUrl must start with https://

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

Подробности о конфигурации .NET описаны в документации, а также посмотрите на паттерн Options.

Источник: https://chris-ayers.com/2022/12/03/validating-dotnet-configuration

День 1436. #Карьера
Читайте Академические Статьи по ИТ
Вы читаете документацию и учебные пособия, чтобы стать лучше, как программист, но, если вы хотите быть лучшим, читайте академические исследования.

Как часто вам приходится копаться в академических статьях по ИТ, чтобы улучшить свои навыки программирования?
Учебники могут помочь вам писать код прямо сейчас, но именно академические статьи могут помочь понять, откуда взялось программирование и куда оно движется. Каждая функция программирования, от нулевого указателя (он же ошибка на миллиард долларов) до ООП (через Smalltalk), была построена на основе исследований, которые уходят корнями в 1960е (и ранее). Будущие инновации будут основываться на сегодняшних исследованиях.

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

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

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

Когда вы видите эти проблемы в их изначальном контексте, например, читаете исследовательские работы, в которых пытались их решить, вы можете лучше понять, где вы сейчас находитесь. Это может привести ко всякого рода прозрениям: «Объекты именно такие, благодаря Smalltalk из 80х. И именно поэтому большие системы такие, поэтому Java и C# такие.»

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

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

Что почитать?
1. В 1996 году Филипп Лапланте написал книгу «Великие статьи по компьютерным наукам», которая на данный момент может быть немного устаревшей.

2. Более свежая книга Гарри Льюиса «Идеи, которые создали будущее» опубликована в 2021.

3. Репозиторий Papers We Love содержит документы и ссылки на документы, организованные по темам. Его создатели приветствуют новые пулл-реквесты с академическими статьями, которые вам нравятся.
Если вы открыли одну из статей из репозитория, ужаснулись и тут же закрыли, вам может помочь одна из презентаций команды Papers We Love, в которых они рассказывают, как понимать научные статьи: от полной фрустрации при первом просмотре до нахождения пути для понимания.

Источник: https://stackoverflow.blog/2022/12/30/you-should-be-reading-academic-computer-science-papers/

День 1437. #ЗаметкиНаПолях #Blazor
Вызываем Код JavaScript из Blazor WebAssembly
Одна из серьезных проблем модернизации существующего или «устаревшего» кода заключается в том, насколько сложно начать работу, потому что код слишком сложен или объёмен. Рефакторинг и переписывание может стать проще, если вы можете интегрировать новый код с существующим устаревшим кодом, а затем медленно и итеративно мигрировать с течением времени.

Сегодня рассмотрим, как из кода Blazor WASM вызвать JavaScript-функцию, которая будет примером некоторого существующего устаревшего кода.

Допустим, у нас есть какая-то функция на Javascript:

var arg = 0;
function legacyFunction(arg) {
  var nxt = arg + 1;
  console.log(arg + ' > ' + nxt);
  return nxt;
}

Чтобы вызвать её в проекте Blazor WASM, нам потребуются 3 простых шага:
1) Добавить тег script со ссылкой на файл Javascript кода в файл шаблона страниц (например, index.html):

<script src="legacysample.js"></script>

2) На странице Razor-компонента внедрить JSRuntime:

@inject IJSRuntime JSRuntime

3) На странице Razor-компонента написать Blazor-функцию с вызовом Javascript кода с помощью JSRuntime:

var currentCount = 0;
...
async void IncrementCount()
{
  currentCount = await 
   JSRuntime.InvokeAsync<int>(
    "legacyFunction", currentCount);
}

На этом третьем и последнем шаге вы можете видеть, что currentCount использует вызов JSRuntime.InvokeAsync с целочисленным типом результата, возвращаемого JavaScript-функцией «legacyFunction», и currentCount, передаваемого в качестве аргумента. Обратите внимание, что метод был изменён на асинхронный для использования await, чтобы JSRuntime мог завершить InvokeAsync, прежде чем вернуть управление Razor-компоненту.

Источник: https://dev.to/aztecconsulting/invoking-legacy-javascript-from-blazor-webassembly-using-the-jsruntime-1df3

День 1438. #Карьера
Улучшаем Эмоциональный Интеллект. Часть 3
Эмоциональный интеллект – это способность понимать эмоции и управлять ими, бесценное качество, которое поможет стать более продуктивными и улучшить отношения с другими. Вот простые правила, которые помогут развить ваш эмоциональный интеллект.

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

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

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

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

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

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

2. Запланируйте время для «обслуживания»
Убраться один раз – одно, но поддерживать организованность — это другое. Почему бы не выделить время каждый день на «обслуживание»? Вы обнаружите, что всего 10–15 минут в день творят чудеса с вашей продуктивностью и психическим здоровьем. Также ежедневное обслуживание упрощает уборку, т.к. вам не нужно выполнять огромную работу, которая кажется слишком сложной, чтобы начать.

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

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

Источник: https://www.inc.com/justin-bariso/emotional-intelligence-how-to-make-better-decisions-how-to-deal-with-life-get-organized.html

День 1439. #ЧтоНовенького
Visual Studio 17.5. Упрощено Добавление Новых Файлов
Visual Studio продолжает инкорпорировать функционал полезных расширений в свой основной функционал. На этот раз пришла очередь расширения Add File от Мэдса Кристенсена.

Стандартный способ добавления нового элемента через окно «Add New Item» довольно муторный. Это большое окно со списком всех доступных шаблонов. Но часто нужно просто автоматически определить, какой шаблон вам нужен по имени файла.

В превью 2 версии Visual Studio 17.5 появилось окно быстрого добавления. В окне обозревателя решения щёлкните правой кнопкой мыши на папке или проекте и выберите Add > New Item… (Добавить > Новый элемент…) или нажмите Ctrl+Shift+A. Вместо старого диалогового окна «Add New Item» вы увидите диалоговое окно «Quick Add» (Быстрое Добавление).

В нём вы можете:
1. Добавить новый файл: MyClass.cs (шаблон будет выбран по расширению)
2. Создать несколько вложенных папок сразу: Folder1/Folder2/, Folder1/Folder2/MyFile.cs
3. Добавлять файлы с любым расширением или вообще без расширения: File.MyExtension, README, .gitignore (расширение задаётся по умолчанию, но если нажать Escape после открытия диалогового окна, оно очистится).
4. Добавить сразу несколько файлов: File1.cs, File2.html или File.(cs, txt). В первом случае будут созданы файлы File1.cs и File2.html. Во втором - File.cs и File.txt.

Также можно быстро переключаться между окном быстрого добавления и обычным окном создания нового элемента по кнопке «Show All Templates»/«Show Compact View» (Показать Все Шаблоны/Показать Компактный Вид) внизу окна добавления элемента. Visual Studio запомнит ваш выбор для будущего использования. Открыть окно быстрого добавления вне зависимости от этой настройки можно по сочетанию клавиш Shift+F2.

Источник: https://devblogs.microsoft.com/visualstudio/adding-new-files-just-got-a-lot-faster/

День 1440. #ЗаметкиНаПолях
Особенность Использования Необязательных Параметров
Мы все любим необязательные параметры методов. Их так просто и удобно использовать. Но есть один момент, при использовании их в отельной библиотеке классов, о котором стоит помнить.

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

Допустим, мы сделали библиотеку классов для калькулятора:

namespace ThirdPartyLibrary;

public static class Calculator
{
   public static int Add(int a = 0, int b = 0)
   {
     Console.WriteLine($"{a}+{b}");
     return a + b;
   }
 }
}

Простой метод с необязательными параметрами. И код, который её использует:

using ThirdPartyLibrary;

int add = Calculator.Add();
add = Calculator.Add(2);
add = Calculator.Add(2, 3);

Console.ReadLine();

//Вывод:
0+0
2+0
2+3

Пока всё хорошо.
Теперь сделаем небольшое изменение в классе Calculator: изменим значения параметров по умолчанию с 0 на 10.
Соберём проект библиотеки (только его, а не всё решение) и скопируем получившиеся файлы библиотеки ThirdPartyLibrary.dll и ThirdPartyLibrary.pdb из папки \bin\Debug библиотеки в папку \bin\Debug консольного приложения. То есть мы обновили библиотеку и хотим, чтобы наше приложение работало с новой версией.

Теперь из той же папки \bin\Debug консольного приложения запустим приложение (exe файл). Мы ожидаем, что оно будет использовать новую версию библиотеки, и будут использоваться новые значения по умолчанию (10), так?

Но результаты не изменились!

0+0
2+0
2+3

Теперь попробуем пересобрать весь проект и запустить его. Получаем то, чего ожидали:

10+10
2+10
2+3

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

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

Источник: https://levelup.gitconnected.com/dangers-of-using-optional-parameters-in-net-c-a953315672fb

День 1441. #ЧтоНовенького
Миграция Проекта с ASP.NET на ASP.NET Core
Я уже писал про возможность миграции проекта ASP.NET Framework на ASP.NET Core с помощью расширения Visual Studio Microsoft Project Migrations. Сегодня расскажу о последних новинках в этом процессе.

Напомню, что процесс можно начать, просто нажав правой кнопкой на проекте и выбрав в контекстном меню Migrate project (Перенести проект). Появится мастер миграции, в котором вы можете выбрать перенести контроллер, класс или представление. Подробнее об этом в предыдущих постах. Сегодня о новинках.

1. Добавлен Обозреватель Конечных Точек (Endpoints Explorer), позволяющий просматривать, какие конечные точки или маршруты были перенесены (в списке справа), а какие ещё предстоит перенести (слева). Вы можете щелкнуть правой кнопкой мыши маршрут и выбрать Open in editor (Открыть в редакторе), чтобы исходный код этого маршрута.

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

3. Добавлена поддержка областей (Area). Теперь, когда вы переносите содержимое в область ASP.NET, при необходимости область будет создана в целевом проекте миграции. Это должно уменьшить объём работы, которую необходимо выполнить при переносе содержимого в области ASP.NET.

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

5. Пакеты адаптеров для System.Web позволяют переносить проекты с зависимостями от System.Web в .NET Standard, .NET 6 или .NET 7, предоставляя общие API System.Web через адаптеры, совместимые с .NET Standard. Это позволяет переносить библиотеки классов с зависимостями от System.Web в .NET Standard, чтобы их можно было использовать вызывающими объектами ASP.NET и ASP.NET Core в сценариях поэтапной миграции. Доступные API включают множество часто используемых элементов из HttpRequest, HttpResponse, HttpContext и других распространённых типов.
Также адаптеры для System.Web включают новые функции для улучшения поэтапной миграции. При поэтапной миграции решения части веб-приложения будут обслуживаться исходным проектом ASP.NET, а части — новым проектом ASP.NET Core. Для простых конечных точек это работает хорошо. Но когда сеанс пользователя включает в себя состояние — будь то элементы сессии или аутентификацию — необходимо совместно использовать это состояние между двумя приложениями, чтобы вход в одно из приложений также входил в другое, и чтобы элементы сессии, записанные конечной точкой одного приложения, могли быть прочитаны другим приложением. Адаптеры System.Web включают функции, позволяющие совместно использовать такое состояние через соединения между приложениями ASP.NET Core и ASP.NET.

6. Была улучшена и обновлена документация, которая сейчас доступна здесь. Документация включает советы по началу работы, описание адаптеров для
System.Web, а также руководство о совместном использовании сессии между приложениями ASP.NET и ASP.NET Core.

Источник: https://devblogs.microsoft.com/dotnet/migrating-from-asp-net-to-asp-net-core-part-5/

День 1442. #МоиИнструменты
Процессор JSON, Который Вам Пригодится
Обработка JSON — обычная задача в повседневной работе разработчиков. Мы привыкли работать с JSON, но иногда нам нужно что-то более динамичное и эффективное, чем System.Text.Json и Newtonsoft.Json. JMESPath — это мощный язык запросов, который позволяет вам выполнять задачи Map/Reduce декларативным и интуитивно понятным способом. Его можно использовать в .NET, см. JmesPath.Net.

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

Например, Azure CLI использует параметр –query для выполнения запроса JMESPath к результатам выполнения команд.

Допустим, у нас есть какие-то данные в JSON в строковой переменной source:

{
  "balance": "$2,285.51",
  "name": "Eva Sharpe",
  "email": "[email protected]",
  "latitude": 46.325291,
  "friends": [
    {
      "id": 0,
      "name": "Nielsen Casey",
      "age": 19
    },
    {
      "id": 1,
      "name": "Carlene Long",
      "age": 38
    }
  ]
}

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

var expressions = new (string, string)[]
{
 ("scalar", "balance"),
 ("projection", "{email: email, name: name}"),
 ("functions", "to_string(latitude)"),
 ("arrays", "friends[*].name"),
 ("filtering", "friends[?age > `20`].name"),
 ("aggregation", "{sum: sum(friends[*].age)}"),
};

var parser = new JmesPath();
foreach (var (name, expression) in expressions)
{
  var result = parser.Transform(source, expression);
  Console.WriteLine($"{name}: {result}");
}

Вывод

scalar: "$2,285.51"
projection: {"email":"[email protected]","name":"Eva Sharpe"}
functions: "46.325291"
arrays: ["Nielsen Casey","Carlene Long"]
filtering: ["Carlene Long"]
aggregation: {"sum":57}

Итого
Как видите, JMESPath неплохо решает проблемы динамической обработки JSON на основе пользовательского ввода. Он также имеет модель расширяемости (возможность писать свои функции), которая открывает массу возможностей.

Источник: https://dev.to/nikiforovall/introduction-to-jmespath-json-processor-you-should-definitely-know-2dpb

День 1443. #Карьера
Улучшаем Эмоциональный Интеллект. Часть 4
Эмоциональный интеллект – это способность понимать эмоции и управлять ими, бесценное качество, которое поможет стать более продуктивными и улучшить отношения с другими. Вот простые правила, которые помогут развить ваш эмоциональный интеллект.

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

Итак, как правило Майи Анжелу проявляется в реальной жизни?

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

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

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

Итак, что вы можете сделать для своих коллег?

Если вы занимаете руководящую должность, будь то менеджер, руководитель группы (или даже родитель), задайте себе и своей команде следующие вопросы:
- Как мне заставить людей чувствовать себя хорошо?
- Могу ли я выслушать? Услышать об их проблемах, трудностях и успехах?
- Предлагаю ли я поддержку для решения этих задач? Замечаю ли я их достижения?
- Благодарю ли я их? Просто потому, что это правильно, но также и потому, что так я побуждаю их продолжать делать то, что они делают.
- Я заставляю их чувствовать себя в безопасности? Чувствовать, что о них заботятся, их ценят, им доверяют? Что они тоже могут рассчитывать на меня?

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

Источник: https://www.inc.com/justin-bariso/how-to-increase-emotional-intelligence.html

День 1444. #МоиИнструменты
Тестовые Контейнеры в C#/.NET
Многие приложения сильно зависят от реляционной базы данных. Ваше приложение использует сложные запросы, ограничения на данные и другие возможности реляционной базы данных. Это означает, что многое в поведении ваших приложений зависит от того, как действует база данных. Поэтому важно проводить тесты на реальной базе. Сегодня это легко сделать с помощью TestContainers.

TestContainers — это библиотека, которая запускает контейнеры Docker для ваших тестов и предоставляет множество настроек для баз данных.

Попробуем настроить тестовый контейнер с Microsoft SqlServer:

// настройка БД
var dbConfig = new MsSqlTestcontainerConfiguration
{
  Password = "Test1234",
  Database = "TestDB"
};

// создание контейнера
var сontainer = 
 new TestcontainersBuilder<MsSqlTestcontainer>()
  .WithDatabase(dbConfig)
  .WithImage("mcr.microsoft.com/mssql/server:2022-latest")
  .Build();

// и запуск
container.StartAsync().Wait();

Этот код загрузит образ докера MS Server и запустит контейнер. Затем запросит строку подключения для этого контейнера и запустит тесты для него. Если не указать путь к образу, будет использован образ по умолчанию. Если предварительно настроенные контейнеры вам не подходят, вы можете запустить произвольный образ с базовым тестовым контейнером.

Посмотрим пример теста:

record Dog (string Name, DateTime BirthDate);

using (var db = new SqlConnection(
  container.ConnectionString))
{ 
  db.Execute(@"CREATE TABLE Dogs(
    BirthDate DATETIME NOT NULL,
    Name VARCHAR(MAX) NOT NULL
  )");

  var born = new DateTime(2022, 12, 22);
  db.Execute(@"
   INSERT Dogs(BirthDate,Name)
   VALUES(@BirthDate, @Name)",
   new {
    BirthDate = born,
    Name = "Joe"
   });

  var dog = db.Query<Dog>(
    @"SELECT * FROM Dogs")
   .First();
  Assert.AreEqual(born, dog.BirthDate);
}

// очищаем контейнер
container.DisposeAsync();

Что если убить процесс, который запускает тесты? Что произойдёт с контейнерами, которые он создал? На самом деле при запуске тестового контейнера создаётся два контейнера. Помимо запущенного вами, создаётся контейнер testcontainers/ryuk, который управляет всеми тестовыми контейнерами и выполняет очистку при сбоях.

В TestContainers встроена поддержка многих баз данных в наследниках класса TestcontainerDatabase. То же самое касается систем сообщений, которые являются наследниками TestcontainerMessageBroker. Всё это можно найти в документации.

Источник: https://www.gamlor.info/posts-output/2022-12-22-test-containers/en/

День 1445. #МоиИнструменты
Используем Новинки Языка на Старых Платформах
Сегодня порекомендую вам интересное видео от Ника Чапсаса об использовании новейших функций языка C# в старых версиях платформы, например, в .NET Framework.

На самом деле, все функции можно использовать практически «из коробки», просто изменив версию языка на 11. Да, Visual Studio не даст вам этого сделать так просто, потому что она автоматом определяет версию языка по версии фреймворка. Но можно вручную отредактировать файл .csproj, указав нужную версию языка в блоке компиляции:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <PlatformTarget>AnyCPU</PlatformTarget>
  …
  <LangVersion>11.0</LangVersion>
</PropertyGroup>

Только одно это действие уже позволит вам писать, например, top-level statements (т.е. обойтись без класса Program).

Добавить другие функции чуть сложнее. Например, чтобы использовать init-свойства, нужно добавить пустой класс IsExternalInit:

namespace System.Runtime.CompilerServices
{
  public static class IsExternalInit { }
}

Однако и эту работу можно облегчить, просто добавив NuGet-пакет PolySharp.

Все подробности в новом видео Ника https://youtu.be/RgKa-tjnUMA

День 1446. #Оффтоп
Закон Дырявых Абстракций
В основе Интернета лежит ключевой элемент магии, на который вы полагаетесь каждый день. Протокол TCP — это надёжный способ передачи данных. Т.е., если вы отправляете сообщение по сети с использованием TCP, оно будет доставлено, и не будет искажено или повреждено.
Для сравнения, есть ненадежный метод передачи данных, называемый IP. Никто не обещает, что ваши данные дойдут до адресата, и они могут испортиться по ходу.
Магия в том, что TCP построен поверх IP. Т.е. TCP обязан каким-то образом надёжно отправлять данные, используя только ненадёжный инструмент.

Но 100%-ной гарантии не даёт даже TCP. Если ваша кошка перегрызла сетевой кабель, и никакие IP-пакеты не могут пройти, то TCP ничего не сможет с этим поделать. Если у вас нестабильное соединение, то только часть ваших IP-пакетов будет проходить. TCP будет работать, но очень медленно.

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

Все нетривиальные абстракции в той или иной степени негерметичны:
- Такая простая вещь, как итерация по большой коллекции может иметь совершенно разную производительность в зависимости от выбранного метода итерации.
- SQL предназначен для того, чтобы абстрагироваться от процедурных шагов, необходимых для запроса к базе данных, позволяя вам просто описать, что вы хотите, и дать базе данных определить, что сделать для выполнения запроса. Но в некоторых случаях определённые SQL-запросы выполняются в тысячи раз медленнее, чем другие логически эквивалентные запросы. Вы не должны заботиться о процедуре, только о спецификации. Но иногда абстракция «протекает» и приводит к ужасной производительности, и вам приходится анализировать план запроса, чтобы выяснить, что не так.
- Класс string позволяет вам притвориться, что строки являются скалярными типами и работать с ними так же, как с целыми числами, например, используя оператор +. Но даже джуны знают, что чрезмерное его употребление ни к чему хорошему не приведёт. Абстракция имеет дыру, которую язык не позволяет заткнуть.

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

Miscrosoft в ASP.NET Web Forms попробовали сделать абстракцию, позволяющую работать с веб-страницами так же, как если бы они были формами настольного приложения. Абстракция задумывалась как способ скрыть всё взаимодействие по HTTP и сделать нажатие на кнопку веб-страницы таким же, как нажатие на кнопку формы настольного приложения. И эта идея с треском провалилась. Сейчас идут попытки сделать наоборот: показывать веб-страницы внутри локального приложения. Посмотрим, что получится из этого.

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

Источник: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

День 1447. #CSharp11
Обзор Новых Функций C# 11. Начало
Я уже ранее кратко описывал, какие новинки должны были появиться, а потом и появились в C# 11. В этой серии подведём итоги. Что же появилось, а что нет.

1. Необработанные (raw) строковые литералы (включено в релиз)
С обычными строками в C# бывает трудно работать, потому что нужно экранировать кавычки ("), обратную косую черту (\) и разрывы строк (\n). В предыдущих версиях C# уже было решение — дословные (verbatim) строки, которые начинаются с @ и допускают использование специальных символов.
Вместо:

string path = "c:\\myfilepath\\with-backslashes";

будет:

string path = @"c:\myfilepath\with-backslashes";

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

C# 11 вводит необработанные строковые литералы, чтобы обойти проблему экранирования. Используется новый разделитель — ряд кавычек, за которыми следует разрыв строки (в начале), и разрыв строки, за которым следует такое же количество кавычек (в конце). Вы просто вставляете свой блок кода или разметку между ними:

string xml = """
  <part number="1976">
    <name>Windscreen Wiper</name>
    <description>The Windscreen wiper automatically removes
       rain from your windscreen. It has a rubber
       <ref part="1977">blade</ref>, which can be ordered
       separately.
    </description>
  </part>
  """;

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

string xml = """" 
    Теперь можно использовать """ в строке.
    """";

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

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

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

int number = 1;
string json =
  $$"""
  {
    "number": "{{number}}"
  }
  """;

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

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1448. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Продолжение
Начало
Продолжим обзор функциональности работы со строками.

2. Разрывы строк во встроенных выражениях (включено в релиз)
В C# 11 добавлено небольшое усовершенствование в способ обработки разрывов строк во встроенных выражениях при интерполяции. В C# 10 вы не могли разрывать строку внутри фигурных скобок:

var text =
  $"Всего {people.Count} человек";

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

var text =
  $"Всего {students.Count 
    + teachers.Count} человек";

3. Строки UTF-8 (включено в упрощённом виде)
C# 11 дает нам новый суффикс переменной u8, который указывает использовать кодировку UTF-8 для строкового литерала:

var utf8 = "HEAD/HTTP/1.1"u8;

Важно понимать, что этот код не создаёт строку. Строки C# используют кодировку UTF-16, и создание совершенно нового пользовательского строкового типа данных UTF-8 было бы излишним. Вместо этого создаётся экземпляр объекта ReadOnlySpan<byte>. Это в основном пригодится, если вы взаимодействуете с веб-протоколом (он почти всегда использует UTF-8) и хотите избежать накладных расходов на написание такого кода:

string utf16 = "HEAD / HTTP/1.1";
byte[] utf8 = Encoding.UTF8.GetBytes(utf16);

Кроме того, вы должны получить ошибку времени компиляции при попытке присвоить u8 строке символы, которые не представлены в UTF8:

var utf8data = "Special chars:\uD801\uD802"u8;

Этот код выдаст ошибку CS9026: The input string cannot be converted into the equivalent UTF-8 byte representation. Unable to translate Unicode character \uD801 at index 14 to specified code page. (Входная строка не может быть преобразована в эквивалентное байтовое представление UTF-8. Невозможно преобразовать символ Unicode \uD801 на позиции 14 в указанную кодовую страницу.)

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

byte[] utf8data = "HEAD / HTTP/1.1";

Но это не было включено в релиз.

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1449. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Продолжение
Начало 1
Продолжение 2-3

4. Шаблоны списков (включено в релиз)
Тренд современного C# - растущее использование методов функционального программирования. В частности, использование выражений, которые позволяют разработчикам заменить императивный код декларативным кодом.

В C# 11 добавлено отличное расширение для синтаксиса выражения switch, позволяющее тестировать массивы. Оно называется выражениями списка, вот тривиальный пример:

int[] numbers = {24, 320, 700};
string test = numbers switch
{
  [24, 320, 700] => "Это нужный массив!",
  _ => "Не подходит" 
};

Этот код использует выражение switch для проверки массива. Если выражение соответствует первому массиву (а оно соответствует), переменной test присваивается строка «Это нужный массив!», в противном случае - строка «Не подходит».

Шаблоны списков становятся намного интереснее, когда вы используете операторы .. или _ для создания срезов:

int[] numbers = {24, 320, 700};
string test = numbers switch
{
  [24, 32, 700] => "Это нужный массив!",
  [24, _, 700] => "2й элемент может быть любым",
  [24, .., 700] => "1й элемент 24, последний 700",
  [< 25, ..] => "1й элемент меньше 25",
  _ => "Не подходит"
};

Оператор .. представляет серию элементов (любое количество), а _ представляет один любой элемент. Таким образом, [24, .., 700] соответствует таким массивам, как [24, 200, 700] или [24, 324, 254, 525, 4, -4, 700]. Кроме того, можно использовать выражения и вместо самих элементов. Шаблон [< 25, ..] предполагает, что первый элемент массива меньше 25, а количество элементов не ограничено.

Заметьте, что, как и в других вариантах использования сопоставления по шаблону в выражениях switch, в случае, когда входящему элементу соответствуют несколько шаблонов, будет использован первый подходящий шаблон. В данном случае - [24, _, 700], хотя [24, .., 700] и [< 25, ..] тоже подходят. Поэтому необходимо располагать шаблоны в switch выражении от частных к более общим. Если вы нарушите это правило, компилятор выдаст ошибку CS8510: The pattern is unreachable. It has already been handled by a previous arm of the switch expression or it is impossible to match. (Шаблон недостижим. Он уже был обработан предыдущим вариантом выражения switch или с ним невозможно сопоставиться.)

Шаблоны списков работают не только с явно определёнными массивами. Любой тип с индексатором и свойствами Length и Count работает для фиксированных совпадений. Шаблоны срезов работают, если у типа есть индексатор, принимающий аргумент Range, или метод Slice с двумя параметрами типа int.

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1450. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Продолжение
Предыдущие части: 1, 2-3, 4

5. Обязательные члены (включено в релиз)
Раньше вы полагались практически исключительно на конструкторы классов, чтобы убедиться, что объекты созданы в правильном состоянии. Сегодня мы часто работаем с более легкими конструкциями, такими как автоматически реализуемые свойства в записях:

public record Employee
{
  public string Name { get; init; }
  public decimal Salary { get; init; }
  public DateTime Hired { get; init; }
}

И когда мы создаём экземпляры таких легковесных объектов, нам нравится использовать инициализаторы:

var newGuy = new Employee
{
  Name = "Dave Bowman",
  Salary = 100000m,
  Hired = DateTime.Now()
};

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

public record Employee
{
  public required string Name { get; init; }
  public decimal Salary { get; init; }
  public DateTime Hired { get; init; }
}

Теперь компилятор не позволит вам написать код, который создаёт Employee без задания свойства Name.

См. также: Подробнее об Обязательных Членах Класса в C#11

6. Параметры с проверкой на null (удалено из релиза)
Как и многие удалённые функции C#, автоматическая проверка параметра на null предлагалась и раньше, но её недостатки так и не были полностью устранены. Идея состояла в том, чтобы избавить методы от многословной проверки параметров и выброса ArgumentNullException с помощью оператора !!. И программисты тут же разделились на тех, кто был от неё в восторге, и тех, кто сразу её возненавидел. Возник вопрос: стоит ли создавать новый оператор только ради одного маленького удобства?

Идея была представлена ещё во времена C# 8. И изначально казалась прекрасной, хотя .NET 6 добавил удобный метод ArgumentNullException.ThrowIfNull(), который тоже хорошо справляется со своей задачей. Т.е. вместо:

public UpdateAddress(int id, Address address)
{
  if (address == null)
  {
    throw new ArgumentNullException("address");
  }
  ...
}

Вы можете написать:

public UpdateAddress(int id, Address address)
{
  ArgumentNullException.ThrowIfNull(address);
  ...
}

Создатели языка рассмотрели первоначальные отзывы об операторе !!. Большинство из них были положительные, но не подавляющее большинство, как это обычно необходимо для функций с таким широким применением. И в итоге они решили, что лучше всего будет удалить её из релиза C# 11.

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1451. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Окончание
Предыдущие части: 1, 2-3, 4, 5-6

7. Статические абстракции в интерфейсах (официально включено в язык)
Реализация уже была в C#10 в виде превью. Но в C# 11 она реализована официально как часть языка. В C# 8 добавлена возможность помещать статические элементы в интерфейс, но интерфейс должен был включать код реализации. В C#10 статические члены могут быть абстрактными, поэтому реализующий их класс может предоставить собственную реализацию. Звучит красиво, но немного сложно, пока вы не рассмотрите некоторые потенциальные варианты использования. Одним из наиболее востребованных является обобщённая математика, которая позволяет использовать операторы (реализованные как статические методы) для обобщённых типов.

8. Типы, ограниченные файлом (включено в релиз)
Добавлен новый модификатор доступа file. Вы можете использовать его в классе или другом типе так же, как вы используете private или public:

file class CanvasUtils { … }
public class Canvas { … }

file делает тип доступным для кода в том же файле, но больше нигде. В примере выше класс Canvas может использовать CanvasUtils, если они находятся в одном файле.

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

9. Полуавтоматически реализуемые свойства (отложено)
Ключевое слово field изначально планировалось для C#10, и даже было продемонстрировано на нескольких докладах Microsoft. Но эта функция не вошла в C#10, а теперь проблемы с реализацией не позволили ей попасть в C#11.

Идея проста. Сегодня автоматически реализуемые свойства C# экономят значительный объём работы, но удобны не во всех сценариях. А когда они не работают, вам нужно вернуться к стандартной реализации свойств со всем шаблонным кодом для получения и установки. Ключевое слово field устраняет некоторые из этих ограничений, позволяя вам получить доступ к полю в автоматически реализуемом свойстве:

public class Employee
{
  public string Name
  { 
    get; 
    set => field = value.Trim();
  }
}

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

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

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1452. #юмор
А как вы оцениваете?
Кстати, про стори-пойнты есть вот тут.

День 1453. #Карьера
Улучшаем Эмоциональный Интеллект. Часть 5
Эмоциональный интеллект – это способность понимать эмоции и управлять ими, бесценное качество, которое поможет стать более продуктивными и улучшить отношения с другими. Вот простые правила, которые помогут развить ваш эмоциональный интеллект.

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

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

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

Здесь мы сосредоточимся на доброжелательности.

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

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

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

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

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

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

Источники:
- https://www.inc.com/justin-bariso/how-to-increase-emotional-intelligence.html
- https://www.inc.com/justin-bariso/emotional-intelligence-personality-big-5-how-to-be-authentic.html