В этой статье я расскажу о том, как я создал систему безопасности для своего проекта. Здесь я описываю этапы реализации, проблемы которые я решил, и как я устранил обнаруженные уязвимости.
Предисловие
Цель этой статьи - объединить и кратко изложить все базовые архитектурные подходы: их терминологию, концепции и отличительные черты. Собрать всё воедино, чтобы можно было относительно быстро вникнуть в основы.
Я решил написать серию статей, посвящённых различным аспектам проектирования программных систем, но первоначальной идеей было показать архитектурное решение моего pet-проекта на FastAPI — пример реализации «чистой архитектуры» с использованием современного стека: Python3.13, FastAPI, Uvicorn, Nginx, PostgreSQL, Alembic, Celery, Redis, Pytest, Filebeat, Logstash, Elasticsearch, Kibana, Prometheus, Grafana, Docker и Docker Compose.
Однако по мере проработки деталей стало очевидно: чтобы обсуждать структуру приложения предметно и аргументированно, необходимо сначала заложить общую теоретическую основу, чтобы читатель понимал, о чем речь.
Так родилась идея вынести базовые концепции архитектуры и проектирования в отдельную публикацию — не перегружать материал сразу всем, а построить серию объёмных, но логично связанных статей.
Мы (команда Axiom JDK) подготовили перевод статьи про var, или Local Variable Type Inference (LVTI). Из этой статьи вы узнаете как работает var, когда эту фичу лучше использовать в коде, а когда — воздержаться. Всё это с примерами кода и комментариями от нашей команды.
Примечание от команды Axiom JDK: Хотя статья написана в 2019 году, она остаётся актуальной в 2025: var (Local Variable Type Inference) уже давно является частью LTS-релизов и ключевой особенностью современного Java-кода, но по-прежнему вызывает споры и вопросы даже у опытных разработчиков. Это отличный материал от Брайана Гётца — одного из архитекторов Java — с разбором принципов, которые не устарели. С тех пор появилось больше практики, но базовая теория осталась неизменной. Мы публикуем перевод как удобный справочник по механике var, его компромиссам и подводным камням.
Если меня на собеседовании спросят что такое ООП, то может получиться как в анекдоте " завыл, бился головой о стену, в общем ушёл от ответа". Любое простое определение ООП не полно, любое полное слишком сложно. Это показывает что ООП само в своих основах очень сложно, а на поверхности лишь видимая часть айсберга. Итак, пробуем дать краткое и герметичное определение, последовательно вводя минимум определений, чтобы были видны цели а не догма. Герметичное значит ясное и самодостаточное, не опирающееся (явно или неявно) на другие нетривиальные понятия. Всё по взрослому. Мне понадобилось много итераций. И на глубине я увидел чудовищ. Я конечно знал их и раньше, но думал что я просто дурак и не понимаю как просто с ними работать. Нырнул глубже и... они не пропали! Для любой сложной ООП системы они останутся с тобой.
ФП в отличие от него имеет крутую ступеньку входа но дальше сложность не растёт.
Habr, что это за поле «Целевая аудитория»?
Статья предназначена для яйцеголовых преподавателей разработки программного обеспечения, которые должны дать отеческое наставление юным программистам, выбирающим свой путь.
Так получилось, что загруженный в меня годами разработки опыт привел к нигилизму и отрицанию общемировых ценностей. Например, я ненавижу демократию, самое первое запротоколированное проявление которой привело к решению распять нахрен одного там назаретянина (но сейчас не об этом). Я отрицаю пользу IDE, необходимость развития языков программирования, целесообразность существования паттернов и еще много достижений цивилизации по остаточному принципу.
Зато я являюсь ярым сторонником велосипедостроения. В подавляющем большинстве ситуаций лучше спроектировать и реализовать свой велосипед с перламутровыми пуговицами, чем пытаться приварить оные к выкидышу китайского велосипедопрома. Почему-то среди моих коллег принято относиться к собственным реализациям чего угодно — пренебрежительнее, чем к невнятной библиотеке версии 0.0.1, написанной албанским стажером три года назад по пьяни.
Если разработчик уровня выше стажера считает, что какой-то хрен из интернета уж точно напишет случайный кусок кода лучше него — это не программист, это самозванец, его надо гнать из команды с волчьим билетом.
Виртуальная СУБД. Язык манипулирования данными (DML)
Эта статья является продолжением серии статей посвященной новой системе разработки клиентских приложений KISS Virtual XML DBMS.
Виртуальная СУБД является чисто объектной и не использует явным образом язык SQL, но это не означает, что она является NoSQL СУБД. Виртуальная СУБД - это чисто объектная система управления реляционной XML базой данных. Язык SQL реализован исключительно объектными средствами.
Язык манипулирования данными представлен в виртуальной СУБД базовым классом recset (набор записей). В статье описаны основные понятия, возможности и особенности этого объектного языка. При этом рассматривается их связь с понятиями и возможностями языка SQL. Акцент сделан на тех различиях, которые позволили обеспечить максимальную эффективность и универсальность виртуальной СУБД.
Виртуальная СУБД. Язык определения данных (DDL).
Эта статья является продолжением серии статей посвященной новой системе разработки клиентских приложений KISS Virtual XML RDBMS.
Виртуальная СУБД - это чисто объектная система управления реляционной XML базой данных. Язык определения данными представлен в виртуальной СУБД базовым классом tblschema (схема виртуальной таблицы). Этот класс предназначен для объектного представления словарей (метаданных) различных физических СУБД. Одной из главных целей создания виртуальной СУБД было обеспечение ее независимости от конкретных физических СУБД, поэтому потребовалось создать собственный универсальный объектный инструмент для определения и корректировки стандартизированных метаданных, совместимый со всеми реляционными СУБД.
В статье описаны основные понятия, возможности и особенности этого объектного языка.Акцент сделан на тех особенностях схемы виртуальной таблицы, которые позволили обеспечить максимальную эффективность, гибкость и универсальность виртуальной СУБД. Также появились уникальные возможности виртуальной СУБД, которые стали доступны для всех физических СУБД.
Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.
Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.
Безусловно, это всё важные и фундаментальные вещи.
Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.
Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.
Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?
Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.
Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.
С появлением LLM люди разделились на три лагеря: тех, кто верит в повышение КПД при помощи автодополнения и тех, кто относится к хайпу крайне скептически. Третий лагерь — это сами LLM, они же тоже что-то там про себя думают, наверное.
За долгие годы работы с кодом я привык слышать от среднего уровня разработчиков (и от тех, кто выбрал языки, которым требуется бесконечная генерация бойлерплейта): «Продуктивность программиста напрямую зависит от IDE». При том, что я всегда производил в несколько раз больше самого сложного в компании кода, используя vim с минимумом плагинов. Подсветка синтаксиса мне помогает, тут (как, впрочем, и почти везде) я с Пайком не согласен. Автодополнение — уже нет, я его иногда включаю «еще раз попробовать, вдруг это со мной что-то не так», и когда читаю курсы — но в основном мне мешают выскакивающие окошки: отвлекают, распыляют внимание, наталкивают на ложный путь.
TL;DR: Нет. Хорошо спроектированный язык в развитии не нуждается.
Попробую объяснить, что меня, человека с тридцатилетним стажем в разработке, свободно пишущем на более дюжины языков, привело к такому абсурдному — на первый взгляд — выводу.
Более того, ниже я постараюсь уложиться в нескольких абзацев, чтобы рассказать, какие требования лично я предъявляю языку программирования в 2025 году, и почему этому «идеалу» просто некуда «развиваться».
Логирование является одним из ключевых и важнейших элементов разработки и эксплуатации приложений. Умение правильно вести журнал логов — ключ к эффективной отладке и мониторингу приложений. Оно дает ценную информацию всей цепочке заинтересованных лиц: от разработчиков и системных администраторов до руководителей бизнеса.
В статье рассмотрен де-факто стандарт логирования — модуль logging в Python. Я дам общие рекомендации по его настройке и опишу практики применения модуля, подходящие для большинства случаев.
Привет, Хаброжители!
Все современные средства разработки — практически без исключения — наделены двумя родовыми травмами. Они не дают доступа к чуть более низкому софтверному уровню (синтаксическому дереву) без помощи сторонних хаков и ориентированы на синхронное исполнение.
Прежде, чем продолжить, я сразу оговорюсь: я не имею в виду узкоспециализированные задачи, типа написания драйверов, программирования контроллеров и прочей околожелезной разработки; там другие правила. Я говорю про мир приложений: от инди-игр до энтерпрайза. Языки высокого уровня, на которых сегодня ведется более (оценка навскидку) 98% всей разработки продуктов для конечного пользователя, лишены примитивов представления AST и параллельного (не путать с асинхронным) исполнения.
Привет! Мы — команда Яндекс Практикума и эксперты курса «Python-разработчик». В этой статье собрали полезные ресурсы, которые помогут освоить принципы объектно-ориентированного программирования (ООП) и научиться применять их на практике.
Если на Силикатной улице (это в Мытищах) остановить тысячу случайных прохожих и спросить их, на каких трёх слонах покоится ООП, каждый второй назовёт инкапсуляцию. В коридорах МИФИ, или на собеседовании в Яндексе — процент будет даже выше. Даже LLM способна на шести пальцах объяснить, почему.
И, тем не менее, ООП — один из худших способов обеспечить инкапсуляцию. Идолопоклонники на этом месте могут поставить тексту, мне и вселенной — минус, остальным я на примерах попытаюсь объяснить, что побудило меня к столь резкому заявлению.
Привет, Хабр!
У меня появилась необходимость отделить проект от фреймворка. Благо кода фреймворка в проекте было не так много, но избавиться от него тоже нужно.
Поэтому было принято решение переписать функционал который он покрывал.
Одной из используемых функций фреймворка было - построение пространства имен.
Пространство имен, проще говоря, создано что-бы задавать область видимости кода для другого кода. Используя пространство имен можно гарантировать что клиентский код не будет зависеть от названия: переменных, функций, класса, и всего чего угодно в коде, в том числе при подключении нескольких библиотек тоже можно не переживать. Клиентский код будет зависеть только от результата работы кода.
Удачно получилось что тема пересекается с моей статьей. Может если это будет серия статьей с пометкой Клиентский код, то мне получится лучше донести что же всё-таки это за код такой.
Книги делятся на две категории: fiction и non-fiction. Технические книги — внезапно — не исключение, и поддаются точно такой же классификации. Между учебником по научной дисциплине, начинающегося с аксиоматики и продолжающегося доказательствами теорем, — и практически любой современной литературой по «Computer Science» — лежит пропасть. Что происходит, когда люди долгое время оказываются рабами одной-единственной книги (с продолжениями), нам хорошо известно из истории. Возникает религия.
99% процентов литературы по ООП — это талмуд. Вероятность того, что вам подойдет «паттерн» — примерно 50%. Как встретить динозавра на Невском. Знание паттернов полезно в той же степени, что и теология, — и примерно тем же по специальности людям. Всегда полезно уметь отличать по запаху Пана от простого фавна, но практических применений такой эрудиции — не существует.
Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.
Если вы сфокусируете взгляд на синей рамке, вы увидите растопырившего лапы Амбидиректуса с вытянутой шеей и маленькой головой, развернутой влево. Перефокусируясь на красную рамку, вы познакомитесь с его приготовившимся нырнуть в стену справа Alter Ego, с плотно ввинченной в шею головой и замершими во взмахе назад передними конечностями.
Я показал вам этого Амбидиректуса для того, чтобы проиллюстрировать основную мысль этого текста: споры о превосходстве той или иной парадигмы над остальными — не имеют никакого смысла и всегда являются религиозной войной остроконечников против тупоконечников.
Данная статья является продолжением серии статей посвященных Системе разработки клиентских приложений (KISS Virtual XML DBCS). В этой статье рассматривается синтаксис языка программирования ULCA (Universal Language for Client Application) , используемого этой Системой.
ULCA (Universal Language for Client Application) - Новый объектный интерпретируемый язык программирования, предназначенный для разработки клиентских desktop и web приложений. Данная статья является продолжением серии статей посвященных Системе разработки клиентских приложений (KISS Virtual XML DBCS). В этой статье рассматривается объектная модель, используемая языком программирования ULCA .
