Недавно на работе передо мной возникла задача максимально быстро погрузиться в автоматизированное тестирование с ранее мной не использовавшимся фреймворком pytest. Почитав порядка десяти статей на Хабре я понял, что в каждой из статей есть много всего интересного, а чтобы системно погрузиться — необходимо идти читать документацию. Я решил, в привычной мне манере, разобраться и систематизировать самый сок для того, чтобы быстро въехать в суть и важные тонкости положив основу для дальнейшего использования. 

Всем интересующимся — добро пожаловать под кат!

В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.

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

Прошу не ругаться, это моя первая статья.

Итак, далёким летом 2021 года я решил обновить свой основной рабочий лэптоп, потому что мой старый был куплен в 2012 году и уже еле‑еле справлялся с теми нагрузками и задачами, что я на него возлагал.

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

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

Критерии были такие:

Привет, Хабр!

Сегодня с вами Дмитрий Ларин, руководитель продуктового направления по защите баз данных и Александр Хребтов, аналитик группы компаний «Гарда», и мы поговорим о способах защиты баз данных. После 2022 года многие российские компании оказались в ситуации, когда привычные инструменты управления базами данных стали недоступны. Миграция на отечественные СУБД обострила вопрос: как защитить критические данные в условиях, когда стандартные средства больше не работают?

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

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

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

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

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

Команда Python for Devs подготовила перевод статьи о скрытых издержках использования старых версий Python. TL;DR: 83% разработчиков застряли на Python 3.10–3.11, и это обходится компаниям в миллионы долларов ежегодно из-за лишних "облачных" затрат. А ведь казалось бы, обновиться — проще простого.

Современные системы состоят из множества различных сервисов и одной из основных задач является обеспечение обмена данными между компонентами системы. Для обеспечения этой функциональности используются шины данных (Enterprise Service Bus, ESB), интегрирующие различные приложения и системы в единую информационную среду. Она выступает в роли «посредника», минимизируя прямые связи между отдельными системами и обеспечивая гибкость взаимодействия. Таким образом, основная цель внедрения ESB — оптимизировать и унифицировать взаимодействие внутри информационного ландшафта предприятия.

Занимаясь проектированием систем ПО, идите самым простым путём из возможных.

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

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

Каждая компания двигается по шкале от незрелой к зрелой и обратно. Это всегда динамика. Сегодня вы образец, завтра вы устаревшая помойка. Если 10 лет назад для наведения порядка внедрялся какой-нибудь "каскадо-водопадный PMI", 5 лет назад гибко-адаптивный Agile-OKR, то сейчас есть динамика к культуре проведения экспериментов*.

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

*Статья состоит из двух блоков - критика и предложение. Контекст: продуктовая ИТ компания среднего уровня, не стартап и не из ТОП 50.

Команда Python for Devs подготовила перевод статьи о том, почему любимая оптимизация Python — присваивать глобальные функции локальным переменным — больше не даёт выигрыша. CPython 3.11 стал умнее, и старый хак l = len уже почти бессмыслен.

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

В статье посмотрим как WASM-модули взаимодействуют с Python хостом. (Спойлер - не все так просто как хотелось, поддержка WASM в Python экосистеме пока слабая)

Рассмотрим, как может выглядеть работа по созданию ТЗ на несложную программу.

Возьмём калькулятор, который будет выполнять базовые арифметические операции (+, -, *, /).

Работу можно построить в 2 этапа:

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

Регулярки освоить нетрудно. Буквально за пару часов можно получить почти средний уровень владения и научиться читать и писать выражения для поиска ip-адресов, e-mail, html-тегов, телефонных номеров, дат и прочих несложных конструкций. Я думаю, все это вам знакомо, но на всякий случай в конце статьи я добавил несколько ссылок для изучения.

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

Всем привет! На связи Дмитрий Неверов, руководитель направления тестирования на проникновение в Бастионе. Мы профессионально ломаем системы безопасности компаний. Разумеется, с разрешения их владельцев. Расскажу кейс, за который я получил ачивку «Фаворит года по версии жюри» Pentest Awards 2025.

Представьте: крупная инфраструктурная компания с регулярными пентестами, серьезным бюджетом на ИБ и жесткими регуляторными требованиями. Казалось бы, что тут можно сломать? А мы взяли и получили права доменного администратора, начав путь с непривилегированной учетки сотрудника. И никаких бэкдоров или zero-day, только чистая работа с Active Directory.

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

Наши родители не могли о таком и мечтать! 

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

Заплатив за это всего 10-15 ₽ за минуту. Но…

Так было, пока не упала маржинальность бизнеса на аренде авто. Выросла ключевая ставка, а цены на новые машины подскочили в 2 раза. 

Сегодня вместе с машиной ты можешь получить штраф от 20 000 ₽ до нескольких миллионов рублей.

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

Меня зовут Кирилл Курдюков, в 2024 году я выступил в Питере на Joker — конференции для Java-разработчиков — с историей о том, как мы с командой делаем СУБД Яндекса удобной для джавистов.

Под катом статья, написанная по мотивам доклада. Это история о том, как маленькими шагами пройти путь от нативного клиента на Java до поддержки Hibernate, Liquibase, jOOQ и других популярных в мире Java-разработки решений.

Я встречал много людей, которым не нравится их работа. И когда я их спрашиваю, чем бы они занимались вместо, около 75% из них отвечают что‑то вроде: «Хммм, не знаю. Я бы хотел открыть свою небольшую кофейню!» Если в тот день я в хорошем настроении, я задаю им встречный вопрос: «Тогда где бы ты взял кофейные зерна?»

Если они не знают что ответить, то я задаю ещё пару наводящих вопросов:

«Психологизация»

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

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

Недавно я прочёл книгу «Паттерны разработки на Python TDD, DDD и событийно-ориентированная архитектура». Основной акцент в ней сделан на том, как именно нужно структурировать программы, чтобы они по мере роста оставались простыми и удобными в поддержке. Это моя любимая тема из области программирования, поэтому, конечно же, книга мне понравилась. Пожалуй, я не возьмусь использовать именно те приёмы, которые авторы рекомендуют в книге — но они обсуждают классные идеи, напомнившие мне о задачах, встречавшихся в моей практике на предыдущих работах. Кроме того, отмечу, что английская версия книги есть в свободном доступе онлайн, так какие вообще вопросы?

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