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

Спойлер: кажется SHA1 устарел, а туториалы этого еще не знают

Привет всем.
Для контекста: я не программист. Я гуманитарий, который до безумия боится цифрового неравенства, которое уже наступает. Поэтому, вооружившись AI‑агентом (Cursor) и бесплатными Claude, Gemini, DeepSeek пытаюсь быть в тренде (некоторые называют это вайб‑кодингом). Признаться я тоже думал, что это что‑то легкое, «вайбовое» — главное, все внятно описать, что ты хочешь. Но по факту в том, что происходит, всё равно приходится разбираться самому.

Свежий пример моих «грабель» — решил прикрутить оплату ЮМани.
Казалось бы, ЮМани, всё придумано до меня. Но есть нюансы...

Я выпал из IT на месяц. Причина банальна, но сурова – капитальный ремонт. По квартире проложено пара километров кабеля, из них 600 метров витой пары для шины управления, на полу разложен макет двух щитов по 54 модуля общей стоимостью под 150 тысяч рублей – и чем глубже я лезу в ПУЭ и считаю сечения, тем чётче одна мысль: если бы инженеры-электрики проектировали системы так же, как мы, разработчики, проектируем распределённые приложения – мы бы все давно сгорели заживо.

Я хотел просто повторить одну обложку в разных сервисах. Но быстро выяснилось, что сама PNG-картинка — только середина пути. Главное начинается дальше: как подставить новый заголовок, куда сохранить файл и кто в итоге пропишет правильный og:image в WordPress.

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

В статье — практический опыт создания LLM Wiki на стеке Astro + Starlight + Markdown. Без Notion, без Google Docs, без проприетарных форматов. Контент — просто файлы, AI-агенты — редакторы с четкими правилами из AGENTS.md, хостинг — бесплатный GitHub Pages.

Месяц назад я уволился из аутсорса и решил, что найду работу за 2–3 недели. Три года опыта, фуллстек, React + Node, пара нормальных проектов в портфолио. Казалось бы — садись и выбирай.

Через 4 недели у меня было 15 собеседований, 2 оффера, 6 молчаний без ответа и один рекрутер который прислал отказ на вакансию на которую я не откликался. Записывал всё в заметки потому что к 10-му собесу уже начал путать компании. Вот что получилось.

Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.

Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.

На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.

Финальная часть серии — про самое нервное в любом ecommerce-проекте: как включать новую архитектуру по частям, не устраивать «большой релиз» и не останавливать продажи. 

К этому моменту у нас уже есть SSO, события, наблюдаемость, быстрый каталог, корзина, цены, checkout, интеграции, Gateway и SDK. Теперь начинается самая чувствительная часть — включать все это в продакшен без большого релиза или остановки продаж.

Сложность — в процессе. Один модуль уже готов, второй еще нет, часть трафика ходит по старому пути, часть — по новому… Поэтому я сделала практическую схему постепенного включения: фича-флаги, канареечный трафик, двойное чтение, shadow-режим и критерии готовности.

Миграция большого legacy-проекта с Vue 2 на Vue 3 — это не только про код. Основная сложность начинается ещё до первого коммита: оценка объёма работ, поиск несовместимых API, планирование и организация процесса разработки.

Почему вообще это важно, и как донести эту мысль до бизнеса я уже описывала в другой своей статье «Ты всё ещё думаешь или уже мигрируешь на Vue 3». Рекомендую почитать.

А тут я поделюсь своим опытом, где мне пришлось лидировать миграцию: самостоятельно составлять план миграции, оценку времени, рисков и проводить саму миграцию.

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

Когда проект на Next.js только начинается, прямой fetch во внешний API кажется самым коротким путём. Есть страница списка, есть поиск, есть внешний источник данных, значит можно сходить туда напрямую и сразу показать результат.

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

В App Router такую роль часто закрывает Route Handlers. В официальной документации Next.js они описаны как пользовательские обработчики запросов внутри app directory на основе стандартных Web Request и Response API. Они доступны только в app, по смыслу заменяют старые API Routes из pages и поддерживают GET, POST, PUT, PATCH, DELETE, HEAD и OPTIONS. (Next.js)

Смысл Route Handlers в том, что они позволяют собрать внутренний серверный контур прямо внутри приложения. Через него можно проксировать внешний API, нормализовать ответ под нужды UI, спрятать env-переменные и секреты, а также вернуть в интерфейс уже свой контракт, а не чужой.

Пятница, 18:00. Вы обновляете PHP на сервере с 7.4 на 8.0 — что может пойти не так? Деплой проходит, страница обновляется, и вместо привычного портала вы видите белый экран с TypeError: array_search(): Argument #2 ($haystack) must be of type array, null given. Мессенджер разрывается от сообщений: «Ничего не работает». Знакомо?

