Однозначно. Чем качественнее промпт, тем лучше ответ.
Но не только этот путь улучшает ответ. Обучение и форматирование ответов на сервере тоже. Например, использование Outlines важный элемент, который я планирую использовать.
Бюджет остался без изменений - 400К. На кластер я сегодня не замахиваюсь. Это возможность масштабировать систему в будущем. Если это потребуется и будет рационально. Несомненно, это весомый плюс к выбору.
Про два хоста думал. Точнее думал, что вот есть ноут и возьму еще PC. Но быстро отказался в пользу eGPU на тот момент. Есть возможность объединять ресурс.
Дело в том, что я не уверен, что определенная мной конфигурация меня устроит. Мне нужен стенд на котором я смогу проверить все вероятные гипотезы. Когда они будут подтверждены, тут да, можно идти в специализацию железа.
Скоростью я в итоге пожертвовал в пользу общего объема памяти, отказавшись от Ultra. Мне, на текущем этапе, важнее возможность поставить больше экспериментов, чем поставить их быстро.
Пристально на него не смотрел. Но заметил при своем анализе. Главное там - низкая пропускная способность памяти.
Ключевое различие заключается в пропускной способности памяти. Унифицированная память M4 Max имеет значительно более высокую пропускную способность (до 819 ГБ/с), что критически важно для рабочих нагрузок, таких как редактирование видео, 3D-рендеринг и некоторые ИИ-задачи. Память на платформе AMD (около 250 ГБ/с) также быстрая, но сильно уступает в этом аспекте.
В совокупности с тем, что это тоже новая платформа, я не стал рисковать и выбрал проверенно и быстро.
Да, задача та же. Но реализация иная. В моей реализации граф знаний для LLM это древовидный, иерархический каталог знаний. Примерно так: в нем есть области знаний, в них разделы, в них секции, в них полки и т.д.. Что-то типа библиотечного устройства.
При вопросе к LLM я передаю запрос пользователя, а также, в системном промпте сообщаю LLM, что есть вот такие области знаний, и если тебе нужно запроси их.
В ответ я получаю или конечный ответ или запрос к области знаний от LLM. Если ответ, я отдаю его пользователю сразу. Если же LLM решила, что нужны данные из конкретной области, я отдаю ей следующий системный промпт с перечнем секций. И ожидаю ответа от нее опять. Так продолжается пока LLM не сгенерирует конечный ответ.
Этот подход позволяет гораздо качественнее отвечать на вопросы пользователя:
LLM неплохо транслирует некачественные запросы в более качественные и понимает какие области знаний затронуты. Похоже на предварительные рассуждения у некоторых моделей. Т.е. то, что классические ретривер простой векторизацией запроса не решает.
LLM не получает кучу сопутствующего хлама. Он идет строго по графу. Его фокус остается строгим на ответе. Это позволяет давать глубокие и качественные ответы.
По пути, который проходит LLM по графу, я могу судить о качестве графа и улучшать его. Т.е. возникает обратная связь с понятным механизмом оценки и улучшения.
И все это не требует классической векторной БД с чанками. Весь процесс можно реализовать на фронте (при определенных условиях и подходе). При этом, данные для ответа могут находиться в привычных для себя средах. Они запрашиваются только тогда, когда это нужно. Это радикально повышает их актуальность и снижает требования к обновлению и доставке данных в RAG и источников.
Хотя на первый взгляд может казаться, что тут LLM слишком греет воздух, но по факту, когда на классическом RAG пользователь задает несколько десятков вопросов, чтобы получить нужный ответ, затраты еще выше, т.к. запросов к LLM +/- столько же, только еще пользователь потеет.
Ах да... граф еще позволяет проверять гипотезы поиска информации. Т.е. давать несколько ответов на вопрос если он неоднозначный. Но эту фичу я еще не впилил. Только продумал как сделаю.
Курса особого нет. Это ориентир. Скажем так, вы не купите дешевле официального курса. А дальше работает удача и локальная конъюнктура.
В моем случае, думаю, имеет место новогодняя горячка. Возможно сейчас можно купить проще. В основном продавцы обещали именно после 12го пополнение запасов.
Плюс, я нахожусь в Питере. В Москве, судя по объявлениям, ценники ниже примерно на 20-30К. Но смысла ехать специально мне нет. На дорогу те же деньги уйдут. С таким же успехом можно прокатиться в Казахстан или туда, где официальный магазин есть. Эффект будет примерно тот же. Но цена ближе к $4000.
Сейчас на барахолке в Москве есть интересное предложение с ультрой (MAC Studio (M3 Ultra/ 28 CPU/ 60 GPU/ 256GB/ 1TB) за 530К. Это очень близко к оригинальному ценнику по официальному курсу (80). Насколько оно реальное - не знаю.
Это ориентир, который я сложил у себя в голове по результатам чтения статей. Сейчас гоняю квалификацию (контрольные вопросы) на разных моделях. По результатам сложу уже собственное понимание. Планирую поделиться результатом.
Сложно ответить на этот вопрос. DocHub мой FOSS продукт. Им пользуются достаточно много компаний. Они иногда обращаются за помощью. Именно для него создаются агенты. Точнее для его новой версии. Также, сейчас я работаю корпоративным архитектором и работодатель не связан с моим продуктом, но я его использую для совей работы. Все это приводит к тому, что я оперирую чувствительной информацией.
Думаю, на год-два мне хватит. А там посмотрим, куда выведет тренд с мини AI станциями.
Сама по себе студия это очень мощная рабочая станция под широкий спектр задач. Плюс, в статье я убрал это как перегруз информацией, но она очень удобна в бытовом плане: компактная; выглядит красиво; экономична.
В общем, если она морально устареет для AI, то для других задач ее хватит еще очень на долго.
На вторичном рынке, кстати, до сих пор M2 продают. И я бы не назвал цену бросовой.
Если ты профессионально и глубоко занимаешься языком, ты быстро впитываешь то, что здесь изложено.
Лично я порой обхожу использование некоторых конструкций т.к. не могу быть уверен в их использовании. Эта статья помогает понять их и реально расширяет мой инструментальный набор.
Следующий современный аспект, это использование статей как промптов ИИ. Например, у меня уже есть промпты которые я переношу из проекта в проект и они помогают решать нетривиальные задачи и находить неочевидные проблемы. Статьи в этом плане прекрасны, т.к. имеют примеры и ИИ хорошо по ним делает выводы.
Помню, я курсовую сдал в Comic Sans. Всем понравилось.
Чтобы критиковать сегодня Скрепыша, нужно смотреть на мир глазами "ушедшего мира".
В "том мире" создавались фундаментальные основы будущих UI и пользовательского опыта. Серепыш сегодня это AI ассистенты. Для меня именно он первый ассистент. И, честно говоря, на мой взгляд, не так уж далеко современные ассистенты ушли по пользе от него.
Но у Скрепыша точно была душа, настроение и главное - он никогда не отчаивался и пытался помочь ну хоть чем-то!
Лично я буду счастлив, если мои доклады будут качественно критиковать. Это весьма большая работа - провести анализ, оформить его и сделать выводы. Это уважение к работе автора и база для дискуссии и развития.
Я с большим уважением отношусь к вкладу в подход "Архитектура как код". Считаю, что пора выводить его из "pet" во взрослые промышленные решения. Растить его зрелость.
Для этого нам нужна открытая экспертная дискуссия. Именно это меня мотивирует написать рецензию на данную статью, а в оригинале на видео конференции ArchDays.
Анализ: Внимательно изучил видео и репозиторий проекта. Предложенная идея и ее реализация стоит внимания потому, что старается решить актуальную задача - устранить разрыв между проектной документацией и реализацией. Это одна из ключевых проблем лежащих в основе самой ценности проектирования. Также, важным является наличие потенциала к автоматизации.
Однако, в идее есть врожденные ограничения из-за попытки все "упростить". На мой взгляд, именно они будут сковывать применение.
Видео метка (0:00): Отличное, мягкое погружение в тему и проблематику. Откровенно завидую подаче материала и способности объяснять все просто.
Видео метка (4:10) Рассматриваются два языка описания диаграмм кодом PlantUML и Structurizr. Утверждается, что они одинаковы по мощностям. Это неверно. PlantUML имеет гораздо более широкие возможности по устоявшимся нотациям. Например, позволяет описать диаграммы взаимодействия, сетевые зоны, алгоритмы и т.п. Structurizr вводит свою нотацию - C4 Model. Это, по сути, все, что он готов нам предложить.
Видео метка (4:31) Предлагается "выкинуть" все из PlantUML и оставить только нотацию С4 Model катастрофически сократив возможности PlantUML. Встает вопрос - почему не взять сразу Structurizr? Скорее всего, потому, что он не дает всех тех возможностей, что есть у PlantUML по созданию своего DSL.
Видео метка (5:11) Утверждается, что все очень просто, т.к. больше ничего и не нужно кроме C4 Model. Это утверждение неверное. C4 Model недостаточна для полноценного описания архитектуры решения. Например, важны не только связи, но и их последовательность.
Видео метка (5:52) Подводится промежуточный итог. Мне кажется важным в него добавить: Взят PlantUML и обрезан до C4 Model волевым решением автора потому, что "больше ничего не нужно". Это фундаментальное решение из которого затем строятся все выводы доклада и ценность идеи.
Видео метка (6:45) Заявляются проблемы: 1. Актуальность архитектурного описания; 2. Достаточность архитектурного описания (декларативность). Здесь хочется отметить, что до этого были "отрезаны" от PlantUML имеющиеся возможности для этого; 3. Отсутствие контроля.
Видео метка (9:00) Звучат слова, которые подменивают суть произошедшего до этого. Говорится, что у нас теперь архитектура as code. Это неверно. У нас все еще диаграммы как код. Они, т.е. диаграммы, описывают архитектурное решение для восприятия человеком. Их код лишь помогает работать с диаграммами как кодом. Т.е. это Doc as Code и DocOps. Именно по этой причине, одна диаграмма не описывает полноту архитектурного решения. Человек не способен прочесть такую диаграмму.
Видео метка (10:27) Стоп... а почему мы оперируем всего тремя сущностями из C4 Model? Где сущность software system (не внешней, а нашей системы)? Выглядит так, что мы не просто взяли C4 Model, но и отрезали от него все кроме описания контейнеров.
Видео метка (12:44) Вводится идея "поженить" IaaC с AaaC. Т.е. рассматриваются широкие понятия, которые включают в себя, например Terraform как индустриальный стандарт для облаков. Но вводится очередное ограничение - k8s. Это аргументированно объясняется. У кубера конфиги. Их мы можем однозначно интерпретировать. Но, например, с Terraformom такой "фокус" не пройдет. Т.к. он может включать в себя алгоритмические конструкции и условия.
На этом этапе у меня создалось впечатление, что широкий заход на IaaC и AaaC, фактически, реализуется тотально урезанной нотацией PlantUML для использования в паре к k8s. Т.е. решение имеет крайне узкую нишу применения.
Видео метка (15:00) Объясняется как можно сверить архитектурное решение заложенное в диаграммы и конфигурацию кубера. Для этого, очевидно, нужно распарсить все диаграммы и все конфиги. Выглядит несложно технически. На деле, это значит, что нужно организовать управление диаграммами в определенной нотации. Ввести внутренние соглашения о их размещении и актуализации...
Стоп... актуализации? Т.е. та самая проблема, которая должна была решиться, возникает в новом качестве? Теперь она блокирует развертывание не только, если у вас что-то в коде и конфиге не так. Теперь придется найти ту самую диаграмму которая не сходится с конфигом и ее тоже поправить. Как ее найти? Кто поправить должен? Решение не предложено.
Видео метка (19:00) Очевидно, что базового языка PlantUML недостаточно для задач, которые сформулированы. Нужны дополнительные метаданные. Для этого предлагается ввести теги. PlantUML тут хорошо помогает. Но проблема в том, что эти теги должны как-то декларироваться. Кем? Как? Если этого решения нет, то вероятность ошибок в коде диаграмм будет велико, что может создавать серьезные проблемы для развертывания. Ведь без тестов мы не катим теперь?
Далее вводится еще масса кастомных форматов и семантики. Становится ясно, что для комфортного использования данного решения потребуется инструментарий в IDE.
Выводы: 1. Решение имеет определенный потенциал к развитию. Для этого его требуется обогатить инструментарием, который позволит участникам производственного процесса удобно писать необходимый код, а также локализовывать источники проблем для быстрого устранения.
2. Решение имеет узкий ландшафт практического применения. На мой взгляд эта проблема в текущей концепции неразрешима. Требуется отказаться от идеи, что код диаграмм это код архитектуры. Код архитектуры должен полностью описывать архитектурное решение, позволяя генерировать необходимые артефакты. В том числе и диаграммы.
3. Несомненно, пройденный путь и идеи делают ценный значительный вклад в развитие и популяризацию подхода AaaC.
Откликнуться на этот тред мне посоветовала моя встроенная социализация выраженная в разделении позиции с @AlexanderSМне импонирует его мнение и я буду тяготеть к сообществу таких людей. Мыслящих не шаблонами, а множествами вариантов из которых выбор будет делаться на основании аргументов и анализа.
У меня очень много коммуникаций, из которых я вынужден фильтровать только ценную информацию. К сожалению, в ваших сообщениях слишком мало аргументов, для того, чтобы они оказались интересными. Обычно я такое быстро забываю. Тем более, что их эмоциональная окраска, ярко продемонстрировала вашу поверхностность и ранимость. Изначально, я не планировал на них реагировать.
Изучение профиля для меня рутинная операция. Очевидно, что отдельный социальный мессадж не может описывать человека в целом. Поэтому, я всегда, для начала, исследую "следы" автора в сообществах. И только потом начинаю дискуссию сложив мнение. Если, конечно, в ней остается смысл.
О сложившемся у меня мнении я вам уже сообщил. Вам следует им просто располагать. Вероятнее всего оно вам с течением времени поможет.
Удачи!
P.S. Или... вы станете моим хейтером и это поможет мне. Выбор за вами. Конформизм или конформизм? Выбирать вам.
Я признаю ваше мнение как часть объективного мира. Вы мое, судя по постам - нет.
Какую цель вы преследуете? Выгляди так, что вы настаиваете на принятие вашего мнения как единственно верного.
Конфо́рмность — изменение в поведении или мнении человека под влиянием реального или воображаемого давления со стороны другого человека или группы людей.
Так какие говорите у вас ценности?
Это далеко не одно наблюдаемое мной противоречие в вашей позиции. Сами прочтите свой профиль. Кажется, что вы просто ищите что-то. Что сами не понимаете. И... кажется, что, просто, этот "опус" вас тронул. У вас возникла тревога. Но не за меня... а внутри вас.
Возможно вам просто нужно кому-то научиться доверять.
Мне кажется, время в детстве значительно "плотнее". Каждый день как маленькая жизнь. У тебя постоянно что-то новое происходит. Тело постоянно меняется. Тебе каждый день говорят, как ты вырос. Это как бы норма. Плюс/минус изменение голоса не сильно заметно. Тем более, что сам ты этого "не слышишь". Я не замечал.
Эльбрус именно ZX Spectrum. Производился в Нальчике заводом "НЗТА" (Нальчикский Завод Телемеханической Аппаратуры) в 1989-1993 годах. Мне было, около 12 лет, когда его купили.
Он действительно был физически доступен в крупных городах. Продавался в магазинах "Электроника". Стоил, примерно, около одного оклада инженера. Во всяком случае, я так запомнил по обсуждениям затрат. Точных цифр я не помню.
Доступность у каждого своя. Лишних денег у нас на тот момент не было. Мы жили не в городе. С работой были большие проблемы, как и с доступом к электронике.
Пока только так:
Дальше иду на сервер из DocHubIDE (мой продукт) и ставлю эксперименты, которые делал с моделями, доступными у агрегаторов.
Я запускаю и через ollama и mlx. Стараюсь через mlx. Но не все модели адаптированы. Поэтому, для тестов, от ollama у меня отказаться не получается.
С кластерами я пока не заморачивался. Учту. Спасибо!
Однозначно. Чем качественнее промпт, тем лучше ответ.
Но не только этот путь улучшает ответ. Обучение и форматирование ответов на сервере тоже. Например, использование Outlines важный элемент, который я планирую использовать.
Бюджет остался без изменений - 400К. На кластер я сегодня не замахиваюсь. Это возможность масштабировать систему в будущем. Если это потребуется и будет рационально. Несомненно, это весомый плюс к выбору.
Про два хоста думал. Точнее думал, что вот есть ноут и возьму еще PC. Но быстро отказался в пользу eGPU на тот момент. Есть возможность объединять ресурс.
Дело в том, что я не уверен, что определенная мной конфигурация меня устроит. Мне нужен стенд на котором я смогу проверить все вероятные гипотезы. Когда они будут подтверждены, тут да, можно идти в специализацию железа.
Скоростью я в итоге пожертвовал в пользу общего объема памяти, отказавшись от Ultra. Мне, на текущем этапе, важнее возможность поставить больше экспериментов, чем поставить их быстро.
Пристально на него не смотрел. Но заметил при своем анализе. Главное там - низкая пропускная способность памяти.
В совокупности с тем, что это тоже новая платформа, я не стал рисковать и выбрал проверенно и быстро.
Да, задача та же. Но реализация иная. В моей реализации граф знаний для LLM это древовидный, иерархический каталог знаний. Примерно так: в нем есть области знаний, в них разделы, в них секции, в них полки и т.д.. Что-то типа библиотечного устройства.
При вопросе к LLM я передаю запрос пользователя, а также, в системном промпте сообщаю LLM, что есть вот такие области знаний, и если тебе нужно запроси их.
В ответ я получаю или конечный ответ или запрос к области знаний от LLM. Если ответ, я отдаю его пользователю сразу. Если же LLM решила, что нужны данные из конкретной области, я отдаю ей следующий системный промпт с перечнем секций. И ожидаю ответа от нее опять. Так продолжается пока LLM не сгенерирует конечный ответ.
Этот подход позволяет гораздо качественнее отвечать на вопросы пользователя:
LLM неплохо транслирует некачественные запросы в более качественные и понимает какие области знаний затронуты. Похоже на предварительные рассуждения у некоторых моделей. Т.е. то, что классические ретривер простой векторизацией запроса не решает.
LLM не получает кучу сопутствующего хлама. Он идет строго по графу. Его фокус остается строгим на ответе. Это позволяет давать глубокие и качественные ответы.
По пути, который проходит LLM по графу, я могу судить о качестве графа и улучшать его. Т.е. возникает обратная связь с понятным механизмом оценки и улучшения.
И все это не требует классической векторной БД с чанками. Весь процесс можно реализовать на фронте (при определенных условиях и подходе). При этом, данные для ответа могут находиться в привычных для себя средах. Они запрашиваются только тогда, когда это нужно. Это радикально повышает их актуальность и снижает требования к обновлению и доставке данных в RAG и источников.
Хотя на первый взгляд может казаться, что тут LLM слишком греет воздух, но по факту, когда на классическом RAG пользователь задает несколько десятков вопросов, чтобы получить нужный ответ, затраты еще выше, т.к. запросов к LLM +/- столько же, только еще пользователь потеет.
Ах да... граф еще позволяет проверять гипотезы поиска информации. Т.е. давать несколько ответов на вопрос если он неоднозначный. Но эту фичу я еще не впилил. Только продумал как сделаю.
Курса особого нет. Это ориентир. Скажем так, вы не купите дешевле официального курса. А дальше работает удача и локальная конъюнктура.
В моем случае, думаю, имеет место новогодняя горячка. Возможно сейчас можно купить проще. В основном продавцы обещали именно после 12го пополнение запасов.
Плюс, я нахожусь в Питере. В Москве, судя по объявлениям, ценники ниже примерно на 20-30К. Но смысла ехать специально мне нет. На дорогу те же деньги уйдут. С таким же успехом можно прокатиться в Казахстан или туда, где официальный магазин есть. Эффект будет примерно тот же. Но цена ближе к $4000.
Сейчас на барахолке в Москве есть интересное предложение с ультрой (MAC Studio (M3 Ultra/ 28 CPU/ 60 GPU/ 256GB/ 1TB) за 530К. Это очень близко к оригинальному ценнику по официальному курсу (80). Насколько оно реальное - не знаю.
В общем, как и пишу в статье - дикий рынок.
Спасибо!
Это ориентир, который я сложил у себя в голове по результатам чтения статей. Сейчас гоняю квалификацию (контрольные вопросы) на разных моделях. По результатам сложу уже собственное понимание. Планирую поделиться результатом.
Сложно ответить на этот вопрос. DocHub мой FOSS продукт. Им пользуются достаточно много компаний. Они иногда обращаются за помощью. Именно для него создаются агенты. Точнее для его новой версии. Также, сейчас я работаю корпоративным архитектором и работодатель не связан с моим продуктом, но я его использую для совей работы. Все это приводит к тому, что я оперирую чувствительной информацией.
Спасибо! Прислушаюсь.
Спасибо!
Думаю, на год-два мне хватит. А там посмотрим, куда выведет тренд с мини AI станциями.
Сама по себе студия это очень мощная рабочая станция под широкий спектр задач. Плюс, в статье я убрал это как перегруз информацией, но она очень удобна в бытовом плане: компактная; выглядит красиво; экономична.
В общем, если она морально устареет для AI, то для других задач ее хватит еще очень на долго.
На вторичном рынке, кстати, до сих пор M2 продают. И я бы не назвал цену бросовой.
Если ты профессионально и глубоко занимаешься языком, ты быстро впитываешь то, что здесь изложено.
Лично я порой обхожу использование некоторых конструкций т.к. не могу быть уверен в их использовании. Эта статья помогает понять их и реально расширяет мой инструментальный набор.
Следующий современный аспект, это использование статей как промптов ИИ. Например, у меня уже есть промпты которые я переношу из проекта в проект и они помогают решать нетривиальные задачи и находить неочевидные проблемы. Статьи в этом плане прекрасны, т.к. имеют примеры и ИИ хорошо по ним делает выводы.
Жив в нашей памяти 100% и... расширяется:))
Помню, я курсовую сдал в Comic Sans. Всем понравилось.
Чтобы критиковать сегодня Скрепыша, нужно смотреть на мир глазами "ушедшего мира".
В "том мире" создавались фундаментальные основы будущих UI и пользовательского опыта. Серепыш сегодня это AI ассистенты. Для меня именно он первый ассистент. И, честно говоря, на мой взгляд, не так уж далеко современные ассистенты ушли по пользе от него.
Но у Скрепыша точно была душа, настроение и главное - он никогда не отчаивался и пытался помочь ну хоть чем-то!
В приведенном примере фокус именно на отсутствии предложений по процессу в оригинальном докладе. Вероятно, эта информация просто не озвучена.
?
Лично я буду счастлив, если мои доклады будут качественно критиковать. Это весьма большая работа - провести анализ, оформить его и сделать выводы. Это уважение к работе автора и база для дискуссии и развития.
Я с большим уважением отношусь к вкладу в подход "Архитектура как код". Считаю, что пора выводить его из "pet" во взрослые промышленные решения. Растить его зрелость.
Для этого нам нужна открытая экспертная дискуссия. Именно это меня мотивирует написать рецензию на данную статью, а в оригинале на видео конференции ArchDays.
Анализ:
Внимательно изучил видео и репозиторий проекта. Предложенная идея и ее реализация стоит внимания потому, что старается решить актуальную задача - устранить разрыв между проектной документацией и реализацией. Это одна из ключевых проблем лежащих в основе самой ценности проектирования. Также, важным является наличие потенциала к автоматизации.
Однако, в идее есть врожденные ограничения из-за попытки все "упростить". На мой взгляд, именно они будут сковывать применение.
Видео метка (0:00): Отличное, мягкое погружение в тему и проблематику. Откровенно завидую подаче материала и способности объяснять все просто.
Видео метка (4:10) Рассматриваются два языка описания диаграмм кодом PlantUML и Structurizr. Утверждается, что они одинаковы по мощностям. Это неверно. PlantUML имеет гораздо более широкие возможности по устоявшимся нотациям. Например, позволяет описать диаграммы взаимодействия, сетевые зоны, алгоритмы и т.п. Structurizr вводит свою нотацию - C4 Model. Это, по сути, все, что он готов нам предложить.
Видео метка (4:31) Предлагается "выкинуть" все из PlantUML и оставить только нотацию С4 Model катастрофически сократив возможности PlantUML. Встает вопрос - почему не взять сразу Structurizr? Скорее всего, потому, что он не дает всех тех возможностей, что есть у PlantUML по созданию своего DSL.
Видео метка (5:11) Утверждается, что все очень просто, т.к. больше ничего и не нужно кроме C4 Model. Это утверждение неверное. C4 Model недостаточна для полноценного описания архитектуры решения. Например, важны не только связи, но и их последовательность.
Видео метка (5:52) Подводится промежуточный итог. Мне кажется важным в него добавить: Взят PlantUML и обрезан до C4 Model волевым решением автора потому, что "больше ничего не нужно". Это фундаментальное решение из которого затем строятся все выводы доклада и ценность идеи.
Видео метка (6:45) Заявляются проблемы:
1. Актуальность архитектурного описания;
2. Достаточность архитектурного описания (декларативность). Здесь хочется отметить, что до этого были "отрезаны" от PlantUML имеющиеся возможности для этого;
3. Отсутствие контроля.
Видео метка (9:00) Звучат слова, которые подменивают суть произошедшего до этого. Говорится, что у нас теперь архитектура as code. Это неверно. У нас все еще диаграммы как код. Они, т.е. диаграммы, описывают архитектурное решение для восприятия человеком. Их код лишь помогает работать с диаграммами как кодом. Т.е. это Doc as Code и DocOps. Именно по этой причине, одна диаграмма не описывает полноту архитектурного решения. Человек не способен прочесть такую диаграмму.
Видео метка (10:27) Стоп... а почему мы оперируем всего тремя сущностями из C4 Model? Где сущность software system (не внешней, а нашей системы)? Выглядит так, что мы не просто взяли C4 Model, но и отрезали от него все кроме описания контейнеров.
Видео метка (12:44) Вводится идея "поженить" IaaC с AaaC. Т.е. рассматриваются широкие понятия, которые включают в себя, например Terraform как индустриальный стандарт для облаков. Но вводится очередное ограничение - k8s. Это аргументированно объясняется. У кубера конфиги. Их мы можем однозначно интерпретировать. Но, например, с Terraformom такой "фокус" не пройдет. Т.к. он может включать в себя алгоритмические конструкции и условия.
На этом этапе у меня создалось впечатление, что широкий заход на IaaC и AaaC, фактически, реализуется тотально урезанной нотацией PlantUML для использования в паре к k8s. Т.е. решение имеет крайне узкую нишу применения.
Видео метка (15:00) Объясняется как можно сверить архитектурное решение заложенное в диаграммы и конфигурацию кубера. Для этого, очевидно, нужно распарсить все диаграммы и все конфиги. Выглядит несложно технически. На деле, это значит, что нужно организовать управление диаграммами в определенной нотации. Ввести внутренние соглашения о их размещении и актуализации...
Стоп... актуализации? Т.е. та самая проблема, которая должна была решиться, возникает в новом качестве? Теперь она блокирует развертывание не только, если у вас что-то в коде и конфиге не так. Теперь придется найти ту самую диаграмму которая не сходится с конфигом и ее тоже поправить. Как ее найти? Кто поправить должен? Решение не предложено.
Видео метка (19:00) Очевидно, что базового языка PlantUML недостаточно для задач, которые сформулированы. Нужны дополнительные метаданные. Для этого предлагается ввести теги. PlantUML тут хорошо помогает. Но проблема в том, что эти теги должны как-то декларироваться. Кем? Как? Если этого решения нет, то вероятность ошибок в коде диаграмм будет велико, что может создавать серьезные проблемы для развертывания. Ведь без тестов мы не катим теперь?
Далее вводится еще масса кастомных форматов и семантики. Становится ясно, что для комфортного использования данного решения потребуется инструментарий в IDE.
Выводы:
1. Решение имеет определенный потенциал к развитию. Для этого его требуется обогатить инструментарием, который позволит участникам производственного процесса удобно писать необходимый код, а также локализовывать источники проблем для быстрого устранения.
2. Решение имеет узкий ландшафт практического применения. На мой взгляд эта проблема в текущей концепции неразрешима. Требуется отказаться от идеи, что код диаграмм это код архитектуры. Код архитектуры должен полностью описывать архитектурное решение, позволяя генерировать необходимые артефакты. В том числе и диаграммы.
3. Несомненно, пройденный путь и идеи делают ценный значительный вклад в развитие и популяризацию подхода AaaC.
P.S. Большое спасибо за Вашу работу!
Откликнуться на этот тред мне посоветовала моя встроенная социализация выраженная в разделении позиции с @AlexanderSМне импонирует его мнение и я буду тяготеть к сообществу таких людей. Мыслящих не шаблонами, а множествами вариантов из которых выбор будет делаться на основании аргументов и анализа.
У меня очень много коммуникаций, из которых я вынужден фильтровать только ценную информацию. К сожалению, в ваших сообщениях слишком мало аргументов, для того, чтобы они оказались интересными. Обычно я такое быстро забываю. Тем более, что их эмоциональная окраска, ярко продемонстрировала вашу поверхностность и ранимость. Изначально, я не планировал на них реагировать.
Изучение профиля для меня рутинная операция. Очевидно, что отдельный социальный мессадж не может описывать человека в целом. Поэтому, я всегда, для начала, исследую "следы" автора в сообществах. И только потом начинаю дискуссию сложив мнение. Если, конечно, в ней остается смысл.
О сложившемся у меня мнении я вам уже сообщил. Вам следует им просто располагать. Вероятнее всего оно вам с течением времени поможет.
Удачи!
P.S. Или... вы станете моим хейтером и это поможет мне. Выбор за вами. Конформизм или конформизм? Выбирать вам.
Я признаю ваше мнение как часть объективного мира. Вы мое, судя по постам - нет.
Какую цель вы преследуете? Выгляди так, что вы настаиваете на принятие вашего мнения как единственно верного.
Конфо́рмность — изменение в поведении или мнении человека под влиянием реального или воображаемого давления со стороны другого человека или группы людей.Так какие говорите у вас ценности?
Это далеко не одно наблюдаемое мной противоречие в вашей позиции. Сами прочтите свой профиль. Кажется, что вы просто ищите что-то. Что сами не понимаете. И... кажется, что, просто, этот "опус" вас тронул. У вас возникла тревога. Но не за меня... а внутри вас.
Возможно вам просто нужно кому-то научиться доверять.
Мне кажется, время в детстве значительно "плотнее". Каждый день как маленькая жизнь. У тебя постоянно что-то новое происходит. Тело постоянно меняется. Тебе каждый день говорят, как ты вырос. Это как бы норма. Плюс/минус изменение голоса не сильно заметно. Тем более, что сам ты этого "не слышишь". Я не замечал.
Эльбрус именно ZX Spectrum. Производился в Нальчике заводом "НЗТА" (Нальчикский Завод Телемеханической Аппаратуры) в 1989-1993 годах. Мне было, около 12 лет, когда его купили.
Он действительно был физически доступен в крупных городах. Продавался в магазинах "Электроника". Стоил, примерно, около одного оклада инженера. Во всяком случае, я так запомнил по обсуждениям затрат. Точных цифр я не помню.
Доступность у каждого своя. Лишних денег у нас на тот момент не было. Мы жили не в городе. С работой были большие проблемы, как и с доступом к электронике.
Вот такой, только желтенький был: