zeta 0.3.0 → 0.4.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 02f15040a2acf0e5a0b85b9d5a3aa02ff61e3aa4
-  data.tar.gz: e5c2e9bbc3751567af03ef034b90f9e715672710
+  metadata.gz: cc1fa795152d2eafcd724bf92624b98e6a24c3c0
+  data.tar.gz: de69bbd58d346f4d8d23243b5aa487cf4dd75443
 SHA512:
-  metadata.gz: fc605fed51ad16edcc90c4ed90bba8cd967c2a1b169d6ff2b5b558cd10886d4a51b31a5ec7a9b09bbdfecbb1421425e9d23dba457a55241d38287a81642e8fa0
-  data.tar.gz: 8ed946c7a676e81c3d36a99bdb7b904498f1c71138c7b4c5ccd229485832f84a245bc8f9c38a5f6f98fe008a101e8ef99036183aa139ac1e811ba73557869963
+  metadata.gz: 26af9adcdd2b7a9de94f10a21261ad15a5ea3784c68cd05c462fbd3c64c5f0ab1a0bf2e279018ce8448b75f439b84706defc376467158738b1a908b09f204304
+  data.tar.gz: 49ade2a3d0b12551600eccd0599b91e6254d9deefeeca6f22a82158240ebf3e6225ba11500377dcc29680fc303cb3c6d6ca73e1a05e1812575a674914331774d

data/CHANGELOG.markdown

@@ -1,6 +1,10 @@
+# 0.4.0 (30-Oct-15)
+- update lacerda which uses ServiceName::Object in favor of ServiceName:Object
+
 # 0.3.0 (29-Oct-15)
 - forward published/consume object validation method to the current service in the infrastructure
 - forward wrapped consume object creation to the current service
+- use HTTP_USER and HTTP_PASSWORD instead of GITHUB_USER and GITHUB_TOKEN
 
 # 0.2.5 (28-Oct-15)
 - better CLI help

data/README.md

@@ -7,11 +7,11 @@
 TLDR:
 - each service defines which objects it publishes or consumes
 - these contracts are formatted in human readable markdown
-- you never have to know/care about other services or repositories
+- you never have to check out other services' repositories
 
 Zeta will:
-- know the rest of your infrastructure and fetches the contracts of all other services
-- alert you if your change in service X breaks service Y
+- know the rest of your infrastructure and fetch the contracts of all other services
+- alert you if your change breaks the expectactions of other services
 ```
 
 In an infrastructure where many services are talking with each other, it's sometimes hard to know **how changes in one service affect other services**, as each service often just knows about itself. Even if local tests pass, you can't know what other services might be affected when you make changes to a service.
@@ -23,7 +23,7 @@ In an infrastructure where many services are talking with each other, it's somet
 
 Let's imagine an imaginary chat app that is split up into three independent services that communicate via a message broker:
 
-- **MessageService** keeps track of the state of to do items
+- **MessageService** keeps track off storing messages
 - **SearchService** makes your chat history searchable
 - **NotificationService**: sends an email when a private message is received
 
@@ -33,7 +33,7 @@ An intern is asked to implement a feature that allows one message to be sent to
 
 😱But **THE INTERN JUST BROKE THE NOTIFICATION SERVICE** because it depends on the `recipient_id` property 😱
 
-Wouldn't it be nice of some test local to the **MessageService** repository to tell the poorintern that removing the `recipient_id` property breaks the expectations other services have of the *MessageService* BEFORE they deploy?
+Wouldn't it be nice of some test local to the **MessageService** repository to tell the poor intern that removing the `recipient_id` property breaks the expectations other services have regarding the *MessageService* BEFORE the intern hits the red deploy button?
 
 
 ## Yes, it would!
@@ -46,8 +46,8 @@ Each service has to contain two files in order for *Zeta* to do its job:
 These are simple markdown files in the wonderful [MSON](https://github.com/apiaryio/mson) format. Let's look at the contracts dir of **MessageService**, shall we?
 
 ### A publish specification:
+`contracts/publish.mson:`
 ```shell
