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

Если администрировать Linux-сервера достаточно долго, рано или поздно сталкиваешься с сетевой фильтрацией. Где-то нужно закрыть лишние порты, где-то ограничить доступ между сегментами сети, а где-то настроить NAT.

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

В этой статье разберёмся, как появился nftables, чем он отличается от привычного iptables, как устроена его архитектура и как на практике использовать его для настройки firewall на Linux-сервере.

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

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

ORC — это колоночный формат, то есть данные хранятся не по строкам (как в CSV), а по столбцам. Именно это даёт ему способность эффективно сжимать и читать только нужные колонки. Есть ещё встроенная индексация и фильтр Блума, которые позволяют не перелопачивать лишние данные.

Давайте заглянем под капот и посмотрим, как устроен ORC-файл, зачем там индексы и как фильтр Блума ускоряет поиск.

Недавно, в одной из соцсетей, наткнулся на короткий пост, в котором автор написал:

«СКАМИНА ДЛЯ АЙТИШНИКОВ
Выглядит так —
Приглашают на интервью, в конце говорят, что вот проект, с которым нужно будет работать, и кидают ссылку на GitHub.
Говорят: склонируй, расскажу, что там по архитектуре.
Ну и если склонировать, там внутри таски для VS Code, которые качают и запускают обфусцированный код.
Берегите себя.»

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

Давайте разберемся, как это работает.

HAProxy часто появляется в инфраструктуре незаметно. Сначала это просто балансировщик: принял трафик, отправил дальше — всё понятно. Потом появляется второй сервис, третий, routing по домену, path, заголовкам, SNI, а заодно canary и временные исключения. И вот конфиг, который когда-то помещался на один экран, превращается в логическую задачу со звёздочкой.

В этот момент почти всегда всплывают ACL. Кто-то использует их осознанно, кто-то — по принципу: нашёл в примере, вроде работает. Рядом с ACL неизбежно стоит mode: tcp или http. Снаружи это выглядит как простая настройка, но на деле — фундаментальное решение, от которого зависит, какие данные HAProxy вообще видит и какие условия способен проверить.

Проблема в том, что HAProxy не делает догадок. Он последователен и выполняет конфигурацию ровно так, как она написана. Отсюда и классика жанра: ACL есть, но backend не выбирается; mode вроде http, но заголовки недоступны; routing работает почти всегда, кроме пятницы.

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

Я попробую продемонстрировать возможную проблему на тестовом примере (кстати, почти аналогичная проблема наблюдалась в реальной ПРОМ-системе).

В какой-то момент почти в каждом Kubernetes-кластере наступает день, когда kubeconfig с правами cluster-admin перестаёт быть временным решением и внезапно становится: так исторически сложилось. Пользователей становится больше, доступы плодятся, а вопрос: кто и зачем может удалить namespace в проде? повисает в воздухе без логичного ответа.

До определённого масштаба это ещё можно терпеть: сертификаты, статические токены, ручная раздача доступов. Но как только в кластере появляются: несколько команд, требования по аудитам, SSO или просто здравый смысл, становится ясно — Kubernetes нужно подключать к нормальной системе аутентификации.

Kubernetes из коробки умеет работать с OIDC (OpenID Connect), и это, пожалуй, самый адекватный способ интегрировать его с внешним Identity Provider. В роли такого провайдера часто выступает Keycloak: open-source, self-hosted, с поддержкой групп, ролей и интеграцией с LDAP/AD. В общем, всё, что обычно уже есть в инфраструктуре, либо планируется к появлению.

Эта история началась с исследования проблем производительности на высоконагруженной базе данных Postgres. Табличка, которая была предметом исследования, довольно небольшая (~100,000 записей), но очень активно используемая.

В процессе исследования я увидел, что Postgres использует индексный доступ по абсолютно неселективному критерию, фактически это был "INDEX FULL SCAN" в терминологии Oracle. Интуиция, наработанная на другой промышленной базе, вопила: "что-то здесь не так!"

Но что?

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

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

Проблема заключается в том, что в таблице на React с колонками, у которых есть свойство position: sticky, иногда пропадала граница между соседними ячейками по вертикали. Причём проявлялась она не всегда и носит случайный характер. Забавно, что изменение масштаба страницы (Ctrl + колесико мыши) мгновенно возвращает исчезнувший бордер. При этом в CSS все прописано и никуда не исчезает — это чисто визуальный баг рендера.

