Пятница, 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.
Зачем на свете нужен ещё один трекер привычек? Их же и так - на любой вкус и цвет. Проблема в том, что ни один из них не нравился моей жене, поэтому пришлось в список идей для пет-проектов добавить и его.
Последние полгода я активно применяю LLM в своей работе. Автокомплитом от Github Copilot я пользуюсь с момента начала бесплатного бета-тестирования, а с выходом Opus 4.5 стало возможно отдавать железяке на реализацию целые блоки логики. Нужно только организовать виртуальную клетку, внутри которой он будет вынужден писать работающий код.
Когда я начал поднимать PostgreSQL через Docker для своих проектов, всё выглядело просто: описал сервис в docker-compose.yml, запустил контейнер - база доступна.
Проблемы начались когда, я начал запускать миграции вместе с контейнерами. Иногда миграции стартовали раньше чем PostgreSQL успевал принять подключения, и приложение падало с ошибкой подключение к базе данных.
Несколько лет, я экспериментирую с генераторами картинок. Меня интересует один вопрос: можно ли из нейронок получить приемлемые концепт-дизайны сайтов,приложений, интерфейсов? Не с точки зрения кода, а хотя бы лэйаутов, цветовых схем и баланса текста/графики.
Онлайн доска DGRM.net кеширует файлы в постоянном кеше. Постоянный кеш не удаляется при закрытии вкладки. Рассказываю как хранить большие файлы в браузере.
Полтора года назад я работал в B2C-продукте с командой около 150 человек. Маркетинг хотел запускать промо на сайте: баннеры, акции, сезонные кампании. Простая задача, на которую у нас ушло два с половиной года и шесть разных решений.
Эта статья про путь, который мы прошли. И про то, что я обнаружил, когда поговорил с другой командой внутри той же компании.
Новый проект, фреймворк, с которым не работал несколько лет, приложение в процессе миграции. Раньше на погружение уходил месяц. В этот раз — неделя.
В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами.
Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки.
Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов.
Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками.
Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.
Если вы пишете на Angular, то наверняка часто используете хуки жизненного цикла вроде ngOnChanges, ngOnInit и ngOnDestroy. С появлением сигналов и концепции Zoneless (когда Zone.js уже не обязателен) у нас появились более элегантные и читаемые альтернативы.
Давайте разберем, как современный подход позволяет упростить код и избавиться от "шумных" методов жизненного цикла.
Молодые разработчики, а иногда и опытные, стремясь сделать код «идеальным», часто уходят в оверинжиниринг и создают трудночитаемые конструкции. В итоге на реализацию уходит больше времени, а поддержка превращается в хард-квест с поиском ответов.
Если и у вас есть желание написать какую-нибудь сложную абстракцию «на будущее» или применить новый паттерн просто потому, что вы его выучили — остановитесь на секунду.
В этой статье мы собрали все, что поможет писать код, который не стыдно показать тимлиду и легко развивать дальше.
Всем привет. Я занимаюсь фронтендом в небольшой команде сервиса бронирования отелей. Хочу как я 8 дней ловил утечку памяти на проде, несколько раз думал, что починил, и каждый раз ошибался. А последний фикс был не в нашем коде, а в патче самого Vue, который через неделю апстрим откатил как регрессионный. У нас в результате осталась одна патч-версия, в которой утечки нет; обычный minor/patch update сейчас для нас не безопасен без повторной проверки heap-снапшотами.
Наш стек Nuxt 3.18 + Vue 3.5.x + TypeScript, SSR, Pinia, PM2 cluster, nginx перед Node. Обычный каталог отелей с тысячами SEO-страниц вида /oteli-v-{город}/{подборка}
