Войти в Y_LAB | IT развитие и юмор
СтатистикаСтажировки, вакансии, полезные материалы, развлекательный контент. Y_LAB — команда опытных IT-специалистов, которая готова помочь вам войти в мир технологий! Сотрудничество (ylab v it) @tamriko1_5
- Последний пост
- 14 авг.
- Последнее чтение
- 11:27
- Постов за неделю
- 5
- Всего постов
- 22
- Тип
- открытый
- Язык
- русский
- Категория
- Карьера
- В каталоге с
- 13 авг.
- 1/24сутки в ленте
- 110
- 1/48двое суток
- 126
- 1/72трое суток
- 135
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
Новый пост Y_LAB Videos! | Свежее видео Всем привет! Рады сообщить, что на наших ютуб-канале и вк-сообществе вышел новый видеоролик “От вайб-кодинга до Enterprise: как ИИ меняет разработку”. О чем видео? В новом выпуске подкаста вместе с ведущим Максимом и Python-разработчиком Александром разбираемся, что такое ИИ-агенты и как они уже меняют процесс разработки. Это первая часть выпуска: говорим о вайб-кодинге, реальной продуктивности ИИ, его эффективности в пет-проектах и Enterprise и о том, действительно ли нейросеть может оказаться дешевле разработчика. 📱 YouTube ——— 📱 VK #Y_LAB_University #Y_LAB_YouTube #Y_LAB_VK
#Y_LAB_University #Y_LAB_Memes
Новый пост Y_LAB_Learning! | CORS, CSRF и Spring Security: что происходит с HTTP-запросом 💬 Java, Frontend О чем статья? Задачи CORS и CSRF. Как они работают, что происходит с запросом между frontend и Java backend. Как правильно настраивать защиту в Spring Security. 📎 Читать статью #Y_LAB_University #Y_LAB_Learning
Новый пост Y_LAB Actual | Код под микроскопом 🔍 Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, которые не всегда очевидны на первый взгляд. Сегодня под микроскопом — 🤨 React и повторные запросы function UserProfile({ userId }) { const [user, setUser] = useState(null); const options = { headers: { Authorization: "Bearer token" } }; useEffect(() => { fetch(`/api/users/${userId}`, options) .then(response => response.json()) .then(setUser); }, [userId, options]); return <div>{user?.name}</div>; } Почему при обычном рендере компонента API может начать получать множество одинаковых запросов? 🎯 useEffect зависит от userId; 🎯 запрос выполняется при изменении пользователя; 🎯 после получения данных вызывается setUser. 💜Но есть одна проблема: const options = { headers: { Authorization: "Bearer token" } }; Этот объект создаётся заново при каждом рендере компонента. А useEffect следит за ним: [userId, options] React сравнивает зависимости по ссылке. Поэтому для него: options → старый объект options → новый объект — это разные значения, даже если содержимое объектов полностью одинаковое. 🤔 Что происходит дальше? Компонент рендерится -> Создаётся новый options -> useEffect отправляет запрос -> При получении ответа вызывается setUser -> Компонент снова рендерится -> Создаётся новый options -> React считает зависимость изменившейся -> useEffect снова отправляет запрос И так запросы могут начать повторяться снова и снова. 🛠 Как исправить? Если объект действительно не меняется, его можно вынести за пределы компонента: const options = { headers: { Authorization: "Bearer token" } }; function UserProfile({ userId }) { const [user, setUser] = useState(null); useEffect(() => { fetch(`/api/users/${userId}`, options) .then(response => response.json()) .then(setUser); }, [userId]); return <div>{user?.name}</div>; } Но иногда проблема решается не внутри самого компонента. Можно вынести работу с API в отдельный слой. Например, компонент отвечает только за отображение данных, а запросы находятся в отдельном сервисе: Component ↓ API layer ↓ Backend 📌 Ещё один вариант — использовать библиотеку для работы с серверными данными. Например, TanStack Query или RTK Query. Они позволяют вынести запросы и управление их состоянием за пределы компонентов, а также предоставляют кэширование, дедупликацию запросов и другие механизмы для работы с серверными данными. В результате компоненту не обязательно самостоятельно решать, когда отправить запрос, где хранить результат и нужно ли повторно загружать те же данные. ⬇️⬇️⬇️ Один лишний запрос кажется мелочью. Но если такой компонент находится на странице, которая активно обновляется, или подобных компонентов десятки, количество запросов может быстро вырасти. В итоге можно получить: 🎯 Лишнюю нагрузку на API; 🎯 Замедление интерфейса; 🎯 Превышение rate limit; 🎯 Неожиданные 429 Too Many Requests; 🎯 Лишние расходы на инфраструктуру. И проблему не всегда получится обнаружить просто открыв Network DevTools. Если запрос выполняется на сервере (например, при SSR или в Server Components), его вообще может не быть среди сетевых запросов браузера. Поэтому при подозрении на лишние обращения к API стоит смотреть не только на frontend, но и на логи, метрики и трассировку запросов. А замечали когда-нибудь, что один компонент способен породить десятки одинаковых запросов? 👀 #Y_LAB_University #Y_LAB_Actual
#Y_LAB_University #Y_LAB_Memes
Новый пост Y_LAB Videos! | Свежее видео Всем привет! Рады сообщить, что на наших ютуб-канале и вк-сообществе вышел новый видеоролик “System Design: как проектировать высоконагруженные системы на Python”. О чем видео? В новом выпуске подкаста вместе с ведущим Павлом и Python-разработчиком Данилом разбираемся, как проектировать высоконагруженные системы на Python и какие архитектурные решения помогают приложениям оставаться стабильными даже при резком росте нагрузки. Обсудим, действительно ли Python медленный, как работают GIL, асинхронность и масштабирование, какие метрики важно отслеживать, а также поговорим о роли ИИ в современной разработке. 📱 YouTube ——— 📱 VK #Y_LAB_University #Y_LAB_YouTube #Y_LAB_VK
Новый пост Y_LAB_Learning! | Real-time без WebSocket: знакомимся с Server-Sent Events 🔵 Frontend О чем статья? Всегда ли для обновления данных в реальном времени нужен WebSocket? Как Server-Sent Events помогают проще реализовать потоковую передачу данных, в каких сценариях они особенно полезны и какие ограничения важно учитывать. 📎 Читать статью #Y_LAB_University #Y_LAB_Learning
Новый пост Y_LAB Actual | Код под микроскопом 🔍 Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, которые чаще всего проявляются уже в продакшене. Сегодня под микроскопом — кэширование браузера 🧑💻 // HTML <link rel="stylesheet" href="/css/style.css"> <script src="/js/app.js"></script> ❗️ Вопрос: Вы исправили баг, выкатили новую версию приложения, деплой прошёл успешно… Но часть пользователей продолжает видеть старый интерфейс. ❓ Почему ❓ Сначала кажется, все верно: ↔️ Новый код загружен на сервер; ↔️ Сборка завершилась без ошибок; ↔️ Приложение доступно. Но проблема может быть совсем не в сервере. Браузер уже сохранил файлы: // text /css/style.css /js/app.js и при следующем открытии страницы может использовать их из собственного кэша. В результате пользователь продолжает работать со старой версией приложения, хотя на сервере уже лежит новая. 🛠 Как обычно решают эту проблему? Во многих проектах к имени файла автоматически добавляют хэш: // HTML <link rel="stylesheet" href="/css/style.a4f91c.css"> <script src="/js/app.82de13.js"></script> После новой сборки хэш меняется: // text app.82de13.js ↓ app.f93b11.js Для браузера это уже новый файл, поэтому он скачивает его заново, а не использует старую версию из кэша. Именно поэтому современные инструменты сборки (Webpack, Vite, Rollup и другие) по умолчанию добавляют хэш в имена файлов. ⬇️⬇️⬇️ Если после релиза пользователи говорят: «У меня всё осталось по-старому», не спешите искать ошибку в коде. Сначала проверьте, не связана ли проблема с кэшированием и версионированием статических файлов. А вам приходилось сталкиваться с ситуацией, когда причина бага оказалась не в коде, а в старой версии файлов, оставшейся в кэше? 👀 #Y_LAB_University #Y_LAB_Actual
#Y_LAB_University #Y_LAB_Memes
Новый пост Y_LAB Videos! | Свежее видео Всем привет! Рады сообщить, что на наших ютуб-канале и вк-сообществе вышел новый видеоролик “Scrum VS Kanban: Чем они отличаются и как выбрать подходящий инструмент?”. О чем видео? В данном видео вместе с нашим Scrum-мастером Анной разбираемся, чем Scrum отличается от Kanban, как устроены оба Agile-подхода и в каких случаях каждый из них помогает команде работать эффективнее. На простых примерах рассмотрим ключевые принципы, особенности процессов и критерии выбора подходящего фреймворка для разных типов проектов. 📱 YouTube ——— 📱 VK #Y_LAB_University #Y_LAB_YouTube #Y_LAB_VK
💯 #Y_LAB_University #Y_LAB_Memes
Новый пост Y_LAB_Learning! | Java Core: разбираем основу, на которой строится современная Java 📱 Java О чем статья? Ключевые концепции языка Java: семантика, коллекции, Generics, обработка исключений, Stream API и другие базовые механизмы, понимание которых помогает писать надежный код и уверенно проходить технические собеседования. 📎 Читать статью #Y_LAB_University #Y_LAB_Learning
Новый пост Y_LAB Actual | Код под микроскопом 🔍 Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, которые чаще всего проявляются уже в продакшене. Сегодня под микроскопом — утечки памяти в React 📱 // JavaScript useEffect(() => { window.addEventListener("resize", handleResize); }, []); Вопрос: Почему спустя несколько часов работы приложение начинает тормозить, хотя в коде нет сложных вычислений? Вроде бы всё выглядит правильно: ↔️ При монтировании компонента подписываемся на событие resize; ↔️ При изменении размера окна вызывается обработчик. Но есть одна проблема... Подписка никогда не удаляется 🫠 ⬇️⬇️⬇️ Что происходит дальше? Представим, что пользователь несколько раз открывает и закрывает страницу с этим компонентом. Каждый раз выполняется: // JavaScript window.addEventListener("resize", handleResize); В результате обработчиков становится всё больше: // text 1 открытие → 1 обработчик 5 открытий → 5 обработчиков 20 открытий → 20 обработчиков Теперь при каждом изменении размера окна браузер вызывает все накопившиеся обработчики, даже если часть компонентов уже давно исчезла с экрана. Это приводит к лишним вычислениям, росту потребления памяти и постепенному снижению производительности приложения. 🔨 Как исправить? В useEffect необходимо вернуть функцию очистки: // JavaScript useEffect(() => { window.addEventListener("resize", handleResize); return () => { window.removeEventListener("resize", handleResize); }; }, []); Теперь при размонтировании компонента обработчик будет удалён, и память не будет расходоваться впустую. 🖍️🖍️🖍️ Во время разработки такую проблему заметить сложно. Компонент открывают несколько раз — и всё работает отлично. Но в продакшене пользователь может провести в приложении несколько часов, переходя между страницами. Если подписки не очищаются, приложение постепенно начинает потреблять всё больше ресурсов, а интерфейс — работать всё медленнее. 💡💡💡 Каждый раз, когда в useEffect появляется: - addEventListener(); - setInterval(); - setTimeout(); - WebSocket; - подписка на внешний сервис, сразу задавайте себе вопрос: А где этот ресурс освобождается? Во многих случаях именно отсутствие очистки становится причиной утечек памяти. А вам приходилось искать проблему, которая в итоге оказалась всего лишь забытым removeEventListener()? 👀 #Y_LAB_University #Y_LAB_Actual
😭😭😭 #Y_LAB_University #Y_LAB_Memes
75 Years Later #Y_LAB_University #Y_LAB_Memes
Новый пост Y_LAB_Learning! | Управление состоянием с MobX: от первых observable до крупных проектов 🔵 Frontend О чем статья? Принципы работы MobX, его основные возможности, преимущества и ограничения. Как библиотека упрощает управление состоянием и помогает строить масштабируемые React-приложения. 📎 Читать статью #Y_LAB_University #Y_LAB_Learning
Новый пост Y_LAB Actual | Код под микроскопом 🔍 Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, которые появляются не во время разработки, а уже в продакшене. Сегодня под микроскопом — пул соединений с базой данных (Connection Pool) 🗄 // python from sqlalchemy import create_engine engine = create_engine(DB_URL) connection = engine.connect() # Работа с базой данных return Вопрос: Почему приложение может внезапно перестать работать с базой данных, хотя сама база полностью исправна? На первый взгляд код выглядит вполне обычным: ↔️ получили соединение ↔️ выполнили запрос ↔️ закончили работу Но есть одна проблема... Соединение с базой данных никогда не возвращается обратно в пул. 💰 Что происходит дальше? Каждый новый запрос получает ещё одно соединение: // text Запрос №1 → получил соединение Запрос №2 → получил соединение Запрос №3 → получил соединение ... Пока однажды пул не закончится. После этого новые запросы начинают ждать свободное соединение, а затем приложение может начать выдавать ошибки вроде: // text QueuePool limit reached или // text TimeoutError: QueuePool limit reached При этом сама база данных продолжает работать. Проблема в приложении. 🛠 Как исправить? После завершения работы соединение необходимо закрыть: // python from sqlalchemy import create_engine engine = create_engine(DB_URL) with engine.connect() as connection: # Работа с базой данных pass Контекстный менеджер (with) автоматически вернёт соединение обратно в пул, даже если во время выполнения кода возникнет исключение. ➡️ Если не использовать with, соединение нужно закрывать вручную: // python connection.close() Важно понимать, что при использовании пула данный вызов не закрывает соединение с базой физически, а лишь возвращает его обратно в пул, чтобы его мог использовать следующий запрос. 🌟🌟🌟 Такие ошибки редко проявляются во время разработки. Локально одновременно работает один пользователь, поэтому свободных соединений почти всегда хватает. Но после выхода в продакшен десятки или сотни параллельных запросов постепенно "разбирают" весь пул. И спустя некоторое время приложение перестаёт работать с базой, хотя причина скрывается всего в одной пропущенной строке или отсутствии контекстного менеджера with. 💡💡💡 Если приложение начинает жаловаться на нехватку соединений, не спешите увеличивать размер пула. Сначала убедитесь, что соединения действительно возвращаются обратно. Очень часто проблема не в количестве соединений, а в том, что часть из них никогда не освобождается. Приходилось когда-нибудь искать утечку соединений с базой? 👀 #Y_LAB_University #Y_LAB_Actual
#Y_LAB_University #Y_LAB_Memes
Новый пост Y_LAB Videos! | Свежее видео Всем привет! Рады сообщить, что на наших ютуб-канале и вк-сообществе вышел новый видеоролик “Классы и метаклассы в Python”. О чем видео? В данном видео вместе с нашим Python-разработчиком Лерой разберемся, как устроены классы и объекты в Python, зачем нужны магические методы, наследование и перегрузка операторов, а также выясним, почему класс сам является объектом. Постепенно перейдем к метаклассам, разберем принцип их работы, посмотрим реальные примеры использования в Django и Pydantic и поймем, в каких случаях этот мощный инструмент действительно стоит применять. 📱 YouTube ——— 📱 VK #Y_LAB_University #Y_LAB_YouTube #Y_LAB_VK
#Y_LAB_University #Y_LAB_Memes