devlor1k

Факапы разработчика, день 7 💥 Ошибка, которая научила меня проверять окружение Программирование — это как сборка мебели: если инструкция или инструменты не те, всё пойдёт наперекосяк. После прошлых факапов я думал, что стал мастером дебаггинга, но окружение решило напомнить мне, что расслабляться рано. 📌 Ситуация Я работал над проектом на Django — небольшое веб-приложение для управления задачами. Всё шло гладко: настроил модели, настроил роуты, запустил локальный сервер. В базе данных (SQLite для разработки) всё сохранялось, страницы отображались, тесты проходили. Я уже готовился выкладывать проект на тестовый сервер. Но при переносе на сервер (с PostgreSQL) приложение начало падать. Страницы грузились через раз, а в логах появлялись ошибки вроде DatabaseError: connection timeout. Я был уверен, что проблема в коде или в базе на сервере. 🔎 День паники Сначала я проверил настройки базы в settings.py: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'mydb', 'USER': 'myuser', 'PASSWORD': 'mypassword', 'HOST': 'localhost', 'PORT': '5432', } } Всё выглядело правильно. Я проверил PostgreSQL на сервере — база работает, подключение через psql проходит. Перезапустил сервер, проверил зависимости — всё совпадает с локальной машиной. Даже переписал часть миграций, думая, что они как-то ломаются. Но ошибка не уходила. Коллега посоветовал проверить сетевые настройки, но я был уверен, что дело в коде. Я потратил часы, сравнивая локальную и серверную версии проекта, и уже начал подозревать баг в самом Django. 🤯 В чём была проблема К концу дня я решил перепроверить конфигурацию. И тут до меня дошло: в settings.py я указал HOST: 'localhost', но на сервере PostgreSQL был настроен на другой порт и не принимал подключения через localhost. Нужно было использовать IP-адрес сервера или правильный хост. Исправил настройки: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'mydb', 'USER': 'myuser', 'PASSWORD': 'mypassword', 'HOST': '127.0.0.1', 'PORT': '5433', # другой порт } } И всё заработало! Ошибка была в том, что я не учёл различия между локальным и серверным окружением. 🎯 Вывод Эта ошибка отняла день и кучу нервов. Что я вынес: Проверяй окружение. Локальная разработка и сервер — это разные миры, и настройки могут отличаться. Держи конфигурации под контролем. Теперь я использую .env-файлы и библиотеку python-decouple для разделения настроек. Слушай коллег. Если бы я сразу проверил сетевые настройки, как мне советовали, сэкономил бы часы. 🚀 Итог Окружение — это не просто фон, а важная часть проекта. Теперь я всегда проверяю настройки сервера, порты и конфиги перед деплоем. Приложение заработало, а я добавил в свой чек-лист пункт «проверить окружение». И знаете, теперь я даже рад, когда всё запускается с первого раза. 😄

Факапы разработчика, день 6 💥 Ошибка, которая научила меня не злоупотреблять кэшем Программирование — это как игра в шахматы: один ход может казаться гениальным, пока не поймёшь, что он сломал всю партию. После прошлых факапов я решил, что теперь буду умнее. Но кэширование данных показало мне, что я всё ещё могу облажаться. 📌 Ситуация Я работал над небольшим REST API на FastAPI для внутренней системы. API возвращало данные о пользователях из базы данных PostgreSQL. Чтобы ускорить запросы, я решил добавить кэширование с помощью библиотеки cachetools. Идея простая: если запрос приходит с тем же параметром, возвращаем результат из кэша, а не лезем в базу. Написал код, добавил кэш: from cachetools import TTLCache cache = TTLCache(maxsize=100, ttl=300) @app.get("/user/{user_id}") def get_user(user_id: int): --if user_id in cache: ----return cache[user_id] --user = db.query(User).get(user_id) --cache[user_id] = user --return user Протестировал — всё летает! Запросы стали быстрее, база нагружается меньше. Я был доволен собой, пока не начали поступать жалобы от коллег. 🔎 День разборок Пользователи заметили, что данные в API иногда устаревшие. Например, если кто-то обновлял профиль (имя или email), API продолжал возвращать старые данные. Я проверил базу — там всё обновляется, а вот API врёт. Сначала подумал, что проблема в базе, но запросы напрямую показывали актуальные данные. Тогда я полез в код. Проверил, как работает cachetools — вроде всё ок, кэш должен обновляться через 5 минут (ttl=300). Я даже увеличил ttl до 10 минут, думая, что данные просто не успевают обновляться. Но это не помогло. Коллеги уже начали шутить, что мой API живёт в прошлом. 🤯 В чём была проблема После дня копания я понял свою ошибку. Я не учёл, что кэш хранит данные по user_id, но не обновляется, если данные в базе меняются. Когда пользователь редактировал профиль, запись в базе обновлялась, но в кэше оставалась старая версия до истечения ttl. Нужно было либо инвалидировать кэш при обновлении, либо вообще не кэшировать изменяемые данные. Я добавил инвалидацию кэша при обновлении профиля: @app.put("/user/{user_id}") def update_user(user_id: int, user_data): --db.query(User).filter(User.id == user_id).update(user_data) --db.commit() --if user_id in cache: ----del cache[user_id] --return {"status": "updated"} Теперь API возвращало актуальные данные, и проблема исчезла. 🎯 Вывод Эта ошибка стоила мне дня и пары шуток от коллег. Что я вынес: Кэш — не панацея. Он ускоряет работу, но может вернуть устаревшие данные, если не продумать обновление. Инвалидируй кэш при изменениях. Если данные могут меняться, нужно либо очищать кэш, либо не использовать его. Тестируй с реальными сценариями. Я тестировал только получение данных, а не обновление. 🚀 Итог Кэширование — мощный инструмент, но требует осторожности. Теперь я всегда проверяю, как данные обновляются, и добавляю инвалидацию кэша. API заработало как надо, а я научился не бросаться в оптимизации без полного понимания. И да, коллеги перестали подшучивать. 😅

