И ещё добавлю:
У Альфа-Банка нужно заказывать отдельную карту для электронных платежей — MasterCard Virtual. Она отлично работает с PayPal. Делают бесплатно в дополнение к основной карте, в течении недели после получения заявки.
Таг может являться «контейнером» для других тагов, каждый из которых, так же может быть контейнером. Один таг может быть включен в несколько контейнеров. Таким образом, у тага может быть несколько родителей. Главное реализовать проверку, чтобы избежать рекурсии. Связи между двумя тагами хранятся в отдельной таблице. У каждой связи есть «позиция в контейнере», по номеру позиции собираем дерево, если надо.
А это смотря что нужно получить.
Думаю, что _вся_ статика в рабочей копии просто не нужна никогда, достаточно, чтобы сохранялась структура хранилищ, это можно сделать созданием виртуальника-хранилища с ограниченным набором файлов, достаточным для разработки (скажем, выборка по базе — только за последнюю неделю).
Для тестирования можно настроить nginx на отдачу статики с боевого хранилища, а upload новых файлов — на тестовое.
Ну, я же говорил про большой проект. :)
Если же проект не большой, то и описанные вами проблемы реже возникают, и разработчиков по-меньше, а значит и ресурсы нужны скромнее.
В разработке мы используем «облегченный» дамп боевой базы, и тормозов по-меньше, и можно несколько копий поднять. Если требуется внести серьезные изменения в базу, разработчик разворачивает свой дамп базы, меняет реквизиты базы в конфиге своей копии, и правит структуру там, никому не мешая, потом комминтит изменения. Да, всё равно, конфликты могут быть, но редко и решаются быстро.
А вот много гигабайт статики на сервере разработки тоже не храним, конечно. Тут есть варианты.
Виртуализация всех спасет. «Большой» сервер-ферма под виртуальники. Отдельный виртуальник под базы (postgres, mysql), отдельный под рабочие копии (там же memcached — общий), если возникает необходимость — легко поднимаются еще виртуальники (файловые хранилища, sphinx и т.д.), благо стандартные образы под это дело всегда под рукой. Естествено, отдельный офисный svn. Так и работаем.
Для тестирования — отдельный физический сервер (или несколько), максимально повторяющий конфигурацию боевой среды.
Почти так и работаем.
Причем, уже сложно представить, как можно работать иначе, если проект действительно большой и над ним одновременно работают несколько разработчиков.
Вот именно, есть сервисы типа www.rss2email.ru предоставляющие такую услугу, поэтому дайте мне ссылку на feed и я разберусь что с ней делать.
А если это рассчитано не тех, кто RSS не пользуется (а может и вообще не знает, что это), то не надо пугать пользователей этим словом, можно так и написать "E-mail подписка на обновления сайта".
Выражение приобретает смысл в контексте заголовка данной статьи. :)
Я вовсе не хочу обидеть автора, но правда считаю, что "RSS на e-mail" - не имеет смысла.
Тут уж надо определится - либо даем пользователю RSS, с который он сможет читать как ему угодно, либо делаем e-mail подписку на обновления. Не надо смешивать.
Имхо - все лишнее, ничего этого не надо.
Стандартная иконка 14x14 с ссылкой на feed возле названия ленты - вот и все. Люди знающие, что такое RSS разберутся что с ним делать.
У Альфа-Банка нужно заказывать отдельную карту для электронных платежей — MasterCard Virtual. Она отлично работает с PayPal. Делают бесплатно в дополнение к основной карте, в течении недели после получения заявки.
Вообще, я как раз думал, что должно хорошо идти:
www.youtube.com/watch?v=y6QXaNTgT68
Но что насчет 1080p? Не пробовали смотреть? Обязательно попробуйте! :) Очень интересно.
Но почему бы хорошего человека и не поблагодарить за хорошую статью?
Сумбурно, но как-то, если в двух словах. :)
Думаю, что _вся_ статика в рабочей копии просто не нужна никогда, достаточно, чтобы сохранялась структура хранилищ, это можно сделать созданием виртуальника-хранилища с ограниченным набором файлов, достаточным для разработки (скажем, выборка по базе — только за последнюю неделю).
Для тестирования можно настроить nginx на отдачу статики с боевого хранилища, а upload новых файлов — на тестовое.
Если же проект не большой, то и описанные вами проблемы реже возникают, и разработчиков по-меньше, а значит и ресурсы нужны скромнее.
В разработке мы используем «облегченный» дамп боевой базы, и тормозов по-меньше, и можно несколько копий поднять. Если требуется внести серьезные изменения в базу, разработчик разворачивает свой дамп базы, меняет реквизиты базы в конфиге своей копии, и правит структуру там, никому не мешая, потом комминтит изменения. Да, всё равно, конфликты могут быть, но редко и решаются быстро.
А вот много гигабайт статики на сервере разработки тоже не храним, конечно. Тут есть варианты.
Для тестирования — отдельный физический сервер (или несколько), максимально повторяющий конфигурацию боевой среды.
Причем, уже сложно представить, как можно работать иначе, если проект действительно большой и над ним одновременно работают несколько разработчиков.
За статью спасибо, многим будет полезно.
А если это рассчитано не тех, кто RSS не пользуется (а может и вообще не знает, что это), то не надо пугать пользователей этим словом, можно так и написать "E-mail подписка на обновления сайта".
Я вовсе не хочу обидеть автора, но правда считаю, что "RSS на e-mail" - не имеет смысла.
Тут уж надо определится - либо даем пользователю RSS, с который он сможет читать как ему угодно, либо делаем e-mail подписку на обновления. Не надо смешивать.
Имхо - все лишнее, ничего этого не надо.
Стандартная иконка 14x14 с ссылкой на feed возле названия ленты - вот и все. Люди знающие, что такое RSS разберутся что с ним делать.