Все потоки

Как принять 4 проекта в курирование и не свихнуться?

TL;DR

Руководитель дал 4 новых проекта в архитектурный надзор. Держать всё в голове нереально. Изучил индустриальные практики и подготовил процесс приёмки совместно с Claude Code. Выложил в open-source. Буду рад feedback от вас и ваших агентов.

Как всё началось

Руководитель: "Вот тебе 4 проекта - принимай в работу."

Я: "Окей... А что там?"

Руководитель: "Узнаешь."

Контест:

• 4 проекта

• Где-то есть пересечение функциональности (где именно - неясно)

• Команды разные, стек разный, зрелость разная

• Держать всё это в голове - бесмысленно

Немного поглядел - стало понятно: нужен системный подход.

Что я сделал

1. Изучил индустриальные практики

Посмотрел, как это делают:

• Futurice Project Handover Checklist

• TOGAF Architecture Review

• Harvard EA Checklist

• Практики из книг (Software Architecture in Practice, Building Evolutionary Architectures)

2. Собрал процесс приёмки и аудита

Готовил совместно с Claude Code. Не в чистом виде, конечно с моей конфигурацией (на текущий момент это 3882 строк rules, skills and commands). Безусловно, вычитывал и редактировал.

Что получилось:

Процесс приёмки проекта

6 фаз:

1. Инициация (получить вводную, доступы)

2. Kickoff встреча (PM + Tech Lead)

3. Сбор информации (документация, код, мониторинг)

4. Аудит (анализ архитектуры)

5. Решение о приёмке (принят/с оговорками/не принят)

6. Онбординг в надзор (регулярные встречи, точки контроля)

Файлы:

• project-handover-process.md - детальный процесс

• project-handover.md - чеклист (11 секций, 80+ пунктов)

Шаблоны аудита системы

Ручной аудит (12 разделов):

• Структура системы (C4, bounded contexts)

• Взаимодействие сервисов (sync/async, матрица зависимостей)

• Паттерны и антипаттерны

• Observability (метрики, логи, трейсинг, алерты)

• Устойчивость (SPOF, graceful degradation, DR)

• Безопасность

• План улучшений

Автоматическая валидация (215 метрик):

• Coupling и fan-out

• Layer violations

• God classes

• Топологические метрики

Файлы:

• system-audit.md - ручной аудит

• audit.md - отчет автоматической валидации

На следующей неделе начинаю приёмку. Посмотрим как процесс сработает в реальности.

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

Вопрос к сообществу

Буду рад feedback от вас и ваших агентов:

1. Процесс: Что лишнее? Чего не хватает?

2. Чеклисты: Какие критичные пункты я упустил?

3. Автоматизация: Используете ли инструменты для валидации архитектуры?

4. Агенты: Если вы используете AI-агентов для аудита - какие задачи им даёте? Как проверяете результаты?

Open-source шаблоны:

• Project Handover - процесс и чеклист приёмки

• System Audit - ручной и автоматический аудит

• Specifications - spec-driven development

• ADR - Architecture Decision Records

С удовольствием улучшу на основе вашего опыта.

UPD: Если интересно как процесс сработал на практике - подписывайтесь, расскажу после завершения приёмки.
Поддержать меня: https://t.me/MikeShogin

Навеяно сегодняшней статьёй «История: как Microsoft шесть раз отказывалась от виджетов, но потом возвращала их».

Понятно, что Майкрософт просто хочет содрать с бедолаги, купившего (тем более, скачавшего) винды, 33 шкуры. И поэтому делает как бы виджеты, но они все должны вести туда, куда хочет Майкрософт. В Copilot, MSN и тому подобные места. Но давайте помечтаем, что могла бы сделать Майкрософт, если бы по-настоящему хотела сделать своим юзерам удобно.

1. Виджет это приложение, точка Приложения бывают хорошие, годные и злые, вредные. Любое приложение может сломать ваш компьютер, украсть данные и деньги. Ответственность делится так: автор приложения прилагает все усилия, чтобы приложение не делало ничего плохого. Юзер прилагает все усилия, чтобы не ставить подозрительные приложения хрен пойми откуда. Если вам кажется, что это наивно, вспомните, что именно эта схема действует на PC прямо сейчас. На Github'е @dartraiden выложил драйвер (даже не простое приложение!), который позволяет использовать недорогие карты для майнинга вместо видеокарт (за 10-15% от цены последних) и написал: «Если вы мне не доверяете, вот инструкция, как собрать драйвер самому». Спасибо, но что-то не хочется )). Собирать драйвер самому. Я доверяю автору проекта! А ещё — авторам редактора Notepad++, браузера Firefox, файлового менеджера FAR (который почти в каждой сессии просит права админа, потому что я захожу им в системные папки) и многим другим авторам приложений.

2. Любое приложение может зарегистрировать себя в качестве виджета. Такая технология у Майкрософт уже есть, и называется ActiveX. Она до сих прекрасно работает (в день, когда сломается ActiveX, я перейду на Линукс, потому что только старые приложения меня под виндой и держат).

   Суть технологии в том, что у вас есть файл .dll, который регистрируется стандартной командой regsvr32 в той папке, где лежит (при переносе в другую папку его надо перерегистрировать). Чтобы не заставлять пользователя вручную выполнять эту команду, её обычно выполняет инсталлятор. (Или просто сам вызывает регистрирующую функцию из этой .dll — ходил анекдот про авторов инсталлятора, которые «сделали ядро в новой версии на X килобайт меньше, включив в него облегчённую версию regsvr32», потому что не знали азов программирования под Windows).

   Этот файл просто создаёт маленькое окошко (говоря техническим языком, window handle), может быть написан на C или Rust, занимать килобайты и работать со скоростью света.

   Всё, что вам нужно — дополнительно записывать при регистрации идентификатор своего ActiveX-компонента в ветку реестра с виджетами.

   Чтобы было проще создавать виджеты на HTML/CSS/JS, Майкрософт мог бы добавить новый тип проекта в Visual Studio: HTML Widget. Он брал бы файлы .html/.css/.js, метаданные и запаковывал бы в ActiveX-компонент вместе с WebView2 (браузерным окном). И ваш виджет отображался бы при помощи Chromium, как это делает приложение (не виджет) Steam, но весил бы, в отличие от Steam, ровно столько, сколько весят картинки и текст.

   Разумеется, ничто не мешало бы создать виджет на C#, Qt, Delphi, на базе своей версии Chromium (как это делает Steam), на базе Gecko, на базе чего угодно.

3. Будучи хозяйкой бала, Windows предлагала бы юзеру зарегистрированные виджеты перетаскивать из палитры виджетов в следующие места: а) рабочий стол, б) панель задач, в) меню «Пуск». Разумеется, любой виджет обязан был бы имплементировать помимо стандартных интерфейсов ActiveX-компонента специальный интерфейс IAmWidget и через него рассказывать о своих требованиях. Так что виджет, которому нужна минимальная площадь 512x512 пикселей, можно было бы создать только на рабочем столе.

4. В каждом из этих мест виджет вписывался бы в стандартную сетку (на рабочем столе такая используется для выравнивания ярлыков, на панели задач — это квадратик ярлыка или прямоугольник приложения). Поместить другие элементы (ярлыки) в занятое место было бы нельзя.

Клиентский путь и деньги: как CJM поможет удержать клиента и сохранить выручку в 2026

Приглашаем на вебинар, на котором эксперты департамента e-commerce «КОРУС Консалтинг» расскажут, почему в 2026 исследование клиентского пути с помощью методики CJM становится необходимым базовым шагом для удержания b2b-клиентов и сохранения выручки бизнеса.

🗓 Когда: 18 февраля, в 16:00 по Москве

💜В программе:
1️⃣ Контекст рынка. Почему удержание b2b-клиентов становится одним из ключевых факторов роста в 2026
2️⃣ Методика CJM в основе клиентской лояльности. Почему при одинаковых условиях клиенты выбирают разные компании;
3️⃣ Кейсы. Как CJM позволила оптовым компаниям увеличить NPS до 95%, захватывать рынки с низкой цифровой зрелостью, переводить до 99% клиентов на онлайн-самообслуживание, увеличивать средний чек и маржинальность.
🔥 А в конце встречи в прямом эфире эксперты проведут чекап b2b-продаж и клиентского опыта вашего бизнеса и помогут сделать первый шаг к изменениям.
💝 Вебинар будет полезен:

• Собственникам и руководителям оптовых и дистрибьюторских компаний
• Коммерческим, digital- и e-commerce-директорам
• Руководителям продаж и сервиса в b2b-компаниях
• Директорам по маркетингу и цифровой трансформации

➡️ ЗАРЕГИСТРИРОВАТЬСЯ

