spree-quick-auction

Для товаров задаем цены от х до у
Тот кто первый покупает подешевле.
Финт в том что самые дешевые можно ставить уже якобы проданными.
http://github.com/pronix/spree-quick-auction

spree-firstdata

Установка:

Скопировать firstdata_payment_gateway в папку
vendor/extensions и перезапустить spree.
spree-firstdata

Использование "and" и "or" в руби

Если вы достаточно долго используете ruby, вы откроете для себя and и or операторы.

На первый взгляд это просто синонимы && и ||.

Есть любители использовать буквы, есть любители символов(надо ж показать что вы их знаете),HO надо понимать разницу между ними.

В итоге "and" "or" не ведут себя, как и их символическое родственников. В частности, они имеют гораздо более низкий приоритет.

На данный момент, вы можете матюгнуться если это покажется слишком запутанным.

А если использовать оба варианта то код становится запутанным.

Вообще поведение and и or (как и многое в руби) уходит корнями в перл.

В перле они использовались как операторы if и unless.
Например так:

do_something() or die "It didn't work!";

Эти же операторы в руби преследуют ту же цель.
Для начала "and" и "or" не булёвые операторы, они переключают путь выполнения программы.

and

And используется для цепочек связанных операций когда одна из них может вернуть nil или false.

Пример:

` post = Post.find_by_name(name) and post.publish! `

Тут пост будет опубликован если он найден.

Чем отличается &&? Давайте экспериментировать.
` foo = 42 && foo/2 `

`NoMethodError: undefined method /' for nil:NilClass`
` from (irb):18`
` from :0`

И что же тут случилось ?
Скобочки помогут раскрыть тайну:

`foo = (42 && foo)/2`

Ожидали мы немного другое поведение(теперь-то уже понятно что ожидать такого больше не будем)

`foo = 42 and foo / 2 => 21 `

…другое дело, все как надо выполнилось.

Другой пример

1. next if widget = widgets.pop

Станет:

` widget = widgets.pop and next `


OR

or используется в тех же цепочках операций.
Лучший способ понять эту конструкцию - серия неудачных операций: попробуй способ 1 -> ошибка -> тогда попробуй способ 2 и т.д.
Пример:


` foo = get_foo() or raise "Could not find foo!" `

Пример рефакторинга.
было:

` raise "Not ready!" unless ready_to_rock? `

стало:

` ready_to_rock? or raise "Not ready!" `


Вывод: and и && так же как or и || абсолютно разные инструменты. Использовать надо каждый в своем случае.

asset_host

Если ваше приложение и статические файлы находятся на одном домене,

то броузер с сервером будут обмениваться печеньками(cookies),

что вызовет лишнюю нагрузку на канал.


Яху советует нам всем использовать разные субдомены для статики и приложения.

В итоге все будет работать быстро и потреблять ресурсов меньше.

В рельсе для этого есть параметр asset_host (лучше его использовать только в production окружении).


_config.action_controller.asset_host = "http://assets.ipronix.ru"
_

И конечно надо настроить nginx


_server {
_
_ listen 80;
_
_ server_name assets.ipronix.com;
_
root /var/www/ipronix.com/production/current/public;

_}
_


После рестарта приложения вы увидите что все стало грузиться с разных субдоменов,

и если попробуете измерить скорость и объем то получите выигрыш в каждом запросе.

Оптимизация миграций(перевод)

Миграции, по моему мнению, одна из лучших вещей в рельсе.
Но что пользоваться максимально эффективно следует придерживаться след правил.


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

class CreateInvoices ActiveRecord::Migration   def self.up     create_table :invoices do |t|       t.integer :number       t.integer :year       t.decimal :total_amount       t.date :invoice_date       t.integer :company_id       t.integer :client_id       t.timestamps     end   end   def self.down     drop_table :invoices   end end

Это обычная миграция генерируемая стандартной script/generate коммандой.
Теперь добавим индексы для сортируемых полей и ключей.

class CreateInvoices ActiveRecord::Migration   def self.up     create_table :invoices do |t|       t.integer :number       t.integer :year       t.decimal :total_amount       t.date :invoice_date       t.integer :company_id       t.integer :client_id       t.timestamps     end   end   add_index :invoices,:company_id   add_index :invoices,:client_id   add_index :invoices,:number   add_index :invoices,:year   def self.down     drop_table :invoices   end end

Индексы важны для производительности.
База начинает летать по сравнению со стандартной миграцией.
Есть несколько плагинов которые будут полезны для вашей базы.
* http://github.com/eladmeidar/rails_indexes
* http://github.com/mlomnicki/automatic_foreign_key
* http://github.com/samdanavia/ambitious_query_indexer


2. Пишите сиды.
Начиная с рельсы 2.3.4 вместо того что б вписывать данные в миграции - пишите их в seed.rb
Обращаю внимание - фикстуры для тестов,сиды для продакшена(содержит данные без которых нельзя стартануть- например список странн или список станций метро)

обход callback в рельсе

1: не в курсе как обновить атрибуты и сохранить модельку без валидации?
2: u.attributes = {:tt => 12, :yu => 78} u.save(false)
1: пасиба, а не в курсе как избежать before/after коллбеков?
2: вроде как то отключать можно
1: @user_profile.send(:update_without_callbacks)

обход callback в рельсе

1: не в курсе как обновить атрибуты и сохранить модельку без валидации?
2: u.attributes = {:tt => 12, :yu => 78} u.save(false)
1: пасиба, а не в курсе как избежать before/after коллбеков?
2: вроде как то отключать можно
1: @user_profile.send(:update_without_callbacks)