I am working on an app where the user can log his working hours after he finished his shift. The app is developed in Ruby on Rails 4.I used the scaffold method, so it generated the necessary methods for create, read, update, delete. The fields are hours_worked:number overtime:boolean and date:datetime, for now, I plan to expand it later with more functionality, with user login and some other stuf. The model is empty, I did used the rake db:migrate method. Now I know that you can use the count method, as is shown on the official site for active record. I don't have the idea how to get the total number of hours worked and show it on the index page. Consider that I just started learning Rails. Any suggestions?
Sounds like this is best used with the Timers gem.
https://github.com/celluloid/timers
In your Sessions#new method, you'd want to initialize a variable to keep track of the current time. And then every so often, you'd use one of the methods in the gem to update the current time. You could then subtract the difference.
This is hard to answer without any info on how you are actually logging the info, or seeing any of your code. However if you are just looking for general suggestions you could just save start and stop timestamps and compare them. Or ask the user to input time worked. There are probably a thousand different ways to do this. Please be more specific on what exactly you need help with.
Related
I have a rails application running in which people can enter timesheets, get reports, ...: www.temponia.com
Now I would like to create a demo environment where users can experiment without the need of having to register.
I already found the gems faker and forgery to generate demo data. But my question is: when a user starts the demo environment, should I generate the data and write the data to the database? I don't want all users to share the same demo environment since one user can completely destroy the experience for other testers...
When I write it to the database, and delete it after a couple of days, aren't I running the risk that some tables will get really high identity values really quick? I would generate for example several thousand timesheet entries to make it look realistic...
Are there any other ways to solve this?
In my opinion, you should let the users do what they want to do, to show the completeness of the application, and let everyone share the same environment.
To repopulate your application, you can add some task every X minutes (depends of frequentation), to automatically insert data when it reaches a minimum threshold. See for example whenever gem to add commands in crontab.
https://github.com/javan/whenever
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!
This seems to be a common question, but I've yet to find a very 'detailed' answer - I'm looking for the best way to allow users to preview the form they are going to submit, before submitting it.
Obviously, storing this in the db isnt the best option (which is what I'm doing right now) because there has to be a process to remove it, and that has a lot of scenarios.
Details
I don't want to show the user the edit action, I want to show the user the show action, and at the top and bottom of the screen have a Publish button.
My questions:
How would you go about storing the information from the form into a session (looking for some controller code)
How would you know in the show action that you are displaying a preview, rather than a 'real' object. (or would you have a separate action for preview?) (looking for some controller/view code here)
How would you remove the session data once the user is 'done' with it?
I think that storing in the database has the same issue with storing it in the session, the cleanup, am I wrong? What is the best way to do this?
You can consider unpublished records created more than few days ago as obsolete (user must know about that policy). Rake task may be executed via cron once a day or more frequently. Also, you can implement some separate rake task to notify users about pending unpublished records, which will be removed soon. Drafts is a great idea and may be untouched if you like at all or for a longer time.
What is the simplest way how to check if user is online and display list of online users?
The only way I can think of is some periodic polling server to update last action timestamp, and when last timestamp is more than xx ago, user is considered to be offline. But it doesn't seem like too eficient solution.
Authlogic can do this by default, and is a great authentication system that is very powerful. I would suggest migrating your current authentication system over to it (maybe a days worth of work, depending how customized your system is).
If you can't (or simply don't want to) move your application over to Authlogic, you can check out the source code at the link above, as well as an example project here.
You could potentially check the session time, if you use database session store. When the updated_at extends past a certain time, assume the user is no longer active. This could be problematic as well, however.
Being honest, it's a somewhat difficult scenario to tell the active number of users without some form of periodic server polling. Your thought is not a bad one.
We can list the online users using active record session store, please see this github app https://github.com/mohanraj-ramanujam/online-users
It's quite common in sites- you have a "demo" version with a guest account full of data/posts/comments that you can play with, and all the data is reset every few hours so users wont spam the demo site.
I thought to have another rails environment, "mysite_demo" and use a cron job to call rake to reset it's database every X hours, and populate the seed data.
Then it hit me that all over my app I'll have to check if I'm running in "demo-mode":
For example, if the demo site has a login/register page too, a user might register, insert some data and wonder why his account is deleted after he logged in again.. so demosite shouldn't have a register option at all.
So I thought I'll make a "demo" branch of the code.. with the difference and just merge changes as I go... sounds like an overkill.
ideas?
In my application I started with a fixed demo user with an account that resets every hour. Something about that model didn't quite sit right - if there were multiple users hitting the demo at the same time you could get into some weird concurrency issues. And what if a user is in the middle of a demo and your reset the demo account? What happens?
I don't know if this model works for you but I ended up creating a brand new user account with a demo flag set in the database - I also automatically log the user in. This way the user gets to play around for as long as they like and I don't have to worry about data getting deleted/changed while a user demos my app. I run a cron job every night that deletes users with the demo flag set that are older than 24 hours.
If the demo version is running from its own database, how is it any different from the real thing? The demo site is just an instance of your product.
Just clean up the DB and redeploy the demo as needed. Is it just this simple or am I missing something?
Then it hit me that all over my app I'll have to check if I'm running in "demo-mode" (e.g, you cant register a new user in the demo) and make the site behave accordingly.
If the site is in demo, why does it matter what the users do? Anything they do will be wiped in a few hours, so they won't be able to actually do work with it.
It sounds like you are trying to handicap the site so they will pay. I don't know what your site does, but if its a host based service(web page that stores & display information) then the limited life span of the data should deter squatters.
If you website does something that can be used elsewhere, then I can see limiting it. An example might be a service that transforms media formats, or writes resumes. If the user can do something useful in the 2 hour window and walk away with it, then you might consider branching.
Why not allow the user to make an account even if it is deleted in an hour?
That allows them to see how the registration process of the script works for at least an hour, maybe give a message on the signup page that the account is only valid for an hour.
Just my thoughts
Is there any other functionality that is different in the demo version than the production environment? If it is just an issue of making the user register, you could just create a registered demo account in production, and give out the user name/password for people. Although this may not be an option depending on other business requirements.
If you are willing to use Authlogic you can take a look at this, then every X hours you can look through the database for users that start with anonymous_ and delete records that are associated with them.
Just make a separate demo site that works exactly like the production one, but the DB gets reset once an hour to clean example data. The only change you need to make is a banner across the top of every page that says its a demo. There are several ways to do it, (modify your site theme, or maybe use frames) but basically you should only have to change the code in one place, instead of throughout the site.
You could setup a new environment demo on your database.yml, with read-only privileges for the User table, and an additional demo_database. Then place some checks on your code to see if your RAILS_ENV is on DEMO.
That way, you only need to work with the same codebase and just show whatever you feel like it.
You can deploy it as a separate app with its own database to a separate domain or subdomain and then check the domain to decide what options should be available. For instance if you put it on demo.example.com you would use:
if request.domain =~ /demo/
If you use Capistrano you can set it up to update both apps when you deploy so they are in sync.