Бэкенд

Я задал это вопрос ИИ (Google) и получил ответ:

Виртуальные машины (ВМ) нужны для запуска нескольких операционных систем на одном компьютере, тестирования программ без риска для основной системы, создания изолированных и безопасных сред, а также для эффективного использования серверных ресурсов в облачных вычислениях и дата-центрах. Они полезны для разработчиков, системных администраторов и для пользователей, которым необходимо работать с разными ОС или приложениями. 

Основные причины, зачем нужны виртуальные машины:

Запуск нескольких ОС: Позволяют использовать Windows на Mac или, наоборот, запускать различные операционные системы в отдельных окнах на вашем компьютере.

Тестирование: Можно безопасно тестировать новое или подозрительное программное обеспечение, не боясь навредить основной системе. Это особенно актуально для тестирования приложений на разных платформах (например, на Windows и Linux).

Изоляция и безопасность: ВМ создают изолированную среду. Если в виртуальной машине произойдет сбой или она заразится вирусом, это не повлияет на работу основной операционной системы.

Виртуальные серверы: ВМ позволяют использовать один физический сервер для размещения нескольких виртуальных серверов. Это экономит средства, снижает потребление энергии и упрощает управление серверной инфраструктурой для компаний.

Гибкость и масштабируемость: ВМ легко создать, настроить и перенести. Это позволяет компаниям быстро адаптироваться к меняющимся нагрузкам и легко масштабировать свои ресурсы.

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

Разберемся с каждым пунктом по отдельности.

Уже начало ноября, и мои парсеры давно собрали свежие данные. Сегодня я поделюсь анализом обновления рейтинга и новостями проекта...

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

Сегодня расскажу о довольно узком, но довольно интересном моменты работы с Linux — о процессе с PID 1 и зомби-процессах. Когда запускаешь приложение в минимальном окружении и оно оказывается первым процессом, могут возникнуть небольшие сюрпрзики. Та же команда ps может показывать несколько процессов со статусом <defunct>. Эти дефекты и есть зомби-процессы. Столкнувшись с ними впервые, можно растеряться, ведь процесс уже завершился, а запись о нём всё торчит в таблице процессов. Как так, и главное, что с этим делать?

Давайте смотреть, почему появляются зомби, какую роль здесь играет процесс №1 (он же init), и как написать свой минималистичный init, который этих зомби убивает (то есть убирает) автоматически.

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

Вспомните свой последний скрипт для автоматизации. Возможно, он скачивал данные, обрабатывал файлы или отправлял отчеты. Вы быстро набросали логику, запустили из командной строки, передав пару аргументов через sys.argv, и… всё сработало. Вы молодец.

Проходит месяц. Скрипт нужно запустить снова. В каком порядке шли аргументы? Какой из них был необязательным? А может, коллега просит поделиться вашей утилитой? В этот момент простая автоматизация превращается в проблему юзабилити.

Некоторые считают Java раздутым монстром, а Rust — чемпионом производительности. Но что, если взглянуть на современную Java с Vector API и многопоточностью? 

В новом переводе от команды Spring АйО посмотрим на запуск масштабной симуляции частиц и сравним результаты. Правда ли, что бывалая Java всё ещё умеет удивлять? 

Сравнение performance-а языков всегда было холиварной темой. Рекомендуем расценивать статью как приглашение к конструктивной дискуссиии, а не как призыв к конкретному действию.

Библиотеки на С слишком сложны. И в этой статье я хочу подробно описать что конкретно под этим имеется в виду и почему оно происходит

Нет, я не про сложность задач, которые они решают, не про количество кода или его качество, а про то, что они представляют собой для конечного пользователя.

Библиотеки не просто сложны, они выглядят намеренно переусложнёнными, как будто разработчики намеренно делали всё, чтобы то во что они вкладывали годами свой труд невозможно было использовать.

Для незнакомых с ситуацией вкратце - любая библиотека на С это в конечном счёте всего лишь набор .c файлов и набор .h файлов, а также опции компиляции которые записываются в современности в CMakeLists.txt. Для адекватных библиотек CMakeLists.txt обычно состоит из набора опций в самом верху (и только они нужны пользователю) и дальше описания таргетов (библиотеки, исполняемые файлы), зачастую это укладывается в сотню строк

Но по какой-то причине в реальности всё совсем не так и тут нужно смотреть на примеры

Типичным примером можно считать репозиторий OpenSSL. Взгляните на (ЧАСТЬ) того что видит перед собой человек, который хочет использовать OpenSSL:

Сегодняшний IT-рынок — это парадокс. С одной стороны, рекрутеры захлебываются в волне откликов: 200+ резюме на вакансию за сутки стали нормой. С другой — компании по-прежнему месяцами ищут «того самого» кандидата и жалуются на нехватку качественных специалистов.

Что пошло не так? Мы провели вебинар с Еленой Муся — экспертом с 17-летним опытом в HR и владелицей кадрового агентства, работающего с IT-продуктовыми компаниями. На основе этого живого разбора и нашего опыта в Слёрме мы сформулировали главные проблемы найма в 2025 году и наметили пути их решения

Привет! Я Алиса, DevOps-инженер в KTS.

В этой статье я расскажу о том, как мы настроили автоматическое обновление драйверов NVIDIA для работы с Jupyter и ML-стеком в управляемом кластере.

Проблема: когда контейнеры и ML-библиотеки обновляются чаще, чем системные образы GPU-нод, версия драйвера быстро перестает соответствовать версии CUDA в контейнере. В итоге при вызове  nvidia-smi возвращает ошибку Driver/library version mismatch, а CUDA просто не видит драйвер на хосте.

