Хороший пример, но как всегда есть одно но. Первое из них, двое других сотрудников так же очень скоро начнут делать перерывы, и будут считать себя не справедливо обиженными жизнь. И их производительно заметно упадет, можно конечно их поменять, но с новыми произойдет тоже самое, удивительно но проще поменять быстрого, чем набрать еще десяток таких же как он. Второе, тот что бегает с двумя мешками очень скоро надорвется, но вот только первые два сотрудника уже не откажутся от своих «законных» перерывов по 40 минут.
Наличие особых условий для части сотрудников не способствует нормальной работе коллектива. Как правило нужно 100 серых мышек, а не 50 мышек и 10 гениев, даже если в итоге второй вариант дешевле, его сложно поддерживать.
Как мне кажется, в ПДД используется вполне четкая формулировка, пункт 10.1, водитель должен тормозить вплоть до полной остановки. Данная формулировка единственно приемлемая для всех случаев. Да она допускает жертвы которых можно было избежать, но при этом она предотвращает другие жертвы, в результате неудачного маневрирования.
Т.е. в ситуации неизбежного ущерба автопилот должен тормозить. Если же можно с высокой точностью просчитать траекторию при которой ущерба можно избежать, то автопилот должен использовать ее.
Ну вот скажем эта. Имено что код нужен, что диаграммы сами по себе не являются законченным работающим процессом. В тех процессах, что я видел и делал, кода было процентов 80% наверное. И только в виде кода можно делать компоненты, которые потом можно повторно переиспользовать — попытки делать их в виде процессов приводят к ужас-ужас.
А зачем делать их в виде процессов? BPMN существует не для замены языкам типа java.
ИМХО или автор не разобрался или работал с плохими инструментами. У BPM есть проблемы, но со статьей они коррелируются слабо.
Визуальное моделирование не преследует цель во всех подробностях изобразить процесс. Его задача мост между кодом и бизнес процессом. Всегда есть компромисс между сокрытием деталей реализации в коде и отображении их в процессе. Если мы его не соблюдаем, мы получил или не читаемый процесс перегруженный деталями реализации или не понятный процесс с целый слоем бизнес логики сокрытым на уровне кода. При разработке «классических» приложений с бизнес логикой в коде, такой проблемы нет, бизнес логика скрыта от пользователя всегда, и как это не прискорбно, очень часто представляет из себя нагромождение костылей. Почему так, потому что когда мы пытаемся формализовать процесс выплывает такая куча нюансов, что учесть их все в стройной не противоречивой модели очень и очень сложно, вот их и закапывают в код. Потом это становиться не поддерживаемой, или поддерживаемой за безумные деньги, системой. С bpm такой фокус не проходит, эта проблемы переноситься с этапа поддержки, на этап проектирования. Это вызывает множество проблем, поскольку заказчику или сразу видно, что процесс не соответствует реальности, или что не читаем и содержит костыли на каждом шагу. Такое продать сложно, проще указать в ТЗ требования, а потом реализовать их через одно место и все довольны.
По остальным пунктам, единственно что соответствует действительности, это отсутствие средств рефакторинга.
Bpmn это не диаграмма, и не графический файл, а текст, xml подобный документ, все доступное для любого текста доступно и для bpm, версионность, jira, find and replace, все естественно есть.
Нужны плагины, не устраивает IDE, нет проблем пишите плагины или вообще напишите полностью свой инструмент. Для примера BPMN можно «разрабатывать» в eclipse.
В используемом нами движке есть не только версионность процесса, на уровне git, но и параллельное исполнение процессов разных версий и средство миграции процессов с одной версии на другую.
Покрытие тестами. Хм, с тем движком с которым работаем мы bpm процесс замечательно покрывается тестами.
Оценка трудозатрат на рисование bpm диаграммы вообще странный пункт, а как вы оцениваете в своих проектах трудозатраты на документирование и описание бизнес процессов заказчика. Это собственно говоря одно и тоже, за исключение специфического языка описания.
Асинхронное взаимодействие, чем оно будет отличаться от аналогичного в «классическом» приложении? В bpm это будет выглядеть или как сервис таск плюс ожидание сообщения, или как отправка и получение сообщения. За ним стоит повесить любую очередь, хоть то же rabbitMQ. Пример с сортировкой списка вообще странный, сортировка списка не есть часть бизнес процесса, она замечательно скрывается на уровне кода.
Похоже или у автора инструменты из кровавого энтерпрайз в которых сюда нельзя туда нельзя и все посыпано сверху SAP'ом, или он не умеет их готовить.
Как мне кажется, главная проблема bpm это высокая сложность описания процесса с сохранением его читабельности. Плюс восприятие, код не нужен, что в корне не верно.
Это проблема общая. У HDD исторически складывалось деление на enterprise диски и consumer диски. Изначально они были очень далеки и их нельзя было перепутать от слова совсем. Дальше появились nearline которые очень близки к consumer дискам, но все же enterprise, и из consumer дисков по вырастали всякие серии для NAS, которые уже не понятно enterprise или нет.
C SSD сложнее, все вырастали из consumer и не понятно как отличить enterprise от consumer, каждый производитель под enterprise подразумевает что-то свое, и ты по факту не можешь рассчитывать на некоторый стандартный набор enterprise фич, их может не быть в конкретной enterprise модели, и они могут быть в топовой consumer модели.
ИМХО две главные проблемы SSD, это непонятки с RAID, не лотерея с производительностью.
И то, и другое очень сильно зависит от конкретной модели «диска» и даже от версии прошивки.
Если будет список SSD которые гарантированно( протестировано независимой общественностью ) буду лишены недостатков существенно деградации производительности при заполнении более чем на 50% и нормально работают с любыми RAID контроллерами, я первый побегу менять диски. А так, каждый раз какая-то магия, тут можно через специальные утилиты изменять размер резервированной области, там на 7 ревизии, но не на 8, нормально работает в RAID и т.д.
В больших кровавых энтерпрайзах вам и в докере не позволят использовать все по своей прихоти.
Если есть требование, что только tomcat и 7 java, то хоть обдокарись, но только tomcat и 7 java.
Докер в таком случае помогает, если админы готовы перейти на java 8/netty и т.д., но есть большое кол-во другого софта на том же хосте, и все это надо тестить, а это огромный объем работы.
Но имхо в таком случае вам и докер на этот хост поставить не дадут.
They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
Вполне официальная цитата, с очень глубоким смыслом. Последнее время становиться все более актуальной. Как только мы пожертвовали свободой ради безопасности, мы стали стадом которое ведут на убой.
ИМХО требования к CPU и RAM зависят от софтовой аналитики. Т.е. будете ли вы на сервере поток анализировать( а следовательно делать декомпрессию ) или нет.
Если нет, то хватит любого современного CPU и минимум RAM. Как пример 20 камер, суммарно 500FPS и 130Мбит поток. Средненький i5 утилизация 17%. Большая часть камер разрешения выше FullHD. Т.е. 3-4Mpix.
По поводу дисков. Полагаю брать брэндовую систему и платить за брэндовые диски именно для данной задачи горячка. Делать RAID 5 вообще самоубийство, учитывая объемы хранения требуется брать диски максимальной емкости, мы у себя перешли на 8Тб, в случае вылета одного диска при такой емкости и кол-ве дисков 8-16шт, очень не маленькая вероятность лишиться данных во время ребилда, я бы даже сказал очень большая.
Самолечение провоцируют медицинские работники соответствующей квалификации, которые своей работой и безразличием к пациенту полостью подорвали доверие ко всей отрасли в целом. И самое неприятно, таких работников очень много, если не большинство.
Как вариант, нам нужно разработать клиент для нашей системы на андройд и IOS, плюс модифицировать сайт и интегрировать все это с телефонией.
Вроде работы много, но ядро системы она не затрагивает. Опыта мобильной работы внутри компании нет, опыта работы с телефонией тоже. Но есть понимание, того, что должно быть в результате. В таком случае вы или нарабатываете компетенции внутри компании, которые вам надо сначала получить( а это деньги и время ), а потом содержать. Или используете компетенции вендора.
Второе часто предпочтительнее по ряду причин. Во первых, первое может не получиться от слова совсем, это риски, во вторых всегда можно в итоге хороших спецов у вендера сманить, что бывает не так уж и редко.
К каждому пункту следует добавить «возможно». ИМХО преимущество аутсорсинга отсутствие необходимости держать компетенции внутри компании. Компетенции может быть много, но каждой на 1 час в неделю, в таких случая аутсорсинг может дать экономию.
Если же у вас проект на фултайм команду, то единственно преимущество аутсорсинга, «возможно» у них уже есть такая команда и они умеют ей управлять. В этом случае вы «экономите риски», при этом увеличивая бюджет.
Большинство крупных проектов состоит из взаимодействующих частей.
Чем больше проект, тем больше будет этих самых частей, иначе его будет невозможно сдать в обозримый промежуток времени и невозможно поддерживать.
Надеюсь это мы можем постулировать?
От сюда сразу несколько проблем:
1) Стабильность интерфейсов данных частей
2) Баланс между размером и сложностью данных частей.
3) Стабильность поведения данных частей.
SOLID позволяет в некоторой степени решить вторую и третью проблему, а так же от части определиться с размером нарезки.
Как вы предлагаете решать данные проблемы в общем случае, без велосипедостроения?
Очень категоричный взгляд на SOLID. Во-первых SOLID, это набор принципов, а не законов. Зачем они нужны, чтобы не ходить по граблям. В зависимости от размера проекта отступление от данных принципов будет вам стоить определенных денег в будущем, они же не про написание кода, а про развитие и поддержку.
От данных принципов можно отступать когда это абсолютно необходимо. Но лучше их придерживаться, чтобы не получить не модифицируемого монстра в итоге.
> Среди водителей таких «автолюбителей» называют резиновыми, гандонами по простому.
Причем здесь водители? Вы никогда в метро не через ту дверь до банкомата не входите или никогда угол по протоптанным дорожкам не срезаете, всегда переходите по зебре строго в ее приделах, никогда не нарушаете никаких лицензионных соглашений, используете исключительно сертифицированные средства шифрования и т.д. и т.п.?
Если почитать все возможные кодексы и подзаконные акты различных ведомств, на каждого можно кучу штрафов повесить.
Идея здравая. Но крайне вредная в действующей реальности. Она лишена системного похода и преследует исключительно карательные цели никак не отвечая на вопрос, что делать.
Все сторонникам, предлагаю задуматься сколько раз в день они реально нарушают различные кодексы, законные и подзаконные акты, а так же их вольное трактование. По факту, думаю на каждого из нас можно в день на несколько тысяч штрафов выписать без всяких проблем.
Плюс не забывайте про фактически не рабочий механизм обжалования.
Извините конечно, но конкуренция в том виде в котором она описывается идеалистами либералами не существует. Люди конечно хотят сервиса, на что люди скажут если функция отключения звука в телефоне станет платной?
Вопрос в том, что есть сервис для людей, а есть сервис для зарабатывания на людях. Хороший пример невозможность заменить аккумулятор в телефоне, вот 20 лет было возможно, а сейчас почему-то конкуренция этот вопрос у большей части производителей решила в одну сторону.
И по большому счету, нет ни одной адекватной причины, чтобы это было так, кроме желания заработать производителей телефонов и отделенность последствий для потребителя, благодаря которой он соглашается на такие условия.
ИМХО монополизм на уровне сервиса, или ведорлок, следует запрещать так же как монополизм на любом другом рынке.
Производитель или гос-во может предъявлять к сервису требования позволяющие качественно оказать услугу( обращаю внимание, это должны быть минимальные требования ), при соблюдении этих требований, все участники сервисного рынка должны быть в равных условиях, включая аффилированные с производителем.
Наличие особых условий для части сотрудников не способствует нормальной работе коллектива. Как правило нужно 100 серых мышек, а не 50 мышек и 10 гениев, даже если в итоге второй вариант дешевле, его сложно поддерживать.
Т.е. в ситуации неизбежного ущерба автопилот должен тормозить. Если же можно с высокой точностью просчитать траекторию при которой ущерба можно избежать, то автопилот должен использовать ее.
А зачем делать их в виде процессов? BPMN существует не для замены языкам типа java.
Визуальное моделирование не преследует цель во всех подробностях изобразить процесс. Его задача мост между кодом и бизнес процессом. Всегда есть компромисс между сокрытием деталей реализации в коде и отображении их в процессе. Если мы его не соблюдаем, мы получил или не читаемый процесс перегруженный деталями реализации или не понятный процесс с целый слоем бизнес логики сокрытым на уровне кода. При разработке «классических» приложений с бизнес логикой в коде, такой проблемы нет, бизнес логика скрыта от пользователя всегда, и как это не прискорбно, очень часто представляет из себя нагромождение костылей. Почему так, потому что когда мы пытаемся формализовать процесс выплывает такая куча нюансов, что учесть их все в стройной не противоречивой модели очень и очень сложно, вот их и закапывают в код. Потом это становиться не поддерживаемой, или поддерживаемой за безумные деньги, системой. С bpm такой фокус не проходит, эта проблемы переноситься с этапа поддержки, на этап проектирования. Это вызывает множество проблем, поскольку заказчику или сразу видно, что процесс не соответствует реальности, или что не читаем и содержит костыли на каждом шагу. Такое продать сложно, проще указать в ТЗ требования, а потом реализовать их через одно место и все довольны.
По остальным пунктам, единственно что соответствует действительности, это отсутствие средств рефакторинга.
Bpmn это не диаграмма, и не графический файл, а текст, xml подобный документ, все доступное для любого текста доступно и для bpm, версионность, jira, find and replace, все естественно есть.
Нужны плагины, не устраивает IDE, нет проблем пишите плагины или вообще напишите полностью свой инструмент. Для примера BPMN можно «разрабатывать» в eclipse.
В используемом нами движке есть не только версионность процесса, на уровне git, но и параллельное исполнение процессов разных версий и средство миграции процессов с одной версии на другую.
Покрытие тестами. Хм, с тем движком с которым работаем мы bpm процесс замечательно покрывается тестами.
Оценка трудозатрат на рисование bpm диаграммы вообще странный пункт, а как вы оцениваете в своих проектах трудозатраты на документирование и описание бизнес процессов заказчика. Это собственно говоря одно и тоже, за исключение специфического языка описания.
Асинхронное взаимодействие, чем оно будет отличаться от аналогичного в «классическом» приложении? В bpm это будет выглядеть или как сервис таск плюс ожидание сообщения, или как отправка и получение сообщения. За ним стоит повесить любую очередь, хоть то же rabbitMQ. Пример с сортировкой списка вообще странный, сортировка списка не есть часть бизнес процесса, она замечательно скрывается на уровне кода.
Похоже или у автора инструменты из кровавого энтерпрайз в которых сюда нельзя туда нельзя и все посыпано сверху SAP'ом, или он не умеет их готовить.
Как мне кажется, главная проблема bpm это высокая сложность описания процесса с сохранением его читабельности. Плюс восприятие, код не нужен, что в корне не верно.
C SSD сложнее, все вырастали из consumer и не понятно как отличить enterprise от consumer, каждый производитель под enterprise подразумевает что-то свое, и ты по факту не можешь рассчитывать на некоторый стандартный набор enterprise фич, их может не быть в конкретной enterprise модели, и они могут быть в топовой consumer модели.
И то, и другое очень сильно зависит от конкретной модели «диска» и даже от версии прошивки.
Если будет список SSD которые гарантированно( протестировано независимой общественностью ) буду лишены недостатков существенно деградации производительности при заполнении более чем на 50% и нормально работают с любыми RAID контроллерами, я первый побегу менять диски. А так, каждый раз какая-то магия, тут можно через специальные утилиты изменять размер резервированной области, там на 7 ревизии, но не на 8, нормально работает в RAID и т.д.
Если есть требование, что только tomcat и 7 java, то хоть обдокарись, но только tomcat и 7 java.
Докер в таком случае помогает, если админы готовы перейти на java 8/netty и т.д., но есть большое кол-во другого софта на том же хосте, и все это надо тестить, а это огромный объем работы.
Но имхо в таком случае вам и докер на этот хост поставить не дадут.
Вполне официальная цитата, с очень глубоким смыслом. Последнее время становиться все более актуальной. Как только мы пожертвовали свободой ради безопасности, мы стали стадом которое ведут на убой.
Если нет, то хватит любого современного CPU и минимум RAM. Как пример 20 камер, суммарно 500FPS и 130Мбит поток. Средненький i5 утилизация 17%. Большая часть камер разрешения выше FullHD. Т.е. 3-4Mpix.
По поводу дисков. Полагаю брать брэндовую систему и платить за брэндовые диски именно для данной задачи горячка. Делать RAID 5 вообще самоубийство, учитывая объемы хранения требуется брать диски максимальной емкости, мы у себя перешли на 8Тб, в случае вылета одного диска при такой емкости и кол-ве дисков 8-16шт, очень не маленькая вероятность лишиться данных во время ребилда, я бы даже сказал очень большая.
Вроде работы много, но ядро системы она не затрагивает. Опыта мобильной работы внутри компании нет, опыта работы с телефонией тоже. Но есть понимание, того, что должно быть в результате. В таком случае вы или нарабатываете компетенции внутри компании, которые вам надо сначала получить( а это деньги и время ), а потом содержать. Или используете компетенции вендора.
Второе часто предпочтительнее по ряду причин. Во первых, первое может не получиться от слова совсем, это риски, во вторых всегда можно в итоге хороших спецов у вендера сманить, что бывает не так уж и редко.
Если же у вас проект на фултайм команду, то единственно преимущество аутсорсинга, «возможно» у них уже есть такая команда и они умеют ей управлять. В этом случае вы «экономите риски», при этом увеличивая бюджет.
Чем больше проект, тем больше будет этих самых частей, иначе его будет невозможно сдать в обозримый промежуток времени и невозможно поддерживать.
Надеюсь это мы можем постулировать?
От сюда сразу несколько проблем:
1) Стабильность интерфейсов данных частей
2) Баланс между размером и сложностью данных частей.
3) Стабильность поведения данных частей.
SOLID позволяет в некоторой степени решить вторую и третью проблему, а так же от части определиться с размером нарезки.
Как вы предлагаете решать данные проблемы в общем случае, без велосипедостроения?
От данных принципов можно отступать когда это абсолютно необходимо. Но лучше их придерживаться, чтобы не получить не модифицируемого монстра в итоге.
Причем здесь водители? Вы никогда в метро не через ту дверь до банкомата не входите или никогда угол по протоптанным дорожкам не срезаете, всегда переходите по зебре строго в ее приделах, никогда не нарушаете никаких лицензионных соглашений, используете исключительно сертифицированные средства шифрования и т.д. и т.п.?
Если почитать все возможные кодексы и подзаконные акты различных ведомств, на каждого можно кучу штрафов повесить.
Все сторонникам, предлагаю задуматься сколько раз в день они реально нарушают различные кодексы, законные и подзаконные акты, а так же их вольное трактование. По факту, думаю на каждого из нас можно в день на несколько тысяч штрафов выписать без всяких проблем.
Плюс не забывайте про фактически не рабочий механизм обжалования.
Вопрос в том, что есть сервис для людей, а есть сервис для зарабатывания на людях. Хороший пример невозможность заменить аккумулятор в телефоне, вот 20 лет было возможно, а сейчас почему-то конкуренция этот вопрос у большей части производителей решила в одну сторону.
И по большому счету, нет ни одной адекватной причины, чтобы это было так, кроме желания заработать производителей телефонов и отделенность последствий для потребителя, благодаря которой он соглашается на такие условия.
ИМХО монополизм на уровне сервиса, или ведорлок, следует запрещать так же как монополизм на любом другом рынке.
Производитель или гос-во может предъявлять к сервису требования позволяющие качественно оказать услугу( обращаю внимание, это должны быть минимальные требования ), при соблюдении этих требований, все участники сервисного рынка должны быть в равных условиях, включая аффилированные с производителем.