Несмотря на его популярность, командам следует тщательно рассмотреть свои потребности и реальные возможности перед принятием решения внедрять данный фреймворк.
Команде в любом случае нужен какой-то процесс разработки, и обычно вопрос не стоит таким образом, что "скрам не подходит, значит, не будем использовать ничего". Рассматриваются разные варианты, выбирается один из них.
Если, руководствуясь вашей статьей, команда пришла к выводу, что скрам ей не подходит, то какие у нее будут альтернативы?
Может ли оказаться, что среди имеющихся альтернатив, даже несмотря на описанные вами недостатки, скрам будет лучшим выбором?
Если я правильно помню, parcel использует как точку входа html-файл. Я не понял, как можно прикрутить его к сайту на php. Мне нужно, чтобы сборщик просто собирал css и js, не требуя обязательного присутствия html. Есть ли какие-то best practices на эту тему для parcel?
Вроде бы статья начала отвечать на давно имевшиеся у меня вопросы, и вот прямо в очень близкой формулировке вопросы. Но потом несколько вводных общих слов и обрыв.
1. Открывать код планируете? В том смысле, что можно ли будет вашу панель устанавливать на свои сервера и дорабатывать (то, в чем продукты ISP* неудобны)? Или хотя бы планируете делать систему плагинов с бОльшим количеством возможностей, чем у ISP?
2. У ISP есть ISPManager, позволяющий разворачивать lamp на сервере. Вы такое будете делать?
Вопросы насущные, так как с ISP сталкиваюсь аналогичными описанными вами проблемами, но свою панель писать ресурсов нет. Воспользовался бы на платной основе чьим-нибудь готовым решением.
Учитывать надо, в обсуждении уже написали, почему, а я немного в другую сторону раскрою вопрос. Есть память, диски, другие запчасти, которые могут прилично стоить. И помимо контроля, что из компа ничего не вытащили шаловливые ручки, хочется еще понимать, какой девайс у кого был куплен и какая у него гарантия. Можно пробить серийник по базе, если все при покупке учитывали, но у тех же плашек памяти так мелко серийник пишут, что глаза сломаешь и при первом вбивании, и при сверке. Используете ли что-нибудь, чтобы облегчить этот процесс?
Скажите, в новой версии можно посмотреть историю одного триггера по разным серверам на одной странице? Например, чтобы составить детальный отчет по группе серверов за месяц.
Не уменьшится, т. е., да, тоже растут. Но при одной таблице в одном файле им можно делать OPTIMIZE TABLE, и незанятое пространство будет высвобождаться.
Вы пишете:
Команде в любом случае нужен какой-то процесс разработки, и обычно вопрос не стоит таким образом, что "скрам не подходит, значит, не будем использовать ничего". Рассматриваются разные варианты, выбирается один из них.
Если, руководствуясь вашей статьей, команда пришла к выводу, что скрам ей не подходит, то какие у нее будут альтернативы?
Может ли оказаться, что среди имеющихся альтернатив, даже несмотря на описанные вами недостатки, скрам будет лучшим выбором?
Спасибо :)
Надеюсь на продолжение.
2. У ISP есть ISPManager, позволяющий разворачивать lamp на сервере. Вы такое будете делать?
Вопросы насущные, так как с ISP сталкиваюсь аналогичными описанными вами проблемами, но свою панель писать ресурсов нет. Воспользовался бы на платной основе чьим-нибудь готовым решением.
Интересно будет попробовать сервис.
Потому что иначе при настройках по умолчанию будет бесконечно расти файл ibdata1, уменьшить который можно только если сделать дамп всех баз, удалить файл и загрузить дамп обратно.
Ну если пытаться уместить ответ в одном комментарии, то вот: 1, 2, 3 :)
Что желательно делать в любом случае, хоть с partitioning, хоть без.