On Monday, October 10, 2011 at 11:37 PM, Brandon Keepers wrote:
>  Hello Qu Comrades (all 3 of you),  

> I've started working on an implementation of hooks and thought I would get some feedback before going any further.

> https://github.com/bkeepers/qu/compare/master…hooks (https://github.com/bkeepers/qu/compare/master...hooks)

> To summarize the major changes: Jobs must now extend Qu::Job. This is something I debated about a lot in the initial implementation of Qu. I initially implemented it as a subclass of Qu::Job, but then decided follow Resque and make jobs simply a class with a perform class method for simplicity's sake. I have since changed my mind and think there's a lot of power in using richer objects for jobs.

> The Qu:Job class currently implements 4 hooks (perform, complete, release, failure). Others will be coming soon, but I still need to figure out some implementation details.  A hook is a method that is called before, after, or around one of the events.  Calling `halt` in a before hook will prevent the original action from occurring (example: `halt` in a before_failure hook will prevent the job from being marked as failed) and will stop all other hooks.

> Here are some examples of what a job using hooks will look like:

> class MyJob < Qu::Job
>   attr_reader :thing

>   around_perform :timeout  
>   before_perform :notify_before_perform
>   after_perform :notify_before_perform

>   before_failure :ignore_annoying_errors

>   def initialize(thing_id)
>     @thing = Thing.find(thing_id)
>   end

>   def perform
>     # …
>   end

> private

>   def notify_before_perform
>     notifier.announce "Performing job #{id}"
>   end

>   def notify_after_perform
>     notifier.announce "Done performing job #{id}"
>   end

>   def ignore_annoying_errors(e)
>     halt if e < ErrorIDoNotCareAbout
>   end

>   def timeout
>     Timeout.timeout(60) do
>       yield
>     end
>   end
> end

> So, what do you think so far? Anything you would do differently?

> Thanks,
> Brandon

On Tuesday, October 11, 2011 at 10:10 AM, Jonathan Hoyt wrote:
>  Looks good to me. How do you handle completely changing the API on a library and letting folks know that you did so? Just update the readme, or do you try and reach out to those you know are using it?  

> On Monday, October 10, 2011 at 11:37 PM, Brandon Keepers wrote:

> >  Hello Qu Comrades (all 3 of you),  

> > I've started working on an implementation of hooks and thought I would get some feedback before going any further.

> > https://github.com/bkeepers/qu/compare/master…hooks (https://github.com/bkeepers/qu/compare/master...hooks)

> > To summarize the major changes: Jobs must now extend Qu::Job. This is something I debated about a lot in the initial implementation of Qu. I initially implemented it as a subclass of Qu::Job, but then decided follow Resque and make jobs simply a class with a perform class method for simplicity's sake. I have since changed my mind and think there's a lot of power in using richer objects for jobs.

> > The Qu:Job class currently implements 4 hooks (perform, complete, release, failure). Others will be coming soon, but I still need to figure out some implementation details.  A hook is a method that is called before, after, or around one of the events.  Calling `halt` in a before hook will prevent the original action from occurring (example: `halt` in a before_failure hook will prevent the job from being marked as failed) and will stop all other hooks.

> > Here are some examples of what a job using hooks will look like:

> > class MyJob < Qu::Job
> >   attr_reader :thing

> >   around_perform :timeout  
> >   before_perform :notify_before_perform
> >   after_perform :notify_before_perform

> >   before_failure :ignore_annoying_errors

> >   def initialize(thing_id)
> >     @thing = Thing.find(thing_id)
> >   end

> >   def perform
> >     # …
> >   end

> > private

> >   def notify_before_perform
> >     notifier.announce "Performing job #{id}"
> >   end

> >   def notify_after_perform
> >     notifier.announce "Done performing job #{id}"
> >   end

> >   def ignore_annoying_errors(e)
> >     halt if e < ErrorIDoNotCareAbout
> >   end

> >   def timeout
> >     Timeout.timeout(60) do
> >       yield
> >     end
> >   end
> > end

> > So, what do you think so far? Anything you would do differently?

> > Thanks,
> > Brandon