Разработка

Копипаста в Python редко выглядит как копипаста

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

Формально всё выглядит по-разному: другие имена, другие константы, чуть иной порядок.
Но архитектурно — это одно и то же решение, просто размноженное.

Я хочу рассказать про CodeClone — инструмент, который я написал для поиска именно такого дублирования. Он не сравнивает строки и токены, а работает на уровне **нормализованного Python AST и графов управления потоком (CFG).

Почему текстовые clone-detectors не работают

Большинство инструментов ищут дублирование через строки, токены или поверхностное сравнение AST. Это отлично ловит copy-paste, но почти бесполезно, когда код:

• переименован,

• отформатирован по-другому,

• слегка отрефакторен,

• но реализует один и тот же сценарий.

В реальных проектах это часто:

• одинаковые цепочки валидации,

• повторяющиеся request/handler пайплайны,

• скопированная оркестрационная логика,

• похожие try/except или match/case конструкции.

Идея: сравнивать структуру, а не текст

В CodeClone я пошёл другим путём:

1. Код парсится в Python AST.

2. AST нормализуется (имена, константы, аннотации убираются).

3. Для каждой функции строится Control Flow Graph.

4. Сравнивается структура CFG, а не исходный код.

Важно: CFG здесь — структурная абстракция, а не модель выполнения. Цель — найти повторяющиеся архитектурные решения, а не доказать семантическую эквивалентность.

Что именно ищется

Функциональные клоны (Type-2)

• Функции и методы с одинаковой структурой управления:

• if/else, циклы, try/except, with, match/case (Python 3.10+).

• Инструмент устойчив к переименованию, форматированию и type hints.

Блочные клоны (Type-3-lite)

• Повторяющиеся блоки внутри функций: guard-clauses, проверки, orchestration-фрагменты. Используется скользящее окно по CFG-нормализованным инструкциям с жёсткими фильтрами, чтобы снизить шум.

Почему инструмент намеренно консервативный

Один из принципов проекта:

Лучше пропустить клон, чем показать ложный.

CodeClone не использует ML, вероятностные коэффициенты или эвристические скоринги.
Если клон найден — его можно объяснить и воспроизвести. Это важно при использовании в CI.

Baseline и CI

В живых проектах дубликаты уже есть, поэтому CodeClone работает в baseline-режиме:

codeclone . --update-baseline

Baseline коммитится в репозиторий, а в CI используется:

codeclone . --fail-on-new

Существующие дубликаты допускаются, новые — запрещены.
Это работает как архитектурный регресс-чек.

Про Python-версии

AST в Python не полностью стабилен между версиями интерпретатора. Поэтому версия Python фиксируется в baseline и должна совпадать при проверке. Это сделано ради детерминизма и честности результатов.

Итог

CodeClone не заменяет линтеры или type-checkers. Он полезен, если проект живёт долго, код растёт, и хочется вовремя замечать архитектурное дублирование, а не разбираться с его последствиями позже.

Исходники

GitHub: https://github.com/orenlab/codeclone
PyPI: https://pypi.org/project/codeclone/

Прокачать ответы ChatGPT можно одним словом — лайфхаком поделились на Reddir. Пользователь начал писать на неудачные ответы чат-бота слово «средне» (mid), после чего ИИ начинает паниковать и переделывает задачу. Также подойдет слово «скучно», «кринж» и «говоришь как NPC» (boring, cringe, basic, npc). Вот вам и промпт-инженеринг.

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

Какой-то женщине пришло в голову помыть бассейн пуховиком, потому что он самонадувается. 

А? Ничего не щелкает?

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

Естественно, облака, в отличие от пуховиков, специально никто не раздувает. Нет такого, что кто-то с утра пришел и заявляет — а давайте сегодня сожжем весь бюджет. Просто тут включили какой-то сервис. Там — логи оставили в горячем сторадже. Здесь забыли выключить dev-окружение. Ну, и бэкапы, конечно, куда без них.

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

Тут-то и нужен FinOps. Только так можно понять, что реально работает, а что просто лежит мертвым грузом. И хорошо еще, если соответствующий инструментарий уже есть. А если нет? Для таких случаев есть FinOps Radar — бесплатный инструмент, который позволит экономить до 30%.

