Веб-разработка *

5-я статья из цикла туториалов о кастомизации своего бизнес-портала в Битрикс24.

Сегодня возьмём наш шаблонный репозиторий для AI-разработки и сделаем на его основе чат-бота. Боту можно написать в мессенджере и научить его делать разные полезные вещи: давать информацию по сделкам, задачам и другим деталям бизнеса. 

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

Что есть в других статьях на сегодня: 
1. Пишем первое приложение с AI-стартером, чтобы видеть прибыли и убытки
2. Добавляем в бизнес-портал Битрикс24 роботов для автоматизации
3. Что даёт воспроизводимая среда разработки и как развернуть контейнеры на VPS 
4. Анализ и модернизация коннектора баз данных с помощью AI-агентов
5. Создание чат-бота в портале Битрикс24 с помощью AI-агентов (вы здесь)

Расходы на AI API копятся незаметно: сессия Claude Code тут, batch к GPT-5 там — и к концу месяца биллинг удивляет. Собрал бесплатное Chrome-расширение, которое показывает траты Anthropic, OpenAI и Gemini в реальном времени прямо в badge браузера.

Продолжаем разбирать HikariCP: как выбирать размер пула, что учитывать в Kubernetes и при нескольких сервисах, почему большой maximumPoolSize не всегда помогает, какие настройки стоит пересмотреть перед продом и какие ошибки чаще всего приводят к проблемам с базой.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Сегодня я хочу поделиться историей создания одного интересного проекта — клиента для облачного сервиса Ollama.

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

Мне нравится рассказывать про HTML и CSS. Отдельное удовольствие — находить очень старые фичи языков, о которых редко кто знает. Сегодня я пришёл как раз с ними.

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

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

Давайте посмотрим, что я подготовил.

В Go легко написать код, который компилируется, но раздражает при чтении: слишком длинные receiver’ы, странные имена пакетов, лишние повторы в вызовах, хаотичный регистр и utils, который постепенно превращается в свалку. Для начинающего Go-разработчика соглашения по именованию могут выглядеть как набор мелких вкусовых правил, хотя на практике они влияют на навигацию по проекту, читаемость API и стоимость будущего рефакторинга.

В статье разберем основные правила и идиомы именования в Go – от идентификаторов и пакетов до методов, интерфейсов и геттеров – с примерами удачных и неудачных решений.

Не успели мы анонсировать долгожданную интеграцию ZentrySpace с Telegram, как случилось то, к чему нас жизнь точно не готовила — зловещее уведомление у скачивающих от «Лаборатории Касперского» о наличии трояна в приложении. По мотивам недавних реальных атак в Telegram, в борьбе с которыми Касперский преуспел, наши потенциальные пользователи, конечно же, насторожились. После получения серии отзывов о том, что ZentrySpace вредоносный и подозрительный, мы начали разбираться в том, что же могло пойти не так.

У нас в комьюнити билдеров я постоянно вижу одну и ту же ошибку. Человек строит продукт, выкатывает, а потом идёт сливать деньги в рекламу. Экономика не сходится, продукт замораживается.

Ребята из ViralMaxing прошли этот путь на предыдущем проекте — привлекли у инвест-фонда 30 миллионов, успели влить пару миллионов в платный трафик, экономика не сошлась, проект заморозили. А потом сделали новый сервис и раскрутили его через закрытые телеграм-клубы. Вход — 5000 рублей.

Передаю слово основателю — Илье Дрозду.

В ноябре наш сервис ViralMaxing закрыл 6000 долларов ежемесячной выручки. К марту вышли на 15 000. Нас двое плюс помощница: я занимаюсь клиентами и маркетингом, мой партнёр Лёша пишет весь код. Инвестиций нет, рекламу не покупали. Расходы на инфраструктуру — около 1200 долларов в месяц.

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD — архитектурной методологии для проектирования фронтенд-приложений.

В конце статьи есть ссылки на другие подходы к организации файловой структуры фронтенд-приложений.

Я работаю проджект‑менеджером в крупной IT‑компании. Я за вечер сделал то, на что раньше ушло бы несколько месяцев работы целой команды. И этот опыт полностью поменял мое отношение к роли разработчика.

Действия ИИ-агента в браузере через скриншоты и клики — минута и десятки центов. Через WebMCP — секунды и доли цента. Два порядка разницы.

Так что же под этим черновиком стандарта WebMCP и куда он нас ведёт?

Делимся рабочим рецептом: SEO‑блог на 84 страницах в трёх языках (RU/KK/EN) через Claude API за три дня. Внутри — почему мы храним статьи как TypeScript‑объекты вместо Markdown, как собрать system prompt на 360 строк, чтобы Claude корректно ставил internal‑ссылки, как генерим уникальные OG‑обложки через Gemini + PIL, и где AI стабильно косячит те 30% работы, которые всё равно делает человек.

Мы живём в эпоху смены парадигмы взаимодействия человека с сетевыми системами, смены того, как люди подтверждают то, что они те, за кого себя выдают. Главные вопросы, которые всегда задавали пользователям, звучали так: «Что вы знаете?» (пароль, PIN-код, девичья фамилия матери), или «Как вы выглядите?» (Face ID, отпечатки пальцев). Теперь же на первый план выходит такой вопрос: «Как вы себя ведёте?».

В наши дни развитие генеративного ИИ и прогресс в разработке вредоносного ПО, вроде RAT (Remote Access Trojan, троян удалённого доступа), позволили киберпреступникам проводить широкомасштабные атаки и даже обходить такие механизмы безопасности, как Face ID или MFA (Multi-Factor Authentication, многофакторная аутентификация, МФА), которые ранее считались «пуленепробиваемыми».

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

Продолжение прошлой статьи про ошибки на Go-собесах. В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”.

Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26.

Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

Я раньше был уверен, что понимаю, как работает отслеживание в интернете. Очистил cookies - чист. Включил VPN - спрятался. Поставил блокировщик - стал почти невидимым. Звучит логично, правда?

Проблема в том, что всё это работает только на уровне, который уже давно не является основным.

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

И самое неприятное - этот отпечаток можно получить без cookies, без авторизации и даже без твоего явного согласия. Ты можешь открыть сайт впервые, но для системы ты уже «кто-то знакомый».

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

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

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

«Дуров, верни стену» – мем старый, но точный. ВКонтакте начала 2010-х была, при всех своих недостатках, одним из последних мест в рунете с по-настоящему живой лентой. Не алгоритмической, не персонализированной до тошноты – просто всё подряд от всех, на кого подписан. Новости соседствовали с мемами, мемы – с чьей-то репостнутой статьёй про квантовую физику, которую ты никогда не дочитаешь, но пролистаешь с удовольствием. Была случайность, была живость, был сам факт того, что ты не знаешь, что увидишь следующим.

Потом ВК превратился в то, во что превращается каждая платформа – в алгоритмический прямоугольник, оптимизированный под время на сайте. Мы переехали в Telegram. Telegram честнее: хронологический порядок, никакого умного ранжирования, читаешь то, на что подписался. Но одна вещь так и не появилась – единая лента. В ВК у тебя была стена, куда всё стекалось само. В Telegram двадцать каналов – это двадцать отдельных мест, которые надо обходить руками каждый день.

Папки? Пробовал. Папки – это шкаф. Они раскладывают каналы по полочкам, но за каждой полкой всё равно надо открывать каждый ящик отдельно. Единого потока нет.

Ботов-агрегаторов в маркете штук пять – все сломаны по одной и той же причине: Bot API физически не видит каналы, в которых бот не является администратором. То есть публичный новостной канал с миллионом подписчиков – недоступен. Бот читает только то, куда его добавили руками, а никто не добавляет чужих ботов в админы своих каналов. Логично, но бесполезно.

В какой-то момент я окончательно устал и собрал своё.

Обзор на браузерные API, которые стали Widely available в апреле 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем.

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

Вайбкод это круто, пока не открываешь первый отчёт сканера безопасности и не видишь 234 проблемы. В статье разберём, как выстроить пайплайн вокруг LLM-проекта: подключить SAST-инструменты, настроить Quality Gate как блокировщик деплоя и использовать модель для исправлений — не вместо инструментов, а поверх них. Покажу на реальном проекте с реальными цифрами. Будет полезно тем, кто активно использует LLM для написания кода, и специалистам в области appsec/devsecops.

Часть 1 — контекст, данные из отчёта DryRun Security и немного теории про DevSecOps.

Часть 2 — подключаем SonarCloud, настраиваем Quality Gate, интегрируем в CI/CD.

Часть 3 — первый скан реального проекта: 234 проблемы, как их разбирать и исправлять через Claude 4.6.

Часть 4 — добавляем Semgrep, смотрим, где инструменты расходятся и где ломается подход.

С кэшированием в Next.js обычно случается одна и та же история. API уже отдаёт новые данные, страница открывается заново, а на экране всё ещё старая версия. После этого в код быстро добавляют cache: "no-store", данные начинают запрашиваться на каждый заход, и через пару минут появляется уже другой вопрос - зачем тогда вообще нужен встроенный механизм кэширования.

Проблема в том, что кэширование обычно звучит как одно явление, а на практике в App Router похожие ощущения могут давать разные уровни поведения. Навигация назад и вперёд может переиспользовать клиентский кэш маршрута, сам маршрут может рендериться по-разному, а серверный fetch в Next.js имеет собственные стратегии кэширования и перевалидации. В актуальной документации это уже разделено на новый режим с Cache Components и на прежнюю модель без них. В этой статье речь именно о привычной модели App Router без Cache Components, где поведение обычно задаётся через fetch, cache, next.revalidate и route segment config. (Next.js)

Полезнее всего разбирать такую тему не с теории, а с наблюдения. Не с вопроса как устроены все слои кэша в Next.js, а с вопроса почему на одном и том же маршруте иногда обновляется рендер страницы, а иногда обновляются данные, и это не всегда одно и то же.

Для примеров ниже используется проект Goods Finder и внешний API DummyJSON. Идея - сначала добавить на страницу штамп серверного рендера, потом отдельно показать момент получения данных, а уже после этого сравнить force-cache, no-store и revalidate.