Criticando su estilo

Es curioso que gente como Damien Katz (creador de CouchDB), o Toni Arcieri (creador de Reia) hayan sido de los primeros (o al menos los que he encontrado) que hayan arrojado una piedra en contra del lenguaje que eligieron para desarrollar elementos que han sido bastante respetados, apoyados y usados.

En este aspecto, otros como Yariv Sadan, han defendido y reconocido algunos de estos comentarios y, tras leer a unos y a otros, me queda la pregunta de, ¿realmente han entendido para qué sirve Erlang?, ¿qué hace y cuales son sus potencias?, ¿cómo sacarle el máximo provecho así como programar orientados a la concurrencia?

Crítica a la sintaxis

Lo primero que critican de Erlang es su sintaxis. Recuerdo la primera vez que vi el lenguaje C, después de haber programado en Basic, Pascal y Modula-2 que dije… ¡qué raro! y ya ni digamos de cuando unos años más tarde comencé a ver Perl…

La sintaxis C-like, como dicen muchos, es muy extendida, pero no es nada comprensible para una persona que comienza desde cero. Niklaus Wirth desarrollo por esto mismo lenguajes como Pascal, para que sirviesen de aprendizaje al modo pseudocódigo. Un código que nada más leerlo, se entienda.

Erlang, en cambio, sigue una metodología más como Prolog, está orientado al desarrollo de funciones matemáticas, por ello, la función tiene una conclusión (->) para su comienzo y termina con un punto final. Cada elemento dentro de la función o expresión matemática se separa por comas, y todo es funcional, es decir, todo elemento en Erlang hace algo y DEBE retornar algo, incluso las estructuras condicionales, por eso tiene la forma que tiene.

Tipos de datos: registros y cadenas de caracteres

Los registros, son a nivel de preprocesador: tuplas. Esto quiere decir que funciones del tipo record_info no existen realmente, por lo que no se pueden emplear variables para pasarle a esa macro y queda el espectro del uso de los registros algo limitado. No obstante, hay algunos trucos que se pueden emplear y existen para paliar esto, en caso de que se requiera/necesite.

Otro de los problemas, con los tipos de datos, son las cadenas de caracteres, las cuales son listas de enteros. Esto no debe de extrañarnos, ya que en todos los lenguajes son listas (o arrays, o vectores) de bytes. En lenguaje C, por ejemplo:

char c[] = "Esto es una cadena";
char d[] = { 'E', 's', 't', 'o', 32, 'e', 's', 32, ..., 0 };
 
printf("%s\n", strcmp(c, d)==0 ? "true" : "false");

Esto nos dará verdadero, ya que ambas son listas de bytes, al igual que en Erlang podemos ver algo parecido con las listas de enteros:

[100,111,103] == "dog".

Lo cual también retornará verdadero.

Rendimiento: Churras con Merinas

Realmente, al leer el artículo de Toni, cuando llego al punto que dice: Erlang sucks at managing memory; habla de una comparación entre Erlang y Azul Vega, un procesador de 54 cores optimizado para ejecutar la JVM.

Un programa con ese procesador y esa JVM, NO se ejecutaría de forma distribuida, realmente, ya que solo se distribuyen las tareas posibles e internas de la JVM entre los cores, en tanto y en cuanto se puedan distribuir estas tareas. No obstante, no está diseñado para conectarse con otros nodos, por lo que NO es escalable. Además, solo tiene cuatro canales para acceso a memoria, por lo que, 27 máquinas de Pentium IV con HyperThreading podrían hacer ese mismo trabajo con Erlang… y aún así aún podríamos poner más hierro a bajo coste para seguir escalando y mejorando el rendimiento del software desarrollado.

¿Es un lenguaje de propósito general?

Erlang fue creado para entornos en los que hubiese que desarrollar software con alto grado de concurrencia, esto lo hace ideal para entornos servidores de cualquier tipo, y actualmente, para los escritorios modernos, donde los programas se ejecutan de forma concurrente, claro.

¿Elrang puede desarrollar web? Sí, ejemplos como ChicagoBoss, o Erlyweb, o Nitrogen lo atestiguan. ¿Erlang puede desarrollar aplicaciones de escritorio? Sí, ejemplos como Wings3D dan crédito de ello. ¿Erlang sirve para desarrollar aplicaciones de servidor? ¡Claro!, para eso fue creado.

En mi opinión, si PHP tiene esa denominación y es un lenguaje de marcas, Erlang DEBE de tenerla

Asignación única… ¿por qué?

Para trazar mejor los códigos, claro, y porque bien pensado, un lenguaje funcional no requiere del uso de tantas variables, por ejemplo, tal y como decía Damien Katz en su artículo, tienes este código:

f(X) ->
  X1 = foo(X),
  X2 = bar(X1),
  baz(X2).

Este código, bien escrito, sería:

f(X) ->
  baz(bar(foo(X))).

