Запускаем бесплатный онлайн-марафон по фронтенд-разработке. Будет как в «Рокки»
Спринты, дедлайны и финальный тест-бой. Кто пройдет с нами три месяца подготовки — получит шанс на титул. Без метафор — мы реально ищем таланты и готовы взять их на стажировку.
Как записаться?
Заполни анкету по ссылке в профиле и скинь другу. Заявки принимаем до 26 марта.
Что будет?
Интенсивный 3-месячный тренинг. Это бесплатно. По сути, ты будешь поэтапно с дедлайнами писать приложение. Каждый спринт проверяем с помощью автотестов. Плюс будет поддержка менторов, наших крепких разработчиков. Это реальная прокачка твоих навыков и готовый проект в резюме.
Это уже четвертый марафон — после каждого наша команда фронтенд-разработчиков растет.
Кого ждём?
Начинающих веб-разработчиков (JS, React), которые уже изучали теорию и хотят прокачаться на практике в условиях, максимально близких к реальному проекту. Главное — желание кодить. Подойдут:
- студенты профильных вузов
- выпускники курсов
- самоучки
Важное условие: приглашаем участников из Беларуси и России.
Что дальше?
После 26 марта отправим на почту инструкции и первые задания. Старт марафона 1 апреля (это не шутка). До связи, Рокки.
Я информирую о релизе постом только потому, что у меня лично сейчас нет свободного времени написать полноценную статью об всех изменениях. Изменений много.
Важное изменение, которое всё же я упомяну - появился свой backend для компилятора. То есть отказ от LLVM состоялся, но на данный момент только для Linux x86_64.
Представим, что у нас некоторая система, состоящая из микросервисов, которые работают на разных машинах, но внутри общей IP-сети на немаршрутизируемых IP-адресах (10.0.0.0/8, 192.168.0.0/16 и т.д.). Микросервисы разговаривают друг с другом по TCP, подключаясь по IP-адресам, указанным в соответствующих конфигурационных файлах каждого. Но можно указать и не IP-адрес, а некий хостнейм, прописав его же в /etc/hosts. Почему-то часто считают, что "хостнейм эквивалентен IP-адресу". Оно, конечно, удобно так считать, с точки зрения "человекопонятности", но не всегда хорошо с точки зрения безопасной настройки.
Дело в том, что опечатка (или намеренная замена символа) в имени хоста может привести к тому, что адрес окажется в чужой DNS-зоне. Простейший случай: users-db.example.com -> users-db.example.co. Да, должно быть закрыто, да, есть .local, а хостнеймы можно записывать одним "лейблом", но это не решает проблему: использование символьного хостнейма гарантирует дополнительные запросы для разрешения имён, будь то локальные запросы на той же машине или запросы внешние, возникшие из-за опечатки. А всякий, даже локальный, библиотечный/системный вызов, выполняющий трансляцию имён и адресов, готов принести с собой неожиданные эффекты (см. ниже пример уже про IP-адреса). Не обязательно это эффекты от подмены библиотеки или подмены конкретного вызова. А если кто-то умеет записывать в /etc/hosts, то он и конфиг любой поправит. Что, впрочем, не всегда так, поскольку раскладывание hosts по машинам могут автоматизировать - тогда перехватить нужно только точку управления скриптом, формирующим файл. А ведь ещё обычно используется два протокола: v6 и v4, адреса и "резолвинг" там разные.
Если в конфигах микросервисов прописывать непосредственно IP-адреса (пусть и автоматом), то ситуация несколько лучше. Есть неплохие шансы, что трансляция имён/адресов не будет использована. Минимальная опечатка в записи немаршрутизируемого адреса реже приводит к тому, что трафик убегает наружу. Это так потому, что, во-первых, на то они и немаршрутизируемые; во-вторых, в таких системах обычно настраивают различные ACL, а они настраиваются для IP, в других местах, не на конкретной машине с микросервисом, да и пальцы у настраивающих ACL дрожат по-иному.
Тут, впрочем, необходимо отметить некоторые тонкости: ping 010.010.010.010 -- на многих и многих системах отправит пакеты в сторону серверов Google (проверьте). Я раньше рекомендовал использовать этот довольно хитрый "оборот" в рамках собеседований на должность сетевого инженера/разработчика (теперь уже смысла, понятно, нет), поскольку понимание того, почему здесь пакеты уходят в сторону сети Google, раскрывает основную часть опасений, связанных с использованием имён хостов в конфигах. Но всё же, в 010.010.010.010 - более одной "опечатки".
Работаю в большом проекте состоящем из более чем сотни динамически подгружаемых библиотек. OracleLinux, QtCreator, Qt, C++. Испытывал большие неудобства при загрузке приложения в режиме отладки с большим количеством точек останова (на 10 штуках старт с 30 секунд увеличивался до 2 минут). Казалось бы очевидное, но закономерность замедления обнаружилась не сразу.
При очередном подгруженном модуле происходит попытка установить точки останова в загруженный код. Чем больше кода загружено, тем дольше идет попытка. Как только все точки останова нашли свое место в загруженном коде, скорость подгрузки очередных модулей снова становится быстрой. Активность или пассивность точек останова не влияет.
Для своего проекта отлаживаемые модули перемещаю в начало загрузки (мое приложение делает это конфигурацией), скорость запуска в отладке теперь примерно одинаковая вне зависимости от разумного количества установленных точек останова.
Возможно, я озвучил очевидность. Но мне, работая в данном окружении и в большой команде достаточно давно, это озарение снизошло не сразу. Я и не сильно боролся с этим до недавних пор, сильное замедление произошло не так давно при переходе с Qt4 на Qt5 (у нас вынужденное legacy).
Как мы сокращали количество запросов по фичам в API
Контекст: я отвечаю за разработку конструктора Telegram-приложений. Начинались мы как конструктор кликеров (еще до хомяка). Со временем эволюционировали в конструктор курсов, сообществ, визиток, мероприятий и любых других приложений
Одна из основных сущностей в коде — это BotUser. То есть пользователь, который появился в приложении (зашёл хотя бы раз), имеет имя и Telegram ID
За ~полгода проекта у нас добавилось много фич, привязанных к пользователю. Практически все сопоставляются 1 к 1 по ключу User ID. Например, квизы, бонусные дни, купленные страницы, купленный карточки апгрейдов, тариф и т.д.
Раньше для каждой новой фичи мы добавляли новый запрос в API с фронтенда. И вот мы заметили, что на каждый заход пользователя стало уходить >10 запросов в API ⚠️.
Примерно вот так:
GET /users/user
// Response
{
"tgUsername": ...,
"tgId": ...,
...
}
GET /users/features/quizzes/completed
// Response
{
"completedQuizzes": ...,
}
GET /users/features/pages/bought
// Response
{
"boughtPages": ...,
}
GET /users/features/rates/rate
// Response
{
"userRate": ...,
}
При этом, на каждый запрос мы проверяли авторизацию. В Telegram это делается с помощью хеша от Telegram + проверка подписи токеном бота
Следовательно, на каждый запрос мы делали JOIN пользователя, брали бота (сущность Bot) из кэша и мэтчили подпись (+ логгировали). Это лишняя нагрузка
Сейчас подсобрали все фичи в один запрос. Теперь, на каждый заход пользователя получается только один GET /app/account/data, который возвращает данные пользователя вместе с данными фичей:
не подгружаем связанные сущности, где не нужно (one-to-one, one-to-many);
если подгружаем сущности, всегда делаем это одним JOIN'ом (а не бегаем по 2-3 раза в БД, как любит делать Hibernate);
берём общие часто запрашиваемые данные из кэшей.
Это позволило снизить нагрузку на сервер и БД. К посту прикрепляю график загрузки части наших серверов по CPU до и после оптимизации.
---
Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.
Что такое MVP и почему лучше сделать плохо чем не сделать совсем?
MVP (Minimum Viable Product) — это базовая версия проекта, которая содержит самые важные функции, необходимые для проверки идеи. Главная цель MVP — не сделать сразу идеально и навсегда, а быстро протестировать гипотезу, собрать обратную связь, чтобы улучшать проект на основе реальных данных, а не догадок.
По моему субъективному мнению MVP должен быть:
Простым. Спроси себя, в чем главная фишка твоего проекта и поищи простые варианты ее реализации. Первые пользователи сами подскажут тебе, что можно улучшить и какие фичи было бы круто добавить в полноценную версию проекта.
Быстрым. Идеальный срок для реализации MVP - до 2 недель. Такие ограничения позволят тебе сфокусироваться на главном и не забросить проект на полпути.
Открытым для обсуждения. Оставь в свободном доступе свой контакт, форму обратной связи или другую возможность поделиться впечатлениями о плюсах и минусах твоего MVP. Так ты узнаешь, что нужно от твоего проекта реальным пользователям и что следует улучшить в первую очередь.
А что на твой взгляд важно в MVP? Расскажи в комментариях!
Четыре статьи о редкоземельных элементах, которые вы могли пропустить
Редкоземельные элементы стали нынче очень модными. Наша редакция еще в 2023 году запустила серию статей на эту тему. Мы решили собрать ссылки на них в одном посте.
В самом первом материале мы подробно рассказали обо всех РЗЭ. Трем элементам мы уделили особое внимание. Здесь мы написали про скандий, тут про празеодим. А еще не забыли про диспрозий.
Мы подробно описали, как добываются, где применяются и, разумеется, особое внимание уделили патентному аспекту.
В Joomla 4 и Joomla 5 появилась концепция Web Assets и WebAssetManager, с помощью которого можно управлять подключениями css, js файлов, подключением. Все css и js файлы включаются в общий реестр ассетов, затем выстраивается граф зависимостей и в итоге на генерируемую страницу подключается только то что нужно на данной странице.
Поскольку веб-ассеты можно добавлять с помощью плагинов (ссылка на статью ниже) - можно сказать, что появилось новое направление для плагинов - веб-ассеты. Вы можете устанавливать плагины, включающие веб-ассеты и использовать их как зависимости в самых разных местах Joomla: в шаблоне, в макетах модулей и плагинов.
Одним из таких плагинов веб-ассетов является WT JSwiper.js. Плагин добавляет в Joomla Web Assets Registry ассет популярного скрипта swiper.js, который потом легко можно использовать в коде:
use Joomla\CMS\Factory;
$wa = Factory::getApplication()->getDocument()->getWebAssetManager();
// Локальный файл
$wa->useScript('swiper-bundle')->useStyle('swiper-bundle');
// Подключение из CDN
$wa->usePreset('swiper-bundle-remote');
😐 Например, было: иконочный шрифт могут использовать 2 разных модуля. CSS обычно подключается в шаблоне и он грузится везде, даже там, где не надо. Если же подключать CSS в одном модуле, а в другом нет - на странице стиль есть ровно до тех пор, пока опубликован модуль с этим подключением.
👍 Стало: теперь в макетах расширений мы просто пишем $wa->useStyle('my.style'); и за необходимостью подключения нужного ассета (в данном случае CSS с иконочным шрифтом) следит Web Asset Manager. Если мы снимем один модуль с публикации, то нужный ассет подключит другой модуль.
Поскольку плагин - расширение Joomla - его можно обновлять обычным для Joomla способом и всегда иметь самую свежую версию любимого js-скрипта или веб-ассета на всех своих сайтах и сайтах ваших клиентов.
В этой версии, кроме обновления собственно ассета до версии 11.2.5 к нему добавился пока что частичный перевод документации Swiper на русский язык.
На одной из моих статей про Customer Journey Map стукнуло 170 000 просмотров -- хороший повод еще раз коротко рассказать про этот инструмент ⬇️
Зачем я первым делом делаю CJM, когда начинаю работать с новым направлением/продуктом?
1️⃣ Чтобы лучше понимать клиента Выявляем потребности, мотивы и боли клиентов => создаем продукты и услуги, которые максимально соответствуют ожиданиям наших клиентов.
2️⃣ Чтобы спроектировать лучшее решение проблемы клиента Опираемся на его реальные шаги, а не на наши иллюзии
3️⃣ Чтобы уменьшить сопротивление клиента в процессе решения его проблемы нашим продуктом Актуализируем все точки контакта клиента с нами. Устраняем слабые места и усиливаем положительные моменты
4️⃣ Чтобы повысить лояльность к нашему бренду Чем больше положительных эмоций будет у клиента при взаимодействии с нашим продуктом, тем выше лояльность клиента. В взаимодействии клиентов с интерфейсами на самом деле не так много радостных моментов. Тут не сложно выделиться, если все делать по уму
5️⃣ Чтобы синхронизировать команду И сам процесс создания, и наличие такого артефакта — по итогу объединяет различные отделы компании вокруг единого клиентского пути. Это похоже на визуализацию стратегии — если она нигде не оцифрована, то каждый в команде будет воспринимать ее по своему
А еще ⭐️ Точно поможет создавать более корректные маркетинговые стратегии. Ведь мы знаем, с чем сталкивается клиент сейчас, и как мы можем предвосхитить его ожидания
⭐️ Точно поможет в разработке новых продуктов. После создания пути клиента сразу видно, с какими еще проблемами сталкивается клиент на пути решения проблемы — а на этих данных уже можно выстроить цепочку других продуктов
Как строить, если хочется построить
Я разделяю создание CJM на 5 шагов
✍️ Описать проблему, которую хотим решить. Важно, пропускать нельзя, плохо написанная проблема и непонимание, зачем это => ненужное исследование
✍️ Собрать необходимую информацию Эта информация поможет нам в дальнейшем 🔄 с описанием сегментов 🔄 с выделением этапов в продукте 🔄 с определением ожиданий пользователя от продукта 🔄 с выявлением барьеров на пути к решению задачи пользователя или сегмента
✍️ Обозначить и описать сегменты
✍️ Отобразить этапы взаимодействия сегмента пользователей с продуктом
✍️ На каждом этапе взаимодействия сегмента пользователей с продуктом 🔄 нанести точки контакта 🔄 добавить проблемы и барьеры 🔄 по желанию добавить ожидания клиента и его эмоции на каждом этапе
Например Владелец ресторана может нарисовать не весь процесс, а выбрать какую-то одну из его частей ✏️ Процесс выбора ресторанов в интернете ✏️ Заказ столика, оплата счета и отзыв на сайте ресторана ✏️ Момент возникновения потребности у клиента пойти именно в ресторан — свадьба, свидание, день рождения или другой повод поиска
А вот какие задачи были у меня в рамках одного из исследований для банка
👁 Понять, что побуждает ИТ-специалистов отказаться от job offer 👁 Выявить, что мотивирует ИТ-специалистов принять предложение компании 👁 Выявить, что удерживает ИТ-специалистов в компании после испытательного срока 👁 Найти проблемные точки на этапе устройства в компанию
Customer journey map — то, что мы сейчас разбирали. Это визуализация взаимодействия клиента и компании с точки зрения клиента.
Service Blueprint — это про процессы внутри компании, с которыми наш клиент чаще всего не взаимодействует. То, что нужно для доставки ценности до конечного клиента И то, что находится “под капотом” продукта или процесса
User Story Map — карта пользовательских историй. Помогает продуктовым командам визуализировать беклог и управлять им.
User Flow — это, чаще всего, визуальное представление пути пользователя с момента запуска приложения или сайта
Если позволите, вкратце о себе. Зовут меня Саней. Имею опыт в тестирование более 3-х лет. В послужном списке тестирования были desktop-приложения для операторов БПЛА, системы защиты информации, система кредитования физических лиц и многое другое.
В настоящий момент работаю в компании QA-специалистом и одновременно являюсь ментором для людей, решивших стать тестировщиками.
Имеется богатый опыт теории и практики в тестировании, а также есть желание поделиться с ним.
Пишу пост на Хабре впервые и хочу узнать, "стоит ли игра свеч" и будет ли кому-то это интересно. Буду раз в неделю выкладывать статью о профессии QA, делаю упор на практику, которая вам в последующем пригодится на работе. И не будем забывать о теории, чтобы успешно пройти интервью)))
Приложение «МойОфис Документы для ОС Аврора» версии 5.х получило сертификат ФСТЭК России
Приложение «МойОфис Документы для ОС Аврора» успешно прошло сертификацию ФСТЭК России. Теперь на устройствах с операционной системой версии 5.1.0.124 и выше можно использовать защищенную версию приложения МойОфис.
Сертификат подтверждает, что «МойОфис Документы для ОС Аврора» соответствует требованиям четвертого уровня доверия в сфере информационной безопасности (УД 4). Приложение может применяться:
в значимых объектах критической информационной инфраструктуры 1 категории;
в государственных информационных системах 1 класса защищенности;
в автоматизированных системах управления производственными и технологическими процессами 1 класса защищенности;
в информационных системах персональных данных при необходимости обеспечения 1 уровня защищенности персональных данных и в информационных системах общего пользования II класса.
Сертификация распространяется на версию «МойОфис Документы для ОС Аврора» 1.6.1.
Защищенная работа с документами на ОС Аврора
Приложение позволяет пользователям работать с документами на мобильных устройствах в безопасной среде. Компании-заказчики могут внедрять «МойОфис Документы для ОС Аврора» в доверенный контур, создавая защищенные рабочие среды, соответствующие требованиям ФСТЭК России. Это особенно важно для организаций, работающих с критически важной информацией, персональными данными и государственными системами.
«МойОфис Документы для ОС Аврора» — это нативное приложение, которое позволяет редактировать текстовые документы, таблицы и презентации без подключения к интернету.
Что умеет приложение:
Создавать, редактировать и форматировать документы разных типов и форматов;
Работать с таблицами, форматировать ячейки, строить графики и диаграммы, использовать формулы;
Просматривать и изменять презентации, запускать слайд-шоу, использовать таймер демонстрации.
Продукт поддерживает русский и английский языки и совместим с смартфонами и планшетами, а также другими устройствами под управлением ОС Аврора версии 5.1.0.124 и выше. Тестирование приложения производилось на оборудовании НИИ «Масштаб».
6 марта на вебинаре с MONT расскажем про результаты пилотного внедрения InfoWatch ARMA Стена (NGFW) в инфраструктуре дистрибьютора и поделимся другими кейсами с разными задачами — от VPN на 300 пользователей с двухфакторной аутентификацией до блокировки торрентов и запрещённых внешних ресурсов и организации бесперебойной работы корпоративного сегмента.
А еще расскажем, как дальше будет развиваться InfoWatch ARMA Стена (NGFW) и что появится в продукте.
Как Яндекс.Маркет обманул меня и игнорировал 2 месяца
История о том, как Яндекс Маркет проводил акцию «Колесо призов», где можно было выиграть iPhone, но вместо этого я получил скидку на настольные игры.
🔹 Что случилось:
Выпал айфон, но держи скидку на настольные игры
Я крутанул колесо, и мне выпал iPhone. На экране явно был изображён телефон. Однако после остановки колеса мне засчитали… скидку на настолки.
Обратите ещё внимание, как криво наполовину недовылезла картинка со скидкой
🔹 Что я сделал:
Я обратился в поддержку 19 января 2025, но они тянули с ответом 2 месяца (!). Когда, наконец, ответили, заявили, что «это просто ошибка анимации», а приз «выбирается случайно». То есть сама игра вводит пользователей в заблуждение, показывая одно, но засчитывая другое.
Здравствуйте, Андрей!
Разобрались в работе колеса призов и выявили ошибку — дело в том, что некорректно отображается анимация. После обновления приложения до версии 7.1.1 ошибки быть не должно.
Итоговый приз показывается только при полной остановки колеса и выбирается случайно — в этом подвоха нет.
🔹 Обратился в Роспотребнадзор:
Мне ответили, что акции, бонусы и скидки не подпадают под Закон о защите прав потребителей, так что они помочь не могут.
🔹 Итог:
Яндекс признал баг, но вместо того, чтобы признать ошибку честно, они просто сказали «так и должно быть». То есть… если приложение показывает вам iPhone, это ничего не значит.
Оцените самостоятельно такой маркетинг. Все ошибаются, но такой бигтех не должен выходить из таких ошибок так плохо.
ИИ-агенты в Альфа-Банке: нейросети создают автотесты без участия человека
Не фантастика, а реальность: в Альфа-Банке мы внедрили ИИ-агентов, которые проектируют, разрабатывают и проверяют автотесты. При этом полностью автономно, как настоящие QA-инженеры, но в разы быстрее и точнее. Это первый в России кейс, когда нейросети полностью закрывают цикл создания тестов — от анализа требований до пул-реквеста.
✨ Что умеют наши агенты?
🧠 Анализировать контекст из Jira и Confluence, вычленяя суть задачи. 🔍 Прогнозировать риски, зависимости и даже «пограничные» сценарии. 🛠️ Генерировать DTO для REST API и превращать ручные сценарии в Java-тесты за минуты. ✅ Сверять код с бизнес-логикой и техстандартами Альфы, защищая прод от случайных ошибок. 🌐 Создавать вариативные проверки — от позитивных кейсов до сложных негативных условий. ⚡ Автоматизировать рутину — и это лишь часть их скиллов.
В ИИ-команде QA есть несколько агентов, каждый работает над своей частью из перечная выше. Сейчас решение пилотируется в нескольких продуктовых командах, но результаты уже впечатляют: меньше ошибок в проде, предсказуемые дедлайны и высвобожденные ресурсы для творческих задач.
«Одна команда ИИ-агентов экономит десятки часов работы, увеличивает скорость релизов и находит на 30% больше багов», — делится Святослав Соловьев, Директор по генеративному ИИ в ИТ Альфа-Банка.
🔜 Скоро расскажем подробнее — как устроены агенты, какие технологии behind the scene и как мы измеряем их эффективность. Оставайтесь с нами!
МойОфис признан одним из лидеров рынка облачного офисного ПО в России по результатам исследования TelecomDaily
Компания МойОфис заняла лидирующие позиции среди поставщиков облачного программного обеспечения для офисной работы в России. Независимое исследование рынка виртуальных офисов, проведенное аналитическим агентством TelecomDaily, охватило 1050 представителей бизнеса, работающих с облачными офисными сервисами, и выявило ключевые тенденции и предпочтения пользователей.
Согласно опубликованным данным TelecomDaily, индекс NPS (готовность пользователей рекомендовать решение к использованию) для продуктов МойОфис составил 56%. При этом, бренд МойОфис является одним из самых узнаваемых на рынке: 52% респондентов знают о его существовании. Больше трети опрошенных компаний (33%) рассказали, что использовали решения МойОфис.
Также МойОфис занял второе место по числу пользователей, планирующих переход на данное офисное ПО в течение года. Согласно опросу, 18% респондентов рассматривают решения компании как приоритетный выбор для обновления офисного пакета.
Исследование выявило, что стабильность работы, безопасность данных и удобство интерфейса являются главными факторами при выборе платформы для организации офисной работы. Эти критерии являются приоритетными при разработке и развитии решений МойОфис, что позволяет компании предлагать продукт, полностью отвечающий потребностям современного бизнеса.
Быстрое трудоустройство в YADRO для разработчиков на С++
У нас стартовал SPRINT OFFER в команду разработки телеком-оборудования. Для «плюсовиков» это возможность получить предложение о работе всего за несколько дней. Если хотите пропустить долгие этапы собеседований, отправляйте заявку до 9 марта.
Как все происходит
Подаете заявку — мы оперативно рассматриваем анкеты.
Проходите HR-скрининг и техническое интервью — без недель ожидания между этапами.
Получаете оффер — если все этапы успешно пройдены, предложение будет у вас в течение 3 дней.
Где предстоит работать
Дивизион телекома создает решения для мобильных сетей. Инженеры разрабатывают базовые станции GSM/LTE, полный стек телекоммуникационных протоколов, а также системы управления и мониторинга. Большую часть кода разработчики пишут на C++. В зависимости от задачи они используют как современные возможности C++20, так и низкоуровневые оптимизации для повышения производительности.
Кого мы ищем
→ Software Engineer (Telecom Platform)
Требуемый уровень: middle, senior, tech lead.
Чем предстоит заниматься:
Разработкой платформы для базовых станций LTE/GSM (middleware, high availability, node management, delivery).
Проектированием архитектуры, работа с C++/Linux.
Интеграцией с аппаратной и программной частью системы.
Оптимизацией кода и решение проблем производительности.
Разработкой API, unit-тестирование, документация.
→ Software Engineer C/C++ (LTE/GSM)
Требуемый уровень: middle, senior, tech lead.
Чем предстоит заниматься:
Разработкой программного обеспечения для базовых станций LTE.
Реализацией стека протоколов 3GPP.
Интеграцией с другими системами, оптимизация кода.
Решением задач производительности и стабильности системы.
Подробнее о вакансиях и команде читайте на странице SPRINT OFFER. Успейте подать заявку до 9 марта!
Представлен проект Scroll Buddy — анимация на полосе прокрутки.
«Вместо скучной полосы прокрутки я подумал, что было бы забавно иметь анимированную фигурку, которая ходит вверх и вниз по краю страницы, когда вы прокручиваете. Это первый прототип, который я сделал. Собираюсь сделать скейтбордиста, скалолаза или белку следующим», — пояснил авто проекта.
