Лично я буду счастлив, если мои доклады будут качественно критиковать. Это весьма большая работа - провести анализ, оформить его и сделать выводы. Это уважение к работе автора и база для дискуссии и развития.
Я с большим уважением отношусь к вкладу в подход "Архитектура как код". Считаю, что пора выводить его из "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 лет, когда его купили.
Он действительно был физически доступен в крупных городах. Продавался в магазинах "Электроника". Стоил, примерно, около одного оклада инженера. Во всяком случае, я так запомнил по обсуждениям затрат. Точных цифр я не помню.
Доступность у каждого своя. Лишних денег у нас на тот момент не было. Мы жили не в городе. С работой были большие проблемы, как и с доступом к электронике.
Я не имею иного опыта. Делюсь только своим. Он субъективен, я это хорошо понимаю и ясно отмечаю в статье.
У меня нет морального права раскрывать иную точку зрения. Тем более давать какому-то взгляду на жизнь оценку. Уверен, если у кого-то возникнет желание рассказать об ином опыте, он это сделает с той целью, которую поставит перед собой.
Моя цель на сегодня: выразить солидарность с праздником "День Матери", подсветив роль матерей в судьбах их детей, в ракурсе особенностей нашей профессиональной области.
Не вижу связи. Все идет по плану. Если, вдруг, возникнут проблемы, мы их решим.
Кажется, что вы что-то конкретное хотите спросить, но вопросы, пока, очень абстрактные. Мне кажется, что стоит сформулировать полный и конкретный вопрос.
На подготовку этой статьи было потрачено около месяца. Отчасти она написана по материалам для выступлений. Но в большей части, мне потребовалось полностью переосмыслить ее изложение. Обеспечить достоверными ссылками на источники. Перепроверить себя.
Изначально мне казалось, что я просто возьму презентацию, напишу те слова, что говорю по ходу выступления и все получится. Но нет. Так не сработало. Презентация имеет смысловые фрагменты, которые легко разделяются. Статья - нет. При проведении презентации я имею обратную связь от аудитории и могу подстроиться. В статье от читателя многое что зависит. От того, что он сам хочет найти.
Я не считаю свое изложение мысли сильным. Но в чем я не сомневаюсь, это в тех смыслах, которые стараюсь донести.
Чтобы не огорчать читателя тратой времени, я проставил маркер сложности на максимум. В начале статьи предоставил ему выбор читать или смотреть видео. Чтобы это стало возможно, убедил организаторов конференции FlowConf опубликовать мое выступление раньше, вне принятых правил.
Я не ставил тег "я пиарюсь" потому, что не считаю так. Хотя, если это чему-то поможет, не вижу в этом проблемы. Я продвигаю подход и сообщество разделяющее его. Оно открыто. Каждый может повлиять на его развитие или продвигать так, как сам посчитает нужным.
Мне жаль, что вы не обнаружили чего-то полезного для своего роста в моей статье. Я старался. Обязательно учту свой опыт. Надеюсь, будущие статьи окажутся более понятными и ценными для вас.
Спасибо! Отличный комментарий. Много важных аспектов затронуто. Считаю необходимым для себя на него обстоятельно ответить. Но мне для этого потребуется время.
Спасибо за комментарии и замечания к тексту! Конечно, я буду исправлять все выявленные недостатки. Как в тексте, так в подходе и коде.
Крайне важно для развития учитывать конструктивную обратную связь. По этой причине я публикую статью и веду постоянную работу с сообществом.
Мне кажется, что я смогу исправить очевидные ошибки замеченные вами. Но вероятно, не все смыслы я уловлю из-за обилия антуражного текста. Если вас не затруднит, можете выразить конструктивные предложения для развития тезисно? Я бы с удовольствием вынес их на рассмотрение сообществом.
Однозначно. Он врастает в DevOps процессы. Без самого DevOps-инженера там делать с кодом особо нечего. Это будет просто замена картинок на код, но не достижение цели перехода. Ценность будет низкая.
Мне кажется, что вы очень точно сформулировали суть, что Архитектор 2.0 это не то, что думают об архитекторе обычно. Этот термин я использую как раз для того, чтобы ясно отделить смысл этой роли от "старого" смысла.
Допускаю, что эту роль можно было бы назвать как-то иначе. Типа ArchOps-инженер. Или что-то в этом духе. Но тогда целевая аудитория была бы не ясна.
В моей практике, переход происходит именно в среде действующих архитекторов. Лично я стремлюсь сохранить преемственность действующий практик, при четком формулировании вектора развития.
Мой опыт тоже противоречивый. С одной стороны, маркетплейс делает уникальные, очень выгодные предложения. Дает возожность списать СберСпасибо, прилично экономя. Но доставка порой отжигает.
Что интересно, в моем кейсе было по принципу "сделай плохо, а потом как было". Т.е. приходило СМС, что не могут доставить, а затем - приходите забирайте. Один раз все же недовезли.
С поиском нужно что-то делать.
Но, справедливости ради скажу, что принципиально не испытываю желание отказаться от площадки. Использую Озон и Алик. И там тоже есть свои очень серьезные для меня дефекты. СММ имеет скорее специфику.
Смотрите, я не буду ставить под сомнение ваш подход. Ровно потому, что не считаю свой верный. Да и, честно говоря, уже не могу его внятно сформулировать, на данном этапе. Скажем так - я наблюдаю и учусь по новой.
Так вот... удержать в голове можно очень ограниченный контекст. Т.е. способность осознания системы как целого, выявление ее недостатков и сильных сторон напрямую зависит от органических способностей человека.
Из этого можно, мне кажется, смело сказать - сложные системы не может проектировать один человек. Ему приходится ее упрощать для осознания. Так учат многие подходы. Но... система остается все такая же сложная.
Упрощение системы ведет лишь к отказу погружаться в частности. Это волевое решение принятия рисков. Волевое решение конкретной личности. Потому, что она не может погрузиться во все.
Таким образом, мне кажется, говорить о том, что система должна быть хорошо спроектирована, это как говорить - мир должен быть хорошо устроен. Может и должен. Но он такой, какой есть. Потому, что мы не можем его монополизировать. Даже свой участок в ДНП, мы не сможем сделать так как хотим.
В подходе "Архитектура как код" я вижу решение осознания большего. Через средства автоматизированного контроля. Через сегментирование архитектуры, оставляя при этом ее управляемой. Т.е. ты сможешь проектировать действительно большие системы в действительно большой команде.
Кажется, что этот подход должен значительно расширить органические возможности умных людей и заметно снизить врожденную силу других.
Говоря про IT как инструмент, скажу вам больше: как сотрудник для бизнеса вы тоже инструмент.
Да, скорее всего мы говорим об одном и том же. Но с разных ракурсов. Я уверен в величии ИТ. Но я совсем не уверен в величии любого ИТшника. ИТ это феномен человечества. А ИТшник, это человек, который этот феномен эксплуатирует.
Кто "ты" для бизнеса, решать тебе. Это не метафора. Именно тебе. Хочешь быть его инструментом? Будь. Хочешь использовать чей-то бизнес для получения стабильного дохода, чтобы выращивать новый вид гладиолусов? Разве можно тебе это запретить?
Но очевидно, люди приходят и уходят, на худой конец могут и заболеть, и так далее.
Очевидно и обратное - бизнесы уходят и приходят. Я чаще меняю работу, чем умираю. Так кто для кого в этой жизни?
Не уверен, что я вас понял верно. Но, скорее я вижу это так. В сегодняшнем, наблюдаемом мной мире. Хотя, можно сказать, что DevOps роль четко выделяемая уже на первом этапе разработки цифровых продуктов. В отличии от архитектора. Она как бы размазана. Принятие архитектурных решений в стартапе доверяется чуть меньше чем всем. Но область воздействия у них скорее ограничена.
Мне кажется,что в стартапе все единицы боевые. Степень влияния любой роли на продукт ограничена лишь желанием и способностью члена команды генерировать полезные идеи и доносить их.
Но в целом, почти всегда возникает технический лидер, с которым согласовываются ключевые решения. Лычки при этом могут быть разные.
И это, все же усредненный паттерн. Конкретный ролевой ландшафт напрямую зависит от самой команды. И очень быстро мутирует.
Вы как-то романтизируете бизнес. Или делаете его каким-то очень правильным. Нет. Бизнес по сути - комплекс мероприятий по получению выгоды из внешней среды с использованием доступных ресурсов. Это все.
И вот теперь, если взять его основу - бизнес всегда временен. Он получает доход из текущих потребностей кого-то, давая ему что-то. И это делается с учетом реальности мира и его технологий.
Если бизнес живет десятилетиями, то он эволюционирует. Сложно представить себе производство мерседеса сегодня с использованием технологий начала века. Причем это во всех смыслах. В том числе и в технологиях управления глобальными корпорациями.
Бизнес обязан видоизменяться и адаптироваться под внешние условия. В которых технологии дают ключевое конкурентное преимущество.
Я ИТ не возвеличиваю. Я изучаю его величие и отражаю в фактах. Как бы бизнес не считал, что ИТ его инструмент, он сегодня от него завист чуть меньше, чем полностью.
В приведенном примере фокус именно на отсутствии предложений по процессу в оригинальном докладе. Вероятно, эта информация просто не озвучена.
👍
Лично я буду счастлив, если мои доклады будут качественно критиковать. Это весьма большая работа - провести анализ, оформить его и сделать выводы. Это уважение к работе автора и база для дискуссии и развития.
Я с большим уважением отношусь к вкладу в подход "Архитектура как код". Считаю, что пора выводить его из "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 лет, когда его купили.
Он действительно был физически доступен в крупных городах. Продавался в магазинах "Электроника". Стоил, примерно, около одного оклада инженера. Во всяком случае, я так запомнил по обсуждениям затрат. Точных цифр я не помню.
Доступность у каждого своя. Лишних денег у нас на тот момент не было. Мы жили не в городе. С работой были большие проблемы, как и с доступом к электронике.
Вот такой, только желтенький был:
Вероятнее всего я изменю стиль подачи материала. Постараюсь исключить название и повествование "в лоб".
Я не имею иного опыта. Делюсь только своим. Он субъективен, я это хорошо понимаю и ясно отмечаю в статье.
У меня нет морального права раскрывать иную точку зрения. Тем более давать какому-то взгляду на жизнь оценку. Уверен, если у кого-то возникнет желание рассказать об ином опыте, он это сделает с той целью, которую поставит перед собой.
Моя цель на сегодня: выразить солидарность с праздником "День Матери", подсветив роль матерей в судьбах их детей, в ракурсе особенностей нашей профессиональной области.
Не вижу связи. Все идет по плану. Если, вдруг, возникнут проблемы, мы их решим.
Кажется, что вы что-то конкретное хотите спросить, но вопросы, пока, очень абстрактные. Мне кажется, что стоит сформулировать полный и конкретный вопрос.
А закрытые там есть?
На подготовку этой статьи было потрачено около месяца. Отчасти она написана по материалам для выступлений. Но в большей части, мне потребовалось полностью переосмыслить ее изложение. Обеспечить достоверными ссылками на источники. Перепроверить себя.
Изначально мне казалось, что я просто возьму презентацию, напишу те слова, что говорю по ходу выступления и все получится. Но нет. Так не сработало. Презентация имеет смысловые фрагменты, которые легко разделяются. Статья - нет. При проведении презентации я имею обратную связь от аудитории и могу подстроиться. В статье от читателя многое что зависит. От того, что он сам хочет найти.
Я не считаю свое изложение мысли сильным. Но в чем я не сомневаюсь, это в тех смыслах, которые стараюсь донести.
Чтобы не огорчать читателя тратой времени, я проставил маркер сложности на максимум. В начале статьи предоставил ему выбор читать или смотреть видео. Чтобы это стало возможно, убедил организаторов конференции FlowConf опубликовать мое выступление раньше, вне принятых правил.
Я не ставил тег "я пиарюсь" потому, что не считаю так. Хотя, если это чему-то поможет, не вижу в этом проблемы. Я продвигаю подход и сообщество разделяющее его. Оно открыто. Каждый может повлиять на его развитие или продвигать так, как сам посчитает нужным.
Мне жаль, что вы не обнаружили чего-то полезного для своего роста в моей статье. Я старался. Обязательно учту свой опыт. Надеюсь, будущие статьи окажутся более понятными и ценными для вас.
Спасибо! Отличный комментарий. Много важных аспектов затронуто. Считаю необходимым для себя на него обстоятельно ответить. Но мне для этого потребуется время.
Спасибо за комментарии и замечания к тексту! Конечно, я буду исправлять все выявленные недостатки. Как в тексте, так в подходе и коде.
Крайне важно для развития учитывать конструктивную обратную связь. По этой причине я публикую статью и веду постоянную работу с сообществом.
Мне кажется, что я смогу исправить очевидные ошибки замеченные вами. Но вероятно, не все смыслы я уловлю из-за обилия антуражного текста. Если вас не затруднит, можете выразить конструктивные предложения для развития тезисно? Я бы с удовольствием вынес их на рассмотрение сообществом.
Однозначно. Он врастает в DevOps процессы. Без самого DevOps-инженера там делать с кодом особо нечего. Это будет просто замена картинок на код, но не достижение цели перехода. Ценность будет низкая.
Мне кажется, что вы очень точно сформулировали суть, что Архитектор 2.0 это не то, что думают об архитекторе обычно. Этот термин я использую как раз для того, чтобы ясно отделить смысл этой роли от "старого" смысла.
Допускаю, что эту роль можно было бы назвать как-то иначе. Типа ArchOps-инженер. Или что-то в этом духе. Но тогда целевая аудитория была бы не ясна.
В моей практике, переход происходит именно в среде действующих архитекторов. Лично я стремлюсь сохранить преемственность действующий практик, при четком формулировании вектора развития.
Мой опыт тоже противоречивый. С одной стороны, маркетплейс делает уникальные, очень выгодные предложения. Дает возожность списать СберСпасибо, прилично экономя. Но доставка порой отжигает.
Что интересно, в моем кейсе было по принципу "сделай плохо, а потом как было". Т.е. приходило СМС, что не могут доставить, а затем - приходите забирайте. Один раз все же недовезли.
С поиском нужно что-то делать.
Но, справедливости ради скажу, что принципиально не испытываю желание отказаться от площадки. Использую Озон и Алик. И там тоже есть свои очень серьезные для меня дефекты. СММ имеет скорее специфику.
Смотрите, я не буду ставить под сомнение ваш подход. Ровно потому, что не считаю свой верный. Да и, честно говоря, уже не могу его внятно сформулировать, на данном этапе. Скажем так - я наблюдаю и учусь по новой.
Так вот... удержать в голове можно очень ограниченный контекст. Т.е. способность осознания системы как целого, выявление ее недостатков и сильных сторон напрямую зависит от органических способностей человека.
Из этого можно, мне кажется, смело сказать - сложные системы не может проектировать один человек. Ему приходится ее упрощать для осознания. Так учат многие подходы. Но... система остается все такая же сложная.
Упрощение системы ведет лишь к отказу погружаться в частности. Это волевое решение принятия рисков. Волевое решение конкретной личности. Потому, что она не может погрузиться во все.
Таким образом, мне кажется, говорить о том, что система должна быть хорошо спроектирована, это как говорить - мир должен быть хорошо устроен. Может и должен. Но он такой, какой есть. Потому, что мы не можем его монополизировать. Даже свой участок в ДНП, мы не сможем сделать так как хотим.
В подходе "Архитектура как код" я вижу решение осознания большего. Через средства автоматизированного контроля. Через сегментирование архитектуры, оставляя при этом ее управляемой. Т.е. ты сможешь проектировать действительно большие системы в действительно большой команде.
Кажется, что этот подход должен значительно расширить органические возможности умных людей и заметно снизить врожденную силу других.
Да, скорее всего мы говорим об одном и том же. Но с разных ракурсов. Я уверен в величии ИТ. Но я совсем не уверен в величии любого ИТшника. ИТ это феномен человечества. А ИТшник, это человек, который этот феномен эксплуатирует.
Кто "ты" для бизнеса, решать тебе. Это не метафора. Именно тебе. Хочешь быть его инструментом? Будь. Хочешь использовать чей-то бизнес для получения стабильного дохода, чтобы выращивать новый вид гладиолусов? Разве можно тебе это запретить?
Очевидно и обратное - бизнесы уходят и приходят. Я чаще меняю работу, чем умираю. Так кто для кого в этой жизни?
Все зависит от контекста (с)
Не уверен, что я вас понял верно. Но, скорее я вижу это так. В сегодняшнем, наблюдаемом мной мире. Хотя, можно сказать, что DevOps роль четко выделяемая уже на первом этапе разработки цифровых продуктов. В отличии от архитектора. Она как бы размазана. Принятие архитектурных решений в стартапе доверяется чуть меньше чем всем. Но область воздействия у них скорее ограничена.
Мне кажется, что в стартапе все единицы боевые. Степень влияния любой роли на продукт ограничена лишь желанием и способностью члена команды генерировать полезные идеи и доносить их.
Но в целом, почти всегда возникает технический лидер, с которым согласовываются ключевые решения. Лычки при этом могут быть разные.
И это, все же усредненный паттерн. Конкретный ролевой ландшафт напрямую зависит от самой команды. И очень быстро мутирует.
Вы как-то романтизируете бизнес. Или делаете его каким-то очень правильным. Нет. Бизнес по сути - комплекс мероприятий по получению выгоды из внешней среды с использованием доступных ресурсов. Это все.
И вот теперь, если взять его основу - бизнес всегда временен. Он получает доход из текущих потребностей кого-то, давая ему что-то. И это делается с учетом реальности мира и его технологий.
Если бизнес живет десятилетиями, то он эволюционирует. Сложно представить себе производство мерседеса сегодня с использованием технологий начала века. Причем это во всех смыслах. В том числе и в технологиях управления глобальными корпорациями.
Бизнес обязан видоизменяться и адаптироваться под внешние условия. В которых технологии дают ключевое конкурентное преимущество.
Я ИТ не возвеличиваю. Я изучаю его величие и отражаю в фактах. Как бы бизнес не считал, что ИТ его инструмент, он сегодня от него завист чуть меньше, чем полностью.