Самое противное в "аудиозаписи встречи" это потом это слушать. А точнее так: - мы ведем запись встречи и внтури успокоились - что если что упустили, то вроде как потом послушаем и поймем. - что бы послушать и найти тот самый (а то и не один) непонятный момент - нужно потратить почти столько же времени, как и на саму встречу. А его нет - в результате вместо того, что бы выясниь вопрос сразу и на месте - мы теряем еще столько же времени и понимаем, что можно было бы спросить сразу, а сейчас уже поздно. Или сложно получить доступ к нужному лицу.
"простые случаи перевода между языками человеческими (ru/ en)" - перевод между языкам человеческими как раз очень часто упирается в семантику. Потому как человеческий язык базируется на внутренних культурных образах, которые у народов с разными языками порой очень сильно не совпадают. И использование тут простых (дословных) переводчиков в лучшем случае делает текст плохочитаемым на другом языке. А в худшем (и наиболее частом) - смыслы искажаются, порой до полностью обратных.
По поводу перевода языка графики в XML и обратно. Ну во первых, любая компьютерная графика изначально существует в некоем НЕ-графическом языке - как минимум набор вызовов функций графического процессора. Пример - формат wmf, а далее уже форматы, в той или иной степени уходащие на дистанцию от графических примитивов графического процессора (SVG, EPS). Вплоть до автогенерации размещения элементов на итоговой картинке (DOT - Graphvis и прочие "diagrm-as-code"). Но самая главная проблема как раз в том, что такие языки возможно отражают семантику ФОРМИРОВАНИЯ КАРТИНКИ, но очень слабо или совсем никак не отображают семантику иллюстрируемого смысла. Даже весьма популярынй PlantUML. Он максимально близок к кодлированию именно смыслов модели, но всеравно более склоняестя к кодированию именно картинок. Пример: как только в подобном языке возникает возможность указать ЦВЕТ блока или стрелки, или возможность на концах стрелки задать разное количество разных закорючек - это уже про картинку а не про смысл. Про смысл будет, если мы эти цвета и закорючки сначала определим внутрь семантического шаблона, а потом уже с помощью таких шаблонов будем описывать предметную область. То есть разделяем вопросы "как нарисовать" от вопросов "каков смысл взаимоотношений".
"Такой инженер может не знать ни одного синтаксиса (языка), поэтому он передает смысл «человеку-интерпретатору» языка Б" - сильная мысль, но скорее всего - не правильная. Потому как мы (люди) судя по всему до сих пор слабо понимаем, что такое "смысл" и как он представлен у нас в мозгу (или где там он еще может быть представлен). Но передавать его мы умеем ТОЛКО через какую-нибудь знаковую систему. Через язык, через схемы, визуальными образами, в конце концов - кинестетически, ударами по лицу или заду. В любом случае исходный "смысл" перекодируется в "знаковую систему" а потом у получателя перекодируется обратно. И на каждом этапе НЕИЗБЕЖНЫ искажения. Можно ли определить некий "Эталонный" смысл и как то передать его таким образом БЕЗ искажений - не знаю. И будет ди это в таком случае передачей именно СМЫСЛА, или же еще одна комплексная знаковая система?
Очень.......странная статья. С одной стороны автор явно человек знающий, образованный, начитанный. В общем явно разбирается в том, о чем говорит. Даже в какой - то мере - фанатеет. Но сама статья скорее не статья а набор мыслей, фактов и ссылок. Поток сознания, выплеснутый на бумагу. И в этом выплеснутом, как в морском прибое на песчанном пляже очень много ценных (ну по крайней мере для меня лично) вещичек, идей, понятий, ссылок. Но в целом логика потерялась. Но за бриллианты, янтарь и ракушки в этом материале - огромное спасобо!
Касательно "вашего чеклиста". Список хороший, но есть 2 "НО":
Дублируется пункт про 404.
Не отражен, с моей точки зрения, критически важный момент (особенно с точки зрения аналитика) - удобство пользователя в рабочем процессе. Причем как это отобразить в таком списке и как его объективно оценивать - не совсем понятно. А суть вот в чем: когда я, как пользователь какого-то сервисе берусь им пользоваться, то обнаруживаю, что важные мне сейчас вещи находятся не в тех местах, уползают за границы первой страницы, требуют лишних кликов, вообще отсутствуюь, присутсвуют элементы, сейчас не нужные или раздражающие, иконки или шрифтовые выделения вводят в заблуждение, сильно долго ждать открытия динамических списков (это уже не очень к UI, но часто связано). Причем в чем основная печаль: когда дизайнер, аналитик, разработчик это се делает - кажется, что все красиво, правильно и удобно. Но они, эти дизайнеры, аналитики, разработчики находятся в процессе решения другой задачи. У них в этот момент другие акценты внимания, подсознательно другие критерии оценки. А как только они же но попытаются пройтись по логике именно применения пользователем, да еще не просто так, а когда от применения зависит или твое время или твоя зарпплата - тогда понимается, что "не на своем месте". Для этого, для наработки опыта, стоит включать каки-то образом и в процесс тестирования результата, с возможностью правок на следующей итерации. Тогда наработается опыт делать user-friendly интерфейс за минимальные итерации.
Мое возмущение не самим инструментом. Ему действительно можно и настройки "подкрутить" и вопросы по другому задавать. Мало того - интуитивно понятно, что польза тут может быть. Но для меня большая угроза не сам ИИ как таковой, а то, что многие "пользователи" вообще разучатся думать критически, и увеличиться объем никому не нужных текстов, в которых еще и очень трудно находить нестыковки. Или скажем так - нужно искать немного другие методы продуцирования ответов от ИИ и другие методы применения ИИ в жизни.
А Вы считаете эти традиции достойными подражания и преумножения с помощью ботов? Я то как раз за то ратую, что бы не тексты городить, а смыслы. Ну и по поводу нормативки. Язык там конечно тяжелый и много чего написано, но зачастую там присутствует вполне четкая и полная логика. Чего как раз не хватает ответам бота при всей внешней похожести.
По поводу содержательности текста стандартов у меня то же много вопросов. И именно к тому, на сколько конкретны формулировки, на сколько значимы и т.п. Стандарты помогают (по крайней мере одна из целей) не забыть что-то важное при проработке проекта. Откуда и много всяких разных слов. Ситуаций много. Но вопрос остается тот же - зачем в проектной документации триста тридцать три раза дублировать одно и то же, вместо того, что бы отражать только особенности и существенные вещи? И похоже пока такой технологии не разработали. Посему и приходиться копировать одно и то же из документа в документ.
Во первых по миграциям. Собственно с попытки сквошнуть все и началось. Джанга радостно взялась сжать миграции и радостно выдала ошибку - циклическая ссылка. Начал разбираться. А поскольку проект уже долгоживущий и файлов миграций несколько сотен - возникла необходимость разобраться со взаимозависимостями. В результате сжал часть миграций, которые не сильно пересекались между собой. Порядка 60 файлов сократил. Но понял, что в принципе это не имеет особого смысла. Потому как если Вы в проекте не занимались тем, что создали таблицу - удалили таблицу, создали поле - удалили поле, то сквош миграций по большому счету не уменьшает количества операций. А как следствие - не уменьшает времени выполнения миграций. Помочь может только замена ряда миграций на "create table". Но это уже сильно нужно все перелопачивать. И опять же - имея такую схему делать много проще. У меня этот проект мало того что долгоживущий, еще и установлен у пары десятков заказчиков в разных версиях, и обновляться они не спешат.
Ну а по поводу использования внешнего сервера для диаграмм - я сказал в тексте. В этом смысле установить себе в качестве зависимости request более целесообразная вещь. А с помощью этого сервиса можно строить МНОГО РАЗНЫХ диаграмм, зная как. Я же пример показал. А далее - все в Ваших руках!
Просмотрел Вашу статью. Не сказал бы что идея нова, но в общем с ней согласен. Мой подход немного о другом. О том как АВТОМАТИЗИРОВАТЬ процесс управления архитектурой. "модель" в этом смысле - что то как раз нематериальное, пока мы не материализуем ее хотя бы в виде документа или диаграммы. Пусть UML или C4 или BPM или чего еще. То что Вы называете "модель" я скорее называю "методикой". И после того, как мы "вынули" модель "из головы" - что и как с ней делать? Как ее оценить, как реализовать "в железе" или ИТ, или бизнеса. И даже не про саму реализацию, а про управление процессом реализации. Вот я о чем.
Со спорностью, а главное - упрощенностью - согласен. Именно упрощенно. И потому - тезисы. Это как раз начало попытки разобраться. Если кто-то даст на эти тезисы более НЕ упрощенный ответ - будет здорово. Ну и по поводу "документ" - "модель". Здесь "документ" скорее технический термин. А документами технически могут описываться и модели. Даже - должны. Но что это такое "модели", и как их "пощупать" - вот вопрос.
Собственно я про то, что "декларативный язык" или какой другой язык, но именно не просто картинки, как раз и формирует "документ". С помощью которого мы можем и описывать, и управлять архитектурой. Я как раз не понимаю других возможностей. Есть "картинка" - диаграмма в Visio, draw.io или еще чего. Но это только картинка. Есть желание хотя бы формировать ее на основе данных. И есть понимание - что этого недостаточно, что бы говорить "мы управляем архитектурой". А что "достаточно" - попытался изложить в заметке.
Самое противное в "аудиозаписи встречи" это потом это слушать. А точнее так:
- мы ведем запись встречи и внтури успокоились - что если что упустили, то вроде как потом послушаем и поймем.
- что бы послушать и найти тот самый (а то и не один) непонятный момент - нужно потратить почти столько же времени, как и на саму встречу. А его нет
- в результате вместо того, что бы выясниь вопрос сразу и на месте - мы теряем еще столько же времени и понимаем, что можно было бы спросить сразу, а сейчас уже поздно. Или сложно получить доступ к нужному лицу.
Немного по существу:
"простые случаи перевода между языками человеческими (ru/ en)" - перевод между языкам человеческими как раз очень часто упирается в семантику. Потому как человеческий язык базируется на внутренних культурных образах, которые у народов с разными языками порой очень сильно не совпадают. И использование тут простых (дословных) переводчиков в лучшем случае делает текст плохочитаемым на другом языке. А в худшем (и наиболее частом) - смыслы искажаются, порой до полностью обратных.
По поводу перевода языка графики в XML и обратно. Ну во первых, любая компьютерная графика изначально существует в некоем НЕ-графическом языке - как минимум набор вызовов функций графического процессора. Пример - формат wmf, а далее уже форматы, в той или иной степени уходащие на дистанцию от графических примитивов графического процессора (SVG, EPS). Вплоть до автогенерации размещения элементов на итоговой картинке (DOT - Graphvis и прочие "diagrm-as-code"). Но самая главная проблема как раз в том, что такие языки возможно отражают семантику ФОРМИРОВАНИЯ КАРТИНКИ, но очень слабо или совсем никак не отображают семантику иллюстрируемого смысла. Даже весьма популярынй PlantUML. Он максимально близок к кодлированию именно смыслов модели, но всеравно более склоняестя к кодированию именно картинок. Пример: как только в подобном языке возникает возможность указать ЦВЕТ блока или стрелки, или возможность на концах стрелки задать разное количество разных закорючек - это уже про картинку а не про смысл. Про смысл будет, если мы эти цвета и закорючки сначала определим внутрь семантического шаблона, а потом уже с помощью таких шаблонов будем описывать предметную область. То есть разделяем вопросы "как нарисовать" от вопросов "каков смысл взаимоотношений".
"Такой инженер может не знать ни одного синтаксиса (языка), поэтому он передает смысл «человеку-интерпретатору» языка Б" - сильная мысль, но скорее всего - не правильная. Потому как мы (люди) судя по всему до сих пор слабо понимаем, что такое "смысл" и как он представлен у нас в мозгу (или где там он еще может быть представлен). Но передавать его мы умеем ТОЛКО через какую-нибудь знаковую систему. Через язык, через схемы, визуальными образами, в конце концов - кинестетически, ударами по лицу или заду. В любом случае исходный "смысл" перекодируется в "знаковую систему" а потом у получателя перекодируется обратно. И на каждом этапе НЕИЗБЕЖНЫ искажения. Можно ли определить некий "Эталонный" смысл и как то передать его таким образом БЕЗ искажений - не знаю. И будет ди это в таком случае передачей именно СМЫСЛА, или же еще одна комплексная знаковая система?
Очень.......странная статья. С одной стороны автор явно человек знающий, образованный, начитанный. В общем явно разбирается в том, о чем говорит. Даже в какой - то мере - фанатеет. Но сама статья скорее не статья а набор мыслей, фактов и ссылок. Поток сознания, выплеснутый на бумагу. И в этом выплеснутом, как в морском прибое на песчанном пляже очень много ценных (ну по крайней мере для меня лично) вещичек, идей, понятий, ссылок. Но в целом логика потерялась.
Но за бриллианты, янтарь и ракушки в этом материале - огромное спасобо!
Касательно "вашего чеклиста". Список хороший, но есть 2 "НО":
Дублируется пункт про 404.
Не отражен, с моей точки зрения, критически важный момент (особенно с точки зрения аналитика) - удобство пользователя в рабочем процессе. Причем как это отобразить в таком списке и как его объективно оценивать - не совсем понятно. А суть вот в чем: когда я, как пользователь какого-то сервисе берусь им пользоваться, то обнаруживаю, что важные мне сейчас вещи находятся не в тех местах, уползают за границы первой страницы, требуют лишних кликов, вообще отсутствуюь, присутсвуют элементы, сейчас не нужные или раздражающие, иконки или шрифтовые выделения вводят в заблуждение, сильно долго ждать открытия динамических списков (это уже не очень к UI, но часто связано).
Причем в чем основная печаль: когда дизайнер, аналитик, разработчик это се делает - кажется, что все красиво, правильно и удобно. Но они, эти дизайнеры, аналитики, разработчики находятся в процессе решения другой задачи. У них в этот момент другие акценты внимания, подсознательно другие критерии оценки.
А как только они же но попытаются пройтись по логике именно применения пользователем, да еще не просто так, а когда от применения зависит или твое время или твоя зарпплата - тогда понимается, что "не на своем месте".
Для этого, для наработки опыта, стоит включать каки-то образом и в процесс тестирования результата, с возможностью правок на следующей итерации. Тогда наработается опыт делать user-friendly интерфейс за минимальные итерации.
Мое возмущение не самим инструментом. Ему действительно можно и настройки "подкрутить" и вопросы по другому задавать. Мало того - интуитивно понятно, что польза тут может быть. Но для меня большая угроза не сам ИИ как таковой, а то, что многие "пользователи" вообще разучатся думать критически, и увеличиться объем никому не нужных текстов, в которых еще и очень трудно находить нестыковки.
Или скажем так - нужно искать немного другие методы продуцирования ответов от ИИ и другие методы применения ИИ в жизни.
А Вы считаете эти традиции достойными подражания и преумножения с помощью ботов?
Я то как раз за то ратую, что бы не тексты городить, а смыслы.
Ну и по поводу нормативки. Язык там конечно тяжелый и много чего написано, но зачастую там присутствует вполне четкая и полная логика. Чего как раз не хватает ответам бота при всей внешней похожести.
По поводу содержательности текста стандартов у меня то же много вопросов. И именно к тому, на сколько конкретны формулировки, на сколько значимы и т.п. Стандарты помогают (по крайней мере одна из целей) не забыть что-то важное при проработке проекта. Откуда и много всяких разных слов. Ситуаций много.
Но вопрос остается тот же - зачем в проектной документации триста тридцать три раза дублировать одно и то же, вместо того, что бы отражать только особенности и существенные вещи? И похоже пока такой технологии не разработали. Посему и приходиться копировать одно и то же из документа в документ.
Во первых по миграциям. Собственно с попытки сквошнуть все и началось. Джанга радостно взялась сжать миграции и радостно выдала ошибку - циклическая ссылка. Начал разбираться. А поскольку проект уже долгоживущий и файлов миграций несколько сотен - возникла необходимость разобраться со взаимозависимостями. В результате сжал часть миграций, которые не сильно пересекались между собой. Порядка 60 файлов сократил. Но понял, что в принципе это не имеет особого смысла. Потому как если Вы в проекте не занимались тем, что создали таблицу - удалили таблицу, создали поле - удалили поле, то сквош миграций по большому счету не уменьшает количества операций. А как следствие - не уменьшает времени выполнения миграций. Помочь может только замена ряда миграций на "create table". Но это уже сильно нужно все перелопачивать. И опять же - имея такую схему делать много проще.
У меня этот проект мало того что долгоживущий, еще и установлен у пары десятков заказчиков в разных версиях, и обновляться они не спешат.
Ну а по поводу использования внешнего сервера для диаграмм - я сказал в тексте. В этом смысле установить себе в качестве зависимости request более целесообразная вещь. А с помощью этого сервиса можно строить МНОГО РАЗНЫХ диаграмм, зная как.
Я же пример показал. А далее - все в Ваших руках!
Просмотрел Вашу статью. Не сказал бы что идея нова, но в общем с ней согласен.
Мой подход немного о другом. О том как АВТОМАТИЗИРОВАТЬ процесс управления архитектурой. "модель" в этом смысле - что то как раз нематериальное, пока мы не материализуем ее хотя бы в виде документа или диаграммы. Пусть UML или C4 или BPM или чего еще. То что Вы называете "модель" я скорее называю "методикой".
И после того, как мы "вынули" модель "из головы" - что и как с ней делать? Как ее оценить, как реализовать "в железе" или ИТ, или бизнеса. И даже не про саму реализацию, а про управление процессом реализации. Вот я о чем.
Со спорностью, а главное - упрощенностью - согласен. Именно упрощенно. И потому - тезисы. Это как раз начало попытки разобраться. Если кто-то даст на эти тезисы более НЕ упрощенный ответ - будет здорово.
Ну и по поводу "документ" - "модель". Здесь "документ" скорее технический термин. А документами технически могут описываться и модели. Даже - должны. Но что это такое "модели", и как их "пощупать" - вот вопрос.
Собственно я про то, что "декларативный язык" или какой другой язык, но именно не просто картинки, как раз и формирует "документ". С помощью которого мы можем и описывать, и управлять архитектурой. Я как раз не понимаю других возможностей. Есть "картинка" - диаграмма в Visio, draw.io или еще чего. Но это только картинка. Есть желание хотя бы формировать ее на основе данных. И есть понимание - что этого недостаточно, что бы говорить "мы управляем архитектурой". А что "достаточно" - попытался изложить в заметке.