Войти в Y_LAB | IT развитие и юмор
رفتن به کانال در Telegram
Стажировки, вакансии, полезные материалы, развлекательный контент. Y_LAB — команда опытных IT-специалистов, которая готова помочь вам войти в мир технологий! Сотрудничество (ylab v it) @tamriko1_5
نمایش بیشتر765
مشترکین
اطلاعاتی وجود ندارد24 ساعت
-27 روز
-830 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئیه '26
ژوئیه '26
+4
در 0 کانالها
ژوئن '26
+10
در 0 کانالها
Get PRO
مه '26
+8
در 0 کانالها
Get PRO
آوریل '26
+13
در 1 کانالها
Get PRO
مارس '26
+11
در 0 کانالها
Get PRO
فوریه '26
+9
در 0 کانالها
Get PRO
ژانویه '26
+8
در 0 کانالها
Get PRO
دسامبر '25
+13
در 0 کانالها
Get PRO
نوامبر '25
+29
در 0 کانالها
Get PRO
اکتبر '25
+27
در 0 کانالها
Get PRO
سپتامبر '25
+15
در 0 کانالها
Get PRO
اوت '25
+6
در 0 کانالها
Get PRO
ژوئیه '25
+11
در 0 کانالها
Get PRO
ژوئن '25
+11
در 0 کانالها
Get PRO
مه '25
+19
در 0 کانالها
Get PRO
آوریل '25
+21
در 0 کانالها
Get PRO
مارس '25
+41
در 0 کانالها
Get PRO
فوریه '25
+24
در 0 کانالها
Get PRO
ژانویه '25
+22
در 0 کانالها
Get PRO
دسامبر '24
+18
در 0 کانالها
Get PRO
نوامبر '24
+20
در 0 کانالها
Get PRO
اکتبر '24
+26
در 0 کانالها
Get PRO
سپتامبر '24
+46
در 0 کانالها
Get PRO
اوت '24
+24
در 0 کانالها
Get PRO
ژوئیه '24
+22
در 0 کانالها
Get PRO
ژوئن '24
+28
در 0 کانالها
Get PRO
مه '24
+48
در 0 کانالها
Get PRO
آوریل '24
+155
در 0 کانالها
Get PRO
مارس '24
+33
در 0 کانالها
Get PRO
فوریه '24
+250
در 0 کانالها
Get PRO
ژانویه '24
+128
در 0 کانالها
Get PRO
دسامبر '23
+25
در 0 کانالها
Get PRO
نوامبر '23
+27
در 0 کانالها
Get PRO
اکتبر '23
+64
در 0 کانالها
Get PRO
سپتامبر '23
+583
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 27 ژوئیه | 0 | |||
| 26 ژوئیه | 0 | |||
| 25 ژوئیه | 0 | |||
| 24 ژوئیه | 0 | |||
| 23 ژوئیه | +1 | |||
| 22 ژوئیه | 0 | |||
| 21 ژوئیه | 0 | |||
| 20 ژوئیه | 0 | |||
| 19 ژوئیه | 0 | |||
| 18 ژوئیه | 0 | |||
| 17 ژوئیه | +1 | |||
| 16 ژوئیه | 0 | |||
| 15 ژوئیه | 0 | |||
| 14 ژوئیه | 0 | |||
| 13 ژوئیه | 0 | |||
| 12 ژوئیه | 0 | |||
| 11 ژوئیه | 0 | |||
| 10 ژوئیه | 0 | |||
| 09 ژوئیه | 0 | |||
| 08 ژوئیه | 0 | |||
| 07 ژوئیه | 0 | |||
| 06 ژوئیه | 0 | |||
| 05 ژوئیه | +1 | |||
| 04 ژوئیه | 0 | |||
| 03 ژوئیه | +1 | |||
| 02 ژوئیه | 0 | |||
| 01 ژوئیه | 0 |
پستهای کانال
| 2 |  75 Years Later
#Y_LAB_University #Y_LAB_Memes | 107 |
| 3 |  Новый пост Y_LAB_Learning! | Управление состоянием с MobX: от первых observable до крупных проектов
🔵 Frontend
О чем статья?
Принципы работы MobX, его основные возможности, преимущества и ограничения. Как библиотека упрощает управление состоянием и помогает строить масштабируемые React-приложения.
📎 Читать статью
#Y_LAB_University #Y_LAB_Learning | 153 |
| 4 |  Новый пост 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 | 119 |
| 5 |  #Y_LAB_University #Y_LAB_Memes | 128 |
| 6 |  Новый пост Y_LAB Videos! | Свежее видео
Всем привет! Рады сообщить, что на наших ютуб-канале и вк-сообществе вышел новый видеоролик “Классы и метаклассы в Python”.
О чем видео?
В данном видео вместе с нашим Python-разработчиком Лерой разберемся, как устроены классы и объекты в Python, зачем нужны магические методы, наследование и перегрузка операторов, а также выясним, почему класс сам является объектом. Постепенно перейдем к метаклассам, разберем принцип их работы, посмотрим реальные примеры использования в Django и Pydantic и поймем, в каких случаях этот мощный инструмент действительно стоит применять.
📱 YouTube
———
📱 VK
#Y_LAB_University #Y_LAB_YouTube #Y_LAB_VK | 194 |
| 7 |  #Y_LAB_University #Y_LAB_Memes | 187 |
| 8 |  Новый пост Y_LAB_Learning! | Тестирование мобильных приложений: реальные задачи, с которыми сталкивается QA
🪲 QA
О чем статья?
Чем мобильное тестирование отличается от WEB, с какими особенностями сталкивается Manual QA и почему проверка приложения не ограничивается интерфейсом.
📎 Читать статью
#Y_LAB_University #Y_LAB_Learning | 174 |
| 9 | Новый пост Y_LAB Actual | Код под микроскопом 🔍
Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, с которыми разработчики сталкиваются в продакшене.
Сегодня под микроскопом — производительность базы данных 🔧
// sql
SELECT *
FROM orders
WHERE user_id = 15482;
Вопрос:
Почему такой простой запрос может выполняться несколько секунд, а иногда и десятки секунд?
Казалось бы
↔️ Выбираем данные из одной таблицы;
↔️ Фильтруем по одному полю.
Но всё зависит не только от самого запроса, а ещё и от того, как устроена таблица.
⬇️⬇️⬇️
Представим, что в таблице orders хранится 20 миллионов записей.
Если для поля user_id нет индекса, то база данных будет вынуждена проверить практически каждую строку таблицы, чтобы найти нужные записи.
🔎 Такой способ поиска называется полным сканированием таблицы (Sequential Scan).
Чем больше данных, тем дольше будет выполняться запрос.
🔩 Как исправить?
Если поиск по полю выполняется регулярно, имеет смысл создать индекс:
// sql
CREATE INDEX idx_orders_user_id
ON orders(user_id);
Теперь вместо последовательного просмотра миллионов строк база сможет быстро найти нужные записи по индексу.
❗️ Но есть важный нюанс.
Кажется, что индексы — универсальное решение. Но на самом деле каждый индекс:
• Занимает дополнительное место на диске;
• Замедляет операции INSERT, UPDATE и DELETE, потому что его тоже нужно обновлять.
Поэтому создавать индексы "на всякий случай" — не лучшая идея. Хороший индекс — это тот, который действительно ускоряет часто выполняемые запросы.
💬💬💬
На небольших таблицах проблема может быть незаметна.
Но когда количество данных начинает исчисляться миллионами записей, отсутствие одного индекса способно увеличить время ответа API с десятков миллисекунд до нескольких секунд.
Приходилось когда-нибудь искать причину медленного запроса, а потом обнаруживать, что проблема была всего лишь в отсутствии индекса? 👀
#Y_LAB_University #Y_LAB_Actual | 159 |
| 10 |  😭😭😭
#Y_LAB_University #Y_LAB_Memes | 158 |
| 11 |  #Y_LAB_University #Y_LAB_Memes | 254 |
| 12 |  Новый пост Y_LAB_Learning! | Почему одного UI уже недостаточно: современный взгляд на WEB-тестирование
🪲 QA
О чем статья?
Как устроено современное WEB-тестирование и почему ручному тестировщику уже недостаточно проверять только интерфейс. Связь UI и API, роль DevTools.
📎 Читать статью
#Y_LAB_University #Y_LAB_Learning | 250 |
| 13 | Новый пост Y_LAB Actual | Код под микроскопом 🔍
Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины ошибок, которые не всегда лежат на поверхности.
Сегодня под микроскопом — HTTP 429 🔍
// python
import requests
for user_id in users:
requests.post(
"https://api.example.com/send",
json={"userId": user_id}
)
На тестовом стенде всё работает отлично.
Но после выхода в прод часть запросов внезапно начинает возвращать:
// http
429 Too Many Requests
Почему так происходит?
На первый взгляд кажется, что проблема в самом API.
Но чаще всего причина совсем в другом: превышен лимит запросов (Rate Limit). 🚨
Многие сервисы ограничивают количество обращений за определённый промежуток времени, чтобы защититься от перегрузки.
Например, API может разрешать:
🎯 Не более 100 запросов в минуту;
🎯 Не более 10 запросов в секунду;
🎯 Или ограничивать число запросов для одного пользователя или IP-адреса.
Если приложение отправляет запросы слишком быстро, сервер начинает отвечать:
// http
429 Too Many Requests
❓ Как правильно обработать такую ситуацию?
Первая мысль — просто повторить запрос:
// python
while True:
response = requests.post(...)
if response.status_code == 429:
continue
Но это только усугубит проблему. 😭
Пока сервер ограничивает обращения, приложение продолжит отправлять новые запросы, создавая ещё большую нагрузку.
🔧 Что делать вместо этого?
Обычно используют один или сразу несколько подходов:
🎯 Читают заголовок Retry-After, если сервер его возвращает, и повторяют запрос только через указанное время;
🎯 Добавляют экспоненциальную задержку (Exponential Backoff), увеличивая интервал между повторными попытками;
🎯 Ограничивают количество одновременно отправляемых запросов на стороне клиента.
💜💜💜
Код может быть полностью корректным и отлично работать во время разработки.
Но в продакшене пользователей становится в сотни раз больше, и ограничения API начинают проявляться именно под нагрузкой.
Поэтому ошибка 429 чаще говорит не о проблеме сервера, а о том, что приложению пора научиться «общаться» с ним аккуратнее.
А вам приходилось бороться с ограничениями Rate Limit? Какой способ обработки оказался самым эффективным? 👀
#Y_LAB_University #Y_LAB_Actual | 200 |
| 14 |  #Y_LAB_University #Y_LAB_Memes | 186 |
| 15 |  Новый пост Y_LAB Videos! | Свежее видео
Всем привет! Рады сообщить, что на наших ютуб-канале и вк-сообществе вышел новый видеоролик “Хочу стать Junior QA”.
О чем видео?
В этом видео разберем Roadmap Junior QA: кто такой QA Engineer, какие hard и soft skills необходимы начинающему тестировщику, какие инструменты используются в работе и что нужно изучить для успешного старта в профессии. Также поговорим о возможных направлениях развития и карьерном росте в тестировании.
📱 YouTube
———
📱 VK
#Y_LAB_University #Y_LAB_YouTube #Y_LAB_VK | 234 |
| 16 |  👀👀👀
#Y_LAB_University #Y_LAB_Memes | 252 |
| 17 |  Новый пост Y_LAB_Learning! | Тестирование в Python: от юнит-тестов до TDD и monkey patching
📱 Python
О чем статья?
Чем отличаются юнит- и интеграционные тесты, что такое TDD, когда использовать mocking и monkey patching.
📎 Читать статью
#Y_LAB_University #Y_LAB_Learning | 265 |
| 18 | Новый пост Y_LAB Actual | Код под микроскопом 🔍
Продолжаем рубрику, в которой разбираем реальные ситуации из разработки и ищем неочевидные причины ошибок.
Сегодня под микроскопом — многопоточность в Java 📱
class Counter {
private int value = 0;
public void increment() {
value++;
}
public int getValue() {
return value;
}
}
Представим, что метод increment() одновременно вызывают 100 потоков по 1000 раз каждый.
❓ Вопрос:
Какое значение в итоге вернёт:
counter.getValue();
Кажется, ответ очевиден:
100000
Но на практике результат может быть совершенно другим.
🤓 Например:
98341
99612
99987
И каждый запуск программы может давать новое значение.
🤔 Почему так происходит?
Операция:
value++;
только выглядит как одно действие.
На самом деле она состоит сразу из трёх шагов:
🎯1. прочитать текущее значение;
🎯2. увеличить его на единицу;
🎯3. записать обратно.
Если два потока одновременно прочитают одно и то же значение, оба увеличат его и оба запишут результат. Один из инкрементов просто потеряется.
Кроме того, в многопоточных приложениях может возникнуть ещё одна проблема — видимость изменений между потоками. Из-за оптимизаций процессора и JVM один поток может некоторое время работать с устаревшим значением переменной.
Для решения именно этой задачи в Java существует ключевое слово volatile. Оно гарантирует, что потоки будут видеть актуальное значение переменной.
Однако в нашем примере volatile не решит проблему полностью. Операция value++ всё равно состоит из чтения, увеличения и записи, поэтому инкременты могут теряться.
↔️ Например:
Поток A читает 5
Поток B читает 5
Поток A записывает 6
Поток B записывает 6
Хотя ожидалось уже значение 7.
🔗 Как исправить?
Для счётчиков в многопоточной среде обычно используют AtomicInteger:
java AtomicInteger counter = new AtomicInteger();
counter.incrementAndGet();
или синхронизацию (synchronized), если требуется защитить более сложную логику.
📢📢📢
Такие ошибки одни из самых неприятных.
Программа не падает.
Компилятор не выдаёт ошибок.
Тесты могут проходить десятки раз подряд.
А проблема проявится только под нагрузкой, когда приложение окажется в реальной эксплуатации.
Сталкивались когда-нибудь с багами, которые появлялись только при большом количестве одновременных запросов? 👀
#Y_LAB_University #Y_LAB_Actual | 226 |
| 19 |  Не беспокоить... машина учится 🧑🏫
#Y_LAB_University #Y_LAB_Memes | 198 |
| 20 |  Новый пост Y_LAB Videos! | Свежее видео
Всем привет! Рады сообщить, что на наших ютуб-канале и вк-сообществе вышел новый видеоролик “Java 21-25: что реально изменилось между двумя LTS-релизами”.
О чем видео?
В данном видео вместе с нашим Java-разработчиком Иваном разбираемся, чем Java 25 отличается от Java 21 и какие изменения действительно важны для production-разработки. Обсудим, как эволюционировали виртуальные потоки, FFM API, JVM, сборщики мусора и средства диагностики, а также почему переход на Java 25 — это не только новые возможности, но и более зрелая, стабильная платформа для современных приложений.
📱 YouTube
———
📱 VK
#Y_LAB_University #Y_LAB_YouTube #Y_LAB_VK | 252 |
