Keeping Chromium updated on your Mac
This is a quick shell script which is how I make sure I keep the latest nightly version of Chromium on my Mac without much hassle...
#!/bin/sh
rm -f chrome-mac.zip chrome-mac
export CHROME_VERSION=`curl http://build.chromium.org/buildbot/snapshots/chromium-rel-mac/LATEST`
curl http://build.chromium.org/buildbot/snapshots/chromium-rel-mac/$CHROME_VERSION/chrome-mac.zip > chrome-mac.zip
unzip chrome-mac.zip
rm -rf /Applications/Chromium.app
mv chrome-mac/Chromium.app /Applications/Chromium.app
rm -rf chrome-mac chrome-mac.zip
Paste the above in to a file and then execute it with 'sh filename'.
MongoDB London 2010 – why you should have gone!
- Image by hoerner_brett via Flickr
Friday was awesome; a combination of geeks, MongoDB, Pizza, Beer & free swag.
I wasn't expecting the MongoDB London conference to be quite as good as it was, but it was really insightful and useful for non beginners. We learnt about proper indexing, useful tips on indexing and schema design as well as doing some hacking with some fellow conference goers.
The schema design talk showed us the advantages and disadvantages of various ways of structuring documents, and highlighted some general things to watch out for.
I found it particularly interesting that, for instance, if you nest things like comments (for threading) that indexes need to be made for each level of the nest - which makes sense when you think about it. However, this means that if you are trying to retrieve all comments written by a particular user, multiple indexes won't be used.
Also, if you were designing a system which coped with a large number of replies / comments, for instance a forum you may hit the 4mb document limit for a single thread.
Sides from NYC conference, as the London ones aren't up as of writing this:
A talk entitled "Approaching 1 Billion Documents" gave us some insight about how MongoDB scales and reminds us that you can have a maximum of 24,000 collections per database at the moment. Not that this should pose a problem for most of us. You can view the slides here:
Other talks, such as ones on general administration were also insightful - it's nice to hear about the different backup strategies and ways of checking what is currently running on your database.
For instance;
db.curentOp()
lists which operations are currently going on in the database, you might see whats blocking, whats being indexed etc.
Statistics wise,
db.collection-name.stats()
will give some insightful information about a collection - such as what indexes exist, how much space they take, how many documents are in the collection, etc.
Also, if you're interested in seeing who attended, have a look at my Mongo DB London 2010 Twitter list - it covers most people from the day.
Related articles you will enjoy;
- State of MongoDB March, 2010 (mongodb.org)
- Reflections on MongoDB (collectiveidea.com)
- Video: John Nunemaker talks about mongoDB (webpulp.tv)
- Introduction to MongoDB (slideshare.net)
Gearman & Kohana: An Introduction
Last Saturday, the 15th of May 2010, I presented at Kohana London 2010 - the first Kohana PHP conference in the UK. My talk was about using the awesome Gearman, came with some sample code written specifically for Kohana.
I've attached my slides as a PDF here, HTML version here and you can download the sample project from it's page on github!
Enjoy and feedback is most welcome.
Amazon S3 reduced redunancy service – is it worth it?
Amazon announced a new option for their S3 service today which allows a reduced GB/mo price (starting from $0.10 / gb / mo, rather than $0.15 / gb / mo) - the catch is reduced redundancy.
The redunancy is decreased from 11 9's to 4 9's, which is according to Amazon still (400x) more than can be expected from your typical disk drive.
What does this mean? Well, 99.99% equals less than 52.56 minutes per year of maximum expected downtime, where as 99.999999999 equals 315.36 microseconds per year or less.
Is your data worth $0.05 / gb / mo fextra for 52 and a bit minutes more uptime?
Here is the announcement as sent by Amazon;
We are pleased to introduce a new storage option for Amazon S3 called Reduced Redundancy Storage (RRS) that enables customers to reduce their costs by storing non-critical, reproducible data at lower levels of redundancy than the standard storage of Amazon S3. It provides a cost-effective solution for distributing or sharing content that is durably stored elsewhere, or for storing thumbnails, transcoded media, or other processed data that can be easily reproduced. The RRS option stores objects on multiple devices across multiple facilities, providing 400 times the durability of a typical disk drive, but does not replicate objects as many times as standard Amazon S3 storage does, and thus is even more cost effective. Both storage options are designed to be highly available, and both are backed by Amazon S3's Service Level Agreement.
Once customer data is stored using either Amazon S3's standard or reduced redundancy storage options, Amazon S3 maintains durability by quickly detecting failed, corrupted, or unresponsive devices and restoring redundancy by re-replicating the data. Amazon S3 standard storage is designed to provide 99.999999999% durability and to sustain the concurrent loss of data in two facilities, while RRS is designed to provide 99.99% durability and to sustain the loss of data in a single facility.
Related articles
- Amazon S3 Reduced Redundancy Storage (RRS) (aws.typepad.com)
- Google To Launch Amazon S3 Competitor 'Google Storage' At I/O (Jason Kincaid/TechCrunch) (techmeme.com)
- NetSuite and Amazon go cloud to cloud with SuiteStorage (v3.co.uk)
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.
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.