¿Quieres agregar logs para que se vean en el cambio de funciones y no los quieres poner dentro de las propias funciones, sino entre las llamadas… pues puedes hacerlo con otras funciones:

log(Caller, X) -> io:format("~s: ~p~n", [Caller, X]), X.
f(X) ->
  log("BAZ: ", baz(log("BAR: ", bar(log("FOO: ", foo(X)))))).

Realmente no es complejo si se escribe y ordena el código de forma adecuada… en otros lenguajes, como por ejemplo C, se pueden escribir cosas como esta:

char *s = "Parsea la cadena";
int size;
for (int i=0, size; s[i]!='\0' && i<100; i++, size++)
  ;

Otros códigos en Perl dan incluso hasta más miedo… pero es como siempre se dice… depende del programador.

El desarrollo en sí

Lo que creo que no se entiende, es que el desarrollo en Erlang, como tal, no es ni escalable, ni redundante, ni aprovecha todos los núcleos y procesadores de las máquinas, así como el resto de núcleos que estén conectados. El hecho de que se pueda aprovechar la forma en la que Erlang fue diseñado, es desarrollar el software de forma concurrente. Con los patrones adecuados.

Por ejemplo, Erlang puede, en un solo nodo, ejecutar casi 2 millones de procesos concurrentes. Esto quiere decir que, cada tarea que haya que realizar, debería de correr en su propio proceso, y este proceso es el que se lanza en el núcleo, procesador y nodo que corresponda. Como cuando se desarrollaba en PVM o MPICH.

Emplear los patrones de OTP es esencial para sacar el máximo provecho de la arquitectura de Erlang, y el crear manejadores de eventos, máquinas de estos, memorias compartidas a través de servidores, etc. debe de realizarse, necesariamente a través de los mecanismos que aporta Erlang.

Si se emplease Erlang para hacer llamadas a Mnesia, desde cualquier parte del código con las llamadas dirty y generando un nuevo proceso por cada petición aislada, tendríamos un programa que puede tiene potenciales errores de concurrencia, y que no aprovecha los nodos que tenga configurados y conectados el sistema.

Conclusión

Me parece muy poco profesional escribir este tipo de artículos, tanto para Tony como para Damien, en los que ponen una serie de circunstancias poco contrastadas y debidas al bajo conocimiento del lenguaje y, precisamente ellos, que han desarrollado grandes herramientas en este lenguaje.

Java, igualmente, es un gran lenguaje, pero como el mismo Tony comenta, requiere de que la JVM cumpla la especificación RTSJ y, en las comparaciones, por ejemplo, hablan incluso de que habría que adquirir un hardware especial para poder desarrollar algo parecido a lo que Erlang hace en cualquier arquitectura, creo que son muy poco objetivos.

Estas búsquedas, igualmente, dieron con una serie de lenguajes nuevos, que han sido desarrollados usando estos analizadores, sobre Erlang, por lo que aprovechan sus ventajas, y salvan algunos de los inconvenientes que tienen algunas personas al ver Erlang por primera vez, con respecto a la sintaxis del lenguaje y la asignación única de variables.

Reia

Con el primer lenguaje que me topé fue Reia, del cual hablé ya en otra ocasión. Este lenguaje fue desarrollado por una persona a la que le gusta mucho la sintaxis particular de Python y Ruby, pero también es muy aficionado a Erlang. Las primeras versiones de Reia tenían un formato muy parecido a Python con tintes de Ruby, y fue modificándose poco a poco, haciendo que cada vez más, se pareciese a Ruby.

La última noticia que he tenido sobre Reia, es que su desarrollador ha decidido abandonar su desarrollo, debido a que encontró otro lenguaje muy parecido, hecho de la misma forma, y que considera que se desarrolló de una forma mucho más elegante. Este lenguaje es Elixir. Por lo que, junto con el autor del lenguaje, Jose Valim, Tony (creador de Reia), se sumará a la lista de desarrolladores de Elixir.

Un ejemplo del lenguaje (aunque se puede ver en el artículo anterior):

# Hello, world!
"Hello, world!".puts()

LFE

Un lenguaje que también me ha llamado la atención, aunque al igual que Erlang, su sintaxis es algo rara para programadores del tipo Java, PHP, Ruby, Python y similares, es LFE (Lisp Flavoured Erlang, algo como Erlang con sabor a Lisp). Este lenguaje, desarrollado por Robert Virding, es una sintaxis de Lisp sobre Erlang.

Se encarga de traducir la sintaxis exacta de lo que se escribe a código Erlang. Un ejemplo de lo que se escribiría en LFE:

(defmodule myhello
  (export (start 0)))
 
