телеграм канал .NET Разработчик
Оцени!

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

Дневник сертифицированного .NET разработчика.
Для связи: @SBenzenko

Информация о канале

Телеграм канал «.NET Разработчик» @netdeveloperdiary (1914 подписчиков). Добавлен в каталог 17 Октября 2020. Категория 💻 IT, технологии. Открыть в: Telegram | в web версии | Ссылка в каталоге: https://tgram.me/netdeveloperdiary | Телеграм ссылка: https://t.me/netdeveloperdiary Язык: Русский, Английский.

Дата добавления
17 Октября 2020 01:46
Последнее обновление
16 Апреля 2021 12:45
Дата создания
31 Января 2019 04:59
Адрес в каталоге
https://tgram.me/netdeveloperdiary
Telegram ссылка
https://t.me/netdeveloperdiary
Подписчики
1914
Язык
Русский, Английский

Похожие каналы

Телеграм каналы похожие на @netdeveloperdiary

Отзывы на канал @netdeveloperdiary

Оставьте пожалуйста свой комментарий о телеграм канале «.NET Разработчик».

Популярное в каталоге

Посмотрите популярные ресурсы в каталоге

Последние посты

Последние сообщения в телеграм канале «.NET Разработчик».

День семьсот девяносто седьмой. #Шпаргалка
20 Команд Git, Которые Надо Знать
Git был выпущен в 2005 году. Несмотря на то, что сейчас появилось много программ с графическим интерфейсом для управления репозиторием, труЪ программеры используют консоль. Поэтому ловите 20 наиболее полезных команд Git, которые понадобятся любому разработчику. Подробности о работе Git см. начиная с этого поста.

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

2. Изменить ваше имя пользователя
git config --global user.name "<ваше имя>"

3. Изменить ваш email
git config --global user.email "test@email.com"

4. Создать репозиторий
git init
Эта команда инициализирует репозиторий в текущей папке.

5. Добавить файл в staging
git add my_file

6. Добавить все файлы в staging
git add .

7. Проверить статус
git status
Эта команда покажет статус текущего репозитория, включая текущую ветку, и файлы как в staging, так и не добавленные туда.

8. Commit
git commit
Эта команда создаст коммит. В этом варианте откроется текстовый редактор, куда вам нужно будет записать сообщение коммита.

9. Commit с сообщением
git commit -m "Ваше сообщение"

10. Просмотр истории
git log

11. Список веток
git branch

12. Создание ветки
git branch my_branch
Заметьте, что Git не переключится на эту ветку автоматом. Для этого см. пункт 14.

13. Удаление ветки
git branch -d my_branch
Обратите внимание на флаг -d.

14. Переключение между ветками
git checkout my_branch

15. Создание ветки и переключение на неё
Пункты 12 и 14 можно объединить в одну команду:
git checkout -b branch_name

16. Добавление удалённого репозитория
git add remote https://repo_url

17. Публикация в удалённый репозиторий
git push

18. Обновление из удалённого репозитория
git pull

19. Временное сохранение изменений
git stash
Эта команда временно сохранит неподтверждённые изменения и вернёт ваш репозиторий в состояние последнего коммита.

20. Получение временно сохранённых изменений
git stash pop
Эта команда применит сохранённые ранее изменения обратно к вашему репозиторию.

Источник: https://www.c-sharpcorner.com/article/20-git-commands-you-should-know/

942 04:38

День семьсот девяносто восьмой. #юмор
Ооо, это про меня.

915 05:07

День семьсот девяносто девятый. #ЗадачиНаСобеседовании
Сегодня предложу вам к просмотру ещё один минисериал от Nick Chapsas на тему заданий на собеседовании. На этот раз Ник разбирает задачу интеграции API сервиса.

Смысл задачи в том, что вам дан REST API (в данном случае API сети ресторанов), вам нужно создать клиента этого API, отвечающего определённым требованиям.

Все подробности задачи Ник объясняет в видео, поэтому не буду их пересказывать.

