DEV Community: Ben Klein

Habitie.net Dev Update #2

Ben Klein — Tue, 19 Jan 2021 15:43:13 +0000

Welcome to the second Dev Update Post from the Habitie.net Team 🙂

Yes, I told you these posts will come every month now. And no, we couldn't keep up with that ☹️

Which leads us to the main topic of this dev update post: The struggle of keeping up the pace in a spare time project while we all have our main jobs, families, hobbies and other stuff.

We have 5 people in our team currently. Each one respective with a main job, life and appointments. We have a team meeting every two weeks where we discuss current topics and plan our sprints. Our sprints last 1 month and include a planning, issues, board, review and retrospective. We're very SCRUM inspired but don't use everything from that toolbox.

However the progress we have is very low currently due to the fact, that we can't work full time on the project and Habitie often loses the priority fight against other important things in our lives. Over the years we learned some lessons about how to keep up the progress and how to get something done on the project. We want to share those lessons with you here.

We keep our issues as small as possible and organize them in epics. Also we include all the important information with each issue to keep them independent and clear. That helps to quickly get into a topic and tackle it.
We have a well documented and working setup guide for our repositories to enable every developer to get the project up and running without struggle or time loss.
We have regular meetings and work in sprints to keep up the motivation and feedback cycles.
We posts any progress we achieve in our team slack channel. It motives to see when other people on the team get something done.
We encourage our team members to do small steps. You don't have to immediately finish the whole issue. Small and slow steps are good as long as they bring you in the right direction.
We recommend not to "drop out" from the project. When you don't do anything for 4 weeks and then come back to work on the project you don't have any idea what's going on, where you left your code, what you're doing or who you are, then you're lost and it takes some energy and time to get back into the project after this. Thus we recommend to do something everyday even if it's just starting the server and clicking around. This will help to stay in touch with the codebase and the project.
We understand that motivation is fugitive. So when you're inspired by something and you want to build somewhat amazing because you're burning for it, then do it! This will keep up the motivation and fun in the project. It's not about tackling one by one boring bug issue but it's about having fun and learning together.

We're planning to introduce further changes and ideas to improve the motivation of the team even more and to increase the progress on the project in the future. Thus we're searching vor new developers to get on the project and we think about publishing the code as OpenSource to get the community on board.

Do you have any experience with spare time projects? Any suggestions or ideas? Share it with us, we're happy to hear from you 🙂

Photo by Danielle MacInnes.

Habitie.net Dev Update #1

Ben Klein — Fri, 17 Jul 2020 09:20:47 +0000

Aloha guys! 🎉

I had this idea of Dev Updates for my passion project some time ago, but for some reason I had some doubts. "Is this even interesting?" or "Will they blame me?" and so on. Then I recently published my article about UseCases as Rails Architecture with more or less the same doubts and the reaction of the people was awesome. Thank you so much! ❤️

So I learned, that DEV.to is an exceptional kind community of nice people who are sharing stuff, giving constructive feedback and encourage each other. And I think that's amazing 😍

So here we are: This is the first Dev Update post of a hopefully long chain of posts in which I want to update you folks about the development state of habitie.net.

The Idea

First of all, what is this all about?

I use lots of apps to organize my life, my work, my motivation and whatever. Wunderlist, Trello, Habitica, Evernote, Google Calendar, and much more. I really love the idea of Habitica. But for some reason it never really helped me in a long term. I started to collect ideas and concepts of how a app have to be so it can help me to achieve my goals, track my todos, organize my stuff and everything. At some point I had enough and started coding some stuff in my spare time. I called it habitie.

The idea is to have an app with minimal gamification, where you can track your goals, define tasks, recurring tasks and habits. A habit can be negative (like smoking), positive (like doing the laundry) or both. Ticking a task or a habit gives you karma. Karma because I like the concept. You do something good (for your life or for others) and something good will come back around. Karma works like experience and you have a experience level like you know it from video games. Also you can define rewards which have a drop chance based on their rarity. Habits and Tasks have a difficulty. This together defines a drop chance for your rewards. Doing simple tasks will probably not drop the super rare epic reward (maybe a vacation or that new gaming pc you wish for), but doing the difficult habits will probably will. This way I want to bring my impulsive buying behavior under control, I think. However it motivates me we stuff I want to have is coupled with tasks I have to do. There also some builtin items, which work like buffs and give you some in-app advantage. That's the basic idea behind habitie. Besides that we have plenty of awesome concepts, ideas and features we want to add to make habitie an app which helps you to organize your life. Checklists, Boards, Notes, Integrations and so on. Stay tuned! 😁

