Debuggable Blog

Programming Psychology II: Private methods

felix@debuggable.com — Mon, 07 Jul 2008 12:49:05 +0000

Hey folks,

my previous posts about code that is easy to write vs code that is easy to read and why XHTML is a joke spawned a fair amount of criticism. This time I am afraid very few people are going to agree with me at all:

Private / protected methods and properties are one of the most stupid concepts of OOP.

This is a thought I first shared at CakeFest Orlando this year, but could not explain properly at the time.

Here is the typical excuse for why any language should implement such a terrible concept:

php

class BankAccount{
private $balance = 0.00;
public function set($newBalance) {
if (!is_numeric($newBalance)) {
$this->error = 'And I will strike down upon thee with great vengeance
and furious anger those who would attempt to poison and
destroy my bank account. [...]';
return false;
}
$this->balance = $newBalance;
return true;
}
public function get() {
return $this->balance;
}
public function save() {
// Great, I can now always blindly trust the value of $this->balance!
return file_put_contents('balance', $this->balance);
}
}

Awesome! Now nobody can mess with the balance of this account class and you don't even have to communicate the rules for using it to other programmers!

If you think you can manage programmers or enforce API policies with a few keywords of your programming language ... think again!

If somebody does not understand why he is not supposed to modify the balance property - he will find ways around it. And it won't be pretty, trust me. He'll directly write his values to the database and reload the object. He'll simply change your source code without warning. He'll extend the class and overwrite the set method.

Programmers will do just about anything to restore power you are trying to take away from them.

Now you might think: "But it really makes sense to use a private property here, nobody would ever want to work around this?". Well maybe. And thats a big maybe. Predicting what other programmers will want to do with your code is like playing number guessing with uuids.

So why not try to make the other programmers your allies? Show them what you are trying to accomplish in a semantic fashion:

php

class BankAccount{
public $balance = 0.00;
public function validates() {
if (!is_numeric($this->balance)) {
$this->error = 'And I will strike down upon thee with great vengeance
and furious anger those who would attempt to poison and
destroy my bank account. [...]';
return false;
}
return true;
}
public function save() {
// Lets just make sure that nothing has gone wrong before saving
if (!$this->validates()) {
return false;
}
return file_put_contents('balance', $this->balance);
}
}

This approach has many advantages:

It gets rid of the useless overhead from setter / getter functions.
It communicates that you need to validate certain things before saving a record.
It embraces open architectures and others can work with it right away.
It makes your class more flexible since you can temporarily feed it with invalid values.
It exposes a new useful method.

Is that it?

Despite the fact that I think that private / protected are a stupid idea to begin with, I have an even bigger issue with them:

The concept of private / protected properties and methods seems to be the most popular recipe for producing crappy code.

I think it's safe to say that all of us were following at least one of the patterns listed below at one point:

Not sure where this code goes - I'll put it in a private method for now.
Oh, I will refactor this later, so I temporarely put it in a private method.
This is just a helper function, no need to clutter the API with it.
I am sure no other class will need to access this property ... lets make it private.

Now ask yourself how many times those decisions have lead to code you are proud of? I cannot recall a single occasion in my work as a programmer where using private / protected has helped me to write better code. In fact, these days I even judge other peoples code by it:

When I see more than 2-3 private / protected methods in a class I know the code I'm looking at is in poor shape.

This may sound like a big simplification, but it holds true. I've almost never seen people use private / protected in the proper (yet stupid) way they are supposed to be used.

The psychology behind this is simple. Give people a way to ignore things they don't want to deal with and they will. Private / protected were not meant for that purpose, but unfortunately they encourage the worst habits in us programmers and I therefor highly recommend against using them.

-- Felix Geisendörfer aka the_undefined

PS: Even if you "just" use the CakePHP convention of prefixing functions with one or two underscores to indicate scope visibility you'll end up writing messy code.

CakePHP RC2 Released!

tim@debuggable.com — Mon, 30 Jun 2008 09:25:39 +0000

Hey folks,

in case you haven't noticed yet, Cake has gone into RC2 phase. Please check it out.

I think extra kudos go this time to gwoo for putting up countless hours to get many tickets fixed during the last two weeks. Cheers mate. :]