В первой части https://youtu.be/_Pjjk4fOh8s довольно подробно описывается создание консольного клиента API. Что хотелось бы отметить из решения – это пакеты, которые Ник использует (помимо стандартных):
1. RefitClient – пакет, который создаёт код клиента API на основе интерфейса.
2. CommandLineParser – о нём я уже писал.
3. OneOf – пакет для объединения различных типов в один тип OneOf<T0,T1,…Tn>. Ник использует его для возврата из метода обобщённого объекта с результатом либо ошибкой. Вызывающий код может использовать методы Match() или Switch(), чтобы выполнять действия в зависимости от типа ответа. Не могу сказать, что мне нравится такой подход, но упоминания он заслуживает.
4. Microsoft.Extensions.Http.Polly – Polly на канале уже тоже упоминался, и не раз. Это, насколько я понимаю, версия от Mirosoft, доступная в .NET 5.

Вторая часть https://youtu.be/NPAK94ZCxD4 посвящена тестированию. И помимо обычных модульных тестов Ник описывает приёмочное (acceptance) тестирование: близкое к человеческому языку описание теста, которое парсится в коде и проверяется автоматически. «Ничего не понятно, но очень интересно»))) Кстати, подробно о приёмочном тестировании есть и третье видео https://youtu.be/qWEDkHGNhvk

861 04:43

День восьмисотый.
Как Измерить Время Исполнения Программ в PowerShell
Командная строка используется всё чаще для запуска сценариев, сборки и других задач, вроде docker и docker-compose. Когда вы запускаете команду, например, dotnet build или dotnet test, она обычно сообщает вам о том, сколько времени потребовалось для выполнения. Но когда у вас есть сценарий, состоящий из нескольких шагов, часто хочется проверить, сколько времени он выполняется. Чтобы оптимизировать его или сравнить время на разных машинах.

Вы можете это сделать с помощью команды Measure-Command:
Measure-Command { ./SomeScript.ps1 }

Она запустит скрипт и предоставит отчет о том, сколько времени он занял. Также можно запускать произвольные команды CLI:
Measure-Command { dotnet build }

Но по умолчанию вы не получаете никакого вывода от выполняемой команды. Чтобы видеть его, нужно добавить параметр вывода (см. картинку):
Measure-Command { dotnet build | Out-Default }

Источник: https://ardalis.com/measure-command-line-script-time-elapsed/

778 04:32

День восемьсот первый.
Как Улучшить Свои Навыки Отладки. Начало
Независимо от того новичок вы или опытный разработчик, время от времени в вашем коде появляются ошибки. Все мы иногда делаем ошибки. В конце концов, невозможно перестать быть человеком. Есть три основных способа борьбы с ошибками:
1. Пред-отладка: снижение вероятности возникновения ошибок.
2. Отладка: выявление, исправление и удаление ошибок после их обнаружения.
3. Пост-отладка: анализ исправленных ошибок и отслеживание непредвиденных ошибок.

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

2. Изучите основные инструменты, которые вы часто используете
Выберите встроенный метод или функцию языка и спросите себя: «Что она принимает? Что возвращает? Что произойдёт, если будет указан недопустимый аргумент?» Вы уверены в своих ответах? Загляните в документацию, вы можете найти там много нового. Такие регулярные упражнения помогут вам отточить свои навыки и использовать инструменты языка правильно.

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

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

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

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

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

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

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

Источник: https://www.freecodecamp.org/news/how-to-improve-your-debugging-skills/

683 06:04

День восемьсот второй.
Как Улучшить Свои Навыки Отладки. Окончание
Начало

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

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

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

