C# *

Привет, друзья! На связи снова Кирилл Пронин из PIX Robotics, и у меня для вас новая статья-сенсация!  
Мы сейчас открыли новый набор стажеров нашу команду разработки RPA, и коллеги попросили рассказать, как проходила стажировка по C# в прошлом году. А я что – я только за, потому что: а) благодаря прошлой стажировке мы заполучили двух талантливых джунов; б) для меня стажировка стала первым опытом в роли TeamLead’a; в) это было весёлое и необычное путешествие с неожиданными результатами (саму крутую цифру я уже вынес в заголовок, об остальных – ниже).

Для нашей команды это был первый опыт запуска стажировки, так что, как бы ни готовились, мы все равно не учли некоторые нюансы. Назвать их громко ОШИБКАМИ пальцы не поднимаются, а вот неожиданностями и нюансами – вполне. А так как для меня это все стало еще и первым опытом «тимлидства», то поделиться всем этим хочется вдвойне. Так что в этой статье расскажу, как организовать продуктивную стажировку, как отбирать лучших из лучших, какие ошибки нам удалось избежать и, конечно, о ключевых особенностях работы.

Я сделал простейшую утилиту для регистрации реализаций в контейнере.

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

Всем привет!

Меня зовут Яков, не сказал бы, что я супер разработчик игр (в общей сумме у меня 20 тыс игроков со всех игр выложенных на Яндекс.Игры), но хотел бы поделиться опытом создания гибкой архитектуры игр в Unity с использованием DI-контейнера Zenject.

В статье не будет основ работы с Zenject, поэтому я надеюсь что вы уже знаете данный фреймворк.

В этой статье Вы узнаете, как создать легковесную систему комбо-атаки для 2D и 3D проектов с использованием машины состояний в Unity. Статья включает примеры кода и ссылку на репозиторий с полным проектом, что делает её полезной как для новичков, так и для опытных разработчиков, стремящихся улучшить свои навыки в создании игровых систем.

Разбираемся с async/await без магии и скуки. Зачем вообще нужна асинхронность? Как устроена асинхронность в .NET внутри? Как работают await, Task, ValueTask, и многое другое?

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

Если интересен контекст моего баттхерта, то стоит посмотреть оригинальное видео, если же нет — можно перейти сразу сюда к моей реализации...

Личный взгляд программиста с стажем на то, как Microsoft переманил Хейлсберга, создал .NET и вытеснил Delphi с технологической сцены. История предательства, перехода эпох и чемодана, который до сих пор скрипит в углу.

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

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

Привет, Хабр!

Наверняка вы сталкивались с out, ref и in, но вот в чём штука — хотя выглядят они похоже, под капотом у них совершенно разные намерения. Один любит брать всё на себя, другой ждёт готового, третий — как библиотекарь: знает много, но не вмешивается. Сегодня разберёмся, когда и кого стоит звать в метод

Привет, Хабр! Когда речь заходит о сравнении объектов, все почему-то решают, что это элементарный вопрос: ну есть же == и есть .Equals(), в чём проблема? На практике — проблема порой вырастает в целое шапито. Сегодня поговорим о весьма противоречивой парочке. Почему иногда, написав var a = b; if (a == b) { ... }, мы проверяем одно, а вызвав a.Equals(b) — совершенно другое? И главное: как это может довольно жестоко подставить нас в реальном коде, когда «ой, ну мы же не ожидали, что кто‑то переопределит оператор == так хитро».

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

Статья подойдет тем, кто:

• Боится ошибаться и откладывает старт.
• Учится и не понимает зачем ему это.
• Учится, но хочет услышать про чужой путь и сделать свои выводы.

Вас не удивило, что проблема 1970-х — высокая сцепленность кода — дожила до 2010-го и способствовала изобретению микросервисов? Если так, то вы не удивитесь и узнав, что микросервисы тоже её не решили. Сегодня индустрия относится к ним скептически. За последние десять лет мы поняли, что они не стали панацеей. Архитекторы в мире IT — это не учёные, и даже не художники. Это шаманы. Удачно разбить систему на несцепленные части было сложно в 1970-е, сложно и сейчас.

При этом микросервисы привносят проблемы, которых не было в монолитных приложениях.

Первая часть

Вторая часть

Недавно я работал над небольшим собственным проектом, представляющим собой Roslyn-генератор интерфейсов только для чтения для существующих классов. Когда я посчитал, что пришло время выкладывать результаты в виде NuGet-пакета, я решил, что нужно создать автоматизированный конвейер сборки. В прошлом я уже решал такую задачу с помощью AppVeyor. Но на этот раз имелись некоторые отличия. Во-первых, в прошлом я использовал Cake для описания задач сборки. На этот раз я решил попробовать Nuke. Последний обещает лучшую интеграцию с Visual Studio. Кроме того, я решил попробовать русский аналог GitHub — GitVerse. Что из этого получилось, читайте ниже.

Много лет мы обсуждали, как разбить монолит на микросервисы. Микросервисная архитектура стала стандартом для создания сложных систем. Однако что делать, если растущее число сервисов начинает тормозить разработку, усложнять сопровождение и порождать избыточность? Забавно, что спустя столько времени я пишу статью о том, как вернуться к монолиту. Это история о том, как микросервисная архитектура сыграла с нами злую шутку, а монолит оказался спасением. Данный подход, хотя и кажется шагом назад, открыл нам возможность упростить код, снизить эксплуатационные затраты и навести порядок в хаосе микросервисов. В этой статье я поделюсь тем, как я переосмыслила процессы и нашла баланс между гибкостью микросервисов и преимуществами модульного подхода.

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

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

Первая часть.

В любой сфере деятельности есть знаковые фигуры. Признанные эксперты. Лидеры мнений. Программирование не является исключением. Всем нам знакомы имена Кернигана, Кнута, Торвальдса, Скита. Не последним в этом ряду будет и имя Мартина Фаулера. Он написал книгу «Рефакторинг», которую обязан прочитать любой профессиональный программист. Он предложил термин Dependency Injection. Он участвовал в подготовке каталога действительно полезных паттернов проектирования. Он был одним из авторов Манифеста Гибкой Разработки Программ.

В 2014-м вместе с Джеймсом Льюисом Фаулер написал статью о микросервисах, которая начинается словами: «Термин „микросервисная архитектура‟ уже несколько лет применяется, чтобы описать способ проектирования программ»… Очевидно, теме микросервисов без малого десять лет. Можно ли добавить что-нибудь к тому, что уже было сказано и написано за это время?

Оказывается, можно.

Привет, Хабр!

Сегодня я хочу рассказать о создании простого, но полезного пет-проекта — Telegram-бота, который помогает пользователям улучшать их английский с помощью GPT-4. Проект отлично подойдет для начинающих разработчиков, так как использует современный стек технологий и имеет понятную архитектуру.