Команда Python for Devs подготовила перевод статьи о том, почему Python так медленный и что сообщество делает, чтобы это исправить. PyCon 2024 показал: Python ждут субинтерпретаторы, immortal objects, JIT-компиляция и другие технологии, которые могут ускорить его в разы.
Статья о том, какие бывают ограничения самописных планировщиков задач и как мы перевели весь процесс планирования в NiFi, сделав его более прозрачным.
(Анонс: Привет. Собираю статистику по инженерным процессам — от enterprise до инди‑команд (форма в конце статьи). Результаты агрегирую и опубликую на хабре в ближайшее время. Анонимно, 5–10 минут. Важен каждый.)
В сети очень много информации о том, как работать в большой и многорукой команде, с кучей выделенных ролей и настроенными процессами. Да я и сам отправляю к девопсам, когда на конференции подходят и спрашивают «а как правильно сделать репликацию базы данных?», потому что они (девопсы) сделают это быстрее и правильнее почти любого бэкендера. Но кроме компаний, в которых работают тысячи инженеров и есть отдел «на любой чих», — есть компании, в которых работают три джуна и один мидл (кстати, они-то и задают этот вопрос). Я и сам когда‑то с такой компании начинал… И эта статья для них.
WebAssembly - молодая, но довольно перспективная технология. WASM позволяет упаковать программу в бинарный формат, который можно запускать на любой системе, в изолированной среде.
В статье посмотрим как WASM-модули взаимодействуют с Python хостом. (Спойлер - не все так просто как хотелось, поддержка WASM в Python экосистеме пока слабая)
Привет, Хабр!
Сегодня я хочу разобрать одну конкретную, но до безобразия полезную задачу, с которой мы столкнулись, когда наш сервис стал обрастать клиентами. Задача простая на словах, но с изюминкой: маршрутизировать входящие TLS-соединения в stream-модуле Nginx на разные бэкенд-пулы в зависимости от имени сервера SNI, которое клиент указывает в самом начале рукопожатия. Причем арендаторов могут добавлять каждую пятницу, а перезагружать Nginx каждый раз — это не наш метод. Конфиги должны быть статичными, а вот список арендаторов — динамическим, живущим где-то в Redis или etcd.
Языковые модели — это не магия, а мощный инструмент, который может ускорить работу программистов, аналитиков, маркетологов и менеджеров. В статье — разбор принципов работы LLM, ключевых проблем (галлюцинации, ограниченный контекст) и практик промпт-инженерии с примерами, которые помогают превратить ИИ в надежного помощника.
Привет, меня зовут Сергей Киселев, я управляю командой Development Platform в MWS Cloud Platform, а ещё давно провожу собеседования разработчиков и собираю команды. Умею делать алгоритмические секции без негатива от кандидатов, сам иногда собираю оферы, учу сына писать на C++. В этой статье расскажу, как мы построили процесс интервью для разработчика в MWS Cloud Platform. И почему важно на собеседовании проверять практические навыки.
Shenandoah — это высокопроизводительный сборщик мусора с низкими задержками, разработанный компанией Red Hat и впервые внедрённый в OpenJDK. Он был создан с целью минимизировать задержки на протяжении работы приложения, что особенно важно для приложений с высокими требованиями к производительности и отзывчивости. В новом переводе от команды Spring АйО рассмотрим основные особенности Shenandoah, его работу, настройку и примеры использования.
Привет, Хабр! Я — Калашников Сергей, DevOps‑инженер в Центре Перспективных Разработок (ex. R&D) компании Bercut. Cегодня поделюсь опытом внедрения систем на базе Tarantool и Tarantool Vshard в оркестратор Kubernetes.
Tarantool — платформа, которая включает в себя in‑memory базу данных, а также встроенный сервер приложений. На базе этой платформы наша команда разрабатывает различные информационные системы, расширяя функциональность с применением языков Lua, Rust, C\C++.
Несмотря на все очевидные плюсы Tarantool, он не является тривиальным в части конфигурирования и bootstrap. Это привело нас к разработке Operator для Kubernetes, который обеспечивает развертывание и конфигурирование кластеров на базе Tarantool и Tarantool Vshard.
Хотя большинство Java-разработчиков в России по-прежнему используют разные вариации IntelliJ IDEA, постепенно начинают появляться и новые альтернативы. Одна из них — OpenIDE, российская среда разработки на базе IntelliJ Platform. Мы уже писали о проекте, и он для нас особенно важен: Axiom JDK входит в консорциум разработки OpenIDE вместе с компаниями «Группа Астра» и Haulmont.
Проект стартовал меньше года назад и уже заметен на рынке Java-инструментов. Чтобы подтвердить это цифрами, делимся результатами опроса Spring АйО среди Java/Spring-разработчиков об используемых IDE в 2025 году.
В Rusprofile наш домен — регтех, мы помогаем компаниям оценивать надежность контрагентов. Каждый день сотни скриптов качают данные из официальных открытых источников, парсят и строят кеши.
В какой‑то момент суммарное время работы скриптов стало неподобающим — задача заканчивалась, условно, к обеду следующего дня, в то время, когда нам нужно было к утру.
Эта статья — о том, как «проклятье масштаба» оказалось алгоритмической задачей; решение — получилось благодаря принципам обхода ориентированных графов; а запаса прочности решения хватило, чтобы с момента появления на протяжении лет не требовалось дополнительных ресурсов и каких‑либо доработок.
Надеемся, эта история будет интересна тем, кому близки темы работы с зоопарком скриптов, управления связанными задачами, алгоритмических решений инженерных проблем, а также всем, кому любопытно, как различные сервисы устроены под капотом и какие особенности есть в регтех.
Будут технические детали, теория графов и немного рефлексии.
Привет, Хабр!
Это снова мы, подкаст «Скрамное ИТ», и у нас готов новый выпуск!
Вы когда-нибудь пытались применить ИТ-логику в личной жизни или распланировать отпуск как рабочий проект? Если да, то этот выпуск точно для вас. Мы поговорим о том, как ИТ-мышление выходит за пределы работы и начинает управлять нашей жизнью — со всеми вытекающими последствиями.
На этот раз нашим гидом по теме стала Юлия Уварова.
Привет, Хабр! Меня зовут Алексей Николаевский, и мы с командой делаем СУБД Яндекса. С 2013 года в Яндексе использовали Kafka для потоковой передачи данных. Но Kafka со временем перестала справляться с растущими объёмами, и в 2017 году мы перешли на своё решение.
Брокер сообщений YDB Topics во многом вдохновлялся Kafka: в нём также есть топики, партиции и аналогичные способы работы с данными. Но есть и существенные отличия, о которых в конце прошлого года я рассказал на московской конференции HighLoad. Под катом — адаптированная для Хабра статья по мотивам этого доклада: про архитектуру транзакций в обеих системах и интересные для разработчиков детали и нюансы, которые мы обсуждали на конференции.
Доброго времени суток дорогой читатель!
Всё последующее содержание статьи очевидно является некой формой садизма, так что если если вы пришли за чоколадкой golangом, питоном, ванильным чапманом или другими формами сладкой жизни, лучше уходите.
Тема изоляции данных клиентов (мультитенантность) в saas или подобных продуктах исторически считается если не самой, то одной из наиболее сложных и требующих архитектурных извращений, тем в веб-разработке.
Существует несколько разных подходов, от банального tenant_id в каждой таблице базы данных, до физического разделения данных на разные сервера под разных тенантнов.
Компромиссным решением является выделение идентичных по содержимому (таблицам) схем для каждого нового клиента в одной базе данных. Таким образом мы получаем относительную защиту от утечек данных между клиентами с минимальными затратами на аренду новых серверов. Именно этот вариант мы и будем рассматривать.
Привет, Хабр!
Есть такой интересный компонент в Vue.js и называется он<Suspense>. Он устроен так, чтобы собирать зависимые async-компоненты и показывать единый индикатор загрузки вместо кучи спиннеров. Проще говоря, пока внутренняя часть (слот #default) ещё не готова из-за ожидания данных, показывается запасное содержимое из слота #fallback. Как только все асинхронные зависимости разрешатся – снимаем запасной экран и выводим основное содержимое. По сути, <Suspense> создаёт границу вокруг вложенных компонентов и контролирует их загрузку.
Это обзор двух проектов аналитических СУБД с открытым исходным кодом, которые развиваются в одном классе задач, но различаются архитектурой, приоритетами и типичными сценариями применения. Ниже — нейтральное сравнение по ключевым аспектам: архитектура и запросный движок, хранение и работа в реальном времени, интеграция с открытыми форматами и lakehouse, производительность, эксплуатация и управление, а также рекомендации по выбору в зависимости от нагрузки.
Виртуальные потоки (JEP 425) являются мощным инструментом для построения приложений, которые в теории могут обслуживать десятки тысяч запросов в секунду. Однако это в теории. Практика же может выглядеть совершенно иначе. Данная статья рассказывает о нескольких подводных камнях, из-за которых виртуальные потоки могут не сработать, а сделать даже хуже.
Команда Go for Devs подготовила перевод статьи о том, как оптимизация аллокаций в Go может снизить нагрузку на сборщик мусора и ускорить приложение почти в два раза. Автор показывает на примере реального веб-приложения, как профилировать кучу, находить «горячие» места и убирать лишние аллокации, чтобы снизить задержки и повысить пропускную способность.
Команда Python for Devs подготовила перевод статьи о том, как найти самый быстрый способ загрузки данных в PostgreSQL с помощью Python. Автор пошагово сравнил разные методы — от построчных вставок до COPY с потоковой генерацией CSV — и показал, как ускорить процесс более чем в 250 раз при нулевом потреблении памяти.
Как GC останавливает весь "мир", чтобы "вынести мусор"!
Концептуальное описание работы GC в Ваших приложениях.