Not sure how to go about this problem that I have. In my website, visitors will look at my product catalogue and place orders, leaving behind their email for contact. I would like my website to automatically process their product's detailed report and store in a temporary folder for 24 hrs. The link will then be emailed to them with a one-time-password. 24hrs later I want the folder removed from my server.
I believe there are website that work similarly.
Question is: Is there anyway that I can program a script to remove folders that have reached their expiry time (24hrs in this case) since the time it was last written to? Or do I have to personally station myself at the server to delete off this folders everyday?
There is number of way to do this, you can use background process, check the expiry when user requests a report or the simplest solution - cron job. Not sure what technology do you use, but this should be a nice tutorial for PHP:
http://net.tutsplus.com/tutorials/php/managing-cron-jobs-with-php-2/
With ruby on rails you have nice cron support and a railscast explaining it:
http://railscasts.com/episodes/164-cron-in-ruby
Related
I've been using Bitbucket for a week now. It seems like a capable platform. Personally in my development activities, I keep a daily "journal" of whatever I need to keep track of separately from any commits to the Git repo. It gives me a place to keep all my "thoughts and ideas" in one place.
Before I end a day's work, or I jot down what I last worked on and any thoughts I think I'll need on the following day. And before I begin each day's work, I just flip to the last page of my journal and it quickly brings me back up to speed of where I was at yesterday, no matter how little sleep I got. :-)
I see Bitbucket has "Comments", "Work Log", "History" and "Activity", but they seem to be tied only to user stories, todos and the like.
Does anyone know of a way where I can have something like a "Work Log" tied directly to my user account? I'm thinking I could use it for my personal "Journal".
Note: I'm using a locally installed Bitbucket server.
If you're using the online https://bitbucket.org (not specified in the question) rather than a hosted instance then you can do a couple of things.
1 Wiki
Create a repository which will act as your work log
Obviously if you want to keep notes with the same code base just enable the wiki for that repository. The question seemed to suggest you may want to be repository/project agnostic
Update the settings of the repository to enable a private or public wiki
This is probably the simplest and richest replacement to your note pad
2 Use a repository
Create a repository which will act as your work log
commit Markdown (i.e readme.md or index.md) files
Note: in the case of a hosted instance this could even be a repository associated to your user rather than a project.
This is very manual, though it does mean you can have an offline version of your "pad" that you can edit/search in your IDE with some IDE autocomplete. Just like the wiki you can use the code backtick escapes with syntax highlighting. Last I checked the these were rendered pretty well in the browser through bitbucket.org as well as any editor/IDE you might use.
Regarding todo's
I've found the best cheap todo solution for me is using a gist as described on life hacker. They are low ceremony and versioned which checks all my boxes (excuse the pun). If you couple that with the above you may actually be able to embed it into your bitbucket wiki, though I've not tried.
If you are using JIRA and Bitbucket already, maybe consider Confluence? Confluence has some convenient and easy to manage TODO functionality and it lets you expand on those thoughts with all the power of a wiki when you are done.
I keep a "TODO" page and additionally put the checkbox on any tasks in other pages. They are all aggregated together in a tasks view.
See:
https://confluence.atlassian.com/conf54/confluence-user-s-guide/managing-changes-and-notifications-and-tasks/managing-tasks-in-confluence
Im developing a azure website where users can upload blob and metadata. I want uploaded stuff too be deleted after some time.
The only way i can think off is going for a cloudapp instead of a website with a worker role that checks like every hour if the uploaded file has expired and continue and delete it. However im going for a simple website here without workerroles.
I have a function that checks if the uploaded item should be deleted and if the user do something on the page i can easily call this function, BUT.. If the user isnt doing anything and the time runs out it wont delete it because the user never calls the function.. The storage will never be deleted. How would you solve this?
Thanks
Too broad to give one right answer, as you can solve this in many ways. But... from an objective perspective because you're using Web Sites I do suggest you look at Web Jobs and see if this might be the right tool for you (as this gives you the ability to run periodic jobs without the bulk of extra VMs in web/worker configuration). You'll still need a way to manage your metadata to know what to delete.
Regarding other Azure-specific built-in mechanisms, you can also consider queuing delete messages, with an invisibility time equal to the time the content is to be available. After that time expires, the queue message becomes visible, and any queue consumer would then see the message and be able to act on it. This can be your Web Job (which has SDK support for queues) or really any other mechanism you build.
Again, a very broad question with no single right answer, so I'm just pointing out the Azure-specific mechanisms that could help solve this particular problem.
Like David said in his answer, there can be many solutions to your problem. One solution could be to rely on blob itself. In this approach you can periodically fetch the list of blobs in the blob container and decide if the blob should be removed or not. The periodic fetching could be done through a Azure WebJob (if application is deployed as a website) or through a Azure Worker Role. Worker role approach is independent of how your main application is deployed. It could be deployed as a cloud service or as a website.
With that, there are two possible approaches you can take:
Rely on Blob's Last Modified Date: Whenever a blob is updated, its Last Modified property gets updated. You can use that to identify if the blob should be deleted or not. This approach would work best if the uploaded blob is never modified.
Rely on Blob's custom metadata: Whenever a blob is uploaded, you could set the upload date/time in blob's metadata. When you fetch the list of blobs, you could compare the upload date/time metadata value with the current date/time and decide if the blob should be deleted or not.
Another approach might be to use the container name to be the "expiry date"
This might make deletion easier, as you then could just remove expired containers
My site lets people create database entries (which most rails apps do), and I realized that there's a huge drop-off from landing on the site to actually signing up to try it. Basically the service lets users build their own document by combining different components. I'm thinking about adding an interface where visitors who are not yet registered can try out the features (building stuff) and ask them to sign up at the last stage, when they're about to publish their document.
First thing that comes to mind is use HTML5 local storage, but then another idea came to mind: maybe I could create a temporary user whenever a visitor tries out the features, and then later remove them from the database if they don't sign in. I'm not sure if this is safe, but this seems like it might be easier than dealing with all the local storage issues.
What would be the best practice for this type of situation?
HTML5 storage would be an option, tho most likely a lot of client side coding.
Other options would be to have a duplicate table of these 'demo' documents which you can clear every now and again for users that did not sign up. You could also just store the document in the user session, as you don't need it permanently stored, and then store it in the database once they have signed up.
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.