Взявшись после долгого перерыва за разработку сайта понял, что время для разработчика летит еще быстрее, чем для любого другого.

Так, например, что бы эффективно программировать на RoR необходимо изучить следующую пачку технологий:

• собственно Ruby
• Rails framework
• GIT - система контроля версий
• RSpec - система автотестирования
• Capistrano - систем развертывания (deploy) сайта
• MySQL (или любой другой DB) - понятно
• mongrel - веб бек-енд сервер

Ну и вкупе, что само собой разумеется:

• HTML
• Javascript (AJAX)
  
• CSS
• хорошо бы Prototype или что-то похожее (Javascript framework)
• хороший text editor (VIM, Emacs)
• apache (nginx)

Из этих списков видно, насколько тяжела и неказиста жизнь простого программиста :)

Если взять совокупное время на изучение этих технологий, то становится понятным, почему разработка сайта на RoR не может стоит дешево.

Отдельной срокой стоит выделить миграцию с SVN на Git и обновление версий Rails (старые сайты все равно нужно суппортить), вследствие которых достаточно большой объем новой информации нужно впитывать заново.

 

Вот ведь как бывает, когда обновляешь систему с rails сайтами.

Все сайты крутились под Freebsd 4.11 и как-то незаметно пришло время обновиться. Поставилась FreeBSD 7, установились свежие рельсы, и наступила пора переноса сайтов. Ох.

Некоторые сайты крутились еще на fcgi, и использовались rails 1.1.6.

А не перевести ли на Rails 2? Сказано-сделано. Для начала завести все как было на новом хосте.

Не буду утомлять, пришлось сделать правки в mysql.rb как написано здесь 

http://railized.com/2008/2/17/wrong-argument-error-when-running-rails-1-1-6-with-ruby-1-8-6

и в boot.rb заменить require_gem на gem в двух местах. И, в принципе, все поднимается.

Ах да, если юзалась LoginSystem от Rails 1, то в Rails 2 об этом следует забыть и часть кода попросту переписать.

PS. Git рулит!

 

Довольно часто данные изменяются на продакшн-сервере, и обычно хочется экспериментировать над свежей копией данных в своем rails приложении.

Тем, кто пользуется для разворачивания приложений capistrano есть хорошая новость: сделать такую вещь весьма несложно.

Итак, у нас в production FreeBSD 7.0, для разработки пользуемся рабочей станцией с ubuntu 8.04.

Рецепт capistrano слегка модифицированный взят отсюда: http://programmingishard.com/code/495

добавляем в config/deploy.rrb

 desc "Load production data into development database"
task :load_production_data, :roles => :db, :only => { :primary => true } do
  require 'yaml'
 
  database = YAML::load_file('config/database.yml')
 
  filename = "dump.#{Time.now.strftime '%Y-%m-%d_%H:%M:%S'}.sql"
  on_rollback { delete "/tmp/#{filename}" }
 
  run "mysqldump -u #{database['production']['username']} --password=#{database['production']['password']} #{database['production']['database']} > /tmp/#{filename}" do |channel, stream, data|
    puts data
  end
  get "/tmp/#{filename}", filename
#  exec "/tmp/#{filename}"
  exec "mysql -u #{database['development']['username']} --password=#{database['development']['password']} #{database['development']['database']} < #{filename}; rm -f #{filename}"
end

после чего пользуемся:

cap load_production_data

и вуаля, свежая копия базы с production у нас в development!

 

На замену безвременно ушедшему плагину Google Sync Google предлагает установить бету плагина Mozilla Weave.

Установил. Вот они, радости браузерного бытия: в отличие от безупречно работающего sync weave нагло тормозит, выполняя синхронизацию почему-то ПОСЛЕ закрытия браузера. Т.е. закрываешь браузер, и еще в течение нескольких минут наблюдаешь окошко синхронизации, которое лично я в 70% случаев просто закрываю, ибо некогда. В последних апдейтах разработчики, видимо осознав пикантность этого дела, добавили индикаторы прогресса, дабы человек понимал, что что-то происходит, а не тупо висит.

На линуке же mozilla weave после некоторого времени вообще отвалился ссылаясь на ошибку криптосистемы.

Google Sync, кстати выпустили в свободное плавание открыв код. Но кому же доверить мои сексуальные данные, пароли к формам? Не думаю что решусь это сделать, разве что проинсталить sync на свой сервер.

Sync! Вернись, все простим :)

 

С nginx мы как-то сразу не подружились.

Синтаксис другой, для запуска php требуются велосипеды в виде стартующих демоны скриптов. Parser3 не запустится, mod_rewrite странноват.

Вывод: nginx рулит под нагрузкой, т.е. там где один сайт размазан и разбалансирован по куче серверов.

