DaveDevelopment::Dave Marshall

Sometime last year, I, along with quite a few others, was asked to review one of
Packt Publishing’s new books, Zend Framework 1.8 Web Application Development, written by Keith Pope. They sent me a copy, which was very good of them and although it’s taken me ages to finish and get round to writing this review, that’s not a true reflection of how good the book was, I’m just a very busy/lazy person! So lazy, that I did in fact say I’d have it done in two weeks, which turned into 4 months.

Packt asked if I’d be interested in reviewing the book, so watch this space, I’ll be back in a couple of weeks with a review.

My Post dated 15/10/2009

Introduction

Design, develop, and deploy feature-rich PHP web applications with this MVC framework

That is the books strap line, and it does exactly what it says on the tin. The bulk of the book actually takes you through the design, development, testing and deployment of a real world example application, called the Storefront. The book claims that it is written for PHP web developers that are either using or looking to start using the Zend Framework and that a basic knowledge of Object Oriented design would be helpful. While you might be able to manage without any OOD experience, I’d say you definitely need some to get the most out of this book, as the second chapter digs right under the hood of the Frameworks MVC architecture. My personal experience was that I got to learn all the things I haven’t had time to learn, I’ve been using the Framework for a couple of years now, always appreciating, but not always understanding what it was doing for me.

MVC Architecture

The first chapter gives you a brief overview of creating an MVC application in the Zend Framework, experienced users of the Framework will probably want to gloss over this part, whereas people looking to start using the framework should take their time and take things in. The next chapter is when I really started to enjoy the book. Each component of the MVC architecture is presented as it’s own topic, with each component getting a breakdown of Design Patterns/theory, default settings/configuration, usage and finally customisation.

The chapter is well put together and considering the amount of information portrayed, is not overwhelming.

Storefront Application

The rest of the book provides the information you need about the framework around a real world example application, called StoreFront, which is a basic e-commerce application. I should point out that I didn’t code the application as I went, if I’m reading I like to read, but where appropriate I have used the book as a reference when updating my existing Zend Framework applications.

The best thing about these chapters though, is some of the design theory you pick up on the way, that isn’t directly relevant to the Zend Framework, but can be applied to any framework out there. Best practices such as Fat Models, Composition, Fluent interfaces are all explained in detail, along with relevant and realistic examples. Further more, the applications MVC separation is excellent, taken in context (it might be a little overkill for the example application, but is there to show you the methods).

After taking you through the creation of the application, the book then takes you into optimisation and testing. The optimisation takes you though some general PHP optimisation techniques, but then ploughs into techniques like a transparent abstract cache that is applied to the models. Testing is carried out with the trusty PHPUnit, along with the frameworks extension of the library Zend_Test and the book goes on to integrate the test suites with apache ant (why not phing) and phpundercontrol.

Conclusion

In conclusion, I thought this book was an excellent read and I plan to follow it through again when I build my next ZF app (I have two good ideas in the pipeline). Find out more or and buy it!. Thanks to Packt for sending me a copy!

If anybody missed it, the last few days has seen plenty of buzz around a new proposal on how to solve the problem with URL shorteners. I kind of got lost in all the different methods and proposals people are discussing, suggesting or implementing, but I went ahead and added some simple logic to lnkd.in, to do a HTTP HEAD request to the given URL, looking for headers in a couple of the formats suggested. I figured that was going to get out of date pretty quickly, so I modified it to use the RevCanonical API, seems to work pretty well, returning a rev=canonical url wherever possible.

I also contributed a basic bit of code to Rob Allen’s Shorter Links plugin for wordpress, allowing users to specifying a base url, davedevelopment.co.uk isn’t all that good for short URLs. Just need to upgrade the plugin and decide on a short domain for my blog now.

Update: registerd daved.in, works a treat

The only programming book I use without fail every working day ;)

Seriously though, this book is great.

Before my much needed Holiday, a colleague of mine asked for my input on a funny issue he was having. The root of the problem was that our production server is still running PHP 5.1.2, where as most of us run 5.2.x on our development and test machines. My problem was that what I was seeing didn’t make sense. The following portion of code is a simple reproduction of the code my colleague was using, running fine on PHP 5.2.x, but causing a fatal error on the production server running 5.1.2, an attribute access violation.

<?php
class BankAccount
{
    protected $balance;

    public function __construct($balance)
    {
        $this->balance = $balance;
    }

    public function __toString()
    {
        return 'Balance: ' . $this->balance;
    }

    public function debit($debit)
    {
        $this->balance -= $credit;
    }

    public function credit($credit)
    {
        $this->balance += $credit;
    }
}

class SavingsAccount extends BankAccount
{
    public function __construct(BankAccount $parent)
    {
        $this->balance = $parent->balance;
    }
}

$first = new BankAccount(1.00);
$second = new SavingsAccount($first);

echo $second, PHP_EOL; // Balance: 1

It turns out that PHP’s visibility restrictions are on a class level, rather than an instance level, and the fatal error was actually due to a bug in 5.1.x.

The visibility of a property or method can be defined by prefixing the declaration with the keywords: public, protected or private. Public declared items can be accessed everywhere. Protected limits access to inherited and parent classes (and to the class that defines the item). Private limits visibility only to the class that defines the item.

This bemused me, as it would appear to me there is no point having a protected operator at all. Suppose I am a lowly programmer given the BankAccount Class above as an API I can use but not change. I have a data access object that returns BankAccount objects too, which I also can’t touch. For reasons unknown to me, but probably to try and create some encapsulation so they can log transactions via the credit and debit methods, the original developer decided that I shouldn’t be able to directly access the balance attribute, but I want to.

<?php

//$myAccount = $dao->getAccount(123);
$myAccount = new BankAccount(1.00);
echo $myAccount, PHP_EOL; // Balance: 1

class WorkAround extends BankAccount
{
    public static function setBalance(BankAccount $acc, $balance)
    {
        $acc->balance = $balance;
    }
}

WorkAround::setBalance($myAccount, 1000000.00);
echo $myAccount, PHP_EOL; // Balance: 1000000

This just doesn’t seem right to me. Don’t get me wrong, I appreciate there needs to be some level of responsibility taken by developers to not do this kind of thing. My colleague writes a lot of Java, in which this is also the expected behaviour with the protected visibility, hence why he set out on this path, so it seemed right to him. Because of this I embarked on a little research to determine how other languages implement visibility.

A very quick and non-extensive bit of research led me to believe that Python doesn’t have visibility as I know it, and C# has protected and internal, but neither work the way I’d like. Ruby has the closest to what I desire in the form of instance variables, but I’m sure there’s plenty I’ve missed.

class BankAccount
    def initialize(bal)
        @balance = bal
    end

    def debit(debit)
        @balance -= debit
    end

    def credit(credit)
        @balance += credit
    end

    def to_s
        "Balance: %d" % @balance
    end
end

class SavingsAccount < BankAccount
    def setBalance(acc, bal)
        # This wont work - we cant access acc.balance
        # acc.balance = balance;
    end

    def bonusCredit(credit)
        # just to prove a sub class can access
        # the instance variable
        @balance += credit + 1
    end
end

first = BankAccount.new(42);
second = SavingsAccount.new(1);

second.setBalance(first, 5000000);
second.bonusCredit(10);

print first  # Balance: 42
print second # Balance: 12 

It worries me sometimes when I come across things like this that I blatantly should know and understand properly. Cheers JC.

In part two of this series, I discussed the technical know how I think will help get you your next PHP job. This part will discuss writing your Curriculum Vitae(CV, resume, etc.). There are a lot of contrasting opinions on this subject, I’ll make a few points, give you some further reading and you can adapt the opinions in to a top notch CV of your own. I’m no major expert and most of the recruitment I have been involved in has been for trainee developers, but these positions attract a high number of CVs, so I’ve seen a fair few.

Your CV does not get you a job

Your CV gets you an interview, your performance in the interview gets you a job. Your CV is a right of passage, this stage is used to filter out the wrong candidates.

Your CV should evolve like you

You should be continually evolving and improving yourself, your CV should continually evolve with you. I can’t see any reason why any two companies should see the same version of your CV. Every time you apply for a position, you CV should be tailored to suit the position. Cut out anything you think will not interest your prospective employer, embellish on what will interest them. You come across as a better candidate and you don’t waste their time.

Don’t stuff your CV with keywords/acronyms

Skills: PHP4/5, SOAP, XML, XSLT, JSON, AJAX, (X)HTML, CSS, RoR, MySQL, SEO, WAI, WCAG, MVC, XML-RPC….

These kinds of lists are great for getting your CV past an agency recruiter, but the actual employers would rather see a reasonable description of how you used 5 of those technologies. I try to briefly describe what I did and why I used those methods/skills/technologies.

.. Overcame performance issues due to large volumes of data by including caching, AJAX and moving some business logic to database triggers and stored procedures. (LAMP)

Besides, if you’re good, they’ll hire you and expect you to quickly learn the skills, technologies and methods they use.

Formatting and Proof Reading

I like CVs short, they take less time to read. One page is good, any more than two is bad. Keep it simple, spell check it, grammar check it, get people smarter than you to proof read it. Speaking of which, here’s my current offering, although it still needs a lot of work. I intend to try switching to plain text, ala Stevey, plus I recently got promoted so I’ve more work history to add. Comments appreciated.

Further Reading

• Manager Tools – Resume podcast
• Manager Tools – Sample Resume
• Steve Yegge on CVs
• Joel Spolsky – Getting your resume read
• Joel Spolsky – Sorting Resumes
• BCS CV Clinic

More in this series

• Part 1: Technical Skills
• Part 2: Soft Skills
• Part 3: Curriculum Vitae