Programando en Ruby

Llevo tiempo escribiendo sobre este lenguaje de programación, como una joya redescubierta, ahora me gustaría centrarme en un libro que leí hace tiempo, pero que me resultó muy útil para comprender y adentrarme mejor en este lenguaje.

Programming Ruby
Dave Thomas, Chad Fowler, Andy Hunt; Pragmatic Bookshelf 2008

Este libro, escrito por uno de los firmantes del manifiesto ágil (Dave Thomas) y otro de ellos como co-autor (Andy Hunt), es un libro que tiene en su interior, no solo el aprendizaje del lenguaje en sí, sino de una metodología de programación, una suma de buenas prácticas de programación que se orientan a sacar el mejor partido del lenguaje potenciando sus fortalezas y aprovechándolas con patrones de desarrollo ágiles que mejoran y potencian su uso.

Recomiendo el libro a todos aquellos que quieran adentrarse en la programación en ruby de la mano de personas que desarrollan día a día con él desde hace mucho tiempo, y no se han quedado estancadas (prueba de ello es que este libro es segunda edición y en 2008 salió la tercera edición, el cual no he podido leer aún, pero promete mayor y mejor contenido).

Joe Armstrong y Erlang

Llevo bastante tiempo hablando de Erlang, y nunca había comentado la mejor fuente que había encontrado para descubrir el lenguaje y adentrarse en la programación concurrente de la mano de uno de sus creadores: Joe Armstrong. La fuente, referida como tal, es el libro que escribió Joe Armstrong por la editorial Pragmatic Programmers:

Programming Erlang
Joe Armstrong; Pragmatic Bookshelf 2007

El libro tiene una sección inicial que nos adentra en el problema que se encontró el autor, el porqué es necesario un lenguaje como Erlang y, sobre todo, un acercamiento al mismo desde la perspectiva de alguien que sabe poco o nada de programación. Es una lectura rápida y amena, facilitada por la claridad del código acompañada.

La única pega, quizás, es que el libro se queda corto a nivel de profundidad, es decir, el tema de OTP lo trata de pasada solo viendo un poco los gen_servers, así como la forma de empaquetado y puesta en producción. El entorno, la concurrencia, la distribución, todo queda en un estadio incial que puede abrumar e incluso dar la sensación de ser muy amplio al principio, pero cuando entramos en harina, se ve que nos falta más información. No obstante, tenemos una buena base y se completa todo con la información que el propio Armstrong ha dejado en la web del lenguaje.

Una lectura muy aconsejable para quien se quiera adentrar en la programación en Erlang y su entorno.

Scrum y XP desde las trincheras

Un año y medio después de haber comenzado con las tecnologías y metdologías ágiles, no tengo más que recomendar el libro que me ayudó a comenzar y que ha sido una guía durante todo este tiempo.

Scrum And XP From The Trenches
Henrik Kniberg; Lulu.com 2007

Este libro (y su traducción al castellano), han supuesto una guía práctica de cómo comenzar en el desarrollo ágil tomando a Scrum como referencia y empleando, en lo que se refiere a técnicas de programación, algunos ejemplos de la metodología de Xtreme Programming.

El libro brinda la visión personal de Henri, una persona que ha estado empleando estas metodologías como consultor con muchos grupos de trabajo a lo largo de muchos años de trabajo y, gracias a ello, y a su excelente labor pedagógica, ha conseguido escribir un buen libro, claro, conciso y bastante corto para todo el material que contiene. Son libros que se leen de forma rápida y te preguntas, cuando llegas a su última hoja: ¿ya se acabó?

Extreme Programming explained

Este es uno de esos libros pioneros que hacen que nos planteemos muchas de las cosas que hacemos y, sobretodo, el cómo lo hacemos.

Extreme Programming Explained
Kent Beck; Addison-Wesley Professional 1999

La metodología de la programación extrema fue acuñada por Kent Beck, como un conjunto de buenas prácticas y una forma de realizar los desarrollos, siempre basándose en dar el mayor valor al cliente, tal y cómo se supone que debe de ser siempre.

No obstante, el propio Beck sabe que esta metodología, al igual que las demás, tiene sus ventajas e inconvenientes, ya que si se intenta seguir de forma inflexible, puede resultar en que los proyectos terminen siendo, en algunos casos infructuosos. En este sentido, Beck, nos llama hacia la agilidad como una forma de sacar nuestro sentido común y emplear nuestro saber hacer, y no los procedimientos tipo que aplicar.

Buen libro, de principio a fin, enseña no solo las bases y teorías, sino que plantea, desde el comentario de cómo funcionarían equipos dentro de la metodología, escenarios de cómo se puede aplicar.

El futuro de MySQL

Desde que MySQL fuese vendida a Sun Microsystems, ha habido bastante gente que ha visto con otros ojos el proyecto, mostrándose algo escépticos a que MySQL pudiera seguir siendo lo que venía siendo, una base de datos libre sin mayores pretensiones. Pero siendo Sun Microsystems una empresa que ha realizado mucho código para la comunidad, pero también ha guardado mucho otro de forma recelosa, teníamos nuestras dudas.

El problema real vino cuando Sun Microsystems fue adquirida por Oracle. Esta adquisición puso a MySQL en la duda de si seguiría siendo lo que es, o pasaría a ser otro producto más recortado en su versión comunitaria y ofrecido por un precio medio/alto a empresas que se lo puedan permitir. Como si de una versión light de Oracle DB se tratase.

Entre todo este tumulto, en parte levantado por Monty, uno de los principales desarrolladores de MySQL, que se fue de la empresa cuando comenzó todo el lío, surgen varias versiones de MySQL, forks, que prometen seguir la línea original y seguir apostando por el crecimiento de este sistema dentro de la comunidad y el software libre.

Una de las apuestas es MariaDB, promovida por el propio Monty, es un fork del último código estable de MySQL, agregando todos los patchs que no se incluyeron en MySQL y dando soporte a problemas que parece que los desarrolladores principales de MySQL han olvidado.

En otro punto se sitúa el proyecto Drizzle, que intenta seguir los ideales iniciales de MySQL en un punto en los que muchos de los desarrolladores que pertenecían a esta comunidad, consideran que se torció el desarrollo principal.

Con esto podemos decir que el espíritu de MySQL no ha muerto, ni morirá, puesto que seguirá vivo en dos ramas separadas de su código original en los momentos clave en los que cada comunidad vió que era el momento de un cambio.

Como nota curiosa, el ecosistema de protección de los sistemas gestores de base de datos abiertas (Open Database Alliance), se encarga de la promoción entorno a los sistemas gestores de las base de datos. Una propuesta interesante que promete un poco de seguridad dentro de este entorno.

La importancia de la actualización

Desde hace años, me vengo encontrando con sistemas instalados que hay que mantener o sobre los que hay que desarrollar, que son instalaciones de hace 5 ó 7 años. Estas instalaciones suelen ser máquinas con RedHat 9, RedHat EL 2, 3 ó 4, o Fedora Core 2 ó 3. En esos años RedHat estaba muy metido en el entorno empresarial y Fedora Core fue una respuesta libre (totalmente) a la desaparición de RedHat Desktop.

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

Wordpress y los ataques DoS

De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

Spam por relay

A la mayoría no solo le sonará este artículo, sino que lo habrá experimentado en propias carnes. Esto se detecta fácilmente, cuando comienzan a llevar emails que vienen con el remitente MAILER-DAEMON. En este momento puedes planteartes dos posibles escenarios:

  • han entrado en tu servidor y han comenzado a enviar un montón de emails desde tu cuenta de usuario, o
  • alguien ha comenzado a enviar un montón de emails a servidores mal configurados, con tu dirección de email como remitente, para hacerte llegar todos esos mensajes.

Visto por cualquiera de las formas pinta mal, pero a la que nos referimos cuando hablamos de spam por relay es la segunda. Tu sistema está bien configurado, nadie ha entrado y no has enviado ningún email, pero sin embargo comienzan a llegar emails de MAILER-DAEMON o similares, diciendo que no han podido entregar tu email (y te lo ponen completo) porque no se encuentra el usuario, porque está mal formado, o por cualquier otro error intencionado que ha introducido el spammer.

El problema se da, y lo sé porque lo he vivido, cuando abres la bandeja de entrada y ves nada más y nada menos que de 30 a 60 mensajes diarios con el mismo asunto. Después, leyendo las cabeceras del email (esas que no se ven a simple vista, ni desde MUAs como Outlook), se puede ver, en la lista de los Received, el último que aparece (que es el primero que se escribió):

Received: (from nj.ua@localhost)
	by nj.ua (8.13.8/8.13.8/Submit) id a862dvhn858019;
	Thu, 21 Jan 2010 09:36:45 +0800

Ha sido enviado por alguien que no se conoce, la siguiente línea es la del que recibe el email, directamente, por lo que no ha pasado, siquiera, por nuestro servidor. Estamos seguros… pero eso no nos quita el problema… y realmente, y lamentablemente, no hay una solución real a este problema, ya que al intentar comunicar a cada uno de los sitios la configuración que deben de poner para que esto no pase (validación de SPF, uso de EHLO o HELO,…) o no saben cómo hacerlo y pasan, o pasan directamente.

Por lo que, el spam ha conseguido otra vía de acceso a través de los sistemas de email más pobremente configurados (y hay muchos así) de Internet. ¿Habrá forma de pararlos?

Los sabores de Windows

Las liberaciones de Windows, de Microsoft, suelen realizarse siempre por triplicado, es decir, de cada línea interesante que saca la compañía, hay tres versiones, después es abandonada por los motivos que se verán obvios.

La triada de Microsoft consiste en sacar una versión primera, una versión más elaborada gráficamente y mejor recibida por el público en general, y una última versión que termina siendo un fiasco, que dura poco en el tiempo y en la memoria de muchos usuarios, afortunadamente para Microsoft.

La línea light

Cuando los equipos no eran tan potentes como para soportar todas las características que tenía incluídas Windows NT, la empresa tuvo que realizar un sistema operativo mezclado con el sistema DOS que ya tenía, para obtener un sistema mixto llamado, en un principio, Windows 95.

Después llegó la versión bonita, que fue Windows 98, la cual era una versión gráficamente superior de Windows 95 y mejor preparada para Internet.

El punto final a esta línea lo puso Windows ME (Millenium Edition), del cual, pocos se acuerdan, salvo los que lo sufrieron y la mayoría coincide en que tenía multitud de fallos y las mejoras gráficas y de incorporación de elementos multimedia no compensaba esos fallos.

La línea NT para particulares

Cuando la potencia de las máquinas de uso cotidiano alcanzó a poder ejecutar sistemas NT, la compañía recuperó su sistema base, sin recortes, y aprovechó el cambio de siglo para sacar su primera versión, la cual tuvo una expansión hacia los sistemas servidores y un gran lanzamiento en lo que respecta a la empresa (que era la que podía hacer el mayor desembolso). Esta versión fue Windows 2000.

Dos años después, esta versión ya era posible en su incorporación al mercado residencial y se potenció su interfaz gráfica, así como sus elementos multimedia, liberándose como Windows XP. Esta versión supuso un cambio drástico a aquellos que cambiaban directamente desde Windows 98 (un sistema basado en el kernel de DOS) a este (con un kernel NT que no permitía ya la ejecución de aplicaciones de 16 bytes de DOS).

Al igual que en la línea anterior, se intentó potenciar la línea multimedia y de interacción gráfica para el sistema pero, parece que la historia se repitió y la tercera entrega, al igual que Windows ME, fue otro fiasco. Esta liberación tuvo el nombre de Windows Vista.

Re-escritura y nueva vida

Después de topar con la imposibilidad de seguir con la infraestructura NT tal y como estaba, la compañía necesitaba un nuevo lavado de cara y comenzó el desarrollo de Windows 7, el cual ha sido una reescritura completa, desde cero, así como lo fue Windows 95 y Windows 2000. Con lo que conforma el principio de otra línea, en la que la siguiente versión será, o eso se espera, muy buena, llegando una tercer que marcará el final de la línea… con otro fiasco.

Alternativas

Microsoft no es la única compañía que, después de 15 años, ha realizado un sistema basado en el kernel de NT para la ejecución de programas. Estos sistemas, desde simuladores para otros sistemas operativos a sistemas operativos en sí mismos, han hecho que el uso de sistemas tipo Windows no sea monopolio de Microsoft.

Entre otros, los emuladores más conocidos, desde el mundo GNU/Linux, son Wine, Cedega y CrossOver (basados en wine).

Uno de los sistemas operativos, que trabaja junto con wine en el desarrollo y emulación del kernel NT bajo sistemas Unix, es ReactOS. El desarrollo de este sistema es muy activo desde que comenzó y ya tienen un LiveCD en el que se pueden probar aplicaciones para Windows. Una alternativa muy a tener en cuenta, y sobre todo porque es GPL, es decir, software libre.

¿Qué se busca conseguir en un desarrollo?

La respuesta rápida y obvia podría ser: que lo desarrollado cumpla con los requisitos pactados.

La realidad, muchas veces, nos demuestra que esto no su cumple, ya que, o los requisitos pactados se engordan, o nos fijamos más en que se cumpla el tiempo pactado, lo cual realmente no es un requisito, en muchos casos. Al final, parece que premia más el tiempo invertido y el dinero gastado que lo que se ha adquirido.

Imagina que vas a comprar unos pantalones, quieres unos pantalones para diario, simples, pero dado que es invierno, que te los puedas pasar sin pasar frío. Ese es nuestro valor a conseguir. Si vamos a comprar los pantalones y hablando con el encargado los pedimos: que sean azules oscuros, con un diseño radical, moderno, de mi talla, … ; quizás al final tengamos unos pantalones que sean como unas mayas… ¡a ver quién se las pone en invierno!, pero claro, por el dinero que dábamos, lo que pedíamos, y el tiempo que le dábamos al encargado para que los buscase… pues es normal.

En desarrollo de software pasa igual. Al principio, el cliente tiene la idea de un software, por ejemlo, para gestionar su almacen. Después piensa que, si se va a invertir mucho tiempo en su desarrollo, entonces puede pedir que venga con sistema de nóminas, contabilidad, gestión de pedidos a mayorista y generación de facturas a clientes… y por el camino, mientras ve algunos proyectos de portfolio, pues se le ocurre pedir también un sistema de carro de compra para internet… y todo eso en el tiempo que se tiene para hacer solo la primera idea… ¿saldría bien?… ¡no!

Volviendo a la pregunta inicial, la respuesta después del planteamiento desarrollado, sería, más concretamente: busco que resuelvan un problema específico que tiene mi empresa, el cual no le permite crecer al ritmo que queremos que crezca.

Por ello, el desarrollo de una aplicación de software debe realizarse siempre con la idea clara en mente de que, el desarrollo, va a cubrir una necesidad detectada, o a automatizar una tarea, que ya se realiza, pero se necesita realizar de forma automática para que los trabajadores puedan realizar más tareas a lo largo de un día. Si el software desarrollado no cumple esta espectativa, no solo no aporta valor, sino que es posiblemente un lastre para la empresa.