Tuesday, July 21, 2009

OSCON quotes - day 1

I want to share quotes I overhear at OSCON 2009. Most of these are from fellow SourceForgers ...


  • I'm a fan of the minimalist beauty of the electronic device.

  • Your API is not a beautiful fucking snowflake.

  • I am as asymptotically close to clean as possible.

  • You're going to be happy about not being happy.

  • I'm German, we know how to deal with crowds.

  • It doesn't matter, you eat it with rice and bread.

  • I fucked the grower to get this shit.

  • It's amazing what you can fit up your ass with a little practice.

  • I don't like my balls soaked in sugar syrup.

  • People shouldn't call each other tar pit.

  • There's nothing you can think of with an olive that I haven't already video'd and sold on the internet.

  • Is this the placenta thing?

  • All eating human flesh stories start with, "I was going to med school."

Friday, February 06, 2009

Test-Driven [Design|Development]

Today I learned to appreciate Test-Driven Design a little bit more. Here's the story.

I'm writing some RSS feeds that will contain extensions and other non-RSS elements using XML Namespaces. I'm using Zend_View and Zend_Feed and I thought the best place to put the namespace would of course be at the top of my default.rss.phtml template file - that way I can register all the namespaces at once at the top of the feed. Instead of writing the test first, I wrote the code first. Took maybe 10-20m and seems to work fine:

<rss content="http://purl.org/rss/1.0/modules/content/"
doap="http://usefulinc.com/ns/doap#"
sf="http://sf.net/api/sfelements.rdf#"
foaf="http://xmlns.com/foaf/0.1/"
rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
version="2.0">
....
</rss>

Then I go to write the test. Lo and behold - it's a big pain in the ass to consume the feed using SimpleXML.

It's easy enough to create a SimpleXML element out of the feed, but I can't create SimpleXML elements from the content:encoded XML data:

<content:encoded>
<!--[CDATA[<doap:version>
<doap:name>Project 1.1 - Foobaj</doap:name>
<doap:created>1202221896</doap:created>
<doap:helper>
<foaf:person>
<foaf:name>admin1</foaf:name>
<foaf:homepage resource="http://lcrouch-703.sb.sf.net/users/admin1">
<foaf:mbox_sha1sum>6dd817a0f71590a68131a5e83b1bd73944654e8d</foaf:mbox_sha1sum>
</foaf:Person>
</doap:helper>
<doap:file-release>proj1.file1.tgz</doap:file-release>
<sf:download-count>0</sf:download-count>
</doap:Version>]]-->
</content:encoded>

Because all the namespaces used in the DOAP class aren't in the content. Argh! My first thought is to screw SimpleXML and do a raw string search/parse in the test. But then I had my epiphany: "If I were an actual client of this feed, I would want to be able to parse it easily with SimpleXML or with any other XML library."

I ended up pushing the xml namespace declarations right down into the appropriate elements - where I now think they are *supposed* to be:

<content:encoded>
<!--[CDATA[<doap:version
doap="http://usefulinc.com/ns/doap#"
sf="http://lcrouch-703.sb.sf.net/api/sfelements.rdf#">
<doap:name>Project 1.1 - Foobaj</doap:name>
<doap:created>1202221896</doap:created>
<doap:helper>
<foaf:person
foaf="http://xmlns.com/foaf/0.1/"
rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<foaf:name>admin1</foaf:name>
<foaf:homepage resource="http://lcrouch-703.sb.sf.net/users/admin1">
<foaf:mbox_sha1sum>6dd817a0f71590a68131a5e83b1bd73944654e8d</foaf:mbox_sha1sum>
</foaf:Person>
</doap:helper>
<doap:file-release>proj1.file1.tgz</doap:file-release>
<sf:download-count>0</sf:download-count>
</doap:Version>]]-->
</content:encoded>

Voila - SimpleXML starts parsing everything very easily.

This is one of the biggest boons for Test-Driven Development - the effects it has on the way you design your code. If I had not tested my code as an actual client would use it, I would have produced some pretty shoddy feeds with useless XML namespacing.

Friday, January 23, 2009

Leave the editor open

I've been trying to adopt some practices from The Productive Programmer. Mostly by using more keyboard shortcuts and productivity tools like Quicksilver, Jumpcut, etc.

Yesterday and today I realized a productivity tactic that isn't in the book - just leave your work open when you "go home" for the night. Don't close the program. In fact, don't even close any files, tabs, or any background programs either. Just save everything and walk away.

The effectiveness of this trick is related to something Joel wrote about a while back ...

For me, just getting started is the only hard thing. An object at rest tends to remain at rest. There's something incredible heavy in my brain that is extremely hard to get up to speed, but once it's rolling at full speed, it takes no effort to keep it going. Like a bicycle decked out for a cross-country, self-supported bike trip -- when you first start riding a bike with all that gear, it's hard to believe how much work it takes to get rolling, but once you are rolling, it feels just as easy as riding a bike without any gear.
Maybe this is the key to productivity: just getting started. Maybe when pair programming works it works because when you schedule a pair programming session with your buddy, you force each other to get started.


