Часто встречал прямо магическую веру в хороший договор.
По моему опыту написания технических заданий и составления договоров, к сожалению, вы не убережете себя от всех нюансов. Фактически, есть несколько вариантов. Например, вариант, когда все неописанное в договоре трактуется в пользу исполнителя. В этом случает вы формально правы, но если вы разработали плохо или не то — то вы потеряли заказчика.
Бизнес веб-студии — это услуги, и сарафанное радио играет очень большую роль в рекомендациях клиентов.
Другой вариант — когда вы в договоре прописываете каждую мелочь. Но в этом случае затраты на документооборот очень сильно возрастают.
Возможно, это оправданно для очень дорогих проектов. Но для небольших — вряд ли.
Я, как руководитель веб-студии, тоже давно смотрю на Agile и даже ходил вместе с разработчиками на тренинги, но, судя по всему, максимум, что мы можем делать — это разбивать проект на небольшие этапы, каждый из которых можно сравнительно быстро сделать.
Увы, все проблемы, которые вы описали, актуальны и очень интересно узнать, как их решают в других веб-студиях.
Только, можно попросить в графиках:
1. Подписать ось Y — не для всех очевидно что это за числа, и указать, что лучше (меньшее число или большее)
2. Сделать более отличающиеся цвета у single disk и у RAID 10
Правильно ли я понял из статьи, что у вас была следующая ситуация:
1. У вас наружу смотрел apache
2. Не было nginx или другого аналогичного сервера
3. При старте системы очень быстро приходило много http запросов, из-за чего число процессов apache достигало критического для системы значения (50?) и у вас заканчивалась и оперативная память, и swap, из-за чего сервер переставал отвечать на какие-либо запросы?
4. однако, запуск скрипта из crontab все-таки работал?
Если да, то именно последний пункт — «запуск чего-нибудь из crontab» является интересным моментом. Это ценная информация.
Остальное, увы — действительно неправильно настроенный сервер.
Для предотвращения именно этой ситуации (с маленьким ростом нагрузки) проще всего было настроить так:
1. nginx как front-end
2. apache с числом одновременных процессов 5-10
в этом случае у вас будет практически невозможным перерасход памяти и вы всегда можете подключиться по ssh.
если при этом у вас nginx еще отдает статику — это будет дополнительное снижение нагрузки.
Это сложный вопрос. Если говорить о разработке, то с вашей стороны будет много усилий на менеджмент, которые не факт что окупятся.
А вот в строительной отрасли субподряд — нормальное и повсеместно используемое явление.
Скажите, а в вашей практике, как заказчика, не было случаев привлечения специалистов в режиме аутстаффинга? Если были — можете ли сравнить плюсы и минусы аутсорсинга и аутстаффинга?
мне кажется, что ваш (правый) вариант лучше еще и из-за «одинаковости» отношения верхней линии к B и С. У автора кажется, что линия идет от A к B, а от A к С — второстепенная и непонятно как связанная линия
наверное, не совсем корректно выразился: 3 посетителя в день, включая выходные.
конвертация посетителей в звонки не 1:1, конечно. но, тем не менее, сути это не меняет — это не просто какой-то рейтинг. многие заказчики говорили, что смотрят на позиции компании в рейтингах.
Все-таки, вы очень хорошо уходите от прямого вопроса, с которого начали.
Вопрос звучит так:
у 1С-Битрикс есть результаты независимого нагрузочного тестирования.
Есть ли подобные результаты у других систем?
Примеры нескольких проектов, которые работают не так, как должны были, конечно, важны, однако важны и примеры хорошо работающих проектов.
Можно сколько угодно скатываться в частности, ответа на вопрос о независимом тестировании не прибавится.
У меня есть мнение что сайт должен приносить прибыль и стабильно работать. Это главный критерий успешного проекта.
Остальное зависит от многих факторов, возникавших при создании сайта. Ни один из этих факторов мы не знаем.
Хотел бы рассказать о концепции выделения стилей во много разных файлов, когда это требуется и когда нет. Мысли, которые здесь написаны, основаны на моем опыте разработки клиентских проектов.
Есть большая разница между тиражными решениями и решениями «под клиента». В первых вы должны обеспечить их работу несмотря ни на что, во вторых — вы можете оптимизироват код под конкретную задачу.
Концепция компонентов в 1С-Битрикс подразумевает, что компонент можно поместить в любое место страницы или верстки, и именно поэтому у компонента могут быть свои стили, js-файлы и картинки, например. Все они хранятся в шаблоне компонента.
При размещении компонента его стили и js фалй подключаются после стилей сайта, что обеспечивает корректное отображение и работу шаблона компонента.
При просмотре страниц эти файлы кэшируются браузером и все счастливы.
Такая технология хороша при тиражном решении, однако, при создании индивидуального сайта, она часто оказывается избыточной.
Поэтому мы делаем по-другому: берем верстку, в которой стили обычно размещаются в одном файле, а у шаблонов компонентов стили удаляем. В этом случае подключаемых файлов меньше и, опять же, все счастливы.
не, так дело не пойдет. вы меня втягиваете в дискуссию, из которой нет нормального выхода.
давайте разберемся в сути.
1. Есть мнение, что все скрипты и стили должны быть в малом количестве файлов.
2. Есть мнение, что это неважно
Насколько я понимаю, разработчики 1С-Битрикс в настоящее время придерживаются мнения №2, но, при этом, вполне себе толерантны к мнению №1 и желающие могут его реализовать.
Поэтому, какой бы вариант не выбрал заказчик, для него есть решение.
Также ниже см. вариант, который мы используем для разработки проектов на 1С-Битрикс (если вам интересно, конечно)
По моему опыту написания технических заданий и составления договоров, к сожалению, вы не убережете себя от всех нюансов. Фактически, есть несколько вариантов. Например, вариант, когда все неописанное в договоре трактуется в пользу исполнителя. В этом случает вы формально правы, но если вы разработали плохо или не то — то вы потеряли заказчика.
Бизнес веб-студии — это услуги, и сарафанное радио играет очень большую роль в рекомендациях клиентов.
Другой вариант — когда вы в договоре прописываете каждую мелочь. Но в этом случае затраты на документооборот очень сильно возрастают.
Возможно, это оправданно для очень дорогих проектов. Но для небольших — вряд ли.
Я, как руководитель веб-студии, тоже давно смотрю на Agile и даже ходил вместе с разработчиками на тренинги, но, судя по всему, максимум, что мы можем делать — это разбивать проект на небольшие этапы, каждый из которых можно сравнительно быстро сделать.
Увы, все проблемы, которые вы описали, актуальны и очень интересно узнать, как их решают в других веб-студиях.
Только, можно попросить в графиках:
1. Подписать ось Y — не для всех очевидно что это за числа, и указать, что лучше (меньшее число или большее)
2. Сделать более отличающиеся цвета у single disk и у RAID 10
1. У вас наружу смотрел apache
2. Не было nginx или другого аналогичного сервера
3. При старте системы очень быстро приходило много http запросов, из-за чего число процессов apache достигало критического для системы значения (50?) и у вас заканчивалась и оперативная память, и swap, из-за чего сервер переставал отвечать на какие-либо запросы?
4. однако, запуск скрипта из crontab все-таки работал?
Если да, то именно последний пункт — «запуск чего-нибудь из crontab» является интересным моментом. Это ценная информация.
Остальное, увы — действительно неправильно настроенный сервер.
Для предотвращения именно этой ситуации (с маленьким ростом нагрузки) проще всего было настроить так:
1. nginx как front-end
2. apache с числом одновременных процессов 5-10
в этом случае у вас будет практически невозможным перерасход памяти и вы всегда можете подключиться по ssh.
если при этом у вас nginx еще отдает статику — это будет дополнительное снижение нагрузки.
Увы, часто меры принимаются постфактум.
У себя мы, например, 3 года назад принудительно перешли на разработку в UTF-8. И счастливы.
И, на самом деле, я рад что из рекомендованных хостингов исчез Мастерхост и РБК. У них традиционно тяжело с качественной настройкой PHP
А вот в строительной отрасли субподряд — нормальное и повсеместно используемое явление.
Скажите, а в вашей практике, как заказчика, не было случаев привлечения специалистов в режиме аутстаффинга? Если были — можете ли сравнить плюсы и минусы аутсорсинга и аутстаффинга?
конвертация посетителей в звонки не 1:1, конечно. но, тем не менее, сути это не меняет — это не просто какой-то рейтинг. многие заказчики говорили, что смотрят на позиции компании в рейтингах.
Вопрос звучит так:
у 1С-Битрикс есть результаты независимого нагрузочного тестирования.
Есть ли подобные результаты у других систем?
Примеры нескольких проектов, которые работают не так, как должны были, конечно, важны, однако важны и примеры хорошо работающих проектов.
Можно сколько угодно скатываться в частности, ответа на вопрос о независимом тестировании не прибавится.
Остальное зависит от многих факторов, возникавших при создании сайта. Ни один из этих факторов мы не знаем.
Есть большая разница между тиражными решениями и решениями «под клиента». В первых вы должны обеспечить их работу несмотря ни на что, во вторых — вы можете оптимизироват код под конкретную задачу.
Концепция компонентов в 1С-Битрикс подразумевает, что компонент можно поместить в любое место страницы или верстки, и именно поэтому у компонента могут быть свои стили, js-файлы и картинки, например. Все они хранятся в шаблоне компонента.
При размещении компонента его стили и js фалй подключаются после стилей сайта, что обеспечивает корректное отображение и работу шаблона компонента.
При просмотре страниц эти файлы кэшируются браузером и все счастливы.
Такая технология хороша при тиражном решении, однако, при создании индивидуального сайта, она часто оказывается избыточной.
Поэтому мы делаем по-другому: берем верстку, в которой стили обычно размещаются в одном файле, а у шаблонов компонентов стили удаляем. В этом случае подключаемых файлов меньше и, опять же, все счастливы.
Как-то так.
давайте разберемся в сути.
1. Есть мнение, что все скрипты и стили должны быть в малом количестве файлов.
2. Есть мнение, что это неважно
Насколько я понимаю, разработчики 1С-Битрикс в настоящее время придерживаются мнения №2, но, при этом, вполне себе толерантны к мнению №1 и желающие могут его реализовать.
Поэтому, какой бы вариант не выбрал заказчик, для него есть решение.
Также ниже см. вариант, который мы используем для разработки проектов на 1С-Битрикс (если вам интересно, конечно)