Программирование *

WebDesktopGL — это фреймворк для преобразования веб-сайтов в настольные приложения на основе Chromium. Совместим с Astra Linux и другими системами Linux. В статье рассказано о следующем:

Как использовать браузер Chromium в качестве отдельного графического движка (параметры запуска Chromium).

Как на виртуальном экране Xephyr или Xvfb (X-сервере) реализованном над Xorg, добавить поддержку GPU видеокарты.

Как реализовать буфер обмена между дисплеями с помощью xclip в Astra Linux и других системах Linux.

Цель работы — это создание аналога фреймворка Electron, альтернативного программного продукта WebDesktopGL, для Astra Linux и других систем Linux. Фреймворк WebDesktopGL был протестирован в средах Wayland и X11 в Ubuntu 24.04 (KDE), в X11 Ubuntu 22.04 (KDE) и Astra Linux 1.8.

В этой статье приведены: паттерны команд Bash в формате скрипта make_window_icon_txt.sh, а также добавление alpha канала с помощью Bash-скрипта утилитами imagemagick (convert) и ffmpeg. Скрипт имеет размер 290 строк. Эти команды bash отвечают на вопросы:

Как удалить фон из анимированных форматов gif, webp, mov?

Как добавить alpha канал в форматы gif, webp, mov, mp4 и png?

Как конвертировать форматы gif, webp, mov, mp4 в отдельные png изображения?

Как собрать форматы gif, webp, mov, mp4 из отдельных png изображений?

Как конвертировать изображения в формат ARGB иконок оконных менеджеров?

Как попиксельно обрабатывать форматы gif, webp, mov, mp4 и png?

Также в статье приведены оптимальные параметры команд imagemagick (convert) и ffmpeg для обработки форматов gif, webp, mov, mp4 и png.

В статье показана структура запросов к окнам Linux, позволяющая управлять уже запущенными окнами. Изначально утилита xdotool_xseticon была создана для динамического изменения значка окна в Astra Linux. Затем функционал утилиты был расширен для полного управления окнами и получения всей информации об окне Linux. Утилита xdotool_xseticon была протестирована в средах Wayland и X11 в Ubuntu 24.04 (KDE), в X11 Ubuntu 22.04 (KDE) и Astra Linux 1.8. Размер утилиты - 1000 строк.

Эксперимент на примере классификации изображений CIFAR-10 с использованием фреймворка ICO: параллельная загрузка данных, аугментации, тренировка и валидация.

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

Потихоньку копятся стресс, нереализованные амбиции и внутреннее несогласие с окружающим миром. Раздражают решения конкретного продакт-менеджера. Бесполезные дейлики. Обязательная корректность в любом рабочем разговоре. А в финале приходит отвращение ко всей индустрии ИТ, превратившейся из творческого полигона в конвейер, штампующий коммерческую посредственность.

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

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

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

В этой статье рассматривается одна из причин такого поведения IDE Qt Creator и приводится решение этой проблемы. Актуальность:

1. В интернете нет описания и решения данной проблемы (я искал).

2. Некоторые решения данной проблемы, которые может выполнить пользователь, вредоносны.

3. ИИ не предлагает верного решения.

4. У ide Qt Creator нет лога ошибки данной проблемы (QT_DEBUG_PLUGINS=1 и gdb бесполезны).

В шестой части цикла про создание DSL на C# добавляем Akbura полноценную поддержку IDE.

Разберём Language Server Protocol, синхронизацию документов, immutable snapshots, MSBuild и semantic tokens. Затем посмотрим, почему для Visual Studio я выбрал нативную интеграцию через MEF и Visual Studio SDK, какие проекты помогли разобраться в Editor API и какие полезные возможности Roslyn неожиданно оказались internal.

В конце немного про публикацию расширений в Visual Studio Marketplace и приключения с Azure.

Каждый день мы пишем JSX, используем хуки и стараемся не нарушать их строгие правила. Но как вся эта «магия» работает под капотом? Почему условный рендер ломает useState, а индексы массива в key приводят к багам? Зачем React перешел на архитектуру Fiber и как алгоритм обходит дерево элементов, не блокируя браузер?

Чтобы перестать воспринимать React как черный ящик, лучший способ — написать его с нуля.

В этой статье мы шаг за шагом воссоздадим собственный движок React. Мы реализуем функцию createElement, разберем Fiber-архитектуру с асинхронным рендерингом, напишем алгоритм Reconciliation и создадим систему хуков, разобравшись в логике их работы.

