Category Archives: programación

Noticias acerca de Programación. Son temas generales que pueden tener en cuenta a varios lenguajes, ser sobre metodología, algoritmia y/o librerías multiplataforma y portadas a muchos lenguajes.

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.

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.

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.

Shoes: programación fácil de GUI en Ruby

Cuando se realizan scripts para ciertas tareas para automatizarlas, pero que tienen que tomar datos del usuario, así como los datos que se presentan son útiles, tanto para rápida consulta, como para dar dicha información por teléfono o usarla en el código, otra interfaz, etc. surge el problema de que la consola se hace un paso como a otro mundo y resulta incómodo.

Una forma de ahorrar la pulsación de teclas, diseñando una interfaz que nos sea útil y presente la información, así como la toma de datos, de forma organizada y práctica, son las aplicaciones basadas en GUI, que se han comenzado a introducir en lo lenguajes de scripting… solo que, el uso de los mismos, se hace tan tedioso, que resulta incómodo realizar una interfaz para usuario en esos sistemas.

Hace poco, en un curso de Ruby on Rails que estaba dando Dani, un colega muy versado en Ruby y su mundo, nos enseñó un juguetito bastante gracioso para hacer GUI desde Ruby: Shoes.

Lo instalé para GNU/Linux y lo comencé a probar… en cuestión de una hora tenía una pequeña aplicación que tomaba información de un ActiveRecord, hacía una consulta según los datos de entrada que le introducía y rellenaba el resto del formulario con los datos de salida… muy útil en esos momentos para la resolución de incidencias, ya que suelen venir con datos incompletos y la resolución debe de ser rápida (y ya estaba cansado de ir a golpe de consulta SQL… mucho que teclear para obtener solo un par de datos :-P )

En la misma página hay un tutorial y, bajando el código, se pueden ver ejemplos donde hay desde programitas simples de reloj, hasta videojuegos en 3D :-) … lo recomiendo, a mi me ha ayudado mucho.

JavaScript y CSS no intruso en HTML

Cuando se pensaba en MVC, la capacidad para dividir las tareas obvias de tratamiento de datos, en lógica de negocio (el modelo), control de flujo de ejecución (el controlador) y la presentación de datos (la vista), aún quedaban en el aire muchos problemas en lo que respecta a las interaces, propiamente dichas, entre estas tres capas.

Centrándonos en la vista, existen miles de soluciones, para alejar al diseñador del código y al programador del diseño, pero aún así, cuando se habla de AJAX y desarrollos específicos… el programador tiene que tocar diseño y el diseñador preocuparse de lo que hará el código de servidor.

Este dolor de cabeza puede paliarse mediante el uso de códigos no intrusivos, lo que facilita la especificación de una interfaz basada en identificadores para el tratamiento del HTML.

El código no intrusivo de servidor lo trataré en otro artículo para que no resulte este muy extenso.

CSS no intrusivo

En principio, desde el punto de vista del navegador, todo es HTML. Pero, al igual que en los procesadores de texto, para facilitar la estructura de estos ficheros y no plagarlos de contenido referente a tipos de letra, colores, fondos… se crearon las hojas de estilos.

Las hojas de estilos en cascada (CSS) ayudan, junto con la especificación de identidades y clases, a dar estilos (colores, fuentes y forma de presentación en general) a las etiquetas escritas en HTML.

El CSS se pude incrustar en las etiquetas HTML mediante el uso de las etiquetas style, o incluso a través de los atributos style dentro de cada una de las etiquetas típicas de HMTL.

La mejor forma de hacer que no sea intrusivo, es colocar esos estilos en un fichero separado, y agregarlo mediante el uso de la etiqueta link en la sección head.

JavaScript no intrusivo

El código JavaScript es algo que se ha ido haciendo cada vez más con el HTML. En principio, se usaba la etiqueta script dentro de la sección head para agruptar todas las funciones de javascript, a las que se iban llamando desde etiquetas como onclick, onmouseover, onchange…, es decir, las etiquetas de eventos de HTML, que se destinan para JavaScript.

Después su uso se fue masificando y mezclando cada vez más con el HTML, haciendo que la etiqueta script, en muchas páginas, se encuentre repetida y segregada a lo largo de todo el texto HTML y, además de eso, en atributos como href, donde se indica explíticitamente que se ejecutará un código javascript.

Esto hizo que el código javascript se convirtiese en parte simbiótica de HTML y, en muchos desarrollos, que no se pudiese separar fácilmente.

Con ciertas técnicas, como las usadas en CSS, la separación de JavaScript se puede llevar a cabo sin problemas, pero requiere de ciertas pautas y costumbres a la hora de realizar el HTML:

  • Asignar ID a las etiquetas con las que se vaya a trabajar dinámicamente.
  • Asignar una clase a todo tipo de etiquetas que se usen para un fin similar.
  • Intentar no realizar anidamientos muy profundos.
  • En caso de tenerlos, intentar diferenciar los niveles de profundidad con IDs claros.
  • No abusar de tablas.
  • Tener especial cuidado con las etiquetas div, sobre todo por su uso con varios navegadores.

Con esto, solo tener claro que, el fichero de tipo javascript que se asocie al HTML, debe tener un código lanzador, que se encargue de asociar las funciones javascript oportunas a los eventos y las modificaciones pertinentes.

Es importante también recordar que, para mejorar la depuración, es mejor generar cuanto menos código por javascript, mejor. Es decir, que si hay que modificar las propiedades de una tabla por dar la posibilidad de varios tipos de ordenación, hacer las funciones específicas para ese cambio en JavaScript, pero no caer en la tentación de pasar los datos a array de javascript para hacerlo todo desde ahí.

Conclusiones

Lo que se trata, en base, es llegar a lo que W3C considera que debería ser la web semántica, pero con el uso de HTML. Intentar organizar los datos con las etiquetas existentes, sin usar estilos de presentación, solo los datos, y agregar a esas etiquetas el estilo de presentación deseado, mediante CSS externo y el dinamismo de cliente que se requiera, mediante JS externo.

Las ventajas que agrega, es que el cambio de una presentación a otra, se puede hacer con tan solo variar el CSS, y agregar nuevas funcionalidades, es solo modificar el JS.

Lenguajes: nuevas versiones

En estos últimos días he visto los nuevos lanzamientos, o lo que se espera lanzar en varios “mundos” del desarrollo del software. Por un lado, hay varios puntos donde la interfaz pasado-futuro corre bastante peligro.

Los desarrolladores de ciertos lenguajes han creído conveniente romper con el pasado de uso de dichos lenguajes para acogerse a los progresos y prácticas más usadas actualmente. Haremos repaso.

Perl 6

El lanzamiento de esta versión de Perl ha traído de cabeza a varios programadores, en algunos sitios ya existen guías de migración de Perl 5 a Perl 6 a modo de poder ayudar a los programadores a pasar a esta nueva versión y aprovechar sus nuevas características. Entre ellas, cabe destacar:

  • Tipificación
  • Parámetros en subrutinas
  • Orientación a Objetos
  • Comparaciones encadenadas
  • Evaluación perezosa
  • Macros

Larry Wall mencionó que la versión 5 era su reescritura de Perl, su visión de cómo debía de ser y que, la versión 6, debía de ser la reescritura de Perl para lo que quiera que sea la comunidad.

PHP 6

La versión de PHP 5, trajo consigo una orientación a objetos muy mejorada. Pero aún hoy, con la versión 5.2 estable y la 5.3 en inestable, se echa en falta una versión más completa del lenguaje, características avanzadas como las que se encuentran en otros lenguajes como Ruby, Java, Python o C++.

Por ello, la versión de PHP 6, nos aportará mejoras considerables como:

  • Closures y lambda
  • Traits
  • Namespaces
  • Más mejoras en la orientación a objetos

