Разработка

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

2. При определении подхода к описанию API нужно учитывать факторы:

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

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

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

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

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

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

- Монорепозитории и мультирепозитории: куда идти и зачем в этом разбираться?

- Renovate, как инструмент управления зависимостями, или как получить еще одного бесплатного* разработчика в команде;

- Что такое централизованное и децентрализованное управление зависимостями?

- Проблемы разделения CI\CD процессов по разным репозиториям, устаревания CI-шаблонов и варианты решения этих проблем;

- Inner Source - панацея или помеха

Современные сервисы и особенно микро-сервисы требуют обширного мониторинга. Но дело в том, что кроме общих соображений и статей вроде 4 golden signals не так уж и много информации как и что мониторить. И каждый раз приходится эту проблему решать вновь.

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

Я не пытаюсь объять всё возможное, но если вы пишите back сервисы, используете rest, вебсокеты, event driven архитектуру и пока не успели обрасти мониторингом, то в этом докладе вы сможете найти много полезного.

Что отличает технически грамотного ПМ от обычного? Насколько глубоко менеджер должен погружаться в техническую сторону проекта и какие профиты это несет проекту? В докладе разберем:

— как и зачем прокачивать технический бэкграунд,

— какой минимум знаний нужен и куда за ними идти,

— как сделать разработчиков союзниками в этом процессе

— почему ПМ должен уметь читать код.

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

В докладе разберём, что представляет собой "качество" и как его можно контролировать. Стандарт ISO/IEC 25010 выступит ключевым в понимании аспектов качества продукта. Рассмотрим, как с помощью метрики Quality Score в сервисе Авито измеряется качество, а также представим конкретный пример оценки качества продукта, иллюстрирующий теоретические знания на практике.

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

Узнаем как операционная системы (ОС) грузит его и запускает. Как программа общается с ОС. И попробуем разобраться, из чего состоит ОС.

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

В докладе мы обсудим:

- Что такое компиляция

- Что такое линковка

- Поговорим про формат исполняемого файла на примере ELF

- Какой код бывает: позиционно зависимый и позиционно независимы (PIC)

- Релокации

- Модели памяти

- Как происходит загрузка нашего кода

- AOT, JIT и интерпретация, кто они такие

- Что такое виртуальная память

- Что такое процесс

- Что такое поток

- Как программа взаимодействует с ОС: syscall и библиотеки

- Что такое ОС и для чего нужна

- Что такое рантайм

- Что такое ядро ОС

- Монолитное ядро

- Микро-ядро

- Взглянем вскользь на устройство микро-ядра на примере KasperkyOS

- Что такие RTOS

- Что такой Гипервизор

- Unikernel

- Зачем заводу компьютерное зрение

- Типичное приложение

- Как мы готовим модели

- Где мы уже набили шишки и где планируем набивать дальше

Python, Golang, Ruby и PHP защищают вас от уязвимостей как могут. А фреймворки помогают сохранить данные и обезопасить как процесс разработки, так и последующую эксплуатацию. Но вот только игнорирование настроек безопасности как ЯП, так и фреймфорков создают проблемы и помогают атакующим. Давайте посмотрим на все это как атакующий? А еще поэксплуатируем выключенные защитные механизмы и забайпасим какую-нить самописную поделку для защиты от атакующих ;)

В своём выступлении расскажу о методологии и инструментах нагрузочного тестирования в СберМаркете:

- Сезонность спроса в eCommerce

- Зачем нужны нагрузочные тесты

- Процесс проведения нагрузочных тестов

- Прогнозирование нагрузки

- Тестирование в продакшне

- Автоматизация

- Платформенная инженерия

- Непрерывная верификация

- Наблюдаемость и измеряемость через эксперимент

Что такое backlog на самом деле

Как структурировать работу до backlog

Какие этапы важно не забыть

Зачем нужен Triage Tag

Что можно сделать в ближайшей перспективе

