Чем популярнее становится FastAPI, тем сильнее критикуют Django. И не просто критикуют. Брезгуют? Пренебрегают? Всего понемножку. Всё чаще слышу, что Django — пережиток прошлого. Любой проект на Django — устаревший мусор. Любой «джанговод» — просто не знает, что тоже устарел. Объективно ли это? Нет, не объективно. Если отвёртка плохо забивает гвозди, это не значит, что отвёртки устарели — просто это не их задача.
🚀 Хотите создать регистрацию в стиле Google для своего Android-приложения? 🚀
Забудьте о скучных формах! Погрузитесь в мир плавной анимации, интуитивного дизайна и надежной безопасности – всё это с помощью Kotlin и Jetpack Compose.
✨ Что вас ждет:
Пошаговый гайд: От первых строк кода до готового результата – разберемся вместе.
Рабочий код: Не просто теория, а готовые решения для вашего проекта.
Комментарии эксперта: Поймете каждый шаг и сможете адаптировать код под свои нужды.
Секреты профессионалов: Узнаете, как сделать регистрацию не только функциональной, но и привлекательной.
💪 Не упустите шанс прокачать свое приложение! 💪
За годы работы с TypeScript, Java, Kotlin и Go я не раз сталкивался с одним и тем же паттерном: команда внедряет «правильное» архитектурное решение — и получает не гибкость, а технический долг.
Причина проста: оверинжиниринг маскируется под профессионализм. Мы выбираем сложные инструменты не потому, что они нужны, а потому, что «так делают в серьёзных проектах».
В результате принцип KISS — «Keep It Simple, Stupid» — работает не хуже, чем в 1930-х, когда его впервые сформулировали в среде авиационных инженеров. В этой статье — мой личный список подходов, которые в 90% случаев (особенно в REST-серверах) приносят больше вреда, чем пользы.
Каждый инвестор рано или поздно сталкивается с необходимостью ведения учёта своего портфеля, особенно если брокеров несколько. В первом приближении для этого подходит Excel: многим знаком, работает локально и почти всегда установлен на компьютере. Подходит для расчета доходности, учета дивидендов.
Однако механическая работа со временем утомляет, а возможности Excel для автоматизации онлайн получения котировок ограничены. Google Таблицы решают эту проблему: это изначально облачный инструмент. Чтобы получить актуальную цену акций, достаточно одной формулы.
В этой статье мы разберём, как Google Таблицы могут дать инвестору больше свободы. Я покажу на примерах, как с помощью встроенных инструментов и простых гугл скриптов (Google Apps Script) превратить таблицу в полноценную платформу для анализа и автоматизации вашего портфеля. А ещё разберем получение котировок в обоих инструментах.
Привет, Хабр!
Мы тут в свободное время пилим проект, который должен решить боль многих айтишников, — автоматизировать рутинный поиск работы. Идея выросла в Telegram-бота «Аврора» , который на "автопилоте" ищет вакансии на hh.ru и откликается на них.
Но чтобы "автопилот" был полезным, он должен быть надежным. Никому не нужен ассистент, который при первом же деплое новой версии или падении сервера забывает, что он делал, и какие вакансии уже отправил.
Сегодня я хочу рассказать не столько о самом боте, сколько о конкретной инженерной задаче, с которой мы столкнулись: как обеспечить персистентность и "бесшовное" возобновление длительных пользовательских задач при перезапуске сервиса.
Под катом — наш подход к Graceful Shutdown, восстановлению сессий и немного про то, как LLM (в нашем случае Gemini) генерирует поисковые запросы.
Привет, Хабр!
я Python-инженер. Последние несколько лет я в одиночку строил довольно сложную бэкенд-систему, и за это время набил немало шишек и нашел, как мне кажется, несколько интересных решений. В этой статье я хочу поделиться не "историей успеха", а конкретными архитектурными проблемами и их решениями при построении высокопроизводительного сервиса на асинхронном Python.
Статья будет полезна тем, кто работает с FastAPI, микросервисами и думает о надежности и масштабируемости своих систем.
В этом посте я расскажу, почему для доставки push-уведомлений в клиентское приложение была выбрана технология Server-Sent Events, и главное, как реализовать масштабируемый SSE сервис на Java + Spring Boot + Webflux, который подойдет для использования не только в небольших проектах, но и в крупных организациях с большим количеством пользователей. Естественно, без подготовки дополнительной инфраструктуры не обойдется.
Если ваш Битрикс тормозит, а Laravel кажется из другой вселенной — эта статья для вас.
На связи Алиса — тимлид в e-commerce агентстве KISLOROD. Мы ежедневно имеем дело с большими каталогами, сложной коммерцией и 1С, которая дышит в затылок. И однажды мы решили сделать невозможное: подружить Битрикс с Laravel. Так, чтобы Битрикс остался каноном и привычной админкой, а Laravel стал помощником — взял на себя API, тяжёлую бизнес-логику и все, что тормозит. Без форка ядра, слез SEO-шника и без утечек в 1С. Да, это реально.
Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.
Я начал писать эту статью около двух месяцев назад. Писал по мере возможности и уже почти закончил, как буквально на днях было обсуждение именно этой темы с коллегами. По результатам услышанных там вопросов я добавил еще пару абзацев, чтобы постараться ответить на данные вопросы в комплексе. Эта статья лежала в черновиках с декабря 2021г, я совсем про нее забыл.
В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.
Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.
Fast Healthcare Interoperability Resources (FHIR) - это прокотол для обмена медицинскими данными. Стандарт очень объемный, одних только ресурсов более полутора сотен, и цель данной статьи - дать стартовую точку для его изучения.
Это первый из запланированной серии постов посвященных FHIR технологиям, далее планирую добавить статьи с шагами регистрации и подключения к EPIC EHR, загрузки FHIR данных, их использования для формирования карты пациента и особенностями использования FHIR данных в AI чат-ботах.
Вчера вечером в Сан-Франциско прошла конференция DevDay 2025, на которой OpenAI представила масштабное обновление своей экосистемы. Компания заметно сместила фокус с потребительских продуктов на создание надёжной и масштабируемой платформы для разработчиков и корпоративного сегмента. Под руководством CEO Сэма Альтмана и при участии легендарного дизайнера Джони Айва мероприятие продемонстрировало новое видение ChatGPT как центральный хаб для взаимодействия с приложениями, данными и автоматизацией.
Ищем как Perplexity по базам научных публикаций, стандартам, книгам, мессенджерам и социальным сетям.
Команда AI for Devs подготовила перевод статьи о новом API /v1/responses от OpenAI, который объединяет простоту Chat Completions и мощь Assistants, и при этом сохраняет состояние рассуждений, мультимодальность и встроенные инструменты. Это шаг к агентам будущего — и, похоже, к новому стандарту работы с моделями OpenAI.
Современные системы состоят из множества различных сервисов и одной из основных задач является обеспечение обмена данными между компонентами системы. Для обеспечения этой функциональности используются шины данных (Enterprise Service Bus, ESB), интегрирующие различные приложения и системы в единую информационную среду. Она выступает в роли «посредника», минимизируя прямые связи между отдельными системами и обеспечивая гибкость взаимодействия. Таким образом, основная цель внедрения ESB — оптимизировать и унифицировать взаимодействие внутри информационного ландшафта предприятия.
Привет, Хабр! Меня зовут Дарья Борисова, я системный аналитик в ПСБ.
Однажды я попробовала интеграции... и теперь они преследуют меня везде, как навязчивый мотив из песни.
Пришлось изучать и внедрять разные подходы, а заодно накопить вагон и маленькую тележку лайфхаков. Сегодня я работаю с Системой быстрых платежей в ПСБ — и готова поделиться тем, что спасло нас в критичных ситуациях.
Почти наверняка вы бывали в ситуациях, когда всё выпустили в прод, а сервер нагрузку не тянет. Или бизнес давит сроками, а времени на идеальные решения нет. Приходится подставлять костыли и ставить быстрые заплатки. Вопрос в том, могут ли они стать надежным решением? И какие компромиссы придется принять — об этом и поговорим.
А точнее: об оптимизации REST API в бою: как снизить количество запросов без потери данных, где проводить расчеты (и чем это грозит), зачем стандартизировать ответы, как кешировать с умом и почему health-check — это не просто «жив/мертв».
История о том, как очередная «быстрая костыль-интеграция» на коленке неожиданно превратилась в почти полноценную Order Management System (OMS) с элементами event-driven архитектуры. Всё это — без предварительного проектирования и без единой строчки кода на Java/Scala/Python (хотя тут немного лукавства, так как пару скриптов на Groovy все-таки имеется), на чистом Apache NiFi и SQLite.
Девизом этого проекта мог бы стать слоган: «Мы не ищем лёгких путей, мы ищем работающие решения». Я инженер в одной ритейл компании, который любит решать задачи, и сегодня расскажу, как закрыл боль бизнеса малой кровью, используя не совсем типичный для веб-сервисов инструмент.
Вот здесь можно посмотреть исходники
Привет, Хабр! Я старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой. Материал основан на реальных кейсах из практики: мы в школе System Analyst не просто рассказываем теорию, а делимся тем, что действительно работает на проектах.
За свою карьеру я написала не одну сотню требований и поняла такую вещь – самые важные и самые незаметные, это блок нефункциональных требований.
В этой статье я расскажу, как правильно выявлять и формулировать НФТ.
Сегодня доклад будет максимально простыми словами, будто сидим, пиво пьем, рыбку едим, потому что необычайно сложный контент. Но я хочу, чтобы вы выключили полностью мозги, расслабились, получили удовольствие и читали сердцем. Все это делал я, Александр Сербул, с небольшой командой. Моя задача — возбудить в вас интерес к Rust, высоким нагрузкам, асинхронщине, многопоточности и тому, как мы это используем.
Привет, Хабр! Каждый раз, создавая новый эндпоинт, я ловил себя на мысли: «А как назвать маршрут?». Казалось, что где-то есть законы и правила, которые помогают создавать API последовательно. Со временем я наткнулся на диаграммы по проектированию, прочитал книгу JJ Geewax — API Design Patterns (Джей‑Джей Гивакс), изучил рекомендации от крупных компаний и понял важную мысль: проектирование API — это такая же область знаний со своими принципами и стандартами.
Однако возникает проблема: стандарты есть, но они разные. Многие из них красивы на бумаге, но непонятно, как их применить в обычном CRUD‑приложении без сложной бизнес‑логики.
Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно.
Есть за мной такой грешок: если какая-то проблема мне долго досаждает, я в конце концов пишу библиотеку, которая её решает. На сей раз такая история возникла с кодом для валидации CLI.
Смотрите, я немало времени уделяю чтению кода, который написали другие люди. Это код опенсорсных проектов, всякий материал по работе, а также код из случайных репозиториев с GitHub, на которые, бывает, наткнёшься в два часа ночи. Причём, я то и дело замечаю одну и ту же проблему: в любом инструменте CLI найдётся одинаковый уродливый валидационный код, запрятанный поглубже. Знаете, в таком роде:
