json-spec 0.1.0 → 0.1.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: dd9a98802b2e9d9d82dff4d9fd8b6b174812f195
-  data.tar.gz: 071fdf0b74f43cae45e079b089a14fd0fc2af5fc
+  metadata.gz: d950cd2da7210e0edb2f3ae51e57a2649e9d913b
+  data.tar.gz: 65bbc08cf21a7d6d1f075311981061cc441cf4ef
 SHA512:
-  metadata.gz: 797adfabb1a8111259da2fdc097d47f68914414a07a8fdc760cd5aaad744e91bdece18dbf735a2e78124361c57779b3d3b127ba5deeaeb51fae5c0e8038248d2
-  data.tar.gz: 59e894989cc21acb4abdc0feb9bcee8cfd4ef892111e6d39195ed0891ae543fbb564b499e57c73cbc1e995c8a4d60e95f31b10d5d1b153e2c5e47650eb6307e9
+  metadata.gz: 82bec3c17230b4fc2e14f4c7b3ded8b4c52e985b87ae3ca15336a10b28af8b7f1fa73a39093b476fa94eaf89fa0439d7f6d557b228834c89b33e41aa10185795
+  data.tar.gz: cd0f955f2247a27ac9db51d2583c6217a5c045057955d1b54d3cc9ea8768add7158d20b6692bfd195eb4d54bf9a48a9f2be8019a290754408270fa7586f2ad50

data/.travis.yml

@@ -0,0 +1,13 @@
+language: ruby
+
+rvm:
+   - "2.0"
+   - "2.1"
+   - "2.2"
+
+before_install: gem install bundler
+
+script: rake
+
+git:
+   submodules: false

data/Gemfile

@@ -2,3 +2,6 @@ source 'https://rubygems.org'
 
 # Specify your gem's dependencies in json-spec.gemspec
 gemspec
+
+gem 'simplecov', require: false
+gem 'coveralls', require: false

data/README.md

@@ -2,6 +2,12 @@
 
 A framework to declare expectations and verify that a json object satisfies those expectations. You can use this expectations to validate jsons you send or receive in your application, or to test your API with unit tests.
 