The Team

Eventually I gathered some really nice people around me to help me to build this SaaS product. Now we're a team of 5 germany and austria based dudes. Including 3 developers, a designer and a psychologist. Together we're working on this passion project in our spare time. Despite we're following a professional approach on the project. Thus we're working with the agile method, Boards, professional tool chain like InVision, GitLab, Heroku, Sentry and so on. We have regular meetings every two weeks to coordinate, talk about current topics and plan our sprints.

Despite we have some really great ideas and so much on our to do list, it's difficult to keep up the pace. A passion project on which we're all working on in our spare time is struggling with the huge time effort which software development brings with it. So team growth is currently one of our highest priorities.

The MVP

However we have built a MVP, which you can find on https://www.habitie.net

It doesn't still contain all the basic features and sure still have some bugs, but it's a good point to start from. Feel free to give it a try and share your feedback and ideas 😄

Currently we're working on a new fancy UX, the mobile app and rounding up the basic features so we can tackle the great stuff on our idea list.

I want to update you on a weekly basis and hope to find some early adopters for the app.

When you have questions, don't hesitate to ask. When you have feedback, please share with us. And when you want to work with us, please contact me and we'll find a way 😄

Have a good time folks!

Cover image by Sean Stratton

Pimp your Rails Application

Ben Klein — Wed, 01 Jul 2020 12:36:24 +0000

Hi DEV community!

Today I want to share something with you folks I've been waiting for weeks now but was to busy to write 😁

It's about the question "How to structure rails applications".

Finding a good and maintainable structure for large rails applications can be challenging. When you don't have a good approach, you'll end up with fat controllers and even fatter models. You keep on coding and at some point you'll lose the overview and have to maintain a spaghetti (code) monster.

Rails already comes with some features to extract code from your controllers, models and views by using concerns, helpers and so on. This is nice but far not enough.

Over the years I used a bunch of different approaches in a bunch of different rails apps. Starting with simple lib classes, tried Trailblazer, different gems and stuff. Finally I found a robust solution how to structure my apps to keep them clean, DRY, testable and maintainable: UseCases and Services (and Behaviors).

Recently I've took alle the code which I have grown over the last 2 years and published it as a gem. Think of it as the framework and support for UseCases, Services and Behaviors.

RailsUseCase gem

Enough talked, let's dip into my take on UseCases, Services and how this gem helps you to write them without boilerplate code.

For that purpose I distinguish between two types of code: low-level technical code and high-level business logic. Services are for low-level code. UseCases for business logic. Pretty simple.

Now let's see what that even means ...

Services for Low Level Code

Services are simple ruby classes which contain non-domain logic for low level, technical stuff. For example downloading a file from a FTP server, communication with an API, CSV generation, attaching a webcam image to a record, whatever.

Services are placed in the app/services directory and should be named like csv_generation_service.rb.

A example service could look like this:

class PDFGenerationService < Rails::Service
  attr_reader :pdf_template, :values

  # Constructor.
  def initialize
    super 'pdf_generation'
    prepare
    validate_libreoffice
  end


  # Entry point.
  #
  # @param [PdfTemplate] pdf_template PdfTemplate record.
  # @param [Hash<String, String>] values Mapping of variables to their values.
  #
  # @returns [String] Path to PDF file.
  def call(pdf_template, values = {})
    @pdf_template = pdf_template
    @values = prepare_variable_values(values)

    write_odt_file
    replace_variables
    generate_pdf

    @pdf_file_path
  ensure
    delete_tempfile
  end
end

The Rails::Service class comes with some handy features to make your life easier:

Call style invocation: PDFGenerationService.(some, params) which is the same as PDFGenerationService.call(some, params)
They are configurable and automatically load their configuration both from config/services/shared.yml and config/services/[service_name].yml. You can access the config as a hash via calling config within the service.
Each service writes it's own log file to log/services/[service_name].log. You can access the logger via logger within the service.

Services replace what was usually done via lib files. They have a clear structure, are reusable, DRY and are easy to test.

UseCases for Business Logic

