Pytanie jest proste, jak skonstruować zadanie aby wykonywało się co rok 31 grudnia o 23:59
jest dużo przykładów odnośnie np: co minute co godzinę jednak nie mogę tego rozpracować jak powinno działać z taką datą
https://github.com/jmettraux/rufus-scheduler/
Szczególnie sekcja "‘every’ jobs and :first_at / :first_in
Kocham odpowiedzi na temat na tym forum 
Czacha, interesuje Cię wygenerowanie takiego wpisu crona:
59 23 31 12 * komenda
Musisz pogrzebać w źródle whenever czy pozwala na tak dokładną (wręcz ręczną) definicję czasu.
dzięki, no tak tylko trochę mi sie nie chce w tym grzebać a w https://github.com/jmettraux/rufus-scheduler/ można by napisac jest jest to - cytując temat “Dead simple task scheduling in Rails”
Pozdrawiam i pozostawiam dla szukających podobnych rozwiązań
http://intridea.com/2009/2/13/dead-simple-task-scheduling-in-rails
Jestem wielkim fanem Johna Mettreaux’a i jego rozwiązań (robiłem o tym spicza na Euruko 2008, kiedy rufus-scheduler był jeszcze openwferu-scheduler ), ale cron ma jedną wielką przewagę nad innymi schedulerami: już jest w systemie i chodzi zawsze, nie wymaga utrzymywania. Tymczasem rufus-scheduler musi być elementem wciąż chodzącego procesu Ruby.
Rufus-scheduler jest świetny kiedy dołączony do już pracującego procesu (jakiś worker który ma załadowaną całą aplikację itd.). Twoje potrzeby (zadanie wykonywane raz w roku) za to doskonale rozwiązuje cron właśnie.
Tzn. w dłuższej perspektywie (zwłaszcza pod kątem pewności rozwiązania) bardziej się opłaca jednak to zrobić przez cron/whenever
Kocham odpowiedzi na temat na tym forum :)[/quote]
Chyba coś nie rozumiem, co jest złego w:
scheduler.every '1y', :first_at => '2010/12/31 23:59' do
# do something
end
EDIT: ok, nie zwróciłem uwagi na tytuł posta 
sebcioz: to że rufus tak na prawde nie używa cron’a
tomash ale jak ktos nie ma dostepu do crona w systemie ze względu na paralityczną firmę hostingową, jest to najlepsze rozwiązanie.
cron jest extra jednak na moje oko javan / whenever jest extra fajny pomysł, ale wykonanie *jowe może w kolejnych wersjach będzie lepiej :P:)
i nie ukrywam że z miłą chęcią przesiadłem się na rufus-scheduler’a do moich potrzeb jest extra (mimo tego że mam pare zadań które muszą się wykonać tylko raz w roku i generalnie najlepszym rozwiązaniem było by tylko przeklikanie tego do cron’a)
chociaż może o to chodzi … może whenerver czeka na mnie 
żebym go zforkował to był by mój pierwszy fork ( chyba się napaliłem hahahaha )
… to powinien uciekać z niej jak najszybciej. Co to za hosting że nie można sobie nawet ustawić codziennych backupów? Ugh!
hamerykański
W tym konkretnym przypadku (trywialna sprawa, 1/rok) również wybrałbym crona.
Natomiast ogólnie należy unikać forkowania zadań railsowych przez crona. Głównie dlatego, że nie mamy kontroli nad tym, ile ciężkich procesów chodzi w danej chwili w systemie.
System staje się więc mniej przewidywalny. Potem w najmniej odpowiednim momencie - gdy pijany architekt zaczyna się dobierać do świeżo omotanej koleżanki - dostaje telefon, żeby ratować aplikację. Udusiła się, bo wystartowało jednocześnie kilka zadań i każde sobie wczytało środowisko railsowe. A monit wziął akurat wolne
Dlatego docelowo i tak powinien być dedykowany worker, obecny stale w tej samej liczbie procesów.
qertoip widzę parę niescisłości w twojej wypowiedzi
forkować tak ale mówiłem o javan / whenever a nie o rufus-scheduler poza tym jedyne co może architekt stracić to trochę czasu na uzupełnienie powietrza nie do nowo omotanej ale nowo kupionej koleżanki
pozdro @ll
Źle zrozumiałeś słowo “forkować”. Co prawda Qertoip użył go niewłaściwie, bo forkuje to się podprocesy (pełnoprawne procesy się po prostu uruchamia, jak ktoś koniecznie chce z angielska to może je spawnować), ale w każdym razie nie chodziło o forkowanie repozytorium.
Zgadza się.
a, no i wszystko jasne jak słońce