
Рассказываю как создать эхо-бота для MAX на Python с помощью библиотеки maxapi без проблем для aiogram разработчика!
Объектно-ориентированное программирование
Рассказываю как создать эхо-бота для MAX на Python с помощью библиотеки maxapi без проблем для aiogram разработчика!
Разбор самых фундаментальных шаблонов проектирования на языке программирования python: наблюдатель, адаптер, команда, компоновщик, декоратор, фасад, фабрика, итератор, заместитель, одиночка, состояние, шаблонный метод.
Привет, Хабр! Меня зовут Константин Крюков, я разрабатываю систему хранения данных TATLIN.UNIFIED в YADRO. Сейчас мы с командой создаем MeyerSAN — решение, которое имитирует неисправность SAS HDD и SSD и позволяет автоматически тестировать реакцию СХД на ошибки.
Мы написали проект на новом стандарте С++ 23 и использовали паттерны объектно-ориентированного программирования. Под катом расскажу, что за решение у нас вышло, как устроена его архитектура. А еще мы вместе вспомним, зачем строить программную архитектуру тщательно и правильно (и не жалеть об утраченном времени на активную разработку).
QapDSLv2: Новый стандарт AST-heavy парсинга
QapDSLv2 обеспечивает:
Молниеносное построение AST
Полное сохранение структуры исходного кода
Простоту интерпретации и модификации грамматик
Забудьте о любы других парсерах! С помощью QapDSLv2 можно создавать компиляторы/анализаторы/форматировщики кода за минуты/часы.
Парсеры и генерация абстрактных синтаксических деревьев (AST) — это обычно долго, сложно и требует тонны шаблонного кода. Но что если я скажу, что теперь можно описывать грамматики и структуры данных одновременно и получать готовый, оптимизированный C++ код автоматически?
QapDSLv2 — новый стандарт эффективности и удобства в парсинге. Это язык описания парсеров, который избавляет от синтаксического шума, упрощает интеграцию с C++ и позволяет создавать сложные анализаторы без боли и ошибок. Забудьте о бесконечных циклах отладки и непонятных генераторах — теперь всё просто, понятно и эффективно.
В этой статье вы узнаете, как QapDSL v2 меняет правила игры в мире парсинга и компиляторов, увидите реальные примеры и поймёте, почему это важно для каждого, кто работает с языками программирования и обработкой текста.
Готовы ускорить разработку и вывести свои проекты на новый уровень?
QapGen — мощный генератор парсеров, построенный на основе QapDSLv2, который из грамматик QapDSLv2 сразу создаёт высокопроизводительный C++ парсер с типизированным AST, описанным прямо в грамматике.
t_sep
{
string
body =
any
(" \t\r\n");
}using
" "
as
t_sep;
t_value{
TAutoPtr<i_value>
body;
" "?}
t_comma_value{
","
t_value
body;
" "?}
t_array:i_value{
"["
" "?
t_value
first?;
vector<t_comma_value>
arr?;
"]"
" "?}
Когда вы работаете с текстовыми файлами в Java, особенно содержащими кириллические символы, то важно правильно управлять кодировкой. Ошибки в кодировке приводят к искажению текста, появлению квадратных символов или нечитаемых строк. В этой статье мы разберём примеры чтения и записи файлов с кириллицей, используя базовые классы ввода и вывода в Java.
Разработка — это не только про код, но и про подходы. В этой статье я постарался собрать и объяснить ключевые принципы проектирования, которые часто упоминают в собеседованиях, в статьях на Medium и в комментариях на GitHub, такие, как SOLID, DRY, KISS, YAGNI, APO, BDUF, бритва Оккама.
📌 Что внутри:
1. Понятные объяснения без перегрузки теорией
2. Примеры на Java (но подойдут и другим разработчикам)
3. Иллюстрации и метафоры, чтобы не уснуть
Будет полезно как новичкам, которые только слышали про SOLID и др. подходы в проектировании, так и разработчикам, которые хотят освежить знания или взглянуть на принципы под другим углом.
Привет! Меня зовут Азамат, я backend-разработчик в Циане. В работе мне часто приходится пересматривать архитектуру компонентов или проектировать её с нуля. Со временем у меня накопились подходы и наблюдения, которыми хочу поделиться.
В этой статье расскажу, с чего я обычно начинаю проектирование, какие вопросы задаю себе перед тем, как описывать архитектуру, и какие принципы помогают принимать решения.
Материал будет полезен тем, кто хочет влиять на архитектуру в своей команде и ищет, с чего начать.
Основная проблема IT-отрасли, на мой непросвещенный взгляд, заключается в том, что жизнь обучает нас профессии примерно так же, как учителя начальной школы — арифметике. Сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды. И так далее.
С чего начинается обучение компьютерным наукам? — С некоторого количества теории, которая скучная и непонятная, как и любая полностью оторванная от практики теория, — а потом — с примеров. Мы открываем REPL и некоторое время забавляемся с ней, как с калькулятором.
Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.
Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.
Если экстраполировать мнение большинства и принять его за аксиому, то в мире будут существовать только банковские приложения и круды с базами данных в качестве узкого места и дополнительными серверами вместо корректного горизонтального масштабирования. Тем не менее, многие даже в своей работе используют инструменты, которым никакая база не требуется, а обеспечение роста гарантируется размазыванием нагрузки по кластеру, а не приклеенными (sticky) сессиями. И я говорю не про десктоп.
Доброго времени суток, Хабр!
Сегодня хотел бы поговорить об анемичной модели — одном из самых дискуссионных топиков (особенно для приверженцев DDD) и о том, как, по моему мнению, правильно её готовить. Для кого-то анемичная модель — это антипаттерн, тогда как для других это единственный правильный способ реализации приложений. Многие использовали её годами и даже не знали, как она называется, и что кем-то она считается антипаттерном. Реальность же такова, что анемичная модель — это инструмент, который может подходить или не подходить в зависимости от ситуации, но при этом является очень популярным и, по факту, «стандартом де-факто» для многих программистов и организаций. Хотя в последние годы я и вижу тенденцию к тому, что DDD и, соответственно, богатая доменная модель становятся всё популярнее, пока что, по моему мнению, им далеко до популярности анемичной модели.
Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.
Тем не менее, хотя я никогда не считал себя евангелистом функционального подхода, и уж, тем более, не примыкал к стану воинствующих пуристов, меня постоянно свербил вопрос: что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?
И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде. Даже банальная асинхронность приносит кучу совершенно нерелевантных проблем: мьютексы любого сорта — это порождение дьявола. В игрушечных примерах из книжек они езе как-то работают, но действительно _многопоточный_ код на них написать фактически нереально. Среда, которая буквально приглашает разработчика ошибиться и разрушить тотальность функций потенциальным дедлоком — не должна иметь права на существование в принципе.
Несколько лет назад я начал добавлять Go в свой арсенал языков (будучи на тот момент Java разработчиком). Мне было очень непривычно. Более того, я принял язык не с первой попытки. Причём пришлось принять его больше из-за сложившихся обстоятельств, чем по собственному желанию.
Но прошло время, Go стал моим основным языком и, рискну сказать, любимым. В статье ниже расскажу, почему язык казался мне непривычным, какие парадигмы мне пришлось поменять в своей голове и почему во многом это оказалось более эффективно.
Уточню: статья ориентирована больше на тех, кто планирует перейти в Go, чем для опытных разработчиков.
Всем привет!
Меня зовут Илья, я работаю в Райффайзен Банке. Мы пишем свои бэкенд-сервисы на Java и Kotlin, поэтому зачастую приходится переключаться с одного языка на другой. Из-за этого невольно начинаешь сравнивать подходы и механизмы одного языка с его JVM-собратом. Сегодня я бы хотел поговорить об одном из таких механизмов — пропагации ошибок и исключений.
Используете ли вы в своем коде исключения? Ответ кажется странным, так как исключения являются неотъемлемой частью Java. Но что, если я спрошу, используете ли вы исключения для управления логикой своей программы?
В мире php-ходящих есть мнение, что первое, что сказал Иисус Христос придя в этот мир: "исключения - зло".
Конструкция по типу try { .. } catch (Exception $e) { ..$e->getMessage() }
знакома каждому 5 человеку в мире и воспринимается как неотъемлемая часть любой логики на php.
И что в этом такого?
Ничего, кроме того, что из чёткой цепочки обработки запросов ваш код быстро превращается в коллекцию try catch
на каждой 3 строке. Это не кажется проблемой до того момента, как дело не дойдёт до разделения приложения на отдельные слои во благо SOLID. Представьте, что в вашей команде >1 человека и все они работают над разными слоями, которые должны между собой взаимодействовать. В подобных ситуациях все участники должны документировать все созданные методы, а так же возвращаемые исключения. И да, это хорошо, но зачастую документация исключений становится невыносимой. Таким образом ваша работа обрастает ненужным слоем прокидывания исключений, которые к слову нужно ещё и создать.
В Java существует две реализации интерфейса List: ArrayList и LinkedList. Какая из них лучше? Как выбрать подходящую для вашего приложения? В данной статье мы сравним их различия, производительность и потребление памяти, чтобы помочь вам определиться с выбором.
Привет, хабр! В этой статье хочу рассказать вам про дескрипторы в python. Покажу как и где их применять, а также расскажу о некоторых особенностях, которые могут не знать даже опытные разработчики. Надеюсь многие смогут найти что-то новое для себя.
Никто давно не пытается выводить теорий о том как правильно писать код.
Старые теории и способы об этом думать в общественной дискуссии давно свелись к спору о синтаксическом сахаре да и теории те были попыткой выделения каких-то математических свойств кода. Потом как известно была доказана невозможность этого.
Сейчас всё изменилось - мы должны рассуждать о проекте как о том, что постоянно изменяется большими группами людей, какая-то часть и кода и людей может быть неправильной, никто из модифицирующих не знает проекта целиком, нужны новые идеи и способы рассуждения.
Привет Хабр! В данной статье я расскажу о там, как работают метаклассы в python, что конкретно они делают, где их можно использовать и почему чаще всего лучше этого не делать.
Данная статья скорее нацелена на начинающих авторов библиотек или любопытных читателей, которые просто хотят узнать что-то новое о Python.
Поскольку среди тех, кому нравится мой стиль изложения, все еще попадаются люди, не имеющие представления о парадигмах внешнего мира, я решил буквально на пальцах показать, что такое акторная модель, и почему познавшие удовольствие работы с ней крайне неохотно отказываются от неё в пользу больших гонораров и душных офисов.
Рассказ рассчитан на тех, кто хотя бы поверхностно знаком с концепциями ООП и (или) ФП. Ниже вы не найдёте всех тех запутывающих псевдонаучных объяснений, которые вам услужливо предоставит Вика или Анжела (или как там вы называете свою любимую LLM в приватных чатиках).
Текст написан именно сегодня, когда Алану Каю исполнилось 85! Поздравляем, Алан, ты — гений, спасибо тебе за всё!