Create a "playable demo" of a Rails site?
This is quite common on sites - you have a demo with a guest account full of data / messages / comments that you can play with, and all the data is reset every few hours, so users won't spam the demo site.
I thought I have another rails environment "mysite_demo" and use a cron job to call rake to reset its database every X hours and populate the seed data.
Then he hit me all over my application, I will need to check if I am running in "demo mode": For example, if the demo site also has a login / registration page, the user can register, insert some details and wonder why his the account is deleted after re-login. Therefore, the demosite should not have a registration parameter at all.
So, I thought I was creating a "demo" branch of code .. with a difference and just changing the changes as I go ... sounds like overkill.
ideas?
source to share
In my application, I started with a fixed demo user with an account that resets every hour. Something about this model isn't quite right: if multiple users hit the demo at the same time, you might run into some strange concurrency issues. What if a user is in the middle of a demo and your demo account is reset? What's happening?
I don't know if this model works for you, but I created a completely new user account with the demo flag set in the database - I also auto register the user. This way the user gets to play around as long as they like and I don't have to worry about the data being deleted / changed when the user dismounts my application. I run a cron job every night that removes users with the demo flag set that is over 24 hours old.
source to share
Then I managed that throughout my application I would need to check if I was running in "demo mode" (for example, you cannot register a new user in the demo) and make the site accordingly.
If the site is in demo, why does it matter what users do? Anything they do will be wiped out after a few hours, so they can't really work with it.
It looks like you are trying to prevent the site from getting paid. I don't know what your site is doing, but if its a host-based service (a web page that stores and displays information) then the limited lifespan of the data should keep squatters away.
If your site does something that can be used elsewhere, then I can restrict it. An example would be a service that converts media formats or writes resumes. If the user can do something useful in the 2 hour window and get away with it, then you might consider branching.
source to share
Is there any other functionality different from the demo than the production one? If it's just a matter of user registration, you can simply create a registered demo account in production and give out a username / password to people. Although this may not be an option depending on other business requirements.
source to share
Just create a separate demo site that works exactly the same as the production site, but the DB gets reset once an hour to clean up the sample data. The only change you need to make is the banner at the top of each page that talks about the demo. There are several ways to do this (change the theme of the site, or perhaps use frames), but basically you will only need to change the code in one place, not the whole site.
source to share
You can set up a new demo environment on your database.yml, with read-only privileges on the User table and an additional demo base. Then put some code checks to see if your RAILS_ENV is in DEMO.
This way you only need to work with the same code base and just show whatever you like.
source to share
You can deploy it as a standalone application with its own database to a separate domain or subdomain and then check the domain to decide what options should be available. For example, if you put it on demo.example.com, you would use:
if request.domain =~ /demo/
If you are using Capistrano, you can configure it to update both applications on deployment so they stay in sync.
source to share