Results for symbols-models

Proc-macro utility to populate enums from database data (shared traits)

A model attribute enums plugin for Rails3. like 'symbolize' gem.

Adds model Features::Para (paragraph) to site, which are usually enumerated as text blocks one by one in a single row (e.g.: testimonials, features, trust symbols etc.).

Symbolic-to-linguistic grounding layer for brain-modeled agentic AI

This code allows you to keep the display labels in the model when the DB holds only a 1 character flag. and when the code requires symbolic references to the value to use in algorithms This gem is superceded by the gem state_objects Please migrate to: https://rubygems.org/gems/state_objects Limitations: Don't use this if you will run reports directly against the DB In that case, the reports will not have access to the display labels

Small, fast and flexible state machines using composition.

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.')

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.')

Crowdfund is a Ruby program developed based on Pragmatic Studio's Ruby Programming hands-on video course, and distributed as a Ruby gem. This program has been developed using all the strengths of Ruby including the following. Ruby Programming Environment * Installing Ruby on your favorite operating system (free exercise) * Running Ruby using the interactive Ruby shell (irb) and writing Ruby program files * Using Ruby's documentation system to get help * Installing external Ruby libraries using RubyGems * Troubleshooting common problems Ruby Language Constructs * Expressions and variables * Numbers, string, and symbols (free video & exercise) * Loops and conditional expressions * Arrays and hashes (free video & exercise on hashes) * Classes, modules, and structs Object-Oriented Programming * Using built-in Ruby classes * Defining your own classes with state and behavior (free video & exercise) * Creating unique objects * Telling objects what to do by calling methods * Modeling class-level inheritance relationships * Sharing code with mixins Object-Oriented Design Principles * Encapsulation * Separation of concerns * Polymorphism * Don't Repeat Yourself * Tell, Don't Ask Blocks and Iterators * Calling built-in methods that take blocks * Writing your own methods that yield to blocks * Implementing custom iterators * Effectively using blocks in your programs Organizing Ruby Code * Creating a Ruby project structure * Separating source files for easier reuse and testing * Namespacing to avoid naming clashes * Input/Output * Reading data from files * Writing data to files * Creating an interactive console prompt * Handling command-line input Unit Testing * Writing and running unit tests with RSpec * Test-driven development and the red-green-refactor cycle * Stubbing methods to control tests * Refactoring code, safely! Distribution * Conforming to RubyGems conventions * Writing a GemSpec * Building a RubyGem * Publishing a RubyGem to a public server Ruby Programming Idioms

Studio Game is a Ruby program developed based on Pragmatic Studio' Ruby Programming hands-on video course, and distributed as a Ruby gem. This program has been developed using all the strengths of Ruby including the following. Ruby Programming Environment * Installing Ruby on your favorite operating system (free exercise) * Running Ruby using the interactive Ruby shell (irb) and writing Ruby program files * Using Ruby's documentation system to get help * Installing external Ruby libraries using RubyGems * Troubleshooting common problems Ruby Language Constructs * Expressions and variables * Numbers, string, and symbols (free video & exercise) * Loops and conditional expressions * Arrays and hashes (free video & exercise on hashes) * Classes, modules, and structs Object-Oriented Programming * Using built-in Ruby classes * Defining your own classes with state and behavior (free video & exercise) * Creating unique objects * Telling objects what to do by calling methods * Modeling class-level inheritance relationships * Sharing code with mixins Object-Oriented Design Principles * Encapsulation * Separation of concerns * Polymorphism * Don't Repeat Yourself * Tell, Don't Ask Blocks and Iterators * Calling built-in methods that take blocks * Writing your own methods that yield to blocks * Implementing custom iterators * Effectively using blocks in your programs Organizing Ruby Code * Creating a Ruby project structure * Separating source files for easier reuse and testing * Namespacing to avoid naming clashes * Input/Output * Reading data from files * Writing data to files * Creating an interactive console prompt * Handling command-line input Unit Testing * Writing and running unit tests with RSpec * Test-driven development and the red-green-refactor cycle * Stubbing methods to control tests * Refactoring code, safely! Distribution * Conforming to RubyGems conventions * Writing a GemSpec * Building a RubyGem * Publishing a RubyGem to a public server Ruby Programming Idioms

{<img src="https://secure.travis-ci.org/socialcast/socialcast-shoulda-ext.png?branch=master" alt="Build Status" />}[http://travis-ci.org/socialcast/socialcast-shoulda-ext] = Socialcast Shoulda Extensions Adds new matchers and functionality to the shoulda test library = Installation In your Gemfile: group :test do gem 'socialcast_shoulda_ext', :git => 'git@github.com:socialcast/socialcast-shoulda-ext.git', :require => 'shoulda_ext' end If you want to include the trigger_callbacks matcher, also add the following to your test helper: ShouldaExt::Matchers::TriggerCallbackMatcher.attach_active_record_callback_hooks! = Matchers == RecordCountChangeMatcher Test if the count for a model has changed, and by how much. Requires the context_with_matcher_before_hooks patch, which is included by default. Provides the following matcher methods: - create_record(klass_or_symbol) Alias for change_record_count.for(klass_or_symbol).by(1) - create_records(klass_or_symbol, amount) Alias for change_record_count.for(klass_or_symbol).by(amount) - destroy_record(klass_or_symbol) Alias for change_record_count.for(klass_or_symbol).by(-1) - destroy_records(klass_or_symbol, amount) Alias for change_record_count.for(klass_or_symbol).by(-amount) - change_record_count Tests the difference in record count before and after the current setup/subject block Can be used with the follow methods: - for(klass_or_symbol) Provides the class which the test is being performed on. Can be a constant or a symbol - by(amount) Provides an expected difference for the number of records for the specified class. Excluding this number will allow the matcher to check for any difference Examples: context "creating a blog article" do context "with good parameters" do setup do post :create, :blog => {:title => 'my blog post', :body => 'Ipsum lorem...'} end should create_record :blog end context "without a body" do setup do post :create, :blog => {:title => 'my blog post' } end should_not create_record Blog end end == RespondWithJson Check if the controller's response is json Examples: context ":index.json" do setup do get :index, :format => 'json' end # Just check to see that the response was json should respond_with_json # Evaluate the hash produced by the json yourself should respond_with_json { |json| json.first['blog']['title'] == 'blog post 1'} # Provide an exact match should respond_with_json.exactly(['blog' => {'id' => 1, 'title' => 'blog post 1'}]) # Provide an exact match with a block should response_with_json.exactly{ |json| JSON.parse(Blog.all.to_json)} end context ":index.html" do setup do get :index end # or the negation should_not respond_with_json end == TriggerCallbackMatcher Test if create, update, destroy, or save callbacks were triggered. Requires running ShouldaExt::Matchers::TriggerCallbackMatcher.attach_active_record_callback_hooks! in your test suite in order to work properly. Examples: context "doing nothing to a record" do subject { Blog.new :title => 'blog title' } should_not trigger_callbacks end context "creating a record" do subject { Blog.create! :title => 'blog title' } should trigger_callbacks.for :create should_not trigger_callbacks.for :update, :destroy end = Integrations Currently only integrates with test/unit. RSpec support to come. = Shoulda Extensions == ContextWithMatcherBeforeHooks Adds the ability to define a 'before' method on any method which will be run before each context's setup/subject block. Used by RecordCountChangeMatcher to record the number of records before the tested operation takes place.

No description provided.