JavaScript *

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

Часто в компонентах можно встретить такой код:

В данной статье мы подробно рассмотрим процесс настройки среды unit-тестирования веб-приложений на базе React и Next.js с использованием Jest и React Testing Library. Мы расскажем об установке необходимых зависимостей, создании конфигурационных файлов, настройке Babel и TypeScript, подключении SCSS и SVG, а также организации структуры проекта. Особое внимание уделено специфике настройки Jest в среде Next.js. Материал будет полезен для frontend-разработчиков и команд разработки, которые работают с React или Next.js проектами и хотят внедрить качественное unit-тестирование. 

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

Кажется, мы окончательно запутались в терминах.

За последнюю неделю меня назвали вайб-кодером раз 20. Не то, чтобы меня это как-то оскорбляло, каюсь, пишу код в Cursor, но просто... Это ведь не так - просто по определению. Похожие чувства я испытывал, когда хакатонами стали называть любые мероприятия с кодингом, а их участников - хакерами. Но язык - штука живая, и писать душную статью о том, как мы все неправильно юзаем термины - точно не то, на что я хочу убить вечер воскресенья.

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

Представляю vue-dnd-kit/components — готовые компоненты для быстрой разработки drag & drop интерфейсов в Vue 3!

📋 Сортируемые таблицы
📊 Канбан-доски
🌳 Древовидные структуры
🧩 Интерактивные дашборды

CLI работает как shadcn/ui — компоненты клонируются в ваш проект, давая полный контроль над кодом. Проект в активной разработке, но уже готов к использованию!

Готовые компоненты: Table, Kanban, Tree, Dashboard.

Статус: бета, API может изменяться. Подходит для прототипов и активной разработки.

Эта статья поможет вам быстро написать API, используя Express и Prisma). Для этого вам понадобятся базовые знания работы с Node.js и понимания разработки реляционных баз данных

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

Тут я расскажу о том, как я впервые с нуля поднимал проект на React, используя связку FSD, TanStack Router, TanStack Query и Effector — и как мы всё это далее подружили подружили или нет 🙂.

Сразу оговорюсь:
Проектом занимается команда, но архитектурный старт, выбор технологий и базовая структура — легли на меня. Это был мой первый опыт в такой роли: отвечать не просто за компоненты или страницы, а за фундамент проекта.
А так же, это моя первая статья. Не претендую на истину в последней инстанции, но надеюсь, кому‑то мой опыт будет полезен и палками бить сильно не будете.

Всем привет! Я — разработчик и велосипедист, которому надоели ограничения Strava. Знакомы боли: GPS‑треки с «телепортами», платный анализ по зонам и неудобная загрузка сегментов на Garmin? Я решил исправить это и написал свой «швейцарский нож» для анализа тренировок.

Под катом — история создания pet‑проекта Peakline на Python, FastAPI и Vanilla JS. Расскажу, как устроен продвинутый FIT‑генератор для гонок с «призраком», как визуализировать исправление «сломанных» GPX‑треков и как заставить график и карту работать в связке. Поделюсь фрагментами кода, архитектурными решениями и подводными камнями при работе с API Strava.

🧠 Русскоязычные LLM для вызова инструментов, переводов и финансовой аналитики

Подборка моделей, которые действительно позволяют отказаться от OpenAI и вести разработку в закрытом контуре без подключения к интернету 🔌

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

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

Позже я добавил NPC с простым AI: они могут преследовать игрока, если тот находится рядом. В этой статье речь пойдёт только о построении пути.

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

Если вы работаете с Vue 3, вы точно сталкивались с ref() и reactive(). Обе функции из Composition API делают значения реактивными — но делают это по-разному. И хотя документация Vue чётко указывает, что использовать в каком случае, она редко объясняет, почему это важно и что может пойти не так, если использовать не тот инструмент.

Вот ссылки на официальную документацию — на всякий случай:

Для автоматического предотвращения переносов после коротких слов можно использовать JavaScript, который заменяет обычные пробелы на неразрывные пробелы ( ) после определённых слов.

В результате проведенного мной исследования безопасности 3000 российских frontend-приложений было обнаружено, что CMS Битрикс более 11 лет передает персональные данные посетителей сайтов на территорию Ирландии. Компании рискуют получить штрафы Роскомнадзора за трансграничную передачу данных без уведомления регулятора.

Автоматизация тестирования API — задача, с которой сталкиваются даже опытные инженеры, но многие всё ещё предпочитают полагаться на ручные запросы в Postman, а затем переносят их в код — и так годами. Но можно ли избежать этого лишнего шага? В этой статье мы покажем, как настроить эффективную автоматизацию тестов API с Postman и Newman, интегрируя их в процессы CI/CD, чтобы избежать ошибок и повысить производительность.

Сегодня я хочу поделиться глубоким исследованием того, как применять золотое сечение в современном дизайне 2025 года. Эта статья основана не только на теории, но и на реальном опыте работы с крупными проектами, A/B тестах и исследованиях пользователей.

Каждый разработчик рано или поздно сталкивается с вопросом: как организовать проект так, чтобы он не превратился в хаос? Или как исправить проект, в котором уже царит хаос?

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

В этот момент мы начинаем задаваться вопросом: «а как нужно писать и организовывать код на самом деле?». В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature‑Sliced Design (FSD).

Наш фронтенд начинался как простой SPA на React, собранный с помощью Vite — типичный монолит с несколькими страницами. Со временем проект оброс новыми функциями и интеграциями и начал становиться всё сложнее в поддержке.

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

После изучения разных вариантов мы остановились на подходе микрофронтендов. Хотелось разграничить зоны ответственности между командами и ускорить разработку, не теряя гибкости. В качестве сборщика решили остаться на Vite — он быстро развивался, предлагал отличную DX и поддержку модульной федерации через плагин. Кроме того, важно было сохранить единый репозиторий, чтобы упростить CI/CD и управление зависимостями.

Сначала я недооценил document.currentScript, но оказалось, что он отлично подходит для передачи параметров конфигурации прямо в теги <script> — и это далеко не все.

Порой я натыкаюсь на давно существующие браузерные API в JavaScript, о которых, по идее, я должен был узнать гораздо раньше. Например, window.screen или метод CSS.supports(). К счастью, я понял, что не один такой. Помню, как однажды упомянул window.screen в посте и получил неожиданно много комментариев от людей, которые тоже впервые о нем слышали. Это меня немного приободрило — я почувствовал себя не таким уж глупым.

Видимо, дело не в том, как давно существует API, а в том, насколько он полезен в реальных задачах. Если window.screen почти нигде не используется, о нем легко забыть.

Но иногда все же появляется неожиданный шанс применить одну из этих малоизвестных возможностей. Похоже, я как раз нашел такой случай для document.currentScript — и намерен использовать его по максимуму.