36 лет назад в этот день, а может быть в предыдущий, инженер Европейского центра ядерных исследований Тим Бернерс-Ли, занимавшийся высокоскоростной шиной FASTBUS для сбора информации с датчиков микрочастиц и разработкой технологий RPC для неё, представил своему руководителю Майку Сендаллу "Предложение по управлению информацией".

Проблемой, которую предлагал решить автор, являлась потеря информации в ЦЕРНе. Номинально у Центра была вертикальная иерархическая структура, но на самом деле в реальной работе всё было очень переплетено, и люди образовывали скорее временную "паутину" связей, которая к тому же постоянно менялась. Информация об этих связях нигде не хранилась — ну, разве что, в каких-то редких случайных письмах, а в основном — передавалась в коридорных разговорах.

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

Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?

Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования

а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.

Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться

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

По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.

Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.

Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹

О, вот это самое крутое выступление за последние несколько лет, которое я слышал на конференциях! Зал был битком, там видно. И ещё это интерактив!

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

В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂

#видеозаписи

Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».

YouTube | VK Видео

Скачать презентацию с сайта Flow

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

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

Я не понимаю всех этих разговоров про неопределенность понятия цифровой трансформации. Вероятно, их ведут те, кто ни разу в глаза не видел трансформированной организации. Мне повезло, я видел (я и ускорение поставки софта в 6-10 раз видел, как обещает Сазерленд, мне вообще повезло).

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

В этом смысле у нас организации бывают образовательно трансформированные (решение любой проблемы = послать сотрудников на обучение, это практически все школы так работают), или бихевиористически-трансформированные (решение любой проблемы = изменение KPI), или маркетингово-трансформированные (решение любой проблемы = поменять маркетинг/продажи).

Конечно, это требует определенной инфраструктуры.

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

Во-вторых, эта ИТ-система должна быть легко модернизируема, расширяема и перестраиваема. Поэтому agile (быстрая поставка), ИИ (программирование без программирования) и открытые системы.

В-третьих, люди должны уметь программировать, создавать и изменять ИТ-системы. Не отдельные люди, которые где-то там в ИТ-департаменте, а все, хотя бы до уровня начальников отделов. В той организации, которую я считаю примером, так и было - начальник операционного управления программист, начальник клиентского - программист, и так далее. Хотя сама организация работала в сфере финансов. И половина сотрудников - в чистом виде ИТ: технологи, разработчки, тестировщики, эксплуатация. Если нужны данные - БД открыты, можно вытащить. Если нужно что-то автоматизировать - есть точки расширения и API, на которые можно повесить скрипты. Если нужно хранить информацию внутри подразделения - создается база данных, а не тысячи экселек или текстовых документов. Если какая-то операция повторяется более трёх раз - она автоматизируется. Вот это - цифровая трансформация! Если у вас не так, значит, у вас что угодно, только не ЦТ.

Да, есть проблемы - где же нам взять столько программистов, да чтобы они работали не программистами. Это разговоры в пользу бедных. Это примерно соответствует вопросу 100-130-летней давности - а где же нам взять столько грамотных людей. Ну академик Ершов ещё в 1981 сказал, что программирование - это вторая грамотность. Вот. Ищите и нанимайте грамотных людей. Без этого никак.

Всем ли нужна цифровая трансформация? Наверное, нет, издержки довольно высоки. Но тогда и не надо делать вид, что вы её хотите, и в стратегические программы вписывать под видом ЦТ закупку новых компьютеров.

Я очень люблю, когда мне участники тренингов задают разные дополнительные вопросы, пусть даже косвенно относящиеся к теме. (Кстати, не только участники тренингов — вы тоже можете меня спрашивать, например в чате к этому каналу).

Вот, например, вопрос про лучшие практики построения админок. На удивление, толковых публикаций на эту тему мало, в основном либо пустые SEO-тексты, либо реклама своих фреймворков/шаблонов. И пишут чаще всего про дизайн, а не про функции.

К хорошим (но очень коротким!) относятся рекомендации от дизайнеров британских правительственных сервисов:
https://designnotes.blog.gov.uk/2015/09/25/design-principles-for-admin-interfaces/ , но это редкость, да и мало там инсайтов.

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

Итак, что я узнал про админки за 25 лет:

— Общий обзор: вытащите на главную страницу админки несколько самых актуальных показателей, последних событий и алертов, чтобы сразу было понятно, что в системе происходит и за что браться в первую очередь;