While the service contains low-level non-business logic, UseCases are for the opposite: high-level business logic and they replace fat controllers. A UseCase takes params and has a outcome, which is successfully or failed. Examples are: Place an item in the cart, create a new user or delete a comment.

Use Cases should be placed in the app/use_cases directory and the file and class name should start with a verb like create_blog_post.rb. I also highly recommend to namespace all use cases with the model module like blog_posts/create.rb.

Example UseCase for creating a blog post:

module BlogPosts
  class Create < Rails::UseCase
    attr_accessor :title, :content, :author, :skip_notifications

    validates :title, presence: true
    validates :content, presence: true
    validates :author, presence: true

    step :build_post
    step :save!
    step :notify_subscribers, unless: -> { skip_notifications }


    private def build_post
      @record = BlogPost.new(
        title: title,
        content: content,
        created_by: author,
        type: :default
      )
    end

    private def notify_subscribers
      # ... send some mails ...
    end
  end
end

Let's take a look on the details:

We can define the params of the UseCase by defining attr_accessors.
The params should always passed as hash and are automatically assigned to instance variables.
We can define validations for those params via ActiveRecord Validations. These are automatically executed when calling the UseCase
The logic of the UseCase is defined by steps. Each step calls the method with the same name. They can be skipped via if or unless
Steps are executed in the defined order. Only when a step succeeds (returns true) the next step will be executed. Steps can be skipped via if or unless.
The UseCase should assign the main record which is handled within the Case to @record.
Calling save! without argument will try to save that record or raises an exception. Also the @record will automatically passed into the outcome.
raising a UseCase::Error immediately stops the UseCase and saves the exception in the outcome.

Calling a UseCase looks like this:

outcome = BlogPost::Create.perform(
  title: 'Super Awesome Stuff!',
  content: 'Lorem Ipsum Dolor Sit Amet',
  created_by: current_user,
  skip_notifications: false
)

puts outcome.inspect
# => {
#   success: true,
#   record: BlogPost(...)
#   errors: [],
#   exception: nil
# }

outcome.success? Tells whether the UseCase was successful.
outcome.record Contains the record which was assigned to @record.
outcome.errors Contain validation messages when the validation failed.
outcome.exception Contains the UseCase::Error exception when any was raised.

UseCases may call other UseCases and use Services.

Each controller action or GraphQL mutation should do nothing than calling a UseCase and handle the outcome. This way you have packed your business logic in highly reusable, robust, elegant and clean ruby classes.

Behaviors

When working with UseCases you will probably have duplicated code at some point. Behaviors allow you to share code between UseCases.

Behaviors should be placed in the app/behaviors directory and the file and module name should named in a way it can be prefixed with with and should end with behavior, like current_user_behavior.rb (read: with current user).

To use a Behavior in a UseCase, use the with directive, like with CurrentUserBehavior.

Example Behavior for accessing the current user of AuthLogic:

module CurrentUserBehavior
  private def session
    UserSession.find
  end

  private def current_user
    UserSession.find&.record
  end
end

Example usage:

module BlogPosts
  class Create < Rails::UseCase
    with CurrentUserBehavior

     # ...

    private def build_post
      @record = BlogPost.new(
        title: title,
        content: content,
        created_by: current_user,
        type: :default
      )
    end

    # ...
  end
end

This way you have an elegant way to share logic between your UseCases to keep them as small as possible.

I hope I could explain the advantages of using these classes to structure a rails application and would be happy when this helps you to improve your app. Please give feedback for the gem and don't forget to star the project 😉

Thanks for the read. Have a nice day and keep coding! ❤️ 👨‍💻

Header image made by Safar Safarov @ Unsplash

I started a list of ruby gems and their crystal shard replacement

Ben Klein — Mon, 24 Jun 2019 19:21:11 +0000

I basically just created the repo. Help me to fill the list! :)

https://github.com/phortx/ruby-gem-to-crystal-list/

What's new in Vuex-ORM/Plugin-GraphQL

Ben Klein — Thu, 18 Oct 2018 12:32:41 +0000

(Photo by rawpixel)

The Vuex-ORM GraphQL Plugin and this article are powered by i22 Digitalagentur.

Since my first post about the Vuex-ORM GraphQL Plugin in may some time has passed and while that, a lot of changes have been introduced. In this article I want to show you what cool new features we got, what has changed and where we're going.

Renaming of the plugin

