Logika działająca wyłacznie na PRAWDZIWEJ produkcji

Mam sobie model:

[code=ruby]class Post < ActiveRecord::Base
after_create :send_notification

private
def send_notification
Thread.new do
Net::HTTP.get(URI.parse(“http://some.host.com/notify?id=#{self.id}&title=#{self.title}”))
end
end
end[/code]
O ile na produkcji zachowuje się jak powinno, to zapewne domyślacie się, jakie konsekwencje niesie za sobą uruchamianie testów, a także praca na serwerze beta/staging (na którym RAILS_ENV = production) - śmieciowe dane.

Normalnie do rozdzielenia konfiguracji używam własnego pliku *.yml, który jest definiowany “na środowisko” i przypisany do konkretnego komputera, jak database.yml. Tutaj by w grę wchodziło jednak przechowywanie jakichś proców w yml… co wydaje mi się herezją.

Dla takiej błahostki nie wyobrażam sobie tworzenie dodatkowego envirnoment, tylko po to, by na serwerze beta nie generować fałszywych requestów.

Pomysłem byłoby utworzenie pliku config/hooks.rb, który byłby definiowany na konkretne komputery, jak config/database.yml:

[code=ruby]#config/hooks.rb
define_hook :send_notification_after_post_create, [:production, :development] do |id, title|
Thread.new do
Net::HTTP.get(URI.parse(“http://some.host.com/notify?id=#{id}&title=#{title}”))
end
end
define_hook :send_notification_after_post_create, [:test] do { |id, title| nil }

w kodzie

hook(:send_notification_after_post_create).call(self.id, self.title)[/code]
Ale wygląda paskudnie, nie wiadomo o co chodzi i wymaga dopisania czegoś w lib/* albo config/initializers/* do obsługi takiego DSLa

Czy ktoś ma jakiś pomysł jak to ładnie poprawić?

a nie wystarczy tak?

Net::HTTP.get(URI.parse(“http://some.host.com/notify?id=#{self.id}&title=#{self.title}”)) unless RAILS_ENV == ‘test’

No tak, a co z serwerem beta, który pracuje w środowisku produkcyjnym również? Mam jeden serwer produkcyjny dla klientów mojego klienta i drugi, pokazowy, z którego te requesty nie powinny wychodzić (tak jak na przykład nie uruchamia się cron wysyłający maile i takie tam)

no to moze hostname albo cos w tym stylu

a = hostname

… unless a == ‘beta’

Ojoj, tworzenie kodu zależnego od środowiska to zazwyczaj zły pomysł. W testach zawsze możesz sobie napisać jakiegoś mocka dla web service.

A jeśli chodzi o różne urle to użyj czegoś w stylu app_config

Problem nie w tym, że mam różne URLe (w dodatku URL jest budowany na podstawie pewnych danych), tylko w tym, ze tylko na prawdziwej produkcji ma być wykonany request.

Edit: mógłbym przekirowywać na jakiś fakeurl, który się wysypie po prostu…
Pozostaje wymyśleć ładny builder dla urli.

Jak dla mnie utworzenie dodatkowego środowiska dla bety to dobry pomysł - u mnie się sprawdza. W takim środowisku można wyłączać reklamy, zwiększać poziom logowania, ustawiać odpowiednią domenę itd. itp.

Narzut praktycznie żaden.

Ja też z reguły mam oddzielne środowisko, najczęściej nazwane staging.

W tym wypadku - skoro to ma działać tylko na produkcyjnym serwerze, to czemu nie zrobić w pliku yml:

  some_notifications_enabled: false

Nie musisz się wtedy bawić we wrzucanie złożonej konfiguracji dla serwera produkcyjnego tylko wyłączasz to dla wszystkich innych serwerów.

Dzięki, drogus! Jak zwykle, najciemniej pod latarnią.