2008

Columnas publicadas en 2008

Coordinación de esfuerzos en grupos de desarrollo e integración de Software Libre

TitleCoordinación de esfuerzos en grupos de desarrollo e integración de Software Libre
Publication TypeMagazine Article
Year of Publication2008
AuthorsWolf G
MagazineSoftware Gurú
FrequencyQuarterly
Issue Number21
Pagination62-63
Date Published08/2008
Type of ArticleColumn
ISSN1870-0888
Keywordscomunidad, organización, Software libre
Full Text

Acercarse a comprender el funcionamiento y la organización de las tareas dentro de las comunidades de desarrollo de software libre es una tarea harto complicada ante quien se acerca con curiosidad, proveniente del mundo del software propietario, desarrollado e integrado centralmente y dentro de compañías que operan como "cajas negras" - Sin exponer sus procesos, sin ofrecer a los clientes una ventana a cada uno de los momentos de su proceso de desarrollo. Comprender cómo funcionan las comunidades de Software Libre es una gran oportunidad para comprender distintas metodologías de ingeniería de procesos, en entornos donde todas las metodologías formales simplemente no tienen cómo ser aplicadas.
El ejemplo que presento se centra en el trabajo que realizo en el grupo de empaquetamiento de módulos de Perl (pkg-perl) para la distribución Debian GNU/Linux [1] - Perl [2] es un lenguaje de programación muy popular, especialmente para las tareas de administración de sistemas y de desarrollo de sitios Web, y uno de sus más importantes recursos es el CPAN [3] (Comprehensive Perl Archive Network), una enorme biblioteca de módulos nacida en octubre de 1996, y que a febrero del 2008 cuenta con más de 13,000 módulos independientes.
CPAN ofrece a sus usuarios, además, herramientas para el desarrollo y seguimiento colaborativo, como un sistema de seguimiento de fallos [4] y un sistema de organización, búsqueda y consulta de la documentación de dichos módulos [5].
El proyecto Debian, por su parte, es la distribución de software libre, hoy por hoy, más grande del mundo, con más de 15,000 paquetes fuente independientes. Su propósito es presentar una colección coherente, consistente y con un elevado nivel control de calidad.
El reto del grupo pkg-perl [6] es empaquetar (de una manera consistente con las políticas de Debian) y dar seguimiento a los fallos que vayan apareciendo en dichos paquetes. Debian ofrece a sus usuarios un sistema de seguimiento de fallos centralizado [7] a través del cual pueden comunicarse directamente con los "mantenedores" de cada uno de los programas. Son ellos los responsables de determinar, para cada fallo, si cae en el ámbito de la consistencia del sistema Debian (y por tanto debe ser corregido directamente por ellos) o si es relativo a la lógica de uno de los paquetes (en cuyo caso debe ser corregido en coordinación con el autor de dicho programa, para que la corrección "fluya" hacia las otras distribuciones que lo integran y, en general, hacia todos sus usuarios).
Hasta hace unos cuatro años, la norma en Debian era que cada mantenedor fuera responsable exclusivo de los paquetes que le interesaran; en 2003 nació el sistema Alioth [8], basado en GForge, y ofreciendo de una manera centralizada las herramientas necesarias para un verdadero desarrollo colaborativo, se comenzaron a configurar grupos amplios de mantenimiento de infraestructura - Uno de los primeros en aparecer, ante la iniciativa de Joachim Breitner, fue pkg-perl. El eje fundamental en torno al cual gira el trabajo del grupo es el depósito Subversion [9], donde mantenemos sobre un esquema de manejo de versiones todos nuestros paquetes, programas y documentos, así como los cambios independientes que vamos realizando sobre de ellos.
Los módulos del CPAN ofrecen varias ventajas para su mantenimiento masivo colaborativo - A diferencia de lo que ocurre en muchos lenguajes, casi la totalidad los módulos están basados en una estructura de compilación ampliamente conocida (ExtUtils::MakeMaker o Module::Build). En primer término, esto permitió la creación de dh-make-perl, un script bastante genérico cuyo objetivo original era simplificar la creación de paquetes Debian directamente a partir del CPAN para ser instalados localmente por los administradores, pero que fue extendido por el grupo pkg-perl para automatizar la creación de paquetes.
Si bien formalmente el grupo pkg-perl cuenta con con 70 miembros, en todo momento hay aproximadamente 15 miembros activos. Actualmente, el grupo es responsable por 660 paquetes - Responsable de dar seguimiento a los fallos reportados, de mantenerlos al día (tanto respecto a nuevas versiones producidas por sus autores como respecto a las políticas en Debian, que van cambiando poco a poco reflejando la evolución del proyecto), de realizar operaciones transversales de control de calidad a través de todos los paquetes, y demás.
Para simplificar la coordinación de todas estas tareas, los integrantes del grupo (especialmente Martín Ferrari, de Argentina, Gregor Hermann, de Austria, y Damyan Ivanov, de Bulgaria) hemos creado un script [10] que compara el estado de los módulos en CPAN, los paquetes en el depósito Subversion, los reportes en el sistema de seguimiento de Debian, y los paquetes publicados en la distribución misma de Debian. Hoy en día, este script es nuestra principal herramienta, brindándonos un reporte de estado condensado y adecuado específicamente a nuestro flujo de trabajo - Y tan útil resulta este resumen que actualmente estamos adecuando este script para que lo utilicen también otros grupos con un enfoque similar; probablemente para cuando este artículo esté impreso, lo estén utilizando ya los grupos de empaquetamiento de Python y Java - habiendo varios más en el horizonte.
En resumen, el ejemplo que aquí presento es sólo uno de tantos - Pero es ilustrativo. Bajo el modelo del software libre, las barreras entre desarrollo e integración se desvanecen, y el contacto directo entre usuario final y los desarrolladores deja de ser una rara ocurrencia, y se vuelve la norma - algo que damos por supuesto en todo momento de nuestros desarrollos.
LIGAS:
[1] Debian GNU/Linux: http://www.debian.org/
[2] Perl: http://www.perl.com/
[3] CPAN (Comprehensive Perl Archive Network): http://www.cpan.org/
[4] Sistema de seguimiento de fallos del CPAN: https://rt.cpan.org/
[5] Sistema de búsqueda y consulta de documentación del CPAN,
http://search.cpan.org/
[6] Grupo de empaquetamiento de módulos de Perl para Debian:
http://pkg-perl.alioth.debian.org/
[7] Sistema de seguimiento de fallos de Debian:
http://bugs.debian.org/
[8] Alioth, sistema de desarrollo y coordinación de proyectos,
http://alioth.debian.org/
[9] Base del depósito Subversion del grupo pkg-perl,
http://svn.debian.org/wsvn/pkg-perl/
[10] Resumen de estado de los paquetes de Perl en Debian
http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi

AttachmentSize
200808_softwareguru_1.jpg819.2 KB
200808_softwareguru_2.jpg3.07 MB

La metaprogramación y los lenguajes dinámicos

TitleLa metaprogramación y los lenguajes dinámicos
Publication TypeWeb Article
Year of Publication2008
AuthorsWolf G
Access Date2009/03/27
KeywordsMetaprogramación, programación, Ruby
Abstract

La metaprogramación es una técnica muy poderosa, y muy socorrida en el terreno de los lenguajes dinámicos. Puede llevarnos a reducir muy fuertemente el total de código que escribimos - Y lo que es mucho más importante, a minimizar la cantidad de código repetido innecesariamente. Nos lleva claramente a aumentar la calidad y mantenibilidad de nuestro código.

URLhttp://www.sg.com.mx/content/view/718/1/
Full Text

La metaprogramación es una técnica muy poderosa, y muy socorrida en el terreno de los lenguajes dinámicos. Puede llevarnos a reducir muy fuertemente el total de código que escribimos - Y lo que es mucho más importante, a minimizar la cantidad de código repetido innecesariamente. Nos lleva claramente a aumentar la calidad y mantenibilidad de nuestro código.

Programas que escriben programas

La metaprogramación consiste en escribir código que no ataca directamente al dominio del problema que queremos atacar, sino que al código que lo resolvería. Dicho sea de otro modo, el código que escribimos no modifica los datos o el estado de nuestra información, sino que el del programa.

Las ventajas de los lenguajes dinámicos