Por otro lado, hay que mencionar que esta versión ya no asegura la compatibilidad hacia atrás, es decir, con scripts programados para versiones de PHP 3.x, 4.x o incluso algunas del 5.x.

Python 2.6 y 3.0

El último lanzamiento de la versión 2.x se hizo con la versión 2.6, la cual incluye características y corrección de fallos, además herramientas para migrar a la versión 3, e incluso comenzar a usar elementos específicos de la versión 3 incluídos en la 2.6, a través del comando future.

La versión 3.0 de Python rompe también la interfaz pasado-futuro al no ser compatible con la rama anterior a nivel de scripts. No obstante, se han incluido herramientas para facilitar su transición.

Las mejoras incluidas:

  • Print es una función
  • Views e Iterators en lugar de Lists
  • Nueva sintaxis de anotaciones, argumentos y literales
  • Cambios en las librerías estándares (reorganización)

Conviene realizar una migración y estudiar un poco los cambios, si se desea realizar el salto a esta nueva versión.

Ruby 1.9.1

El comentario más sonado sobre esta versión es: el más rápido que la 1.8; y es que, parece que, aún no habiendo cambiado mucho la forma del lenguaje, sí han cambiado los procedimientos internos para hacerlos más óptimos.

Lea las características para más información.

Conclusiones

Aprender un lenguaje no es una seguridad en cuanto a dejar de aprender se refiere. Dentro de cada uno de los lenguajes de programación existentes, se han observado cambios patentes que se realizan con una periodicidad de pocos años, con lo que es bueno mantenerse al tanto de las nuevas versiones, otros lenguajes y, sobre todo, las necesidades y entornos, sus progresos y cómo se adaptan los lenguajes a ellos, puesto que determinarán si estamos eligiendo adecuadamente nuestra herramienta de trabajo o no.

Lenguajes de Programación

Revisando los tipos de lenguajes de programación existentes, llego a esta clasificación de los mismos:

  • Lenguajes imperativos
    • Lenguajes Spaguetti
    • Lenguajes Estructurados
    • Lenguajes Modulares
    • Lenguajes Orientados a Objetos
  • Lenguajes lógicos
    • Lenguajes declarativos
    • Lenguajes funcionales

Todos estos lenguajes de programación obedecen a una necesidad y/o ideología subyacente, que motivó el desarrollo del lenguaje con la metodología y sintaxis específica. A continuación describiré algo más en detalle cada uno de los anteriores.

Lenguajes Spaguetti

Fueron los primeros lenguajes de programación. El lenguaje máquina y posterior ensamblador, se basaba en la programación de instrucciones, una a una y comandos de salto ante ciertos estados del procesador. Con ello se conseguía un código entrelazado en saltos de línea a línea y parte a parte, consiguiendo un spaguetti bien entrelazado en proyectos grandes.

Lenguajes como Basic, posteriormente, siguieron esta forma de programación.

Lenguajes Estructurados

Los lenguajes estructurados que surgieron después (Fortran, C, Pascal, …) se basan en la estructuración del código en forma de procedimientos, funciones o subrutinas. Cada programa está formado por un conjunto de estas estructuras que son llamadas entre sí, tienen un nombre diferenciado y una funcionalidad bien conocida que se basa en los parámetros de entrada, pudiendo retornar valores en su retorno.

Lenguajes Modulares

Es un nivel más en los lenguajes estructurados. Se basa en la agrupación de los procedimientos, funciones y/o subrutinas en bloques, paquetes o módulos, de modo que queden bien organizados. Lenguajes como Java, Perl, Ruby o Modula-2, hacen uso de esta metodología.

Lenguajes Orientados a Objetos

El enfoque de este paradigma se basa en darle más importancia a los datos que a las acciones en sí. Es decir, en los modelos anteriores, la separación se hacía por unidades funcionales (verbos). La programación orientada a objetos se realiza mediante la organización del código mediante el conjunto de datos con sus funciones afines (objetos = datos + funciones).

