День девятьсот тридцать восьмой. #Курсы
10 Фактов о Microsoft Learn, Которые Полезно Знать
В Microsoft Learn есть ресурсы, необходимые для развития ваших навыков, а также инструменты, которые помогут вам добиться большего для вашей команды, вашей организации и вашей карьеры. Вот 10 фактов о Microsoft Learn, которые вам следует знать:

1. Учитесь бесплатно, в удобном для вас темпе
Вы можете бесплатно получить доступ к интерактивным материалам для самостоятельного обучения и учиться в удобном для вас темпе и в удобное для вас время.

2. Практикуйтесь во время обучения
Получите практический опыт, используя бесплатную песочницу, позволяющую работать со службами Microsoft Azure без платной подписки. Материалы для самостоятельного обучения включают упражнения, которые научат вас создавать в Azure реальные вещи, такие как Функции Azure или запускать виртуальные машины.

3. Изучите контент для всех уровней квалификации
Microsoft Learn предназначена не только для работающих технических специалистов, но и для студентов и тех, кто плохо знаком с технологиями. Вы можете фильтровать учебный контент и сертификаты по уровню - начальный, средний и продвинутый. Если вы студент, приобретите технические навыки на будущее с помощью Microsoft Learn для студентов.

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

5. Планируйте курсы под руководством инструктора
Если вы предпочитаете углублённое, структурированное обучение с поддержкой технических экспертов, запланируйте учебные курсы под руководством инструктора, предлагаемые авторизованными партнерами Microsoft Learning. Ищите курсы в Microsoft Learn, фильтруйте по местоположению и времени, исследуйте виртуальные курсы и оформляйте заказ на партнёрском веб-сайте. Обратите внимание, что эта функция находится в стадии бета-тестирования и в настоящее время доступна для ограниченного числа курсов.

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

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

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

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

10. Смотрите телевизор и учитесь
У Microsoft Learn есть телеканал Learn TV. Смотрите прямые трансляции, шоу и обучающие видеоролики, чтобы узнать, как создавать решения с использованием продуктов Microsoft, от экспертов, которые эти продукты создали.

Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/10-facts-you-should-know-about-microsoft-learn/ba-p/2038073

День девятьсот тридцать девятый. #ЧтоНовенького
Превью Функции в .NET 6. Начало
В .NET 6 представлены несколько новых функций, пока в виде превью. Это значит, что они не поддерживаются для использования в производственной среде в .NET 6. Они пока выпущены для оценки сообществом и предоставления обратной связи относительно сценариев их использования и возможных улучшений.

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

1. Статические абстрактные члены интерфейсов
Как видно из названия, это означает, что теперь вы можете объявлять статические абстрактные методы как часть интерфейса и реализовывать их в производном типе. Простой, но мощный пример этого - IParseable, который позволяет определять контракт парсинга строки для создания данного типа:

public interface IParseable<TSelf>
    where TSelf : IParseable<TSelf> {
  static abstract TSelf Parse(
    string s,
    IFormatProvider? provider);
  
  static abstract bool TryParse(
    [NotNullWhen(true)] string? s, 
    IFormatProvider? provider,
    out TSelf result);
}

public readonly struct Guid : IParseable<Guid>
{
  public static Guid Parse(
    string s, IFormatProvider? provider)
  {
    /* Реализация */
  }

  public static bool TryParse(
    [NotNullWhen(true)] string? s, 
    IFormatProvider? provider, out Guid result)
  {
    /* Реализация */
  }
}

Особенности:
- Теперь вы можете объявлять элементы интерфейса, которые одновременно являются статическими и абстрактными.
- В настоящее время это не поддерживается для методов интерфейса с реализацией по умолчанию, поэтому сочетание static virtual не является допустимой комбинацией.
- Эта функциональность доступна только для интерфейсов, она недоступна для других типов, таких как абстрактный класс.
- Эти члены недоступны через интерфейс, то есть IParseable<Guid>.Parse(someString, null) приведет к ошибке компиляции.

Поясним последний пункт. Обычно абстрактные или виртуальные члены вызываются через какую-либо виртуальную диспетчеризацию (при полиморфном использовании). Для статических методов у нас нет объекта или экземпляра, поэтому среда выполнения не сможет определить, что IParseable<Guid>.Parse(…) должно разрешиться в Guid.Parse. Чтобы это работало, нужно где-то указать фактический тип, и это можно сделать с помощью дженериков:

public static T InvariantParse<T>(string s)
    where T : IParseable<T>
{
  return T.Parse(s, CultureInfo.InvariantCulture);
}

В этом случае среда выполнения может определить, какой метод Parse следует разрешить, подсмотрев его на конкретном используемом T. Если пользователь указал InvariantParse<int>(someString), он будет преобразован в метод Parse из System.Int32. А InvariantParse<Guid>(someString) будет преобразован в метод Parse из System.Guid и так далее.

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

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

Источник: https://devblogs.microsoft.com/dotnet/preview-features-in-net-6-generic-math/

День девятьсот сороковой. #ЧтоНовенького
Превью Функции в .NET 6. Продолжение
Начало

2. Обобщённая математика
Одна из давно востребованных функций .NET - это возможность использовать операторы для обобщённых типов. Нововведение добавляет возможность писать обобщённый код относительно, например, числовых типов, на которые наложены ограничения в виде интерфейсов с нужными операторами. Таким образом, алгоритмы могут выражены в следующем виде:
// Интерфейс определяет статические свойства и операторы

interface IAddable<T> where T : IAddable<T>
{
  static abstract T Zero { get; }
  static abstract T operator +(T t1, T t2);
}

// Классы и структуры (включая встроенные) реализуют интерфейс
struct Int32 : …, IAddable<Int32>
{
  public static Int32 operator +(Int32 x, Int32 y)
    => x + y;
  public static Int32 Zero => 0;
}

// Обобщённые алгоритмы могут использовать статические члены типа Т
public static T AddAll<T>(T[] ts)
  where T : IAddable<T>
{
  // вызов статического свойства
  T result = T.Zero;
  // вызов статического оператора +
  foreach (T t in ts) { result += t; }
  return result;
}

Это стало возможным благодаря появлению нескольких новых статических абстрактных интерфейсов, которые соответствуют различным операторам, доступным для языка, и предоставлению нескольких других интерфейсов, представляющих обобщённые функции, такие как синтаксический анализ или обработка чисел. Интерфейсы были разработаны для расширяемости и повторного использования и поэтому обычно представляют лишь отдельные операторы или свойства. Например, в одном интерфейсе не используются парные операции, такие как умножение и деление, поскольку они подходят не для всех типов. Matrix4x4*Matrix4x4 является допустимым, а Matrix4x4/Matrix4x4 - нет. Кроме того, интерфейсы обычно позволяют типам исходных данных и результата различаться, чтобы поддерживать такие сценарии, как double = TimeSpan/TimeSpan или Vector4 = Vector4*float.

Вот некоторые из новых интерфейсов:
- INumber – члены общие для числовых типов,
- IFloatingPoint – члены общие для чисел с плавающей точкой,
- IAdditionOperators – x+y,
- ISubtractionOperators – x–y,
- IMultiplyOperators – x*y,
- IDivisionOperators – x/y,
- IComparisonOperators – x<y, x>y, x<=y и x>=y,
- IEqualityOperators – x==y и x!=y,
- IIncrementOperators – ++x и x++.

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

Источники:
- https://devblogs.microsoft.com/dotnet/preview-features-in-net-6-generic-math/
- https://habr.com/ru/post/572902/

День девятьсот сорок первый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
96. Ваши Клиенты Говорят Не То, Что Думают
Я никогда не встречал клиента, который не был бы счастлив описать мне в деталях, что он хочет. Проблема в том, что клиенты не всегда говорят вам всей правды. Обычно они не лгут, но говорят на языке клиентов, а не разработчиков. Они используют свои термины и контекст. Они не учитывают важные детали. Они предполагают, что вы проработали в их компании 20 лет, как и они. Это усугубляется тем фактом, что многие клиенты вообще не знают, чего хотят! Некоторые имеют представление о «большой картине», но редко могут хорошо рассказать о деталях. Другие могут вообще слабо представлять, что хотят, но твёрдо знать, чего они не хотят. Так как же вы можете доставить программный продукт тому, кто не говорит вам всю правду о том, чего он хочет? Это довольно просто. Просто больше взаимодействуйте с ними.

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

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

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

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Nate Jackson

