День 1424. #Оффтоп #ЗадачиНаСобеседовании
Больше недели думал, писать ли что-нибудь про ChatGPT. Если кто не знает, что это, вот описание из русской Википедии:
«ChatGPT — это прототип чат-бота с искусственным интеллектом, разработанный OpenAI и специализирующийся на диалогах. ChatGPT — большая языковая модель, отлаженная как с помощью методов обучения с учителем, так и с подкреплением. Базовой моделью, которая была доработана, была языковая модель от OpenAI GPT-3.5, улучшенная версия GPT-3.
ChatGPT был запущен 30 ноября 2022 года и привлёк внимание своими подробными ответами и четкими формулировками, хотя его фактическая точность подверглась критике.»

Сам его пока не ковырял, не было времени, а отзывы в программистской среде пока самые разнообразные от восторженно-панических «программисты больше не нужны» до скептически-злорадных «да там косяк на косяке». Но сегодня всё-таки поделюсь пока самым впечатляющим из того что я видел. Видео от Клемента Михайлеску, создателя платформы AlgoExpert.io, которая предлагает задачи для собеседований на кодирование.

Клемент задал боту задачи «как есть», так, как они описаны на его сайте, предварительно дав ему контекст: «Ты проходишь собеседование в Google с написанием кода». Всего было 3 алгоритмических задачи разного уровня: простой, посложнее и самый сложный. Как сказал Клемент, если первые две задачи довольно стандартные и решения можно найти в сети, то третья (опять же, по его словам) в сети не встречается.

В общем, что из этого вышло, смотрите в новом видео от Клемента Михайлеску https://youtu.be/gOf2SQVMUL0

PS: Кстати, кому интересно, можете запаузить видео и попробовать решить сами.

День 1426. #ЗаметкиНаПолях
Добавляем Все Проекты в Решение с Помощью CLI
Допустим, по какой-то причине вам нужно быстро создать файл решения Visual Studio, включающий все проекты во всех подпапках. Как вариант, может быть нужно быстро рассчитать метрики кода для всего репозитория GitHub или вы просто хотите увидеть все проекты в одном месте. Может быть утомительно находить и добавлять каждый файл csproj в каждой подпапке вручную, особенно в кодовой базе, с которой вы не знакомы.

Команда dotnet sln
Файлы решений .NET можно создавать из командной строки. Синтаксис довольно прост:

dotnet new sln -n Everything

В приведённом выше примере флаг -n позволяет указать имя; в противном случае по умолчанию будет использоваться текущее имя папки. Результатом этой команды является пустой файл решения с именем Everything.sln.

Далее вам просто нужно добавить все файлы проекта. К сожалению, нет встроенного способа сделать это с помощью команды dotnet sln, но вы можете легко написать это в сценарии. Следующая команда должна работать из Powershell или в Linux:

dotnet sln add (ls -r **/*.csproj)

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

Если у вас уже есть файл решения в папке, из которой вы запускаете команду, вам просто нужно указать имя файла решения в команде. Например, если файл решения называется Everything.sln, запустите следующую команду:

dotnet sln ./Everything.sln add (ls -r **/*.csproj)

Источник: https://ardalis.com/add-all-projects-to-solution/

День 1427. #УправлениеПроектом
Как Ускорить Конвейер Разработки ПО
Приоритетом в конвейере разработки ПО является скорость. Независимо от типа ПО, над которым вы работаете, скорость работы команды будет превыше всего. При этом необходимо знать некоторые стратегии, чтобы ускорить работу команды без ущерба для качества или безопасности кода. Вот советы, призванные помочь командам работать максимально быстро и эффективно.

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

2. Установите лимиты незавершенной работы
Сейчас большинство конвейеров разработки ПО соответствуют методологиям управления проектами Kanban или Scrum для отслеживания задач проекта на различных стадиях завершения. Эти элементы незавершенной работы (Work-In-Progress) помогают следить за прогрессом команды и её способностью выполнять больше работы.
Проблема в том, что часто этот список разрастается и выходит из-под контроля. Тогда члены команды пытаются работать в режиме многозадачности, переключаясь между различными элементами, чтобы попытаться избавиться от невыполненной работы. При этом темп работы команды обычно замедляется, а ошибки начинают проникать в код.
Люди плохо справляются с многозадачностью. Решение в том, чтобы не дать им этого сделать. Установка жёстких ограничений на количество элементов WIP, на каждом этапе рабочего процесса гарантирует, что члены команды не откусят больше, чем могут прожевать, и выполнят больше задач за меньшее время.

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

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

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

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

Источник: https://www.freecodecamp.org/news/how-to-speed-up-your-software-development-pipeline/

День 1428. #ЧтоНовенького
Пишем Markdown в Visual Studio
Markdown — отличное решение для форматирования кода. GitHub использует его для файлов readme, a Microsoft - в качестве стандарта для документации Visual Studio.

Редактор Markdown должен быть включен и доступен, если вы обновились до последней превью версии VS 17.5. Его можно включить и отключить в меню Tools > Options > Preview Features (Инструменты > Параметры > Функции предварительного просмотра), отметив или сняв флажок “Markdown language service” (Сервис языка Markdown).

