Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 54
Возможность локальной работы, без интернета. Поэтому были исключены многие онлайн сервисы, такие как koding.com, а так же системы контроля версий.
Не вижу зависимости между «локальной работой» и «системами контроля версий».
Я успешно использую тот же git (bitbucket) для поддержки репозиториев кода и конфигов. И работаю локально.
Я тоже сразу подумал о git'e, когда столкнулся с данной задачей. Но синхронизировать базы там гораздо сложнее, если вообще возможно. Плюс требуется постоянно делать комиты и пуши. Мне кажется для соло разработчика это решение лучше.
Всё зависит от размера базы. Относительно небольшие можно хранить просто как sql-дампы в системе контроля версий. Благодаря этому появляется версионность базы и полная синхронность с исходниками. А если использовать mercurial, в репозиторий сохраняются только diff'ы.
Т.е. сценарий, когда я внес изменения в базу, сделал дамп, запушил на одной машине, потом запулил на другой, а еще залил дамп и перегрузил базу, вы считаете лучшим, чем полностью автоматическая синхронизация за считанные секунды?
Если делать это всё вручную, то звучит достаточно долго, хотя на практике занимает не больше минуты. Но это всё можно автоматизировать, чтобы надо было только скрипт запустить. Просто как я понял, в вашем варианте нет версионности базы и если нужно откатиться на предыдущую версию или на соседнюю ветку, то можно папасть в неработоспособную среду.
Кстати для версионирования базы есть отдельные, более автоматизированные, решения. Тут даже на хабре пару раз писали. Мне просто не очень часто приходится базу синхронизировать, поэтому автоматизацией этого процесса особо не занимался.
Кстати для версионирования базы есть отдельные, более автоматизированные, решения. Тут даже на хабре пару раз писали. Мне просто не очень часто приходится базу синхронизировать, поэтому автоматизацией этого процесса особо не занимался.
Вообще для этого существуют миграции баз данных. Плюс еще на сервер деплоить становится проше
с помощью hook-ов git-а можно настроить автовыгрузку и автозагрузку базы из дампа
Читая подобные статьи понимаю, что выбор ноутбука в качестве основного рабочего инструмента был верным решением 8 лет назад и остается им до сих пор.
Носить с собой ноутбук не всегда удобно. Мне вот лично до работы сейчас поболее часа добираться.
Постоянно таскать с собой ноут по городу/метро — то ещё удовольствие.
Постоянно таскать с собой ноут по городу/метро — то ещё удовольствие.
А я вот за 5 лет уже начинаю подзадалбываться каждый день на работу с сумкой ходить…
Как показывает практика, для разработки в связке Apache/PHP под мак какие-то готовые стеки подходят не очень, учитывая наличие встроенного в ОС веб-сервера. Сборка и подключение расширений проходят как танец с бубном.
И мне так же, как и bvn13, думается, что разница между git и G drive при оффлайн-работе минимальна. К тому же в системе контроля версий мержить можно ручками, а как разрешать конфликты настолько же гибко в облачных папках мне неизвестно.
Upd. не туда, простите.
И мне так же, как и bvn13, думается, что разница между git и G drive при оффлайн-работе минимальна. К тому же в системе контроля версий мержить можно ручками, а как разрешать конфликты настолько же гибко в облачных папках мне неизвестно.
Upd. не туда, простите.
Каждый делает выбор основываясь на своих специфических требованиях, которые могут включать очень большое количество различных факторов. И ноутбук далеко не таблетка от всех болячек для программиста.
Как по мне так это вообще костыль: Испытывать дискомфорт в размере монитора и размерах клавиатуры постоянно + перемещение его, и его комплектации за собой постоянно (личный транспорт конечно убирает большую часть этого неудобства)…
Как по мне, задачу синхронизации можно решить более качественно ;)
Я уже молчу, про соотношение цен на эквивалент по мощности для стационарного компа с хорошими, если не топовыми характеристиками…
Как по мне так это вообще костыль: Испытывать дискомфорт в размере монитора и размерах клавиатуры постоянно + перемещение его, и его комплектации за собой постоянно (личный транспорт конечно убирает большую часть этого неудобства)…
Как по мне, задачу синхронизации можно решить более качественно ;)
Я уже молчу, про соотношение цен на эквивалент по мощности для стационарного компа с хорошими, если не топовыми характеристиками…
Я периодически синхронизирую данные между ноутбуком и обычным компом )
Начав работать на 2х мониторах full HD, я понял как же я ошибался работая на ноутбуке.
Все что нужно — GIT и поднятный локальный сервак на всех машинах, на которых ведется разработка (точнее на тех, где необходимо обеспечить возможность работать в оффлайне). Вы какой-то чушью занимаетесь, ей богу. 2013 год на дворе.
Вся фишка в автоматизме. А еще в синхронизации базы данных.
Мы на разных языках говорим. Извините.
Ключевые слова для гугла: репликация баз данных, git.
Ключевые слова для гугла: репликация баз данных, git.
Действительно на разных. Повторюсь, дело в автоматизации процесса. Согласитесь, как альтернатива такое решение имеет право на существование?
Как плохая альтернатива — имеет.
Для синхронизации файлов — есть git, для синхронизация баз — штатные средства БД. Вы для этого используете инструмент, который предназначен для другого.
В чем выгода-то?
Вы совершенно определенно работаете в гордом одиночестве, и притягиваете на разные машины одни и те же собственные правки. То есть вероятность конфликтов правок стремится к нулю. Можно и с помощью GIT автоматическое притягивание изменений сделать, если уж сильно приперло. Думаю я не один такой, для кого git pull origin master при начале работы — как руки перед едой помыть.
Дело то ваше, конечно. Нравится так синхронизировать — ну и здорово. Только все равно при появлении еще хотя бы одного разработчика или верстальщика придется переходить на GIT, Dropbox там не спасет.
Повторюсь, для того, что вы делаете, существуют специально созданные для этого инструменты.
Для синхронизации файлов — есть git, для синхронизация баз — штатные средства БД. Вы для этого используете инструмент, который предназначен для другого.
В чем выгода-то?
Вы совершенно определенно работаете в гордом одиночестве, и притягиваете на разные машины одни и те же собственные правки. То есть вероятность конфликтов правок стремится к нулю. Можно и с помощью GIT автоматическое притягивание изменений сделать, если уж сильно приперло. Думаю я не один такой, для кого git pull origin master при начале работы — как руки перед едой помыть.
Дело то ваше, конечно. Нравится так синхронизировать — ну и здорово. Только все равно при появлении еще хотя бы одного разработчика или верстальщика придется переходить на GIT, Dropbox там не спасет.
Повторюсь, для того, что вы делаете, существуют специально созданные для этого инструменты.
тогда как вам такой вариант: выбрать компьютер с выходом в интернет без NAT, поднять на нем OpenVPN-сервер, на всех рабочих машинах — клиенты. В проектах с базой работать через OpenVPN и делать регулярные дампы базы в архив. Результат: база всегда одна и едина.
Для синхронизации базы данных при разработке хорошо использовать фикстуры.
1. Вы никогда не потеряете данные
2. Вы всегда можете их обновить
3. Они контролятся тем же гитом
4. Можно делать разные фикстуры под свои нужды (к примеру тестовая база только для юнит тестов)
1. Вы никогда не потеряете данные
2. Вы всегда можете их обновить
3. Они контролятся тем же гитом
4. Можно делать разные фикстуры под свои нужды (к примеру тестовая база только для юнит тестов)
У меня похожее решение, только я использую Open Server и установлен он у меня просто в папку с Дропбоксом. А так как при запуске сервера он создает себе виртуальный диск и запускается там — то не имеет значения где расположены файлы. За 3 года небыло никаких проблем при синхронизации, ни с файлами проэктов, ни с БД, ни с конфигами.
И лучшее решение… барабанная дробь… флешка!
Чтобы не настраивать рабочую среду на разных машинах, я установил всё под vmware и скопировал. На данный момент рабочая среда пережила уже одну смену компьютера и два падения жесткого диска. Ну а исходники и пр. через всякие bitbucket'ы.
Можно проще.
Я создал шифрованный контейнер TrueCrypt, который монтирую как отдельный диск (такая виртуальная флешка). И все что нужно лежит в этом контейнере.
Сразу решается несколько проблем:
— Защита проекта стойким шифрованием (для параноиков)
— Меньше возни с путями для файлов, в некоторых случаях можно использовать Portable-версии софта
— Меньше глюков синхронизации.
Я создал шифрованный контейнер TrueCrypt, который монтирую как отдельный диск (такая виртуальная флешка). И все что нужно лежит в этом контейнере.
Сразу решается несколько проблем:
— Защита проекта стойким шифрованием (для параноиков)
— Меньше возни с путями для файлов, в некоторых случаях можно использовать Portable-версии софта
— Меньше глюков синхронизации.
Годная конфигурация — флешка + vagrant + chef/puppet + git
Все прелести использования dropbox и аналогов к сожалению перечеркивает один минус — они не умеют синхронизировать симлинки :(
Все прелести использования dropbox и аналогов к сожалению перечеркивает один минус — они не умеют синхронизировать симлинки :(
А зачем синхронизировать симлинки? Они ведь созданы на машине, и указывают на диск, а не наоборот.
Если Ваш documentroot находится на облачном диске и Вы используете в нем симлинки для того, чтобы не плодить контент (например папки с картинками, файлами между frontend и backend), ожидайте неприятных сюрпризов.
В моей практике также было, что dropbox очень качественно попортил локальный репозитарий git когда пришлось включить старый компьютер после 3-4 месяцев простоя.
В моей практике также было, что dropbox очень качественно попортил локальный репозитарий git когда пришлось включить старый компьютер после 3-4 месяцев простоя.
bittirrent sync?
Windows, Mac OSX — это еще не кросплатформенный, под линукс же нет %)
Как писали выше — репликация БД + git. Все люди так и работают.
Однако, как вариант который иногда требуется — поднять свой маленький тестовый сервак, например на каком-нибудь WD MyBookLive, настроить ему DynDNS и работать откуда угодно если требуется именно реальный серв — он отовсюду будет виден одинаково. Проблема бэкапа решается, опять же, git + репликация БД.
Однако, как вариант который иногда требуется — поднять свой маленький тестовый сервак, например на каком-нибудь WD MyBookLive, настроить ему DynDNS и работать откуда угодно если требуется именно реальный серв — он отовсюду будет виден одинаково. Проблема бэкапа решается, опять же, git + репликация БД.
А вот поделитесь опытом, как вы репликацию на трех машинах настраиваете (с учетом, что запись идет в локальный сервер БД)? В кольцо ее замыкаете?
Если для инфраструктуры включающей MyBookLive — тогда все более чем очевидно, головная база лежит на нем а он включен 24/7.
Если для инфраструктуры без него, тогда головную базу оставляю на компе, за которым работаю большее время.
На худой конец, никто не отменял возможность слить дамп БД в любой момент, что в принципе можно сделать одним кликом по скрипту.
Все сугубо индивидуально.
С недавних пор на работу поставили один небольшой серверочек на атоме, который также включен 24/7 (кушает мало, атом же), и для целей локальной синхронизации он решает все проблемы.
Для файлов используем SugarSync, тариф на 100 GB, весь код в проектах лежит на bitbucket.
Если что-то коряво объяснил — спрашивайте, уточню.
Если для инфраструктуры без него, тогда головную базу оставляю на компе, за которым работаю большее время.
На худой конец, никто не отменял возможность слить дамп БД в любой момент, что в принципе можно сделать одним кликом по скрипту.
Все сугубо индивидуально.
С недавних пор на работу поставили один небольшой серверочек на атоме, который также включен 24/7 (кушает мало, атом же), и для целей локальной синхронизации он решает все проблемы.
Для файлов используем SugarSync, тариф на 100 GB, весь код в проектах лежит на bitbucket.
Если что-то коряво объяснил — спрашивайте, уточню.
Только вот с InnoDB таблицами при таком тупом копировании файлов, могут быть большие проблемы.
как бы в самой статье мало чего полезного, можно было двумя словами написать «делайте симлинки».
В целом, проблема так и не решится, например, МАС и винда по разному работают с правами на файлы, а сайты то вообще в линуксе будут, даже если использовать ХАМРР на обеих машинах проблемы могут быть другого порядка, про AMPPS я не слышал, но если это не виртуальная машина, то легче не станет.
Мой вариант такой:
— VirtualBox с Linux + веб-сервер
— некоторые даже в виртуалку ставят графическую систему с системами IDE + все остальное (например, Drupal quickstart)
Если нужно экономить трафик, то есть 2 пути:
— поискать где-то на хабре была статья про Dropbox trueCrypt в которой рассказано как настроить что бы обновлялись нужные части диска (не проверял, но может поможет)
— в виртуальной машине сделать несколько дисков: система, базы данных, файлы. Ну и синхронизировать только нужные диски (систему только один раз синхронизировать и если на нее не ставит новый софт или делать настройки, то ее можно больше не синхронизировать)
В целом, проблема так и не решится, например, МАС и винда по разному работают с правами на файлы, а сайты то вообще в линуксе будут, даже если использовать ХАМРР на обеих машинах проблемы могут быть другого порядка, про AMPPS я не слышал, но если это не виртуальная машина, то легче не станет.
Мой вариант такой:
— VirtualBox с Linux + веб-сервер
— некоторые даже в виртуалку ставят графическую систему с системами IDE + все остальное (например, Drupal quickstart)
Если нужно экономить трафик, то есть 2 пути:
— поискать где-то на хабре была статья про Dropbox trueCrypt в которой рассказано как настроить что бы обновлялись нужные части диска (не проверял, но может поможет)
— в виртуальной машине сделать несколько дисков: система, базы данных, файлы. Ну и синхронизировать только нужные диски (систему только один раз синхронизировать и если на нее не ставит новый софт или делать настройки, то ее можно больше не синхронизировать)
Симлинками тут дело не ограничивается. Как минимум нужно еще отключить логирование :)
В целом, не понял о чем ваш комментарий, но проблема решена, и прежде чем написать сюда, я провел тестирование. Никаких проблем с правами на файлы не было, ведь каждая система имеет свою копию файлов. Виртуалка это такой кошмарный костыль, как по мне.
В целом, не понял о чем ваш комментарий, но проблема решена, и прежде чем написать сюда, я провел тестирование. Никаких проблем с правами на файлы не было, ведь каждая система имеет свою копию файлов. Виртуалка это такой кошмарный костыль, как по мне.
В чем заключается «костыльность» виртуалки? Вы ее использовали ранее?
Назначение виртуалки ПОЛНОСТЬЮ эмулировать сервер на котором будет работать ваш сайт, практически вы получаете копию сервера Linux на котором работает ваш сайт. Проблем при работе виртуалки даже в теории быть не может ибо мы переносите не часть системы, а всю систему. При этом данный подход будет работать не только в винде и МАС, но и в любом линуксе, везде где запустится VirtualBox и везде будет 100% одинаковая работа. Уточните в чем костыльность данного подхода.
Это Денвер в данном ракурсе костыль.
Назначение виртуалки ПОЛНОСТЬЮ эмулировать сервер на котором будет работать ваш сайт, практически вы получаете копию сервера Linux на котором работает ваш сайт. Проблем при работе виртуалки даже в теории быть не может ибо мы переносите не часть системы, а всю систему. При этом данный подход будет работать не только в винде и МАС, но и в любом линуксе, везде где запустится VirtualBox и везде будет 100% одинаковая работа. Уточните в чем костыльность данного подхода.
Это Денвер в данном ракурсе костыль.
Просто хочу похвастаться. Вот недавно перешёл на такую схему: всё под контролем git, включая sql-дампы. Сохраняю не всю базу, потому что данные проще получить из сети на свежеустановленном рабочем месте (ну, такая специфика). Взятая VDS-ка является по сути сервером разработки, на который я отправляю изменения в репозитории. На рабочий сервер, кстати, всё шлёт скрипт deploy.sh (rsync), настраивает окружение setup.sh (права доступа на файлы и папки).
Раньше я был глупее и синхронизировал всю папку с проектом (вместе с .git) обычным дропбоксом.
Раньше я был глупее и синхронизировал всю папку с проектом (вместе с .git) обычным дропбоксом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Синхронизация рабочего пространства веб-разработчика