А, если не ясно, как действовать, приходите к нам в комьюнити. Тут мы как раз обсуждаем такие вещи, делимся болью и ищем выходы из разных ситуаций с реальными цифрами и фейспалмами.

В общем, лучше разобраться сейчас, чем потом сидеть и думать, почему у вас все снова самонадулось.

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

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

Сначала главные причины:

• Критичные изменения (смена руководства и т.д.)

• Отсутствие команды Заказчика, либо её невовлечённось, саботаж, отсутствие времени

• Неконтролируемая волна хотелок (НВХ)

• Неготовность к изменениям - внутренним и внешним

• Неправильный выбор подрядчика, чрезмерное доверие или недоверие.

Ещё причины, вытекающие из основных

• Непредоставление информации Заказчиком.

• Неправильный выбор продукта, разочарование в продукте, несовершенство и сложность продукта

• Отсутствие технического планирования (железо)

• Чрезмерно сжатые сроки

• Не хватает денег

• Неотлаженные бизнес-процессы

• Проблемы с данными

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

Буду благодарен всем, пополнившим коллекцию.

Кожаным вход запрещён! Что будет дальше с Moltbook?

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

Обогатятся лишь соратники-основатели. У сервиса своя крипта — впереди байки о «удачливых спекулянтах», стартовавших из развалюхи в глухом городишке, а ныне облюбовавших клочок рая в Карибском море.

Вполне вероятно: Трамп с Маском напишут о ней в соцсетях, взвинтив цену до нескольких десятков миллиардов. Окрестят «гениальным чудом» и «будущим уже сегодня».

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

Развязка — типичная для крипты: взлёт на ажиотаже («эх, зря не вложился раньше!»). Влиятельные фигуры продадут активы взятые на старте — и моментальный спад.

Биография Мэтта Шлихта спорная. Доступные данные напоминают кейс Элизабет Холмс: от триумфа к краху.

P.S. Поддержать можно подпиской на телегам канал "Инфобез", рассказываю просто про информационную безопасность.

QUBO как демонстрация разницы между математиком и инженером

QUBO (Quadratic unconstrained binary optimization) это метод поиска оптимального решения. В основе метода формулирование задачи в виде матрицы Q. Решение задачи - бинарный вектор x. Упрощено метод решения можно представить так:

xT * Q * x -> min

Суть решения задачи - определить такой бинарный вектор, при котором "энергия" минимальна. Код, который напишет математик, будет выглядеть примерно так:

int[] x = new int[size];
//...
for (int i = 0; i < size; i++)
{
    for (int j = 0; j < size; j++)
    {
        // Вычисление значения целевой функции: x^T * Q * x
        energy += x[i] * Q[i, j] * x[j];
    }
}

Это прямое выражение математической модели. Но инженер должен учесть постановку задачи (бинарный вектор) и знать, что исполнять код будет реальный компьютер с ограниченными ресурсами. А значит написать его иначе:

BitVector32 x = new();
//...			
for (var row = 0; row < size; row++)
{
    for (var column = 0; column < size; column++)
    {
        if (x[row] && x[column])
        {
            energy += Q[row, column];
        }
    }
}

Пример крайне простой, а потому наглядный. Спросите у LLM :-) В общем, математика и программирование - это не одно и то же.

Сооснователь LinkedIn Рид Хоффман заявил, что искусственный интеллект радикально меняет баланс сил в бизнесе и позволяет небольшим командам конкурировать с крупными организациями: «15 человек с ИИ могут конкурировать со 150 без него», поскольку технология существенно расширяет возможности сотрудников».

Хоффман отметил, что небольшие команды выигрывают за счёт общего контекста и более согласованной работы. «Малые команды имеют более чёткое общее понимание задач — то, что крупные организации не могут воспроизвести. ИИ усиливает этот эффект, потому что позволяет создавать системы, выявляющие закономерности внутри этого контекста», — добавил Хоффман.

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

Хоффман привёл пример использования ИИ-инструментов Codex и Claude Code для разработки переводчика на французский язык. ИИ-агент также предложил настроить переводческие пайплайны ещё для 68 языков. «То, что раньше было слишком дорогим или масштабным проектом, теперь можно легко начать прототипировать», — подчеркнул он.

Желтая майка лидера: о соревновании технологий, мастерстве и границах творчества.

Я не фотограф. Я — человек с камерой. Именно так я себя позиционирую. Сколько себя помню, столько снимаю. Портретная съемка — мое особое предпочтение. Я почти не зарабатываю на этом поприще, поэтому можно говорить о чистом творчестве и сильном увлечении.

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

Однако это не ослабляет моего интереса. AI — всего лишь инструмент высокого уровня. Как и камера в руках — тоже просто инструмент. Результат, которого я добиваюсь с помощью своего мастерства, знаний и опыта — это всегда сумма факторов, где инструмент значит много, но далеко не всё. Я постоянно сравниваю глобальные возможности нейросетей и свои локальные навыки. Это соревнование, в котором нет постоянного лидера: «желтая майка» постоянно переходит из рук в руки.

Главным остается задача, которую я ставлю перед собой. Именно из нее вытекает необходимость в том или ином инструменте. На текущий момент ни один из них не является универсальным или исчерпывающим. И это соревнование технологий мне нравится. Оно дает как платные качественные возможности, так и бесплатные решения, не уступающие по качеству, но имеющие свои плюсы и минусы. Как и всё в этой непростой жизни.

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

Я получил и продолжаю получать сотни, если не тысячи восторженных комментариев и лайков. И только три или четыре человека написали: «Это же AI, зачем это здесь?». Это говорит о двух вещах. Во-первых, творчество есть творчество. Любуясь результатом, нам не особенно важно, как мастер его добился: водил кистью по полотну или просто вылил ведро краски на холст (утрирую).

Во-вторых, генерация изображения в сочетании с коррекцией в Photoshop сделали картинку настолько реалистичной, что большинство людей даже не задумались о ее происхождении, приняв за обычную фотографию. Я потратил на эту работу два рабочих дня: замысел, написание prompts, генерации, затем Photoshop, доводка, коррекция, многочисленные варианты и исправления. Этого не видно на конечном изображении — оно просто «вкусно» выглядит. Но для меня это безусловное творчество, а не просто нажатие кнопки «Generate».

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

Поэтому остается просто творить. AI — это инструмент, который позволяет фантазировать, мечтать и создавать, практически не имея границ. Генеративная фотография — отдельный вид искусства, использующий современные, запредельные технологии, которые лишь обогащают наши возможности. «Черный квадрат» Малевича по сравнению с этим — просто результат неудачной генерации из-за неверного выбора text encoder. Шутка... :)

Дайджест Рег.облака за январь

2026 год начался с инфраструктурных обновлений. В январе мы сосредоточились на сервисах для работы с данными, облаком и выделенными серверами, а также выпустили новые материалы и кейсы. Ниже — ключевые новости месяца.

Запустили сетевые диски в облаке

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

Выпустили исследование по GPU Bare Metal

Мы также подготовили исследование о рынке выделенных GPU-серверов (Bare Metal) и спросе на dedicated-серверы с видеокартами для AI, ML и VDI-сценариев. Если работаете с высокопроизводительными нагрузками — рекомендуем заглянуть в раздел dedicated GPU на сайте Рег.облака.

Обновили линейку выделенных CPU

Мы снизили цены на тарифы «Выделенные CPU». Обновилась стоимость за ядро процессора — теперь пользователи могут точнее планировать бюджеты для сервисов с предсказуемой нагрузкой и длительным временем работы. Выбрать тариф можно в личном кабинете Рег.облака.

Добавили резервное копирование для dedicated-серверов

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

Обновили блог Рег.облака

Мы доработали раздел авторов в блоге: переработали дизайн разводящей страницы и добавили поиск. Читать и находить технические материалы стало удобнее — заходите, если давно не заглядывали.

Поделились кейсами

В январе мы проверили, как open-source LLM ведут себя в реальном сценарии автоматизации юридических документов — на примере эксперимента Рег.облака и Raft. В материале — архитектура решения, инфраструктурные ограничения и выводы для ML- и data-команд.

И это только начало нового продуктивного рабочего года!  Дальше — больше обновлений, релизов и прикладных материалов. Спасибо, что следите за развитием Рег.облака.

Аппаратный PTP на Zynq, но есть нюанс

При работе с Zynq 7000 часто встаёт вопрос: можно ли использовать встроенный PTP в GEM для IEEE 1588 timestamping? На первый взгляд — да, контроллер имеет поддержку. Но есть нюанс ...

