utter 1.0.11 → 1.0.12

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: a6be512cec38a463f18416795e951d283a76c350
-  data.tar.gz: 8eefd2f2954a0e382ffb9405d3945793760f99f4
+  metadata.gz: cdf2b5c8c75676a9605a818673f990b68474ffe3
+  data.tar.gz: eab9137f7b86d03b26f1dccd28abd7687c0d3c5b
 SHA512:
-  metadata.gz: f8a0b83279afe7fbd16459df3b11026f3f0d6aa883d14fb2eda0e285b2164f86a06b1a49b9fcbe1471521af9cc0aa1bb1facfe9c998aec9df5ad89e24cb9c446
-  data.tar.gz: a3d109d82928cbe87f1d0f0c2ebf96fb99756fba22baaa4199383715303ce45001535ddfc820ee325427106ad09715642c20666c9c551fd8ff5b4f6cc2e9f311
+  metadata.gz: 79f51c198aefd0586da59a5550ca214eef5829c2ba97936013ef38faa98c0d082ec0e0d99a5c1ae19a74976bc7ba6dc61baff7a034698281ce194bd029d7ad7e
+  data.tar.gz: 3c3a04af7302911994775a69ccae096b46ffc04f8b01918d2b78d1d588f30826de8423c52fb07807d0d85ce49dcbd07328c2224450912c56ec737509c6558995

data/README.md

@@ -66,10 +66,20 @@ Rule-based programs also separate the knowledge from the rest of the program in
 
 Microservice Documentation
 ==========================
+TODO Checkout Thor soucecode to see how they implment Desc methods to make it similar to generate documentation.
+TODO Also checkout grape sourcecode
 Utter under the hood uses sinatra gem to auto-generate an live interactive documentation from your code comments, in example
 if you mount your microservice on api.mystartup.com/v1/products the live interactive documenations will be auto-generated on api.mystartup/v1/products/docs
 each user can read it and send json from the documentation pages to your live api.
 
+URL: http://nameko.readthedocs.io/en/stable/about_microservices.html#single-purpose
+
+UseCases
+=========
+if your enviroment is a polygot of microservcies with different technologies and languages, Utter is the one you should use if you want to write Ruby code.
+
+Somthing like Uber can use Utter to the mess of their system. Utter will divide their system on domain basis, provide their engineers with Rule-based communication to other services, and a dramatically smaller number of services (using domain design as guideline for isolating services)! https://eng.uber.com/soa/
+https://eng.uber.com/building-tincup/
 What's Utter Main UseCase?
 ===========================
 WRITING EFFECTIVE USE CASES: http://alistair.cockburn.us/get/2465

data/bin/cli.rb

@@ -0,0 +1,100 @@
+#!/usr/bin/env ruby
+
+require "thor"
+require_relative 'quotes'
+require_relative 'generators'
+
+module Utter
+  #This directory contains common microservice templates
+  #- auth microservice template
+  #- logging microservice template
+  #- admin microservice template
+  #
+  #- User generate a template and specifiy certain attr to customize the template to their own needs.
+  #- User then use/further developm the generated microservice.
+  class CLI < Thor
+    include Utter::Quotes
+
+    no_commands do 
+      def seprator
+	puts (" ")
+	puts("-------------------------------------------------------------------------------")
+	puts(" ")
+      end
+    end
+
+    utter_banner
+    # Generates a microservice
+    desc "microservice", "Generates an utter microservice project"
+    def microservice
+      microservices_quotes 
+
+      seprator
+
+      info = set_color("  INFO  ", :green, :on_white, :bold)
+      message = " e.g. api.github.com/v1/repos "
+      puts (info + message)
+
+      project_name = ask(set_color("Organization/Project Name, e.g. 'github': ", :bold))
+
+      api_version = ask(set_color("API Version, e.g. 'v1': ",:bold))
+
+      service_name = ask(set_color("Microservice Name, e.g. 'repos': ", :bold))
+      
+      seprator
+
+      path  = "./#{project_name}::#{api_version}::#{service_name}" 
+
+      params = {:path => path, :module_name => project_name, :ext_name => service_name}
+
+      generator = Utter::Generators::Microservice.new
+      generator.destination_root = path 
+
+      generator.create_microservice_directory_structure 
+      generator.create_domain_directory_structure 
+      generator.create_configru(params)
+      generator.create_gemfile(params)
+
+      #generator.create_domain_directory ({:path => path, :module_name => project_name, :ext_name => service_name})
+      #generator.invoke_all
+
+      message   = set_color "  DONE  ", :green, :on_white, :bold
+      motive = set_color " You're Awesome!" + " ", :yellow
+      say(message + motive)
+      say("run `bundle install; bundle exec rackup`")
+    end
+
+=begin
+      say("Configure SSL now?")
+      choices = ["YES","NO"]
+      choices = choices.map.with_index{ |a, i| [i+1, *a]}
+      print_table choices
+      selection = ask("Answer:", :green).to_i
+      p selection 
+=end
+
+    # Generates a domain ext 
+    desc "ext", "Generates an utter domain extension in your domain/lib/ directory"
+    def ext module_name, ext_name
+      ddd_quotes
+      params = {:path => path, :module_name => project_name, :ext_name => service_name}
+      generator = Utter::Generators::Ext.new
+      generator.create_ext params={}
+      #generator.invoke_all
+    end
+
+    # Generates a consumer domain ext to talk to other services
+    desc "consumer", "Generates an utter consumer domain extension to talk to other services in your domain/lib/ directory"
+    def consumer module_name="Consumer", ext_name
+    end
+
+    # Generates a consumer domain ext to talk to other services
+    desc "auth", "Generates an utter auth microservice"
+    def auth module_name="Consumer", ext_name
+    end
+
+  end
+end
+
+Utter::CLI.start
+#Ext.new.generate "DomainName", "Lapse"

data/bin/generators.rb

@@ -0,0 +1,93 @@
+require 'thor'
+require 'thor/group'
+
+module Utter
+  module Generators
+    # Usage
+    # generator = Utter::Generators::Microservice.new
+    # generator.destination_root = path #optional, will use current directory by default
+    # generator.invoke_all
+    class Microservice < Thor::Group
+      include Thor::Actions
+      desc 'Generate an utter microservice directory structure'
+
+      def create_microservice_directory_structure 
+	#empty_directory 'microservice'
+	empty_directory 'microservice/lib'
+	empty_directory 'microservice/spec'
+      end
+
+      def create_domain_directory_structure 
+	#empty_directory 'domain'
+	empty_directory 'domain/lib'
+	empty_directory 'domain/spec'
+      end
+
+      def create_configru params={}
+	create_file "config.ru"
+	@file = <<-FOO
+Dir[File.dirname(__FILE__) + '/microservice/**/*.rb'].each {|file| require file }                                                                                              
+Dir[File.dirname(__FILE__) + '/domain/**/*.rb'].each {|file| require file }                                                                                              
+
+map "/" do
+  run Sonopace::API::Status
+end
+
+	FOO
+
+	open("#{params[:path]}/config.ru", 'a') do |f|
+	  f.puts @file
+	end
+      end
+
+      def create_gemfile params={}
+	create_file "Gemfile"
+	@file = <<-FOO
+source 'https://rubygems.org'
+gem 'utter'
+	FOO
+
+	open("#{params[:path]}/Gemfile", 'a') do |f|
+	  f.puts @file
+	end
+      end
+
+    end
+
+    class Ext < Thor::Group
+      include Thor::Actions
+      desc 'Generate an utter domain extension'
+
+      def create_ext params={}
+	@module_name = params[:module_name].downcase
+	@ext_name = params[:ext_name].downcase
+
+	create_file "domain/lib/#{@ext_name.downcase}.rb"
+	@file = <<-FOO
+module #{@module_name.capitalize}
+  VERSION = "0.0.0"
+  class #{@ext_name.capitalize} 
+    def initialize(app, opts={}, params={})
+      @app 	= app
+      @opts 	= opts 
+      @params 	= params 
+    end
+
+    def call(env)
+      #TODO manipulate value objects, before passing to the stack!
+      @app.call(env)
+      #TODO manipulate value objects, after passing to the stack!
+    end
+  end
+end
+	FOO
+
+	open("domain/lib/#{@ext_name.downcase}.rb", 'a') do |f|
+	  f.puts @file
+	end
+      end
+
+    end
+
+  end
+end

data/bin/quotes.rb

@@ -0,0 +1,171 @@
+module Utter
+  module Quotes
+
+    def self.included(klass)
+      klass.extend self 
+    end
+
+
+
+    # Design qoutes
+    @@design_qoutes= [
+	"Good Design Is Innovative ~ Dieter Rams",
+	"Good Design Makes a Product Useful ~ ",
+	"Good Design Is Aesthetic ~ ",
+	"Good Design Is Unobtrusive ~ ",
+	"Good Design Is Honest ~ ",
+	"Good Design Is Long-lasting ~ ",
+	"Good Design Is Thorough Down to the Last Detail ~ ",
+	"Good Design Is Environmentally Friendly ~ ",
+	"Good Design Is as Little Design as Possible ~ ",
+	"Good Design Makes A Product Understandable ~ "]
+
+    # Display microservices qoutes
+    @@microservices_quotes = [
+      "Microservices are important simply because they add unique value in a way of simplification of complexity in systems.", 
+      "By breaking apart your system or application into many smaller parts, you show ways of reducing duplication, increasing cohesion and lowering your coupling between parts, thus making your overall system parts easier to understand, more scalable, and easier to change.",
+      "The downside of a distributed system is that it is always more complex from a systems standpoint. The overhead of many small services to manage is another factor to consider.", 
+      "One of the biggest problems with Microservices is the dependencies and challenges with designing services to not be all-in dependent on each other and the solutions to this."]
+
+    # Domain Driven Design qoutes
+    @@ddd_quotes = [
+      "“The indirectness of communication conceals the formation of schisms—different team members use terms differently but don’t realize it.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“The effort of translation prevents the interplay of knowledge and ideas that lead to deep model insights.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“Every software program relates to some activity or interest of its user.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“A model is a selectively simplified and consciously structured form of knowledge.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“Success comes in an emerging set of abstract concepts that makes sense of all the detail. This distillation is a rigorous expression of the particular knowledge that has been found most relevant.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“The heart of software is its ability to solve domain-related problems for its user.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“Knowledge trickles in one direction, but does not accumulate.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert’s way of thinking.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“They show design constraints, but they are not design specifications in every detail. They represent the skeletons of ideas.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“the model is not the diagram.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“The behavior of running code is unambiguous.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“documenting exclusively through code has some of the same basic problems as using comprehensive UML diagrams.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“A document shouldn’t try to do what the code already does well.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“Written documents should complement the code and the talking.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“you may hear the UBIQUITOUS LANGUAGE changing naturally while a document is being left behind.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“There is no need for explanatory models to be object models, and it is generally best if they are not.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“The astrolabe was a mechanical implementation of an object-oriented model of the sky.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“crucial discoveries always emerge during the design/implementation effort.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software",
+
+	"“The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose. When the domain is complex, this is a difficult task, calling for the concentrated effort of talented and skilled people. Developers have to steep themselves in the domain to build up knowledge of the business. They must hone their modeling skills and master domain design. Yet these are not the priorities on most software projects. Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills. Technical people enjoy quantifiable problems that exercise their technical skills. Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+	"“When we set out to write software, we never know enough.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+	"“The vital detail about the design is captured in the code. A well-written implementation should be transparent, revealing the model underlying it.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+	"“there should be some learning when a domain model is discussed.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+
+	"“The domain experts had learned more and had clarified the goal of the application.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+	"“The kind of knowledge captured in a model such as the PCB example goes beyond “find the nouns.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+
+	"“Business activities and rules are as central to a domain as are the entities involved; any domain will have various categories of concepts.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+	"“Knowledge crunching is an exploration, and you can’t know where you will end up.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software", 
+
+
+	"“Translation muddles model concepts, which leads to destructive refactoring of code.” 
+	― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software" 
+
+      ]
+
+    def method_missing(m, *args, &block)  
+      case m
+
+      when :utter_banner 
+	extend Thor::Shell
+	utter_title   = set_color " Utter ", :red, :on_white, :bold
+	utter_version = set_color Utter::VERSION + " ", :black, :on_white, :bold
+	say(utter_title + utter_version )
+
+	return # back to the calling routine	
+
+      when :about_utter
+	#say("Utter is a Domain-specific Microservices Framework written in Ruby for building both regular and advanced Rule-based web APIs")
+
+      when :ddd_quotes
+	quote = @@ddd_quotes.sample
+
+      when :design_qoutes
+	quote = @@design_quotes.sample
+
+      when :microservices_quotes 
+	quote = @@microservices_quotes.sample
+
+      else
+	puts " Utter doesn't know #{m} -- please try again."  
+      end
+
+      def wrap(s, width=75)
+	s.gsub(/(.{1,#{width}})(\s+|\Z)/, "\\1\n")
+      end
+
+      say(wrap(quote))
+    end
+
+  end
+end

data/lib/utter.rb

@@ -16,7 +16,7 @@ module Utter
   # MAJOR version when you make incompatible API changes,
   # MINOR version when you add functionality in a backwards-compatible manner, and
   # PATCH version when you make backwards-compatible bug fixes.
-  VERSION = "1.0.11"
+  VERSION = "1.0.12"
 
   $log = Logger.new(STDOUT)
 

data/samples/upjoystream::v1::torrents/Gemfile

@@ -2,4 +2,4 @@ source 'https://rubygems.org'
 ruby '2.3.1'
 
 gem 'rack'
-#gem 'utter'
+gem 'utter'

data/samples/upjoystream::v1::torrents/Gemfile.lock

@@ -1,13 +1,54 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    rack (2.0.1)
+    coderay (1.1.1)
+    ibsciss-middleware (0.4.1)
+    method_source (0.8.2)
+    minitest (5.9.1)
+    multi_json (1.12.1)
+    mushin (0.1.0)
+      ibsciss-middleware (~> 0.3)
+    pry (0.10.4)
+      coderay (~> 1.1.0)
+      method_source (~> 0.8.1)
+      slop (~> 3.4)
+    puma (3.6.0)
+    rack (1.6.4)
+    rack-protection (1.5.3)
+      rack
+    rack-test (0.6.3)
+      rack (>= 1.0)
+    rake (11.3.0)
+    sinatra (1.4.7)
+      rack (~> 1.5)
+      rack-protection (~> 1.4)
+      tilt (>= 1.3, < 3)
+    sinatra-cross_origin (0.3.2)
+    sinatra-json (0.1.0)
+      multi_json (~> 1.0)
+      sinatra (~> 1.0)
+    slop (3.6.0)
+    thor (0.19.1)
+    tilt (2.0.5)
+    utter (1.0.11)
+      bundler
+      minitest
+      mushin
+      pry
+      puma
+      rack-test
+      rake
+      sinatra
+      sinatra-cross_origin
+      sinatra-json
+      thor
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
   rack
+  utter
 
 RUBY VERSION
    ruby 2.3.1p112

data/samples/upjoystream::v1::torrents/config.ru

@@ -7,10 +7,19 @@
 #require 'bundler/setup'
 #Bundler.require(:default)
 
-#require 'utter'
-require_relative './../../lib/utter'
-Dir[File.dirname(__FILE__) + 'domain/lib/*.rb'].each {|file| require file }
-Dir[File.dirname(__FILE__) + 'microservice/lib/*.rb'].each {|file| require file }
+require 'utter'
+#require_relative './../../lib/utter'
+#
+Dir["domain/lib/**/*.rb"].each do |file| 
+  p file
+  require_relative file 
+end
+
+Dir["microservice/lib/**/*.rb"].each do |file| 
+  p file
+  require_relative file 
+end
+
 
 map('/') do
   run API::V1::Torrents

data/samples/upjoystream::v1::torrents/microservice/lib/app.rb

@@ -7,6 +7,9 @@ module API
       get '/' do
 	"public info"
 	"private info (eyes only)"
+	Utter::Stack.new do 
+	  use Echo, "this is my message"
+	end
       end
       #run! if app_file == $0
     end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: utter
 version: !ruby/object:Gem::Version
-  version: 1.0.11
+  version: 1.0.12
 platform: ruby
 authors:
 - zotherstupidguy
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2016-10-02 00:00:00.000000000 Z
+date: 2016-10-04 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: pry
@@ -329,15 +329,15 @@ extra_rdoc_files: []
 files:
 - ".gitignore"
 - ".travis.yml"
-- CODE_OF_CONDUCT.md
 - Gemfile
-- LICENSE.txt
 - README.md
 - Rakefile
+- bin/cli.rb
 - bin/console
-- bin/scaffold.rb
+- bin/generators.rb
+- bin/highline.rb
+- bin/quotes.rb
 - bin/setup
-- bin/templates/README.md
 - lib/internals/core/auth.rb
 - lib/internals/core/microservice.rb
 - lib/internals/core/service_discovery.rb

data/CODE_OF_CONDUCT.md

@@ -1,49 +0,0 @@
-# Contributor Code of Conduct
-
-As contributors and maintainers of this project, and in the interest of
-fostering an open and welcoming community, we pledge to respect all people who
-contribute through reporting issues, posting feature requests, updating
-documentation, submitting pull requests or patches, and other activities.
-
-We are committed to making participation in this project a harassment-free
-experience for everyone, regardless of level of experience, gender, gender
-identity and expression, sexual orientation, disability, personal appearance,
-body size, race, ethnicity, age, religion, or nationality.
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery
-* Personal attacks
-* Trolling or insulting/derogatory comments
-* Public or private harassment
-* Publishing other's private information, such as physical or electronic
-  addresses, without explicit permission
-* Other unethical or unprofessional conduct
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-By adopting this Code of Conduct, project maintainers commit themselves to
-fairly and consistently applying these principles to every aspect of managing
-this project. Project maintainers who do not follow or enforce the Code of
-Conduct may be permanently removed from the project team.
-
-This code of conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community.
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting a project maintainer at zotherstupidguy@gmail.com. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. Maintainers are
-obligated to maintain confidentiality with regard to the reporter of an
-incident.
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 1.3.0, available at
-[http://contributor-covenant.org/version/1/3/0/][version]
-
-[homepage]: http://contributor-covenant.org
-[version]: http://contributor-covenant.org/version/1/3/0/

data/LICENSE.txt

@@ -1,21 +0,0 @@
-The MIT License (MIT)
-
-Copyright (c) 2016 zotherstupidguy
-
-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.

data/bin/templates/README.md

@@ -1,7 +0,0 @@
-This directory contains common microservice templates
-- auth microservice template
-- logging microservice template
-- admin microservice template
-
-- User generate a template and specifiy certain attr to customize the template to their own needs.
-- User then use/further developm the generated microservice.