In the bike metaphor, leaving all your work open is like leaving the bike poised on a down-hill slope. All you have to do is get back to it and hop on. If I sit down at a blank desktop, I'm more likely to open my email, read my RSS feeds, open work email, and THEN, finally, open my code editors. If I sit down in front of a code editor, I'm likely to start editing code immediately.

Friday, January 09, 2009

Seven things that probably you may not know about me

Anderson tagged me, so I'll give this a try, though I'm going to have a tough time finding 7 other people who haven't been tagged already.

  • I have a black belt in the hodge-podge kick-boxing-jujutsu-taekwondo-karate style of fighting they teach at Apollo's Karate.

  • I have an identical twin brother, and 2 older brothers, one of whom is also a PHP developer.

  • I am emerging Catholic.

  • I brew my own beer.

  • I love soccer. I try to play every weekend. Also, GO REDS!

  • I can speak conversational Russian. I also speak a little French, a tiny bit of German and Portuguese, and I'm starting to learn Spanish. I'm only fluent in English though. :(

  • I landed my job at SourceForge after I made an OSS project there. So go make one yourself! :)


I'll tag ...

So tagging it back to Brazil, from whence I was tagged. :)

Thursday, January 08, 2009

Unit-testing ZF Controllers without Zend_Test

I've read a couple articles and blog posts recently talking about Zend_Test and/or testing Zend Framework Controllers. Particularly for controller testing, I'm kinda surprised how much plumbing code people are using. I recently started testing some Zend_Controller code (from ZF 1.5 even!) at SourceForge and did not do nearly that much plumbing.

Basically, I want to test the controller code in isolation from the front controller, the router, the dispatcher, the views, etc. All I to do is set up a request object, invoke the action methods of the controllers, and then assert against the variables assigned to the view. For these tests, I don't care about the output of the view templates themselves - I just want to know the controllers are putting the right variables into the view object.

It turns out this is actually pretty simple. I made a custom test case:



class Sfx_Controller_TestCase extends Sfx_TestCase
{
protected $_request;
protected $_response;
protected $_controller;

public function setUp()
{
parent::setUp();

// set up smarty view and restful view helper
$viewRenderer = new Sfx_Controller_Action_Helper_TestViewRenderer();
Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);

$this->_request = new Zend_Controller_Request_Http();
$this->_response = new Zend_Controller_Response_Cli();

}
}


Sfx_TestCase contains all my bootstrap code. However, the only thing I do in bootstrap is set include path and set up a default db adapter for Zend_Db_Table. I don't do anything with Zend_Controller_Front. So this may as well extend straight from PHPUnit_Framework_TestCase. I'm not sure why others are claiming you have to use Zend_Controller_Front to test ZF Controllers - you don't.

I wrote and use Sfx_Controller_Action_Helper_TestViewRenderer (and proposed it as a core class) to simply create an empty Zend_View object into which the controllers can assign variables. Here's the whole class:



class Sfx_Controller_Action_Helper_TestViewRenderer extends Zend_Controller_Action_Helper_ViewRenderer
{
public function initView()
{
if (null === $this->view) {
$this->setView(new Zend_View());
}
// Register view with action controller (unless already registered)
if ((null !== $this->_actionController) && (null === $this->_actionController->view)) {
$this->_actionController->view = $this->view;
}
}
}



With only this much plumbing, I'm able to test the Controllers in isolation - no worrying about routes, dispatchers, plugins, helpers, nor view templates - like so:



class ProjectControllerTest extends Sfx_Controller_TestCase
{
private function __constructProjectController()
{
return new ProjectController($this->_request, $this->_response);
}

public function test_indexAction_fetches_all_projects()
{
$this->_controller = $this->__constructProjectController();
$this->_controller->indexAction(); // assigns 'resources' to view
$this->assertNotNull($this->_controller->view->resources);
$this->assertEquals(27,count($this->_controller->view->resources));
}

public function test_indexAction_new_since_fetches_only_new_projects()
{
$this->_request->setParam('new_since',1205880839);
$this->_controller = $this->__constructProjectController();
$this->_controller->indexAction();
$projects = $this->_controller->view->resources;
$this->assertEquals(4,count($projects));
foreach($projects as $project){
$this->assertGreaterThan(1205880839, $project->create_time);
}
}

public function test_indexAction_limit_limits_projects()
{
$this->_request->setParam('changed_since', 1205880839);
$this->_request->setParam('order_by','changed_since');
$this->_request->setParam('limit', 5);
$this->_controller = $this->__constructProjectController();
$this->_controller->indexAction();
$projects = $this->_controller->view->resources;
$this->assertEquals(5,count($projects));
$prevChangeTime = 0;
foreach($projects as $project){
$this->assertGreaterThanOrEqual($prevRegTime, $project->change_time);
$prevChangeTime = $project->change_time;
}
}

}



I'm finding this to be a much simpler and easier way of testing ZF Controllers than the other articles I've been reading. Now if you want to test everything in the front controller dispatch process and the view templates, I think Zend_Test is the best bet, but I've not used it yet so I can't be sure. The above classes work fine for what I do.