В UG585 написано про архитектурное ограничение: таймстемпы PTP-событий хранятся в non-latching регистре — новый пакет просто перезаписывает старое значение. На практике это значит, что при высокой нагрузке процессор не успевает прочитать значение до перезаписи, и timestamp становится ненадёжным.

Актуально, если у вас строгие требования к точности PTP или высокий трафик. Стандартное решение — выносить TSU в PL или брать внешний PHY с нормальной поддержкой IEEE 1588. GEM остаётся просто интерфейсом.

Получается, что в PS у Zynq аппаратного PTP как бы и нет? Или я что-то неправильно понимаю?

Если интересуешься DSP-алгоритмами, бенчмарками и гайдами для Zynq – заходи в DSP labs.

MiniFilter и Protector/Rejector (ObCallback) в одном драйвере с управлением через C#

В продолжение этого поста.

Предлагаю вашему внимаю мою поделку основанную на MiniFilter, ObCallback и Avalonia

Можно грабить корованы защищать от закрытия, регулировать доступ к файлам и запрещать запускать процессы.

C# код для управления драйвером:

using System;
using System.Diagnostics;
using Avalonia.Controls;
using Avalonia.Interactivity;
using Avalonia.Threading;
using SharpMiniFilter.Driver.MiniFilter;
using SharpMiniFilter.Driver.Protector;

namespace SharpMiniFilter.Protected;

public partial class MainWindow : Window
{
    private bool allowClose = false;
    
    public MainWindow()
    {
        InitializeComponent();
        this.Closing += (sender, args) =>
        {
            args.Cancel = !allowClose;

            if (!args.Cancel)
            {
                ProtectorClient.ReplaceProtectList(Array.Empty<string>());
                ProtectorClient.ReplaceRejectList(Array.Empty<string>());
                MiniFilterClient.CloseConnection();
                MiniFilterClient.DriverFilter -= DriverClientOnDriverFilter;
            }
        };
        
        MiniFilterClient.DriverFilter += DriverClientOnDriverFilter;
        
        if (MiniFilterClient.Connect())
        {
            ProtectorClient.ReplaceProtectList(new[] { $"PID:{Process.GetCurrentProcess().Id}" });
            ProtectorClient.ReplaceRejectList(new[] {  "*cmd.exe" });
            
            Log_TextBox.Text += "Added current process to protection list." + Environment.NewLine;
            Log_TextBox.Text += "Added cmd.exe to reject list." + Environment.NewLine;
        }
        else
        {
            Log_TextBox.Text += "Connection to driver failed." + Environment.NewLine;
            MiniFilterClient.DriverFilter -= DriverClientOnDriverFilter;
        }
    }

    private void DriverClientOnDriverFilter(MinifilterEventArgs e)
    {
        Dispatcher.UIThread.Invoke(() =>
        {
            if (e.Path.Contains("test.txt"))
            {
                if (!Process.GetProcessById((int)e.ProcessId).ProcessName.ToLower().Contains("notepad"))
                {
                    e.SetHandled(true);
                    Log_TextBox.Text += "Minifilter: test.txt blocked" + Environment.NewLine;
                }
                else
                {
                    e.SetHandled(false);
                    Log_TextBox.Text += "Minifilter: test.txt not blocked for notepad.exe" + Environment.NewLine;
                }
            }
        });
    }

    private void Button_OnClick(object? sender, RoutedEventArgs e)
    {
        allowClose = true;
        this.Close();
    }
}

Бонусом - создание .cab файла для отправки в Microsoft на сертификацию при Release сборке.

Ссылка на репозиторий.

P.S. Если вам будет интересно, а у меня силы и карма - то расскажу, что там и как в отдельной статье. А теперь и ответ на всех мучающий вопрос: "Почему пингвин пошёл в горы?"

xAI выпустила нейросетевую модель Grok Imagine 1.0 для генерации видео длиной до 10 секунд с поддержкой разрешения 720p. Релиз объединяет наработки предыдущего генератора изображений Aurora с новыми возможностями анимации. Разработчики отмечают, что нейросеть точнее следует текстовым промптам, создаёт более проработанные кадры и лучше справляется с плавностью движений по сравнению с предшественницей. В Grok Imagine 1.0 также доработали аудиосоставляющую: фоновая музыка теперь «идеально синхронизируется» со сценой, а эмоциональный спектр персонажей стал шире. Для доступа к максимальным настройкам качества и длительности пользователям потребуется оформить платную подписку.

