Бэкенд

В статье рассматриваются особенности типов данных для хранения вещественных чисел в PostgreSQL.

Типы данных PostgreSQL для работы с вещественными числами:

1) float4, синоним real, синоним float(1..24)

2) float8, синоним float, синоним double precision, синоним float(25..53)

3) numeric синоним decimal. Диапазон для этого типа значительный: 131072 цифр до точки и 16383 цифр после точки. Но если при определении типа указать numeric(точность, масштаб), то максимальные значения точности и масштаба 1000. numeric можно объявить с отрицательным масштабом: значения могут округляться десятков, сотен, тысяч.

Кроме чисел и null поддерживаются значения Infinity, -Infinity, NaN.

Поля типов данных фиксированной длины не могут вытесняться в TOSAT-таблицу, переменной длины (numeric) могут.

float4 обеспечивает точность 6 разрядов (значащих чисел в десятичной системе счисления), float8 обеспечивает точность 15 разрядов. Последний разряд округляется:

Переезд крупных, высоконагруженных систем с одной СУБД на другую — всегда вызов, сравнимый с хирургической операцией на работающем сердце. Компания ОТР поделилась уникальным опытом миграции одной из таких систем с Oracle на отечественную Postgres Pro. Ирина Токарева и Сергей Кузнецов из ОТР рассказали о тернистом пути, противостоянии росту энтропии больших объёмов поступающих и изменяемых данных, достигнутых результатах.

Доброго времени, Хабр!

Совсем недавно я уволился из компании, в которой хорошей практикой считалось проведение обучающих/развлекающих презентаций для коллег во время ланчей (уволился не из-за этой практики, если что), и так как нынче я живу и работаю не в России, и все мои коллеги ничего не слышали ни про какие Joker‑ы и JPoint‑ы, то я решил несколько считерить, взять какую‑нибудь классную презентацию из этих конференций, перевести и показать коллегам (с указанием ссылки на первоисточники, разумеется, профессиональная этика мне не чужда). Выбор пал на видео Евгения Борисова и Баруха Садогурского «Приключения Сеньора Холмса и Джуниора Ватсона» (кто не смотрел — бегите и смотрите)

Таким образом я перевел два детективных расследования из того видео, и мне захотелось придумать свое собственное, а не только переводить чужие. Оффтопик: это офигеть как непросто. Надо перелопатить кучу информации, зацепиться за какие-нибудь прикольные баги/неочевидные моменты в работе java/фреймворков/etc., выцепить из них те, которые можно объединить в одно общее дело, затем еще антураж придумать, чтобы это был не просто код, а стилизованный код. Long story short: я сделяль. Я очень горжусь этой презентацией, я показал ее коллегам, я показал ее всем друзьям, и теперь вот решил выложить этот материал и тут

Наверняка вы все работаете с Kubernetes, публикуете сервисы наружу через Ingress-контроллер. Уверен, что большинство из вас использует ingress-nginx. Создаете манифест, деплоите его в k8s, но не всегда получаете именно тот результат, который хотели бы. Или же все работает, но спустя какое-то время что-то идет не так. 

В этой серии статей, созданной по мотивам выступления на DevOpsConf’25, мы подробно разберемся как работает сам ingress-nginx контроллер и почему это не совсем классический nginx. Погрузимся в дебри LUA-кода чтобы понять, как реализована балансировка. А также затронем тему сниппетов, как их включить если они вам очень нужны, и почему этого делать не стоит.

Меня зовут Алексей Колосков, я Lead DevOps из Hilbert Team. Больше 15 лет я в IT: за это время админил, разрабатывал, развивал on-premise инфраструктуру, инфраструктуру в облаках и даже курсы по DevOps, Security и DataTech в Yandex Cloud. Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специализацией Yandex Cloud Professional по направлениям DevOps и Data Platform.

Привет, Хабр! Это мой первый пост и решил я его посвятить тому: Как можно автоматизировать ведение своего ТГ канала с помощью ИИ. На мой взгляд тема довольно свежая и интересная, а что самое главное полезная. Статья по большей мере ориентирована на новичков у которых имеются базовые знания python, но это не означает что другим она не будет интересна. Итак, начнем!

