Karma tracking. about bosta HOT 16 CLOSED

I see what you mean @omaraboumrad , but it all depends on the details of the implemented features, if it is simply get/set karma value then node-persist sounds like a reasonable solution, but IMO I think SQLite can provide the best of both worlds:

1- it is literally just 1 file
2- it provides the advantage of using SQL queries
3- we can migrate fast to tilde (export SQL => import SQL => Done!)

but the main reason is the features that can be easily added when using SQL e.g with a single query we can:

• get user with top karma of the month
• get top 5 users
• all kind of fun reports that can be easily executed in one statement using SQL, and that can provide some interesting insights
• etc..

from bosta.

I'm not recommending plain text and in my opinion, I don't think that Bosta should even have it's own database. I think tilde should act as central and Bosta simply integrates tilde's APIs. However, since tidle doesn't have this functionality yet, and so that we don't waste time waiting, what's the alternative? A Redis instance on the droplet? I know for a fact that what will be built, no one will bother refactoring it later on, so this is the final version :D

from bosta.

adding a persistence layer such as a database or redis seems an overkill for such a feature.

The rudimentary storage we use is node-persist which should be enough. We can use a namespaced key:

bosta.karma.users.<uid>: 5
bosta.karma.users.<uid>: 100

from bosta.

I love this feature and you can start implementing it right away no need for us to debate it, it's a waste of time. The only thing I want to discuss are the details of the implementation:

1. Where will the data be stored, currently Bosta doesn't store information beyond basic strings in a plain text file.
2. Should this be shallowly or heavily integrated with tilde? i.e. How easy is it to create the API for this on tilde and have Bosta use it instead of Bosta having it's own database.

I think if we can have the scenario you mentioned up and running the soonest possible, we'll start adding features as we see necessary.

from bosta.

yeah, plain text file won't cut it unless we're extremely limited and cannot have a simple database setup: What we can do if we're extremely limited is to have a text file per user (user.txt) that has all the karma logs for that user. It's a massive headache (especially if there are concurrent read/writes). I think bosta is currently hosted on a 512mb droplet, I'll see what we can do (basically nagging @omaraboumrad).

For what concerns API integration: it can always be built when it's needed. tilde (or any other service) will be able to integrate.

I'll be working on ProperSpecs™ the following week, everyone is welcome to join.

from bosta.

if Redis is already setup we can use it and write to disc every x time. If not, we can have a database (since either Redis or some dbms system) installed on the server as a temporary solution until tilde is ready for this functionality then we can easily migrate our data.

from bosta.

Redis isn't setup, so we gotta do that.. You got access to Bosta's instance?

from bosta.

I don't have access, no. Let's not install anything at this point, I believe there is a discussion to be made about persisting data in general for bosta which might affect this plugin.

There isn't a need at this stage to persist anything, I'll be busy doing the parsing and echoing who's giving karma to whom and the likes.

from bosta.

cool feature!
regarding the database how about you use a simple database system temporarily (e.g sqlite => https://www.npmjs.com/package/sqlite3)
and once tilde table(s) are ready it will be really easy to just move the table(s) data there, and from my side I can help implementing the tilde part

from bosta.

thanks @HassanKanj I completely forgot about SQLite!

from bosta.

If we consider the original purpose of this plugin by @phr34ck

The purpose is to keep track of all those +1/+5 karma points that we "give" whenever someone says something smart, funny, etc. The purpose of that purpose is having fun and not building a well thought out system that cares about correctness or covering every single use case.

Karma is a simple idea that doesn't have any real value, I don't believe there's insight that merits considering reports. The data that available is so minuscule that it can be loaded fully into memory and computation can be done with very little effort.

While i don't particularly mind adding a persistence layer beyond what we currently have, we can at least start with what's available and later on improve if needed.

from bosta.

Regarding the technology, we can totally start somewhere for sure.

About the insights and the real value part, of course I don't mean by that an actual concrete and directly relevant value such as the one we deduce from doing surveys..

For example, I am very interested in human behavior and social groups dynamics, and karma points can be an indirect and important index to provide insights about that, especially when observing trends.. so we can experiment with the following:

• checking whose karma is suddenly trending lately (an indicator that s/he is becoming more socially active in the group) and vice versa
• checking whose karma suddenly dropped (and is it related to someone's else karma going up?)..
• trying to see if we can deduce friendships between members based on karma sender/receiver,..
• and many other stuff..

And we can add commands such as (bosta deduceFriends user and see how accurate this can be, etc..)

Would that be relevant in real life? not necessarily! but for me personally.. these are some cool/fun features to build..

And I know @phr34ck is actually trying to build a simple system just to set karma points, and many programmers may not necessarily be interested in the above details, but still the system can be extendable in the future with all kind of functionalities..

from bosta.

although I haven't decided what will be persisted exactly, I can tell you it's not going to be a simple integer attached to a user.

The idea of karma is a simple as it gets but I want to keep track of multiple things that makes it more interesting (to me at least):

• When the karma was given: karma logs per user
• Karma is per-user however there is an important information that should be there as well: the optional message that gave that user x karma.
• total karma: could be either a single integer field that's incremented or it's calculated on demand (based on the logs).

thinking about loud: I was thinking yesterday that maybe we can add 3 extra emoticons: 0.5, 1, 2, 5 that users can respond to messages with instead of writing: +1. /thinking out loud

I haven't read about node-persist so everything that follows might be dead wrong.

I don't believe adding a persistent layer of any kind is going to increase complexity in any way (except adding an extra step when installing on a new dev machine). It will be there for whoever is building a plugin that requires persistence and plugins that don't need it won't have to use it. Everything will be same as it is now, the added layer will only give us the potential of leveraging it.

Instead of writing/appending to a textfile/nodepersist you write to sql (or whatever). The data is simple and the operation is simple and the load is well within the single machine that we have. It will require no extra cost, no extra maintenance time (no more than what we currently allocated).

from bosta.

Let's get this shit done already!

from bosta.

@phr34ck do the honors of closing this feature

from bosta.

thanks for everyone involved, specially @mena-devs/bosta-developers :D.

from bosta.