Lenguajes que hacen uso de esta metodología son: Smalltalk, Ruby, C++, Java y Python, entre otros.

Lenguajes Declarativos

Los lenguajes declarativos se basan en una especificación lógica de lo que la máquina debe de hacer. Pero sin entrar en detalle en el cómo debe de hacerlo. Es un lenguaje más cercano al lenguaje natural que al lenguaje máquina, que se basa en la entrada de predicados para, a través de inferencia, llegar a un resultado.

Lenguajes que se basan en este paradigma son Lisp, Scheme, Clips y Prolog, entre otros.

Lenguajes Funcionales

Los lenguajes funcionales son como los declarativos, pero en lugar de predicados, trabajan con funciones matemáticas, es decir, carecen de máquina de inferencia y la definición de programas se basa en la especificación matemática del programa que se quiere conseguir.

Lenguajes que se basan en este paradigma son Haskell y Erlang, principalmente.

Otros paradigmas compartidos

Las necesidades de los desarrolladores cambia según el sector en que se trabaje, la época, la empresa… cualquier factor puede influir para tomar como determinación el uso de una tecnología y/o metodología específica y, dentro de la elección tomada, puede permutarse incluso hasta llegara a alcanzar un nuevo paradigma.

Estos paradigmas, se incluyen dentro de lenguajes ya creados y solo requieren de un uso específico de un tipo de lenguajes para conseguir el propósito deseado.

Los paradigmas que obedecen a esta forma son:

  • Programación Orientada a Eventos
  • Programación Orientada a Aspectos
  • Programación Concurrente

Estos paradigmas pueden ser integrados en cualquiera (o la mayoría) de los lenguajes citados anteriormente. Dejo pendiente el comentar estos paradigmas de programación.

Lenguajes esotéricos

Otro viernes… las oficinas a medio gas y toca trabajar… me da por buscar información, ahora que aprendo más sobre Ruby y Erlang y, topo con un lenguaje llamado COW. Un lenguaje esotérico.

Ves cosas como la serie de fibonacci:

MoO
moO
MoO
mOo
[[ main loop ]]
MOO
[[ print first number ]]
OOM
[[ temp copy of first number ]]
MMM
moO
moO
MMM
mOo
mOo
[[ store second number off in the first position now ]]
moO
MMM
mOo
MMM
[[ move back to temp number ]]
moO
moO
[[ use temp to add to first and store in second in loop ]]
MOO
MOo
mOo
MoO
moO
moo
mOo
mOo
moo

Supongo que el autor de este lenguaje llegaría hasta el punto de decir si hasta las vacas pueden programar… y mira por donde, ahora sí :-D Ahora tenemos un sistema de accesibilidad para que las vacas, con sus gemidos, puedan trabajar por nosotros :-P

Pero realmente, este es uno de los desafíos que se ponen algunos programadores, diseñar un lenguaje Turing completo que desafíen el ingenio, la creatividad y sentido del humor de todos los programadores en general.

Aquí dejo un enlace a más lenguajes de programación esotéricos.

Ruby… esa pequeña joya

El lenguaje de programación Ruby, creado por Yukihiro Matsumoto (a.k.a. Matz), fue ideado para ser un lenguaje que simplificara las actividades diarias y necesidades de programación de su creador, al igual que Perl (la otra joya) fuera creada por Larry Wall para cubrir sus necesidades como administrador de sistemas, Matz necesitaba un lenguaje que fuese igual o más potente que Perl, y con igual o mejor implementación de orientación a objetos que Python.

En su trabajo, Matz, usaba Perl, mientras desarrollaba Ruby en paralelo, hasta que fue lo suficientemente bueno como para reemplazarlo. El nombre de Ruby, por tanto, está motivado por la similitud, en simbología, con Perl. La primera liberación fue en 1995.