Всем привет, меня зовут Миша, и я разрабатываю платформу Яндекс Еды. Первые компоненты были написаны почти 10 лет назад (когда Еда ещё была стартапом Foodfox), и у нас накопилось много кода, который просто хорошо работает, а иногда даже «работает — не трогай». Но в процессе развития и устоявшиеся части системы нужно трогать, про что мои коллеги уже писали — как мы повышали версию PHP, пилили монолит и снимали нагрузку с БД. 

Наконец настал черёд рассказать про процессинг заказов доставки еды из кафе и ресторанов (а также продуктов из магазинов и многого другого). За годы эволюционного развития он значительно разросся, что стало заметно затруднять дальнейшее развитие — например, изменения, связанные с выходом на новые рынки, — а также влиять на надёжность. 

Поэтому мы решили вынести процессинг заказа в отдельный специализированный сервис. Чтобы определить, что выносить, а что оставлять, нужно было составить исчерпывающий и актуальный список процессов, которые происходят с заказом. И здесь мы столкнулись с вызовом: это знание распределено по многим людям и документам, поскольку на протяжении долгого времени в процессинг заказов вносили изменения многие команды. И перед нами встал вопрос — как собрать нужную информацию о системе с заметной долей легаси быстро, да так, чтобы информация была актуальна?

Привет, Хабр!

Сегодня рассмотрим, как тестировать React‑хуки с помощью @testing-library/react-hooks.

Сравнивая различный code-style в проектах, я упоминал про методы проверки коллекций на наличие элементов. Самые очевидные способы – это использование LINQ-метода Any() или сравнение свойства Count с нулем. И если вы выбрали первый вариант, то у вас могут быть проблемы. Поэтому предлагаю подробнее рассмотреть этот вопрос. Кстати, если вы выбрали второй вариант, то у вас тоже могут быть проблемы.

Привет, Хабр!

В этой статье рассмотрим, что такое композиционные хуки во Vue 3, зачем они нужны и как их использовать.

Команда Spring АйО перевела и адаптировала доклад Мацея Валковяка “Performance oriented Spring Data JPA & Hibernate”, в котором на наглядных примерах рассказывается, как существенно нарастить производительность приложения, оптимизировав его взаимодействие с БД. 

Доклад будет опубликован тремя частями. В первой части было рассказано об оптимизации управления соединениями с базой данных. Во второй части мы посмотрели на то, как оптимизировать код и настройки Spring Data и Hibernate, чтобы минимизировать количество отправляемых в базу данных SQL запросов. Третья часть посвящена обзору инструментов, которые могут помочь разработчику правильно организовать работу по регулярной оптимизации производительности приложений, в том числе при работе командой.

Использование MVC — это удобная отправная точка для небольших и средних проектов. Он прост, широко понятен и поддерживается большинством фреймворков. Однако по мере роста продукта MVC становится архитектурным тормозом: он нарушает принципы модульности, затрудняет тестирование и ведёт к плотной связанности компонентов.

Привет, Хабр! С вами команда разработки платформы Russ Online Группы компаний Russ (входит в объединенную компанию Wildberries & Russ). Мы хотим поделиться историей о том, как от монолитной системы мы перешли к микросервисной архитектуре и облачным решениям на базе Kubernetes и S3. Эта трансформация создала фундамент для дальнейшего развития платформы и внедрения новых сервисов.

Пользователь Reddit опубликовал в r/rustjerk сгенерированный ИИ пост под названием «Почему наш CTO запретил использовать Rust после одного переписывания кода». Очевидно, что этот рассказ выдуман, но у меня есть история похожая на него в том смысле, что успех проекта на Rust привёл к прекращению использования этого языка в компании.

Несколько лет назад я работал в стартапе-«единороге», во время пандемии развивавшемся невероятно быстро. Его основное приложение было написано на Ruby on Rails, а часть инструментария для работы с видео — на Node.js, но мы никак не применяли быстрые компилируемые языки наподобие Rust и Go. Через пару месяцев после моего прихода в компанию нам нужно было реализовать работающий в реальном времени сервис, который бы позволял нам получать информацию о том, кто из пользователей находится онлайн (то есть в профиле есть зелёная точка) и чем они занимаются (например: N пользователей смотрят презентацию X, M пользователей находятся в разделе маркетинга и так далее). Ничего особо сложного, но мы рассчитывали на изначальный рост до ста тысяч пользователей. Эта цель тоже не особо сложна, но большинство разработчиков согласилось, что Ruby — не лучший выбор для этого.