La metaprogramación no es una nueva idea - Nació hace ya más de 40 años, con el lenguaje Lisp, y se popularizó tremendamente en el lenguaje Smalltalk, a principios de los 80.
Ambos lenguajes fueron revolucionarios en diversos aspectos, y si no gozan hoy en dí­a de mayor popularidad, se debe a que, en sus implementaciones originales sufrí­an de problemas de rendimiento en el hardware de su época. Sin embargo, sus ideas básicas han servido para conformar a una gran cantidad de lenguajes que han ido adquiriendo una cada vez mayor popularidad y aceptación: Los lenguajes dinámicos.
Podemos categorizar a un lenguaje de dinámico cuando no requiere de ciclos determinados y claramente separados de compilación y ejecución. Mucha gente cree erróneamente que los lenguajes dinámicos (por ejemplo, Perl, Ruby, Python o PHP, ampliamente utilizados en el mundo del Software Libre) son interpretados - La realidad es completamente distinta, son lenguajes que cuentan con compiladores tremendamente eficientes, que en fracciones de segundo pueden convertir decenas de miles de ­líneas de código en una representación binaria (bytecode para sus respectivas máquinas virtuales).
La caracterí­stica definitoria de estos lenguajes como dinámicos no es el compilador ágil (aunque, claro está, lo requieren) - Es la presencia de la instrucción (o familia de instrucciones) «eval». En resumidas cuentas, eval recibe un parámetro, tí­picamente una cadena, y lo evalúa como código fuente - Como una primer probadita de metaprogramación, consideren el siguiente código de Ruby:

  1. def crea_clase(nombre, clase_padre)
  2. eval "class #{nombre} < #{clase_padre} ; end"
  3. end

Al invocar a este método -claro está, en tiempo de ejecución- puedo ampliar la jerarquí­a de clases existente. Por ejemplo, si quiero definir suficientes clases para representar los muebles de una oficina, podrí­a decirle a Ruby:

  1. ['Mesa', 'Silla', 'Archivero', 'Librero'].each do |tipo|
  2. crea_clase(tipo, 'Mueble')
  3. end

Obviamente, la lista de objetos no necesariamente la tengo representada en mi código fuente - puede ser proporcionada por el usuario o determinada a partir del entorno de ejecución. Y a partir de este punto, para todos los propósitos de nuestro código, sería como si en tiempo de compilación hubiéramos incluido explí­citamente en el código:

  1. class Mesa < Mueble; end
  2. class Silla < Mueble; end
  3. class Archivero < Mueble; end
  4. class Librero < Mueble; end

Pero esto va mucho más allá de una manera cómoda y reducida de especificar clases.
Lenguajes específicos de dominio
A partir del número noviembre-diciembre de 2007 de SoftwareGurú hemos recibido entregas del tutorial de Ruby on Rails escrito por Carlos Ortega. Cuando nos acercamos por primera vez a Rails, lo primero que encontramos es una serie de declaraciones que no pertenecen a Ruby, y aparentan un estilo de programación declarativo. Por ejemplo, al definir un modelo:

  1. class Person < ActiveRecord::Base
  2. validates_presence_of :name
  3. validates_numericality_of :age, :greater_than => 0, :less_than => 100
  4. end

ActiveRecord es el ORM de Ruby on Rails - presenta una abstracción de los datos en las tablas de la base de datos, dándoles una interfaz natural orientada a objetos. El módulo ActiveRecord::Validations::ClassMethods extiende al lenguaje a través de la metaprogramación, y expone una serie de validadores, que presentan una sintaxis natural de escribir y fácil de leer - Un lenguaje especí­fico al dominio de las validaciones.

Reflectividad

La mayor parte de los lenguajes dinámicos son también reflectivos. Los objetos (y, recuerden, en los lenguajes completamente orientados a objetos, todo es un objeto - Incluyendo las clases, no sólo los objetos instanciados) pueden ser interrogados respecto a los métodos que ofrecen. Un ejemplo simple que muestra el poder combinado de la reflectividad junto con la metaprogramación es este simple rastreador universal:

  1. def trace(obj)
  2. obj.methods.each do |meth|
  3. eval "def obj.#{meth}(*args)
  4. warn 'Llamando al método #{meth} en #{obj.class}'
  5. super(*args)
  6. end"
  7.  
  8. end
  9. end

Basta llamar a nuestra función «trace» con cualquier objeto del sistema para que nos muestre un rastreo completo de cada una de las acciones que éste realice. Por ejemplo (desde la consola interactiva de Ruby):

  1. >> p = Person.find(:first)
  2.  
  3. >> trace(p)
  4. >> p.name
  5. Llamando al método method_missing en Person
  6. Llamando al método class en Person
  7. Llamando al método class en Person
  8. Llamando al método class en Person
  9.  
  10. Llamando al método send en Person
  11. => "Fulano D. Tal"

Aquí podemos encontrar cómo es que incluso la misma clase Person (que no es otra que la que declaramos hace algunas líneas) recibe sus métodos: ¡A través de la reflexibilidad, preguntándole a la base de datos acerca de su propia estructura!
El espacio no permite, tristemente, dar más ejemplos de cómo podemos explotar estas técnicas - Pero espero que con esta sencilla muestra puedan comprender la riqueza que esta técnica nos proporciona, y lo conciso que puede hacer a nuestro código.

AttachmentSize
200805_softwareguru_1.jpg496.65 KB
200805_softwareguru_2.jpg469.31 KB
200805_softwareguru_3.jpg145.62 KB

¿Cómo enseñar a los programadores del futuro?

Title¿Cómo enseñar a los programadores del futuro?
Publication TypeMagazine Article
Year of Publication2008
AuthorsWolf G
MagazineSoftware Gurú
Issue Number22
Pagination64
Date Published11/2008
Type of ArticleColumn
ISSN1870-0888
Keywordsautodidacta, enseñanza, motivación, paradigmas
Full Text

Nuestro gremio se caracteriza por conformarse por dos principales perfiles: Autodidactas y escolarizados. Esto obedece en no pequeña medida a que el campo es aún novedoso, y es aún posible para un aficionado ir obteniendo de manera gradual e independiente los conocimientos necesarios para llegar a un nivel de competencia comparable con quien estudió una carrera formalmente.
El programador autodidacta típicamente es un miembro muy valioso del equipo de desarrollo, dado que llegó a acumular sus conocimientos -teóricos y prácticos- por interés y motivación propia. Si bien es común que su formación muestre importantes "agujeros" cognitivos, especialmente en aquellos campos que requieren mayor rigor teórico/matemático, o sencillamente en aquellos por donde el interés no lo llevó, comunmente los subsanará tan pronto se enfrente a situaciones que los requieran. Sin embargo, es digno de mención que justamente es en las áreas más teóricas y aparentemente áridas del cómputo donde hay una mayor proporción de profesionales con éste
perfil.
No puede ser casualidad que dentro de los desarrolladores de Software Libre haya una tan alta proporción de autodidactas, gente formada en otras disciplinas y que ha ido encontrando su nicho de interés y trabajo en el cómputo, encontrando en la creación de herramientas que cubran sus necesidades particulares una nueva vocación.
Podríamos dedicar un muy amplio espacio a analizar la relación entre el conocimiento adquirido formal e informalmente, y en cómo insertar a estos en un esquema académicamente más formal... Pero el tema del que quiero ocuparme en esta ocasión es de quien viene de una enseñanza escolarizada.
¿Cómo transmitir el conocimiento, el interés, el entusiasmo, a los programadores escolarizados, para que alcancen un nivel de habilidad similar al de los autodidactas? Para esto, es fundamental que nos preguntemos, ¿qué y cómo enseñan a sus alumnos las universidades en nuestro país en cada una de las opciones de formación profesional relacionadas con el cómputo? ¿Qué perfiles reales de egreso hay de cada una de estas carreras (desde la muy aterrizada Licenciatura en Informática Administrativa, pasando por las muy variadas Ingenierías, con perfiles orientados más hacia Sistemas, Electrónica u otras variantes, y hasta el purismo teórico de las Ciencias de la Computación)? ¿Y cómo explicamos que, a la hora de buscar un trabajo, tan frecuentemente todos son puestos dentro de la misma gran bolsa?
El primer gran obstáculo al que creo todos los programas académicos deben reaccionar es a que muchos alumnos sienten que programar es una tarea tediosa, un rol que se verán forzado a desempeñar durante los primeros años de su trabajo, en lo que logra un ascenso a un puesto de "responsabilidad". Esto es, en buena medida, por lo torpe que resulta la enseñanza de los conceptos y habilidades básicos de la programación.
Hay dos escuelas básicas: Comenzar enseñando programación utilizando un lenguaje mínimo aunque completo, apto para transmitir los rudimentos de la estructura y el control de flujo (al estilo de C o del venerable Pascal). En contraposición a ellos, muchos otros académicos defienden comenzar enseñando con un paradigma completamente POO, con lenguajes como Java o como C#. Y ambas alternativas nos dejan importantes huecos por llenar.
Para alguien que inició con lenguajes de muy alto nivel, resulta más dificil comprender la traducción a código de más bajo nivel y la implementación en hardware del mismo, especialmente lo relativo a administración de memoria y el órden de complejidad; en este sentido, una de las más brillantes exposiciones la hace Ulrich Drepper, en su detallado y muy recomendable texto "What Every Programmer Should Know About Memory" [1]. Para todas las aplicaciones que corren "cerca del metal", como desarrollos de sistemas tiempo real, embebidos, controladores de hardware o software orientado al alto rendimiento, es fundamental dominar estos temas.
Por otro lado, para los programadores que parten de un entorno meramente procedimental, la POO se presenta como una complejidad adicional, como un obstáculo para la manera que ya tienen -y ya conocen- de soluciónar los problemas.
Si bien la discusión académica respecto a estas dos escuelas está tan viva como cuando se planteó por primera vez hace más de 20 años (p.ej. [2] y sus respuestas en [3]), creo yo que el problema de la motivación reside en no enfocarnos en lenguajes y marcos /simples/ (sin ser de juguete), que no permiten al alumno experimentar la /gratificación instantánea/ de lograr resultados atractivos tras apenas un primer acercamiento. Los lenguajes denominados /de scripts/ (Python, Ruby, Perl, y un largo etcétera) deben, claro, ser enseñados de otra manera, mucho más gradual, pero sin duda ayudan a mantener alta la motivación y baja la frustración.
Pero... ¿No son lenguajes con relativamente baja penetración corporativa? Así es, y eso representa otra ventaja - Una de las principales cualificaciones de un programador debe ser la capacidad de aprender tecnologías nuevas. Al enseñar con herramientas distintas, ayudamos a que los alumnos desarrollen la importante habilidad de /aprender a aprender/, no encasillarse en una herramienta. ¡Que se hagan del hábito de aprender nuevos lenguajes para diferentes retos!
[1] "What Every Programmer Should Know About Memory", Ulrich Drepper,
Red Hat, noviembre 2007,
http://people.redhat.com/drepper/cpumemory.pdf
[2] "Just say 'A Class Defines a Data Type'", Chenglie Hu,
Communications of the ACM vol. 51 No. 3, marzo 2008,
http://mags.acm.org/communications/200803/
[3] "Forum" (respuestas de los lectores), Peter Froehlich, Jack Cain,
Chuhg-Chih Li, Mark Hanna, Communications of the ACM vol. 51
No. 5, mayo 2008, http://mags.acm.org/communications/200805/

AttachmentSize
200811_softwareguru.jpg284.52 KB

¿Y por qué cambiar?

Title¿Y por qué cambiar?
Publication TypeMagazine Article
Year of Publication2008
AuthorsWolf G
MagazinePC Magazine en español
Date Published04/2008
Type of ArticleInterview
ISSN1665-4897
Keywordsevangelizacion, motivación, Software libre
Full Text

Tiene más de diez años que dí el brinco y migré a Linux - Ya no sólo como mi entorno primario, sino como el único sistema operativo que tengo instalado en cualquiera de mis computadoras.
En 1997, obviamente, hacer esto no estaba exento de problemas o retos. Yo soy del grupo de usuarios que decidieron migrar en primer término por razones ideológicas, a partir de la convicción de que el Software Libre es superior moralmente a cualquier sistema propietario, como Windows o MacOS.
Claro, ya desde hace diez años -e incluso para los más convencidos- era muy importante el argumento de la calidad y la estabilidad. Linux -heredero de la familia de sistemas operativos Unix y más de 35 años de historia- mantuvo desde sus humildes principios al ser desarrollado en la computadora personal de un estudiante finlandés de posgrado la que posiblemente aún hoy es su principal característica: La modularidad. Una computadora que corre con Linux tiene siempre en ejecución a cientos de pequeños programas, cada uno de ellos altamente especializado y de propósito claramente limitado, pero orientados a la integración - con interfaces públicas claras y bien documentadas. ¿Qué significa esto?
Todos los programas que utilizamos son, obviamente, escritos por seres humanos. Por más talentoso que sea un programador, no queda exento de equivocaciones. Estas son, sin entrar en demasiados detalles, las que llevan a errores en el comportamiento de nuestros programas. La gran ventaja, pues, que tienen los sistemas operativos tipo Unix es que, al ser tan modulares, no sólo nos es muchísimo más fácil localizar qué es lo que causa determinado fallo, sino ayudan a asegurar que, una vez corregido éste, su impacto será el menor posible. Esta es una de las grandes razones por las que el entorno GNU/Linux, incluso en su infancia (en que era desarrollado meramente como hobby, no tenía detrás a todas las empresas que hoy en día lo impulsan), fuera claramente más confiable para aplicaciones de servidor que Windows, que cuenta con la empresa de software más grande del mundo.
Desde 1997, claro, ya hemos avanzado muchísimo: Hoy en día hay gente que comienza a usar programas libres (como los reseñados en esta revista) o se muda por completo a Linux ya no sólo por ideología o por ganas de aprender, sino porque el entorno es más atractivo, estético, funcional o incluso compatible con su forma de trabajo - ¡sí! Hoy en día, programas como OpenOffice o Gimp son compatibles con una gama de formatos mucho más amplia que sus contrapartes propietarias, y sus interfaces de usuario se han vuelto más intuitivas que las últimas versiones de la competencia, sobre-cargada de funcionalidad rara vez utilizada.
Otra ventaja central de Linux es que es Software Libre - Y no, con esto no me refiero a que Linux sea gratuito (aunque típicamente lo sea, hay una industria muy importante construída alrededor del Software Libre). Si bien al día de hoy tengo más de diez años con Linux, tengo más de 25 como usuario frecuente de computadoras.
Me inicié aún con las "minicomputadoras" de principios de los 80, con decenas de terminales, y me tocó vivir y aprender la época de las Apple II y de las Commodore 64, las primeras PC... Y si bien todas ellas brindaban conocimiento y experiencias importantísimas para todo quien, como yo, a la postre se dedicaría al cómputo como actividad profesional, siempre partían de la lógica de que había un núcleo operativo cerrado, casi sagrado, que La Empresa (fuera en este caso Apple, Commodore, IBM o Microsoft) nos daba, sobre del cual podríamos construir. Con el software libre, sin embargo, lo que recibimos es una invitación a asomarnos a cada uno de los componentes del sistema - Una invitación con toda la documentación necesaria, con todas las herramientas de desarrollo y depuración para lograrlo.
La diferencia es tremenda: Un usuario de Linux con algo de curiosidad científica no se enfrenta a la "magia negra" de cómo funciona el sistema, y no acepta el argumento de que "la computadora no quiere" o que "la computadora está lenta". Un usuario de Linux, con el paso del tiempo, va comprendiendo las funciones y relaciones entre los componentes del sistema, y se vuelve capaz de corregir un problema. No sólo eso; a través de todo tipo de foros de intercambio, podemos participar en el desarrollo, mantenimiento o soporte de todos esos programas que tanto nos han dado.
Entonces, en resumen... ¿Por qué me mudé al Software Libre, y por qué sigo ahí? Porque me dio herramientas indispensables para ser un usuario más feliz, más profesional - y una mejor persona, miembro activo de una comunidad que me ha dado todo lo necesario para mi desarrollo profesional.

AttachmentSize
Texto original para publicación4.71 KB
200804_pcmag_1.jpg229.25 KB
200804_pcmag_2.jpg299.04 KB