Unobtrusive scripting adapter for jQuery
A framework for responsive emails
Cross-language temporary (disposable/throwaway) email detection library. Covers hundreds fake email providers.
bootstrap-sass is a Sass-powered version of Bootstrap 3, ready to drop right into your Sass powered applications.
A JavaScript library for escaping CSS strings and identifiers while generating the shortest possible ASCII-only output.
A fast, zero-dependency package for cutting down on common issues developers have when running pod install.
Simple git hooks manager
The Linux 64-bit binary for lefthook, git hooks manager.
Companion package for the cocoon Ruby gem.
Rails UJS for the react-rails gem
Rokt Mobile SDK to integrate ROKT Api into ReactNative application
Responsive Theme for ActiveAdmin
RailsAdmin is a Rails engine that provides an easy-to-use interface for managing your data.
Ruby plugin for textlint
sdk for Gem Farm (by GemWorks 💎)
Native ES6 @mentions
Flat design for ActiveAdmin
Local <time> elements
Mekari ui toolkit
Webpack Builder for Architect
Google's Material Design colors for Sass/Scss
A Babel preset that enables parsing of proposals supported by the current Node.js version.
A live preview of your emails right in your browser.
The Linux ARM 64-bit binary for lefthook, git hooks manager.
A collection of gem related tasks for Runfile
Intercepts Resend gem API calls in development, stores emails as JSON, and provides a web UI to browse, preview, and simulate replies. Production code runs unchanged — same pipeline in dev and prod.
# Soft Delete > In a production app, you should probably never really delete anything. [source](https://twitter.com/theebeastmaster/status/966870021099180034) A soft-delete marks a record as deleted, and keeps it in the database for historical reference. ## Installation Add this line to your application's Gemfile: ```ruby gem "soft_delete-workbar", require: "soft_delete" ``` And then execute: $ bundle Or install it yourself as: $ gem install soft_delete-workbar ## Usage Safely "delete" records from your database without losing them permanently. * Add SoftDelete to a model ``` class MyModel < ActiveRecord::Base include SoftDelete end ``` * Add a `deleted_at` column to the model's database table ``` rails g migration AddSoftDeleteToMyModels deleted_at:timestamp ``` * Safely call `MyModel#delete` without losing the record forever ## Methods Please see the `SoftDelete` module and the associated tests for a description of the methods that will be added to your model. * `.not_deleted` - records without a deleted_at timestamp * `.deleted` - records with a deleted_at timestamp * `#delete` - set the deleted_at timestamp * `#delete!` - delete the record from the database * `#destroy` - set the deleted_at timestamp, and run callbacks * `#destroy!` - delete the record from the database, and run callbacks * `#restore` - set the deleted_at timestamp to nil It will be necessary to exclude deleted records when querying the model. Use the `not_deleted` scope that now exists on the model. ```ruby class MyModelsController < ApplicationController def index @my_models = MyModel.not_deleted end end ``` ## Development After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. 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). ## Contributing Bug reports and pull requests are welcome on GitHub at https://github.com/workbar-dev/soft_delete. ## License The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
pikuri-code adds the shell-and-dev-loop layer on top of pikuri-workspace's filesystem tools: a +Pikuri::Code::Bash+ that runs commands via the +Pikuri::Subprocess+ chokepoint with +Confirmer+ gating (optionally wrapped in a +Pikuri::Code::Bash::Sandbox::Bubblewrap+ filesystem sandbox), plus the demo +bin/pikuri-code+ binary that wires file + shell + web tools into an interactive coding agent rooted at the current working directory. The +Pikuri.prompt+ search path picks up this gem's +prompts/coding-system-prompt.txt+ automatically on require.
= Mcrypt - libmcrypt bindings for Ruby Mcrypt provides Ruby-language bindings for libmcrypt(3), a symmetric cryptography library. {Libmcrypt}[http://mcrypt.sourceforge.net/] supports lots of different ciphers and encryption modes. == You will need * A working Ruby installation (>= 1.8.6 or 1.9) * A working libmcrypt installation (2.5.x or 2.6.x, tested with 2.5.8) * A sane build environment == Installation Install the gem: gem install ruby-mcrypt --test -- --with-mcrypt-dir=/path/to/mcrypt/prefix If you're installing on Ubuntu: sudo apt-get install mcrypt libmcrypt-dev gem install ruby-mcrypt If you want to run the longer test suite, do this instead: MCRYPT_TEST_BRUTE=1 \ gem install ruby-mcrypt --test -- --with-mcrypt-dir=/path/to/mcrypt/prefix Put this in your code: require 'rubygems' require 'mcrypt' Or in Rails' environment.rb: gem "ruby-mcrypt", :lib => "mcrypt" == Usage crypto = Mcrypt.new(:twofish, :cbc, MY_KEY, MY_IV, :pkcs) # encryption and decryption in one step ciphertext = crypto.encrypt(plaintext) plaintext = crypto.decrypt(ciphertext) # encrypt in smaller steps while chunk = $stdin.read(4096) $stdout << crypto.encrypt_more(chunk) end $stdout << crypto.encrypt_finish # or decrypt: while chunk = $stdin.read(4096) $stdout << crypto.decrypt_more(chunk) end $stdout << crypto.decrypt_finish == Known Issues * Test coverage is lacking. If you find any bugs, please let the author know. == Wish List * IO-like behavior, e.g. crypto.open($stdin) { |stream| ... } == Author * Philip Garrett <philgarr at gmail.com> == Copyright and License Copyright (c) 2009-2013 Philip Garrett. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
# Chef Data Region ## Description Chef Data Region extends the `Chef::DSL::DataQuery` module's `data_bag_item` method with the ability to dynamically expand the data bag name in a configurable, environment-specific manner. ## Motivation This gem exists to address the following scenario: An organization maintains data in Chef data bag items. The data is deployed to several data center environments and is stored in data bags whose names reference the environments. The organization wants to write environment-agnostic recipes that access the data bags without explicitly referencing the data bags by their environment names. As a concrete example, imagine the organization maintains encrypted data for three deployment environments: development, staging, and production. It maintains this data in three data bags, one for each environment, with data for services named `gadget` and `widget` in items: | Environment | Bag | Item | |-------------+----------------+--------| | Development | secure-dev | gadget | | Development | secure-dev | widget | | Production | secure-prod | gadget | | Production | secure-prod | widget | | Staging | secure-staging | gadget | | Staging | secure-staging | widget | The items are encrypted with a key unique to that environment to maximize security. Now consider how a recipe would access these bags. When then recipe is running, it needs to know the data center environment in order to construct the bag name. The organization would most likely assign the enviroment name to a node attribute. In a naive implementation, each recipe would include logic that examined the attribute's value to determine which bag to load. This would obviously duplicate code. Imagine instead that the organization wants to reference the bag by the name `secure` and rely on an _abstraction_ to translate `secure` into the environment-specific bag name. This gem provides that abstraction. ## Features This gem overrides the `data_bag_item` method with configurable logic that dynamically decides which bag to load. It retains API compatibility with `Chef::DSL::DataQuery#data_bag_item`, so existing recipes that call `data_bag_item` work without modification. The gem imposes no constraints on data bag item structure. ## Configuration Assign the region name to a node attribute that varies by environment: node.default['local'][region'] = 'staging' Add the following configuration to Chef Client's `client.rb` file. * Require the gem: require 'chef/data_region' * Configure the gem with a hash that maps a bag name to an expansion pattern: Chef::DataRegion.add( 'secure', { attribute: %w(local region), pattern: 'secure-%<attribute>s' } ) ## Bag name expansion The gem expands bag names using Ruby's `format` method. _More pending..._
Chef-Berksfile-Env ================== A Chef plugin which allows you to lock down your Chef Environment's cookbook versions with a Berksfile. This is effectively the same as doing `berks apply ...` but via `knife environment from file ...`. View the [Change Log](https://github.com/bbaugher/chef-berksfile-env/blob/master/CHANGELOG.md) to see what has changed. Installation ------------ /opt/chef/embedded/bin/gem install chef-berksfile-env Usage ----- In your chef repo create a Berksfile next to your Chef environment file like this, chef-repo/environments/[ENV_NAME]/Berksfile This is the default location that will used by the plugin. We have to put the Berksfile in its own directory since [multiple Berksfiles can't exist in the same directory](https://github.com/berkshelf/berkshelf/issues/1247). The berksfile should include any cookbooks that your nodes or roles explicitly mention for that environment, source "https://supermarket.getchef.com" cookbook "java" cookbook "yum", "~> 2.0" ... Next we need to generate our Berksfile's lock file, berks install Your environment file must by in `.rb` format and look like this, require 'chef-berksfile-env' # The name must be defined first so we can use it to find the Berksfile name "my_env" # Load Berksfile locked dependencies as my environment's cookbook version contraints load_berksfile ... Now our environment will use the locked versions of the cookbooks and transitive dependencies generated by our Berksfile. Upgrading to the latest dependecies is now as simple as, berks install Our Berksfile also provides an easy way to ensure all the cookbooks and their versions that our environment requires are uploaded to our chef-server, berks upload How the Plugin Finds the Berksfile ---------------------------------- If you are curious how the plugin knows to find the Berksfile in `chef-repo/environments/[ENV]/Berksfile`, you want to put your Berksfile somewhere else or you have run into this error `Expected Berksfile at [/path/../Berksfile] but does not exist`, this section will explain how this works and ways to tweak the path or fix your error. `load_berksfile` has an optional argument which represents the path to your Berksfile. This path can be pseduo relative (explained in a moment) or absolute. By default the value is `environments/[ENV_NAME]/Berksfile`. By pseduo relative I mean that its a relative path but the plugin will check to see if the directory we are executing from partially matches our relative path. So if we are running knife from `/home/chef-repo/environments` and our relative path is `chef-repo/environments/dev/Berksfile` the plugin will see that the relative path is partially included in our execution directory and will attempt to merge the two to come up with `/home/chef-repo/environments/dev/Berksfile`. If we can't make any match at all we attempt to guess the path by just joining the relative path with our execution directory. So why do we do this? Well the only way to use this plugin is if your environment is in Ruby format. Chef's `knife from file ...` uses Ruby's `instance_eval` in order to do this. This means the code on Chef's end effectively looks like this, env.instance_eval(IO.read(env_ruby_file)) which means that any context about the location of the environment file is lost. So we have no great way to discern the location of our environment Ruby file, so instead we guess.