В видео я показываю несколько возможных оптимизаций вашего рабочего процесса. Станет удобнее и проще использовать ваш основной инструмент для работы.
Раз. Убираем Activity Bar. В нем есть три типа иконок: нужные нам часто, нужные иногда, совсем ненужные. Логика такая: для нужных мы создаем горячие клавиши (или пользуемся существующими). Для средне-нужных используем cmd+p и выбор команды. Ненужными – не пользуемся :)
Кастомные настройки для горячих клавиш для управления разными View (плюс к стандратным):
Два. Убираем Side Bar. Большую часть времени он не нужен. В основном нам просто нужно читать и реже писать код. Зачем нам Side Bar? Убирается основной по cmd+b, а второй по cmd+alt+b.
Но если оставить Side Bar справа, то его появление / скрытие будет двигать код. Что будет мешать. Потому – убираем его вправо.
Три. И не забудьте поместить Command Palette в центр рабочей области. Так будет удобнее: появяться она будет сразу перед глазами. Просто перетаскиваем мышкой.
Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести
Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.
В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться.
Мы растём по количеству и продуктов, и людей, нанятых для их разработки. Недавно начали толкаться локтями: не понимали, как качественно контрибьютить в большие кодовые базы, как они должны эволюционировать. Поэтому пришли к ивент-штормингу.
Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.
Ивент-шторминг проводится с фокусом на цикличную реактивность: происходит событие, которое визуально меняет что-то для пользователя, тот принимает решение и отдаёт команду, команда приводит к новому событию.
На этих циклах фокусируемся на доске в Miro во время встречи.
В ивент-шторминге 3 этапа:
1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.
2. Проходим по таймлайну с конца, ищем ошибки. Выделяем ключевые события, которые нельзя откатить: клиент зарегистрировался, совершил бронирование, провёл оплату. Здесь происходит стык сервисов. На стыках обогащаем цепочку. Пишем, кто и что делает: актор-клиент зарегистрировался, подключился сервис юзер-менеджмента.
3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации.
Цепочка готова, мы получили полезный контекст, все одинаково понимают процессы и видят, что нужно делать, чтобы их улучшить.
Во время встречи составляем словарик. Если сейлз говорит непонятное разработчикам слово — мы его добавляем в словарь, и оно просасывается в наш интерфейс и кодовую базу. Всё это учит разработчиков понимать, на какие рычажки они влияют своим кодом.
Поделюсь советами, как круто провести ивент-шторминг.
Онлайн-формат
● Для проведения онлайн достаточно доски в Miro.
● Разбивайте встречу на три части, каждая встреча — один этап.
● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.
● Максимум людей для успешной фасилитации онлайн — 8–10 человек.
● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».
● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.
● Берите людей из разных направлений домена.
● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.
● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.
● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.
Фасилитация
● На старте не бойтесь повторить все вводные.
● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.
● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали.
● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.
● Если бизнес утверждает, что два события происходят одновременно, это важная точка обсуждения.
● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.
Как провести идеально бесполезное собеседование для фронтендера!
Шаг 1: Берем «элитный» шаблон Яндекс.Мультитрека.
Шаг 2: Удаляем всё ценное — оставляем только хаотичный набор вопросов.
Шаг 3: Делаем вид, что это «специально под вакансию» (спойлер: одни и те же 40 вопросов получают все — от стажера до лида).
Главные хиты программы:
— «Назови 5+ способов центрировать div» (ведь React-лид должен уметь это с закрытыми глазами). — «Расскажи про Event Loop как стихотворение» (иначе как проверить лидерские качества?). — «SOLID наизусть, включая историю создания каждого принципа». — Секретный прием: задаем общие вопросы, но с видом эксперта ждем «правильного» ответа (который знает только интервьюер).
Философский бонус: пока такие собеседования существуют, «прохождение собеседований» остаётся отдельным навыком в вакууме — где побеждает не тот, кто лучше код пишет, а тот, кто научился угадывать, что имел в виду интервьюер.
Гарантированный результат:
Кандидат либо засыпает, либо пишет гневный пост.
Ваша компания экономит на зарплатах — никто не доходит до оффера.
Вы получаете статус «самое запоминающееся собеседование в карьере». Если узнали свою компанию — не переживайте, вы не одиноки в этом увлекательном квесте!
Представлена бесплатная платформа Pagy, которая позволяет создавать лендинги и небольшие веб-проекты за секунды. Работает в браузере и собирает сайты или визитки без привлечения дизайнера, верстальщика. Не требует никакой установки ПО. Все просто: выбираете шаблон и сразу его редактируете, пишите текст, вставляете ссылки и пикчи. Ни одной строчки кода писать не нужно, хостинг не требуется. Есть аналитика метрик сайта и сотни уже готовых дизайнов от разрабов и коммьюнити.
Чужой товарный знак в TITLE вашего сайта: есть ли риск судебного иска?
Сайт - средство привлечения клиентов и сопровождения продаж. Инструмент мощный, но зависимый: нужна поисковая оптимизация, иначе сайт затеряется среди миллиарда похожих ресурсов.
Такая оптимизация подталкивает поискового робота к тому, чтобы он приблизил к пользователю конкретную веб-страницу - поместил ссылку на нее как можно выше в выдаче по запросу.
Место страницы сайта в поисковой выдаче выше за счет текста внутри элемента TITLE.
Элемент TITLE размещается вверху кода веб-страницы между служебными символами <title></title>. Внутри элемента - текст, который отражает ключевую мысль всего контента страницы.
Пользователю не виден код сайта, но код видит поисковый робот. Он переходит на веб-страницу, изучает сведения внутри TITLE и помещает ссылку на эту страницу в выдачу по соответствующему запросу пользователя. Повыше.
В чем проблема? Давайте на примере.
Сайт моей адвокатской практики включает страницу "Главная", которая знакомит с моей юридической помощью: сообщает предложение, показывает его ценность, описывает пользу для каждого профиля и так далее.
Моя специализация - юридическая помощь по интеллектуальной собственности. Поэтому в код элемента TITLE этой веб-страницы я поместил ключевую мысль: "Защита интеллектуальной собственности | Адвокат С.В. Пропастин".
Поисковый робот считывает код и учитывает текст из TITLE при выдаче ссылки на веб-страницу. По запросу пользователя "защита интеллектуальной собственности".
Я порылся в реестре товарных знаков Роспатента и нашел комбинированный товарный знак условного конкурента. На нем изображены щит и словосочетание: Патентное бюро "Защита интеллектуальной собственности" (заявка 2019763408).
Ключевая мысль "защита интеллектуальной собственности" в TITLE кода моего сайта и словесный элемент товарного знака бюро сильно похожи!
Отсюда вопрос -
Застрахован ли я от судебного иска на том лишь основании, что фрагмент чужого товарного знака прописан в невидимом для пользователя месте - коде сайта?
Вопрос не праздный.
Гипотетически я могу отбирать клиентов у бюро: пользователи ищут в интернете именно бюро, за счет моего title наталкиваются на мой сайт и переходят на него, оценивают преимущества и обращаются ко мне за помощью.
Бюро вправе защищаться - подать на меня в суд. Потребовать, чтобы я перестал нарушать их права на товарный знак и возместил ущерб.
С такой ситуацией может столкнуться любой бизнес: малый, средний или крупный...
Ответ на вопрос мне не нравится, но истина дороже -
Маскировка чужого товарного знака в элементе TITLE кода веб-страницы не защищает меня от иска правообладателя знака. Почему?
1. Товарный знак включает словесный элемент "защита интеллектуальной собственности". Ключевая мысль в TITLE моего сайта тоже сформулирована в словесной форме с таким же наполнением.
Словесная форма товарного знака и ключевой мысли, их одинаковый текст - аргумент в пользу использования на сайте именно товарного знака, принадлежащего бюро.
2. Один из способов использования товарного знака - его размещение в сети "Интернет".
Сайты являются обязательным звеном этой сети. Без них линии связи теряют смысл: нечего соединять. Именно использование товарного знака без согласия его владельца - повод для судебного иска.
3. Без специальных сервисов элемент TITLE в коде сайта невидим пользователю. Но именно в случае с TITLE пользователь видит результат исполнения кода, так как ключевая мысль:
1) выводится в виде заголовка и подсвечивается системой на странице выдачи по поисковому запросу;
2) выводится на персональном компьютере в адресной строке браузера при переходе на главную страницу сайта.
Поговорите со своим адвокатом. Он назовет условия, когда допустимо использовать чужой товарный знак без ущерба для кошелька. В моей ситуации, например, такие условия есть.
Интересно, вы проговариваете в процессе SEO тему использования чужих товарных знаков?
Язык Go называют одним из самых удобных для бэкенда. Дело тут не в примитивности: его специально стремились сделать простым и лаконичным, чтобы пользователям было легко работать с синтаксисом и понимать чужой код.
Если вы уже знакомы с Go, но не хватает практики, приглашаем пройти новый курс в Академии Selectel. С ним вы научитесь писать простые сервисы на Go и использовать его в некоторых рабочих задачах, а еще получите большую подборку ресурсов для погружения в этот язык.
Что делает данный код? Читает сообщения из first-topic, парсит из них поле user типа str, выполняет вашу логику обработки, отправляет новое сообщение в another-topic. Просто? Удобно? Да!
Что нам дает такой подход?
Декларативное описание, чего мы хотим. Не надо руками создавать коннекты и рулить потоком выполнения
— Слушай, я посмотрел у Тинькоффа — у них такие крутые анимации. Давайте и нам такие сделаем!
— Ну, у нас не финтех, мобильного приложения нет, и вообще — у нас CRM для логистов…
— Ну и что? Люди любят, когда красиво! Сделаем плавные графики, чтобы всё оживало. UX, UI, ты же понимаешь!
— У нас при этом не работают фильтры, отчёты формируются вручную, и у клиента падает система при импорте Excel. Может, сначала это починим?
— Ладно… Только кнопки тогда сделай с закруглениями, как в Тинькоффе. Хоть что-то красивое будет.
Выглядит лучше. Работает — так же плохо.
Потому что копировать обёртку, когда продукт внутри разваливается — это мёртворождение дизайна.
Вдохновение — не преступление.
Но копирование без понимания контекста — худший выбор.
У Тинькоффа и команда дизайнеров, и исследования юзабилити, и огромный бюджет, и полгода на rollout.
Сначала надо решить боль клиента, а не украсить страдание. Сделай стабильный функционал, и только потом — красивый. Иначе копирование по цене тех долга выйдет.
Как скрыть Webvisor от Яндекс.Метрики во вкладке "Сеть" в DevTools
Вкладка Network
При отладке фронтенда или анализе сетевых запросов в DevTools часто возникает проблема: запросы к mc.yandex.ru (Webvisor) загромождают вкладку «Сеть» и мешают сосредоточиться на действительно нужных данных. Особенно если на странице активно работает Яндекс.Метрика с включённым Webvisor.
Хорошая новость: эти запросы легко отфильтровать или полностью заблокировать. Делюсь несколькими способами, как это сделать.
Этот способ касается и других типов запросов, мне лично мешают запросы от mc.yandex.ru.
Способ 1. Фильтрация через DevTools (Network)
Если не хочется ничего ломать, просто исключите Webvisor из отображения:
Откройте DevTools (F12 или Ctrl+Shift+I / Cmd+Option+I).
Перейдите на вкладку Network (Сеть).
В строке фильтра введите: -mc.yandex.ru
Способ 2. Полная блокировка через Request Blocking
Если вы не хотите, чтобы эти запросы вообще происходили:
Откройте DevTools.
Нажмите на три точки в правом верхнем углу панели → More tools (Другие инструменты) → Network request blocking (Блокировка сетевых запросов).
В появившемся окне добавьте правило: *mc.yandex.ru*
Включите галочку Enable request blocking.
Теперь DevTools будет блокировать запросы к Webvisor ещё до их отправки.
Способ 3. Расширения браузера (например, uBlock Origin)
Для более глобального решения можно использовать расширения:
В настройках фильтров добавьте правило: ||mc.yandex.ru^
Теперь все запросы к mc.yandex.ru будут блокироваться на уровне браузера.
Заключение
Webvisor — полезный инструмент аналитики, но при разработке он чаще мешает, чем помогает. В зависимости от ваших задач можно отфильтровать, заблокировать или вовсе отключить его. Выбирайте подходящий способ и работайте продуктивно.
Если у вас есть свои хаки по "чистке" вкладки Network — делитесь в комментариях 👇
Как Stripe использует r.stripe.com/b: поведенческий анализ
Когда речь заходит об антифроде в Stripe, чаще всего вспоминают Radar, 3DS и JavaScript SDK. Но в самом центре поведенческой аналитики Stripe работает менее известный, но ключевой endpoint — r.stripe.com/b.
В этой статье разберём:
зачем Stripe использует r.stripe.com/b;
какие сигналы отправляются через него;
как он помогает выявлять headless-браузеры;
и как эти механизмы исследуются техническими сообществами, включая bfd.
📡 Что такое r.stripe.com/b
Это внутренний endpoint Stripe Radar. Он используется для сбора поведенческих сигналов клиента и браузера. Его вызов можно отследить в Chrome DevTools при использовании платёжной формы Stripe — чаще всего после генерации payment method или до confirm-запроса.
Что Stripe передаёт в r.stripe.com/b
Формат — POST, содержимое — application/x-www-form-urlencoded. Поля:
radar_options[hcaptcha_token]
radar_options[event]
p, v, d, m — закодированные поля с JS-данными
Фингерпринт сессии (__stripe_mid, __stripe_sid)
Эти данные собираются JavaScript'ом SDK через скрипты вроде m.stripe.com/6.
Что реально проверяет Stripe
Был ли пользователь ботом (анализ input, delay, blur)
Используется ли headless-браузер
Совпадают ли JS-объекты: navigator, window, chrome
Есть ли permissions.query()
Используется ли эмуляция Canvas / WebGL / Audio
👁 Пример поведения
Конфигурация Статус Комментарий Headless Chrome Declined Payload пустой Undetected + Spoof 3DS Stripe заподозрил spoof Ручной ввод + Mobile IP Success Поведение натуральное
Где это изучают
На техническом форуме bfd cash обсуждают не только карту и merchant, но и логики поведения SDK Stripe. Многие участники выкладывают HAR-файлы, конфиги undetected Chrome, расшифровки r.stripe.com/b payload. Оттуда же мы взяли идею тестировать JS spoof через Canvas API в реальном браузере.
💡 Вывод
Stripe анализирует не только карту, но и то, как вы её вводите. И r.stripe.com/b — важнейший компонент этой системы. Если вы хотите контролировать конверсию, особенно при микроплатежах — понимание этого механизма даст вам весомое преимущество.
✉️ В следующем посте — анализ ответа /confirm и как по status, code и type понять, что произошло.
Если нужен шаблон HAR, конфиг spoof или список JS-объектов, которые вызывает Stripe — напишите. Или загляните на bfd, где эти вопросы разбираются регулярно.
Мифы и правда про 3DS и Stripe Radar: что реально влияет на прохождение платежа
Stripe — один из самых популярных платёжных шлюзов в мире. Он прост в интеграции, но часто вызывает головную боль у разработчиков из-за "невидимого" антифрода и внезапных запросов 3DS. ⠀ В этой статье я разберу:
когда и почему включается 3DS;
как работает Stripe Radar;
что реально влияет на прохождение платежа, а что — миф;
и почему не только карта, но и браузер может быть причиной отклонения.
Что такое 3DS и зачем он нужен?
3D Secure (3DS) — это дополнительный уровень аутентификации от банка-эмитента. По факту, это либо ввод кода из SMS, либо редирект на страницу подтверждения.
Stripe может запрашивать 3DS, даже если карта его не требует. Почему?
Потому что решение об этом может принять Stripe Radar — встроенная антифрод-система, анализирующая поведение клиента, fingerprint браузера, страну, IP, тип карты, и ещё десятки метрик.
Поведения: focus/blur, тайминг ввода, размер окна, устройства ввода
IP-геолокации
BIN-категории карты (например, debit USA ≠ credit EU)
Эти данные передаются в Radar, который на их основе применяет правила — автоматические или кастомные.
📌 Даже если у карты нет обязательного 3DS, Radar может всё равно форсировать challenge, если сессия кажется подозрительной.
🧪 Разоблачение популярных мифов
❌ Миф 1: Если карта валидная, Stripe не запрашивает 3DS
Факт: Stripe может запросить 3DS по поведенческим причинам, даже если карта настоящая.
❌ Миф 2: Всё решает только банк
Факт: В случае с Radar, Stripe может “настоять” на challenge. Stripe ≠ просто прокси.
❌ Миф 3: Можно отключить 3DS через настройки
Факт: Нет. Stripe использует "динамический 3DS" и самостоятельно определяет необходимость.
Что реально влияет на 3DS и проход платежа
✅ Страна карты и гео пользователя ✅ Поведение пользователя (движение мыши, тайминг, взаимодействие) ✅ Наличие navigator.webdriver = true ✅ Fingerprint: canvas/audio/webgl + размер окна ✅ Использование TOR/VPN ✅ Чистота IP ✅ Тип браузера (обычный vs headless)
Где об этом говорят?
Официальная документация Stripe объясняет только базовые вещи. За деталями приходится идти глубже — в коммьюнити.
Что мы проверили руками
Мы провели 40+ тестов с разными конфигурациями:
обычный Chrome vs undetected-chromedriver
реальное поведение vs instant fill
IP USA vs ротационный мобильный
карта Visa debit США vs MasterCard Prepaid EU
Результат: при headless + instant + VPN вероятность 3DS → 83%. А при "живом" поведении + clean IP + debit USA → 3DS не запрашивался вообще.
💡 Вывод
3DS — это не "банковская заглушка", а часть более широкой системы оценки сессии. Radar — не только антифрод, но и UX-страж.
Чтобы понять, почему Stripe блокирует платёж, нужно не только проверять карту, но и анализировать поведение сессии и окружение браузера.
✉️ В следующей статье — подробный анализ, как m.stripe.com и r.stripe.com собирают fingerprint и какие JS-фичи наиболее критичны.
Если интересны конфиги undetected Chrome или примеры DevTools-логов — дайте знать в комментариях.
На техническом форуме bfd cashобсуждают реальные кейсы, когда Stripe режет сессии без объяснения, как именно работают JS-ловушки, и как SDK "опрашивает" окружение. Там же есть примеры с DevTools и HAR-записями поведения Stripe в разных условиях.
При оформлении заявлений в детский сад на детей на uslugi.mosreg.ru столкнулся с тем, что если ранее было подано заявление и нужно какие-то данные в нём поправить, то выбрать год зачисления ребёнка в ДС можно только следующий. То есть, мы подали в 2024, а теперь можно выбрать только 2026 год, потому что текущий нельзя.
Мне показалось это не очень удобным, решил немножко изучить фронтенд сайта и обнаружил, что валидации на простановку года нет :)
В видео подробнее, как обойти ограничение
P.S. На записи не видно контекстного меню в браузере, когда нажимаешь ПКМ, нас интересует последний пункт "Просмотреть код"
Над CMS Joomla постоянно ведётся работа: создаётся новый функционал, исправляются ошибки, делаются мелкие правки. Разработка ведётся на GitHub. Изменения оформляются в виде Pull Request (PR). Для того, чтобы изменения могли войти в ядро - их обязательно должны успешно протестировать минимум 2 человека КРОМЕ автора изменений. А помочь с большинством PR можно очень и очень быстро, это не занимает много времени, чему подтверждением служит это видео.
Разберёмся, где заканчивается компонент и начинается сервис, как уменьшить связанность и повысить читаемость. Завершим практикой: проведем пошаговый рефакторинг на реальном примере.
📅 Дата: 11.07.2025
⏰ Время: 17:00-18:30 (Мск)
На вебинаре:
✔️ Разделение ответственности между компонентами и сервисами
✔️ Уменьшение связанности и повышение читаемости
✔️ Паттерны и антипаттерны в архитектуре Angular
✔️ Практический рефакторинг на примере «грязного» компонент
👨🎓 Спикер: Погорелов Павел — эксперт в области фронтенд-разработки.
Узнайте, как выстроить архитектуру Angular-приложения, которая выдержит рост команды и кода!
Привет, Хабр! Делюсь своим простым, но мощным инструментом: веб-интерфейс для чтения данных с UART-сенсоров прямо через браузер. Да, без установки чего-либо. Просто открываешь страницу — и видишь, что творится в воздухе.
🤔 Зачем всё это?
Если ты возишься с датчиками качества воздуха, то знаешь, как это бывает: подключил — и пошёл искать minicom, Ultra, какой-нибудь Python-скрипт, или ещё чего. А если ты просто хочешь посмотреть, дышит ли твой сенсор — зачем столько движений?
И тут пришла идея: а почему бы не сделать всё в браузере?
🌐 HTML + JS + JSON = 👌
Ты заходишь на sensor.pollutants.eu, выбираешь нужный сенсор из списка (если в JSON их несколько), подключаешься к COM-порту — и данные потекли.
Без установки. Просто HTML-страница, в которой уже всё встроено:
работа с Web Serial API,
парсинг бинарных фреймов по структуре из JSON,
визуализация данных через Chart.js,
конфигурация через внешний JSON-файл.
скачивание статистики в CSV
⚙️ Конфигурация сенсоров
Конфиг грузится с GitHub и содержит несколько сенсоров. Можeте загрузить свой JSON. Проект на hackaday
Представлен сайт, где можно летать по миру на самолётике — благодаря Google Картам. Города полностью трёхмерные — для полётов доступны Париж, Токио, Рио, Брюссель и другие города.
1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций.
Запустили продажу SSL-сертификатов для комплексной защиты сайтов и почтовых сервисов
SSL-сертификаты — цифровые решения, обеспечивающих безопасность передачи конфиденциальных данных пользователей. Они создают защищенное HTTPS-соединение, которое шифрует логины, пароли, банковские реквизиты и личную информацию.
У нас вы сможете приобрести все популярные типы SSL-сертификатов для бизнес-сайтов, личного блога, почтовых сервисов, финансовых организаций и других проектов, работающих с персональными данными пользователей, в частности из России и Беларуси:
🔑 DV — быстрая проверка домена.
🔑 OV/EV — расширенная проверка организации.
🔑 Wildcard — защита неограниченного количества поддоменов.
🔑 SAN — решение для мультидоменных проектов и почтовых сервисов.
Повышайте доверие своих пользователей и улучшайте поисковую оптимизацию!
Опубликована база по веб-разработке от Microsoft. В учебном курсе от компании представлено 24 урока, где разбирается всё от основ веба, работы браузеров, сетевых протоколов до HTML, CSS и JS. Всё обучение ориентировано на практику. После каждого раздела есть тесты и интерактивные кодинг-задачи. Также есть несколько пет-проектов, которые можно реализовать после обучения и положить себе в портфолио.
Британское правительство потратило более £500 тысяч на обновление логотипа сайта gov.uk, ограничившееся сменой цвета и перемещением точки. Новое оформление, разработанное агентством M&C Saatchi, вызвало насмешки чиновников и критику со стороны общественных организаций.
JavaScript, дизайн-системы и рок-н-ролл — что такое фронтенд в 2025 году?
Что происходит, когда в одном месте собираются JS-еры, UX-дизайнеры и исследователи? Получается Frontend&UX Talks!
Без сложных интерфейсов в фронтенде сегодня никуда: продукты становятся все масштабнее, а требования – все выше. Для всего этого нужны свежие и эффективные решения, которые ускорят разработку, и помогут провести релевантные UX-исследования.
Чтобы обсудить эти темы, мы в МойОфис пригласили ребят из разных компаний: Alfa Research Center, Лаборатория Касперского и Контур.
Всего на митапе будет 7 докладов, где расскажем:
как реактивное программирование и RxJS меняет разработку – и какие у него есть нюансы;
какие свежие css-спецификации могут упростить ежедневный кодинг;
как «редизайнить» сложные интерфейсы: рассказ на личном опыте переосмысления визуала настольных редакторов практически с нуля;
что за методы UX-исследований использует финтех сегодня – и какие из них можете перенять и вы :)
и многое другое, что поможет в работе со сложными интерфейсами!
Если тебе близки эти темы — приходи 26 июня в 15:00. Регистрация и подробности по ссылке.
1️⃣ Текущий прогресс по xsoulspace.dev привел к тому, что обнаружил что есть закономерность какие именно модели хороши для использования в проектировании layout страницы (спойлер - не записал какие 🤦♂️ кажется использовал Claude 4.0 thinking + Gemini 2.5 Pro).
Что попробовал сделать : нарисовал простой wireframe image -> сконвертировал в ACSII art, и затем скормил LLM для более корректного восприятия layout.
Оказалось что так проще, но относительно (за счет убирания лишних элементов проще понять что где расположено), но с другой стороны LLM все так же тяжело воспринимать layout (если он чересчур кастомный).
2️⃣обновил все flutter библиотеки, last answer, word by word, budget app до flutter 3.8 - пользовался агентами в окошках. В некоторых случаях правил руками, но в большей части работал по принципу PDSA (Plan Do Study Act), где я разрабатывал план, а агент по нему шел, потому изучал результаты и т.д. Вывод - нужно сильнее нарабатывать промпты.
3️⃣внезапно получил спам-рассылку-письмо с возможностью потестить on device API для того чтобы запускать модели. Чтобы потетстить решил запилить новое приложение для работы с промптами - действовал по принципу:
Идея и этические принципы
Палитра и дизайн система на основе идеи и принципов
План работы
Имплементация через агентов + доп ресерчи чтобы агенты понимали какую информацию брать.
Удалось собрать прототип за 12 часов (рабочую, включая все экраны и дизайн систему). Следующий этап - буду модифицировать чтобы можно было тестировать на реальных промптах в проектах.
Опыт: понял как создавать и работать с ролями (опишу в следующем посте про MVP), разобрался как запускать LLM на устройстве. Недостатки: нужно более точно прописывать тех стак, особенно ключевые места, такие как - синхронизация данных, тип хранилища и т.д. И хорошо если изначально можно давать wireframes, или подгенеривать на основании дизайн системы.
Хотелось сделать нечто среднее между игрой и обычным интерфейсом, но пока не получилось.
4️⃣Создал детальный план и начал прорабатывать новую систему сохранения данных. Для меня это оказалось большой проблемой - потому что Hive, Isar на flutter перестали поддерживаться, а другие библиотеки неудобно использовать (где-то перешел на Sembast).
В результате на мой взгляд завязка на том, что данные хранятся непонятно где для конечного пользователя опасна тем, что в случае прекращения работы с приложением теряются все данные. Это оч больно.
Поэтому решил объединить все идеи и написать одну библиотеку которая будет из коробки давать синхронизацию с гитом, github и папками. Так надеюсь удастся побороть проблему долговечности и надежности хранения данных. Пока агенты имплементировали 4 этапа из 5 (основную логику провайдеров данных), и как итог - собрал отдельное тестовое приложение (todo), чтобы протестировать работу (отдельный скриншот), понять недостатки и как можно быстрее завершить библиотеку чтобы начать интеграцию во все проекты. Это важно, потому что при одновременной интеграции сразу будет понятно что работает, а что нет, и таким образом будет проще получать feedback и развивать библиотеку качественно.
Спасибо за ваше время и хорошего дня!
p.s.:
Бумаги которые claude нашел по теме и одновременно не по теме)
Попробую публиковать серию постов про мои новые эксперименты с вайбкодингом.
Не использую v0, bolt - так как они совсем почти no-code + генерят react приложения, а мне интересно сейчас проработать поработать с Dart проектами.
Начал с крафта нового сайта для xsoulspace.dev (мой основной сайт по проектам, давным давно писал на flutter и очень давно не обновлял).
Основная идея в том, чтобы:
Как можно больше проработать паттернов вайбкодинга
Как можно качественнее научиться работать с дизайнерской точки зрения
Научиться учить агента новой информации (новый пишу на jaspr - а на нем крайне мало информации - и скорее всего не обучалась ни одна модель, поэтому вайбкодить на нем тяжело - если агенту дать задачу без правил и промптов - он не сможет завершить задачу и закопается в ошибках).
Пока что удалось сделать немного - восстановил навыки промптинга (которые прокачивал в прошлом году)
Восстановил часть промптов которые были раскиданы по проектам.
Частично удалось распараллелить работу (используя окна и табы агентов в cursor) и научиться давать относительно автономные задачи (по принципу PDSA (Plan Do Study Act))..
Исходный код открытый, поэтому буду делиться результатами когда завершу делать :) (надеюсь что скоро)
Пока что было две идеи:
Сделать в виде интерактивной игры (получились вырвиглазные кнопки
Каким-то образом придумать бенто..
Сложность с бенто и с игрой в том, что если всем моделям тяжело делать даже по картинке ассимитричные вещи и то, на чем они не обучались.
Некоторый текст и данные на картинке ниже абстрактные.
Спасибо за ваше время и хорошего дня!
P.s.: почему-то на хабре нельзя загрузить больше одной картинки в пост:(
P.p.s.: почему-то нельзя опубликовать публикацию если хоть раз проставил галочку запланировать..
Это большая тема, о которой можно говорить очень много. Самое главное, что возможности применения ограничиваются только вашей больной фантазией. Вы строите интерфейс своего модуля или плагина и вам нужно подтянуть данные из сторонней системы (список чего-нибудь по какому-нибудь API), чтобы сохранить выбранный id в Joomla. Или сделать какую-то проверку и в зависимости от неё показать то или иное сообщение пользователю. Для этого подойдут свои пользовательские типы полей.
Интерфейс Joomla по большей части описан в XML-файлах. У каждого из них свои параметры. Некоторые не описаны в документации (manual.joomla.org), поэтому самым любопытным будет полезно заглянуть в собственно файлы фреймворка по пути libraries/src/Form/FormField.php, а так же в libraries/src/Form/Fields. У каждого класса поля перечислены его специфические свойства, которые можно описывать в XML. А в своём типе поля вы можете устанавливать эти значения программно.
В моём модуле WT Quick links под капотом происходят изменения. Теперь для работы (в админке) ему нужен вспомогательный плагин. А в самом модуле нам бы проверить, а не выключен ли он?
В Joomla есть тип поля Note - заметка. Его можно использовать для вывода примечаний.
<field type="note"
name="your_note_for_user"
label="Заголовок примечания"
title="Альтернативный способ для заголовка"
description="Текст примечания"
class="col-12 alert alert-info"
heading="h1"
close="true"
/>
heading- указывать уровень заголовка. close - позволяет закрыть это примечание.
В классе поля libraries/src/Form/Field/NoteField.php описана логика вывода. И в принципе оно нам подходит для нашей задачи. Но оно будет выводить сообщение всегда, а нам нужно только тогда, когда плагин отключён.
Поэтому берём и создаём свой класс поля, который мы унаследуем от NoteField. Это значит, что у нас в руках будет весь инструментарий стандартного поля Note + то, что мы сами добавим.
addfieldprefix - указываем namespace к нашему классу, может быть любой нам нужный
name - нельзя полю без имени...
Это означает, что Joomla будет использовать класс поля из файла modules/mod_wt_quick_links/src/Fields/SystempluginstatusField.php. А в классе поля будет написано следующее:
<?php
// namespace для атрибута addfieldprefix
namespace Joomla\Module\Wtquicklinks\Site\Fields;
// нельзя напрямую обращаться к этому файлу
defined('_JEXEC') or die;
// подключаем родительский класс для переопределения
use Joomla\CMS\Form\Field\NoteField;
use Joomla\CMS\Language\Text;
use Joomla\CMS\Plugin\PluginHelper;
// имя класса и имя файла точь-в-точь
class SystempluginstatusField extends NoteField
{
protected $type = 'Systempluginstatus'; // тип поля без "Field" в конце
protected function getLabel()
{
// если плагин не включён
if(PluginHelper::isEnabled('system','wtquicklinks')) {
// меняем свойства родительского класса поля
$this->class = 'alert alert-danger w-100';
$this->element['label'] = '⚠️ А-а-а-а!';
$this->element['description'] = 'Плагин не включён!!';
// и просто рендерим его с нашими свойствами
return parent::getLabel();
}
// А иначе всё хорошо, скрываем поле из виду.
$this->parentclass = 'd-none';
return '';
}
}
Просто и удобно. И людям приятно, что о них позаботились и рассказали почему что-то не работает.
Т.к. мы пилим продукты и нам важна Обратная связь от пользователей - мы ее собираем в Google Forms, они оч крутые, но есть пара нюансов:
1) Обработка персональных данных по закону должна быть в РФ. Штраф до 500к рублей! И т.к. мы хотим делать бизнес на РФ - нам нужно использовать оператора из РФ.
2) Мы сейчас собрали таблицу куда приходят все “Данные” от наших иностранных пользователей.
У нас сейчас 6 таблиц, только с 3 расширений, дальше будет больше.
Ходить по страницам не так удобно как у всех топовых сервисов по созданию форм.
Мы хотим видеть одну таблицу с сортировкой по последним и фильтрами по всем ответам/заявкам.
Нужно было объяснить зачем нужна роль для LLM и как ей пользоваться)
Можно представить что роль - это персонаж, у которого есть свои особые характеристики и свойства. То как мы пропишем персонажа влияет на то, как агент или llm будет себя вести (стиль ответа, его поведение, "характер"). В чатах обычно можно использовать с "act as [ROLE]"
🖼 🚀 Я почти всегда выбираю ISR в Next.js для контентных сайтов.
Вот почему:
SSR: - Каждый запрос = генерация страницы
SSG: - Обновить контент = пересобрать весь проект - При 1000+ страниц билдится часами
ISR - лучший вариант: - Не генерит страницы сразу. Только по запросу. - Ключевой параметр: revalidate - определяет, как часто Next.js должен перегенерировать страницы.
Например revalidate: 60 - страница обновляется раз в 60 сек, а между этим - юзер видит кэш из памяти. Для некоторых контентных сайтов норма обновления данных 8-24 часа. Данные будут в оперативной памяти все это время.
💡 Фишка для SEO: После деплоя (CI/CD) - страницы прогреваются скриптом, чтобы не ждать первого захода. Это нужно чтобы поисковые боты видели всегда лучшую версию сайта, а не ждали прогрузки кеша.
📌 Вывод: Если тебе не нужен real-time обновления сайта - ISR закрывает почти все потребности.
Задача будет полезна разработчикам веб-приложений и сервисов.
Текст подготовил Артём Шумейко — внештатный райтер, амбассадор Selectel и автор YouTube-канала о разработке.
Условие
В компании «ГигаПост» выпустили долгожданное обновление: на сайте появилась новая кнопка «Подписаться на тему». Интерфейс готов, API поддерживает, проверено на стенде — все работает как часы.
Но после релиза начались странности. Некоторые пользователи видят кнопку, а некоторые — нет. Кто-то говорит, что она появилась через сутки. Кто-то — что только после нажатия Ctrl+F5.
Команда фронтенда уверена — код задеплоен. Бэкенд-эндпоинт отвечает корректно. На тестовом стенде все видно. Даже сам разработчик открывает сайт на своем ноутбуке — кнопка есть.
Начали подозревать баг в логике отображения, потом — переключение языка, затем подумали про авторизацию. Но фича пропадает у пользователей даже с одинаковыми условиями.
И вот тогда кто-то предложил простую мысль: а пользователи вообще видят свежую версию сайта?
Задача
Почему часть пользователей не видит новую кнопку, хотя код задеплоили? В чем может быть причина? Где в цепочке доставки может остаться старая версия?
Предлагайте свое решение в комментариях. А правильный ответ можно подсмотреть в Академии Selectel.
Апгрейднули тарифы и добавили пояснение к каждому. Давайте знакомиться:
👉Тариф Dev. Подходит для тестирования функционала нашего Managed Kubernetes — 200 ₽/мес
Пример использования: небольшие пет-проекты
👉Тариф Base. Для кластеров со средней нагрузкой, где отказоустойчивость не критична — 2000 ₽/мес
Пример использования: корпоративные веб-сервисы или ML inference-сервисы
👉Тариф Custom. Для гибкой настройки — от 2520 ₽/мес
Пример использования: highload-платформы и BigData/ML пайплайны
Пара слов о тарифе Custom. В нем можно выбрать количество ядер, объем оперативы и диска, а также установку с одной мастер-нодой или с тремя для настройки отказоустойчивости.
