Кстати, рекрутёры стали гораздо реже спрашивать: «почему меняете место работы?»
и подобнее вопросы

Это прогресс! Нас услышали!

Нестандартная ситуация

История без имён и скриншотов, потому что я добрый и этичный.

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

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

Слово за слово что-то накидывает про вакансию, условия, грейды, ожидая, что я отвечу. В выходные.

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

Во-первых, такая активность сотрудника в выходные многое говорит о процессах и транслируемых ценностях внутри компании.
Во-вторых, отсутствие границы между личным и профессиональным - верх некомпетентности и непрофессионализма.

Про беженцев

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

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

Нет, вы только прочитайте формулировку: «давно созрело желание пожить в цивилизованном государстве с работающими социальными институтами»

Насколько же это субъективно и эмоционально. Видимо, вместо занятия разработкой такие «специалисты» проходят уроки в школе сарказма Тони Старка.

Тоже хотел бы посетить пару уроков, ведь потом оказывается, что:

▪️Покупательская способность зарплаты падает на несколько порядков

▪️Уровень развития b2c сервисов где-то в каменном веке

▪️Совершенно другой и непонятный ландшафт как рынка труда, так и социума

В общем, не поддавайтесь истерии новостного фона.

Последние пару недель проходил собеседования

Как и многим другим специалистам в индустрии, мне нужен инструмент для объективной оценки себя и исследования конъюктуры рынка.

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

Помимо этого, можно узнать запросы рынка. Какие навыки в тренде, какие устарели. Узнать свои точки роста, в чём плаваешь, в чём спец.

Одним словом, мастхэв.

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

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

Поэтому, мне тоже надо, в своём роде, провести собеседование. Узнать стек, процессы, проблемы, вызовы, задачи. Сделать выводы. И пока обо всём спрашиваю, из-за вовлечённости в процесс, дико устаю.

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

Кто такой senior?

Этим вопросом задаётся каждый в it. Компания, джун, миддл, сам сеньор.

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

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

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

Поэтому, сеньор это тот, кому сказали: «<Имя>, рады вам сообщить, что вы приняты в <компания> на должность senior <что-то там> developer!»

А ещё, можете поздравить меня - получил такое сообщение!

Counter-offer is a bad practice

Сотрудник уходит из компании. Или он ценный кадр, или на рынке дефицит (привет, айти) - не важно. Поиск и замена стоит где-то два его оклада в месяц.

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

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

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

А ещё можно подумать, что его действия случайные и необдуманные. Значит, человек ненадёжный, и ему нужно искать замену. Скорее всего, подешевле.

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

JetBrains облажались

И признались в собственной стагнации и творческой импотенции. Недавно вышел preview release нового продукта Fleet. Но нужен ли он?

Многие ожидали от Fleet «убийство» Visual Studio Code. Давайте пройдёмся по пунктам и разберёмся кого убьёт новая IDE.

В первую очередь, стоит отметить платность Fleet. В будущем, после официального релиза, для его использования будет необходимо купить подписку. На текущий момент модель лицензирования и ценообразования ещё в разработке.

Fleet позиционируется как легковесный редактор, но в реальности дела обстоят иначе. Для установки надо скачать некий JetBrains Toolbox, уже в котором надо выбрать желаемый продукт. Спасибо компании за лишнюю головную боль.

А ещё спасибо за то, что теперь пользователей компьютеров больше не волнует вопрос, куда девать лишнюю ОЗУ. Ведь теперь её не будет. Fleet потребляет от 2 до 3 ГБ оперативной памяти.

Smart mode - это вообще не киллер фича. Мне предлагают довериться некоторому чёрному ящику в вопросах удовлетворения потребностей при разработке, использующей конкретную технологию.

Лучше скачаю подходящую IDE и допилю её соответствующими плагинами, или сделаю это в том же VS Code. А текущая модель расширения Fleet также, всё ещё в разработке, и нет гарантии, что её не свернут.

В общем, ребята выкатили на всеобщее обозрение сырой неэффективный продукт, не привносящий ничего нового на рынок. Так что, Fleet не убийца VS Code, а убийца JetBrains.

Это прозвучит странно…

Но Microsoft знает толк в «импортозамещении»! Сейчас объясню, что это значит.

На языке программирования C# написана одна из самых популярных библиотек по работе с JSON - Newtonsoft.Json.

Я бы сказал, сверхпопулярная - почти 2.5 миллиарда скачиваний. Дошло до того, что платформа .net core (до версии 3.0) включала в себе различные адаптеры и коннекторы под этот инструмент. Под стороннюю библиотеку!

Так появился пакет System.Text.Json, который покрывает 100% потребностей ежедневных задач при работе с форматом. Так ещё и имеет нативную поддержку платформы и работает эффективнее, как по времени, так и по памяти.

Современная классика в новом прочтении 🤣
Обожаю такие приколы

https://youtu.be/uHt01D6rOLI

Остался разочарован программой DotNext 2022 Autumn…

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

Моё внимание особенно привлекли два доклада.

1. «Введение в Microsoft SignalR». Серьёзно? Введение? В 2022? Технологии почти 10 лет, на её основе сделали blazor, почему знакомиться надо только сейчас?

2. «MediatR не нужен». Совпадение, однако ранее я выпускал статью на точно такую же тему. Не удивлюсь, если её просто перескажут…

Замена MediatR здесь

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

У библиотеки много изъянов, но осталось не понятно, как лаконично решить эту проблему распределения.
Сквозь статью красной нитью прошла мысль - явное лучше неявного. Причём по многим параметрам, таким как, например:

▪️Когнитивная сложность кода

▪️Поддерживаемость

▪️Тестируемость

▪️Отлаживаемость

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

