What Every Programmer Should Know about How CPUs Work • Matt Godbolt • GOTO 2024 (Рубрика #Engineering)

Посмотрел на неделе интересное выступление Мэтта Годболта, британского программиста, разработчика игр и бывшего сотрудника Google, наиболее известного как создатель популярного среди разработчиков инструмента Compiler Explorer. В этом выступлении Мэтт рассказывал о вещах, которые обязательно знать программистам о том, как работают CPUs (да, я знаю, что сейчас более модно рассказывать о том, как работают GPUs, но мы тут про базу, а не про хайп). Доклад проливает свет за 45 минут на следующие вещи

- Как выглядит архитектура современных процессоров в плане конвейерной обработки инструкций, что такое фронтэнд и бэкэнд в процессорах
- Как базово работает механизм branch prediction (предсказания ветвлений)
- Как процессоры разбирают инструкции и избегают конфликтов при работе с регистрами.
- Как достигается одновременное выполнение множества инструкций и почему это важно для производительности (тут про буфер переупорядочивания)
- Как процессор реагирует на ошибки (например, сегментации) и отменяет неверные вычисления.
- Как точность предсказания ветвлений напрямую влияет на скорость работы программ.
- Как сортировка данных и особенности кода влияют на эффективность исполнения (примеры на Python и C++)
- Почему деление — одна из самых медленных операций, как компиляторы и программисты могут это обойти (роль кэшей и памяти)
- Какие инструменты можно использовать для анализа производительности (Perf, Compiler Explorer, Cache Grind и другие)

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

#Engineering #Software #Architecture #Hardware

[3/3] Quality Metrics in Software Architecture (Рубрика #Architecture)

Заканчивая рассказ (1 и 2) про этот whitepaper поделюсь иллюстрациями из самой статьи

[2/3] Quality Metrics in Software Architecture (Рубрика #Architecture)

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

Для реализации своего фреймворка авторы взяли следующие инструменты
- Модель реализована с помощью доменно-специфического языка (Domain-Specific Language, DSL) на базе xText, что позволяет текстово описывать элементы качества и их связи.
- Для визуализации используется генератор кода (xTend), который строит интерактивные веб-интерфейсы: списки метрик и атрибутов, а также граф взаимосвязей между ними.
- Каталог поддерживает расширение и коллективную работу: любой участник может предложить новую метрику или атрибут через pull request, после чего данные автоматически попадают в визуализацию (правда, в репозитории не было pull requests за все время)

Если описывать подход авторов к исследованию, то он был достаточно строгим
- Они сформулировали исследовательские вопросы (RQ1–RQ4): какие метрики и атрибуты используются, являются ли они универсальными или специфичными, внутренними или внешними, и как их применять на практике.
- Они сформулировали поисковую стратегию: запросы по ключевым словам в пяти крупнейших научных базах (IEEExplore, ACM Digital Library, Scopus, Springer Link, ScienceDirect) за период 2011–2022 гг.
- Они отфильтровали найденные публикации по релевантности, языку, типу публикации и другим критериям, из 746 публикаций осталось всего 33
- Они проанализировали и классифицировали найденные метрики и атрибуты - для этого использовались характеристики из ISO/IEC 25010:2011, а потом они добавили классификацию по признакам generic/specific (универсальные/специфичные) и internal/external (внутренние/внешние)
- На основе этого они собрали модель и дальше использовали DSL для описания и генерации визуализаций

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

Авторы подчёркивают, что их каталог и фреймворк — это "живой" инструмент, который должен развиваться совместно с профессиональным сообществом. Основные направления будущих исследований и развития:
- Оценка и валидация с участием стейкхолдеров: планируется провести пользовательские исследования с архитекторами и экспертами для проверки удобства и полезности DSL и каталога.
- Комьюнити-драйв развитие: каталог открыт для внешних вкладов, его развитие зависит от активности сообщества инженеров и исследователей.
- Интеграция в практику: каталог может использоваться для:
-- Поиска и выявления новых или отсутствующих связей между метриками и атрибутами;
-- Поддержки инструментов автоматической оценки качества архитектуры;
-- Анализа влияния одних атрибутов качества на другие (impact traceability);
-- Построения переиспользуемых моделей качества и SaaS-решений, не зависящих от конкретного архитектурного языка.
- Расширение набора внешних метрик: большинство найденных метрик — внутренние, поэтому требуется разработка и внедрение большего количества внешних метрик, отражающих восприятие качества пользователями и заказчиками.
- Валидация связей между атрибутами: каталог помогает выявлять неожиданные или спорные связи между атрибутами качества, что может стать поводом для новых исследований и экспериментальных проверок

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

#Architecture #Metrics #Software #Engineering #SystemDesign #Management

Platform Engineering Night (Рубрика #Engineering)

Только что начиналась наша конференция Platform Engineering Night (трансляция доступна здесь). Конференцию открыл Игорь Маслов, наш VP of Coretech & Data.

Сама конференция про то, как платформы дружат с искусственным интеллектом! Эта дружба пройдет под знаком Productivity & AI, мы погрузимся в реальные кейсы, где AI не просто модное слово, а инструмент, который уже сегодня автоматизирует рутину, предсказывает сбои, масштабирует сервисы и повышает продуктивность команд. Только проверенные подходы, которые работают в проде — никаких теорий, только практика.

1) На сцену выйдут заслуженные джентельмены и лидеры индустрии: Игорь Маслов (Т-Банк), Евгений Колесников (Yandex Infrastructure), Денис Артюшин (Nestor, Т-Банк), Иван Юрченко (FineDog, Т-Банк) и другие. Они расскажут, как строить собственных AI-ассистентов, эволюционировать SRE и внедрять AI в инженерные платформы.
2) Помимо докладов будут демонстрационные зоны, где можно пообщаться с инженерами, потрогать платформы руками и узнать, как устроены LLM Platform, FineDog и другие решения для автоматизации и управления инцидентами.
3) Будет экспериментальный контент в виде кодинг-батла: AI против человека! Кто быстрее и качественнее решит задачу — разработчик или AI-ассистент? Сначала — битва, потом разбор полётов от экспертов. Голосуй за фаворита и участвуй в обсуждении: сможет ли искусственный интеллект заменить живой опыт и инженерное мышление?
4) Ну и конечно будет крутой нетворкинг, где можно будет обменяться опытом с практиками, найти единомышленников, обсудить острые вопросы и заводи новые профессиональные связи.

P.S.
Я присутствую на этой конференции, так что если кто-то уже у нас в гостях, то пишите, сможем поговорить очно:)

#PlatformEngineering #Architecture #Processes #Conference

