Введение

Telegram — один из самых популярных мессенджеров в мире, предлагающий такие функции, как групповые чаты, каналы, голосовые и видеозвонки, а также возможность создания ботов. В данной статье мы не будем ставить цель показать, как создать с нуля приложение a-la "Hello, World!", а изучим более сложный пример готовой реализации бота на платформе .NET с использованием современных технологий и практик разработки, локализацией, поддержкой пожертвований в Telegram Stars и т.д.

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

Так однажды произошло и в процессе установки нашего продукта. Мы столкнулись с тем, что привычные действия приводят к совершенно непривычному результату. Об этом мы и решили рассказать. В этой статье мы разберём проблему с закрытием файловых дескрипторов при выполнении команды на создание пула в Ceph. Расскажем, как мы её обнаружили, что делали, чтобы определить причину её возникновения, и самое важное — почему это произошло и как решить проблему. Получился настоящий детектив.

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

Сегодня поговорим о том, как правильно настраивать автовакуумирование в PostgreSQL — одном из механизмов, который позволяет базе данных оставаться "в форме" и поддерживать производительность на должном уровне. Если неправильно подойти к настройке, можно столкнуться с деградацией скорости обработки запросов и внезапным ростом объема данных.

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

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

Всем привет!

Данная статья содержит информация о том, как написать телеграм бота на C# с использованием Yandex Cloud Functions и Телеграм Webhook. Также в данной статье будет рассмотрено CI/CD с помощью GitHub Actions.

P.S. полезная литература находится в ссылках!

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

Reactive Extensions, известные также как Rx.NET, представляют собой библиотеку для .NET, предназначенную для композиции асинхронных и событийно-ориентированных программ с помощью наблюдаемых последовательностей и операторов запросов в стиле LINQ.

Основная фича Rx заключается в управлении асинхронными данными так, как если бы они были синхронными коллекциями.

В этой статье мы рассмотрми, как работать с Rx в C#.

С некоторых пор я предпочитаю использовать фейки вместо стабов и моков, поскольку использование фейковых объектов вместо других тестовых дублёров делает тестовые наборы более надёжными. Я написал кодовую базу для своей книги Code That Fits in Your Head полностью с использованием фейков и тестового шпиона, и мне редко приходилось исправлять неработающие тесты. Никаких Moq, FakeItEasy, NSubstitute или Rhino Mocks, только написанные вручную тестовые дублёры.

Недавно я понял, что проблема с моками и стабами заключается в том, что они нарушают инкапсуляцию.

Сегодня поговорим о неочевидной особенности некоторых коллекций в .NET. Долго вокруг да около ходить не будем и начнём с задачки на самопроверку.

Привет, Хабр! Меня зовут Давид, я C#-разработчик в SimbirSoft. В современном программировании эффективное управление ресурсами и контроль за выполнением задач становятся ключевыми аспектами для создания надежных и масштабируемых приложений. В C# одним из важнейших инструментов в для достижения этих целей является механизм Cancellation Token. Эта концепция позволяет разработчикам изящно и безопасно управлять долгосрочными или ресурсоемкими операциями, обеспечивая возможность их отмены по требованию.

В этой статье мы погрузимся в мир Cancellation Token в C#, исследуя его роль, принципы работы и практическое применение. Мы обсудим, как эта технология позволяет разработчикам улучшить производительность и надежность их приложений, а также — как избежать распространенных ошибок при работе с асинхронными операциями. Подробно рассмотрим примеры кода, демонстрирующие использование Cancellation Token в различных сценариях, что сделает наше обсуждение не только теоретически насыщенным, но и довольно практичным для программистов любого уровня.

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

Когда я первый раз услышал про .NET Aspire, я подумал что это какая-то очередная лажа от Майкрософта, про которую все забудут через неделю.

