I'm interested in learning how to implement a News Feed / Activity Feed on a web app for multiple models like Books, Authors, Comments, etc...
Any recommendations from the group? Gems/Plugins, or experience personally or from others on the best/smartest way to proceed?
Thanks!
You don't need any Gem.
Create a new model, e.g. Activity, to store activity details. The module should store at least the activity timestamp, the event (e.g. created, destroyed, published, ...) and the id of the related record (you can even use a polymorphic association if you want)
Create a method which gets in input a record with additional metadata and creates a new activity record
In you controllers, call the method each time you want to keep track of an action, passing the modified record as parameter
Then you'll have a list of Activity records you can easily fetch to display the latest events.
First and foremost, I’d like to be open and say that I am an employee of Stream, an API for building scalable news and activity feeds – much like you would see on Facebook, Instagram, and other social media applications.
From my extensive experience as a developer and consultant and continued research and self-education, Stream’s technology stack is extremely effective or competitive. You can get a news or activity feed up and running in a fraction of the time than it would take you to build out your own infrastructure (Cassandra clusters, queuing mechanisms, etc.).
That being said, I highly recommend checking out Stream. What it really comes down to is buy vs build. You can spend months building out a custom solution, or rely on a proven and scalable platform such as Stream that will offer you everything you need to get up and going, in a fraction of the time.
If you're skeptical, check out the 5 minute tutorial at https://getstream.io/get_started/.
Best of luck!
Related
I am about to embark on the creation of one of my first meaningful rails apps, and am a bit unsure of how to structure things.
Here's my situation. I am using a SAAS inventory software that keeps track of approximately 4000 products. I need an app that can perform routine maintenance functions on the products. For example, to give you an idea:
Every week, calculate and set the "low stock alert quantity" for each product based on historic sales
Assign products to product categories based on rules (i.e. if the word "t-shirt" is in the title, automatically add it to the t-shirts category)
etc etc
My questions are as follows:
I'm not sure exactly how to structure the data in this app. Should I query the API each time I need to retrieve the products? Or should I build a local copy of the inventory in a local database, for faster querying? If I am to build a local copy of the database, what would be an efficient way of keeping an up to date version of each product without consuming too much server resources? Obviously I can't pull 4000 products via the API at once...and I also don't want a cron job to be running every minute of the day.
Where should I place the code for my remote API functions? Do I create a class, module, or something else?
Thanks for any advice.
First of all, do you really need a web interface? I don't see so in your app description. If what you want to build is a maintenance set of tools that would be executed periodically, why would you use Rails?
The way of structuring data depends on your needs and resources. Does your SAAS provide instant notifications on products update, such as webhooks? Does your SAAS API let you fetch only products that were updated after a certain date? What's more important to you, speed or working with up to date data? Answering those questions to yourself should help you to decide what the best approach is.
Regarding the app design, it looks that you could write a gem where you could have different modules to manage data, execute operations with that data and connect to the third party service, and use that gem in scripts that would execute periodically. I would recommend you reading a book on Object Oriented design that I truly believe it'd help you, Practical Object-Oriented Design in Ruby.
Just one last word, I'm taking too many assumptions here, no one but you know better your requirements, and the design of your software depends on that.
If your API follows REST then it can very easily be integrated into rails using ActiveResource. If the API is more complicated, you could use ActiveModel and roll your own implementation. Just create a base class of your own that handles connection and authentication and extend your models from that. Given the limited description of your problem, there's not much more I can say.
I am going to write a simple credit system that user can "add", "deduct" credits in the system. Currently I am thinking of two approaches.
Simple one: Store the user' credit as balance field in the database, and all actions ("add", "deduct") are logged but not used to compute the latest balance.
History based: Don't store the balance in database. The balance is computed by looking at the history of transactions, e.g. ("add", "deduct")
Both case would works I think, but I am looking to see if any caveat when designing such a system, particularly I am favoring the History based system.
Or, are there any reference implementation or open source module I am use?
Update: Or are there any Ruby/Rail based module like AuthLogic so I can plug and play into my existing code without reinventing the wheel (e.g. transaction, rollback, security etc)?
Absolutely use both.
The balance-based way gives you fast access to the current amount.
The history-based way gives you auditing. The history table should store the transaction (as you describe), a timestamp, the balance before the transaction happened, and ideally a way to track the funds' source/destination.
See the Ruby Toolbox for bookkeeping and Plutus double-entry bookkeeping gem.
In addition, if your credit system may affect users, then I recommend also using logging, and ideally read about secure log verification and provable timestamp chaining.
For logging details see: techniques for ensuring verifiability of event log files.
For open source code that does credit, you may want to look into: http://www.gnucash.org/
Adding and deducting credits implies that you might also need to be aware of where these credits came from and where they went. Any time you get into a situation like this, whether it is with currency or some other numerical quantity that needs to be tracked and accounted for, you should consider using a double entry accounting pattern.
This pattern has worked for centuries and gives you all of the functionality you need to be able to see what your balances are and how they got to be that way:
Audit log of all transactions (including sources and sinks of "funds")
Running balance of all accounts over time (if you choose to record it)
Easy validation of the correctness of records
Ability to "write-once" - no updates means no tampering
If you aren't familiar with the details, start here: Double Entry Bookkeeping or ask anyone who has taken an introductory course in bookkeeping.
You asked for a Ruby on Rails open source solution that you could plug and play into your application. You can use Plutus. Here is an excerpt from the description of this project on Github:
The plutus plugin provides a complete double entry accounting system
for use in any Ruby on Rails application. The plugin follows general
Double Entry Bookkeeping practices. ... Plutus consists of tables that
maintain your accounts, entries and debits and credits. Each entry can
have many debits and credits. The entry table, which records your
business transactions is, essentially, your accounting Journal.
yes, use both.
On top of that, you'll sometime need to reverse a transaction/
transactions.When doing that, create a new reversed transaction to
notate the money transfer.
sometimes, You'll need to unify several transactions under one roof. I suggest to create a third table called 'tokens' that will be the payments manager and you'll unify those grouped transactions under that token.
token.transactions = (select * from transactions t where t.token = "123") for example
Until now I've worked on a web app for keeping record of different products from different warehouses in regards to inventories and transactions etc.
I was asked to do an ecommerce front end for selling products from these warehouses and I would like to know how should I approach this problem?
The warehouses web app has a lot of logic and a lot of products and details and I don't know whether to use the same databases(s) for the second app by mingling the data in regards to user mgmt, sales orders and etc.
I've tried doing my homework but for the love of internet I don't even know how to search, if I'm placed on the right track I shall retreat to my cave and study.
I'm not very experienced in this matter and I would like to receive some aid in deciding how to approach the problem, go for a unified database or separated one-way linked datbases and how hard would it be to maintain the second approach if so?
Speaking of warehouses, I believe that is what you should do with your data, e.g. roll each and every disparate data source into a common set of classes/objects that your eCommerce store consumes and deals with.
To that end, here are some rough pointers:
Abstract logic currently within your inventory app into a middle tier WCF Service that both your inventory app and eCommerce app can consume it. You don't want your inventory app to be the bottleneck here.
Warehouse your data, e.g. consolidate all of these different data sources into your own classes/data structures that you control. You will need to do this to create an effective MVC pattern that is maintainable and sustainable. You don't want those disparate domain model inventories to control your view model design.
You also don't want to execute all of that disparate logic every time you want a product to show to the end user, so cache the data in a well indexed, suitable table as described above for high availability that you can get to using Entity Framework or similar. Agree with the business on an acceptable delay and kick off your import/update processes on a schedule.
Use Net.Tcp bindings on your services to move your data around internally. It's quick, it's efficient and there is very little overhead compared to SOAP when dealing in larger data movements.
Depending on scale required, you may also want to consider implementing a WCF Service purely for the back-end of your ecommerce store, that deals only in customer interactions with the underlying warehoused data sources, this could then warrant its own server eventually if the store becomes popular. Also, you could figure in messaging eventually between your SOA components, later down the line.
Profit. No, seriously!
I hope this helps. Good luck!
I'm building something like Facebooks Wall inside of Rails. It will look something like this:
Stacey S. Wants to be Friends
You've been invited to the Summer Social
Pat Replied to your Message: Hey!!!
American Pet Society has a new Post: Love Your Cat!
There are two ways to do this. I could have each of these different events write to the events database when they are created or I could pull from the relationships, invitation, inbox and posts tables and create the events on the fly.
I'm leaning towards the events database approach because it seems cleaner to just call that one table than all the other tables and then sort them correctly. Is this how you would do it?
I'm building a system with similar requirements now, and I think you'll find that the performance characteristics of the latter approach make it extremely untenable. depending on how much usage you intend to get out of the system, you may find the event table to be a performance hog during the request as well. What I'm doing is using an architecture that's basically CQS with event sourcing which builds the feeds for a given user in the background and caches them in a thoroughly denormalized fashion to make the request cycle very short.
Another approach you should look at is using Chronologic: https://github.com/gowalla/chronologic. It may save you quite a bit of effort.
By all means, it will save you from a lot of complicated queries and sorting. Go for the event table approach.
I have a few apps written in ruby on rails and like any good developer I want high quality data about my site, such as measuring the number of new user accounts per day. I'm in the process of writing my own analytics tools, but I feel like i'm re-inventing the wheel. Are there any plugins or gems that could help me pull this data and display it quickly (graphs are a plus)?
If not, what types of features would you want in such a tool (i'll put a plugin on github if my code is good enough)?
Update:
To clarify a bit, i'm looking for business level-analytics. I already use google-analytics for my site traffic, and active-scaffold to get an admin page, right now my application has users which generate tickets and can create surveys, i'm interested in general trends in my application and by graphing new & existing user numbers versus new tickets and new surveys i can get the info that I want. I like to get general numbers, so i'm pulling all the users for the last 30 days, and then iterating over them to count how many i get per day...then i'm saving that to an array and plotting versus tickets, etc. Right i'm doing this using a home brew library which isn't very efficient, and before I put time/energy into making it better I want to make sure i'm not duplicating an existing set of tools. Or writing un-needed code.
If you post how you personally do this, and the answer is at least intelligible i'll be happy to give you a karma bump for your time.
You have three options that are all fairly easy to implement:
Google Analytics
Just include a small javascript snippet in the footer of your page and you get meaningful data about your hits/traffic. This is extremely easy, and will provide traffic information, but nothing about the internal workings about your applications.
New Relic: RPM
New Relic RPM is a service that comes in the form of a plugin. There is a free version, which gives you a (useful) taste of the features it can provide. This plugin will give you hardcore rails analytics. It will tell you what percentage of a request to a controller is spent in the model, in the view, etc. It will tell you how long each SQL call takes. This is great for optimizing your application.
ActiveScaffold
While not in and of itself an administrative tool, ActiveScaffold fits the bill quite nicely. Just create an admin namespace and create ActiveScaffolds for all your models/resources. This lets you see the data in an easy to use way, get simple counts of your rows (to see how many users you have, for example). This is a very easy setup, with little overhead.
Edit to reply to the OP Edit
There are no gems/plugins that I'm aware of that provide business-level analytics that you seem to want, as they are specialized associations between models that can't be predicted. The best bet, in my opinion, would be to roll your own solution that provides the data you want.
Probably the easiest way is to stick with good ol' Google Analytics. I'm pretty sure there are tools for more specific needs, but for general purpose analytics they are probably the best.