JVM Day от Т-Банка (Рубрика #Software)

В конце лета пройдет очередная конференция про JVM технологии от Т-Банка. На конференции будут обсуждаться инженерные практики, сложные кейсы, нестандартные решения. В этом году будут три секции: Java, Scala и Backend. В текущий момент открыт прием заявок (call for papers), причем приветствуются следующие темы для каждой секции
- Java: инструментарий и тулинг, грядущие возможности Java и Kotlin, Java Enterprise, качество и организация кода, JVM, технологии в ретроспективе и истории факапов.
- Scala: новые фичи языка и их использование, подходы к разработке, инструменты, системы эффектов (Cats Effect, ZIO, Kyo), обзор и сравнение библиотек.
- Backend: опыт внедрения архитектурных подходов и практик, микросервисная архитектура, надежность и доступность, инфобез, инфраструктурные оптимизации, AI в разработке, устаревающие технологии и автоматизация тестирования.

Если у вас есть желание поделиться интересной историей, то не держите ее в себе и подавайте заявку на сайте конференции до 16 мая (по своему опыту члена программного комитета могу сказать, что если подаешь заявку раньше, то шанс получить одобрение выше)

#Software #Engineering #Architecture

[1/3] Quality Metrics in Software Architecture (Рубрика #Architecture)

Интересная обзорная статья про архитектуру софта, в которой авторы систематизировали и структурировали метрики (metrics) для оценки качества архитектуры (software architecture). Они сфокусировались на метриках, которые можно применять только к архитектурному описанию (architecture-only metrics), без необходимости анализа исходного кода или реализованной системы. В результате проведённого систематического обзора литературы (Systematic Literature Review, SLR) был создан каталог из 52 метрик и 41 атрибута качества (quality attributes), сгруппированных по 8 основным характеристикам качества (quality characteristics) согласно международному стандарту ISO/IEC 25010:2011. Для практического применения этот каталог реализован в виде модели и фреймворка, поддерживающего визуализацию и расширение набора метрик. Сам код доступен на Github, там же доступна визуализация самой модели с метриками, атрибутами и их кластеризацией как статической, так и динамической.

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

Если говорить про модель авторов, то из анализа литературы они собрали фреймворк, что включает следующие компонены
- ArchitecturalQualityModel - корневой элемент, объединяющий все остальные сущности модели.
- QualityElements - элементы качества, которые бывают трёх типов:
-- Metric - конкретная метрика для измерения качества архитектуры
-- QualityCharacteristic - глобальная характеристика качества (например, reliability, maintainability)
-- QualityAttribute — атрибут качества, связанный с одной из характеристик
- QualityRel — отношения между элементами качества, например, какая метрика измеряет какой атрибут
- ResearchContributions — ссылки на научные публикации, в которых определены или предложены элементы или связи.

Каталог организован по 8 характеристикам качества из ISO/IEC 25010:2011 (интересно, что в 2023 году вышло обновление этого стандарта)
- Функциональная пригодность
- Уровень производительности
- Совместимость
- Удобство использования (юзабилити)
- Надёжность
- Защищённость
- Сопровождаемость
- Переносимость (мобильность)
Для каждой характеристики выделены соответствующие атрибуты качества и связанные с ними метрики. Например, для Maintainability это Cohesion, Coupling, Complexity и др.

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

#Architecture #Metrics #Software #Engineering #SystemDesign #Management

Code of Leadership #37 - Interview with Borish Chernysh about frontend architecture and reliability (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Борис Черныш, с которым мы обсудили фронтовые архитектуры и вопросы обеспечения надежности клиентских приложений. Борис руководит направлением развития веб платформ в Т-Банке и занимает роль CRO (chief reliability engineer) в управлении разработки клиентских интерфейсов, где находятся наша платформа веба, мобилки и API.

За час мы успели обсудить следующие темы
- Знакомство с гостем, школьные и университетские годы, выбор профессии
- Начало карьеры: первая работа и фриланс
- Переходы между компаниями и опыт в Тинькофф
- Преодоление трудностей и рост до тимлида
- Развитие мониторинга, внедрение дежурств и выстраивание процессов
- Организационные изменения и создание SRE-команды
- Архитектурные изменения: микрофронтенды, Mobile First
- Роль Chief Reliability Officer, баланс между ролями инженера и технического менеджера
- Рекомендации по развитию: самообразование, книги, фундаментальные знания

Рекомендации Бориса для дополнительного изучения
1) Мышление и управление собой
- Левенчук Анатолий «Системное мышление», книга которая помогла Борису научиться превращать большие и сложные проблемы в несколько проблем поменьше и попроще, в дополнение к книге рекомендую сайт https://untools.co/ и редактор mind map - xmind;
- Максим Дорофеев «Джедайские техники». Это книга, которую Борис рекомендует прочитать не меньше трех раз и желательно с разбегом в пол-года год. Результат будет стоить потраченных усилий.
2) Инженерка
- Robert Hammer «Patterns for fault tolerant software», Борис прочитал ее чёрти когда в издании 2007 года, и скорее всего уже есть более актуальная замена, но для него это был просто трамплин в мир отказоустойчивости;
- Martin Kleppmann «Designing Data-Intensive Applications». Банально, но факт, эту книгу Борис рекомендует не только купить, но и прочитать всем инженерам, разработчикам, SRE, QA. Я как-то уже рассказывал об этой книге
3) Управление другими
- Алексей Пименов «Канбан. Базовая практика». По мнению Бориса, это очень понятно написанный и емкий гайд по тому что такое канбан и как им пользоваться, рекомендую всем как чтение на выходные. Я как-то уже рассказывал об этой книге
- Алексей Иванов, Света Шедина «Аутентичная коммуникация». Чем выше позиция, тем больше приходится обсуждать что-то и договариваться. Книга позволяет видеть паттерны во взаимодействии и переводить разговоры в конструктивное русло.

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

Precision и recall на пальцах (Рубрика #ML)

Буквально вчера мы разбирали whitepaper про подход ByteDance к code review (1, 2 и 3), где ребята отдавали предпочтения precision и жертвовали recall при проектировании своего решения. Precision (точность) и recall (полнота) - это две важные метрики для оценки качества моделей классификации, особенно когда классы распределены неравномерно или когда важно минимизировать определённые ошибки. Но что это значит на простом языке? Давайте обсудим.

Precision (точность) отвечает на вопрос: из всех объектов, которые модель определила как положительные, сколько действительно являются положительными?
Формула выглядит так
Precision = TP / (TP + FP), где
- TP (True Positive) — правильно определённые положительные объекты,
- FP (False Positive) — ошибочно определённые как положительные объекты
Проще всего объяснить на примере Васи, что сторожит овец и кричит "Волк", когда думает, что пришел волк. Precision показывает, как часто, когда Вася кричал "Волк!", волк действительно приходил. Если Вася часто путает собаку с волком и зря поднимает тревогу, precision будет низкой

Recall (полнота) отвечает на вопрос: из всех реально существующих положительных объектов, сколько модель нашла?
Формула для recall похожая, но не совсем
Recall = TP / (TP+FN), где
- FN (False Negative) — положительные объекты, которые модель пропустила
Продолжим пример Васи с овцами. Recall показывает, насколько Вася внимателен: из всех случаев, когда волк действительно приходил, сколько раз Вася это заметил и крикнул "Волк!"? Если Вася часто спит и пропускает волка, recall будет низкой

Обычно между этими метриками есть компромисс: если повысить одну, другая может снизиться. Например, если модель "перестраховывается" и помечает мало объектов как положительные (только когда уверена), precision будет высокой, а recall — низкой. Если помечает почти всё как положительное, recall будет высокой, а precision — низкой

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

В итоге, в случае с ассистентом в code review не выгодно слишком часто кричать "Волки", так как в этом случае инженеры просто перестанут обращать внимание на помощь code review ассистента:)

