🔥 Ещё одна тема, которую многие не понимают по опыту. Особенно фронты!
👉 И причина, скорее всего, в лени, нехватке времени или других приоритетах — "разберусь потом", "и так работает", ну вы поняли...
А ведь если ты не понимаешь эту механику — велика вероятность, что предложишь не самое удачное решение в реальных задачах...
Давайте я попробую объяснить чуть проще.
👀 Вашему вниманию:
Service и Web Workers
Все знают, что браузер использует один поток (
Но если JavaScript-а слишком много — основной поток блокируется, и весь пользовательский интерфейс тормозит.
👉 Как избежать блокировок?
Воркеры (workers)!
Они позволяют выполнять код в фоновом потоке, не мешая рендеру и взаимодействию с пользователем.
---
💡 Кратко:
- Воркеры — отдельная среда выполнения JS, без доступа к window и document.
- Не могут трогать DOM напрямую.
- Используют отдельный поток → не мешают UI.
---
👷♂️ Web Workers
📌 Что умеют:
- Обрабатывать большие объёмы данных
- Выполнять сложную логику, чтобы не тормозил интерфейс
📌 Живут только пока вкладка открыта. Закрыл вкладку — web воркер завершил работу.
---
🛰 Service Workers
📌 Что умеют:
- Перехватывать сетевые запросы (
- Обрабатывать push-уведомления (
- Работать в фоне, даже если ни одна вкладка не открыта
📌 Где применяют:
- PWA (работа сайта без интернета)
- Push-уведомления на новостных сайтах
- Кэширование и заглушки при недоступности сервера
---
Надеюсь, стало понятнее 🙂
Если хотите — могу создать репу с примерами, чтобы было проще разобраться руками.
---
🔗 Полезные ресурсы:
https://web.dev/articles/workers-overview
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
👉 И причина, скорее всего, в лени, нехватке времени или других приоритетах — "разберусь потом", "и так работает", ну вы поняли...
А ведь если ты не понимаешь эту механику — велика вероятность, что предложишь не самое удачное решение в реальных задачах...
Давайте я попробую объяснить чуть проще.
👀 Вашему вниманию:
Service и Web Workers
Все знают, что браузер использует один поток (
main thread) для выполнения JavaScript-кода, отрисовки страницы и сборки мусора. Но если JavaScript-а слишком много — основной поток блокируется, и весь пользовательский интерфейс тормозит.
👉 Как избежать блокировок?
Воркеры (workers)!
Они позволяют выполнять код в фоновом потоке, не мешая рендеру и взаимодействию с пользователем.
---
💡 Кратко:
- Воркеры — отдельная среда выполнения JS, без доступа к window и document.
- Не могут трогать DOM напрямую.
- Используют отдельный поток → не мешают UI.
---
👷♂️ Web Workers
📌 Что умеют:
- Обрабатывать большие объёмы данных
- Выполнять сложную логику, чтобы не тормозил интерфейс
📌 Живут только пока вкладка открыта. Закрыл вкладку — web воркер завершил работу.
---
🛰 Service Workers
📌 Что умеют:
- Перехватывать сетевые запросы (
fetch)- Обрабатывать push-уведомления (
push)- Работать в фоне, даже если ни одна вкладка не открыта
📌 Где применяют:
- PWA (работа сайта без интернета)
- Push-уведомления на новостных сайтах
- Кэширование и заглушки при недоступности сервера
---
Надеюсь, стало понятнее 🙂
Если хотите — могу создать репу с примерами, чтобы было проще разобраться руками.
---
🔗 Полезные ресурсы:
https://web.dev/articles/workers-overview
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers
web.dev
Workers overview | Articles | web.dev
How web workers and service workers can improve the performance of your website, and when to use a web worker versus a service worker.
👍14🔥4
Буквально на этой неделе произошла интересная история.
Мы с коллегой проводили ассессмент одного frontend-разработчика.
И он буквально с порога — с ходу начинает негативить:
> «Вот эти ваши проверки ни к чему!»
> «Теория вообще не нужна — всё приходит с опытом!»
Честно говоря, мы немного опешили.
Ну да, если бы всё действительно приходило *только* с опытом — возможно, жить было бы и проще 🤷♀️
По ощущениям, у человека опыт есть, это видно.
Но — как мне показалось — не было кругозора и глубины знаний.
---
❓А вы что думаете? Нужно ли тратить время на самообразование и развитие?
Или достаточно просто «на работе разобраться» и все ресерчи делать походу?
Мы с коллегой проводили ассессмент одного frontend-разработчика.
И он буквально с порога — с ходу начинает негативить:
> «Вот эти ваши проверки ни к чему!»
> «Теория вообще не нужна — всё приходит с опытом!»
Честно говоря, мы немного опешили.
Ну да, если бы всё действительно приходило *только* с опытом — возможно, жить было бы и проще 🤷♀️
По ощущениям, у человека опыт есть, это видно.
Но — как мне показалось — не было кругозора и глубины знаний.
---
❓А вы что думаете? Нужно ли тратить время на самообразование и развитие?
Или достаточно просто «на работе разобраться» и все ресерчи делать походу?
🔥12
Media is too big
VIEW IN TELEGRAM
✨ Всем привет!
В продолжение недавнего поста — сегодня немного про веб-воркеры 👩💻
Честно говоря, на практике мне не приходилось их использовать — ведь сложные вычисления в идеале вообще не должны происходить на фронте. Всегда топлю за то, чтобы этим занимался бэкенд или хотя бы BFF.
Ну, если только вы не делаете игру с кучей анимаций и динамики 🤯
Но если всё-таки так вышло, что надо делать тяжёлые вычисления прямо на клиенте и при этом не блокировать интерфейс — вот небольшой лайфхак.
📦 Быстро накидала репу с простейшим примером:
https://github.com/gohintosh/web-worker-example
🎥 И рассказала всю логику в коротком трехминутном видео — без воды, всё по делу!
Надеюсь, пример окажется полезным, а объяснение — понятным.
Посмотрите обязательно! 🧡
🔗 Полезные ресурсы:
https://web.dev/learn/performance/web-worker-overview
https://doka.guide/js/web-workers/
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
https://www.w3.org/TR/2021/NOTE-workers-20210128/
В продолжение недавнего поста — сегодня немного про веб-воркеры 👩💻
Честно говоря, на практике мне не приходилось их использовать — ведь сложные вычисления в идеале вообще не должны происходить на фронте. Всегда топлю за то, чтобы этим занимался бэкенд или хотя бы BFF.
Ну, если только вы не делаете игру с кучей анимаций и динамики 🤯
Но если всё-таки так вышло, что надо делать тяжёлые вычисления прямо на клиенте и при этом не блокировать интерфейс — вот небольшой лайфхак.
📦 Быстро накидала репу с простейшим примером:
https://github.com/gohintosh/web-worker-example
🎥 И рассказала всю логику в коротком трехминутном видео — без воды, всё по делу!
Надеюсь, пример окажется полезным, а объяснение — понятным.
Посмотрите обязательно! 🧡
🔗 Полезные ресурсы:
https://web.dev/learn/performance/web-worker-overview
https://doka.guide/js/web-workers/
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
https://www.w3.org/TR/2021/NOTE-workers-20210128/
🔥16
💼Из разработчика в руководителя: с какими трудностями я столкнулась
Поскольку моя текущая роль — руководитель разработки, решила поделиться, с какими внутренними вопросами и сложностями я столкнулась, когда перешла на эту позицию:
🧠 Я почти не пишу код. Боже, я деградирую?!
💬 Как мотивировать команду?
🪫 Как работать с не мотивированными людьми?
📚 Как не забыть всё, что знала, и продолжать развиваться?
⏰ Где взять время, чтобы и задачи разгребать, и хоть чуть-чуть кодить?
📅 Почему так много встреч? И зачем я на всех?
🧾 Как ничего не забыть и не продолбать важное?
⚖️ Как не стать микроменеджером, когда всё кажется важным?
😵 Как не выгореть, пока разбираешься, кто ты теперь вообще?
Если есть что еще добавить пишите в чат.
Буду понемного писать посты о том как мне удается решать такого рода вопросы в том числе.
Потому что мы ведь все понимаем: не всю жизнь мы будем писать код. Надо как-то учиться двигаться дальше 🚀
Поскольку моя текущая роль — руководитель разработки, решила поделиться, с какими внутренними вопросами и сложностями я столкнулась, когда перешла на эту позицию:
🧠 Я почти не пишу код. Боже, я деградирую?!
💬 Как мотивировать команду?
🪫 Как работать с не мотивированными людьми?
📚 Как не забыть всё, что знала, и продолжать развиваться?
⏰ Где взять время, чтобы и задачи разгребать, и хоть чуть-чуть кодить?
📅 Почему так много встреч? И зачем я на всех?
🧾 Как ничего не забыть и не продолбать важное?
⚖️ Как не стать микроменеджером, когда всё кажется важным?
😵 Как не выгореть, пока разбираешься, кто ты теперь вообще?
Если есть что еще добавить пишите в чат.
Буду понемного писать посты о том как мне удается решать такого рода вопросы в том числе.
Потому что мы ведь все понимаем: не всю жизнь мы будем писать код. Надо как-то учиться двигаться дальше 🚀
🤯4👍3
Я решила в субботу ваши великолепные умы не перегружать 😂 поэтому просто реальная достаточно смешная история из моего опыта
🎓 Как я получила A++ за курсовую на магистратуре в Лондоне🙈😂
Март 2015, магистратура в Лондоне. Нам выдали assignment по модулю Network Computing. Задание: реализовать RMI (Remote Method Invocation) на Java.
RMI — это такой способ, с помощью которого один объект может вызывать методы другого объекта на другом компьютере.
На тот момент никто из нас — ни я, ни мои одногруппники — вообще не понимал, что такое этот RMI, и Java у всех был только на начальном уровне. С чего начинать — непонятно 🫠
Нашла в библиотеке очень толстую книгу про RMI. Прочитала вступление… поняла ничего 😅
Перерыла весь интернет — пусто.
Потом решилась поискать на YouTube… и О ЧУДО! Нашла чувака, который быстро и чётко всё объяснял, даже показал исходники 🙏 Я смотрела это видео раз 100, ставила на паузу, делала скриншоты, повторяла шаг за шагом.
Всё поняла! Переписала код, изменила названия переменных, классов, интерфейсов , расписала всё в отчёте до самых мелочей. Прям in details, как говорится 😎
Сдала курсовую. В день результатов я просто молилась, чтобы получить хотя бы C — особенно с учётом проверки на плагиат 😬
И вот… мне ставят A++ 😱
Да ещё и забрали мой диск с работой в архив — чтобы показывать другим студентам как пример 🫠
Остальные получили так себе. Даже один араб, которому было лет на 6 больше меня и он вроде как опытный Java разраб, получил B+ 😒 Ну, может и несправедливо… но я ведь реально поняла тему и могла бы ответить на любой вопрос 😆
P.S. С того момента прошло 10 лет 😂 лучше меня не спрашивать про RMI 🤣 на харде может быть смогу найти исходники, но это не точно 😂 давайте лучше потом обсудим RPC, gRPC, REST 😂
🎓 Как я получила A++ за курсовую на магистратуре в Лондоне🙈😂
Март 2015, магистратура в Лондоне. Нам выдали assignment по модулю Network Computing. Задание: реализовать RMI (Remote Method Invocation) на Java.
RMI — это такой способ, с помощью которого один объект может вызывать методы другого объекта на другом компьютере.
На тот момент никто из нас — ни я, ни мои одногруппники — вообще не понимал, что такое этот RMI, и Java у всех был только на начальном уровне. С чего начинать — непонятно 🫠
Нашла в библиотеке очень толстую книгу про RMI. Прочитала вступление… поняла ничего 😅
Перерыла весь интернет — пусто.
Потом решилась поискать на YouTube… и О ЧУДО! Нашла чувака, который быстро и чётко всё объяснял, даже показал исходники 🙏 Я смотрела это видео раз 100, ставила на паузу, делала скриншоты, повторяла шаг за шагом.
Всё поняла! Переписала код, изменила названия переменных, классов, интерфейсов , расписала всё в отчёте до самых мелочей. Прям in details, как говорится 😎
Сдала курсовую. В день результатов я просто молилась, чтобы получить хотя бы C — особенно с учётом проверки на плагиат 😬
И вот… мне ставят A++ 😱
Да ещё и забрали мой диск с работой в архив — чтобы показывать другим студентам как пример 🫠
Остальные получили так себе. Даже один араб, которому было лет на 6 больше меня и он вроде как опытный Java разраб, получил B+ 😒 Ну, может и несправедливо… но я ведь реально поняла тему и могла бы ответить на любой вопрос 😆
P.S. С того момента прошло 10 лет 😂 лучше меня не спрашивать про RMI 🤣 на харде может быть смогу найти исходники, но это не точно 😂 давайте лучше потом обсудим RPC, gRPC, REST 😂
👍13
👋 Всем привет!
Недавно наткнулась на интересный сайт — https://bigfrontend.dev/ — его называют LeetCode-ом для фронтендеров. Там собрано много клёвых задач для практики, и я решила поделиться находкой 😊
Нашла задачку, решила — и поняла, что это отличная идея для небольших регулярных постов. Если зайдёт, можно делать рубрику: решать задачи вместе и обсуждать 💬
Давайте сегодня разомнёмся на одной из задач JavaScript уровня medium:
👉 https://bigfrontend.dev/problem/get-DOM-tags
Условие:
Есть DOM-дерево. Нужно вернуть массив уникальных имён тегов (в нижнем регистре). Порядок не важен.
Как подойти к решению:
Поскольку перед нами дерево — логично пройти его в ширину или глубину. А для хранения уникальных тегов идеально подойдёт
Как нам сделать дерево так чтобы удобно было обходить его? Думаю что таким вопросом уже кто-то точно задавался. (тут даже можно погуглить если ничего на ум не приходит чтобы не изобретать велосипед, тут главное правильное направление мыслей все же)
Есть такой встроенный в браузер объект [
Создаётся он через
👉 [Документация](https://developer.mozilla.org/en-US/docs/Web/API/Document/createTreeWalker)
Шаги:
1. Создаём
2. Создаём экземпляр класса
3. Берём текущую ноду
4. Пока есть ноды — добавляем их
5. Когда обойдём всё дерево — возвращаем массив из
Решение:
P.S. надеюсь оказалось полезно и вы что-то новое узнали и возможно даже продолжите решать задачки из этого сайта)
#frontend #javanoscript #разборЗадач #leetcodeДляФронта
Недавно наткнулась на интересный сайт — https://bigfrontend.dev/ — его называют LeetCode-ом для фронтендеров. Там собрано много клёвых задач для практики, и я решила поделиться находкой 😊
Нашла задачку, решила — и поняла, что это отличная идея для небольших регулярных постов. Если зайдёт, можно делать рубрику: решать задачи вместе и обсуждать 💬
Давайте сегодня разомнёмся на одной из задач JavaScript уровня medium:
👉 https://bigfrontend.dev/problem/get-DOM-tags
Условие:
Есть DOM-дерево. Нужно вернуть массив уникальных имён тегов (в нижнем регистре). Порядок не важен.
Как подойти к решению:
Поскольку перед нами дерево — логично пройти его в ширину или глубину. А для хранения уникальных тегов идеально подойдёт
Set.Как нам сделать дерево так чтобы удобно было обходить его? Думаю что таким вопросом уже кто-то точно задавался. (тут даже можно погуглить если ничего на ум не приходит чтобы не изобретать велосипед, тут главное правильное направление мыслей все же)
Есть такой встроенный в браузер объект [
TreeWalker](https://developer.mozilla.org/en-US/docs/Web/API/TreeWalker). Он позволяет удобно обойти DOM.Создаётся он через
document.createTreeWalker:👉 [Документация](https://developer.mozilla.org/en-US/docs/Web/API/Document/createTreeWalker)
Шаги:
1. Создаём
TreeWalker: document.createTreeWalker(tree, NodeFilter.SHOW_ELEMENT), второй аргумент нам нужен для того чтобы нам в дереве были возвращены только элементы2. Создаём экземпляр класса
Set, в который будем добавлять теги.3. Берём текущую ноду
treeWalker.currentNode.4. Пока есть ноды — добавляем их
tagName (в нижнем регистре) в Set и двигаемся к следующей.5. Когда обойдём всё дерево — возвращаем массив из
Set.Решение:
/**
* @param {HTMLElement} tree
* @return {string[]}
*/
function getTags(tree) {
const treeWalker = document.createTreeWalker(tree, NodeFilter.SHOW_ELEMENT);
const res = new Set();
let cur = treeWalker.currentNode;
while (cur) {
res.add(cur.tagName.toLowerCase());
cur = treeWalker.nextNode();
}
return Array.from(res);
}
P.S. надеюсь оказалось полезно и вы что-то новое узнали и возможно даже продолжите решать задачки из этого сайта)
#frontend #javanoscript #разборЗадач #leetcodeДляФронта
bigfrontend.dev
BFE.dev - prepare for Front-End job interviews.
BFE.dev is a place to practice Front-End dev skills, discuss with others, get ready for interviews and get yourdream offer.
🔥12👍1
🎨 Организация стилей в современных веб-приложениях
Когда-то мы писали просто
А теперь… десятки подходов, библиотек и баталии в комментариях 😅
Вот краткий обзор популярных решений (по моему мнению).
---
💡 Styled-components
📄 [Документация](https://styled-components.com/docs)
💻 [Пример](https://styled-components.com/docs/basics#getting-started)
⏱️ Когда применяются стили: во время выполнения (runtime)
🛠 Настройка Webpack: ❌ не требуется
🔥 Размер бандла: больше, т.к. включает runtime
🚀 Плюсы: удобный синтаксис, динамические стили
⚠️ Минусы: runtime cost
---
💡 Linaria
📄 [Документация](https://github.com/callstack/linaria/tree/master/docs)
💻 [Пример](https://github.com/callstack/linaria/tree/master/examples)
⏱️ Когда применяются стили: build-time
🛠 Настройка Webpack: ✅ обязательна, нужны плагины
🔥 Размер бандла: минимальный — в итоговом JS нет стилей
🚀 Плюсы: без runtime
⚠️ Минусы: сложнее настроить
---
💡 CSS Modules
📄 [Документация](https://github.com/css-modules/css-modules/tree/master/docs)
💻 [Пример](https://github.com/css-modules/webpack-demo)
⏱️ Когда применяются стили: на этапе сборки (build-time)
🛠 Настройка Webpack: да, если настраиваешь вручную
🔥 Размер бандла: небольшой
🚀 Плюсы: простой, без runtime
⚠️ Минусы: не такой гибкий как css in js
---
✨ В итоге:
- Хочешь простоты — CSS Modules
- Нужны динамические стили — Styled-components
- Хочешь скорость и zero-runtime — Linaria
А какой из подходов вам больше всего нравится и почему?
#frontend #css #styledcomponents #linaria #cssmodules #вебразработка
Когда-то мы писали просто
style.css — и всё работало. А теперь… десятки подходов, библиотек и баталии в комментариях 😅
Вот краткий обзор популярных решений (по моему мнению).
---
💡 Styled-components
📄 [Документация](https://styled-components.com/docs)
💻 [Пример](https://styled-components.com/docs/basics#getting-started)
⏱️ Когда применяются стили: во время выполнения (runtime)
🛠 Настройка Webpack: ❌ не требуется
🔥 Размер бандла: больше, т.к. включает runtime
🚀 Плюсы: удобный синтаксис, динамические стили
⚠️ Минусы: runtime cost
---
💡 Linaria
📄 [Документация](https://github.com/callstack/linaria/tree/master/docs)
💻 [Пример](https://github.com/callstack/linaria/tree/master/examples)
⏱️ Когда применяются стили: build-time
🛠 Настройка Webpack: ✅ обязательна, нужны плагины
🔥 Размер бандла: минимальный — в итоговом JS нет стилей
🚀 Плюсы: без runtime
⚠️ Минусы: сложнее настроить
---
💡 CSS Modules
📄 [Документация](https://github.com/css-modules/css-modules/tree/master/docs)
💻 [Пример](https://github.com/css-modules/webpack-demo)
⏱️ Когда применяются стили: на этапе сборки (build-time)
🛠 Настройка Webpack: да, если настраиваешь вручную
🔥 Размер бандла: небольшой
🚀 Плюсы: простой, без runtime
⚠️ Минусы: не такой гибкий как css in js
---
✨ В итоге:
- Хочешь простоты — CSS Modules
- Нужны динамические стили — Styled-components
- Хочешь скорость и zero-runtime — Linaria
А какой из подходов вам больше всего нравится и почему?
#frontend #css #styledcomponents #linaria #cssmodules #вебразработка
Styled-Components
Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress
❤3
Всем привет!
Вижу по вашим реакциям, что мой последний пост вам не особо зашел 😅
А потом совершенно случайно натыкаюсь на этот апдейт от команды styled-components — https://opencollective.com/styled-components/updates/thank-you — и понимаю, что с 18 марта 2025 года библиотека официально признана deprecated.
Причины:
🛑 Команда React де-факто задепрекейтила некоторые API, включая Context API, которое недоступно в React Server Components и не имеет пути миграции.
🌪 Экосистема в целом ушла от концепции css-in-js. Альтернативы вроде Tailwind набрали дикую популярность и вытеснили старые подходы.
👋 Основной мейнтейнер библиотеки (под ником quantizor) больше не использует styled-components в продакшене крупных проектов. А значит, реальные кейсы применения тоже будут постепенно исчезать.
В арсенале у нас по-прежнему остаются CSS Modules и Linaria, которые продолжают жить и развиваться 💪
Вижу по вашим реакциям, что мой последний пост вам не особо зашел 😅
А потом совершенно случайно натыкаюсь на этот апдейт от команды styled-components — https://opencollective.com/styled-components/updates/thank-you — и понимаю, что с 18 марта 2025 года библиотека официально признана deprecated.
Причины:
🛑 Команда React де-факто задепрекейтила некоторые API, включая Context API, которое недоступно в React Server Components и не имеет пути миграции.
🌪 Экосистема в целом ушла от концепции css-in-js. Альтернативы вроде Tailwind набрали дикую популярность и вытеснили старые подходы.
👋 Основной мейнтейнер библиотеки (под ником quantizor) больше не использует styled-components в продакшене крупных проектов. А значит, реальные кейсы применения тоже будут постепенно исчезать.
В арсенале у нас по-прежнему остаются CSS Modules и Linaria, которые продолжают жить и развиваться 💪
Opencollective
Thank you - styled-components
First and foremost, thank you to everyone who has contributed to styled-components over the years. Open Source is hard work, and many of the larger feature and/or refactoring drives probably would never have shipped without your support! As...
❤7👍4💯2
Всем привет!
И вот — мой первый пост из серии «Борьба с тараканами» (читай: внутренними установками 🪳).
### 🧠 Таракан №1:
«Я почти не пишу код. Боже, я деградирую?!»
Долгое время мне казалось, что всё в нашей профессии крутится вокруг кода.
Типа: я пишу код — значит, делаю что-то важное и сложное.
А всё остальное — «ну это же просто, там думать особо не надо».
(Спойлер: надо. И ещё как.)
Однажды я попробовала себя в роли аналитика. И знаете, мой мозг отказывался воспринимать написанную задачу как результат моей работы. Типа: *всё? серьёзно?*
Как же я ошибалась.
Если в задаче плохо проработан системный анализ — никакая разработка, а тем более тестирование, не принесёт удовольствия.
Вся команда будет страдать.
Разработка — это лишь один из этапов. Чтобы идея, рожденная на этапе discovery, воплотилась в реальность, нужно пройти длинный путь: исследование, проектирование, согласования и только потом реализация.
И честно? По мне иногда дизайн интерфейсов сложнее, чем «просто реализовать по ТЗ».
🧩 А ещё одно важное наблюдение:
Если в команде не налажены процессы, атмосфера токсичная, нет мотивации и ясности — никакой код не спасёт.
Да, программирование — это круто. Но по-настоящему оно может быть и хобби.
А вот тимлид — это про масштаб. Это и наставничество, и поддержка команды, и создание культуры. Это про системные изменения и осознанный вклад.
И да — тимлид вполне может (и должен) брать задачи из бэклога, пусть хотя бы на 20%.
Но главное — понимать, зачем и ради чего ты в этой роли.
---
#тараканытимлида
Продолжение следует 👀
И вот — мой первый пост из серии «Борьба с тараканами» (читай: внутренними установками 🪳).
### 🧠 Таракан №1:
«Я почти не пишу код. Боже, я деградирую?!»
Долгое время мне казалось, что всё в нашей профессии крутится вокруг кода.
Типа: я пишу код — значит, делаю что-то важное и сложное.
А всё остальное — «ну это же просто, там думать особо не надо».
(Спойлер: надо. И ещё как.)
Однажды я попробовала себя в роли аналитика. И знаете, мой мозг отказывался воспринимать написанную задачу как результат моей работы. Типа: *всё? серьёзно?*
Как же я ошибалась.
Если в задаче плохо проработан системный анализ — никакая разработка, а тем более тестирование, не принесёт удовольствия.
Вся команда будет страдать.
Разработка — это лишь один из этапов. Чтобы идея, рожденная на этапе discovery, воплотилась в реальность, нужно пройти длинный путь: исследование, проектирование, согласования и только потом реализация.
И честно? По мне иногда дизайн интерфейсов сложнее, чем «просто реализовать по ТЗ».
🧩 А ещё одно важное наблюдение:
Если в команде не налажены процессы, атмосфера токсичная, нет мотивации и ясности — никакой код не спасёт.
Да, программирование — это круто. Но по-настоящему оно может быть и хобби.
А вот тимлид — это про масштаб. Это и наставничество, и поддержка команды, и создание культуры. Это про системные изменения и осознанный вклад.
И да — тимлид вполне может (и должен) брать задачи из бэклога, пусть хотя бы на 20%.
Но главное — понимать, зачем и ради чего ты в этой роли.
---
#тараканытимлида
Продолжение следует 👀
👍8🔥3❤2
Всем привет!
Недавно задумалась: как же несправедливо, что почти все фронты отлично знают как работают
📌 На самом деле всё просто. Вот отличная статья, где всё на пальцах:
https://css-tricks.com/using-requestanimationframe/
---
🧠 Что это вообще?
Метод
> “Эй, я хочу сделать анимацию — позови меня перед следующим кадром.”
Браузер вызовет вашу функцию ровно перед перерисовкой экрана.
Это обычно происходит 60 раз в секунду (60 Гц), но может быть и 120 или 144 Гц — в зависимости от монитора.
(И вам не нужно определять частоту — кайф же!)
👀 А если вкладка в фоне — браузер приостановит вызовы, чтобы не тратить ресурсы зря.
---
✍️ Синтаксис супер-простой:
📌 Вызовите один раз — и функция будет рекурсивно запускаться перед каждым кадром. Идеально для прогресс-баров, скролл-эффектов, игр, всего где нужна плавность.
---
⚠️ Главное — не забывайте вовремя отменять
Недавно задумалась: как же несправедливо, что почти все фронты отлично знают как работают
setTimeout и setInterval, но мало кто (по моему опыту на собесах) в курсе про requestAnimationFrame.📌 На самом деле всё просто. Вот отличная статья, где всё на пальцах:
https://css-tricks.com/using-requestanimationframe/
---
🧠 Что это вообще?
Метод
window.requestAnimationFrame() сообщает браузеру: > “Эй, я хочу сделать анимацию — позови меня перед следующим кадром.”
Браузер вызовет вашу функцию ровно перед перерисовкой экрана.
Это обычно происходит 60 раз в секунду (60 Гц), но может быть и 120 или 144 Гц — в зависимости от монитора.
(И вам не нужно определять частоту — кайф же!)
👀 А если вкладка в фоне — браузер приостановит вызовы, чтобы не тратить ресурсы зря.
---
✍️ Синтаксис супер-простой:
function repeatOften() {
// делаем что-то на каждом кадре
requestAnimationFrame(repeatOften);
}
requestAnimationFrame(repeatOften);📌 Вызовите один раз — и функция будет рекурсивно запускаться перед каждым кадром. Идеально для прогресс-баров, скролл-эффектов, игр, всего где нужна плавность.
---
⚠️ Главное — не забывайте вовремя отменять
requestAnimationFrame, если он больше не нужен: иначе будет утечка памяти.CSS-Tricks
Using requestAnimationFrame | CSS-Tricks
There used to be just one way to do a timed loop in JavaScript: setInterval(). If you needed to repeat something pretty fast (but not
👍10🔥5
🧠 Как ничего не забыть и не продолбать важное?
В своей работе я использую два приложения, которые помогают держать всё под контролем и ничего не забывать:
🗂 [Obsidian](https://obsidian.md/) и ✅ [SingularityApp](https://singularity-app.com/)
Они выполняют разные задачи, и вместе — идеальный дуэт.
---
📘 Obsidian — мое личное хранилище знаний.
Я настроила удобную структуру файлов и пользуюсь быстрым поиском по ключевым словам. Там лежит всё:
- цели и планы,
- заметки про людей (полезно, если нужно дать обратную связь),
- черновики речей и выступлений,
- скрипты собесов и просто личные инсайты.
А ещё — это обычные
Можно синхронизировать между устройствами при необходимости и всегда иметь всё под рукой.
---
📆 SingularityApp — мой таск-менеджер на каждый день.
Здесь я фиксирую задачи, даже если они мелкие и несрочные.
Например:
- «Поставить встречу с командой через 2 дня» — чтобы не забыть и не отвлекаться сейчас.
- «Уточнить вопрос после звонка» — небольшая заметка, которая потом напомнит в нужный момент.
Таким образом, я:
— не распыляюсь,
— быстро реагирую,
— держу в голове ровно ноль мыслей 😄
---
📌 Итог: я помню все договорённости, ничего не теряю, и успеваю в 10 раз больше.
#тараканытимлида
В своей работе я использую два приложения, которые помогают держать всё под контролем и ничего не забывать:
🗂 [Obsidian](https://obsidian.md/) и ✅ [SingularityApp](https://singularity-app.com/)
Они выполняют разные задачи, и вместе — идеальный дуэт.
---
📘 Obsidian — мое личное хранилище знаний.
Я настроила удобную структуру файлов и пользуюсь быстрым поиском по ключевым словам. Там лежит всё:
- цели и планы,
- заметки про людей (полезно, если нужно дать обратную связь),
- черновики речей и выступлений,
- скрипты собесов и просто личные инсайты.
А ещё — это обычные
.md-файлы. Разработчики меня поймут 😉 Можно синхронизировать между устройствами при необходимости и всегда иметь всё под рукой.
---
📆 SingularityApp — мой таск-менеджер на каждый день.
Здесь я фиксирую задачи, даже если они мелкие и несрочные.
Например:
- «Поставить встречу с командой через 2 дня» — чтобы не забыть и не отвлекаться сейчас.
- «Уточнить вопрос после звонка» — небольшая заметка, которая потом напомнит в нужный момент.
Таким образом, я:
— не распыляюсь,
— быстро реагирую,
— держу в голове ровно ноль мыслей 😄
---
📌 Итог: я помню все договорённости, ничего не теряю, и успеваю в 10 раз больше.
#тараканытимлида
Obsidian
Obsidian - Sharpen your thinking
The free and flexible app for your private thoughts.
👍6❤3🔥3
Сижу себе спокойно, никого не трогаю — и тут прилетает уведомление от YouTube:
"Почему BFF должны писать именно фронтендеры" 🎯
По моему опыту, чаще всего BFF (Backend for Frontend) действительно пишут фронты. Хотя бывают кейсы, когда за это берутся и бэки. Всё зависит от проекта и команды.
В общем, интересное выступление, рекомендую к просмотру!
👉 https://youtube.com/shorts/1C2nT0FHn1E?si=uN6Ulek19mh1SNNs
"Почему BFF должны писать именно фронтендеры" 🎯
По моему опыту, чаще всего BFF (Backend for Frontend) действительно пишут фронты. Хотя бывают кейсы, когда за это берутся и бэки. Всё зависит от проекта и команды.
В общем, интересное выступление, рекомендую к просмотру!
👉 https://youtube.com/shorts/1C2nT0FHn1E?si=uN6Ulek19mh1SNNs
YouTube
Почему BFF должны писать именно фронтендеры
Это фрагмент выступления Максима Вишневского, архитектора в Mindbox, на «Я 💛 Фронтенд 2025». В докладе Максим разобрал, почему стандартных API недостаточно ...
🔥6
Достижение субкадровой интерполяции с помощью GSAP и Web Workers
Помню, как впервые узнала о GSAP: одна знакомая попросила меня стать её ментором. Просьба была необычной — она хотела стать фронтенд-разработчиком и верстать рекламные баннеры используя GSAP.
На тот момент я вообще не знала, что такое GSAP. Но отказать не смогла. Сразу предупредила: у нас три месяца интенсива, и если будут пропуски домашних заданий или я увижу отсутствие мотивации — мы попрощаемся.
Так я и погрузилась в мир анимаций :)
Но пост не об этом!
Недавно я случайно наткнулась на статью:
👉 [Achieving Sub-Frame Interpolation with GSAP and Web Workers](https://dev.to/hexshift/achieving-sub-frame-interpolation-with-gsap-and-web-workers-4a50)
И это как раз в тему — ведь недавно в канале мы обсуждали и Web Workers, и
Анимация в браузере ограничена частотой обновления экрана (обычно 60 кадров в секунду). Но с помощью небольшого творческого хакинга можно симулировать субкадровую интерполяцию — это способ вычислять и отрисовывать промежуточные состояния между кадрами, чтобы анимации выглядели ещё плавнее, чем позволяет частота обновления экрана.
Если хотите добиться суперплавной анимации без блокировки основного потока, перенесите расчёты анимаций в Web Worker.
Это действительно ускоряет работу и разгружает главный поток.
Спасибо, кэп! Как говорится, повторение — мать учения 😄
Статью читать необязательно, но можно пробежаться глазами по коду!
Помню, как впервые узнала о GSAP: одна знакомая попросила меня стать её ментором. Просьба была необычной — она хотела стать фронтенд-разработчиком и верстать рекламные баннеры используя GSAP.
На тот момент я вообще не знала, что такое GSAP. Но отказать не смогла. Сразу предупредила: у нас три месяца интенсива, и если будут пропуски домашних заданий или я увижу отсутствие мотивации — мы попрощаемся.
Так я и погрузилась в мир анимаций :)
Но пост не об этом!
Недавно я случайно наткнулась на статью:
👉 [Achieving Sub-Frame Interpolation with GSAP and Web Workers](https://dev.to/hexshift/achieving-sub-frame-interpolation-with-gsap-and-web-workers-4a50)
И это как раз в тему — ведь недавно в канале мы обсуждали и Web Workers, и
requestAnimationFrame!Анимация в браузере ограничена частотой обновления экрана (обычно 60 кадров в секунду). Но с помощью небольшого творческого хакинга можно симулировать субкадровую интерполяцию — это способ вычислять и отрисовывать промежуточные состояния между кадрами, чтобы анимации выглядели ещё плавнее, чем позволяет частота обновления экрана.
Если хотите добиться суперплавной анимации без блокировки основного потока, перенесите расчёты анимаций в Web Worker.
Это действительно ускоряет работу и разгружает главный поток.
Спасибо, кэп! Как говорится, повторение — мать учения 😄
Статью читать необязательно, но можно пробежаться глазами по коду!
DEV Community
Achieving Sub-Frame Interpolation with GSAP and Web Workers
Browser animation timing is limited by the refresh rate (typically 60fps). But with a bit of creative...
👍7
👋 Всем привет!
Вчера прочитала интересную статью:
📎 https://www.smashingmagazine.com/2025/04/building-offline-friendly-image-upload-system/
В ней рассказывается, как создать offline-friendly систему загрузки изображений.
✨ Почему стоит прочитать:
В статье есть отличные инсайты, которые можно попробовать применить на практике. Наверное, именно в этом и заключается ценность подобных материалов: когда вы столкнётесь с похожим кейсом, уже будете знать, какие технологии использовать и как построить решение.
📌 В кратце:
Что делать, если пользователь загружает изображение, а в этот момент пропадает сеть? Чтобы не заставлять его делать всё заново, можно:
— сохранять изображение локально через IndexedDB (только при отсутствии сети);
— использовать service worker для отслеживания восстановления соединения;
— запускать отложенную загрузку через Background Sync, как только сеть появится.
P.S. Подробнее про Background Sync — вот тут:
https://developer.mozilla.org/ru/docs/Web/API/Background_Fetch_API
P.P.S. Автор также упоминает об ограничениях. В общем, рекомендую к прочтению.
Вчера прочитала интересную статью:
📎 https://www.smashingmagazine.com/2025/04/building-offline-friendly-image-upload-system/
В ней рассказывается, как создать offline-friendly систему загрузки изображений.
✨ Почему стоит прочитать:
В статье есть отличные инсайты, которые можно попробовать применить на практике. Наверное, именно в этом и заключается ценность подобных материалов: когда вы столкнётесь с похожим кейсом, уже будете знать, какие технологии использовать и как построить решение.
📌 В кратце:
Что делать, если пользователь загружает изображение, а в этот момент пропадает сеть? Чтобы не заставлять его делать всё заново, можно:
— сохранять изображение локально через IndexedDB (только при отсутствии сети);
— использовать service worker для отслеживания восстановления соединения;
— запускать отложенную загрузку через Background Sync, как только сеть появится.
P.S. Подробнее про Background Sync — вот тут:
https://developer.mozilla.org/ru/docs/Web/API/Background_Fetch_API
P.P.S. Автор также упоминает об ограничениях. В общем, рекомендую к прочтению.
Smashing Magazine
Building An Offline-Friendly Image Upload System — Smashing Magazine
Poor internet connectivity doesn’t have to mean poor UX. With PWA technologies like `IndexedDB`, service workers, and the Background Sync API, you can build an offline-friendly image upload system that queues uploads and retries them automatically — so your…
🔥5👍1
🧠 Искусственный интеллект, конечно, помогает писать код — но базовые знания человека всё ещё никто не отменял.
Любой код, который сгенерировал ИИ, нужно обязательно проверять. Как говорится: "доверяй, но проверяй". А ещё важно уметь правильно запускать проект — и разбираться, где и что может пойти не так.
🔧 Случай из жизни. Моя подруга вместе с другом делают приложение с помощью ИИ. В какой-то момент она пишет мне: "Фронт не собирается, всё криво и косо, друг уже неделю пытается запустить, но безуспешно".
На созвоне я сразу замечаю, что Tailwind работает неправильно: вижу класс с названием
⏱️ Разобраться на месте не было времени, попросила доступ к репе. И когда села — сразу поняла: в проекте почему-то три (!) разных файла конфигурации Tailwind, с разными названиями. Поправила за 5 минут — и всё заработало. А еще же нужно было запустить это незнакомое приложение, которое было монолитом, сервер на Uvicorn (с которым я столкнулась впервые) — но и его запустила быстро и пофиксила проблему за считанные минуты.
А друг моей подруги, полагаясь только на ИИ, неделю пытался разобраться 😅
📌 К чему это всё: базовые знания — это фундамент. Даже если технология новая, они помогут быстро в ней разобраться. А ещё — не бойтесь обращаться за помощью к тем, у кого больше опыта. Это сэкономит вам кучу времени.
Любой код, который сгенерировал ИИ, нужно обязательно проверять. Как говорится: "доверяй, но проверяй". А ещё важно уметь правильно запускать проект — и разбираться, где и что может пойти не так.
🔧 Случай из жизни. Моя подруга вместе с другом делают приложение с помощью ИИ. В какой-то момент она пишет мне: "Фронт не собирается, всё криво и косо, друг уже неделю пытается запустить, но безуспешно".
На созвоне я сразу замечаю, что Tailwind работает неправильно: вижу класс с названием
blue, а фон — не синий 🤷♀️⏱️ Разобраться на месте не было времени, попросила доступ к репе. И когда села — сразу поняла: в проекте почему-то три (!) разных файла конфигурации Tailwind, с разными названиями. Поправила за 5 минут — и всё заработало. А еще же нужно было запустить это незнакомое приложение, которое было монолитом, сервер на Uvicorn (с которым я столкнулась впервые) — но и его запустила быстро и пофиксила проблему за считанные минуты.
А друг моей подруги, полагаясь только на ИИ, неделю пытался разобраться 😅
📌 К чему это всё: базовые знания — это фундамент. Даже если технология новая, они помогут быстро в ней разобраться. А ещё — не бойтесь обращаться за помощью к тем, у кого больше опыта. Это сэкономит вам кучу времени.
❤11💯2
Frontend Developer
Достижение субкадровой интерполяции с помощью GSAP и Web Workers Помню, как впервые узнала о GSAP: одна знакомая попросила меня стать её ментором. Просьба была необычной — она хотела стать фронтенд-разработчиком и верстать рекламные баннеры используя GSAP.…
🚀 GSAP 3.13 теперь полностью бесплатен!
С релизом версии 3.13, GSAP (GreenSock Animation Platform) стал абсолютно бесплатным — включая все ранее платные плагины. Это стало возможным благодаря поддержке компании Webflow, которая приобрела GSAP и открыла доступ ко всему инструментарию, включая коммерческое использование.
📌 Единственное ограничение: запрещено использовать GSAP в продуктах, позволяющих создавать визуальные анимации без кода и конкурирующих с возможностями Webflow.
🔗 Подробнее:
https://gsap.com/blog/3-13/
https://github.com/greensock/GSAP
С релизом версии 3.13, GSAP (GreenSock Animation Platform) стал абсолютно бесплатным — включая все ранее платные плагины. Это стало возможным благодаря поддержке компании Webflow, которая приобрела GSAP и открыла доступ ко всему инструментарию, включая коммерческое использование.
📌 Единственное ограничение: запрещено использовать GSAP в продуктах, позволяющих создавать визуальные анимации без кода и конкурирующих с возможностями Webflow.
🔗 Подробнее:
https://gsap.com/blog/3-13/
https://github.com/greensock/GSAP
Gsap
3.13 release | GSAP | Docs & Learning
Thanks to Webflow, GSAP is now 100% FREE including ALL of the bonus plugins! Version 3.13 also brings a complete rewrite of SplitText
👍4🔥2
Всем привет!
Давайте подведем итоги за последние два месяца — что появилось в этом канале 👇
📌 ДАЙДЖЕСТ: МАРТ & АПРЕЛЬ
🎯 Frontend от меня:
Исторический экскурс от JavaScript до ES Modules – https://news.1rj.ru/str/frontenddevelopernews/4
Как вообще уживаются вместе .cjs, .mjs и .js файлы в одном проекте – https://news.1rj.ru/str/frontenddevelopernews/5
Service и Web Workers – https://news.1rj.ru/str/frontenddevelopernews/9
Пример работы с веб-воркером –https://news.1rj.ru/str/frontenddevelopernews/11
Разбор задачи из bigfrontend.dev – https://news.1rj.ru/str/frontenddevelopernews/14
Организация стилей в современных веб-приложениях – https://news.1rj.ru/str/frontenddevelopernews/15
requestAnimationFrame – https://news.1rj.ru/str/frontenddevelopernews/18
🗺 Frontend-новости:
Устаревание styled-components – https://news.1rj.ru/str/frontenddevelopernews/16
GSAP 3.13 теперь полностью бесплатен – https://news.1rj.ru/str/frontenddevelopernews/25
👩💻 Тимлидство:
Из разработчика в руководителя: с какими трудностями я столкнулась – https://news.1rj.ru/str/frontenddevelopernews/12
Я почти не пишу код. Боже, я деградирую?! – https://news.1rj.ru/str/frontenddevelopernews/17
Как ничего не забыть и не продолбать важное? – https://news.1rj.ru/str/frontenddevelopernews/19
💡 Реальные кейсы:
«Теория не нужна!» — реальный кейс с ассессмента – https://news.1rj.ru/str/frontenddevelopernews/10
Как я получила A++ за курсовую на магистратуре в Лондоне – https://news.1rj.ru/str/frontenddevelopernews/13
ИИ помогает писать код — но базу всё равно нужно знать – https://news.1rj.ru/str/frontenddevelopernews/24
📚 Статьи и видео:
Первоначальная производительность загрузки для React-разработчиков: глубокое исследование – https://news.1rj.ru/str/frontenddevelopernews/6
Почему BFF должны писать именно фронтендеры – https://news.1rj.ru/str/frontenddevelopernews/21
Достижение субкадровой интерполяции с помощью GSAP и Web Workers – https://news.1rj.ru/str/frontenddevelopernews/22
Как создать offline-friendly систему загрузки изображений – https://news.1rj.ru/str/frontenddevelopernews/23
---
Дальше — больше! Кажется, я только начинаю набирать обороты.
Спасибо, что вы со мной — обещаю, дальше будет ещё интереснее!
#дайджест
Давайте подведем итоги за последние два месяца — что появилось в этом канале 👇
📌 ДАЙДЖЕСТ: МАРТ & АПРЕЛЬ
🎯 Frontend от меня:
Исторический экскурс от JavaScript до ES Modules – https://news.1rj.ru/str/frontenddevelopernews/4
Как вообще уживаются вместе .cjs, .mjs и .js файлы в одном проекте – https://news.1rj.ru/str/frontenddevelopernews/5
Service и Web Workers – https://news.1rj.ru/str/frontenddevelopernews/9
Пример работы с веб-воркером –https://news.1rj.ru/str/frontenddevelopernews/11
Разбор задачи из bigfrontend.dev – https://news.1rj.ru/str/frontenddevelopernews/14
Организация стилей в современных веб-приложениях – https://news.1rj.ru/str/frontenddevelopernews/15
requestAnimationFrame – https://news.1rj.ru/str/frontenddevelopernews/18
🗺 Frontend-новости:
Устаревание styled-components – https://news.1rj.ru/str/frontenddevelopernews/16
GSAP 3.13 теперь полностью бесплатен – https://news.1rj.ru/str/frontenddevelopernews/25
👩💻 Тимлидство:
Из разработчика в руководителя: с какими трудностями я столкнулась – https://news.1rj.ru/str/frontenddevelopernews/12
Я почти не пишу код. Боже, я деградирую?! – https://news.1rj.ru/str/frontenddevelopernews/17
Как ничего не забыть и не продолбать важное? – https://news.1rj.ru/str/frontenddevelopernews/19
💡 Реальные кейсы:
«Теория не нужна!» — реальный кейс с ассессмента – https://news.1rj.ru/str/frontenddevelopernews/10
Как я получила A++ за курсовую на магистратуре в Лондоне – https://news.1rj.ru/str/frontenddevelopernews/13
ИИ помогает писать код — но базу всё равно нужно знать – https://news.1rj.ru/str/frontenddevelopernews/24
📚 Статьи и видео:
Первоначальная производительность загрузки для React-разработчиков: глубокое исследование – https://news.1rj.ru/str/frontenddevelopernews/6
Почему BFF должны писать именно фронтендеры – https://news.1rj.ru/str/frontenddevelopernews/21
Достижение субкадровой интерполяции с помощью GSAP и Web Workers – https://news.1rj.ru/str/frontenddevelopernews/22
Как создать offline-friendly систему загрузки изображений – https://news.1rj.ru/str/frontenddevelopernews/23
---
Дальше — больше! Кажется, я только начинаю набирать обороты.
Спасибо, что вы со мной — обещаю, дальше будет ещё интереснее!
#дайджест
Telegram
Frontend Developer
Всем привет!
Сегодня разберём одну из самых частых тем, которую разработчики скипают при изучении, а потом на собесах хлопают глазками, когда их спрашивают:
“В чём же разница между CommonJS и ES Modules?”
Самое обидное — ведь мы сталкиваемся с этим каждый…
Сегодня разберём одну из самых частых тем, которую разработчики скипают при изучении, а потом на собесах хлопают глазками, когда их спрашивают:
“В чём же разница между CommonJS и ES Modules?”
Самое обидное — ведь мы сталкиваемся с этим каждый…
👏11❤1👍1
Frontend Developer pinned «Всем привет! Давайте подведем итоги за последние два месяца — что появилось в этом канале 👇 📌 ДАЙДЖЕСТ: МАРТ & АПРЕЛЬ 🎯 Frontend от меня: Исторический экскурс от JavaScript до ES Modules – https://news.1rj.ru/str/frontenddevelopernews/4 Как вообще уживаются вместе…»
Часто на собеседованиях многие разработчики, к сожалению, не знают и не понимают, что такое НФТ — нефункциональные требования.
А зря. Это действительно важно: нужно понимать не только что должна делать система, но и как она должна это делать. Нефункциональные требования определяют качество работы системы в целом — насколько быстро она откликается, выдерживает ли нагрузку, безопасна ли, доступна ли 24/7.
Недавно нашла отличный гайд от Microsoft по работе с НФТ:
👉 https://github.com/microsoft/code-with-engineering-playbook/blob/main/docs/design/design-patterns/non-functional-requirements-capture-guide.md
А здесь — подробное описание каждого типа требований:
👉 https://microsoft.github.io/code-with-engineering-playbook/non-functional-requirements/accessibility/
P.S. Если будет интересно, могу разобрать НФТ подробнее в отдельных постах 🙂
А зря. Это действительно важно: нужно понимать не только что должна делать система, но и как она должна это делать. Нефункциональные требования определяют качество работы системы в целом — насколько быстро она откликается, выдерживает ли нагрузку, безопасна ли, доступна ли 24/7.
Недавно нашла отличный гайд от Microsoft по работе с НФТ:
👉 https://github.com/microsoft/code-with-engineering-playbook/blob/main/docs/design/design-patterns/non-functional-requirements-capture-guide.md
А здесь — подробное описание каждого типа требований:
👉 https://microsoft.github.io/code-with-engineering-playbook/non-functional-requirements/accessibility/
P.S. Если будет интересно, могу разобрать НФТ подробнее в отдельных постах 🙂
GitHub
code-with-engineering-playbook/docs/design/design-patterns/non-functional-requirements-capture-guide.md at main · microsoft/code…
This is the playbook for "code-with" customer or partner engagements - microsoft/code-with-engineering-playbook
❤5
Сегодня хочу поделиться мыслями:
какие действия, по моему мнению, помогают разработчику преуспеть в этом быстро меняющемся мире?
Вот мой топ:
1. 📖 Регулярно читать — статьи, блоги, посты, книги. Развивать насмотренность и расширять кругозор.
2. 📺 Смотреть доклады и обучающие видео — лучше понимать концепции, узнавать о новых подходах, прокачивать навыки "на слух".
3. 🛠 Пилить пет-проекты — отличный способ протестировать новую либу, язык или архитектурный подход.
Да, те самые 10 000 часов, о которых все говорят — можно наработать именно здесь.
4. 🧠 Обсуждать и рефлексировать знания — с коллегами, наставниками, друзьями.
Проговаривание, написание, объяснение другим — всё это закрепляет материал в разы лучше.
5. 📋 Фиксировать и структурировать — вести заметки, таблички, личную вики. Это помогает возвращаться к знаниям и видеть прогресс. У меня есть подобная база в notion.
6. ⚖️ Бережно относиться к себе — выгорание — не миф. Баланс между работой и жизнью — не слабость, а залог долгосрочной продуктивности.
Но следующий вопрос, который мы с вами обсудим — где найти на всё это время? 😂
какие действия, по моему мнению, помогают разработчику преуспеть в этом быстро меняющемся мире?
Вот мой топ:
1. 📖 Регулярно читать — статьи, блоги, посты, книги. Развивать насмотренность и расширять кругозор.
2. 📺 Смотреть доклады и обучающие видео — лучше понимать концепции, узнавать о новых подходах, прокачивать навыки "на слух".
3. 🛠 Пилить пет-проекты — отличный способ протестировать новую либу, язык или архитектурный подход.
Да, те самые 10 000 часов, о которых все говорят — можно наработать именно здесь.
4. 🧠 Обсуждать и рефлексировать знания — с коллегами, наставниками, друзьями.
Проговаривание, написание, объяснение другим — всё это закрепляет материал в разы лучше.
5. 📋 Фиксировать и структурировать — вести заметки, таблички, личную вики. Это помогает возвращаться к знаниям и видеть прогресс. У меня есть подобная база в notion.
6. ⚖️ Бережно относиться к себе — выгорание — не миф. Баланс между работой и жизнью — не слабость, а залог долгосрочной продуктивности.
Но следующий вопрос, который мы с вами обсудим — где найти на всё это время? 😂
❤4
gRPC против REST: Как выбрать лучший подход к проектированию API
Всем привет! Наткнулась на полезную статью — https://blog.logrocket.com/grpc-vs-rest/
В ней объясняется, что такое REST и gRPC, в чём их ключевые различия и в каких случаях лучше применять тот или иной подход. Есть наглядные примеры.
Вот краткая выжимка, но всё же рекомендую прочитать статью целиком 👇
---
🔍 Основные различия
REST — архитектурный стиль, использующий HTTP/1.1 и JSON. Прост в использовании и широко поддерживается в браузерах.
gRPC — высокопроизводительный фреймворк от Google на базе HTTP/2 и Protocol Buffers. Обеспечивает эффективную, строготипизированную передачу данных между сервисами.
---
⚙️ Сравнение производительности
📦 Сериализация и объём данных
REST:
* Использует текстовые форматы (JSON/XML)
* Более крупный размер данных из-за текстового кодирования
* Читаем человеком, но менее эффективно
* Сериализация/десериализация может быть ресурсоёмкой для больших данных
gRPC:
* Использует бинарный формат (Protocol Buffers)
* Полезная нагрузка на 30–40% меньше по сравнению с JSON
* Быстрая сериализация и десериализация
* Меньшая нагрузка на пропускную способность сети
---
🌐 Сетевая эффективность
REST:
* Основан на HTTP/1.1 (поддержка HTTP/2 ограниченная)
* Один запрос — одно TCP-соединение
* Выше задержка при множестве запросов
* Ограниченное повторное использование соединений
* Сжатие заголовков доступно только с HTTP/2
gRPC:
* Основан на HTTP/2
* Мультиплексирует несколько запросов по одному соединению
* Поддерживает двусторонний стриминг, что снижает задержку
* Постоянные соединения повышают производительность
* Эффективное сжатие заголовков снижает издержки
---
✅ Когда выбрать REST
* Публичные API — когда важна широкая совместимость с клиентами и возможность обнаружения (discoverability).
* Веб-клиенты — для прямой поддержки в браузере без необходимости прокси или шлюзов.
* Простые CRUD-операции — когда достаточно базовых операций с ресурсами.
* Разные языки в микросервисах — если не все сервисы могут поддерживать gRPC.
* Удобная отладка — когда важно уметь просматривать и анализировать содержимое запросов.
---
🚀 Когда выбрать gRPC
* Микросервисная архитектура — когда важна эффективная внутренняя коммуникация между сервисами.
* Polyglot-среда — для совместимости между сервисами с помощью автогенерации кода.
* Реальное время — когда особенно полезны возможности стриминга в gRPC.
* Высокая нагрузка и требования к скорости — идеально для систем, критичных к производительности.
* IoT и мобильные приложения — где важны эффективность использования трафика и энергосбережение
---
P.S. Всё же советую прочитать статью целиком — когда дойдёт до реального выбора между REST и gRPC, вы будете во всеоружии и точно поймёте, какой подход лучше подойдёт именно в данном кейсе 🚀
Всем привет! Наткнулась на полезную статью — https://blog.logrocket.com/grpc-vs-rest/
В ней объясняется, что такое REST и gRPC, в чём их ключевые различия и в каких случаях лучше применять тот или иной подход. Есть наглядные примеры.
Вот краткая выжимка, но всё же рекомендую прочитать статью целиком 👇
---
🔍 Основные различия
REST — архитектурный стиль, использующий HTTP/1.1 и JSON. Прост в использовании и широко поддерживается в браузерах.
gRPC — высокопроизводительный фреймворк от Google на базе HTTP/2 и Protocol Buffers. Обеспечивает эффективную, строготипизированную передачу данных между сервисами.
---
⚙️ Сравнение производительности
📦 Сериализация и объём данных
REST:
* Использует текстовые форматы (JSON/XML)
* Более крупный размер данных из-за текстового кодирования
* Читаем человеком, но менее эффективно
* Сериализация/десериализация может быть ресурсоёмкой для больших данных
gRPC:
* Использует бинарный формат (Protocol Buffers)
* Полезная нагрузка на 30–40% меньше по сравнению с JSON
* Быстрая сериализация и десериализация
* Меньшая нагрузка на пропускную способность сети
---
🌐 Сетевая эффективность
REST:
* Основан на HTTP/1.1 (поддержка HTTP/2 ограниченная)
* Один запрос — одно TCP-соединение
* Выше задержка при множестве запросов
* Ограниченное повторное использование соединений
* Сжатие заголовков доступно только с HTTP/2
gRPC:
* Основан на HTTP/2
* Мультиплексирует несколько запросов по одному соединению
* Поддерживает двусторонний стриминг, что снижает задержку
* Постоянные соединения повышают производительность
* Эффективное сжатие заголовков снижает издержки
---
✅ Когда выбрать REST
* Публичные API — когда важна широкая совместимость с клиентами и возможность обнаружения (discoverability).
* Веб-клиенты — для прямой поддержки в браузере без необходимости прокси или шлюзов.
* Простые CRUD-операции — когда достаточно базовых операций с ресурсами.
* Разные языки в микросервисах — если не все сервисы могут поддерживать gRPC.
* Удобная отладка — когда важно уметь просматривать и анализировать содержимое запросов.
---
🚀 Когда выбрать gRPC
* Микросервисная архитектура — когда важна эффективная внутренняя коммуникация между сервисами.
* Polyglot-среда — для совместимости между сервисами с помощью автогенерации кода.
* Реальное время — когда особенно полезны возможности стриминга в gRPC.
* Высокая нагрузка и требования к скорости — идеально для систем, критичных к производительности.
* IoT и мобильные приложения — где важны эффективность использования трафика и энергосбережение
---
P.S. Всё же советую прочитать статью целиком — когда дойдёт до реального выбора между REST и gRPC, вы будете во всеоружии и точно поймёте, какой подход лучше подойдёт именно в данном кейсе 🚀
LogRocket Blog
gRPC vs. REST: Choosing the best API design approach - LogRocket Blog
Compare gRPC vs REST to understand differences in performance, efficiency, and architecture for building modern APIs.
🔥3