Разработка

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

В своем докладе на Стачке 2024 я предлагаю:

* окунуться во все разнообразие идей для тестирования

* отобрать наиболее актуальные и интересные решения

* предложить сборку мечты для тестирования на суд Python сообществу

Меня зовут Ирина, я — директор департамента аналитики в ITFB Group.

Свой департамент я вырастила из маленького отдела, состоящего из 8 человек. Сейчас в моей команде 91 сотрудник, и я не планирую останавливаться!

Хочу поделиться своим опытом и рассказать вам:

1. Как у нас выстроен карьерный трек от стажера до главного аналитика.

2. Как выглядит карьерная лестница.

3. Что важно на каждом из этапов роста.

4. На что делать акценты, когда строишь свою карьеру в IT.

5. А как быть, если ты уже специалист уровня middle+.

6. Обязательно ли расти в управленца или можно куда-то еще.

7. У всех ли получается стать менеджерами и надо ли это делать.

8. Почему круто, когда в компании выстроен карьерный трек и как это мотивирует сотрудников.

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

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

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

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

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

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

Мастер-класс проводит Филипп Дельгядо, архитектор компании lekton.io.

Статический анализ - очень полезная технология поиска ошибок в коде, имеющая на сегодняшний день множество возможностей.

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

Будет приведено много интересных примеров из нашей практики, как стат. анализатор:

- может быть внимательнее программистов;

- обучает людей;

- замечает нашу лень;

- может помочь оптимизировать код;

- экономит наше время.

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

1. Коротко об аутентификации
2. Децентрализованная авторизация
3. Централизованная авторизация с единой точкой принятия решений
4. Централизованная авторизация с встроенной точкой принятия решений
5. Авторизация скраю
6. Ещё немного об аутентификации
7. Примеры реализации ASP.NET Core WebApi, ASP.NET Core Blazor, классический frontend с React
8. Переиспользование токенов безопасности

С чего начать вход в проект;

Как проанализировать проект;

Как работать с метриками и их результатами;

Как улучшить проект.

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

Чем интересна данная тема для обсуждения? Это будет поверхностный обзор архитектуры событийных систем, с открытым для предложений окном.

Модный и популярный сейчас среди Go разработчиков протокол gRPC основан на Protobuf, который существует в нескольких версиях, сложность с Protobuf на Python в том, что Python 3 асинхронный лишь условно, а декодирование Protobuf блокирует другие операции системы так как по интерпретатор ограничен одним процессом.

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

Ручки сервиса будут просто проксировать приходящие Protobuf события так как они пришли в kafka, после чего отдельное приложение будет вычитывать сообщения и обрабатывать события.

1. Проблемы разработки типовых CRUD приложение на Spring Boot и Java: boilerplate, code duplication и прочее.

2. Проблемы разработки java-микросервисов в больших компаниях: разные подходы и уровни компетенций в Spring Framework.

3. Возможности быстрой разработки приложений на Java, обзор инструментов.

4. Обзор Jmix и его связи с Spring Boot

5. Пример разработки full stack веб-приложения на Jmix.

6. Выводы.

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

2. Про fastlane, xcodegen и немного за нюансы работы с файловой системой.

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

4. Про работу с иконками и лаунч скринами.

5. А также все про то, как одной кнопкой сделать сборку в Testflight (разберем до момента работы CI).

1. Поговорим про навигацию в Flutter.

2. Рассмотрим какие есть отличия и специфичные моменты под разные платформы.

3. Посмотрим что такое Router и зачем он нужен.

4. Рассмотрим существующие решения.

- Как компания AdvantShop доставляет обновления приложения множеству клиентов в автоматическом режиме.

- Автоматическое конфигурирование исходников из эталонной мастер ветки под каждого клиента

- Как настроить Fastlane для автоматической публикации в Google Play Market

- Как настроить Fastlane для автоматической публикации в App Store

Паттерн запуска задач по расписанию и области его применения.

Варианты реализации паттерна средствами JDK.

Quartz и его аналоги.

Запуск задач по расписанию в Spring Framework.

Внешние планировщики задач.

Ограничения в реализации.

Особенности тестирования.

Для больших компаний или больших проектов не всегда хватает одного модуля, иногда надо пошарить какие-нибудь классы, UI-элементы, иногда дело доходит до функционала. На помощь тут приходит деление проекта на модули, но как это сделать? Как будет правильно? Как не навредить себе и другим разработчикам?

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

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

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

