Привет, Хабр! Меня зовут Алексей Колосков, я DevOps/Cloud-инженер в Hilbert Team. Вместе с моим коллегой Михаилом Кажемским в этой статье мы расскажем об особенностях DevSecOps-пайплайна и концепции Shift Left. Вы узнаете об основных этапах DevSecOps-пайплайна, автоматизированных проверках безопасности при разработке ПО, бесплатных и опенсорс-инструментах. Также найдёте советы, которые помогут раньше обнаруживать уязвимости и улучшать безопасность приложения. 

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

Наконец-то пришло время взяться за то, что я давно планировал — подробный гайд по асинхронной версии SQLAlchemy 2.0 в стиле ORM. В этой серии статей я подробно расскажу обо всех аспектах: от создания моделей и установления связей между ними до миграций с Alembic и взаимодействия с данными в базе. Мы будем шаг за шагом разбирать ключевые моменты работы с асинхронной базой данных, что позволит вам глубже понять SQLAlchemy и применить эти знания на практике.

Для начала, давайте разберёмся, что такое SQLAlchemy и почему каждый разработчик, работающий с реляционными базами данных (такими как SQLite, PostgreSQL, MySQL и т. д.), должен знать о ней. После этого — настройка. Мы будем работать с PostgreSQL, но не переживайте: код, который мы напишем, универсален для всех реляционных баз данных. Мы начнем с базовой настройки SQLAlchemy для асинхронного взаимодействия, а затем перейдём к созданию таблиц в современном декларативном стиле.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В первой части лекции мы узнали, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. В этой - разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.

После выхода релиз-кандидата версии 17 в плане выпуска осталась последняя незакрытая дата: 26 сентября 2024 года. На этот день намечен официальный выпуск PostgreSQL 17.

В этой статье рассказывается о патчах, принятых в ходе последнего мартовского коммитфеста. Предыдущие статьи о коммитфестах 17-й версии: 2023-07, 2023-09, 2023-11, 2024-01.

Все вместе они дают подробное представление о новой версии СУБД.

Добрый день, коллеги! Как известно, компания "Postgres Professional" более не рекомендует использовать секционирование с использованием pg_pathman, а рекомендует использовать вместо него декларативное секционирование. Однако помимо синтаксического сахара и утилитарного кода по поддержке интервального (в стиле Oracle) секционирования, я обнаружил для себя ещё одну проблему в такой миграции (переходе). Надеюсь, коллеги из PGPro доработают декларативное секционирование к моменту окончательного выпиливания pg_pathman.

«Китайский мудрец, сидя на берегу реки, сетует на расплодившиеся вокруг технологии», — такой текст я вбила в какую-то из многочисленных нейросетей, генерирующих картинки. Судя по всему, вместо расплодившихся вокруг технологий китайский мудрец случайно получил расплодившиеся ноги.

ИИ, с ним такое бывает.

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

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

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

Компания Postgres Professional занимается разработкой и поддержкой СУБД с 2015 года. Это серьёзный срок для компании в ИТ-сфере, и за это время мы видели много случаев, когда клиенты сталкивались с неоптимальным выполнением запросов. Обычно оптимизатор PostgreSQL неплохо справляется и строит хорошие планы, если количества джойнов в запросе не больше 10 и данные в таблицах распределены равномерно. Однако в даже на изначально тщательно продуманной базе данных, оптимизатор может сгенерировать настолько неоптимальный план, что его время выполнения может увеличиться в разы. В некоторых особо экстремальных случаях даже практически невозможно дождаться окончания выполнения запроса и понять при помощи EXPLAIN ANALYZE, что пошло не так. Усугубляющим фактором является то, что оптимизатор PostgreSQL никак не запоминает допущенные ошибки выполнения. Построив неоптимальный план один раз, он с большей долей вероятности будет делать это снова и снова до тех пор, пока что-то не изменится: статистика, настройки оптимизатора или какое-то внутреннее состояние СУБД.

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

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

Однако все эти методы или имеют мало предсказуемый результат (AQO), или требуют глубокого понимания причин возникшей проблемы с ручной донастройкой СУБД. В своей новой разработке мы решили взглянуть на проблему исправления ошибок оптимизации с другой стороны. Основная идея в том, чтобы добавить возможность перепланирования на основе полезных сведений, которые можно получить из уже частично выполненного запроса. Помимо этого нужно сформулировать критерии для плохо спланированных запросов, для которых необходимо провести перепланирование.

В 2017 году я начал изучать Java. И, чтобы как-то визуализировать результат трудов, я решил сделать десктопное приложение (функционал продублирован в Telegram боте).

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

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

Привет!

Пока мы разрабатывали продукты по кибербезопасности, на нас самих напали мошенники. 

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

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

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

Этим постом я запускаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В программе: рассказ об основах SQL, возможностях простых и сложных SELECT, анализ производительности запросов, разбор [не]эффективного применения индексов и особенностей работы транзакций и блокировок в этой СУБД.

Курс не претендует на лавры "войти в айти", поэтому подразумевает наличие у слушателя опыта программирования или работы с другими СУБД, и, главное, желания самостоятельно изучать тему работы с PostgreSQL глубже.

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

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

В последнее время нам почти каждый день рассказывают в новостях, какие очередные вершины покорили языковые нейросетки, и почему они уже через месяц совершенно точно оставят лично вас без работы. При этом мало кто понимает — а как вообще нейросети вроде ChatGPT работают внутри? Так вот, устраивайтесь поудобнее: в этой статье мы наконец объясним всё так, чтобы понял даже шестилетний гуманитарий!

Для пользователей explain.tensor.ru - нашего сервиса визуализации PostgreSQL-планов, мы создали плагин "Explain PostgreSQL" для всех IDE от JetBrains, теперь есть возможность форматировать запросы и анализировать планы непосредственно в IDE.

Как использовать плагин и детали о его разработке читайте ниже.

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

История начинается с несложной задачи и небольшого Python приложения.

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

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

В процессе своего повествования, постараюсь пояснить принятые мной решения, некоторые из которых прямо напрашиваются на решение иным способом.

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

Меня зовут Александр Пряхин, я TechUnit Lead в Авито. В IT работаю уже 14 лет. Из них 8 лет руковожу командами. Параллельно с этим преподаю и менторю. Сегодня разберём, как готовить демонов на PHP — от А до Я, и почему это актуально.