Amazon AWS announces versioning for their S3 service
Amazon AWS have just announced a new addition to their S3 simple storage service, versioning. After you apply for the beta program, you'll have the ability to enable versioning on a per-bucket basis, rather than per item.
Versioning will save you from accidental deletion of files and enable a few other interesting possibilities - there is even a new feature which prevents deletion of items with out a multi-factor authentication token (much like an RSA SecurID), which should be nice for accountability & preventing accidental / malicious removal of items by staff.
The announcement from Amazon themselves reads like this:
We are pleased to announce the availability of the Versioning feature for beta use across all of our Amazon S3 Regions. Versioning allows you to preserve, retrieve, and restore every version of every object in an Amazon S3 bucket. Once you enable Versioning for a bucket, Amazon S3 preserves existing objects any time you perform a PUT, POST, COPY, or DELETE operation on them. By default, GET requests will retrieve the most recently written version. Older versions of an overwritten or deleted object can be retrieved by specifying a version in the request.
Some further reading at Amazon's proposals, AWS forum announcement
Picking the best weekday for a website launch
Picking the best weekday for a website launch can be difficult. When considering it, there are a number of key things to take in to account:
Expected traffic / business volume
Launching on the busiest day of the month is not likely to be the best choice - a trail by fire can be risky especially for a major launch. Picking a quiet time of the month - check your sales & website analytics - will mean less lost revenue & annoyed customers and stress if things do go wrong.
Developer availability
Launching at the end of the week might seem like a nice way of finishing the week off - but teething problems might mean work over the weekend. This isn't good for keeping your developers happy!
Launching early in the week (unless of course this is your busiest period) is going to mean more normal working time to work on any (hopefully minor) issues you come across. Should there be a disaster, the whole team will be around anyway.
Support availability
Although your hosting provider probably does operate over a weekend, they are likely to have more staff around during normal working hours.
Phoning them before hand will be a good idea to make sure:
- There are no scheduled maintenance windows of their network, your server or any of their peers.
- If they manage backups that there is a current one (can't hurt to ask if you can't check yourself for some reason).
- They have staff around at the time you are expecting to launch and that they are aware this is happening - this is especially important if they monitor your servers (they may think something has failed).
Recommended Book : High Performance Web Sites
High Performance Web Sites is another book which we've found highly useful here at UKD1.
The book includes good advice from the guys who wrote YSlow for Firebug in the form of fourteen rules.
It's aim is to advise a front end developer how to improve the performance of your site - which in-turn will improve your visitors experience. A faster loading site means happier users.
Most of the rules are pretty simple to implement as well as being well cheap / free cost wise. Highly recommended.
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.
Recommended Book : High Performance MySQL: Optimization, Backups, Replication, and More
I got this book a while back after reading the authors blog - MySQL Performance Blog. The book is well written, full of helpful information and not for complete beginniers - which is a nice change!
It has has good sections on benchmarking, profiling, backups, security, as well as MySQL tools.
The last slice of Cake?
The lead developer of CakePHP, Nate Abele, today waved good by to Cake in a quick tweet about the project. Reports are that he is joining some of the Cake team working on a fork of Cake3 to be called “Lithium”.
Nate later confirms;
Yup, myself and most of the old team have spun off a new project called #Lithium (http://li3.rad-dev.org), based on PHP 5.3"
Awesome, another 5.3 framework - I'll be following Lithium's development as it occurs.
Symfony is one of the first major PHP frameworks planning to drop support for 5.2
Symfony 2.0 will leverage PHP 5.3 and drop PHP 5.2 compatibility. Big news - Symfony is one of the first major PHP frameworks to drop support for 5.2, though its not happening for some time.
Both the upcoming Zend Framework and CakePHP 2.0 versions will rely on PHP 5.3. And for Symfony, I said it will still be compatible with PHP 5.2. From my point of view at the time, it would be a mistake to upgrade major frameworks to PHP 5.3 now for one main reason: major frameworks are used by many big companies, and upgrading to the latest version of a software fast in such companies is not always feasible.
Symfony 2.0 is due to be released late 2010. Read some more on the Symfony blog.
New version of Lighttpd released – 1.4.24
- Connection state handling (pipelining should work now)
- FastCGI fixes: improved disabled-time handling, fixed bug in active-backends counter.
- TLS SNI support
You can download it from here, or read the rest of the announcement.
10 Essential Entrepreneurs to Follow on Twitter
Mashable have a great article on some of the best Entrepreneurs to follow on twitter - read the full article here, or if your lazy, we've made a twitter list for you.
Happy 40th Birthday, Internet!
On October 29, 1969, the first two nodes of ARPANET were interconnected between UCLA’s School of Engineering and Applied Science and SRI International (SRI) in Menlo Park, California. It took 12 years for 213 computers to get linked in the network.
Read more at Mashable : http://mashable.com/2009/10/29/happy-40th-birthday-internet/