Los sectores del software

De siempre, se va viendo que las empresas de software se decantan por una forma de hacer las cosas, mientras que otras eligen otro camino distinto y, muy pocas, mezclan elementos de doctrinas tan establecidas y dogmáticas como son: el mundo del software libre, el mundo java o el mundo .net.

El mundo .NET

Como todo lo que tiene que ver con Microsoft, el mundo .NET se mueve, casi exclusivamente, con productos y herramientas desarrolladas por esta misma compañía. Funciona sobre Windows, con base de datos de Microsoft y se diseña con herramientas de Microsoft.

Lo bueno de Microsoft es que desarrollan los productos para un público general y sin conocimientos extensos. Los lenguajes suelen ser o muy fáciles (Visual Basic) o muy complejos (C++, C#), pero cumplen con todas las necesidades de los programadores a los que van dirigidas las herramientas. Así mismo, tienen un alto nivel de operatibilidad entre los diferentes productos, es decir, escribir código ASP con SQL Server es simple, gracias a ese nivel de compactación y simplificación.

Lo bueno de la simplificación lleva a lo malo de la complejidad también. Un programa que se hace de forma simple y fácil, siguiendo los pasos que Microsoft ha pensado para dar es simple, sencillo y rápido. Pero cuando la aplicación debe tener una forma específica o salirse un poco del camino típico, comienzan a surgir problemas solo saldables con código complejo.

Ximian, absorbida por Novell, ha realizado muchas aproximaciones a este mundo para portarlo al mundo del software libre a través de su escritorio Gnome y su proyecto Mono. No obstante, es un tema un poco espinoso, ya que quien usa software libre, por lo general, se aleja de las tecnologías propuestas por esta gran multinacional, por lo que, aunque es usada y tiene su cuota de mercado, Mono no llega a ser usado tanto como podría esperarse.

El mundo Java

El mundo de Java ha estado siempre en una lucha constante y abriéndose camino en el desarrollo de software, sin mucho éxito al principio, sobre todo en lo que respecta a las aplicaciones de escritorio. Esto fue debido a su naturaleza de pseudo-compilación y pseudo-interpretación, ya que es un lenguaje compilado e interpretado que se ejecuta sobre una máquina virtual, y las labores de interpretación de los bytecodes son algo costosos, en relación a código que se ejecuta de forma nativa.

No obstante, en la parte web, de interfaces, desde que comenzó, ha tenido una gran aceptación, puesto que permite el desarrollo de las aplicaciones en cualquier infraestructura (windows, linux, solaris, …) y se han desarrollado grandes herramientas para el desarrollo en este sentido.

Java siempre es el favorito y preferido de las consultoras (a menos en España), donde es empleado para el desarrollo de aplicaciones, tanto de escritorio como web en todos los sectores donde son contratados.

La mayoría de empresas que han tenido relación con Microsoft y han salido de malas con la grande, han terminado montándose al carro de Java y aportando a esta comunidad en modo de open source herramientas, conocimiento, etc. Además de Sun Microsystems (su fundadora), hay otras como IBM, RedHat, Oracle, etc. que se han sumado al carro de Java para el desarrollo y ampliación de esta comunidad.

Hay comunidades de software libre que se han sumado a la aportación de código para el mundo Java. Esto supongo que será erróneamente aportado como el voto útil, sin saber que en nada se beneficia al software libre en sí, sino solo al mundo Java que, aunque pueda parecer atractiva la idea de luchar contra el tirano, no es más que ayudar a una empresa a derrocar a otra. Esto puede ser muy discutible, sobre todo por los defensores de Java :-D

El mundo del software libre

Al margen de la guerra entre .Net y Java, surgen los entornos, sistemas y elementos de software libre. Pensar que todo el mundo tiene que ser Java o .Net es un craso error, ya que hay muchos elementos que se pueden combinar a gusto propio del desarrollador y emplearlos como mejor convenga para obtener los mejores resultados para una tarea concreta.

A este respecto, una de las comunidades con más auge es la de desarrolladores de PHP, por ejemplo, que es el lenguaje que más proyectos de software libre tiene desarrollados, y es el más usado para el desarrollo de sitios como Facebook, Menéame, Wordpress, etc.

Otra de las comunidades más activa en los entornos web es la de Ruby, Ruby on Rails más específicamente, que tiene un entorno fácil y profesional para el desarrollo rápido de sitios web. También Python, con su framework Django. Ambos presentes en el mundo Java a través de JRuby y Jython, respectivamente.

Entornos también desarrollados en lenguajes más específicos como Perl, Erlang, Tcl, etc. hacen que se complete el abanico de posibilidades para el desarrollo de software a través de las soluciones que aporta el software libre.

La nota negativa, es que los elementos no son altamente cooperativos, es decir, aunque se basan en estándares, normas y todos son abiertos, hay que realizar desarrollos para poder tener funcionando cosas entre unos y otros, debido a que en el software libre, no todo está hecho o viene dado fácilmente. Pero la nota positiva sobre esto, es que la dificultad que eso entraña es mucho menor que la que entrañaría el desarrollar algo no hecho o no pensado para hacerse, en Java o .Net.

Conclusión

En principio, no te quedes solo con uno, esto no son tres equipos a los que haya que apoyar a muerte, estas son tres formas de ver la tecnología y puede convenir cualquiera de las tres según el contexto en el que haya que ponerse.

Por ejemplo, en una empresa que se haya invertido en infraestructura y software Microsoft, se tenga todo montado en SQL Server, con ASP e interfaces desarrolladas en Visual Basic, desarrollar cualquier nueva ampliación o una nueva herramienta, cabe pensar que será siempre más fácil si nos ceñimos a lo ya establecido que si comenzamos a cambiar lo que hay.

Igualmente, en otra empresa en la que se haya realizado una inversión para Java, incluso con servidores Solaris, y bases de datos Oracle, no conviene pensar en desarrollar nada con Visual Basic, ni PHP, sino pensar en agregar más aplicaciones de tipo J2EE, que será lo más fácil de implementar.

Por último, en una empresa pequeña, con aspiraciones a crecer, que tengan todo desarrollado en PHP y MySQL, se podría cambiar a un framework de desarrollo para PHP, así como agregar elementos más complejos en caso de ser necesarios (como memcached).

En definitiva, no intentar cambiar lo que ya hay si funciona. Otro caso es que no funcione o que haya que realizar adaptaciones y se pueda aprovechar para agregar elementos más generales o estándares.

Comet ha muerto, ¡larga vida a websockets!

Leyendo el artículo de Joe Armstrong, sobre este mismo título, comenta que con la aparición de websockets (una nueva característica que ha aparecido en HTML5), el sistema comet y otros derivados, están abocados a la extinción.

Desde siempre, el sistema HTTP, llamado también web, ha sido un sistema cliente-servidor, donde el cliente siempre ha sido el navegador web, o cualquier herramienta que pudiese hacer una petición HTTP hacia un servidor, y el servidor, un ente pasivo, se encargaba de procesar la petición y retornar una respuesta. Nada más.

Una de las implementaciones más usadas por este sistema se produce gracias a la característica de HTTP 1.1 de mantener viva la conexión (keep alive) permitiendo al navegador realizar más peticiones y al servidor encauzar una respuesta progresiva, como una lluvia de estrellas (cometas) es el streaming, ya que el sistema puede enviar datos de vídeo progresivamente.

El problema viene dado, también, por la propia especificación de HTTP 1.1, donde se indica que sólo puede haber dos conexiones simultáneas con entre navegador y servidor, con lo que, el uso en una página web con hoja de estilos y bastantes imágenes puede no ser muy aconsejable.

¿Qué aporta de nuevo o de mejorado websockets? a través de HTML y JavaScript de forma simple, se establece una conexión con el servidor dada una URL y un sub-protocolo en el que deben de hablar. Una vez conectado, los elementos html pueden tener eventos del tipo: onopen, onmessage, onclose; indicando los tres eventos que pueden darse en la conexión y el diálogo abierto con el servidor.

Hay que recordar que la interacción vendrá dada por el servidor, esto es que, un programa ejecutándose en el servidor (que no tiene porqué ser de tipo web) puede enviar un evento al puerto especificado por el cliente y el mensaje ser recogido por el navegador y dárselo al elemento al que haga referencia el propio mensaje.

De momento, en Google Chrome se encuentra operativo y se puede probar. En el artículo de Joe Armstrong se puede descargar un código en Erlang para el servidor y un código HTML para el navegador.

Realizaré pruebas y ya comentaré la impresión que me cause el sistema.

Ruleta Rusa en Unix

Navegando por la red he topado con un blog en el que he visto la ruleta rusa de unix.

La idea es jugar, como si de una pistola se tratase, con el comando rm -rf / (lo cual elimina TODOS los ficheros del disco duro y unidades montadas que se tengan -si son accesibles-). El comando toma un número aleatorio y prueba si es divisible por seis. Si es así… ¡bang!, estás muerto, sino, puede volver a tirar :-D

[ $[ $RANDOM % 6 ] == 0 ] && sudo rm -rf / || sudo echo “You live”

Curioso, ¿no?

NOTA: este blog no se hace responsable de los malos usos de los comandos expuestos, de si se elimina toda la información de su disco por un uso irresponsable del mismo, etc. Mi consejo… no lo uséis… o al menos, crear una jaula para jugar.

La Regla de los Nueves

Esto es algo que aprendí, ahora hace ya unos 5 años, cuando comencé a instalar mi primer servicio de alta disponibilidad.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

Sistemas de Mensajes Encolados (MQ)

Hace poco me he encontrado con un problema. Tengo un entramado de servidores y comunicaciones entre cada uno de ellos. Cada servidor puede notificar, ya sea vía SOAP, HTTP, XMPP o mediante cualquier otro protocolo, un evento o una información a otro servidor del entramado, con lo que cada servidor se configura de una forma específica, con una serie de nombres de dominio o IPs.

El problema viene al querer aplicar escalabilidad al proyecto. Cuando no solo hay un equipo implicado, sino que existen dos o tres, los cuales hay que configurar bajo ciertas circunstancias.

Lo primero que pensé, es que, si le puedo notificar a la red de que sucede un evento en concreto, ya sea a una sola máquina o conjunto definido de estas (pero para todos los equipos la misma configuración), facilitaría la puesta en producción. Con lo que me puse a buscar y encontré MQ, message queue.

El encolado de mensajes

La comunicación de los equipos informáticos se basa en mensajes, en eventos, que deben de poder transmitirse de unos a otros cuando sucedan (si es que se quiere tener la máxima fiabilidad en la información que se trata).

Una forma es comunicar directamente al implicado, lo cual resulta un poco tedioso si los implicados son muchos y muy distintos.

Otra forma es mediante un sistema JMS o un MQ, como RabbitMQ.

El encolado de mensajes es un sistema que permite que un elemento perteneciente a un sistema de información, pueda comunicar un estado, evento o mensaje informativo o imperativo a otro conjunto de elementos dentro del sistema, para que interactúe con él.

Por ejemplo, si tenemos un servidor web, una interfaz, que controla un conjunto de máquinas encargadas realizar llamadas salientes, rastrear páginas de la web para almacenar información para un buscador o similar, y la interfaz quiere enviar parámetros nuevos de configuración a estas, puede hacerlo mediante el envío de un mensaje generalizado a ese conjunto de máquinas, y estas máquinas recibirán el mensaje en el momento que lo soliciten.

Esta utilidad es igualmente buena para cuando una interfaz web, por ejemplo de un estudio fotográfico, carga imágenes desde la web, las retoca con algún tipo de efecto, ajuste, etc. y más adelante permite su descarga. El sistema web puede enviar el evento al sistema de retocado de que hay una imagen disponible, y cuando la imagen ya está disponible, el sistema de retocado puede enviar otro mensaje de vuelta diciendo que ya está.

Quizás esto último podría hacerse mejor con una base de datos, pero con el sistema de mensajería, se eliminan los datos en el momento que ya no se necesitan, mientras que con la base de datos, esos datos podrían permanecer ahí de forma indeterminada.

Conclusiones

Los sistemas de encolado de mensajes tienen su utilidad, sobre todo, en sistemas formados por varias máquinas, con roles bien definidos y en las que se quiere afinar lo que son las conexiones y comunicaciones entre las máquinas.

La Técnica Pomodoro

pomodoroLa técnica de pomodoro al igual que GTD (getting things done) o ZTD (zend to done), son técnicas para realizar las tareas diarias de forma ordenada y evitando distracciones.

Esta técnica debe su nombre a un reloj de cocina con forma de tomate (pomodoro), ya que, la propia técnica se basa en la medición del tiempo con un cronómetro, como los utilizados en la cocina.

La lista de tareas

Básicamente, hay tres artecfactos que se emplean para poder realizar esta técnica:

  • Inventario de Actividades: donde habrá que recoger todas las tareas a realizar.
  • Tareas para Hoy: las tareas que se han planteado para hacer hoy. El criterio para su selección puede ser la prioridad, dificultad o antigüedad.
  • Registro: donde, diariamente se apuntarán las tareas realizadas, junto con los pomodoros empleados para su compleción.

La gestión del tiempo

La técnica en sí, se basa en la gestión del tiempo mediante cortos periódos de dedicación exclusiva. Esto quiere decir que, cuando se comienza un periódo, se debe de estar completamente dedicado a esa actividad hasta que suene la campana.

Para desarrollar la técnica con precisión, necesitaremos un cronómetro o un sistema que nos alerte de cuando comienza y termina un pomodoro. Como su origen indica, puede ser un cronómetro fijo y real en la mesa del trabajador (lo cual puede ser algo incómodo en una oficina con muchas personas trabajando) o uno informático como este.

Los pomodoros (entendidos como los periódos de tiempo) deben de ser de no más de 30 minutos, con lo que, lo ideal, sería tener períodos de 25 minutos, con 5 minutos de descanso y, cada 4 períodos, hacer el descanso extensible de 15 a 30 minutos.

Cada tarea puede ocupar no solo un pomodoro, sino varios, esto se registra al final en el registro, poniendo las tareas realizadas, junto con el número de pomodoros invertidos en su realización.

Las interrupciones

Cuando se está trabajando en una tarea concreta y entra otra distinta con mucha prioridad, tanto que no puede esperar al final del pomodoro actual, se anula el pomodoro en curso y se comienza otro nuevo con la nueva tarea.

Este es el punto débil, quizás, de esta técnica, ya que si la dinámica de trabajo es hacerlo con incidencias y/o peticiones, podría producirse un momento en el que ningún pomodoro pudiese completarse en ninguna tarea, con lo que, llegamos al punto de que no se usa, realmente, esta técnica.

Conclusiones

Para las tareas de desarrollo y sobre todo en proyectos, sin incidencias, esta es una gran técnica equiparable a GTD y ZTD. No obstante, si el entorno de trabajo es más orientado a eventos, a interrupciones, esta técnica no aplica, puesto que las propias interrupciones son las que van marcando los tiempos a poder aplicar.

Para saber más:

Entrenador (Coach) de Desarrollo de Software

El término de entrenador (coach) de desarrollo de software es un papel que suele ser muy importante en el quehacer diario de una empresa que tiene desarrollos de software, ya sean internos o para clientes externos.

¿Qué hace el entrenador (coach)?

Los cometidos del entrenador son dos, que pueden parecer contrapuestos, pero que se pueden combinar para conseguir lo mejor de cada una de ellas, según el momento en que se necesiten emplear:

  • El mentor, de las tareas propias de desarrollo, indicando e incluso enseñando con el ejemplo, el cómo se hacen las tareas. De este tipo, aunque no se suelen dedicar exclusivamente a esto, hay algunos en las empresas de software actuales.
  • El entrenador, propiamente dicho, se encarga de trazar la estrategia y encauzar a los jugadores dentro de la misma a hacer lo que mejor saben hacer para conseguir los mejores resultados. Realmente, cualquier jefe o mando intermedio se encarga de estas tareas mediante órdenes. El trazado del plan estratégico a seguir, el plan de proyecto, es algo que pocos jefes o mandos intermedios hacen.

La faceta del mentor

La labor de enseñanza es algo intrínseco al mundo de la informática, ya que todo avanza tan rápido, que es necesario ponerse cada poco tiempo al día de las nuevas tecnologías, y sobre todo, las que nos ayuden a mejorar el ritmo de desarrollo de nuestras labores cotidianas.

Por tanto, para hacer la labor de enseñanza, el perfil de coach debería de ser técnico, ya que, además, en el mundo en que vivimos, decir a un subordinado, ya estresado por el trabajo, que aprenda solo una tecnología y la aplique a un proyecto, puede ser el detonante principal de quedarse, poco a poco, sin equipo.

Por otro lado, si la formación es impuesta por el coach mediante ejemplos en el propio proyecto de desarrollo, ya sea por él mismo o por gente subcontratada que dé el primer paso (en caso de que el coach no tenga un perfil técnico). Como se suele decir predicar con el ejemplo.

La faceta del entrenador

Como es normal, un gestor de proyectos, es necesario e imprescindible que gestione de la mejor forma posible los recursos humanos y los proyectos que hay que realizar, dados por prioridades, para que cada uno de ellos se consiga terminar en el menor tiempo posible.

El gestor de proyectos debe de facilitar, al igual que el perfil de Scrum Master con su equipo, todo lo necesario para que su equipo pueda realizar sus proyectos.

Conclusiones

El coach es el perfil que estaría, en Scrum, jerárquicamente, por encima del Scrum Master y que ayudaría a los equipos a su gestión y promoción para su mejora.

Se encarga de la recepción de los proyectos, la valoración con los equipos o equipo específico, y su apilación en la lista de proyectos a realizar. Esta es, quizás su faceta más importante.

No obstante, la labor de enseñanza, hacer de mentor o facilitar mentores para sus equipos, no es nada desdeñable y debe de considerarse también como un punto importante en las tareas a desempeñar de este rol.

La Historia de Erlang

He encontrado un documento (en inglés) que redacta la historia de Erlang contada por su desarrollador principal, en los laboratorios de Ericsson:

Erlang fue diseñado para escribir programas concurrentes que se ejecutasen eternamente. Erlang usa procesos concurrentes para estructurar el programa. Estos procesos no tienen memoria compartida y se comunican por paso de mensajes asíncronos. Los procesos de erlang son ligeros y pertenecen al lenguaje, no al sistema operativo. Erlang tiene mecanismos que permiten que los programas cambien on-the-fly (en vivo) así, esos programas pueden evolucionar y cambiar sin detener su ejecución. Estos mecanismos simplifican la construcción de software implementando sistemas non-stop (que no se detienen).

El desarrollo inicial de Erlang tuvo lugar en 1986 en el Laboratorio de Computación de Ericsson. Erlang fue diseñado con un objetivo específico en mente: proporcionar una mejor forma de programar aplicaciones de telefonía. En ese momento, las aplicaciones de telefonía eran atípicas del tipo de problemas que podían resolver los lenguajes de programación convencionales. Las aplicaciones de telefonía son, por su naturaleza, altamente concurrentes: un simple switch debe manejar decenas o cientos de miles de transacciones simultáneas. Tales transacciones son intrínsecamente distribuidas y el software se espera que sea altamente tolerante a fallos. Cuando el software que controla los teléfonos falla, sale en los periódicos, algo que no ocurre cuando fallan las aplicaciones de escritorio. El software de telefonía debe también cambiar on-the-fly, esto es, sin perder el servicio mientras se realiza una actualización del código. El software de telefonía debe también operar en tiempo real, con ajustados requisitos de tiempo para algunas operaciones, y más relajado tiempo en otras clases de operaciones.

Como puede leerse en el extracto, Joe Armstrong, fijó los requisitos de Erlang en solucionar los problemas de un entorno altamente concurrente, que no puede permitirse caer y que debe de actualizarse sin pérdida de servicio.

Actualmente, esta definición casa con casi la mayor parte de servicios en Internet.

Cuánto cuesta un Proyecto de Software

Hoy ya hace unas semanas que en la empresa en la que trabajo se ha comenzado un movimiento positivo en favor de medir lo que cuesta realizar desarrollos de software, dentro del departamento de desarrollo, lo cual es positivo desde el punto de vista del desarrollador, del programador y de los directivos.

Hay que tener siempre presente que, cuando se realiza un trabajo, ya sea el que sea, si lo realiza una persona ajena, no de la empresa, se paga una factura por sus servicios, en los que viene detallado, normalmente, la mano de obra, que suele cobrarse en factor de tiempo empleado.

El coste asociado de emplear a una persona que está en nómina, dentro de la propia empresa, puede ser menor, pero no cero. Si un empleado cobra en bruto unos 2000 euros mensuales y le mandamos hacer un trabajo para lo cual gasta todo un mes, es de lógica pensar, que ese trabajo me ha costado esos 2000 euros, ya que es lo que ha hecho el empleado. Si el proyecto al final solo hace ingresar a la empresa 200 euros, la empresa ha perdido con ese desarrollo 1800 euros.

En el caso de que un proyecto se desarrolle en dos semanas de ese trabajador, por redondear, damos que son 1000 euros el coste y se consiguen 1200 euros. La empresa ha conseguido con su labor 200 euros… pero si el desarrollo ha sido deficiente, por el poco tiempo empleado, y el programador tiene que ir invirtiendo horas, que al final resultan ser días (en suma) y llegan a ser otras dos semanas, tendremos que esos 200 euros se convierten en 800 euros de pérdidas.

El las metodologías ágiles se hace hincapié a dar valor, es decir, realizar el desarrollo por iteraciones, siempre haciendo lo que más valor dé al cliente. Por ejemplo, si tenemos 10 requisitos en un proyecto, impuestos por el cliente, pero los más importantes son los 2 primeros, podemos negociar con el cliente el hacer esos dos primeros, valorarlos con el tiempo que toma el realizarlos y, en caso de querer el resto de requisitos, o algunos más, volver a realizar otra petición.

¿Qué conseguimos con esto?

  • Que el cliente pida lo que necesita, únicamente.
  • Que el precio que se pague sea el justo y necesario, e incluso no muy desorbitado para el cliente.
  • Que la estimación de tiempo sea más ajustada a la realidad, siendo los plazos de desarrollo más cortos.
  • Que el cliente consiga su producto, su valor, antes.

Por lo que recomiendo a todos los que trabajan en nómina en una empresa, y su jefe (o siendo jefes) no se lleven el cómputo de horas invertidas en proyectos, incidencias, etc., que lo hagan, porque es una moneda de cambio muy útil para cuando se quieren conseguir cosas importantes, dentro de la empresa.

PHP 5.3

Llego algo tarde, cosas del verano, pero voy a comentar algunas de las mejoras que vienen incluidas en la nueva liberación de PHP, la 5.3.

Para mi, esta versión, además de corregir fallos de la anterior, aporta características que le hacen acercarse aún más a la forma de programación profesional que viene dada con otros lenguajes como Java, C#, C++, Python, Ruby…

Espacios de nombres (namespaces)

Los espacios de nombres, llamados en otros lenguajes: paquetes, módulos, …; con esto, podemos tener organizado nuestro código, no solo en directorios, sino también bien delimitado su espacio de nombres mediante el uso del namespace.

Por ejemplo, si tenemos dos directorios: File y BD; que pertenecen a un programa y cada uno de ellos tiene un archivo para contener la clase Output, en las versiones anteriores de PHP habría que incluir uno u otro, o modificar el nombre para que fuese FileOutput y DBOutput, redundando la ruta con el nombre de la clase.

Ahora, con el uso de namespaces, se puede delimitar con solo agregar una sección de código como esta:

namespace File {
 
    class Output {
        /* ... */
    }
}
 
namespace {
    $f = new File\Output();
}

Static… ahora sí

En las versiones anteriores de PHP, los valores static no eran tratados del todo bien, no permitiéndose algunos usos que parecían lógicos y no produciéndose, sobre todo en la herencia, los resultados que se esperaban.

Ahora, ya se permite el uso de variables para contener el nombre de la clase a la que llamar de forma estática, es decir, ya se permite este uso:

class A {
    public static function say() {
        echo "Hola\n";
    }
}
 
$clase = "A";
$clase::say();

Así mismo, el uso del late state binding, es posible mediante la palabra clave static, de modo que, si se llama a un método estático como static::metodo() en lugar de como self::metodo(), se llama al método de la clase hija que haya sobrecargado al método que se llama. Un ejemplo:

class A {
    public static function who() {
        echo __CLASS__;
    }
    public static function test() {
        static::who(); // Here comes Late Static Bindings
    }
}
 
class B extends A {
    public static function who() {
         echo __CLASS__;
    }
}
 
B::test();  // output: B

Por último, la función especial __call no se llama cuando no hay un método de clase que no exista, en su lugar se llamará a __callStatic, de modo que se pueda hacer diferencia de cuando se está llamando a un método de objeto y cuando se llama a un método de clase.

Más de Late State Binding

Hasta ahora, cuando se quería hacer una clase abstracta que llamase a funciones de sus clases hijas, que aún no han sido declaradas, éstas debían ser abstractas. Pero si la clase no era abstracta y el método a llamar no constaba como abstracto, la llamada no se realizaba a esa función, sino a la del padre.

El sistema de late state binding, asegura que la llamada a métodos se hará siempre de abajo a arriba, es decir, si existe un método en la clase hija que se instanció, aunque el método en ejecución sea el del padre, el método que se llama es el de la clase hija. Más o menos lo que se vió con los métodos estáticos, pero esta vez con métodos.

Funciones anónimas

El uso de funciones anónimas (closures o lambda) es una técnica de programación que permite completar código escrito, mediante el desarrollo parcial de algún algoritmo. Imagina que quieres hacer un código en el que tengas que hacer algo, un paso inicial, un paso intermedio y, en cada iteración una ejecución específica, para terminar con un último paso tras esa iteración.

El código concreto dentro de la iteración puede variar… y de hecho variará en cada implementación, pero el resto no, el resto se mantiene de forma fija. Pues, se puede implementar el esqueleto del programa, y aceptar como parámetro de la función que se haga, una variable que contenga el código a ejecutar. La función que completaría nuestro código se puede hacer así:

$code = function ($dato1, $dato2) {
    echo $dato1 . "--" $dato2 . "\n";
};
 
algoritmo($code);
 
function algoritmo( $func ) {
    for ($i=0; $i<100; $i++) {
        $func($i, $i*$i);
    }
}

También se pueden emplear funciones como array_walk, preg_replace_callback, uasort, etc.

Esto permite realizar códigos como los que se realizan en Ruby o en los lenguajes funcionales y declarativos.

Recolector de Basura de Referencias Circulares opcional

Se deja al programador la decisión de si quiere activar el recolector de referencias circulares del garbage collector, o no. Por defecto viene activado y actúa de la siguiente forma, con este código:

class A {
    function __construct () {
        $this->b = new B($this);
    }
}
 
class B {
    function __construct ($parent = NULL) {
        $this->parent = $parent;
    }
}
 
for ($i = 0 ; $i < 1000000 ; $i++) {
    $a = new A();
    unset($a);
}
 
echo number_format(memory_get_usage());

Si se ejecuta desde consola, con una versión de PHP anterior a la 5.3, se verá en pantalla un error fatal, de que el límite de memoria se ha superado.

Esto es debido a que la liberación de memoria, cuando se va a proceder a liberar la clase B, ve que tiene una referencia a A, que ya va a ser liberada y crea un ciclo, con lo que, para evitarlo, no libera B. En las versiones de PHP 5.3 en adelante, se detecta este ciclo como tal y se liberan ambas.

También existe la posibilidad de desactivar este comportamiento o ver si está activo, con las funciones gc_enable, gc_enabled y gc_disable.

Nowdoc y Heredoc

Hasta ahora, los bloques de tipo heredoc eran los únicos que permitían escribir de forma libre un texto para después usarlo como variable. Ahora también disponemos de los nowdoc, que son iguales, salvo que no se hace parseo de variables. Un ejemplo:

$hola = "Hi, ";
 
$hd = < <<END
texto $hola
END;
 
$nd = <<<'END'
texto $hola
END;
 
echo $hd; // output: texto Hi,
echo $nd; // output: texto $hola

Constantes

Ahora, la palabra clave const puede ser empleada fuera del alcance de una clase, con lo que, en lugar de usar define se puede emplear esta forma:

// antes
// define("CONSTANTE", "Hola mundo!");
 
// ahora
const CONSTANTE = "Hola mundo!";

Operador Ternario simplificado

El operador ternario (expr1)?(expr2):(expr3) ahora permite dejar vacío el espacio correspondiente a (expr2) de modo que si (expr1) es verdadero, se retorna (expr1) y si es falso, se retorna (expr3).

Nuevos Módulos

PHPar

Al igual que JAR, PHPar sirve para empaquetar los PHP en un solo fichero, con lo que se mejora el despliegue de las aplicaciones, la organización del código, etc.

Intl

Mejores funciones de internacionalización para PHP. Hasta ahora, en PHP el único soporte de internacionalización que había disponible era gettext, ahora, con el uso de Intl y sus clases, se facilita internacionalizar una aplicación web, ya que tiene soporte para numeración, fecha, etc.

FileInfo

Da información sobre ficheros, usando la cabecera magic del propio fichero, intenta localizar de forma heurística su tipo, pudiendo retornarlo en formato MIME.

Etiquetas de Salto

Bueno, como en todo, hay avances y retrocesos, esto de proporcionar a PHP un elemento de código spaguetti como es el goto, no hace sino potenciar los malos usos, por lo que yo descartaría su uso.

Migración

Como cualquier liberación de lenguaje, PHP viene con mejoras, agregados y, además, cambios que implican que códigos anteriores puedan dejar de funciona, con lo que es aconsejable leerse bien la guía de migración, para ver los cambios que se introducen, lo que llega a ser deprecated, etc.

Conclusiones

Con esta liberación, PHP da varios matices que le hacen acercarse más a lenguajes como C++ y Java, agregando cosas como PHPar y los namespaces, así como mejorando su implementación de POO.

Considero que el cambiar a esta versión y desarrollar con las nuevas implementaciones hará que los códigos desarrollados sean más claros y, sobre todo, más organizados, por lo que es una buena baza para realizar el cambio.

Además, viendo la guía de migración, se deja entrever que los cambios de la versión anterior, 5.2.x, a esta nueva rama, son mínimos, con lo que, si se ha desarrollado código acorde a la versión anterior, realizar los cambios para adecuarse a esta versión, no es nada complicado.