Here are some links that might interest you:

-- Tim Koschuetzki aka DarkAngelBGE

Working with databases on OSX will soon be as awesome as everything else on OSX

nate@cakephp.org — Tue, 24 Jun 2008 16:33:23 +0000

Howdy people (ha! there's a new one),

As we all know, database apps on most platforms... well, suck... even on OSX. The best we have is CocoaMySQL, which, while okay, could certainly not be called great. This shouldn't be the case. We have higher standards. We can do better.

Enter Shift. Shift started life as a direct port of the apparently-no-longer-maintained CocoaMySQL, and indeed, much of the code and interface is still the same. However, the interface mockups of the upcoming 0.5 release make this a project worth keeping a close eye on.

How to bend Cake's Model::find() method to your needs

tim@debuggable.com — Sat, 21 Jun 2008 13:14:59 +0000

Hey folks,

CakePHP allows you to use your own "find-types" for the Model::find() methodology. Those of your who are familiar with the find() method know that there are currently four types in the core: 'list', 'all', 'first' and 'count'. However, sometimes it is nice to specify your own type so you can have a call like this:

php

$this->Comment->find('pending');

So how would you go about implementing this? Correct, you would overwrite the find() method in your model and provide the default functionality if there is one of the default types used. Let's have a look at how you could implement this pending find from above:

php

class Comment extends AppModel {
var $belongsTo = array('User');
function find($type, $queryData = array()) {
switch ($type) {
case 'pending':
return $this->find('all', array(
'fields' => array('User.email', 'User.first_name', 'User.last_name', 'Comment.name')
, 'conditions' => array(
'Comment.active' => 0
, 'Comment.blocked' => 0
)
, 'contain' => array('User')
));
default:
return parent::find($type, $queryData);
}
}
}

So this is actually not very difficult code, but it is very powerful. You could specify different sets of conditions, fields, orders, groups by's and containments just by adding a new entry to the switch statement. Please note that there is no break needed within the switch as we return home.

Let's add some code for finding pending users that were invited by the currently logged-in user. This is what we could use in the controller:

php

$this->Comment->find('pending', array('created_by_id' => User::get('id')));

Now for the model we would need to add some code that tracks if $queryData['conditions'] is set, and use that as well in conjunction with the conditions specified in our find type. While we are at it, let's also add some code that would handle fields, order, group, recursive and contain statements:

php

class Comment extends AppModel {
var $belongsTo = array('User');
function find($type, $queryData = array()) {
$defaults = array(
'conditions' => null
, 'fields' => array()
, 'order' => null
, 'recursive' => null
, 'contain' => null
);
$queryData = am($defaults, $queryData);
switch ($type) {
case 'pending':
return $this->find('all', array(
'fields' => am(
array('User.email', 'User.first_name', 'User.last_name', 'Comment.name')
, $queryData['fields']
)
, 'conditions' => am(array(
'Comment.active' => 0
, 'Comment.blocked' => 0
), $queryData['conditions'])
, 'contain' => am(array('User'), $queryData['contain'])
));
default:
return parent::find($type, $queryData);
}
}
}

With some default values we can happily use our custom find type alongside dynamic conditions inserted by our controllers. If you think this am() stuff is overkill, you could as well just provide another find type:

php

$this->Comment->find('pending-created-by-logged-in-user');

php

class Comment extends AppModel {
var $belongsTo = array('User');
function find($type, $queryData = array()) {
switch ($type) {
case 'pending':
return $this->find('all', array(
'fields' => array('User.email', 'User.first_name', 'User.last_name', 'Comment.name')
, 'conditions' => array(
'Comment.active' => 0
, 'Comment.blocked' => 0
)
, 'contain' => array('User')
));
case 'pending-created-by-logged-in-user':
return $this->find('all', array(
'fields' => array('User.email', 'User.first_name', 'User.last_name')
, 'conditions' => array(
'Comment.active' => 0
, 'Comment.blocked' => 0
, 'Comment.created_by_id' => User::get('id')
)
, 'contain' => array('User')
));
default:
return parent::find($type, $queryData);
}
}
}

... well you get the idea. By the way, do you notice how useful using a static functions like this User::get() methods are for fetching properties and data from the currently logged in user? More on that later.

Anybody willing to share some dough on this one?

-- Tim Koschuetzki aka DarkAngelBGE

How To Execute Only Specific Test Methods in CakePHP Unit Tests

tim@debuggable.com — Thu, 19 Jun 2008 08:41:11 +0000

Hey folks,

most of us familiar with unit testing with CakePHP and SimpleTest know that
SimpleTest always executes all methods starting with the string "test".

This can be problematic sometimes:

As you unit test your application you realize that the same test fails again and again and you cannot make it work and therefore want to tackle it in isolation from the other tests.
Many tests fail and you want to tackle them one at a time without getting distracted by the failure messages of the others.
Say you debug a model class of yours and have many tests for the same model function. Now, in order to get the one failing test working, you want to output some debug information within that model method. However, as there are many tests for that method, the debug information will always show for every test and your screen is full of debug information and you spend five or more seconds searching for the correct one.
Executing all test functions takes a tremendous amount of time and you just need to get one test to work. You obviously don't want to spend 30 seconds waiting just to get the same failure message again and again. ; )

At this point you have two options:

Create a new testcase, copy all the code that is needed to setUp() it properly, copy the test function over and observe and debug it there. Then copy back when you are done and then for every test method. This isn't very fast.
Put an 'x' before every test method name except before the one you want to debug. This really slows you down if there are many test functions.
Read the following tip and make your life a lot easier. ; )

As the CakeTestCase class extends SimpleTest's UnitTestCase class, it inherits all their functionality. Fortunately, SimpleTest internally has a useful mechanism to choose which functions to execute in the test class.

The name of this method is getTests(), which returns an array of methods that it shall execute. By default it looks like this:

php

function getTests() {
$methods = array();
foreach (get_class_methods(get_class($this)) as $method) {
if ($this->_isTest($method)) {
$methods[] = $method;
}
}
return $methods;
}
function _isTest($method) {
if (strtolower(substr($method, 0, 4)) == 'test') {
return ! SimpleTestCompatibility::isA($this, strtolower($method));
}
return false;
}

Pretty straightforward. Fetches all method names from the current class and tests if they start with 'test' (and looks if they are tests). So we see all that getTests() really does is return an array of test methods.

Let's look at an example on how to put this to use. Say you have the following tests (which absolutely make no sense whatsoever) in your custom CakePHP Test class:

php

class MyHumbleTest extends CakeTestCase {
function setUp() {}
function testOfIdenticalClass() {
$this->assertIdentical('class', 'class');
}
function testOfIdenticalName() {
$this->assertIdentical('name', 'name');
}
function tearDown() {}
}

.. and then some. Now you want to check the testOfIdenticalName method alone. You would add a getTests() implementation:

php

class MuHumbleTest extends CakeTestCase {
function setUp() {}
function testOfIdenticalClass() {
$this->assertIdentical('class', 'class');
}
function testOfIdenticalName() {
$this->assertIdentical('name', 'name');
}
function getTests() {
return array('testOfIdenticalName');
}
function tearDown() {}
}

Very cool and handy, yes? Life is getting easier with such things, especially with many test functions.

One thing to note is that if you want to keep fixtures working, you have to tell it to still execute the start(), startCase(), endCase() an end() callbacks:

php

class MuHumbleTest extends CakeTestCase {
function setUp() {}
function testOfIdenticalClass() {
$this->assertIdentical('class', 'class');
}
function testOfIdenticalName() {
$this->assertIdentical('name', 'name');
}
function getTests() {
$methods = array('testOfIdenticalName');
return am(a('start', 'startCase'), $methods, a('endCase', 'end'));
}
function tearDown() {}
}

-- Tim Koschuetzki aka DarkAngelBGE

How to Group By in CakePHP's new release Part 2

tim@debuggable.com — Mon, 16 Jun 2008 12:23:23 +0000

Hey folks,

having promised it in the first post on how to do Group By in CakePHP I worked on an array() version for the group statement in Model::find() calls. So I implemented it. This is what can be accomplished now:

php