День девятьсот сорок второй. #юмор
Знакомо?

День девятьсот сорок третий. #ЗаметкиНаПолях
Почему Вы Всегда Должны Разрабатывать в Среде "Development" в ASP.NET
В .NET Core/5+ появилось понятие «среды». Среды используются для описания различных этапов на пути к производственному коду. Например, локальная разработка, тестирование, staging, production и т.д. У вас может быть неограниченное количество сред, и нет никаких правил о том, как вы их называете. Или есть?

Недавно я помогал коллеге решить проблему, которая возникала только в одной среде (первом этапе CD в Azure). В других средах проблем не было. Возникала ошибка “Cannot Consume Scoped Service From Singleton“ (Невозможно Получить Scoped Сервис из Синглтон Сервиса). В общем-то решить её было довольно просто, но почему же она возникала только в этой среде?

«Известные» среды в .NET
Как сказано выше, правил именования сред в .NET нет. Однако, существуют 3 «предустановленные» среды: Development, Staging и Production. Мы даже можем использовать в коде специальные методы:

env.IsDevelopment();
env.IsProduction();
//Проверяет, называется ли текущая среда Test1
env.IsEnvironment("Test1"); 

На самом деле, под капотом IsDevelopment просто вызывает IsEnvironment(“Development”). Вроде всё логично.

Возвращаясь к проекту. Там среда разработки называлась “Local”, а первый этап CD в Azure назывался “Development”. Таков был корпоративный стандарт, вроде никаких проблем возникать не должно, просто используем

env.IsEnvironment("Local");

вместо

env.IsDevelopment();

Проверки на IsDevelopment во фреймворке
А что там в коде собственно .NET, написанном Microsoft? В принципе уже должно быть очевидно: проблема в том, что Microsoft ожидает, что среда вашей локальной разработки будет называться именно «Development». Не «Local», не «Dev», не «DevMachine», а «Development». Даже когда мы создаём новое веб-приложение ASP.NET Core, мы получаем шаблонный код, который выглядит так:

if (env.IsDevelopment())
{
  app.UseDeveloperExceptionPage();
}

Поэтому я полез в исходный код .NET (как же хорошо иметь исходники!), и нашёл это:

bool isDevelopment = context.HostingEnvironment.IsDevelopment();
options.ValidateScopes = isDevelopment;
options.ValidateOnBuild = isDevelopment;

Установка ValidateScopes в true фактически запускает проверку захвата сервисов и выдаёт упомянутое выше исключение «Cannot use scoped service from singleton». Поскольку среда разработки называлась «Local», а среда CD - «Development», мы видели исключение только в CD.

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

Источник: https://dotnetcoretutorials.com/2021/08/06/why-you-should-always-use-asp-net-development-environment-for-local-development/

День девятьсот сорок четвёртый. #Оффтоп
Советы по Улучшению Ваших Навыков Разработки в .NET. Начало

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

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

«Если вы знаете врага и знаете себя, вам не нужно бояться результата сотни сражений. Если вы знаете себя, но не знаете врага, при каждой одержанной победе вы также будете терпеть поражение. Если вы не знаете ни врага, ни себя, вы проиграете в каждой битве».
- Сунь-цзы, Искусство войны

Зная себя и свои инструменты, вы сможете привести свои программные проекты к успеху. По крайней мере, я так понимаю смысл этой цитаты.

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

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

В последние несколько лет я стал использовать функциональное программирование среди других инструментов разработки. Что мне нравится в этой парадигме, так это то, что вам нужно отделить поведение от собственно данных. Структуры данных могут явно инкапсулировать лишь небольшие фрагменты бизнес-логики. Поскольку определение типа в языках типа F# требует минимальных затрат и церемоний, часто можно встретить множество типов.

Когда я освоился с F#, я заметил, что нахожу время, чтобы продумать, как должны формироваться данные. Не только форма имеет значение, но и её характеристики и то, как она будет связана с другими компонентами. Будучи более строгим языком, чем C#, F# заставляет меня тратить больше времени на обдумывание и проектирование того, как части будут объединены для достижения своей цели (целей). Когда я вижу, что часть данных становится слишком сложной, я быстро разбиваю её на более мелкие компоненты, чтобы чтение кода было менее утомительным для тех, потребуется понять предназначение системы/приложения.