— Админы — разные. Дайте им возможность настроить админку лично для себя. Скорее всего, ваши админы выполняют разные задачи, поэтому хорошо бы предусмотреть виджеты и возможность вытащить на первую страницу разные данные и действия;

— Разные и многоуровневые права доступа, а не один админ со всеми правами. Админы бывают разные, и в больших системах доступ админов может быть очень гранулировано нарезан — как по доступу к разным типам данных и разным действиям, так и по содержанию данных. Например, по категориям клиентов, или как у меня было на учебной платформе: админ учебных групп отдельного вуза, админ одного курса, админ вуза с доступом ко всем курсам, админ всех студентов, админ всех курсов, админ всей системы. Только на назначение прав доступа три роли несовмещаемые должны быть, в идеале: один создает группы с правами, другой заводит пользователей, третий назначает пользователей в группы по идентификаторам. Чтобы один админ не мог создать супер-пользователя.

— Журналирование всех действий админа (в том числе на просмотр, фильтры и поиск; в том числе — с оповещениями более старшего админа о подозрительных действиях);

— Поиск, фильтры и сортировка (в админке бывают большие объемы данных);

— Серьезные подтверждения для опасных необратимых действий (не кнопка "Да, продожить", а в виде ручного ввода длинной строки текста, "Я понимаю, что я собираюсь удалить бэкап базы данных, и это действие невозможно отменить" или согласия старшего админа);

— Возможность отменить действия. Вообще сохранение истории и возможность просмотра предыдущих состояний (и связей!) объекта.

— "Мягкое удаление" везде, где возможно (если это не противоречит регуляторным требованиям). Следите также за каскадным удалением, оно опасно!

— Функции для пакетных операций! Когда можно выделить несколько элементов и с ними что-то сделать одним действием.

— Инлайн-редактирование прямо в строке таблицы. Часто бывает трудно реализовать чисто технически, но в некоторых случаях сильно упрощает работу.

— Связки всего со всем и переходы — когда можно легко из одного объекта в другой связанный провалиться, или перейти от общего к деталям (drill down) и вернуться обратно.

— Подсветка тревожных и подозрительных событий (когда они ещё не стали сбоем и проблемой). Например,

— Принцип "один экран — одно действие" в админках не работает. Там наоборот — лучше побольше контекстных действий уместить на экране.

— Ширина экрана и плотность информации. Используйте экран по полной! В админках не очень нужен дизайнерский "воздух", чаще важнее число отображаемых элементов.

— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.

Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!

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

Для системного аналитика задача наверное не совсем типовая — обычно мы не занимаемся визуализацией данных, это больше прерогатива дата-аналитиков или BI. Но вдруг кому-то понадобится. Я вообще когда-то вел занятия по разным цифровым сервисам в магистратуре "Мультимедийная журналистика" НИУ ВШЭ, даже как-то раз был выбран там лучшим преподавателем. Собрал себе библиотечку мультимедийных сервисов — где инфографику можно накидать, где визуализацию данных, где таймлайн, где мультик, где игру, а где проект на карте. Многие сервисы с того времени уже закрылись, а те, что остались — недоступны в РФ.

Но вот этот сервис визуализации — RawGraphs — от Миланского политехнического института ещё существует и доступен.
Там у них в примерах много красоты — она делается дизайнерами уже после выгрузки визуализации в SVG и доведения в графическом редакторе. Получается нарядно: https://www.rawgraphs.io/gallery

В отличие от обычных графиков, доступных, например, в Excel, в этих средах визуализации есть штуки типа sankey diagram (когда что-то перетекает во что-то, можно потоки пользователей так визуализировать, есть есть ветвление), круговые дендрограммы (иерархические структуры с кластерами), или тот же circle packing, который показывает вложенность объектов.

А если вас вообще интересует тема визуализаций, посмотрите вот этот каталог: https://datavizproject.com/

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

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

А может быть, вы занимали какую-то другую роль, и теперь вам нужно требования писать. Ну и в принципе часто оказывается, что люди не особо понимают, как документы составлять. Для документов, в которых нужно кого-нибудь в чем-нибудь убедить, есть книга "Принцип пирамиды Минто", авторства Барбары Минто.

Для документов системного анализа она тоже подходит, но давайте раскрою чуть конкретнее. Мы, на самом деле, этими документами хотим убедить заказчиков, что:
- система/доработка нужна;
- она решит проблему заказчика;
- она гораздо сложнее, чем думал заказчик (поэтому нужно дать больше денег).

Итак, принципы пирамиды Куприянова:

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

