Разработка

Меня зовут Алекс Гусев. В этой публикации я очень кратко раскрываю, почему переход с IntelliJ IDEA (PhpStorm) на VSCode ломает привычную работу с JSDoc в JavaScript-проектах.

За две недели я собрал бесплатный веб-сервис, который генерирует диаграммы по текстовому описанию — без ручного рисования и без мучений с кривыми картинками от ИИ. Ключевая идея: вместо генерации изображений — генерация PlantUML-кода, затем серверный рендеринг в PNG и выдача пользователю. В статье рассказываю, как я проектировал сущности и сервисы, строил микросервисную архитектуру с очередями, поднимал PlantUML-server и MinIO, настраивал мониторинг и деплой, а также танцы с бубнами вокруг локальной LLM — и как меня спас старый ноутбук с GPU. Отдельно — про боль вайбкодинга: где ИИ-агенты помогают, а где требуют жёсткого микроменеджмента и шаблонов промптов.

На протяжении многих лет тестовые наборы ReactOS оставались без должного внимания. Они представляли собой случайный набор:

- собственных тестов проекта;

- старых тестов Wine, которые проверялись только на Windows Server 2003 иногда — на случайных более новых версиях Windows (на усмотрение участника).

Импортированные тесты Wine были сильно модифицированы, а внесённые изменения не всегда хорошо документировались.

Я взялся навести порядок в этом хаосе.

В 1998 году NASA потеряла свой космический аппарат Mars Climate Orbiter, стоимостью 328 млн долларов из-за несогласованности команд, работавших над его созданием. Летательный аппарат прошел над поверхностью Марса на высоте всего 57 км вместо расчетных 110 км и был уничтожен атмосферой планеты. Почти двукратное отклонение было обусловлено ошибкой в программном обеспечении: команды по тяге двигателя в программном обеспечении аппарата использовали единицу измерения силы ньютон, в то время как программное обеспечение на Земле, которое создавало эти команды, использовало британскую единицу измерения (фунт-сила).

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

Сегодня я расскажу вам про мой путь от 0 до 500+ задач на Leetcode. Сначала, пару слов о себе: достаточно слабое образование, завалил кучу собеседований на алгоритмы (например, в Авито где-то в 2020 году), никогда не умел решать задачи, и не любил. Долгое время узнав о секции алгоритмов просто отказывался от собеседований. Сейчас не боюсь и могу. Даже в Бигтех эту секцию проходил несколько раз.

Я делал всякий фронтенд, потом стал делать бекенд (на NodeJS), но алгоритмы никогда не получались.

И вот, засучив рукава, я решил разделаться с этим безобразием раз и навсегда. Мой профиль на LeetCode на сегодняшний день выглядит так:

Планировщик Linux долгое время оставался зоной, куда можно было заглянуть, но почти невозможно вмешаться без пересборки ядра. С появлением sched_ext эта граница сдвинулась: теперь логику планирования можно описывать кодом на C и загружать в ядро через eBPF. В статье разберём минимальный рабочий планировщик, посмотрим, как он взаимодействует с ядром, и обсудим, какие новые возможности это открывает для экспериментов и диагностики поведения системы под нагрузкой.

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

Что общего у программистов и кроликов? Красные глаза. Только кроликам это идет, а нам — не очень.

Я программист, который проводит за экраном от 6 до 12 часов каждый день, а в особо "удачные" моменты - все 18. За годы такой жизни я пришёл к выводу: либо учишься защищать глаза, либо становишься похожим на героя фильма ужасов к 30 годам.

Эта статья будет полезна не только IT-специалистам, но и всем, кто работает за компьютером.

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

Вот тут и пригодится ИИ, который способен cоставить настоящий план атаки и найти уязвимости. Но встает вопрос: если такому агенту дать реальную боевую среду, способен ли он найти в ней уязвимости? Исследователи из Оксфорда построили инфраструктуру из 8000 машин, посадили десять живых пентестеров, ИИ-агента и стали сравнивать…

В обзоре разберем, как именно ученые устроили безопасный эксперимент и пора ли специалистам по безопасности искать новую работу?

Вопрос: что же такого прорывного добавили в архитектуру, чтобы она стала считаться чем-то новым с точки зрения инженеров, а не маркетологов?

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

В отличие от традиционных подходов, где Data Warehouse оперировал исключительно структурированными данными в табличной форме, а Data Lake работал с файлами в их исходном виде, разработчики Lakehouse сумели соединить лучшие качества обеих архитектур.

Ключевым отличием стал формат OTF — Open Table Format, через который удалось реализовать единый стандарт доступа к данным и 4 технологически-культурных сдвига. Перечислю их: ...

Привет! Я Максим Катрушенко, главный специалист по анализу данных и машинному обучению в ПГК Диджитал. В свое предыдущей статье я разбирал ошибки в резюме джунов (и не только), которые снижают шансы попасть в ML. Сегодня расскажу, как упорядочить инструменты data scientist'а, чтобы легко адаптироваться в специальности.

Введение

Недавно мне показали проект по прогнозированию ремонта вагонов. Несколько десятков параметров, миллионы записей. Всё решение — один файл Jupyter Notebook и пара скриптов.

Я открыл этот файл. Две тысячи строк кода. Названия переменных вроде df_tmp_final_v3. Комментарии на смеси русского и английского. Сохранённые модели назывались model_good.pkl и model_production_maybe.pkl. Некоторые ячейки кода было страшно запускать. Ни документации, ни записи о проведённых тестах.