Это оказывает существенное влияние на подход к созданию ПО. Я применял эту концепцию всякий раз, когда разрабатывал ПО на C# или другом языке. Кроме того, выявление взаимосвязей в данных поможет вам во многих отношениях. Тот, кто будет поддерживать код сможет легче понять разницу между построением отношений и реальной бизнес-логикой. Улучшение жизни тех, кто читает ваш код, улучшает вас как разработчика. Вы продемонстрируете черту великих разработчиков: эмпатию к коллегам.

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

Источник: https://kevinavignon.com/2020/12/23/guidelines-to-improve-your-software-design-skills-with-net-part-i/
Автор оригинала: Kevin Avignon

День девятьсот сорок пятый. #Оффтоп
Советы по Улучшению Ваших Навыков Разработки в .NET. Продолжение
Начало

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

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

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

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

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

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

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

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

Источник: https://kevinavignon.com/2020/12/23/guidelines-to-improve-your-software-design-skills-with-net-part-i/
Автор оригинала: Kevin Avignon

День девятьсот сорок шестой. #Оффтоп
Советы по Улучшению Ваших Навыков Разработки в .NET. Продолжение
Начало
Продолжение

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

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

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

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

6. Несмотря на гибкость, List<T> не всегда будет лучшей коллекцией для использования
Изучение структур данных - это ключевой компонент, который поможет вам постоянно совершенствоваться. От вас всегда ждут, что вы понимаете, как всё работает под капотом. От вас требуется глубокое понимание кода и систем, которые вы разрабатываете или обслуживаете. Использование правильной структуры данных может быть разницей между быстро и медленно работающим алгоритмом. Как разработчик вы бы не хотели создать систему, которая не может обрабатывать большой объём данных из-за плохой реализации.

Современные языки, такие как C#, позволяют разработчикам безболезненно писать плохо продуманный код. Например, из коллекций можно всегда использовать только List<T>. Почему это плохо? Отличный вопрос, особенно потому, что ваша IDE не предупреждает вас о том, что вы, вероятно, могли бы сделать лучше.

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

Возвращаясь к List<T>. Он удобен, если вы не знаете заранее размер нужного вам массива. Но в нём нет никакой магии. Под капотом он выделяет всё тот же массив (по умолчанию из 4х элементов). Когда место в нём заканчивается, этот массив копируется в новый, в 2 раза больше. Это важно понимать, что вы будете выделять избыточную память для вашей коллекции данных, добавляя элементы, каждый раз, когда вы достигаете предела ёмкости коллекции. Если у вас есть возможность узнать размер коллекции в момент инициализации, лучше всего его предоставить.

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

Источник: https://kevinavignon.com/2020/12/23/guidelines-to-improve-your-software-design-skills-with-net-part-i/
Автор оригинала: Kevin Avignon

День девятьсот сорок седьмой. #Оффтоп
Советы по Улучшению Ваших Навыков Разработки в .NET. Окончание
Начало
Продолжение
Продолжение

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

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

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

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

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

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

В заключение
- Разработчики ПО должны понимать все, что связано с приложением, которое они разрабатывают/обслуживают.
- При реализации кода проявляйте эмпатию. Человек, исправляющий ошибку в этом коде, может быть вами, но спустя 3 года. К тому времени вы забудете, о чём думали, когда писали этот код.
- Убедитесь, что понимаете компромиссы по объёму данных и времени, решая, какой подход лучше подходит для решения проблемы. Здесь не существует серебряной пули. Выберите один вариант и живите с этим.
- Не переусердствуйте с проектированием функции/класса/архитектуры ПО. Это может сделать будущие итерации разработки нестабильными и затруднить внесение изменений.
- Реализация без тестов производительности - это просто мнение разработчика о его ощущения. Вы не можете утверждать, что ваш код быстрый, без каких-либо подтверждающих фактов. Используйте BenchmarkDotNet для исследования производительности.
- Постарайтесь сначала разобраться в проблеме и подумать об альтернативных подходах, прежде чем бросаться за реализацию.
- При оптимизации решения нужно учесть множество факторов и соображений. Например, имеет ли смысл тратить месяц на рефакторинг кода, когда компания спешит стать первым приложением на рынке?