eBPF давно перестал быть узкоспециализированной игрушкой для kernel-энтузиастов и исследователей внутренностей Linux. Сегодня с ним, так или иначе, сталкиваются не только SRE, но вообще все, кто разрабатывает системы, близкие к сети, производительности или безопасности: от авторов сетевых плагинов (CNI) и прокси, до разработчиков кастомных агентских решений, observability-инструментов и low-level инфраструктурных компонентов. Даже если вы никогда не писали eBPF-код руками, есть хороший шанс, что он уже работает в вашей системе — тихо, незаметно и с довольно широкими полномочиями.

Чаще всего eBPF проявляется через удобные CLI, библиотеки и дашборды: установили агент, включили, и внезапно система знает о происходящем больше, чем strace, tcpdump и половина метрик вместе взятых. Но за этим комфортом скрывается нетривиальный механизм исполнения пользовательского кода прямо внутри ядра Linux — с жёсткими правилами валидации, ограниченной моделью исполнения и целым набором архитектурных компромиссов, о которых обычно не принято говорить в маркетинговых описаниях.

Здравствуйте, снова я — Дмитрий, React-разработчик. Все мы видели с вами такие карты, именуемые картойдами, в данном случае — карта России, я взял первую попавшуюся из интернета, для примера.

Если верить вакансиям, DevOps — это человек-оркестр: он пишет пайплайны, чинит Kubernetes, настраивает облака, знает Linux на уровне ядра, умеет в безопасность, автоматизацию, мониторинг и, на всякий случай, может заменить бэкендера, когда тот ушёл в отпуск. Желательно за зарплату джуна и с готовностью выходить на алерты в три часа ночи. Реальность, к счастью, чуть менее драматична. Но и чуть более сложна, чем рассказывают на вводных курсах (привет тем, кто решился вкатится по быстрому). В этой статье разберёмся, кто такой DevOps на самом деле, почему от него действительно ждут «всего и сразу» и где заканчивается адекватное ожидание, и начинается фантазия работодателя.

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

Изначально может показаться, что здесь сложного практически ничего нет: есть toFixed() и toLocaleString(), но практика показывает, что реальные интерфейсы почти никогда в это не укладываются.

Почему? Потому что в разных диапазонах чисел пользователи ждут разного поведения.

Именно с этим сталкиваются разработчики при работе с таблицами, отчётами, финансовыми данными и аналитикой.

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

Ниже опишу требования к форматированию, которые легли в основу функции, и покажу, как они отражаются в коде и в интерфейсе.

Сетевую часть Linux обычно «настраивают», но редко понимают. Добавляют iptables-правило, включают NAT, правят sysctl — и если трафик пошёл, считается, что задача решена. Проблемы начинаются ровно в тот момент, когда он не идёт, а поведение системы перестаёт быть очевидным. В Linux нет магии. Есть IP-пакет, его заголовки и строго определённый путь внутри ядра: маршрутизация, netfilter, conntrack, NAT, TCP/UDP стек. Если не понимать этот путь целиком, firewall выглядит как чёрный ящик: NAT — как случайный набор правил, а Kubernetes CNI — как нечто «особенное», существующее отдельно от обычной сети.

Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.

Nginx часто воспринимают как «просто веб-сервер», который достаточно поставить и запустить с дефолтным конфигом. На этом этапе обычно и останавливаются: процессы работают как попало, заголовки отдаются по умолчанию, SSL настроен формально, keepalive либо не используется, либо вредит, а маршрутизация запросов со временем обрастает хаотичными location. В результате конфигурация вроде бы выполняет свою задачу, но остаётся плохо управляемой, неочевидной и далёкой от оптимальной.

Эта статья — о базовых, но часто недооценённых возможностях Nginx. Мы последовательно разберём настройку рабочих процессов, управление HTTP-заголовками, корректную конфигурацию SSL, работу keepalive-соединений и маршрутизацию запросов. Без магии и редких трюков — только то, что действительно используется в продакшене и позволяет сделать конфигурацию понятной, предсказуемой и безопасной даже для начинающего администратора.

Снова на связи я –Дмитрий, React-разработчик, и в этот раз мы поговорим о создании фундамента для дальнейшей разработки.

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

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

Представим ситуацию: мы спланировали маршрут до точки назначения, предположили, по какой дороге будет быстрее добраться, даже вспомнили, где обычно бывают пробки, чтобы их объехать. Но, неожиданно, на самом свободном участке образовался затор из‑за аварии в правом ряду. В этот момент понимаем, что лучше бы мы ехали по навигатору, и какая‑нибудь «Анфиса» предупреждала о дорожной ситуации, чтобы в определенный момент можно было изменить траекторию движения. Именно так годами чувствовали себя пользователи Spark, когда их красиво оптимизированные запросы наталкивались на суровую реальность распределенных данных.