My first Katayuno

Coding Katas are small problems from a known domain, with the objective of practise basic programming elements and TDD.

Katayunos are the combination of “Coding Katas” and “Desayunos” (which means breakfast in Spanish). It consists on sitting in pairs, in front of a laptop, choose one of the available katas and programming language and have breakfast while working on the given problem practising TDD and thinking about the best approach to solve the problem.

Well, this weekend I’ve been involved on my first Katayuno experience, at Softonic offices. The practised kata was KataBankOCR, where we are given with an ASCI numbers and we have to transform that into a String, not very complex but it had an interesting point into the test.

At the first iteration, we were tackling the problem wrong. We spend some time trying to validate the input and where a bit slow because our strict state (RED – GREEN – REFACTOR) of TDD work-flow. At the end of the first iteration we were discussing about how much we have to cover with the test. On that problem, we can’t test much more than “for a given input” which is the “expected output”.

What you think about testing private methods?

Obviously you can’t test private methods straight away, but you can work around that. However, we agree that doing that is not a good test case. The main reason is that we want to test the problem, not our concrete solution about the problem. The point is that at the end of the exercise, we could switch tests and our code shall keep passing both tests.    

On the second iteration we got it right (in PHP) and in the third and last iteration I had the chance to play with Jasmine, a test library for Javascript (pretty cool stuff). I’ve uploaded my code into Github. Pretty good exercise overall, and felt like I’ve learned and enjoyed.

 

How to name interfaces / abstract classes with namespaces

I’m building a new library with the aim to parse venues from Internet (code on Github). Well, aside from the purpose or usage of the library I’m using this project development to try to write the domain oriented code and by the way I’m facing some arquitectural problems.

Basically, in the past the most common convention for naming interfaces or abstract classes was the following:

For the interface (lib/domain/venue/interface.php):

interface venues_domain_venue_interface {}

And for the abstract (lib/domain/venue/abstract.php):

abstract class venues_domain_venue_abstract {}

Now, I want to port this code to PHP 5.3 Namespace format. The translation is not that direct, note that “abstract” and “interface” are reserver keywords and I can not use then to name my clases.

For the interface (lib/Domain/Venue/Interface.php):

use Venues\Domain\Venue;
 
interface Interface {}

And for the abstract (lib/Domain/Venue/Abstract.php):

use Venues\Domain\Venue;
 
abstract class Abstract {}

That will simply break with a PHP Parse Error because the “Interface” or “Abstract” are reserver keywords.

Researching on Internet I’ve found the following options:

 

1. Prepend the domain name

For the interface (lib/Domain/Venue/VenueInterface.php):

use Venues\Domain\Venue;
 
interface VenueInterface {}

And for the abstract (lib/Domain/Venue/VenueAbstract.php):

use Venues\Domain\Venue;
 
abstract class VenueAbstract {}

 

2. Append the domain name

For the interface (lib/Domain/Venue/InterfaceVenue.php):

use Venues\Domain\Venue;
 
interface InterfaceVenue {}

And for the abstract (lib/Domain/Venue/AbstractVenue.php):

use Venues\Domain\Venue;
 
abstract class AbstractVenue {}

 

3. Prepending “I” or “A”

For the interface (lib/Domain/Venue/IVenue.php):

use Venues\Domain\Venue;
 
interface IVenue {}

And for the abstract (lib/Domain/Venue/AVenue.php):

use Venues\Domain\Venue;
 
abstract class AVenue {}

 

4. Append “Class”

For the interface (lib/Domain/Venue/InterfaceClass.php):

use Venues\Domain\Venue;
 
interface InterfaceClass {}

And for the abstract (lib/Domain/Venue/VenueClass.php):

use Venues\Domain\Venue;
 
abstract class VenueClass {}

 

References:

Some good and bad things from PHP

