Results for get-git-changed-files

Get git changed files by commit id or date time

No description provided.

A lightweight cache for file metadata, ideal for processes that work on a specific set of files and only need to reprocess files that have changed since the last run

Tells you whether or not dependencies in package.json have been changed.

Run commands and scripts after git pull

No description provided.

Detect file name case changes in a Git repository

Utility for dealing with modified, created, deleted files since a git commit

Get the change between any of your branch and current branch of a `git` repository

Delightful JavaScript Testing.

Delightful JavaScript Testing.

Parse a JSON string that has git merge conflicts, resolving if possible

Run a command if a file changes via Git hooks

Run ESLint on your changes only

Lint files staged by git

List files changed since a git revision

Only pass through changed files

get a list of staged git files and their status

A simple key/value storage using files to persist the data

VSCode oniguruma bindings

Programmatic access to the ARIA specification

Git resource definitions for Fluid services

Tiny LiveReload server, background-friendly

A little library for asserting types and values, with zero dependencies.

Some call it the unlimited undo. It tracks every single file change in a git repository. Hangover runs in the background. The file changes get committed to the next parent hangover repository. You can restore any state of your files from the moment on you started hangover.

Deliver all master files managed in a single master snapshot directory into the specified directory while maintaining the hierarchy of the master snapshot directory. If the destination file already exists, back it up first and then deliver the master file. The difference with rsync is that master_delivery creates a symlinks instead of copying the master files. They are symlinks, so you have to keep in mind that you have to keep the master files in the same location, but it also has the advantage that the master file is updated at the same time when you directly make changes to the delivered file. Do you have any experience that the master file is getting old gradually? master_delivery can prevent this. If the master directory is git or svn managed, you can manage revisions of files that are delivered here and there at once with commands like git diff and git commit.

# Rack::ReadOnly This gem allows Rack based APIs to be set to read only. At the most basic it can be used like this from your `config.ru`: ```ruby require 'rack/read_only' use Rack::ReadOnly, { active: ENV["READ_ONLY"] == "1", response_body: '{ "error": "This API is currently in read only mode." }' } run MyApp ``` When in read only mode the API will continue to respond to GET, HEAD, and OPTIONS requests as normal, but reject POST, PUT, DELETE, and PATCH requests with the body specified, and a 503 error code. ## Installation Add this line to your application's Gemfile: ```ruby gem 'rack-read_only' ``` And then execute: $ bundle Or install it yourself as: $ gem install rack-read_only ## Development After checking out the repo, run `bin/setup` to install dependencies. To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release` to create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org). ## Contributing 1. Fork it ( https://github.com/jellybob/rack-read_only/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 Any new builds should pass the tests on [Travis](https://travis-ci.org/jellybob/rack-read_only)

Diff and patch tables

