Why PHP is not my favourite language?

Because I'm not a web application developer; I'm an enterprise application developer, who sometimes writes Web apps. So I use Perl.

What are your reasons?

Why Perl is my favourite language?

"Because it's different, like me"

Please, post your answer to this question, I'll make a resume with them. Thank you!

21 - Perl 6

Hola, acaba de salir reciente la última compilación 21 de Rakudo, la implementación de referencia de Perl6. Siempre me ha gustado el 21, quizás por ser el siglo en el que estamos, quizás porque es el día en que cambian las estaciones del año, quizás porque fue el dorsal con el que Perico Delgado ganó aquel mítico Tour de Francia del 88, quien sabe.

Bromas aparte, creo que ya podemos usar una versión bastante evolucionada de la implementación (no para producción, a mi juicio), para ir probando y saboreando sus nuevas características y empezar a escribir al respecto. Sí, ha llegado ese momento largamente esperado de arremangarse y adentrarse en las aguas aún poco profundas del lenguaje.

El aprendizaje de un nuevo lenguaje nunca me ha preocupado, he llegado a utilizar demasiados como C, C++, Fortran, Basic, Pascal, Perl 5, Java, C#, Groovy, y unos cuantos ensambladores (x86, 68000, MIPS) todos ellos con cierto nivel de profundidad, y en algunos casos con mucho conocimiento. La verdad es que es algo que me llama la atención y me gusta. Ojala pudiese aprender idiomas con la misma facilidad. Ahora llega el momento de coger las riendas de un nuevo caballo llamado Rakudo y me dispongo a disfrutar de la montura, los comienzos serán un momento perfecto para adaptarnos mutuamente. Sí digo bien, adaptarnos.... quiero probar eso de poder hacer mutaciones a mi gusto y tener mi dialecto. Creo que el tema de los DSL es algo muy importante para los próximos años.

Por otro lado, y es lo que más me preocupa, es que un lenguaje pese a que es fácil de aprender, donde muestra su potencial es en el conjunto de librerías y utilidades que lo complementan.... mucho trabajo por hacer aquí hasta que haya un CPAN6 decente y usable... ahí es donde hay que centrar el esfuerzo en los próximos 2 años, en mi opinión.

Bueno, me auto-deseo suerte, valor y ... al Rakudo!

¿Te animas?

I have an idea (2)

How can we improve the use of Perl ?

This is a simple question, many peope has answered it, and in this article I'm going to present my idea in this area.

Often, we say that CPAN is our main tool in order to develop some kind of solution, and we are right. But CPAN provides many different ways to do the same thing, someones are good and others aren't (TIMTOWTDI). CPAN should show the number of downloads of each distribution, and the activity (number of changes per unit of time). We are lazy, I know; but comments in modules and feedback are wellcome.

With this tools (Perl+CPAN), we need to build applications. Reference applications. There's a few in my opinion. In different areas (not only Web, we are tired). If we can create a set of modelic applications, people will ask for the tools used to build them. This is a very important thing: define a collection of important projects, and assign a development group.

We need to be present at the cloud! it's time for it!

I have an idea (1)

Until now, I have written my posts in Spanish. My first idea is turn to English in order to allow more people will be able to read this blog. So, I hope my poor English level won't be an obstable.
With this "I have an idea" series, I try to explain some ideas that cross my mind. Sometimes they will be crazy, or boring, or interesting.

The first idea title: "PSR - Perl Specification Request". Last years, we are experimenting a slow and progressive descrease of Perl-enterpise use. Other platforms like JEE and .NET are growing. We need to improve our presence in this scenario, but how? Perhaps we can pay attention to success projects in this area, and create or improve similar things in our environment. For example, I like the EJB3 model in JEE to build enterprise applications, covering topics like scalability, security, transactions, etc. There is a set of specifications for EJB3, and many providers have built their products according with them.

Perl6 introduced a new concept in our world: specification. Rakudo is one implementation of that one. This is a very important thing, we should use. Why not create a PSR group? His job will be create the specification of hot topic areas, like web objects, persistence, rules, busines process model, validation, etc. The each group of people will implement their own solution. The PSR could propose a test-suite in order to ensure the implementation is correct.

This is a simple idea, but with a big amount of work to do:

• Organizative, in order to identify the specification areas, the specification propossal procedure, the interfaces between specifications, the work plan and scheduled tasks
• Technical, with two levels: first the specification group, which makes the interface definition, defines the funcionality and build the test suite. Second, the workgroup that implements the specification

I think we need to improve in a organizated way, and perhaps this idea may be a good starting point in order to define a scenario in which we will feel confortable. Rakudo will be probably released next spring, and this will be a good starting point. The specification model I have proposed may be the main concept to build CPAN 2.0.

What do you think?

Proxy object

Los objetos proxy constituyen un concepto avanzado que se asemeja por completo a los más conocidos servidores proxy, los cuales actúan como intermediarios entre el cliente y el servidor. En nuestro caso, un objeto proxy constituye una especie de envoltorio "invisible" (wrapper) sobre un objeto que es el que al final queremos invocar.

Probablemente te preguntes para qué te sirve esto, la verdad es que cuando se conoce bien, uno se pregunta como es posible no haber conocido de su existencia previamente. En resumidas cuentas, siempre que tengamos que hacer algo adicional a una simple llamada a un método de un objeto, el Proxy es un buen candidato a cubrir esta necesidad.