Факапы разработчика, день 5 💥 Ошибка, которая научила меня проверять данные Программирование — это как готовка: если ингредиенты не те, блюдо не получится. После прошлых факапов я решил, что теперь буду внимательнее к мелочам. Но оказалось, что можно облажаться не только с кодом, но и с тем, что в него приходит. 📌 Ситуация Я работал над небольшим веб-приложением на Flask. Нужно было сделать страницу, где пользователь вводит число, а сервер возвращает его факториал. Простая задачка: получаем число из формы, вычисляем факториал, показываем результат. Написал код, протестировал с парой чисел — всё работает, страница выдаёт правильные ответы. Но потом я заметил, что при некоторых запросах приложение возвращает странные результаты или падает с ошибкой. Например, ввожу 5 — всё ок, ввожу 10 — тоже ок, а ввожу 0 или отрицательное число — всё ломается. 🔎 День копания в коде Я начал проверять код. Вот как выглядела моя функция: def factorial(n): --if n == 0: ----return 1 --return n * factorial(n - 1) Казалось бы, всё правильно: для 0 возвращаем 1, для остальных чисел — рекурсия. Я добавил логи, чтобы посмотреть, что приходит в функцию. Оказалось, что проблема возникает, когда пользователь вводит отрицательное число или что-то нечислового типа, например, буквы. Но почему-то я был уверен, что Flask сам проверяет входные данные. Я полез в код формы и увидел, что беру данные напрямую: number = request.form['number'] result = factorial(number) Добавил проверку, чтобы преобразовать number в число: number = int(request.form['number']) Но это не решило проблему полностью: если пользователь вводил буквы, приложение всё равно падало с ошибкой ValueError. 🤯 В чём была проблема После дня дебаггинга я понял, что я вообще не проверял входные данные должным образом. Я предполагал, что пользователь всегда введёт корректное число, но в реальной жизни это не так. Нужно было добавить полную валидацию: try: --number = int(request.form['number']) --if number < 0: ----return "Ошибка: число должно быть неотрицательным" --result = factorial(number) --return f"Факториал: {result}" except ValueError: --return "Ошибка: введите число" Эта проверка решила всё: приложение перестало падать, а пользователю показывалось понятное сообщение об ошибке. 🎯 Вывод Эта ошибка отняла у меня день, потому что я был слишком наивным. Что я вынес: Никогда не доверяй входным данным. Пользователи могут ввести что угодно — буквы, пробелы, эмодзи. Добавляй валидацию на старте. Проверка типов и значений должна быть до любой логики. Делай понятные сообщения об ошибках. Это спасает и пользователя, и тебя от головной боли. 🚀 Итог Теперь я всегда начинаю с проверки входных данных, даже если кажется, что это «простая задачка». Приложение теперь работает стабильно, а я добавил ещё и верхний лимит на число, чтобы рекурсия не уронила сервер. И знаете, теперь я даже рад, когда вижу сообщение об ошибке — значит, я предусмотрел этот случай. 😄