Results for helper-git-hash

Helpers to read debian control files

{<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.

== README.md: #ScheduledResource This gem is for displaying how things are used over time -- a schedule for a set of "resources". You can configure the elements of the schedule and there are utilities and protocols to connect them: - Configuration (specification and management), - Query interfaces (a REST-like API and internal protocols to query the models), and - A basic Rails controller implementation. We have a way to configure the schedule, internal methods to generate the data, and a way to retrieve data from the client. However this gem is largely view-framework agnostic. We could use a variety of client-side packages or even more traditional Rails view templates to generate HTML. In any case, to get a good feel in a display like this we need some client-side code. The gem includes client-side modules to: - Manage &lt;b&gt;time and display geometries&lt;/b&gt; with "infinite" scroll along the time axis. - &lt;b&gt;Format display cells&lt;/b&gt; in ways specific to the resource models. - &lt;b&gt;Update text justification&lt;/b&gt; as the display is scrolled horizontally. ## Configuration A **scheduled resource** is something that can be used for one thing at a time. So if "Rocky &amp; Bullwinkle" is on channel 3 from 10am to 11am on Saturday, then 'channel 3' is the &lt;u&gt;resource&lt;/u&gt; and that showing of the episode is a &lt;u&gt;resource-use&lt;/u&gt; block. Resources and use-blocks are typically Rails models. Each resource and its use-blocks get one row in the display. That row has a label to the left with some timespan visible on the rest of the row. Something else you would expect see in a schedule would be headers and labels -- perhaps one row with the date and another row with the hour. Headers and labels also fit the model of resources and use-blocks. Basic timezone-aware classes (ZTime*) for those are included in this gem. ### Config File The schedule configuration comes from &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; which has three top-level sections: - ResourceKinds: A hash where the key is a Resource and the value is a UseBlock. (Both are class names), - Resources: A list where each item is a Resource Class followed by one or more resource ids, and - visibleTime: The visible timespan of the schedule in seconds. The example file &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; (installed when you run &lt;tt&gt;schedulize&lt;/tt&gt;) should be enough to display a two-row schedule with just the date above and the hour below. Of course you can monkey-patch or subclass these classes for your own needs. ### The schedule API The 'schedule' endpoint uses parameters &lt;tt&gt;t1&lt;/tt&gt; and &lt;tt&gt;t2&lt;/tt&gt; to specify a time interval for the request. A third parameter &lt;tt&gt;inc&lt;/tt&gt; allows an initial time window to be expanded without repeating blocks that span those boundaries. The time parameters _plus the configured resources_ define the data to be returned. ### More About Configuration Management The &lt;b&gt;ScheduledResource&lt;/b&gt; class manages resource and use-block class names, id's and labels for a schedule according to the configuration file. A ScheduledResource instance ties together: 1. A resource class (eg TvStation), 2. An id (a channel number in this example), and 3. Strings and other assets that will go into the DOM. The id is used to - select a resource _instance_ and - select instances of the _resource use block_ class (eg Program instances). The id _could_ be a database id but more often is something a little more suited to human use in the configuration. In any case it is used by model class method &lt;tt&gt;(resource_use_block_class).get_all_blocks()&lt;/tt&gt; to select the right use-blocks for the resource. A resource class name and id are are joined with a '_' to form a tag that also serves as an id for the DOM. Once the configuration yaml is loaded that data is maintained in the session structure. Of course having a single configuration file limits the application's usefulness. A more general approach would be to have a user model with login and configuration would be associated with the user. ## Installation Add this line to your application's Gemfile: ```ruby gem 'scheduled_resource' ``` And then execute: $ bundle Or install it yourself as: $ gem install scheduled_resource Then from your application's root execute: $ schedulize . This will install a few image placeholders, client-side modules and a stylesheet under &lt;tt&gt;vendor/assets&lt;/tt&gt;, an example configuration in &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; and an example controller in &lt;tt&gt;app/controllers/schedule_controller.rb&lt;/tt&gt;. Also, if you use $ bundle show scheduled_resource to locate the installed source you can browse example classes &lt;tt&gt;lib/z_time_*.rb&lt;/tt&gt; and the controller helper methods in &lt;tt&gt;lib/scheduled_resource/helper.rb&lt;/tt&gt; ## Testing This gem also provides for a basic test application using angularjs to display a minimal but functional schedule showing just the day and hour headers in two different timezones (US Pacific and Eastern). Proceed as follows, starting with a fresh Rails app: $ rails new test_sr As above, add the gem to the Gemfile, then $ cd test_sr $ bundle $ schedulize . Add lines such as these to &lt;tt&gt;config/routes.rb&lt;/tt&gt; get "/schedule/index" =&gt; "schedule#index" get "/schedule" =&gt; "schedule#schedule" Copy / merge these files from the gem source into the test app: $SR_SRC/app/views/layouts/application.html.erb $SR_SRC/app/views/schedule/index.html.erb $SR_SRC/app/assets/javascripts/{angular.js,script.js,controllers.js} and add &lt;tt&gt;//= require angular&lt;/tt&gt; to application.js just below the entries for &lt;tt&gt;jquery&lt;/tt&gt;. After you run the server and browse to http://0.0.0.0:3000/schedule/index you should see the four time-header rows specified by the sample config file. ## More Examples A better place to see the use of this gem is at [tv4](https://github.com/emeyekayee/tv4). Specifically, models &lt;tt&gt;app/models/event.rb&lt;/tt&gt; and &lt;tt&gt;app/models/station.rb&lt;/tt&gt; give better examples of implementing the ScheduledResource protocol and adapting to a db schema organized along somewhat different lines. ## Contributing 1. Fork it ( https://github.com/emeyekayee/scheduled_resource/fork ) 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create a new Pull Request

No description provided.