Una razón para controlar el acceso a un objeto, es precisamente aplazar la creación e inicialización del mismo hasta que realmente lo necesitamos (obviamente en aquellos casos en los cuales esto tenga un coste significativo). Un ejemplo puede ser la carga de un documento que contiene además de texto, multitud de imágenes incrustadas. Obviamente no es necesario cargar todas las imágenes al principio, ya que con un alto grado de probabilidad no serán utilizadas inmediatamente. En este caso, conviene realizar la carga bajo demanda, y es donde entra el Proxy ya que a todos los efectos se puede considerar como un objeto del tipo que enmascara (Imagen) pero con capacidad de programar e interceptar la llamada al método que deseemos. Imaginemos que el método es "draw", en este caso aprovechamos en el proxy para crear el objeto Imagen y a continuación invocar a "draw".

Según el tipo de uso, hay gente que clasifica los objetos Proxy en alguna de las siguientes categorías:

• Remote proxy, que se encarga de codificar la petición y sus argumentos para enviar la solicitud y recibir la respuesta del objeto real. Un ejemplo de esto suelen ser las llamadas a Web Services, que nos aislan de toda la complejidad de tratar con las peticiones sobre la capa de transporte elegida (http, smtp, ...)
• Virtual proxy, para dotar de un nivel de cache al objeto que se está llamado. Imagina aquellas situaciones en las cuales la respuesta del objeto real es la misma ante la misma entrada, el proxy puede cachear las respuestas e invalidar las mismas en base a determinados criterios
• Protection proxy, para verificar si la llamada tiene suficientes privilegios como para poder realizarse

Bueno, vista la parte "teórica", quizás esté bien ver un poco de código ¿no crees?

package Proxy;
use strict;
use Carp;
use UNIVERSAL qw/can/;


our $AUTOLOAD;


sub new {
  my ($class, $target) = @_;
  return bless {TARGET=>$target}, $class;
}


sub isa {
  my $self = shift;
  return $self->{TARGET}->isa(@_);
}


sub AUTOLOAD {
  my $self = shift;
  my @params = @_;
  my $method = substr($AUTOLOAD,7);
  return if( $method eq 'DESTROY' );
  my $target = $self->{TARGET};
  if( defined $target ) {
    if( UNIVERSAL::can($target, $method) ) {
      return $target->$method(@params);
    }
    else {
      croak "Proxy target doesn't support $method method";
    }
  }
  else {
    croak "Proxy target hasn't been set $target";
  }
}

1;

Como puedes observar, se trata de la definición de un módulo Proxy que hace uso del método especial AUTOLOAD de Perl. Recuerda, esta función (si existe) se llama cada vez que no se encuentra un método que se está intentando llamar. En AUTOLOAD, simplemente se verifica que el método existe en el objeto destino, y si es así, se llama.
Para probar esto, imaginemos que tenemos otra clase Persona, muy sencilla (con ayuda de Class::Accessor):

package Persona;
use base qw(Class::Accessor);


Persona->mk_accessors(qw(name role salary));

1;

Bueno, hasta ahora nada del otro mundo. Imaginemos ahora que nos piden que la propiedad "salary", cada vez que sea consultada, debe quedar constancia en un fichero de quien lo hizo. Nuestra primera intención podría ser ir a tocar la clase Persona y meter el código donde corresponda. Sin embargo, a mi juicio, eso "ensuciaría" la clase con cuestiones que no le son propias. Y además para algo tengo que utilizar el tema del Proxy, que para eso lo he explicado...

En primer lugar, creamos una clase que hereda de la anterior y que hace el trabajo de log en el fichero:

package Proxy::Persona;

use base 'Proxy';
use strict;
use autodie;

sub salary {
  my $self = shift;
  my @params = @_;
  if( @params ) {
    $self->{TARGET}->salary($params[0]);
  }
  else {
    open my $fh, ">>person.txt";
    my @now = localtime(time);
    printf $fh "[%02d-%02d-%d] %10s %s\n", $now[3], 1+$now[4], 1900+$now[5], getlogin, $self->{TARGET}->salary;
    close $fh;

    return $self->{TARGET}->salary;
  }
}
1;

Y a continucación creamos un fichero para probar que esto ha funcionado:

use Persona;
use Proxy::Persona;

$p = new Persona;

$p->name('JOSE');
$p->role('MANAGER');
$p->salary(2000);

$x = Proxy::Persona->new($p);
print "Salario: ", $x->salary(), "\n";

Precisamente el último print, es el que sirve para llamar al método proxetizado y hacer el log. Cualquier otra llamada a cualquier otro método de la clase Persona, se llama sin mayor actuación. Es de destacar:

• La clase target (Persona) no se ha modificado para nada
• El script que utiliza la clase proxy debe ser modificado ligeramente para crear un objeto de la clase Proxy::Persona
• Toda la funcionalidad que deseemos añadir, figura en la clase Proxy::Persona, con lo cual queda mucho más limpio el resto del código que empleamos.

Bien, espero que con esta pequeña aportación, haya quedado mucho más claro para que sirve y cómo podemos beneficiarnos del uso del patrón Proxy.

Me gustaría conocer tus opiniones, no únicamente de este tema, sino de la línea de los artículos, o si hay algún tema que sea de tu interés y que pudiese ser motivo de una entrada. ¡Animo!