git diff —name-only [diff options] | xargs tar -czf files.tar.gz
оч. полезно если нужно получить только изменённые файлы, чтобы залить на хостинг, к которому есть только ftp доступ.
UPD [22.02.2013]:
Команда, выдаст ошибку, если были удалённые файлы между коммитами. Поэтому, правильнее добавить инструкцию —diff-filter.
пример:
git diff —name-only —diff-filter=ACMRTUXB «release7» «release8» | xargs tar -czf release8.tar.gz
создаст архив release8.tar.gz со всеми файлами изменёнными или добавленными с коммита с тегом «release7» до коммита с тегом «release8»
P.S. wordpress сам меняет два коротких тире на длинное тире. В git нужно писать два коротких тире перед инструкциями name-only и diff-filter
CDN — Content Delivery Network, географически распределённая сеть для ускорения доставки контента (в основном статического). По сути представляет собой, ряд серверов, в различных географических областях мира, для ускорения загрузки файлов. Т.е. если пользователь будет что-то загружать из сайта, построенного на основе CDN, то ему будут отдаваться данные с ближайшего для него сервера (ближайшего не с географической точки зрения, а с сетевой).
Услуги CDN представляют несколько компаний, я рассматриваю только Amazon CloudFront, т.к. он один из самых крупных и уже использовал раньше некоторые решения Amazon. У Amazon CloudFront всего 18 датацентров на данный момент. Из них 10 в США, 5 в Европе и 3 в Азии. Цены можно посмотреть тут: https://aws.amazon.com/cloudfront/pricing/. Что примечательно, оплата только за трафик. Т.е. если CDN не будет использоваться платить ничего не нужно (кроме 1$ снятого для проверки кредитки).
Преимущества CDN для очень крупных сайтов можно даже не перечислять, т.к. распределение работы на множество серверов там делается в первую очередь не для ускорения загрузки, а для возможности работы этих проектов в принципе и уменьшения нагрузки на сети, т.к. нет такого сервера или интернет-канала, который может выдержать, например, трафик youtube.
Для не очень больших проектов, использование CDN имеет смысл в случае большого объёма статического контента. Если сервера, например будут находиться в США, то пользователям из Европы и Азии, данные будут отдаваться гораздо медленнее. Но и внутри США CDN тоже имеет смысл использовать, т.к. это большая страна с большим количеством сетей и если сервер находится на восточном побережье, то в калифорнию сигнал идёт какое-то время.
Рассмотрим преимущества CDN для небольших проектов, для хранения статических файлов.
Ускоряется загрузка статических файлов для пользователей из разных стран мира.
Улучшается скорость загрузки сайта, что хорошо отражается на индексации и положении сайта в поисковых системах. (Скорость загрузки сайта играет определённую роль при ранжировании сайта)
Уменьшается нагрузка на сервер, т.к. статические файлы грузятся исключительно с CDN (т.е. с других серверов).
Сильно уменьшается потребление трафика на сайте, т.к. статические файлы это основной пожиратель трафика.
Минусы:
Кроме стоимости хостинга, использование СDN также стоит дополнительных денег.
Давно хотел попробовать использовать CDN для одного из проектов, но останавливало то, что нужно всё это долго настраивать. Я думал, что нужно каждый файл отправлять вручную в CDN, обновлять их, следить за целостностью кеша в CDN и т.д. — т.е. изучать API и писать много скриптов. Такой путь возможен, но оказалось всё гораздо проще.
Подключить CDN у меня заняло полтора дня. Чтобы получить доступ к Amazon CloudFront (и к другим сервисам Amazon), сначала нужно зарегистрироваться на Amazon Web Services, ввести данные своей кредитки и пройти авторизацию своего номера телефона. Через несколько минут или часов, после проверки, аккаунт будет активирован.
Затем в панели управления Amazon CloudFront нужно создать Distribution (дистрибуцию). Дистрибуция — это по сути, кеш статических файлов для отдельного сайта. Можно создать до 100 дистрибуций на аккаунт.
Первым шагом нужно указать Origin — где расположен сам сервер, на Amazon S3 либо в другом месте (Custom Origin), если отдельный сервер, нужно выбрать Custom. Затем нужно вписать название сайта, например www.mysite.com.
Во втором шаге можно указать CNAME. В принципе этот шаг не обязателен, но полезен.
После создания дистрибуции Amazon какое-то время инициализирует дистрибуцию, и даёт адрес CDN вида a1b2c3d4e5f6g7.cloudfront.net. Всё! CND работает, если на сайте, например, есть файл www.mysite.com/images/1.jpg, то его можно открыть как a1b2c3d4e5f6g7.cloudfront.net/images/1.jpg. Amazon сам скачает этот файл с сайта, распределит между своими серверами, и отдаст пользователям с ближайшего сервера, в зависимости от того, где они находятся.
Теперь насчёт CNAME. Они нужны, чтобы «спрятать» страшный урл вида a1b2c3d4e5f6g7.cloudfront.net, и чтобы безболезненно иметь возможность отказаться от CND в будущем. Для этого можно указать, например img.mysite.com и прописать его в DNS домена как CNAME с поддомена img на a1b2c3d4e5f6g7.cloudfront.net. Теперь файлы будут открываться с поддомена img.mysite.com, загружаясь на самом деле с CDN.
Для использования CDN на сайте достаточно просто поменять все ссылки на статичные файлы используя выданный адрес CDN или на указанный поддомен, в случае использования CNAME.
Остаётся только изучить Invalidate API, для экстренного удаления файлов из кеша (чтобы заменить файл более новым с сервера), но вроде есть специальные программы, скрипты, в которых это уже реализовано.
Открыл для себя Google Charts Api. Иногда нужно вывести на основе данных в каком-нибудь проекте диаграммку или простенькую динамическую схемку, а программировать вывод в HTML или отрисовать это картинкой нет ни времени ни желания.
С помощью Google Charts Api данные нужно просто передать в виде одной строчки GET параметров к картинке, а Google за нас делает всю «грязную» работу.
Например по данной ссылке: http://chart.apis.google.com/chart?chxs=0,676767,12&chxt=x&chs=400×160&cht=p3&chd=s:GMSY&chp=0.6&chl=1+ящик+водки|2+ящик+текилы|3+ящика+вина|4+ящика+пива&chtt=Как+я+провёл+лето
Будет сгенерирована, вот такая аккуратная диаграммка.
Или по такой ссылке: http://chart.apis.google.com/chart?chxl=0:|Я+Злой|Я+Нормальный|Я+Хороший&chxt=y&chs=400×200&cht=gm&chd=t:15&chl=Не+подходи%2C+укушу!&chtt=Доброметр
Вот такая:
Диаграммы могут быть самых различных типов, и можно достаточно сильно их кастомизировать. Обещают без ограничений, до 250 тыс. запросов в сутки с одного хоста, что более чем достаточно.
Чтобы не разбираться с десятками параметров, есть удобный Chart Editor: https://imagecharteditor.appspot.com/. Выбираем нужную диаграмму, настраиваем стиль и вид, а затем просто уже подставляем динамически нужные данные в скрипте.
Кроме Google Charts Api для создания статических диаграмм, есть ещё Google Visualization API для создания различных интерактивных чартов (примерно то, что можно увидеть в Google Analytics). Особо пока не разбирался, но принцип похож. Сравнение Google Charts Api и Visualization API для построения диаграмм, можно увидеть тут: https://code.google.com/intl/ru-RU/apis/charttools/docs/choosing.html.
По долгу службы я делаю несколько десятков сайтов каждый год. Часто очень сложно проверить, как они будут выглядеть в разных браузерах. Разные версии Internet Explorer’a, Oper’ы и т.д. будут по-разному показывать реализованный html-код.
Сегодня наткнулся на весьма полезный ресурс: http://browsershots.org. Нужно ввести адрес сайта, и он открывается в самых различных браузерах на разных платформах (4 платформы, более 50 браузеров разных версий) — и через некоторое время становятся доступными скриншоты сайта. Единственное, что скриншоты подготавливаются не слишком быстро, в течении получаса. Можно выловить все баги, проблемы с кодировками, подобрать шрифты, чтобы везде открывалось симпатично. Весьма удобно!
С трудом поставил новый Apache на ноутбук. Раньше на своей машине использовал старые версии — там настроить было всё просто. С того времени много чего поменялось, в новой версии всё настроить оказалось затруднительно, потратил несколько дней. Долго не мог разобраться, как настроить правильно виртуальные хосты.
В моём случае, виртуальные хосты настраивались следующим образом:
В httpd.conf расскоментируем строчку:
#Include conf/extra/httpd-vhosts.conf
(Убираем решётку вначале)
Открываем в папке extra файл httpd-vhosts.conf (папка extra находится внутри папки conf)
NameVirtualHost *:80
меняем на
NameVirtualHost 127.0.0.1
Удаляем все виртуальные хосты которые есть, пишем вместо них:
<VirtualHost 127.0.0.1>
DocumentRoot «c:/{тут путь к папке htdocs, папки куда установлен Apache}»
ServerName localhost
</VirtualHost>
Первая инструкция VirualHost для localhost, который у меня находится в htdocs папки, где установлен Apache. Вторая и последующая инструкции для новых виртуальных сайтов. После внесения изменения перегружаем сервис Apache, не забываем внести название сайта sitename в host файл.