#ML #PopularScience #AI #Engineering #Software

[3/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

В последнем посте из серии (1 и 2) я приведу основные иллюстрации из статьи.

[2/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

Продолжаем рассмотрение интересного whitepaper о code review со второй части модели, а именно механизму data flywheel

Data flywheel — это системный подход к постоянному улучшению за счёт:
1. Annotation Feedback Integration: BitsAI-CR собирает и использует обратную связь пользователей для дообучения и улучшения датасетов.
2. Outdated Rate Measurement: введён новый метрик — Outdated Rate, который измеряет процент строк кода, изменённых после того, как BitsAI-CR их пометил. Это даёт объективную оценку того, насколько часто разработчики реально принимают предложения системы.
3. Dynamic Rule Adjustment: cистема постоянно корректирует правила review на основе точности и Outdated Rate, убирая те, что генерируют малоценные комментарии (низкий Outdated Rate при высокой точности).
Вместе эти компоненты создают цикл обратной связи, который шаг за шагом повышает качество code review на основе реального поведения разработчиков.

Авторы применили продвинутую стратегию обучения и оптимизации BitsAI-CR, включающую несколько ключевых элементов:
- В качестве базовой модели выбран Doubao-Pro-32K-0828 (собственная LLM ByteDance), что обусловлено требованиями безопасности и приватности данных. Размер последовательности выбран 8192 токена, так как 99% примеров review укладываются в этот лимит.
- Для дообучения RuleChecker и ReviewFilter использовалась техника LoRA (Low-Rank Adaptation)
- Также они учились на основе подробной таксономии правил code review, что дало
-- Структурированную основу для выявления и классификации проблем в коде
-- Системный сбор и разметку данных для обучения
-- Чёткие критерии для оценки качества системы
- Такой подход показал себя эффективным: BitsAI-CR, обученный на таксономии, достиг точности 57.03%, тогда как версия без таксономии (на случайных человеческих review) — лишь 16.83%.

Для оценки модели авторы новую метрику - Outdated Rate, измеряющий долю строк кода, изменённых после комментариев BitsAI-CR. Это позволяет:
1. Автоматически оценивать реальное влияние комментариев на практике
2. Понимать, насколько предложения системы действительно внедряются разработчиками
Такой подход закрывает недостатки традиционных метрик точности, которые требуют ручной разметки и не отражают реальную пользу для бизнеса.

При внедрении в production система показала впечатляющие технические результаты
1. Точность (Precision): Без таксономии и двухступенчатой архитектуры точность была около 25%. После внедрения этих элементов точность RuleChecker выросла с 27.9% до 62.6%, а ReviewFilter — с 35.6% до 75.0%. Это доказывает эффективность двухступенчатой архитектуры в снижении ложных срабатываний.
2. Outdated Rate: Для языка Go (основного в ByteDance) Outdated Rate вырос до 26.7% через 18 недель оптимизации. Для сравнения, у людей этот показатель колеблется между 35-46%. Постепенное приближение к человеческому уровню — свидетельство практической ценности BitsAI-CR.

Кроме того, BitsAI-CR быстро стал частью процесса разработки:
1. Аудитория: Более 12 000 Weekly Active Users (WAU), свыше 210 000 Weekly Page Views (WPV) — система интегрирована в рабочий процесс.
2. Retention: Retention на второй неделе — 61.64%, через восемь недель — около 48%. Это первый опубликованный бенчмарк retention для подобных инструментов code intelligence.
3. Оценка пользователей: В опросе (N=137) и интервью с экспертами (N=12) 74.5% (102/137) пользователей подтвердили пользу и эффективность BitsAI-CR.
Все эксперты отметили пользу BitsAI-CR, указав на пожелания по скорости, кастомизации и поддержке языков.

Авторы обозначили чёткие планы по развитию BitsAI-CR:
1) Расширение языковой поддержки до всех языков программирования, а не только пяти основных.
2) Улучшение контекстного понимания. Сейчас BitsAI-CR анализирует код на уровне функций с ограниченным контекстом. В планах — кросс-файловый анализ (cross-file review), чтобы находить проблемы, связанные с архитектурой и зависимостями между файлами.
3) Постоянное развитие и доработки системы

#Software #AI #Engineering #Process #DevEx

