В интернете большое количество статей о сдаче экзамена ISTQB онлайн и достаточно подробно описана сама процедура - как подготовить рабочее место, поставить нужные плагины в Chrome, как следует и не следует общаться с проктором и так далее. В этой статье я хочу поделиться опытом сдачи экзамена on-site, то есть с выездом в конкретную локацию, а не дома.
Всем привет!
Это продолжение статьи о трансформации подхода к использованию ИИ — от базового применения к AI-Native.
В первой части мы разобрали уровни зрелости искусственного интеллекта, ключевые этапы ИИ-трансформации и классификацию приложений и модальностей LLM.
Во второй части:
От Software к Trustware: в процессе непрерывной технологической трансформации
AI-Powered Trustware Development Lifecycle
Риски безопасности AI-Native приложений
Процессы безопасной разработки — это не просто набор инструментов для проверки кода. Основная концепция в том, чтобы все процессы работали как единый механизм, а безопасность была не просто дополнением, а неотъемлемой частью разработки. Фреймворк Building Security in Maturity Model (BSIMM) предлагает смотреть на процессы безопасной разработки с точки зрения зрелости, как на измеримую систему действий и результатов, а не просто как на чек‑лист практик.
В этом году Synopsys не обделил нас новым отчетом и представил BSIMM 15, который мы с вами разберем. Не буду углубляться, что такое BSIMM и как его применять на практике, об этом вы можете прочесть в статье про BSIMM 14, но стоит отметить, что BSIMM дает ежегодную оценку применимости различных практик. На этом и сосредоточимся, посмотрим, какие появились новые активности и какие сейчас в тренде.
14 октября 2025 года вышла Joomla 6, а так же минорная версия Joomla 5.4. Что нового в этих релизах, какой релизный цикл, ресурсы для Joomla-разработчиков - в этой статье.
Картинка: TomoNews Sci & Tech, Gang65
- Дедушка, а ветрогенераторы с тремя лопастями бывают?
- Бывают, внучок, бывают...
- А, с двумя лопастями бывают?
- Бывают, внучок, бывают...
- Дедушка, а вообще без лопастей бывают?
- Нет, внучок, не бывают!
- А вот и нет, дедушка, бывают! :-D
Много различных генераторов — замечательных и не очень, и среди них особняком стоит одно устройство, потенциал которого, возможно, ещё не до конца осознан: ветрогенератор на эффекте Магнуса.
Многие компании реализуют GitOps-подход как часть внутренней Developers Platform. Он помогает унифицировать и автоматизировать доставку кода, повысить надёжность деплоя и дать разработчикам удобный интерфейс для работы с инфраструктурой. Один из самых популярных инструментов для этого — Argo CD.
Статья основана на воркшопе Егора Салиева и Николая Пушкарева, DevOps-инженеров Hilbert Team, проведённом на DevOps Conf 2025. В ней мы разберемся, как внедрить Argo CD и его ключевые компоненты, чтобы построить масштабируемую GitOps-платформу.
Материал будет в двух частях. Он будет полезен разработчикам и DevOps-инженерам, которые хотят понять, с чего начать внедрение GitOps в команде, организовать инфраструктуру под разные масштабы, а также всем, кто ищет способы унификации деплоя.
Работа с графикой невозможна без специальных инструментов — графических редакторов. Но что если ваш редактор вылетит прям во время работы из-за багов?
Давайте с помощью статического анализатора поищем потенциальные ошибки и странные места в исходном коде открытого проекта PixiEditor.
Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:
Uptrace v2.0 использует новый JSON-тип ClickHouse для хранения observability-данных. Результат: запросы по трейсам ускорились в 10 раз.
Делюсь практическим опытом внедрения: установка за 5 минут через Docker, настройка data transformations для обработки данных на лету, гибкие retention policies для экономии на хранении.
В статье:
Пошаговая инструкция от установки до production
Примеры кода на Node.js с OpenTelemetry
Кейсы настройки: снижение cardinality URL, парсинг данных, удаление PII
Чеклист для продакшена
Подходит для микросервисных архитектур на 5+ сервисов, где нужна скорость поиска по атрибутам трейсов.
Привет, Хабр. С гордостью, триумфом и трепетом хотим рассказать вам об одной из наших флагманских новинок, вышедшей в пылающем июле — книге «Экскурс в неопределённое поведение C++».
Cегодня книжные полки изобилуют нестареющими пособиями по C++. Этот язык чрезвычайно важен не только в разработке игр, финансового софта и встраиваемого ПО, но и как основной материал для изучения алгоритмов. Именно поэтому мы даже выпустили две книги-билингвы по алгоритмам, в которых код на C++ соседствует с идентичным ему кодом на Python. Это наш многолетний бестселлер «Алгоритмический тренинг. Решения практических задач на Python и C++» Максима Иванова и недавняя новинка «Базовые алгоритмы. Реализации на Python и C++ на примере классических игр» Павла Довгалюка. Но язык C++ не только очень полезен, но и опасен, так как на этапе преобразования исходного кода в машинный многие решения отдаются на откуп компилятору. Поскольку компилятор в большинстве режимов изначально заточен на оптимизацию кода, он регулярно привносит в код C++ непредсказуемые и порой необъяснимые варианты неопределённого поведения (UB, Undefined Behavior). Титаническую работу по систематизации неопределённого поведения в C++ проделал уважаемый Дмитрий Свиридкин @Nekrolm. В настоящее время он работает инженером по программированию встраиваемых систем в отделе Cloudfront Compute компании AWS. Дмитрий преподавал курсы по Linux и C++ в Санкт-Петербургском государственном университете и Высшей школе экономики, а также имеет богатейший послужной список, в котором есть и олимпиады по информатике, и машинное обучение, и программирование прошивок и, конечно же, выжимание последних капель производительности из самого неукротимого облачного железа. Некоторое время его заметки публиковались на сайте компании PVS-Studio, разрабатывающей известный российский статический анализатор кода. Далее под катом - предисловие Андрея Карпова, а также обзор самой книги.
Как все знают, GIL (Global Interpreter Lock) не позволяет нескольким потокам CPython выполнять CPU-bound задачи параллельно. Глобальная блокировка интерпретатора предоставляет каждому потоку лишь небольшой интервал времени для работы. При этом планирование работы потоков (какому именно потоку из ожидающих предоставить разрешение на выполнение) осуществляется планировщиком операционной системы. Интерпретатор не является полноценным планировщиком работы потоков, он делегирует эту функцию операционной системе. GIL использует мьютексы ОС для блокировки работы потоков так, чтобы в один момент времени мог выполняться только один поток из нескольких.
Фронтенд давно упёрся в потолок оптимизаций. Мы научились грамотно мемоизировать, батчить обновления, выносить тяжёлые вычисления в воркеры, но каждый раз упираемся в одну и ту же проблему: компоненты всё ещё перерисовываются чаще, чем нужно.
React стал символом этой модели. Благодаря Fiber и Concurrent Mode он действительно стал быстрее, но его архитектура по‑прежнему опирается на дерево компонентов и диффинг виртуального DOM. Даже с умным планировщиком React всё ещё «пересчитывает дерево», а не конкретные зависимости данных.
И вот на этом фоне появилась Signals — архитектура, которая предлагает другой путь.
Не оптимизировать старую модель, а избавиться от неё, сделав обновления атомарными и точечными. Без VDOM, ререндеров и догадок.
В этой статье мы разберём, чем «сигнальная реактивность» отличается от компонентной, и на реальных примерах из Solid.js и Angular Signals посмотрим, где именно проходит граница между «умным диффом» и «fine‑grained реактивностью».
Я разобрала историю Discord, потому что этот кейс хорошо иллюстрирует: во многих компаниях рост — результат серии экспериментов, из которых выстреливают не все. Главное — понимать, почему.
Сейчас Discord — вторая по популярности платформа для онлайн-образования с выручкой в 725 млн долларов и 656 млн зарегистрированных пользователей. А началось всё с неудачной игры.
Хочу показать, как они это сделали. Конкретные решения, цифры и результаты.
Привет! Меня зовут Евгений Бартенев, я техлид и автор курса «Python-разработчик» в Яндекс Практикуме. В профессии я уже больше 20 лет: прошёл путь от джуниора до эксперта по Python и видел, как меняется рынок и как вместе с ним меняются требования к разработчикам.
И за это время я заметил одну закономерность: часто после первых шагов в карьере люди словно упираются в потолок. Кажется, цель ясна: «стать мидлом, потом синьором» — но такой ориентир почти никогда не помогает двигаться вперёд. Дело в том, что должность — лишь формальный ярлык. Настоящий рост приходит через навыки, опыт и умение применять их на деле. Без понимания этой логики легко застрять на одном месте: работать много, но не двигаться в профессии.
В этом материале поделюсь подходами, которые помогут выйти из подобной ситуации. Я расскажу, что такое план профессионального развития, зачем он нужен и как его использовать для личного роста, на собеседованиях, в обучении и в реальной работе. Затем покажу пример карты навыков Python-разработчика, дам шаблон плана и конкретные рекомендации, что делать, если вы действительно нацелены на движение вперёд и хотите вырасти до уровня эксперта.
Привет, Хаброжители! Книга предназначена для всех, кто хочет погрузиться в эффективную кроссплатформенную разработку с Flutter. Вы не только изучите синтаксис языка Dart и основы фреймворка, но и сразу примените знания на практике, разрабатывая проект, который развивается на протяжении всей книги. После каждой новой темы вас ждут задания по доработке его кодовой базы, что позволит уверенно прокачать свои hard-скиллы.
Всем привет! Меня зовут Михаил, я веду Telegram-канал «Python Шпильки», где делюсь изящными приемами программирования. Сегодня я хочу рассказать об универсальном декораторе, который может принимать аргументы, а также вызываться без их приема. Для тех кто хорошо знает тему декораторов - ничего нового они тут не увидят! Этот пост для тех, кто, возможно, хочет более подробно понять тему декоратора. Итак, поехали.
Для начала приведу пример конструкции универсального декоратора:
Не кажется ли вам, что ИИ снизил ценность операционных знаний, типа «как сделать ту или иную вещь на том или ином языке программирования», но повысил ценность архитектурного мышления и умения правильно декомпозировать код, то есть делить его на модули. Принципы этого деления никак не изменились с 70-х годов. Но теперь им нужно следовать куда как более тщательно, иначе ИИ создаст настолько плохо структурированный код, что распутать человеческими мозгами будет невозможно.
Под катом принципы декомпозиции (с обобщёнными примерами) и история этих принципов
Про OPC UA слышали мы все, кто хоть раз работал со SCADA системами, АСУ ТП или просто в студенческие годы пытался состыковать оборудование и программы верхнего уровня.
Обещают независимый, безопасный, масштабируемый, al inclusive стандарт для промышленного Интернета вещей. Но как это работает в реальных условиях? Что происходит, когда ты ставишь OPC UA-сервер не в демо-лаборатории, а в реальных условиях на производстве, где есть полный набор динозавров из 90х, 00х и современные монстры. И мы хотим, чтобы работало, не тормозило и все вместе.
В этой статье я попробую рассказать, как мы внедряли OPC UA в нескольких проектах, на практике, в реальных условиях со всеми плюсами и минусами.
Всем привет! Меня зовут Даша, я python-разработчик в команде Big Data «Группы Лента» (Lenta tech). За свой восьмилетний опыт работы я успела поучаствовать в большом количестве проектов. Инструменты и фреймворки менялись, но оставалось одно — Kafka. Сначала этот инструмент использовался с опаской и на небольших проектах, а сейчас стал стандартом при проектировании любых систем.
Я собрала набор практических приемов, которые помогают настраивать её быстро и без лишних сложностей. В статье делюсь своими «рецептами», которые не всегда можно найти в документации или «нагуглить».
Одна из открытых пока задач в области баз данных - поддержание базы данных в консистентном состоянии одновременно на нескольких экземплярах СУБД (узлах), принимающих клиентские соединения независимо друг от друга. Суть проблемы заключается не в том, чтобы синхронизировать состояние удалённо по сети, а в том, что в случае отказа одного из узлов такой системы остальные должны продолжить свою работу без перерыва: принимать соединения, коммитить транзакции не потеряв при этом консистентность. Аналогией для случая одного экземпляра СУБД здесь может быть, к примеру, обеспечение работы при отказе планки оперативной памяти или прерывающемся доступе к нескольким ядрам процессора.
Здесь я хочу возобновить обсуждение проблемы мультимастера на базе Postgres: его практическую ценность, реализуемость, стэк технологий, которые нужно создать. Возможно, что поставив проблему более узко, мы сможем прийти к решению, которое будет полезно для отрасли...
