Как в Git получить все изменённые файлы между двумя коммитами

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 Amazon CloudFront

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

Открыл для себя 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 2.2.x

С трудом поставил новый 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>

<VirtualHost 127.0.0.1>
   DocumentRoot “d:/sitename/website”
   ServerName sitename
</VirtualHost>

Первая инструкция VirualHost для localhost, который у меня находится в htdocs папки, где установлен Apache. Вторая и последующая инструкции для новых виртуальных сайтов. После внесения изменения перегружаем сервис Apache, не забываем внести название сайта sitename в host файл.