Конечный перевод первого примера все равно не понятен и не содержит всей информации из исходного текста. Переводить такой текст может только специалист в данной области, а не переводчик.
Все от ситуации зависит. Если ты каким-то образом повысил привилегии и тебе быстро нужны пароли нескольких пользователей, то описанная методика более предпочтительна, не придется ждать когда пользователь пароль сменит. Хотя и менее надежна. Опять же, если пароль нам нужен не от домена, а от чего-то другого и мы предполагаем что он совпадает или сформирован по тому же принципу, то заставлять пользователя его сменить - рискованно. В общем, каждый инструмент под свою задачу.
Powershell, несомненно удобен, особенно Windows- администраторам, привыкшим его использовать. В нашем же случае, большая часть инфраструктуры линуксовая и питон нам "роднее", это первая причина. Вторая — эти скрипты — маленькая часть автоматизации тестовой лаборатории. Есть еще веб — страницы на которых отображается информация о машинах, мониторинг, информирование, ansible и т.д. А для решения таких задач питон подходит куда лучше.
Не секрет: основной стек продукта для которого нужен движок — .Net Core. Продукт тиражируемый, соответственно делать дополнительные исполняемые компоненты и зависимости в окружении накладно, нам необходимо встраиваемое решение. Camunda, на мой взгляд, классное решение для использования в энтерпрайзе с преобладанием Java-стека.
Видели, знаем. Но на момент начала нашей разработки xaml он еще не поддерживал и у него не было ни одного релиза (единственный релиз 09.2018). В текущем состоянии он еще очень далек от классического WWF.
Мы проанализировали пул-реквесты и поняли, что сделали некоторые изменения, которые автор ранее не принял от других пользователей. По этому остались со своим форком: github.com/avanpostid/workflow-core.
Сертифицируется конкретный билд, что делает сертификацию профанацией в масштабе государства. Как разработчик сертифицированного ПО, могу вам сказать, что дальнейшая судьба этого билда — лежать записанным на диске на полке у клиента.
Пользуюсь случаем:
Хотели заменить морально устаревший E-Staf. Основные претензии к нему:
— толстый клиент, отсутствие возможности удаленной работы (без VPN/RDP, что сложно для рекрутера)
— коммуникации по кандидатам с заказчиками только через письма, в ручном режиме (много копипасты)
— выгрузка резюме не читается на iOS
— подготовка отчетов занимает много времени.
Протестировали вашу систему у себя в компании. Поняли, что пока ваш продукт не готов даже для использования в масштабах ИТ-компании из 50 человек.
Главные недостатки:
— отсутствие авторизации. Я в роли заказчика могу видеть вакансии и кандидатов других заказчиков, могу изменять статус кандидатов вплоть до «принят».
— качество интерфейса очень далеко от качества вашего же лендинга в плане дизайна, специалисты по UX, похоже, так же не привлекались к разработке.
— интерфейс для мобильных устройств не адаптирован.
Мой вам совет: бросьте смежные направления, сделайте качественный MVP автоматизирующий процесс подбора и к вам потянутся пользователи.
Заявленные минусы решения на основе прокси сервера 1 и 3 — глупость, вы, видимо, в принципе с технологией не разобрались.
В целом, согласен, что решение на базе локального веб-сервера адекватнее.
Еще стоит порекомендовать полезные тулзы от OneLogin: https://developers.onelogin.com/saml/online-tools/x509-certs/obtain-self-signed-certs
Помогают сильно сократить время отладки поддержки SAML в приложении и в принципе лучше понять технологию.
Конечный перевод первого примера все равно не понятен и не содержит всей информации из исходного текста. Переводить такой текст может только специалист в данной области, а не переводчик.
Все от ситуации зависит. Если ты каким-то образом повысил привилегии и тебе быстро нужны пароли нескольких пользователей, то описанная методика более предпочтительна, не придется ждать когда пользователь пароль сменит. Хотя и менее надежна. Опять же, если пароль нам нужен не от домена, а от чего-то другого и мы предполагаем что он совпадает или сформирован по тому же принципу, то заставлять пользователя его сменить - рискованно.
В общем, каждый инструмент под свою задачу.
Уточните, пожалуйста, что это за метрика?
Можно запустить 50 workflow в секунду?
Можно завершить 50 workflow за секунду?
Можно выполнить за секунду 50 шагов workflow?
Какая производительность у стандартного WorkflowCore без доработок в этой метрике?
Powershell, несомненно удобен, особенно Windows- администраторам, привыкшим его использовать. В нашем же случае, большая часть инфраструктуры линуксовая и питон нам "роднее", это первая причина. Вторая — эти скрипты — маленькая часть автоматизации тестовой лаборатории. Есть еще веб — страницы на которых отображается информация о машинах, мониторинг, информирование, ansible и т.д. А для решения таких задач питон подходит куда лучше.
Хотели заменить морально устаревший E-Staf. Основные претензии к нему:
— толстый клиент, отсутствие возможности удаленной работы (без VPN/RDP, что сложно для рекрутера)
— коммуникации по кандидатам с заказчиками только через письма, в ручном режиме (много копипасты)
— выгрузка резюме не читается на iOS
— подготовка отчетов занимает много времени.
Протестировали вашу систему у себя в компании. Поняли, что пока ваш продукт не готов даже для использования в масштабах ИТ-компании из 50 человек.
Главные недостатки:
— отсутствие авторизации. Я в роли заказчика могу видеть вакансии и кандидатов других заказчиков, могу изменять статус кандидатов вплоть до «принят».
— качество интерфейса очень далеко от качества вашего же лендинга в плане дизайна, специалисты по UX, похоже, так же не привлекались к разработке.
— интерфейс для мобильных устройств не адаптирован.
Мой вам совет: бросьте смежные направления, сделайте качественный MVP автоматизирующий процесс подбора и к вам потянутся пользователи.
— что это за термин? Можете его пояснить?
Правильный термин — дистрибьютор.
Не проработали единый язык).
В целом, согласен, что решение на базе локального веб-сервера адекватнее.