# Fresh::Auth This gem makes it really, REALLY easy to use the Freshbooks API. It couldn't be easier. With only 3 functions you'll ever need to use, and only 2 required configuration values, it can't get any easier. ## Installation Add this line to your application's Gemfile: gem 'fresh-auth' And then execute: $ bundle Or install it yourself as: $ gem install fresh-auth ## Usage ### Configuration: You must define your Freshbooks subdomain and your OAuth Secret in your application code before using Fresh::Auth. For Ruby on Rails apps, a new file at config/initializers/fresh-auth.rb would be appropriate. Your configuration file should look like this (you fill in the three empty strings): Fresh::Auth.configure do |config| # The part of your login url between 'http://' and '.freshbooks.com' config.url.subdomain = "" # Under 'My Account' (on the top right when you're logged into Freshbooks) # -> 'Freshbooks API' -> 'OAuth Developer Access' -> 'OAuth Secret' # You'll need to request this from Freshbooks initially. config.oauth_secret = "" # Optional. Any string of your choice. Be creative or check out http://www.thebitmill.com/tools/password.html config.nonce_salt = "" end Fear not: If you try to use Fresh::Auth without configuring it first, an exception will be thrown that clearly describes the problem. ### Public API: There are two modules in this API: Fresh::Auth::Authentication and Fresh::Auth::Api #### Fresh::Auth::Authentication This module authenticates you with Freshbooks, storing the authentication in an array called `session`. This integrates seamlessly with Ruby on Rails' controller environment. If you're using some framework other than Ruby on Rails, make sure to define session in your class before including the Authentication module. This isn't recommended because your class will also need to define other objects called `params` and `request` and implement a `redirect_to` method. It gets complicated. Better leave it to Rails to handle this for you. The only public function of this module is AuthenticateWithFreshbooks. To use it, just add the following line of code to your controller: ` include Fresh::Auth::Authentication ` Then, the following line of code authenticates with Freshbooks from any method in your controller: ` AuthenticateWithFreshbooks() ` Note that, after authenticating with Freshbooks, the user will be redirected back to the same path using HTTP GET, so make sure the resource supports HTTP GET and that in the business logic executed on GET, AuthenticateWihFreshbooks() is called. #### Fresh::Auth::Api Once you've authenticated, you want to send XML requests to Freshbooks. The first step is preparing the XML with Fresh::Auth::Api.GenerateXml, which you'll supply with a block that defines all the nested XML that you want in your request. GenerateXml also takes two arguments before the block: the class and method that you want to call. First, in your controller: `include Fresh::Auth::Api` Then, in some method in that controller: my_xml = GenerateXml :invoice, :update do |xml| xml.client_id 20 xml.status 'sent' xml.notes 'Pick up the car by 5' xml.terms 'Cash only' xml.lines { xml.line { xml.name 'catalytic converter' xml.quantity 1 xml.unit_cost 450 xml.type 'Item' } xml.line { xml.name 'labor' xml.quantity 1 xml.unit_cost 60 xml.type 'Time' } } end Ok, you created the XML. Now you want to send it. Sounds pretty complicated, right? Not at all! Ready? Let's go! `_response = PostToFreshbooksApi my_xml` Now, are you wondering what's in `_response`? I'll tell you shortly, but before we discuss that, we have to know about the exception that PostToFreshbooksApi might raise. It raises a detailed error message if the response status is not 'ok'. Makes sense, right? Now, you still want to know what's in `_response`? Oh, nothing fancy. Just a Nokogiri XML object, representing the root element of the xml response. Could this get any easier? ## Contributing 1. Fork it 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Added some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create new Pull Request

Diff and patch tables

# DECC 2050 CALCULATOR TOOL A C version and ruby wrapper for the www.decc.gov.uk 2050 energy and climate change excel calculator Further detail on the project: http://www.decc.gov.uk/2050 Canonical source: http://github.com/decc/decc_2050_model ## DEPENDENCIES 1. ruby 1.9.2 (including development headers) 2. basic c development headers This has ONLY been tested on OSX and on Ubuntu 64 bit EC2 ami. Grateful for reports from other platforms. In the util folder are two example scripts than can be helpful: 1. start-high-memory-instance.sh - is the script we use to setup an aws server to compile the model. You can't use it directly, because you won't have the right keys and certificates, but it can give clues. 2. setup-2050-model-builder-script.sh - is the script we use to get all the dependencies on that aws server correct, download this code, and then compile the model. Again, it may not be quite right for you but can server as inspiration ## INSTALLATION Note that this compiles the underlying c code, which might take 10-20 minutes or so gem install decc_2050_model ## UPDATING TO NEWER VERSIONS OF EXCEL MODEL First of all, you need to be working on the github version of the code, not the rubygem: git clone http://github.com/decc/decc_2050_model Then put the new spreadsheet in spreadsheet/2050Model.xlsx Then, from the top directory of the gem: bundle bundle exec rake The next step is to check whether lib/decc_2050_model/decc_2050_model_result.rb and lib/decc_2050_model/model_structure.rb need to be altered so that they pick up the correct places in the underlying excel. The final stage is to build and install the new gem: gem build decc_2050_model.gemspec gem install decc_2050_model-<version>.gem ... where <version> is the version number of the gem file that was created in the folder. Now follow the instructions in the twenty-fifty server directory in order to ensure that it is using this new version of the gem.

== 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

