CTE в PostgreSQL упрощают код, но могут снижать производительность. Разбираем 4 антипаттерна, примеры EXPLAIN ANALYZE и практические способы оптимизации.

В прошлой статье мы упоминали основные SQL‑антипаттерны, способные замедлять работу базы данных. Продолжаем тему — на этот раз про CTE. 

Common Table Expressions (CTE), или конструкции WITH, — привычный инструмент SQL-разработчика. Чем сложнее запрос, тем выше шанс встретить в нём WITH: код становится чище, а запутанная логика разбивается на понятные блоки. CTE используют как альтернативу вложенным запросам и временным таблицам. Однако за внешней простотой и читаемостью скрываются риски снижения производительности, которые не всегда удаётся предвидеть.

Такие запросы на первый взгляд выглядят правильными, но работают неэффективно, и проблема вылезает только в EXPLAIN ANALYZE (инструмент разбирали в прошлом гайде). Разберём четыре антипаттерна CTE, посмотрим планы выполнения и покажем, как переписать запрос. В конце — короткий чек-лист диагностики.

Эта статья может быть полезна начинающим разработчикам и аналитикам, которые уже полюбили синтаксис CTE, но хотят понять, что на самом деле происходит «под капотом» в PostgreSQL.

В предыдущей статье я рассказывал о том, как предоставить удалённый доступ к данным измерений метеостанции с помощью модулей Heltec Automation HTIT-WB32LAF V3, объединяющих микроконтроллер ESP32-S3FN8 с LoRa-чипом SX1262. При правильной установке антенн и хороших условиях распространения радиоволн возможна передача данных на километры.

Но что, если нужно передавать данные ещё дальше, а возможности антенн с большим коэффициентом усиления исчерпаны и мощность передатчика повышать нельзя? 

В этот раз я пришёл с двухчастным текстом про F#, тайппровайдеры, скрипты, спортивное программирование, MVU, консольные интерфейсы в стиле FarManager, низкоуровневый интероп с виндой, некоторое количество хаков ХМ и, внезапно, живопись. Причём только консольные интерфейсы с некоторой натяжкой можно назвать центральным элементом повествования, поэтому я понятия не имею, как должен выглядеть потенциальный читатель этой статьи. Будем исходить из предположения, что он либо достаточно опытен, либо у него достаточно времени и усердия, чтобы расковырять всё, что я не счёл должным разобрать детально (я могу, но только за 16 глав).

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

Секрет попал в Dockerfile, разработчик спохватился и добавил RUN rm. Файла в контейнере больше нет — значит, всё в порядке? Нет: строку по-прежнему можно достать из образа, даже не запуская контейнер. Я собрала восемь образов, в каждом передала секрет своим способом и разобрала результат на слои и метаданные. Ниже — где именно оседает секрет в каждом случае и какие два способа действительно не оставляют следов.

Все эксперименты выполнены на Ubuntu 24.04.1 LTS, Docker Engine 29.1.3, BuildKit v0.26.2.

Vue снова меняет способ обновления интерфейса: теперь на горизонте Vapor и рендеринг без Virtual DOM. Зачем очередная архитектурная перестройка и что не устраивает команду Vue в нынешнем подходе?

Чтобы ответить, проследим путь Vue от Object.defineProperty до Proxy  и зачем теперь понадобился Vapor. Это поможет лучше понимать поведение ref, reactive и computed, вникнуть в причины архитектурных изменений Vue и подготовиться к дальнейшим изменениям.

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

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

Совместное исследование DDoS-Guard и FirstVDS

Раньше считалось, что DDoS-атаки направлены на «крупную рыбу» — корпорации, госкомпании, банки. Но реальность 2026 года говорит о другом: жертвой злоумышленников может стать кто угодно.

За три года число атак выросло с 2,2 до 2,5 млн. Их распределённость увеличилась на 480%. DDoS-атаки стали массовым, доступным и, что самое опасное, автоматизированным инструментом. 

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

Вместе с DDoS-Guard мы решили разобраться, а есть ли кто-то, кто оказывается в красной зоне риска чаще других? Изменился ли характер атак за последние несколько лет? Для этого мы проанализировали данные клиентов, глобальную статистику атак и опросы владельцев бизнеса. В итоге получили портрет идеальной жертвы. 

Дальше рассказываем, как мы это делали и что же удалось выяснить.

Ранее в своих статьях я рассказывал, как подключать модули EBYTE LoRa к Raspberry Pi и Repka Pi (ссылки в конце этой статьи). Но такие микрокомпьютеры потребляют довольно много электроэнергии и не «проживут» долго на аккумуляторе. 

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

В этой статье на примере метеостанции я расскажу о том, как создавать узлы сбора данных LoRa на базе микроконтроллера ESP32-S3, установленного в модуле Heltec Automation HTIT‑WB32LAF V3. Микроконтроллер может переходить в состояние глубокого сна, когда работают только часы реального времени и память RTC, а вся периферия отключается. В результате узел сбора данных может работать очень долго, питаясь от аккумулятора.

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

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

