All streams
Search
Write a publication
Pull to refresh
57
0
Данил Письменный @dapi

Инженер-программист

Send message
Как пример. 1. Можно не привязывать и показыватьтолько флешки. 2. Можно привызывать к любой другой модели и как-бы посылать ей сообщения.
Хорошие слайдики, спасибо.
Если это вы о моем синтаксисе, то пинок принят — на русском пишу хуже чем на компьютерном )
Почему-то не доступен сайт, а там неплохие статейки, надеюсь еще поднимется.
Почти. Пошел искать книгу на скачку.
А вы спрашивайте если что-то интересно, в личку или в комментах. А я буду в статьях объяснять.
Оп-па! Был дезинформирован, беру свои слова обратно.

Сейчас проверил в Ruby 1.8.6 метода Symbol#to_proc нет.
Насчет syntax sugar и скорости выполнения.

DSL и удобство чтения кода, а также приоритет быстроты написания кода перед его выполнением одни из основных принципов Ruby. Лично мне поэтому и нравится писать на Ruby.

Конечно ваше право их отвергать.
Symbol#to_proc появился в Ruby почти десять лет назад в версии1.1.

Амперсанд для последнего аргумента еще раньше.

Хорошая ссылка, надо накидать таких «по теме» в статью.
Я надеюсь вы это про последний пример )
А уж ко всяких очередникам типа reqsue, delayed_job, workling и тп. эта софтина не имеет ВООБЩЕ никакого отношения и не в коем случае не претендует на их замену.

Вы что-то путатете фоновое периодическое выполнение задач с выполнением заданий по запросу.
loop_dance и resquire это совершенно разные вещи у них различные цели и методы их достижения.

Насчет контроля вы вообще не правы — с контролем и параллельным запуском как раз таки все в порядке, каждого демона можно контролировать отдельно и через rake task и из приложения.

Главное достоинство loop_dance в том, что вы получаете подконтрольного автоматически запускаемого демона за 5 строк кода. Сделали и забыли. Не нужно лазить на сервак, редактировать крон, прописывать пути и т.п. и т.д.
Думаю не стоит — другая задача, придется самому очередь сообщений организовывать.
О, кстати, насчет resque.

Правильно понимаю что для того чтобы с ним выполнять какие-то типовые задачи периодически, например каждые 5 минут, нужно запустить redis-сервер, reqsue-сервер и еще какую-то нибудь хрень (хотя бы по крону) которая будет эти задачи периодически пихать в очередь?
Кстати в этом большой плюс — гарантия что через некоторое время память на забьется тормознувшими тасками, что бывает при частом запуске по крону.

А если нужно параллельное выполнение, то задачу можно кинуть во второго танцора, который будет выполняться параллельно:

 class Dancer2 < LoopDance::Dancer

   every 6.hours do
      # делать что-то очень важное параллельно первому танцору
   end

 end


вторым танцором можно также управлять отдельно
cron это очень хороший вариант для редких задач. Есть два недостатка:

1) по крону не будешь запускать частые задачи, такие, например, как ежеминутный опрос твиттера, иначе большая часть ресурсов процессора будет уходить на запуск задач, а не на их выполнение;
2) если кроновские задачи вдруг начали подвисать (сеть подводит или просто стали сложнее и длительнее) и время их выполнение превышает частоту запуска. Например задача запускается каждые 10 минут, а длительность выполнения начала превышать 11 минут, то через некоторое время вы получите память забитую зависшими тасками со всеми вытекающими последствиями.

Есть два способа выполнения периодических задач — по крону и демоном. У каждого способа есть свои достоинства и недостатки.
Я думаю на облаке будет вести себя также как и на одиноком сервере — висеть в памяти, но потреблять процессор только вовремя выполнения задач.
Верно. Если один так зависнет — остальные не выполнятся.
Перенес, а их оказывается два…

Information

Rating
Does not participate
Location
Чебоксары, Чувашия, Россия
Date of birth
Registered
Activity