Переговоры начались стандартно: рукопожатия, слайды. Потом пошли возражения: «Зачем нам менять наш офис на ваш?», «Сможете пояснить нестыковки в документации?», «А чем докажете, что ваше решение лучше?» — и Рома «поплыл». 

Привет, Хабр. Меня зовут Вадим Бадиков, я специалист по анализу данных и я работаю в «Синимекс». Как вы возможно уже догадались по заголовку и небольшому спойлеру выше, я буду рассказывать что-то про продажи — точнее, про нашего ИИ-тренера по продажам. Берите поп-корн, наливайте кофе — поехали. 

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

Так родилась идея поделиться накопившимися за 10-летний стаж наблюдениями и плодами размышлений:

- Как стиль написания кода отражает образ мышления разработчика.

- Как разработчики воспринимают код программы.

- Почему один язык программирования, что называется, «заходит», а другой - нет.

Вопрос: что же такого прорывного добавили в архитектуру, чтобы она стала считаться чем-то новым с точки зрения инженеров, а не маркетологов?

Ответ: фундаментально изменилась парадигма хранения и обработки данных.

В отличие от традиционных подходов, где Data Warehouse оперировал исключительно структурированными данными в табличной форме, а Data Lake работал с файлами в их исходном виде, разработчики Lakehouse сумели соединить лучшие качества обеих архитектур.

Ключевым отличием стал формат OTF — Open Table Format, через который удалось реализовать единый стандарт доступа к данным и 4 технологически-культурных сдвига. Перечислю их: ...

В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.

Хочу рассказать о магии построения Dream Team: как у меня получилось это сделать на текущем проекте.

Это полезно, потому что я могу спокойно уходить в отпуск, где меня не дергают, не держать все время руку на пульсе (не проверять чаты и почту). А при выходе из отпуска могу спокойно встроиться обратно в работу и не тушить пожары, которые возникли во время моего отпуска (потому что они не возникают). Кайф, не правда ли?

Моя статья в какой-то мере универсальна — описанные инструменты подойдут для любой команды. Возможно, даже руководители проектов возьмут себе что-то на вооружение.

За 9 лет разработки ПО  я периодически выступал в  роли ментора и сталкивался с проблемой, которую недавно озвучил начинающий программист после онлайн-курсов: 

«Не понимаю, как делить код на классы».

Оказалось, на курсах учили языку, но не программированию. А ведь язык — лишь инструмент, и принципы проектирования кода универсальны для разных языков программирования.

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

Так и родилась идея написать эту статью.

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

Всем привет! Меня зовут Антон Баранов, я тимлид разработки в компании "Синимекс", недавно я завершил работу над двумя микросервисными проектами в сфере финтех, а до этого был техлидом и разработчиком на проектах, связанных с БЭК-офисами и витринами данных. Сейчас я актуализирую свой чек-лист и хочу поделиться с вами размышлениями о том, почему старт проекта — это одновременно и самое захватывающее, и самое рискованное время для тимлида.

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

Как часто оценка по задаче совпадает с реальными трудозатратами?

Умение точно оценить объём работ спасает от переработок, напряжённой обстановки на проекте, поддерживает доверительные отношения в команде и показывает вас с хорошей стороны перед заказчиком.

Но интуитивные и ставшие традиционными способы оценки задач дают низкую точность. Пора взять на вооружение другой способ, дающий 90+% точность в оценке.

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

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

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

Как пилить монолит на микрофронты, углубиться в суть синхронности и асинхронности, обсудить отсутствия документации и её влияния на накопление технического долга – все это в рамках System Analyst Meetup от ГК «Юзтех» и компании «Синимекс».

Так почему же Contract First оказался не так хорош на практике?

Это связано с тем, что в теории Contract First не учитывает необходимость постоянных доработок контракта и коммуникации между командами. Основная проблема кроется не в инструментах, а в процессах разработки API: если они выстроены плохо, коммуникация нарушается. Именно процессы — а не недостаток компетенций или инструментов — являются источником проблем.

Агенты в ИТ — это автономные программные сущности, способные к целеполаганию и взаимодействию. Рассказывать о них я буду по этой дорожной карте: 

1. Базовые концепции МАС: архитектурные принципы и классификация

2. Интеллектуальные vs автономные агенты: сравнительный анализ

3. Моделирование взаимодействий: от теории к практике

4. Эмерджентный интеллект — когда система становится "умнее" суммы своих частей

5. Перспективы технологии: от банковских систем до промышленной автоматизации.

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

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

Пространственное агрегирование помогает контролировать степень детализации данных в зависимости от пространственных характеристик отдельных записей. Эта операция может быть полезна, если вы хотите сравнить разные регионы по конкретному параметру, (например, плотность населения или динамика продаж), оценить значение признака на единицу площади (скажем, среднюю выручку магазинов на квадратный километр) или преобразовать набор точек в растровые пространственные данные.

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

Статья продолжает обсуждение пространственных признаков в Python. Здесь мы рассматриваем пространственные объединения — аналог обычного объединения в мире геоданных, основанный на топологических отношениях между объектами, таких как пересечение, вложение или касание. Также мы узнаем, как правильно рассчитывать различные типы расстояний (и иногда это не просто евклидово расстояние между двумя точками). Например, геодезическое расстояние учитывает кривизну Земли, что особенно важно для анализа данных на больших территориях; расстояние маршрута учитывает направление: оптимальный маршрут от A до B не всегда равен маршруту от B до A. 

Привет, я Александр Мещеряков, более 3-х лет работаю в компании «Синимекс» специалистом по анализу данных. Мне удалось поработать с различными ML-проектами, и больше всего меня увлекла работа с геоданными. Для многих эта тема кажется немного «магией» и я хотел бы на страницах Хабра пролить на нее немного света.

Эта статья — как шпаргалка для шеф-повара: берите готовые рецепты под ваши задачи. Здесь вы найдёте ключевые библиотеки (geopandas, h3-py) и принципы работы с геоданными — от парсинга OpenStreetMap до агрегации по шестиугольникам.

Все эти 10 лет задаюсь вопросом: «Почему в BI всего две профессии — BI Developer и BI Analyst, а в других data-областях — Data Science, Data Engineering, Data Analytics — их много, с разными названиями и набором обязанностей? Ждать ли новых BI профессий в будущем? Каких?»

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

Когда я впервые услышал о Data Warehouse (DWH), мне казалось, что это просто большая база данных. Однако, углубившись в тему, я понял, что настоящее хранилище данных должно отвечать множеству требований. Например, оно должно обеспечивать гетерогенность — возможность принимать данные из множества различных и несвязанных систем, что отличает его от классических реляционных или транзакционных баз данных. Оно должно обладать гибкостью и расширяемостью, позволяя добавлять новые источники данных без нарушения работы системы. Также важна историчность — способность хранить изменяющиеся атрибуты, такие как смена фамилии сотрудника. Хранилище должно быть способно обрабатывать огромные объемы данных и при этом обеспечивать высокую скорость обновления, позволяя создавать отчеты на основе актуальной информации.

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

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