Привет, Хабр! Я — Дмитрий Селищев,  в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить SQL-запросы. Мы поговорим о стандартных конструкциях CASE и FILTER, которые позволяют писать более чистый код и, что важнее, на порядки сокращать время построения сложных отчетов. Давайте на живых примерах посмотрим, как это работает.

Статья о том, как мы пришли к ИИ для 1С и что из этого вышло. Материал получился про попытку собрать полноценную ИИ-платформу для работы с учетными данными. Расскажу, зачем нам понадобился MCP, как мы связали его с 1С:Шина, почему отдельно уперлись в права доступа и как в итоге устроили агента внутри 1С. Также покажу, где видим место для skills, RAG и OCR, и что пока не стали отдавать модели на самостоятельное выполнение.

Мы, devrel-ы, привыкли, что удивлять и креативить — это наша работа, поэтому к чужим приглашениям часто относимся со сдержанным профессиональным прищуром. Однако когда я получила пригласительное письмо на 20-й День рождения Хабра с темой «Дача 2.0», внутри что-то щёлкнуло раньше, чем я успела включить своего внутреннего скептика: я поняла, что точно не пропущу это событие.

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

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

Рассказываю о том, что делать со всем этим безобразием...

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

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

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

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

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

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

Так родилась идея поделиться накопившимися за 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 и поделюсь опытом его внедрения на крупном проекте. Этот материал будет полезен тем, кто интересуется гибкими методологиями и их применением в больших масштабах.

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

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