Как разобраться с 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
Или вот хардкорный пост.
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javanoscript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.💐 🌸 🌷
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javanoscript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥47❤30❤🔥13👍5👎3
Про математику в системном анализе и проектировании.
Я вообще топлю за инженерные методы в разработке, в частности — за расчеты. Вы, наверное, могли заметить. Используются математические методы в анализе и проектировании нечасто. Тем ценнее ситуации, когда их можно применить, причем с очевидной пользой.
Рассмотрим такую задачу: мы проектируем интеграцию или API бэкенда, и хотим оценить пиковую нагрузку. Допустим, у нас есть 1000 пользователей, и сценарий их работы такой, что каждый из них за час делает примерно 10 запросов к системе в случайное время. Какой RPS (число запросов в секунду) должен выдерживать сервер?
Если просто 1000*10/(60*60) — число пользователей на число операций деленое на число секунд в одном часе — получится 2.78 запросов/сек.
Но, очевидно, запросы от разных пользователей могут совпадать по времени. Для моделирования такой ситуации нужно использовать пуассоновский процесс, а точнее — распределение Пуассона.
Оно задается жутковатой формулой вероятности:
P(k)=λˆk*eˆ-λ/k!
(да, лямбда в степени k, умноженное на e в степени -λ, деленое на k факториал),
где λ — среднее количество событий за промежуток времени, k — интересующее нас количество событий, P(k) — вероятность того, что k событий произойдут в одну секунду.
В нашем примере λ = 2.78, а k можно разные подставлять:
P(5) = 0.086
P(6) = 0.04
P(7) = 0.016
Для нашего количества событий (10000) эти вероятности очень велики, например, RPS=7 у нас будет 57 раз за час!
А вот P(13) = 0.00001, то есть 1 раз в час. Значит, можно рассчитывать на RPS=13.
Формулу Пуассона можно использовать только для случайных обращений! Если у вас процесс устроен как-то регулярно — нужно использовать анализ сценариев. Например, когда все побежали в сервис после получения оповещения. Или когда в конце часа/дня обязательно нужно что-то сделать (отметиться, отправить коммит), или например все побежали сдавать домашку за 5 минут до дедлайна — тогда процесс не случайный, и нужно анализировать именно эти пики.
Ну а вероятности по формуле Пуассона можно посчитать в одном из калькуляторов, например: https://stattrek.com/online-calculator/poisson (здесь x это k, а λ названа μ), или в Экселе через функцию POISSON.
Применяйте инженерные методы в системном анализе!
Я вообще топлю за инженерные методы в разработке, в частности — за расчеты. Вы, наверное, могли заметить. Используются математические методы в анализе и проектировании нечасто. Тем ценнее ситуации, когда их можно применить, причем с очевидной пользой.
Рассмотрим такую задачу: мы проектируем интеграцию или API бэкенда, и хотим оценить пиковую нагрузку. Допустим, у нас есть 1000 пользователей, и сценарий их работы такой, что каждый из них за час делает примерно 10 запросов к системе в случайное время. Какой RPS (число запросов в секунду) должен выдерживать сервер?
Если просто 1000*10/(60*60) — число пользователей на число операций деленое на число секунд в одном часе — получится 2.78 запросов/сек.
Но, очевидно, запросы от разных пользователей могут совпадать по времени. Для моделирования такой ситуации нужно использовать пуассоновский процесс, а точнее — распределение Пуассона.
Оно задается жутковатой формулой вероятности:
P(k)=λˆk*eˆ-λ/k!
(да, лямбда в степени k, умноженное на e в степени -λ, деленое на k факториал),
где λ — среднее количество событий за промежуток времени, k — интересующее нас количество событий, P(k) — вероятность того, что k событий произойдут в одну секунду.
В нашем примере λ = 2.78, а k можно разные подставлять:
P(5) = 0.086
P(6) = 0.04
P(7) = 0.016
Для нашего количества событий (10000) эти вероятности очень велики, например, RPS=7 у нас будет 57 раз за час!
А вот P(13) = 0.00001, то есть 1 раз в час. Значит, можно рассчитывать на RPS=13.
Формулу Пуассона можно использовать только для случайных обращений! Если у вас процесс устроен как-то регулярно — нужно использовать анализ сценариев. Например, когда все побежали в сервис после получения оповещения. Или когда в конце часа/дня обязательно нужно что-то сделать (отметиться, отправить коммит), или например все побежали сдавать домашку за 5 минут до дедлайна — тогда процесс не случайный, и нужно анализировать именно эти пики.
Ну а вероятности по формуле Пуассона можно посчитать в одном из калькуляторов, например: https://stattrek.com/online-calculator/poisson (здесь x это k, а λ названа μ), или в Экселе через функцию POISSON.
Применяйте инженерные методы в системном анализе!
🔥54👍27🤯8😁2👎1
36 лет назад в этот день, а может быть в предыдущий, инженер Европейского центра ядерных исследований Тим Бернерс-Ли, занимавшийся высокоскоростной шиной FASTBUS для сбора информации с датчиков микрочастиц и разработкой технологий RPC для неё, представил своему руководителю Майку Сендаллу "Предложение по управлению информацией".
Проблемой, которую предлагал решить автор, являлась потеря информации в ЦЕРНе. Номинально у Центра была вертикальная иерархическая структура, но на самом деле в реальной работе всё было очень переплетено, и люди образовывали скорее временную "паутину" связей, которая к тому же постоянно менялась. Информация об этих связях нигде не хранилась — ну, разве что, в каких-то редких случайных письмах, а в основном — передавалась в коридорных разговорах.
Часто это приводило к тому, что две соседние лаборатории работали над дублирующими друг друга проектами, а разобраться в том, кто использует конкретную установку или датчик, и чей эксперимент слетит, если их немного перенастроить — не представлялось возможным. А когда что-то ломалось, требовалось просто детективное расследование причин и технических деталей.
Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?
Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования
а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.
Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться
Это всё должно было помочь хранить актуальную информацию по проектам, быстро извлекать нужные документы и вести учет личных навыков людей (по привязкам людей к проектам, софту и оборудованию, с которым они работали или которое создавали).
По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.
Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.
Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹
Проблемой, которую предлагал решить автор, являлась потеря информации в ЦЕРНе. Номинально у Центра была вертикальная иерархическая структура, но на самом деле в реальной работе всё было очень переплетено, и люди образовывали скорее временную "паутину" связей, которая к тому же постоянно менялась. Информация об этих связях нигде не хранилась — ну, разве что, в каких-то редких случайных письмах, а в основном — передавалась в коридорных разговорах.
Часто это приводило к тому, что две соседние лаборатории работали над дублирующими друг друга проектами, а разобраться в том, кто использует конкретную установку или датчик, и чей эксперимент слетит, если их немного перенастроить — не представлялось возможным. А когда что-то ломалось, требовалось просто детективное расследование причин и технических деталей.
Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?
Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования
а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.
Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться
Это всё должно было помочь хранить актуальную информацию по проектам, быстро извлекать нужные документы и вести учет личных навыков людей (по привязкам людей к проектам, софту и оборудованию, с которым они работали или которое создавали).
По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.
Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.
Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹
🔥31🎉24👍5❤4
Я иногда просматриваю программы конференций по инженерии требований, чтобы понять, о чем сейчас говорят, какие темы актуальны.
Их две топовых:
RE (собственно, Requirements Engineering) от IEEE и
REFSQ (Requirements Engineering: Foundation for Software Quality), с участием IREB и Springer.
В 2025 обе проходят в Испании: REFSQ вот сейчас в апреле в Барселоне, RE в сентябре в Валенсии.
Это прям научные конференции, проходят в университетах, с профессорами и исследовательскими докладами. Впрочем, обычно есть и индустриальный трек, это больше на наши конференции похоже.
Программы SE пока нет, а в REFSQ, ожидаемо, чуть ли не треть докладов про ИИ и LLM.
Но удивила меня тема конференции. Фокус, так сказать. Пока мы тут, на WAW например, ИИ выносим на флаг, в западном мире людей совсем другое интересует.
Знаете, что?
Социальная ответственность!
(Social REsponsibility)
Это круто, и я про это тоже часто думаю.
То, что мы делаем, то, какие системы создаем, какие функции в них реализуем — как это влияет на жизнь людей?
Осознаем ли мы это влияние и свою ответственность?
Как организаторы пишут:
А, какая формулировка!
Соответственно, вопросы, которые они выносят на обсуждение:
➡️ Как наше сообщество инженеров по требованиям (читай — системных аналитиков) может внести вклад в «общественное благо»?
➡️ Как поддержать «ответственное проектирование» (Responsible Design) посредством разработки требований?
➡️ Как активно вовлекать общество (крупные/разнородные группы заинтересованных сторон) в разработку требований (например, совместное создание/совместное проектирование)?
➡️ Как систематически извлекать, проектировать и оценивать социальные ценности и воздействия?
➡️ Как согласовать социальные потребности и эволюцию «интеллектуальных» систем?
А вам как кажется, актуальные темы для нашего сообщества? Хотели бы вы их обсудить на какой-нибудь конференции?
Их две топовых:
RE (собственно, Requirements Engineering) от IEEE и
REFSQ (Requirements Engineering: Foundation for Software Quality), с участием IREB и Springer.
В 2025 обе проходят в Испании: REFSQ вот сейчас в апреле в Барселоне, RE в сентябре в Валенсии.
Это прям научные конференции, проходят в университетах, с профессорами и исследовательскими докладами. Впрочем, обычно есть и индустриальный трек, это больше на наши конференции похоже.
Программы SE пока нет, а в REFSQ, ожидаемо, чуть ли не треть докладов про ИИ и LLM.
Но удивила меня тема конференции. Фокус, так сказать. Пока мы тут, на WAW например, ИИ выносим на флаг, в западном мире людей совсем другое интересует.
Знаете, что?
(Social REsponsibility)
Это круто, и я про это тоже часто думаю.
То, что мы делаем, то, какие системы создаем, какие функции в них реализуем — как это влияет на жизнь людей?
Осознаем ли мы это влияние и свою ответственность?
Как организаторы пишут:
Инженерия требований — это социально-техническая дисциплина, которая направлена на понимание и анализ потребностей заинтересованных сторон, затронутых внедрением цифровых решений, и на передачу этих потребностей команде разработчиков. Эта роль посредника позволяет нашему сообществу оказывать существенное влияние на цели, возможности, функциональность и качество цифровых решений и, таким образом, брать на себя ОТВЕТСТВЕННОСТЬ за социальное воздействие, которое приносят эти решения.
А, какая формулировка!
Соответственно, вопросы, которые они выносят на обсуждение:
А вам как кажется, актуальные темы для нашего сообщества? Хотели бы вы их обсудить на какой-нибудь конференции?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23❤9🤔7🗿3
О, вот это самое крутое выступление за последние несколько лет, которое я слышал на конференциях! Зал был битком, там видно. И ещё это интерактив!
Сама тема вообще не специфичная для аналитика — это в чистом виде практикум по противодействию манипуляторам на работе. А может быть, как раз для аналитиков будет актуально — у нас вечно не совсем четко определены границы рабочих обязанностей, поэтому навешать лишнего забесплатно — это у нас постоянно.
В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂
Сама тема вообще не специфичная для аналитика — это в чистом виде практикум по противодействию манипуляторам на работе. А может быть, как раз для аналитиков будет актуально — у нас вечно не совсем четко определены границы рабочих обязанностей, поэтому навешать лишнего забесплатно — это у нас постоянно.
В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂
👍8❤2💯2
Forwarded from Flow — конференция про системный и бизнес-анализ
#видеозаписи
Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».
YouTube | VK Видео
Скачать презентацию с сайта Flow
Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».
YouTube | VK Видео
Скачать презентацию с сайта Flow
👍13
Накатал сегодня мощный пост про цифровую трансформацию, скопирую сюда тоже. Не то чтобы аналитиков часто спрашивают про ЦТ (что, на самом деле, странно), но вдруг кому-то придётся этим заниматься. Вот, знайте, как оно должно выглядеть.
Задело меня то, что многие говорят о недостаточной определенности понятия цифровой трансформации. Вроде бы все хотят, но никто толком не знает, что это такое и как узнать, что оно у тебя есть (или нет).
Я не понимаю всех этих разговоров про неопределенность понятия цифровой трансформации. Вероятно, их ведут те, кто ни разу в глаза не видел трансформированной организации. Мне повезло, я видел (я и ускорение поставки софта в 6-10 раз видел, как обещает Сазерленд, мне вообще повезло).
Так вот, признак цифровой трансформации в организации - это рефлекторное движение каждого сотрудника, столкнувшегося с какой-то проблемой, к написанию кода, решающего эту проблему, или иным способом внесения изменения в цифровую систему, на которой работает организация. Ну, просто это первое, что в голову приходит.
В этом смысле у нас организации бывают образовательно трансформированные (решение любой проблемы = послать сотрудников на обучение, это практически все школы так работают), или бихевиористически-трансформированные (решение любой проблемы = изменение KPI), или маркетингово-трансформированные (решение любой проблемы = поменять маркетинг/продажи).
Конечно, это требует определенной инфраструктуры.
Во-первых, организация должна работать на основе ИТ-системы. Ну без этого никак, к сожалению. Можно установить тонны компьютеров, но если нет единой системы, в которую они объединены - нет носителя деятельности.
Во-вторых, эта ИТ-система должна быть легко модернизируема, расширяема и перестраиваема. Поэтому agile (быстрая поставка), ИИ (программирование без программирования) и открытые системы.
В-третьих, люди должны уметь программировать, создавать и изменять ИТ-системы. Не отдельные люди, которые где-то там в ИТ-департаменте, а все, хотя бы до уровня начальников отделов. В той организации, которую я считаю примером, так и было - начальник операционного управления программист, начальник клиентского - программист, и так далее. Хотя сама организация работала в сфере финансов. И половина сотрудников - в чистом виде ИТ: технологи, разработчки, тестировщики, эксплуатация. Если нужны данные - БД открыты, можно вытащить. Если нужно что-то автоматизировать - есть точки расширения и API, на которые можно повесить скрипты. Если нужно хранить информацию внутри подразделения - создается база данных, а не тысячи экселек или текстовых документов. Если какая-то операция повторяется более трёх раз - она автоматизируется. Вот это - цифровая трансформация! Если у вас не так, значит, у вас что угодно, только не ЦТ.
Да, есть проблемы - где же нам взять столько программистов, да чтобы они работали не программистами. Это разговоры в пользу бедных. Это примерно соответствует вопросу 100-130-летней давности - а где же нам взять столько грамотных людей. Ну академик Ершов ещё в 1981 сказал, что программирование - это вторая грамотность. Вот. Ищите и нанимайте грамотных людей. Без этого никак.
Всем ли нужна цифровая трансформация? Наверное, нет, издержки довольно высоки. Но тогда и не надо делать вид, что вы её хотите, и в стратегические программы вписывать под видом ЦТ закупку новых компьютеров.
Задело меня то, что многие говорят о недостаточной определенности понятия цифровой трансформации. Вроде бы все хотят, но никто толком не знает, что это такое и как узнать, что оно у тебя есть (или нет).
Я не понимаю всех этих разговоров про неопределенность понятия цифровой трансформации. Вероятно, их ведут те, кто ни разу в глаза не видел трансформированной организации. Мне повезло, я видел (я и ускорение поставки софта в 6-10 раз видел, как обещает Сазерленд, мне вообще повезло).
Так вот, признак цифровой трансформации в организации - это рефлекторное движение каждого сотрудника, столкнувшегося с какой-то проблемой, к написанию кода, решающего эту проблему, или иным способом внесения изменения в цифровую систему, на которой работает организация. Ну, просто это первое, что в голову приходит.
В этом смысле у нас организации бывают образовательно трансформированные (решение любой проблемы = послать сотрудников на обучение, это практически все школы так работают), или бихевиористически-трансформированные (решение любой проблемы = изменение KPI), или маркетингово-трансформированные (решение любой проблемы = поменять маркетинг/продажи).
Конечно, это требует определенной инфраструктуры.
Во-первых, организация должна работать на основе ИТ-системы. Ну без этого никак, к сожалению. Можно установить тонны компьютеров, но если нет единой системы, в которую они объединены - нет носителя деятельности.
Во-вторых, эта ИТ-система должна быть легко модернизируема, расширяема и перестраиваема. Поэтому agile (быстрая поставка), ИИ (программирование без программирования) и открытые системы.
В-третьих, люди должны уметь программировать, создавать и изменять ИТ-системы. Не отдельные люди, которые где-то там в ИТ-департаменте, а все, хотя бы до уровня начальников отделов. В той организации, которую я считаю примером, так и было - начальник операционного управления программист, начальник клиентского - программист, и так далее. Хотя сама организация работала в сфере финансов. И половина сотрудников - в чистом виде ИТ: технологи, разработчки, тестировщики, эксплуатация. Если нужны данные - БД открыты, можно вытащить. Если нужно что-то автоматизировать - есть точки расширения и API, на которые можно повесить скрипты. Если нужно хранить информацию внутри подразделения - создается база данных, а не тысячи экселек или текстовых документов. Если какая-то операция повторяется более трёх раз - она автоматизируется. Вот это - цифровая трансформация! Если у вас не так, значит, у вас что угодно, только не ЦТ.
Да, есть проблемы - где же нам взять столько программистов, да чтобы они работали не программистами. Это разговоры в пользу бедных. Это примерно соответствует вопросу 100-130-летней давности - а где же нам взять столько грамотных людей. Ну академик Ершов ещё в 1981 сказал, что программирование - это вторая грамотность. Вот. Ищите и нанимайте грамотных людей. Без этого никак.
Всем ли нужна цифровая трансформация? Наверное, нет, издержки довольно высоки. Но тогда и не надо делать вид, что вы её хотите, и в стратегические программы вписывать под видом ЦТ закупку новых компьютеров.
1🔥23👍6❤1🤔1😐1
Я очень люблю, когда мне участники тренингов задают разные дополнительные вопросы, пусть даже косвенно относящиеся к теме. (Кстати, не только участники тренингов — вы тоже можете меня спрашивать, например в чате к этому каналу).
Вот, например, вопрос про лучшие практики построения админок. На удивление, толковых публикаций на эту тему мало, в основном либо пустые SEO-тексты, либо реклама своих фреймворков/шаблонов. И пишут чаще всего про дизайн, а не про функции.
К хорошим (но очень коротким!) относятся рекомендации от дизайнеров британских правительственных сервисов:
https://designnotes.blog.gov.uk/2015/09/25/design-principles-for-admin-interfaces/ , но это редкость, да и мало там инсайтов.
Поэтому я взял на себя смелость собрать несколько идей и принципов, с которыми лично сталкивался. Надеюсь, будет вам полезно, если вы занимаетесь админками. Не значит, что вам все эти практики нужны, но просто знайте про них, вдруг пригодятся.
Итак, что я узнал про админки за 25 лет:
— Общий обзор: вытащите на главную страницу админки несколько самых актуальных показателей, последних событий и алертов, чтобы сразу было понятно, что в системе происходит и за что браться в первую очередь;
— Админы — разные. Дайте им возможность настроить админку лично для себя. Скорее всего, ваши админы выполняют разные задачи, поэтому хорошо бы предусмотреть виджеты и возможность вытащить на первую страницу разные данные и действия;
— Разные и многоуровневые права доступа, а не один админ со всеми правами. Админы бывают разные, и в больших системах доступ админов может быть очень гранулировано нарезан — как по доступу к разным типам данных и разным действиям, так и по содержанию данных. Например, по категориям клиентов, или как у меня было на учебной платформе: админ учебных групп отдельного вуза, админ одного курса, админ вуза с доступом ко всем курсам, админ всех студентов, админ всех курсов, админ всей системы. Только на назначение прав доступа три роли несовмещаемые должны быть, в идеале: один создает группы с правами, другой заводит пользователей, третий назначает пользователей в группы по идентификаторам. Чтобы один админ не мог создать супер-пользователя.
— Журналирование всех действий админа (в том числе на просмотр, фильтры и поиск; в том числе — с оповещениями более старшего админа о подозрительных действиях);
— Поиск, фильтры и сортировка (в админке бывают большие объемы данных);
— Серьезные подтверждения для опасных необратимых действий (не кнопка "Да, продожить", а в виде ручного ввода длинной строки текста, "Я понимаю, что я собираюсь удалить бэкап базы данных, и это действие невозможно отменить" или согласия старшего админа);
— Возможность отменить действия. Вообще сохранение истории и возможность просмотра предыдущих состояний (и связей!) объекта.
— "Мягкое удаление" везде, где возможно (если это не противоречит регуляторным требованиям). Следите также за каскадным удалением, оно опасно!
— Функции для пакетных операций! Когда можно выделить несколько элементов и с ними что-то сделать одним действием.
— Инлайн-редактирование прямо в строке таблицы. Часто бывает трудно реализовать чисто технически, но в некоторых случаях сильно упрощает работу.
— Связки всего со всем и переходы — когда можно легко из одного объекта в другой связанный провалиться, или перейти от общего к деталям (drill down) и вернуться обратно.
— Подсветка тревожных и подозрительных событий (когда они ещё не стали сбоем и проблемой). Например,
— Принцип "один экран — одно действие" в админках не работает. Там наоборот — лучше побольше контекстных действий уместить на экране.
— Ширина экрана и плотность информации. Используйте экран по полной! В админках не очень нужен дизайнерский "воздух", чаще важнее число отображаемых элементов.
— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.
Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!
Вот, например, вопрос про лучшие практики построения админок. На удивление, толковых публикаций на эту тему мало, в основном либо пустые SEO-тексты, либо реклама своих фреймворков/шаблонов. И пишут чаще всего про дизайн, а не про функции.
К хорошим (но очень коротким!) относятся рекомендации от дизайнеров британских правительственных сервисов:
https://designnotes.blog.gov.uk/2015/09/25/design-principles-for-admin-interfaces/ , но это редкость, да и мало там инсайтов.
Поэтому я взял на себя смелость собрать несколько идей и принципов, с которыми лично сталкивался. Надеюсь, будет вам полезно, если вы занимаетесь админками. Не значит, что вам все эти практики нужны, но просто знайте про них, вдруг пригодятся.
Итак, что я узнал про админки за 25 лет:
— Общий обзор: вытащите на главную страницу админки несколько самых актуальных показателей, последних событий и алертов, чтобы сразу было понятно, что в системе происходит и за что браться в первую очередь;
— Админы — разные. Дайте им возможность настроить админку лично для себя. Скорее всего, ваши админы выполняют разные задачи, поэтому хорошо бы предусмотреть виджеты и возможность вытащить на первую страницу разные данные и действия;
— Разные и многоуровневые права доступа, а не один админ со всеми правами. Админы бывают разные, и в больших системах доступ админов может быть очень гранулировано нарезан — как по доступу к разным типам данных и разным действиям, так и по содержанию данных. Например, по категориям клиентов, или как у меня было на учебной платформе: админ учебных групп отдельного вуза, админ одного курса, админ вуза с доступом ко всем курсам, админ всех студентов, админ всех курсов, админ всей системы. Только на назначение прав доступа три роли несовмещаемые должны быть, в идеале: один создает группы с правами, другой заводит пользователей, третий назначает пользователей в группы по идентификаторам. Чтобы один админ не мог создать супер-пользователя.
— Журналирование всех действий админа (в том числе на просмотр, фильтры и поиск; в том числе — с оповещениями более старшего админа о подозрительных действиях);
— Поиск, фильтры и сортировка (в админке бывают большие объемы данных);
— Серьезные подтверждения для опасных необратимых действий (не кнопка "Да, продожить", а в виде ручного ввода длинной строки текста, "Я понимаю, что я собираюсь удалить бэкап базы данных, и это действие невозможно отменить" или согласия старшего админа);
— Возможность отменить действия. Вообще сохранение истории и возможность просмотра предыдущих состояний (и связей!) объекта.
— "Мягкое удаление" везде, где возможно (если это не противоречит регуляторным требованиям). Следите также за каскадным удалением, оно опасно!
— Функции для пакетных операций! Когда можно выделить несколько элементов и с ними что-то сделать одним действием.
— Инлайн-редактирование прямо в строке таблицы. Часто бывает трудно реализовать чисто технически, но в некоторых случаях сильно упрощает работу.
— Связки всего со всем и переходы — когда можно легко из одного объекта в другой связанный провалиться, или перейти от общего к деталям (drill down) и вернуться обратно.
— Подсветка тревожных и подозрительных событий (когда они ещё не стали сбоем и проблемой). Например,
— Принцип "один экран — одно действие" в админках не работает. Там наоборот — лучше побольше контекстных действий уместить на экране.
— Ширина экрана и плотность информации. Используйте экран по полной! В админках не очень нужен дизайнерский "воздух", чаще важнее число отображаемых элементов.
— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.
Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!
1👍35🔥13❤7
Красивая картинка про оценки трудоемкости разработки софта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
Называется "воронка неопределенности Боэма" (Barry Boehm).
Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.
Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")
На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок
При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).
Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.
У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.
В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.
❤19🔥13👍8👌1
This media is not supported in your browser
VIEW IN TELEGRAM
В вебинаре про карту интеграций был вопрос про первую версию, которая с кружочками. Точнее, про инструмент, в котором я её визуализировал.
Для системного аналитика задача наверное не совсем типовая — обычно мы не занимаемся визуализацией данных, это больше прерогатива дата-аналитиков или BI. Но вдруг кому-то понадобится. Я вообще когда-то вел занятия по разным цифровым сервисам в магистратуре "Мультимедийная журналистика" НИУ ВШЭ, даже как-то раз был выбран там лучшим преподавателем. Собрал себе библиотечку мультимедийных сервисов — где инфографику можно накидать, где визуализацию данных, где таймлайн, где мультик, где игру, а где проект на карте. Многие сервисы с того времени уже закрылись, а те, что остались — недоступны в РФ.
Но вот этот сервис визуализации — RawGraphs — от Миланского политехнического института ещё существует и доступен.
Там у них в примерах много красоты — она делается дизайнерами уже после выгрузки визуализации в SVG и доведения в графическом редакторе. Получается нарядно: https://www.rawgraphs.io/gallery
В отличие от обычных графиков, доступных, например, в Excel, в этих средах визуализации есть штуки типа sankey diagram (когда что-то перетекает во что-то, можно потоки пользователей так визуализировать, есть есть ветвление), круговые дендрограммы (иерархические структуры с кластерами), или тот же circle packing, который показывает вложенность объектов.
А если вас вообще интересует тема визуализаций, посмотрите вот этот каталог: https://datavizproject.com/
Я тащусь от красивых визуализаций.
В другой жизни я бы, наверное, был бы владельцем студии инфографики и интерактивных сервисов, но не сложилось.
Для системного аналитика задача наверное не совсем типовая — обычно мы не занимаемся визуализацией данных, это больше прерогатива дата-аналитиков или BI. Но вдруг кому-то понадобится. Я вообще когда-то вел занятия по разным цифровым сервисам в магистратуре "Мультимедийная журналистика" НИУ ВШЭ, даже как-то раз был выбран там лучшим преподавателем. Собрал себе библиотечку мультимедийных сервисов — где инфографику можно накидать, где визуализацию данных, где таймлайн, где мультик, где игру, а где проект на карте. Многие сервисы с того времени уже закрылись, а те, что остались — недоступны в РФ.
Но вот этот сервис визуализации — RawGraphs — от Миланского политехнического института ещё существует и доступен.
Там у них в примерах много красоты — она делается дизайнерами уже после выгрузки визуализации в SVG и доведения в графическом редакторе. Получается нарядно: https://www.rawgraphs.io/gallery
В отличие от обычных графиков, доступных, например, в Excel, в этих средах визуализации есть штуки типа sankey diagram (когда что-то перетекает во что-то, можно потоки пользователей так визуализировать, есть есть ветвление), круговые дендрограммы (иерархические структуры с кластерами), или тот же circle packing, который показывает вложенность объектов.
А если вас вообще интересует тема визуализаций, посмотрите вот этот каталог: https://datavizproject.com/
Я тащусь от красивых визуализаций.
В другой жизни я бы, наверное, был бы владельцем студии инфографики и интерактивных сервисов, но не сложилось.
🔥18👍5❤3😁2