2. Где-то через 1-2 страницы от начала документа должна быть БОЛЬШАЯ КАРТИНКА. Книжки без картинок читать скучно. Это должна быть картинка, иллюстрирующая знакомую заказчику обстановку, но с нового ракурса. Типичный пример — контекстная диаграмма. Окружение системы знакомо, роли знакомы, потоки данных знакомы — из нового появляется система, которая это всё объединит. В детали устройства системы вдаваться не нужно, но иногда стоит, если нужно подчеркнуть, насколько она сложная.

3. Общее правило: любая картинка требует текстовой расшифровки. Обычно это таблица, в которой перечислено всё, что изображено на картинке + новые подробности. Для контекстной диаграммы это перечисление ролей, смежных систем, входов и выходов.

4. От контекстной диаграммы легко перейти к требованиям пользователей: хотим, чтобы в систему можно было ввести то-то и то-то, а она нам сама считала/генерировала/обобщала ... и показывала. Тут отлично могут подойти юзер-стори и джоб-стори. Из нового: добавляются тригеры и контекст: когда мы этого хотим? Зачем? Как? (С какими показателями/ограничениями). Скорее всего, мы тут фиксируем то, что нам пользователи ранее рассказали в интервью, и им это должно быть знакомо. Если что, можно предоставить запись, когда именно и кто про это говорил.

5. Добавляем деталей: модель объектов предметной области + их состояния + что с ними можно делать (юскейсы). Пока только названия и цели. Проверка: системы нет, а юскейс имеет смысл (как-то же они сейчас это делают?)

На этом заканчивается описание того, что уже существует в мире — даже если нашей системы нет, это всё равно есть. Есть цели, есть объекты, есть роли, есть юскейсы. Закончили рассказывать про известное. Возможно, что-то из этого известного заказчикам ранее не было известно, или не было систематизировано — мы уже принесли пользу. Сюда же можно добавить ограничения, бизнес-правила и показатели назначения: сколько объектов/пользователей/операций должна поддерживать система, с какой частотой
/интенсивностью/надежностью — это всё тоже объективно следует из потребностей и планов бизнеса.

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

Этого ещё нет, это наши проектные решения. Из решений могут следовать новые требования. Они относятся к элементам решения: экранам, API, отчетам. Обычно эта часть документа более подробная. Может быть это даже отдельные документы. И так доходим до деталей реализации, которые бизнес-заказчик и смотреть не будет, это техника.

Есть такой клёвый инструмент — Tech Radar, радар используемых технологий в компании.

Придумали его thoughtworks — компания, в которой, например, работает Мартин Фаулер в классной должности Chief Scientist (я бы тоже таким работал!)

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

Adopt — то, что в компании активно используется и является практически стандартом.
Trial — то, что готово к использованию, даже где-то применяется в исследовательских целях, но в этом мы не так уверены, как в предыдущих технологиях.
Assess — то, к чему мы присматриваемся, но пока даже не проводим исследования
Hold — то, что уже не должно применяться в новых проектах, но может ещё оставаться в легаси

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

Вот, например, Т-Банк: https://radar.tinkoff.ru/
Мы тут видим в Adopt: OpenAPI, Scrum/Kanban, Feature Toggle, а вот DDD — только в Trial.

Нас интересует, понятно, сектор "Техники", может быть — "Инструменты" (хотя часто их не очень-то различают).

Вот Авито: https://techradar.avito.ru/
Swagger 2.0 — в Adopt, OpenAPI 3.0 — в Assess

МТС: https://mts-digital.ru/technology/techradar/
В Adopt есть Archi(!), а в Hold — Figma(!). Зато в фреймворках есть gRPC.

HH: https://hh.ru/article/techradar

В общем, практически ни у кого ничего по системному анализу! А очень зря, между прочим.
Если у вас хоть сколько-нибудь аналитиков в компании есть — имеет смысл такую карту составить.
Там будут, конечно, только техники, подходы и инструменты, но уже это само по себе полезно.

Что мы сейчас применяем — юзер-стори или юскейсы? А диаграммы мы рисуем где — в draw.io или в plantuml?
И для себя полезно понимать, и новички не будут сомневаться. Такая ситуационная инженерия метода работы на минималках.

У самих thoughtworks на радаре совсем другое, там сплошной ИИ:
В Adopt: RAG, в Trial: Small language models, генерация синтетических данных для тестов, LLM для реверс-инженеринга, вызовы функций из LLM и всякое такое. А ещё — Domain Storytelling! Как облегченная версия Event Storming'a. При этом DDD даже нет на радаре, это у них вообще "фундаментальный подход к созданию ПО". А Event Storming у них вошел в Adopt ещё в 2018 году.