Зато судьбы учёных они меняют легко.

В конце 1990-х годов, когда физики неожиданно обнаружили, что нейтрино обладают массой, Тьерри Лассерр оставил космологию, чтобы полностью посвятить себя изучению элементарных частиц. «Это было так захватывающе, что я просто не смог устоять», — сказал Лассерр, ныне физик в Институте ядерной физики Общества Макса Планка в Гейдельберге, Германия. А Марк Росс-Лонерган собирался стать метеорологом, пока в 2010 году случайно не столкнулся с физикой частиц и не изменил своё решение. Лассерр, Росс-Лонерган и тысячи других учёных посвятили карьеру исследованию этой почти инертной частицы.

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

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

В статье соберем полностью локальную RAG-систему на Go, PostgreSQL и Ollama без облачных API и сторонних сервисов. Разберем весь путь — от индексации документов до получения ответа LLM на основе найденного контекста.

Это первая статья в серии про LoRa — технологию передачи данных, способную работать с сигналами ниже уровня шума. Протокол LoRa позволяют передавать данные на километры с очень небольшой мощностью передатчика — порядка 10 мВт или 10 дБм. При этом модули LoRa потребляют так мало энергии, что могут работать от одной зарядки аккумулятора год или больше.

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

С помощью LoRa можно сделать шлюз, который будет работать далеко от зоны покрытия интернета. Можно даже настроить передачу сообщений на большие расстояния вообще без интернета.

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

Это вторая часть статьи про Linux Incident Response — разбор live response на работающем Linux-хосте с подозрением на компрометацию.

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

Первая часть здесь.

В этой части процесс идет далее — к менее изменчивым артефактам. Рассмотрим механизмы закрепления и следы на диске: systemd-сервисы и timers, cron, автозапуск, пользователи, группы, пакеты, логи, kernel-артефакты. В финале расскажем о построении таймлайна, оформлении IOC и действия с системой после завершения расследования.

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

Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. 

Этот материал исправляет такие упущения. Он будет разбит на две части. В этой статье обсудим принципы расследования, изоляции, подготовки инструментария, начала анализа и исследования сети и процессов. 

Добро пожаловать под кат. 

Способен ли маленький нетбук принести хоть какую-либо пользу в 2026 году?

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

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

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

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

Сегодня мы закончим ковырять порт тайловых миров на F#. Правда, в прошлый раз мы исчерпали запас того, что вообще можно было «портировать», поэтому переключим внимание на совершенно новые фичи. Все они касаются UI (в узком смысле), ну или, говоря терминами игровой индустрии, HUD (Heads-Up Display).

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

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

Переход к микросервисной архитектуре неизбежно поднимает вопрос эффективности межсервисного взаимодействия. В PHP традиционный стек на базе PHP-FPM и REST API создает дополнительные накладные расходы: каждый запрос обрабатывается в отдельном процессе, что требует повторной инициализации контейнера зависимостей, загрузки конфигурации и всего контекста приложения. В результате увеличивается latency и снижается пропускная способность сервиса.

В этой статье мы шаг за шагом разработаем высокопроизводительный микросервис на Symfony 7, используя RoadRunner в качестве постоянного приложения-сервера, gRPC для межсервисного взаимодействия и Protocol Buffers для сериализации данных. По итогам вы получите полностью рабочий сервис и поймете, как построить производительную альтернативу классическому стеку PHP-FPM + REST.

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

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

PrimeTek, бывшая PrimeFaces, запустила PrimeUI — новую лицензионную модель для экосистемы PrimeNG, PrimeReact и PrimeVue. Это подаётся как унификация бренда, но по сути компания собирает свои ключевые продукты под одной коммерческой оболочкой. Раньше они существовали как набор отдельных библиотек, которые монетизировались через дополнительные продукты и сервисы. Теперь вся экосистема превращается в единый лицензируемый актив.

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

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

Начиная с 1960-х годов исследователи разрабатывают компьютерные программы, называемые системами интерактивного доказательства. Используя такую систему, математик записывает каждую строку доказательства (включая каждое определение) на языке, понятном компьютеру, а затем система проверяет логику. Если хотя бы один шаг не вытекает из предыдущего — если не доказана каждая мелочь вплоть до того, что 1 + 1 = 2, — программа не примет доказательство.

Сейчас учёные надеются формализовать всю математику с помощью системы интерактивного доказательства под названием Lean. Уже создана библиотека, содержащая более 120 000 определений, и проверено четверть миллиона теорем. Несколько математиков поддерживают эту базу данных, обновляя её и проверяя новые данные. (Некоторые из них занимаются этой работой полный рабочий день.) Они уже получили более 10 миллионов долларов финансирования, в основном от миллиардера-финансиста Алекса Герко.