Недавно наши интеграционные тесты Jest упали из-за недостатка памяти. Как оказалось, это не было аномалией, и тесты постоянно аккумулировали на себе столько памяти, что единственный процесс Node.js достиг стандартного предела в 4 ГБ, установленного в V8 для размера кучи. У нас около 450 тестов, объединенных в 50 сьютов, которые в основном являются интеграционными: имитированные HTTP-запросы обрабатываются на сервере, который взаимодействует с базой данных Postgres, запущенной в Docker. По этой причине мы используем последовательный запуск, поскольку у нас нет изолированного хранилища для каждого сьюта. После того, как мы обнаружили несколько проблем с Jest, соответствующих нашим диагнозам, одним из действий, которые мы предприняли, было выяснить, сможет ли миграция на альтернативный фреймворк решить наши проблемы.
Завалить важный проект из-за Agile, уронить огромную CRM и потерять всю БД маркетплейса — это не страшный сон в ИТ, а реальность. Мы устали от «успешного успеха» и уже делились факапами СберМаркета на F*ckup Meetup. А сегодня мы расскажем о пяти громких провалах других компаний.
При всех достоинствах Kafka как распределенного хранилища потока сообщений, боль вызывало раздельное хранение метаданных (топологии разделов, конфигурации кластера и прочего) и необходимость запуска в кластере рядом с Kafka еще и Apache Zookeeper. Побочным эффектом такого соседства (кроме дополнительных забот об администрировании и мониторинге) является долгое время восстановления после сбоя при больших размерах кластера, значительном количестве разделов или сложной топологии групп. Но ситуация улучшается и отличная новость появилась полторы недели назад в KIP-833, что в ближайшей версии Kafka 3.3 новый протокол согласования метаданных (KRaft), работающий внутри Kafka без Zookeeper, будет признан Production-Ready и далее постепенно зависимость от Zookeeper будет помечена как deprecated и удалена. В этой статье мы поговорим об особенностях протокола KRaft и разберемся как настроить новый кластер Kafka без необходимости установки Zookeeper.
Сравнение объектов является важной функцией объектно-ориентированных языков программирования. В этом руководстве мы рассмотрим некоторые функции языка Java, которые позволяют нам сравнивать объекты. Также мы обратим внимание на подобные функции во внешних библиотеках.
Специально для тех, кто ищет альтернативу Unreal Engine или Unity, мы продолжаем цикл статей про безболезненный переход на UNIGINE с зарубежных движков. В третьем выпуске рассмотрим миграцию с Unreal Engine 4 с точки зрения программиста.
Под катом: написание игровой логики, триггеры, ввод, рейкастинг и другое.
Об оптимизации закупочной деятельности мы впервые задумались ещё в 2019 году. Создавать облачный сервис для некоммерческих закупок (закупок для нужд компаний) B2B Altis мы решили в нестандартном для российского рынка партнерстве, когда ритейлер выступает не просто заказчиком решения, но и его соразработчиком. В качестве партнера была выбрана крупнейшая коммерческая площадка электронных торгов B2B-Center. Партнерство открывало доступ к проверенной базе российских поставщиков - 574,6 тысячам контрагентов.
В крупной компании закупки – вопрос серьёзный, регулируется ESG-политикой, нормативами и требованием полной прозрачности. Закупочная деятельность нуждается в штате специалистов, которые чуть ли не в ручном режиме и в разных системах управляют процессами, в том числе базами данных, проверкой документации, поиском поставщиков и, наконец, контролируют поставку. До разработки сервиса нам было сложно отследить, на какой стадии заказ и в какой степени он соответствует первичным договоренностям.
Данными Mediascope ежедневно пользуется большинство участников медиарекламного рынка и каждый день наши клиенты совершают множество запросов как к самим данным, так и к нашим сервисам расчета и анализа медиапоказателей. Поэтому нам нередко приходится решать самые разные задачи, связанные с оптимизацией нагрузки на инфраструктуру. В этой статье вы найдете интересный кейс управления нагрузкой на кластер ClickHouse (CH), который решили внутри Mediascope. Команда нашего отдела разработки систем расчета и доставки прошла большой путь: от неуместного применения МL до простого, но рабочего решения.
Эта статья предназначена, прежде всего, для тех, кто является либо управленцем (то может быть человек, который управляет проектом, коллективом, взаимодействует с каким-либо заказчиком, с внешней стороной), либо она также может быть интересна для тех, кто хочет разобраться и вообще более-менее понимать, что такое классовая теория и как её можно использовать на практике.
Лично я считаю, что сама по себе эта теория очень хороша и удобна. И если вы будете ее использовать в своей работе, то вам, как и мне, будет гораздо проще.
Это история о первой из двух катастроф связанных с межконтинентальной баллистической ракетой Titan II.
В далёком 1965 году, 9 августа, в штате Арканзас на стартовом комплексе 373-4 всё шло своим чередом. Ракета Titan II находилась в пусковой шахте под землёй, персонал занимался её обслуживанием. Комплекс 373-4, расположенный недалеко от города Сирси, проходил программу модификации под названием YARD FENCE. YARD FENCE имел призвание облегчить техническое обслуживание системы и повысить её надёжность, а также устойчивость шахты в случае ближнего ядерного взрыва. Согласно плану, Titan II должна была находиться в шахте полностью заправленной без боеголовки. На своих рабочих местах находилось около 50 человек. Работа кипела как в бункере, так и на поверхности. Гидравлическая система №2, которая приводила в действие рабочие платформы и взрывные клапаны шахты промывалась. Резервуар с гидравлической жидкостью и насос для неё располагались на поверхности. Их задача — прогонка гидравлической жидкости через 8-дюймовый канал (20.5 см). Крышка бункера была закрыта. Для проведения работ требовались кислород-ацетиленовая и электродуговая сварка. Всё оборудование располагалось на 2 — 7 уровнях шахты. Работы включали в себя покраску люков доступа с Т-образными замками на первом уровне, а также установку стальных крышек на акустические модули на уровне 7 и несколько выше.
Немного контекста о том, как возникло это исследование...
В один из тех летних дней, когда на улице стояла ясная, солнечная, жаркая погода, когда стрижи быстро пролетали за окном, распространяя веселые звуки, мы закончили очередную задачу по проекту (в нашем проекте используется Python). Задача заключалась в получении различными способами (очередь, сервисы, файловая система и т.д.) входящих документов (JSON формат), обработке этих документов и сохранении обработанных документов обратно в JSON формате в архивную базу данных. Завершив кодирование и юнит тесты, мы выкатили решение на одно из тестовых окружений и стали ждать результатов. По функциональности решение работало отменно, но, оценив скорость работы решения, я задался вопросом, а можно ли его ускорить?
Закусывая гудроном остатки радиоактивной водки, с интересом наблюдаю за всеобщей истерией. Добралась она и до нас, когда ключевой заказчик решил завернуть свои системы за VPN, в том числе и Gitlab, где мы должны хранить исходники и обновлять их перед релизами. Делать это вручную не хочется, поэтому решил автоматизировать процесс, а заодно написать данную статью, по сути – рабочую инструкцию для коллег, ну и для вас, уважаемые читатели.
В статье рассматривается ситуация, когда необходимо синхронизировать два репозитория, находящихся на изолированных друг от друга серверах Gitlab, и есть машина, с которой есть доступ до обоих серверов. Синхронизация осуществляется скриптом на bash, который проверяет наличие обновлений и производит pull-push при их наличии, а также оповещает о событии в Telegram.
Привет, Habr!
Вы или ваши близкие точно сталкиваетесь с тем, что раз в месяц нужно выйти на лестничную площадку, включить фонарик в телефоне и переписать показания счётчика электроэнергии, а ещё снять показания счётчиков воды, и, возможно, даже природного газа. Нашим коллегам из департамента недвижимости и эксплуатации приходится проделывать такое упражнение ежемесячно на 18 тысячах объектов! Поэтому у нас в команде Центра искусственного интеллекта (ЦИИ) Блока «Сервисы» появилась идея облегчить жизнь сервис-менеджера с помощью технологии Computer Vision (далее CV), как Optical Character Recognition (сокращённо — OCR).
В принципе, задача выглядела простой и очевидной даже на уровне начинающего специалиста, который только осваивает технологии CV. Но в реальной жизни всё оказалось намного интереснее и вариативнее. Во-первых, даже при наличии некоторого количества публикаций с описанием похожих решений не оказалось готового датасета, на котором эти решения можно было бы сравнить. Во-вторых, обладая достаточным количеством ресурсов, сбор и разметка данных всё равно потребовали значительной изобретательности.
Кроме того, на своей лестничной площадке мы видим всегда одни и те же счётчики, а разнообразие их видов в «дикой природе» оказалось гораздо шире! Поэтому мы решили, что будет интересно узнать о нашем пути практического решения задачи распознавания счётчиков (более строгое название, как подсказали наши коллеги, — приборов учёта. Поэтому далее будут встречаться оба этих термина, но речь будет идти об одном и том же).
Для выявления ключевых слов, для начала будет решена задача кластеризации на тематики текстов с помощью метода LDA (Latent Dirichlet Allocation). После этого будет решаться задача, непосредственно, выявления ключевых словосочетаний с помощью предобученной модели Bert. И завершающим будет метод WordToVec, служащий для решения задачи поиска наиболее семантически похожих слов в тексте.
В этой статье: продакт овнер – это человек поживший.
Быстрое решение задач – это как никотин, вызывает привыкание. Продакт не равно эникейщик. Результаты беседы с PO Lead в логистической компании.
Последнее время, и, есть такое подозрение, что не последнее, а это перманентное состояние Хабра, много всяких публикаций на тему "Как я (мой друг\Лена\педиатр-офтальмолог\кошка моей жены) вошли в IT в 45 лет".
И неоднократно замечалось. что такие публикации есть типичная "ошибка выжившего" - потому что те, у кого ни хрена не получилось, ничего подобного не пишут.
Потому я попробую эту тему немножечко копнуть на своем примере и таки написать, почему Я НЕ ВОШЕЛ В IT. Хотя мысли посещают постоянно, регулярно, и все вокруг меня прямо в спину пихают. "Иди в IT", - говорят они. - "Там хорошо получают", - говорят они.
Но я, если честно, совсем не в восторге от этих перспектив. Впрочем, начнем с начала.
С развитием информационных технологий развивалась и сфера мошенничества в ИТ, вирусных и хакерских атак. Естественно, вырос спрос и на услуги Информационной Безопасности (ИБ). Он всегда был, но с повсеместной компьютеризацией он сильно увеличился. Ведь сейчас трудно представить современный мир без кучи различных гаджетов и компьютерной техники. Конечно, есть уголки мира, куда прогресс ещё не дошел в полной мере, но сейчас не о них.
В мае 2021 года вышел новый frontend-фреймворк Qwik. Его создал Misko Hevery, разработчик фреймворка Angular. Qwik сразу наделал шума: Misko обещал быстрый старт приложения и почти моментальную возможность интерактивного взаимодействия.
Спустя год после первого релиза разбираемся, облегчает ли Qwik работу, вместе с Игорем Кацубой, ведущим frontend-разработчиком в Tinkoff.
Обнаружение объектов — одна из подзадач компьютерного зрения для идентификации определенных объектов. Например, люди, здания, растений, дорожных знаков или транспортные средства на изображениях и видео.
Для создания таких моделей существует множество различных типов алгоритмов, таких, как Scale-invariant feature transform (SIFT), Detectron, RefineDet или You Only Look Once (YOLO). Их часто используют в самых разных отраслях, начиная с автономного вождения и охранных систем, заканчивая автоматизацией на производстве и распознаванием лиц.
Как и с любой моделью машинного обучения, всё начинается с создания обучающего набора данных. Сделать это можно разными способами: можно заказать разметку данных, а можно всё сделать самому.
Конечно, второй вариант займет намного больше времени и сил, но с помощью правильно подобранного ПО можно неплохо упростить задачу. Сейчас я подробно расскажут, как быстро создать обучающий датасет для задач детекции объектов YOLO с помощью Label Studio.
Российские разработчики задались вопросами о том, как увеличить пропускные способности железнодорожной магистрали без изменения инфраструктуры, сократить время восстановления графика движения поездов после непредвиденных инцидентов и помочь поездному диспетчеру спрогнозировать развитие событий в сложной обстановке.
