I would like to make an emailing in my symfony project.
The user admin log-in in the backend and click on the button "start emailing", then 8000 emails is sending (2 per second). The admin user can close his page and go back a few moment later to see the emailing's progression. (10%...., then 20%... etc).
How can i do ? I think a have to use CRON TASK, but i'm not sure...
Maybe there is a better/other solution ?
Can you explain me the best way to program my emailing ?
Thanks, and sorry for my english!
The best way to rate the sending would be setting your MTA to do that for you. If it's a application requirement then go for Gearman. There is this awesome wrapper for the PHP interface (http://www.symfony-project.org/plugins/sfGearmanPlugin). It works really well.
Cron tasks do not know if the previous running instance has finished the job. It really messes thing easily up. For those cases, like yours, that you need to back processing, the best choice is a solution like Gearman.
Related
I've got two applications: Interface is a Rails app and Processor is for bash scripts.
I need to notify an Interface user's session if a bash process on Processor fails. I have access to the command line on Processor, so I can hit http://interface.com/process/12/error/:error_message with :error_message set on Processor.
I'm not sure how to make that work though. That route works from the browser, but I don't know how to redirect the user with the error message.
Any help would be great.
Thanks.
To answer this, I am going to make some assumptions about your setup. Please correct me if I don't have it right.
I assume that your Interface user is monitoring your site by visiting a page such as http://interface.com/process/12/monitor on the Interface server and you want the error message to pop up to let them know something went wrong.
Given that, consider having your call to http://interface.com/process/12/error/:error_message store the error in a related ProcessError table. Then, use javascript on the monitor page to poll the Interface server for "new" errors. The polling interval really depends on the situation. If you're the only user, every second would be fine, but if there are going to be lots of monitoring users at once, you would probably want to make the polling interval longer. How long depends on load and how important it is that the user is notified quickly.
A push solution would be more efficient, but is a bit harder to accomplish. If this is appealing to you, have a look at Faye, a publish-subscribe messaging system that supports Rails servers and html+javascript clients.
Hopefully this points you in the right direction!
I was wondering how I would go about updating my passes. I already know I need a webServiceURL (which I assume will be your IP address or one set on Ruby on Rails or something) and an authentication token. I'm more focused on how I would actually, physically update it. Is there an easy way out of this? Sort of like those iPhone app creating websites (but you don't professionally code it). I'm going to look into it more, but there aren't too many resources on the internet to choose from (that are useful).
If you are looking for a WYSIWYG, point and click solution, you might want to check out our service PassKit.
To see how updates work, you can start with this demo pass, flip it over and push yourself an update. You can import the template for the demo direct into the pass creator, edit it, and be pushing updates to your own passes within 5 minutes.
We also have a fully functional API that allows your to update and push a new pass your pass in a single call, E.g.
https://api.passkit.com/v1/pass/update/template/yourTemplateName/serial/yourPassSerial/push/?field_value1=newValue&field_value2=newValue2
If you want some code to get you stated, you can also access the source code to our pass creation pages.
If you are going to roll your own, I would use passbook-ios or something like that which is a Ruby Gem. If you want to use a service Urban Airship has one....though the pricing is a bit expensive at 10 cents a pass.
Lance
We are looking at setting up an internal web application (ASP.NET MVC) as a kiosk for the employees that don't have a dedicated computer. We currently do not have this kiosk setup. Each employee will have their own login to look at some basic payroll information and request leaves of absence. This same web application will be used by the office workers with a dedicated PC at their desk.
I am going to go out on a limb and say that no matter how many times we tell the employees, the employees will not click log off when they walk away from the kiosk. What would you do to help prevent this from happening?
lets try to fix the users instead of the code :) , i guess that your log out button is like the one here on stackoverflow. its a little text link "logout" some where in the upper right corner. thats perfect for people who use webapps day by day and are aware of the fact that they need to logout before someone comes along a does havoc to thier facebook profile, but less tech savy users wont think of that and walk away.
you need to the get the attention of your users to this logout-button and teach them that logging-out is a good thing.
try the following
give the logout button more visual weight then usally make it bigger, make it a real button instead of a textlink and even change its color to something more alerting (red, orange, ... whatever fits your ci)
if they dont loggout, use the session timeout and some javascript the refresh the page after any amount of inactivity, but also set a flag that this user has not logged out after his last visit. that way you can greet him on his next login with a nice confirmation dialog, and tell him once again why logging out is so important and where your logout-button is located.
The naive solution would be to enforce a timeout. If there's no activity from the user within a certain time limit (say, a minute or so), log them out. Of course, this won't prevent someone from walking up immediately after an employee is done and seeing how much money they make.
ATMs handle this, I think, by timing out after a minute or two, which isn't super-secure but at least offers some minimal security.
If the employees have any kind of RFID card or other security token, you could require them to put it in a reader slot, and log them out whenever the card disappears. Handling this within a web app, though, could get complicated.
The simple way is to use a little javascript.
Just have it set to something like 30 seconds of inactivity. If the user hasn't clicked on anything have the javascript send it back to a login page.
Here's a link to get you started.
Assuming you've already thought of the obvious (aggressive session timeouts, non-persistent authentication cookies, etc); how about a bit of an "out there" suggestion?
I'm not sure how do-able this would be with a web-based interface; but what about using some form of IR sensor with a usb/serial interface and an API you can tie into? This may make it possible to invoke some form of "logout" operation when someone walks away from the kiosk.
Perhaps someone has a better suggestion for external hardware, but this was the first thing that lept to my mind as a out-of-the-box approach.
I found a jQuery version that seems to work quite well. I'll start by using that and see how that goes.
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.
We would like to implement a feature by which users could send an email to an application specific address and we will parse the message and take certain actions on it, similar to 37signals's backpack (and probably some of their other apps).
If anyone has done something similar, could you fill me in on how you did so? I'm unsure on how to, at a high-level, 'import' the email into the app so that I could process it.
Thank you.
I have recently implemented that exact functionality in rails. I would advice you to look at the 'Receive E-mail Reliably via POP or IMAP' in the the Advanced Rails Recipes book.
I've personally found that the best source for getting this up and running and it explains how to do far better than I can. Good luck which ever way you choose to do it :)
Here's how I fetch from a POP server:
require 'net/pop'
pop = Net::POP3.new('mail.yourdomain.com')
pop.start(account, password)
pop.each_mail do |m|
email = TMail::Mail.parse(m.pop)
email.base64_decode
OttoMailer.process_email_in(email, m.unique_id)
m.delete
end
pop.finish
Why not run a Ruby SMTP mailserver, which will receive the mails via port 25, and then you can parse/interpret etc. as you wish ?
(I say Ruby since that's how you've tagged your question)
An alternative solution is to run procmail (or similar), pattern match on the subject, and then invoke scripts (configured in the .procmailrc file). However that may not scale so well for large volumes of mail.
ActionMailer can receive e-mails as well as send them! I don't remember how this is done but if you look at the documentation you can see it there. But from memory the e-mail gets piped through procmail into a script in the script directory.
There seems to be a book on the subject as well.
Good luck! :)