Weekly roundup: giving back to Zend Framework

I've proposed myself for becoming the Zend_Debug maintainer for the 2.x iteration of Zend Framework. Actually it is composed by a single class, but since I don't know how much time I will have available in the next months I feel I can start from here, and alleviate a bit the workload of the most busy maintainers.
If you want to help too, join the zf-contributor mailing list.

Here are my articles for this week.
Practical PHP Patterns: Identity Map
Writing user stories for web applications
Practical PHP Patterns: Lazy Loading
Yahoo! Query Language

What to do on weekends

At least, what I do on weekends in relation to software development, university and all my work-related projects and tasks. Feel free to add comments about your lifestyle and what you think of work-life balance: I think I finally found an equilibrium after all these years, without feeling guilty in my free time.

What I do on the weekend (when I have time)
When I have time because weekend is meant for resting, going out, drinking, partying... Still, you sometimes find yourself waking up at 10 AM on Sunday morning or find a free hour before going to a football game. How will this hour be spent?
I usually read books, monstly non-fiction, and articles from feed aggregator that built up until Saturday or Sunday.
I experiment sometimes, or start writing drafts for new articles. And I plan the goals and the required work for the upcoming week.

What I don't do in the weekend
I don't write code in the weekend: I know that even when I feel inspired writing code on Sunday, it would drain my energies for the subsequent week. There is a famous icon of the open source programmer that writes code in his free time, but free time shouldn't be oppressed by a todo list by definition. I schedule my contributions in the workweek, when I can establish a rhythm in my work and process also non-exciting programming tasks.
I never publish original content (something other than a link roundup) for the same reason. Brainstorming or writing a rough draft is simple when you have the inspiration and you want to capture some thoughts, but actually publishing it implies a polishing process (proofreading, formatting, editing...) that is boring to do when you're supposed to rest the mind.
A nice addition to this list now that I have embraced the Pomodoro technique: I never timebox on the weekend. This exclusion of free time from pomodoros is explicitly stated by the inventor of the technique.

As a sidenote, I never check email on purpose after a predetermined hour even in the workdays,or at least try to: now that I'm expecting feedback from eBay sellers I infringe the rule, unfortunately.
Since you wouldn't want to craft an answer to some complex question or start a new project following a late evening email, just don't check the inbox: reading such emails now will only result in worrying over the night. Having a different e-mail for work and life will be useful...

Image from Wikimedia Commons.

Weekly roundup: computer died

My home primary computer died yesterday after a week of freezes. The disks seem fine, so there's no data loss. Anyway, I'll continue to write from the netbook.

Here are the posts of this week published elsewhere on the web.

DZone
Practical PHP Patterns: Data Mapper
Asynchronous processing in PHP
Practical PHP Patterns: Unit of Work
Zend_Test for Acceptance TDD

php|architect
phpDay 2010 international talks

Learning the Pomodoro technique

During a workshop of Francesco Trucchia I've been introduced to the Pomodoro technique for time management. I've known the existence of this methodology for years, but I never gave it a shot, being unsure if it was adequate for programming tasks.
It seems however that in the Agile world the Pomodoro technique has a good following. I won't go into the details of explaining this technique as the official site can do this much better than me (I started timeboxing with pomodoros on Tuesday morning.)
Basically, the atomic unit of time is an uninterruptible pomodoro, which lasts 25 minutes and which comprehends 5 minute pause at the end of period of work. Pomodoros can't be sliced up nor you can do other tasks different from the planned ones during a pomodoro, and the pause of 5 minutes is mandatory. During the pause, you can't continue thinking about the problem you were tackling (this has been difficult to grasp, but if you clear your mind during a pause 5 minutes have a value of much more).

Timeboxing has been very useful for writing articles, which is a task that commonly can suck up hours. I got a feedback on how much I was completing, and been forced to improve my process and avoid distractions (like looking for a word on Wiktionary or insisting on a particular construction).

For programming, which is the critical task, I am still experimenting after three days. With fast computers or platforms, this technique works very well. But sometimes I work with Java and I can get a cup of coffee before a test finishes running. I can't help multitasking with two machines to get something done in this environment.
The most difficult part for now has been estimating, since I have no experience with these short timeboxed. However, these estimations may become more accurate than
The rapid feedback of a pomodoro finishing is definitely a psychological pro, since it gives me back confidence on the task I complete and notice me if something is scattering into the next timebox (and so may be re-estimated, or maybe I should take a wider look at documentation before jumping into coding).

The forced interruption, in fact, has proven very useful, despite the worries of interrupting the flow.
First, Test-Driven Development helps me keeping my flow when I resume my work. I take a look at the last unit or acceptance test that does not pass and I know immediately where I was working on.
Second, it is often the case that I'm taking too much time on a single task: for example I am perform fine refactoring on code that I may end up throwing away, or I am insisting on integrating an external library now and fighting with runtime errors when I should switch to a different task with higher ROI.
Thus, the basic 25-5 minutes cycle is not a danger for programmers. Enter often in a state where we lose track of time it's not something we should be proud of...

phpDay wrapping up

Some last considerations on phpDay 2010 and then I'll stop annoying you with these informations.

First, if you were at phpDay and attended my talk, feel free to leave feedback on the specific joind.in page. Feedback is important for the organization, to know which events raised the interest of the crowd, and for speakers to improve and fine tune their talks.

Second, my slides for the Architettura e testabilità talk are online:

Php day2010

View more presentations from piccoloprincipe.

Finally, there are a few interviews to some of the speakers (a group that also comprehends me) on html.it (in Italian).

I would like to thank you all the attendees. Given the reception, I'll propose my talk (and maybe new ideas) to other conferences... Trying cannot hurt.

