wiki.ziemers.de

ziemer's informatik Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen:
wiki:software:beuthbot:deconcentrator

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung 		Vorhergehende Überarbeitung
wiki:software:beuthbot:deconcentrator [23.01.2020 10:43]
Timo Bruns 		wiki:software:beuthbot:deconcentrator [19.05.2020 21:52] (aktuell)
Jan Fromme
Zeile 4: Zeile 4:
  
 ==== Table Of Content ==== ==== Table Of Content ====
 +   - [[wiki:software:beuthbot:deconcentrator#deconcentrator|Deconcentrator]]
 +   - [[wiki:software:beuthbot:deconcentrator#table_of_content|Table of content]]
 +   - [[wiki:software:beuthbot:deconcentrator#scope|Scope]]
 +   - [[wiki:software:beuthbot:deconcentrator#how-to|How To]]
 +   - [[wiki:software:beuthbot:deconcentrator#authors|Authors]]
 +
  
 ==== scope ====  ==== scope ==== 
 +be a common endpoint for various nlu providers:
 +
 +- [[https://rasa.com/docs/rasa/|RASA]]
 +
 +others aren't implemented yet, but implementation should be trivial: 
 +
 +- [[https://azure.microsoft.com/de-de/services/cognitive-services/language-understanding-intelligent-service/|Microsoft LUIS]]\\
 +- [[https://cloud.google.com/natural-language/|Google Cloud NLU]]\\
 +- [[https://www.ibm.com/watson/services/natural-language-understanding/|IBM Watson NLU]]\\
  
 ==== principles ====  ==== principles ==== 
  
 === important frameworks/software pieces === === important frameworks/software pieces ===
 +- [[https://nginx.org|nginx]]: reverse proxy (static files) and uwsgi gateway 
 +- [[https://pypi.org/project/uWSGI/|uWSGI]]: wsgi implementation 
 +- [[https://www.django-rest-framework.org/|Django REST framework]]: REST interfaces, viewsets, generic serialization  
 +    logic etc. 
 +- [[https://www.djangoproject.com/|Django]]: "The web framework for perfectionists with deadlines."  
 +- [[https://docs.celeryproject.org/|Celery]]: Distributed task queue for delegating I/O tasks (like doing web requests) 
 +- [[https://www.rabbitmq.com/|RabbitMQ]]: async task queue itself 
 +- [[https://redis.io/|redis]]: django cache, session cache, celery result backend 
 +- [[https://memcached.org/|memcached]]: django cache. 
 +- [[https://www.postgresql.org/|PostgreSQL]]: database backend.
 === important models === === important models ===
 +
 +- `Method`: the abstraction of a function to retrieve an actual NLU processing result.
 +- `Provider`: the actual provider, which is doing some kind of NLU processing. 
 +- `Strategy`: how to select a `Provider` for a specific `Objective`
 +- `Objective`: kind of a task that has to be done. It's the main entry-point, user-supplied. It contains the actual 
 +    payload which has to be NLU processed and selects an strategy.
 +- `Job`: the `Strategy` creates jobs from an `Objective`. Each job then has a specific `Provider` to use for processing.
 +- `Result`: the outcome of asking a `Provider`.
  
 === implementation details === === implementation details ===
 +
 +- `Objective`, `Job` and `Result` make use of non-abc-dispatching (i. e. dispatching without a common abstract base 
 +    class). That means:
 +    - they have a common method with equal signature called `execute()` and are connected to the same `post_save` 
 +        handler.
 +    - once an object of one of these classes is `save`d, the `post_save` hook will call that common method. 
 +    - that method, then, calls the `Strategy` model method for further handling.
 +    - to avoid infinite recursion, one has to avoid calling `save()` within the `Strategy` method, instead using the 
 +        `<Model>.objects.filter(...).update(...)`-approach
 +- the `ViewSet`s design:
 +    - `Method`s, `Strategy`s, `Job`s and `Result`s can only be read
 +    - `Provider`s can be CRUD on demand. 
 +    - `Objective`s can be created and retrieved, but not updated or deleted.
  
 ==== how-to ==== ==== how-to ====
  
-==== Versioning ====+The project contains multiple `docker-compose` files; therefore, basically you only have to `docker-compose up` the  
 +project.  
 + 
 +- You need to build the deconcentrator image in the directory that holds the Dockerfile. 
 +    docker build -t deconcentrator:latest . 
 +- You can use the `management.sh` script to create the required secret files: `./management.sh prepare`; they are required to start the containers. 
 + 
 +- You will probably want to create a sym-link named `docker-compose.override.yml` to export the nginx port to the public  
 +    ln -s docker-compose.production.yml docker-compose.override.yml 
 +- You will probably want to run the migrations; basically it's a `./manage.py migrate` call, which can be done via  
 +    ./management.sh exec uwsgi /mnt/deconcentrator/manage.py migrate 
 +- To access the admin interface, you'll have to create a superuser account first:  
 +    ./management.sh exec uwsgi /mnt/deconcentrator/manage.py createsuperuser 
 + 
  
  
 ==== Authors ==== ==== Authors ====
 +
 +
 + **Kai Nessig** - //Initial work// - [[https://github.com/tiberius|GitHub]]
 +
 +See also the list of [[https://github.com/beuthbot/deconcentrator/graphs/contributors]] who participated in this project.
 +<WRAP pagebreak></WRAP>
wiki/software/beuthbot/deconcentrator.1579772602.txt.gz · Zuletzt geändert: 23.01.2020 10:43 von Timo Bruns

Seiten-Werkzeuge