I am building an online poster maker store with Ruby on Rails that gives the customer the option to either download a digital file for a generated poster or to have us print it for them and ship it to them. I am having troubles deciding where in my application to put this functionality. I am using a basic products, line_item, and cart structure.
Do I:
1) Make an option on the checkout that creates an Order if they decide to have us print the poster. If they just want the digital file it would just give them access on their user page after checkout.
2) Make a attribute on my line_item model that saves weather they want to download or print the file.
3) Something else entirely?
Thanks in advance for your help!
I believe I have found a solution! After talking to another developer friend, it hit me that the best solution might be to put all of the attributes for both printed and downloadable posters in the same products model and then expose only the information needed for each particular order.
For example,
If the order is to be printed by us, the user will be asked to fill out a shipping address form and asked what paper they want us to use. If they customer is just going to download the generated poster design these fields in the form will be hidden.
I believe that this is a much simpler solution then the two that I described above and will be the easiest to implement.
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.
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
I'm building a static website with 10000+ pages generates from json file with middleman.
Each page is a document (pdf) with it's own id, summary and a download link.
I need to give anonymous users the ability to rate a document and show global rating for each document.
Since the website is static, i've been looking for a solution like disqus that handles pages rating and ability to get counts via api. I didn't find any.
Let's say I'll have to create a seperate server that handles rating. Which technology should I use ? I think about Redis, but the big problem is what if a visitor creates a scripts that rates up/down a document million times. How can I make sure there will be no flooding?
I know about captcha, but will it be effective in this scenario?
Are there other solutions?
So here are my questions:
Is Redis the right choice for this?
NodeJS/Rails ? I'm pretty confortable with Rails, but NodeJS is faster ?
Is captcha enough to be sure there will be no (minimum) flooding ? Other solution?
Thank you.
Redis is an awesome solution for it. you can use redis abilities to store each rating given and another key to store the calculated rating for an easy fetch
If you are familiar with Javascript, Node JS is a fun choice to go. if you are more familiar with ruby - Sinatra would do the trick just fine.
as for the captcha solution - keeping anon users from flooding your rating queue is a PITA. you should probably allow only registered / logged in users to rate - and only after a successful download request.in that case - a captcha would be just fine.
my first entry here.
I'm trying to add a comment system to our Posts model. However, I am not sure of the best way to go about it for a number of reasons. I'd like the comment system to be similar to that on Forrst.com but i'd rather have visitors who comment not need an account as the site is our company site not a large community.
Outline of features are:
Visitor can comment on post, entering name, email and comment.
Our team members can comment, i'd like these to be styled differently so would like the system to know it was from one of our team, they will be logged into the system when leaving a comment.
Visitors and team members can reply to a comment. The system needs to know which comment it was in reply to.
Lastly i'd like the system to know if the comment was written by the post author.
I have looked and been trying out acts_as_commentable_with_threading which seems perfect except everyone needs a user account to leave a comment, something I am trying to avoid unless anyone has other thoughts on that?
I have also implemented this myself by creating a comments model and using awesome_nested_set for the threading. Within the comments model I have a user_id which is only populated if the user is logged in (meaning they must be a team member), this seems a little messy though.
Does anyone have any thoughts on this?
Oh, and I would love each person to be notified of a reply to their comment (if pos).
Thanks in advance.
There are lot of tools available to post comments and working with ruby on rails.
http://ruby-toolbox.com/categories/rails_comments.html
also you can customize according your own requirement instead of writing a messy code.
If you do not want to integrate a third-party service like Disqus, you have Juvia The Comments and Commontator. Also you can count with opinio as alternative. but only with Rails 3 and at the moment and as notice the development seems stalled.
I am using embedded documents in MongoDB for a Rails 3 app. I like that I can use embedded documents and the values are all returned with one query and there is less load on the database server. But what happens if I want my users to be able to update properties that really should be shared across documents. Is this sort of operation feasible with MongoDB or would I be better off using normal id based relations? If ID based relations are the way to go would it affect performance to a great degree?
If you need to know anything else about the application or data I would be happy to let you know what I am working with.
Document that has many properties that all documents share.
Person
name: string
description: string
Document that wants to use these properties:
Post
(references many people)
body: string
This all depends on what are you going to do with your Person model later. I know of at least one working example (blog using MongoDB) where its developer keeps user data inside comments they make and uses one collection for the entire blog. Well, ok, he uses second one for his "tag cloud" :) He just doesn't need to keep centralized list of all commenters, he doesn't care. His blog contains consolidated data from all his previous sites/blogs?, almost 6000 posts total. Posts contain comments, comments contain users, users have emails, he got "subscribe to comments" option for every user who comments some post, authorization is handled by the external OpenID service aggregator (Loginza), he keeps user email got from Loginza response and their "login token" in their cookies. So the functionality is pretty good.
So, the real question is - what are you going to do with your Users later? If really feel like you need a separate collection (you're going to let users have centralized control panels, have site-based registration, you're going to make user-centristic features and so on), make it separate. If not - keep it simple and have fun :)
It depends on what user info you want to share acrross documents. Lets say if you have user and user have emails. Does not make sence to move emails into separate collection since will be not more that 10, 20, 100 emails per user. But if user say have some big related information that always growing, like blog posts then make sence to move it into separate collection.
So answer depend on user document structure. If you show your user document structure and what you planning to move into separate collection i will help you make decision.