Нам нужно было обновить Jupyter с ML-стеком, зависящим от CUDA. Как следствие, встал вопрос обновления драйверов NVIDIA на GPU-нодах. Можно было выполнять его руками на каждой ноде, но такой способ нам не подходил, и мы выбрали автоматизацию, которой и посвящена моя статья. Ниже я разберу и ручное обновление, и варианты автоматизации, а также объясню, как мы решали проблему конфликта GPU Operator с предустановленными драйверами.

Привет, Хабр! Мы — Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать.

Приветствуем любую обратную связь! (づ ◕‿◕ )づ

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

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

Если вы пишете код дольше пары недель, вам наверняка знакомо это чувство. Ваш проект, который вчера работал идеально, сегодня после пары «незначительных» правок ведет себя непредсказуемо. Вы чините одно — ломается другое. Каждое изменение превращается в ручную проверку всего приложения, а рефакторинг вызывает тихий ужас. Код становится похож на хрупкий карточный домик, где тронешь одну карту — и всё рухнет.

Это не ваша вина. Это естественный этап роста любого проекта. И чтобы перейти от «кода, который страшно трогать» к «надежной и стабильной системе», профессиональные разработчики используют один мощный инструмент — автоматизированное тестирование.

Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI, для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит.

Да, создание графа зависимостей в compile-time — это, во-первых, очень быстро, и, во-вторых, удобно: получаешь сообщения об ошибках конфигурации уже при компиляции.

Но накладные расходы на сопровождение всего этого хозяйства – прямо скажем, это боль.

Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости.

Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

Храните десятки копий одного файла?

Dedupler — Laravel-пакет, который автоматически предотвращает дубликаты через SHA-1 хеширование. Экономит место, ускоряет бэкапы, предоставляет REST API, одобрен Laravel News.

Рассказываю про возможности, производительность и миграцию legacy-проектов.

Приключилась у меня беда, посыпался один жёсткий диск. Думал его полечить с помощью "Виктории". Но увы, сейчас всё изменилось и диски стали умными.

Раньше можно было пометить плохие секторы, что бы операционная система туда ни чего не писала. Диск работал дальше, только становился меньше объёмом.

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

Что бы диск попытался использовать резервы в плохой сектор должно быть что-то записано. Терять мне нечего, перезаписываю диск нулями. Перехожу в линукс и выполняю команду:

Качество данных — это не просто вопрос наличия значений в столбцах таблиц. Это вопрос доверия к данным в целом. Мы можем создавать сложные системы отчётности, но если на каком-то этапе ETL в данных возникают пропуски, дубликаты или они не соответствуют ожиданиям, вся система теряет доверие потребителей. В результате приходится тратить много времени на поиск и устранение причин таких проблем.

Гуминовые вещества есть почти повсюду в природе – это сырье будущего.
Эти вещества проявляют уникальные биологические свойства, не нанося никакого вреда природе. Гуминовые вещества (от лат. humus — земля) впервые были выделены в 1786 году немецким учёным Францем Ашаром из торфа.  Водные гуминовые вещества были впервые выделены в 1806 году из родниковой воды  Йёнсом Якобом Берцелиусом.
Природное органическое вещество – это стык живого и неживого. Гуминовые вещества (ГВ) – это продукт разложения всей живой органики, в который превращаются растения после отмирания при разложении растительных и животных остатков под действием микроорганизмов и абиотических факторов среды. Представляют собой макрокомпоненту органического вещества почвенных и водных экосистем, а также твёрдых горючих ископаемых. Авария на резервуаре № 5 ТЭЦ-3, принадлежащей Норильско-Таймырской энергетической компании (НТЭК) — дочернему предприятию «Норникеля», привела к утечке около 21 тысячи тонн дизельного топлива.  Авария была вызвана сочетанием технологических, климатических и человеческого факторов. Основной причиной стала разгерметизация резервуара № 5 на ТЭЦ-3 вследствие проседания свайного основания, вызванного таянием вечной мерзлоты. Топливо попало в близлежащие реки Амбарная и Далдыкан, а также озеро Пясино, создав угрозу для экосистемы Северного Ледовитого океана. Разлив нефтепродуктов стал одним из крупнейших в Арктике за всю историю и привёл к значительному экологическому ущербу.

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

Сегодня рассмотрим решение одной непростой задачи, как в Django выдавать очень большие объёмы данных, например, выгрузку в CSV или потоковый JSON-формат NDJSON) так, чтобы сервер не ложился от нагрузки, а пользователи быстрее получали первые данные. Разберём, как использовать StreamingHttpResponse и генераторы (в том числе асинхронные) для стриминга больших ответов и поговорим нюансах.

Конец осени, первый снег и идеальный момент, чтобы заглянуть под капот системного софта. 22 ноября в Москве соберем системных инженеров, исследователей и разработчиков, чтобы обсудить, как устроены компиляторы, ядро Linux и драйверы. Митап разделен на два потока: С++ и C/Linux kernel. Регистрируйтесь и подключайтесь — офлайн или онлайн.

Привет, Хабр! Я Роман Севрук, менеджер по развитию решений СУБД в К2Тех. Мы своего рода детективы на технологическом рынке — выслеживаем и разбираем каждое новое решение в сегменте российских баз данных.

В этой статье рассмотрим новую подборку баз данных с разными технологическими подходами, которые формируют ландшафт локальной экосистемы российских СУБД. Объясним: