La magia de Perl

Una de las características que hacen de perl una navaja suiza (por cierto afilada) son las construcciones mágicas del lenguaje, que permiten escribir micro programas rápida y fácilmente, y es una de las razones por las cuales el lenguaje tiene fama de incomprensible.
Aunque el uso de estas construcciones están contraindicadas en la programación de sistemas, son de gran utilidad en el día a día de los administradores de sistemas y programadores, por ello voy a explicar las más comunes, para que puedas apreciar su potencia y entender los scripts que se crucen en tu camino.
[artículo completo]

Perl arcaico

Hace un par de dias me tocó atender un proveedor que vino a ofrecer sus servicios para el desarrollo de una aplicación web.
Como alguno de los participantes de la organización tuvo que manejar un imprevisto aproveché para iniciar un pequeña investigación durante la charla informal: "¿Que herramientas de desarrollo utilizan en su empresa?".
En un mundo ideal la respuesta hubiera sido: "Perl", pero me informaron que ellos trabajan principalmente en Python, aunque pueden trabajar en otros ambientes, incluyendo Perl.
Después de informarles que en la organización preferimos Perl para el desarrollo de nuestras aplicaciones, y después de un micro debate religioso, uno de ellos (Juan) concluyó:

En definitiva cualquier cosa que se puede hacer en un lenguaje se puede hacer en el otro, solo que en Perl la programación es más arcaica

en aquel momento casi me altero, pero en vista de que llegó el que faltaba y que lo importante era la reunión, me quedé tranquilo.
Ahora en retrospectiva me pregunto: ¿a qué se refería con eso de que Perl es arcaico? ...
 [artículo completo]

Reunificando Scheme

Menos de dos años han pasado desde la polémica 6ta revisión del lenguaje Scheme (R6RS), que causó una ruptura de la comunidad. El lenguaje siempre se caracterizó por ser puro y minimalista hasta que este nuevo estándar duplicó el tamaño de la especificación.
En el proceso de ruptura apareció un movimiento para mejorar R5RS, pero manteniendo el lenguaje fiel a sus principios, así nació ERR5RS.
Scheme nunca se convirtió en un lenguaje práctico para el despliegue de aplicaciones, debido a que muchos aspectos de la implementación no eran parte del estándar, dificultando la interoperación del código entre las diversas implementaciones del lenguaje, así que la comunidad de scheme siempre ha estado de una u otra forma dividida, sin embargo R6RS causó una gran fractura, con la mayoría de los fabricantes quedándose en R5RS o migrando a ERR5RS, mientras las implementaciones grandes se fueron por la vía de R6RS.
Esto es una lástima porque los fundamentos matemáticos sobre los que se basa Scheme son muy formales, de hecho toda la semántica del lenguaje está definida matemáticamente a usando semántica denotacional.
Hace unos días para mi sorpresa se activó nuevamente la lista de discusión de R6RS, y la discusiones que vi fueron sobre la división del lenguaje en dos versiones y los posibles nombres que se le darían cada versión!
En un esfuerzo por reunificar la comunidad se piensa en que la próxima versión de Scheme (R7RS?), tendrá una versión light que permita implementaciones pequeñas y mantener a los puristas contentos, mientras la versión pro sería más pragmática, con énfasis en la implementación y desarrollo de sistemas y en interoperabilidad entre las versiones de los diversos fabricantes de compiladores, esta versión profesional podría incluir  un sistema de módulos y una librería estándar.
Ojala este nuevo esfuerzo pueda reunificar nuevamente a la comunidad sin convertir Scheme en un nuevo Common Lisp.

El Ironman de Perl

La Organización de Perl Iluminado (enlightened perl organisation), está promoviendo un maratón de blogging en perl para de motivar a los miembros de la comunidad a promover el uso de este lenguaje.
Las reglas son simples:

• Se puede escribir cualquier cosa sobre Perl, desde información básica hasta avanzada incluso chistes (lo que brinda incluso oportunidad a los detractores del lenguaje).
• Los artículos pueden ser cortos o largos, así que se pueden escribir recomendaciones simples, trucos, etc.
• Los artículos no tienen que ser necesariamente en inglés, asi que podemos hacer artículos en castellano!
• Hay que publicar al menos 4 artículos cada 32 dias, y ningún artículo puede tener más de 10 días de separación.

Si estás interesado puedes enviar un mensaje a ironman@shadowcat.co.uk con los detalles del blog, luego inscribe el feed y tu blog será agregado en http://ironman.enlightenedperl.org/.
Yo por mi parte estoy comenzando un nuevo blog: Perliscopio a ver si logro mantener el ritmo ;-)

Microsoft no entiende a los gobiernos.

Recientemente me conseguí este artículo que ilustra la estupidez de los sudafricanos, que luego se extiende a los asiáticos, latinoamericanos y que finalmente llega incluso a parte de los europeos, por pensar que el software libre es una mejor opción para los gobiernos de sus respectivos países.

El señor Matusow parece estar consternado por el hecho de que Sur África ha decidido utilizar software libre cuando no haya ninguna ventaja extraordinaria ofrecida por software propietario, la idea del gobierno de Sur África es simple:

El criterio principal para seleccionar soluciones de software permanecerá siendo la mejora de la eficiencia, efectividad y economía de los servicios ofrecidos por el gobierno a sus ciudadanos

Lo cual, debería ser uno de los objetivos principales de cualquier gobierno del mundo para cualquier solución en cualquier área, así que no debería haber mayor problema, sin embargo el documento sigue:

El software libre ofrece ventajas significativas ventajas indirectas. Donde las ventajas y desventajas directas de productos libres y propietarios sean igualmente fuertes y si las circunstancias en una situación específica no lo hacen inadecuado, el software libre será preferible

Que en mi opinión es una postura bastante moderada, sin embargo el señor Matusow entra en crisis y emite opiniones como:

Yo estoy en contra de los mandatos en tecnología, y este no es diferente.

Peor aún, obliga a los jefes de tecnología a tomar decisiones que no quieren hacer - esencialmente tomando ambientes que funcionan y representan grandes inversiones para migrarlos a soluciones no probadas y más caras.

Será que el señor Matusow aún trabajando para Microsoft no está al tanto de que su compañía hace exactamente esto todo el tiempo, la última cita es perfectamente válida en el contexto de Windows Vista, donde a pesar de las súplicas de los usuarios, Microsoft los obligará a tomar una decisión que obviamente no quieren tomar, para migrar a una solución más cara en dinero y en recursos.

Adicionalmente el artículo nos habla de las amargas experiencias del autor en la que toda discusión sobre software libre termina en un debate Linux contra Windows, y que los pobres ignorantes de los gobiernos no se dan cuenta de que la libertad en Linux no les servirá para nada cuando la solución final sea montar algo como SAP en Linux.

Tal vez este señor no sea capaz de visualizar que se pueden implementar soluciones 100% libres para resolver el 99% de las necesidades de automatización de oficina, gestión gubernamental y servicios al ciudadano. Seguramente existen casos específicos en los cuales ningún software libre ofrezca todas las opciones requeridas, sin embargo cuando se trata de soberanía y seguridad nacional, creo que es más rentable a largo plazo, desarrollar las funcionalidades requeridas que permanecer como una nación subordinada a las decisiones de una fábrica de software.

Después nos hacen un análisis de lo que los gobiernos buscan en el software libre:

1. Ahorrar dinero
2. Desarrollo tecnológico
3. Soluciones adaptadas a las necesidades locales
4. Eficiencia operativa y financiera
5. Oportunidades para vendedores e integradores locales
6. etc.

Sin verguenza alguna, se explica que no hay ninguna oportunidad de que el desarrollo del sistema operativo suceda en Sur África - aseveración por demás interesante tratandose justamente del país donde se creó la distribución de Linux más exitosa de todos los tiempos (Ubuntu) - que el modelo de software libre debe aplicarse al desarrollo de aplicaciones y dejar el sistema opearativo en paz.

Sin embargo el "etc." incluye algunas cosas que convenientemente se omiten en la lista, probablemente por que son de menor importancia (para el autor):

1. Independencia
2. Soberanía
3. Seguridad Nacional

Desde mi punto de vista este señor es totalmente ignorante sobre las prioridades de un Estado, o se hace la vista gorda, sobre todo cuando vive en un país que es capaz de gastar enormes cantidades de recursos, e incluso iniciar guerras o invasiones con frecuencia en nombre de algunas de esas premisas.

Pero nuestro articulista nos dice que es irreal pensar en que los estudiantes de las universidades se sumergirán en las profundidades del funcionamiento interno de Linux, por lo que asumo que está muy consciente al menos de los asuntos de independencia y soberanía tecnológica. Lo cierto es que aún cuando sea poco probable que los estudiantes se metan de lleno en el funcionamiento interno de Linux, esto es completamente posible, mientras en Windows es absolutamente imposible por su naturaleza propietaria.

Finalmente Matusow nos ilustra la ignorancia de los países en desarrollo, donde el software libre se asume como software gratuito, aunque el desarrollo de las soluciones tecnológicas es igual o más costoso utilizando software libre. Claro está que él no se da cuenta de los costos intangibles de la lista anterior, por supuesto el vive de los abusos de su empleador cuando obliga a un Estado a migrar de Windows XP a Windows Vista, sin importarle que además de los costos de licencias - de los que él se beneficia, además obliga a los gobiernos a renovar toda la plataforma tecnológica de una nación.

Es sumamente triste que a estas alturas del año 2008, después de que una gran cantidad de gobiernos en todos los continentes han analizado los beneficios del software libre desde infinidad de perspectivas, todavía existan personajes como este, que supongo serán pagados para escribir este tipo de ridiculeces.

Autocompletación en VIM

Por si acaso alguien todavía no lo sabe: vim autocompleta. Y debido que lo puedo usar desde terminales remotos, en un editor que arranca en un segundo, no necesito cosas como Eclipse, donde necesito un ambiente gráfico y 5 minutos para comenzar a editar cualquier cosa.

Para autocompletar por contexto edite un archivo y agregue:

sub factorial {
   my $n = shift;
   return 1 if $n <= 1;     return f 

y mientras el cursor está todavía al lado de la f (en modo de inserción), pulse CTRL-N y vim completará el la palabra, Vim busca en el archivo actual por palabras que comienzan con el prefijo indicado, y si hay mas de una, abre una persiana de selección.

Con la sintaxis activada (:syntax on) y en modo Perl también busca palabras para autocompletar en todos los módulos que se han usado, supongo que hará lo mismo con python, ruby, etc.

Si quiere autocompletación sobre el lenguaje, puede agregar a su .vimrc, las funciones correspondientes para el lenguaje, a mi me resulta cómoda la ayuda para CSS:

  autocmd FileType css set omnifunc=csscomplete#CompleteCSS

Luego en un archivo CSS, al tipear:

.miclase {
  text

seguido inmediatamente de CTRL-X CTRL-O, mostrará las opciones correspondientes, que se pueden seleccionar con las flechas de dirección.

Hay toda una variedad de lenguajes en los que podemos autocompletar:

  autocmd FileType python set omnifunc=pythoncomplete#Complete
 autocmd FileType c set omnifunc=ccomplete#Complete
 autocmd FileType cpp set omnifunc=ccomplete#Complete
 autocmd FileType python set omnifunc=pythoncomplete#Complete
 autocmd FileType perl setlocal expandtab ts=4
 autocmd FileType javascript set omnifunc=javascriptcomplete#CompleteJS
 autocmd FileType php set omnifunc=phpcomplete#CompletePHP
 autocmd FileType xml set omnifunc=xmlcomplete#CompleteTags
 autocmd FileType html set omnifunc=htmlcomplete#CompleteTags
 autocmd FileType sgml set omnifunc=xmlcomplete#CompleteTags

Esos son los que vienen de cajita en Debian, pero como todo en vim, eso es programable, si necesitan un lenguaje nuevo se pueden hacer la definición, que debe ser similar al archivo que define las palabras de perl.

Amazon apuesta a Erlang

Amazon acaba de lanzar SimpleDB, un nuevo servicio de almacenamiento estructurado, con las características de alta disponibilidad y concurrencia de S3. Este es el segundo servicio basado en Erlang que lanza Amazon al mercado, el otro es el servicio de colas (Simple Queue Service), y es emocionante ver el rendimiento de la plataforma Erlang para la implementación de sistemas que deben operar confiablemente 24x7 y además proveer escalabilidad infinita, tanto en rendimiento como en capacidad.

Amazon, con su plataforma basada en Perl, Linux, Xen, y ahora Erlang, realmente le está sacando punta al software libre.

Pero veamos de que se trata este nuevo servicio que es el sueño mojado de los desarrolladores de la web 2.0.

SimpleDB no funciona como una base de datos relacional, no se necesita definir un esquema, en este sentido parece seguir la tendencia a la desaparición de las bases de datos relacionales, que mencioné en un artículo anterior.

Las características que más me gustan de este servicio:

• Manipulación de conjuntos de datos realmente grandes (10GB por dominio y hasta 100 dominios por usuario)
  
• Muy rápido (espero que se mantenga así)
• Modelo de computación por demanda (solo se paga por lo que se usa)
  
• Modelo de datos similar al utilizado por los lenguajes de scripts (Perl, Python, etc.), sin necesidad de definir esquemas.
• Interfaz REST y también SOAP.
  
• Fácil de usar, como los hashes en Perl :-)
• Hecho en Erlang, me pregunto si usaron CouchDB ;-)
  

Sin embargo, hay que considerar algunos detalles operacionales:

• Al igual que el servicio S3, los objetos almacenados no están disponibles inmediatamente, hasta que están replicados y se puede garantizar la disponibilidad de los mismos, de este modo Amazon se olvida de la C en ACID, para garantizar la durabilidad.
• Todo es texto, las consultas se hacen lexicográficamente, así que los números deben formatearse apropiadamente, las fechas deben almacenarse en ISO-8601 (pero todos ustedes ya hacen esto, no?).

El modelo de datos es sencillamente espectacular y hace honor a su nombre, los datos se organizan en dominios, donde se pueden almacenar colecciones de atributos, donde cada atributo tener uno o más valores. Las colecciones de atributos pueden ser diferentes para cada objeto del dominio.

Para todos aquellos acostumbrados a lenguajes como Perl, Ruby, Python, etc. pueden imaginarse la estructura de datos como un arreglo que contiene hashes cuyos valores pueden ser escalares o listas.

El lenguaje de búsqueda provee los operadores: =, !=, <, >, <=, >=, STARTS-WITH, AND, OR, NOT, INTERSECTION AND UNION, pero las consultas están limitadas a un máximo de 5 segundos (aunque ninguna consulta de las que pude probar en las 8 horas que tiene el servicio, tardo más de algunos milisegundos).

Hay que mencionar que los costos de almacenamiento son muy superiores a los de S3, mientras que en este último almacenar un 1GB cuesta $0.15, en SimpleDB cuesta $1.50, es decir 10 veces más caro, aunque se puede transferir datos gratuitamente entre S3 y SimpleDB.