Мы продолжаем нашу серию статей, посвящённых фундаментальным концепциям разработки. Сегодня мы поговорим о проверенных практиках, которые помогают разработчикам избегать распространённых ошибок и работать эффективнее. Мы разберём принципы SOLID, а также парадигмы YAGNI, DRY и KISS, которые особенно актуальны в объектно-ориентированном программировании.
Распределенные системы (aka микросервисы) набрали популярность и применяются все шире в современных реалиях. Сервисов становится больше, привычные задачи для них решаются сложнее, усложнились и вопросы аутентификации и контроля доступа.
В статье рассмотрим различные подходы использования API Gateway как части более общего API security-решения в контексте его работы с токенами доступа, выделяя преимущества, недостатки и связанные с ними вопросы безопасности. Также разберем, почему нужно ограничивать область действия access token и может ли API Gateway помочь и в данном вопросе.
Статья написана на основе материала, с которым выступал на PHDays 2025 и CodeFest 15.
Всем привет!
Не так давно вышла статья о том, как Валентин Ульянов aka @misterzsm нанял джуна в свой open source проект. Я и есть тот самый джун Рома (на самом деле я Рамазан).
В этой статье я бы хотел рассказать вам эту же историю, но со своей стороны. В частности, расскажу вам немного о своём бэкграунде, о том, почему я решил согласиться на это предложение, а также отвечу на некоторые комментарии из статьи Валика.
Во многих проектах на Next.js возможности для SEO остаются неиспользованными: страницы индексируются не полностью, структурированные элементы отсутствуют, а ссылки в соцсетях отображаются неправильно. Чтобы этого избежать, существуют проверенные инструменты и подходы, которые помогают сделать SEO понятным, полным и эффективным.
В данной статье рассмотрены ключевые аспекты настройки SEO в проектах на Next.js: работа с метаданными, генерация sitemap и robots.txt, оптимизация изображений и внедрение структурированных данных.
Всем привет, с вами Артем Леванов, Front Lead в компании WebRise.
В прошлой статье мы разобрали, как навести порядок в создании форм — выделили примитивы, ячейки и типовые поля.
Следующая проблема, с которой сталкивается любая форма — валидация.
Формы могут быть красивыми и структурными, но без единого подхода к валидации они быстро превращаются в хаос.
В этой статье поговорим о том, почему встроенные и кастомные проверки плохо масштабируются, особенно в динамических формах, и как Zod решает эту проблему, превращая валидацию в декларативную и типобезопасную систему.
Привет, Хабр!
В последние годы CSS стабильно развивается. По себе знаю, что уследить непросто. По этой причине многие продолжают использовать лишь часть его возможностей, ограничиваясь проверенными годами решениями.
Ничего против них не имею. Просто хочу рассказать о нескольких приёмах, которые вы могли упустить. Они помогут вам в разных ситуациях.
Давайте посмотрим, что я вам подготовил.
Команда JavaScript for Devs подготовила перевод статьи Пола Кинлана о том, почему новые веб-фреймворки сегодня оказываются «мёртвыми при рождении». Автор утверждает: сочетание сетевых эффектов, экосистемы React и обучения LLM формирует замкнутый цикл, в котором альтернативы просто не успевают набрать критическую массу.
Прямая мутация данных — ситуация, когда мы меняем объект или массив по существующей ссылке, не создавая новую копию. В React это одна из самых частых и при этом самых коварных ошибок. Она нарушает принцип неизменяемости (immutability) — если данные изменились, должен появиться новый объект, а старый оставаться без изменений.
На этом принципе строятся ключевые механизмы React: сравнение пропсов и состояния, оптимизации через мемоизацию и предсказуемость ререндеров. Если данные меняются напрямую, часть компонентов не обновляется, появляются случайные баги, а отладка становится сложнее.
В этой статье мы разберем реальные кейсы из практики Modus BI, покажем наш подход и правила, которые помогают исключить мутации на этапе разработки. Гайд поможет вам системно подойти к вопросу и навсегда избавиться от целого класса неуловимых багов.
Команда Python for Devs подготовила перевод статьи о том, как "free-threaded" Python меняет правила игры для веб-сервисов. Автор сравнивает Python 3.14 с GIL и без него на реальных ASGI и WSGI приложениях — и приходит к неожиданному выводу: несмотря на локальные просадки в производительности, "free-threaded" Python уже сейчас может упростить масштабирование и снизить накладные расходы.
Всем привет! Последние несколько месяцев я работаю над пет-проектом — интерактивной образовательной платформой для изучения Web Audio API и принципов обработки и синтеза цифрового звука. На платформе пользователи смогут решать задачи, программируя на JavaScript прямо в браузере. Эти программы выполняются в изолированной среде — песочнице, где пользовательский код не может повлиять на работу самой платформы.
Когда я начал реализовывать песочницу для своего проекта, я быстро понял, что это куда сложнее, чем кажется на первый взгляд. Я перепробовал разные подходы и убедился, что тема изоляции кода в браузере далека от очевидной, а большинство материалов в сети рассматривают её лишь поверхностно. Из моих исследований и экспериментов выросла эта статья — подробный разбор того, как устроены песочницы в браузере и какие архитектурные принципы и нюансы безопасности лежат в их основе.
Пора к части второй! У нас уже есть очень хорошие функциональные тултипы с позиционированием, но они в основном «смотрели» вверх или вниз и смещались у краёв, чтобы избежать выхода за границы. Теперь мы пойдём дальше и рассмотрим четыре позиции без смещений.
Кто я такой и с какой горы прибыл?
Зовут меня Юра и у меня немногим больше семи лет опыта разработки фронта на vue+typescript. Начал я, что забавно, с Angular 5 в далёком 2018, когда пятёрка ещё была актуальной версией, и работал с ним немногим больше пары месяцев, после чего перекатился во vue2.
Работал я исключительно в B2B и внутренней разработке. Системы документооборота, сервисдески и вот это вот всё. Благодаря этому я повидал разного. От DDD, до "паста-болоньезе-код".
На последних двух проектах я наступил в FSD. Методологию для организации кодовой базы выбирал не я, но я честно пытался в ней разобраться и как-то удобно организовать. К сожалению, оба раза код становился проблемой с высокой связностью, неочевидным размещением сущностей и сложно отслеживаемой системой взаимодействий компонентов кода.
При всём этом я наблюдал активный рост популярности FSD методологии в сообществе. Это натолкнуло меня на мысль о том, что я просто недостаточно разобрался, и тогда я начал копать. Смотреть, как же готовят FSD, сравнивать с известными мне архитектурными подходами. В этой статье я хочу поделиться выводами, к которым пришёл, и предложить решения, которые нашёл.
Привет! Недавно начал активно использовать инструмент GitHub SpecKit, который превращает хаотичные промпты при разработке в чёткие структурированные документы для AI-агентов. Я пробовал писать код с использованием LLM и был недоволен как нейросеть пишет код. Придерживался мнения проще самому написать код, чем играть в генерацию кода. Те, кто уже баловался вейкбордингом знают, как нейросеть начинает фантазировать/галлюцинировать и гонять по кругу ошибки в перемешку с фантазиями и не существующими методами. Но SpecKit приятно удивил 😊
Синтаксис сокращённой записи через точку — .foo — позволяет писать более лаконичный Dart-код, опуская имя типа там, где компилятор может вывести его из контекста. Это аккуратная альтернатива полному варианту вида ContextType.foo при обращении к значениям перечислений (enum), статическим членам и конструкторам.
Теперь язык стал еще более лаконичным.
Сегодня мы рады объявить о выпуске Dart 3.10!
В этом выпуске мы продолжаем работать над улучшением базового опыта разработки. Новая функция сокращённых обозначений ( .) поможет вам писать более читабельный и менее многословный код. Мы также представляем мощную систему плагинов-анализаторов , которая позволяет создавать собственные правила статического анализа, интегрируемые непосредственно в вашу IDE. И мы рады сообщить, что хуки сборки теперь стабильны!
В этом выпуске также реализован ряд улучшений pub.dev и управления пакетами. Вы найдёте новые возможности поиска на вкладке «Нравится» в своём профиле, а авторы пакетов теперь могут отключить ручную публикацию для повышения безопасности. Наконец, мы добавили набор новых, более точных аннотаций об устаревании , чтобы вы могли более точно контролировать развитие своего API.
Продолжайте читать, чтобы узнать больше об этих и других улучшениях в Dart 3.10.
Добро пожаловать в наш ежеквартальный релиз Flutter 3.38. Это обновление призвано повысить вашу продуктивность и улучшить взаимодействие с разработчиками благодаря сокращённым точкам и обновлениям для предварительных просмотров виджетов. Благодаря нашему сообществу этот релиз включает в себя в общей сложности 825 коммитов от 145 уникальных участников, 37 из которых — новички. Давайте разберёмся, что же нового в этом релизе.
RAG (Retrieval‑Augmented Generation или генерация, дополненная поиском) — это метод искусственного интеллекта, сочетающий генеративную большую языковую модель (LLM) с внешней базой знаний для создания более точных, контекстно‑зависимых и актуальных ответов. Принцип его работы заключается в том, что сначала извлекается релевантная информация из набора документов или источников данных, а затем эта информация передается в LLM для формирования окончательного ответа. Этот процесс позволяет модели выдавать более точные ответы, менее подверженные «галлюцинациям», и ее можно обновлять без дорогостоящего переобучения.
Сегодня мы разберёмся, как собрать базовую RAG‑систему на PHP (да, да, не надо удивляться) с помощью фреймворка Neuron AI. Это будет наш маленький proof‑of‑concept — минимально работающий, но вполне реальный пример.
Ну что, начнём генерацию?
Разбираюсь, пришло ли время нового интерфейса: как ИИ‑чаты, параллельные маршруты и слотовая архитектура меняют роль сайтов, дизайнеров и разработчиков.
Представьте: вы строите систему верификации дипломов. Требования простые — данные должны быть неизменяемыми (привет, блокчейн) и при этом быстро доступными для запросов (привет, PostgreSQL). Казалось бы, идеальное решение — писать в оба хранилища. Но дьявол, как всегда, кроется в деталях.
Наш проект использует паттерн двойной записи (Dual-Write):
Solana — гарантирует неизменность и прозрачность данных о выданных дипломах
PostgreSQL (Supabase) — обеспечивает быстрые выборки и сложные запросы
Звучит красиво на архитектурных диаграммах, но в production всё не так радужно. Главная проблема — частичные сбои. Транзакция в Solana прошла успешно, диплом записан в блокчейн навечно, а вот запись в PostgreSQL упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает.
Сегодня я покажу, как мы столкнулись с этой проблемой лицом к лицу и какие паттерны применили для её решения.
На протяжении десятилетий в массовой культуре укоренилась идея о разделении мозга на два полушария — аналитическое «левое» и творческое «правое». Согласно этому упрощенному взгляду, люди и, соответственно, их профессиональный выбор делятся на два лагеря: логичные «технари» с доминирующим левым полушарием и образные «гуманитарии» с ведущим правым.
