Реализмом в симах не пахнет и сегодня. Для реализма не хватает real-time процессов. Если дом будет строиться пусть даже три недели, как у китайцев, это убьет весь игровой процесс.
Летом 2011 я на три недели съездил на Мальту. А вернувшись с нее, слег с болевым синдромом вследствие грыжи межпозвоночных дисков пояснично-крестцового отдела. С этого момента началось мое хождение по мукам. Были и таблетки, и уколы, и даже полтора года хождения в центр Бубновского в Сокольниках. А потом через отцовские связи в 2014 году нашелся ортовертеброневролог, который рефлексотерапией за какие-то 10 сеансов поставил меня на ноги, и "снял с иглы" постоянных забегов по врачам. Еще несколько лет я к нему ходил раз в полгода на 3-5 сеансов, потом стал ходить раз в год, и последний раз я у него был уже лет 5 назад. И это без каких-либо изменений в образе жизни.
И если до врача-спасителя я "на медицину" тратил около 70% своих доходов, то непосредственно на него я тратил 5%.
Настоящий холивар начинается вокруг необходимости переводить термины, а не транслитерировать их. Например, вместо "аллокация памяти" писать "выделение памяти". Транслитерация выигрывает у перевода в том случае, когда перевод занимает больше места, чем транслитерация, во всех остальных случаях проигрывает, и выглядит натужно.
чтобы коллективно такие диаграммы рисовать, нужно использовать нечто вроде Visual Paradigm - он всю версионность таких процессов как-то сам отслеживает и обслуживает
помнится, основной аргумент в пользу именно pgsql при переходе от oracle заключался в том, что pgsql довольно сильно похожа на oracle, т.к. разрабы pgsql когда-то разрабатывали oracle...
и последнее (на сегодня точно) замечание - потоки управления и сообщения не взаимозаменяемы. поток управления связывает задачи и подпроцессы внутри бассейна в одну или несколько траекторий исполнения, а поток сообщений показывает направление движения информации, и обозначает факты информационного обмена между бассейнами.
а еще demo.bpmn.io умеет с недавних пор свернутые Sub Process'ы связывать с отдельными диаграммами, как Visual Paradigm. и хранится все это добро по-прежнему в одном bpmn-файле, который по сути есть обыкновенный XML
я читал годичный курс в одном московском ВУЗе бакалаврам прикладной информатики по использованию BPMN в их профессиональной деятельности в течение 10 лет, и % успешно его осваивающих был хорошо если около 20.
и еще один момент - промежуточное событие-сообщение не используется для обозначения информационного обмена между ролями, а только между бассейнами. если надо показать обмен между ролями, то, во-первых, есть специальные два Task'а - Send Task и Receive Task, обозначаются черным и пустым конвертами в левом верхнем углу Task'а; а во-вторых, можно использовать Data Object, связав его при помощи двух Association Flow с соотв. Task'ами или SubProcess'ами
bpmn-js как раз является истинным представителем жанра опенсорс, т.к. позволяет встраивать себя в любой вебсайт, а не только эксплуатировать себя с "одобренных партией" сайтов и приложений.
Во-первых, лучше и удобнее пользоваться инструментами на основе фреймворка bpmn-js, например, demo.bpmn.io, storm.bpmn2.ru, Camunda Modeler и прочими подобиями.
Во-вторых, согласно стандарту, единственный элемент, который может разделять или объединять потоки управления - это шлюз.
В-третьих, хорошо бы рисовать диаграмму в одном стиле. Т.е., если задачи/работы могут (с вашей точки зрения) разделять или объединять потоки управления, тогда не надо использовать шлюзы; если используете шлюзы для разделения/слияния потоков управления, то только их используйте. Читаемость схемы гораздо выше, если каждый элемент выполняет только определенную ему стандартом роль - разнообразие здесь только во вред.
Реализмом в симах не пахнет и сегодня. Для реализма не хватает real-time процессов. Если дом будет строиться пусть даже три недели, как у китайцев, это убьет весь игровой процесс.
Летом 2011 я на три недели съездил на Мальту. А вернувшись с нее, слег с болевым синдромом вследствие грыжи межпозвоночных дисков пояснично-крестцового отдела. С этого момента началось мое хождение по мукам. Были и таблетки, и уколы, и даже полтора года хождения в центр Бубновского в Сокольниках. А потом через отцовские связи в 2014 году нашелся ортовертеброневролог, который рефлексотерапией за какие-то 10 сеансов поставил меня на ноги, и "снял с иглы" постоянных забегов по врачам. Еще несколько лет я к нему ходил раз в полгода на 3-5 сеансов, потом стал ходить раз в год, и последний раз я у него был уже лет 5 назад. И это без каких-либо изменений в образе жизни.
И если до врача-спасителя я "на медицину" тратил около 70% своих доходов, то непосредственно на него я тратил 5%.
а как же Transport Tycoon Deluxe, и OpenTTD на ее основе?
Настоящий холивар начинается вокруг необходимости переводить термины, а не транслитерировать их. Например, вместо "аллокация памяти" писать "выделение памяти". Транслитерация выигрывает у перевода в том случае, когда перевод занимает больше места, чем транслитерация, во всех остальных случаях проигрывает, и выглядит натужно.
большое спасибо
хорошо бы новый mini увидеть
чтобы коллективно такие диаграммы рисовать, нужно использовать нечто вроде Visual Paradigm - он всю версионность таких процессов как-то сам отслеживает и обслуживает
"Первая часть изысканий делается через встроенную в IDE возможность перехода " а IDE какая? VS Code, CLion?
помнится, основной аргумент в пользу именно pgsql при переходе от oracle заключался в том, что pgsql довольно сильно похожа на oracle, т.к. разрабы pgsql когда-то разрабатывали oracle...
странно, на мои русскоязычные запросы выдаются почему-то англоязычные ответы
и последнее (на сегодня точно) замечание - потоки управления и сообщения не взаимозаменяемы. поток управления связывает задачи и подпроцессы внутри бассейна в одну или несколько траекторий исполнения, а поток сообщений показывает направление движения информации, и обозначает факты информационного обмена между бассейнами.
а еще demo.bpmn.io умеет с недавних пор свернутые Sub Process'ы связывать с отдельными диаграммами, как Visual Paradigm. и хранится все это добро по-прежнему в одном bpmn-файле, который по сути есть обыкновенный XML
я читал годичный курс в одном московском ВУЗе бакалаврам прикладной информатики по использованию BPMN в их профессиональной деятельности в течение 10 лет, и % успешно его осваивающих был хорошо если около 20.
storm.bpmn2.ru умеет "в валидацию"
и еще один момент - промежуточное событие-сообщение не используется для обозначения информационного обмена между ролями, а только между бассейнами. если надо показать обмен между ролями, то, во-первых, есть специальные два Task'а - Send Task и Receive Task, обозначаются черным и пустым конвертами в левом верхнем углу Task'а; а во-вторых, можно использовать Data Object, связав его при помощи двух Association Flow с соотв. Task'ами или SubProcess'ами
bpmn-js как раз является истинным представителем жанра опенсорс, т.к. позволяет встраивать себя в любой вебсайт, а не только эксплуатировать себя с "одобренных партией" сайтов и приложений.
чтобы рисовать хореографию, можно пользоваться этим веб-инструментом https://bpt-lab.org/chor-js-demo/
Во-первых, лучше и удобнее пользоваться инструментами на основе фреймворка bpmn-js, например, demo.bpmn.io, storm.bpmn2.ru, Camunda Modeler и прочими подобиями.
Во-вторых, согласно стандарту, единственный элемент, который может разделять или объединять потоки управления - это шлюз.
В-третьих, хорошо бы рисовать диаграмму в одном стиле. Т.е., если задачи/работы могут (с вашей точки зрения) разделять или объединять потоки управления, тогда не надо использовать шлюзы; если используете шлюзы для разделения/слияния потоков управления, то только их используйте. Читаемость схемы гораздо выше, если каждый элемент выполняет только определенную ему стандартом роль - разнообразие здесь только во вред.