Yandex for Frontend
Канал для фронтендеров от Яндекса. Рассказываем о мероприятиях для фронтендеров и любителей красивых и функциональных интерфейсов, делимся экспертизой. Чат: https://t.me/yalovefrontend Каналы Яндекса про разработку: https://t.me/addlist/Hrq31w2p1vUyOGZi
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام Yandex for Frontend
تُعد قناة Yandex for Frontend (@yandex4frontend) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 10 866 مشتركاً، محتلاً المرتبة 10 957 في فئة التكنولوجيات والتطبيقات والمرتبة 58 252 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 10 866 مشتركاً.
بحسب آخر البيانات بتاريخ 09 أكتوبر, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار -21، وفي آخر 24 ساعة بمقدار 0، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 25.38%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 16.37% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 2 757 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 778 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 13.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل интерфейс, yandex, typescript, css, фронтендеров.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Канал для фронтендеров от Яндекса. Рассказываем о мероприятиях для фронтендеров и любителей красивых и функциональных интерфейсов, делимся экспертизой.
Чат: https://t.me/yalovefrontend
Каналы Яндекса про разработку: https://t.me/addlist/Hrq31w2p1vU...”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 10 أكتوبر, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
Потом я создал три новых навыка AI-агента. И выложил их на GitHub: 🟡 compile — обрабатывает заметки из inbox по моим правилам ведения базы и обновляет AI Wiki 🟡 vault-health-check — быстрая проверка. Чинит сломанные ссылки, заметки без ссылок, устаревшие заметки, незакоммиченные изменения. Полезно запускать после ручных правок 🟡 deep-audit — глубокий аудит заметок: структура, связи, валидность утверждений и ссылок на источники🔜 Как с этим работать? Я прошу агента искать ответы в первую очередь в базе. И при необходимости собирать ответ в новую заметку. Например, спрашиваю: «Какие есть лучшие практики использования AI при разработке ПО?» Получаю суммаризацию статей и собранные вместе мысли из evergreen notes. Такой конспект можно быстро прочитать и провалиться глубже по ссылкам. Если информации в базе не хватило, прошу собрать дополнительные материалы и ссылки из моих источников. Сохраняю, компилирую, уточняю. И так по кругу 🙂 🔜 Что получилось в результате? 🟡 Я обработал весь накопившийся за годы текстовый бэклог, свыше 250 источников 🟡 Разобрался в темах, до которых не доходили руки: geospatial AI, тренды по AI в разработке, паттерны агентных систем 🟡 База стала не просто архивом ссылок, а рабочим инструментом. Теперь не нужно вспоминать, где именно видел нужную мысль. Достаточно задать вопрос агенту и провалиться в источники В итоге мне зашло. Я наконец-то разгрёб старые запасы ссылок, оставленных на потом, и создал процесс, в котором база знаний не просто копится, а сама помогает думать. Промпты, формат заметок и audit-сценарии я ещё дорабатываю. Но направление выглядит очень перспективным. Подписывайтесь: 💬 @Yandex4Frontend
Меня зовут Женя Успенский, я руковожу разработкой фронтенда в Яндекс Трекере и отвечаю за архитектуру платформы плагинов. Это отдельный механизм, который позволяет без навыков кодинга расширять Трекер собственными модулями без модификации его ядра.Хочу рассказать, как построить безопасную экосистему плагинов: изолировать сторонний JavaScript, организовать взаимодействие с API и при этом сохранить удобный Developer Experience. 🤯 Когда мы задумали дать пользователям возможность писать свой код прямо внутри Трекера, первая реакция команды безопасности была: «Вы что, с ума сошли?» И ребят можно понять. Пустить сторонний JavaScript в B2B-продукт с чувствительными данными — это прямой путь к XSS, вытаскиванию токенов и утечкам. Поэтому нам нужна была архитектура, которая позволит создавать сложные интерактивные плагины с динамическим UI, но при этом упакует их в железную изоляцию. 🈶 Как мы изолировали код Взвесив все за и против, остановились на классической изоляции через
iframe. Это решение выглядит не так концептуально, зато даёт гарантии безопасности и позволяет быстро выйти в продакшен.
Как это устроено:
🟡 Каждый плагин отдаётся с отдельного изолированного хоста, у которого нет доступа к cookie и хранилищу основного приложения
🟡 В параметрах iframe мы явно разрешаем только выполнение скриптов (allow-scripts) и жёстко ограничиваем все остальные возможности
🟡 Политика безопасности запрещает практически всё, в том числе сетевые запросы на любые внешние адреса, которые отличаются от собственного домена iframe
Все ключевые модули получившейся системы мы оформили как самостоятельные, независимые пакеты. Это позволяет подключать к платформе плагинов любые другие сервисы и не переписывать архитектуру изоляции с нуля. А общение плагина с сервисом и внешним миром происходит через специальный объект Bridge, который для транспорта использует postMessage.
✨ Мы хотели дать авторам плагинов хороший Developer Experience: строгую типизацию, автокомплит параметров в IDE и подсказки, но стандартные пути нас не устраивали. Поэтому мы нашли решение на стыке возможностей TypeScript-типов и объекта Proxy.
🈶 Что мы сделали
Мы отказались от генерации JS-кода в пользу генерации исключительно TypeScript-типов (.d.ts) напрямую из нашей OpenAPI-схемы. А вместо абстрактных имён методов мы стали использовать нативные REST-пути в виде строковых литералов. Синтаксис вызова API в нашем SDK выглядит так:
const issue = await sdk.api.v3.get['/issues/{id}']({
path: { id: 'QUEUE-123' },
query: { expand: 'comments' }
});
Когда разработчик пишет sdk.api.v3.get[ и ставит открывающую кавычку, TypeScript воспринимает это как обращение к свойству огромного интерфейса. Благодаря этому движки автокомплита и в VS Code, и в WebStorm моментально выводят список всех доступных эндпойнтов. И самое главное: IDE показывает полную JSDoc-документацию прямо во время набора строки.
Весь рантайм-роутер умещается буквально в 10 строк благодаря ES6 Proxy. Так что в исполняемом JS-файле нашего SDK нет ни одного упоминания эндпойнтов.
➡️ Читайте все подробности в статье на Хабре. Там я рассказал, как работает платформа плагинов и как мы тестировали её внутри Яндекса. А также поделился тем, что ещё есть под капотом нашего механизма.
Подписывайтесь:
💬 @Yandex4Frontend{flag_something}, где something — искомый флаг. Для решения большинства наших задач игрокам нужны знания фронтенда, сетей и инструментов разработки.
🈶 С чего всё начиналось
Нам хотелось делать классный онлайн: что-нибудь запоминающееся и выделяющееся. Так в 2021 году небольшая команда из трёх человек за две недели собрала полноценную CTF-игру с различными по сложности заданиями. В итоге у нас получилось 17 флагов, 8 уровней, 384 прохождения игры и один уютный чатик.
В 2022 году мы переписали движок и добавили номинации, в 2023-м — обзавелись собственной игровой вселенной и определились с визуальным стилем, в 2024-м — отправили героев в космос. А в этом году мы снова обновили сценарий и движок, чтобы ещё сильнее мотивировать участников исследовать мир.
🈶 Как придумываем задания
Мы собираем идеи заранее: в течение года находим странное и интересное, например особенности браузера, новые фичи CSS, необычные демки с CodePen и так далее. Потом для каждого задания пишем пояснение, как с ним работать.
До игры мы прорешиваем задачи самостоятельно и силами сторонних участников. В итоге у нас получается список заданий, которые отранжированы по сложности. Дальше остаётся только встроить их в игру без конфликтов с основным сюжетом.
➡️ В статье на Хабре я рассказал больше подробностей о том, как мы развиваем игру (и при чём тут Мона Лиза). А ещё поделился примерами заданий прошлых CTF.
Подписывайтесь:
💬 @Yandex4Frontendintl-push:
title: Intl Push
triggers:
- on: commit
into: trunk
max-active: 1
flow: intl-push
Скрипт проходит по изменениям в PR, находит добавленные ключи и формирует из них список. Затем для каждого воркспейса запускает команду, которая отправляет все ключи из кода в TMS, и туда же попадают новые. Свежие ключи улетают через API в систему управления переводами.
Но отправка ключей — полдела, нужно ещё забирать готовые переводы обратно в код. Поэтому ровно в 05:00 по Москве запускается cron-job:
intl-pull:
title: Intl Pull
flow: intl-pull
max-active: 1
schedule:
timezone: MSK
cron: 0 5 * * *
Скрипт выкачивает переводы для всех 27 языков, раскладывает данные по файлам локализации в репозитории и сам создаёт Pull Request с изменениями. И, если тесты проходят, отправляет его на автоапрув.
🧽 А ещё мы добавили в CI дополнительную проверку на дубликаты, чтобы нельзя было случайно слить два PR с одинаковыми ключами.
⏮ В рамках проекта мы сделали дашборд, который помогает нам узнавать статус перевода на конкретный язык. В нём видно всё: синие столбцы означают ключи, у которых задача есть, а красные, что её нет. Если графа какого-то языка внезапно покраснела на 30%, мы сразу понимаем, что кто-то влил крупную фичу, а переводы застряли. Поэтому можем среагировать до того, как это заметит пользователь.
❗️ У нас есть правило: фичу открываем на конкретную страну только после появления переводов на нужный язык.
Английский и русский обязательны всегда. Если фича нужна только в России, она открывается только для российских парков. Если нужна на зарубежные рынки, то ждём, пока переводы доедут. Дашборд позволяет отслеживать этот момент в реальном времени.
🈶 Какую проблему подсветила автоматизация
Когда вы удаляете React-компонент — вы устраняете вызов <Message>. ID исчезает из кодовой базы, но в TMS он остаётся.
Мы тратили ресурсы на хранение того, что пользователь никогда не увидит. И на момент аудита в TMS накопилось около 4–5 тысяч таких ключей-призраков. Но у нас уже давно есть скрипт, который сравнивает слепок ключей в коде со слепком в TMS, поэтому их можно постепенно удалять.
🈶 Как мы сэкономили рабочее время
В среднем разработчики раньше заводили 2,5 задачи на перевод в день, тратили около 2 минут на каждую и 15 минут на обновление файлов. Это 20 минут ручной работы на команду ежедневно — достаточно, чтобы выбить из рабочего потока. Теперь всё это делает CI.
💡 И мы можем гарантировать: если код в мастере сегодня, перевод будет на проде через N дней. Менеджеры планируют маркетинговые запуски и релизы в новых странах с точностью до дня.
➡️ Читайте все подробности в моей статье на Хабре. Там я рассказала, как мы жили до появления автоматизации и как устраняли накопившийся лингвистический долг, чтобы насладиться её результатами. А также поделилась метриками и задачами на будущее.
Подписывайтесь:
💬 @Yandex4Frontend