First of all we renamed the plugin to have a consistent naming across all the Vuex-ORM the plugins. The Plugin is now called Vuex-ORM/Plugin-GraphQL and thus the NPM package is named @vuex-orm/plugin-graphql.

Moving ahead 1.0.0

To make clear, that we are approaching a stable API, I'm currently releasing Release Candidates for 1.0.0. While writing this article we already have RC 21.

In parallel the Maintainers of Vuex-ORM and the plugins are talking about a consistent API across all persistence plugins. When this API specification is finished, we're ready for 1.0.0. Please keep in mind that until finishing the spec, the API of the Plugin will probably change. I'll keep you up to date.

Convenience methods

We got clean a API with convenience methods now. No more calling dispatch(), instead you can use fetch(), $persist(), $deleteAndDestroy() and many more!

Support for response mocking in unit tests

One of the latest RC versions brought response mocking support for Vue Unit Tests of components, that interact with the GraphQL server.

Please check the testing section in the documentation for details.

GrpahQL schema analyzing

When the first query or mutation to the GraphQL API is sent, the plugin sends a introspection query to the API, downloads the schema, analyzes it and extracts different information like the types of the fields to use, which fields to ignore, because they're not in the schema and whether custom queries and mutations return a connection or a record.

Further it detects differences between the Vuex-ORM model definitions and the schema and logs warnings.

In the future there will probably be more smart consulting of your GraphQL schema, we're open for suggestions.

Support for different API designs

Due to the fact that there is no fixed way to design a GraphQL API and there are at least 3 ways how connections could look like, the plugin now brings support for all of them, via a connectionMode setting. This will be automatically determined by analyzing the schema, so you don't have to configure anything. However, if that fails, you can explicitly overwrite the connection mode via config.

Checkout the documentation to see what connection types are supported.

In the future the plugin will get even more flexible and allows the developer to change the naming of the C(R)UD mutations. Stay tuned.

Support for custom queries and mutations

Because not all mutations are Create/Update/Delete and because not all queries can be generated automatically, the plugin now also supports custom queries and mutations. Either related to a model or not.

Take a look a the documentation to get an idea how to use custom queries and mutations

Support for HTTP headers

Setting HTTP headers either static when initializing the plugin or dynamic by passing a function is the key to setup Authentication mechanisms and a often requested feature. The plugin supports this now!

Lots of bugfixes and documentation improvements

Along with those changes came a big bunch of bugfixes, improvements both for the code and the documentation.

I also reduced the number of dependencies of the plugin to 1 (!). Which is a very slim signature for a NPM package :)

SSR Support

Support for server side rendering and Nuxt.js is experimental since RC 21. Please give feedback if it works for you!

As you can see, we got same pace in the project and we're approaching version 1.0.0 very quickly. You're invited to join our support slack channel or open a GitHub issue. We love to hear your feedback!

This OpenSource project is build with ❤️ at i22

Need your help: Show me your GraphQL Schema

Ben Klein — Tue, 03 Jul 2018 12:40:50 +0000

Hello Community!

I need your help. I'm the maintainer of Vuex-ORM-GraphQL. It's a tough job to cover all those different ways to design a GraphQL Schema. You would help me a lot if you could run the introspection query below against your GraphQL API and send me the result.

This way I can analyze what different schema designs are out there and write unit tests to ensure that my plugin can handle them all :)

Disclaimer: Please make sure it's ok to send me the schema! Don't send me any secret or sensible information you may be sentenced for. However I promise to keep the stuff you send me secret and I will delete it right after analyzing it. I will not use them for any other purpose or distribute it.

Here is the introspection schema, you can run it against your API by using GraphiQL for example.

{
  __schema {
    types {
      name
      description

      fields(includeDeprecated: true) {
        name
        description
        args {
          name
          description
          type {
            name
            kind

            ofType {
              kind

              name
              ofType {
                kind
                name

                ofType {
                  kind
                  name
                }
              }
            }
          }
        }

        type {
          name
          kind

          ofType {
            kind

            name
            ofType {
              kind
              name

              ofType {
                kind
                name
              }
            }
          }
        }
      }

      inputFields {
        name
        description

        type {
          name
          kind

          ofType {
            kind

            name
            ofType {
              kind
              name

              ofType {
                kind
                name
              }
            }
          }
        }
      }
    }
  }
}

Send me the result as a private gist to bk@itws.de.

Thank you very much for your help!

Vue <3 GraphQL

Ben Klein — Mon, 28 May 2018 08:34:33 +0000

TL;DR: I made dis: https://vuex-orm.github.io/vuex-orm-graphql/

This is my first article on dev.to and I want to use this to share my current open source project with this amazing community :)

The GraphQL Plugin for Vuex-ORM and this article is powered by the Germany based i22 Digitalagentur GmbH.

The beginning of journey

In my current side project, I was using a JSON/REST API and attached the Frontend Single Page Application via JSData. A setup that never made me really happy and brought a lot of issues.

Then I discovered Vuex-ORM which brings everything I need to work with models in Vue and also has real reactivity, is blazing fast and uses Vuex. I felt like I replace JSData with Vuex-ORM. But: There have been no plugins to attach an API. I don't want to have too much boilerplate in my components and I don't like to fiddle around with the specifics of the communication with the API. Integrating your Single Page Application with your API can be a pain. But it shouldn't.

At same time earlier this year, I've learned about GraphQL in my new full time job. And it was amazing. After some playing around, I've stated to love it and felt like I could replace the REST/JSON API of my side project with GraphQL.

Then we were starting a project in my full-time job at i22 with a very similar setup like my side project, so I decided to give Vuex-ORM a try. But we have committed to use GraphQL (like in all our other projects). Like there was no JSON/REST plugin for Vuex-ORM there was also no GraphQL plugin. I thought, I could write one. Shouldn't be that difficult, I thought: We already have our model definitions and a GraphQL API, I just could transform the model definitions into a GraphQL query. I could use the apollo-client lib. This plugin should make the communication with the API a pleasure. No boilerplate, no fiddling together JSON structures or whatever. So let's start!

It was a lot more difficult then I thought, but after some weeks of development, I had a basically working plugin which has a minimal component boilerplate and just works with reactivity and all that fancy stuff.

Time to go the next step: Migrate my side project from JSON/REST + JSData to Vuex-ORM + GraphQL. While doing that I discovered some bugs in my plugin and fixed them, wrote some more tests and added some missing features.

Today, some months of finetuning, testing and a lot of help from Kia, the very kind and smart maintainer of Vuex-ORM, later, I have a well working GraphQL Plugin for Vuex-ORM with all basic features, documentation and two of my current projects using it. It works like a charm. I'm very happy with it currently :)

Now it's time to share my work with the community. In the rest of this article I will show you how the Vuex-ORM-GraphQL plugin works and how you can use it in your project. Please remember: This is just a basic example. For more details, please take a look in the documentations both of Vuex-ORM and Vuex-ORM-GraphQL. Have fun!

How it works

I assume you have experience with Vue and maybe GraphQL.

Vuex-ORM

First of all we have to setup Vuex-ORM, which is pretty simple.

yarn add @vuex-orm/core

Then create a store.js and a models directory somewhere in your app.

Let's assume we're building a simple blog. There are posts and comments. So we need two models. Let's create them in our new models directory:

models/post.js:

import { Model } from '@vuex-orm/core';
import Comment from './comment';

/**
 * The Vuex-ORM post model
 */
export default class Post extends Model {
    // Tell Vuex-ORM the path where the records should be stored in Vuex
    static entity = 'posts';

    // Tell Vuex-ORM-GraphQL to eagerly load all comments when we fetch a post.
    static eagerLoad = ['comments'];

    // Setup the fields and relations for Vuex-ORM
    static fields () {
        return {
            id: this.increment(),
            title: this.string(''),
            content: this.string(''),
            publishedAt: this.string(''),

            comments: this.hasMany(Comment, 'postId')
        }
    }
}

models/comment.js:

import { Model } from '@vuex-orm/core';
import Post from './post';

/**
 * The Vuex-ORM comment model
 */
export default class Comment extends Model {
    // Tell Vuex-ORM the path where the records should be stored in Vuex
    static entity = 'comment';

    // Setup the fields for Vuex-ORM
    static fields () {
        return {
            id: this.increment(),
            author: this.string(''),
            content: this.string(''),
            publishedAt: this.string(''),

            postId: this.number(0),
            post: this.belongsTo(Post, 'postId')
        }
    }
}

As you can see, setting up a model for Vuex-ORM is very easy. Now we have to setup our Vuex store like this:

store.js

