Тут кратко описан основной workflow c git:
Клонируем репозиторий:
git clone git@example.com:username/reponame.git
Когда наизменяли что-то в файлах, то выполняем:
git status
Увидим список изменённых файлов.
Тут кратко описан основной workflow c git:
Клонируем репозиторий:
git clone git@example.com:username/reponame.git
Когда наизменяли что-то в файлах, то выполняем:
git status
Увидим список изменённых файлов.
Не так давно мне надо было настраивать новый сервак. В ходе настройки я решил помечать свои действия, чтобы в будущем мне было куда подглядывать и делать это быстро. Полагаю, что эти мои пометки будут полезны и другим. Вот и получилась эта статья. Прошу заметить что данная статья в стадии черновика. Некоторые действия я мог делать в другом порядке, а потом что-то туда-сюда менять. А что-то и вовсе мог забыть пометить. Планирую при следующей настройке сервера привести в порядок эту инструкцию. А пока вот делюсь ею в таком виде =)
Дано: свежеустановленный debian6.
Задача: настроить сервер для работы с ruby on rails. Настроить и задеплоить приложение (у меня оно называлось samohodom).
Средства:
Иногда возникает ситуация, когда на рабочей машине несколько проектов, которые используют разные гемы, которые иногда могут конфликтовать. Тут очень в тему оказываются gemset’ы. Это одна из «фишек» RVM (ruby bersion manager). Если Вы ещё не пользуетесь RVM, то я писал про его установку в статье Начало работы с Ruby on Rails.
Допустим, что у Вас уже установлен RVM и надо создать gemset: Continue Reading »
http://drupal.org/project/ubercart
Включил модули ubercart’а: product, store, catalog
А дальше не удобно довольно-таки. Т.к. каждый товар имеет поля типа «артикул», «цена», «вес» и тд и тп… И получается, что эти поля из админки надо прятать. А для этого писать дополнительный модуль с кучей хуков. Плюс сам уберкарт состоит из примерно 20 модулей. Которые мы все скачиваем, но включаем только 3 из них. Вобщем для каталогов без возможности продажи не рекомендую.
13.10.2009
Тут упомяну парочку модулей для работы с блоками. Например когда клиенту надо управлять содержимым какого-то блока.
У нас как-то возникла неприятная ситуация, когда google проиндексировал рабочую копию клиентского сайта на нашем поддомене. А тем более это случилось до запуска живого сайта клиента. И при запросах в поиск наша рабочая копия была в выдаче выше, чем основной сайт. Да, нехорошо тогда получилось. Вывод: вешайте basic http-авторизацию на dev сайт во время разработки. Ну или как минимум запрещайте индексацию через robots.txt
Ну а если уж накосячили, то вешайте потом на dev сайте 301ый редирект (moved permanently). Для этого поместите в .htaccess в корне вашего dev сайта вот такие строки:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^development\.example\.com$ [NC]
RewriteRule ^(.*)$ http://example.net/$1 [R=301,L]
При такой записи если пользователь запрашивал страницу http://development.example.com/news, то он будет редирекнут на http://example.net
И для поиском 301ый редирект в данной ситуации будет лучшим вариантом.
Покажу на таком примере: какая-то информация на сайте организована через таксономию. Владельцу сайта нужно иметь доступ к изменению списка терминов, но при этом видеть непонятное ему «таксономия», а внутри «добавить словарь» – ему не надо.
Выносим пункт на листинг терминов словаря в менюшку. А в своём модуле прописываем:
Я вот решил включить feedburner к моей rss ленте, чтобы можно было видеть статистику по подписчикам. А в связи с этим просьба к тем, кто подписан на мою ленту напрямую с моего сайта изменить адрес rss на http://feeds2.feedburner.com/BestBlogName
Это позволит на сайте всем видеть количество rss подписчиков на мой блог (сейчас счётчик внизу справа), а мне даст немного информации о моих подписчиках.
Надеюсь на вашу отзывчивость и заранее спасибо =)
Продолжение серии статей по drupal, которые давно надо было опубликовать.
Тут речь про несколько замечательных модулей, которые должны помочь при решении задачи ограничения прав доступа и не показывания админу того, что ему видеть не обязательно.