JEDI-манифест. Принципы работы с новичками

Я давно сокрушаюсь, что на нашем рынке недостаточно работают с джунами, и как следствие мы испытываем проблемы с мидлами и синьорами. И всю дорогу предлагал это изменить, брать больше джунов. Одна команда - один джун. Крайне понятный и простой прием, один управленческий принцип, имплементировав который, мы получим устойчивый приток новых кадров в нашу сферу

Но, потом начинаются справедливая критика: а "как их отбирать?", "как их растить?", "это же мне придется для них искать отдельные джуновские задачи?", и так далее. И вот тут и кроется проблема

Без понимания как с этим жить, естественно, никто не будет набирать джунов, либо, будет сильно страдать, делая какие-то отдельные лягушатники, огораживать их отдельной оградкой, не звать на «взрослые» планирования/стратегии/гильдии (нужное подчеркнуть), а потом будут удивляться, а чо это они у нас не растут?

Короче, к чему я все? Собрались мы с моими уважаемыми коллегами по цеху, которые, как и я, видят в этом проблему, знают как растить и топят за джунов, и задали себе вопрос: а какими принципами мы руководствуемся, организуя работу с джунами?

Так вот, мы собрали 15 принципов работы с джунами и назвали их JEDI-манифест (Junior Engagement and Development Initiative), который выложили на github. Далее мы будем писать гайды, как делать те или иные вещи и развивать методологическую составляющую. Мы очень надеемся, что этим сможем помочь разработчикам, командам и компаниям справится с непониманием и преодолеть этот барьер

Делитесь, ругайте, хвалите, мы очень будем рады любой обратной связи, а если вы разделяете ценности с нами и хотите поучаствовать - присоединяйтесь на правах опенсорса, мы будем рады)

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

https://www.youtube.com/watch?v=zp6wQn1L3sc

Друзья, мы совсем скоро начинаем #moscowcss_26

Ссылка на трансляцию: https://www.youtube.com/watch?v=bPgiOkMyxJQ
Начинаем в 19:00

Адрес:
Яндекс
ул. Льва Толстого, 16
https://yandex.ru/maps/org/yandeks/1124715036

Влияет ли безопасность приложения на time to market?

Думаю многие понимают, что деплой веб-приложения на продакшн сервера в крупных корпорациях не проходит через один pipeline
Это определенный выстроенный процесс для контроля установленного продуктом требования к качеству и безопасности.

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

Отсюда у студии может быть несколько сценариев, что бы не сорвать релизы и комфортно сработать:
1. Вы на берегу договариваетесь, какие проверенные вами библиотеки будете использовать в проекте и согласовываете. Возможно вовсе отказываетесь от их использования в пользу упрощения процедуры приемки у СБ, но это может повысить затраты на тестирование.

2. Вы внутри выстраиваете процесс CI/CD для проверки безопасности(SAST) вашего кода, что бы подстраховать путь приемки перед релизом.
Если слышите об этом впервые, можно минимально собрать это из библиотеки темплейтов по вкусу и покрыть хотя бы минимум - проверка на стороне корпорации все равно будет, просто шансов сорвать дедлайн и будет меньше.

SAST (Static Application Security Testing) - это метод анализа исходного кода на наличие уязвимостей без выполнения программы.

Многие уязвимости могут возникать именно из-за использования устаревших библиотек или расширяющих поддержку старых устройств.

Все это страховка, но не гарантия. Даже в популярных библиотеках типа axios есть свои приколы, которые могут проявить себя в сжатые сроки. Там нет уязвимости, но есть повод который обязательно развернет и запустит цикл повторно. Отказ от использования сторонних библиотек и применение SAST могут существенно снизить риски.

Важно соблюдать баланс между безопасностью, производительностью и функциональностью, что бы сократить time to market.

Все easy - анимация без математики и жесточайших расчетов новых координат

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

Как истинные ценители Vue (вуя) мы теперь имеем шанс делиться с вами демками на Codepen в любимом нам формате фреймворка
А это значит, что с минимальными усилиями это можно покрутить и разобрать без долго вникания тут

