Ответ на пост «До чего доводит любовь к DnD или как проводят досуг взрослые люди»2
Меня тут девушка мастер подземелий в какой-то момент озадачила, мол тыж фронтенд программист, сделай мне так, чтобы карты предметов можно было создать и распечатать. Ну и я как совсем еще неопытный фронтенд программист стал во всю прыть ваять сей продукт.
Короче говоря, вот ссылка.
Все абсолютно бесплатно, ни рекламы, ни какого-либо мне известного налюбилова здесь нет. Старался в первую очередь для девушки, но может кому еще понравится/пригодится.
Удивительным образом, UI/UX дизайнер - это прям отдельная профессия, а в Figma я не заглядывал.
В панамку активно принимаю, поскольку хочу набраться опыта/лайфхаков/лучших практик. Сделать определенно можно лучше, но вроде работает сносно. Если у вас дойдут руки дойти до панамки в виде репозитория и напихать туда, то я только за.
Мой TechArt: как я совмещаю код в React и кисть в Procreate, чтобы создавать крутые арты с помощью AI
Всем привет! Как человек, сидящий на двух стульях арта и кода делюсь своим лайфхаком по прокачке творчества. 👩🎨👩💻
Мой день делится между стилями в CSS и стилями в Procreate. И если с традиционным рисованием (от бумаги до айпада) всё ясно, то моя фронтенд-логика помогла мне не испугаться нейросетей, а встроить их в свой пайплайн как штатный инструмент.
Проще говоря, я воспринимаю AI как асинхронную функцию в моём творческом процессе:
1. Генерация данных (prompt -> варианты): Я задаю параметры, AI возвращает массив сырых данных (картинок).
2. Обработка и валидация: Я, как строгий тимлид, отвергаю 95% сгенерированного (спасибо, что не нужно проводить code review для нейросети, а то бы я сгорела). Оставляю лишь годные «билды».
3. Финальный коммит: Беру лучший вариант эскиза и делаю полный рефакторинг в Procreate: исправляю анатомию, добавляю смыслы, свет и свою авторскую магию.
Нейросеть для меня — это не соавтор, а мощный npm-пакет для генерации идей и референсов. Он не пишет за меня весь код, но ускоряет разработку в разы.
Я осознанно выбираю технологии, которые резонируют с моей задачей. Даже здесь работает принцип — нужен правильный инструмент под задачу. Где-то чистый ручной труд, а где-то — `await generateInspiration()`.