3. Исправление ошибки
После обнаружения и понимания причины ошибки мы должны исправить её. Иногда, если вы понимаете, в чём ошибка, вы быстро найдёте решение. Однако бывают случаи, когда даже понимание не даёт решения, как бы мы ни старались. Не тратьте слишком много времени на раздумья, поищите подходящее решение в интернете по коду или сообщению об ошибке или другому подходящему запросу. Также можно спросить коллегу, или задать вопрос на форуме, на StackOverflow, в чате, где-угодно (но только после того, как вы самостоятельно обдумали проблему!). Люди склонны видеть вещи по-разному, взгляд на проблему со стороны может помочь. Иногда даже само объяснение проблемы другому человеку помогает найти решение.

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

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

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

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

Источник: https://www.freecodecamp.org/news/how-to-improve-your-debugging-skills/

635 07:16

День восемьсот третий. #ВопросыНаСобеседовании
Попробую новый вид постов на тему вопросов на собеседовании. Подписчик прислал набор вопросов, которые ему недавно задали на собеседовании и попросил оценить. Попробую сам ответить и прокомментировать, а также жду комментариев от вас. Как по поводу ответов, так и по поводу, как вам вопросы и как вообще такой формат.

Поехали!

Дисклеймер: вопросы буду приводить в том виде, как они мне были присланы. Я постараюсь не гуглить правильные ответы, а приведу свои мысли. Поэтому мои ответы не обязательно будут правильными. Если что, поправляйте в комментариях.

Внутренности .NET
1) Есть класс Object. У него определенны Equals и GetHashCode. Если вы переопределите Equals, но не переопределите GetHashCode для какого-нибудь класса, компилятор выдаст вам Warning. Почему?
Методы Equals и GetHashCode связаны в том смысле, что GetHashCode должен выдавать одинаковый результат у объектов, для которых Equals выдаёт true. Поэтому переопределение Equals скорее всего потребует и переопределения GetHashCode.
Подробнее об Equals
Подробнее о GetHashCode

2) В классе Dictionary, когда происходит поиск по ключу. Какая сложность? А в List при вызове FirstOrDefault()?
В Dictionary поиск по ключу происходит со сложностью O(1) из-за хеширования ключей. В List – первый элемент выберется за O(1), но если до этого будет поиск по индексу, то O(n).
Подробнее

3) Есть конструкция async/await. Как она работает? Когда добавляю async и await, что там меняется относительно того, если бы я не добавлял.
Создаётся конечный автомат для сохранения состояния. Все инструкции после строки с await добавляются в функцию продолжения, которая вызывается после завершения ожидания инструкции, следующей за await.
Подробнее

4) У меня была операция File.ReadAll(), я заменил ее на File.ReadAllAsync() какая из этих операций будет быстрее?
Странный вопрос, на мой взгляд, о сферическом быстродействии в вакууме. Тут столько неизвестных, что определённо ответить на этот вопрос просто невозможно. Скорее всего разницы в быстродействии не будет заметно, т.к. время на чтение файла будет на порядок превышать затраты на асинхронность.

5) Если синхронные методы работают быстрее чем асинхронные, зачем нам нужная асинхронная модель?
Опять какое-то теоретизирование о быстродействии синхронных и асинхронных методов. Быстродействие надо измерять в каждом конкретном случае. А вообще асинхронные методы используются для исключения блокировки UI потока, а также для операций, не использующих процессор, вроде чтения/записи файлов, обращения к БД или сетевых вызовов.

6) Есть I/O Bound потоки и CPU Bound потоки. Какая разница между ними?
Эти потоки различаются по типу нагрузки на ресурсы компьютера. I/O Bound поток больше нагружает диск (чтение/запись файлов), CPU Bound поток больше нагружает процессор (вычислительные операции).

7) File.ReadAllAsync() какого типа поток?
Совсем не понял вопроса. Начнём с того, что нет метода ReadAllAsync(), есть ReadAllBytesAsync(), возвращающий Task<byte[]>, и ReadAllTextAsync(), возвращающий Task<string>.

8) Task.Run(t => File.ReadAll()) и File.ReadAllAsync() это эквивалентные вызовы? Объясните.
Отвлечёмся от того, что снова указаны несуществующие методы. Здесь, если выполнить так, как написано, то, насколько я понимаю, Task.Run не возвратит результата.