import Vue from 'vue';
import Vuex from 'vuex';
import VuexORM from '@vuex-orm/core';

import Post from './models/post';
import Comment from './models/comment';


// Setup Vuex
Vue.use(Vuex);

// Setup Vuex-ORM database
const database = new VuexORM.Database();
database.register(Post, {});
database.register(Comment, {});

// Create Vuex Store and register the Vuex ORM plugin.
export default new Vuex.Store({
  plugins: [VuexORM.install(database)]
});

After that we can already create new records, find them, change them and delete them in a component:

import Post from 'store/models/post';

Post.create({
  title: 'Example Blog Post',
  content: 'Lorem ipsum dolor sit amet',
  publishedAt: (new Date()).toISOString()
});

const allPosts = Post.all();

Vuex-ORM GraphQL Plugin

In the next step we setup my new GraphQL Plugin for Vuex-ORM, which is amazing simple, because the plugin hides all the complexity of the apollo-http-link, apollo-client and so on from you. It's designed to be installed and just work:

yarn add @vuex-orm/plugin-graphql

Change the store.js like this:

// ...
database.register(Post, {});
database.register(Comment, {});

// --8<-------------
// This is the new part
import installVuexORMGraphQL from '@vuex-orm/plugin-graphql';
VuexORM.use(installVuexORMGraphQL, {
  database: database,
  debug: process.env.NODE_ENV !== 'production'
});
// --8<-------------

// Create Vuex Store and register the Vuex ORM plugin.
export default new Vuex.Store({
  plugins: [VuexORM.install(database)]
});

Not much magic here, we just register the Vuex-ORM-GraphQL plugin as a Vuex-ORM plugin and pass the database. Nothing more to do. As I said: Setup I super easy ;)

Store vs Persistence Actions

While using Vuex-ORM with the GraphQL plugin you have to distinct between two types of Vuex actions:

Store actions: Retrieve data from or save data to the Vuex Store (Vue Component <--> Vuex Store)
Persistence actions: Load data from or persist data to the GraphQL API (Vuex Store <--> GraphQL Server)

The following table lists all actions and what they do:

CRUD	Vuex Only	Persist to GraphQL API
READ	`find()`, `all()`, `query()`	`fetch()`
CREATE	`create()` or `insert()`	`$persist()`
UPDATE	`$update()`	`$push()`
DELETE	`$delete()`	`$destroy()`

Example

After our setup we can use Vuex-ORM to fetch data from the GraphQL API and display it reactively:

<template>
  <div class="blog">
    <article v-for="post in posts" :key="post.id" class="blog__post">
      <h2>{{post.title}}</h2>
      <small>{{post.publishedAt}}</small>

      <p>{{post.content}}</p>

      <a href="#" @click.prevent="destroy(post)">Delete this post</a>

      <hr />

      <section class="comments">
        <h3>Comments</h3>

        <article v-for="comment in posts.comments" :key="comment.id" class="comments__comment">
          <h4>From {{comment.author}}</h4>
          <p>{{comment.content}}</p>
        </article>
      </section>
    </article>
  </div>
</template>

<script>
  import Post from 'data/models/post';

  export default {
    computed: {
      // Returns all posts with reactivity.
      posts: () => Post.all()
    },

    async mounted() {
      // Load all posts form the GraphQL API.
      await Post.fetch();
    },

    methods: {
      // Deletes the post from Vuex Store and from the server.
      async destroy(post) {
        post.$deleteAndDestroy();
      }
    }
  }
</script>

And that's all the required code to load the blog posts and comments from the server, display them and allow the user to delete the post.

GraphQL Queries

The code above generates following GraphQL query for fetch:

query Posts {
  posts {
    nodes {
      id
      content
      title
      publishedAt

      comments {
        nodes {
          id
          author
          content
          publishedAt
          postId
        }
      }
    }
  }
}

And the following GraphQL mutation for destroy:

mutation DeletePost($id: ID!) {
  deletePost(id: $id) {
    id
  }
}

Conclusion

There's still a lot of work to do: The code is a mess at some points, there are some missing tests, subscriptions are not implemented yet, there could be much more configurability and the documentation is not finished yet. But I thought it's time to share my work with the community to get feedback and hopefully get some contributions to bring the plugin to a stable version 1.0.0.

Thanks for reading.

PS: The side project launches soon. I will make a post about it when the time case come ;)