As a PHP developer I recognise that I’m not as opinated as I should be. When someone asks me “Why I’ve choose PHP” I just say that it’s because it was the first language I’ve deep into and I’ve keep developing myself into PHP (it’s what it allows me to develop more in less time). Once you know a language and you have enough knowledge is interesting to move into other languages so you can open your mind and get a better understanding of your preferred language (exactly like learning another spoken language). I hope I can learn any other language soon ;)

I’m going to summarize some pros and cons from PHP as a interesting excersise for myself:

Advantages:

  • Documentation: At the beginning is difficult to get use to (like any other documentation) but when you are into it, it’s pretty handy. My usual searches on google are “php array functions” or “php string functions”. A good point is allowing the comments from the users, some of them really interesting.
  • Easy to start: It’s easy to install WAMP (on Windows) or using php on cli with *NIX. There are lots of tutorials and all-known open source projects to look at the source code to learn more (WordPress, Drupal, etc.). Furthermore, you can got a cheap host easily.
  • Web optimized: Really easy to access to GET and POST variables and by default there is a direct map between the file and the URL. This kind of things make it easy to learn.
  • Right model: Requests are isolated from other requests and if it goes wrong, that is too isolated, which means that you can leak memory, have terrible bugs or infinite loops and you will not kill your server beause Apache is on top of that.
  • Scaling: Is relative common knowledge to scale PHP, you can search on Internet and you will find lots of tutorials, tips, etc.

Disadvantages:

  • Error handling: There is more than a single way to handling errors: trigger_error(), Exceptions and returning codes. Not having a unique and organized way make libraries mix all of this methods and sometimes makes it difficult to trap.
  • Too many falses: Not having a typed variables makes all this expressions evaluate as false: null, false, empty string, zero, the string containing ‘0’ and empty array.
  • Initialization: There is a lot of things that can be modified on the php.ini and it could change from server to server. Not a big pain but should be aware.
  • Returning arrays: If a function returns an array you have to assign it to a variable before accessing an element, you can’t just add an index after the function call.
  • No multiple inheritance: PHP doesn’t support multiple inheritance.
  • Evolving language: The fact that it’s evolving and having new features in each release has other constraints: “register_globals” (“script.php?auth=1″ sets $auth as TRUE by default), “magic_quotes” (that’s not for security and people is relying on that) and “PHP4’s object reference model” (where references didn’t point to the object, they were pointing to the variable).
  • Others: Lack of case sensitivity (“$variable” is the same than “$VaRiaBLe”), needle and haystack vs haystack and needle in different array methods, having to use “array()” instead of just “[]”.

Profiling your database in Zend Framework

Just a quick tip for all Zend Framework developers.

Imagine I’m getting an error from a select that I’ve created:

$questionRow = $this->fetchRow($select);

If you want to see which query is being executed on your database, you can go with something like that:

$db = Zend_Db_Table::getDefaultAdapter();
$profiler = $db->getProfiler()->setEnabled(true);
 
// like before
$questionRow = $this->fetchRow($select);
 
$query = $profiler->getLastQueryProfile();
var_dump($query);
die;

That will print the SQL query that has just been executed.

Error messages in Zend Form .ini file

I was searching the way to customize the validator error messages in Zend Form using the .ini file.

Finally I found two useful links:

  1. Rob Allen answering in StackOverflow
  2. One guy asking a similar question in Nabble

I copy here the content of my form.ini:

; apellido
elements.apellido.type = "text"
elements.apellido.options.label = "Apellido"
elements.apellido.options.description = "Introduce tu apellido"
elements.apellido.options.validators.notempty.validator = "NotEmpty"
elements.apellido.options.validators.notempty.options.messages.isEmpty = "Campo requerido"
elements.apellido.options.validators.notempty.breakChainOnFailure = true
elements.apellido.options.validators.strlen.validator = "StringLength"
elements.apellido.options.validators.strlen.options.min = "1"
elements.apellido.options.validators.strlen.options.max = "100"
elements.apellido.options.required = true