[3/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

В последнем посте из серии (1 и 2) я приведу основные иллюстрации из статьи.

[3/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

В последнем посте из серии (1 и 2) я приведу основные иллюстрации из статьи.

[1/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

Интересная научная статья от ByteDance, создателя TikTok на тему автоматизированного code review с использованием GenAI. Интересно, что чуть раньше я уже разбирал как Google подходит к этому вопросу при разборе "Resolving Code Review Comments with Machine Learning" в трех частях: 1, 2 и 3. Но у ребят из ByteDance немного другой подход - они сделали систему, в которой LLM пишет на MR (merge requests) комментарии в code review, а у ребят из Google сам комментарий писал инженер, а LLM делало code suggest, который предлагал фикс, что соответствует этому комментарию. Но давайте посмотрим какие проблемы авторы из ByteDance пытались решить, создавая BitsAI-CR:
- Избавиться от трудоемкого узкого места в виде традиционного code review
- Устранить ошибки и непоследовательности в комментариях при code review

Вообще, тема использования LLM для code review плодотворна, но там есть проблемки, которые авторы учли и попробовали устранить (кстати, в списке ссылок больше 50 других научных статей, десяток из которых про code review)
1. Низкая точность и надёжность: многие LLM-решения генерируют неточные или нерелевантные комментарии, тратя время разработчиков.
2. Недостаточная практичность: текущие системы часто не дают полезной обратной связи, которую реально используют разработчики.
3. Отсутствие механизма постоянного улучшения: большинство решений не учатся на обратной связи пользователей и не эволюционируют со временем.

Для решения этих проблем авторы придумали архитектуру из двух частей, что сочетает высокоточный pipeline генерации комментариев к review и механизм data flywheel. Такой подход не только выявляет потенциальные проблемы в коде с высокой точностью, но и запускает цикл постоянного улучшения на основе реальной обратной связи от разработчиков. Интересно, что для генерации комментариев используется таксономия правил code review, где есть категории security vulnerability, code defect, maintainability and readability, performance issue.

Давайте заглянем в то, как устроен каждый из двух компонентов модели

Review Comment Generation Pipeline
Pipeline работает в четыре последовательных этапа:
1. Context Preparation: на этом этапе входные изменения кода структурируются для дальнейшего анализа. Изменения разбиваются на сегменты по header hunks, добавляются полные определения функций - это даёт LLM достаточно контекста для качественного анализа.
2. RuleChecker: это дообученная LLM, обученная на широкой таксономии из 219 правил review. RuleChecker выявляет потенциальные проблемы в каждом сегменте кода, классифицируя ошибки по типам: уязвимости, проблемы производительности, нарушения стандартов кодирования и др. На выходе - первоначальные комментарии к review.
3. ReviewFilter: этот слой верификации - ключевой механизм контроля качества, который фильтрует ложные срабатывания и галлюцинации RuleChecker. ReviewFilter - тоже дообученная LLM, использующая три паттерна рассуждений: Direct Conclusion, Reasoning-First, Conclusion-First. После тестов наиболее эффективным оказался Conclusion-First - он лучше всего балансирует точность и производительность.
4. Comment Aggregation: на этом этапе схожие комментарии группируются с помощью cosine similarity, чтобы не перегружать разработчиков дублирующей обратной связью. В каждой группе сохраняется один представитель.

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

#Software #AI #Engineering #Process #DevEx

Exclusive: the most-cited papers of the twenty-first century (Рубрика #Science)

Интересная статья от Nature, в которой авторы попробовали подсчитать самые цитируемые статьи 21 века. Точно подсчитать было довольно сложно, так как существует целая пачка ресурсов, что считают цитирования по своему, но авторы взяли взвешенный подход. Кроме того, в области computer science и ML довольно часто авторы сначала публикуют препринты, а потом эти же статьи публикуются по итогам конференций, в итоге, часто ссылки на препринт версии не учитываются при расчетах цитируемости основной статьи.

Из интересного можно отметить, что в 25 лучших статей попало много ML статей, вот их список с занимаемыми ими местами
1. Deep Residual Learning for Image Recognition (ResNet), (2016), He, K., Zhang, X., Ren, S., & Sun, J.
Эта статья описывает архитектуру ResNet, которая описывает архитектуру нейросетей с примерно 150 слоями - примерно в 5 раз больше, чем было принято ранее. Эта архитектура позволила преодолеть проблему затухания сигнала при увеличении числа слоев, что стало прорывом для развития глубокого обучения и последующих достижений в ИИ, таких как AlphaGo, AlphaFold и ChatGPT.
6. Random forests ,(2001), Leo Breiman
Эта работа представляет алгоритм машинного обучения, который существенно улучшил предыдущие методы ансамблей деревьев решений. В этой работе описан новый способ построения ансамбля: множество независимых деревьев решений обучаются на случайных подвыборках данных и случайных подмножествах признаков, а итоговое решение принимается большинством голосов (для классификации) или усреднением (для регрессии)
7. Attention Is All You Need, (2017), Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, Illia Polosukhin
В этой статье исследователи из Google представили архитектуру Transformer, которая произвела революцию в обработке естественного языка и других последовательных данных. Главной инновацией стал отказ от рекуррентных нейронных сетей в пользу механизма self-attention (самовнимания), позволяющего модели определять важность каждого элемента последовательности относительно других и учитывать контекст на любом расстоянии.
8. ImageNet Classification with Deep Convolutional Neural Networks (2012), Alex Krizhevsky, Ilya Sutskever, Geoffrey E. Hinton
В этой статье описывалась архитектура AlexNet - глубокая сверточная нейронная сеть (CNN), которая совершила прорыв в компьютерном зрении, победив в конкурсе ILSVRC-2012 с ошибкой top-5 в 15.3% против 26.2% у ближайшего конкурента. AlexNet продемонстрировал, что глубокие CNN, обученные на больших данных, способны распознавать объекты с высокой точностью даже без ручной настройки признаков, заложив основы современного глубокого обучения
12. U-Net: Convolutional Networks for Biomedical Image Segmentation (2015), Olaf Ronneberger, Philipp Fischer, Thomas Brox
Эта статья представила революционную архитектуру для сегментации биомедицинских изображений, сочетающую кодирующий путь (свёрточные слои для извлечения признаков) и симметричный декодирующий путь (транспонированные свёртки для восстановления разрешения), соединённые skip-связями для сохранения пространственной информаци
16. Deep learning (2015), Yann LeCun, Yoshua Bengio, Geoffrey Hinton
Обзорная статья про глубокое обучение от корифеев этой темы
24. ImageNet: A large-scale hierarchical image database (2009), Jia Deng; Wei Dong; Richard Socher; Li-Jia Li; Kai Li; Li Fei-Fei
Статья описывает создание масштабной базы данных изображений ImageNet, организованной по иерархии WordNet. Цель проекта - собрать для большинства из 80 000 синсетов WordNet по 500–1000 полноразмерных и тщательно размеченных изображений, что обеспечивает десятки миллионов аннотированных примеров. Интересно, что в 8 статье AlexNet показывала свои топ-результаты как раз обучаясь на ImageNet.

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

#Science #ML #AI #Software #Engineering

Postgres против MySQL: что решает выбор базы данных | Петр Зайцев (Рубрика #Engineering)

Посмотрел интересное двухчасовое интервью Петра Зайцева, создателя компании Percona. Такое ощущение, что вернулся в начало карьеры, когда особо еще не было облаков и все хвастались тем, как они свой Mysql готовят к высоким нагрузукам:) Ну а если серьезно, то Кирилл Мокевнин, автор подкаста, и Петр Зайцев за 2 часа успели обсудить кучу тем, среди которых

1. Эволюция и история развития баз данных и компаний
Ребята вспоминали истории Percona, MySQL, PostgreSQL, MariaDB, а также влияние крупных игроков (Oracle, Sun) на рынок и развитие экосистемы баз данных.
2. Бизнес-модели и монетизация open-source
Обсудили особенности бизнес-моделей Percona, MySQL, вопросы монетизации open-source-проектов, проблемы коммерциализации и поддержка клиентов.
3. Технические отличия и сравнение MySQL и PostgreSQL
Базово сравненили архитектуры, производительности, типов данных, масштабируемости, соответствия стандартам SQL, особенностей работы с большими данными и сложными запросами.
4. Влияние облачных технологий
Обсудили роль облаков (Amazon, Google Cloud, Яндекс.Облако), опыт миграций, плюсы и минусы облачных решений, вопросы доверия и безопасности, влияние санкций и переход на европейские облака.
5. Миграция между СУБД и связанные сложности
Привели примеры перехода с Oracle на PostgreSQL, сложности миграции крупных проектов, зависимость от типа приложения, риски и опыт успешных/неудачных миграций.
6. Рынок, конкуренция и экосистема баз данных
Описали рост рынка, появление новых игроков (Redis, MongoDB, InfluxDB), конкуренция между решениями, роль форков и коммерческих версий, а также поддержка множества СУБД для удовлетворения разных потребностей.
7. Роль и влияние крупных компаний и специалистов
Поговорили про влияние Oracle, Amazon, Google на рынок, формирование профессиональной элиты, обучение специалистов, создание монополий и альтернативных решений.
8. Технические аспекты и особенности работы с СУБД
Поговорили про движки баз данных, вспомнили MyISAM, а также InnoDB, а также как на этом поднялась Percona Server. Поговорили про особенности работы с транзакциями, блокировками, индексами, поддержка расширенных типов данных и языков программирования.
9. Проблемы безопасности, управления и надежности
Вспомнили примеры сбоев, хакерских атак, важность резервного копирования, меры по обеспечению безопасности и управления данными в облаке и on-premise.
10. Будущее рынка и тенденции развития
Обсудили темы разнообразия баз данных, появление специализированных решений (Vector Search, Redis), влияние разработчиков и облаков на выбор технологий, перспективы развития PostgreSQL и других СУБД.

В общем, я выпуск посмотрел с удовольствием:)

#Database #Engineering #Architecture #Management #Software #Data

[2/2] 100 Principles of Game Design (100 принципов гейм-дизайна. Универсальные принципы разработки и решения проблем) (Рубрика #Design)

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

1. Циклы обратной связи
Регулярный анализ и корректировка игровых процессов позволяют поддерживать баланс и динамичность игрового опыта. Циклы обратной связи могут быть положительными (усиливающими определенное поведение) или отрицательными (сдерживающими). Правильно спроектированные циклы обратной связи помогают поддерживать напряжение в игре, предотвращая как слишком быстрое доминирование сильных игроков, так и безнадежное отставание слабых. Понимание этих механизмов критически важно для создания справедливой и увлекательной игровой динамики.
2. Основной геймплейный цикл
Повторяемость и структурированность базовых игровых этапов создают фундамент для устойчивости и вовлеченности игрока. Основной геймплейный цикл определяет ключевые действия, которые игрок выполняет снова и снова в процессе игры. Хорошо спроектированный цикл должен быть достаточно простым для быстрого освоения, но при этом глубоким для длительного интереса. Он служит основой всего игрового процесса, и его качество напрямую влияет на общее впечатление от игры.
3. Дизайн опыта
Данный принцип фокусируется на создании уникальных и запоминающихся эмоций через продуманные визуальные и звуковые эффекты. Вместо простого набора механик и правил, современный гейм-дизайн рассматривает игру как целостный опыт, который должен вызывать определенные эмоции и состояния у игрока. Этот подход требует интеграции всех аспектов игры – от сюжета и визуального стиля до звукового сопровождения и игровых механик – для создания цельного и эмоционально насыщенного игрового опыта.
4. Повествование через окружение
Использование окружающей среды для передачи сюжетной информации позволяет создать глубину и атмосферность без излишней экспозиции. Этот принцип предлагает альтернативный подход к повествованию, отличный от традиционных диалогов и катсцен. Через тщательно спроектированные игровые локации, детали интерьера, записки, аудиозаписи и другие элементы окружения игроки могут самостоятельно собирать фрагменты истории, что повышает их вовлеченность и поощряет исследование игрового мира.

А вот упоминаемые в книге источники, оказавшие влияние на формирование принципов современного гейм-дизайна
1. Книга "A Theory of Fun for Game Design»", Раф Костер, 2004 год - основополагающий труд, объясняющий природу удовольствия от игрового процесса через призму когнитивной психологии и нейробиологии.
2. Книга "Frames of Mind: The Theory of Multiple Intelligences", Говард Гарднер, 1983 год - теория множественного интеллекта, адаптированная для понимания разнообразия игровых предпочтений аудитории.
3. Статья "Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs", Ричард Бартл, 1996 год и книга "Designing Virtual Worlds", Ричард Бартл, 2003 год - классификация игроков по Бартлу
4. Доклад "Why We Play Games: 4 Keys to More Emotion", Николь Лаццаро, 2004 год - модель "4 Keys 2 Fun"
5. Книга "The Art of Game Design: A Book of Lenses", Джесси Шелл, 2008 год - работа, повлиявшая на методы анализа игровых механик.
6. Концепция "The Laws of Occult Game Design", Дэвид Говард - без отдельной публикации
7. Книга "Homo Ludens", Йохан Хёйзинга, 1938 год - философское исследование игры как культурного феномена

#Games #Design #Architecture #Economics #Engineering

Обложки книг "100 Principles of Game Design" и "100 принципов гейм-дизайна. Универсальные принципы разработки и решения проблем"

[1/2] 100 Principles of Game Design (100 принципов гейм-дизайна. Универсальные принципы разработки и решения проблем) (Рубрика #Design)

Эта книга 100 принципов геймдизайна вышла на английском в 2012 году, а была переведена в Бомборе в 2024. Она представляет собой калейдоскоп статей на важные темы из мира геймдизайна. Она написана 10+ авторами, а редактором выступила Венди Деспейн – опытный гейм-дизайнер и педагог. Книга представляет собой своего рода практическое руководство для разработчиков игр, объединяя в себе универсальные принципы. Я взал ее почитать из-за того, что мой старший сын учится на геймдизайнера, поэтому эта тема для меня интересна. Кроме того, геймдизайн мне напоминает проектирование и дизайн обычных цифровых продуктов, а это очень близко к моей рабочей деятельности.

Логическая организация изложения основана на делении материала на четыре основные части: «Инновация», «Создание», «Баланс» и «Решение проблем». Первая часть посвящена генерации идей и поиску нестандартных подходов, вторая – методам и инструментам проектирования, третья – обеспечению справедливости и равновесия в игровом процессе, а четвертая – практическим рекомендациям по устранению возникших трудностей. Такая структура позволяет систематизировать знания и применять их в реальных проектах. Правда, каждый из принципов описан букально на одной-двух страницах, за которыми часто стоят целые книги или научные работы, что упоминают авторы - это приводит к тому, что по настоящему разобраться в теме по этой книге не получится. Но зато вы узнаете или вспомните многие ключевые принципы дизайна и проектирования

Вот примеры важных принципов, о которых говорится в игре
1. A/Симметрия геймплея и синхронность
Данный принцип строится на гармоничном взаимодействии всех элементов игры, что обеспечивает равновесный и предсказуемый игровой процесс. Симметрия может проявляться в различных аспектах игры – от расположения игроков на карте до распределения ресурсов и возможностей. Синхронность же касается временных аспектов игрового процесса, определяя, действуют ли игроки одновременно или по очереди. Правильно спроектированное сочетание этих элементов создает ощущение справедливости и сбалансированности, что критически важно для поддержания интереса игроков.
2. Типы игроков по Бартлу
Понимание различных категорий игроков помогает адаптировать игровую механику под индивидуальные предпочтения и мотивы аудитории. Ричард Бартл предложил классификацию игроков, разделив их на основные типы в зависимости от их мотивации и стиля игры. Знание этой теории позволяет разработчикам создавать игры, которые будут интересны различным категориям игроков, предлагая разнообразный контент и механики, удовлетворяющие различные психологические потребности аудитории. Это особенно важно для многопользовательских игр с широкой целевой аудиторией.
3. Кооперация и противостояние
Принцип раскрывает баланс между коллективной работой и индивидуальной борьбой за лидирующие позиции, способствуя развитию как командного духа, так и здоровой конкуренции. Разработчики могут использовать различные механики для поощрения сотрудничества или конкуренции в зависимости от целей игры. Правильное сочетание этих элементов создает динамичный геймплей, где игроки могут выбирать стратегии в зависимости от ситуации, что увеличивает реиграбельность и вариативность игрового опыта.
4. Правило 80/20
Данный принцип акцентирует внимание на том, что основная ценность игры сосредоточена в небольшом числе ключевых элементов, что позволяет оптимизировать игровые ресурсы. Это правило, известное также как принцип Парето, применяется в гейм-дизайне для определения приоритетов разработки. Оно подразумевает, что 80% удовольствия игроков происходит от 20% контента игры. Понимание этого помогает разработчикам сконцентрироваться на наиболее значимых аспектах игры, оптимизируя время и ресурсы на разработку.

Прододжение обзора этой книги в следующем посте.

#Games #Design #Architecture #Economics #Engineering

Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #Architecture)

В мае я выступлю на конференции Positive Hack Days в Лужниках, где практикующий технический директор я расскажу:
- как оценить стоимость атрибутов качества и обосновать ее бизнесу через модель рисков;
- почему нельзя внедрить их позднее (объясню эмерджентные свойства систем);
- какие принципы создания надежных и безопасных систем применяют западные big-tech-компании;
- как внедрять эти принципы через паттерны проектирования и интеграцию в процессы разработки (shift left everything и secure by design).
Все это будет сопровождаться примерами из практики Т-Банка.

Приходите на конференцию послушать и пообщаться - там будет интересно:)

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

Вайб-кодинг: практика, о которой почему-то не говорят (Рубрика #AI)

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

В принципе, я почти ничего нового не узнал, так как про вайб-кодинг как раз активно говорят, несмотря на подзаголовок статьи. Но сама статья достаточно качественно написана, сопровождается примерами и ее просто и приятно читать. Кстати, про вайб-кодинг даже я уже несколько раз вспоминал
- Разбор обсуждения Y Combinator в выпуске "Vibe Coding Is The Future"
- Interview with Vibe Coder in 2025

#AI #Engineering #Software #ML

Platform Engineering Night (Рубрика #Engineering)

Уже через неделю, 23 апреля, в офисе Т-Банка пройдет конференция Platform Engineering Night, на которой мы посмотрим как платформы дружат с искусственным интеллектом! Эта дружба пройдет под знаком Productivity & AI, мы погрузимся в реальные кейсы, где AI не просто модное слово, а инструмент, который уже сегодня автоматизирует рутину, предсказывает сбои, масштабирует сервисы и повышает продуктивность команд. Только проверенные подходы, которые работают в проде — никаких теорий, только практика.

1) На сцену выйдут заслуженные джентельмены и лидеры индустрии: Игорь Маслов (Т-Банк), Евгений Колесников (Yandex Infrastructure), Денис Артюшин (Nestor, Т-Банк), Иван Юрченко (FineDog, Т-Банк) и другие. Они расскажут, как строить собственных AI-ассистентов, эволюционировать SRE и внедрять AI в инженерные платформы.
2) Помимо докладов будут демонстрационные зоны, где можно пообщаться с инженерами, потрогать платформы руками и узнать, как устроены LLM Platform, FineDog и другие решения для автоматизации и управления инцидентами.
3) Будет экспериментальный контент в виде кодинг-батла: AI против человека! Кто быстрее и качественнее решит задачу — разработчик или AI-ассистент? Сначала — битва, потом разбор полётов от экспертов. Голосуй за фаворита и участвуй в обсуждении: сможет ли искусственный интеллект заменить живой опыт и инженерное мышление?
4) Ну и конечно будет крутой нетворкинг, где можно будет обменяться опытом с практиками, найти единомышленников, обсудить острые вопросы и заводи новые профессиональные связи.

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

P.S.
На эту конференцию я смогу попасть и сам - повезло, что буду в Москве в этот день, так что если кто-то будет у нас в гостях, то пишите, сможем поговорить очно:)

#PlatformEngineering #Architecture #Processes #Conference

Обложка и описание глав книги "Глубокое обучение. Погружение в мир нейронных сетей"

Глубокое обучение. Погружение в мир нейронных сетей (Рубрика #AI)

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

Часть 1. Как обучать нейронные сети
Глава 1. От биологии к информатике, или We need to go deeper
Глава 2. Предварительные сведения, или Курс молодого бойца
Глава 3. Перцептрон, или Эмбрион мудрого компьютера
Часть 2. Основные архитектуры
Глава 4. Быстрее, глубже, сильнее, или Об оврагах, долинах и трамплинах
Глава 5. Сверточные нейронные сети и автокодировщики, или Не верь глазам своим
Глава 6. Рекуррентные нейронные сети, или Как правильно кусать себя за хвост
Часть 3. Новые архитектуры и применения
Глава 7. Как научить компьютер читать, или Математик - Мужчина + Женщина = ...
Глава 8. Современные архитектуры, или Как в споре рождается истина
Глава 9. Глубокое обучение с подкреплением, или Удивительно происшествие с чемпионом
Глава 10. Нейробаевские методы, или Прошлое и будущее машинного обучения

В общем, книга рассматривает примерно все, что происходило в глубоком обучении до 2018 года, включая, отсылки к работе мозга, теорвер и матстаты, градиентный спуск, сверточные и рекуррентные нейронные сети, распределенные представления слов (word2vec), модели с вниманием и encoder-decoder, глубокое обучение с подкреплением и нейробаесовские методы. Для чтения книги очень полезно быть подкованным в математике на уровне университетского курса - это поволит лучше улавлить магию, происходящую внутри моделей и понимать почему она так работает, а не просто фигачить код в Tensorflow или Keras.

P.S.
Я бы с удовольствием прочитал обновленное переиздание книги с разбором того, что случилось за последние 5+ лет, особенно, если бы авторы сохранили свою теоретико-практическую подачу и юмор.

#AI #Math #Software #ML #Humor

Code of Leadership #36 - Interview with Rodion Reshetov about Analytics and DnD (Рубрика #Management)

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

За час мы успели обсудить следующие темы
- Знакомство с гостем
- Образование и переезд в Москву
- Начало карьеры
- Старт работы в Тинькофф в колл-центре
- Переход в управление контроля качестом
- Переход в аналитики
- Оцифровка процессов и переход в их прогнозирование
- Работа в проекте Proteus (замена Tableau на базе Apache Superset)
- Продуктовые исследования и проект коллекций
- Настольное ролевое сообщество в Т-Банке
- Идея фестиваля настольных игр
- Развитие и приоритеты
- Заключение

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #ProductManagement #Management #Games

Фестиваль настольных ролевых игр в Т-Банке: Приключения за гранью кода (Рубрика #Culture)

Вчера пока я гулял по Пекину у нас в компании прошел первый фестиваль настольных ролевых игр (D&D), где можно прокачать не только свой профессиональный скилл, но и навыки импровизации, стратегического мышления и командной работы. Этот фестиваль - идеальное место для ИТ-специалистов, которые любят логические задачи, нестандартные решения и увлекательные истории. В программе мероприятия были
- Игры от опытных мастеров
- Мастер-классы, где можно было узнать как создавать собственных персонажей и миры
- Маркет НРИ-товаров, где можно было купить уникальные аксессуары для будущих приключений
- Презентации в формате "Печа-куча" - от тимбилдинга до игровых механик

Конкретно были представлены
- Дивный Новый Мир: Гостья - остросюжетное приключение с элементами детектива. В небольшой деревушке на окраине империи начали происходить странные дела: дети стали стариками, старики не помнят детства...
- Star Wars приключение - двойное солнце Татуина пробивается сквозь окна корабля. Вчерашняя попойка прошла на славу — контрабанда передана, кредстики пропиты.
- Легкая работка - сопровождение девушки до археологической группы, нашедшей нечто интересное. Звучит просто, но так ли это на самом деле?
- Лабиринтные Крысы - особняк старого лорда, набитый ловушками, монстрами и сокровищами. Цель одна — войдите никем и вернитесь баснословно богатыми, если вам хватит сил выжить...
- и другие

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

P.S.
Завтра выйдет выпуск подкаста "Code of Leadership", в котором я буду общаться с коллегой, который и организовал этот подкаст о том, как он больше 9 лет назад пришел в компанию, как менялась его роль, а также как он в свое свободное время организовал такой фестиваль. Stay tuned ...

#Games #Culture #Software

Шаолинь (Рубрика #Travel)

В детстве, когда я смотрел кино про мастеров боевых искусств из храма в лесу на горе Шао (так переводится Шаолинь), я и представить не мог, что посещу это место. Этот храм оставил значимый след в истории Китая и важен для самих китайцев, так как он знаменит давними традициями в буддизме, боевых искусствах и традиционной китайской медицине. Но зарубежная популярность к Шаолиню пришла после культового фильма 1982 года с Джетом Ли. Потом была целая пачка других фильмов, а потом появилась франшиза про кунг-фу Панду, который мало того, что смог постичь кунг-фу, но и напомнил лично мне китайскую версию Винни-Пуха. Ну а если серьезно, то прогулка по храму с экскурсией и дальше хайкинг по горам были очень интересны и позволили соприкоснуться с культурой Китая. В этот день я узнал, что
- Джеки Чан не мастер боевых единоборств, а трюкач и артист изначально, правда он некоторое время тренировался в Шаолине
- Брюс Ли вообще из Гонконга и практиковал Вин Чунь, а не шаолинское кунг-фу
- Кунг-фу Панду изначально запретили в Китае, а потом разрешили
- Черепашки ниндзя не только мультяшные, но и гастрономические персонажи (но мне они на вкус не зашли)

В общем, визит в это место мне понравился - это как Диснейленд для взрослых:)

#Culture #History #Travel

Метафорическое описание стратегии Huawei (Рубрика #Culture)

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

-----------

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

Исток
Река начинается как слияние десятков тысяч родников. Каждый родник — сотрудник-акционер, их взносы формируют общее течение. Более 80 000 сотрудников участвуют в этой системе, владея долями через профсоюз компании. Родник основателя (всего 1% собственности) направляет общее русло, избегая краткосрочных запросов акционеров.

Притоки инвестиций
Три главных притока сливаются в мощное течение реки Huawei:
1) Бурный поток НИОКР
В 2021 году Huawei инвестировала 142,7 млрд юаней в развитие технологий, что составило 22,4% от выручки. Этот приток питает инновации, включая более 3000 патентов 5G.
2) Канал денежного потока
Huawei балансирует между внутренними резервами и стратегическими финансами. Например, в 2020 году выпуск корпоративных облигаций вырос на 50%, а краткосрочные активы обеспечивали ликвидность при рыночных затруднениях.
3) Глобальная дельта
В Европе смартфоны Huawei увеличили продажи на 123% в 2021 году, достигнув доли 5% на многих локальных рынках. Каждый поток адаптирован к местным особенностям, будь то потребительские устройства или облачные решения.

Плотины стратегии
Стратегические дамбы помогают управлять течением:
- Дамба собственности: система, где сотрудники являются акционерами, позволяет компании фокусироваться на долгосрочном развитии.
- Резервуар инноваций: в нём заключены инвестиции в НИОКР, которые подпитывают облачные решения, ИИ, квантовые вычисления и умные устройства.
- Шлюзы партнёрства: Huawei Cloud входит в топ-5 мировых облачных провайдеров и активно строит глобальные партнёрства с предприятиями, операторами и правительствами.

Поймы экосистем Huawei
Осевшие наносы реки формируют три стратегических сегмента:
1) Пойма операторов
Здесь накапливается ил 5G, питая сеть телеком-инфраструктуры. Этот сегмент приносит 48,4% общей выручки компании.
2) Болота корпоративного сектора
Лабиринт облачных каналов и IoT-решений обеспечивает 14,6% выручки. Эти технологии помогают цифровой трансформации бизнесов и правительств.
3) Дельта потребителей
Смартфоны и умные устройства принесли 29,4% выручки, несмотря на международные санкции и сложные условия на рынке.