Как сломать языковой барьер в клиентском сервисе с помощью нейротехнологий?

Недавно мы в ЮMoney внедрили систему языкового перевода диалогов пользователей и службы поддержки. Она распознаёт 25 языков и автоматически работает как для запросов пользователей, так и для ответов поддержки. Пользователь пишет на родном языке — система мгновенно переводит сообщение на русский. Оператор отвечает на русском — пользователь сразу получает сообщение на родном языке.

Под капотом — довольно практичная архитектура. Язык определяется через FastText, обученный на реальных диалогах поддержки и 25 языках, с точностью около 99% и задержкой в миллисекунды. Перевод выполняют специализированные модели на базе NLLB с LoRA-адаптерами, дообученными именно на финтех-данных. Это позволяет корректно обрабатывать названия брендов, продуктов и финансовых терминов и не «ломать» смысл там, где универсальные модели часто ошибаются.

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

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

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

Рассказываем подробно об архитектуре машинного перевода в нашем блоге.

Что такое Portainer и зачем он нужен для управления Docker

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

Сегодня поговорим о Portainer — графическом интерфейсе для управления Docker, Kubernetes и Podman. В новой статье показали, какие задачи он решает, в каких сценариях действительно полезен и чем отличается от работы через командную строку. Отдельно разобрали ключевые возможности: управление контейнерами и образами, просмотр логов и статистики, работу с сетями и томами, запуск приложений через docker-compose и готовые шаблоны.

Пошаговая инструкция по установке Portainer через Docker-контейнер и подсказки, с каких разделов удобнее начать работу — в базе знаний Рег.облака.

Подборка бесплатных курсов для опытных и начинающих програмистов

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

• «Инженер облачных сервисов» — курс для специалистов с опытом, программа рассчитана на 70 часов или примерно месяц ежедневных занятий по 2 часа в день. Начните сейчас, а продолжить можно в своём темпе.

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

• «Подготовка к алгоритмическому собеседованию» — курс для специалистов с опытом. Для изучения теоретического материала понадобится 10 часов, время прохождения практики зависит от вашей подготовки. Знания из курса повысят ваши шансы на успешное прохождение собеседований. В курсе мы сфокусировались на том, что нужно для подготовки к интервью, а также поделились опытом разработчиков и подсветили много неочевидных моментов. А ещё собрали список материалов для самостоятельной подготовки.

• «Основы Go» — курс для тех, у кого есть опыт в программировании на других языках. Программа рассчитана на 30 часов или примерно 2 недели занятий по 2 часа в день. За это время вы научитесь читать и понимать код на Go, но чтобы создавать собственный код с нуля, уже придётся погрузиться в профессию глубже.

• «Основы Python-разработки» — обучение с нуля. За 20 часов поможем разобраться в бэкенд-разработке и начать писать код на Python — можно устроить марафон на выходных.

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

• «1С: программирование на русском» — обучение с нуля. Курс можно пройти за 45 минут: вечером после работы или на обеденном перерыве. Вы познакомитесь с одним из самых востребованных языков программирования, узнаете возможности 1C и примерите на себя роль 1С-разработчика. Если всё ещё думаете, что 1С — программа для бухгалтеров — это совсем не так.

→ Каталог бесплатных курсов

Дайджест обновлений VK HR Tek за январь

Всем привет! Рассказываем, что нового появилось в VK HR Tek — модульной платформе с готовыми кадровыми сервисами (КЭДО, график отпусков, ЛНА, командировки, авансовые отчеты, корпоративный портал, модуль прием на работу и другие). 

Главная страница

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

Часовые пояса

Добавили возможность использовать данные сотрудника из 1С для определения его часового пояса. Импорт данных о часовых поясах из 1С в КЭДО работает с адресами рабочих мест сотрудников.

Новые возможности согласования документов руководителями

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

Роли сотрудников

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

Ролевая модель

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

Больше обновлений, доступных пользователям VK HR Tek, можно изучить в Базе знаний.

Информация о возможностях платформы →

Почему шаблон коммерческого предложения и сметы — это плохо, особенно в услугах

Когда ко мне приходит новый проект, всё начинается не с формального КП или сметы, а с разговора и предварительного брифа. Я слушаю, задаю вопросы, уточняю, переспрашиваю. И в какой-то момент в голове начинает складываться картинка: что за бизнес, где он сейчас, куда хочет прийти и что вообще с ним делать.

И вот только после этого я сажусь писать коммерческое предложение и смету.

Если бы у меня был шаблон, всё было бы проще: поменял название компании, отправил. В ответ получил бы что-то из серии: «подумаем», «получили, спасибо».

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

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

Очень часто именно на этапе написания сметы появляются:

• более точные этапы работ,

• логика последовательности,

• идеи, которые потом напрямую попадают в проект.

То есть коммерческое предложение — это уже часть работы, а не формальность перед ней. Этим документом вы усиливаете первое впечатление (или ухудшаете). Клиент сразу видит ваши компетенции, понимает этапы и логику работы, видит ожидаемый результат. А вы получаете драфт плана работы, первичные идеи и гипотезы, по которым быстрее можно начать работу над проектом. Всем профит!

Открытый проект Go Katas поможет освоить язык программирования прямо Go. В репозитории решения есть сборник сотен ежедневных упражнений, чтобы довести навыки кодинга на Go до автоматизма, изучить конкурентность и Context, отработать Graceful Shutdown, а также защиту от утечек воркеров и правильный Fan-Out. Есть множество упражнений на Zero-Allocation парсинг, работу в sync.Pool и шардированные мапы.

В соцсетях рассказали, как выявить сайт, который продаёт и сливает персональные данные — достаточно при регистрации написать в строке «Отчество» его название.

Копипаста в Python редко выглядит как копипаста

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

Формально всё выглядит по-разному: другие имена, другие константы, чуть иной порядок.
Но архитектурно — это одно и то же решение, просто размноженное.

Я хочу рассказать про CodeClone — инструмент, который я написал для поиска именно такого дублирования. Он не сравнивает строки и токены, а работает на уровне **нормализованного Python AST и графов управления потоком (CFG).

Почему текстовые clone-detectors не работают

Большинство инструментов ищут дублирование через строки, токены или поверхностное сравнение AST. Это отлично ловит copy-paste, но почти бесполезно, когда код:

• переименован,

• отформатирован по-другому,

• слегка отрефакторен,

• но реализует один и тот же сценарий.

В реальных проектах это часто:

• одинаковые цепочки валидации,

• повторяющиеся request/handler пайплайны,

• скопированная оркестрационная логика,

• похожие try/except или match/case конструкции.

Идея: сравнивать структуру, а не текст

В CodeClone я пошёл другим путём:

1. Код парсится в Python AST.

2. AST нормализуется (имена, константы, аннотации убираются).

3. Для каждой функции строится Control Flow Graph.

4. Сравнивается структура CFG, а не исходный код.

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

Что именно ищется

Функциональные клоны (Type-2)

• Функции и методы с одинаковой структурой управления:

• if/else, циклы, try/except, with, match/case (Python 3.10+).

• Инструмент устойчив к переименованию, форматированию и type hints.

Блочные клоны (Type-3-lite)

• Повторяющиеся блоки внутри функций: guard-clauses, проверки, orchestration-фрагменты. Используется скользящее окно по CFG-нормализованным инструкциям с жёсткими фильтрами, чтобы снизить шум.

Почему инструмент намеренно консервативный

Один из принципов проекта:

Лучше пропустить клон, чем показать ложный.

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

Baseline и CI

В живых проектах дубликаты уже есть, поэтому CodeClone работает в baseline-режиме:

codeclone . --update-baseline

Baseline коммитится в репозиторий, а в CI используется:

codeclone . --fail-on-new

Существующие дубликаты допускаются, новые — запрещены.
Это работает как архитектурный регресс-чек.

Про Python-версии

AST в Python не полностью стабилен между версиями интерпретатора. Поэтому версия Python фиксируется в baseline и должна совпадать при проверке. Это сделано ради детерминизма и честности результатов.

Итог

CodeClone не заменяет линтеры или type-checkers. Он полезен, если проект живёт долго, код растёт, и хочется вовремя замечать архитектурное дублирование, а не разбираться с его последствиями позже.

Исходники

GitHub: https://github.com/orenlab/codeclone
PyPI: https://pypi.org/project/codeclone/

Прокачать ответы ChatGPT можно одним словом — лайфхаком поделились на Reddir. Пользователь начал писать на неудачные ответы чат-бота слово «средне» (mid), после чего ИИ начинает паниковать и переделывает задачу. Также подойдет слово «скучно», «кринж» и «говоришь как NPC» (boring, cringe, basic, npc). Вот вам и промпт-инженеринг.

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

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