Узнаёте? Это частая реальность в области данных.

Вы не одиноки

Многие начинающие специалисты задают похожие вопросы:

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

Как внедрить модель? В Notebook всё работает, но как превратить её в сервис, который сможет использовать ваше приложение?

Хорошая новость: для этих проблем уже есть решения.

Привет, Хабр!
Команда CTSG запустила новый сезон подкаста Crosscheck. В одном из первых выпусков эксперты обсуждают актуальную, «горящую» на сегодняшний день, тему обезличивания баз данных: изменения в законодательстве, методы обезличивания, маскирование и многое другое.

Команда Spring АйО подготовила перевод статьи в которой автор разбирает, где параллельные стримы действительно масштабируются, а где создают накладные расходы, конкуренцию за ресурсы и иллюзию производительности. Коротко: сначала аналитика и измерения, потом — параллелизм.

Привет, Хабр! Cегодня рассмотрим, как ускорить интеграционные тесты в Spring Boot с помощью специальных slice аннотаций.

Начнём с того, почему вообще тесты могут быть медленными. Используя @SpringBootTest, мы просим Spring Boot поднять весь контекст приложения для каждого тестового класса. У нас доступны все бины, но часто все это избыточно. Например, хочется протестировать контроллер, а Spring загружает ещё и базу данных, и сервисы, и шлёт запросы к Kafka. В результате простой тест метода контроллера может запускаться несколько секунд, пока поднимется веб‑сервер, инициализируется база, подтянутся все классы.

Эту проблему осознали и добавили так называемые test slice‑аннотации. Все простоб грузим не весь контекст, а только срез приложения, например, только веб‑слой или только слой доступа к данным. Spring Boot содержит готовые slice‑аннотации для основных слоёв: @WebMvcTest для веб, @DataJpaTest для JPA‑репозиториев, и ещё пачку для других случаев.

Рассмотрим на примерах двух интересных слайса: @DataJpaTest и @WebMvcTest.

Несмотря на весь технический прогресс IT, мне за всё время так и не удалось повстречать убедительное решение проблемы ввода «ghbdtn» вместо «привет» или «lf» вместо «да» — путаницы с раскладкой клавиатуры при наборе текста.

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

Я опишу реализацию решения для среды рабочего стола GNOME, проверенное на дистрибутивах Fedora 43 и Ubuntu 24.04.

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

Аналитика рынка промышленных сетей.

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

Рынок промышленных сетей формируется не громкими публикациями про IoT/IIoT и не усилиями маркетологов. Его формируют ключевые игроки отрасли — лидеры, которые создают профильные организации (ODVA - EtherNet/IP, CLPA - CC Link, PI - PROFINET/PROFIBUS/IO-Link и др.), разрабатывают стандарты и фактически устанавливают правила игры. По своей структуре это олигополистический рынок, во многом сопоставимый с картельной моделью: именно лидеры определяют направления и темпы развития. В индустриальном сегменте не рынок диктует лидерам, что делать, а лидеры управляют рынком. 

Аннотация

Настоящая статья представляет собой развернутое исследование, посвященное систематическому изучению классических алгоритмов оценки оптического потока — фундаментальной задачи компьютерного зрения. Основной целью работы является последовательный и строгий вывод ключевых методов, начиная от базовых физических постулатов и заканчивая завершенными, готовыми к реализации математическими моделями. В центре внимания находится уравнение ограничения оптического потока, выводимое из краеугольного предположения о постоянстве яркости, и два основополагающих, принципиально различных подхода к решению этой недоопределенной задачи: локальный метод Лукаса-Канаде, основанный на предположении о пространственной согласованности потока в малой окрестности, и глобальный метод Хорна-Шанка, вводящий условие плавности (гладкости) потока в виде регуляризирующего функционала. Подробно анализируются теоретические основания каждого подхода, их математический аппарат, включая вывод и решение соответствующих систем уравнений, а также проводится сравнительный анализ их сильных сторон и присущих им фундаментальных ограничений, таких как проблема апертуры и чувствительность к нарушениям исходных предположений.

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

Оптимизация в React почти всегда сводится к двум факторам: объёму работы, которую выполняет JavaScript, и частоте (а также «стоимости») перерисовок компонентов. Сам React работает достаточно быстро, но в крупных интерфейсах даже небольшие архитектурные промахи и на первый взгляд безобидные ререндеры начинают заметно бить по производительности.

В данной статье мы расскажем про ключевые подходы к оптимизации React-приложений: как уменьшить количество лишних ререндеров, сократить объём вычислений при вводе и скролле и снизить нагрузку стартового JavaScript.

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

Регулярно встречая подобные проблемы в своей работе, мы во Flowwow решили внедрить процесс, который помог не только снизить на треть количество времени на анализ корневых причин сложных инцидентов, но и значительно упростить согласование фич для программистов. Этот процесс получил кодовое название ADR.

Не для кого не секрет, что мы сейчас пользуемся григорианским календарём введённым после Октябрьской революции большевиками, но празднуем христианские праздники по юлианскому календарю, который отличается от григорианского на 13 дней. Но почему так происходит? Давайте разбираться.

Привет, Хабр! Меня зовут Максим Галаганов, я ведущий разработчик систем доставки почты в Mail. Занимаюсь в основном почтовым сервером, но сегодня расскажу о другой задаче — как мы меняли вендора антивирусного решения. API нового решения кардинально отличался от старого, и пришлось изрядно поизобретать, чтобы всё заработало.

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