Для примера будем использовать наш продукт для просмотра топологии и верификации(EDA) и расскажем, как мы построили его лицензирование.

Каждый коммерческий продукт рано или поздно упирается в один вопрос: кому именно вы продаёте право пользоваться программой.

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

Но если продукт одновременно нужен заводам, университетам, небольшим компаниям и стартапам, модель меняется. Это уже не десять клиентов, а сотни или тысячи машин: учебные лицензии, trial, временные ключи, один ноутбук на нескольких сотрудников.

В этот момент плохо работает модель «один бинарь и проверка лицензии есть или нет».

Последние месяцы я рецензирую научный софт для JOSS, Journal of Open Source Software. Это настоящий рецензируемый журнал с редколлегией, только статья в нём короткая, около тысячи слов, а главный объект ревью - репозиторий с кодом. Ревью идёт в публичном GitHub-треде под именем рецензента, и весь процесс от заявки до вердикта открыт любому желающему. Я инженер, не учёный: ни PhD, ни публикационного списка у меня нет.

Что полезного может делать бизнес-процесс, в котором всего одна задача, и та пользовательская? Что можно рассказать про BPMN-схему, которая поместится на экране смартфона? Муки выбора, драма, предательство и обстоятельства непреодолимой силы — вот что! Я расскажу, как на самом деле разрабатываются BPMN, исполняемые в движках вроде Camunda и Flowable, и, может быть, вы перестанете считать их просто «очередной графической нотацией»

Бэкапы с моих серверов уезжают в объектное хранилище, и стоило это около десяти тысяч в месяц. Потом пришло письмо, что средства заканчиваются, а по расходу за трое суток выходило уже сорок с лишним. Провайдер ни при чём: репозиторий раздулся до 291 ГиБ, из которых 190 были чистым дублем, а prune не отрабатывал вообще никогда — репозиторий был повреждён, плюс шесть виртуалок конкурировали за один эксклюзивный лок. Разбираю по шагам, что нашёл и как перестроил схему.

20 августа на OpenRouter появилась строчка stealth/ox-alpha. Без карточки модели и даже намёка, кто её выложил. Провайдер значился как «Anonymous». Цена — ноль. Контекст — мильон. Площадка предупреждала: мы не владелец этой модели, а просто маршрутизируем запросы.

Через шесть дней у анона было имя, десятки триллионов обработанных токенов и полмиллиона разработчиков, которые за это время успели залить в него рабочий код. Спойлер, который уже не спойлер: это оказалась GLM-5.3-Flash от китайской Z.ai.

Но путь от «непонятно что» до «фронтир‑модели» получился драматичным и заслуживает разбора. Ну а поскольку я лично пялился в этот тред почти неделю, обновляя ленту как одержимый — расскажу вам что там произошло, по порядку.

Работа с файлами в REST API Битрикс24 — та задача, где документация заканчивается ровно там, где начинаются проблемы. Официальные примеры показывают, как загрузить один файл в одно поле. А дальше выясняется, что у crm.item.update и crm.deal.update разные несовместимые форматы, что вложенный base64 через http_build_query уходит в никуда, а сервер при этом честно отвечает «result».

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

Собрал всё в один разбор — шесть подходов с кодом и восемь граблей:

два формата файлового значения, которые нельзя смешивать, и почему при смешении затираются уже прикреплённые файлы;

тихий провал: HTTP 200, в ответе result, поле не обновилось;

useOriginalUfNames=Y, без которого UF_CRM_* молча игнорируются;

downloadUrl приходит с пустым auth= и без подстановки токена не скачивается, а при протухшем токене вместо файла отдаётся HTML-страница с кодом 200;

у одного изображения бывает несколько URL, и часть из них не работает — пришлось делать скоринг вариантов по эвристике.

В конце — таблица «что брать под какую задачу» и чеклист граблей. Двадцать блоков кода, всё из боевых проектов.

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

Привет! Я Костя Никитин, руководитель направления в одном из подразделений Т-Банка. Занимаюсь проектированием высоконагруженных систем — мы импортозамещаем автоматизированную банковскую систему. Если упростить, это автоматизация бухгалтерского учета: все банковские операции приходят к нам, нужно их сложить и посчитать. В Java-мире я уже больше двенадцати лет, начинал когда-то с 1.6.

