www.greg-wright.co.uk

For many people good management just "goes without saying". What I'm going to write is patently obvious, but for a surprising number of managers the blindingly obvious escapes them, and they leave a disastrous trail of broken careers and embittered former employees in their wake.

In just 7 weeks of November and December 2008 I wrote the initial code for http://www.stuff2send.com, a site which allows people travelling round the country to earn extra money by delivering packages as part of their journey. The site, which included Google Map and PayPal integration, went live on time and within budget and support and development was then taken over by the brilliant Tom and Lisa at 18aproductions.com.

I've always thought that the best programmers have the worst memories. The reason is simple. If you have a bad memeory you have to write your code in a way that you will understand it in the future. If you have a good memory you can do what you like, give variables stupid names, make the code as unreadable as you like - you can rely on your memory to help you out when you revisit the code.

In no particular order:

• Value and respect all their staff
• Nurture and develop talent
• Able to exercise authority
• Good Listeners
• Open to change
• Accountable
• Set clear written goals and targets for success
• Provide constructive criticism the action not negative criticism of the person
• Reasonable
• Deal with difficult issues in private

Throughout my 20+ years in IT I've been fortunate enough to be managed by many good people and a few bad ones. Will Dawson at ICL in Bracknell was a brilliant manager. He set clear written goals and had a natural flair at bringing out the best in people. Dave Watson at Fidelity managed to make a tough job great fun and was prepared to be woken up in the middle of the night if there was a problem with one of the bank's computers. Bryan Cowles at Siemens taught me all I know about project management just by "doing it". Together we landed several major projects "day perfect".

Its not always obvious which method gets called when overloading methods with different access controls and calling them from the parent class. Consider:

<?php
class C1 {
  public function __construct() {
    $this->go();
  }

  private function go() {
    echo "In the C1::go()\n";
  }
}

class C2 extends C1 {
  public function __construct() {
    parent::__construct();
  }

  protected function go() {
    echo "In the C2::go()\n";
  }
}
$c=new C2();

The output is "In the C1::go()"

Now consider:

class C1 {

I want to run a test that should take less than a second but could perhaps get into a longer / infinite loop, so I want to set a timer interrupt to go off in 1 seconds time and handle the exception it generates to force a test failure.

What is the probability of being able to do this with PHP?

I've just built 2 copies of PHP 5.2.9 from scratch on different linux versions (with very slightly different configurations).

In the first case make test returns 40 errors (from 6529 tests) (0.6% of tests which were run fail) In the second case 54 (0.8%) of 6550 tests fail.

That's a lot of tests failing. It should build cleanly.

Did all tests run when 5.2.9 was released? Who knows. Maybe its just developers failing to run and update tests when code is updated. Maybe its even more serious.

Additional information in an ON Clause can be confusing. Consider the difference between


SELECT books.title, sales.quantity FROM books
LEFT JOIN sales
ON books.bookId = sales.storeId
WHERE sales.storeId = 123


and


SELECT books.title, sales.quantity FROM books
LEFT JOIN sales
ON books.bookId = sales.storeId
AND sales.storeId = 123


Based on http://www.sqlteam.com/article/additional-criteria-in-the-join-clause

The first case does what you would expect - printing out books and sales data for store 123.

PHP's lack of support for overriding methods is a real performance hog. You have to work out what the programmer meant by the types of the parameters sent to the method manually. All this takes time and has to be done every time the method is called.

You end up with code that looks like this:

/**
* I want to do something like calling myfunc(new Instance("thingstring")) or just
* myclass("thingstring");
*/
public function myfunc( $instance ) {
if (is_string($instance)) $instance=new Instance($instance);

http://develobert.blogspot.com/2008/06/50-random-php-facts.html

See comment #3!

$this is spurious.
$this is almost never needed. If a variable is not available in local scope then it must be in class scope, so why on earth do I have to clutter my PHP classes with $this?

Are you listening PHP?

http://pinderkent.phumblog.com/post/2009/04/static_typing_is_a_necessity...

Guess what the output of the following code is:

<?php
error_reporting(E_ALL|E_STRICT);
session_write_close();

Answer: Nothing. PHP lets you try to close a session that was never opened and doesn't even murmur a warning.

The lack of proper OO capabilities in PHP makes me want to scream. For example operator overloading and method overloading are so fundamental to what everyone else is doing with OO code. These are really essential areas of OO design that PHP just chooses to ignore.

Why can't the PHP designers just bite the bullet and make everything a proper class and do the job properly instead of the half-baked pseudo-OO currently offered?

Will PHP 6 be any better? Somehow I doubt it.