Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming»

Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂

Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.

Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).

Like/Share 🙂

12 октября в 18:00 присоединяйтесь к нашему бесплатному вебинару, посвященному OWASP Proactive Controls

Open Worldwide Application Security Project — это открытый всемирный проект по безопасности приложений

Мы расскажем вам о некоторых проектах, которые представлены в OWASP, и как они важны для безопасности ПО.

Узнаете, какие методы и практики безопасности рекомендуются в Proactive Controls и как они помогают защищать приложения от угроз и атак.

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

Обсудим следующие темы:
➖проекты OWASP, которые будут полезны аналитикам
➖ какие методы обеспечения безопасности описаны в Proactive Controls?
➖ с какими документами OWASP имеется связь в Proactive Controls?

Кому будет интересен вебинар:
✔️ специалистам по разработке
✔️системным аналитикам
✔️ менеджерам продуктов

Алексей Краснов
➖ Systems Analyst в команде Security Development финтех компании
➖ 10 лет в области информационной безопасности
➖ 8 лет в бизнес- и системном анализе

Запись встречи будет выложена на наш youtube канал в течение недели.

#безопасность #вебинар

Регистрируйтесь!

Посмотрите на этот график с основными факторами провалов IT-проектов.

На мой взгляд, это пример непонимания природы разработки.

Авторы статьи рекомендуют больше времени уделить оценке времени и сроков.

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

Скоуп изменился, людей не хватает, коммуникации не эффективные, пользователи не вовлечены, нехватка ресурсов…

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

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

При этом график остается полезным, и выводы можно сделать такие:
1. С высокой вероятностью скоуп изменится, учитывайте это в оценке и закладывайте практики по управлению скоупом
2. С высокой вероятностью людей не будет хватать, или будут пробелы в компетенциях, – учитывайте в риск-модели отсутствие ключевых компетенций на некоторый срок
3. Сразу формируйте план коммуникаций, учитывайте, что это только план и конкретные методы необходимо будет стабилизировать (как, с кем, как часто коммуницировать)
4. Если на момент старта проекта нет ресурсов (окружений, каких-то коробочных решений, например), закладывайте это в риск-модель, ресурсы не появляются волшебным образом
5. В начале проекта максимально часто пересматривайте риск модель и сверяйтесь с планом, фиксируйте отклонения, начало – период максимальной неопределенности

(источник графика: https://paper.ijcsns.org/07_book/201905/20190509.pdf)

@sergey486

В 19:00 Иван Волынкин (OneCell) расскажет как предоставить команде возможность работать на разных dev окружениях с разными ветками и всегда знать, где что задеплоено.

Подключайтесь по ссылке на эфир и задавайте вопросы спикеру: https://www.youtube.com/live/sViiClT1t-M?feature=shared

Ваня пилит классный и удобный open source инструмент: https://github.com/jonasasx/envrouter 🙂

В видео Ваня показал envrouter в действии, демка пока даже доступна публично https://demo.envrouter.ru (как я понял 1-2 дня будет доступна)

Кому интересно попробовать или поконтрибьютить, чат проекта:
https://t.iss.one/envrouter_ru

Мысль про приоритеты на подумать: «помимо приоритета есть еще срок, в рамках которого приоритет в принципе имеет смысл».

Еще мысль про приоритеты и критериальные оценки, а точнее – вопросы на подумать: «Были ли задачи, которые вы брали и срочно делали. Почему? По какому критерию? Значит этот критерий был важен. А до какого уровня он должен упасть, чтобы перестать быть важным?
Cвязан ли этот критерий с каким-то другим?»

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

UPD: появилась в продаже

https://bhv.ru/product/izuchaem-ddd-predmetno-orientirovannoe-proektirovanie/

Если заметите опечатки, пишите мне в личку (@sergey486), я все форвардну издательству. В следующем тираже все будет исправлено.

1. Как делать микросервисы единообразными, когда их много, а разрабы все разные? — Олег Козырев, Авито
У нас было несколько десятков микросервисов, и их число продолжало расти. Всё бы ничего, но когда один сервис написан так, как привыкли писать на PHP, другой вдохновлен Ruby, а третий и вовсе отдаёт плюсами, то становится жутко. С таким зоопарком подходов переключаться от сервиса к сервису очень сложно и трудозатратно, а главное, чревато большим количеством ошибок в разработке. Поговорим о проблеме и ее решении.

2. Paranoia driven development — Мясников Алексей, Яндекс
Как спроектировать контракты так, чтобы не допускать ошибок при их использовании. На нескольких примерах мы пройдем путь от ненадежных контрактов к надежным. На всех этапах дизайна кода будем исходить из того, что кодом будут пользоваться самые "одаренные" программисты.

3. Микросервисы в небольших командах разработки: почему вам нужен PaaS? — Алексей Коротин, Sports ru
Какие проблемы поможет решить PaaS? Архитектура компонентов и как организовать миграцию старых сервисов на новые рельсы.

4. Обработка ошибок в go в 2023 — Виталий Попов, InDrive
Доклад дает конкретный алгоритм выбора способа обработок ошибок в go для проекта. Плюс маленький обзор пакетов, существующих, для каждого из способов.

➖➖➖

🗓 8 ноября, начало в 19:00 мск, Среда

🌐 ОНЛАЙН

✅ Регистрация на мероприятие

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

https://podlodka.io/techcrew

Компания ScyllaDB проспонсировала открытую публикацию избранных глав из технического бестселлера Amazon Мартина Клепмана «Проектирование высоконагруженных приложений»:
https://lp.scylladb.com/designing-data-intensive-apps-book-offer

А мы перевели на русский язык 1-ю из этих избранных глав, посвящённую технологиям работы с данными, на которых построены современные СУБД и ответственные интернет-сервисы

Глава 3. Хранение и извлечение данных

Структуры данных, которые поддерживают вашу базу данных
- Хэш-индексы
- SST-таблицы и LSM-деревья
- B-деревья
- Сравнение B-деревьев и LSM-деревьев
- Другие индексные структуры данных

Транзакционная обработка или аналитика?
- Хранилище данных
- Звезды и Снежинки: схемы для аналитики
- Агрегация: Кубы данных и материализованные представления

Столбцово-ориентированное хранилище
- Сжатие столбцов
- Порядок сортировки в хранилище столбцов
- Запись в столбцово-ориентированное хранилище

https://systems.education/designing-data-intensive-applications

#книги #архитектура

Кто использует https://raml.org для API?
Поделитесь впечатлениями.