Найти в Дзене
Cloudflare и падение 18 ноября. Какие выводы можем сделать?
Во вторник 18 ноября многие из наших любимых сервисов перестали работать. Причиной всему было падение Cloudflare, и об этом они кстати написали достаточно добротный отчет. Однако нас как QA-инженеров (и не только) интересует не столько сам факт падения, сколько выводы, которые мы можем из него сделать: 1. Без нормального observability никуда. Что делали в Cloudflare? Вместо починки бага - отражали несуществующую DDoS-атаку. Казалось бы, перепутать реальный баг и атаку сложно. Но когда метрики и алерты настроены так, что вводят в заблуждение, именно такие ошибки совершаются снова и снова...
4 месяца назад
Избегай ООП в Python
Многие, особенно начинающие инженеры, считают объектно-ориентированное программирование «серебряной пулей», которая решает все архитектурные проблемы, но это лишь инструмент.Да и в Python он далеко не всегда уместен. - Лишние абстракции — хочешь усложнить простую вещь? Оберни её в класс. - Скрытая логика — за каскадом абстракций легко потерять что-то важное. - Многословность — Python ценят за лаконичность, а классы часто её убивают. - Производительность — добавление классов несёт накладные расходы...
7 месяцев назад
«Программировать больше не нужно — всё сделает ИИ, надо только правильно написать промпт
«Программировать больше не нужно — всё сделает ИИ, надо только правильно написать промпт». На мой взгляд, это опасная иллюзия. Вот почему. 1. Даже по исследованиям, QA — далеко не в топе профессий, которые ИИ заменит первыми. Автоматизация затронет их, но полностью заменить — вряд ли. Аналогично и с программистами, хоть они и попали в ТОП-40 наиболее подверженных влиянию профессий. 2. Промптинг ≠ магия. Чтобы написать хороший промпт, нужно знать предметную область. Принцип «какое ТЗ — такое ХЗ» выходит на новый уровень. 3. Контроль качества никто не отменял. AI может выдать результат, полный...
7 месяцев назад
Год назад я писал, что ИИ нас в ближайшее время не заменит
Год назад я писал, что ИИ нас в ближайшее время не заменит. Давайте посмотрим, что изменилось за это время — и куда всё движется. 📊 Свежие данные: - В июле 2025 года исследования показали: QA по-прежнему не спешат доверять ИИ. - При этом AI уже активно трансформирует индустрию тестирования. - Не первый раз натыкаюсь, что спрос на QA и SDET растет быстрее, чем спрос на разработчиков. Попробую найти какое-то исследование на этот счет. - До 2035 года прогнозируют пусть скромный, но рост рынка автоматизации тестирования примерно на 8%. 💡 Выводы: 1. ИИ в тестировании — не мимолётный хайп, а долгосрочный инструмент...
7 месяцев назад
В продолжение мысли из прошлой статьи про «лучшее — враг хорошего», но с чуть другого угла
В продолжение мысли из прошлой статьи про «лучшее — враг хорошего», но с чуть другого угла. Недавно наткнулся на заметку, где автор жалуется на неудобство стандартных ассерт-функций в Go. В итоге большинство разработчиков тащат в зависимости testify. Казалось бы — мелочь: подключил и забыл. Но это лишняя зависимость, на которую ты не влияешь. Хотя тот же assert можно накидать за пару минут. И вот тут начинается интересное. Я уже говорил на митапе в Иннополисе про то, что лишние абстракции и зависимости часто вредят, хотя в моменте решение кажется удобным. Причины простые: 📌 Нет контроля над кодом → зависимость может тянуть за собой десятки других пакетов...
7 месяцев назад
Недавно у меня выдалось пару дней, чтобы спокойно поразмышлять
Недавно у меня выдалось пару дней, чтобы спокойно поразмышлять. И я вспомнил про этот канал, который почти год был в спячке. Почему перестал писать? Из объективных причин осталась только одна: материалы казались «недостаточно хорошими». Всё остальное — отговорки: «нет времени», «нет тем» и т.д. Классическая прокрастинация: вместо того чтобы делать, мы ищем идеальные инструменты, подходы и решения. В работе с этим перфекционизмом я худо-бедно научился бороться. С блогом — ещё нет. Но есть три приёма, которые помогают в рабочих задачах: 1️⃣ Хоть какой-то результат лучше, чем ноль Бизнесу чаще важен факт выполнения задачи, а не архитектурная изысканность кода...
7 месяцев назад
Дата релиза Python 3.13 все ближе. Осталось буквально несколько дней. Основная причина, по которой многие так ждут эту версию - это возможность отключать GIL. Сообщество уже давно просило добавить такую возможность. Конечно, у нас есть другие интерпретаторы Python без GIL - это и Jython, и различные библиотеки, которые помогают обходить ограничения GIL, ибо они написаны на С++ или Rust (тот же numpy), еще есть multiprocessing (возможность делать параллельные вычисления за счет процессов, а не потоков). Однако, иметь возможность отключить GIL в стандартной реализации Python (CPython) очень важно, ведь это, помимо всего прочего, может ускорить развитие языка и расширение сферы его применения. И вот казалось бы, нас ждет новый дивный мир, где параллельные вычисления выйдут на новый уровень, и больше не потребуется писать библиотеки для Python на более низкоуровневых языках, чтобы обойти все ограничения. Но в этом столь ожидаемом релизе Python есть ложка дегтя, и не одна: 1️⃣ По умолчанию мы все еще будем использовать GIL. В 3.13 у нас появится возможность его отключить, но мы будем это делать на свой страх и риск. Уже было написано много кода, который не будет корректно работать с отключенной глобальной блокировкой интерпретатора. Пройдут годы, прежде чем большинство самых популярных библиотек начнут поддерживать эту возможность. Например, такая известная библиотека, как anyIO, под капотом использует threading, что говорит нам о том, что большинство популярных фреймворков, тот же FastAPI, не смогут корректно работать с отключенным GIL 2️⃣ Та версия Python, которая по умолчанию будет работать без GIL- это далеко не третий Python. Многие из тех, кто вовлечен в разработку этого языка, называют сроки подобных изменений - от 5 лет и больше. Также разработчики говорят, что не получится сделать GIL отключенным по умолчанию, не сломав обратную совместимость. Из чего можно сделать вывод, что Python окончательно избавится от GIL если только к 4 версии (если она когда-нибудь появится). 3️⃣ Python любят за то, что он достаточно простой и лаконичный. Удаление GIL неминуемо усложнит код. 4️⃣ На предрелизных сборках, один и тот же код с включенным и отключенным GIL показывал совершенно противоречивые результаты. Если в версиях программы с мультитредингом мы видели выигрыш в производительности, то синглтред версии программы становились медленнее. Надеюсь, что в релизной версии это будет исправлено. Если все так плохо, зачем оно нам? Не стоит отчаиваться: ➖ Это очень крупные изменения, эффект от которых мы увидим только через 3-5 лет. Можно рассмотреть их как шанс поучаствовать в разработке open-source проектов, ибо кто-то же должен добавлять поддержку столь желаемой фичи во все библиотеки. ➖ В долгосрочной перспективе в выигрыше окажутся разработчики, которые делают back-end на том же FastAPI, который может стать еще быстрее. ➖ Удаление GIL также откроет кучу возможностей для разработчиков ИИ (в теории), т.к. это позволит отказаться от вспомогательных языков, таких как C++ и Rust, которые используются для написания столь необходимых библиотек, ускоряющих ввод-вывод и обучение моделей. А что такое GIL и зачем он нам нужен, расскажу позже, уже после релиза долгожданной многими версии 😊
1 год назад