Some useful tips that you might know:

  • If you don’t put the “options.required = true” the “NotEmpty” validator doesn’t work.
  • If you don’t put the “breakChainOnFailure = true” the form will carry on executing other validators.
  • You can search in the Zend Framework source code for the messages that you can overwrite. Look at: “Zend/Validate/*” files.

I wish it will be useful for somebody =) !

Buenas prácticas en PHP

Miguel, mi buen socio y mejor amigo ha estado impartiendo las dos semanas anteriores el curso de PHP Avanzado (programa en pdf) de Jedi (Junior Empresa). Se trata de unos cursos de verano que ofrece esta organización adherida a la UPC. Yo le he estado echando un cable a modo de becario.

Estuvo repasando en una de las sesiones de teoría las buenas prácticas a la hora de escribir código en PHP. A continuación las recopilo, pues aunque algunas sean obvias y parezcan básicas creo que es importantes tenerlas en cuenta, sobretodo si se trabaja en grupo. Además, PHP es tan flexible que permite hacer muchas marranadas.

1) Usar “soft tabs” (seguido de espacios) o bien configurar el IDE para que el botón de tabulación se transforme automáticamente en X espacios (normalmente 4). Esto evita los típicos problemas de indentado al leer el código en distintos editores de texto.

2) La llave que abre los bloques “{” debe ir en la linea siguiente de la declaración.

3) Pautas para nombrar clases:

  • Letra inicial en mayúscula.
  • Resto de nombre se escribe en CamelCase.
  • Se usa “_” para indicar la capa o paquete en la que se encuentra la clase (normalmente el folder).

4) Pautas para nombrar variables:

  • Poner nombres entendibles, explicativos y concisos
  • Usa camelCase

5) Pautas para nombrar constantes:

  • Toda en mayúscula
  • Distintas palabras separadas por “_”

6) Pautas para nombrar métodos:

  • Si es privado, añadir el “_” delante del nombre de la función

7) No usar “open tag” <?.  Estos pueden ser confundidos con el inicio de código <?xml. En su lugar, usar siempre <?php.

8) Para documentar usar siempre /* */ o //, nunca usar #.

Estas son algunas. Seguramente haya mas … si alguien quiere completar la lista lo añadiré sin ningún problema.

Editado: Añado algunas más que he recibido mediante los comentarios de CPS 2.0.

9) Los string literales van entre comillas simples:

$a = 'Example String';

Nota: Yo uso por defecto las comillas dobles, por el tema de los apostrofes en catalán. Lo importante es definir un estándar.

10) En la concatenación usar espacio antes y despues de “.”:

$company = 'Zend' . ' ' . 'Technologies';

11) Para concatenacion multilinea, poner el “.” en la linea siguiente y tabularlos a la altura de “=”:

$sql = "SELECT `id`, `name` FROM `people` "
. "WHERE `name` = 'Susan' "
. "ORDER BY `name` ASC ";

Muchas gracias por la colaboración ;) !

Función de swap sin variable aux

Este es el típico problema que te ponen a veces para probar tu habilidad como programador.

Tienes que hacer una función para cambiar los valores de dos variables sin usar una variable auxiliar.

La función que a todos se nos ocurre és:

function swap($a, $b) {
   $tmp = $a;
   $a = $b;
   $b = $tmp;
}

Pero esta no cumple el enunciado. Una posible función que si cumple el enunciado es la siguiente:

function swap($a, $b) {
   $a = $a + $b;
   $b = $a - $b;
   $a = $a - $b;
}

Edición 05/07/2010:

Juan Antonio Galán, mediante los comentarios me hace llegar esta solución:

function swap($a, $b) {
   list($a, $b) = array($b, $a);
}

Y Víctor me comenta esta otra:

function swap($a, $b) {
   $a ^= $b ^= $a ^= $b;
}

