А насколько удобно в Camunda и Bonita делаются более сложные топологии, например, параллельные подпроцессы и условия по их результатам? В идеале, скажем, когда заявку должны независимо параллельно проверить и одобрить: технолог AND отдел IT AND (финансовый отдел OR директор филиала)
Я в итоге думаю, что модель в том смысле, как она появилась в ActiveRecord, не противоречит понятию модели из системного анализа. Как только у нас появляются разные слои абстракции, так модель предметной области расслаивается на модели отдельных подсистем. Сложное понятие из предметной области практически всегда в силу своей сложности заслуживает того, чтобы его рассматривать как подсистему и строить собственную модель (как термин системного анализа).
Ну и модель в rails уже достаточно многие используют без привязки именно к ActiveRecord, а именно как четко выделенную группу классов, которые моделируют предметную область, оторванную от представления для пользователя или для API.
Да, хороший пример с грузоперевозками. В результате эволюции отрасли появились процессы и термины, лучше всего приспособленные к задачам, у которых убрано все лишнее. Программистам лучше всего перенести существующую модель в цифру.
Когда процессы и отношения только зарождаются — готовых моделей нет и их нужно придумывать. Один из первых подходов — использовать физические объекты и процессы, но сразу же упрощать, убирать все неважное, оставлять только минимально необходимое.
Здесь модель — это термин из MVC, например, при использовании Ruby on Rails. То есть это класс, отражающий какое-нибудь важное понятие или предмет из предметной области.
Согласен, тоже слово перегруженное ассоциациями. Но в ООП много способов применения классов и не для всех способов применения выбор имени класса может иметь такое существенное значение.
Вообще-то не совсем «там не совсем так» :) Практически у всех реализаций все обернуто либо в контейнер, либо, как минимум, в неймспейсы, изолирующие одни юзерские процессы от других. Да и если рабочее окружение контейнера с файловой системой уже находится в кэше, то запуск процесса в контейнера ничем не отличается от простого запуска процесса. То есть время на запуск процесса и загрузку в него библиотек требуется по-любому.
Где-то могут быть еще вариации, типа security manager в JVM, позволяющий в одной JVM запускать треды разных юзеров. Ну или PHP с safe_mode. Но это, честно говоря, кривая реализация и от таких нужно бежать — со всех сторон плохо: и плохо с безопасностью, и конкуренция за ресурсы, и неточный биллинг.
Сейчас — сделать дамп из текущего сервера и влить дамп в новый сервер. Когда RocksDB будет добавлен в MariaDB — то достаточно ALTER TABLE на новый ENGINE.
У bitnami это только набор образов для каждого приложения или стека. У jetware — это конструктор, в котором набираются несколько приложений и для части из них есть дополнительная автоматическая интеграция. Например, для Drupal, Solr и NodeJS.
Потому что это реально сложно, хотя и можно: http://jetware.org
Правда, для российских хостеров интеграция в ближайшее время не планируется. Но там очень легко ставится в любую ОС и они могут самостоятельно допилить интеграцию.
Еще немаловажная причина не складывать разных пользователей в nginx с интегрированным passenger — разным пользователям в эксплуатации могут требоваться разные версии passenger. Одному нужна более новая версия с исправленным багом, с которым он сталкивается, другому наоборот, никакие лишние изменения не нужны.
Поэтому лучше как в нашем случае — passenger от nginx отдельно.
Просто под юзером — это малая часть задачи. Чтобы все было хорошо, нужно еще для каждого пользователя правильно выставлять контекст выполнения — доступные файловые системы, переменные окружения, лимиты памяти/стека/процессора, приоритеты выполнения.
В первую очередь это удобнее клиентам. Сайт с привязкой к кластеру, DNS и CDN создается через веб-панель в один клик и не нужно по зарываться в документацию и конфигурировать отдельности все эти компоненты. Apache также нужен для настройки сложной структуры через .htaccess, организации хранения документов через WebDAV и для обслуживания других платформ, например, под mod_php — phpmyadmin и awstat. В связке Redmine + LDAP + SVN без Apache не обойтись. Поэтому для простоты и для минимизации расхода ресурсов по дефолту используется apache.
Если клиенту ничего этого не нужно, он отключает их конфигурации apache и запускает так, как ему нужно и passenger, и unicorn, и puma. По скорости будет все то же самое, что и с apache, но чуть меньше будет расход памяти.
Плагином включать passenger в nginx в нашем случае нельзя, так как мы изолируем клиентов друг о друга и по правам доступа (безопасность) и по ресурсам (нагрузка соседей).
Я думаю, что вы видите проблему на ровном месте, там, где ее нет. strict weak order является подклассом partial order. Вы работаете с более узким классом strict weak order и из-за этого требуете, чтобы оператор не работал для более широкого класса. А, например, у меня последние пол-года половина задач связана с зависимостями и топологической сортировкой, и для меня это рутина, а не изыски.
Вам с qsort наличие <=> у хэша ничем не помешает. Он выдает на nil такое же исключение, как и на сравнение числа со строкой. Если вы сейчас не проверяете на nil, то у вас будут вылезать ошибки и при смешивании типов в одном списке:
> 'a' <=> 2
=> nil
Если же вы полагаетесь на то, что у вас в массиве ничего кроме чисел не будет, то каким образом вам помешает <=> у хэша, ведь у вас в массиве ничего кроме чисел нет?
Возможно, для того, чтобы сделать более удобным и строгим для вас язык, стоило бы наоборот, ввести что-то типа <===>, который бы выдавал исключение вместо nil.
partially ordered set является нормальной строгой математикой и не должно никого смущать. Классы являются отличным образцом и выкорчевав оператор <=> вы без всякой пользы убъете возможность строить граф наследования классов.
У вас есть обоснование того, что это большая ошибка проектирования?
> сильно смущает, что !(a<b || a>b) не эквивалентно a==b
Это не должно смущать. В ЖЖ, насколько я вижу, у вас произошла путаница из-за того, что вы захотели qsort, и для этого потребовали strict weak ordering. И, вероятно, смешали strict weak ordering, strict partial ordering и weak partial ordering.
Но вы предъявили избыточное требование к тому, что это требование и не должно выполнять. В partially ordered set равенство определяется антисимметрией, то есть (a <= b && b <= a) -> a == b. И при таком условии и топологическая сортировка работает, и выполняются все операции сравнения, там где есть отношение порядка. qsort и не должен тут работать.
Там не укладывается из-за того, что вместо для несравниваемых элементов отдают false вместо nil. Если отдавать nil, то все будет в порядке.
С '==' в ЖЖ не видно, откуда проблема. Есть утверждение, что '==' оказалась более узкая, чем антисимметрия, но чем обосновано это утверждение, не написано.
Ну и модель в rails уже достаточно многие используют без привязки именно к ActiveRecord, а именно как четко выделенную группу классов, которые моделируют предметную область, оторванную от представления для пользователя или для API.
Когда процессы и отношения только зарождаются — готовых моделей нет и их нужно придумывать. Один из первых подходов — использовать физические объекты и процессы, но сразу же упрощать, убирать все неважное, оставлять только минимально необходимое.
Согласен, тоже слово перегруженное ассоциациями. Но в ООП много способов применения классов и не для всех способов применения выбор имени класса может иметь такое существенное значение.
Где-то могут быть еще вариации, типа security manager в JVM, позволяющий в одной JVM запускать треды разных юзеров. Ну или PHP с safe_mode. Но это, честно говоря, кривая реализация и от таких нужно бежать — со всех сторон плохо: и плохо с безопасностью, и конкуренция за ресурсы, и неточный биллинг.
В Azure не стали же делать криво?
2) CPU при записи больше. Куча человеческого труда в проектировании и кодировании — тоже достаточно высокая цена.
Правда, для российских хостеров интеграция в ближайшее время не планируется. Но там очень легко ставится в любую ОС и они могут самостоятельно допилить интеграцию.
Поэтому лучше как в нашем случае — passenger от nginx отдельно.
Если клиенту ничего этого не нужно, он отключает их конфигурации apache и запускает так, как ему нужно и passenger, и unicorn, и puma. По скорости будет все то же самое, что и с apache, но чуть меньше будет расход памяти.
Плагином включать passenger в nginx в нашем случае нельзя, так как мы изолируем клиентов друг о друга и по правам доступа (безопасность) и по ресурсам (нагрузка соседей).
Вам с qsort наличие <=> у хэша ничем не помешает. Он выдает на nil такое же исключение, как и на сравнение числа со строкой. Если вы сейчас не проверяете на nil, то у вас будут вылезать ошибки и при смешивании типов в одном списке:
Если же вы полагаетесь на то, что у вас в массиве ничего кроме чисел не будет, то каким образом вам помешает <=> у хэша, ведь у вас в массиве ничего кроме чисел нет?
Возможно, для того, чтобы сделать более удобным и строгим для вас язык, стоило бы наоборот, ввести что-то типа <===>, который бы выдавал исключение вместо nil.
У вас есть обоснование того, что это большая ошибка проектирования?
Это не должно смущать. В ЖЖ, насколько я вижу, у вас произошла путаница из-за того, что вы захотели qsort, и для этого потребовали strict weak ordering. И, вероятно, смешали strict weak ordering, strict partial ordering и weak partial ordering.
Но вы предъявили избыточное требование к тому, что это требование и не должно выполнять. В partially ordered set равенство определяется антисимметрией, то есть (a <= b && b <= a) -> a == b. И при таком условии и топологическая сортировка работает, и выполняются все операции сравнения, там где есть отношение порядка. qsort и не должен тут работать.
С '==' в ЖЖ не видно, откуда проблема. Есть утверждение, что '==' оказалась более узкая, чем антисимметрия, но чем обосновано это утверждение, не написано.