Python *

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

Организация - это важно. То же относится к ML-проектам. Из каких компонент он должен состоять? Как оформить проект, чтобы всего хватало и было удобно это масштабировать? Рассмотрим организацию по шаблону CookieCutter с примерами.

Вам интересно, какие индексы используются больше или меньше? Какие не используются вовсе? Какие таблицы и индексы самые большие? Очень легко создать такие диаграммы. Это и красиво, и полезно.

Конвейер данных (Data Pipeline) - это последовательность шагов для обработки данных. Если данные еще не присутствуют в платформе данных, они поступают в начале конвейера. Затем конвейер обрабатывает данные через ряд этапов, где выход каждого этапа становится входом следующего. Этот процесс продолжается до тех пор, пока конвейер не будет завершен. В некоторых случаях независимые этапы могут выполняться одновременно.

Как правило, устранение пропусков — обязательный этап  предварительной обработки временных рядов. Эта небольшая работа — попытка создания инструмента оперативного подбора модели для импутации (вменения) пропущенных последовательностей.

Научные и технические вычисления — неотъемлемая часть работы инженеров, аналитиков и специалистов по машинному обучению. В этой статье мы разберём, чем полезна библиотека SciPy, какие задачи она помогает решать и как дополняет возможности NumPy. Покажем на примерах, как работать с константами, кластеризацией и преобразованием сигналов.

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

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

Часто при разработке небходимо иметь на локальной машине сервер kafka с ssl аутентификацией.
Надеюсь эта статья поможет быстро поднять его и приступить к разработке.

Речь пойдет о новом механизме хранения и манипулирования данными в SimpleUI, который так тесно связан с UI-механизмами платформы что по сути является частью UI/UX. Это многогранный артефакт – это и «визуальная форма данных» (списки, поля ввода, поиск) и резидентное в памяти хранение и примитивное локальное хранение. В целом можно сказать, что «вы наполняете датасет данными, а платформа делает все остальное». Причем в результате выигрыш во всем – в скорости разработки, в прозрачности решения и производительности на любых объемах данных. Кроме того, это удобная работа со ссылочными объектами, что делаем Симпл более удобным для работы с данными внешних систем, а датасеты в свою очередь становятся основным механизмом хранения данных внешних систем (даже для онлайн-решений).

Mask R-CNN 3D – это расширение знаменитой модели Mask R-CNN для работы с трехмерными данными (объёмными изображениями или облаками точек). Классическая Mask R-CNN предназначена для instance segmentation (сегментации отдельных объектов) на 2D-изображениях и состоит из двух основных частей: (1) сети предложений областей (Region Proposal Network, RPN) и (2) головы (Head) с несколькими выходными ветвями для классификации, регрессии ограничивающих рамок и сегментации масок . В версии 3D эта же концепция перенесена в трехмерное пространство.

Входом модели Mask R-CNN 3D обычно является объёмный данных – например, медицинский 3D снимок (CT/MRI) размером (D×H×W) или облако точек, представляющее 3D-сцену. Backbone-сеть (обычно сверточная нейросеть типа ResNet) извлекает из входных данных многомасштабные признаки. В 3D версии backbone заменяет все 2D-операции (свертки, пулинг) на 3D-аналоги, позволяя обрабатывать объёмные данные напрямую. (Если 3D-данные заданы как облако точек, возможно предварительное преобразование, например, вокселизация пространства или проекция на несколько 2D-плоскостей – об этом подробнее в разделе 6.) Backbone формирует карты признаков – объёмные тензоры с пониженным разрешением, но содержащие высокоуровневую информацию о структуре объектов в сцене.

Далее вступает Region Proposal Network (RPN) – небольшая сеть, скользящая по картам признаков и генерирующая набор предположительных объектов (region proposals) в виде ограничивающих 3D-рамок (прямоугольных параллелепипедов в координатах исходного объёма). RPN использует заранее заданные «якоря» (anchor boxes) – шаблонные 3D-боксы разных размеров и соотношений сторон, размещенные по всей карте признаков . Для каждого такого anchor RPN предсказывает два значения: объектность (есть объект/фон) и смещение рамки (на сколько нужно подвинуть и масштабировать anchor, чтобы точнее охватить объект). После этого выбираются топ-N наиболее перспективных предложений с помощью non-maximum suppression (NMS) – подавления пересекающихся рамок с меньшей оценкой.

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

Работая с аналитикой, мы часто сталкиваемся с одной и той же проблемой: данные есть, но исследовать их неудобно.