У вас один SSG-лендинг, а платный трафик льётся из 12 кампаний под разные боли ЦА. Все ведут на дефолтный hero — конверсия в заявку проседает на 30–50%. Делать 12 лендингов дорого и убивает SEO, подменять hero на клиенте — FOUC и дефолт для поисковых ботов.

Рабочая схема, поставленная в продакшен за день: edge-функция Cloudflare Pages переписывает HTML на лету через HTMLRewriter, SSG остаётся источником истины, client-side React дублирует логику при гидратации. 200 строк кода, латенси без изменений (HTMLRewriter работает потоком), Lighthouse не страдает. Разбираю код, нюансы интеграции с vite-react-ssg и грабли из прода.

Принципы SOLID, DRY, KISS во фронтенде работают ровно так же, как в любой другой разработке. Но если открыть почти любой проект, всё равно натыкаешься на мешанину.

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

На примере такой вещи, как store попробуем ответить на вопрос: что вообще такое контракт, зачем же нужна типизация и действительно ли это помогает в разработке.

Недавно я решил завести собственный блог. Сначала посмотрел в сторону SSG, но они показались мне не слишком удобными для того сценария, который я хотел получить. Затем попробовал несколько CMS, однако быстро упёрся в другую проблему: мой сервер оказался слишком слабым для большинства современных решений.

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

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

За последние два года в экосистеме PHP вокруг AI-разработки сформировалась целая индустрия. Если раньше интеграция LLM выглядела как несколько строк кода с вызовом OpenAI API, то сегодня разработчики строят полноценные агентные системы: с памятью, инструментами, workflow, наблюдаемостью (observability) и даже командами специализированных агентов.

Обычно, когда говорят об AI-разработке, в первую очередь говорят о Python. Тут полно интересных вещей, таких как: LangChain, LangGraph, CrewAI, AutoGen – весь основной шум долгое время происходил именно там.

Но параллельно интересная история развивается и в PHP. И меня это, безусловно, очень радует.

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

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

В предыдущей публикации я представил веб-инструмент для построения линий влияния в многопролётных шарнирных балках. Инструмент позволяет визуализировать линии влияния поперечных сил Q, изгибающих моментов M и реакций опор R, а также получать численные значения для любого заданного сечения.

Теперь — следующий шаг.

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

Привет, Хабр! Меня зовут Сергей Зиновьев, я бизнес-партнёр по информационной безопасности в Авито. Если какие-то сканы на безопасность кода легко автоматизировать, то с уязвимостями на этапе проектирования всё обстоит сложнее. Для превентивного выявления подобных проблем организации и сообщества вроде NIST и OWASP рекомендуют использовать моделирование угроз в рамках своих гайдлайнов и фреймворков. В нашей практике это довольно творческий процесс, требующий понимания как продуктовой, так и технической стороны.

В Авито мы масштабировали этот процесс на 2500+ инженеров, и сегодня я расскажу, как мы к этому пришли — с какими сложностями столкнулись, какой фреймворк выработали и как адаптировали его под реальные потребности продуктовых команд.

Речь не об очередном проекте, сделанном за один вечер, и не о «чудесах» вайбкодинга. Это довольно большой проект, который я реализовал в одиночку: без единой самостоятельно написанной строки кода и без привлечения каких-либо специалистов.

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

Летом прошлого года открыл для себя Claude Code и решил попробовать создать что-то свое. Выбрал понятную и знакомую сферу и начал ковыряться.

Надеюсь, мой опыт и эта история окажутся кому-то полезными.

Сделать текстовую игру на базе LLM легко, если вас устраивает бесконечный неконтролируемый чат, который ломается через 30 ходов из-за модельного дрейфа и амнезии. Сделать полноценную RPG с детерминированными механиками, инвентарём, картой-графом и пермадезом — инженерная задача.

Ниже — подробный разбор архитектурных решений, юнит-экономики, борьбы с гонками данных и инфраструктурных грабель, собранных при разработке проекта «Стирая Грань» (Beyond The Verge) — полностью русскоязычной AI RPG на стеке FastAPI + PostgreSQL/pgvector + Flutter Web.

Перехват HTTPS — это техническая концепция и хакерская техника, которая заключается в обходе шифрования TLS для инспекции защищённого трафика. Таким образом, злоумышленник может активировать DPI незаметно для владельца сайта и его посетителей — и эффективно просматривать их трафик в то время, как они будут уверены в своей защищённости.

На практике атака более десяти лет производится через обман Удостоверяющих центров (УЦ), такого как Let’s Encrypt. На первом этапе злоумышленник заставляет их выдать TLS-сертификаты для доменов, которые им не принадлежат, перехватывая запросы ACME-HTTP-01. Для атаки уязвимы все УЦ, которые используют ACME.