А вот и пятничная годнота!

Если кто хочет на себя примерить роль руководителя - будет информативно 🙌🏻

Можно вопросики кидать в чат канала

Вместо тысячи строк

GPT наблюдает за твоим 12-летним опытом работы в айти

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

Интересно, как ИИ определяет какие данные ему не нужны, и в какой период их чистит?

Всем привет!
Поприветствуйте нашего третьего спикера - Влад Худяков 🎙

Влад давно хотел выступить у нас на митапе и вот, наконец, у него получилось💪
О чем расскажет нам Влад?

Все мы так или иначе пересекаемся с задачами по анимации элементов и целых секций.

Легко если это базовое поведение по наведению или циклы. Другое дело - когда нужный результат анимации зависит от ряда параметров, времени, прогресса нескольких элементов и все это меняется динамически.
А если потом это затащить во Vue компонент, изменять из store и даже переиспользовать?

Рассмотрим варианты анимаций, реализацию тайм-лайнов при помощи GSAP. Посмотрим на его плюсы и минусы, а так же альтернативы.
Главное поймем - для каких анимаций достаточно CSS, а когда пора идти за библиотекой.

👉 РЕГИСТРАЦИЯ НА МИТАП 👈

Делюсь ссылочками, которые будут полезны вам для погружение в мир таймлайн анимации при помощи GSAP.

Кто не был на докладе прикрепляю ссылку на запись трансляции

Итак:
1) GSAP на уровне ядра очень самодостаточен. Он адаптивный, легко используется во фреймворках и даже понимает WebGL
Читать о ядре

2) Плагины расширяют возможности, делая его не просто станком таймлайнов.
Их куда больше, чем я охватил в докладе.
Смотреть все

3) Мы не должны думать, что это чисто для сайтов. Игрушки по типу angry birds, doodle jump и другие - отлично реализуются при помощи GSAP
Вот отличный пример игры

Больше примеров для наслаждения и желания уже сесть и покрутить библиотеку тут

Напрашивается долгожданный стрим, да?

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. Так бизнес сам управляет страницами и создает новые, не трогая код.

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

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

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

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