$result = $Thread->find('all', array(
'conditions' => array('Thread.project_id' => 1),
'group' => 'Thread.project_id, Project.id')
);
$this->assertEqual($result, $expected);
$result = $Thread->find('all', array(
'conditions' => array('Thread.project_id' => 1),
'group' => 'project_id')
);
$this->assertEqual($result, $expected);
$result = $Thread->find('all', array(
'conditions' => array('Thread.project_id' => 1),
'group' => array('project_id'))
);
$this->assertEqual($result, $expected);
$result = $Thread->find('all', array(
'conditions' => array('Thread.project_id' => 1),
'group' => array('project_id', 'Project.id'))
);
$this->assertEqual($result, $expected);
$result = $Thread->find('all', array(
'conditions' => array('Thread.project_id' => 1),
'group' => array('Thread.project_id', 'Project.id'))
);
$this->assertEqual($result, $expected);

As you can see you can still group via the former string method. In addition to that any combination of available fields can be used in an array to form a GROUP BY statement with values separated by comma.

So this code here:

php

$result = $Thread->find('all', array(
'conditions' => array('Thread.project_id' => 1),
'group' => array('Thread.project_id', 'Project.id'))
);

would result in a GROUP BY statement that looks like:

php

GROUP BY `Thread`.`project_id`, `Project`.`id`

You can leave out the alias of the model the find is invoked on as long as your columns aren't ambigous.

Happy baking all! Oh and for those who are interested in the code, have a look at the changeset.

-- Tim Koschuetzki aka DarkAngelBGE

3 Jobs for skilled Bakers

felix@debuggable.com — Thu, 12 Jun 2008 13:02:53 +0000

Hey folks,

it's only been a short while since the launch of the new job board for the CakePHP community and there are already 3 jobs posted. If you are currently seeking employment, you should consider the following opportunities:

QRIU is seeking bakers to work on cutting edge CakePHP technology with them.
Doubledot Media Limited has opportunities to play with MySql clustering and web APIs in their Christchurch (New Zeland) kitchen.
Netro42 Ltd wants to hire passionate bakers that are good at communication in London (UK).

If any of those jobs sound interesting to you, go ahead and apply. If you are looking for skilled bakers yourself, consider posting on the job board. It is $300 / post of which 50% are donated to the Cake Software Foundation.

All jobs posted within the next month are also going to be featured on debuggable.com including a back link to the company website.

-- Felix Geisendörfer aka the_undefined

How to do Group By conditions in Model find() calls in the CakePHP RC1

tim@debuggable.com — Wed, 11 Jun 2008 09:30:15 +0000

Hey folks,

we have to thank Mark Story and wluigi for working on group by conditions for Cake's Model::find() method. Up until now, you would have to add your GROUP BY stuff to string'ed conditions in order to support a group by statement, which could be very ugly.

Have a look at the following:

php

$query = trim(low($query));
$conditions =
"Product.active = '1' AND (LOWER(Product.name) LIKE '%{$query}%'
OR LOWER(Product.description) LIKE '%{$query}%'
OR LOWER(Product.sku) LIKE '%{$query}%') GROUP BY Product.name";
$this->paginate['Product']['conditions'] = $conditions;
$products = $this->paginate('Product');

Now with the new worked in group key you would just do:

php

$query = trim(low($query));
$conditions = array(
'or' => array(
'LOWER(Product.name) LIKE' => "%{$query}%",
'LOWER(Product.description) LIKE' => "%{$query}%",
'LOWER(Product.sku) LIKE' => "%{$query}%"
),
'active' => 1
);
$this->paginate['Product']['conditions'] = $conditions;
$this->paginate['Product']['group'] = 'Product.name';
$products = $this->paginate('Product');

Much cleaner! Cool! Now let's see what we'd do if we wanted to group by over several columns:

php

$order = array('created' => 'desc', 'name' => 'asc');
$group = 'name, created';
$products = $this->paginate('Product', compact('order', 'group'));

The group statement currently works as a string. So you would have to separate multiple group by fields by a comma.

Kudos to wluigi and mark_story. Checkout the Changeset if you are interested in the underlying implementation.

Now who is not excited about the new release?

-- Tim Koschuetzki aka DarkAngelBGE

Crawl Google, they do the same to you ; )

felix@debuggable.com — Tue, 10 Jun 2008 18:07:26 +0000

Hey folks,

