Results for gt-node

Performs Wordpress-style conversion of single and double newlines to <p> and <br /> tags. Produces well-formed HTML and intelligently ignores unbreakable sections like <script> and <pre> tags. Conveniently turns Wordpress post content into valid HTML.

Graphviz wrapper for Ruby. This can be used as a common library, a rails plugin and a command line tool. == FEATURES/PROBLEMS: GraphvizR is graphviz adapter for Ruby, and it can: * generate a graphviz dot file, * generate an image file by means of utilizing graphviz, * interprete rdot file and generate an image file, * and, generate a graph image file in rails application as a rails plugin. == SYNOPSYS: === Command Line: bin/graphviz_r sample/record.rdot === In Your Code: This ruby code: gvr = GraphvizR.new 'sample' gvr.graph [:label => 'example', :size => '1.5, 2.5'] gvr.beta [:shape => :box] gvr.alpha >> gvr.beta (gvr.beta >> gvr.delta) [:label => 'label1'] gvr.delta >> gvr.gamma gvr.to_dot replies the dot code: digraph sample { graph [label = "example", size = "1.5, 2.5"]; beta [shape = box]; alpha -> beta; beta -> delta [label = "label1"]; delta -> gamma; } To know more detail, please see test/test_graphviz_r.rb === On Rails : <b>use _render :rdot_ in controller</b> def show_graph render :rdot do graph [:size => '1.5, 2.5'] node [:shape => :record] node1 [:label => "<p_left> left|<p_center>center|<p_right> right"] node2 [:label => "left|center|right"] node1 >> node2 node1(:p_left) >> node2 node2 >> node1(:p_center) (node2 >> node1(:p_right)) [:label => 'record'] end end <b>use rdot view template</b> class RdotGenController < ApplicationController def index @label1 = "<p_left> left|<p_center>center|<p_right> right" @label2 = "left|center|right" end end # view/rdot_gen/index.rdot graph [:size => '1.5, 2.5'] node [:shape => :record] node1 [:label => @label1] node2 [:label => @label2] node1 >> node2 node1(:p_left) >> node2 node2 >> node1(:p_center) (node2 >> node1(:p_right)) [:label => 'record'] == DEPENDENCIES: * Graphviz (http://www.graphviz.org) == TODO: == INSTALL: * sudo gem install graphviz_r * if you want to use this in ruby on rails * script/plugin install http://technohippy.net/svn/repos/graphviz_r/trunk/vendor/plugins/rdot == LICENSE: (The MIT License)

(This gem was named as treevisitor) tree.rb is a 'clone' of tree unix command. The gem implements a library to mange tree structures. The gem contains also a library to build tree with a dsl (domain specific language), and an implementation of visitor design pattern. An example of DSL to build tree: <pre> tree = TreeNode.create do node "root" do leaf "l1" node "sub" do leaf "l3" end node "wo leaves" end </pre>

Implement orderable trees in ActiveRecord using the nested set model, with multiple roots and scoping, and most importantly user-defined ordering of subtrees. Fetches preordered trees in one go, updates are write-heavy. This is a substantially butchered-up version/offspring of acts_as_threaded. The main additional perk is the ability to reorder nodes, which are always fetched ordered. Example: root = Folder.create! :name => "Main folder" subfolder_1 = Folder.create! :name => "Subfolder", :parent_id => root.id subfolder_2 = Folder.create! :name => "Another subfolder", :parent_id => root.id subfolder_2.move_to_top # just like acts_as_list but nestedly awesome root.all_children # => [subfolder_2, subfolder_1] See the rdocs for examples the method names. It also inherits the awesome properties of acts_as_threaded, namely materialized depth, root_id and parent_id values on each object which are updated when nodes get moved. Thanks to the authors of acts_as_threaded, awesome_nested_set, better_nested_set and all the others for inspiration.

A high-performance pure Ruby Red-Black Tree implementation. Features: O(1) key lookup via hybrid hash index, O(log n) insert/delete, lazy Enumerator-based range queries (lt/gt/between), nearest/prev/succ search, memory-efficient node pooling, and MultiRBTree for duplicate keys with first/last value access.

Diff and patch tables

Diff and patch tables

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

No description provided.