Представим типичную ситуацию. Есть таблица с десятками колонок и миллионами строк. Нужно понять, почему изменился какой-то показатель — например, выручка или конверсия. Обычно это превращается в цепочку SQL-запросов: сначала агрегируем данные по стране, потом по городу, потом по конкретному сегменту пользователей и тд.

Если таких гипотез несколько, количество запросов быстро растёт с геометрической прогрессией. Каждый новый уровень детализации требует отдельного SQL.

В какой-то момент хочется просто кликнуть по графику и мгновенно увидеть более детальные данные. Без написания нового запроса.

Именно здесь на помощь приходят BI-инструменты. Один из самых популярных open-source инструментов для аналитики — Apache Superset.

Поиск работы в IT часто выглядит похожим образом: десятки откликов, постоянные собеседования, новые команды, разные проекты и условия.

На старте карьеры я довольно быстро столкнулся с проблемой, о которой сейчас регулярно слышу и от других специалистов.

Собеседований много, информация начинает смешиваться. По итогу в голове остаётся только одно — предложенная зарплата.

В результате решение об оффере принимается почти вслепую.

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

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

Поделюсь основными из них, надеюсь, что всем будет полезно 👇

Привет, Хабр. Компаниям часто приходится подписывать договоры и акты с клиентами. Полноценный ЭДО — это долго и дорого для простых задач, а сканы по почте и личные визиты — неудобны.

Закон № 63-ФЗ разрешает использовать простую электронную подпись (ПЭП). Это обычный код из СМС на телефон. Такой способ подтверждает согласие клиента и подходит для большинства гражданских договоров.

В статье расскажем, как собрать на Python сервис для подписания документов. Вы сможете встроить его в свои ИТ-процессы.

Проект PhotoMentor создавался как ИИ-ментор для фотографов. Механика простая: пользователь загружает снимок, а под капотом Gemini выступает в роли арт-директора — анализирует композицию, работу со светом, цветовую гармонию и выдает детальный фидбек с оценкой.

С главной проблемой Vision-моделей я столкнулся в первый же день закрытых тестов. Я скормил Gemini свой тестовый снимок: крупный портрет собаки, положившей морду на лапы.

Модель уверенно выдала:

Перед вами третья и последняя часть моей статьи про конференцию алготрейдеров в Москве. Часть 1 была про инфраструктуру, а часть 2 про практическое применение ИИ.

Третья часть будет о последствиях. Перед вами будут четыре доклада на одну тему:

* неэффективности,
* уязвимости,
* масштабирование систем.

А ещё в статье интересная торговая идея с дисбалансом внутри синтетического инструмента — целой корзины акций Мосбиржи.

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

Одна жалоба повторялась достаточно часто: «Когда что‑то падает, приходится обходить несколько серверов, смотреть логи по отдельности и пытаться сложить картину вручную. ELK/syslog решают, но ради пары сервисов это перебор.»

После этого я решил собрать небольшой прототип LogRanger — CLI‑утилиты, которая по SSH забирает логи с нескольких серверов и открывает их в lnav одной командой. Ниже коротко расскажу, какую проблему хочу закрыть и что именно делаю.

Пока IT-директор «Магнита» ищет способы сэкономить 200 млн рублей на серверах и обновляет техрадары, в их логистике ежегодно «сгорает» 2,5 миллиарда. Я пришел в комментарии к CIO с готовым алгоритмом, который пакует фуры со скоростью 500 000 объектов в секунду с учетом LIFO, развесовки и крена, но получил лишь игнор и минус в рейтинг. Что ж, переходим к публичному вызову: 168 часов против 2,5 миллиардов. Кто быстрее — математика или корпоративный TOGAF?

Как я заменил Excel-сводные на Telegram-бота и ускорил контроль потерь на складе

Я автоматизировал рутинный процесс, который постоянно отъедал время: сбор выгрузок, построение сводных в Excel, перенос результатов в Google Sheets и ручной контроль повторений. Теперь всё делается одной кнопкой в Telegram: бот берёт последний файл из папки на Яндекс.Диске, обрабатывает данные и выкладывает готовую витрину в Google Sheets. Отдельно он показывает товар, который начнёт списываться в ближайшие 24 часа — это стало не просто ускорением, а новым инструментом управления потерями.

Раз в несколько месяцев я вижу одни и те же обсуждения:
«Manual QA больше не нужны»,
«Рынок перегрет»,
«Всё автоматизируют и заменят».

Если коротко — нет, QA никуда не исчезает.
Но профессия действительно сильно меняется. И тем, кто работает в тестировании, важно понимать в какую сторону.

В этой статье расскажу. Что нужно делать, чтобы не остаться у мусорки без работы 👇