Эскизы поз фей с 51 по 60
А теперь извините, мне нужно допилить очередной спринт по отрисовке летящих фей! Эскизов уже больше 60, и это только начало! 🧚♀️
Shadow DOM - DOM внутри DOM
Дисклеймер. На пикабу до сих пор не завезли редактор кода, поэтому картинки. Кому на нравятся картинки - при желании может почитать статью на GitHub
DOM — это программный интерфейс (API) для кода страницы, который представляет страницу как древовидную структуру объектов.
Каждый HTML-элемент (например, <p>, <div>, <img>), каждый атрибут и каждый фрагмент текста является отдельным «узлом» (node) в этом дереве. С JavaScript, мы можем обращаться к этим узлам, чтобы динамически изменять страницу: менять текст, добавлять стили, создавать новые элементы или удалять существующие. По сути, DOM — это «живая» модель документа, с которой взаимодействует код.
Но у этой открытости есть и обратная сторона. Когда мы создаем сложный, многократно используемый компонент (например, кастомный видеоплеер или виджет календаря), его внутренняя структура и стили становятся уязвимыми. Стили CSS с основной страницы могут случайно «протечь» внутрь компонента и сломать его внешний вид. Аналогично, JavaScript-код страницы может непреднамеренно изменить внутренние элементы компонента, нарушив его логику.
Для решения этой проблемы и существует Shadow DOM (теневой DOM).
По своей сути, Shadow DOM — это «DOM внутри DOM». Это скрытое дерево элементов, которое прикрепляется к обычному элементу на странице (называемому «хостом»), но при этом оно изолировано от основного DOM. Оно позволяет разработчику создать герметичную границу вокруг внутренней структуры компонента, защищая его от внешнего мира.
Теневой DOM позволяет прикреплять скрытые DOM-деревья к элементам в обычном DOM-дереве. Это теневое дерево начинается с теневого корня (shadow root), под который можно прикреплять любые элементы так же, как и в обычном DOM.
Существует несколько терминов, связанных с теневым DOM, которые следует знать:
Теневой хост (Shadow host): Обычный узел DOM, к которому прикреплен теневой DOM.
Теневое дерево (Shadow tree): DOM-дерево внутри теневого DOM.
Теневая граница (Shadow boundary): Место, где заканчивается теневой DOM и начинается обычный DOM.
Теневой корень (Shadow root): Корневой узел теневого дерева.
Вы можете воздействовать на узлы в теневом DOM точно так же, как и на обычные узлы. Разница в том, что никакой код внутри теневого DOM не может повлиять на что-либо за его пределами, что обеспечивает надёжную инкапсуляцию.
До того, как теневой DOM стал доступен веб-разработчикам, браузеры уже использовали его для инкапсуляции внутренней структуры стандартных элементов. Например, элемент <video> с элементами управления. Всё, что вы видите в DOM, — это тег <video>, но он содержит ряд кнопок и других элементов управления внутри своего теневого DOM.
Создание теневого DOM
Создавать теневой DOM можно двумя способами: императивно с помощью JavaScript или декларативно прямо в HTML.
Императивно с помощью JavaScript
Этот способ отлично подходит для приложений, рендерящихся на стороне клиента. Мы выбираем элемент-хост и вызываем на нём метод attachShadow().
Результат на странице будет выглядеть так:
Я нахожусь в теневом DOM Я не в теневом DOM
Декларативно с помощью HTML
Для приложений, где важен рендеринг на стороне сервера, можно определить теневой DOM декларативно, используя элемент <template> с атрибутом shadowrootmode.
Когда браузер обработает этот код, он автоматически создаст теневой корень для <div> и поместит в него содержимое тега <template>. Сам тег <template> при этом исчезнет из основного DOM-дерева.
Инкапсуляция: защита от JavaScript и CSS
Главное преимущество Shadow DOM — это изоляция. Давайте посмотрим, как она работает.
Инкапсуляция от JavaScript
Добавим кнопку, которая будет пытаться изменить все элементы <span> на странице.
При нажатии на кнопку текст изменится только у <span>, который находится в основном документе. Элемент внутри теневого DOM останется нетронутым, потому что document.querySelectorAll() не может "заглянуть" за теневую границу.
Доступ к теневому DOM: свойство shadowRoot и работа с вложенностью
Когда мы вызываем host.attachShadow({ mode: "open" }), мы создаём теневой DOM в "открытом" режиме. Это означает, что мы можем получить доступ к его содержимому извне через свойство host.shadowRoot.
Если же указать mode: "closed", свойство host.shadowRoot вернёт null, и доступ к теневому дереву извне будет закрыт. Это не строгий механизм безопасности, а скорее соглашение для разработчиков о том, что внутренности компонента трогать не следует.
Работа с вложенными теневыми деревьями
В сложных компонентных архитектурах один пользовательский элемент может содержать внутри себя другие пользовательские элементы, каждый из которых имеет свой собственный Shadow DOM. Чтобы добраться до элемента в глубоко вложенном теневом дереве, придётся последовательно "проходить" через каждый shadowRoot.
Представим себе такую структуру:
Компонент <nmbrs-form> (основная форма).
Внутри него находится <div>, а в нём — компонент <nmbrs-button> (кастомная кнопка).
Внутри <nmbrs-button> находится настоящая HTML-кнопка <button>.
Чтобы получить доступ к этой кнопке из глобального контекста, путь будет выглядеть так:
SВ виде одной цепочки вызовов это выглядит так:
Такая длинная цепочка наглядно демонстрирует мощь инкапсуляции: чтобы добраться до внутренних деталей, нужно явно пройти через каждую "границу". Это делает код более предсказуемым и защищает компоненты от случайных изменений.
Инкапсуляция от CSS
Стили, определённые на основной странице, не влияют на элементы внутри теневого DOM.
Элемент <span> внутри теневого дерева не получит эти стили. Это решает огромную проблему случайных пересечений и конфликтов CSS.
Применение стилей внутри теневого DOM
Стили, определённые внутри теневого дерева, в свою очередь, не влияют на основную страницу. Есть два основных способа их добавления.
1. Конструируемые таблицы стилей (Constructable Stylesheets)
Этот метод позволяет создавать объект CSSStyleSheet в JavaScript и применять его к одному или нескольким теневым деревьям. Это эффективно, если у вас есть общие стили для множества компонентов.
2. Добавление элемента <style>
Простой и декларативный способ — поместить тег <style> прямо внутрь теневого дерева (часто внутри <template>).
Теневой DOM и пользовательские элементы: идеальное сочетание
Вся мощь теневого DOM раскрывается при создании пользовательских элементов (Custom Elements). Без инкапсуляции они были бы невероятно хрупкими.
Пользовательский элемент — это класс, наследующий HTMLElement. Как правило, сам элемент выступает в роли теневого хоста, а вся его внутренняя структура создаётся внутри теневого дерева.
Вот пример простого компонента <filled-circle>:
Теперь мы можем использовать его в HTML как обычный тег, не беспокоясь о его внутреннем устройстве:
Каждый из этих компонентов будет полностью инкапсулирован и защищён от влияния внешней страницы.
Полезно? Подпишись.
Удачи 🚀
Как мы делали мини-игру про ровер на Марсе внутри Telegram WebApp
«Хочется сделать простую карту, чтобы листать её в Telegram». С этого всё и началось. А закончилось — изометрическим движком, авторизацией по WebApp, системой энергии, покупкой участков и боевым ровером с шестью колёсами.



🚀 С чего всё началось?
В начале всё было очень просто.
Мы сделали простенького бота, о котором я уже как-то тут писал, и бэк рендерил картинки с кусочком карты, где ты находишься.
В целом, даже эта идея была вполне рабочей и первые 300 пользователей с разных источников легко собрались. Мы даже провели на 9 мая конкурс "найди звезду победы" и выплатили победителю небольшой приз :)
Но само собой, что бот - не предел мечтаний, нужно было пилить полноценный мини-апп.
На боте лишь проверили гипотезу, отладили механики, типа уменьшения энергии, подзарядки аккумулятора в течении времени, пока не заходишь в игру.
Первый шаг в сторону мини-аппки - сделали вебстраничку, где можно было листать мышкой или пальцем — просто ради визуализации. Прямоугольная сетка, тайлы, немного стилей. Telegram WebApp проглатывал HTML5 на ура. Тогда не было никакой логики, просто подгрузка текстур и картинка под пальцем.
Вот как это выглядело:
Пользователь заходил и видел карту Марса.
Никакого взаимодействия — только “глянуть”.
🎮 А потом захотелось интерактивности
Следующим шагом стало добавление изометрии — чтобы выглядело как псевдо-3D. Самое интересное, что даже не потребовалось изменять текстуры. Серьезно :) Они по-прежнему те же самые, квадратные, 64 х 64. И не используется никакой 3д - движок.
вот краткое и понятное объяснение, как строится изометрическая карта из квадратных тайлов:
🧠 Основная идея:
Каждый квадратный тайл поворачивается на 45° и масштабируется по вертикали, чтобы получился ромб (изометрическая проекция). Вместо привычной сетки (x, y) мы рассчитываем экранные координаты (left, top) по формуле:
📐 Формулы для отображения:
При размере одного тайла T:
W = T * sqrt(2) — изометрическая ширина (диагональ квадрата).
H = W / 2 — изометрическая высота (высота ромба).
WX2 = W / 2, HX2 = H / 2 — половинки для смещения от центра.
Переход от логических координат (dx, dy) к пиксельным:
isoX = (dx - dy) * WX2 + centerX; isoY = (dx + dy) * HX2 + centerY;
🧩 Что это даёт:
(dx - dy) — смещает тайл по горизонтали.
(dx + dy) — смещает тайл по вертикали.
centerX, centerY — центр экрана, чтобы карта строилась относительно игрока.
🎯 В результате:
Из обычной квадратной сетки (x, y) формируется ромбовидная карта, где видны и горизонтальные, и вертикальные соседние тайлы.
Центральная клетка (текущий игрок) — всегда по центру, а остальные располагаются вокруг.
Ну а дальше уже дело техники - придумали алгоритм перемещения в 8 направлениях: вверх, вниз, влево, вправо, плюс диагонали.
Подключили ранее обкатанный в чатботе расход энергии за каждый шаг, и разный расход за диагональные движения, в сравнении с линейным. Плюс небольшой рандом :)
Задали запреты на воду, скалы и занятую клетку, чтобы не было “читов”.
🔐 Само собой - авторизация
Чтобы пользователь не “прыгал” по чужим роверам и участкам, мы внедрили Telegram WebApp InitData (это такая строка с хешем, которую фронт передает нам в бэк, а мы - уже на сервере телеграм с токеном бота валидируем подпись. Если сошлась - то пользователь зашел к нам через телегу. Если нет - скорее всего он просто открыл веб-страницу как сайт, или что-то пытается поломать, подделать :)
Если кратко:
Telegram сам отдаёт токен с подписью.
Мы проверяем подпись на бэке по HMAC SHA256.
Получаем ID пользователя, сохраняем его в сессии.
Теперь всё честно: ровер – только твой, кристаллы – только твои.
🪐 Стало красивее: добавили кристаллы и рамки
Потом появились:
Кристаллы на клетках — можно собирать.
Подсветка клеток: белая рамка — твоя, красная — чужая.
Имена владельцев, чтобы было видно, кто что захватил.
В планах: Покупка участков за кристаллы. Это было в текстовом боте. И ползая по карте, даже видны купленные тобой (белым) и оппонентами (красным) участки.
⚡️ Оптимизация и загрузка ассетов
Мы поняли, что каждая картинка может тормозить игру на слабом устройстве, и:
Добавили прелоадер, который подгружает PNG-шки перед игрой.
Сделали показ спиннера на любом действии (движение, загрузка).
Кэшируем тайлы и обновляем только при движении.
🤖 Как выглядит сейчас
Игрок:
Заходит в Telegram Mini App.
Авторизуется за доли секунды.
Видит изометрическую карту с ровером, кристаллами, участками, рекламными баннерами.
Может двигаться по клеткам, собирать кристаллы (в будущем - бурить и находить ресурсы, торговать ими, покупать землю).
А мы — всё это рисуем прямо в DOM.
Никаких Canvas, WebGL, или тяжелых движков. Только HTML, CSS и немного магии на JS.
💬 Если интересно — покажу, как это выглядит вживую.
Тестить можно тут. А если зайдёт — добавим NFT, фермы и квесты на выживание 😄
Что дальше после HTML/CSS?
Куда двигаться в веб-разработке и не только
Вчера мы публиковали подборку лучших курсов по HTML и CSS — возможно, вы уже выбираете подходящий вариант для старта. Но что делать после освоения базовой верстки? Куда двигаться, чтобы продолжать развиваться в IT?
Если вы уже уверенно верстаете страницы, но не знаете, какой навык осваивать следующим — этот материал для вас. Мы разберем основные направления развития после HTML/CSS и поможем выбрать подходящий путь.
1. Углубляемся в фронтенд: JavaScript и фреймворки
HTML и CSS — это база, но без JavaScript (JS) сайты остаются статичными. JS добавляет интерактивность: анимации, формы, динамическую загрузку данных.
Что учить?
Основы JavaScript: синтаксис, DOM-манипуляции, асинхронность (Promise, async/await).
Фреймворки и библиотеки: React.js (самый популярный, востребован в вакансиях), Vue.js (проще для новичков), Angular (используют в корпорациях).
Дополнительные инструменты: TypeScript (типизированный JS), Next.js/Gatsby (для SSR и статических сайтов).
Результат: сможете создавать сложные SPA (Single Page Applications) и претендовать на позицию Junior Frontend-разработчика.
2. Осваиваем бэкенд: серверная часть
Если вам интересно, как работают базы данных, авторизация и API, можно уйти в бэкенд.
Варианты технологий:
Node.js + Express (если хотите остаться в JS-экосистеме);
Python (Django/Flask) — проще синтаксис, много возможностей;
PHP (Laravel) — популярен в вебе;
C# (ASP.NET) / Java (Spring) — корпоративный сектор.
Результат: сможете писать серверную логику и стать Fullstack-разработчиком.
3. Идем в дизайн и UX/UI
Если вам нравится не только верстать, но и продумывать интерфейсы, можно развиваться в дизайн:
Figma/Adobe XD — создание макетов;
Основы UX — юзабилити, исследования;
Анимация интерфейсов (CSS/JS, GSAP, Framer Motion).
Результат: сможете работать UI/UX-дизайнером или фронтендером с уклоном в дизайн.
4. Другие направления: мобильная разработка, тестирование, DevOps
Мобильная разработка: React Native, Flutter, Swift/Kotlin.
Тестирование (QA): ручное и автоматическое (Selenium, Cypress).
DevOps: Docker, CI/CD, облачные технологии (AWS, Azure).
Как выбрать направление?
Вместо того чтобы пытаться освоить всt сразу, попробуйте определить, что вам интереснее всего:
Если вам нравится создавать визуальные элементы, работать с анимацией и интерфейсами, то выбирайте фронтенд.
Если вас больше увлекает: логика и работа с данными, создание сложных систем, решение неочевидных задач, то вам может подойти бэкенд-разработка.
Если мечтаете: разрабатывать мобильные приложения, работать с современными кроссплатформенными технологиями, то вас может заинтересовать мобильная разработка.
Главное — не останавливаться! После HTML/CSS открывается огромный мир IT, и вы можете найти именно то, что вам по душе.
А что бы выбрали вы? Делитесь в комментариях!
Жизнь фронтендера: когда твой код – это искусство, а браузер – холст
Привет, Пикабу! Сегодня я хочу рассказать вам о захватывающем мире фронтенд-разработки. Готовы погрузиться в пучину тегов, стилей и скриптов? Поехали!
1. HTML: скелет нашего цифрового тела
Представьте, что вы скульптор, но вместо глины у вас теги. Каждый <div> – это маленькая вселенная, а <p> – повествование целой истории. А когда вы случайно забываете закрыть тег, это как забыть застегнуть ширинку – вроде работает, но что-то не так.
2. CSS: макияж для вашего сайта
CSS – это как модный журнал для вашего HTML. Хотите, чтобы ваш сайт выглядел как топ-модель на подиуме? Просто добавьте немного flexbox и grid, и вуаля! Хотя иногда CSS больше похож на игру "Угадай, почему этот элемент съехал на 2 пикселя влево".
3. JavaScript: душа вашего сайта
Если HTML – это тело, а CSS – одежда, то JavaScript – это душа вашего сайта. Именно он заставляет всё двигаться, реагировать и иногда падать с криком "Uncaught TypeError". Но когда вы наконец-то заставляете всё работать идеально, чувствуете себя настоящим волшебником!
4. Фреймворки: когда вы устали изобретать велосипед
React, Vue, Angular – выбирайте свой яд. Эти ребята обещают сделать вашу жизнь проще, и они действительно это делают... после 10 часов настройки и 100 ошибок при сборке.
5. Отладка: детективная работа 21 века
Кто сказал, что программисты не детективы? Попробуйте найти ошибку в 1000 строк кода! Это как искать иголку в стоге сена, только стог постоянно меняет форму, а иголка превращается в стог.
Заключение
Быть фронтендером – значит быть немного художником, немного волшебником и чуточку мазохистом. Но когда вы видите, как ваш код оживает в браузере, понимаете – оно того стоило!
А вы, дорогие читатели, сталкивались с миром фронтенд-разработки? Поделитесь своими историями в комментариях!
