Expert PHP 5 Tools review

The book I'm reviewing today is Expert PHP 5 Tools, which in the last month has gained a lot of momentum in the blogosphere.

One of the first part of this book makes a great deal (correctly) of coding standards. Although this focus on the code, this is not a book on how to write code (with topics like object-oriented design for example), but as the title suggests on tools that supports the development, and on how to deal with the infrastructure necessary to maintain a project.

Some of the main topics treated by this book are version control (with Subversion), and debugging/error management in PHP (Xdebug). Sure you'll never introduce breakpoint in PHP, debugging is much simpler than in other languages as a script terminates after every request; but having the right tools can speed up you very much. I still prefer thorough testing to debugging.
Another interesting topic is the use of PHP open source frameworks, with a panoramic of the available solutions and a Zend Framework example. Don't worry about the particular technology since MVC stacks of the different frameworks (which are the innovation that makes a framework different from a library, as it manages HTTP requests and responses) are usually equivalent.
 
The second part of the book goes on to cover topics such as testing (a delicate topic for me), and deployment of applications. PHPUnit is introduced from the ground up, with all its features like annotations, fixtures and code coverage reports. Even Test-Driven Development is discussed to some extent.

A bit out of place was the introduction to Uml, a dangerous standard when applied in the large or at a great level of detail. Remember though that understanding of basic Uml (class, sequence) diagrams is a requirement since many patterns are explained with this kind of documentation. Moreover, small and focused Uml diagrams can communicate very much about a design.
The practice of Continuos Integration is explained with a nice idea: setting up a CI server for Zend Framework. Leveraging open source projects gives some points to this book.

Some points I did not like was the idea of favoring IDEs very much, which is quite the contrary of the toolbox metaphor, a set of small tools you can combine instead of a monolithic one. Another minor point is the large preference for PHP tools over the ones written in other languages: after all the author is using Eclipse, which is certainly not written in PHP.

I'm not severe on this type of readings, because I always have to remember that a book is a starting point: you have to actually use the practices described here and gain experience to be effective. Thus, if you are a project manager which wants to really empower his developers instead of limiting them, check out this book.

Weekly roundup - phpDay 2010 edition

I've been at the phpDay conference until today, so I haven't had time to write the usual roundup. Hope you enjoy these articles.

DZone
Practical PHP Patterns: Row Data Gateway
Ajax and MVC
Practical PHP Patterns: Active Record
Test-Driven Development with OSGi

php|architect
ORM Designer

I will write more about the experience at my first conference in the next days.

Packing for phpDay 2010

I'm packing for phpDay, which starts tomorrow. It seems we will have a powerful Wifi connection, and an hotel near the Adriatic sea.

If you read this blog and will be at phpDay, look for me at the conference center (it's likely that I follow yours, too), I will be glad to meet you. I will arrive tomorrow around 1 PM (local time).
Anyway, stay in touch with the hashtag #phpday2010...

Weekly roundup: preparing for phpDay

The upcoming week will be very intense: after three full days spent in university and my thesis, I'll leave for phpDay, a voyage of 500+ kilometers.
As always, I have some original articles of mine that were published in other websites.

php|architect
phpDay 2010 - a presentation of the international speakers.

DZone
Practical PHP Patterns: Service Layer
Evolution of a programmer (eek! 10000+ people read this article)
Practical PHP Patterns: Table Data Gateway
PHP 2.x frameworks and Ruby on Rails

Small steps

Today I was working with a Java framework which runs on top of OSGi (another framework, and yes, Java is verbose even from the platform stack point of view.)
After having prepared a (hopefully) failing acceptance test which used httpunit to extract the content of a dynamic page and verify that the world "Hello" is contained in it, I was ready to run the test, see the assertion failing and start writing our beloved production code.
Unfortunately, the test failed not because of the assertion, but because the JUnit Plugin runner, which takes a JUnit test and run it over a configured OSGi framework, was saying "No tests found." How that was possible?

When tests that should drive the development leave you without a clue on what is happening, chances are that you are taking big steps when you should walk carefully. I was taking big steps because it takes two minutes to run such an acceptance test due to all the infrastructure noise, but I'm not an expert in OSGi applications and I should have taken smaller steps towards my goal of a failing test. The same is true for production code: if I can't get a green bar maybe my failing tests are not fine-grained enough.

Thus I run a git reset and perform the following baby steps to build confidence:

• create an empty bundle (jargon for package), and write an empty test in it. Run and see Warning: no assertions, but nothing explodes.
• Add a test method with a assertTrue(true) call. Run, and nothing explodes still.
• Add httpunit in lib/ and set it up with the Bundle-ClassPath directive, which basically says where the runtime can find the library JARs in the bundle. 

Ok, it was that. After a quick search on Google, I found out that I was specifying the classpath as I've always done via command line or ant scripts:
Bundle-ClassPath: .:lib/httpunit.jar
while OSGi has a different opinion of classpaths:
Bundle-ClassPath: ., lib/httpunit.jar
So I lost even the current directory (.) from the classpath when introducing the first, malformed directive.

After having located the problem with a test-first approach, I was able to (slowly) run my red test and return writing production code.
Automated testing and incremental development save the day again - imagine what would have happened if I had to debug this mess manually, with a framework that takes some minutes to start, and no idea of where the error was...

International Workers' Day roundup

Every weekend, I have some links I'd like to share with you. They point to articles of mine originally published out of this blog, during this week.

php|architect
First beta of Doctrine 2 released

DZone
Practical PHP Patterns: Domain Model
Vim for PHP development
Practical PHP Patterns: Table Module
Synchronization in PHP

Hope you enjoy them. Anyway, today is the International workers' day here in Europe. Happy useless Saturday holidays!