Вот некоторые функции редактора Markdown:
- Семантическая подсветка синтаксиса в редакторе.
- Форматирование текста применяется прямо в редакторе.
- Окно предварительного просмотра, которое можно вызвать по Shift+F7.
- Большинство стандартных элементов управления редактора Visual Studio работают и в редакторе Markdown.

Источник: https://devblogs.microsoft.com/visualstudio/write-markdown-without-leaving-visual-studio/

День 1429. #ЗаметкиНаПолях
Создание Дампа при Зависании Тестов на CI-машине
Когда на вашем компьютере возникают проблемы, отлаживать их просто, так как вы можете легко подключить отладчик и посмотреть, что происходит. Но если тесты зависают в CI/CD конвейере подключить отладчик не так просто. Приходится искать альтернативный способ отладки проблемы.

dotnet test имеет много полезных опций. Одной из них является --blame-hang, которая позволяет сделать дамп процесса и всех дочерних процессов, когда тест зависает. Вы можете настроить желаемый тайм-аут и тип дампа, который хотите сделать. Затем можно загрузить дамп в артефакты сборки и проанализировать его локально:

dotnet test 
 --blame-hang-timeout 5m 
 --blame-hang-dump-type full

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

Если вы используете CI, например GitHub Actions, вы можете загрузить файл дампа как артефакт:

name: sample
on:
  workflow_dispatch:
  push:
    branches:
      - '*'

jobs:
  run_test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run tests
      run: dotnet test a.sln --configuration Debug --blame-hang-timeout 30s

    - uses: actions/upload-artifact@v3
      if: always()
      with:
        name: results
        retention-days: 1
        path: TestResults/**/*

Источник: https://www.meziantou.net/generating-a-dump-file-when-tests-hang-on-a-ci-machine.htm

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

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

Для этого используется трехэтапный метод:
1. Мотивация
Если вы хотите изменить привычку, вы должны быть должным образом мотивированы, т.е. полностью убеждены в том, что привычку нужно изменить, и искренне хотеть её изменить.
Для этого нужно найти своё «почему». Почему вы хотите (и должны) изменить эту привычку? Какие преимущества вы получите, если добьётесь успеха?
Например, вы хотите проводить больше времени с семьей и укреплять важные отношения вне работы. А также улучшить здоровье, если сможете снизить уровень стресса, больше спать и с удовольствием проводить выходные.
Для этого нужно перестать брать на себя чрезмерные обязательства и установить чёткие границы между работой и остальной жизнью.

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

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

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

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

День 1431.
Подводим итоги года. Поиграем в бинго? Присылайте свои ответы.

PS: Win+Shift+S для снимка экрана, потом в уведомлениях Snip & Sketch для рисования на нём.

День 1432.
Это был трудный год. Ой, это не оттуда.
Дорогие подписчики. От всей души поздравляю вас с новым годом! Чистого вам кода без багов, зелёных тестов, адекватных и щедрых заказчиков. Пусть всё у вас получается и удаётся.

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

Правило L.A.U.G.H
Если вы страдаете от синдрома самозванца, вам поможет правило L.A.U.G.H. Оно отвергает распространённый совет «притворяться, пока не получится». Вместо этого оно побуждает придерживаться установки на рост, оттачивать свой уникальный опыт и делиться им.

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

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

3. Понимайте (Understand)
Продолжая экспериментировать снова и снова, вы начнёте замечать закономерности. Продолжая пробовать, анализировать, учиться, вы начнёте видеть, что работает, а что нет. Сделайте это достаточное количество раз, и у вас появятся идеи, которых нет у других.

4. Растите (Grow)
Вот где многие ошибаются. Как только они понимают, как что-то работает, они перестают учиться. Они становятся «всезнайками». Не делайте этого. Никогда не считайте себя экспертом. Всегда считайте себя студентом. Это позволит вам продолжать совершенствовать процесс, чтобы продолжать адаптацию и дальше расти.
Шаги с первого по третий помогут вам опередить большинство других. Но четвёртый шаг поместит вас в один процент лучших.

5. Помогайте (Help)
Теперь вы в состоянии помогать другим. Вы удивитесь, что это не занимает так много времени, как вы думаете. В нескольких шагах позади вас всегда есть люди, которые могут извлечь пользу из того, что вы уже узнали. Но вы даже можете помочь тем, кто более опытен, потому что вы привносите уникальную точку зрения, уникальный опыт. Так вы продолжите привлекать к себе других.

Если вы похожи на меня, всякий раз, когда вы пробуете что-то новое, вы всё равно будете бороться с теми же чувствами. Та же самая неуверенность, тот же голос, который кричит: «Ты не достоин». Но вот что нужно помнить.
Люди, которых вы считаете лучше вас, - они такие же, как вы. У них есть сильные стороны, слабости, страхи. В чём-то они хороши, в чём-то нет.
Так что, если вы чувствуете себя маленькой рыбкой в большом аквариуме, не следуйте правилу «притворись акулой, пока ей не станешь». Вместо этого применяйте правило L.A.U.G.H и докажите, что вы достойны.

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

День 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/