Marc Grabanski just had the great idea of using google to help with the migration of your site to a new domain / url schema. Just get a list of all pages google has indexed from your site and then use that as your basis for checking if your migration worked or not. This is very convenient because you do not have to know all your own urls yourself, and you'll only get the relevant ones (if they are not in google they are unlikely to have traffic).

So here is some quick code for crawling Google instead of being crawled by them in CakePHP:

php

class GoogleIndexShell extends Shell {
function main() {
App::import('HttpSocket');
list($site) = $this->args;
$Socket = new HttpSocket();
$links = array();
$start = 0;
$num = 100;
do {
$r = $Socket->get('http://www.google.com/search', array(
'hl' => 'en',
'as_sitesearch' => $site,
'num' => $num,
'filter' => 0,
'start' => $start,
));
if (!preg_match_all('/href="([^"]+)" class="?l"?/is', $r, $matches)) {
die($this->out('Error: Could not parse google results'));
}
$links = array_merge($links, $matches[1]);
$start = $start + $num;
} while (count($matches[1]) >= $num);
$links = array_unique($links);
$this->out(sprintf('-> Found %d links on google:', count($links)));
$this->hr();
$this->out(join("\n", $links));
}
}

Usage is as simple as running:

./cake google_index debuggable.com

Which should produce an output like this:

Welcome to CakePHP v1.2.0.7125 beta Console
---------------------------------------------------------------
App : app
Path: /Users/felix/dev/www/php5/debuggable/app
---------------------------------------------------------------
-> Found 293 links on google:
---------------------------------------------------------------
http://debuggable.com/
http://debuggable.com/contracting
http://debuggable.com/contact
http://debuggable.com/workshops
http://debuggable.com/open-source/fixtures-shell
http://debuggable.com/open-source/google-analytics-api
http://debuggable.com/posts/thinking-what:480f4dd5-5f1c-4d37-99b0-4768cbdd56cb
http://debuggable.com/posts/jquerycamp07:480f4dd6-8d40-44e1-8551-4a58cbdd56cb
...

Oh and if you want to see more shell sample code, also check out our FixtureShell and the blog post for it.

-- Felix Geisendörfer aka the_undefined

PS: Please note that this is a quick hack, and any non-trivial change in the markup google uses will break. This is only meant for temporary usage.

Better array syntax for PHP: Here's your chance to weigh in

nate@cakephp.org — Mon, 09 Jun 2008 17:55:26 +0000

Hi folks.

Recently there's been some discussion on the PHP internals mailing list about providing an alternate array declaration syntax for PHP.

Instead of:

php

$fields = array('id', 'name', 'created');

it would be possible to do

php

$fields = ['id', 'name', 'created'];

Simpler, cleaner and very familiar to anyone who has done development in almost any other modern web language, especially JavaScript.

Well, there's a patch available, but 2/3 of the active PHP committers (who participated in the vote) voted against its inclusion. However, of the end-users participating in the discussion, 17 out of 20 voted in favor. Shortly before the voting was concluded, there was a call for some user-land input, so I decided to humbly submit my two pennies.

This fact has been pointed out previously, but it bears repeating: the
divide between users and committers on this issue is stark: only 1/3
of committers are in favor, but almost all users who have voiced
opinions on the issue are in favor. The people actually using the
language want something new, because in this case something new is
better. Come on guys, arrays are our bread and butter. PHP has more
support for working with arrays than it does for doing pretty much
anything else.

I can't imagine I'll be taken very seriously. I also find it hard to believe that many actual users of PHP would be against this, a fact which is all the more tragic given the rhetoric of the core committers who are against it (a full summary of the discussion can be seen at http://markmail.org/message/rsi4welftwou24p3, please note that this is not updated in real-time).

Fortunately PHP, like Cake, is an Open Source project, and even I've been known to implement and support features which I personally don't like or have no use for, if the community support behind the idea is strong enough. The same goes for PHP, so here's your chance to make your voice heard. Blog, leave comments, post to the internals list, lobby your local PHP core committer (remember to be nice).

Obviously a feature like this, even though we wouldn't be able to directly take advantage of it anytime soon, would be a great help in pushing all PHP projects, especially ours, forward to the future.