Представьте себе: вы закончили большую задачу, написали много строк кода, проверили всё, даже подумали над названием каждой переменной! Но откладываете создание PR на день, два, три…из-за того, что не хочется идти в ревью и получать критику?
А мне такое и представлять не надо. Я испытываю подобное почти перед каждый своим ревью, даже спустя 6 лет в разработке.
Просыпаюсь утром, открываю ленту - и сразу два инцидента. Оба про npm. Оба серьёзные. И оба произошли в один день.
Первый - в Axios (да, тот самый, который стоит вообще везде) три часа раздавал RAT-троян. Второй - Anthropic случайно выложила полные исходники Claude Code в публичный npm. Полмиллиона строк с промптами и архитектурой.
Вот и доброе утро)
Ошибки в API часто воспринимаются как второстепенная часть контракта – до тех пор, пока интеграции не начинают ломаться в самых неожиданных местах. В этот момент выясняется, что одного HTTP-кода недостаточно: без ясной структуры и контекста ошибки превращаются в источник неопределённости и лишней работы. В статье разберём, как проектировать ошибки как полноценный элемент API – с понятной семантикой, единым форматом и возможностью для автоматической обработки.
В Symfony есть встроенный компонент Serializer, который покрывает 90% задач. Но его часто обходят стороной, то ли по привычке, то ли из-за того, что документация показывает только тривиальные примеры. А между тем, Serializer — гибкий и вполне годный инструмент, если понимать его архитектуру.
Разберём, как он устроен.
Я запустил сайт. Не шаблон на Tilda, не одностраничник на Notion - полноценный статический сайт на Astro, с блогом, лендингом продукта и двумя языками. И прежде чем написать первую статью в блог, я потратил непропорционально много времени на то, чтобы этот сайт правильно видели поисковики - и, что важнее, языковые модели.
Эта статья - о том, что я настраивал, зачем, и почему в 2026 году одного SEO уже недостаточно.
Здравствуйте, товарищи! Продолжаю писать о своих приключениях в мире open source. Сегодня речь пойдет о маркетинге, а точнее: про один из каналов - площадки для стартапов, типа Product Hunt.
Расскажу про свой опыт запуска open source проекта на трех таких площадках. Как готовился, что вышло, и стоила ли игра свеч. Рассказ пойдет в хронологическом порядке, но больше информации будет про одну из площадок, которая нам казалась важнее и с которой мы получили больше профита.
Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз.
Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..
Что происходит с индустрией прямо сейчас. Агенты, Manus, личный опыт и честный ответ — стоит ли паниковать. Взял идею стартапа, скормил агенту — через 20 минут получил рабочий код. Это круто или страшно? Давайте разбираться.
В экосистеме JavaScript произошёл серьёзный инцидент, который хорошо показывает, насколько опасными стали атаки на open source и цепочки поставок. Исследователи StepSecurity сообщили о компрометации axios — одной из самых популярных HTTP-библиотек в npm (~83 миллионов загрузок в неделю). Злоумышленник получил доступ к аккаунту одного из ведущих мейнтейнеров проекта и опубликовал две вредоносные версии пакета: axios@1.14.1 и axios@0.30.4.
На первый взгляд это выглядит как обычное обновление зависимости. Но на деле установка этих версий могла привести к заражению системы трояном удалённого доступа.
Представьте себе, что вы разработчик, и перед вами стоит задача: сделать так, чтобы после входа пользователь мог получать свои личные данные, не вводя пароль при каждом клике. Звучит как классическая задача аутентификации, правда?
Традиционный подход — сессии. Вы логинитесь, сервер создаёт сессию, запоминает ваш ID у себя в базе данных, а вам выдаёт куку с ID этой сессии. Всё работает, пока вы на одном сервере. А если у вас их два? Или десять? Куда девать сессии? Начинаются проблемы с синхронизацией, Redis, общими хранилищами…
Альтернатива — JWT (JSON Web Token). В этой статье мы с вами:
Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же core-разработчик фреймворка Litestar, пакета django-stubs и множества других пакетов для Django.
Сегодня я расскажу, как мы сделали самый быстрый и самый семантически корректный фреймворк для создания апишек на Джанго. Поговорим про конкурентов, покажу очень крутые интеграции, поделюсь своей философией и правилами, которые использовались для создания фреймоврка, ну накину на вентилятор для интереса.
Если хотите похоливарить в коментах на тему того, какой фреймворк самый лучший и удобный – залетайте! Обсудим.
Привет, Хабр!
CSS часто преподносит сюрпризы, способные запутать даже опытных разработчиков. Я понимаю их раздражение. Тут всё закономерно.
Как человек, хорошо знающий CSS, могу сказать, что он умеет удивлять. Причём так, что в замешательстве оказываются даже опытные разработчики. Поэтому я понимаю разные мемчики по поводу CSS. Они возникли не на пустом месте.
И всё же, несмотря на все потраченные нервы, CSS мне нравится. Поэтому хочется, чтобы разработчики реже тратили время на борьбу с его особенностями. Изменить стандарты языка не в моих силах, но я смог собрать несколько неочевидных моментов, которые в своё время поставили в тупик меня и моих коллег.
Пришёл поделиться с вами. Давайте посмотрим, что я подготовил.
BIP39 вместо номера телефона, ECDH P-256 + AES-256-GCM, non-extractable CryptoKey, трафик неотличимый от HTTPS. Как это устроено, что сломалось в процессе и почему некоторые решения были болезненными.
Привет, я — Александра, юрист для digital-агентств и фрилансеров! Специально для всех владельцев сайтов я подготовила подробную статью о том, какие юридические документы должны быть на каждом сайте в зависимости от его вида и наполнения. Прочитав её, вы точно всё поймёте.
Мне нравится писать тесты. Написание теста и последующее обновление кода для его прохождения — всегда увлекательный процесс.
Но нет ничего хуже, чем выяснение того, что проверяют существующие тесты (раньше я сам часто был автором таких тестов).
Представляю вашему вниманию мои советы по написанию высококачественных тестов для фронтенда.
“Долг понимания” (comprehension debt) — это скрытая цена, которую человеческий интеллект и память платят в результате чрезмерной зависимости от ИИ и автоматизации. Для инженеров это особенно актуально в сфере разработки агентных систем.
Когда команды активно используют инструменты для генерации кода с помощью ИИ, возникают определенные издержки, которые не отражаются в показателях производительности. Особенно это касается случаев, когда проверка всего кода, генерируемого ИИ, становится утомительной. Эти издержки накапливаются постепенно, и в конечном итоге их приходится оплачивать — с процентами. Это называется “долг понимания” или “когнитивный долг”.
Мне очень не нравится термин. Он подсознательно «сужает» взгляд на ИИ и ограничивает его использование.
«Когда у вас в руке молоток, все становится похожим на гвозди».
Вайб‑кодинг словно бы говорит: «Иди и программируй!»
Есть данные, и нужен какой‑то отчет? Иди вайбкодь! Бэкенд, фронтенд, VPS, вот это всё. А зачем, если тот же ИИ можно просто попросить сделать Excel файлик с нужной структурой и нужными формулами? И он будет понятнее, с ним можно будет работать в будущем, его можно отдать кому‑то, не решая вопросы про доступы, безопасность и тому подобное
Хотите запустить блог или какой‑то контентный проект? Иди вайбкодь! Изучай Next.js, Sanity, Supabase, Vercel! Деплой, отлаживай! Но зачем, если можно взять хоть Ghost, хоть WordPress, с помощью того же ИИ получить рекомендации по нужным плагинам и темам, настроить всю верстку, и получить понятное обновляемое решение?
Ну что, расскажем, как всё начиналось? Даже не знаю, рассказать правду или как оно было на самом деле. В любом случае, получится предельно личный мемуар об эволюции новосибирского Digital-рынка. Поскольку я в «продвижении» сайтов обитаю с 2003 года, на роль компетентного наблюдателя, который видел рождение, смерть и реинкарнацию десятков алгоритмов, бизнесов и специалистов, я как минимум подхожу.
Мой опыт показал, что этот простой на первый взгляд механизм часто вызывает неожиданные сложности в реализации. Когда в дискуссиях меня начинают спрашивать почему, приходится долго объяснять. Поэтому решил создать эту статью как ликбез, да и чтобы в процессе свои мысли структурировать для будущих аргументов.
TLDR;
Использование SaaS в авторизации и аутентификации пользователей для решений не ограниченных контуром предприятия имеют самую большую эффективность и удобство. (можно промотать страницу в самый конец - там будет сравнительная таблица)
Когда разработчик приходит в Next.js из обычного React SPA, он часто тащит с собой старую схему мышления. Есть поле ввода, значит будет useState. Есть поиск, значит будет useEffect. Есть список данных, значит будем следить за изменением состояния и вручную запускать новый запрос.
На маленьком экране это вроде работает. Но очень быстро выясняется, что в приложении уже не одно состояние, а три. Есть значение в поле, значение в URL, данные, загруженные по одному из этих значений. Потом появляется четвёртая проблема. Кнопки Back и Forward начинают вести себя странно. Ссылкой на результат поиска неудобно делиться. А отладка превращается в угадайку, потому что не до конца понятно, что именно сейчас считается главным источником правды.
В App Router это решается проще. Если фильтр является частью состояния страницы, его логично держать в URL. Тогда схема становится прямой: URL изменился -> сервер прочитал searchParams -> выполнил fetch -> отрендерил новый список. В этот момент Next.js начинает восприниматься как понятный инженерный инструмент.