9) Есть строковая переменная, в ней написано название типа, я хочу создать объект этого типа. Как мне это сделать? Корректировка: Тип ты не знаешь в Compile Time.
Использовать Activator.CreateInstance(). Подробности на память не помню, надо гуглить.

Как вам вопросы? Что скажете о моих ответах? Стоит ли продолжать выпускать такие посты?

573 05:26

День восемьсот четвёртый. #ЗаметкиНаПолях
Что такое Debugger.Launch?
Допустим, вы запускаете приложение (например, веб-приложение или службу Windows), в котором есть startup метод, который вы хотите отладить. Часто это может быть настройка внедрения зависимостей, раннее чтение файла конфигурации или что-то подобное. Допустим, вы не можете просто нажать F5 в Visual Studio и начать отладку. Вам нужно запустить приложение, а потом подключить отладчик. Для веб-приложений это иногда связано с тем, что вы используете IIS и переходите по URL-адресу своего приложения. А службу Windows, вы хотите отладить, когда она на самом деле исполняется как служба Windows.

Можно добавить в нужное место кода Thread.Sleep(10000); и попытаться подключить отладчик, в течение этого времени. Но гораздо проще это сделать с помощью:
System.Diagnostics.Debugger.Launch();

Тогда, если вы запустите приложение (не через отладку из Visual Studio), то, когда исполнение дойдёт до этой строчки, появится диалоговое окно, где вам будет предложено выбрать отладчик для этого приложения. Можно выбрать Visual Studio, и приложение откроется в режиме отладки.

А что насчёт Debugger.Break()?
Этот метод также использовался для начала отладки. Но, как говорится в документации Microsoft, начиная с .NET Framework 4, если не выбран отладчик, то не гарантируется, что метод Break приведёт к вызову окна выбора отладчика. Вместо этого в систему отчётов об ошибках Windows (WER) направляется сообщение об ошибке. Таким образом, документация советует для старта отладчика использовать Debugger.Launch.

Если же отладчик уже подключен, Debugger.Break заставляет код останавливать выполнение так же, как и точка останова. Так что в некотором смысле это похоже на точку останова, которую могут использовать разработчики на разных машинах вместо ручной инструкции: «Поместите точку останова в строку XX файла YYY…». Это может показаться не очень полезным, кроме случая, который мы рассмотрим далее.

Когда Debugger.Launch не работает
В очень редких случаях Debugger.Launch не предлагает пользователю отладить код. Либо требуется отладка в приложении, не представленном во всплывающем окне. Тогда есть простое решение:
// Ждём подключения отладчика.
while(!System.Diagnostics.Debugger.IsAttached)
{
Thread.Sleep(100); //либо Task.Delay()
}
System.Diagnostics.Debugger.Break();

Если отладчик не подключен, программа ожидает его подключения в бесконечном цикле. После подключения отладчика цикл будет прерван, и мы продолжим выполнение. Debugger.Break немедленно останавливает выполнение и действует как точка останова, позволяя нам начать пошаговое выполнение кода, если мы хотим.
Этот код можно обернуть в конструкцию
#if DEBUG

#endif

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

Источник: https://dotnetcoretutorials.com/2021/04/03/i-wish-i-knew-about-debugger-launch-earlier/

512 05:36

Даже если ты никогда не программировал, есть возможность начать карьеру в IT.

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

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

На практическом курсе «Профессия Тестировщик» тебя ждёт:
40 модулей;
250 онлайн-уроков;
поддержка наставников-практиков с многолетним опытом;
возможность начать зарабатывать уже через три месяца обучения;
три дипломные работы;
сертификат и крутое портфолио по завершении;
помощь с трудоустройством.

Переходи по ссылке и регистрируйся. Первые 6 месяцев обучения бесплатно!▶️ https://clc.am/k2t0ew
#реклама

499 06:53