Расскажу о проблемах, с которыми мы столкнулись, когда переехали в Kubernetes, как мы их порешали и как в итоге оптимизировали ресурсы при работе в виртуализации. Если вы хоть раз ловили OOMKilled на ровном месте и не понимали за что, может быть, узнаете себя.

Спойлер: в финале мы сократили потребление памяти на 18%, CPU — на 31%, а приложения при этом стали работать быстрее. Погнали.

Мы списали uv со счетов. А потом он ускорил наш CI на 80%

В Python-сообществе вокруг uv уже несколько месяцев шум: быстрый резолвинг, один инструмент вместо зоопарка утилит и обещание ускорить привычный workflow. Звучит хорошо — пока не проверишь на своём стеке.

Мы так и сделали. Взяли один микросервис: Python 3.14, 37 прямых зависимостей, 153 пакета в lock-файле, приватные пакеты и внутренний Nexus. Ожидание было простым: если uv действительно быстрее Poetry, миграция окупится сама.

Локально получилось наоборот. Резолвинг — да, быстрее. Установка по готовому lock-файлу — нет, иногда даже медленнее. Эксперимент закрыли и остались на Poetry.

Через несколько недель пришлось вернуться. Не из любопытства, а из-за алерта Trivy и сюрпризов Poetry 2 с корпоративными индексами. И вот тогда uv показал себя совсем в другом месте — в CI.

В статье разберем:

- почему локальный бенчмарк uv vs Poetry нас обманул;
- как Poetry 2 сломал привычную разработку без VPN;
- зачем мы писали парсер poetry.lock → requirements.txt и почему это оказалось костылём;
- как точечная замена Poetry на uv sync в пайплайне сократила время с 5:10 до 2:50;
- почему в итоге uv стал единым стандартом и локально, и в CI.

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

Self-hosted Sentry — это 65 контейнеров, 16-32 ГБ RAM и выделенный инженер на поддержку. Всё ради того, чтобы ловить стектрейсы. Разбираемся, почему индустрия приняла это как норму, сравниваем альтернативы (GlitchTip, BugSink, Hawk) и знакомимся с Metric — Sentry-совместимым мониторингом на, которому хватает 1 ГБ RAM и двух контейнеров. Миграция — смена одной строки DSN.

Кто может назвать самый известный во всем мире «помощник» при написании не только программного кода, а вообще любого, даже небольшого текста? Наш тайный чемпион – буфер обмена!

Кто-то, наверняка, сейчас усмехнется, но задумайтесь на пару секунд: сколько раз вы не переписывали текст тупо слово за словом, а просто копировали и вставляли его в нужное вам место? Ведь мало кому захочется так тратить свое время, когда можно просто скопипастить. Все к этому привыкли настолько, что никто не сможет уверенно сказать сколько раз за день он нажимает [Ctrl]+[C] и [Ctrl]+[V]. В каких-то случаях, может быть, удобнее перебирать пальцами [Ctrl]+[Insert] и [Shift]+[Insert], или мышью тыкать в картинки на панели инструментов, – все это уже кому как удобно поступать в каждый момент времени.

Все-таки буфер обмена можно назвать главным помощником при написании текстов, и в том числе в 1С-разработке. И тем более, что в 1С можно так копировать не только текст процедур, но реквизиты и целые объекты в структуре конфигурации.

Привет, Хабр. Я 1С-разработчик SimbirSoft Михаил, в этой статье поделюсь своим опытом подбора инструментов, которые помогают ускорить разработку в 1С.

Хайп-цикл фронтенда, кажется, наконец-то выдохся. Мы вышли из фазы бесконечного переизобретения колеса, где каждый месяц появлялся «убийца React», и вошли в эпоху убийцы Fable инженерной зрелости. Сегодня опытного инженера сложно впечатлить очередным фреймворком: ценность сместилась в сторону предсказуемости, скорости поставки (delivery) и снижения когнитивной нагрузки.

Привет, меня зовут Павел Востриков, и я — архитектор веб-направления в «Лаборатории Касперского». В этой статье хочу разобрать JS-экосистему как набор инженерных компромиссов.

На HolyJS Spring 2026 мы предложили 120+ инженерам оценить свой реальный стек. Получившийся радар мог быть просто списком библиотек, но в итоге вышел срезом того, как выглядит рациональный подход к коду в 2026 году. Мы видим, как разработчики массово идут в сторону предсказуемой скорости масштабирования решений и инженерной гигиены.