На виртуальный хостинг nginx не годится :( Опыт не удался.

И обратно приходим к апачу 2.x

Ах да, может кому пригодятся найденные и подпиленные rc-style скрипт запуска php процессов в Freebsd.

ставил php5 из портов и nginx

----------------- /usr/local/etc/rc.d/spawn.sh -------------------------

#!/bin/sh
# Define these fcgiphp_* variables in one of these files:
#       /etc/rc.conf
#       /etc/rc.conf.local
#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
#
fcgiphp_enable=${fcgiphp_enable-"NO"}
fcgiphp_flags=${fcgiphp_flags-"-s /tmp/php-fcgi.sock -u www -g www"}

. /etc/rc.subr

name="fcgiphp"
rcvar=`set_rcvar`
command="/usr/local/bin/spawn-fcgi"
fcgi_server="/usr/local/bin/php-cgi"
fcgi_server_short="php-cgi"

load_rc_config $name

start_cmd="echo \"Starting ${name}.\"; ${command} -f ${fcgi_server} ${fcgiphp_fl                                                                             ags}"
stop_cmd="echo \"Stopping ${name}.\"; while [ 1 ]; do killall ${fcgi_server_shor 

 

и в самом rc.conf 

fcgiphp_enable="YES"

 

в nginx.conf

 location ~ \.php$ {
                fastcgi_pass   unix:/tmp/php-fcgi.sock;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /www/site/htdocs$fastcgi_script_name;
                include        fastcgi_params;
                }
 

 

Строительство сайта.
Как объяснить клиенту что такое сайт и каковы этапы его разработки? Среднестатистическому пользователю достаточно сложно понять технические нюансы разработки сайта, как и на что влияют принимаемые условия, и какими должны быть соглашения между разработчиком и клиентом.
А предложите клиенту относиться к разработке сайта точно также как к постройке дома. Каким должен быть сайт? А каким должен быть дом? В любом случае у клиента уже должно быть видение, что должно быть в доме(сайте), количество этажей, окон, комнат - это структура сайта. Дом может быть как недорогим одноэтажным(сайты-визитки), так и настоящими очень дорогими зАмками с подземными входами.

  читать далее >>

Внимание,

в связи с переездом домена сайт http://it-expert.com.ua теперь будет расположен по адресу http://nexus.org.ua.

Автоматический редирект с сохранением ссылок выполнен следующим образом:

1. в апаче создаем хост nexus.org.ua, где и прописываем нужного юзера в suexec.
2. каталог /www/it-expert.com.ua на сервере переименовываем в /www/nexus.org.ua, переназначаем права chown -R nexus:suwww nexus.org.ua.
3. создаем /www/it-expert.com.ua и структуру каталогов для апача, например, htdocs. chown -R it-expert.com.ua:suwww it-expert.com.ua
4. в /www/it-expert.com.ua/htdocs создаем .htaccess, в который вписываем следущее:

RewriteEngine On
RewriteBase /
RewriteRule (.*) http://nexus.org.ua/$1 [R=permanent,L]

И вуаля, все работает со старыми ссылками на новом домене nexus.org.ua.

Ну а через некоторое время по адресу http://it-expert.com.ua будет находится сайт нашего предприятия по предоставлению услуг IT аутсорсинга.

P.S. А вот и статья об отношении поисковиков к 301 редиректу с сайта. 

 

Тихо и незаметно вызрел еще один сайт на Ruby on Rails. 

Сей сайт находится по адресу http://nxt.com.ua

Rails 2.0, пользует плагины acts_as_tree, in_place_editing, restful_authentication, tiny_mce 

 

 

От читателя поступил вопрос, как сделать так, что бы в браузере изображений url были бы не вида ../../images, а /images ?

Очень просто, достаточно добавить в вызов tiny_mce  в контроллере такие параметры:

:relative_urls=>false,
:convert_urls=>true

и ваши url будут вида /images  и т.д.
хотя, при правильной разработке, этого не требуется. 

Плагин ActiveSearch просто чудо какое-то, большое человеческое спасибо julik.nl за его разработку.

Штука сия облегчает и без того легкую жизнь ;-) rails-девелопера при разработке простейшего поиска по записям базы.

Идея сего плагина такова: используя разнообразные инексаторы исходя из планируемого объема данных вырабатываем оптимальный подход к поиску по записям базы.

Например, мой сайт содержит весьма небольшой объем данных, и, как рекомендует Julik, при объеме до 500 записей целесообразно использовать простейший индексатор ActiveSearch::LikeIndexer.

Для того чтобы поиск заработал необходимо:

1. Установить плагин:

cd project

ruby script/plugin install http://julik.textdriven.com/svn/tools/rails_plugins/simple_search/ 

2. Добавить поле searchable к таблицам, по которым вы собираетесь искать. Целессобразно сделать это через миграцию:

  def self.up
    add_column("products","searchable", :text)
    add_column("categories","searchable", :text)
   
 end 

def self.down   
    remove_column("products","searchable")
    remove_column("categories","searchable")
  end

3. В моделях Product и Category добавляем указание к индексированию:

   indexes_columns :title, :short_description, :long_description

4.  запустить начальное индексирование:

консоль rais:

ruby script/console

в консоли

Products.indexers[0].rebuild!

Category.indexers[0].rebuild!

Все, теперь мы можем достаточно быстро искать по записям:

@found_categories = Category.indexers[0].query(@query)
@found_products = Product.indexers[0].query(@query)

 Можно искать и по Category.find_using_term("query"), как в документации указано, но, видимо такое использование предполагает использование сразу нескольких индексаторов.

 

Таким образом плагин может быть использован с:

1. индексом в поле searchable в каждой модели, по которой будет производиться поиск.

2. индексом в отдельной таблице

3. индексом через плагин ferret 

способы индексации расположены в порядке увеличения количества данных для поиска.

Удобно, Julik, u made my day.