Рыночные сезоны
Река Huawei переживала как приливы, так и отливы:
1) Отлив 2019 года
Санкции осушили некоторые русла, особенно в международных цепочках поставок. Однако Huawei перешла к внутренним разработкам, например, HarmonyOS.
2) Паводок 2020 года
Инвестиции в облачные сервисы позволили Huawei Cloud выйти на 170 стран, создавая новые потоки сотрудничества.
3) Засуха санкций
Американские санкции стали серьёзной преградой для Huawei, особенно в сегменте потребительских устройств. Однако, компания сумела перенаправить поток своих усилий на внутренний рынок и разработку альтернативных технологий, таких как собственная HarmonyOS и независимые чипы.

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

Эта река, несущая технологии 5G, ИИ и облачные решения, остаётся одним из самых мощных потоков в мире, отражая силу управления и видение инноваций.

-----------

#Management #BusinessStory #Culture #Humor

On the Rise - From Dazhongli to HKRI Taikoo Hui (Рубрика #History)

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

P.S.
Мне понравился отель, в котором мы жили, это был "The Sukhothai" от этого застройщика HKRI - в нем обсулуживание на отличном уровне, а также он классно расположен и можно спокойно выйти и дойти пешком до ключевых туристических мест, навроде, Nanjing Road.

#Travel #Culture #History

Референсные визиты в компании и мысли о стратегии (Рубрика #Management)

За последнюю неделю я понял всю прелесть референсных визитов в другие компании. Такие экскурсии бывают разными - иногда тебе проводят экскурсии и рассказывают разные истории
- С фокусом на конкретном продукте
- Чисто маркетинговые
- Глобальные, где этапы развития компании пересекаются с цифровыми изменениями на уровне государства
- Стратегическими, где стратегия компании описывается как некоторый путь внутри своей отрасли

Из таких визитов я понял, что мне нравятся именно стратегические доклады, когда спикер может четко рассказать про
- Эволюцию компании и этапы, что она прошла по пути до текущего момента
- Текущую картину мира: Что делаем и зачем? Что не делаем и почему? Чем отличаемся от конкурентов и почему им сложно повторить бизнес-модель?
- Какие планы на будущее: Куда сфокусированы усилия? Почему ставка именно на них?
- Каким образом будут имплементироваться эти планы: Как в компании относятся к инновациям? Как проверяют гипотезы? Как выглядит оргструктура и разделение зон ответственности, между бизнес-вертикалями, продуктом и IT, cash cows и инвестиционными проектами?
Конечно, можно еще добавить кучу интересных тем для обсуждений, но как говорил Антуан де Сент Экзюпери
Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать
В итоге, если я слышу выступление, уложенное в такую рамку, то понимаю, что у компании есть стратегия и сотрудники понимают ее и могуть доступно объяснить. А это как мне думается и является ключом к успеху стратегии.

Отдельно отмечу, что референсные визиты позволяют
- Своими глазами увидеть происходящее в компании: в HQ, производственных помещениях (правда, покажут только публичную часть)
- Получить информацию из первых рук: в референсных визитах спикеру часто можно задавать дополнительные вопросы для уточнения деталий (правда, не на все из которых они отвечают)
- Провести сравнение: своей компании и той, в которую ты пришел с визитом (правда, тут надо быть осторожным и помнить про анекдот "Ну так и вы тоже говорите...")

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

#Management #Processes #Leadership #BusinessStory #Engineering #Software

MERA митап по бенчмаркам (Рубрика #AI)

15 апреля в 17.00 MERA и Альянс в сфере ИИ приглашают в офис Т-Банка на митап по бенчмаркам во всех их формах и проявлениях.

Хедлайнеры программы — сами авторы бенчмарка MERA, де-факто стандарта для автоматического тестирования русскоязычных LLM, и создатели российской LLM Arena, главной платформы для сравнения моделей в реальном времени. 

Организаторы митапа обещают поговорить о том:
- как устроены бенчмарки для текстовых и мультимодальных моделей;
- что учитывать при проверке LLM на качество написания кода;
как сравнивать друг с другом специализированные ML-модели.

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

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

ByteDance как фабрика приложений поверх платформы Volcano Engine (Рубрика #BusinessStory)

Раньше я уже рассказывал про фабрику внимания от ByteDance, что создали агрегатор новостей Toutiao, а потом сервис коротких видео Douyin, что на международном рынке стал называться TikTok. Но если поближе познакомиться с компанией из первых рук, то кажутся интересными следующие моменты
1) Залипательная рекомендательная система - про это говорят все, но не я не мог это упомянуть
2) Привлечение пользователей через предустановки на телефоны, когда это еще не было мейнстримом в Китае (стремительный рост в 2014 год зачастую был обусловлен этим)
3) Ориентация компании на фабрику приложений, когда вместо создания Super App типа Wechat от Tencent компания обкатывает новые идеи через создание отдельных приложений. Собственно, Douyin был одним из трех видео-приложений, что были запущены +/- одновременно. В это приложение верили меньше, чем в 2 предыдущих, но оно победило
4) Собственно в год делают порядка 10 новых приложений, но до запуска доходят единицы. В такие приложения налиывают трафик и дальше каждые полгода они проходят гейты, где надо продемонстрировать результаты. Если результатов нет, то приложение закрывают, часть сотрудников отправляют на улицу, а часть ротируют внутри компании. Если результаты хорошие, то добавляют ресурсов.
5) В итоге, компания захватывает внимание пользователей своими приложениями, а дальше монетизирует через рекламу и долю с продаж в e-comm. Кстати, у Douyin 766mln DAU в Китае, а если смотреть уникальных пользователей в Китае, то там будет все 900+ mln DAU и вот какие основные приложения у ребят (заметьте сколько приложений для создателей контента)
# Приложение DAU(M) Область применения
1 Douyin 766 Short Video Platform
2 Toutiao 254 News & Information
3 Xigua Video 178 Video Sharing
4 Hongguo - Micro-Dramas & Streaming
5 Huoshan Video - Short Video Platform
6 Ulike - Beauty Camera & Photo Editing
7 Hypic - Photo Editing
8 Doubao - AI Chatbot
9 CapCut - Video Editing Tool

