.NET Разработчик

День девятьсот шестьдесят второй. #NuGet
Генерация Фейковых Данных с Помощью Faker.Net
При разработке, тестировании или демонстрации продукта часто важно использовать данные, которые не являются настоящими. Либо потому, что у вас ещё нет фактических данных, либо потому, что вы не хотите показывать или выбирать данные реальных пользователей, которые могут содержать конфиденциальную информацию. Faker.Net поможет в этом, упростив получение множества случайных имен, адресов, email адресов, и прочей личной информации.

Пакет .NET изначально был портом библиотеки Ruby от 2009 года, но во многом разошлась с ней. Библиотека Ruby сама по себе была портом библиотеки Perl Data::Faker от 2007 года. .NET библиотека продолжает использоваться и постоянно обновляется. Причина её популярности, вероятно, связана со множеством вариантов использования и очень простой структурой.

Сначала нужно установить пакет Faker.Net. Мы можем сделать это через диспетчер пакетов в Visual Studio или через интерфейс CLI:

dotnet add package Faker.Net

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

class UserProfile
{
  string Name { get; set; }
  int Followers { get; set; }
  string Address { get; set; }
  string Bio { get; set; }
}

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

var user = new UserProfile();
user.Name = Faker.Name.FullName(NameFormats.WithPrefix);
// "Mrs. Jerod Nader"

Для генерации случайных чисел Faker.Net использует класс RandomNumberGenerator из System.Security.Cryptography:

user.Followers = Faker.RandomNumber.Next(0, 10000);
// 3452

Далее создадим адрес:

user.Address = $"{Faker.Address.Country()}, {Faker.Address.City()}";
// "Fiji, Wavaland"

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

Последний шаг – текст для биографии. Можно просто взять несколько предложений из «рыбы» "Lorem Ipsum…":

user.Bio = String.Join(" ", Faker.Lorem.Sentences(3));
// "Ea voluptas maiores nihil quia et eum. Vel et eos est architecto rerum est. Eum esse voluptatem ab necessitatibus."

Кроме того, можно создавать:
- доменные имена:

user.CompanyDomain = Faker.Internet.DomainName();
// "torp.com"

- email адреса (заметьте, что использовано имя пользователя):

user.Email = Faker.Internet.Email(user.Name);
// "mrs_jerod.nader@hermanborer.name"

- URL адреса:

user.resources = Enumerable.Range(0,2).Select(_ => Faker.Internet.SecureUrl());
// "https://www.quigleyrobel.us/films/page.aspx"
// "https://www.braunborer.uk/guide/page.jsp"

- и многое другое.

Источник: https://blog.elmah.io/easy-generation-of-fake-dummy-data-in-c-with-faker-net/

День девятьсот шестьдесят первый. #ЗаметкиНаПолях
Как Добавить Представление в EF Core DbContext
Представление (View) - это виртуальная таблица, основанная на результатах предопределённого запроса. Представления позволяют инкапсулировать сложный запрос в логический объект в базе данных.

Допустим, у нас есть две таблицы: продуктов (Products) и оценок продуктов (Ratings). Наша цель - создать представление SQL, которое может упростить следующий оператор LINQ:

var prodRatings = 
  db.Products
  .Select(x => new {
    id = x.Id,
    name = x.Name,
    avg = x.Ratings.Average(r => r.Stars)
  });

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

dotnet ef migrations add ProductRatingAvg

Затем откроем файл новой миграции в папке Migrations. Он содержит два метода, в которые добавляется код, выполняемый при применении (Up) и откате (Down) миграции. Мы можем вручную добавить любой код, который хотим выполнить. Например, для создания представления добавим выполнение произвольного Sql запроса:

public partial class ProductRatingAvg : Migration
{
  protected override void 
   Up(MigrationBuilder mb)
  {
    mb.Sql(@"
create view ProductAverages as
select p.Id, p.Name, avg(r.Stars) as AverageRating
from Products p inner join Ratings r on p.Id = R.ProductionId
group by p.Id, p.Name;");
  }

  protected override void 
   Down(MigrationBuilder mb)
  {
    mb.Sql(@"drop view ProductAverages;");
  }
}

Следующий шаг – добавить модель ProductAverage в DbContext:

public class ProductAverage {
  public int Id { get; set; }
  public string Name { get; set; }
  public double AverageRating { get; set; }
}

public DbSet<ProductAverage> ProductAverages { get; set; }

Далее привяжем сущность к представлению в методе DbContext.OnModelCreating:

modelBuilder
  .Entity<ProductAverage>()
  .ToView(nameof(ProductAverages))
  .HasKey(t => t.Id);

Наше свойство ProductAverages называется так же, как представление, поэтому мы можем использовать nameof, хотя в метод ToView() можно передать любую строку.

Теперь мы можем использовать наше новое представление так же, как любой другой DbSet:

var db = new MyDbContext();
…
var averages = 
  await db.ProductAverages.ToListAsync();

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

Источник: https://khalidabuhakmeh.com/how-to-add-a-view-to-an-entity-framework-core-dbcontext

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

46. ​​Один законченный проект лучше 10 незавершённых.
Старайтесь работать над одним или парой проектов одновременно и следовать графику исполнения работы. Помните, что важны только готовые проекты.

47. Лучший способ учиться - обучать других.
Чтобы научить других, вы должны сами хорошо изучить тему. Это гарантирует, что вы познакомитесь с концепцией досконально, и будет беспроигрышным вариантом, если вы поделитесь своими знаниями.

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

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

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

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

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

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

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

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

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

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

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

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

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

35. Google и Stack Overflow – ваши друзья.
Эти ресурсы созданы для того, чтобы вам могли помочь. Не стесняйтесь гуглить или заглядывать в SO, даже если кто-то смотрит. Они тоже это делают.

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

37. Всегда помните о правиле 20/80.
Имейте в виду, что последние 20% проекта занимают 80% времени. Так что дважды подумайте, прежде чем сообщать клиенту о прогрессе.

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

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

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

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

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

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

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

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

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

Источник: 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

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

Вещи, Которые Я Хотел бы Знать, Когда Начинал Карьеру. Начало
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

День девятьсот пятьдесят шестой. #Оффтоп
Вчера слушал очередную серию подкаста 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.

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

День девятьсот пятьдесят четвёртый. #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)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

День девятьсот пятьдесят первый. #ЧтоНовенького
Улучшения Работы с Файлами в .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

День девятьсот пятидесятый. #ЗаметкиНаПолях
Относитесь к Интеграционным Тестам Как к Внешним Потребителям
В 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/

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

https://youtu.be/ra3-DPAJFfc

День девятьсот сорок восьмой. #ЧтоНовенького
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/

День девятьсот сорок седьмой. #Оффтоп
Советы по Улучшению Ваших Навыков Разработки в .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

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

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

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

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

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

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

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

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

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

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

День девятьсот сорок четвёртый. #Оффтоп
Советы по Улучшению Ваших Навыков Разработки в .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

День девятьсот сорок третий. #ЗаметкиНаПолях
Почему Вы Всегда Должны Разрабатывать в Среде "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/