Источник: https://kevinavignon.com/2020/12/23/guidelines-to-improve-your-software-design-skills-with-net-part-i/
Автор оригинала: Kevin Avignon

День девятьсот сорок восьмой. #ЧтоНовенького
IEnumerable.Chunk() в .NET 6
В .NET 6 для IEnumerable<T> появился новый метод расширения Chunk(size). Этот метод на самом деле довольно простой, но в то же время мощный. На данный момент .NET 6 находится в предварительной версии. И заметьте, что эта функция доступна только в .NET 6. Ни в .NET 5, ни в .NET Core 3.1, ни в любой другой версии.

Итак, мы можем написать такой код:

var list = Enumerable.Range(1, 100);
var chunkSize = 10;
//Делим коллекцию на части по 10
foreach(var chunk in list.Chunk(chunkSize)) 
{
  foreach(var item in chunk)
    Console.WriteLine(item);
}

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

var list = Enumerable.Range(1, 100);
foreach(var chunk in list.Chunk(10)) 
{
  Parallel.ForEach(chunk, (item) =>
  {
    //параллельная обработка
  });
}

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

Вы, наверное, думаете, а почему не использовать Skip иTake? Можно, но метод Chunk более лаконичен и делает код немного более читаемым.

Источники: https://dotnetcoretutorials.com/2021/08/12/ienumerable-chunk-in-net-6/

День девятьсот сорок девятый. #Оффтоп
Сегодня порекомендую вам развлекательное и ностальгическое видео с канала Dave’s Garage. На этот раз бывший разработчик Microsoft рассказывает о создании легендарной игры Pinball, в котором он принимал участие. Как игра создавалась, какие проблемы возникали, почему её нет в последних версиях Windows, и как её всё-таки можно туда добавить.

https://youtu.be/ra3-DPAJFfc

День девятьсот пятидесятый. #ЗаметкиНаПолях
Относитесь к Интеграционным Тестам Как к Внешним Потребителям
В ASP.NET Core есть отличная поддержка для написания интеграционных тестов. Они используются, например, при создании API, чтобы убедиться, что вы не нарушаете публичные контракты при разработке.

Допустим, у нас есть контроллер, выдающий информацию о гамбургере:

public class HamburgersController : ControllerBase
{
  [HttpGet("{name}")]
  public ActionResult<HamburgerDto> Get(string name)
  {
    var burger = new HamburgerDto();
    // получение информации
    // …
    return new OkObjectResult(burger);
  }
}

public class HamburgerDto
{
  public string Name { get; set; }
}

Мы создаём интеграционный тест, чтобы убедиться, что конечная точка работает должным образом, например, выдаёт 200 OK. И ещё один тест, который проверяет, что тело ответа содержит название гамбургера (тестирование контракта):

public async Task ShouldReturnBurgerName()
{
  // запрос к контроллеру
  // …
  var burger = await JsonSerializer
    .DeserializeAsync<HamburgerDto>(
      response, 
      new JsonSerializerOptions(JsonSerializerDefaults.Web));

  burger.Name.ShouldBe("Big Mac");
}

Тест работает отлично, но у него есть одна серьезная проблема. Выше мы говорили, что этот тест предназначен, чтобы проверить, не нарушаем ли мы контракт. Представьте, что нам нужно переименовать свойство Name в HamburgerName (критическое изменение в контракте). Если мы используем инструмент рефакторинга, который автоматически переименует свойство во всех местах, где оно используется, вышеуказанный тест обновится автоматически и все равно будет проходить:

…
burger.HamburgerName.ShouldBe("Big Mac");
… 

Проблема в том, что мы десериализуем ответ в класс HamburgerDto. Мы привязываем наш интеграционный тест к деталям реализации нашего API.

Вместо десериализации ответа в HamburgerDto мы можем использовать JsonDocument:

public async Task ShouldReturnBurgerName()
{
  // запрос к контроллеру
  // …
  var burger = await 
    JsonDocument.ParseAsync(response);

  burger.RootElement
    .GetProperty("name").GetString()
    .ShouldBe("Big Mac");
}