# Rake::ToolkitProgram Create toolkit programs easily with `Rake` and `OptionParser` syntax. Bash completions and usage help are baked in. ## Installation Add this line to your application's Gemfile: ```ruby gem 'rake-toolkit_program' ``` And then execute: $ bundle Or install it yourself as: $ gem install rake-toolkit_program ## Quickstart * Shebang it up (in a file named `awesome_tool.rb`) ```ruby #!/usr/bin/env ruby ``` * Require the library ```ruby require 'rake/toolkit_program' ``` * Make your life easier ```ruby Program = Rake::ToolkitProgram ``` * Define your command tasks ```ruby Program.command_tasks do desc "Build it" task 'build' do # Ruby code here end desc "Test it" task 'test' => ['build'] do # Rake syntax ↑↑↑↑↑↑↑ for dependencies # Ruby code here end end ``` You can use `Program.args` in your tasks to access the other arguments on the command line. For argument parsing integrated into the help provided by the program, see the use of `Rake::Task(Rake::ToolkitProgram::TaskExt)#parse_args` below. * Wire the mainline ```ruby Program.run(on_error: :exit_program!) if $0 == __FILE__ ``` * In the shell, prepare to run the program (UNIX/Linux systems only) ```console $ chmod +x awesome_tool.rb $ ./awesome_tool.rb --install-completions Completions installed in /home/rtweeks/.bashrc Source /home/rtweeks/.bash-complete/awesome_tool.rb-completions for immediate availability. $ source /home/rtweeks/.bash-complete/awesome_tool.rb-completions ``` * Ask for help ```console $ ./awesome_tool.rb help *** ./awesome_tool.rb Toolkit Program *** . . . ``` ## Usage Let's look at a short sample toolkit program -- put this in `awesome.rb`: ```ruby #!/usr/bin/env ruby require 'rake/toolkit_program' require 'ostruct' ToolkitProgram = Rake::ToolkitProgram ToolkitProgram.title = "My Awesome Toolkit of Awesome" ToolkitProgram.command_tasks do desc <<-END_DESC.dedent Fooing myself I'm not sure what I'm doing, but I'm definitely fooing! END_DESC task :foo do a = ToolkitProgram.args puts "I'm fooed#{' on a ' if a.implement}#{a.implement}" end.parse_args(into: OpenStruct.new) do |parser, args| parser.no_positional_args! parser.on('-i', '--implement IMPLEMENT', 'An implement on which to be fooed') do |val| args.implement = val end end end if __FILE__ == $0 ToolkitProgram.run(on_error: :exit_program!) end ``` Make sure to `chmod +x awesome.rb`! What does this support? $ ./awesome.rb foo I'm fooed $ ./awesome.rb --help *** My Awesome Toolkit of Awesome *** Usage: ./awesome.rb COMMAND [OPTION ...] Avaliable options vary depending on the command given. For details of a particular command, use: ./awesome.rb help COMMAND Commands: foo Fooing myself help Show a list of commands or details of one command Use help COMMAND to get more help on a specific command. $ ./awesome.rb help foo *** My Awesome Toolkit of Awesome *** Usage: ./awesome.rb foo [OPTION ...] Fooing myself I'm not sure what I'm doing, but I'm definitely fooing! Options: -i, --implement IMPLEMENT An implement on which to be fooed $ ./awesome.rb --install-completions Completions installed in /home/rtweeks/.bashrc Source /home/rtweeks/.bash-complete/awesome.rb-completions for immediate availability. $ source /home/rtweeks/.bash-complete/awesome.rb-completions $ ./awesome.rb <tab><tab> foo help $ ./awesome.rb f<tab> ↳ ./awesome.rb foo $ ./awesome.rb foo <tab> ↳ ./awesome.rb foo -- $ ./awesome.rb foo --<tab><tab> --help --implement $ ./awesome.rb foo --i<tab> ↳ ./awesome.rb foo --implement $ ./awesome.rb foo --implement <tab><tab> --help awesome.rb $ ./awesome.rb foo --implement spoon I'm fooed on a spoon ### Defining Toolkit Commands Just define tasks in the block of `Rake::ToolkitProgram.command_tasks` with `task` (i.e. `Rake::DSL#task`). If `desc` is used to provide a description, the task will become visible in help and completions. When a command task is initially defined, positional arguments to the command are available as an `Array` through `Rake::ToolkitProgram.args`. ### Option Parsing This gem extends `Rake::Task` with a `#parse_args` method that creates a `Rake::ToolkitProgram::CommandOptionParser` (derived from the standard library's `OptionParser`) and an argument accumulator and `yield`s them to its block. * The arguments accumulated through the `Rake::ToolkitProgram::CommandOptionParser` are available to the task in `Rake::ToolkitProgram.args`, replacing the normal `Array` of positional arguments. * Use the `into:` keyword of `#parse_args` to provide a custom argument accumulator object for the associated command. The default argument accumulator constructor can be defined with `Rake::ToolkitProgram.default_parsed_args`. Without either of these, the default accumulator is a `Hash`. * Options defined using `OptionParser#on` (or any of the variants) will print in the help for the associated command. ### Positional Arguments Accessing positional arguments given after the command name depends on whether or not `Rake::Task(Rake::ToolkitProgram::TaskExt)#parse_args` has been called on the command task. If this method is not called, positional arguments will be an `Array` accessible through `Rake::ToolkitProgram.args`. When `Rake::Task(Rake::ToolkitProgram::TaskExt)#parse_args` is used: * `Rake::ToolkitProgram::CommandOptionParser#capture_positionals` can be used to define how positional arguments are accumulated. * If the argument accumulator is a `Hash`, the default (without calling this method) is to assign the `Array` of positional arguments to the `nil` key of the `Hash`. * For other types of accumulators, the positional arguments are only accessible if `Rake::ToolkitProgram::CommandOptionParser#capture_positionals` is used to define how they are captured. * If a block is given to this method, the block of the method will receive the `Array` of positional arguments. If it is passed an argument value, that value is used as the key under which to store the positional arguments if the argument accumulator is a `Hash`. * `Rake::ToolkitProgram::CommandOptionParser#expect_positional_cardinality` can be used to set a rule for the count of positional arguments. This will affect the _usage_ presented in the help for the associated command. * `Rake::ToolkitProgram::CommandOptionParser#map_positional_args` may be used to transform (or otherwise process) positional arguments one at a time and in the context of options and/or arguments appearing earlier on the command line. ### Convenience Methods * `Rake::Task(Rake::ToolkitProgram::TaskExt)#prohibit_args` is a quick way, for commands that accept no options or positional arguments, to declare this so the help and bash completions reflect this. It is equivalent to using `#parse_args` and telling the parser `parser.expect_positional_cardinality(0)`. * `Rake::ToolkitProgram::CommandOptionParser#no_positional_args!` is a shortcut for calling `#expect_positional_cardinality(0)` on the same object. * `Rake::Task(Rake::ToolkitProgram::TaskExt)#invalid_args!` and `Rake::ToolkitProgram::CommandOptionParser#invalid_args!` are convenient ways to raise `Rake::ToolkitProgram::InvalidCommandLine` with a message. ## OptionParser in Rubies Before and After v2.4 The `OptionParser` class was extended in Ruby 2.4 to simplify capturing options into a `Hash` or other container implementing `#[]=` in a similar way. This gem supports that, but it means that behavior varies somewhat between the pre-2.4 era and the 2.4+ era. To have consistent behavior across that version change, the recommendation is to use a `Struct`, `OpenStruct`, or custom class to hold program options rather than `Hash`. ## Development After checking out the repo, run `bin/setup` to install dependencies. You can also run `bin/console` for an interactive prompt that will allow you to experiment. To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org). To run the tests, use `rake`, `rake test`, or `rspec spec`. Tests can only be run on systems that support `Kernel#fork`, as this is used to present a pristine and isolated environment for setting up the tool. If run using Ruby 2.3 or earlier, some tests will be pending because functionality expects Ruby 2.4's `OptionParser`. ## Contributing Bug reports and pull requests are welcome on GitHub at https://github.com/PayTrace/rake-toolkit_program. For further details on contributing, see [CONTRIBUTING.md](./CONTRIBUTING.md).