Компания PVS-Studio и платформа Hexway заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Hexway VamPy — это решение, агрегирующее данные о безопасности из разных источников для работы с уязвимостями.
В Hexway стало возможным загрузить результаты анализа PVS-Studio в виде отчёта и работать с конкретными ошибками так же, как это позволяют другие инструменты. Загрузка возможна двумя способами: через пользовательский интерфейс или командную строку с использованием CLI-инструментов.
Подробнее о том, как загрузить результаты анализа PVS-Studio в Hexway VamPy можно прочитать в соответствующем разделе нашей документации.
В видео я показываю несколько возможных оптимизаций вашего рабочего процесса. Станет удобнее и проще использовать ваш основной инструмент для работы.
Раз. Убираем Activity Bar. В нем есть три типа иконок: нужные нам часто, нужные иногда, совсем ненужные. Логика такая: для нужных мы создаем горячие клавиши (или пользуемся существующими). Для средне-нужных используем cmd+p и выбор команды. Ненужными – не пользуемся :)
Кастомные настройки для горячих клавиш для управления разными View (плюс к стандратным):
Два. Убираем Side Bar. Большую часть времени он не нужен. В основном нам просто нужно читать и реже писать код. Зачем нам Side Bar? Убирается основной по cmd+b, а второй по cmd+alt+b.
Но если оставить Side Bar справа, то его появление / скрытие будет двигать код. Что будет мешать. Потому – убираем его вправо.
Три. И не забудьте поместить Command Palette в центр рабочей области. Так будет удобнее: появяться она будет сразу перед глазами. Просто перетаскиваем мышкой.
Это самые умные модели, которые вы можете запустить у себя дома — маленькая gpt-oss-20b летает на домашнем ПК. А ещё это первый релиз в опенсорс от OpenAI за 6 лет — последний раз они так выпускали GPT-2.
gpt-oss доступна в двух версиях: с 20 млрд и 120 млрд параметров. Для первой для работы требуется минимум 16 ГБ видеопамяти, а для второй — 80 ГБ.
TypeScript и C++ в одном бинаре. Первый open source-проект от МойОфис
Команда МойОфис выложила в open source собственную разработку — компилятор tsnative. Это кроссплатформенный инструмент, который объединяет удобство TypeScript с производительностью C++ в одном приложении. Исходники — на GitHub под лицензией Apache 2.0.
Компилятор tsnative — это первая и ключевая часть более масштабного проекта под названием AntiQ, в котором мы переосмысляем подход к кроссплатформенной разработке без тяжёлых фреймворков.
AntiQ разделен на два самостоятельных компонента. Сейчас в open source опубликован только tsnative — главный модуль, в котором сосредоточена основная логика и заложены архитектурные принципы всей платформы.
Зачем это нужно?
tsnative — это кроссплатформенный компилятор, преобразующий TypeScript в нативный машинный код. Он обеспечивает бесшовную интеграцию с C++ без glue-кода или JavaScript-движков, объединяя удобство высокоуровневой разработки с производительностью системного кода. В результате вы получаете один бинарник, собранный из двух языков.
Как это работает:
C++-функции помечаются TS_EXPORT;
генерируются .d.ts-декларации для TS;
TypeScript- и C++-код собираются через LLVM;
на выходе — один исполняемый файл, без обёрток.
// math.cpp
#include "TS.h"
TS_EXPORT int add(int a, int b) {
return a + b;
}
// index.ts
console.log(add(2, 3)); // -> 5
// index.ts
console.log(add(2, 3)); // -> 5
Проект может быть интересен тем, кто:
делает нативные приложения, но хочет писать часть логики на TS;
ищет замену закрытым коммерческим компиляторам;
любит ковыряться в сборке, кросс-компиляции и низкоуровневом коде.
Открытый код — не просто «выложили и забыли». Мы хотим, чтобы проектом пользовались, коммитили, обсуждали. Поэтому будем рады pull request’ам, issue и звёздочкам. Всё как обычно :)
Для ЛЛ: перечислены способы мотивации сотрудников, которые вам могут показаться банальными
Недавно на работе разгорелся жаркий спор. Двое наших разработчиков сцепились из-за выбора библиотеки для работы с датами в монорепе на js. Один был фанатом Luxon, утверждая, что она идеально подходит для сложных задач с датами и временем. Второй клялся, что Date-fns – в это лучший выбор, потому что она лёгкая, быстрая и позволяет использовать только нужные функции, не раздувая проект.
Ну не суть. Я сидел рядом и наблюдал за этим словесным баттлом. Проект уже грозил загнуться, не начавшись.
Понимая, что бесконечные дебаты ни к чему не приведут, я решил вмешаться. Первое, что необходимо сделать в таких ситуациях – выслушать всех причастных. Я дал каждому возможность высказаться, кивая и делая вид, что записываю их аргументы в блокнот. В голове я уже прикидывал, как не дать спору остановить работу.
Разрешение конфликта
Чтобы выйти из тупика, я предложил компромисс: «Ребята, давайте так. Каждый из вас реализует свою часть проекта с использованием своей библиотеки. На проверку идей у вас 2 дня, потом сравним, что получилось». Они согласились, и весь накал спора тут же утих – оба погрузились в работу, стремясь доказать, что их выбор лучший.
В итоге мы остановились на одной из либ, но не это важно. Главное, что разрешился конфликт между двумя сотрудниками на почве выбора технологий. А часто бывает и по-другому, что никто не хочет уступать и каждый топит за свой алгоритм/либу в проекте.
В таких случаях я обычно:
Развожу спорщиков по разным проектам
Или принимаю сам решение какую технологию использовать далее
В обоих случаях после конфликта может упасть мотивация, могут затаиться обиды и т.д.
Мотивация-шмотивация
Несмотря на подзаголовок, я приведу реально применённые способы поднятия мотивации разработчиков:
Деньги-деньги, решают многое. Сюда же незапланированные премии.
Повышение должности сотрудника (иногда даже без повышения зарплаты, не везде корректно настроены грейды). Был «разработчик», стал «Ведущий разработчик», потом «Старший разработчик» и т.д.
Обновляешь ноутбук работнику. Иногда для сотрудника это долгожданное обновление, и это очень повышает его мотивацию и лояльность к компании (ну или к тому, кто её выбил).
Про лишние дни отдыха тоже понятно.
Оплата билетов на конференции по IT-тематике (а они не всем по карману сейчас), покупка лицензий на удобный софт.
Признание заслуг в разработке проекта перед вышестоящим начальством и текущей командой. Хотя это должно быть по умолчанию в команде.
Этих пунктов может быть ещё очень много, везде индивидуально.
Конфликты между коллегами в команде – это не трагедия, а возможность для экспериментов и роста. Выслушать каждого, дать шанс доказать свою точку зрения на практике и подкрепить это мотивацией – именно так конфликт становится точкой роста.
Если есть чем поделиться, как вас мотивировали - прошу в комментарии.
Gemini 2.5 Deep Think получила первую официальную золотую медаль IMO среди AI-систем
20 июля 2025 года Google DeepMind совершила прорыв: их модель Gemini 2.5 в режиме Deep Think стала первой AI-системой, официально получившей золотую медаль на Международной математической олимпиаде (IMO). Разбираемся, что это значит для развития искусственного интеллекта и когда технология станет доступна разработчикам.
Что произошло на IMO 2025?
Gemini 2.5 Deep Think набрала 35 из 42 возможных баллов, решив 5 из 6 олимпиадных задач за отведённые 4,5 часа. Главная особенность — все решения проходили на естественном языке без формальных переводов в системы вроде Lean или Coq.
Это кардинально отличается от предыдущих попыток. Например, AlphaGeometry от Google в 2024 году достигла только серебряного уровня в геометрических задачах, при этом тратила дни на решение одной задачи и требовала мощных вычислительных кластеров.
Важно: OpenAI заявляла о золотом уровне для своих моделей o1/o3, но официального признания от комитета IMO они не получали.
Архитектура Deep Think: мульти-агентное мышление
Технологический прорыв Deep Think заключается в нескольких ключевых инновациях:
1. Множественные потоки рассуждений
Модель запускает несколько параллельных "агентов", каждый из которых исследует свой путь решения. Затем результаты объединяются для финального анализа — подход, схожий с Grok 4 Heavy от xAI.
2. Увеличенное время на размышления
В отличие от обычных языковых моделей, Deep Think намеренно замедляет генерацию ответа, позволяя внутренним процессам глубже проанализировать проблему.
3. Специализированное обучение с подкреплением
Применяются алгоритмы RL, которые поощряют не только правильность решений, но и чёткость доказательств и качество формулировок.
Доступность и ценообразование
Здесь начинаются проблемы. Google выпустила две версии Deep Think:
IMO Gold версия — доступна только избранным математикам и исследователям
Bronze версия — публично доступна через подписку Google AI Ultra
Стоимость Bronze версии:
$124.99/мес первые 3 месяца
$249.99/мес в дальнейшем
Включает: Deep Think, Veo 3 (генерация видео), 30 ТБ хранилища
Ограничения Bronze версии:
Время ответа: 30-60 секунд на сложные запросы
Ограниченное количество запросов в день
Упрощённые возможности по сравнению с IMO-версией
Критический взгляд: стоит ли овчинка выделки?
Реакция комьюнити неоднозначная. Основные претензии:
Неоправданно высокая цена: многие пользователи отмечают, что подписка Ultra даёт те же квоты API, что и бесплатный аккаунт
Медленная работа: 30-60 секунд ожидания не подходят для продуктивной работы
Неясные перспективы: Google не сообщает, когда IMO-версия станет доступна публично
Значение для индустрии
Успех Deep Think на IMO знаменует переход от "умных автодополнений" к системам, способным к настоящему рассуждению. Это открывает новые возможности:
Научные исследования: помощь в доказательстве теорем и решении сложных задач
Инженерия: анализ комплексных технических проблем
Образование: персонализированное обучение математике и логике
Что дальше?
Google обещает API-доступ к Deep Think "в ближайшие недели", но пока только для "доверенных партнёров". Полноценная IMO-версия может остаться исследовательским инструментом надолго.
Для разработчиков это означает ожидание: пока что Deep Think — это скорее демонстрация возможностей, чем готовый продукт для интеграции.
Выводы
Gemini 2.5 Deep Think действительно совершила исторический прорыв, став первой AI-системой с официальной золотой медалью IMO. Однако коммерческая реализация пока разочаровывает: высокие цены, ограниченный функционал и неясные перспективы развития.
Если вам нужна скорость и код — оставайтесь с GPT-4, Claude или o1. Если же готовы платить за глубокие рассуждения и не спешите — Deep Think может стать интересным инструментом.
Привет! Мы на Хабр Карьере собираем сотни онлайн-курсов в IT или digital на маркетплейсе курсов и каждую неделю делаем подборки обучений для тех, кто хочет учиться какой-то специализации с нуля или для тех, кто уже в профессии, но чувствует, что хочет прокачать навыки.
Собрали подборку для тех, кто хочет перейти во фронтенд. Вообще все курсы по специализации можно посмотреть здесь, а ниже оставляем ссылки по ключевым навыкам:
Язык для добавления интерактивности на веб-страницах. Используется в браузере и на сервере (через Node.js), лежит в основе большинства фронтенд-фреймворков.
В двух, приложенных к этому посту файлах (здесь и здесь), показан код для решения одной и той же задачи в мобильном приложении. А именно: запустить обратный отсчёт перед началом игры.
В одном файле эта задача реализована в архитектуре BPN (Business Process Notation), о которой рассказывал раньше здесь. А во втором файле тот же код организован по архитектуре MVVM.
Код и в том, и в другом файле написан с помощью Claude Sonnet. В случае с BPN структурировал код вручную, следуя бизнес-процессам. А во втором случае попросил Клода сделать рефакторинг, используя традиционный современный подход и он выбрал MVVM.
Что можно сказать в итоге, сравнивая архитектуру в том, и другом случае.
Объём кода
В BPN варианте 270 строки кода с комментариями, в MVVM - 524.
Т.е., в MVVM случае кода практически в 2 раза больше.
MVVM - вью и модель, анимация и аудио как сервисы, роутер, отдельная структура для хранения значений свойств и т.д.
Что лучше
Как всегда, каждый из подходов имеет свои плюсы и минусы.
В BPN нравится, что можно видеть модель процесса, в данном случае модель одной из задач приложения.
Что такое “Модель”
Наиболее традиционны 2 понимания термина “модель”.
В одном случае, это структура данных, модель объекта.
Например:
struct Person {
let firstName: String
let lastName: String
var age: Int
}
В другом случае, под моделью понимается всё, что не относится к интерфейсу.
Но есть и третье понимание модели - это модель приложения, или модель отдельных процессов внутри приложения. Т.е., составные части приложения (процесса) и их последовательность.
В BPN файле такая модель проступает наглядно:
Модель процесса "Обратный отсчет"
Здесь Обратный отсчёт складывается из таких блоков как подготовка, собственно выполнение, анимация, звук и закрытие экрана. Внутри каждого этапа видны его составляющие - методы и необходимые свойства.
В файале MVVM блоков кода гораздо больше и нужно несколько раз проскоролить чтобы увидеть их в выпадающем меню. И увидеть целостную модель здесь сложнее.
Conclusion
На относительно небольших проектах архитектура MVVM может быть избыточна. Здесь могут использоваться более простые варианты.
BPN позволяет видеть целостную модель задачи (процесса, приложения).
Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.
Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.
Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.
Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.
Язык Go называют одним из самых удобных для бэкенда. Дело тут не в примитивности: его специально стремились сделать простым и лаконичным, чтобы пользователям было легко работать с синтаксисом и понимать чужой код.
Если вы уже знакомы с Go, но не хватает практики, приглашаем пройти новый курс в Академии Selectel. С ним вы научитесь писать простые сервисы на Go и использовать его в некоторых рабочих задачах, а еще получите большую подборку ресурсов для погружения в этот язык.
Обновлена информационная база JBook по изучению Java полностью на русском языке. Проект помогает выучить язык с полного нуля и до уровня поиска работы, включая концепции, приёмы, актуальные фреймворки, ООП, основные алгоритмы, паттерны решения задач и видеоразборы. Есть множество упражнений разного уровня сложности к каждой лекции. Проект развивается с 2018 года и постоянно обновляется вместе с версиями Java, документацией и новыми подходами к разработке.
Ранее в Amvera Cloud, были возможны откаты только путём новой сборки из нужного коммита в Git-репозитории. Помимо этого, использовалась медленная технология сборки.
Мы ускорили сборки до 10 раз и сделали возможность быстрого отката к предыдущим версиям!
Стало легче откатывать приложение, в случае ошибок.
Подключить быстрые сборки можно в разделе проекта «Контроль версий».
Интерфейс управления версиями сборок
Новые сборки
Быстрее старых до 10 раз.
Позволяют откатываться к предыдущим версиям одной кнопкой. Это полезно, если вы случайно накатили баг и надо вернуться к прошлой версии.
Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе), бесплатными https-доменами, мониторингом работы приложений, встроенным проксированием до ведущих LLM и собственным инференсом LLaMA.
Вам не нужно думать о настройке инфраструктуры. Git push amvera master и ваш проект запущен. Зарегистрируйтесь и получите 111 рублей на тест.
Мне на LeetCode постоянно LeetCode point-ы добавляют. У кого-нибудь есть реальный пример полезного применения этих points? У меня их 26 штук уже. Делать пока с ними ничего невозможно. А что реально полезного от них можно получить? Можно ли RMT-ить их? У кого получалось
Использование случайностей в функциональном тестировании
Для кого эта статья?
Инженеры по автоматизации и разработчики тестов — вам точно будет интересно.
Обычные разработчики, если вы заинтересованы в качестве продукта, а не считаете тесты "расплатой за грехи" или "прихотью менеджмента" — тоже.
А кого, возможно, не заинтересует
Если у вас постоянно есть падающие тесты, и никто не разбирается в причинах, а просто смотрят на процент "зелёных" и "красных", — эта статья может показаться бесполезной.
Откуда вообще эта идея?
Возможно, вы сталкивались с ситуацией, когда один и тот же тест гоняется с разными входными данными. Типичный data-driven подход: параметризуем, и всё работает.
На первый взгляд — всё логично. Но на практике:
увеличивается время прогона (особенно для UI-тестов);
растёт вероятность нестабильности (flaky-тесты);
тесты зачастую дублируют поведение друг друга.
Наглядный пример
Допустим, у нас есть UI-тест, проверяющий переходы по меню на сайте. Стартовая страница содержит меню для перехода на страницы A, B, C, D.
Сценарий теста:
Открываем стартовую страницу.
Выбираем пункт в меню.
Проверяем, что оказались на нужной странице.
Что делает большинство:
Пишут четыре теста: переход на A, на B, на C и на D.
Или параметризуют тест: гоняют один и тот же сценарий с разными входными.
Но по сути, мы проверяем одну и ту же функциональность перехода по меню. Зачем гонять одни и те же шаги с разными данными?
Проблема
Если тест проверяет функциональность, то логично оставить один вариант— переход на страницу A. Экономите ресурсы, всё стабильно и функциональность проверяется. Но однажды приходит тимлид с вопросом:
Почему тесты не поймали баг с переходом на страницу D?
В этом случае экономия не оправдалась
Что делать?
Тест — это тоже код. Он может быть не стабильным. И чем чаще он запускается, тем быстрее мы понимаем, стабилен он или нет.
А теперь возвращаемся к примеру с меню:
Что, если каждый раз случайным образом выбирать один из пунктов (A, B, C, D)?
Экономим ресурсы: запускается один тест вместо четырёх.
С течением времени мы случайным образом "покроем" все пункты.
Чем чаще прогоняются тесты, тем быстрее мы обнаружим баг (например, если страница C не открывается).
Это не универсальное решение, но в ряде случаев — вполне разумный компромисс между экономией и эффективностью.
Это не ноу-хау
Такой подход давно известен — он называется property-based testing.
Как пример - фреймворк Hypothesis, который позволяет генерировать данные автоматически и находить пограничные случаи, о которых вы даже не думали.
Что важно помнить
Использование случайности не должно усложнять тест. Логика должна быть понятна и читаема.
Если тест упал, он должен сообщить, что именно пошло не так, даже если данные были сгенерированы случайно.
Рандомизация — всего лишь один из способов сделать тесты более эффективными, но это не универсальное решение
Иногда стоит логировать/фиксировать сгенерированные данные, особенно при падении теста — чтобы потом воспроизвести баг
Итог
Рандомизация в тестировании — мощный инструмент:
помогает экономить ресурсы;
расширяет покрытие;
стимулирует стабильность и надёжность тестов.
Но применять её стоит с умом: понимать, зачем, где, и в каком объёме.
А как у вас это устроено? Используете ли вы property-based подход в тестах? Или всё ещё параметризуете всё подряд? Буду рад услышать ваши мнения, кейсы и даже критику.
Q1: Если сейчас есть задача по-быстрому сбацать что то с формами под винду - какая есть альтернатива дельфи?
Q2: А если так же быстро накидать, только кроссплатформенное приложение и без зависимостей?
И мой ответ
A: Не находишь, что 3000$ за кроссплатформенный дизайнер форм слишком дорого? Даже за хороший.
Собственно, порылся в памяти и в википедии, проверил что там еще живое и набросал списочек визуальных дизайнеров для Linux - приложеньиц. По названию язык программирования и фреймворк легко идентифицируется.
Все может использоваться бесплатно и без особых претензий на функциональность. Единственное, иногда бывает нужно еще нарисовать какой то чарт/график и загрузить/записать данные в БД/XML/JSON - с этим могут быть нюансы с конкретным вариантом.
С чем то я работал, с чем то нет, актуальные версии вживую не проверял.
GNOME Builder (ex.Anjuta). GTK multilang IDE
Cambalache (ex.Glade) - GTK form builder
Qt Creator
FLUID for FLTK
wxFormBuilder for wxWidgets
Projucer for JUCE
Ultimate++
NetBeans GUI design tool for Java Swing
TKproE (TCL/TK Programming Environment)
Lazarus
MSEide+MSEgui Pascal
GTK# Visual Designer MonoDevelop (retired)
Xamarin.Forms GTK Backend (discontinued for NET MAUI)
За более чем 30 лет работы в IT я зарабатывал на жизнь программированием на языках Assembler, Basic, C, C++, Fortran, Lisp, Pascal, PL/I, Python, REXX, Scheme (в алфавитном порядке), а также руководством подобными процессами. Занимался я преимущественно системным программированием, то есть, так сказать, производством средств производства; но не только.
Вот какой получился рейтинг языков программирования в моей жизни:
– больше всего строк кода я написал на ассемблере, причём в основном бесплатно, в процессе обучения; – больше всего по продолжительности я программировал на Паскале (не то чтобы это было свойство самого Паскаля, а просто время такое было); – больше всего удовольствия я получал от использования PL/I; – самой дорогой в перерасчёте на строчку кода была моя программа на REXX (так сказать, антипод ассемблера в моей карьере); – самый сложный код я писал на Scheme.
Решил по фану реализовать конвертор милей в километры на C. Ссылка тут.
Advanced distance converter: miles to kilometers
Usage: ./bin/fib_miles2km [OPTIONS] [distance]
Options:
-h, --help Show help information
-f, --fib=ARG Convert miles to km using basic Fibonacci
-b, --basic=ARG Convert miles to km using standard formula
-i, --fib-interp=ARG Convert using Fibonacci interpolation
-c, --fib-cache=ARG Convert using cached Fibonacci
-g, --fib-golden=ARG Convert using golden ratio