-/home/dev/message-service$ cat contracts/publish.mson
 # Data Structures
 This file defines what MessageService may publish.
 
@@ -62,12 +62,12 @@ This file defines what MessageService may publish.
 So far so good. This way *MessageService* can tell the world what exactly it means when a `Message` object is published. Much the same, the *NotificationService* could define which properties of a `Message` object from the `MessageService` it is actually interested in:
 
 ### A consume specification:
+`contracts/consume.mson:`
 ```shell
-/home/dev/notification-service$ cat contracts/consume.mson
 # Data Structures
 We just consume one object type, and it comes from the MessageService. Check it out!
 
-# MessageService:Message
+# MessageService::Message
 - sender_id: (number, required)
 - recipient_id: (number, required)
 ```
@@ -84,7 +84,7 @@ As you can see, this consumer expects the `recipient_id` property to be present
 ## Getting started
 
 ### 1. Installation
-First, add *Zeta* to your `Gemfile` or install manually:
+Even though it does not matter what programming languages your services are written in, you'll need ruby to run Zeta. To install, add *Zeta* to your `Gemfile` or install it manually:
 
 ```shell
 $ gem install zeta
@@ -135,10 +135,11 @@ production:
 
 ```
 
-You typically just create the above file once and then don't touch it anymore. If that file is in a private repository (that would be a good idea), make sure you `export GITHUB_USER=youruser` and `GITHUB_TOKEN=yourtoken` and *Zeta* will use that.
+You typically just create the above file once in each project and then don't touch it anymore. Whenever a new service gets added to or removed from the infrastructure, you just update the central infrastructure configuration. The what? Central infrastructure configuration? Oh, look:
 
-Here's how `github.com/jensmander/zeta-config/infrastructure/master.yml` might look in our example above:
+Here's how the infrastructure configuration file might look for our example above:
 
+`git@github.com:jensmander/zeta-config/infrastructure/master.yml:`
 ```yaml
 MessageService:
   github:
@@ -159,10 +160,15 @@ NotificationService:
 
 Whenever you add a service to the infrastructure, you just add it to this central file and all existing services will automatically know about your new service.
 
+### 3. Authentication
 
-### 3. Usage
+If your infrastruture configuration file is HTTP Basic auth protected, or in a private repository on github (that would be a good idea), make sure you `export HTTP_USER=username` and `HTTP_PASSWORD=secret` and *Zeta* will use that. If you host on github, the use your username and generate an API token to use as the password.
 
-```shell
+### 4. Usage: Command line
+
+Zeta comes with a `zeta` command that takes care of all the things:
+
+```
 Usage: zeta [options] full_check|fetch_remote_contracts|update_own_contracts|validate
 
 Specific options:
@@ -183,9 +189,9 @@ $ zeta -e development full_check
 
 The above command performs the following three steps:
 
-1. Fetch all contracts from remote repositories and put them into the cache directory configured above
-2. Copy the current services contracts (that you might have changed) into the cache directory
-3. Validate all contracts (i.e. make sure that every publishing service satisfies its consumers)
+1. **Fetch all contracts** from remote repositories and put them into the cache directory configured above
+2. **Copy the current service's contracts** which you might have changed into the contracts cache directory
+3. **Validate all contracts** (i.e. make sure that every publishing service satisfies its consumers)
 
 The above commands can also be run in isolation:
 
@@ -206,3 +212,25 @@ $ zeta -e development update_own_contracts validate
 ```
 
 Otherwise it will exit with an error and display any contract violations in JSON.
+
+### 5. Usage: in ruby
+
+If you use *Zeta* in ruby, it will automatically know the current service, i.e. the one that it's running in. It will create a singleton `Lacerda::Infrastructure` instance from the [Lacerda gem](https://github.com/moviepilot/Lacerda), which gives you access to a bunch of interesting functions. If you're using [pry](https://github.com/pry/pry), go ahead and do a quick `ls Zeta` and you will something like this, likely outdated, list:
+
+```ruby
+[1] pry(main)> ls Zeta
+Zeta.methods:
+  cache_dir             current_service   update_own_contracts
+  config                env               validate_object_to_consume
+  config_file           errors            validate_object_to_consume!
+  consume_object        infrastructure    validate_object_to_publish
+  contracts_fulfilled?  update_contracts  validate_object_to_publish!
+[2] pry(main)>
+```
+
+Each and every one of these goes directly to your instance `Lacerda::Infrastructure`, as defined by `config/zeta.yml`. Feel free to explore them a bit, but the ones' that might be of most interest are:
+
+- `Zeta.validate_object_to_publish('Post', data_to_send)` makes sure that the content in `data_to_send` conforms to your 'Post' specification in your local `publish.mson`
+- `Zeta.consume_object('MessageService::Message', received_data)` will give you an instance of the [Blumquist](https://github.com/moviepilot/blumquist) class, which is an obect that has getters for all properties you specified in `consume.mson`
+
+If you use these in your servies, they will help keeping the publish and consume specifications in sync with what's actually happening in the code.

data/circle.yml

@@ -1,3 +1,3 @@
 machine:
   ruby:
-    version: 2.2.1
+    version: '1.9'

data/lib/zeta/local_or_remote_file.rb

@@ -30,7 +30,7 @@ class Zeta::LocalOrRemoteFile
   end
 
   def self.http_get(url, verbose)
-    masked_url = ENV['GITHUB_TOKEN'].blank? ? url : url.sub(ENV['GITHUB_TOKEN'], '***')
+    masked_url = ENV['HTTP_PASSWORD'].blank? ? url : url.sub(ENV['HTTP_PASSWORD'], '***')
     print "GET #{masked_url}... " if verbose
     result = HTTParty.get url
     raise "Error #{result.code}" unless result.code == 200
@@ -45,6 +45,8 @@ class Zeta::LocalOrRemoteFile
     !!@options[:verbose]
   end
 
+  # In order not to have git as a dependency, we'll fetch from
+  # raw.githubusercontent.com as long as we get away with it.
   def github_url
     repo   = @options[:github][:repo]
     branch = @options[:github][:branch]
@@ -52,8 +54,10 @@ class Zeta::LocalOrRemoteFile
     file   = @options[:file]
 
     uri = [branch, path, file].compact.join('/')
-    if u = ENV['GITHUB_USER'] and t = ENV['GITHUB_TOKEN']
-      "https://#{u}:#{t}@raw.githubusercontent.com/#{repo}/#{uri}"
+    u = ENV['HTTP_USER'] 
+    p = ENV['HTTP_PASSWORD']
+    if p
+      "https://#{u}:#{p}@raw.githubusercontent.com/#{repo}/#{uri}"
     else
       "https://raw.githubusercontent.com/#{repo}/#{uri}"
     end

data/lib/zeta/version.rb

@@ -1,3 +1,3 @@
 class Zeta
-  VERSION = "0.3.0"
+  VERSION = "0.4.0"
 end

data/zeta.gemspec

@@ -19,7 +19,7 @@ Gem::Specification.new do |spec|
   spec.require_paths = ['lib']
 
   spec.add_runtime_dependency 'rake', '~> 10.2'
-  spec.add_runtime_dependency 'lacerda', '~> 0.5'
+  spec.add_runtime_dependency 'lacerda', '~> 0.7'
   spec.add_runtime_dependency 'activesupport'
   spec.add_runtime_dependency 'httparty', '~> 0.13'
   spec.add_runtime_dependency 'colorize'

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: zeta
 version: !ruby/object:Gem::Version
-  version: 0.3.0
+  version: 0.4.0
 platform: ruby
 authors:
 - Jannis Hermanns
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2015-10-29 00:00:00.000000000 Z
+date: 2015-10-30 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rake
@@ -30,14 +30,14 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '0.5'
+        version: '0.7'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '0.5'
+        version: '0.7'
 - !ruby/object:Gem::Dependency
   name: activesupport
   requirement: !ruby/object:Gem::Requirement