I have a rails app and want to log how often a user triggers certain events. I want to use it not just for analytics but to use it as one of the core features in the app (such as ranking and displaying the info).
For example, I could log how often a user comes back to the app and use that information to rank users.
Is there any ruby gem that makes it easier to do something like this?
I didn't think using 3rd party analytics engine was the way to go because this is a core feature to the product. However I am open to suggestions.
Your need is very broad so no matter what you select, you will have to customize it.
I think the merit gem is a good start. You can configure the gem to mark the sessions controller action to gain points and then rank the users using the points.
Some might say that this is not the intended purpose of the gem but I think it depends on what you think the app main purpose.
Check out the gem here: https://github.com/tute/merit
Good luck!
Related
I have my main app and admin app built as a microservice, they are communicating via api. I want to share some constants between those two apps.
For example I have User model that can have role Owner or Regular. In admin app I can search Users and in this search I have dropdown with hardcoded user type (Owner, Regular). This is okay, but when I change naming (e.g. Regular -> Standard) I have to update my Admin app also.
To avoid changing admin app every time I change some core naming in my main app I want to somehow share those constants, so every change in main app will change Admin at the same time.
For now I found 2 solutions, both with pros and cons:
First is sending constants from main app to admin via json api. I have build a class that will fetch and store all constants in class variable, so it's available from every part of the the app. The good thing about this solution is performance (thanks to memoization it's only one api request) and it's easy to use later. The bad thing is I have no idea how to handle tests in this case. Of course I cannot let my tests make request to main app and stubbing this request makes the whole idea pointless, because after every change of constants in main app I will need to change tests in admin app.
Second approach I thought of is building a gem that will store all constants. It's very easy to implement, but this means I will need to make changes to this repo every time I want to change constants in main app. Also I work with big team and they won't be happy that they have to work on 2 repos at the same time.
What do you think about those solutions? First one seems to be perfect for me except tests, so maybe you have some ideas how to stub those constants without real values? I haven't tried gem solution yet so if you see some obstacles please let me know.
Maybe there is another better solution to this problem?
I'm not sure if there might be a better solution in terms of structure of the services themselves, for example one of the two services could have an API which returns the constants for the other to use.
But to answer the question you could use an engine, or more likely for simple sharing of constants, a gem. You can create a new gem with bundle gem <GEM NAME> and then add it to the Gemfile of both apps.
You will need to either have a gem server (e.g. geminabox) or just point directly to your code repo, e.g.
gem 'my-gem', git: 'git#my-server.com:git/my-gem`
Personally speaking I'd go with the API returning the constants because you might want to rewrite one service in another language in which case sharing a gem falls down.
write a gem and include it in the different services.
if they run on the same machines, another possibility is env vars.
Keep it in a DB/storage, i.e. memchache/redi. Load the relevant constants on each service init.
I'm new here and I thought I could ask a topic about creating a friend's list for users in my small rails project, since I couldn't find an answer specific enough to what I'm looking for.
I'm trying to make a basic friend request, so that I can have users in a database use a 'friend' function to keep track of players they like, so that they can keep in contact, etc. I currently am thinking that I need to use a has_many relation in regards to setting things up, but I'm not quite sure where to take it from there, besides just having each user have a list of names they wish to keep. If that's how it's done, how would I code that so each user has a list of users they wish to keep, as well as remove, add, email, etc?
It depends on how much complete and complex you want to implement it into your project.
You may want to use a gem, like amistad or has_friendship, which are plain simple to install and use. You also have socialization, which has a follow/mention/like usage like Twitter does.
If you want to learn how to code that from scratch (e.g. educational purposes), this railscast is pretty good at explaining how to implement that feature.
And if you want something even more complex, you have some gems that gives you features that you usually have at a social network (friends, photos, personal blogs and so on...): social_stream or diaspora
I'm building a system that (when completed) will serve multiple commercial customers. I need to accomplish the following:
App should use one database
Each commercial customer will have multiple users.
When any of the commercial customer's users create/read data, they should do so under the commercial customer's namespace....Thus they should not be able to see other customers' data and should also not be allowed to create data etc. for other customers.
Initially I thought that the best way would be to assign all users to a commercial customer via association. As I was worried about querying the database too much, I did some research and found some info regarding Rack and middleware. This seems to be another option of achieving what I want, but it confused me a little.
What is the best option to achieve this sort of functionality in my app?
**PS. All commercial Customers will have unique URL's ex. customer1.myapp.com
Thanks
Rack and Middleware are layers that requests go through before they hit the code you wrote in your Controllers and Models. In short, if you need some preprocessing, or anything of that nature going on, then you shouldn't mess with middleware. For this particular case, you don't need to deal with middleware.
You're building a standard Rails app that serves different clients (users, if you will). It is okay to make many queries to the DB. The important thing is to make sure your queries are efficient and that you're making proper use of the ActiveRecord system, which helps a lot in efficiency. You have Model#includes, Model#eager_load, amongst other methods at your disposal.
As for customer1.myapp.com, there is a lot of information in Rails guides about getting those things set up and interfacing with it.
What you're looking for is Multitenancy.
There are several approaches on how to implement it. One of the options is to use PostgreSQL's schemas.
You can take a look on the gem Apartment. Maybe you can get some idea out of it.
I am writing a site with multiple levels of privileges. There are basically 3 kinds of users in my system. They are Admin, Business, and Consumers (normal users). Let's just say that I am building an advertising site.
So I have a model "Campaign" which has a RESTful API that comes with rails scaffold. Businesses can create campaigns, users can only see which campaigns they want to join, and admins can do everything.
Now, I know how to apply before_filter and check rigorously for the type of users that can access a particular view.
However, each level of privilege has its own unique views.
Businesses can see the insights and analytics of their campaigns. (let's call this campaigns/analytics)
Consumers can see all the campaigns that they have participated in. (let's call this campaigns/your)
And admins have special views where they can monitor the site's activity. (let's call this campaigns/monitor_businesses).
Right now, my CampaignController has the usual RESTful views + analytics + your + monitor_businesses. Of course, I have multiple data models (not just campaigns) and this makes my RESTful controllers for those data models to be really messy.
What should I do? I am seriously considering starting a ConsumerController and then a BusinessController and put all associated views in these controllers. I don't know if this violates "RESTful" principles but I want to know what better patterns exists to deal with my problem.
I am open to all kinds of suggestions.
Why dont you try the CanCan gem for role management?
You can install as you would any gem using bundler.
It is easy to set up and keeps you from creating the same boilerplate code that you normally would by creating extra controllers or actions.
To get you started I suggest that you visit the documentation on the main page. There is more information about defining what a user can do here and you can see how to check for abilities here.
You also need to add one line to controllers you want to enforce permissions on which you can read about here.
If the standard documentation isnt enough to get you started why don't you take a look at Railscast 192. It shows you how to get up and running with CanCan and it is a great source because Ryan Bates is the creator of the screencast as well as the creator of CanCan. If the video moves too fast for you there is a text version here.
y dont you try the cancan gem for role management http://rubygems.org/gems/cancan
or do gem install cancan I hope this helps.
My site requires authentication, so it has membership. I wonder if I should create my own comment system for user to discuss/comment on an article, or should just use third-party comment system like Disqus or Intense Debate, which requires seperate account (Twitter, Facebook, etc.).
In fact, it would be good if there is a guide to create my own comment system or Q&A system for users to discuss a particular article on my website. If you know of any, please lemme know.
Thanks.
I recently am working on a project where I had to weigh the same things. I eventually decided to roll my own comments.
Namely the advantage of rolling your own is that you have full control on how they work. I needed a moderation system/queue that I needed to work a specific way, for one. Second, someday I will be looking to integrate a 'community reputation' system, so that was another plus for rolling my own. Such things I don't want to leave to a third party solution outside of my control and the third parties don't always have such a flexible API to modify.
On the other hand, Disqus (or similar third party commenting systems) may be up your alley if your needs are more simple. For one, it's easy to get up and running and may be all you may really need. Accounts for it work across anything using Disqus, and that may win convenience points for your users who are sick and tired of having to sign up for a million accounts for a million websites. Disqus also has built in tools (for spam, trolls, etc) and that is also convenient.
If you go with rolling your own solution with user accounts, you can integrate things like Facebook/Twitter/etc login to make the registration process easier. But overall, like I said, depends on how fancy or complex you need the whole thing to be.
Should you roll your own, a good start is a recent Railscasts episode on the Ancestry gem http://railscasts.com/episodes/262-trees-with-ancestry, it should give you a good start on building threaded comments.
Something in the middle :) Use the acts_as_commentable plugin :
https://github.com/jinzhu/acts_as_commentable