Теперь, если бы мы изменили свойство Name на HamburgerName, вышеуказанный тест не прошёл бы. Это делает тест более похожим на внешнего потребителя нашего API. Используя такой подход, мы можем предотвратить внесение критических изменений в производственный код.

Источник: https://josef.codes/treat-you-integration-tests-as-external-consumers/

День девятьсот пятьдесят первый. #ЧтоНовенького
Улучшения Работы с Файлами в .NET 6
В .NET 6 класс FileStream станет намного быстрее и надёжнее благодаря тому, что его почти полностью переписали. Также улучшены функций ввода-вывода: одновременное чтение и запись, сбор статистики и представлены новые API для них.

Поиск и позиция в файле
Узкие места производительности в методах FileStream.ReadAsync() и FileStream.WriteAsync() были вызваны тем фактом, что, когда FileStream открыт для асинхронного ввода-вывода, он синхронизировал смещение файла с Windows для каждой асинхронной операции. Решено перестать это делать, отслеживать смещение только в памяти и использовать системные вызовы, с явным указанием смещения файла. Это сделано как для Windows, так и для Unix. Это привело к улучшению производительности от 10 до 100 раз в Windows и около 25 раз в Unix.

Length
Кэширование значения FileStream.Length при открытии файла только для чтения приводит к почти мгновенному возврату значения из памяти после первого вызова в Windows. Для Unix нет гарантии, что файл не будет изменён кем-то другим во время чтения, поэтому там эта оптимизация не применяется.

WriteAsync
По советам сообщества, для Windows была переделана логика вызова функции WriteFile, которая больше не предполагает увеличения размера файла перед вызовом (WriteFile способна делать это автоматически). Кроме того, снижено потребление памяти за счёт использования ValueTask. Это позволило ускорить производительность в отдельных случаях до 5 раз, и на порядок уменьшить размер потребляемой памяти. В Unix скорость работы не сильно изменилась, но потребление памяти также удалось значительно снизить.

ReadAsync
Как упоминалось выше, удалось сократить количество системных вызовов для определения позиции в файле, поэтому даже для файлов, открытых со способом доступа ReadWrite, скорость чтения увеличилась до 2,5 раз. И, аналогично WriteAsync, за счёт использования ValueTask объём потребляемой памяти, особенно при работе с большими файлами, сократился на несколько порядков.

Read и Write
Синхронные операции чтения и записи уже были практически в оптимальном состоянии. Для Windows изменили их работу, отказавшись от использования потока из пула и заменив его на выделение объекта EventWaitHandle. Таким образом удалось сократить скорость и потребление памяти на 30-50%.

Потокобезопасный ввод-вывод
Чтобы сделать это возможным, в .NET 6 Preview 7 представлены API, принимающие смещение в файле, и не сохраняющие состояние (класс System.IO.RandomAccess).

Используя API, запрашивающее смещение файла, можно использовать системные вызовы на основе смещения (pread()|pwrite() в Unix, ReadFile()|WriteFile() в Windows), которые не изменяют текущее смещение для данного дескриптора файла. Это позволяет выполнять потокобезопасные операции чтения и записи. Пример использования:

async Task ThreadSafeAsync(
   string path,
   IReadOnlyList<ReadOnlyMemory<byte>> buffers)
{
  // новый API (preview 6)
  using SafeFileHandle handle = 
    File.OpenHandle( 
      path, FileMode.Create, FileAccess.Write,
      FileShare.None, FileOptions.Asynchronous); 

  long offset = 0;
  for (int i = 0; i < buffers.Count; i++)
  {
    // новый API (preview 7)
    await RandomAccess.WriteAsync(
      handle, buffers[i], offset
    ); 
    offset += buffers[i].Length;
  }
}

Примечание: Новые API не поддерживают каналы и сокеты, поскольку в них отсутствует концепция смещения (позиции).

Источники: https://devblogs.microsoft.com/dotnet/file-io-improvements-in-dotnet-6

День девятьсот пятьдесят второй. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
97. Вам Сложно Изучать Программирование? Вот Почему. Начало
Вы слишком много раз пытались и сдались? Может, вы просто не годитесь для этого?

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

«Я никогда не смогу стать таким, как они», - думаете вы с благоговением. - «Как они научились это делать?»
Я скажу вам одно - они определенно не родились с умением программировать, и они не умнее вас.