Особенно, учитывая какую дичь часто завозят в шарп (например те же ужасно спроектированные Primary Constructor'ы про которые я писал, или вот прикол-пропозал от самого Тоуба). Так что ожидания у меня, честно говоря, были ниже нуля.

Но попробовав его лично, я был, честно говоря, шокирован. Трепещите, жависты!! Трепещите гошники! Трещепищите питонисты - такого вы еще точно не видели.

Я даже представить не мог, что DevEx можно сделать настолько офигительным.

В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.

Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.

Эта история началась с того, что и мы с проблемами масштабирования столкнулись. Под хабракатом вы узнаете, как мы прошли через отрицание проблемы, гнев на Ceph, торг с CTO и разработку собственного решения. Как выбирали технологии, на какие грабли наступили, и что в итоге получилось.

В современном мире телеграм-боты стали неотъемлемой частью нашей повседневной жизни. Они стали незаменимыми в самых разнообразных задачах – от автоматизации повседневных операций до обеспечения клиентов высококачественным сервисом.

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

Не страшно! В этой статье я поделюсь с вами всеми этапами создания собственного фреймворка для телеграм-бота с использованием C#.

Приветствую, товарищи-программисты!

Материалы по разработке Telegram ботов на C# начинают потихоньку устаревать, новой информации я не нашел, поэтому решил написать свою статью.

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

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

Мы возьмём сугубо игровую задачу с понятным результатом и на её примере узнаем:

• на какие ноды AST стоит обратить внимание в первую очередь;
• где Fantomas-у нельзя доверять;
• где можно хакать;
• где лучше придерживаться пуризма;
• и как на F# можно строить Fluent API.

В этой части мы сосредоточимся на общей организации генератора, входных данных и основных элементах AST. В следующей сделаем то же самое, но на более сложном уровне, сместив повествование в сторону устройства Fluent API.

Привет, Хабр! С вами снова AliExpress Order Management System. Сегодня поговорим о том, как мы увеличивали количество шардов без длительного даунтайма. Спойлер: в конце - самое интересное ;)

Итак, функции активации. Что мы знаем о них помимо загадочной тайны ужасных соглашений о наименованиях (о чем поговорим позже 🧐) и зачем они нам нужны (если вас это вообще интересно)?

Идея, собственно, настолько проста, что даже ваш кот может разобраться в этом. Прежде всего, что-то похожее есть в наших головах. Для этого давайте взглянем на упрощенный нейрон (органический и искусственный):

Это перевод первой главы из поста How Async/Await Really Works in C#

Этот пост .Net блога является продолжением исходного поста, глубоко погружающим в историю, приведшую к созданию конструкций async/await и стоящие за этим дизайнерские решения и детали реализации async/await в C# и .NET.

Исходный пост What is .NET, and why should you choose it? предоставляет обзор платформы на высоком-уровне, перечисляя различные компоненты и решения на уровне дизайна, и предваряя последующие посты в глубину обозначенных тем.

Ссылки в развитие темы:

1. Часть 2 Артефакты от EAP шаблона, SynchronizationContext

2. Уроки по асинхронному программированию из первой половины работы

3. Параллельные вычисления — Все дело в контексте-синхронизации (SynchronizationContext)

4. Async/Await из C#. Головоломка для разработчиков компилятора и для нас

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

На текущий момент есть различные точки зрения на то, сколько же в ООП всё-таки принципов и в этой статье мы будем считать, что этих принципов четыре: Инкапсуляция, Наследование, Полиморфизм и Абстракция. Примеры будут приведены на языке C#, однако, они очень простые, да и сама суть не зависит от языка, поэтому будет полезна всем начинающим изучать ООП программистам.

Традиционно, для реализации CI/CD сценариев DevOps-инженеры используют различные платформы, такие как Jenkins, TeamCity, Azure DevOps и т.д. Их конфигурирование для сборки, версионирования, создания релизов решений может быть сложным и трудоемким, особенно если решение состоит из множества проектов/единиц развёртывания.

Обычно для настройки сборки решений в .NET используется большое количество разнородных скриптов, что создает ряд проблем:

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

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

• Непредсказуемость: нет уверенности, что процесс будет проходить одинаково на всех серверах сборки, поскольку он зависит от настроек окружения и установленных там SDK. Более того, сборка или запуск тестов могут проходить на одной ОС, а развёртывание - на другой, приводя к непредсказуемым ошибкам.

• Зависимость от инструментов: для настройки CI/CD с использованием скриптов обычно требуется определенный набор инструментов, создавая зависимость от них и усложняя переносимость настроек.

• Отсутствие контроля версий: нередко бывает так, что скрипты не хранятся в системе контроля версий, тем самым затрудняя отслеживание изменений и воспроизведение конфигурации для определенной версии приложения.

• Отсутствие вовлеченности разработчиков: поскольку, зачастую, настройка CI/CD выполняется DevOps-инженерами, разработчики не могут вносить изменения в процесс сборки напрямую. Более того, разработчики могут не знать, как настроен весь процесс, что делает его менее прозрачным и увеличивает время реакции на изменения или проблемы.

• Зависимость от внешних поставщиков: в постоянно изменяющихся условиях рынка, коробочные решения для CI/CD могут устаревать, переставать соответствовать требованиям организации или просто уходить с рынка. Всё это может приводить к необходимости перехода на другие решения и влечёт дополнительные затраты на переобучение и перенастройку процесса.

Что можно сделать, чтобы решить эти проблемы?