I am tempted to use Spree to build a site where any user will be able to publish a place for rental, or rent a place, in a similar fashion to Airbnb.
People say spree is highly customisable, however most of examples and tutorials are based on a "store" where users only purchase from physical products.
I think that I can edit the Spree::User to grant more permissions so they can also publish. And I may be able to edit the products to include location. Products will be treated as unlimited stock so they are always there.
Then the products listing page will be very changed so that places appear based on user location / search location.
Will I be able to perform all of that or should I start looking other platform?
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 recently had a new business rule that will require our users to pay for individual modules in our web application.
So, all the features we build in the application will not apply to all users. Some users can choose to add features that they want.
I've tried researching into an architecture/mindset to how to approach this development.
If I could get an idea on how to get started with this.. I would very much appreciate it.
I work with .NET web applications, and Microsoft SQL Server.
Thanks.
First list what "objects" or things you need to keep track of.
Users
userid
fullname
can manage his features? You said not all users can
...
Features:
featureid
description
cost
...
UserHasFeature
a link between a user and a feature
each line is userid, featureid
Using this you can query which user has what feature. Or list the users that have access to a particular feature.
In your web app, you will need administrator functions:
users management: add, remove, modify, list
feature: add, remove, modify, list
link management: add, remove, list
Reports: whatever reports you want to have
And user functions:
user: signin, modify, reset password, view all features, view features the user already has, add a new feature, remove a feature
reports: total cost of features the user is using, others
Now this is a very quick first draft. There are a lot of missing requirements:
approval workflow: can a user modify his features without the approbation of X?
payment methods
project number for internal billing
cost structure: monthly, one time, ...?
managers can view the features of the employees he manages?
...
This to remember:
Start with objects in your projet. These become tables.
Characteristics of the objects become fields in your tables.
If the same characteristic appears in many object tables, with the same values, consider creating a new table for these. Ex. in an address, you would not leave the country value as a simple VARCHAR field. You would link to another table with the country values.
List the relations. These become foreign keys, or link tables.
Split your objects. So apply 1NF, 2NF and 3NF at least. It is enough for most applications. (NF == Normal Form).
Each table and links require administrator pages (CRUD)
Users have a limited view related to their features only.
This is a huge subject, I could go on and on, but this could get you started.
Have fun!
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 about to start expanding my secondhand app, where people can put their used university books for sale.
Right now the app is only available in one country, but in the near future other scandinavian countries will follow.
As an example I want to expand to Sweden, the user should only be able to see/buy/sell books that are for sale in that country.
I have come up with 2 solutions, but none of them are quite good:
Location decides country.
User selects the country from a list.
I would like to hear your thoughts on this, since lots of apps do this - but I can't figure out how.
Why not a combination of both? Try the location services first, if for whatever reason they have location services turned off or don't allow it, have them select their country. The country selection should be one of the first prompts they are given when they open the app (if location services aren't on). Otherwise, before they are allowed to post any books for sale. In other words they shouldn't be allowed to put a book up for sales without the app knowing which country they are in.
Are you using swift (what version) or objective-c?
https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLLocationManager_Class/
You'll need a list of countries: How do I get a list of countries in Swift ios?
If you are willing to pay some. You could look at a ip based Solution like the www.maxmind.com api. It Gives country info and more. And we bought 50.000 queries for 50 dollars. And as we check once per user, we did not even finÃsh our bought queries!
I believe your application should do a guesswork and provide easy-to-use alternative for the case when the guess was incorrect. Get the country by location or IP. When the user installs the app, show the selected country and make sure your user can easily change it both in the installer and in the app itself (if, for instance, one student moves from a country to the other).
I have a site for a hobby im working on that has restaurant reviews on it. I want users to be able to add new restaurants in as well as edit the info on other restaurants which they may or may have not added to the site. I am not sure what the best way to approach this is. I have a few options I have thought of, but I'm not sure.
Only allow restaurants that are on say google places
main concern with this approach is if a restaurant a user wants to go to isn't listed on google places then what
Allow users to manually add in restaurants and check google places and fill in pertinent info like address phone if not on google places then let user add all info in manually... if is or is'nt on google places still have to manually accept restaurant to the site
the main downside of this is I may have to spend tons of time making sure a restaurant is real or isn't real
Anyone have any ideas?
also i am running rails should i just use a versioning gem to achieve the request an update so that way i can moderate updates or new restaurants...
I am no Ruby guy, so I will not comment on that part. But depending on the size of your user base I would solve it by user moderation or do it manually. If you haven't got that many users moderating the new entries should be feasible and if you got many users it should be possible to accept any new entry and then allow users to flag bad entries like it is done here on SO or on foursquare or Facebook Places.
Of course you could choose to accept anything available on Google Places, but only allowing entries that can be found there would make it annoying for users to enter new info which would discourage them from doing so.