Muchas gracias por vuestra aportación ;) !

Por qué Zend Framework?

El otro día recibí un comentario de un lector de mi blog y me preguntaba:

Pau, por que  Zend Framework? Vi que hace un tiempo habías hecho un post sobre CakePHP.

Voy a dar la respuesta a este comentario en forma de post. Es cierto que había escrito un post sobre CakePHP. Un amigo (Xavier Orduña) me lo presentó y lo probé. Entonces aún no conocí­a ningún framework de desarrollo y, al topar por primera vez con Cake, me pareció una manera muy rápida de agilizar el desarrollo de una aplicación web.

Un tiempo más tarde, y sin haber profundizado con Cake, probé Zend Framework. También me lo recomendó otro amigo (Claudio Cossio) y tengo que confesar que me gustó más que Cake.

Ya llevo un tiempo desarrollando con Zend y después de un par de proyectos, puedo sacar las siguientes conclusiones. Antes advierto que no soy un experto en frameworks, he tocado mas o menos en profundidad Zend, he jugado con CakePHP y Django (para Python) y me han hablado muy bien de Symphony, así que ya aviso que mi punto de vista va a estar desviado.

  1. Documentación correcta: Acostumbro a consultar su documentación a menudo y está bastante bien, con ejemplos bastante bien explicados y sobretodo prácticos.
  2. Sencillo: Es relativamente sencillo de montar una aplicación básica con Zend Framework. Si luego quieres ir un poco más allá ya en cuanto a complejidad, ya vas a tener que mirarte la documentación.
  3. Completitud de módulos: Tiene módulos para casi todo. Una vez empiezas a programar con él, cada vez que revisas los módulos encuentras alguno que te va a ser útil.
  4. Zend está detrás: El hecho de que Zend, la compañía que desarrolla PHP está detrás de este framework me da una cierta seguridad de que será mantenido y que dará soporte por mucho tiempo.
  5. Patrones de base de datos: Me encanta el patrón de diseño que usa ZF para acceso a la base de datos: Table Data Gateway y Row Data Gateway. Me imagino que la mayoría de frameworks deben usar cosas parecidas, pero la manera en que lo resuelve Zend Framework es especialmente cómoda para el programador.

Por último, cito las palabras del amigo Carlos Buenosvinos en una de las discusiones del Grupo de programadores PHP Barcelona, en respuesta a “¿Qué framework PHP usáis?“:

Has de considerar, la comunidad, la continuidad, performance, si está basado en componentes o no (migrar o nueva aplicación desde 0), contenido en la red, libros (material didáctico), oferta de desarrolladores (en el caso de que quieras contratar), funcionalidades totales, funcionalidades que se adaptan a tus requerimientos, funcionalidades que le faltan para tu aplicación, si tienes desarrolladores en tu equipo que ya conozcan algún framework, soporte con PHP 5.3 (compatibilidad hacia atrás, sin compatibilidad, …), etc. No te dejes llevar por modas, como siempre, la respuesta es depende.

Pues nada, saludos y disfruten de las vacaciones de navidad (quien las tenga!).

PHP Conference 2009

La gente de PHP Barcelona se han animado, como cada año, a montar una la PHP Conference 2009, una conferéncia relacionada con PHP que se celebrará el 30 y 31 de Octubre en el Citilab, en Cornellà. Como podéis ver, el planning parece muy interesante.

Seguramente asistiré, como mínimo el sábado. Para los amantes del Facebook han creado el evento. Si os habéis decidido a venir apuntaros e invitar a todos vuestros colegas.

http://www.facebook.com/event.php?eid=150863109670

De cara a la promoción podéis seguir también a su twitter:

http://twitter.com/phpbarcelona

Han empezado a usar el topic #phpbcn2009 si alguno se anima a hablar de la conference usándolo más promoción para el evento de una manera sana y gratuita.

¡Espero veros ahí!