The fundamental point is that Mobile Safari is not the only web browser available on phones and if you are serious about providing mobile web to your users, then developing for the other 85% should be part of your modus operandi.

However (and there's always a however!) it's not easy. It's trivial for me to have multiple web browsers and multiple operating systems on one computer for testing. It is not trivial for me to have 10 phones with different browsers and screen sizes. We don't do enough mobile work to justify the costs.

What actually annoyed me was Rentzch's response. Rentzch started by saying that Koch's argument was "stupid/lazy/undisciplined" and then goes on to say:

I see a quiet revolution of mobile developers waiting for other phones to catch up to the iPhone.

and

I think mobile developers intuitively grasp that accommodating the insufficient software+hardware of non-iPhones out there will only prolong the status quo, extending needless suffering for developers and users alike.

That's exactly what we all said when we wanted Netscape 4 to die because IE was so much better. Rentzch has made Koch's point for for him whilst trying to disagree.

For what it's worth, I think that any mobile device manufacturer who wants web developers to develop for their device's browser, should provide hardware that doesn't need a plan. It doesn't even need to be a phone. Mobile Safari is the easiest mobile browser to test against as it's available in the iPod Touch.

As a result, I have updated my Zend Framework tutorial so that it is completely current. The main change I made was to remove the _init methods in the Bootstrap as they are no longer needed. I also take advantage of the new features of the zf tool to enable layouts and create forms. It's a shame that it gets the class name of the form wrong though!

Windows

On Windows, the mail() function uses SMTP over port 25. Unless you've changed your php.ini file, then it will try to connect to localhost in order to send an email. On Windows VM, I use Fakemail. This is an SMTP mail server written in perl (or python) that store emails as files into a given directory. When your web application sends an email, you check in the directory and look at the files created. One top tip: alter the script to give each file a .txt extension. Then you can double click :)

Fakemail is also very useful in Linux/Mac if you are using the SMTP transport mail in Zend_Mail or Swiftmailer or whatever.

Linux / OS X

On the *nix based systems, mail() sends email using an application on the system called sendmail (or any number of compatible alternatives). By default it will call the sendmail binary, however you can change this in your php.ini with the sendmail_path setting.

I set my development boxes like this:

sendmail_path = /usr/local/bin/trapmail

Now, mail() will call my trapmail script. This script is trivial:

formail -R cc X-original-cc 
  -R to X-original-to 
  -R bcc X-original-bcc 
  -f -A"To: rob@akrabat.com" 
| /usr/sbin/sendmail -t -i

This script causes all emails to be redirect to my email address with the original to, cc and bcc fields renamed in the headers, so they can be checked!. I like this solution even better than Fakemail as it's easier to see exactly what the mail looks like in a mail client, especially for HTML format.

I just wish I had thought of this script myself! However Sean Coates came up with the idea in 2005 and I've been using it every since.

If you need to know whether a view helper exists before you call it, one way is to write a simple view helper to tell you:

class App_View_Helper_HelperExists extends Zend_View_Helper_Abstract
{
    function helperExists($name) {
        return (bool)$this->view->getPluginLoader('helper')->load($name, false);
    }
}

You can then use it in a view scripts like this:

<?php if ($this->helperExists('doMagic')) { echo $this->doMagic(); } ?>

As Jeremy mentions in the comments, this code came out of a discussion on the PHPNW IRC channel #phpnw

In my case, I wanted to create a resource for CouchDb that checked that the database was created and if not, create it.

Creating your own plugin is easy enough. The obvious place is library/App/Application/Resource and a typical resource would look like this:

class App_Application_Resource_Couchdb extends Zend_Application_Resource_ResourceAbstract
{
    /**
     * Defined by Zend_Application_Resource_Resource
     *
     * @return Phly_Couch|null
     */
    public function init()
    {
         // do stuff here to init CouchDB
        $options = $this->getOptions(); 
        // $options contains everything under 'resources.couchdb' in application.ini
    }
}

You then need to tell Zend_Application about your new plugins. This is done with this line in application.ini:

pluginPaths.App_Application_Resource_ = "App/Application/Resource"

You can now have as many resource plugins as you like within the App_Application_Resource_ class-space.

Also, Matthew Weier O'Phinney has also written an article on Zend_Application which you should read too.

The easiest way, given a ZF project created using Zend_Tool is this:

Create /index.php

<?php 
define('RUNNING_FROM_ROOT', true);
include 'public/index.php';

This uses the index.php already created by Zend_Tool and means that we don't have to change anything if we move to a VPS host where we can set the DocumentRoot directly to public/.

Create /.htaccess

SetEnv APPLICATION_ENV development

RewriteEngine On
RewriteRule .* index.php

We create a .htaccess file that redirects every request to index.php. We want to do this so that no one can try and read application/configs/application.ini. Obviously, set the APPLICATION_ENV to the correct value!

Referencing public facing files

Having created a very aggressive, rewrite rule, what about CSS/JS/image files though?

Fortunately, we already have a .htaccess file in the public/ folder that correctly handles this situation. As Apache will execute the .htaccess files in the deepest directory it finds, any reference to a public facing file within the public/ folder will correctly be served.

You do have to be aware of this when referencing public facing files though and add the /public to the baseUrl yourself.

For example, you may set up your CSS file and other view settings within a Front Controller plugin like this:

class App_Controller_Plugin_View extends Zend_Controller_Plugin_Abstract
{
    public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
    {
        $frontController = Zend_Controller_Front::getInstance();
        $view = $frontController->getParam('bootstrap')->getResource('view'); 

        $view->doctype('XHTML1_STRICT');
            
        $baseUrl = $request->getBaseUrl();
        if (defined('RUNNING_FROM_ROOT')) {
            $baseUrl .= '/public'; 
        }
        $view->headLink()->appendStylesheet($baseUrl . '/css/main.css');
        $view->headLink()->appendStylesheet($baseUrl . '/css/screen.css', 'screen');
        $view->headLink()->appendStylesheet($baseUrl . '/css/print.css', 'print');
    }   
}

(This code assumes you have added a resources.view[] = "" to your application.ini)

As we have a constant that tells us if we're running from the root, we can dynamically add the /public into the URL. If we change to a host where the DocumentRoot is set directly to the public/ folder, then we don't need to change our code.

That's it. Your Zend Framework application works nicely with shared hosts.

I'll be concentrating on Zend Framework with a tutorial called "Building a Zend Framework application" and a talk on "Working with Zend_Form". After a couple of less technical talks recently, it'll be fun to dive into strongly technical content. Hopefully, I'll be able to explain Zend_Form well enough that people will understand it too!

I didn't know much about git at all before reading the book. I do now :)

It turns out that git is fairly easy when you have a good explanation of how to use it. The book starts from the basics of what version control is, which I already knew. It was good to see equal coverage of how to set up git in Windows, OSX and Linux. I was aware that Windows support wasn't prime-time, but at least doable with msys.

The bulk of the book covers how to actually use git and this is where I learnt enough about git to actually understand it. There were two main surprises for me:

• You need to re-add a modified file every time you want to commit it. This puts it in the staging area. Fortunately the -a switch to git add will auto-add for you!
• Directories are not stored under version control. It's like CVS :)

Other than that, it's just like Subversion, only faster! (You also have that distributed thing going on.)

I suck at reviewing.

Pragmatic Version Control Using Git is a very good book if you want to learn git.

It's even better as a reference book as you can actually find things in it too.

If you want to know all there is to know about git, then get this book.

Even the paper feels good in your hand when you turn the page.

January

Other than the snow, The big thing that happened in January was that an article I wrote was published in php|architect.

February

We had daffodils in snow at the start of this month and then towards the end, the PHPUK conference took place.

March

Spring arrived in March. The Severn Valley Railway had its Festival of Steam gala, and I took a day off so that I could photograph it.

April

A month of punctures. I went to a Microsoft community event in London too.

May

This is birthday month in our household. It was also our first trip away camping this year.

June

What little good weather we had this year, was in June. I popped up to Manchester for a PHPNW meet. DPC 09 was also held in June and I spoke on caching.

July

We finished decorating the living room in July. We also had a week's holiday in Wales.

August

I started using a Wacom tablet in August as I was getting a pain in my wrist. August is school holiday month, so we went away for another week, to Cumbria.

September

We sold our Pathfinder in September and didn't do much else. I took the kids to visit to the Gloucestershire Warwickshire Railway during the month too.

October

PHP Conference season started again for me with PHPNW 09. I spoke on project management.

November

Another month, two conferences! ZendCon 09 where I gave a tutorial on the Zend Framework certification and spoke on project management. I also visited Alcatraz. IPC 09 was also held in November, where I spoke on caching and deployment.

December

The final month of the year saw me working way too hard. We did take the kids to see Santa though.

Here's to 2010!

Automate your Deployment is a look at how to automate the process of deploying your application to the web server. At my company we started automating our deployment systems just over a year and the number of issues we have around deployment of new code to a website has dropped considerably and is no longer a stressful event.

If you aren't currently using an automated deployment script, I can't recommend highly enough that you set yourself a New Year's resolution to investigate the options and implement a system for yourself.