За базу взят тот самый, прилипший ко мне на конфах GSAP с расширением MorphSVG
Без знания координат и манипуляций с цифрами мы указываем в таймлайне какой элемент по id мы магически превращаем в другой элемент (так же указав id или селектор) и он чудно сделает все за нас.
Нам остается добавить динамики и прикрутить это к эвентам курсора.
Сам GreenSock дает возможность фри крутить это в песочнице Codepen - а значит можно изначально понять насколько библиотека упрощает жизнь разрабу и дает возможность оптимизировано креативить цепляя состояние к реактивности

Конечно, среди нас много хардовых ребят и вы как челлендж пересчитали бы это в координатах за пару часов/дней - но зачем, если через 15 минут это уже может греть вам сердечко
Не правда ли?

Шаблон Vue на Codepen
Дублирую ссылку на реализацию анимации

P.S второй пост за день. Не правда ли прекрасно?

Регулярные запросы для обновления простых данных.

При разработке функционала с острым желанием реал-тайма - в голову сразу лезут сокеты.

Есть более простой и рабочий вариант под среднюю задачу - написать щадящий интервальный автоапдейт.

Идейно: Мы перед обновлением данных проверяем вкладку на активность. Если вкладка не активна - запроса не будет, но как только мы на нее вернемся - улетит свежий запрос и данные станут актуальными.

Таким образом мы следим за состоянием вкладки и оперируем несколькими методами для стопа, старта автообновления и самим запросом данных.
Пример реализации во Vue показал в песочнице на фиче обновления комментариев

Вопрос: Для каких задач по вашему подходит такое решение?

GSAP теперь абсолютно бесплатный даже для коммерции!

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

На конференциях не раз слышал, что я словно рекламирую GreenSock ибо это платная штука и не все готовы изучать лицензию, брать риски.

Теперь кажется все, или уже нафиг не надо и AnimeJS захватит мир?

Как мы оптимизировали отпуска в корпорации Газпромнефть
с десятками тысяч сотрудников

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

Сотрудник видит количество доступных дней, создает периоды, выбирает даты и отправляет на согласование — и всё. Учитываются все ограничения бизнеса: отпуск можно взять только спустя 6 месяцев после приёма, один из периодов обязательно не менее 14 дней, а распланировать нужно все дни.

Руководитель получает наглядную картину по команде: кто когда уходит, есть ли пересечения, можно ли отпускать. Может тут же утвердить или внести корректировки.

Интерфейс собрали на Vue.js + state, стили на препроцессоре SCSS, бэкенд силами внутренней команды. Всё валидируется и на клиенте, и на сервере.



Как результат:
HR-отдел получает точные и валидные запросы на отпуск от сотрудников. Руководители могут запланировать свой отпуск, видят пересечения отпусков подчиненных, корректируют и могут планировать работу без слепых зон. Сотрудники видят количество доступных им дней и имеют возможность через интерфейс отправить запрос на согласование. Больше никакой бумаги и ручки - только интерфейс.

#кейсы #crm_системы #фронтенд

Через какие у вас планируется отпуск, и видно ли там пересечения с другими сотрудниками команды?

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

В проекте кинофестеваля мы начали с создания страниц, позже вынесли устоявшиеся компоненты в дизайн-систему.
Дизайнер обязан не просто рисовать страницы, а проектировать и поддерживать систему компонентов. В каждом макете выделяются повторяющиеся элементы — карточки, кнопки, заголовки, формы в общий UI Kit. Это независимые модули с чёткими отступами, поведением и состояниями. Это основа для компонентной системы проекта и дальнейшего кода.

На этапе вёрстки мы изолировали каждый модуль: никакой жёсткой привязки к странице, только входные параметры и слоты. Компоненты гибкие, конфигурируемые и легко переиспользуемые. Все компоненты вынесли в Figma, чтобы вся команда — разработчики, контентщики и менеджеры — знали, что уже реализовано и как этим пользоваться.

Следующий поинт — интеграция с админ-панелью. Контент-менеджеры не обращаются к разработчику для каждой правки контента. Вместо этого страницы собираются из модулей прямо в админке: менять порядок блоков, заголовки, описания, включать и выключать элементы. Для этого у каждого модуля прописываются поля, которые напрямую передаются как props. Так бизнес сам управляет страницами и создает новые, не трогая код.

Чтобы это работало в долгую, нужно одно правило: никаких дубликатов. Каждый новый экран собирается из существующих компонентов. Если чего-то не хватает — создаётся новый модуль, добавляется в библиотеку и документируется. Это позволяет избежать мутации компонентов и хаоса.

Модульный подход — это не про “красоту интерфейса”. Это про эффективность, масштабируемость и контроль продукта. Он позволяет быстро запускать новые страницы, тестировать идеи, экономить ресурсы и масштабировать продукт без перегрузки команды.

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

Удобно, не так ли?

Как можно ускорить запуск проектов с помощью v0 и ChatGPT 5 ⚡️

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

⚙️ v0 — позволяет не выдумывать визуал через код. Удачный инструмент для быстрой сборки верстки.

Используем для:
- Мгновенного старта — быстро собрать кликабельный интерфейс для системы бронирования за 3 часа на основе UI библиотек (допустим PrimeVue). В среднем на вёрстку уходило 2–3 дня.
- Проверки гипотез — получить несколько прототипов по ТЗ и показать его клиентам как можно скорее. Клиент смотрит рабочий функционал на моках без готового бэкенда.
- Экономии ресурсов — не требует много времени разработчика и продумывания расположения кнопок при разработке на этапе старта проекта.

Допиливать v0 прототипы можно на уровне легкого рефакторинга при помощи chatGPT, тк v0 переписывает при каждом запросе все компоненты с нуля

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

Используем для:
- Рефакторинга кода — можно оптимизировать модуль на Vue 3, уменьшив код или сделать его гибче сделав функции чистыми.
- Автоматизации рутины — базовая задача это генерация документации по API. Покрытие тестами по части функций.
- Быстрых решений — можно найти несколько способов реализации и выбрать для себя лучший предотвратив рефакторинг

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

Конечно для боевых проектов мы привлекаем дизайнера тк готовых компонентов для релиза не достаточно.
Если в вашем проекте нет брендбука/кита и функционал важнее чем визуал - вам хватит готовой UI библиотеки
⸻

Внимание вопрос:
Расскажите какие инструменты ускоряющие вашу работу и снижающие рутину вы для себя нашли и юзали ли v0?

Заряжен рассказывать о технолоджиях

Знакомство со спикерами WS МИТАП №5: Strapi. Путь фронтендера к фулстеку 🤩

Представляем вам приглашенного спикера — Владислава Худякова, основателя студии веб-разработки Spot.

Влад начинал свой путь с верстки на таблицах и подбора градиентов «на глаз», а сегодня вместе с командой создает реактивные решения для управления digital-продуктами. Основной стек Spot — Vue.js, Laravel и Python. Strapi команда использует в проектах, где важен быстрый запуск и гибкая настройка.

За последние годы Влад выступал на митапах Evrone, Иннополис, Vue MSK и Moscow CSS, участвовал в подкастах Cloud и Frontend Weekend, публиковал статьи на Хабре.

На митапе Влад поделится опытом в докладе «Многоязычный контент без боли: i18n в действии». Расскажет, как устроена локализация в Strapi 5: от включения и преднастройки моделей до работы с данными и лучших практик. Покажет, как правильно настраивать многоязычность, избегать ошибок с глобальными и переводимыми полями и запускать продукты в продакшн без лишней боли.

Не упустите возможность получить практические знания от эксперта, который совмещает разработку, управление студией и активное участие в IT-сообществе.

Напоминаем детали мероприятия:
Когда: 13 сентября, 16:00
Где: г. Ростов-на-Дону, ул. Города Волос 14, 2 этаж, Южный ИТ-Парк

Ознакомиться с полной программой мероприятия и зарегистрироваться можно здесь

Если не сможешь присутствовать очно, подключайся к онлайн-трансляции

Всем хай, вернулся в строй после первого долгого отпуска. Попутно афигенская новость:
Запись моего доклада по конструктору сайта на vue.js с конфы Msk Vue подъехала. В основе бэка кстати лежит Laravel как собственный такой Headless

Кто не был - есть возможность посмотреть на ютубе. Будут вопросики задавайте через комментарии этого поста - отвечу :)

Теперь ждем запись с Ростова, где в презе была инструкция как собрать мультиязычный сайт-конструктор на Strapi 5 :)

Всем доброго вечера пятнички!

Наверняка вы еще за пк, или по пути домой - а значит, что можно послушать запись доклада по теме: Многоязычный контент на Strapi 5 (i18n)

На примерах, которые я показываю в докладе можно получить не только мультиязычное API, но и возможность реализовать конструктор блоков сайта и применить в работе.

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

Будут вопросы - велком в комментарии - разберем