(defun start ()
  (: io format '"Hello World!~n"))

Se traduciría así en código Erlang:

-module(myhello).
-export([start/0]).
 
start() ->
  io:format("Hello Wordl!~n", []).

El sistema no tiene una forma fácil de compilar, pero el sistema está bien desarrollado y para los amantes de la sintaxis Lisp o Scheme es una gran oportunidad de poder desarrollar en ese entorno.

La ventaja de LFE, es que mantiene completamente la ideología en sí de Erlang y solo cambia la sintaxis, por lo que la metodología de OTP es completamente válida y se puede emplear al 100% como si de Erlang en sí se tratara.

Elixir

Lo descubrí a través de Reia. Este lenguaje, al igual que Reia, se basa en Ruby, sin tintes de Python. Ofrece una orientación a objetos más fuerte que Ruby y que Reia, ya que ni tan siquiera admite funciones de tipo built-in como puts, todos los métodos deben de pertenecer a un objeto.

La motivación e influencias en la creación de Elixir fueron, precisamente, Reia y LFE, según afirma el propio Jose Vallim en su respuesta a la noticia de Tony de parar el desarrollo de Reia.

Este lenguaje, permite además, hacer scripting, por lo que da una mayor versatilidad. El lenguaje es muy parecido (tiene algunas variaciones) que Ruby y tiene acceso a módulos Erlang de forma sencilla.

Un ejemplo del código:

module Hello
  def world
    IO.puts "Hello World"
  end
end

Elixir respeta un poco, o intenta llevar a su sintaxis, el paradigma de OTP de una forma más o menos asequible. En el ejemplo gen_server_bookshelf, se muestra cómo crear un gen_server y las diferencias que agrega al paradigma de OTP, debido a la propia ideología del lenguaje. El uso del pattern matching en los argumentos de las llamadas hace que se vea muy parecido a Erlang por lo que es un buen ejemplo de cambio de sintaxis manteniendo la potencia de Erlang por debajo.

Efene

Desarrollado por Marion Guerra y basado en la sintaxis de JavaScript y Python, Efene es otro de los lenguajes que se ejecuta sobre la máquina virtual de Erlang.

Un ejemplo de este lenguaje:

# classic hello world
 
hello = fn (Who) {
    io.format("hello ~s!~n", [Who])
}
 
@public
run = fn () {
    hello("world")
}

La sintaxis del lenguaje, para los que prefieran el formato de tipo JavaScript, será más cómoda, y el uso de los módulos se abstrae, permitiendo usar los que ya trae consigo Erlang (ejemplo el io.format, que es una traducción para el io:format de Erlang).

El defecto viene quizás en el hecho de que efene no tiene soporte de procesos, por lo que el lanzamiento de los mismos, junto con la posibilidad de usar el paradigma de OTP encubierto en el propio lenguaje, se anula completamente.

Conclusiones

Muchos de los lenguajes tienen la potencia de aportar una nueva sintaxis, que era el gran problema que le veían muchos programadores a Erlang, sobre una potente infraestructura. No obstante, el paradigma de programación que introduce Erlang a través de OTP queda un poco tapado o incluso anulado en algunos de estos lenguajes, afortunadamente, de los vistos, solo efene.

En sí, quien programa en Erlang, y termina usando y viendo el paradigma del lenguaje en sí, la programación funcional, OTP y su sintaxis, es normal que no quiera abstraerse a otro tipo de sintaxis. No obstante, admito que a veces, tener otra sintaxis más amigable se agradece, no solo por ver mejor el lenguaje, sino también para introducir a más gente en él.

En este sentido, el libro persigue que los programadores tengan en cuenta tres objetivos para la escritura de su código: robustez, eficiencia y fácil mantenimiento.

En general, da un repaso a todos los aspectos de Perl, el uso de las variables y nomenclaturas, definición de procedimientos (o subrutinas) uso de paquetes específicos como strict, documentar apropiadamente el código, etc.

Un libro muy recomendable para todos aquellos que quieran progresar en su conocimiento de este lenguaje haciendo buen código.

Ejemplo de procrastinación: El Pintor

Pongamos como ejemplo que haya pintores que cobren por horas en lugar de por metros pintados o por trabajo completo a realizar. Si un pintor tiene que pintar una pared de 20 metros cuadrados, para la cual sabe que puede tardar unas 2 horas, puede que trabaje una hora, pare para tomar algo, prepare de forma calmada y lenta su equipo, y trabaje después la segunda hora, habiendo echado, finalmente unas 4 ó 5 horas… quizás incluso las 8 horas que son el día laboral normal de cualquier persona.

El pintor cobrará entonces por 8 horas, en lugar de 2 horas que ha sido su trabajo real. Es más, si el trabajo fuese de 200 metros cuadrados, sabiendo que son 20 horas, quizás en ese momento, por procrastinación, los primeros días no hace gran cosa, y cuando va viendo que quien lo contrató comienza a estar con la mosca detrás de la oreja, entonces trabaja bien las últimas 10 horas que le queden, habiendo hecho un trabajo de tres días (todos tenemos derecho a nuestros descansos) en cinco días.

Por ello, estos profesionales, por costumbre (que no de mala fe), acostumbrarán a posponer el trabajo en el tiempo (procrastinar) para llegar al punto de parecer, durante un tiempo al menos, malos profesionales, acelerando en el último punto, para que se vea que saben trabajar, y acabando el trabajo justo a tiempo para que no se les eche del trabajo.

En el mundo del software…

Hay muchas veces que, la estimación de un proyecto de software se hace por tiempo. En función del tiempo tardado, se paga a los programadores, y se estima el precio del proyecto. No obstante, esto tiene bastante puntos negativos para los desarrolladores, e incluso para los clientes:

1. La competencia: competir por el desarrollo de software es decir que tardas menos (y por lo tanto cobras menos)… pero si el tiempo se recorta y no los requisitos, o pagas menos a los trabajadores (programadores) o les presionas para que hagan más en menos tiempo.
2. Procrastinación: si se firma un proyecto de un año, se fija el alcance los requisitos, y se comienza a trabajar. Pasará, y eso se quiera o no es así, que los primeros meses la curva de implicación y desarrollo es muy baja, mientras que el último mes es incluso insana, echando más de ocho horas diarias. La presión no se tiene hasta que la fecha está próxima a cumplirse, y como a los desarrolladores/programadores se les paga por el tiempo que están ahí desarrollando la solución, no les motiva el terminar antes.
3. Recursos Humanos: aún usando metodologías ágiles, si la presión es variante en el tiempo y la motivación de hay que entregar se sucede con bastante frecuencia, sin que haya un premio por ello, y sin embargo habiendo broncas o castigos en caso de no llegar, eso hace que la gente se desmotive, comience a trabajar cada vez peor y termine viendo más las páginas de trabajo que el desarrollo en sí.
4. Retorno de Inversión: equivocarse en una fecha tras otra, puede ser un punto de pérdida de dinero si se tiene que invertir horas de personas en algo que se supone que debería de estar acabado. Supone no saber exactamente el precio de un desarrollo hasta que no se ha terminado completamente.

¿Otro modelo es posible?

Pudiera ser posible, sí. Pensemos en el modelo del pintor, ¿cómo le pagaríamos?… supongo que lo más óptimo sería por pintura gastada y por metros pintados, así como por manos que dé. Es decir, materiales y mano de obra calculando el trabajo realizado, y no las horas invertidas. Esto hace que el trabajador sea el más interesado en ser óptimo en su trabajo, ya que, tanto si tarda una hora, como si tarda tres, cobrará lo mismo.

En el mundo del desarrollo de software, ¿es posible hacer esto?… muchos dirán inmediatamente que no… que es complejo, sino imposible, determinar cuánto tiempo se demora en desarrollar un cierto sistema. La pregunta es clara:

Si es posible determinar el tiempo que se va a tardar en un desarrollo, ¿por qué no se puede determinar el precio de ese mismo desarrollo?

Esto es lo que vienen haciendo desde hace mucho tiempo otras doctrinas, como la abogacía, los registradores, los notarios, los arquitectos… todos los que tienen colegios. En el primer caso, por ejemplo, el Colegio de Abogados de cada provincia establece un precio por trabajo específico a realizar. En nuestro caso, el desarrollo de software, por ejemplo, podríamos determinar conceptos como:

• Desarrollo de una página web: HTML + CSS + JavaScript; precio mínimo: XXX euros
• Desarrollo de una página dinámica web (lenguaje de etiquetas: JSP, ASP, PHP, …); precio mínimo: XXX euros
• Desarrollo de un sistema de gestión de usuarios; precio mínimo: XXX euros
• …

Si se desglosa el desarrollo que se pide, hasta el nivel de análisis (e incluso diseño) más básico, toda petición se pueden englosar en uno de estos conceptos, quedando algunos otros como “as” en la manga, como la creación de conceptos de investigación, o incluso de riesgo, por tratarse de algo que se sale de la línea base en la que desarrolla la empresa en concreto.

Estableciendo precios

Al igual que se debe de realizar un modelo de negocio cuando se levanta una empresa, se deberían de plantear los precios por concepto de lo que la empresa realiza. Está claro que hay conceptos que seguirán quedándose en horas, como la hora de atención al cliente, o la hora de soporte, o la hora de formación.

No obstante, se pueden determinar ciertos desarrollos en los que la empresa se desenvuelve sin problemas, si es web, por ejemplo todo lo que se suele desarrollar de web y cosas que no se han hecho pero se saben hacer, así como si fuese de sistemas, todos los posibles montajes que se pueden realizar en base a tipologías de servidores que se quisieran montar, sistemas de seguridad, de redes, etc.

Buscando motivación en lugar de procrastinación

Si se tiene una empresa en la que los desarrollos son para la propia empresa, tipos como se han puesto de moda SaaS (Software as a Service), es decir, vender software como servicio y no como producto, entonces se podría hacer una evaluación de los tipos de desarrollos que se acometen, fijar un esquema de conceptos internos, y pagar a los desarrolladores por trabajo realizado. Tal y como se paga a los equipos comerciales.

En este caso, las empresas pagarían el mínimo fijo a los trabajadores, y una comisión, por trabajo realizado ese mes. Si se han realizado muchas labores imputables por conceptos acordados, el trabajador percibirá la cuantía según su hoja de servicio. Sin embargo, si ha realizado poco trabajo o ninguno, solo percibirá el mínimo.

Competencia interna e intereses contrapuestos

Desgraciadamente, no todo es bueno en este modelo. El hecho de ganar más dinero si se hace más, hace que también se busque la forma de hacer menos y seguir ganando más (naturaleza humana), por lo que nos podemos encontrar que haya gente que intente atribuirse el trabajo de otros, o incluso soliciten ayuda del compañero para que le acabe el trabajo.

Esto hace que el trabajador se mueva siempre en beneficio propio, y no en el de la empresa, ya que gana dinero si hace, no si ayuda. Esto puede forzar a que el trabajador genere más trabajo del que requiera la empresa en cierto punto (necesidad de ganar más) o incluso que haga más hora para conseguir más beneficio.

Todo es controlable y todo se puede mejorar. Estos puntos son salvables, ya que se pueden incluir conceptos de soporte entre trabajadores. Si el jefe estima que un trabajador está ayudando a sus compañeros, puede darle un incentivo por compañerismo, que esté reflejado en la tabla de conceptos, con lo que se potencia el trabajo en equipo.

Así mismo, se puede incentivar el que se trabaje a unas horas concretas, asistencia a reuniones o incluso tener un contra-incentivo si se permanece en la oficina pasada una hora concreta, para controlar que un trabajador no llegue a un punto insano de saturación por obsesión de intentar conseguir cada vez más.

Conclusión

Considero que, al igual que el incentivo es una buena forma de educar a un niño, es una buena forma de mantener la motivación de una persona en el trabajo, haciendo que la propia persona, con su experiencia y su creatividad, en las horas que determine dedicar al trabajo, consiga el mayor partido, ganando lo que quiera ganar, y con limitaciones para que la obsesión o avaricia se pueda presentar.

Los partes horarios son un ente arcaico que vienen bien en casos de trabajos concretos, que no se pueden medir por un trabajo realizado, sino más bien por un servicio prestado o por una atención dada. Pero este no es el caso del desarrollo de software.

Un vistazo al lenguaje

En su página web, nada más acceder, se ve un cuadro con un código de algo más de 20 líneas completamente funcional y que resulta en… ¡un chat! Aquí el código:

type message = { author : string ; text : string }
 
@publish room = Network.cloud("room") : Network.network(message)
 
user_update(x : message) =
  line = <div class="line">
            <div class="user">{x.author}:</>
            <div class="message">{x.text}</>
         </>
  do Dom.transform([#conversation +<- line ])
  Dom.scroll_to_bottom(#conversation)
 
broadcast(author) =
   do Network.broadcast({~author text=Dom.get_value(#entry)}, room)
   Dom.clear_value(#entry)
 
start() =
   author = Random.string(8)
   <div id=#header><div id=#logo></></>
   <div id=#conversation onready={_ -> Network.add_callback(user_update, room)}></>
   <div id=#footer>
      <input id=#entry onnewline={_ -> broadcast(author)} />
      <div class="button" onclick={_ -> broadcast(author)}>Post</>
   </>
 
server = Server.one_page_bundle("Chat", [@static_resource_directory("resources")],
       ["resources/css.css"], start)

La sintaxis del lenguaje recuerda bastante a JavaScript, con tintes de programación funcional al estilo Prolog. Esto mezclado a que la sintaxis de XML en que se basa HTML puede incrustarse en el propio código, como si de instrucciones propias del lenguaje se tratasen, haciendo que la salida en este formato sea más limpia que en otros lenguajes de etiquetas como JSP, ASP o PHP.

Sin saber nada del lenguaje, choca ver el ejemplo, donde se instancian algunos objetos de red (en el ejemplo del chat) y se agregan líneas con una sintaxis de operadores que no se ven generalmente en otros lenguajes (como +<-).

Se define un tipo de datos que se mantiene por sesión de navegador, y la información entre el navegador y el servidor se va intercambiando entre código JavaScript y AJAX. Así mismo, se hace una comunicación broadcast, esto quiere decir que se envía el mensaje que le llega al sistema a todos los que tengan una sesión abierta de la aplicación.

Este tipo de facilidad hace que realizar un chat en la web, como se muestra en el ejemplo, sea muy sencillo, así como realizar juegos en red, en internet, e incluso aplicaciones de gestión que requieran de notificación de cuando se toca la ficha de un cliente o similar.

Las potencias del lenguaje

En los últimos tiempos he ido viendo que se hace más patente la necesidad de los programadores en desarrollar aplicaciones en un modelo de concurrencia óptimo y fácil. En este sentido, lenguajes como Erlang, Scala, Clojure, Haskell, y ahora Opa, se han hecho un hueco y compiten en un sector en el que el desarrollo se complica con el resto de lenguajes, y estos lo resuelven de una forma cómoda y elegante.

Opa no es un lenguaje de propósito general, sino que está orientado 100% a la web. En este entorno se desenvuelve con soltura y se pueden desarrollar entornos complejos de una forma compacta, clara y concisa.

Lo que en otros lenguajes llega a ser un dolor de cabeza, como es la notificación de eventos, compartir memoria entre varios procesos y mantener el flujo entre muchas sesiones diferentes hacia solo una aplicación, Opa lo resuelve con sus elementos base.

Consiguiendo popularidad

En su página web, en estos días, anuncian el Opa Developer Challange 2011, el cual es un concurso (o desafío) para desarrollar una aplicación en Opa, consiguiendo a cambio, en caso de ser ganador, un premio según el puesto en que se quede (MacBook Air, iPad 2 o Nintendo DS).

Estos concursos son un foco importante para desarrolladores ya que hay dos cosas bastante atrayentes. La primera, el premio en caso de resultar ganador o de las tres primeras posiciones. La segunda… la palabra “challange” (desafío), lo cual resulta muy atrayente a ciertos programadores (hackers), que se interesan por los desafíos y las nuevas tecnologías.

En todo caso, esto será sin duda un empujón para el lenguaje, con lo que, entre las aplicaciones que ya hay desarrolladas y las que genere el concurso, se generará un buen abanico para dar más y mejor nombre a este lenguaje.

La parte mala…

Una de las partes que Opa hace más hincapié, es que no tiene errores de XSS ni inyección de SQL, es decir, es seguro. El problema, es que no tiene errores de XSS porque no permite reflection, algo que se hace bastante útil a veces, ni el uso de una base de datos SQL.

El tema de tener que emplear el sistema NoSQL de base de datos que integra el sistema Opa, hace que muchos desarrollos sean impracticables en este sistema, ya que dependen de una base de datos que se requiere sea en un SGBD de un tipo específico.

Esto se suma a que no tiene tampoco, al menos aún, soporte de SOAP o XML-RPC, por lo que tampoco podría acceder a un Web Service externo para poder tomar esos datos. No obstante, sí tiene soporte REST como servidor y como cliente, por lo que, desarrollando un sistema externo en otro lenguaje con acceso tipo REST a base de datos, podría hacerse un puente al sistema gestor de base de datos. Aunque, claro, es más trabajo y dependencia de un sistema que esté programado y desarrollado en otro lenguaje.

El hecho de que el lenguaje genere un binario ejecutable, da la seguridad de que no se puede modificar ni inyectar código, ya que no es scripting, pero eso le quita también la versatilidad de poder actualizar el código sin necesidad de parar el sistema. Además de que el hecho de que se distribuya un binario (en caso de Windows, un .EXE) lo hace sensible a ser atacado por virus.

Conclusiones

Es un lenguaje interesante, y una arquitectura igualmente curiosa. Para los que somos además administradores de sistemas, esto no es muy atractivo, ya que cierra un poco las puertas ciñendo el crecimiento a montar un solo elemento en los servidores, encapsulado y poco configurable. No obstante, en aras de la sencillez y puesto el foco en el objetivo a conseguir, resulta bastante óptimo y atractivo.

En mi opinión, cuando solucionen el hecho de poder conectarse, aunque sea de forma ActiveRecord, ORM o SQL a una base de datos relacional, sin perder la base en la que se forjó la idea y el sistema de Opa, el sistema comenzará a ser mucho más usado en muchos más ámbitos.

¿Qué es y qué hace Xdebug?

Xdebug es un módulo de PHP que se carga únicamente cuando se quiere trazar una ejecución de un código PHP (por ello no conviene, en ningún caso, cargarlo en producción, ya que puede cargar de por sí el sistema).

El módulo se encarga de almacenar información de cada llamada a función de PHP, junto con la marca horaria en la que se sucede para tener la traza exacta del curso de la ejecución del programa.

¿Cómo y dónde se obtiene esta información?

Cada traza es soltada dentro de un fichero llamado cachegrind.out. finalizado con el número del proceso en el que se ejecuta el intérprete de PHP.

Este archivo puede ser abierto desde algún programa como KCacheGrind (de KDE para GNU/Linux y Windows), así como WinCacheGrind, xdebugtoolkit y WebGrind. Así se muestra con KCacheGrind:

Como puede verse, los procesos se muestran de forma jerárquica en las llamadas a través de un árbol de llamadas, pudiendo poner la base en cualquier función inicial.

Además, permite ver el listado de las llamadas que han sido más usadas, y las que más demoran su ejecución. Lo cual viene muy bien para poder optimizar, no solo las funciones en sí, sino también la forma en la que se llaman.

Conclusión

Es una gran herramienta que no debería de faltar en todo programador PHP, ya que nos da información muy valiosa sobre la optimización con la que escribimos nuestro código y nos puede señalar faltas en el rendimiento que solo se verían demasiado tarde, en producción.

Orientación a Objetos, no a Clases

Teniendo en cuenta de que Ruby es un lenguaje orientado a objetos (y no a clases), huelga decir que, no solo se puede redefinir una clase (es decir, el objeto plantilla del que se generan otros objetos), sino que también se puede redefinir un objeto instanciado sin que afecte al resto de objetos del mismo tipo.

Sobre la orientación a objetos de Ruby, vamos a hacer este simple ejercicio desde irb para que se pueda ver algo más claro:

class A
end
 
a = A.new
 
a.class   # A
A.class  # Class
Class.class # Class

Como se puede ver, el objeto a es de tipo A, el objeto (que no clase) A es de tipo Class, y el objeto (que tampoco clase) Class es recursivo en sí mismo, ya que Class es el tipo raíz del que parten todos los objetos… como en Java lo es Object.

Reescribiendo Clases

Una de las mayores potencias de Ruby, es que una clase definida, se puede redefinir, ya sea para cambiar un comportamiento específico, o para agregarle mayor funcionalidad. Esto de cara a la programación orientada a objetos, es una aberración, realmente, porque rompe la encapsulación… peeeero, de cara al pragmatismo, es muy útil poder modificar un comportamiento general para adaptarlo a uno específico sin necesidad de tener que reescribir de qué clase se hereda.

Haciendo una prueba:

class A
end
 
a = A.new
puts a    # #<A:0x000000000000>
 
class A
  def to_s
    "Clase A"
  end
end
 
puts a    # Clase A
 
b = A.new
 
class << b
  def to_s
    "objeto b"
  end
end
 
puts b    # objeto b
puts a    # Clase A

Con esto se puede comprobar, que la redefinición de métodos se puede conseguir, tanto para objetos como para clases.

Y ahora… el yield

Otra de las potencias de Ruby es que, podemos definir un código, dejando una definición a medias para poder ampliarla en el momento el que sea llamada, por ejemplo:

def ordena( vector )
     (0..(vector.size-2)).each do |i|
         k = i
         (i+1..(vector.size-1)).each do |j|
             k=j if yield(vector[k], vector[j])
         end
         if k!=i
             tmp = vector[k]
             vector[k] = vector[i]
             vector[i] = tmp
         end
     end
end
 
vector = [ 5, 3, 2, 4, 6, 1 ]
 
ordena(vector) do |e1, e2|
    (e1 > e2)
end
 
puts vector  # [1, 2, 3, 4, 5, 6]
 
ordena(vector) do |e1, e2|
    (e1 < e2)
end
 
puts vector  # [6, 5, 4, 3, 2, 1]

En este ejemplo de código, la función yield no está definida, sino que equivale al bloque de código que se especifica más tarde, cuando se llama a la función ordena, en el caso mostrado, es como si las funciones yield fuesen en el primer caso:

def yield(e1, e2)
    (e1 > e2)
end

Y en el segundo caso, exactamente igual pero cambiando la comparación para que la ordenación sea en sentido descendente.

La definición del código es in-situ, en el momento de usarse es cuando se especifica qué hace yield.

Se puede hacer algo más complejo, por ejemplo, cambiando el array de enteros por un array de objetos específicos que tengan una comparación algo más complicada. Aún así, el código de ordena no habría que cambiarlo. Solo la llamada, y su bloque adjunto.

Conclusiones

Para los que no conozcan bien Ruby, esto les habrá sonado a chino, para los que lo conozcan bien, quizás algo ya más que sabido, pero lo importante, es que se tenga claro el concepto y lo que se puede hacer, ya que, la necesidad, de seguro, surgirá después.

Hola,

conforme al tema de los proyectos/productos, los desarrollos que se deben de realizar, los que se solicitan, y los que terminan (o no) entrando, es labor de la empresa asegurar un flujo constante de proyectos/productos con mejoras sobre lo que se ofrece en el portfolio de productos ya realizados, pero, queremos que conste que:

1. Cada proyecto/producto que se solicita, tiene unas implicaciones en tiempo y dinero que debe de amortizarse con los beneficios del mismo, ya que los recursos son finitos, al igual que el tiempo y el dinero de que dispone la compañía para este tipo de peticiones.
2. Los productos/proyectos tienen un proceso de desarrollo dependiendo de su complejidad, así como de la necesidad de integración dentro de otros productos/proyectos que ya estén desarrollados, por lo que no solo es labor de I+D, sino también de Sistemas y Área de Negocio el desarrollo oportuno del proyecto/producto, su forma de facturación y estructura de costes y la correcta puesta en producción para su monitorización y mantenimiento.
3. El desarrollo tiene varias fases en las que se debe de realizar el proyecto codificando cada parte solicitada o modificando un código ya existente, lo cual puede significar un mal funcionamiento en caso de que se haga con tiempos muy cortos y sin posibilidad de pruebas. La estimación de tiempos deberá de hacerse conforme a lo que se tarde en cada área en realizar su trabajo, y no comenzar a contar el tiempo antes de un inicio real.
4. Cada cambio que se solicita, pasado el período dispuesto para ello, conlleva tirar el trabajo de los días anteriores para comenzar prácticamente de nuevo y con menos tiempo. Por lo que, cada cambio, cuesta tiempo y dinero.
5. Desarrollar rápido una aplicación y ponerla a disposición del cliente, aún habiendo avisado de que puede generar fallos, es algo que debe de asumir quien lo solicita y sus responsables directos, así como los responsables de la infraestructura a mantener, puesto que en caso de fallo puede que no se vea afectado solo el desarrollo y el cliente para el cual se ha realizado el desarrollo, sino también el resto de clientes.

Puesto en conocimiento estos datos, queremos hacer constar y solicitar de vuestra parte que:

1. Se nos tenga en cuenta en cada proyecto/producto que se defina, así como cualquier cambio o indecisión que se tenga, antes de comenzar el desarrollo.
2. No se introduzcan cambios de última hora en desarrollos que están comenzados y con una fecha de entrega pactada, a menos que se pueda renegociar esta fecha de entrega.
3. Se defina un modelo de negocio antes del comienzo del desarrollo, para que la integración con área de negocio pueda realizarse desde primera hora.
4. Se nos dé voz y voto en las decisiones a tomar, en negociaciones con el cliente, y la forma de realizar cada desarrollo, ya que podemos aportar algo de innovación y valor diferencial, así como podemos amoldar su petición para optimizar el desarrollo y que el ciclo pueda, realmente, ser más corto.
5. Se tenga en cuenta de que I+D es desarrollo, es decir, que las tareas de llevar un proyecto/producto a producción es tarea de un conjunto de personas y de un jefe de proyecto designado para asegurar el éxito del proyecto/producto, por lo que, la responsabilidad es compartida por todas las áreas de entregar cada uno su parte y de realizar cada uno su trabajo.

Con todo esto, espero que podamos hacer más comités de desarrollo de productos y se nos dé mayor visibilidad ante la llegada de cualquier proyecto.

Gracias.

Espero que ante esta rogativa, se consiga algo bueno y de calado, ya que es asignatura pendiente en el sector de la informática el poder tener voz y voto a la hora de participar en la definición de productos/proyectos dentro del seno de muchas compañías de toda índole.

Este autor, en su afán por facilitar dentro de lo posible el desarrollo de software para todo tipo, se ha introducido en las entrañas de lo que es el software de empresa típico y ha definido elementos, objetos, patrones y ayudas específicas que facilitan el análisis, diseño y programación en general de aplicaciones de este tipo. El libro es Analysis Patterns.

La obra nos introduce en el mundo de los patrones, los conceptos y modelos de los negocios e intenta dar una visión general del porqué estos patrones pueden ayudarnos a simplificar la creación de aplicaciones. A través de los capítulos, se van viendo, tema por tema, todos los aspectos que en toda empresa se suelen abordar: contabilidad, plannings, inventario, etc.

Como suele decir Richard Stallman: “para leer buen código hay que leer buen código“; y esta obra la considero un buen sistema de análisis para el que se quiera aventurar a realizar análisis de sistemas de información.

En todas las empresas en las que he trabajado, siempre surge el problema de que, cuando sale algo nuevo o se crea un cierto programa, un sistema o una forma de trabajo, si la persona que la ha motivado no sabe su nombre: se la inventa.

Esto pasa con mucha frecuencia, y no es malo, pero es común que toda la empresa termine usando el vocablo en muy poco tiempo y, toda persona que entre nueva, si ese vocablo le parece desconocido o le sugiere otra cosa distinta, le lleve a confusión hasta que se lo expliquen.

Para esto se suelen hacer glosarios o lo que, en ingeniería del software se conoce como: Modelo de Dominio.

Este documento tiene varias partes, una de ellas se especifica como un glosario, estando ordenado alfabéticamente, y recogiendo todas las palabras que se usan, comúnmente en el entorno profesional en el que se mueve la empresa, y las palabras referentes a productos y servicios específicos que se comercializan o adquieren por parte de la empresa. Otra de las partes es la relación que hay entre conceptos que se manejan en la empresa, definición de características de cada uno de los elementos y restricciones de uso de los mismos.

Ceñirse a estándares es una forma de no necesitar un modelo de dominio, pero es complicado no saltarse las normas alguna que otra vez, por lo que, aún tomando precauciones de llamar a todo por su nombre, es conveniente y productivo, sobre todo para las nuevas incorporaciones o subcontratas, tener este documento disponible.