Если вы увлечены тем, что требует знаний в области программирования (например, data science или теорией разработки программного обеспечения), вам действительно важно преодолеть этот страх. Боязнь программирования может сдерживать ваш прогресс долгие годы. Тем не менее, об этом мало кто говорит.

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

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

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

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

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

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

Источник: https://towardsdatascience.com/finding-it-difficult-to-learn-programming-heres-why-639024be0a13
Автор оригинала: Natassha Selvaraj

День девятьсот пятьдесят третий. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
97. Вам Сложно Изучать Программирование? Вот Почему. Окончание
Начало

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

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

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

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

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

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

Источник: https://towardsdatascience.com/finding-it-difficult-to-learn-programming-heres-why-639024be0a13
Автор оригинала: Natassha Selvaraj

День девятьсот пятьдесят четвёртый. #TipsAndTricks
Малоизвестные Способы Форматирования Строк
Про форматирование строк я уже писал на канале. И, казалось бы, какие тут могут быть сюрпризы? Давайте посмотрим.
Для краткости я буду приводить только формат в интерполированных строках. Всё то же самое будет работать и для string.Format(). Также в примерах я сразу буду использовать значения. Но имейте в виду, что слева от двоеточия может идти имя переменной.

1. Добавление нолей в начало числа:

$"{123:00000}"    // "00123"
$"{45:00000}"     // "00045"
$"{123456:00000}" // "123456"
$"{123:d5}"       // "00123"

2. Кастомный формат для цены:

$"{1234:$#,###.00}"    // "$1,234.00"
$"{12:$#,###.00}"      // "$12.00"
$"{1234.56:$#,###.00}" // "$1,234.56"

Здесь # – цифра или ничего, 0 – цифра или 0, запятая и точка – разделители тысяч и дробной части соответственно.

3. Формат номера телефона:

$"{79012345678:+#(###)###-##-##}"
//"+7(901)234-56-78"

Отформатировать телефон в американском формате с точками можно, экранировав их:

$"{18005551234:+# ###\\.###\\.####}"
//"+1 800.555.1234"

4. Форматирование процентов:

$"{1.23:##.00%}"  // "123%"
$"{1.23:##.00'%}" // "1.23%"

По умолчанию знак % умножает число на 100.

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

int x = int.Parse("1,345");

Чтобы правильно спарсить эту строку, используйте перечисление NumberStyles из System.Globalization:

int x = int.Parse("1,345", NumberStyles.AllowThousands);
// Результат: 1345

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

int x = int.Parse("$    +1,345.00   ",
  NumberStyles.Number | 
  NumberStyles.AllowCurrencySymbol);
// Результат: 1345

6. Как избежать боксинга
Как известно, string.Format приводит к боксингу переданных в него аргументов. Любители микрооптимизаций могут использовать вместо этого метод ToString, передав в него формат:

double x = 19.95;
string str1 = string.Format("{0:C}", x);
string str2 = x.ToString("C");

7. «Тетрарный» оператор
Сразу оговорюсь, что это название я выдумал по аналогии с тернарным оператором. string.Format может выводить различные значения, в зависимости от знака переданного аргумента: положительный, отрицательный или ноль. Для этого используется символ точки с запятой:

$"{4.2:positive;negative;zero}" //positive
$"{-2:positive;negative;zero}"  //negative
$"{0:positive;negative;zero}"   //zero

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

$"{0:yes;no}" // "yes"

Также можно использовать формат вывода:

$"{42:#.00;(#.00)}"  // "42.00"
$"{-42:#.00;(#.00)}" // "(42.00)"

Сколько из этих способов вы знали раньше? Пишите в комментариях.

Источники:
- https://blog.stevex.net/2007/09/string-formatting-faq/
- https://blog.stevex.net/string-formatting-in-csharp/

День девятьсот пятьдесят шестой. #Оффтоп
Вчера слушал очередную серию подкаста Dotnet Rocks про DDD. Сама по себе беседа была довольно интересной. В гостях были Steve "Ardalis" Smith и Julie Lerman.

