Разработка: on-line vs off-line

До этого времени все, что я создавал в интернете, я делал on-line, то есть на своих сайтах без использования сред разработки. Я имею в виду, что мои плагины, изменения в дизайне шаблонов и все остальное (в том числе мелкие правки кода) делались на живых сайтах. Но вот пришлось мне переехать в работе на Denwer, и тому есть несколько причин (написано для обычного хостинга, не для VDS или собственного сервера):

Сравнение on-line и off-line разработки
Параметр сравненияOn-lineOff-line
Скорость обновления страницыЗависит от скорости соединения с интернетом. У меня высокая, но помните про необходимость соединения – это занимает порой секунды, если сервер, на котором находится сайт, перегружен или есть другие возможные проблемы даже на линии провайдера.Максимальная скорость, равная скорости открытия обычной папки
Лог ошибокИспользование лога на сервера – стандартные настройки детальности отображения, ничего нельзя поменять (в большинстве случаев)Возможность кое-что изменить – включить/отключить логирование разных элементов, поковырявшись немного
Тестирование на живом сайтеВы сразу смотрите, как будет работать тот или иной код на вашем сайте – не придется допиливать и помнить про [не]установленные/[не]настроенные модули или библиотекиИспользование Denwer’a или LAMP/WAMP дает вам возможность тестировать лишь на стандартных настройках и нет полной гибкости и приближенности к реальности.

В целом можно сказать, что работа off-linе – быстрее в самом процессе разработки, но на этапе внедрения могут быть проблемы.

По мере придумывания, эта таблица будет расширяться. Буду благодарен, если вы поможете :)

комментариев 13

  1. Не мало важным обстоятельством является вообще работать с сайтом, когда нет возможности выхода в инет. Причины самые разные. Командировки. Отсутствие сети по вине провайдера и т.д. Россия есть Россия. И Москвой она не ограничена.

  2. Если это работа, то резервный канал должен быть. Когда в начале 2000х фрилансили здесь, в 600 км от Москвы – на этот случай всегда был резерв. Основной диалап 57600, запасной диалап 33600, GPRS :-).

  3. Что уж говорить про наши дни, и особенно про крупные города, где и провайдеров много, и домашних сетей, и вайфай споты есть, и 3G. Можно запросто при наличии необходимости иметь несколько резервных каналов.

  4. @Святослав:
    А я украинец и живу в Харькове :)

    @BaRoN!:
    Я тоже начинал с диалапа… Эх, иногда не хватает его звука подключения, этот ласкающий слух стрекот и переливы непонятного звука… ))))

  5. Sol:

    Идеальное решение – это локальная система, в точности повторяющая сервер. С парлями, путями и прочим. Если на десктопе не *них, то хотя бы виртуальный, через VMware. И тогда стадия внедрения сведется к одной синхронизации (ftp, svn, git – неважно).

  6. Султан,
    Не бывает идеального переезда – ну вот не верю в это. Всегда мелкая скрытая проволочка остается… И так обидно становится – вроде ведь все продумал…

  7. Роман:

    Как быть с правами доступа при переносе файлов с хостинга на Денвер и обратно?

  8. Роман,
    возникают проблемы?

  9. Sol,
    все равно море подводных камней может быть :) идеально – это полный бэкап на уровне железа, затем внедрение фичи и потом восстановление, причем БД – это отдельный сервер

  10. dimanet:

    Как вариант, взять например XenServer и устанавливать ОС + сайт в виртуалке.
    Потом без проблем можно переносить на другой(более мощный например) сервер или делать копию текущего образа

    PS: это конешно вариант только для выделенного сервера

  11. Игорь:

    А вот подскажите пожалуйста, кто какими методами пользуется, вот есть сервер, каким образом можно сделать или полный бекап или записать на болванку все что есть на сервере, что-то у меня не получалось и я оставил это до лучших времен… Спасибо

  12. dimanet,
    существует такой вариант.. но он не без минусов :)
    хотя плюс очевидный – виртуалка не зависит от железа ;)

  13. dimanet:

    Не все виртуалки прямо такие независимые, но в данном случае так, тк ядро юниксов под Xen переписано у всех основных типов Unix OS

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *