Biweekly roundup: more and more languages

I am a PHP developer and a student by day, but I don't want to limit my options: I'm currently experimenting with Clojure and exercising with Rails. Each new language or platform teach us something general about programming; I advise you to abandon any prejudice if you decide to dive into a new language in your practice time (which for a PHPer programming Ruby is essential.)

Here are my articles published in the last two weeks.

What I learned in the Global Day of Code Retreat is a summary of my experience at the Code Retreat in Milan during the Decembed edition.
Practical PHP Refactoring: Remove Setting Method is about guaranteeing immutability or simplifying the interface of an object by throwing away a method.
Testing and specifying JavaScript code with Jasmine is an example of usage of the popular BDD JavaScript testing framework.
Practical PHP Refactoring: Hide Method is about information hiding: limiting the scope of a method to be able to easily evolve it later.
Practical PHP Refactoring: Replace Constructor with Factory Method transforms a giant constructor into several well-named Factory Methods.
Rails from the point of view of a PHP developer is about me trying out Rails 3 (again, without prejudices).
Practical PHP Refactoring: Encapsulate Downcast (and Wrapping) is about the PHP version of downcasting: converting primitives and wrapping them in Value Objects.
jQuery plugins with jsTestDriver is an example of real world JavaScript development with TDD.

Weekly roundup: the code retreat

Yesterday was the Global Day of Code Retreat, an event where local groups of developers get together to hone their skills. It consists of six iterations of solving a problem (simulating the Game of Life) in pairs, where at the end of each hour the code is deleted and the pairs mixed. This combination enforces a focus on the method, not on the result; and allows to try out many different approaches (outside in, bottom up, functional and object-oriented languages, using no else or primitive types, closed eyes and an hand tied behind your back...)

I will write more about the experience in Milan in the next days on DZone. Here are my articles published in the past week.
Practical PHP Refactoring: Replace Parameter with Method is about simplifying a method's argument list by eliminating premature parameterization.
Clojure for dummies: a kata is the FizzBuzz problem implemented in Clojure, a now-popular Lisp dialect.
Practical PHP Refactoring: Introduce Parameter Object is about replacing a list of parameters with a single object.
HTML5 Drag and Drop uploading outlines how this technique works, when it breaks and how you can get it in your application in a few minutes.

XPUG Milano, November 30th

Yesterday Uberto Barbini held the second part of his Agile Day presentation at the eXtreme Programming user group in Milan. Here are the topics of the talk and the discussion, that you can also follow on the slide deck.

At the conference (video in Italian), Uberto covered only part of the presentation, so he restarted from the half presentation check:

• many bugs are caused by shared, inconsistene state
• the procedural paradigm doesn't care how you organize state
• OOP encapsulates state inside objects
• functional programming expels state from pure functions.

An example of OOP went wrong was a MyBag object which allows read and write access to any item inside. The Singleton pattern used for no reason and the absence of any form of Dependency Injection are other common pitfalls: just because a piece of code contains many classes and methods it does not mean it is object-oriented.

The Blackboard

An interesting thing came up while this non-OO code was presented to us: we cannot judge a design without knowing which is the underlying problem it solves. While changing class names simplifies a slide, the same Blackboard metaphor can be implemented with wildly different results:

• in the case of a list of actions to perform, it couples the actions in a certain order; the first or second action populates the blackboard for the other ones and cannot be moved.
• in a distributed scenario, it decouples different processes from knowing the rest of the system, and allows new configurations.

Yet the scenarios are identical if not for the names of classes and methods.

The presentation went on to compare the object-oriented and functional approach as different tools for solving different problems: they are not always in competition, but code can contain a mix of both according to the problem at hand. For example, Uberto cited simulations as a really natural place for objects, and transformations of data into different formats (XML, JSON) as a call for pure functions.

This reminded me of the Expression Problem and of how new requirements favor either the functional or object-oriented solution.


Rebecca's book

I'm not sure I will understand the Centralized/Dispersed/Delegate control comparisons before reading Rebecca Wirfs-Brock's book on design, but an issue that came up is that this kind of books is disappearing, despite being very handy in teaching design. Today we see many technical books which teach how to code in Java or Clojure or Ruby, but not book on how to model and solve problems with code.


Elegance and familiarity

A final note is Rick Hickey's (inventor of Clojure) quotation:

Elegance and familiarity are orthogonal.

Just because we see functional code as strange and different from the object-oriented approach, it does not mean it's inelegant: probably just that we are not familiar with it. It is closed against different changes than the equivalent OO solution; and a functional programmer will see our objects as inelegant too.

PHPUnit_Selenium 1.1.1 has been released

Yesterday Sebastian reviewed my PHPUnit_Selenium master branch and release a new package in the phpunit PEAR channel. You can install it along with PHPUnit easily:

$ sudo pear install phpunit/PHPUnit_Selenium

Before this release, PHPUnit_Selenium was broken when used with PHPUnit 3.6.

I'm closing several more issues and I plan to cover with tests the 2K lines of code contained in the package: currently the test coverage is terrible. After the current features are covered, we can start thinking about supporting the Selenium 2 API (based on WebDriver). In any case, I will keep backward compatibility: support for WebDriver will come with another base Testcase Class.
If you want to contribute, consider providing tests for the functionality you are using. For example, the following areas are uncovered:

• running Selenese tests
• all the Custom Assertion methods
• running tests in multiple browsers.

Acceptable tests comprehend an HTML page to use as a target and the actual test, written in Selenese or using PHPUnit_SeleniumTestCase. If you want your pull request to be immediately accepted, provide a test along with the rest of the code. You can take some inspiration from the existing ones in the Tests folder, which will serve as examples.

There is an undocumented, experimental feature in this release: call PHPUnit_Extensions_SeleniumTestCase::shareSession(true) in your bootstrap and the browser session will be shared between tests; a new session will be restarted only after non successful tests.
 It will be up to you to reset the state of the browser to perform new tests, and will leave the browser windows open after the end of the run: it's called experimental for a reason.