Вот пример из моего Notion - обратите внимание на даты: работа велась долго и тщательно.
И именно поэтому так сложно принять ситуацию, когда серьёзный труд встречают не просто равнодушием, даже негативом.
И это не единый источник, так же вносил часть информации в .txt файлы
Я увидел дизлайк за “сгенерировано ИИ”. Ну ладно, допустим(просто представим человек так подумал), но карму понижать, чтоб я вообще ничего не мог делать здесь…
Публикации с откровенной ерундой набирают популярность, собирают лайки и внимание. А я сижу с материалом, над которым работал месяцами, и не могу поверить, что результат встречают не просто холодно, а негативом.
Вы понимаете, какой это материал: чтобы его написать, я действительно потратил месяц или два работы. Интервью смотрел создателя БД. На хабре нет подобной статьи.
Я изучил биографию создателя базы данных, указал источники, сделал всё, чтобы текст был максимально объективным.
Я прочитал его книгу, статьи, документацию - и вы просто не представляете, сколько сил вложено в этот процесс. Это не поверхностный пересказ, а глубокая работа, требующая времени, внимания и концентрации.
И именно поэтому так демотивирует, когда результат встречают негативом.
Сейчас у меня не так много времени, но, дорогие читатели, я продолжу расширять и дополнять материалы о RavenDB настолько, насколько смогу.
Как я писал в начале статьи, над этим проектом я работаю в одиночку - и это действительно непросто. Но эта работа нужна: иначе такая мощная и продуманная база данных ещё долго оставалась бы в тени.
RavenDB заслуживает внимания, изучения и практического применения, и я постараюсь внести свой вклад в то, чтобы она получила заслуженное место в профессиональном сообществе.
Когда работа над статьёй будет завершена? Тогда, когда вступление перестанет содержать фразу о «живом документе» и превратится в полноценное, завершённое введение.
Пока же статья развивается, дополняется и остаётся открытой для новых материалов.
Если уж мерить по критерию «кого размазал Афир», то под этот критерий попадает половина индустрии. Он размазал множество систем - от Cassandra и MongoDB до Etcd, CockroachDB и Redis.
Афир это крутой инженер, для которого подобные разборы = профессиональная деятельность. Его задача как раз в том, чтобы находить слабые места даже в зрелых и популярных системах.
Технически любая СУБД сталкивалась или будет сталкиваться с проблемами - это нормальная часть эволюции сложных систем.
Если вы читали книгу Орена Эйни - libgavran, то знаете, что он подробно разбирает реальные кейсы.
Например, как ALICE выявила серьёзные проблемы в PostgreSQL - и это не делает PostgreSQL «плохой», это делает её активно используемой и тщательно анализируемой.
Когда подобных случаев нет, это обычно означает следующее:
Базу никто не использует
Базу никто не анализирует
База не представляет интереса
Именно активное использование, критика и разбор инцидентов показывают, что продукт живой, востребованный и развивается.
Это реальная история касаемо того самого Senior. Не знают как их создать самому в ЯП, самый элементарный пример. Порой интересные кадры встречаются, а так задачи выполняют и работают хорошо. На них жалоб нет, но это забавно со стороны.
Официальная информация, интервью посмотрите с создателем БД, прочитайте документацию прежде писать комментарий.
Беттинг спокойно функционирует и найм происходит через HeadHunter. ЕСТЬ мелкие и крупные компании. В тот же известный всем 1xbet и прочие спокойно устраиваются и работают удаленно.
Вообще без понятия про RiakDb. Никогда о ней не слышал и мои друзья что работают в беттинге тоже, у них MongoDb
Хочется делать упор именно на такие материалы - с разбором того, что происходит “под капотом”. Базовые вещи сегодня легко найти в документации, существующих статьях или с помощью нейросетей, а вот глубокие технические разборы встречаются гораздо реже.
Сейчас как раз готовлю новый материал. Тема непростая, поэтому на подготовку потребуется время…
Слышал про одну компанию: на позицию Senior/Middle разработчика спрашивают различия между Clean Architecture и Onion Architecture. Самое забавное, что у них самих используется Sliced Architecture.
При этом никто не собирается переписывать существующие проекты на новую архитектуру - это огромные затраты для бизнеса. Как система была построена изначально, так она обычно и развивается дальше.
Но вместо обсуждения реальных инженерных решений кандидату предлагают «высушить мозг» вопросами, которыми чаще занимается архитектор.
На практике во многих компаниях есть готовые шаблоны проектов с уже подготовленными решениями: Dockerfile, CI/CD, werf, базовая структура проекта и архитектурные заготовки. Если нужно выделить новый микросервис, обычно берут такой template за основу и адаптируют под задачу. Никто не садится каждый раз с нуля придумывать новую архитектуру.
Ещё интереснее, когда спрашивают про Kafka, хотя в самой компании Kafka вообще не используется. Никто там с ней не работал, как узнается позже, но кандидата проверяют на знание деталей.
Ну, я бы все-таки сказал, что готовиться нужно. Иначе вообще все печально может выглядеть.
Но в целом я с вами согласен.
После долгого перерыва без собеседований я пришел на интервью, прекрасно понимал, как решать задачу, мог объяснить алгоритм словами, но написать ни одной строчки кода не смог. Просто ступор. Дыхание перехватило, из-за того что на тебя смотрят и оценивают, мысли моментально разлетелись. До сих пор не понимаю, как это работает.
При этом мои знания вполне можно оценить объективно - по отзывам коллег, по опыту и по тем материалам, которые я публикую. Например, у меня есть статья, где я подробно разбирал архитектуру MassTransit и рассказывал о реализации Sagas.
Еще одна моя ошибка была в том, что я слишком сильно воспринимал обратную связь от интервьюеров. Но чем больше общался с разными людьми, в том числе гораздо более сильными и авторитетными специалистами, тем больше понимал, что мнение какого-то руководителя из неизвестной мне компании - это далеко не истина в последней инстанции.
К тому же я встречал интервьюеров, которые сами были напряжены или явно не в настроении. Там просто надо уходить. Если человек сам постоянно находится в негативе, это его выбор. Главное - не перенимать это состояние на себя. Очень многие проблемы начинаются именно из-за нервов. Если он хочет тратить на это свое здоровье - это его дело.
И, кстати, я далеко не один такой. У друзей из других компаний были абсолютно такие же истории.
У меня так же есть друзья, которые работают уже с 15 лет проггерами. Есть накрутчики так же в отдельности. Однако они хорошие специалисты и решают задачи на высоте. Руководители ими довольны.
Порой жизнь вносит свои коррективы, и поиск работы становится вопросом выживания.
Поэтому сложно однозначно осуждать человека, который списывает. При этом так поступают не только начинающие специалисты, но и люди с большим опытом, для которых это лишь способ повысить свои шансы.
В то же время можно понять и руководителя. Он стремится собрать надежную команду и минимизировать риск неудачного найма.
У каждой стороны свои мотивы, а значит - и свой стресс.
Эта статья написана для того, чтобы помочь взглянуть на процесс собеседований спокойнее и снизить уровень этого стресса как у кандидатов, так и у нанимающих.
Это выражение применимо не только к собеседованиям, а практически к любой сделке или ситуации, которая не состоялась.
Отказы могут идти один за другим, и это само по себе не является показателем уровня знаний. Конечно, бывают случаи, когда кандидат объективно не справился с каким-то вопросом или задачей - такое тоже случается, и в этом нет ничего необычного.
В некоторых компаниях процесс выглядит максимально формально: кандидатов заносят в Excel таблицу, выставляют баллы по разным критериям, а затем принимают решение на основе итоговой оценки.
Мало баллов - значит кандидат не проходит дальше. Насколько такой подход эффективен - каждый может оценивать по-своему.
У интервьюеров может быть множество тараканов в голове. Сегодня одни, завтра другие и все этому подвержены.
Главная мысль в другом: к отказам стоит относиться спокойнее.
Эта статья написана для того, чтобы показать начинающим и даже опытным специалистам: попытка полностью контролировать процесс собеседования бессмысленна.
Слишком много факторов находится за пределами влияния человека которого собеседуют…
Достаточно один раз столкнуться с кандидатом, который успешно списывал на собеседовании, не справился с работой и отношение интервьюера может измениться.
После такого опыта он начинает видеть потенциального списывателя практически в каждом новом кандидате. Возникает излишняя подозрительность, а иногда - даже автоматические отказы тем, кто кажется «слишком подготовленным» или отвечает слишком уверенно.
Со временем это обычно проходит, но до тех пор под удар могут попасть и абсолютно честные специалисты.
Поэтому странно видеть обесценивание чужих трудов. Человек просто взял и перевел полезный материал - с инициативой и интересом к теме(раскрасил даже более красиво диаграмму, чем у ориг.автора). Не высказал своего мнения, просто перевел статью.
Не каждая статья обязана быть полезной senior и middle разработчикам и то даже в работе младших разработчиком можно найти полезности(обычно Senior/Middle специалисты в этом не признаются, ЭГО слишком велико).
Судя по реакции и закладкам, материал нашёл свою аудиторию. Дарья - junior-разработчик, который пытается разбираться в теме и делиться знаниями. Такой энтузиазм обычно хочется поддерживать, а не отбивать токсичными комментариями.
Я в первую очередь обратил внимание на ваш профиль - вы написали, что являетесь младшим специалистом в backend-разработке. Поэтому на будущее хочу сказать следующее.
Токсичность
На токсичность некоторых ребят просто не обращайте внимания - это ещё вполне адекватная публика(с долькой иронии и юмора, что вполне даже здорово). В IT-сообществе, к сожалению, хватает токсичных людей.
Люди часто ждут от статьи чего-то «взрывного» и необычного, не задумываясь о том, что за любым материалом стоят чей-то опыт, время и труд. Для кого-то описанные вещи могут быть очевидными, а для кого-то - действительно полезными и новыми.
При этом каждая опубликованная статья - это ещё и определённая конкуренция на рынке за те же вакансии. Человек делится своими знаниями, хотя мог бы оставить их при себе.
Ирония в том, что такой труд далеко не всегда бывает благодарным: работодателям порой всё равно, сколько сил ты вложил в статьи, open source или обучение других людей.
К тому же многие вообще не зарегистрированы на Хабре - они просто читают материалы без лайков, комментариев и какой-либо обратной связи. Поэтому по реакции под статьёй не всегда можно объективно судить о её реальной пользе.
Опыт близкого окружения
У меня есть друг - Senior-разработчик, сильный специалист. После одной статьи ему столько негатива и «помидоров» накидали, что, как он сам говорил, желание публиковаться на Хабре пропало совсем.
Хотя он парень действительно умный: работал в одном из крупнейших банков России.
Выбор библиотеки - это почти всегда зона ответственности сильных специалистов: техлида, иногда архитектора и других ключевых участников команды. Обычно они собираются, обсуждают варианты, взвешивают плюсы и минусы и принимают решение.
Созвоны, как известно, бывают разные: есть формата «ППР» - пришли, поговорили, разошлись, а есть действительно содержательные встречи, где решаются важные технические вопросы.
Не буду говорить о конкретном банке - это NDA, и подставлять людей не хочется. Скажу лишь так: в одном из крупнейших банков России(я уверен во множестве так), в одном из подразделений, используется MassTransit
1) не правильно вставили ссылку на sharplab(нажмите CreateGist там)* Вы же делаете статью для других, а красота в мелочах
2) Я кстати тоже разбирал state machine, ток опорой в ней была библиотека MassTransit и SagaStateMachine сравнивал с AsyncStateMachine - https://habr.com/ru/articles/1033712/#mt14 Рекомендую посмотреть.
3) И не используйте длинные "-" т.е "—" т.к это слишком сильно любит ИИ(в том числе он любит фантомить). Утверждать, что это ИИ не стану т.к в оригинальной статье данные тире есть, но это сразу бросаетсяв глаза.
В любом случае лайк уж поставлю за отсылку к оригинальной статье и за распространение в РУ сегменте(я об этой статье незнал даже, ведь как то из уст в уста информация бегает) - вполне себе полезно(как ссылка на другие источники), удачи вам!
Хочу поблагодарить всех, кто следил за статьёй, а также новых читателей. Сообщаю, что больше не планирую её поддерживать: основные и наиболее интересные(даже сверх этого, ведь подобного материала сам не встречал), на мой взгляд, темы уже разобраны.
Материал потребовал большой работы, поэтому буду благодарен за поддержку - будь то продвижение статьи, подписка или комментарий.
Как применять эту информацию дальше - остаётся на ваше усмотрение. Если остались вопросы, задавайте их в комментариях. Всем удачи!
Вот здесь все описано
Я вас понимаю, но тяжело оставаться равнодушным.
Вот пример из моего Notion - обратите внимание на даты: работа велась долго и тщательно.
И именно поэтому так сложно принять ситуацию, когда серьёзный труд встречают не просто равнодушием, даже негативом.
И это не единый источник, так же вносил часть информации в .txt файлы
Я увидел дизлайк за “сгенерировано ИИ”. Ну ладно, допустим(просто представим человек так подумал), но карму понижать, чтоб я вообще ничего не мог делать здесь…
Я всё больше прихожу к выводу, что делиться материалами не имеет смысла, как сделал мой друг однажды.
Гораздо спокойнее изучать тему для себя: углубляться, разбираться, накапливать знания - и максимум делиться ими только с друзьями.
Такой принцип, похоже, работает везде: меньше разочарований, больше пользы для себя и близкого круга.
Не делаешь добра - и не получаешь зла.
Ситуация сейчас такая: я просто в шоке.
Публикации с откровенной ерундой набирают популярность, собирают лайки и внимание. А я сижу с материалом, над которым работал месяцами, и не могу поверить, что результат встречают не просто холодно, а негативом.
Вы понимаете, какой это материал: чтобы его написать, я действительно потратил месяц или два работы. Интервью смотрел создателя БД. На хабре нет подобной статьи.
Я изучил биографию создателя базы данных, указал источники, сделал всё, чтобы текст был максимально объективным.
Я прочитал его книгу, статьи, документацию - и вы просто не представляете, сколько сил вложено в этот процесс. Это не поверхностный пересказ, а глубокая работа, требующая времени, внимания и концентрации.
И именно поэтому так демотивирует, когда результат встречают негативом.
Сейчас у меня не так много времени, но, дорогие читатели, я продолжу расширять и дополнять материалы о RavenDB настолько, насколько смогу.
Как я писал в начале статьи, над этим проектом я работаю в одиночку - и это действительно непросто. Но эта работа нужна: иначе такая мощная и продуманная база данных ещё долго оставалась бы в тени.
RavenDB заслуживает внимания, изучения и практического применения, и я постараюсь внести свой вклад в то, чтобы она получила заслуженное место в профессиональном сообществе.
Когда работа над статьёй будет завершена? Тогда, когда вступление перестанет содержать фразу о «живом документе» и превратится в полноценное, завершённое введение.
Пока же статья развивается, дополняется и остаётся открытой для новых материалов.
Если уж мерить по критерию «кого размазал Афир», то под этот критерий попадает половина индустрии. Он размазал множество систем - от Cassandra и MongoDB до Etcd, CockroachDB и Redis.
Афир это крутой инженер, для которого подобные разборы = профессиональная деятельность. Его задача как раз в том, чтобы находить слабые места даже в зрелых и популярных системах.
Технически любая СУБД сталкивалась или будет сталкиваться с проблемами - это нормальная часть эволюции сложных систем.
Если вы читали книгу Орена Эйни - libgavran, то знаете, что он подробно разбирает реальные кейсы.
Например, как ALICE выявила серьёзные проблемы в PostgreSQL - и это не делает PostgreSQL «плохой», это делает её активно используемой и тщательно анализируемой.
Когда подобных случаев нет, это обычно означает следующее:
Базу никто не использует
Базу никто не анализирует
База не представляет интереса
Именно активное использование, критика и разбор инцидентов показывают, что продукт живой, востребованный и развивается.
Допустим в 1xbet, как пример, нанимают не напрямую, а через Аутстафф(компания прокладка). Там вы можете проживать где угодно и спокойно работать.
Это реальная история касаемо того самого Senior. Не знают как их создать самому в ЯП, самый элементарный пример. Порой интересные кадры встречаются, а так задачи выполняют и работают хорошо. На них жалоб нет, но это забавно со стороны.
Официальная информация, интервью посмотрите с создателем БД, прочитайте документацию прежде писать комментарий.
Беттинг спокойно функционирует и найм происходит через HeadHunter. ЕСТЬ мелкие и крупные компании. В тот же известный всем 1xbet и прочие спокойно устраиваются и работают удаленно.
Вообще без понятия про RiakDb. Никогда о ней не слышал и мои друзья что работают в беттинге тоже, у них MongoDb
Спасибо за фидбек :)
Хочется делать упор именно на такие материалы - с разбором того, что происходит “под капотом”. Базовые вещи сегодня легко найти в документации, существующих статьях или с помощью нейросетей, а вот глубокие технические разборы встречаются гораздо реже.
Сейчас как раз готовлю новый материал. Тема непростая, поэтому на подготовку потребуется время…
Слышал про одну компанию: на позицию Senior/Middle разработчика спрашивают различия между Clean Architecture и Onion Architecture. Самое забавное, что у них самих используется Sliced Architecture.
При этом никто не собирается переписывать существующие проекты на новую архитектуру - это огромные затраты для бизнеса. Как система была построена изначально, так она обычно и развивается дальше.
Но вместо обсуждения реальных инженерных решений кандидату предлагают «высушить мозг» вопросами, которыми чаще занимается архитектор.
На практике во многих компаниях есть готовые шаблоны проектов с уже подготовленными решениями: Dockerfile, CI/CD, werf, базовая структура проекта и архитектурные заготовки. Если нужно выделить новый микросервис, обычно берут такой template за основу и адаптируют под задачу. Никто не садится каждый раз с нуля придумывать новую архитектуру.
Ещё интереснее, когда спрашивают про Kafka, хотя в самой компании Kafka вообще не используется. Никто там с ней не работал, как узнается позже, но кандидата проверяют на знание деталей.
Ну, я бы все-таки сказал, что готовиться нужно. Иначе вообще все печально может выглядеть.
Но в целом я с вами согласен.
После долгого перерыва без собеседований я пришел на интервью, прекрасно понимал, как решать задачу, мог объяснить алгоритм словами, но написать ни одной строчки кода не смог. Просто ступор. Дыхание перехватило, из-за того что на тебя смотрят и оценивают, мысли моментально разлетелись. До сих пор не понимаю, как это работает.
При этом мои знания вполне можно оценить объективно - по отзывам коллег, по опыту и по тем материалам, которые я публикую. Например, у меня есть статья, где я подробно разбирал архитектуру MassTransit и рассказывал о реализации Sagas.
Еще одна моя ошибка была в том, что я слишком сильно воспринимал обратную связь от интервьюеров. Но чем больше общался с разными людьми, в том числе гораздо более сильными и авторитетными специалистами, тем больше понимал, что мнение какого-то руководителя из неизвестной мне компании - это далеко не истина в последней инстанции.
К тому же я встречал интервьюеров, которые сами были напряжены или явно не в настроении. Там просто надо уходить. Если человек сам постоянно находится в негативе, это его выбор. Главное - не перенимать это состояние на себя. Очень многие проблемы начинаются именно из-за нервов. Если он хочет тратить на это свое здоровье - это его дело.
И, кстати, я далеко не один такой. У друзей из других компаний были абсолютно такие же истории.
У меня так же есть друзья, которые работают уже с 15 лет проггерами. Есть накрутчики так же в отдельности. Однако они хорошие специалисты и решают задачи на высоте. Руководители ими довольны.
Порой жизнь вносит свои коррективы, и поиск работы становится вопросом выживания.
Поэтому сложно однозначно осуждать человека, который списывает. При этом так поступают не только начинающие специалисты, но и люди с большим опытом, для которых это лишь способ повысить свои шансы.
В то же время можно понять и руководителя. Он стремится собрать надежную команду и минимизировать риск неудачного найма.
У каждой стороны свои мотивы, а значит - и свой стресс.
Эта статья написана для того, чтобы помочь взглянуть на процесс собеседований спокойнее и снизить уровень этого стресса как у кандидатов, так и у нанимающих.
Это выражение применимо не только к собеседованиям, а практически к любой сделке или ситуации, которая не состоялась.
Отказы могут идти один за другим, и это само по себе не является показателем уровня знаний. Конечно, бывают случаи, когда кандидат объективно не справился с каким-то вопросом или задачей - такое тоже случается, и в этом нет ничего необычного.
В некоторых компаниях процесс выглядит максимально формально: кандидатов заносят в Excel таблицу, выставляют баллы по разным критериям, а затем принимают решение на основе итоговой оценки.
Мало баллов - значит кандидат не проходит дальше. Насколько такой подход эффективен - каждый может оценивать по-своему.
У интервьюеров может быть множество тараканов в голове. Сегодня одни, завтра другие и все этому подвержены.
Главная мысль в другом: к отказам стоит относиться спокойнее.
Эта статья написана для того, чтобы показать начинающим и даже опытным специалистам: попытка полностью контролировать процесс собеседования бессмысленна.
Слишком много факторов находится за пределами влияния человека которого собеседуют…
Достаточно один раз столкнуться с кандидатом, который успешно списывал на собеседовании, не справился с работой и отношение интервьюера может измениться.
После такого опыта он начинает видеть потенциального списывателя практически в каждом новом кандидате. Возникает излишняя подозрительность, а иногда - даже автоматические отказы тем, кто кажется «слишком подготовленным» или отвечает слишком уверенно.
Со временем это обычно проходит, но до тех пор под удар могут попасть и абсолютно честные специалисты.
Алексей, давайте по справедливости, проверьте в Google или в Яндексе по запросу:
site:habr.com "Ranjeet Singh"или даже по уникальному фрагменту кода:
site:habr.com "awaiter = 5__1.GetStringAsync("https://msdn.microsoft.com\").GetAwaiter();"Если так последнее вбить нигде нет упоминания medium сайта.
site:habr.com "https://medium.com/@ranjeetdotme/how-async-await-works-in-c-eccf16bd3b90"Я специально проверял.
Поэтому странно видеть обесценивание чужих трудов. Человек просто взял и перевел полезный материал - с инициативой и интересом к теме(раскрасил даже более красиво диаграмму, чем у ориг.автора). Не высказал своего мнения, просто перевел статью.
Не каждая статья обязана быть полезной senior и middle разработчикам и то даже в работе младших разработчиком можно найти полезности(обычно Senior/Middle специалисты в этом не признаются, ЭГО слишком велико).
Судя по реакции и закладкам, материал нашёл свою аудиторию. Дарья - junior-разработчик, который пытается разбираться в теме и делиться знаниями. Такой энтузиазм обычно хочется поддерживать, а не отбивать токсичными комментариями.
Вообщем я вас не поддерживаю в данном вопросе.
Вводная часть
Я в первую очередь обратил внимание на ваш профиль - вы написали, что являетесь младшим специалистом в backend-разработке. Поэтому на будущее хочу сказать следующее.
Токсичность
На токсичность некоторых ребят просто не обращайте внимания - это ещё вполне адекватная публика(с долькой иронии и юмора, что вполне даже здорово). В IT-сообществе, к сожалению, хватает токсичных людей.
Люди часто ждут от статьи чего-то «взрывного» и необычного, не задумываясь о том, что за любым материалом стоят чей-то опыт, время и труд. Для кого-то описанные вещи могут быть очевидными, а для кого-то - действительно полезными и новыми.
При этом каждая опубликованная статья - это ещё и определённая конкуренция на рынке за те же вакансии. Человек делится своими знаниями, хотя мог бы оставить их при себе.
Ирония в том, что такой труд далеко не всегда бывает благодарным: работодателям порой всё равно, сколько сил ты вложил в статьи, open source или обучение других людей.
К тому же многие вообще не зарегистрированы на Хабре - они просто читают материалы без лайков, комментариев и какой-либо обратной связи. Поэтому по реакции под статьёй не всегда можно объективно судить о её реальной пользе.
Опыт близкого окружения
У меня есть друг - Senior-разработчик, сильный специалист. После одной статьи ему столько негатива и «помидоров» накидали, что, как он сам говорил, желание публиковаться на Хабре пропало совсем.
Хотя он парень действительно умный: работал в одном из крупнейших банков России.
Тут уж каждому своё.
Выбор библиотеки - это почти всегда зона ответственности сильных специалистов: техлида, иногда архитектора и других ключевых участников команды. Обычно они собираются, обсуждают варианты, взвешивают плюсы и минусы и принимают решение.
Созвоны, как известно, бывают разные: есть формата «ППР» - пришли, поговорили, разошлись, а есть действительно содержательные встречи, где решаются важные технические вопросы.
Не буду говорить о конкретном банке - это NDA, и подставлять людей не хочется. Скажу лишь так: в одном из крупнейших банков России(я уверен во множестве так), в одном из подразделений, используется MassTransit
Дарья, я понимаю, что вы перевели статью, но:
1) не правильно вставили ссылку на sharplab(нажмите CreateGist там)*
Вы же делаете статью для других, а красота в мелочах
2) Я кстати тоже разбирал state machine, ток опорой в ней была библиотека MassTransit и SagaStateMachine сравнивал с AsyncStateMachine - https://habr.com/ru/articles/1033712/#mt14
Рекомендую посмотреть.
3) И не используйте длинные "-" т.е "—" т.к это слишком сильно любит ИИ(в том числе он любит фантомить). Утверждать, что это ИИ не стану т.к в оригинальной статье данные тире есть, но это сразу бросаетсяв глаза.
В любом случае лайк уж поставлю за отсылку к оригинальной статье и за распространение в РУ сегменте(я об этой статье незнал даже, ведь как то из уст в уста информация бегает) - вполне себе полезно(как ссылка на другие источники), удачи вам!
Хочу поблагодарить всех, кто следил за статьёй, а также новых читателей. Сообщаю, что больше не планирую её поддерживать: основные и наиболее интересные(даже сверх этого, ведь подобного материала сам не встречал), на мой взгляд, темы уже разобраны.
Материал потребовал большой работы, поэтому буду благодарен за поддержку - будь то продвижение статьи, подписка или комментарий.
Как применять эту информацию дальше - остаётся на ваше усмотрение. Если остались вопросы, задавайте их в комментариях. Всем удачи!