В российских IT-компаниях термин SRE стал модным синонимом эксплуатации.

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

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

ITIL имеет намного большую сферу приложения, чем SRE, но следующие части ITIL пересекаются с SRE:

* Управление доступностью

* Управление производительностью

* Контроль за изменениями

* Управление инцидентами

* Мониторинг и реакция на события

* Управление проблемами

* Управление релизами

* Управление конфигурацией

* Управление непрерывностью

* Процессы поддержки

* Менеджмент SLA

* Менеджмент заявок

* Управление валидацией и тестированием

* Управление развёртыванием

* Управление инфраструктурой и платформами

* Управление разработкой

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

На фоне ITIL SRE превращается в "мы не объясним как вам наладить эксплуатацию, но вы должны быть инженером и писать код". Фундаментальные вещи в SRE: риски, SLO/SLI, мониторинг - это база в ITIL, которую в ITIL уже снабдили подробной инструкцией по внедрению.

Место SRE - в треугольнике с ITIL и DevOps. С одной стороны SRE не предлагает принципиально новых процессов эксплуатации, а с другой предлагает конкретную реализацию принципов CALMS из философии DevOps.

Доклад-кейс как благодаря изменению процессов и структуры бизнес линии можно значительно ускорить Lead time в ит командах.

Вы используете Hibernate? Какую модель предпочитаете: анемичную или богатую? Если вы рассматриваете ваши сущности как DTO с getters/setters, то вы сторонник анемичной. Я хочу показать вам альтернативный вариант - богатую доменную модель. Какие есть плюсы и минусы у данного решения

1. Проблематика возникновения ошибок
2. Сколько стоит исправление ошибок на разных этапах разработки (чем раньше тем проще и дешевле)
3. Способы анализа кода, какой выбрать?
4. Код-ревью и статический анализ, в чем разница
5. Статический анализ: особенности, преимущества и недостатки
6. Польза наглядно – примеры обнаруженных ошибок в реальных проектах
7. SAST - безопасность и защищенность (SAST, SSDL, безопасная разработка и Shift left)
8. Уязвимости: CWE & CVE
9. Примеры поиска уязвимостей с помощью SAST
10. Безопасная разработка: Shift Left & SSDL
11. Как использования статического анализа поможет разработчику на практике?
12. Как подобрать инструмент и где можно использовать
13. Советы по эффективной интеграции

Я - автор библиотеки / CLI-инструмента INSTLD (https://github.com/pomponchik/instld). Он под завязку набит питонячьей магией, в частности переопределяет машинерию импортов, парсит исходные коды программ и так далее. На конференции я расскажу самые интересные подробности внутрянки, например:

- Как сделать так, чтобы при выполнении инструкции import вызывался ваш собственный код?

- Как реализовывать метаязыки на базе комментариев? Как для этого научиться прочитать комментарий из кодовой базы в рантайме и парсить его.

- Как обеспечить временную установку пакетов во временную директорию?

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

• Архитектура и как она помогает спасти проект в будущем
• MVC паттерн и как он дружит с GetX
• А как насчет BLoC
• Плюсы и минусы GetX и BLoC
• Что же выбрать?

1) Что делает сервис ЕТА

2) Как производится расчет интервалов доставки внутри сервиса

3) Архитектура и стэк сервиса

4) Что сделали для улучшения модели

5) Какие фичи не зашли

6) Планы по улучшению

Тезисы доклада «Современные ГИС или облачные технологии и low-code решения пространственном анализе больших данных»

1. Роль облачных технологий: Обсуждение важности облачных решений в анализе больших геоданных и пространственном анализе.

2. Примеры использования: Презентация практических случаев применения геоаналитики и машинного обучения в различных отраслях.

3. Инструменты и технологии облачных вычислений для обработки и анализа геоданных.

4. Подходы к интеграции и хранению геопространственных данных в облаке.

5. Преимущества пространственных индексов: Значение использования пространственных индексов для повышения производительности и скорости обработки запросов.

6. Визуализация данных: Технологии визуализации и анализа пространственных данных.

7. Демократизация: Low-code и No-code workflows для пространственного анализа

Макросы Swift были представлены на WWDC 2023 и представляют собой инструмент кодогенерации для Swift. С их помощью можно упрощать и ускорять разработку приложений. Например, создание экранов и элементов SwiftUI. В своем докладе расскажу и покажу