Второй по счету WAW — Зимний аналитический уикенд — прошел. Я, честно говоря, очень переживал — такую высокую планку с точки зрения атмосферы и нетворкинга задал первый WAW. Когда в любое время проходишь по лобби отеля, и видишь, что везде тут и там сидят группками люди и общаются — это кайф! 💖 То есть, в основном же все на докладах и мастер-классах, но всегда кто-то активно тусит в кулуарах — огонь! 🔥 Кажется, это то, чего хотят все организаторы всех конференций.
Опытные люди говорили мне после первого WAW — ну, это эффект новой конференции, первый раз обычно всегда хорошо проходит, а вы попробуйте повторить. Поэтому в этом году я особенно волновался — удастся ли нам повторить успех прошлого года? В первую очередь — сохранить эту атмосферу и вайб? Ну и набрать доклады с мастер-классами — достаточно глубокие, чтобы было интересно, и достаточно практические, чтобы можно было брать и делать? При том, что конференций по системному анализу становится всё больше, а вот спикеров сильно больше не становится.
И, знаете что? Кажется, всё получилось!😻 Так же до ночи сидели люди, что-то обсуждая, так же исписали весь флипчарт, установленный в фойе, так же тусили между и параллельно с докладами, перемешивались за обедом, танцевали на афтепати.
Ну и отзывы. Отзывы всегда приятно читать — значит, все нервы и споры в ПК, все горящие дедлайны и общение со спикерами (не всегда простое) — всё было не зря!
Теперь нужно в третий раз затащить, и это будет уже точно не случайность, а закономерность!
Опытные люди говорили мне после первого WAW — ну, это эффект новой конференции, первый раз обычно всегда хорошо проходит, а вы попробуйте повторить. Поэтому в этом году я особенно волновался — удастся ли нам повторить успех прошлого года? В первую очередь — сохранить эту атмосферу и вайб? Ну и набрать доклады с мастер-классами — достаточно глубокие, чтобы было интересно, и достаточно практические, чтобы можно было брать и делать? При том, что конференций по системному анализу становится всё больше, а вот спикеров сильно больше не становится.
И, знаете что? Кажется, всё получилось!
Ну и отзывы. Отзывы всегда приятно читать — значит, все нервы и споры в ПК, все горящие дедлайны и общение со спикерами (не всегда простое) — всё было не зря!
Теперь нужно в третий раз затащить, и это будет уже точно не случайность, а закономерность!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥13👍2👏1
На WAW был очень жаркий круглый стол, "Стандарты в процессах разработки в эпоху ИИ".
Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)
Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.
Джоел обращает внимание, что почти вся литература по организации разработки и системному анализу написана людьми из внутренней разработки — потому что только в этой области компании могут привлекать консультантов и экспертов, которые в основном и пишут книги.
Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.
Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.
С другой стороны, какие-то внутренние вещи для удобства вообще не имеют большого значения. Автоматизируем мы какой-то процесс в этом месяце или в следующем — в принципе, большой разницы нет. Даже год не всегда важен. Именно отсюда все данные про проекты с превышением сроков и бюджета, как будто это что-то плохое. И умные книги — как за долю времени на анализ улучшить прогноз времени на выполнение.
А вот в продуктах — за что топили другие участники дискуссии, и я в том числе — важно число экспериментов и, соответственно, TTM — время до предъявления фичи рынку. И вот тут аналитики вообще не нужны — нужна хорошо построенная архитектура и инфраструктура, которая позволяет быстро делать фичи без глубокой проработки, выкатывать на часть аудитории и смотреть на реакцию. Потом быстро обратно откатывать, если не пошло, ну или развивать дальше, если угадали. Всё, что замедляет релиз — убирать из процесса. Аналитиков в первую очередь. По последним веяниям тут даже продакт-оунеры лишние — в больших продуктовых компаниях команды без них работают.
И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.
Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.
Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?
Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)
Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.
Джоел обращает внимание, что почти вся литература по организации разработки и системному анализу написана людьми из внутренней разработки — потому что только в этой области компании могут привлекать консультантов и экспертов, которые в основном и пишут книги.
Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.
Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.
С другой стороны, какие-то внутренние вещи для удобства вообще не имеют большого значения. Автоматизируем мы какой-то процесс в этом месяце или в следующем — в принципе, большой разницы нет. Даже год не всегда важен. Именно отсюда все данные про проекты с превышением сроков и бюджета, как будто это что-то плохое. И умные книги — как за долю времени на анализ улучшить прогноз времени на выполнение.
А вот в продуктах — за что топили другие участники дискуссии, и я в том числе — важно число экспериментов и, соответственно, TTM — время до предъявления фичи рынку. И вот тут аналитики вообще не нужны — нужна хорошо построенная архитектура и инфраструктура, которая позволяет быстро делать фичи без глубокой проработки, выкатывать на часть аудитории и смотреть на реакцию. Потом быстро обратно откатывать, если не пошло, ну или развивать дальше, если угадали. Всё, что замедляет релиз — убирать из процесса. Аналитиков в первую очередь. По последним веяниям тут даже продакт-оунеры лишние — в больших продуктовых компаниях команды без них работают.
И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.
Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.
Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?
🔥15❤9👍8🤔3🤯1
Вообще, когда начинаешь разбираться с сутью разговоров про стандартизацию процессов, часто выясняется, что всё дело в угадывании сроков. Только в этом, в основном.
То есть, риторика такая: команда всё время даёт неправильные оценки сроков, причем всегда в меньшую сторону. Для заказной разработки это выливается в недооценку стоимости проекта, потому что они продают не результат для клиента, а стоимость разработки ПО. Для внутренней разработки — потому что попадание в озвученные сроки оценить удобнее, чем поставленную ценность — срабатывает эвристика доступности, ментальное искажение "замена атрибута".
В любом случае, задача оценки сроков мучительна для людей и почти всегда сводится к угадайке. Тут можно откалиброваться, и научиться давать более-менее похожие оценки. То есть, натренировать свою нейросеть.
Но вообще задача на 100% для ML! Нужно взять разные параметры проектов и их реальные сроки. Закинуть в нейросетку, тут даже никакая LLM не нужна, RNN вполне справится — и пусть учится! У нейросетки предсказания должны лучше получаться, потому что не будет человеческих искажений "а что, если мы объявим реальный срок, а менеджер разозлится и начнет нас продавливать?". Тут бесчувственный компьютер — хоть ругай его, хоть не ругай.
LLM может понадобиться, если вы хотите какие-то параметры вытаскивать из текста, например ТЗ. Тут он может помочь, но я бы использовал его хитро — например, сначала попросил вытащить разные параметры — что-нибудь вроде числа функциональных точек.
Неплохо упомянуть конкретные методики: COCOMO, FiSMA, Nesma, AFP — ну, во что вы верите🤷♂️
Хорошо обученный LLM вытащит из своих глубин знания о конкретном методе, прикинет из общих соображений сроки, и вы получите конкретный результат. При включенных рассуждениях можно даже посмотреть, как она "думает". Вот, например, на карточках видно, как рассуждает DeepSeek.
В целом, не сильно отличается от человека, вот что.
Ну а людей такими запросами мучать не нужно, максимум — согласовать с ними оценку. На предмет увеличения :)
И никаких стандартов и взаимных претензий.
Ну а если хотите поиграться, вот несколько статей про оценку сроков нейросетями, просто для примера:
На RNN:
[1] https://www.researchgate.net/publication/321102199_Recurrent_Neural_Network_based_Prediction_of_Software_Effort
[2] https://www.mdpi.com/2073-431X/13/12/335
На LLM:
[3] https://arxiv.org/abs/2402.07158
[4] https://arxiv.org/html/2409.09617v1
По запросу 'RNN software effort estimation' много статей гуглится.
UPD: DeepSeek анализировал концепт системы по планированию и оформлению путешествий. Его первоначальная оценка:
После уточнения вводных накинул ещё 30%:
То есть, риторика такая: команда всё время даёт неправильные оценки сроков, причем всегда в меньшую сторону. Для заказной разработки это выливается в недооценку стоимости проекта, потому что они продают не результат для клиента, а стоимость разработки ПО. Для внутренней разработки — потому что попадание в озвученные сроки оценить удобнее, чем поставленную ценность — срабатывает эвристика доступности, ментальное искажение "замена атрибута".
В любом случае, задача оценки сроков мучительна для людей и почти всегда сводится к угадайке. Тут можно откалиброваться, и научиться давать более-менее похожие оценки. То есть, натренировать свою нейросеть.
Но вообще задача на 100% для ML! Нужно взять разные параметры проектов и их реальные сроки. Закинуть в нейросетку, тут даже никакая LLM не нужна, RNN вполне справится — и пусть учится! У нейросетки предсказания должны лучше получаться, потому что не будет человеческих искажений "а что, если мы объявим реальный срок, а менеджер разозлится и начнет нас продавливать?". Тут бесчувственный компьютер — хоть ругай его, хоть не ругай.
LLM может понадобиться, если вы хотите какие-то параметры вытаскивать из текста, например ТЗ. Тут он может помочь, но я бы использовал его хитро — например, сначала попросил вытащить разные параметры — что-нибудь вроде числа функциональных точек.
Неплохо упомянуть конкретные методики: COCOMO, FiSMA, Nesma, AFP — ну, во что вы верите
Хорошо обученный LLM вытащит из своих глубин знания о конкретном методе, прикинет из общих соображений сроки, и вы получите конкретный результат. При включенных рассуждениях можно даже посмотреть, как она "думает". Вот, например, на карточках видно, как рассуждает DeepSeek.
В целом, не сильно отличается от человека, вот что.
Ну а людей такими запросами мучать не нужно, максимум — согласовать с ними оценку. На предмет увеличения :)
И никаких стандартов и взаимных претензий.
Ну а если хотите поиграться, вот несколько статей про оценку сроков нейросетями, просто для примера:
На RNN:
[1] https://www.researchgate.net/publication/321102199_Recurrent_Neural_Network_based_Prediction_of_Software_Effort
[2] https://www.mdpi.com/2073-431X/13/12/335
На LLM:
[3] https://arxiv.org/abs/2402.07158
[4] https://arxiv.org/html/2409.09617v1
По запросу 'RNN software effort estimation' много статей гуглится.
UPD: DeepSeek анализировал концепт системы по планированию и оформлению путешествий. Его первоначальная оценка:
Для системы средней сложности с базовым функционалом: 8-12 месяцев. При наличии готовых модулей (например, аутентификации) срок может сократиться до 6-9 месяцев.
После уточнения вводных накинул ещё 30%:
Этап Длительность Комментарий
Проектирование 5-8 недель Учёт новых интеграций (визы, календари)
Бэкенд-разработка 6-9 месяцев Особое внимание интеграциям с высокорисковыми системами
Фронтенд 4-6 месяцев Сложные интерфейсы для конструктора маршрутов и планировщика
Тестирование 10-12 недель Проверка сценариев мультивалютных операций и модерации
Общий срок: 12-16 месяцев
(увеличение на 30-40% к первоначальной оценке)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🔥8❤1
Очень много событий, совсем забыл написать про Analyst Marathon, а там было, что посмотреть.
Небольшой обзор, что успел посмотреть:
Андрей Бураков, "Ничего мы вам не гарантируем или как брокеры НЕ гарантируют доставку сообщений"
Ну, Андрея всегда интересно послушать, а особенно когда он потрясает основы. Например как в этот раз -- когда он шатает основы гарантированной доставки сообщений и глубоко раскапывает механизмы их реализации. Всё всегда может сломаться, сообщения могут задублироваться, но мы можем с этим работать, нужно знать, как. Если хотите разобраться с гарантиями доставки, идемпотентностью, транзакционной целостностью в брокерах -- посмотрите доклад.
Руслан Сафин "Принцип каскадного снижения связанности"
Руслан так же глубоко разбирает темы связанности и сцепленности (coupling and cohesion). И показывает на примере разбивку системы -- уменьшение связности. Кстати, впервые услышал перевод cohesion как "прочности". Кажется, это должно быть связано с робастностью, нужно подумать эту мысль. Ну и когда тепреь слышу про coupling, не могу выбросить из головы фразу Роя Филдинга: "в архитектуре системы было так много связей, что на диаграмму нужно ставить пометку 18+".
Алексей Краснов "Использование Abuse cases и Attacker stories для анализа требований по безопасности"
Очень интересная мысль в докладе -- как аналитику понять безопасность. Напишите юскейсы злоумышленника! Как настоящие, с целями и успешными результатами, только вредные для системы. Очень крутая идея, и понятная. Потом, конечно, можно ввести требования, которые рушат все вредные юскейсы и на допускают их успешного окончания. Очень практичные требования к безопасности, не какая-то абстракция.
Валерий Разномазов, "Математический аппарат для системного и бизнес-анализа". Многообещающее название, но внутри очень спорный. Я сам топлю за использование математических методов и моделей в системном анализе, по пока мало что могу предложить. Ждал инсайтов, но тут не совсем та математика, которую я ожидал. В основном здесь про теорию множеств, графы и матрицы. Кажется, это лично моя проблема, потому что множества и операции с ними, графы и матрицы у меня настолько вросли в базовую картину мира, что я их уже не воспринимаю, как что-то особенное. Это просто повседневный язык мышления. Если у вас не было этого в школе или в институте -- посмотрите доклад, это база.
Понравился доклад Елизаветы Акмановой про API -- она подробно разобрала разные варианты версионирования API и какие есть плюсы и минусы у каждого варианта. Полезно, я писал об этом тут, а в докладе -- с примерами из практики. Начинаю всё лучше понимать Филдинга с его идеей вписывать версию API в имя домена.
Ну и доклад Николая Лебедева просто огненный, с разными кейсами применения ИИ -- особенно любопытно, как сразу в процессе созвона по ключевым словам ИИ автоматически ставит таски -- это какая-то фантастика.
В общем, очень интересный набор докладов, рекомендую. Если вы конференцию пропустили, у Analyst Marathon записи прошедших конференций есть (за деньги), ссылка та же.
Небольшой обзор, что успел посмотреть:
Андрей Бураков, "Ничего мы вам не гарантируем или как брокеры НЕ гарантируют доставку сообщений"
Ну, Андрея всегда интересно послушать, а особенно когда он потрясает основы. Например как в этот раз -- когда он шатает основы гарантированной доставки сообщений и глубоко раскапывает механизмы их реализации. Всё всегда может сломаться, сообщения могут задублироваться, но мы можем с этим работать, нужно знать, как. Если хотите разобраться с гарантиями доставки, идемпотентностью, транзакционной целостностью в брокерах -- посмотрите доклад.
Руслан Сафин "Принцип каскадного снижения связанности"
Руслан так же глубоко разбирает темы связанности и сцепленности (coupling and cohesion). И показывает на примере разбивку системы -- уменьшение связности. Кстати, впервые услышал перевод cohesion как "прочности". Кажется, это должно быть связано с робастностью, нужно подумать эту мысль. Ну и когда тепреь слышу про coupling, не могу выбросить из головы фразу Роя Филдинга: "в архитектуре системы было так много связей, что на диаграмму нужно ставить пометку 18+".
Алексей Краснов "Использование Abuse cases и Attacker stories для анализа требований по безопасности"
Очень интересная мысль в докладе -- как аналитику понять безопасность. Напишите юскейсы злоумышленника! Как настоящие, с целями и успешными результатами, только вредные для системы. Очень крутая идея, и понятная. Потом, конечно, можно ввести требования, которые рушат все вредные юскейсы и на допускают их успешного окончания. Очень практичные требования к безопасности, не какая-то абстракция.
Валерий Разномазов, "Математический аппарат для системного и бизнес-анализа". Многообещающее название, но внутри очень спорный. Я сам топлю за использование математических методов и моделей в системном анализе, по пока мало что могу предложить. Ждал инсайтов, но тут не совсем та математика, которую я ожидал. В основном здесь про теорию множеств, графы и матрицы. Кажется, это лично моя проблема, потому что множества и операции с ними, графы и матрицы у меня настолько вросли в базовую картину мира, что я их уже не воспринимаю, как что-то особенное. Это просто повседневный язык мышления. Если у вас не было этого в школе или в институте -- посмотрите доклад, это база.
Понравился доклад Елизаветы Акмановой про API -- она подробно разобрала разные варианты версионирования API и какие есть плюсы и минусы у каждого варианта. Полезно, я писал об этом тут, а в докладе -- с примерами из практики. Начинаю всё лучше понимать Филдинга с его идеей вписывать версию API в имя домена.
Ну и доклад Николая Лебедева просто огненный, с разными кейсами применения ИИ -- особенно любопытно, как сразу в процессе созвона по ключевым словам ИИ автоматически ставит таски -- это какая-то фантастика.
В общем, очень интересный набор докладов, рекомендую. Если вы конференцию пропустили, у Analyst Marathon записи прошедших конференций есть (за деньги), ссылка та же.
👍15❤7🔥1
Больше видео хороших и разных про ИИ!
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
👍10
Как разобраться с JSON?
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
{ "id": 12345,
"name": "Константин",
"surname": "Константинопольский",
"birthdate": "1990-04-14"
}Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
👍20🤯7❤6
Вообще я хотел серьезный пост написать про математику, которая помогает в интеграциях, но потом вспомнил — какое сегодня число и какой день недели, и понял, что никто толком не работает, и умная тема не зайдет.
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
5😁59❤8👍3