+## Status
+
+[![Gem Version](https://badge.fury.io/rb/json-spec.svg)](https://badge.fury.io/rb/json-spec)
+[![Build Status](https://travis-ci.org/cabeza-de-termo/ruby-json-spec.svg?branch=master)](https://travis-ci.org/cabeza-de-termo/ruby-json-spec)
+[![Coverage Status](https://coveralls.io/repos/cabeza-de-termo/ruby-json-spec/badge.svg?branch=master&service=github)](https://coveralls.io/github/cabeza-de-termo/ruby-json-spec?branch=master)
+
 ## Installation
 
 Add this line to your application's Gemfile:
@@ -233,7 +239,7 @@ If you want to run this example, see the [second example](examples/example-2-def
 
 ## Declaring expectations for fields not known in advance.
 
-If you run the previous example, you may notice that it outputs the folowing:
+If you run the previous example, you may notice that it outputs the following:
 
 ```
 - Failed expectations: 0
@@ -383,7 +389,7 @@ And third, and worst than the previous reasons, is that we are duplicating expec
 
 So it would be nice to be able to organize the expectations somehow.
 
-We can put expectations in methods, and then call those methods from within the json_spec. This methods can be in any class, but we are going to create a `ComposerJson` class to keep the `composer.json` expectations in one place.
+We can put expectations in methods, and then call those methods from within the json_spec. This methods can be in any object, but we are going to create a `ComposerJson` class to keep the `composer.json` expectations in one place.
 So now we have the class
 
 ```ruby
@@ -505,13 +511,13 @@ CabezaDeTermo::JsonSpec::JsonSpec.new do
 end
 ```
 
-That is because when we don't pass a parameter to the defintion block, it changes the binding of self, and the we can not declare thinkgs like
+That is because when we don't pass a parameter to the defintion block, it changes the binding of self, and then we can not declare thinkgs like
 
 ```ruby
 .to_be_as_defined_in(self, :keywords_spec)
 ```
 
-Changing the binding to self is usually a bad idea, but in the definitions of this framework it will only do that if no parameter is given to the definition block.
+Changing the binding of self without asking first is not a polite thing to do, but in the definition blocks of this framework it will only do that if no parameter is given to the block.
 
 If you want to run this example, see the [fourth example](examples/example-4-to-be-as-defined-in.rb) in the `examples/` folder.
 
@@ -519,16 +525,18 @@ If you want to run this example, see the [fourth example](examples/example-4-to-
 
 If we look at the `composer.json` definition, we will notice that sometimes it accepts different structures for the same field. For instance, for `psr-4` values, it can take a list of folder strings or a single folder string.
 
-To expect different structures on the same object, we use `:expect(:any_of)`:
+To expect different structures on the same object, we use `expect(:any_of)`:
 
 ```ruby
 expect('psr-4') .to_be_a(:list) do
-	expect(:any_of) do
-		expect_a(:scalar) .to_be_folder
-	or_also
-		expect_a(:list) .not_empty do
-			each do
-				expect_a(:scalar) .to_be_folder
+	each do
+		expect(:any_of) do
+			expect_a(:scalar) .to_be_folder
+		or_also
+			expect_a(:list) .not_empty do
+				each do
+					expect_a(:scalar) .to_be_folder
+				end
 			end
 		end
 	end
@@ -672,7 +680,7 @@ CabezaDeTermo::JsonSpec::ExpectationsLibrary.define do
 	expectations do
 		define :to_be_some_complex_stuff do
 			with_class IsSomeComplexStuff
-			message "<%= value %> is not a ComplexStuff."
+			message "<%= value %> is not some complex stuff."
 		end
 	end
 end
@@ -710,7 +718,7 @@ json_spec.define do
 end
 ```
 
-You have to admit that these custom messages, although they are in a slang so boring and outdated that will get you to sleep in, like, 10 minutes, have a lot more of what we might call `poetic flight` than the default ones.
+You have to admit that these custom messages, although they are in a slang so boring and outdated that will get you to sleep in, like, 10 minutes, have a lot more of what we might call poetic flight than the default ones.
 
 Just like when defining new Expectations, we have several ways to define custom messages. Lets walk through them:
 
@@ -726,7 +734,7 @@ CabezaDeTermo::JsonSpec::ExpectationsLibrary.define do
 end
 ```
 
-This is the simpliest way, and it should be enough most of the times. You can reference :value_holder, :value, :accessors_chain, :field and :expectation objects from within a erb block: `<%= field %>`.
+This is the simpliest way, and it should be enough most of the times. You can reference :value_holder, :value, :accessors_chain, :field and :expectation objects from within a erb block: `<%= ... %>`.
 
 - Using a [BlockMessageFormatter](lib/cabeza-de-termo/json-spec/message-formatters/block-message-formatter.rb) object
 
@@ -734,7 +742,7 @@ This is the simpliest way, and it should be enough most of the times. You can re
 CabezaDeTermo::JsonSpec::ExpectationsLibrary.define do
 	expectations do
 		define :to_be_integer do
-			message_block { |expectation, value_holder| "No a valid integer." }
+			message_block { |expectation, value_holder| "Not a valid integer." }
 		end
 	end
 end
@@ -787,7 +795,7 @@ Ok, so we can define default expectations for each expression, add new custom ex
 
 In that case, it is a good idea to bundle it all together in one place.
 
-That place can be the [LibraryInitializer](lib/cabeza-de-termo/json-spec/expectations-library/initializers/library-initializer.rb).
+That place can be a [LibraryInitializer](lib/cabeza-de-termo/json-spec/expectations-library/initializers/library-initializer.rb).
 
 Create you own class that implements the [LibraryInitializer](lib/cabeza-de-termo/json-spec/expectations-library/initializers/library-initializer.rb) protocol, and there create a new and fully configured [ExpectationsLibrary](lib/cabeza-de-termo/json-spec/expectations-library/expectations-library.rb).
 
@@ -926,7 +934,7 @@ Anyways, you can use the Vagrant configuration for that. To do so:
 
 * Install [VirtualBox](https://www.virtualbox.org/)
 * Install [Vagrant](https://www.vagrantup.com/)
-* `git clone --recursive git@github.com:mrubi/ruby-json-spec.git`
+* `git clone --recursive git@github.com:cabeza-de-termo/ruby-json-spec.git`
 * `cd ruby-json-spec/cachivache`
 * `vagrant up`
 
@@ -935,7 +943,7 @@ and that will install all the necessary things to run the tests and examples in
 Then to start playing around with the code, do
 
 * `vagrant ssh`
-* `cd src/json-spec`
+* `cd src`
 
 and that's it. You have a fully prepared, ready to use development environment.
 
@@ -943,16 +951,9 @@ and that's it. You have a fully prepared, ready to use development environment.
 
 * `rake test`
 
-## Development
-
-After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` 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/[USERNAME]/json-spec.
-
+Bug reports and pull requests are welcome on GitHub at https://github.com/cabeza-de-termo/ruby-json-spec.
 
 ## License
 

data/cachivache/.gitignore

@@ -1 +1 @@
-.vagrant
+.vagrant

data/cachivache/README.md

@@ -1,6 +1,12 @@
 # CabezaDeTermo::Cachivache
 
-Cachivache is a provisioner for Vagrant machines that use Ubuntu images.
+## Installation
+
+- `gem install cachivache`
+
+## Description
+
+Cachivache is a provisioner for Vagrant machines with Ubuntu images.
 
 You can provision a Vagrant VM using shell scripts, or more sophisticated tools like [Puppet](https://puppetlabs.com/), [Chef](https://www.chef.io/chef/), [salt](https://docs.saltstack.com/en/latest/), [Ansible](http://www.ansible.com/) and by the time you are reading this probably a few more.
 
@@ -16,24 +22,46 @@ On the other hand, the problems with shell provisions are that
 
 The provisioning tools like Puppet and Chef resolve these problems, and a lot more. Actually, they resolve so much more problems that is overkill to only use them to provision a Vagrant machine for developing.
 All of these tools define their own DSL and high level concepts and metaphors, they require you configure them, you must search for the correct recipes to install what you want, etc.
-These tools are a must to manage the provisioning of different environments, but for a developer machine they are way too much.
+These tools are a must to manage the provisioning of different environments, but for a single developer machine they are way too much.
 
 Cachivache is a middle ground between bash scripts and these tools.
 Instead of reinventing the wheel with a brand new DSL and new metaphors, Cachivache uses a wheel that we have had for ages: [Rake](https://github.com/ruby/rake).
 
-The idea behind Cachivache is to put little bash scripts in Rake tasks, and the run those tasks from within the Vagrant VM. As the Ubuntu images already come with a Ruby installation, there's not much to do at all.
+## Usage
+
+Once you installed the `cachivache` gem, setup cachivache for your project:
+
+- Go to the root of your project
+- `cachivache init`
+- `cd cachivache`
+
+write some stuffs in your `stuff` folder and set what stuff to install and your git email and user:
+
+- `cachivache config`
+
+and that's it, you can now start Vagrant with:
+
+- `vagrant up`
+- `vagrant ssh`
+- `cd src`
+
+and you have your project running in a Vagrant machine.
+
+If you want to commit from Vagrant, add the `:'projects-setup'` as a dependency of your project in the stuff you created, it will set your git credentials.
+
+The idea behind Cachivache is to put little bash scripts in Rake tasks, and then run those tasks from within the Vagrant VM. As the Ubuntu images already come with a Ruby installation, there's not much to do at all.
 
 So, Cachivache has very few concepts:
 
 - Bash scripts, which you put in Rake tasks
 
-- Rake tasks, that can depend on other Rake tasks
+- Rake tasks (also called stuffs in this framework), that can depend on other Rake tasks
 
 - Ruby string interpolation, which allows you to easily parametrize stuff in the bash scripts
 
 - And the secret ingredient: stuff
 
-What is stuff? Stuff is a folder. That's it. Cachivache believes in giving power to the people, so instead of defining how, where and when you must organize your scripts, it will let you organize things in any way you want in a couple of folders: `stuff-library` and `stuff`. No recipes, playbooks, roles, bags, configurations, minions, masters, slaves, facts, etc. Just put stuff in a folder.
+What is stuff? Stuff is a folder with .rb files. That's it. Cachivache believes in giving power to the people, so instead of defining how, where and when you must organize your scripts, it will let you organize things in any way you want in a couple of folders: `stuff-library` and `stuff`. No recipes, playbooks, roles, bags, configurations, minions, masters, slaves, facts, etc. Just put stuff in a folder.
 [`stuff-library`](https://github.com/cabeza-de-termo/stuff-library) folder holds some existing stuff you can use to install things, and in `stuff` you can toss your own stuff for your project.
 
 ## So, what does a stuff look like?
@@ -43,200 +71,252 @@ Well, here's an example stuff that setups all the necessary things to work on a
 ```ruby
 dependencies = [
    :'projects-setup',
-	:graphviz,
+   :graphviz,
    :xdebug,
-   :composer
+   :'php-cli',
+   :composer,
 ]
 
-namespace :stuff do
-   task :'php-json-spec' => dependencies do
-   	sh %{
-			cd #{PHPJsonSpec.project_folder}
+stuff :'php-json-spec' => dependencies do
+   shell %{
+      cd #{PhpJsonSpec.project_folder}
 
-			composer install
+      composer install
 
-			# Run the test coverage report
-			php vendor/bin/phpunit -c phpunit-with-coverage.xml
+      # Run the test coverage report
+      php vendor/bin/phpunit -c phpunit-with-coverage.xml
 
-			# Generate the documentation
-			php vendor/bin/phpdoc   		
-   	}
-   end
+      # Generate the documentation
+      php vendor/bin/phpdoc         
+   }
 end
 
-class PHPJsonSpec
-   include LetBehaviour
-
+configure :PhpJsonSpec do
    let(:project_folder)     { Cachivache.src_folder }
 end
 ```
+## How do I tell Cachivache what to install?
+
+Edit the file `cachivache.rb` and define the stuffs to install in the section
+
+```ruby
+   ####################################
+   # Define what stuff to install
+   ####################################
+
+   let(:stuff_to_install) {
+      [
+         'ruby-json-spec',
+         'some-other-stuff',
+         'a-namespace:and-another-one:more-stuff',
+         'mysql-server', # You can install any stuff as long as it is defined
+      ]
+   }
+```
 
-That's all there is. Bash + Rake + string interpolation + a little sintatic sugar.
+Note that if you set the dependencies of each stuff correctly, you will only have to tell Cachivache to install the top most stuff, and Rake will do the rest for you. Thanks Rake! 
 
 ## What other awesome features has Cachivache?
 
 As I said before, all the work is done by Rake, so pretty much none.
 
-There is some sintactic sugar you can use to perform some common task though.
+There is some sintactic sugar you can use to perform some common task though. But please note that using any of these shorcuts is not mandatory at all, you can just stick to plain old shell scripts.
 
 If you haven't see any ruby code before, here are some tips to use in Cachivache stuffs:
 
 ### You can define strings in several ways:
 
 ```ruby
-task :'do-stuff' do
-   sh %Q{
+stuff :'do-stuff' do
+   shell %Q{
       echo "stuff"
    }
 end
 
 # or
 
-task :'do-stuff' do
-   sh %Q[
+stuff :'do-stuff' do
+   shell %Q[
       echo "stuff"
    ]
 end
 
 # or
 
-task :'do-stuff' do
-   sh %(
+stuff :'do-stuff' do
+   shell %(
       echo "stuff"
    )
 end
 
 # or in a single line
 
-task :'do-stuff' do
-   sh %Q{echo "stuff"}
+stuff :'do-stuff' do
+   shell %Q{echo "stuff"}
 end
 
 # or with ""
 
-task :'do-stuff' do
-   sh "echo \"stuff\""
+stuff :'do-stuff' do
+   shell "echo \"stuff\""
 end
 ```
 
 You see in the last example that if we define strings using "" we need to scape internals \", so the simpliest is to use `%Q{}`.
 
-### You can call as many `sh` blocks in a task as you like:
+### You can call as many `shell` blocks within a task as you like. You can also :invoke and :execute other tasks:
 
 ```ruby
-task :'do-stuff' do
-   sh %Q{
+stuff :'do-stuff' do
+   shell %Q{
       echo "stuff"
    }
 
-   sh %Q{
+   invoke 'install-apache'
+
+   shell %Q{
       echo "even more stuff"
    }
-end
-```
 
-### You can invoke and execute other tasks from within a task:
+   execute 'restart-apache'
 
-```ruby
-task :'do-stuff' do
-   invoke 'install-apache'
-	execute 'restart-apache'
+   shell! %Q{
+      echo "You would normally not need to use :shell! (note the exclamation mark) but you can"
+   }
 end
 ```
 
 The difference between :invoke and :execute is that :execute will perform the task every time it's called, whilst :invoke will only run the task once during the provision. So, to install and configure stuff use :invoke, but to turn things on and off use :execute.
-Or always use :execute to make things simplier. It's up to you.
+Or if your tasks are idempotent, always use :execute to make things simplier. It's up to you.
 
 ### Instead of using bash `if ! ...; then; .... fi`, you can use these Cachivache helpers:
 
 ```ruby
-task :'do-stuff' do
-	sh_unless file_exists: '/bla.conf' do
-	   sh %Q{
-	      ls -la
-	      rm -rf bla
-	   }
-	end
+stuff :'do-stuff' do
+   shell_unless file_exists: '/bla.conf' do
+      shell %Q{
+         ls -la
+         rm -rf bla
+      }
+   end
 end
 ```
 
 ```ruby
-task :'do-stuff' do
-	sh_unless folder_exists: '/bla' do
-	   sh %Q{
-	      ls -la
-	      rm -rf bla
-	   }
-	end
+stuff :'do-stuff' do
+   shell_unless folder_exists: '/bla' do
+      shell %Q{
+         ls -la
+         rm -rf bla
+      }
+   end
 end
 ```
 
 ```ruby
-task :'do-stuff' do
-	sh_unless file: '/bla', contains: 'some regex' do
-	   sh %Q{
-	      ls -la
-	      rm -rf bla
-	   }
-	end
+stuff :'do-stuff' do
+   shell_unless file: '/bla', contains: 'some regex' do
+      shell %Q{
+         ls -la
+         rm -rf bla
+      }
+   end
 end
 ```
 
 ```ruby
-task :'do-stuff' do
-	sh_unless command: 'java -version', contains: 'java 1.8' do
-	   sh %Q{
-	      ls -la
-	      rm -rf bla
-	   }
-	end
+stuff :'do-stuff' do
+   shell_unless command: 'java -version', contains: 'java 1.8' do
+      shell %Q{
+         ls -la
+         rm -rf bla
+      }
+   end
 end
 ```
 
 - To append and replace text in a file, you can use this Cachivache helper:
 
 ```ruby
-task :'do-stuff' do
-	sh_in_file "/etc/bla.conf" do
-	   replace pattern: "%user%", with: "admin"
+stuff :'do-stuff' do
+   in_file "/etc/bla.conf" do
+      shell replace pattern: "%user%", with: "admin"
 
-	   append "[cachivache]"
-	   append "path='/bla'"
-	end
+      shell append "[cachivache]"
+      shell append "path='/bla'"
+      shell append :new_line
+   end
+end
+```
+
+### You can use variables instead of hardcoding values in the scripts:
+
+```ruby
+stuff :'do-stuff' do
+   shell %Q{
+      mkdir #{DoStuff.some_folder}
+
+      mkdir #{SomethingDefinedElsewhereWorksToo.some_folder}
+   }
+end
+
+configure :DoStuff do
+   let(:some_folder)    { '/home/vagrant/some-folder' }
 end
 ```
 
 ### If you want to remind the user of something after the provision is done, in any task use :remind_to
 
 ```ruby
-task :'do-stuff' do
-	sh %Q{
-		ls -la
-	}
+stuff :'do-stuff' do
+   shell %Q{
+      ls -la
+   }
 
-	remind_to "Please don't forget to add '#{Cachivache.vagrant_ip_address} cachivache.com' to your /etc/hosts file"
+   remind_to "Please don't forget to add '#{Cachivache.vagrant_ip_address} cachivache.com' to your /etc/hosts file"
 end
 ```
+## What if I want to use my own [`stuff-library`](https://github.com/cabeza-de-termo/stuff-library)?
 
-## Installation
+No prob! Go to your `cachivache` folder and:
 
-- Go to the root of your project
-- `git clone git@github.com:cabeza-de-termo/cachivache.git`
-- `cd cachivache/`
-- `rm -rf .git/`
-- `git submodule add git@github.com:cabeza-de-termo/stuff-library.git`
+- `cachivache add-stuff-library git@github.com:someuser/my-very-own-stuff-library.git`
 
-Now edit `cachivache.rb` and set what stuff to install and your git email and user:
+Cachivache will load any .rb file in the cachivache folder, so your library stuff will be loaded too.
 
-- `pico cachivache.rb`
+To update some stuff library from git do:
 
-## What if I want to use my own stuff-library?
+- `cachivache update-stuff-libraries my-very-own-stuff-library`
 
-No prob! just replace or add to the previous step your custom library:
+To update all the stuff libraries do:
 
-- `git submodule add git@github.com:someuser/my-very-own-stuff-library.git`
+- `cachivache update-stuff-libraries`
 
-Cachivache will load any .rb file in the cachivache folder, so your library stuff will be loaded too.
+To remove a stuff library do:
+
+- `cachivache remove-stuff-libraries stuff-library`
+
+## Debugging
+
+During the building of the stuff, it's useful to be able to see what the provision would do instead of running it.
+
+To debug the provision do
+
+- Go to the root of your project
+- `cd cachivache`
+- `vagrant ssh`
+- `cd src/cachivache` (now you are in Vagrant)
+- `bundle install`
+- `rake explain` will output the complete shell script without running it
+- `rake some-stuff` will execute only some-stuff and its dependencies
+
+## Running the tests
+
+Not a single test was written this day :(
+
+## Roadmap
+
+- v1.0.0: Make a custom Vagrant provisioner plugin
 
 ## Contributing