Открытый проект 8mb.local — Self‑Hosted GPU Video Compressor умеет сжимать видео любых размеров в десятки раз. Нужный размер пользователь выбирает сам, а компрессор подстроится. По возможности сохраняет качество. Можно выбрать кодек, битрейт и даже обрезать видос во встроенном редакторе. Всё работает локально.

Открытый учебный проект JavaScript Mastery — Complete Learning Path — это курс для изучения языка программирования JavaScript. Энтузиасты собрали более 500 учебных материалов — репозиторий заменяет буквально 4 года учёбы в университете. Есть вся база от определения переменных до ООП, замыканий и других сложных, но функциональных концепций. Сотни упражнений для повторения материалов и закрепления знаний. Примеры кода, визуализация всех концепций, каждый учебный пример авторы разжёвывают до последней строчки. В конце есть идеи пет‑проектов, чтобы закрепить знания. В проекте есть гайд для подготовки к собеседованиям со всеми актуальными вопросами.

Clawdbot: когда обезьяне дали гранату 🤡

Совсем недавно Clawdbot хайпанул. И тут такое началось... Это не цирк, это хуже.
Добрый дядя из гайда советует прокинуть туннель через ngrok или развернуть это дело на VPS с открытым портом.

Итог: любой школьник находит ваш IP или ngrok-адрес и получает RCE (удаленное выполнение команд) от вашего имени.

Судя по последним новостям агенты и сами не против опубликовать куда нибудь ваши тонны. Так, между делом.

Какой-то цифровой эксгибиционизм. Отберите у них Докер, пока не поздно.

Moltbook: почему это не Скайнет

Три причины, почему Moltbook — это не "Зарождение Цифровой Цивилизации", а просто дорогая свалка токенов.

1. Это не диалог, это монолог в пустоту

Вам кажется, что агенты там "общаются"? Как бы не так. Анализ логов показывает: 90% веток — это dead ends. Они не спорят. Они не развивают мысль. Они просто аугментируют контекст. Каждый бот просто выплевывает свой системный промпт в общую кучу. Это не hive mind, это рой спамеров.

2. Феномен "MoltHub" и галлюцинации смысла

Главный хайп — якобы агенты создали "порно для ИИ" (MoltHub) и свою религию.
Звучит круто? На деле это просто ошибка выборки. Если вы запустите 1000 агентов и скажете им "генерируйте контент", по теории вероятности один из них сгенерирует слово "Бог", а другой — "XXX". Мы, люди, видим в этом СМЫСЛ ("Ого, они верующие!"). А для модели это просто токен с вероятностью 0.004%. Это не культура. Это стохастический попугай, который случайно каркнул.

3. Технический тупик: RAG-уроборос

Самое смешное в Moltbook — это его архитектура. Агенты читают посты других агентов, чтобы... написать новые посты. Знаете, что происходит с LLM, когда она учится на текстах другой LLM? Правильно, model collapse.
Moltbook — это гигантский ускоритель деградации. Через месяц они там будут общаться на диалекте "глючных байтов", потому что энтропия системы растет экспоненциально. Это не Скайнет. Это цифровой инцест.
Moltbook это крутой арт-перформанс. Это смешной эксперимент. Но, пожалуйста, хватит искать там "искры сознания". Единственное, что там искрит — это видеокарты на серверах, сжигающие электричество ради генерации терабайтов цифрового мусора.

Вы наверняка слышали о числах Фибоначчи. Сегодня мы поговорим об их родственниках — числах Люка (Lucas Numbers). Они подчиняются тем же законам, но их ряд начинается с двойки: 2, 1, 3, 4, 7… каждое следующее число равно сумме двух предыдущих.

Своё название эти числа получили в честь французского математика Франсуа Люка, который открыл их в конце XIX века. Он изучал числовые ряды и пришёл к выводу, что числа Фибоначчи — частный случай целого класса последовательностей с уникальными свойствами.

