A simple Amazon SNS client in PHP
After reading the announcement for the new Amazon AWS product, Amazon SNS (Simple Notifcation Service) it seemed like a great idea, though there is as yet no PHP sample code provided.
If you've not seen it, it's a cloud notification service - it allows creation of "topics" (think a mailing list / channel) and management of subscribers to the topics. Interestingly subscribers don't have to be just email - they can be http / SQS subscribers too. However, I'm most interested in the email functionality.
I've written a simple client in PHP which I've put on github - you can get it here. Please note, it's about an hours work and doesn't include any error checking at all...but it works.
Enjoy.
Checklist : 7 critical pre-website launch things to check
This is a pre-launch checklist - things a developer probably needs to get ready before the big day (ideally long before).
It's critical to prepare for the launch before the last minute day. So, the list:
1. The domain
You need to have either bought the domain or if its already registered have access to the DNS settings so you can alter them. If you the domain already exists and you don't control it's DNS, you'll want to ask you client for the access details - or ask their I.T. department to prepare to change.
Why its critical : its the lynch-pin for the whole affair, no access means you can't set your site live come launch day.
Also, find out the DNS's TTL, some free DNS providers have these set long - meaning the time for a complete change over globally is longer. If you want to get around this you can change the name servers - mirror the current DNS settings - to a better DNS provider.
2. The server
Have the details of the hosting been given to you? Have you checked that any modules / services / software that is required is installed? Does Apache / Lighttpd have the correct modules?
Why its critical : It may work on your development server, but if you've not installed that important module on the live server, its not going to work.
3. The SSL
If your project is for an e-commerce website or something else that requires security its likely you'll need an SSL certificate. Does your client have one already? You may be able to reuse it. Installing it on your development server (& using your hosts file to check it works correctly) will let you test for any oddities with your software - cookies / sessions / etc.
Why its critical : Some SSL certificates can take a while to actually get provisioned - the certificate authority may want you to jump through quite a few hoops before issuing it. Best to get this one out of the way early.
4. Migration script
If your upgrading a site which already exists you'll likely have user data. You'll (probably) therefore need to write a migration script from the old schema to the new one. Testing your script against last nights live database backup is good practice - I usually automate this and run it several times a day whilst testing. It helps iron out any bugs.
Why its critical : Loosing users data is highly likely to annoy them, loosing you custom. Also, if you botch a migration an set the site live you may end up having to either unstitch or loose data to switch back to the old version.
5. Test launch
If possible - test launch. If your hosting on a brand new server run through the launch, set up the server, run your migration, use your hosts file to point the domain at the server and check it.
Why its critical : if you can do this step, your much less likely to encounter problems on the day - as you'd have found most things wrong before hand.
6. The schedule
When is the site going live? In the evening? I normally prefer to do launches early in the morning as I'm awake and will be if there are teething problems during the whole day. However, make sure that you check when your peak traffic is during the week / day as well.
Clients often seem to want to launch at the end of a week - this in my opinion is not a good idea as most people don't work weekends.
Why its critical : Having a smooth launch which affects as few people as possible is always nicer to your visitors (aka customers?) which they'll love you for.
7. The disaster plan
Whilst its never something we want to happen, sometimes it does. Best to plan for it then!
- Is it possible to cut back to the old site - if so, how?
- Take backups before you attempt to go live - they'll be useful if it all goes wrong
- What counts as a disaster - when should we roll back? (i.e. if just SSL didn't work, can we live with it whilst we fix it?)
Why its critical : Unexpected things happen. Planning for them helps, you'll only have to do it on your feet otherwise.
Hopefully you'll find this list useful - I'll be making a few more lists as time goes on - I'd love to get some feedback from your own experiences.