I have an app I'm working on that is a credits system for a store. A customer brings in items and receives a credit and then can turn around and use that credit towards certain goods in the store. I've set it up so every time a credit holder or credit is created,updated, or destroyed the event is logged. I'm wondering if there is an easy way to use the event data from the logs to create a dashboard displaying things such as X number of credits created and Y number of credits used today. This may not be the right way to go about doing this at all and if so feel free to guide me in another direction. Thanks in advance!
You should save the information into a database (in addition) to the log and operate on it in this fashion.
So for example, maybe you have a User it should be a Model and have credits which should be an integer. You can modify this value every time a transaction happens.
You can also create an associated model 'transactions' which belong_to the user and to find out transactions that happened on a certain day, you would be able to pull up all of the transactions of that user in a certain time range.
If your credits work similar to dollars and money. And your transactions are like orders, you may want to look into using the Spree gem. https://github.com/spree/spree
You definitely do not want to be reading from the logs to do very usual actions like you're describing.
Related
I have a question for a project I am working on. I am working on a RoR project in which a site is selling a single type of item, a book. The person I am creating this for does not want to deal with users creating user account to check out as the sales season is very short for this product, the purchases are done once per year, and the site only sells a single item.
I am wondering if there is something wrong with the implementation I am thinking of. What I was envisioning was a single database class called Orders. visitors to the site would simple fill out an order form with payment details through stripe and click submit. If they payment clears, the order with all the Orders information would be persisted to the DB. If the payment fails then it is not persisted and the relevant error information is displayed in using flash.
I suppose the meat of my question is; is there anything inherently 'wrong' about implementing this model without a users class and just having visitors to the site place orders?
I am a fairly new developer and this is my first big project so any feedback is appreciated!
If your requirements say that it is okay, then it is okay, if your requirements say it is not okay, then it is not okay.
There's not more to say, since only you know what your requirements are.
We are having a lot of transactions on the site, so for this reason we are re-cycling our booking confirmation numbers/ order id numbers on the confirmation screen which is set into our purchaseID . Since we are re-using our booking confirmation number, in order to make our purchaseID unique we are adding timestamp to our purchaseID variable using pipe delimeter. So formula looks like:
purchaseID = order_id + '|' + timestamp (current date).
My concern here is, let's say I make a booking today and my purchase id looks like -
purchaseID = 5747118 | 6-7-2019
Now I access my confirmation screen again tomorrow and after 2 days, 3 days and so on and I see adobe calls firing. Because I accessed my confirmation page on different dates my timestamp changed and thus my purchaseID is not unique anymore. Even though I am seeing my same booking confirmation page my purchaseID is not unique now. Does this mean, every time i view my confirmation screen on a different day my booking/revenue would be counted multiple times ? If yes, what's the best way to tackle this issue ?
So it sounds like someone can go to your site, make a purchase and see the confirmation page, and then later on, go back to the same confirmation page without actually making another purchase. Maybe they bookmarked the page and come back to it later for reference. Or maybe they refreshed the page, because reasons.
Does your site charge their credit card for accessing the page again? I sure hope not. Your site/coding should be structured in a way that does not keep charging the customer more money every time they view the page again.
And your code logic for outputting Adobe Analytics should be structured in the same way: your coding logic should be that you only output purchase event and variables (e.g. purchaseID) when a purchase actually occurs.
In practice, this sometimes isn't easy to do because of how the site is structured. So part of why purchaseIDexists is to de-duplicate purchases, so that if purchase event and data is re-popped, it will be de-duped. But it only works if you output the same purchaseID when the visitor refreshes the page or otherwise comes back to it later on (where they aren't actually making another purchase).
Which it sounds like you were doing with the original booking confirmation number you pushed to purchaseID. But things went south when you decided to throw a current datestamp into the mix because you started recycling booking confirmation numbers. Well you can't do that. You can use a dynamic value such as the current date/timestamp as part of the value, but you must remember it, and output it in the future.
Maybe this involves adding an extra column to your database with the date/timestamp of purchase (which I have to assume you surely already have), and then pull that value when you pull the booking confirmation number.
Or maybe the solution involves stepping back and rethinking the fact you are recycling booking confirmation numbers. This seems like a bad idea to me. It's definitely a bad idea for your Adobe Analytics implementation, as you have seen for yourself. But is this not a bad idea in general? What happens if a customer buys something today and has # 12345 as proof of transaction to reference, and then tomorrow, a week, a year or whatever from now, some other customer gets the same number?
It stands to reason that you will end up with a mess on your hands, trying to sort out which customer bought what. Transaction ids by their nature are supposed to be forever unique to the transaction. So my very first recommended solution to you would be to stop recycling your booking confirmation numbers. Move to a different format if you need to (e.g. UUID).
Failing that, my next recommendation would be what I said a couple paragraphs up, about storing the date/timestamp in a column at the actual time of purchase (which surely you already have), and then grab and use that value along with the booking confirmation # to use as delimited value, instead of generating the current date on the fly (which absolutely does not work).
I am have been using rails for about a week now and have created a website/app which for simplicity's sake we can call a job board. Users can create listings which other users can then apply for. Everything is working as desired. The next thing that I want to set up is the ability to charge users to create the listings.
After extensive searching, I can't find any tutorials that explain this process, just the typical cart and checkout for selling physical products.
I have been pondering solutions but I wanted to consult here for pro advice.
For the payment process (at least for now) I will most likely use active merchant and Paypal as I am based in Europe.
My current doubts are with setting up the modeling.
Would it be better to create a new model eg. 'credits', have users purchase 'credits', then run a variable when trying to create a 'job', eg. if_user_has_credits post the job else link to buy_credits_path, or is there a more direct way of achieving this through the already functional user and jobs models?
Any advice on setting up this functionality would be greatly appreciated.
Thanks.
I would try to create a credit system, so users just have to purchase credits and you can just drive the user to purchase credits in case they do not have enough for create a listing:
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. The balance-based way gives you fast access to the current amount
History based: Don't store the balance in database. The balance is computed by looking at the history of transactions, e.g. ("add", "deduct"). The history-based way gives you auditing. The history table should store the transaction, a timestamp, the balance before the transaction happened, and ideally a way to track the funds' source/destination.
You can use both. See the Ruby toolbox for bookeeping and Plutus
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
Build a restaurant reservation system with the following function:
Here's the list of prioritized functions:
Restaurant Owner
can set number of tables (assuming all 4 seating per table)
can review current reservation,
reservation older than 2 hours are automatically cleared
can add reservation done over phone for given day/time
can remove reservation
can update reservation done over phone
Customer
can review number of available table for day / time
can add reservation for day / time, get confirmation number
can cancel reservation with confirmation number
can update reservation with confirmation number
I am completely new to ruby on rails, I just need a simple hint on how to get started and what should be my approach for this problem?
Start by defining the models (entities), their properties, and how they relate to each other. Next, figure out what functionality needs to be exposed to the front end.
(Those steps can occur in either order, or, more realistically, each will affect your thoughts about the other, so it bounces back and forth as you iterate over the various things the system must handle.)
Expand the user stories you have above with conditions you'll encounter and how you'll know it's done. Rails makes it easy to get starting building up preliminary functionality--don't get hung up with how it looks at first, just make sure you can actually do what you need to.
You'll also need a user authentication/authorization system; I recommend using an existing one like authlogic or devise. Whether or not you need something like cancan for authorization I don't know; but you'll need some way of making sure people can only see what they're supposed to be able to.
You'll also need something like eventmachine for sweeping away old reservations (man, in NYC if you're like 10 minutes late, you're outta there!) but take things a step at a time--first just implement the sweeper as a manual process to get the logic worked out.
Good luck!
The functionality I'm trying to implement is used in a site called Wefollow ( http://wefollow.com/ ):
On this WeFollow each account is checked for
# of followers
# of statuses
How can reliably update the information for each account without bumping into the 2000 queries/hour limit imposed by Twitter?
I'm trying to build a directory and update the same details. How can I deal with this?
Help would be very much appreciated.
EDIT: I'm trying to understand how that site works, not promoting it. I'm sorry if I wasn't clear enough.
If there's a hard limit, there's a hard limit. I would do this by putting all accounts in a rotating queue and updating them in that order up to a given maximum. If you can't cover all accounts, that's too bad. You could also calculate activity values based on deltas per user and prioritise the updating of those users. If a user hasn't changed in a month then there's no point checking that user more frequently than every week. Likewise, if a given user is very active, they can be pushed to the front of the queue.
BTW I would say this is verging on not programming related.
You can apply to have your IP address and account whitelisted which will increase your rate limit to 20,000/hour if you are approved. (http://apiwiki.twitter.com/Rate-limiting)
At FanPageList.com, we update information for our accounts every 2-4 hours. If you look closely at wefollow.com, some of their counts are outdated. Even at TwitterCounter.com, they only claim to update their counts daily (unless you pay for their paid service, they will start tracking your account hourly).