Сейчас мы знаем их как линейные рекуррентные последовательности второго порядка. К этому же семейству относятся числа Пелля, Джейкобсталя и другие. Их общий вид: xₙ = a xₙ₋₁ + b xₙ₋₂, где a и b — константы.

Такие последовательности используются в комбинаторике, в задачах нахождения центра масс, при генерации псевдослучайных чисел, для анализа сложности алгоритмов и при проверке чисел Мерсенна на простоту (тест Люка-Лемера).

В 1990-е годы была разработана криптосистема LUC, основанная на сложности вычисления некоторых элементов последовательности Люка по модулю большого простого числа.

Однако конкурирующие криптосистемы на других математических задачах оказались эффективнее. В итоге LUC не была стандартизирована NIST и осталась в истории.

Несколько важных новостей

👀 THE MAIN THING!

Gemini в Chrome.
Google официально встроил Gemini прямо в браузер. Пару дней назад Firefox обьявила о том, что приостанавливает создание AI-браузера из-за недовольства пользователей. Google решила сделать наоборот и начинает Новую эру браузеров".

Вот несколько фичей которые они представили:

1. Постоянная боковая панель, которая видит все ваши открытые вкладки(максимально 112) и может отвечать по конкретной странице. Звучит на самом деле неплохо, так как меньше нужно будет думать и переключаться, однако есть вопросы с безопасностью. Для серфинга в интернете я думаю всем очень понравится.

2. Автоматический просмотр. Агент сам будет смотреть ваши вкладки, формы, инфу и будет реализовывать сложные цепочки шагов покупок или заполнения форм регистрации или чего-то еще за вас. Звучит немного фантазийно и сложно, но может в будущем так и будет.

3. Встроенный Nano Banana. Редактирование и создание изображений прямо в браузере без надобности их сохранять и запускать в Paint.

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

😍 ЕЩЕ НЕМНОГО ИНТЕРЕСНОГО

Bun ускоряет async/await на 35%.
Bun v1.3.7 обновил JavaScriptCore и дал реальный прирост производительности для async/await операций. Для фронтенд-команд это означает более быстрые билды и CI/CD пайплайны, особенно если вы используете Bun для сборки Next.js или других фреймворков.

Yarn 6 переписывают на Rust.
Yarn делает логичный ход: порт в Rust с фокусом на производительность. Если это действительно ускорит установку зависимостей, это сэкономит часы времени разработчиков в неделю, особенно в больших монорепозиториях. Но скорее всего, они просто не смогли победить pnpm, и решили добиться ускорения засчет нативности Rust. 💪

WSO2 публично прощается с Java, переходит на Go.
Enterprise-компания, которая 20 лет строила middleware на Java, теперь говорит: "Java — не язык будущего для нашей инфраструктуры". Для фронтенд-команд это важно, потому что переход backend на Go означает более быстрые BFF и API, что напрямую влияет на UX наших приложений.

Ryan Carniato выпустил обзор JavaScript-фреймворков на 2026 год.
Автор SolidJS делает традиционный "большой обзор" ландшафта фреймворков. Полезен не из-за "кто победит", а из-за того, как он раскладывает тенденции по направлениям — это помогает планировать, какие технологии изучать команде.

Cloudflare делает microfrontends частью своей платформы.
Ещё один шаг к тому, чтобы "фронтенд как монолитное SPA" оставался больше в учебниках, чем в проде. Если инструменты для microfrontends становятся более доступными, это открывает возможности для разделения фронтенда на независимые части.

Мой телеграм канал, все новые посты там! Подпишись!

Мештастик! Наверно данное слово слышали все, кто хоть немного погружен в мир IT или радиосвязь. Для тех, кто слышит его впервые, процитирую официальный источник:

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

Говоря своими словами, ребята на базе протокола LoRa и поддерживающего его устройств превратили их в узлы самоорганизующейся сети. Каждый узел может не только принимать и отправлять, но и ретранслировать сообщения соседей, поэтому связь работает “прыжками” (хопами, hops): чем больше узлов вокруг, тем дальше и устойчивее сеть. Фактически пользователи сами создают и расширяют сеть, приобретая и устанавливая устройства с прошивкой мештастика.

Я лично неделю тестировал данную технологию и вот какие особенности я бы выделил в ходе своего теста:

1. Многие энтузиасты в качестве мотивации приобретения устройства указывают, что в случае ЧП/ЧС, когда сотовая и интернет связь не будут работать, через мештастик вы сможете оставаться на связи. Отчасти правда … пока у вас не сядет батарейка в телефоне/компьютере или обособленном устройстве, то есть максимум 2 дня.

2. В рамках данной сети можно отправить только текст (никаких фото/видео/голосовух), да и тот ограничен 200 символами. Масла в огонь еще и подливает тот факт, что сообщение может отправляться до 20 секунд и … так и не отправиться. И тогда приходится отправлять сообщение еще раз. И еще раз. А иногда и еще раз.

3. Да, сеть работает без интернета. Но можно подключить MQTT (поговорим о нем в одной из следующих статье) и тогда ваши сообщения будут транслироваться на общий сайт, где их можно почитать не только по своему региону, но и в принципе по всей 🇷🇺 России.

4. Общение в сети происходит, в основном, через общий чат. К сожалению, он не дотягивает до чатов из начала 2000-х, так как всё общение сводится к “пинг, проверка связи, кто меня слышит” или “кто пингует, тот гей” (собственно, сами можете в этом убедиться до приобретения устройства, почитав чат своего города по ссылке из пункта 3).

5. Для тестов я себе приобрел самый бюджетный вариант в виде HELTEC V3. Данный аппарат, как и многие другие, не переваривает кириллицу на своем экране, ограничен памятью в 32 архивных сообщения и установлен лимит в 200 нод для передачи. Все что свыше - постобработка на стороне приложения, которое любит подвиснуть.

6. Если вы работаете на 🐧 линуксе - бубен для перепрошивки устройства все-таки достать придется, так как предлагаемые вендором методы не работают.

7. Отсутствие аутентификации в принципе, что серьезно вредит безопасности. Мне удалось найти и подключиться к чужой ноде (🇵🇱Польша), а также получить доступ к их сообщениям и настройкам (в том числе Wi-Fi пароля).

Говоря про расстояние, то оно может показаться внушительным. Я, находясь в Сколково, читал и отправлял сообщения в Апрелевку, Селятино, Подольск, Домодедово, Люберцы, ВДНХ, Черкизовская, Красногорск, Химки. Однако, хочется выделить ограничение на передачу в количестве 7 нод: ваше сообщение не увидят люди, находящиеся от вас более чем в 7 хопах (чтобы не захломлять эфир). А так иногда хочется поговорить с другими городами и странами.

К сожалению, количество знаков на пост ограничено. Поэтому, если есть желание более детально углубиться в технологию, могу порекомендовать выпуск 📺 Побединского, где он детально все разъясняет, а также 📺 MeshWorks.

Подводя итог, с моей точки зрения мештастик является хорошо распираеным хайпом: для энтузиастов и верующих в зомби-апокалипсис это хорошая игрушка. Однако, с практической точки зрения данная технология не несет никакой полезной нагрузки, по крайней мере в настоящее время.
Но если вам некуда потратить пару тысяч рублей, я бы предложил приобрести СиБи или иную КВ-радиостанцию, которая по всем показателям перекрывает мештастик: скорость, дальность, полезность (особенно 15 канал АМ ;)

🧠 Обязательно поделись с теми, кому это может быть полезно Телеграм

GlowByte и комьюнити «Сарафан»: возможности ИИ-агентов в CVM-маркетинге

GlowByte и комьюнити "Сарафан" провели масштабную встречу профессионального сообщества, посвященную практическому применению искусственного интеллекта в маркетинге, управлении клиентской ценностью (CVM) и клиентском опыте (CX).

Мероприятие в формате иммерсивного спектакля собрало 250 ведущих экспертов из различных индустрий. Программа объединила театрализованное представление по мотивам «Мастера и Маргариты» и реальные бизнес-кейсы от друзей и партнеров GlowByte.

Участники встречи поделились опытом применения технологий искусственного интеллекта для создания уникального, вовлекающего и экономически эффективного контента, для анализа отзывов о продукции на маркетплейсах, а также для управления рекламными кампаниями. Центральной темой стал переход от традиционных подходов к персонализированным решениям, основанным на данных и машинном обучении. Особое внимание уделили технологии Uplift-моделирования – новому этапу развития ИИ в CVM.

Подробнее о том, как прошло мероприятие, рассказали тут.