В Assess — тоже сплошной LLM, но ещё, например, GraphQL как инструмент talk-to-data: когда LLM-ка для ответа на вопрос формирует запрос GraphQL, вызывает его, парсит и отвечает по-человечески.

В общем, прямо разительные отличия: в наших-то радарах вообще про ИИ мало. И это октябрь прошлого года! Новый техрадар от thoughtworks выходит буквально сейчас: ещё не опубликован, пока только представлен в вебинарах, буквально позавчера.

Опубликуют — посмотрим, какой там прогресс. Сами они называют ситуацию с LLM "кембрийским взрывом". Кто не запрыгнет — останется вендобионтом 😂

ByteByteGo в рассылке подогнал роадмэп развития архитектора ПО.

Посмотрим, какие есть пересечения с системными аналитиками.

1. Языки. Выучить парочку языков программирования для бэкенда. Java, Python, Go, JS. Ну, тут мимо.

2. Инструменты. GitHub, Jenkins, Jira, ELK, Sonar. Аналитик из этого знает обычно Jira и может быть GitHub. GitHub — это хранение исходников и версий (тут, думаю, в первую очередь имеется в виду сама идея работы с git: все эти пуллы, пуши, коммиты, ветки и PR. Кстати, если хотите разобраться и потренироваться — есть вот такой клёвый симулятор: https://learngitbranching.js.org/). Jenkins — это конструктор пайплана CI/CD, Sonar (видимо, всё же SonarQube) — анализатор качества кода. ELK — это типовое решение для сбора и анализа логов, состоящее из трех open source решений: Elasticsearch, Logstash и Kibana. Logstash собирает и парсит логи и складывает их в БД Elasticsearch, а Kibana строит визуализации. Elasticsearch — NoSQL база данных и поисковый движок. Если у вас есть интеграции, скорее всего, у вас уже развернут ELK. Что интересно, аналитик практически никогда не пишет требования к сбору логов. Оно само как-то.

3. Принципы проектирования: ООП и паттерны ООП (называются GoF — Gang of Four, Банда Четырех, по четырем авторам); TDD — разработка через тестирование; Clean Code; это всё про программирование и конструкции внутри программы, аналитикам наверное не особо нужно. А вот о чем аналитик должен иметь представление: DDD, ACID, MVC, CAP-теорема. Если вы работаете с интеграциями — вам важнее ACID и CAP (а может и PACELC), если с вебом — MVC хотя бы на уровне концепции. Ну а DDD в любом случае.

4. Архитектурные паттерны: слоистая архитектура, микросервисы, публикация/подписка, клиент-сервер, EDA (событийно-ориентированная), гексагональная архитектура. Тут лучше всё изучить, особенно если вы занимаетесь интеграциями. Кроме, разве что, гексагональной архитектуры. Почему вообще гексагональная и MVC в разные разделы попали, я не очень понимаю. И куда дели Clean Architecture. Кажется, в 3 разделе больше про внутреннюю архитектуру, а тут больше про распределенные. Ну да ладно. Про разные виды архитектур в Systems.Education вот даже книгу перевели: https://systems.education/software-architecture-patterns

5. Платформенные знания. Контейнеры, оркестрация, облака, бессерверная архитектура, CDN, шлюзы, распределенные системы, CI/CD. Хотя бы понимать на уровне названий — что это такое, когда и для чего используется. API-шлюзы и оркестрация — это практически про интеграцию, CDN — про веб.

6. Данные и аналитика. Это тоже очень часто попадает в задачи аналитика. SQL, NoSQL, Kafkа — это всё знакомые слова. Data Streaming, OLAP, Object Storage, Data Migration — менее знакомые, но про миграции я регулярно слышу доклады, кажется это тоже попадает к аналитику.

7. Сети и безопасность. Уровень ниже, чем обычно смотрит аналитик, но, опять же, базовые понятия нужно знать, если вы работаете с интеграциями — например, разные виды обеспечения безопасности и аутентификации. А если вам критичная скорость, то можно и в TCP/IP занырнуть.

8. Дополнительные навыки: технологии, принятие решений, управление стейкхолдерами, коммуникация, оценки, лидерство. Тут, кажется, больше половины про аналитика, а то и все.

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

Сакраментальный вопрос: можно ли всё-таки дорасти до архитектора без опыта промышленного программирования? (Совсем без заглядывания в код и понимания, из чего он состоит, видимо, нет)

Сегодня 1 апреля, и IETF традиционно в этот день выпускает шуточные стандарты. Когда-то так появились стандарты на передачу IP-пакетов почтовыми голубями (RFC 1149, RFC 2549) и протокол Hyper Text Coffee Pot Control Protocol (RFC 2324), из которого пришла знаменитая ошибка HTTP 418 I'm a teapot. В 2022 вышел стандарт, запрещающий внесение багов в программный код (RFC 9225), в 2024 — предложения по протоколу FLIP (Faster Than Light Speed Protocol) — предлагающий передавать пакеты быстрее скорости света за счет их предугадывания на стороне приемника при помощи ИИ (RFC 9564).

Российские стандартизаторы тоже склонны к юмору, хотя и более тонкому. Например, у нас есть ГОСТ Р 43.0.21—2020 Информационное обеспечение техники и операторской деятельности. Сознание и самосознание.

Введен он, правда, не 1 апреля, а 1 февраля 2021.

Очень полезный ГОСТ! Цитирую область применения:

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

43 серия ГОСТов вообще вся прекрасна. Кроме сознания и самосознания там стандартизированы такие понятия, как деятельность (ГОСТ 43.0.20—2019), научение (ГОСТ 43.0.24—2021), системность (ГОСТ 43.0.30—2021), а на 2025 по Программе национальной стандартизации запланирована разработка ГОСТов на самоактуализацию и просветление. Номеров у стандартов пока нет, да и саму программу найти не так просто, но есть шифры темы: 1.0.487-1.015.23 и 1.0.487-1.016.23. То есть запланированы они были ещё в 23 году, работы велись в 23-24, к 01.04.2025 должны быть окончательные версии, а через год, в апреле 2026 нужно ждать утверждения.

Всего ГОСТов из этой серии уже 68 (!) штук на текущий момент.

Все они про информационное обеспечение техники и операторской деятельности, то есть это по сути про UI, UX, информационную архитектуру. Правда, внутри они основаны на "ноон-технологии" — это какая-то псевдонаука "нооника", следов которой нигде, кроме этих ГОСТов, не обнаруживается.

Все разработаны неким "Центром НООН-исследований", директором которого является человек, одновременно возглавляющий технический комитет по разработке этих стандартов — ТК 379 Росстандарта, а разрабатываются они за счет бюджетного финансирования. То есть, обычный бизнес — сам утверждает план разработки стандартов, сам же выигрывает конкурсы на их разработку, и так уже больше 20 лет. Вот такой юмор.

Впрочем, зато у нас теперь есть "ГОСТовское" определение системного анализа (из того же ГОСТ 43.0.30—2021):

Системный анализ — это практика улучшающего вмешательства в проблемные ситуации.

Вот так, ни больше, ни меньше. Можете ссылаться, ГОСТовское определение.

А основная идея системного анализа, сводится, цитирую:

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

Чеканные формулировки! Пользуемся! Всё по ГОСТу!

Ооо, IETF вчера выпустило RFC 9759 Unified Time Scaling for Temporal Coordination Frameworks (https://datatracker.ietf.org/doc/html/rfc9759) — фреймворк для оценивания сроков различных работ. Вот этого нам давно не хватало! Привожу таблицу для округления оценок оттуда. Теперь заживем, все эстимейты будут точнее — есть стандарт!

Я вообще редко делаю репосты, но иногда контент того стоит. Вот, например, отличные карточки (и док, пройдите по ссылке, скопируйте себе) про именование топиков в Кафке.

Тема типичная для bikeshedding'а (как это по-русски? Долгое обсуждение мелких малозначительных деталей). Нужно один раз договориться, и придерживаться правил.

Вот тут есть ещё парочка вариантов: https://cnr.sh/posts/2017-08-29-how-paint-bike-shed-kafka-topic-naming-conventions/ , https://www.kadeck.com/blog/kafka-topic-naming-conventions-5-recommendations-with-examples , все сходятся на следующих правилах:
1. маленькими буквами, через точку.
2. использовать названия бизнес-доменов, сущностей и событий, а не названия продюсеров, консьюмеров, схем данных и команд разработки (они могут меняться).
3. выделять внешние (public) и внутренние (private) топики

Про номер версии мнения расходятся, некоторые рекомендуют складывать не в название, а в header, ну это как с версионированием в HTTP: хотите ли вы до конца сохранять обратную совместимость, или хотите, чтобы старые клиенты побыстрее отвалились и перешли на новую версию?

А у вас какие правила именования топиков?