А? Ничего не щелкает?

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

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

То есть с виду-то все выглядит очень безобидно. Но через пару месяцев смотришь на счет и не понимаешь, как он вообще таким стал. В общем, самонадутие в чистом виде. Только не мемное, а финансовое.

Тут-то и нужен FinOps. Только так можно понять, что реально работает, а что просто лежит мертвым грузом. И хорошо еще, если соответствующий инструментарий уже есть. А если нет? Для таких случаев есть FinOps Radar — бесплатный инструмент, который позволит экономить до 30%.

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

В общем, лучше разобраться сейчас, чем потом сидеть и думать, почему у вас все снова самонадулось.

Вот так новость – ребята из BotHub прикрутили к себе систему “Гарант”, ту самую, которая знает законы РФ вдоль и поперек еще с тех времен, когда интернет был роскошью.

И теперь можно просто рубануть одну галочку – и модель начнет черпать актуальные знания из законодательства прямо на лету. Ни один нюанс не ускользнет!

Как включить? Да элементарно:

• Ставим в правой панели галочку “Правовой поиск”;

• Выбираем модель, которая умеет запускать инструменты в процессе ответа (хоть ChatGPT 5.2, хоть ChatGPT 5 Mini – без разницы);

• Пишем вопрос, связанный с чем-то юридическим, и жмем Enter.

Всё! Система выдаст ответ и приложит текстовые файлы (.txt) с выдержками из законов.

Формат вопросов – как обычно, любой, можно своими словами. Вот, к примеру, что сразу пришло в голову:

• Какие изменения для айтишников вступили с 1 января 2026 года?

• По договору подряда: обязательные условия по ГК, риски заказчика, если нет акта приемки, и как защититься в контракте?

• Купил телефон, через две недели начал глючить – могу ли требовать деньги назад, а не ремонт?

• Пришел штраф с камеры, но за рулем был не я. Как оспорить и в какие сроки?

• Можно ли снимать видео в торговом центре, если охрана сопротивляется?

• Вернули товар без чека – законно ли это и чем можно заменить чек?

И самое приятное – модель не фантазирует, а цитирует и интерпретирует реальные законы через “Гарант”. Это же просто космос!

Можно задавать и сложные запросы, расписывать ситуацию в деталях, прикреплять документы – система разберется. Ответы будут понятны даже тем, кто в праве не шарит. Кстати, в интерфейсе есть слайдер “Максимальное количество поисков” – по умолчанию стоит 5, что дает 50 результатов (по 10 за запрос). Мелочь, а приятно.

⚹ ⚹ ⚹

Я, например, решил проверить на вечном вопросе: а можно ли вообще фотографировать что угодно в торговом центре?

И был поражен – оказалось, нюансов целая куча: люди в кадре или нет, видны ли лица, будешь ли публиковать… В ответе было штук 12 уточняющих пунктов! Выглядит убедительно и чертовски полезно.

П.С. Потыкать можно вот тут – дают бонус в 300 000 капсов на эксперименты:
https://bothub.chat/?invitedBy=m_aGCkuyTgqllHCK0dUc7.

12 февраля вебинар про ETL-платформу в облаке

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

Какие вопросы обсудим на вебинаре:

• как интегрировать данные из различных источников (базы данных, S3, API) в единую экосистему;

• как централизовать управление метаданными и схемами для согласованности и качества данных;

• как настроить SQL-запросы к разнородным источникам без переноса данных;

• как оценить экономию времени и ресурсов при переходе с self-hosted решений на управляемые сервисы.

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

📅 Когда? 12 февраля в 11:00 мск.

📍Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы экспертам в прямом эфире.

P.S. Если вы руководитель или инженер данных, BI-лидер или архитектор данных, то перед вебинаром предлагаем скачать чек-лик и проверить зрелость ваших ETL/ELT‑процессов. В итоге у вас будет готовый план оптимизации с применением cloud native подходов, который вы обсудите с нашим архитекторов, а на вебинаре увидите, как решение выглядит изнутри и сможете уточнить технические детали.

Развитые софт-скилы для аналитика — +1000 к долгосрочному профессиональному успеху, ведь с ними преуспевать в работе будет проще. Благо софты, как и харды, всегда можно прокачать. 

Поэтому делимся несколькими важными для аналитика софт-скилами и рассказываем о методах тренировки этих «мягких» навыков.

Стратегическое мышление, или, иначе, helicopter view

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

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

Фасилитация встреч