Привет, Хабр! Сегодня у нас откровенный разговор с Денисом Глуховым — руководителем ЦК архитектуры блока цифровой трансформации РСХБ-Интех. Узнаем, как выглядит рабочий день специалиста, который хорошо знаком с кухней цифровой трансформации в крупном банке и превращает сложные бизнес-требования в эффективные технологические решения.

Денис, как начинается твой рабочий день? Есть ли у тебя утренние ритуалы или привычки?

Мой рабочий день начинается c момента,  когда я оставляю авто на перехватывающей парковке и сажусь в МЦД. Я открываю ноутбук и по пути на работу просматриваю накопившуюся почту, отвечаю на сообщения, просматриваю календарь и распределяю задачи, ранжируя их по приоритетам. Территориально с командой находимся на Теплом Стане, но фактически работаю на два офиса, так как большое количество очных встреч проходит с руководством в офисе в Москва-Сити. Люблю офис на Теплом Стане: там лучше думается. Мой обязательный утренний ритуал — самый большой завтрак в корпоративном кафе.

Какие основные задачи и проекты ты планируешь к выполнению сейчас? Как ты определяешь приоритеты?

Основной проект, который сейчас в активной фазе, — это Свои Финансы, цифровой канал обслуживания физических лиц, построенный на микросервисной архитектуре. В рамках данной активности мы уходим от монолитного решения подрядчика в сторону собственной разработки на импортозамещенном стеке и размещаем наши решения на интеграционной платформе App.Farm. А что касается приоритета для архитектора главное — это обеспечение потребностей бизнеса и продуктовых команд, помощь в проектировании и консультации. Это наша основная операционная активность .

В момент стремительного роста стартапа — когда вчерашний пилот оборачивается первой прибылью, а завтра уже планируется 100× exit — основатель впервые задумывается не только о цифрах на балансе, но и о том, что случится с бизнесом после него. Личная ответственность за семью и здоровье выходит на первый план, а нематериальные активы — код, домены, бренд — легко становятся «яблоком раздора» между наследниками.

Apache Spark — это мощный фреймворк для распределённой обработки больших объёмов данных, позволяющий выполнять сложные вычисления на кластерах компьютеров с высокой производительностью и гибкостью.

И вот 23 мая 2025 года компания Apache выпустила новую версию Spark 4.

Стоит отметить, что Apache Spark — масштабный фреймворк с широким функционалом. В данной статье я сосредоточусь на нововведениях, которые в первую очередь затронут пользователей Spark SQL и PySpark.

Привет! Меня зовут Азамат, я backend-разработчик в Циане. В работе мне часто приходится пересматривать архитектуру компонентов или проектировать её с нуля. Со временем у меня накопились подходы и наблюдения, которыми хочу поделиться.

В этой статье расскажу, с чего я обычно начинаю проектирование, какие вопросы задаю себе перед тем, как описывать архитектуру, и какие принципы помогают принимать решения.

Материал будет полезен тем, кто хочет влиять на архитектуру в своей команде и ищет, с чего начать.

Model Context Protocol (MCP) — это унифицированный протокол взаимодействия между большими языковыми моделями (LLM) и внешними источниками данных и инструментами. Spring AI предоставляет очень простой декларативный подход для добавления любых инструментов в контекст LLM с помощью MCP. Мы рассмотрим несколько простых примеров по созданию MCP-клиента и MCP-сервера.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Недавно получил такой комментарий к одному из обзоров ESB: «Я считаю, что интеграционные платформы больше не нужны», а спустя время в Телеграм-сообществе «Шины не для машины» развернулась дискуссия на тему «Паттерн ESB безнадежно устарел». Решил собрать в одной статье популярные вопросы по теме и ответить на них.

Статья о том, как мы улучшали логи внедрением сквозных идентификаторов и не только. Делали это для того, чтобы упростить и ускорить разбор возникающих ошибок. Это в разы сократило время разбора.

Статья может быть полезна backend-разработчикам, лидам, тестировщикам, аналитикам, которые проектируют и разрабатывают сложные системы. Код написан на java и соседних технологиях, но подходы, я уверен, универсальны. Они упростят жизнь при разборе ошибок на проде и на тестовых стендах.