День шестьсот восемьдесят четвёртый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
1. Разносторонний Рост
Ко второму году работы я уже знал все основы. Я собрал все низко висящие плоды, и мой рост замедлился. Возник большой вопрос: «Как расти дальше?» Я мало что мог сделать, чтобы улучшить свои навыки программирования. Большинство статей и блогов про методы написания более чистого кода, KISS, DRY, YAGNI и т.д. - являются микрооптимизациями. Почти ничего из этого не приносит большой пользы для роста (хотя это не значит, что их не стоит изучать совсем).
Я обнаружил кое-что интересное. Я разрабатываю ПО, но жизненный цикл разработки ПО является частью более крупного жизненного цикла: разработки продукта. Я решил пойти вширь, а не вглубь. Удивительно, но это помогло мне глубже понять то, что я делаю. Я выбрал три основных направления:
1) Изучение того, что делают люди вокруг меня
Поскольку мы не закрыты от общения с коллегами, имеет смысл лучше понять работу менеджеров продукта, продавцов и аналитиков. В конце концов, бизнес зарабатывает на продукте. Цель не в том, чтобы писать код, а в том, чтобы приносить прибыль бизнесу. Большинство крупных компаний не делают что-то одно, а это означает, что в одной и той же компании есть разные пути для извлечения прибыли. Все работники находятся по крайней мере на одном из путей, иначе они бы не работали в компании. Отслеживание этих путей, а также исследование пути, на котором нахожусь я, было очень ценно. Это помогло мне понять, насколько я важен, и какие рычаги я могу использовать, чтобы стать более эффективным. Иногда нужно упростить работу продажникам, чтобы они могли увеличить продажи. В другом случае нужно создать новый функционал для клиентов. В третьем - исправить функцию, которая постоянно ломается.
Менеджеры продукта - лучший источник этой информации. Они знают, как бизнес зарабатывает деньги, кто их клиенты и что им нужно. За год я довольно много встречался с коллегами. Второе преимущество этого - знание контекста работы других. Это помогло мне в общении. Например, один разговор помог мне понять, почему Саре из отдела продаж нужен инструмент массового обновления. В некоторых компаниях много сотрудников, и обновлять их по одному - проблема. Код, который я в итоге написал, буквально избавил Сару от мучений.
2) Тренировка правильных мыслительных привычек
Разработка ПО требует правильного мышления и принятия правильных решений. Написание кода — это реализация этих решений. Мыслительная привычка — это то, что ваш мозг делает регулярно. Это может быть размышление о X всякий раз, когда случается Y, или применение инструмента X к проблеме Y. Короче говоря, мыслительные привычки помогают размышлению. Я предположил, что, если изучить общие принципы, их можно будет применить и в разработке ПО.
3) Правильное мышление
Разработка ПО - отличная область для практики правильного мышления. Циклы обратной связи короче, и оценка правильности решения не занимает много времени. Я погрузился в изучение когнитивных наук. Это полезный навык, который стоит изучить. Он поможет и тому, чем я занимаюсь по работе, и принесёт дивиденды в жизни вообще. Подробнее об этом позже.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd#d46c
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
1. Разносторонний Рост
Ко второму году работы я уже знал все основы. Я собрал все низко висящие плоды, и мой рост замедлился. Возник большой вопрос: «Как расти дальше?» Я мало что мог сделать, чтобы улучшить свои навыки программирования. Большинство статей и блогов про методы написания более чистого кода, KISS, DRY, YAGNI и т.д. - являются микрооптимизациями. Почти ничего из этого не приносит большой пользы для роста (хотя это не значит, что их не стоит изучать совсем).
Я обнаружил кое-что интересное. Я разрабатываю ПО, но жизненный цикл разработки ПО является частью более крупного жизненного цикла: разработки продукта. Я решил пойти вширь, а не вглубь. Удивительно, но это помогло мне глубже понять то, что я делаю. Я выбрал три основных направления:
1) Изучение того, что делают люди вокруг меня
Поскольку мы не закрыты от общения с коллегами, имеет смысл лучше понять работу менеджеров продукта, продавцов и аналитиков. В конце концов, бизнес зарабатывает на продукте. Цель не в том, чтобы писать код, а в том, чтобы приносить прибыль бизнесу. Большинство крупных компаний не делают что-то одно, а это означает, что в одной и той же компании есть разные пути для извлечения прибыли. Все работники находятся по крайней мере на одном из путей, иначе они бы не работали в компании. Отслеживание этих путей, а также исследование пути, на котором нахожусь я, было очень ценно. Это помогло мне понять, насколько я важен, и какие рычаги я могу использовать, чтобы стать более эффективным. Иногда нужно упростить работу продажникам, чтобы они могли увеличить продажи. В другом случае нужно создать новый функционал для клиентов. В третьем - исправить функцию, которая постоянно ломается.
Менеджеры продукта - лучший источник этой информации. Они знают, как бизнес зарабатывает деньги, кто их клиенты и что им нужно. За год я довольно много встречался с коллегами. Второе преимущество этого - знание контекста работы других. Это помогло мне в общении. Например, один разговор помог мне понять, почему Саре из отдела продаж нужен инструмент массового обновления. В некоторых компаниях много сотрудников, и обновлять их по одному - проблема. Код, который я в итоге написал, буквально избавил Сару от мучений.
2) Тренировка правильных мыслительных привычек
Разработка ПО требует правильного мышления и принятия правильных решений. Написание кода — это реализация этих решений. Мыслительная привычка — это то, что ваш мозг делает регулярно. Это может быть размышление о X всякий раз, когда случается Y, или применение инструмента X к проблеме Y. Короче говоря, мыслительные привычки помогают размышлению. Я предположил, что, если изучить общие принципы, их можно будет применить и в разработке ПО.
3) Правильное мышление
Разработка ПО - отличная область для практики правильного мышления. Циклы обратной связи короче, и оценка правильности решения не занимает много времени. Я погрузился в изучение когнитивных наук. Это полезный навык, который стоит изучить. Он поможет и тому, чем я занимаюсь по работе, и принесёт дивиденды в жизни вообще. Подробнее об этом позже.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd#d46c
Автор оригинала – Neil Kakkar
День шестьсот восемьдесят пятый. #Оффтоп
Перенесём разговоры по воскресеньям на разговоры по вторникам))) Судя по всему, на неделе обсуждения получаются активнее. Действительно, что ещё делать в течение дня, работать что ли?
Вчера вечером по Москве и сильно ранним утром по североамериканскому времени у Google случился массивный сбой, который привёл к перебоям в работе, судя по всему, всех сервисов, где требовалась аутентификация. По этому поводу бывший разработчик Google, наш старый знакомый, Клемент Михайлеску, выпустил видео о том, как такого рода проблемы решаются в крупных компаниях.
В двух словах, в компании есть «On Call»-инженеры (инженеры на вызове), которым могут позвонить в середине ночи в случае, если случается что-то серьёзное. Насколько я понял, эта роль передаётся по очереди всем разработчикам. Давайте обсудим. Есть ли такое в вашей компании? Случалось ли это с вами, что было (если не секрет), и что было за это вам?)))
Перенесём разговоры по воскресеньям на разговоры по вторникам))) Судя по всему, на неделе обсуждения получаются активнее. Действительно, что ещё делать в течение дня, работать что ли?
Вчера вечером по Москве и сильно ранним утром по североамериканскому времени у Google случился массивный сбой, который привёл к перебоям в работе, судя по всему, всех сервисов, где требовалась аутентификация. По этому поводу бывший разработчик Google, наш старый знакомый, Клемент Михайлеску, выпустил видео о том, как такого рода проблемы решаются в крупных компаниях.
В двух словах, в компании есть «On Call»-инженеры (инженеры на вызове), которым могут позвонить в середине ночи в случае, если случается что-то серьёзное. Насколько я понял, эта роль передаётся по очереди всем разработчикам. Давайте обсудим. Есть ли такое в вашей компании? Случалось ли это с вами, что было (если не секрет), и что было за это вам?)))
День шестьсот восемьдесят шестой. #Оффтоп
The API Book
Случайно наткнулся на довольно занятную книгу. Ну как книгу, она пока в стадии написания, но значительная часть её уже готова. "The API Book" за авторством Сергея Константинова. Найти её можно на гитхабе автора как в английском, так и в русском варианте.
Книга посвящена созданию API. Пока готов первый раздел, посвящённый проектированию. Я только начал читать, поэтому полного впечатления о книге пока не составил. Однако, судя по первым главам, довольно интересное, лёгкое теоретическое чтение. Автор не грузит техническими деталями, примеры на псевдокоде. Поможет как для приобретения практических навыков, так и для общего развития.
«Ключевой вопрос, который вы должны задать себе <при проектировании API>, выглядит так: какую проблему мы решаем? Задать его следует четыре раза с ударением на каждом из четырёх слов.»
Подробности в книге по ссылке выше.
The API Book
Случайно наткнулся на довольно занятную книгу. Ну как книгу, она пока в стадии написания, но значительная часть её уже готова. "The API Book" за авторством Сергея Константинова. Найти её можно на гитхабе автора как в английском, так и в русском варианте.
Книга посвящена созданию API. Пока готов первый раздел, посвящённый проектированию. Я только начал читать, поэтому полного впечатления о книге пока не составил. Однако, судя по первым главам, довольно интересное, лёгкое теоретическое чтение. Автор не грузит техническими деталями, примеры на псевдокоде. Поможет как для приобретения практических навыков, так и для общего развития.
«Ключевой вопрос, который вы должны задать себе <при проектировании API>, выглядит так: какую проблему мы решаем? Задать его следует четыре раза с ударением на каждом из четырёх слов.»
Подробности в книге по ссылке выше.
День шестьсот восемьдесят седьмой. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Начало 1/3
В третьей части нашего обзора .NET 5 рассмотрим ASP.NET.
- BCL
- Исторические технологии
1. Сериализация
Числа, которые отображаются как строки в кавычках
2. Заменённые пакеты
Были переименованы или заменены различные пакеты:
API
=>
- Незначащие пробелы будут удаляться из файлов .razor во время компиляции. Это может привести к устранению сотен пустых узлов, которые потребляют память и пропускную способность сети несмотря на то, что не влияют на отображаемый HTML. Тестирование Microsoft показало улучшение времени рендеринга до 40%.
- В структуре
- Авторам библиотек, поддерживающих как .NET Core 3.x, так и .NET 5, потребуется использовать условную ссылку на пакет
Blazor в .NET 5 требует дополнительных функций, которые недоступны в старых браузерах. Internet Explorer не будет поддерживаться вообще. Ранее IE 11 мог получить доступ к веб-сайтам на основе Blazor через polyfills и asm.js. Но, по словам Дэниела Рота, с этим «было много проблем, и опыт использования был не очень хорош», поэтому в Microsoft отказались от asm.js и сосредоточились на WebAssembly.
Никакой конкретной причины относительно Edge Legacy не было указано, но, похоже, это сделано потому, что браузер больше не будет поддерживаться с 9 марта 2021 года. Edge Legacy был официально заменён браузером на основе Chromium.
5. Логи в HttpClient
В .NET Core логи HttpClient записывались с именами кодов ответа HTTP:
Продолжение следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
Критические Изменения в .NET5. ASP.NET. Начало 1/3
В третьей части нашего обзора .NET 5 рассмотрим ASP.NET.
- BCL
- Исторические технологии
1. Сериализация
Числа, которые отображаются как строки в кавычках
{ "Number": "5" }, теперь могут быть десериализованы с помощью стандартного инструмента System.Text.Json.JsonSerializer в числовые свойства, как если бы они были обычными числами в JSON. Раньше это вызвало исключение JsonException.2. Заменённые пакеты
Были переименованы или заменены различные пакеты:
AzureAD.UI=>
Microsoft.Identity.Web,API
AzureADB2C.UI =>
Microsoft.Identity.Web,Microsoft.AspNetCore.DataProtection=>
.AzureKeyVault
Azure.Extensions.AspNetCore
.DataProtection.Keys,Microsoft.AspNetCore.DataProtection=>
.AzureStorage
Azure.Extensions.AspNetCore
.DataProtection.Blobs,Microsoft.Extensions=>
.Configuration.AzureKeyVault
Azure.Extensions.AspNetCore
.Configuration.Secrets
3. Изменения в Blazor для производительности- Незначащие пробелы будут удаляться из файлов .razor во время компиляции. Это может привести к устранению сотен пустых узлов, которые потребляют память и пропускную способность сети несмотря на то, что не влияют на отображаемый HTML. Тестирование Microsoft показало улучшение времени рендеринга до 40%.
- В структуре
RenderTreeFrame различные публичные поля только для чтения, были заменены публичными свойствами только для чтения. Это изменение нарушает двоичный код, но не нарушает исходный код. То есть код не нужно будет изменять, но нужно будет перекомпилировать для работы с новой версией.- Авторам библиотек, поддерживающих как .NET Core 3.x, так и .NET 5, потребуется использовать условную ссылку на пакет
Microsoft.AspNetCore.Components для учёта обеих версий:<PackageReference Include="Microsoft.AspNetCore.Components" Version="3.0.0" Condition="'$(TargetFramework)' == 'netstandard2.0'" />4. Blazor прекращает поддержку IE и Edge Legacy
<PackageReference Include="Microsoft.AspNetCore.Components" Version="5.0.0-rc.1.*" Condition="'$(TargetFramework)' != 'netstandard2.0'" />
Blazor в .NET 5 требует дополнительных функций, которые недоступны в старых браузерах. Internet Explorer не будет поддерживаться вообще. Ранее IE 11 мог получить доступ к веб-сайтам на основе Blazor через polyfills и asm.js. Но, по словам Дэниела Рота, с этим «было много проблем, и опыт использования был не очень хорош», поэтому в Microsoft отказались от asm.js и сосредоточились на WebAssembly.
Никакой конкретной причины относительно Edge Legacy не было указано, но, похоже, это сделано потому, что браузер больше не будет поддерживаться с 9 марта 2021 года. Edge Legacy был официально заменён браузером на основе Chromium.
5. Логи в HttpClient
В .NET Core логи HttpClient записывались с именами кодов ответа HTTP:
Received HTTP response after 56.0044ms - OKДля большей согласованности с другими частями .NET это поведение было изменено на использование числовых кодов:
End processing HTTP request after 70.0862ms – OK
Received HTTP response after 56.0044ms - 200Целью изменения было устранение несоответствия, из-за которого «затруднялось выполнение запросов через структурированные системы ведения логов, такие как Elasticsearch». Если вам нужно сохранить старое поведение, Microsoft рекомендует взять исходный код классов логирования для версии .NET Core 3.1 и включить их в свой проект. Возможно, это впервые, когда Microsoft используют открытый исходный код для решения проблемы обратной совместимости.
End processing HTTP request after 70.0862ms – 200
Продолжение следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
День шестьсот восемьдесят восьмой. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Продолжение 2/3
Продолжаем рассматривать изменения в ASP.NET в .NET5.
- BCL
- Исторические технологии
- ASP.NET. Начало
6. Исключение BadHttpRequestException заменено на BadHttpRequestException
Это странное изменение является результатом наличия в .NET трех классов
-
-
-
Поскольку все они означают одно и то же, это сочли избыточным. Теперь используется только версия Http, другие были отмечены как устаревшие. Для некоторой обратной совместимости они будут унаследованы от версии Http.
7. Повторное согласование сертификата HttpSys отключено
Чтобы повысить производительность, предотвратить взаимоблокировки и поддерживать совместимость с HTTP/2, HttpSys по умолчанию не будет повторно согласовывать сертификаты клиентов. Несмотря на то, что его можно включить, Microsoft не рекомендует этого делать.
8. MVC: ObjectModelValidator вызывает новую перегрузку ValidationVisitor.Validate
Исходная сигнатура этого метода:
В .NET 5 введена новая виртуальная перегрузка, и
9. Отменена кодировка имени файла cookie
В стандарте HTTP имена файлов cookie представляют собой ограниченный набор символов ASCII. Для удобства разработчиков многие платформы, включая ASP.NET Core, позволяют включать дополнительные символы и просто кодируют их. Эта возможность была удалена по соображениям безопасности. Если в имени есть не-ASCII символ, может возникнуть исключение. Значения файлов cookie будут по-прежнему кодироваться/декодироваться как обычно.
Окончание следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
Критические Изменения в .NET5. ASP.NET. Продолжение 2/3
Продолжаем рассматривать изменения в ASP.NET в .NET5.
- BCL
- Исторические технологии
- ASP.NET. Начало
6. Исключение BadHttpRequestException заменено на BadHttpRequestException
Это странное изменение является результатом наличия в .NET трех классов
BadHttpRequestException. Их полные имена:-
Microsoft.AspNetCore.Server
.Kestrel.BadHttpRequestException, -
Microsoft.AspNetCore.Server
.IIS.BadHttpRequestException и -
Microsoft.AspNetCore
.Http.BadHttpRequestException. Поскольку все они означают одно и то же, это сочли избыточным. Теперь используется только версия Http, другие были отмечены как устаревшие. Для некоторой обратной совместимости они будут унаследованы от версии Http.
7. Повторное согласование сертификата HttpSys отключено
Чтобы повысить производительность, предотвратить взаимоблокировки и поддерживать совместимость с HTTP/2, HttpSys по умолчанию не будет повторно согласовывать сертификаты клиентов. Несмотря на то, что его можно включить, Microsoft не рекомендует этого делать.
8. MVC: ObjectModelValidator вызывает новую перегрузку ValidationVisitor.Validate
Исходная сигнатура этого метода:
public virtual bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel)Разработчики могут перегружать его для выполнения своей логики проверки. Затем этот метод вызывается объектом
ObjectModelValidator.В .NET 5 введена новая виртуальная перегрузка, и
ObjectModelValidator теперь вызывает её:public virtual bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel, object container)При этом старая версия оставлена, и просто вызывает новую, передавая
null в последний параметр. Если разработчик переопределит исходный метод Validate, то в .NET5 это переопределение будет проигнорировано. Код будет компилироваться, но ObjectModelValidator вместо переопределённого разработчиком метода вызовет новую перегрузку, и переопределённая версия просто не будет работать без каких-либо объяснений. Если вы посчитали, что это редко используемый функционал, то заметьте, что переопределяет этот метод, например, пакет FluentValidation (хотя, его код уже, похоже, исправили)9. Отменена кодировка имени файла cookie
В стандарте HTTP имена файлов cookie представляют собой ограниченный набор символов ASCII. Для удобства разработчиков многие платформы, включая ASP.NET Core, позволяют включать дополнительные символы и просто кодируют их. Эта возможность была удалена по соображениям безопасности. Если в имени есть не-ASCII символ, может возникнуть исключение. Значения файлов cookie будут по-прежнему кодироваться/декодироваться как обычно.
Окончание следует…
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
День шестьсот восемьдесят девятый. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Окончание 3/3
В этом посте завершим обзор важных изменений в ASP.NET, введённых в .NET 5.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
10. SignalR: протокол хаба MessagePack теперь использует MessagePackSerializerOptions
Ранее SignalR использовал MessagePack 1 для сериализации сообщений. В .NET 5 он был обновлен для использования MessagePack 2. Поскольку в MessagePack 2 было сделано критическое изменение (переход от
11. SignalR теперь требует маршрутизации конечных точек
Маршрутизация конечных точек появилась в ASP.NET Core 3. Подробнее о том, зачем она была введена, я писал в этом посте. SignalR в это же время добавил возможность использовать маршрутизацию конечных точек, но это было необязательно. Старый механизм настраиваемой маршрутизации все ещё был доступен, хотя и отмечен как устаревший. В .NET 5 старый метод был полностью удалён, и теперь необходимо использовать конечную точку. К счастью, изменения в коде минимальны. Вместо:
Последнее изменение, которое мы обсудим в этом блоке - это соответствие стандартам для файлов CSV. По странному недосмотру предыдущие версии ASP.NET Core обслуживали статические файлы CSV как
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
Критические Изменения в .NET5. ASP.NET. Окончание 3/3
В этом посте завершим обзор важных изменений в ASP.NET, введённых в .NET 5.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
10. SignalR: протокол хаба MessagePack теперь использует MessagePackSerializerOptions
Ранее SignalR использовал MessagePack 1 для сериализации сообщений. В .NET 5 он был обновлен для использования MessagePack 2. Поскольку в MessagePack 2 было сделано критическое изменение (переход от
IFormatterResolver к MessagePackSerializerOptions), в SignalR потребовалось внести аналогичное изменение в процесс обработки конфигурации. Это изменение повлияет только на тех, кто изменяет MessagePackHubProtocolOptions для SignalR.11. SignalR теперь требует маршрутизации конечных точек
Маршрутизация конечных точек появилась в ASP.NET Core 3. Подробнее о том, зачем она была введена, я писал в этом посте. SignalR в это же время добавил возможность использовать маршрутизацию конечных точек, но это было необязательно. Старый механизм настраиваемой маршрутизации все ещё был доступен, хотя и отмечен как устаревший. В .NET 5 старый метод был полностью удалён, и теперь необходимо использовать конечную точку. К счастью, изменения в коде минимальны. Вместо:
app.UseSignalR(routes =>надо использовать
{
routes.MapHub<SomeHub>("/path");
});
app.UseEndpoints(endpoints =>12. Статические файлы: тип содержимого CSV изменен на соответствующий стандартам
{
endpoints.MapHub<SomeHub>("/path");
});
Последнее изменение, которое мы обсудим в этом блоке - это соответствие стандартам для файлов CSV. По странному недосмотру предыдущие версии ASP.NET Core обслуживали статические файлы CSV как
application/octet-stream, вместо text/csv. Это может повлиять на то, как браузеры обрабатывают эти файлы, что раньше заставляло разработчиков использовать FileExtensionContentTypeProvider для переопределения этого поведения. Теперь будет использоваться правильный тип содержимого. Если же разработчикам, использующим ASP.NET Core 5, потребуется старое поведение, они могут использовать всё тот же FileExtensionContentTypeProvider, чтобы вернуться к application/octet-stream.Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/
День шестьсот девяностый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
70. Изучайте Гуманитарные Науки
Практически в любом проекте разработки ПО, кроме самых маленьких, люди работают с другими людьми. Во всех областях исследований, кроме самых абстрактных, люди пишут для людей ПО, которое поможет им в достижении какой-либо цели. Люди пишут программы вместе с людьми для людей. Этот бизнес связан с людьми. К сожалению, в процессе обучения программистов очень мало внимания уделяется аспекту взаимодействия с людьми, с которыми они работают. К счастью, есть целая область исследований, которая может помочь.
Например, Людвиг Витгенштейн приводит очень хороший пример в «Философских исследованиях», что любой язык, который мы используем для общения друг с другом, не является – и не может быть – универсальным форматом для передачи мысли, идеи или изображения из головы одного человека в голову другого. Поэтому мы должны быть готовы к недопониманиям уже на этапе сбора требований. Витгенштейн также показывает, что наша способность понимать друг друга вовсе не возникает из общих определений, она возникает из общего опыта, образа жизни. Это может быть одной из причин, по которой программисты, стремящиеся разобраться в проблемах своей проблемной области, как правило, добиваются большего успеха, чем те, кто дистанцируется от неё.
Лакофф и Джонсон представляют нам сборник «Метафоры, которыми мы живем» (Дж. Лакофф, М. Джонсон - ЛКИ, 2008) предполагая, что язык в значительной степени метафоричен, и что эти метафоры дают представление о том, как мы воспринимаем мир. Даже такие, казалось бы, конкретные термины, как «денежный поток» (cash flow), используемый в разговоре о финансовой системе, можно рассматривать как метафору: «деньги как вода». Как эта метафора влияет на наше восприятие систем, работающих с деньгами? Или же часто используется метафора слоёв в стеке протоколов, где пользовательские слои «вверху», а детали технологии «внизу». Это влияет на то, как мы представляем структуру систем, которые мы строим. Это также может указывать на стремление мыслить шаблонно, от чего время от времени бывает полезно отказываться.
Мартин Хайдеггер внимательно изучил, как люди пользуются инструментами. Программисты создают, меняют, дорабатывают и используют инструменты. Инструменты – постоянный объект интереса программистов. Но для пользователей, как показывает Хайддегер в книге «Бытие и время», инструмент невидим, и понять его можно только при использовании. Для пользователей инструменты становятся объектами изучения только тогда, когда они не работают. Это различие в акцентах стоит иметь в виду всякий раз, когда обсуждается удобство использования.
Элеонора Рош пересмотрела модель категорий Аристотеля, согласно которой мы выстраиваем своё понимание мира. Когда программисты спрашивают пользователей об их желаниях относительно системы, они, как правило, просят дать определения на основе предикатов (некоторых утверждений о субъекте разговора). Например, делать что-то, если случаются события A, B или C. Для программистов это очень удобно. Предикаты могут легко стать атрибутами класса или столбцами в таблице. Эти категории чёткие, непересекающиеся и аккуратные. К сожалению, как показала Рош в работе «Естественные категории» ("Natural categories", Rosch, E. H. - Cognitive Psychology, 1973) и более поздних работах, обычные люди понимают мир иначе. Они постигают его на примерах. Некоторые примеры, так называемые прототипы, лучше других. Поэтому результаты могут получаться нечёткими, перекрываться с другими и иметь сложную внутреннюю структуру. Поскольку мы настаиваем на аристотелевских ответах, мы не можем задать пользователям правильных вопросов, отсюда и сложности в достижении взаимопонимания.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Keith Braithwaite
97 Вещей, Которые Должен Знать Каждый Программист
70. Изучайте Гуманитарные Науки
Практически в любом проекте разработки ПО, кроме самых маленьких, люди работают с другими людьми. Во всех областях исследований, кроме самых абстрактных, люди пишут для людей ПО, которое поможет им в достижении какой-либо цели. Люди пишут программы вместе с людьми для людей. Этот бизнес связан с людьми. К сожалению, в процессе обучения программистов очень мало внимания уделяется аспекту взаимодействия с людьми, с которыми они работают. К счастью, есть целая область исследований, которая может помочь.
Например, Людвиг Витгенштейн приводит очень хороший пример в «Философских исследованиях», что любой язык, который мы используем для общения друг с другом, не является – и не может быть – универсальным форматом для передачи мысли, идеи или изображения из головы одного человека в голову другого. Поэтому мы должны быть готовы к недопониманиям уже на этапе сбора требований. Витгенштейн также показывает, что наша способность понимать друг друга вовсе не возникает из общих определений, она возникает из общего опыта, образа жизни. Это может быть одной из причин, по которой программисты, стремящиеся разобраться в проблемах своей проблемной области, как правило, добиваются большего успеха, чем те, кто дистанцируется от неё.
Лакофф и Джонсон представляют нам сборник «Метафоры, которыми мы живем» (Дж. Лакофф, М. Джонсон - ЛКИ, 2008) предполагая, что язык в значительной степени метафоричен, и что эти метафоры дают представление о том, как мы воспринимаем мир. Даже такие, казалось бы, конкретные термины, как «денежный поток» (cash flow), используемый в разговоре о финансовой системе, можно рассматривать как метафору: «деньги как вода». Как эта метафора влияет на наше восприятие систем, работающих с деньгами? Или же часто используется метафора слоёв в стеке протоколов, где пользовательские слои «вверху», а детали технологии «внизу». Это влияет на то, как мы представляем структуру систем, которые мы строим. Это также может указывать на стремление мыслить шаблонно, от чего время от времени бывает полезно отказываться.
Мартин Хайдеггер внимательно изучил, как люди пользуются инструментами. Программисты создают, меняют, дорабатывают и используют инструменты. Инструменты – постоянный объект интереса программистов. Но для пользователей, как показывает Хайддегер в книге «Бытие и время», инструмент невидим, и понять его можно только при использовании. Для пользователей инструменты становятся объектами изучения только тогда, когда они не работают. Это различие в акцентах стоит иметь в виду всякий раз, когда обсуждается удобство использования.
Элеонора Рош пересмотрела модель категорий Аристотеля, согласно которой мы выстраиваем своё понимание мира. Когда программисты спрашивают пользователей об их желаниях относительно системы, они, как правило, просят дать определения на основе предикатов (некоторых утверждений о субъекте разговора). Например, делать что-то, если случаются события A, B или C. Для программистов это очень удобно. Предикаты могут легко стать атрибутами класса или столбцами в таблице. Эти категории чёткие, непересекающиеся и аккуратные. К сожалению, как показала Рош в работе «Естественные категории» ("Natural categories", Rosch, E. H. - Cognitive Psychology, 1973) и более поздних работах, обычные люди понимают мир иначе. Они постигают его на примерах. Некоторые примеры, так называемые прототипы, лучше других. Поэтому результаты могут получаться нечёткими, перекрываться с другими и иметь сложную внутреннюю структуру. Поскольку мы настаиваем на аристотелевских ответах, мы не можем задать пользователям правильных вопросов, отсюда и сложности в достижении взаимопонимания.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Keith Braithwaite
День шестьсот девяносто первый. #ЧтоНовенького
Нововведения в GitHub
Ручные Подтверждения в GitHub Actions
В GitHub Actions в бета версии появились функции развёртывания. Теперь вы можете:
1. Визуализировать пайплайн
2. Создавать среды, в которых можно устанавливать
- Рецензентов, которые подтверждают развёртывание вручную
- Время ожидания перед запуском развёртывания
- Секреты специфичные для каждой среды
Перейдите в Settings > Environments и создайте новую среду. Задайте имя среды и нажмите Configure environment. Добавьте требуемых рецензентов, установив флажок Required reviewers (вы можете добавить список людей и/или команд). После этого не забудьте нажать Save protection rules (см. картинку 1 ниже).
Теперь можно отредактировать файл YAML. В него нужно добавить блок:
Появится красивая визуализация пайплайна (см. картинку 2 ниже). Как видите, процесс прошёл стадии развёртывания и функциональных тестов, а затем остановился. Теперь он ждёт подтверждения от заданных рецензентов. У рецензентов, соответственно, появляется сообщение, что процесс развёртывания ждёт подтверждения. После получения подтверждения процесс продолжается.
Обсуждения
До сих пор GitHub предлагал только Issues и Pull Requests в качестве площадки для обсуждений. Проблема в том, что они имеют линейный формат и хорошо подходят для обсуждения изменений в коде, но не для создания базы знаний сообщества. Беседам нужно отдельное место - для этого и созданы GitHub Discussions.
Обсуждения привязаны к репозиторию вашего проекта. Их многопоточный формат позволяет легко начинать, отвечать и организовывать неструктурированные беседы. Вопросы могут быть отмечены как отвеченные, поэтому со временем база знаний сообщества будет расти естественным образом. А поскольку обсуждения не закрываются, как Issues, они могут легко служить местом для хранения часто задаваемых вопросов и другой совместной документации.
Источники:
- https://devblogs.microsoft.com/devops/i-need-manual-approvers-for-github-actions-and-i-got-them-now/
- https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/
Нововведения в GitHub
Ручные Подтверждения в GitHub Actions
В GitHub Actions в бета версии появились функции развёртывания. Теперь вы можете:
1. Визуализировать пайплайн
2. Создавать среды, в которых можно устанавливать
- Рецензентов, которые подтверждают развёртывание вручную
- Время ожидания перед запуском развёртывания
- Секреты специфичные для каждой среды
Перейдите в Settings > Environments и создайте новую среду. Задайте имя среды и нажмите Configure environment. Добавьте требуемых рецензентов, установив флажок Required reviewers (вы можете добавить список людей и/или команд). После этого не забудьте нажать Save protection rules (см. картинку 1 ниже).
Теперь можно отредактировать файл YAML. В него нужно добавить блок:
environment:Обратите внимание, что имя среды в YAML файле должно совпадать с именем среды, заданной в параметрах GitHub выше.
name: <имя среды>
url: <url развёрнутого в среде сайта>
Появится красивая визуализация пайплайна (см. картинку 2 ниже). Как видите, процесс прошёл стадии развёртывания и функциональных тестов, а затем остановился. Теперь он ждёт подтверждения от заданных рецензентов. У рецензентов, соответственно, появляется сообщение, что процесс развёртывания ждёт подтверждения. После получения подтверждения процесс продолжается.
Обсуждения
До сих пор GitHub предлагал только Issues и Pull Requests в качестве площадки для обсуждений. Проблема в том, что они имеют линейный формат и хорошо подходят для обсуждения изменений в коде, но не для создания базы знаний сообщества. Беседам нужно отдельное место - для этого и созданы GitHub Discussions.
Обсуждения привязаны к репозиторию вашего проекта. Их многопоточный формат позволяет легко начинать, отвечать и организовывать неструктурированные беседы. Вопросы могут быть отмечены как отвеченные, поэтому со временем база знаний сообщества будет расти естественным образом. А поскольку обсуждения не закрываются, как Issues, они могут легко служить местом для хранения часто задаваемых вопросов и другой совместной документации.
Источники:
- https://devblogs.microsoft.com/devops/i-need-manual-approvers-for-github-actions-and-i-got-them-now/
- https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/
День шестьсот девяносто второй. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.
Например, недавно я боролся с доменом с большим количеством сложной бизнес-логики. Нормой были пограничные случаи, и мы хотели разработать систему, которая успешно с ними справляется. Именно тогда я прочитал о предметно-ориентированном проектировании. Я смог мгновенно применить его на практике. Впоследствии я лучше усвоил эти концепции. Я приобрёл новую ментальную модель создания корпоративного ПО.
Второй способ поиска новых ментальных моделей – читать статьи, появляющиеся на специализированных ресурсах (например, на Хабре). Там вы можете подчерпнуть интересные идеи. Однако они намного менее эффективны, чем описанная выше техника. Единственная причина заниматься этим на постоянной основе – набирать багаж навыков. Это позволяет знать о методах решения проблем, поэтому, когда я сталкиваюсь с проблемой, я могу вспомнить, что где-то читал про метод, который может помочь.
Последний способ - это изучение новых языков. Изучение нового диалекта или новых функций языка принесёт гораздо меньше пользы, чем, скажем, изучение языка, абсолютно непохожего на ваш. Каждый язык имеет свой словарный запас и грамматику, и позволяет по-иному смотреть на вещи.
Когда управление памятью находится под вашим контролем, вы понимаете, как работают указатели и выделение памяти. Когда C# абстрагирует это, вы цените снижение сложности. Когда в функциональном языке используются фильтры и проекции, вы понимаете, как можно заменить циклы for. И тогда вы замечаете, что в ООП некоторые вещи становятся проще. Нет одного волшебного инструмента, который подошёл бы ко всему. Но несмотря на это, вам не нужно менять ваш инструмент. Вы можете адаптировать передовой опыт для решения ваших проблем: например, использовать функциональные парадигмы в ООП. Принципы важнее, чем способы их выражения.
3. Стратегии повышения эффективности повседневной деятельности
Другая сторона медали - привычки, позволяющие хорошо мыслить. Это начинается с того, что вы в течение дня замечаете мелкие нюансы, которые вызывают у вас раздражение: неэффективные собрания, тормозящая программа, какая-нибудь рутинная задача, требующая от вас постоянно выполнять одни и те же действия. Затем вы придумываете стратегию, как этого избежать. Эти мелкие улучшения часто недооцениваются.
Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День шестьсот девяносто третий.
Nuget Пакеты, с Которыми Должен Быть Знаком Каждый .NET разработчик
1. xUnit и NUnit
Пакеты для юнит-тестов. Ничего необычного.
2. Moq и NSubstitute
Также для написания юнит-тестов – пакеты для создания фиктивных объектов в тестах.
3. Polly
Пакет для осуществления повторных попыток. Если у вас есть API, который может быть недоступен какое-то время, вам необходимо реализовать механизм повторения запросов, и Polly очень облегчит вам жизнь.
4. FluentAssertions
Снова вернёмся к юнит-тестам. Этот пакет позволяет создавать утверждения, вызывая цепочку методов, что делает выражение близким к обычному английскому языку, например:
Один из самых известных пакетов вообще и для теста производительности вашего кода в частности.
6. Serilog
Пакет для ведения журналов. Хотя, здесь можно назвать и ещё несколько похожих. Да и логгер по умолчанию от Майкрософт в последнее время переписан и усовершенствован.
7. Autofixture и Bogus
Эти пакеты позволяют вам сгенерировать тестовые данные для вашей базы данных на стадии разработки, либо для тестов. По умолчанию Autofixture создаст случайные данные, тогда как Bogus больше ориентирован на домен, и создаст данные близкие к реальности.
8. Scrutor
Пакет, расширяющий встроенные в .NET возможности внедрения зависимостей. Работает на соглашениях об именовании. Также позволяет декорировать внедрённую зависимость.
9. Automapper
Очень широко используемый пакет для связи объектов передачи данных (DTO) с объектами бизнес-логики.
10. Dapper и Entity Framework Core
Описание ORM пакетов потянет на целую книгу. Здесь стоит отметить, что эти 2 пакета можно использовать совместно. Например, Dapper для чтения из БД из-за его скорости, а EF Core – для записи, поскольку он хорошо справляется со сложными запросами на модификацию данных.
11. MediatR
Очень широко используемый пакет для реализации паттерна CQRS.
12. FluentValidation
Аналогично FluentAssertions предоставляет интерфейс цепочки методов для валидации объектов.
13. Swagger, Refit и RestSharp
Пакеты, позволяющие вам создавать клиентов для ваших REST API. Первые два больше полагаются на созданные вами объекты модели, последний предоставляет fluent-интерфейс.
14. Json.NET
Пакет от Newtonsoft для сериализации/десериализации в JSON. Майкрософт довольно неплохо усовершенствовали стандартную сериализацию, но Json.NET всё ещё превосходит её во многих аспектах.
Какие полезные NuGet пакеты вы используете? Оставляйте варианты в комментариях.
Источник: https://www.youtube.com/watch?v=qapJwFY9y2Y
Nuget Пакеты, с Которыми Должен Быть Знаком Каждый .NET разработчик
1. xUnit и NUnit
Пакеты для юнит-тестов. Ничего необычного.
2. Moq и NSubstitute
Также для написания юнит-тестов – пакеты для создания фиктивных объектов в тестах.
3. Polly
Пакет для осуществления повторных попыток. Если у вас есть API, который может быть недоступен какое-то время, вам необходимо реализовать механизм повторения запросов, и Polly очень облегчит вам жизнь.
4. FluentAssertions
Снова вернёмся к юнит-тестам. Этот пакет позволяет создавать утверждения, вызывая цепочку методов, что делает выражение близким к обычному английскому языку, например:
actual.Should().Contain("EF").And.HaveLength(6)…
5. BenchmarkDotNetОдин из самых известных пакетов вообще и для теста производительности вашего кода в частности.
6. Serilog
Пакет для ведения журналов. Хотя, здесь можно назвать и ещё несколько похожих. Да и логгер по умолчанию от Майкрософт в последнее время переписан и усовершенствован.
7. Autofixture и Bogus
Эти пакеты позволяют вам сгенерировать тестовые данные для вашей базы данных на стадии разработки, либо для тестов. По умолчанию Autofixture создаст случайные данные, тогда как Bogus больше ориентирован на домен, и создаст данные близкие к реальности.
8. Scrutor
Пакет, расширяющий встроенные в .NET возможности внедрения зависимостей. Работает на соглашениях об именовании. Также позволяет декорировать внедрённую зависимость.
9. Automapper
Очень широко используемый пакет для связи объектов передачи данных (DTO) с объектами бизнес-логики.
10. Dapper и Entity Framework Core
Описание ORM пакетов потянет на целую книгу. Здесь стоит отметить, что эти 2 пакета можно использовать совместно. Например, Dapper для чтения из БД из-за его скорости, а EF Core – для записи, поскольку он хорошо справляется со сложными запросами на модификацию данных.
11. MediatR
Очень широко используемый пакет для реализации паттерна CQRS.
12. FluentValidation
Аналогично FluentAssertions предоставляет интерфейс цепочки методов для валидации объектов.
13. Swagger, Refit и RestSharp
Пакеты, позволяющие вам создавать клиентов для ваших REST API. Первые два больше полагаются на созданные вами объекты модели, последний предоставляет fluent-интерфейс.
14. Json.NET
Пакет от Newtonsoft для сериализации/десериализации в JSON. Майкрософт довольно неплохо усовершенствовали стандартную сериализацию, но Json.NET всё ещё превосходит её во многих аспектах.
Какие полезные NuGet пакеты вы используете? Оставляйте варианты в комментариях.
Источник: https://www.youtube.com/watch?v=qapJwFY9y2Y
День шестьсот девяносто четвёртый.
Microsoft вводит бесплатное продление сертификатов
За последний год в Microsoft Azure добавили более 1000 новых возможностей. Быстрые темпы технологических изменений меняют и картину востребованных навыков в цифровом мире.
В Microsoft Learn создали набор тренингов и сертификатов, призванных помочь техническим специалистам оставаться в курсе событий. В 2021 году вводится несколько обновлений в программы сертификации.
Во-первых, сертифицированным специалистам предоставляется возможность продлить свои сертификаты Microsoft, изначально полученные путём сдачи экзаменов. В начале февраля 2021 года можно будет продлить срок действия сертификатов, пройдя бесплатный аттестационный тест в Microsoft Learn. Вместо того, чтобы пересдавать экзамены, тест можно пройти онлайн в удобное для вас время в течение шести месяцев до истечения срока действия вашего сертификата. После прохождения аттестации сертификация продлевается ещё на один год с текущей даты истечения срока действия. И это можно делать ежегодно. Для помощи в подготовке будет доступна бесплатная коллекция учебных модулей для каждого аттестационного теста.
Во-вторых, срок действия сертификатов теперь ограничен годом, начиная с даты получения. С июня 2021 г. это изменение вступит в силу для новых сертификатов. Переход на одногодичный срок действия сертификации зависит от того, насколько быстро меняются облачные технологии. Ежегодное обновление сертификатов подтверждает, что навыки и способность выполнять свои должностные обязанности актуальны на рынке.
Этот новый подход побуждает специалистов оставаться на волне актуальных технологий, но в то же время позволяет снизить нагрузку и затраты на поддержание активности вашей сертификации.
Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/stay-current-with-in-demand-skills-through-free-certification/ba-p/1489678
Microsoft вводит бесплатное продление сертификатов
За последний год в Microsoft Azure добавили более 1000 новых возможностей. Быстрые темпы технологических изменений меняют и картину востребованных навыков в цифровом мире.
В Microsoft Learn создали набор тренингов и сертификатов, призванных помочь техническим специалистам оставаться в курсе событий. В 2021 году вводится несколько обновлений в программы сертификации.
Во-первых, сертифицированным специалистам предоставляется возможность продлить свои сертификаты Microsoft, изначально полученные путём сдачи экзаменов. В начале февраля 2021 года можно будет продлить срок действия сертификатов, пройдя бесплатный аттестационный тест в Microsoft Learn. Вместо того, чтобы пересдавать экзамены, тест можно пройти онлайн в удобное для вас время в течение шести месяцев до истечения срока действия вашего сертификата. После прохождения аттестации сертификация продлевается ещё на один год с текущей даты истечения срока действия. И это можно делать ежегодно. Для помощи в подготовке будет доступна бесплатная коллекция учебных модулей для каждого аттестационного теста.
Во-вторых, срок действия сертификатов теперь ограничен годом, начиная с даты получения. С июня 2021 г. это изменение вступит в силу для новых сертификатов. Переход на одногодичный срок действия сертификации зависит от того, насколько быстро меняются облачные технологии. Ежегодное обновление сертификатов подтверждает, что навыки и способность выполнять свои должностные обязанности актуальны на рынке.
Этот новый подход побуждает специалистов оставаться на волне актуальных технологий, но в то же время позволяет снизить нагрузку и затраты на поддержание активности вашей сертификации.
Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/stay-current-with-in-demand-skills-through-free-certification/ba-p/1489678
День шестьсот девяносто пятый. #ЧтоНовенького
Критические Изменения в .NET5. WPF/Windows Forms
В заключительной части нашего обзора критических изменений в .NET 5 рассмотрим WPF/Windows Forms.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
- ASP.NET Core. Окончание
Windows Forms, наряду с веб-формами, консолью и службами Windows, была одной из исходных сред приложений в первом .NET, вышедшем в 2002 году. Среда действует как тонкая оболочка для нативных элементов управления Windows. Это обеспечивает хорошую производительность, но довольно ограничено в настройках. Первое серьезное изменение в WinForms появилось в .NET 2.0 в 2005 году. Были заменены различные пользовательские элементы управления. С тех пор технология считается «завершённой». Единственные заметные изменения - это периодические обновления для поддержки мониторов с более высоким разрешением. Даже долго не решаемые ошибки обычно игнорировались, к большому раздражению разработчиков на WinForms.
Windows Presentation Foundation (WPF) была первой попыткой Microsoft создать полностью настраиваемую среду графического интерфейса. Несмотря на то, что он был выпущен всего через 4 года после WinForms, потребовалось время, чтобы стать общепринятым, поскольку шаблоны и концепции проектирования были более сложными. Производительность также может быть проблемой. Двумя ключевыми особенностями WPF были использование XAML для макета пользовательского интерфейса и шаблона MVVM для привязки данных. Как и WinForms, WPF долгие годы считался «законченным». Он даже не получил поддержки XAML-2009 после того, как спецификация XAML была выпущена в 2012 году. Такие проекты, как Avalonia, пытались сгладить недостатки WPF, например, позволяя привязку событий непосредственно к методу модели или модели представления.
1. Новый SDK
В .NET Core 3.x для WPF и WinForms требовался специальный SDK
2. Убран вывод в консоль
Хотя подавляющее большинство приложений WPF и WinForms не отображаются в консоли, на самом деле это не запрещено, это просто значение по умолчанию. Если нужно, вы можете установить для
3. Улучшенная обработка ошибок
В Windows Forms для .NET Core 3 большей части кода валидации просто не существовало. То есть переданный недопустимый аргумент мог вызвать исключение
4. Удалены элементы управления строки состояния
Одним из элементов управления, заменённых в .NET Framework 2, стал
Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-windows/
Критические Изменения в .NET5. WPF/Windows Forms
В заключительной части нашего обзора критических изменений в .NET 5 рассмотрим WPF/Windows Forms.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение
- ASP.NET Core. Окончание
Windows Forms, наряду с веб-формами, консолью и службами Windows, была одной из исходных сред приложений в первом .NET, вышедшем в 2002 году. Среда действует как тонкая оболочка для нативных элементов управления Windows. Это обеспечивает хорошую производительность, но довольно ограничено в настройках. Первое серьезное изменение в WinForms появилось в .NET 2.0 в 2005 году. Были заменены различные пользовательские элементы управления. С тех пор технология считается «завершённой». Единственные заметные изменения - это периодические обновления для поддержки мониторов с более высоким разрешением. Даже долго не решаемые ошибки обычно игнорировались, к большому раздражению разработчиков на WinForms.
Windows Presentation Foundation (WPF) была первой попыткой Microsoft создать полностью настраиваемую среду графического интерфейса. Несмотря на то, что он был выпущен всего через 4 года после WinForms, потребовалось время, чтобы стать общепринятым, поскольку шаблоны и концепции проектирования были более сложными. Производительность также может быть проблемой. Двумя ключевыми особенностями WPF были использование XAML для макета пользовательского интерфейса и шаблона MVVM для привязки данных. Как и WinForms, WPF долгие годы считался «законченным». Он даже не получил поддержки XAML-2009 после того, как спецификация XAML была выпущена в 2012 году. Такие проекты, как Avalonia, пытались сгладить недостатки WPF, например, позволяя привязку событий непосредственно к методу модели или модели представления.
1. Новый SDK
В .NET Core 3.x для WPF и WinForms требовался специальный SDK
Microsoft.NET.Sdk.WindowsDesktop. В .NET5 они используют Microsoft.NET.Sdk, как и любой другой проект. Однако целевой платформой должна быть net5.0-windows, а не просто net5.0.2. Убран вывод в консоль
Хотя подавляющее большинство приложений WPF и WinForms не отображаются в консоли, на самом деле это не запрещено, это просто значение по умолчанию. Если нужно, вы можете установить для
OutputType значение Exe вместо WinExe. В .NET5 параметр OutputType будет игнорироваться, если вы также не установите для DisableWinExeOutputInference значение true.3. Улучшенная обработка ошибок
В Windows Forms для .NET Core 3 большей части кода валидации просто не существовало. То есть переданный недопустимый аргумент мог вызвать исключение
NullReferenceException или просто вести себя неопределённым образом. В .NET5 будет выброшено более соответствующее исключение ArgumentException, ArgumentNullException или ArgumentOutOfRangeException. 4. Удалены элементы управления строки состояния
Одним из элементов управления, заменённых в .NET Framework 2, стал
StatusBar. Эквивалент в .NET 2 - StatusStrip. В Microsoft не объяснили, почему его нужно было удалить, возможно, затраты на обслуживание были слишком высоки для элемента, о существовании которого большинство людей даже не подозревает. StatusBar уже очень давно не отображается в панели инструментов дизайнера и полностью удалён в .NET5.Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-windows/
День шестьсот девяносто шестой. #Оффтоп
Доброй рабоче-нерабочей субботы, дорогие товарищи. На сегодня у меня для вас лёгенькое 3х-часовое интервью с 78-летним программистом от IT Бороды. https://www.youtube.com/watch?v=eqsg3Blzmdg Жёсткие диски бы делать из таких людей!
Доброй рабоче-нерабочей субботы, дорогие товарищи. На сегодня у меня для вас лёгенькое 3х-часовое интервью с 78-летним программистом от IT Бороды. https://www.youtube.com/watch?v=eqsg3Blzmdg Жёсткие диски бы делать из таких людей!
День шестьсот девяносто седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
97 Вещей, Которые Должен Знать Каждый Программист
71. Изобретайте Велосипеды
Просто используйте то, что уже существует. Глупо изобретать велосипед…
Сколько раз вы слышали эту фразу или её вариации? Каждому разработчику это приходится слышать довольно часто. Но почему? Почему изобретение велосипеда так осуждается? Потому что чаще всего существующий код является рабочим кодом. Он уже прошёл какой-то контроль качества и тщательное тестирование и успешно используется. Кроме того, время и усилия, вложенные в переписывание, вряд ли окупят выгоды перед использованием существующего продукта или кодовой базы. Стоит ли изобретать велосипед? Зачем? Когда?
Возможно, вы слышали о паттернах (#DesignPatterns) разработки или читали книги по разработке ПО. Эти книги могут быть скучными, независимо от того, насколько прекрасна содержащаяся в них информация. Точно так же, как просмотр фильма о парусном спорте сильно отличается от парусного спорта. Так и использование существующего кода намного скучнее разработки собственного ПО с нуля, его тестирования, взлома, починки и улучшения в процессе.
Изобретение велосипеда - это не просто упражнение в том, где разместить конструкции кода: это о том, как получить глубокие знания о внутренней работе различных компонентов, которые уже существуют. Вы знаете, как работают менеджеры памяти? Виртуальный пейджинг? Можете реализовать это самостоятельно? Как насчет двусвязных списков? Классов динамических массивов? ODBC-клиента? Можете написать графический пользовательский интерфейс, который бы работал так же, как один из популярных, известных вам? Можете создать свой собственный виджет для браузера? Знаете, как «на лету» выбрать между записью в постоянную БД или в БД в памяти?
Большинство разработчиков просто никогда сами не создавали такие типы основных программных реализаций и поэтому не имеют глубоких знаний о том, как они функционируют. Как следствие, все эти виды программного обеспечения рассматриваются как загадочные чёрные ящики, которые просто работают. Только поверхностного понимания недостаточно, чтобы выявить скрытые в глубине опасности. Незнание более глубоких вещей в разработке программного обеспечения ограничит вашу способность создавать блестящие продукты.
Изобретать велосипед и ошибаться гораздо важнее, чем делать всё правильно с первого раза. Уроки, извлечённые из проб и ошибок, содержат эмоциональную составляющую, которую невозможно получить при чтении технической книги!
Изученные факты и «книжные навыки» имеют решающее значение. Но для того, чтобы стать отличным программистом, приобретённый опыт не менее важен, чем полученные знания. Изобретать велосипед так же важно для образования и навыков разработчика, как тяжелая атлетика важна для бодибилдера.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jason P. Sage
День шестьсот девяносто восьмой. #MoreEffectiveCSharp
18. Предпочитайте Переопределения Обработчикам Событий
Многие классы .NET предоставляют два разных способа обработки событий. Вы можете подписать обработчик событий или переопределить виртуальную функцию базового класса. Внутри производных классов вы всегда должны переопределять виртуальную функцию. Ограничьте использование обработчиков событий реагированием на события в несвязанных объектах.
Рассмотрим код приложения WPF, где нужно реагировать на события нажатия мыши. Вы можете переопределить метод
Хорошо, но подписка на события зачем-то добавлена. Зачем?
1. Переопределения предназначены для производных классов. Но сторонние классы должны использовать механизм событий.
2. XAML поддерживает декларативную подписку на события. То есть дизайнер приложения в визуальном редакторе может выбрать действие при нажатии мыши, если оно доступно, и не добавлять работы программисту.
3. Это позволяет подписываться на события во время выполнения. Вы можете подключить разные обработчики событий, в зависимости от обстоятельств выполнения программы.
4. Возможно подключить несколько обработчиков к одному событию.
Итого
Когда у вас есть одна функция, которая обрабатывает одно событие в производном классе, переопределение является лучшим подходом. Это решение легче поддерживать, оно с большей вероятностью сохранит корректность с течением времени и более эффективно. Оставьте обработчики событий для других целей.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 18.
18. Предпочитайте Переопределения Обработчикам Событий
Многие классы .NET предоставляют два разных способа обработки событий. Вы можете подписать обработчик событий или переопределить виртуальную функцию базового класса. Внутри производных классов вы всегда должны переопределять виртуальную функцию. Ограничьте использование обработчиков событий реагированием на события в несвязанных объектах.
Рассмотрим код приложения WPF, где нужно реагировать на события нажатия мыши. Вы можете переопределить метод
OnMouseDown():public partial class MainWindow : WindowЛибо вы можете подписать обработчик события, что требует изменений как в файле C#, так и в файле XAML:
{
//…
protected override void OnMouseDown(MouseButtonEventArgs e)
{
DoMouseThings(e);
base.OnMouseDown(e);
}
}
<Window x:Class="WpfApp1.MainWindow"Следует предпочесть первое решение, и вот почему. При переопределении функции сначала вызывается ваш обработчик, а вызов функции базового класса отвечает за вызов любых обработчиков событий в цепочке. В некоторых редких случаях вам может потребоваться заменить поведение по умолчанию, чтобы другие обработчики не вызывались, но зачастую поведение по умолчанию – то, что вам нужно. Кроме того, в первом варианте нужно поддерживать изменение в одном месте, а во втором – в двух.
xmlns:local="clr-namespace:WpfApp1"
mc:Ignorable="d"
Title="MainWindow" Height="350" Width="525"
MouseDown="OnMouseDownHandler">
<Grid></Grid>
</Window>
public partial class MainWindow : Window
{
//…
private void OnMouseDownHandler(
object sender, MouseButtonEventArgs e)
{
DoMouseThings(e);
}
}
Хорошо, но подписка на события зачем-то добавлена. Зачем?
1. Переопределения предназначены для производных классов. Но сторонние классы должны использовать механизм событий.
2. XAML поддерживает декларативную подписку на события. То есть дизайнер приложения в визуальном редакторе может выбрать действие при нажатии мыши, если оно доступно, и не добавлять работы программисту.
3. Это позволяет подписываться на события во время выполнения. Вы можете подключить разные обработчики событий, в зависимости от обстоятельств выполнения программы.
4. Возможно подключить несколько обработчиков к одному событию.
Итого
Когда у вас есть одна функция, которая обрабатывает одно событие в производном классе, переопределение является лучшим подходом. Это решение легче поддерживать, оно с большей вероятностью сохранит корректность с течением времени и более эффективно. Оставьте обработчики событий для других целей.
Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 18.
День шестьсот девяносто девятый. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
4. Следите за скоростью
Я заметил, что более медленный темп даёт прирост моей производительности. Хотите сделать больше? Не торопитесь. Вот что я имею в виду.
Я заметил, что люди спешат решать проблемы. Это может быть что-то, что они делали раньше, или что-то, на что у нас есть шаблон решения. Приятно щёлкать задачи, как орешки. Я тоже так делал раньше. Однако есть очень ограниченное количество случаев, когда это имеет смысл.
Каждый раз, когда я работаю над чем-то новым, я нахожу время, чтобы узнать кое-что о системе, с которой я работаю, и вещах, тесно связанных с ней. Если она слишком большая, я стараюсь учиться как можно больше. Каждый раз, когда я возвращаюсь к системе, я стремлюсь узнать больше.
Когда вы не торопитесь, у вас есть шанс поэкспериментировать, поучиться и обдумать логику. Значит останется достаточно времени, чтобы всё сделать. В условиях постоянной спешки сроки горят, и всё ваше внимание сосредоточено на завершении задачи. Защищать свой темп - значит не позволять дедлайнам овладевать вами. Часто для этого достаточно просто поговорить с вашим начальством.
Неторопливость может со стороны показаться бездельничаньем, но умение отстоять возможность работать в своём темпе - это суперсила. Это долгосрочное вложение в собственное развитие за счет краткосрочной эффективности. Когда я тороплюсь завершить задачу, мне гораздо труднее обнаруживать и исправлять ошибки. Я не трачу время на обдумывание правильных логических конструкций, а это значит, что мои предположения могут не соответствовать существующему коду, и именно в этом несоответствии кроется большинство ошибок. Я отстаиваю возможность работы в своём темпе, поэтому я могу выделить время, чтобы уделить больше внимания обучению, а не исполнению.
Один из моих любимых вариантов использования времени - экспериментирование. Иногда я обнаруживаю ошибку, которая не имеет для меня никакого смысла. Я понимаю, что запутался, но при этом нахожу ответ на Stack Overflow и продолжаю работу. Однако меня беспокоит то, что я не понял причину появления ошибки. Stack Overflow дал ответ, но не объяснение, что было не так в моём понимании логики работы программы. Чтобы укрепить свое понимание, мне нужно поэкспериментировать.
Если у меня нет свободного времени, мне некогда экспериментировать, а значит, я должен забыть об этой ошибке. И напротив, если есть возможность провести пару экспериментов, можно точно выяснить, чего я не понимал. Я люблю такие моменты, когда я узнаю что-то новое о системе. В следующий раз это сделает меня намного эффективнее.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.
4. Следите за скоростью
Я заметил, что более медленный темп даёт прирост моей производительности. Хотите сделать больше? Не торопитесь. Вот что я имею в виду.
Я заметил, что люди спешат решать проблемы. Это может быть что-то, что они делали раньше, или что-то, на что у нас есть шаблон решения. Приятно щёлкать задачи, как орешки. Я тоже так делал раньше. Однако есть очень ограниченное количество случаев, когда это имеет смысл.
Каждый раз, когда я работаю над чем-то новым, я нахожу время, чтобы узнать кое-что о системе, с которой я работаю, и вещах, тесно связанных с ней. Если она слишком большая, я стараюсь учиться как можно больше. Каждый раз, когда я возвращаюсь к системе, я стремлюсь узнать больше.
Когда вы не торопитесь, у вас есть шанс поэкспериментировать, поучиться и обдумать логику. Значит останется достаточно времени, чтобы всё сделать. В условиях постоянной спешки сроки горят, и всё ваше внимание сосредоточено на завершении задачи. Защищать свой темп - значит не позволять дедлайнам овладевать вами. Часто для этого достаточно просто поговорить с вашим начальством.
Неторопливость может со стороны показаться бездельничаньем, но умение отстоять возможность работать в своём темпе - это суперсила. Это долгосрочное вложение в собственное развитие за счет краткосрочной эффективности. Когда я тороплюсь завершить задачу, мне гораздо труднее обнаруживать и исправлять ошибки. Я не трачу время на обдумывание правильных логических конструкций, а это значит, что мои предположения могут не соответствовать существующему коду, и именно в этом несоответствии кроется большинство ошибок. Я отстаиваю возможность работы в своём темпе, поэтому я могу выделить время, чтобы уделить больше внимания обучению, а не исполнению.
Один из моих любимых вариантов использования времени - экспериментирование. Иногда я обнаруживаю ошибку, которая не имеет для меня никакого смысла. Я понимаю, что запутался, но при этом нахожу ответ на Stack Overflow и продолжаю работу. Однако меня беспокоит то, что я не понял причину появления ошибки. Stack Overflow дал ответ, но не объяснение, что было не так в моём понимании логики работы программы. Чтобы укрепить свое понимание, мне нужно поэкспериментировать.
Если у меня нет свободного времени, мне некогда экспериментировать, а значит, я должен забыть об этой ошибке. И напротив, если есть возможность провести пару экспериментов, можно точно выяснить, чего я не понимал. Я люблю такие моменты, когда я узнаю что-то новое о системе. В следующий раз это сделает меня намного эффективнее.
Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar
День семисотый. #Оффтоп
5 обязательных навыков для разработчиков 2021. Начало
Дни, когда разработчики просто сидели перед своими компьютерами и печатали код, давно прошли. В современном мире разработка ПО - это гораздо больше: это скорее культура и карьера. Вы когда-нибудь чувствовали себя отвратительно из-за того, что не смогли найти работу или пройти собеседование? Конечно, мы все прошли через эту фазу, у неё даже есть название... синдром самозванца. Но сейчас не об этом. Мы обсудим 5 обязательных навыков для разработчиков в 2021 году, которые помогут вам добиться успеха, стать современным разработчиком и повысить ваши шансы при общении с потенциальными работодателями.
1. Навыки обучения
Способность к обучению - важный навык, которым должен обладать каждый разработчик. Вы будете сталкиваться с многочисленными проблемами и новым набором задач почти каждый день. Вам нужно уметь учиться и быстро усваивать весь гигантский объём информации, с которым вы будете сталкиваться. Общие советы, как научиться чему-либо быстрее:
- Ограничить количество вещей, которые вы изучаете за раз. Будьте конкретны в том, что вы изучаете и усваиваете в каждый конкретный момент, потому что вы не можете изучить, усвоить и понять несколько вещей одновременно.
- Практикуйтесь по-настоящему и пишите код. Если вы изучаете новый язык или библиотеку, обязательно пишите код по мере чтения. Избегайте чтения сегодня и практики завтра, практикуйтесь здесь и сейчас.
2. Навыки прохождения собеседования
Это одни из самых важных навыков, которыми должен обладать разработчик, потому что без него вам будет сложно устроиться на работу. Вот некоторые важные моменты, которые помогли мне в процессе собеседования:
- Изучите компанию
Нельзя входить в комнату для собеседований полным новичком. Нужно провести исследование, узнать кого именно компания ищет, что ценит в работниках, помимо простого описания в вакансии. Нужно научиться позиционировать себя как идеального человека, которого ищет компания, на основе проведенного вами исследования. Просмотрите веб-сайт компании, найдите их страницы в социальных сетях и прочие данные о компании в сети. Наконец, обратите внимание на описание вакансии: из него также можно извлечь много полезной информации. Это поможет вам как правильно отвечать на вопросы интервьюера, так и задавать ему правильные вопросы.
- Задавайте вопросы интервьюеру
Это мой любимый совет на все времена: процесс собеседования должен быть диалогом между вами и интервьюером, а не экзаменом. Вам также необходимо провести собеседование с интервьюером, задав соответствующие вопросы. Этот процесс может помочь вам лучше понять компанию, команду и менеджеров. Вы можете использовать эту информацию, чтобы предложить идею, которая поможет развитию их компании. Вы должны выглядеть заинтересованными в компании, а не только в должности. Интервьюер долен видеть это и по вашему выражению лица, и по манере вашего разговора. Представьте, что кандидат во время интервью даёт компании идею, как кардинально улучшить бизнес-процесс и заработать больше денег. Как вы думаете, откажется ли компания от такого кандидата?
- Расслабьтесь и будьте собой
Наконец, расслабьтесь, это просто интервью, это обычный разговор, который вы вели много раз. Не нервничайте, будь, что будет. Даже если вы не получите работу, это не означает, что вы ни на что не годны. Возможно, компании просто не нужен такой кандидат, как вы, и вам не следует пытаться вписаться в неё, во что бы то ни стало. Не притворяйтесь кем-то, кем вы не являетесь, лишь для того, чтобы получить работу. Это может только навредить вам, потому что вы можете не вписываться в их культуру, вы можете не стать хорошим командным игроком. Будьте лучшей версией себя, и позвольте интервьюеру определить, кто подходит для его компании. А лучший вариант для вас ещё найдётся.
Окончание следует…
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
5 обязательных навыков для разработчиков 2021. Начало
Дни, когда разработчики просто сидели перед своими компьютерами и печатали код, давно прошли. В современном мире разработка ПО - это гораздо больше: это скорее культура и карьера. Вы когда-нибудь чувствовали себя отвратительно из-за того, что не смогли найти работу или пройти собеседование? Конечно, мы все прошли через эту фазу, у неё даже есть название... синдром самозванца. Но сейчас не об этом. Мы обсудим 5 обязательных навыков для разработчиков в 2021 году, которые помогут вам добиться успеха, стать современным разработчиком и повысить ваши шансы при общении с потенциальными работодателями.
1. Навыки обучения
Способность к обучению - важный навык, которым должен обладать каждый разработчик. Вы будете сталкиваться с многочисленными проблемами и новым набором задач почти каждый день. Вам нужно уметь учиться и быстро усваивать весь гигантский объём информации, с которым вы будете сталкиваться. Общие советы, как научиться чему-либо быстрее:
- Ограничить количество вещей, которые вы изучаете за раз. Будьте конкретны в том, что вы изучаете и усваиваете в каждый конкретный момент, потому что вы не можете изучить, усвоить и понять несколько вещей одновременно.
- Практикуйтесь по-настоящему и пишите код. Если вы изучаете новый язык или библиотеку, обязательно пишите код по мере чтения. Избегайте чтения сегодня и практики завтра, практикуйтесь здесь и сейчас.
2. Навыки прохождения собеседования
Это одни из самых важных навыков, которыми должен обладать разработчик, потому что без него вам будет сложно устроиться на работу. Вот некоторые важные моменты, которые помогли мне в процессе собеседования:
- Изучите компанию
Нельзя входить в комнату для собеседований полным новичком. Нужно провести исследование, узнать кого именно компания ищет, что ценит в работниках, помимо простого описания в вакансии. Нужно научиться позиционировать себя как идеального человека, которого ищет компания, на основе проведенного вами исследования. Просмотрите веб-сайт компании, найдите их страницы в социальных сетях и прочие данные о компании в сети. Наконец, обратите внимание на описание вакансии: из него также можно извлечь много полезной информации. Это поможет вам как правильно отвечать на вопросы интервьюера, так и задавать ему правильные вопросы.
- Задавайте вопросы интервьюеру
Это мой любимый совет на все времена: процесс собеседования должен быть диалогом между вами и интервьюером, а не экзаменом. Вам также необходимо провести собеседование с интервьюером, задав соответствующие вопросы. Этот процесс может помочь вам лучше понять компанию, команду и менеджеров. Вы можете использовать эту информацию, чтобы предложить идею, которая поможет развитию их компании. Вы должны выглядеть заинтересованными в компании, а не только в должности. Интервьюер долен видеть это и по вашему выражению лица, и по манере вашего разговора. Представьте, что кандидат во время интервью даёт компании идею, как кардинально улучшить бизнес-процесс и заработать больше денег. Как вы думаете, откажется ли компания от такого кандидата?
- Расслабьтесь и будьте собой
Наконец, расслабьтесь, это просто интервью, это обычный разговор, который вы вели много раз. Не нервничайте, будь, что будет. Даже если вы не получите работу, это не означает, что вы ни на что не годны. Возможно, компании просто не нужен такой кандидат, как вы, и вам не следует пытаться вписаться в неё, во что бы то ни стало. Не притворяйтесь кем-то, кем вы не являетесь, лишь для того, чтобы получить работу. Это может только навредить вам, потому что вы можете не вписываться в их культуру, вы можете не стать хорошим командным игроком. Будьте лучшей версией себя, и позвольте интервьюеру определить, кто подходит для его компании. А лучший вариант для вас ещё найдётся.
Окончание следует…
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
День семьсот первый. #Оффтоп
5 обязательных навыков для разработчиков 2021. Окончание
Начало
3. Будьте «нанимаемым»
Компании хотят знать гораздо больше, чем просто о ваших навыках программирования. Они хотят видеть ваши достижения и подтверждения вашей квалификации, а также хотят убедиться, что у вас есть необходимые навыки хорошего работника.
- Задавайте профессиональные вопросы
Вам нужно научиться задавать профессиональные вопросы. Как на собеседовании, так и просто в разговоре с коллегами. Это скажет вашим работодателям о том, что вы обладаете обширными знаниями в своей области.
- Очистите свои социальные сети
Это может показаться паранойей, и вообще, это ваша личная жизнь. Но всё больше кадровиков ищут информацию о кандидатах в Интернете перед принятием решения о приёме на работу (иногда даже перед собеседованием). И довольно часто кандидаты отсеиваются уже на этом этапе. Поищите себя в сети и посмотрите, какие результаты вы получите. Вы бы приняли себя на работу?
- Обновите своё резюме
Убедитесь, что ваше резюме всегда отражает самую последнюю информацию, а также не содержит неактуальной или вводящей в заблуждение информации.
4. Навыки коммуникации
Ещё один отличный навык, который вам стоит освоить, - это создание социальных связей, знакомств, сотрудничество с коллегами в компании или в вашей сфере специализации. Никто не является кладезем знаний. Нужно сотрудничать с людьми, чтобы вы могли получать помощь, вместе работать над проектами и обмениваться навыками. Быть самым умным парнем с лучшими навыками тайм-менеджмента и знанием всех технических деталей - это хорошо, но рано или поздно найдётся проблема, которая даже вам окажется не под силу. Именно тут помогут сотрудничество и связи. Вы легко сможете найти решение при помощи других специалистов в этой области.
5. Навыки программирования
Как бы банально это ни звучало, будьте профессионалом в том, что вы делаете. Чтобы хорошо программировать, нужно много терпения, времени и постоянная практика. Практикуйте задачи на алгоритмы и частые задачи с собеседований (см. #ЗадачиНаСобеседовании), чтобы тренировать навыки решения задач, а также просматривайте частые вопросы на собеседовании (см. #ВопросыНаСобеседовании), чтобы не забывать теорию. Вы должны отлично владеть хотя бы одним языком программирования, что облегчит для вас изучение других языков.
Какими ещё важными навыками должен, по-вашему, обладать современный программист? Пишите в комментариях. И с наступающим всех!
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
5 обязательных навыков для разработчиков 2021. Окончание
Начало
3. Будьте «нанимаемым»
Компании хотят знать гораздо больше, чем просто о ваших навыках программирования. Они хотят видеть ваши достижения и подтверждения вашей квалификации, а также хотят убедиться, что у вас есть необходимые навыки хорошего работника.
- Задавайте профессиональные вопросы
Вам нужно научиться задавать профессиональные вопросы. Как на собеседовании, так и просто в разговоре с коллегами. Это скажет вашим работодателям о том, что вы обладаете обширными знаниями в своей области.
- Очистите свои социальные сети
Это может показаться паранойей, и вообще, это ваша личная жизнь. Но всё больше кадровиков ищут информацию о кандидатах в Интернете перед принятием решения о приёме на работу (иногда даже перед собеседованием). И довольно часто кандидаты отсеиваются уже на этом этапе. Поищите себя в сети и посмотрите, какие результаты вы получите. Вы бы приняли себя на работу?
- Обновите своё резюме
Убедитесь, что ваше резюме всегда отражает самую последнюю информацию, а также не содержит неактуальной или вводящей в заблуждение информации.
4. Навыки коммуникации
Ещё один отличный навык, который вам стоит освоить, - это создание социальных связей, знакомств, сотрудничество с коллегами в компании или в вашей сфере специализации. Никто не является кладезем знаний. Нужно сотрудничать с людьми, чтобы вы могли получать помощь, вместе работать над проектами и обмениваться навыками. Быть самым умным парнем с лучшими навыками тайм-менеджмента и знанием всех технических деталей - это хорошо, но рано или поздно найдётся проблема, которая даже вам окажется не под силу. Именно тут помогут сотрудничество и связи. Вы легко сможете найти решение при помощи других специалистов в этой области.
5. Навыки программирования
Как бы банально это ни звучало, будьте профессионалом в том, что вы делаете. Чтобы хорошо программировать, нужно много терпения, времени и постоянная практика. Практикуйте задачи на алгоритмы и частые задачи с собеседований (см. #ЗадачиНаСобеседовании), чтобы тренировать навыки решения задач, а также просматривайте частые вопросы на собеседовании (см. #ВопросыНаСобеседовании), чтобы не забывать теорию. Вы должны отлично владеть хотя бы одним языком программирования, что облегчит для вас изучение других языков.
Какими ещё важными навыками должен, по-вашему, обладать современный программист? Пишите в комментариях. И с наступающим всех!
Источник: https://medium.com/backenders-club/5-must-have-skills-for-developers-2021-e64d91f273cc
Автор оригинала – Solomon Eseme
День семьсот второй.
Расслабьтесь и зарядитесь энергией
Для многих из нас большой удачей будет возможность провести новогодние праздники, не отвлекаясь на работу. Если у вас есть такая возможность, используйте её, чтобы отдохнуть и подготовиться к вызовам 2021 года. Проведите время с семьей, даже если вы были с ними весь год из-за карантина. Потратьте несколько минут на приборку рабочего стола (как физического, так и виртуального). Сделайте бекап. Почистите почтовый ящик, откажитесь от ненужных подписок.
Подумайте о том, что вы сделали в прошлом году. Чем вы больше всего гордитесь? В чём вы добились прогресса и что надеетесь улучшить в новом году? Какие у вас долгосрочные карьерные цели и какие шаги вы можете предпринять в новом году для их достижения?
Высыпитесь, наконец! Всё больше исследований показывают, что сон имеет решающее значение для нашего здоровья. Ютуб, сериалы и игры никуда не денутся.
С новым годом!
Автор оригинала: Steve "ardalis" Smith
Расслабьтесь и зарядитесь энергией
Для многих из нас большой удачей будет возможность провести новогодние праздники, не отвлекаясь на работу. Если у вас есть такая возможность, используйте её, чтобы отдохнуть и подготовиться к вызовам 2021 года. Проведите время с семьей, даже если вы были с ними весь год из-за карантина. Потратьте несколько минут на приборку рабочего стола (как физического, так и виртуального). Сделайте бекап. Почистите почтовый ящик, откажитесь от ненужных подписок.
Подумайте о том, что вы сделали в прошлом году. Чем вы больше всего гордитесь? В чём вы добились прогресса и что надеетесь улучшить в новом году? Какие у вас долгосрочные карьерные цели и какие шаги вы можете предпринять в новом году для их достижения?
Высыпитесь, наконец! Всё больше исследований показывают, что сон имеет решающее значение для нашего здоровья. Ютуб, сериалы и игры никуда не денутся.
С новым годом!
Автор оригинала: Steve "ardalis" Smith