Но заинтересовала меня другая вещь, которую они упомянули в начале разговора - OpenAI Codex. Не так давно я писал про утилиту Copilot в GitHub, которая генерирует код за вас. Идея в том, что вы пишете человеческим языком, что вы хотите сделать, а AI система генерирует код. Так вот OpenAI выпустили ролик, где демонстрируют, как это работает, и ролик просто взрывает мозг. Авторы за 8 минут создают полноценную (хотя и простенькую) аркадную игру, где космический корабль должен избегать столкновения с астероидом. Вся игра от начала до конца написана фразами вроде «Расположи астероид в случайном месте экрана» и «Пусть астероид двигается горизонтально и вертикально, отскакивая от границ экрана» (хотя, конечно, по-английски). После ввода каждой фразы система на лету генерирует JavaScript код и показывает результат его работы.

В общем, вот само видео. В нём нет никаких комментариев, но они и не нужны. https://www.youtube.com/watch?v=Zm9B-DvwOgw

А здесь ребята из OpenAI чуть подробнее, с комментариями, показывают, как работает Codex на нескольких примерах: страничка «Hello world», простая игра, плагин для MS Word.

Скайнет не за горами?

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

Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Начало
1. Разработка ПО - это решение проблем.
Быть программистом - это гораздо больше, чем сидеть перед компьютером и беспорядочно нажимать кнопки на клавиатуре. Это означает решать множество реальных проблем и облегчать жизни людей. Если вы способны это делать, вы не пропадёте.

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

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

4. У вас всё под рукой.
Сейчас уже не 50-е и даже не 90-е, когда нужно было идти в библиотеку, чтобы изучить какую-то тему. Вся необходимая информация всегда под рукой. Используйте свой мозг и интернет.

5. Для программирования не требуется топового оборудования.
Ультрасовременный процессор, огромное количество оперативной памяти и 5 мониторов - всё это необязательно. Ноутбука среднего уровня более чем достаточно, чтобы начать работу.

6. Необязательно хорошо разбираться в математике.
Программирование часто ассоциируется с гениями с IQ 200+. Серьёзная математика может потребоваться в таких темах, как искусственный интеллект, робототехника, криптография и т.д., но основной массе разработчиков она не нужна.

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

8. Идеальное время - сейчас.
Сохранение полезной статьи или курса в закладках - это просто один из вариантов прокрастинации. Лучше всего прочитать статью или пройти курс сейчас.

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

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

11. Воспринимайте ошибки как уроки.
Если вы посмотрите любую историю успеха, вы обнаружите, что на самом деле она состоит из попыток, ошибок и новых попыток чуть менее, чем полностью. Настойчивость и любопытство – ключи к победе.

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

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

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

15. Это марафон, а не спринт.
Область разработки постоянно развивается, поэтому приготовьтесь к непрерывному обучению. Если начать слишком активно, вы быстро устанете.

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

Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka

День девятьсот пятьдесят восьмой. #Оффтоп
Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Продолжение
Начало 1-15

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

17. Легко увлечься.
Быть активным в сообществе - это здорово, но имейте в виду, что там вы часто открываете новые более оптимизированные технологии, более современные API и фреймворки и т.п. Это не всегда означает, что ваш текущий стек плохой, и вам следует его менять.

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

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

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

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

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

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

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

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

26. Будьте скромным, и другие будут уважать вас.
Празднуйте свои достижения внутри, но скромнее выражайте эмоции. Хвастовство до добра не доведёт.

27. Перфекционизм замедлит вас.
Предпочитать качество количеству - это здорово. Но не переусердствуйте, иначе у вас останутся сотни незавершённых проектов.

28. Открытый исходный код - это здорово.
Открытый исходный код в последнее время распространился от мелких частных репозиториев до крупных компаний. Даже код .NET теперь открыт. Убедитесь, что вы изучаете передовой опыт и паттерны проектирования, используемые другими людьми.

29. Диплом не обязателен.
Клиентов больше волнуют не корочки, а ваше практическое умение решать их проблемы.

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

31. Корпорациям вы нужны для CRUD-приложений.
Сердце корпоративных приложений - это CRUD-операции. Учитесь и будьте готовы работать с ними ежедневно, если планируете там работать.

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

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

Источник: https://dev.to/madza/65-things-i-wish-i-knew-when-i-started-to-code-20ka