Суть навыка в умении вести переговоры и выстраивать коммуникацию так, чтобы находить компромисс между конфликтующими сторонами. 

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

Понимание потребностей и выявление требований

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

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

Самоорганизация

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

Как развивать: пробовать декомпозировать свои задачи и разбивать сложные процессы на управляемые шаги. А еще не стоит пренебрегать этапом планирования личной эффективности и личной работы. 

Коммуникация и обмен информацией

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

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

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

Хотел написать небольшой пост по причинам провалов проектов 1С. Но погрузился в тему, что люди пишут, и вижу, что получится неплохая статья. А пока собрал основные причины - мои, от ИИ и из Сети, и получил список. Дополняйте в комментариях. Потом в статье рассмотрю подробнее.

Сначала главные причины:

• Критичные изменения (смена руководства и т.д.)

• Отсутствие команды Заказчика, либо её невовлечённось, саботаж, отсутствие времени

• Неконтролируемая волна хотелок (НВХ)

• Неготовность к изменениям - внутренним и внешним

• Неправильный выбор подрядчика, чрезмерное доверие или недоверие.

Ещё причины, вытекающие из основных

• Непредоставление информации Заказчиком.

• Неправильный выбор продукта, разочарование в продукте, несовершенство и сложность продукта

• Отсутствие технического планирования (железо)

• Чрезмерно сжатые сроки

• Не хватает денег

• Неотлаженные бизнес-процессы

• Проблемы с данными

Также нашёл и такие "причины", о них в статье планирую специальный комментарий:
Внедрение без обследования
Отсутствие или изменение целей
Неправильно выбранная проектная методология
Незаинтересованность руководства Заказчика

Буду благодарен всем, пополнившим коллекцию.

Кожаным вход запрещён! Что будет дальше с Moltbook?

Разбирая новости и сам проект, анализирую куда всё повернётся. Поделюсь взглядом — он может не оправдаться, воспринимайте это как мой сон.

Обогатятся лишь соратники-основатели. У сервиса своя крипта — впереди байки о «удачливых спекулянтах», стартовавших из развалюхи в глухом городишке, а ныне облюбовавших клочок рая в Карибском море.

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

Занятнее — впереди. Конкуренты адаптируют концепцию, опубликовав «собственные» версии. Назвав инновационными разработками, но под капотом это лишь перелицованный клон.

Развязка — типичная для крипты: взлёт на ажиотаже («эх, зря не вложился раньше!»). Влиятельные фигуры продадут активы взятые на старте — и моментальный спад.

Биография Мэтта Шлихта спорная. Доступные данные напоминают кейс Элизабет Холмс: от триумфа к краху.

P.S. Поддержать можно подпиской на телегам канал "Инфобез", рассказываю просто про информационную безопасность.

Где и как прокачивать soft skills?

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

А чтобы становиться лучше было проще, мы на Хабр Карьере собрали курсы, которые помогут вам развить надпрофессиональные навыки без скучной теории и далеких от реальности примеров:

— Нейросети на практике. ИИ для рабочих задач и повышения личной эффективности.

— Деловые коммуникации. Переговоры, переписка и взаимодействие в команде.

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

— Тайм-менеджмент. Приоритизация задач и работа с нагрузкой без выгорания.

— Ораторское мастерство. Уверенные выступления и умение ясно доносить мысли.

→ Пришло время прокачивать софты

QUBO как демонстрация разницы между математиком и инженером

QUBO (Quadratic unconstrained binary optimization) это метод поиска оптимального решения. В основе метода формулирование задачи в виде матрицы Q. Решение задачи - бинарный вектор x. Упрощено метод решения можно представить так:

xT * Q * x -> min

Суть решения задачи - определить такой бинарный вектор, при котором "энергия" минимальна. Код, который напишет математик, будет выглядеть примерно так:

int[] x = new int[size];
//...
for (int i = 0; i < size; i++)
{
    for (int j = 0; j < size; j++)
    {
        // Вычисление значения целевой функции: x^T * Q * x
        energy += x[i] * Q[i, j] * x[j];
    }
}

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

BitVector32 x = new();
//...			
for (var row = 0; row < size; row++)
{
    for (var column = 0; column < size; column++)
    {
        if (x[row] && x[column])
        {
            energy += Q[row, column];
        }
    }
}

Пример крайне простой, а потому наглядный. Спросите у LLM :-) В общем, математика и программирование - это не одно и то же.