En Japón, Ruby ha llegado a tener más popularidad que Python. Los adeptos de Ruby, así como su creador sostienen que Ruby fue diseñado para ser más fácil, y además divertido.

Viendo muchas de sus librerías, y sus similitudes con las librerías de Perl, se entiende lo que se menciona acerca del paso de Perl a Ruby, al igual que la sintaxis, en lo que se refiere a expresiones regulares, la declaración y uso de datos de tipo array y hash. No obstante, Ruby tiene una característica básica, y es que, todos sus datos son objetos, es decir, lo que en Perl serían datos scalar, aquí son todos objetos.

Podría seguir con más parecidos, trozos de código y explicando cómo se programa en este lenguaje que cada vez me atrae más… pero casi prefiero que lo leáis en sus sitios habituales de referencia:

http://www.ruby-doc.org/

Espero que lo disfrutéis.

Gráfico Burndown (más de Scrum)

En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en otro artículo, volvemos a la carga.

Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.

Para esto, hemos hecho uso de un gráfico burndown.

Burndown

El gráfico de burndown se caracteriza por tener en su eje X el tiempo, solo los días laborables que se vayan a trabajar (sino el gráfico saldría algo extraño) y en el eje Y los puntos de tarea que se van a completar en el sprint.

Pila de Producto, Pila de Sprint y Puntos de Tarea

La pila de producto es la cantidad de características que nos piden que incorporemos a un producto software. Estas tareas son funcionales, generalmente.

La pila de sprint es una primera criba que se toma de la lista total de características, a modo de poder desarrollar una versión 0.1. Esto se realiza para que, al final del sprint, que no debe de ser un período de tiempo muy prolongado, se tenga algo palpable para el cliente (o dueño de producto) y pueda replantearse el resto de peticiones en función de lo que está viendo.

Los puntos de tarea son, en sí, la dificultad y el tiempo que se puede llegar a invertir en la tarea en sí. Es una unidad de medida relativa que no implica en sí tiempo, pero está bastante ligada a él.

Por ejemplo, si hacer un alta de cliente implica una sola consulta a base de datos y retornar el valor de resultado, esa tarea podemos estimar que tiene 1 punto. El caso de la modificación, implicaría tomar los datos, mostrarlos, tomar los cambios y hacerlos efectivos. Esa tarea se puede estimar en 2 ó 3 puntos. Ahora, hacer el balance de todos los clientes dados de alta y los ingresos que tuvieron en el año pasado, todo ello paginado… puede ser una tarea con una puntuación de 10, relativamente con respecto a las anteriores.

Datos en el gráfico de Burndown

El gráfico se traza para cada sprint. Se estima el tiempo que se puede o quiere tardar en realizar una serie de características. Al comenzar, el primer sprint, no se sabe la velocidad del grupo, realmente, por lo que se puede comenzar sin estimación precisa. Esto se va ajustando con el tiempo.

En principio, se comienza el trabajo, se comienzan a realizar tareas.

Al día siguiente, se hace revisión de las tareas acabadas y se apunta en el gráfico el día anterior y los puntos que se avanzó. El gráfico, al crearlo, se suele trazar una línea que cubre la diagonal de la esquina superior izquierda hasta la esquina inferior derecha. Si los puntos van cayendo sobre la línea, ya sabemos lo que se va a ir tardando en realizar el proyecto.

En caso de que los puntos vayan cayendo en el rectángulo superior, eso será indicio de que hay que eliminar historias. Si se mantiene siempre en el bloque inferior, se pueden agregar más historias.

Conclusiones

Después de un par de jornadas, se puede ver la velocidad del equipo y se tiene una percepción real de lo que se hace, lo que se tarda y las tareas que hay que ir acelerando o postergando para llegar a la fecha, sin necesidad de estar cerca de la fecha de entrega. Es, sin duda, uno de los mejores métodos de estimación de tiempos a corto plazo… para el sprint.

Hablaré en los próximos artículos sobre las estimaciones a largo plazo, gestión de hitos y más sobre la pila de producto.