eventbox 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 06556e4ddd4d9ccd8cfede0c2163dd164165bdf6585d6a3352a1f44b7d17ff67
+  data.tar.gz: 6532937e73f20e42808a5516699781ed95284fc1cc52e0d160b443239e690fd6
+SHA512:
+  metadata.gz: 69dd49a9e166760c2cb7487ef5560ed92a59b68eaf4702dbf08dcab93751ae8bfc2f271f387eae0822b4798f60f8eff7cd644ecf63fd765bf10b42758c37e8ac
+  data.tar.gz: 66d26b6bf6dcac3954273b216261e576cbd62aec7b8c208eec55b84fd87fe3e1a1b452884cf8a97e2ef772c34020d48d0596ed1483e755a630aace852c7a20e1

checksums.yaml.gz.sig

@@ -0,0 +1 @@
+d<]]�oF�5�t>�

data/.appveyor.yml

@@ -0,0 +1,28 @@
+build: off
+
+init:
+  - set PATH=C:/Ruby%ruby_version%/bin;%PATH%
+  - set RUBYOPT=--verbose -Eutf-8 --enable-frozen-string-literal
+
+install:
+  - ps: |
+      if ($env:RUBYDOWNLOAD -ne $null) {
+        $(new-object net.webclient).DownloadFile("https://github.com/oneclick/rubyinstaller2/releases/download/rubyinstaller-head/rubyinstaller-head-$env:RUBYDOWNLOAD.exe", "$pwd/ruby-setup.exe")
+        cmd /c ruby-setup.exe /verysilent /dir=C:/Ruby$env:ruby_version
+      }
+  - ruby --version
+  - gem --version
+  - gem install bundler --conservative
+  - bundle install
+
+test_script:
+  - bundle exec rake test TESTOPTS=-v
+
+environment:
+  matrix:
+    - ruby_version: "head"
+      RUBYDOWNLOAD: x64
+    - ruby_version: "head"
+      RUBYDOWNLOAD: x86
+    - ruby_version: "24-x64"
+    - ruby_version: "24"

data/.gitignore

@@ -0,0 +1,8 @@
+/.bundle/
+/.yardoc
+/_yardoc/
+/coverage/
+/doc/
+/pkg/
+/spec/reports/
+/tmp/

data/.travis.yml

@@ -0,0 +1,16 @@
+---
+sudo: false
+language: ruby
+cache: bundler
+matrix:
+  fast_finish: true
+  include:
+    - rvm: 2.3.8
+    - rvm: 2.5.3
+      env: RUBYOPT=--verbose --enable-frozen-string-literal
+    - rvm: jruby-9.2.4.1
+    - rvm: ruby-head
+      env: RUBYOPT=--verbose --enable-frozen-string-literal
+
+script:
+  - bundle exec rake test TESTOPTS=-v

data/.yardopts

@@ -0,0 +1,9 @@
+--readme README.md
+--title "Eventbox"
+--protected
+--private
+--no-private
+--embed-mixin Eventbox::Boxable
+lib/**/*.rb
+-
+docs/**/*.md

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+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.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at kanis@comcard.de. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/Gemfile

@@ -0,0 +1,10 @@
+source "https://rubygems.org"
+
+git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
+
+# Specify your gem's dependencies in eventbox.gemspec
+gemspec
+
+group :test do
+  gem 'simplecov', require: false
+end

data/LICENSE.txt

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2018 Lars Kanis
+
+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/README.md

@@ -0,0 +1,381 @@
+[![Build Status Linux](https://travis-ci.com/larskanis/eventbox.svg?branch=master)](https://travis-ci.com/larskanis/eventbox)
+[![Build status Windows](https://ci.appveyor.com/api/projects/status/tq397g0gfke1mcud/branch/master?svg=true)](https://ci.appveyor.com/project/larskanis/eventbox/branch/master)
+
+# Eventbox
+
+_Manage multithreading with the safety of event based programming_
+
+{Eventbox} objects are event based and single threaded from the inside but thread-safe and blocking from the outside.
+Eventbox enforces a separation of code for event processing and code running blocking operations.
+Code inside an {Eventbox} object is executed non-concurrently and hence shouldn't do any blocking operations.
+This is similar to the typical JavaScript programming style.
+
+On the other hand all blocking operations can be executed in action threads spawned by the {Eventbox.action action} method type.
+Communication between actions and event processing is done through ordinary method or lambda calls.
+
+An important task of Eventbox is to avoid race conditions through shared data.
+Such data races between event scope and external/action scope are avoided through {Eventbox::Sanitizer filters} applied to all inputs and outputs.
+That way {Eventbox} guarantees stable states while event processing without a need for any locks.
+
+Eventbox is a model of concurrent computation that is used to build thread-safe objects with arbitrary interfaces.
+It is kind of [advancement](#comparison-threading-abstractions) of the well known [actor model](https://en.wikipedia.org/wiki/Actor_model) leveraging the possibilities of the ruby language.
+
+* [API documentation](https://www.rubydoc.info/github/larskanis/eventbox/master)
+
+
+## Requirements
+
+* Ruby-2.3 or newer or
+* JRuby 9.1 or newer
+
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+```ruby
+gem 'eventbox'
+```
+
+And then execute:
+
+    $ bundle
+
+Or install it yourself as:
+
+    $ gem install eventbox
+
+
+## Usage
+
+{Eventbox} is an universal approach to build thread-safe objects.
+It can therefore be used to build well known multithread abstractions like a Queue class:
+
+```ruby
+require "eventbox"
+class Queue < Eventbox
+  # Called at Queue.new just like Object#initialize in ordinary ruby classes
+  async_call def init
+    @que = []       # List of values waiting for being fetched by deq
+    @waiting = []   # List of blocking deq calls waiting for new values to be pushed by enq
+  end
+
+  # Push a value to the queue and return the next value by the next waiting deq call
+  async_call def enq(€value)  # €-variables are passed through as reference
+    @que << €value            # Push a value to the queue
+    if w=@waiting.shift
+      w.yield @que.shift      # Let one waiting deq call return with the next value from the queue
+    end
+  end
+
+  # Fetch a value from the queue or suspend the caller until a value has been enqueued
+  yield_call def deq(result)
+    if @que.empty?
+      @waiting << result      # Don't return a value now, but enqueue the request as waiting
+    else
+      result.yield @que.shift # Immediately return the next value from the queue
+    end
+  end
+end
+```
+It has semantics like ruby's builtin Queue implementation:
+
+```ruby
+q = Queue.new
+Thread.new do
+  5.times do |i|
+    q.enq i      # Enqueue integers 0 to 5
+  end
+end
+
+5.times do
+  p q.deq        # Fetch and print 5 integers from the queue
+end
+
+# It gives the following output:
+0
+1
+2
+3
+4
+```
+
+Although there are no mutex or condition variables in use, the implementation is guaranteed to be thread-safe.
+The key feature is the {Eventbox.yield_call} method definition.
+It divides the single external call into two internal events: The event of the start of call and the event of releasing the call with a return value.
+In contrast {Eventbox.async_call} defines a method which handles one event only - the start of the call.
+The external call returns immediately, but can't return a value.
+
+Seeing curly braces instead of links? Switch to the [API documentation](https://www.rubydoc.info/github/larskanis/eventbox/master).
+
+The branch in `Queue#deq` shows a typical decision taking in Eventbox:
+If the call can be processed immediately it yields the result, else wise the result is added to a list to be processes later.
+It's important to check this list at each event which could signal the ability to complete the enqueued processing.
+This is done in `Queue#enq` in the above example.
+
+If you just need a queue it's better to stay at the Queue implementations of the standard library or [concurrent-ruby](https://github.com/ruby-concurrency/concurrent-ruby).
+However if you want to cancel items in the queue for example, you need more control about waiting items or waiting callers than common thread abstractions offer.
+The same if you want to query and visualize the internal state of processing - that means the pending items in the queue.
+
+
+### Hands on
+
+The following examples illustrate most important aspects of Eventbox.
+It is recommended to work them through, in order to fully understand how Eventbox can be used to implement all kind of multi-threaded applications.
+
+* {file:docs/downloads.md HTTP client} - Understand how to use actions to build a HTTP client which downloads several URLs in parallel.
+* {file:docs/server.md TCP server} - Understand how to startup and shutdown blocking actions and to combine several Eventbox classes to handle parallel connections.
+* {file:docs/threadpool.md Thread-pool} - Understand how parallel external requests can be serialized and scheduled.
+
+
+## Method types
+
+### Event Scope
+
+Eventbox offers 3 different types of external callable methods:
+
+* {Eventbox.yield_call yield_call} defines a blocking or non-blocking method with return value.
+  It is the most flexible call type.
+* {Eventbox.sync_call sync_call} is a convenience version of `yield_call` for a non-blocking method with return value.
+* {Eventbox.async_call async_call} is a convenience version of `yield_call` for a non-blocking method without return value.
+
+They can be defined with `private`, `protected` or `public` visibility.
+The method body is referred to as "event scope" of a given Eventbox object.
+Code in the event scope is based on an event driven programming style where events are signaled by method calls or by callback functions.
+
+The event scope shouldn't be used to do blocking operations.
+There is no hard criteria for what is considered a blocking operation, but since event scope methods of one object don't run concurrently, it decreases the overall responsiveness of the Eventbox instance.
+If the processing time of an event scope method or block exceeds the limit of 0.5 seconds, a warning is print to `STDERR`.
+This limit can be changed by {Eventbox.with_options}.
+
+Arguments of async, sync and yield calls can be prefixed by a € sign.
+This marks them as to be passed through as reference, instead of being copied.
+A €-variable is wrapped and protected within the event scope, but unwrapped when passed to action or external scope.
+
+In additoin there are accessor methods usable as known from ordinary ruby objects: {Eventbox.attr_reader attr_reader},  {Eventbox.attr_writer attr_writer} and  {Eventbox.attr_accessor attr_accessor}.
+They allow thread-safe access to instance variables.
+
+Beside {Eventbox.async_call async_call}, {Eventbox.sync_call sync_call} and {Eventbox.yield_call yield_call} methods it's possible to define plain `private` methods, since they are not accessible externally.
+However any plain `public` or `protected` methods within Eventbox classes are rejected.
+
+Seeing curly braces instead of links? Switch to the [API documentation](https://www.rubydoc.info/github/larskanis/eventbox/master).
+
+### Action Scope
+
+{Eventbox.action Action} methods are very different from the above.
+They run concurrently to all event scope methods within their own thread.
+Although actions reside within the same class they don't share instance variables with the event scope.
+However they can safely call all instance methods.
+The method body is referred to as "action scope".
+
+Eventbox doesn't provide specific methods for asynchronous IO, but relies on ruby's builtin methods or gems for this purpose.
+The intention is, that IO or any other blocking calls are done through {Eventbox.action action} methods.
+In contrast to event scope, they should not share any data with other actions or threads.
+Instead a shared-nothing approach is the recommended way to build actions.
+That means, that all data required for one particular action call, should be passed as arguments, but nothing more.
+And all data generated by the action should be passed as arguments back to event scope methods and the outcome should be managed there.
+
+Some data shall just be managed as reference in some scope without being accessed there.
+Or it is passed through a given scope only.
+In such cases it can be marked as {Eventbox#shared_object shared_object}.
+This wrapping is similar to € argument variables, however {Eventbox#shared_object shared_object} it more versatile.
+It marks objects permanently and wraps them even when they are stored inside of a copied object.
+
+### External scope
+
+Code outside of the Eventbox class is referred to as "external scope".
+
+
+## Block and Proc types
+
+Similary to the 3 method calls above there are 3 types of proc objects which act as anonymous counterparts of the method call types.
+
+* {Eventbox#yield_proc yield_proc} allocates a blocking or non-blocking proc object with a return value.
+  It is the most flexible proc type.
+* {Eventbox#sync_proc sync_proc} is a convenience version of yield_proc for a non-blocking code block with return value.
+* {Eventbox#async_proc async_proc} is a convenience version of yield_proc for a non-blocking code block without return value.
+
+These proc objects can be created within event scope, can be passed to external scope and called from there.
+
+Arguments of async, sync and yield procs can be prefixed by a € sign.
+In that case, they are passed as reference, equally to €-variables of {Eventbox.async_call async_call}, {Eventbox.sync_call sync_call} and {Eventbox.yield_call yield_call} methods.
+
+The other way around - Proc objects or blocks which are defined in external or action scope - can be passed to event scope.
+Such a Proc object is wrapped as a {Eventbox::ExternalProc} object within the event scope.
+There it can be called as usual - however the execution of the proc doesn't stall the Eventbox object.
+Instead the event scope method is executed until its end, while the block is executed within the thread which has called the current event scope method.
+Optionally the block can be called with a completion block as the last argument, which is called with the result of the external proc when it has finished.
+
+
+## Exceptions
+
+Eventbox makes use of exceptions in several ways.
+
+All exceptions raised within the event scope are passed to the internal or external caller, like in ordinary ruby objects.
+It's also possible to raise deferred exceptions through the result proc of a {Eventbox#yield_call yield_call} or {Eventbox#yield_proc yield_proc}.
+See the {Eventbox::CompletionProc#raise} method.
+
+Exceptions raised in the action scope are not automatically passed to a caller, but must be handled appropriately by the Eventbox instance.
+It is recommended to handle exceptions in actions similar to the following, unless you're very sure, that no exception happens:
+
+```ruby
+action def start_connection(host, port)
+  sock = TCPSocket.new(host, port)
+rescue => err
+  conn_failed(err)
+else
+  conn_succeeded(sock)
+end
+
+async_call def conn_succeeded(sock)
+  # handle the success event (e.g. start communication by another action)
+end
+
+async_call def conn_failed(error)
+  # handle the failure event (retry or similar)
+end
+```
+
+Another use of exceptions is for sending signals to running actions.
+This is done by {Eventbox::Action#raise}.
+
+
+## What is safe and what isn't?
+
+At each transition of the scope all passing objects are sanitized by the {Eventbox::Sanitizer}.
+It protects the event scope from data races and arbitrates between blocking and event based semantics.
+This is done by copying or wrapping the objects conveniently as described in the {Eventbox::Sanitizer}.
+That way event scope methods never get an inconsistent state regardless of the activities of external threads.
+
+Obviously it's not safe to do things like using `send` to call private methods from external, access instance variables per `instance_variable_set` or use global variables in a multithreading context.
+Such rough ways of communication with an Eventbox object are surely neither recommended nor supported.
+Other than these the event scope of an Eventbox instance is pretty well protected against accident mistakes.
+
+However there's a catch which needs to take note of:
+It is not restricted to access any constants from event scope.
+Therefore it's possible to call for example `Thread.new` within the event scope.
+Unsurprisingly is a very bad idea, since the provided block is called with no synchronization and can therefore lead to all kind of threading issues.
+It would be safe to call `Thread.new` with an {Eventbox#async_proc async_proc}, however since the proc is not allowed to do any blocking operations, it's recommended to use an {Eventbox.action action} method definition instead to spawn threads.
+
+Also note that Eventbox doesn't protect external scope or action scope from threading issues.
+The external scope is recognized as one common space.
+External libraries and objects must be thread-safe on its own if used from different threads in external or action scope.
+Protecting them is beyond the scope of Eventbox.
+
+
+## Time based events
+
+It's possible to generate a timer event by stating an action with a `sleep` and subsequent call to an {Eventbox.async_call async_call} method.
+However that's not very convenient.
+Therefore Eventbox provides a dedicated {Eventbox::Timer timer module} for simple timer functions.
+It can be included into Eventbox classes by:
+
+```ruby
+  include Eventbox::Timer
+```
+
+It offers {Eventbox::Timer#timer_after} and {Eventbox::Timer#timer_every} functions to schedule blocks to be called.
+
+
+## Derived classes and mixins
+
+Eventbox classes can be derived like ordinary ruby classes - there are no restrictions specific to Eventbox.
+Methods of base classes can be called by `super`.
+All classes of the hierarchy share the same instance variables like ordinary ruby objects.
+Only {Eventbox.action action} methods use their own variable space.
+
+It's also possible to mix a module into the Eventbox class.
+See the description of {Eventbox::Boxable} for how it works.
+
+
+## When to use Eventbox?
+
+Eventbox comes into play when things are getting more complicated or more customized.
+For instance a module which shall distribute work orders to external processes.
+When it shall visualize the progress and allow cancellation of orders, available abstractions don't fit well to the problem.
+
+In such a case Eventbox helps to manage a consistent state about these running activities.
+It also allows to query this state in a natural way, since states can be stored in plain ruby objects (arrays, hashs, etc) instead of specialized thread abstractions.
+
+While not impossible to implement things per raw threads, mutexes and condition variables, it's pretty hard to do that right.
+There are no tools to verify correct usage of mutexes or other threading abstractions in ruby.
+However threading errors are subtle, so you'll probably not notice mistakes, until going to production.
+
+Due to Eventbox's checks and guaranties it's easier to verify and prove correctness of implementations running on top of it.
+This was the primary motivation to develop this library.
+
+
+<a name="comparison-threading-abstractions"></a>
+## Comparison with other threading abstractions
+
+### The Actor model
+
+Eventbox is kind of advancement of the well known [actor model](https://en.wikipedia.org/wiki/Actor_model) leveraging the possibilities of the ruby language.
+While the actor model uses explicit message passing, Eventbox relies on method calls, closure calls and exceptions, which makes it much more natural to use.
+Unlike an actor, Eventbox doesn't start a thread per object, but uses the thread of the caller to execute non-blocking code.
+This makes instantiation of Eventbox objects cheeper than Actor objects.
+Instead it can create and manage in-object private threads in form of {Eventbox.action actions} to be used for blocking operations.
+
+Many actor implementations manage an inheritance tree of actor objects.
+Parent actors are then notified about failures of child actors.
+In contrast Eventbox objects maintain a list of all running internal actions instead, but are completely independent from each other.
+Failures are handled object internal - see chapter "Exceptions" above.
+
+### Internal state
+
+Eventbox keeps all instance variables in a consistent state as a whole.
+This is an important difference to [thread-safe collections](https://github.com/ruby-concurrency/concurrent-ruby#thread-safe-value-objects-structures-and-collections) like `Concurrent::Hash`.
+They mislead the developer to believe that a module is thread-safe when it's just using these classes.
+
+Unfortunately this is often wrong: They require a lot of experience to avoid mistakes through non-atomic updates, non-atomic test-and-set operations or race-conditions through using several thread-safe objects in combination (although a consistent state is only managed on a per object base).
+
+### Data races
+
+Most thread abstractions don't do deeper checks for wrong usage of data.
+In particular they don't protect from data races like Eventbox does.
+Ruby doesn't (yet) have mechanisms to bind objects to threads, so that there's no builtin safety.
+
+### Blocking and non-blocking scope
+
+Beside this, Eventbox has an explicit specification where blocking and where non-blocking code has to be executed and the compliance is monitored.
+This ensures that events are processed in time regardless of the current state.
+Such a specification is not enforced by most other threading abstractions and can quickly lead to delayed reactions in particular situations.
+
+
+## Comparison with other async libraries
+
+Eventbox doesn't try to implement IO or other blocking operations on top of a global event loop.
+Instead it encourages the use of blocking operations and threads for things which should run in parallel, while keeping the management code in safe internal methods written in an event based style.
+Because IO is done in action threads, the only type of events handled by the event scope are method calls received from actions or external calls.
+They are processed by a kind of event loop which runs one per Eventbox object.
+
+This is in contrast to libraries like [async](https://github.com/socketry/async), [EventMachine](https://github.com/eventmachine/eventmachine) or [Celluloid](https://github.com/celluloid/celluloid) which provide dozens of IO wrappers.
+
+
+## Eventbox performance
+
+Eventbox is reasonably fast, but far from the performance of low level threading primitives (like implemented in [concurrent-ruby](https://github.com/ruby-concurrency/concurrent-ruby) ).
+It is not written to minimize resource consumption or maximize performance or throughput.
+Instead it is written to minimize race conditions and implementation complexity in a multithreaded environment.
+And it is written to act as a solid and consistent foundation for a wide range of concurrent computation problems.
+
+So if your use case requires raw performance more than implementation safety, Eventbox is probably not the right tool.
+
+Still there is lots of room for performance improvements in Eventbox, like faster method invocations or copy-on-write objects.
+If there's a stronger interest in Eventbox performance, it's possible to source relevant parts out to a C extension.
+The introduction of guilds in ruby will probably be helpful for Eventbox as well.
+
+
+## Contributing
+
+Bug reports and pull requests are welcome on GitHub at https://github.com/larskanis/eventbox. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
+
+
+## License
+
+The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
+
+
+## Code of Conduct
+
+Everyone interacting in the Eventbox project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/larskanis/eventbox/blob/master/CODE_OF_CONDUCT.md).