The Rails team have announced that CoffeeScript and SASS will be defaults in Rails 3.1
Personally I think this is a great idea. In fact, this is one of the reasons why I like Rails so much – that I don’t have to spend hours/weeks researching and agonising over which technologies to use. It’s like delegating the decision to someone else. Someone smarter, more experienced and knowledgeable. And someone who’s delivered the goods in the past (ref DRY, REST, Convention over Configuration, MVC, testing etc)
Yes I’m a Rails nube, and most of those disagreeing with the decision are not, but I’ve yet to see a good solid argument against it. Most of the reasons seem academic, “Steeper learning curve”, “It’s your choice not mine” – reasons I don’t think are really that big of a deal. Nubes will defer learning the new tech till later, and those who don’t like CoffeeScript or SASS simply don’t have to use them… just as it is now with any of the other defaults that you might not happen to like (such as Test::Unit).
In this guide, we’ll look at moving a MYSQL based website to a new server. For the purpose of this guide, this step-by-step is for a vBulletin based site, but the principles are the same no matter what type of application your site is using (eg Drupal, WordPress, etc).
- Transfer our website files from the old server to the new server
- Make a copy of our database
- Transfer the database to the new server
- Set the database up to work on the new server
- Press the on switch!
XCache is one of the most respected php cachers around, so here’s a little how to guide that I wrote up as a reference for myself a while back. Hope you find it useful…
- Ssh telnet into your server as root user
- Grab XCache by typing:
Wait for package to download
There are lots of scripts out there that do a great job of backing up your MYSQL database – so why’s this one any different? And why does it deserve the ‘Ultimate’ label? Well, it…
- Is one of the few backup scripts that elegantly turns your site ‘off’ whilst carrying out a backup
- Stores a copy of your backup on your server
- Transfers another copy to a different server (offsite backup)
- Keeps a month’s worth of backups
- Sends you a nice report each day with detailed stats on how long each element took
- Works with any site regardless of application, e.g. vBulletin, IPB, WordPress, Drupal, etc
The backup will take place every day, and simply overwrite the previous month’s backups, and as some months have 31 days, you’ll have that extra bit of contingency too. I’ve opted to create a guide on how to create this script rather than just give you the files and let you get on with it – it’ll help you understand what’s going on, and give you a warm fuzzy feeling inside! (Not a hands-on type of person? Want someone to configure/set it all up for you? Scroll down to the end of this guide for more info!)
Part two will show you how to create a backup of your files too (e.g. image uploads) complementing this script perfectly, so stay tuned!