Практически все без исключения веб-приложения используют те или иные базы данных для хранения информации. По мере роста размера проекта, вопросы отказоустойчивости и масштабираемости встают перед разработчиками всё острее. Один из ключевых вопросов - использовать собственный сервер/кластер или прибегнуть к услугам облачных провайдеров. Мы с командой за 20 лет перепробовали различные варианты. И я готов поделиться своим опытом, ответить на, казалось бы простые вопросы, возникающие у тех, кто только начал идти по этому пути. Я расскажу какими облачными провадерами мы пользовались, как устроена архитектура их managed database сервисов и с какими проблемами мы сталкивались в процессе их эксплуатации, а так же причинах перехода на собственный отказоустойчивый кластер.

Разберем основные этапы разработки сервиса для автоматического распознавания и векторизации данных на спутниковых снимках, аэрофотоснимках, данных с БПЛА.

Описание:

1. Выбор архитектуры нейронной сети: изучим современные архитектуры сетей для семантической сегментации объектов на изображениях.

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

3. Обучение и тестирование модели: разберем стратегию обучения сети, настройку гиперпараметров.

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

5. Разработка серверной части: рассмотрим технические аспекты реализации модуля авторизации и обработки заявок от клиентов (PHP/C++), модуля распознавания (Python), брокера сообщений для асинхронного взаимодействие между компонентами.

6. Разработка клиентской части: рассмотрим технические аспекты реализации интерфейса пользователя (Qt), интеграции в ГИС, взаимодействия с сервером

7. Масштабирование системы и оптимизация производительности: уделим внимание подключению дополнительных серверов для распознавания, использованию ресурсов GPU

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

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

Необходима полностью автоматическая система внедрения микросервисов.

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

В докладе представлена архитектура такой системы внедрения с использованием популярных проектов ArgoCD, CrossPlane, AtlasGo и некоторого кол-ва расширений необходимых для полностью автоматического внедрения в микросервисных проектах

В большой компании где много команд, которые работаю над одним продуктом в монолите, надо выбирать единый путь.

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

Как мы это сделали, какой путь прошли, что выбрали, и какие выводы получили. Вот об этом и будет доклад.

Что затронем:

- Ликбез по ИИ

- Применение машинного обучения в реальных кейсах (помимо ChatGPT)

- Использование нейронных сетей для тестирования - как и где

- Перспективы развития инструментов искусственного интеллекта в области QA

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

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

Мы обсудим методы тестирования и применение эмуляторов для моделирования реальных условий эксплуатации.

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

В выступлении я на своём личном опыте председателя ТСЖ расскажу об общности и разности подходов, а также о том, чему может научиться DevOps или SRE в эксплуатации собственных систем из реального мира.

Что делать когда у вас есть разработчики (код), сисадмины (инфраструктура) и тестировщики, но нет тех кто наладит общение между этими тремя лагерями.

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

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

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

Все реляционные базы данных похожи друг на друга, каждая NoSQL база данных удивляет по-своему. Базы данных с широкими столбцами на первый взгляд кажутся очень близкими к реляционным. Даже в языке запросов той же CassandraDB для операторов используются названия из старого доброго SQL. Но такое впечатление обманчиво. Принципиально иной подход к организации хранилища обуславливает специфические решения типовых задач по работе с данными и специфические же проблемы. Однако, и возможности баз данных этого семейства для своей ниши тоже сложно переоценить. В своём докладе я расскажу о вопросах, которые нужно решать, если вы планируете использовать базы данных с широкими столбцами в своей системе. Поделюсь особенностями работы с наиболее быстрым представителем этого семейства – ScyllaDB, её преимуществами и недостатками, которые выяснились за три года промышленной эксплуатации в составе высоконагруженной системы обработки данных.

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

#команда #эффективность

1. В классической системной инженерии чрезвычайно мощным инструментом является иерархическое разбиение системы по отношению "часть-целое". Для материальных систем такое деление "естественно" за счет 3D-природы материала.

2. В программных системах нет такого "естественного" деления и в результате мы теряем мощнейшее средство организации мышления и управления сложностью.

3. Современные ООЯП по историческим причинам загоняют нас в программную "флатландию", не давая выразительных средств для качественного структурирования программных систем.

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

5. Все прежние меры, призванные преодолеть этот разрыв (тесты архитектуры, архитектура/диаграмма "как код", etc) не решают глубинную причину и поэтому паллиативны

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

Покажу пример такого эксперимента в виде DSL на Rust.