Я часто общаюсь с предпринимателями и вижу: даже те, кто давно в бизнесе, не знают, что если на сайте есть форма с запросом имени или телефона — они уже считаются оператором ПД и обязаны соблюдать требования закона.

Многие думают, что формальная политика конфиденциальности, скачанная из интернета, спасёт. Это глубокое заблуждение. Кстати, эти правила касаются не только сайтов — Telegram-ботов тоже , если они собирают данные пользователей.

Привет! Меня зовут Андрей Кузьмин, в МТС я работаю DevOps-инженером. В моей работе инструменты решают многое — например, помогают команде быстрее выпускать обновления, вовремя узнавать о проблемах и сразу их исправлять. Благодаря им бизнес не теряет клиентов и деньги из-за сбоев в работе сервисов.

В этой подборке — восемь инструментов, популярных у современных DevOps-команд. Мониторинг, автоматизация, управление инцидентами, анализ данных, полная прозрачность инфраструктуры и кое-что еще. Каждый инструмент закрывает свою критическую задачу и реально упрощает работу. Поехали!

• ACL (Access-List, списки управления доступом), используемые в спискахраспределения, изначально разрабатывались для фильтрации пакетов, а не для фильтрации маршрутов
• Невозможность определения совпадения маски маршрута при использовании стандартных ACL
• Использование расширенных ACL может оказаться громоздким для конфигурирования
• Работа ACL достаточно медленна, так как они последовательно применяется к каждой записи в маршрутном обновлении

Приветствую!

В нашем чате "Кот на салфетке" (кстати, заходите — у нас весело) регулярно всплывают бугурты об использовании различных ИИ-агентов (Copilot, Cursor) для написания кода. Главными инициаторами сего действа выступают Сергей и Кавай (расскажите маме, что вы в "тиливизаре").

Они оба проповедуют диаметрально противоположные позиции:

К написанию этой статьи меня подтолкнуло изучение архитектурных подходов для Vue.js-проектов, а вдохновила - детально описанная методология Feature-Sliced Design.

К сожалению, PHP-сообществу не хватает подобных развернутых рекомендаций, да и вообще, каких-то общепризнанных стандартных подходов в структуре проекта.

Моя статья - это попытка обобщить изученную мною за много лет информацию и сформировать универсальную структуру проекта, основанную на принципах Clean Architecture и модульного монолита.

Шардирование, двухфазный коммит и распределенные транзакции окружены определенными мифами и заблуждениями. Например, может быть достаточно неочевидно, что двухфазный коммит обеспечивает только атомарность транзакций, но не их изоляцию. Поэтому мы решили написать пост, который бы помог разобраться в этих сложных вещах и сделать правильный выбор, когда Postgres'а Вам станет мало и Вы столкнётесь с шардированием.

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

Функционально проект реализует систему сбора и анализа вакансий с агрегаторов вроде HeadHunter. Но гораздо важнее не то, какие задачи решает система, а то — как именно она это делает. Этот проект — прежде всего о структуре, архитектуре и принципах.

Основные используемые технологии: Python 3.13, FastAPI, Nginx, Uvicorn, PostgreSQL, Alembic, Celery, Redis, Pytest, FileBeat, LogStash, ElasticSearch, Kibana, Prometheus, Grafana, Docker, Docker Compose.

Это первая из статей, посвященных веб-серверу Angie. Мысль создать цикл статей возникла в процессе разработки курса по администрированию Nginx и Angie. Приходилось сталкиваться с темами, которые довольно слабо описаны в открытых источниках, либо не описаны вообще. В планах описать типичные области его использования с реальными примерами доступным языком. Так как большинство решений и конфигов будет совместимо с Nginx, надеюсь цикл будет полезен сообществу.

Привет, Хабр. В этой статье я продолжу изучение возможностей электронного журнала(прошлая статья).

На этот раз поговорим о использовании школьного электронного как файлового хранилища. Загрузим туда образы линукса, аниме и многое другое...

Привет, Хабр! В этой статье речь пойдет о лазерном ЧПУ-станке, который наша студенческая команда делала на 2ом курсе в рамках университетской проектной практики. Основная цель материала - поделиться личным опытом и дать обзорное представление о том, как такие устройства можно собирать. Будет много картинок, ссылок на смежные темы и субъективного мнения.

3 года назад я рассказывал как я делаю опенсорсную табличку "Я Занят". С тех пор проект полностью перешел внутрь Flipper Devices и его разрабатывает та же команда, что и Flipper Zero.

BUSY Bar — девайс для концентрации и современный Pomodoro-таймер с блокировкой отвлекающих приложений и уведомлений. Мы обновили дизайн устройства, доработали его функции и произвели первую тестовую партию. В этой статье я расскажу что мы сделали за это время и как изменился проект.

Привет, Хабр! Недавно брат поинтересовался, как я решаю проблему с вечно забитым диском на MacBook, и я решил не только ему ответить, но и поделиться своим опытом со всеми. Расскажу, как бороться с нехваткой места и какой внешний накопитель выбрать, чтобы не разориться и не разочароваться.

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

Делюсь опытом реализации распознавания показаний стрелочного манометра по фотографии и отправки их в Home Assistant.

Давно мучал вопрос передачи показаний давления системы отопления со штатного манометра газового котла. Для этого несколько лет назад была приобретена камера ESP32-CAM и интегрирована в Home Assistant посредством ESPHome.

Введение: Архитектурное дежавю

Вы когда-нибудь замечали, как цифровой мир движется по спирали? В 2018 году я, размахивая Dockerfile и Helm-чартами, внедрял микросервисы на C# с RabbitMQ — всё ради священной цели «низкой связанности». А через три года, переключившись на Angular, с ужасом осознал: фронтенд-компоненты общались через цепочки Input/Output, словно это 2005-й, а мы пишем WinForms.

Это как собрать космический корабль, но управлять им через телеграф. На бэкенде мы гордо декларируем event-driven architecture, а на фронтенде компоненты перешёптываются через пропсы, будто подростки на школьной дискотеке. Ирония? Чем сложнее становились наши системы, тем больше они напоминали те самые монолиты, от которых мы бежали в мире backend.

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

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

Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.

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

Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.

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