See in HD and fullscreen!
Original blog post here.

First I found out the best way to avoid problems with routing urls beeing not cached - especially when using Router::mapResources() - is to enable the caching per action in the controller like this:

function view($id = null) {
$this->cacheAction = "10 minutes";
// more stuff
}

The next problem was that cached views don't retain document mime type (xml, json, etc.). The first request works correctly (uncached request), but the second request will come back as text/html. You can find a more detailed description of the problem here.

I got an advice to enable callbacks for my views but that slows down and defeats the purpose of the cache. My approach now is to use a layout like this:

With the header('Content-type: text/x-json'); embedded in the nocache tags, it works fast and returns the correct mime type.

• Development-Server XDebug enabled, APC enabled, View cache disabled:
  Requests per second: 1.64 [#/sec]
• Development-Server XDebug enabled, APC enabled, View cache enabled (files):
  Requests per second: 29.04 [#/sec]
• Development-Server XDebug disabled, APC enabled, View cache enabled (files):
  Requests per second: 95.66 [#/sec]

Further reading
8 Ways to Speed Up the Performance of CakePHP Apps.
Store View Cache in APC or Memcached.

Another helpfull resource is: Understanding Git Conceptually and gitref.org

This is a refresh of the original Social Media Revolution with updated statistics and images. Created by author Erik Qualman and based on the #1 Best Selling book Socialnomics.

Social Media Revolution 2 (Refresh) from Erik Qualman on Vimeo.

I have made a rough comparison for the classic "on demand" small instance against the new reserved instance:

On Demand Instance:
$0 + (365*24*$0,10) = $876/year = $73/month

Reserved Instance 1year:
$325 + (365*24*$0,03) = $588/year = $50/month
Saves you $288/year or $24/month.

Reserved Instance 3years:
$500 + (3*365*24*$0,03) = $1288/3years = $430/year = $36/month
Saves you 446 $/year or 37$/month.

Here's the offical FAQ on using Reserved Instances. And here's a funny but critically blog post about the "single commandline that can costs you losts of money". I think Marc Musings is right and I wish that Amazon would improve this because I had the same bad emotions with this "new API feature". It would basically a good idea to have alerts and/or limits for charges, instances and traffic.

Can't wait for reserved Instances to be available for the EU region... "in the near future" as Amazon promised... Happy emotions when spending big money with ec2-purchase-reserved-instances-offering!

UPDATE 09-08-21: New Lower Prices for Amazon EC2 Reserved Instances and I'm also happy to see that one of my EC2 instance hit the 500 days uptime mark.

According to Debians Upgrade instruction and it's "How to recover" section, the problem can be caused by new naming conventions for IDE disks.

This problem can occur when the upgrade of the kernel introduces the use of the new generation of IDE drivers. The IDE disk naming convention for the old drivers was hda, hdb, hdc, hdd. The new drivers will name the same disks respectively sda, sdb, sdc, sdd. The problem appears when the upgrade does not generate a new /boot/grub/menu.lst file to take the new naming convention into account. During the boot, Grub will pass a system root partition to the kernel that the kernel doesn't find.

This seems like to be very common reason for these "Waiting for root file system" troubles that many faces now when upgrading to Lenny. But in my case I allready had the new sda* names in the grub/menu.lst and /etc/fstab. The "solution to recover" did not work.

The virtual lenny server with the new kernel images that fails to boot was hosted by VMWare Server 1.0.3. For a nearly the same upgrade process (etch to lenny) hosted on FMWare fusion 2.0.2, I did not have these problems.

Solution: My VMWare Server 1.0.3 was out of date and had a known vmware bug that caused this error. Upgrading to the latest version (now 1.0.8) solved the problem.

Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!

In "/etc/nagios3/nagios.cfg" the "check_external_commands=1" was already set. So there was something more required to make it run on Debian...

Deep in my memory I know that there was a debian way to solve this user right related problem. This time I'll write it down here - perhaps I'll find it more easily when I upgrade to Debian GNU/Linux 6.0 (codenamed squeeze) and/or Nagios4.

/etc/init.d/nagios3 stop
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start