TypeScript *

Если вы занимаетесь фронтенд-разработкой, то наверняка работали со Storybook — удобной витриной компонентов, на которой красиво лежат компоненты и примеры их использования. Его любят за интерактивную документацию, возможность визуального контроля и изолированной разработки. Но замечали ли вы, сколько действий приходится делать, чтобы взять компонент из Storybook и вставить его в реальный проект? 

Наверняка вы сталкивались с ситуацией: нашли компонент в Storybook, затем переключились обратно в IDE, скопировали код, вставили, адаптировали, проверили, и повторили снова. Кажется, многовато действий для простой вставки компонента, правда? Постоянные переключения между браузером и IDE, ручной копипаст и отсутствие связи с уже написанным кодом делают этот процесс неудобным и медленным.

Storybook Studio: всё в одном месте...

Сегодня в нашем CI ежедневно запускается более 5 000 автотестов, которые проверяют всё: от корректности скриншотов панели до скорости отклика API. Это не просто тулза в пайплайне, а часть инженерной культуры команды, которая помогает нам выпускать изменения быстро и с уверенностью.

Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud.

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

Чтобы не выбирать между скоростью и стабильностью, мы сразу сделали ставку на автоматизацию и автотесты. Это позволило команде быстро выпускать новые фичи, не боясь сломать что-то важное, и при этом держать контроль над качеством на каждом уровне.

В этой статье расскажу, как устроена наша система, какие типы тестов мы используем, как выстроен процесс, и какие уроки мы из этого извлекли.

В классическом исполнении, списки включают в себя все элементы из коллекции. Другими словами, те элементы, которые не видны пользователю (находятся за пределами вьюпорта) все равно присутствуют в DOM дереве. А теперь представим, если список состоит допустим из 1 000 000 элементов, как это повлияет на производительность и ресурсоемкось? Ответ очевиден, пропорционально объёму коллекции будет расти ресурсопотребление и снижаться общая производительность.

Но к счастью для нас есть методы и алгоритмы позволяющие существенно ускорить работу таких «исполинских» списков.

HTML Builder — визуальный конструктор HTML-структур с drag-and-drop интерфейсом для библиотеки @vue-dnd-kit/components!

🔹 HTML Builder позволяет создавать HTML-структуры без написания кода
🔹 Включает рабочую область, палитру компонентов, дерево элементов и панель настроек
🔹 Сейчас это ранняя бета с минимальным функционалом, но уже можно оценить концепцию
Идеально подходит для создания прототипов и визуальных редакторов CMS.

🔗 Демо: https://zizigy.github.io/html-builder/
🔗 GitHub: https://github.com/ZiZIGY/html-builder

Ищу обратную связь по UI/UX и функциональности. Какие фичи хотели бы видеть? Что можно улучшить в интерфейсе? И тд тп.

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

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

Я — Web разработчик в команде CodeX @e11sy

Я работал над переписыванием системы уведомлений open-source трекера ошибок Хоук. Он отлавливает ошибки в ПО и присылает уведомления разработчикам. Исходная реализация была простой и не масштабируемой, что приводило к задержкам получения уведомлений.

Привет, Хабр! Сегодня хочу поделиться опытом создания универсальной системы для работы с пользовательским контентом, которая позволила нам избежать дублирования кода и создать масштабируемое решение.

История о том, как мы с командой сделали умный подбор картинок, а в процессе затестили русскоязычную модель RuCLIP и обсудили маникюр.

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

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

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

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

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

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

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

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

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

Привет, Хабр! Меня зовут Дима, я фронтенд‑разработчик Яндекса. В этой статье я расскажу о том, как мы переписали наш ридер для электронных книг, создав универсальное решение для веба и нативных приложений.

Статья будет интересна фронтенд‑разработчикам. Из неё вы узнаете, как создать универсальное ядро для веба и натива, получить вместо запутанных асинхронных вызовов чёткие последовательности действий и убрать визуальные артефакты при одновременных пользовательских действиях.

В 2022-м мы окончательно задолбались.

Каждый новый проект все по кругу: таблички, формы, фильтры, CRUD. Всё снова, как в Groundhog Day. Копипастить старое было больно, собирать с нуля – ещё хуже. И главное, ощущение абсурда: 2022 год, а мы продолжаем лепить админки вручную, будто на дворе 2015.

Окей, логичный шаг – найти готовое решение.

Мы правда пытались не изобретать велосипед

Первым делом пошли смотреть на CMS. Попробовали Strapi – мощный зверь, но если вам просто нужно бэку выдать пару CRUD’ов, то тянуть за собой целую экосистему с философией и особым образом жизни, это как стрелять из базуки по воробьям.

Дальше, дизайн-системы вроде Salesforce Lightning, Fluent UI и Fusion Design. Компоненты красивые, но по факту это просто UI-кирпичики. Всю бизнес-логику, связи между сущностями, обработку данных всё равно пишешь сам. Хотели сэкономить время, а получили “ты теперь ещё и архитектурой займись”.

React-Admin показался перспективным. Но мы быстро поняли, что он хочет, чтобы ты делал вещи его способом. А мы хотели делать их по-своему. Онбординг тяжёлый, кастомизация сложная, UI на любителя. Как часто бывает: сначала кажется, что ты взял инструмент, а потом он берёт тебя.

Мы поняли: компромиссы – это медленно

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

Хорошая отказоустойчивость начинается с мышления.

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

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

(История экономиста с неоконченной Computer Science, который нашёл себя в автоматизации логистики)

Хабр, привет! Меня зовут Александр и я обычный менеджер по работе с ключевыми клиентами в логистической компании, которая занимается в основном контейнерными перевозками из Китая в РФ (рекламы не будет).

Кратко обо мне: всегда интересовали компьютеры и программирование, но жизнь складывалась немного иначе чем хотелось. В 14 лет всей семьей уехали жить в Италию, где я закончил экономический, а также потом поехал учиться на 3 года на Computer Science в г. Пиза (да, это там, где башня падает и все никак не упадет). К сожалению, в связи с бумом ковида было принято решение возвращаться домой, да и долги по учебе не добавляли оптимизма в связи с чем, спустя год изоляции (возможно многие знают как жестили в Европе с ограничениями) я отправился на родину в Москву, где после непонятного года я смог более‑менее укрепиться в сфере международных перевозок.

Несмотря на все пертурбации, я по‑прежнему искал любыми способами оставлять в жизни место и время для программирования, Хабра и поиска интересных решений и попыток самому что‑то сделать годное. В моем небольшом арсенале есть основы С с универа и Java/Kotlin/JS, которые я использую везде куда дотягиваются руки.

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

Привет! Мы Дима и Илья, работаем в команде ТМА-разработки Doubletapp и расскажем, как создать Telegram Mini App на стеке React + Python.

Telegram Mini Apps — это мощный инструмент, который позволяет создавать интерактивные веб-приложения, работающие прямо внутри мессенджера. Они идеально подходят для игр, маркетплейсов, сервисов бронирования и многого другого.

В этом туториале мы разберем процесс создания Mini App:

• настроим проект
• создадим фронтенд на React с поддержкой Telegram SDK
• реализуем бэкенд на Python (Django)
• свяжем все компоненты и развернем приложение.

Как избежать хаоса в безопасности NestJS при применении guards. Вместо разнообразных наборов проверок на каждом контроллере лучше перейти на многослойную систему глобальных guards, что упростит масштабирование системы и повысит ее безопасность.

Статья написана для юзверя (в том числе разработчика) с базовыми знаниями работы в операционной системе, консолью, IDE и браузером.

В статье рассматривается инструкция для установки LLM локально на ПК юзверя для обхода проблем работы с удаленными серверами. Также статья поможет в совсем базовом понимании работы с LLM.

Здесь будет рассматриваться IDE VSCode, однако всё нижеописанное актуально и для JB Webstorm или Pycharm (и др).

Важность надежной обработки запросов в оффлайн-режиме невозможно переоценить, особенно для приложений, которые должны функционировать и в отсутствии интернет-соединения. Workbox - это мощный инструмент для управления Service Worker в браузерах, он как раз призван решать подобную задачу при помощи соответствующего плагина, но поддержка Background Sync API не универсальна. В этой статье я покажу, как расширить Workbox, чтобы Background Sync корректно работал даже на платформе iOS/Safari.