6) Приложения BytaDance работают на своем публичном облаке Volcano Engine, что входит в группу компаний (облако было запущено в 2021 году). Чем-то это напоминает появление Tech компаний у крупных игроков (а вот мы у себя всю группу компаний назвали Т‑Технологии). Собственно, облако доступно публично, но максимальная уровень помощи и доработок доступна вертикалям, что отвечают за отдельные приложения - они имеют отдельный бюджет и отдельные IT-команды, но могут обращаться за помощью к ByteDance Tech Volcano Engine. Кстати, по ощущениям это облако скорее не публичное, а частично публичное - для компаний внутри группы и партнеров:)

7) Компания набирает лучшие инженерные кадры, выплачивая им зарплаты выше рынка - это позволяет поддерживать высокий уровень инженерной культуры и ориентации на результат (с учетом расформирования команд, закрывшихся приложений, а также частичных сокращений в них). В 2024 году в компании выручка была порядка 1.3 mln $ на сотрудника (146 bln $ / 110k сотрудников). Если ориентироваться на оценку количества инженеров в ByteDance в 12k WAU на основании статьи "BitsAI-CR: Automated Code Review via LLM in Practice", то получим, что на инженера выручка порядка 12 mln $. Вот что значит иметь фабрику приложений, аудиторию под миллиард пользователей, монетизироваться на рекламе и комиссии с продаж, а также использовать свою облачную плафторму и свой процессинг:) Оценка компании порядка $315 bln, если ориентироваться на недавню buyback программу.

#Management #Leadership #BusinessStory #Engineering #AI #Software

[3/3] Resolving Code Review Comments with Machine Learning (Рубрика #AI)

Заканчивая обзор (1 и 2) whitepaper от Google на тему code review, приведу красивые иллюстрации из статьи. На них видно как работает система, как ребята тюнили качество модели, а также приведены примеры сложных продуктовых кейсов, навроде, 3-way-merges, когда "author attempts to accept an ML-suggested edit in anincompatible code stat."

#Software #AI #Engineering #Process #DevEx