C# *

Дали мне недавно задачу написать тесты для одной CLI-тулзы. Это мне уже привычно и понимание, зачем тулза нужна, есть. Я только не знал, что меня ждёт в коде. Программист, писавший её, сделал гигантскую работу — претензий нет (не обижайся, пожалуйста, если читаешь это, но это стоит отдельной статьи). Там суммарно, наверно, порядка 30к строк кода написано. Нюанс в том, что, видимо, он раньше не писал на C#,

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

Привет, Хабр. Я — Андрей Макар-Уваров, Head of Frontend в Surf. Недавно решил проверить одну гипотезу: насколько далеко можно уехать на ИИ в разработке, если взять задачу, в которой ты абсолютный ноль.

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

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

Эти антипаттерны не привязаны к языку программирования — они встречаются и в Java, и в Go, и в Python. Примеры покажу на C#/.NET, но суть та же для любого стека. Три конкретных случая из реальных проектов — и как их исправить.

Я хочу поделиться опытом создания универсального прокси-сервера на C#, который поддерживает не только HTTP/HTTPS, но и FTP-протокол с автоматической подстановкой учетных данных. Зачем это нужно? Представьте ситуацию: вам нужно работать с FTP-сервером через корпоративный прокси, но стандартные средства не поддерживают автоматическую аутентификацию. Или вы хотите иметь полный контроль над трафиком между клиентом и FTP-сервером. Мой прокси-сервер решает эти задачи.

Привет, уважаемые пользователи Хабра! Решил поделиться с вами историей своего пути в геймдев. Забегая вперед, скажу, что история еще не окончена и чем окончится никому не известно. Тем не менее, возможно она вдохновит тех, кто хочет изменить свою жизнь, но не решается это сделать, потому что считает, что в «40+ уже поздно» или опасается быть непонятым окружающими.

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

Всем привет! Меня зовут Григорий Дядиченко, и я разрабатываю разные проекты на заказ. Сталкивались ли вы с ситуацией, когда персонаж в вашей игре начинает немного дёргаться, если поиграть достаточно долго? Или пуля иногда пролетает сквозь тонкую стену, хотя коллайдер на месте? Если да — добро пожаловать в мир проблем float precision.

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

Если вам интересна эта тема — добро пожаловать под кат!

В мире высоконагруженных .NET-приложений каждая наносекунда на счету. Когда ваш код обрабатывает миллионы запросов, даже микрооптимизации могут дать ощутимый прирост производительности. Две ключевые фичи, появившиеся в .NET 8— SearchValues<T> и FrozenSet<T>/FrozenDictionary<TKey, TValue> — позволяют выжать максимум из «горячих путей» (hot paths) благодаря умной предварительной оптимизации.

Меня зовут Степан, я C# профессионал уже более 7 лет на рынке и рассказываю об этом в Telegram каналe StepOne. Иногда мне скучно на работе, потому что перекладывать JSON это слишком просто, даже если микросервисы.

Я отучился на системного программиста-компиляторщика и столкнулся с отсутствием спроса рынка на такие навыки. Но выбрал быть счастливым и написал язык программирования hydrascript, чтобы JSON гонялся даже в докере на макбуке. Решение под катом вас точно удивит!

Давно интересовал вопрос использования 16-битного АЦП STM32H7 для обработки I/Q сигналов в реальном времени.

Почти год ушел на эксперименты реализации SDR приемника на базе Tayloe mixer и MCU STM32H723ZGT6, и вот что у меня получилось: принимаемый КВ диапазон 1...30МГц, вывод обработанного аудио через внутренний 12-битный ЦАП или вывод I/Q потока на ПК через UAC1.

Всем привет! Я - новичок на Хабре, потому, набравшись смелости, хотел бы поделиться небольшим домашним проектом, над которым работаю последний год в свободное время.

Расскажу немного про Big Picture Manager и о том, как читать сырые данные с контроллера Xbox Series и какие маршруты я исследовал, чтобы в итоге записать в него данные.

Любой десктопный монолит имеет один фатальный изъян: если UI поток падает - умирает вся бизнес-логика. Я решил это применив бэкенд-подход на десктопе.

Задача была амбициозной: создать единый центр управления рабочим местом. Чтобы одной кнопкой (или по расписанию) переключать ПК и комнату между режимами “кодинг”, “игры”, “стрим”. Это значит: управлять умным домом (Home Assistant), блокировать отвлекающие процессы и сайты, запускать нужный софт, контролировать медиа (Spotify) - и всё это через плагины.

Это - четвертая и последняя (пока) статья цикла про ограничение скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей друг с другом) описание функции ограничения скорости обработки запросов в ASP.NET Core. В этой статье рассмотрено, как на базе универсального компонента ограничения скорости реализована функция ограничения скорости обработки запросов в ASP.NET Core.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

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

Это - третья статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте. В этой статье я собираюсь завершить описание универсального компонента ограничения в .NET: описать входящие в его состав базовые (неселективные) ограничители.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

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

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

На днях HR-отдел отклонил мое резюме на позицию джуна. Вместо фидбека я получил ответ «В нашей команде слишком много козерогов, и нашему тарологу не понравился ваш Сатурн». Сначала я хотел возмутиться, но потом подумал. Может звезды не врут? Возможно наш звездный язык программирования определяется в зависимости от расположения планет во время первого запуска IDE.

Я провел фундаментальное исследование, проанализировал натальные карты Гвидо ван Россума, Страуструпа и прочих, и составил первый в мире точный гороскоп языков программирования.

И результат меня поразил...

В этой статье мы заглянем под капот CLR (Common Language Runtime) и разберём как хранятся разные типы данных. Также поговорим о том, что такое стек и куча, и как они взаимодействуют. И в заключении рассмотрим, как происходит выделение памяти и разберем принципы работы сборщика мусора.

На рождественских каникулах я ехал на автобусах из одного штата в другой, и мне нужно было как-то убить 24 часа. Я читал об UTF-8 и узнал об этой кодировке нечто интересное: все традиционные символы ASCII сохранены в ней в их исходном однобайтовом представлении, поэтому их можно сканировать крайне быстро. Я решил поэкспериментировать с кодом, максимально быстро подсчитывающим такие символы, в результате получив готовый парсер CSV, который вполне сравним с предыдущими парсерами, а то и быстрее них.

В статье я расскажу о своём процессе работы, экспериментах и оптимизациях, которые привели меня к этому итогу.

Давайте представим, что вам нужно создать класс для хранения данных пользователя. Сколько строк кода вы напишете? Конструктор, свойства, метод ToString(), сравнение объектов... А если добавится новое поле? Придется обновлять конструктор, метод Equals, GetHashCode — утомительная работа, которая не добавляет бизнес-ценности вашему приложению.

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

Это - вторая статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

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

Рынок современных игровых движков постепенно расширяется, и всё больше студий выбирают не кого-то из двух гигантов (учитывая последние события, вообще одного), а движки поменьше. Сегодня поговорим про одного из новичков индустрии — S&Box. И это случай, когда новичок не такой простой, каким кажется. Подробнее о проекте и о том, какие ошибки мы смогли найти с помощью PVS-Studio, расскажем в статье.

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

Недавно мне довелось погрузиться в чтение кода функции ограничения скорости обработки входящих запросов к веб-приложению на ASP.NET Core. И в этом цикле статей я хочу поделиться найденным и понятым мной. Тем более, ещё в самом начале своих штудий я обнаружил, что эта тема на Хабре просто не рассматривалась никак - даже на уровне пересказа документации с сайта Microsoft (весьма скудной, кстати). А потому вот прямо сейчас я хочу заполнить этот пробел.