Сейчас идёт речь про контроллеры ASP NET Core, поскольку в основном применяется MediatR именно там. Решение было на поверхности - эксклюзивно делюсь им с вами.

FromServicesAttribute

И всё. Мы переходим на method injection, и сразу жизнь упрощается. Код такой же явный и декларативный, но гораздо короче.
В некоторых случаях можно даже не заводить интерфейсы, а регистрировать сразу concrete type.
Пример, как это выглядит:

[ApiController]
[Route("[controller]")]
public class SomeController
{
    [HttpGet("data")]
    public Task<GetSomeDataResponse> GetSomeData(
        [FromQuery] GetSomeDataRequest request,
        [FromServices] GetSomeDataRequestHandler handler,
        CancellationToken token) =>
        handler.HandleAsync(request, token);
}

Стоит ли выбрасывать исключение из конструктора?

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

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

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

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

Монолиты и микросервисы

Достаточно часто можно увидеть в чатах/комментариях по теме что-то вроде такого:

«А с микросервисами не все работают? Я вот на первой работе год работал и там был монолит. Но мне казалось, что микросервисы вот вообще у всех, кроме меня»

«С одним местом работы на монолите мало какие конторы будут звать на собес на вменяемые деньги»

Говорить о том какие плохие монолиты и какие хорошие микросервисы стало очень модно. Но, как обычно, правда где-то посередине.

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

Но иногда чем проще, тем лучше. Иногда, простой монолит - это хорошо.
Есть множество успешных примеров:
▪️StackOverflow
▪️Slack
▪️GitHub
и многие другие

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

Больше по вопросу можно почитать в этой классной статье Хабре

AutoMapper не нужен

Я провёл детальное расследование по этому вопросу.

Материалы дела уже на Хабре.

Попрошу вас прочитать и поставить плюс

#хабр

Под вышедшей статьёй очень понравился один комментарий. Настолько, что решил его опубликовать в канале. Орфография и пунктуация автора сохранены в оригинале:

«Я не могу понять одного, почему библиотека или ее автор решает за меня как ее использовать? Если есть инструмент для маппинга, то его домен это маппинг и основная задача - предоставить апи для решения задач маппинга. Вместо этого создатели автомаппера гнут свою линию, причем доходит до смешного: в одном ответе на стековерфлоу они советуют юзать какой-то новый метод, а уже в другом говорят что это плохая идея, а метод мы удалили навсегда. И эти парни не знают слов deprecated, obsolete и тп. Мы художники - мы так видим, а вы переписывайте как хотите ваши маппинги - напрасная трата человеко-часов. Мало того, они как бы дают вам возможность вернуть часть функционала, если очень надо, но код примеров еще надо найти в каком-то из обсуждений и самое главное - этот код бажный, какое-то издевательство. Этого достаточно, чтобы начать обходить эту либу стороной, неизвестно что они решат удалить или запретить завтра, а переписывать сотни мапингов нет никакого желания.

Сама идея неявного маппинга многократно доказала, что это гарантированный источник ошибок, который к тому же скрывает связи внутри приложения. Это означает, что все эти маппинги надо будет покрывать тестами, но зачем, если вполне можно сделать апи, которое максимально ограничит эти ошибки?»

async void это костыль .NET’а

Многие .NET разработчики знают, что с 5й версии C# в языке появились инструменты для реализации концепции асинхронного программирования.
Ключевые слова async/await, типы данных Task и Task<T>, библиотека TPL.

Однако, мало кто знает почему два слова, async void, можно написать друг за другом, а компилятор не отругается, в отличие от бородатого сеньора-помидора на код ревью.

Казалось бы, всё просто: если метод возвращает что-то типа T, то его асинхронный вариант вернёт Task<T>.
Если не возвращается ничего, то есть стоит void, то асинхронный вариант имеет тип Task.

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

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

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

Почему async void нельзя применять в реализации типовых задач асинхронного программирования?
У него совершенно другая семантика.

1️⃣ Исключения, выброшенные в такой среде не отлавливаются через catch. Они не оборачиваются в задачу, а вызываются прямо на контексте синхронизации. Отследить такое можно только с помощью глобальных «ловцов всего», что есть прямая дорога к неподдерживаемости.

2️⃣ Методы с такой сигнатурой нельзя компоновать с другими асинхронными вызовами через общий API. Цепочки задач, коллбеки при продолжении, общее ожидание - всё это недоступно.

3️⃣ Такой код сложно тестировать и поддерживать. Например, MS Test вовсе работает только с асинхронным кодом, возвращающим Task и Task<T>. Для каждого конкретного случая придётся писать свой собственный контекст синхронизации. Решение не простое и далеко не оптимальное.

Ну а больше деталей - на странице MSDN

Не знаю подводят ли другие блоггеры итоги года, но для меня 2022 однозначно был хорошим.

Я ротировался на senior должность, оказался в гостях у Антона Назарова, выпустил немало успешных статей на Хабре и, конечно, завёл этот замечательный канал!

Уверен, дальше - больше 🚀⚡️💪
Всех с наступающим🎄
Счастливого Нового Года 🥳

Год начинается с хороших новостей 😊

Как объяснить обывателю что такое программирование?

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

Всё это далеко от истины.
Начиная от бесполезности и до притворства в работе.

Давайте вспомним, кто такой инженер.
Инженер - это специалист, который создаёт или совершенствует технические механизмы.
То есть, он делает чертёж, изготавливает детали, продумывает как они будут взаимодействовать в едином механизме.

Мне кажется, аналогия очевидна. Программисты - инженеры XXI века.
Только механизмы и детали - цифровые.
Разрабатываемые системы нельзя потрогать, только представить в голове или выразить с помощью некоторой нотации.

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