Разработка: on-line vs off-line
До этого времени все, что я создавал в интернете, я делал on-line, то есть на своих сайтах без использования сред разработки. Я имею в виду, что мои плагины, изменения в дизайне шаблонов и все остальное (в том числе мелкие правки кода) делались на живых сайтах. Но вот пришлось мне переехать в работе на Denwer, и тому есть несколько причин (написано для обычного хостинга, не для VDS или собственного сервера):
| Параметр сравнения | On-line | Off-line |
| Скорость обновления страницы | Зависит от скорости соединения с интернетом. У меня высокая, но помните про необходимость соединения – это занимает порой секунды, если сервер, на котором находится сайт, перегружен или есть другие возможные проблемы даже на линии провайдера. | Максимальная скорость, равная скорости открытия обычной папки |
| Лог ошибок | Использование лога на сервера – стандартные настройки детальности отображения, ничего нельзя поменять (в большинстве случаев) | Возможность кое-что изменить – включить/отключить логирование разных элементов, поковырявшись немного |
| Тестирование на живом сайте | Вы сразу смотрите, как будет работать тот или иной код на вашем сайте – не придется допиливать и помнить про [не]установленные/[не]настроенные модули или библиотеки | Использование Denwer’a или LAMP/WAMP дает вам возможность тестировать лишь на стандартных настройках и нет полной гибкости и приближенности к реальности. |
В целом можно сказать, что работа off-linе – быстрее в самом процессе разработки, но на этапе внедрения могут быть проблемы.
По мере придумывания, эта таблица будет расширяться. Буду благодарен, если вы поможете :)
Не мало важным обстоятельством является вообще работать с сайтом, когда нет возможности выхода в инет. Причины самые разные. Командировки. Отсутствие сети по вине провайдера и т.д. Россия есть Россия. И Москвой она не ограничена.
Если это работа, то резервный канал должен быть. Когда в начале 2000х фрилансили здесь, в 600 км от Москвы – на этот случай всегда был резерв. Основной диалап 57600, запасной диалап 33600, GPRS :-).
Что уж говорить про наши дни, и особенно про крупные города, где и провайдеров много, и домашних сетей, и вайфай споты есть, и 3G. Можно запросто при наличии необходимости иметь несколько резервных каналов.
@Святослав:
А я украинец и живу в Харькове :)
@BaRoN!:
Я тоже начинал с диалапа… Эх, иногда не хватает его звука подключения, этот ласкающий слух стрекот и переливы непонятного звука… ))))
Идеальное решение – это локальная система, в точности повторяющая сервер. С парлями, путями и прочим. Если на десктопе не *них, то хотя бы виртуальный, через VMware. И тогда стадия внедрения сведется к одной синхронизации (ftp, svn, git – неважно).
Султан,
Не бывает идеального переезда – ну вот не верю в это. Всегда мелкая скрытая проволочка остается… И так обидно становится – вроде ведь все продумал…
Как быть с правами доступа при переносе файлов с хостинга на Денвер и обратно?
Роман,
возникают проблемы?
Sol,
все равно море подводных камней может быть :) идеально – это полный бэкап на уровне железа, затем внедрение фичи и потом восстановление, причем БД – это отдельный сервер
Как вариант, взять например XenServer и устанавливать ОС + сайт в виртуалке.
Потом без проблем можно переносить на другой(более мощный например) сервер или делать копию текущего образа
PS: это конешно вариант только для выделенного сервера
А вот подскажите пожалуйста, кто какими методами пользуется, вот есть сервер, каким образом можно сделать или полный бекап или записать на болванку все что есть на сервере, что-то у меня не получалось и я оставил это до лучших времен… Спасибо
dimanet,
существует такой вариант.. но он не без минусов :)
хотя плюс очевидный – виртуалка не зависит от железа ;)
Не все виртуалки прямо такие независимые, но в данном случае так, тк ядро юниксов под Xen переписано у всех основных типов Unix OS