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.
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'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 users in my system and I want to create a reputation system where they begin to accumulate points based on a few, simpler inputs:
The ratings of their reviews
The number of reviews they have
The number of followers
I don't need it to be super complex, just functional and believable. I am seeking help both on the "math" side, but also if there are gems they do pieces of it on the user-interface and data-model side.
I would take a look at thumbs_up, I looked into it for a recent project and now wished we had used it instead of a different gem. Seems pretty straightforward.
While it's not a Rails specific book and more conceptual, I recommend the book 'Building Web Reputation Systems.' http://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/ref=sr_1_1?ie=UTF8&s=books&qid=1303234014&sr=8-1
Depending on what you're trying to do, lots of planning goes underneath them and the book talks a lot about the process along with other examples from Yahoo and soforth.
I work at an in-house IT department for company running 10 or so only shops of varying complexity. The shops code has been written over the last 8 years, each shop a new branch growing father and father away from the stem (I guess that makes it a bush?)
The need for more and more complex discounts, campaigns and user monitoring are growing rapidly - and changing rapidly as well (you never know what they come up with). So we have decided to write a new system from scratch and bring the different shops back together having them run on the same core code. We have considered .NET, but due to the fact that the design requirements change so fast we have more or less decided to give Rails a try. But we have some uncertainties/questions about rails.
Is Rails (stack) suitable to run to build a shop framework and who should this be organized?
We are running around 10 shops of which some are very much alike only differing in style, where others stands out in functionality, flow and content. But behind the business logic is all the same. The shops functionality is to a great extend the same as well. As an example the checkout page of one shop might display great details about VAT, discounts, P&P, etc. where as another might only show the necessary minimum.
Which approach would you take? Would you build and maintain a runable template shop with a functional superset of the shops. As new functionality is developed then merge the code with the other shops? Sounds a bit cumbersome.
In the example with the checkout page the views would differ from shop to shop, but the controllers and the models would remain the same, as long as you externalize configurations, like payment method types, and so on.
From this perspective it would make more sense just to create a repository of the views and configurations for each shop and then maintain model and controller code in a separate repository.
Would be possible to arrange the views according to shop, keeping all resources in one repositoary /views/shopname/Product. Would this make sense?
What do you think? how would you do this? Will working with rails in this way bring to much trouble?
Our campaign/discount system is growing steadily complex, both GUI and business logic. (in this view Rails seems interesting with its fast turnaround). Our discounts are property based and these properties are stored in a database row.
Making changes in the requirements to the workings of a discount is a real headache. So we are slowly replacing this property based system with a system that for each discount attaches a class (PHP) and a configuration so that each discount type has its own class and each utilization of such discount could specify some values for this class to operate on given current context (basically: what is in the basket)
In rails what approach would you take?
In rails you can easily extend your model (discount) with yet another property, migrate and you are ready (maybe a bit simplified). Could you write a base discount class that relied on a few basic properties and then write modules that hook into (extends) this class in case you need more advanced functionality?
Specifically what would this be in Rails terms a helper?
Some of this post might be a bit unclear. Please do ask questions. Also I'm in the process of learning Rails so please excuse me if don't use the right terms or if I've missed some of the main ideas of Rails.
Thanks
Michael
Is Rails (stack) suitable to run to
build a shop framework and how should
this be organized?
Sure, it can be suitable see:
http://www.shopify.com/
http://www.liquidmarkup.org/
I would not recommend it as a first project though.
Dont forget Spree Commerce as a viable solution that may or not suid your needs. On the other hand, if you want to roll your own solution, also check ActiveMerchant for payment gateway integration.
Maybe I am mistating the problems and conflating the answer with the questions, but please here me out. I would like to think (communally, with you) about a site that is based on any any of the MVC frameworks(something PHP or ASP.NET MVC, whtever) that would use a search engine (lucene/solr, FAST ESP, whatever) as the back end of the Model. That is to say, there is no database per se in the project. Just a giant index of docuements that are semistructured content.
I am looking to understand - and keep in mind the site is primarily read-only - where I am likely to run into trouble. What are the things that make you think this is a bad idea from the get go. Also, please assume that there will be a robust infrastructure with caching surrounding the search engine - so while perf comments are welcomed, we feel they are not the major problem.
Thanks!
In general, I'd use a tool like Lucene for searching content, and a database for retrieving it. That doesn't mean that it won't work. It's more a question of why you don't want to use a database. Yes, it can work, and it probably will work (depending on the functional requirements of the site, read on), but that still doesn't make a tool like Lucene the right tool for the job per se.
That being said, it also it does depend on the kind of site however. Is it really a site with just a whole bunch of searchable data and nothing else, or is it something much more than that? If the answer is the first, then good! If it is the latter, there are some issues I can think of:
Updates to the data can be troublesome. "Instant updates" are usually a no-go, as Lucene would have to rebuild its index, which is time-consuming. If there aren't many updates to the data that's fine. You can just recreate the index a couple of times per day, or nightly, if that works.
Trying to stuff any data in an index which is not really suited to be indexed is usually not a good idea. If the site lets users register on your site, then that user data should really go in a database. It's not impossible to store it in a lucene index, it's just not the right tool for the job. Use the index as a bunch of indexed documents, but don't use it as a database as well.