Results for watch-notify

Watch and Notify your not tested routes of a RoR Application, it also has a simple report about Routes defines, used and tested

Watch "favorare" status and notify if "favorare" added.

Command line utility that continuously watches for the buildkite job running current git HEAD and notifies on build status changes.

Watch directories using platform specific notifier.

tengine_job_agent works with tengine_job

Watches local gems and notifies the user if they are outdated.

Watches a specified iCal-format calendar for events. When the time for an event comes, sends the name of the event to a servant that supports the "commandable" role (http://belphanior.net/roles/commandable/v1). For example, say you have an iCal at www.foo.com/calendar that has an entry named "wake me up" at 10AM today. If you have a servant at 127.0.0.1:3000 that supports "commandable" and understands the "wake me up" command, you could run the calendar_watcher_servant with a servant_config file that looks as follows: { "ip":"127.0.0.1", "port":"4000", "calendar url":"http://www.foo.com/calendar" "servant url":"http://127.0.0.1:3000" "update seconds":"60" } With this configuration, the calendar watcher servant will check the calendar every 60 seconds for new events. When it checks after 10AM, it will discover the "wake me up" event and send it to the servant at 127.0.0.1:3000.

git-notifier is a gem for Mac Os that allows you to watch one or more git repositories and receive a growl notification when a change is committed

Hotcorg watches cpu temperture. You can direct thretholds. If cpu temperture gets over them, Hotdog notifies to you. (for macOS only)

The Bullet plugin is designed to help you increase your application's performance by reducing the number of queries it makes. It will watch your queries while you develop your application and notify you when you should add eager loading (N+1 queries) or when you're using eager loading that isn't necessary.

The Bullet plugin is designed to help you increase your application's performance by reducing the number of queries it makes. It will watch your queries while you develop your application and notify you when you should add eager loading (N+1 queries) or when you're using eager loading that isn't necessary.

ALPHA Alert -- just uploaded initial release. Linux inotify is a means to receive events describing file system activity (create, modify, delete, close, etc). Sinotify was derived from aredridel's package (http://raa.ruby-lang.org/project/ruby-inotify/), with the addition of Paul Boon's tweak for making the event_check thread more polite (see http://www.mindbucket.com/2009/02/24/ruby-daemons-verifying-good-behavior/) In sinotify, the classes Sinotify::PrimNotifier and Sinotify::PrimEvent provide a low level wrapper to inotify, with the ability to establish 'watches' and then listen for inotify events using one of inotify's synchronous event loops, and providing access to the events' masks (see 'man inotify' for details). Sinotify::PrimEvent class adds a little semantic sugar to the event in to the form of 'etypes', which are just ruby symbols that describe the event mask. If the event has a raw mask of (DELETE_SELF & IS_DIR), then the etypes array would be [:delete_self, :is_dir]. In addition to the 'straight' wrapper in inotify, sinotify provides an asynchronous implementation of the 'observer pattern' for notification. In other words, Sinotify::Notifier listens in the background for inotify events, adapting them into instances of Sinotify::Event as they come in and immediately placing them in a concurrent queue, from which they are 'announced' to 'subscribers' of the event. [Sinotify uses the 'cosell' implementation of the Announcements event notification framework, hence the terminology 'subscribe' and 'announce' rather then 'listen' and 'trigger' used in the standard event observer pattern. See the 'cosell' package on github for details.] A variety of 'knobs' are provided for controlling the behavior of the notifier: whether a watch should apply to a single directory or should recurse into subdirectores, how fast it should broadcast queued events, etc (see Sinotify::Notifier, and the example in the synopsis section below). An event 'spy' can also be setup to log all Sinotify::PrimEvents and Sinotify::Events. Sinotify::Event simplifies inotify's muddled event model, sending events only for those files/directories that have changed. That's not to say you can't setup a notifier that recurses into subdirectories, just that any individual event will apply to a single file, and not to its children. Also, event types are identified using words (in the form of ruby :symbols) instead of inotify's event masks. See Sinotify::Event for more explanation. The README for inotify: http://www.kernel.org/pub/linux/kernel/people/rml/inotify/README Selected quotes from the README for inotify: * "Rumor is that the 'd' in 'dnotify' does not stand for 'directory' but for 'suck.'" * "The 'i' in inotify does not stand for 'suck' but for 'inode' -- the logical choice since inotify is inode-based." (The 's' in 'sinotify' does in fact stand for 'suck.')

No description provided.

No description provided.

No description provided.

No description provided.