Amatl (i)

Hoy he comenzado un poco más en serio esta idea que tengo, Amatl. Se trata de un programa (y sus respectivas librerías) para crear widgets de escritorio en Gnome, mejor conocidos como Desklets.

Estoy consciente de que existen los GDesklets, aDesklets y los Desklets de Mono en Silverlight. Pero, además de querer unos con un nombre un poco más original (><), me desilusionó un poco la escasez de widgets implementados, además que después de probarlos un poco, hubo algunas cosas que no me gustaron, desde detalles como la instalación a cuestiones de usabilidad. Aparte de querer desarrollar un proyecto un poco más en serio, y aprovechar para enamorarme más de mi lenguaje favorito.

Por ahora, sólo creé el proyecto en code.google, y me he puesto a jugar con Ruby y GTK, con buenos resultados (ventanas transparentes con marcos personalizables que se quedan en el escritorio a voluntad, entre otras cosas). Me dedicaré estas vacaciones(?), además de la chamba, a trabajarle en este proyecto. Pero hago una invitación: Quien quiera aportar algo al proyecto, desde ideas a formar parte como desarrollador o artista, es bienvenido. Agradecería mucho los comentarios. Sé que con lo que he escrito aquí no es ni suficiente, pronto los actualizaré con un avance :D

Sobre rieles (i)

Últimamente no he posteado nada, he estado ocupado con el inicio de clases y otros proyectos. Pero eso no le interesa a nadie aquí...



Hasta que por fin me decido. Esta última semana, habiendo conseguido un buen libro y algunos tutoriales, por fin me he lanzado al mundo de Ruby on Rails.

He de decir que siempre le tuve un cierto pavor a las aplicaciones Web. Para ser sinceros, mis experiencias con las bases de datos han sido más bien desastrosas; además que trabajar con un proyecto de más de 5 archivos nunca se me ha dado. Afortunadamente, Rails me comprende.

Por ahora, he leído ya la mayor parte del libro Agile Web Development with Rails (la primera edición, que no pude conseguir la segunda), y en menos de una semana, dedicándole tan solo un rato al día, he podido crear mi propio proyecto, una variación del ejemplo con el cual trabaja el libro. Si eso no es ágil, entonces no sé qué lo sea.

He estado trabajando con NetBeans para Ruby [on Rails], el cual ha resultado ser genial. El mejor editor para Ruby que he probado, además de tener gran soporte para Rails en específico. Quizá un poco lento (por lo menos en mi máquina), pero sin duda vale la pena.

Por otra parte, la filosofía de Rails viene a solucionar muchos conflictos personales. Convención sobre configuración, eso es. El hecho de que todo esté donde tiene que estar, que la lógica de cada una de las partes pueda ser tratada por separado, y que existan plugins que le facilitan a uno la vida, realmente ha hecho que me guste esto del Web Development.

Así que comenzaré con un par de proyectos que tengo pensados desde hacer tiempo. Quién quita y al rato surge algo *útil* de ahí. :D

Primer lanzamiento de IronRuby

A través del blog de Miguel de Icaza, me entero que John Lam, quien trabaja para Microsoft, ha dado al mundo una probadita de lo que será IronRuby. Es decir, la versión pre-alfa. Y es muy prometedor.

Con la experiencia de JRuby, se demostró que Ruby era lo suficientemente maduro como para mezclarse con otros lenguajes ya bien desarrollados, y que además lo hace muy bien. Ahora, IronRuby ofrece una integración del de Ruby con el .NET Framework, lo cual es una buena noticia para los programadores.

Lo mejor de todo esto es que es (o pretende ser, debido a su etapa de desarrollo) compatible con las librerías del .NET, lo cual suena muy alentador. Y con la ayuda de Mono, no sólo los programadores de Windows se verán beneficiados.

Este post es una belleza. No sólo demuestra el poder de IronRuby, sino también la gran combinación que hace con Windows Forms. Si hay algo de lo que Ruby sufre es de una librería concisa y maciza para crear GUIs, y parece que esta es una muy buena alternativa.

Por ser código abierto, se garantizan contar con programadores entusiastas, fórmula que ha resultado muy bien para la comunidad Ruby. Felicidades a los desarrolladores involucrados.

¿Y los rubíes, dónde?

Leyendo en el blog de O'Reilly Ruby, un post interesante hizo que me pusiera a pensar de nuevo es la vida laboral que me espera: no hay trabajos en Ruby.

Tal sentencia en principio me parece muy exagerada, pero no está muy alejada de la realidad: Ruby carece de popularidad. Y más aún, fuera del éxito de Rails, Ruby es muy poco usado para aplicaciones reales, incluidas las comerciales. Parece ser que hasta ahora, se ha confinado a ser sólo un lenguaje de Scripting, no superior a Perl para tal fin.

Sin embargo, hay algo que destaca de Ruby sobre los demás lenguajes: su rápido crecimiento.

Si hay algo que decir acerca de Ruby (y estoy seguro que los rubistas que lean esto no me podrán negar) es que es un lenguaje apasionante. Así es, en el sentido literal de la palabra, cada vez son más los casos de programadores que se enamoran de esta pequeña joya.

Por ahora no cazaré brujas e iniciaré la eterna discusión sobre si X lenguaje es mejor que Y, pero hablando de Ruby, es preferido por muchos debido a su sencillez, su flexibilidad, su dinamismo, y hasta porque es divertido, entre muchas otras razones. Rails lo ha sabido demostrar, y a pesar de ser éste un hijo del primero, tiene más popularidad que Ruby mismo. Esto también demuestra que el mercado es el que manda, y Rails es el mensajero de guerra para tal fin.

Lo cual me lleva a mi punto principal: Ruby está apenas en una etapa de desarrollo, en la que se mueve más por inercia propia que por necesidad. Ha madurado muy rápidamente, y en mi opinión, pronto empatará (si no es que reemplazará) a algunos de los lenguajes comerciales utilizados en la actualidad. Sin embargo, los nuevos paradigmas de trabajo han hecho posible que pasantes, freelancers o simplemente gente con muchas ganas de trabajar puedan dedicarse a este negocio de la manera que les gusta: the Ruby Way.

Ruby es un arte, y como tal, debe primero alcanzar su máximo esplendor por sí mismo, antes de formar parte de las arcas de los coleccionistas.

El retorno de FizzBuzz

Como ya había mencionado en un post pasado, en el Ruby Quiz de la semana pasada se ponía a prueba a la comunidad Ruby con el quiz más participado hasta el momento: el FizzBuzz. Sin embargo, siento que James (reviewer de Ruby Quiz) no dijo todo lo que esperaba escuchar.

Comenzando por una cita del autor del artículo mencionado en el post pasado:

FizzBuzz es presentado como el mínimo nivel de comprensión requerida para ilustrar suficiencia y habilidad. No hay gloria en resolver esta prueba. Incluso si la puedes escribir en cinco lenguajes diferentes o en menos de 50 bytes.

El punto del artículo original fue reflexionar acerca de porqué debemos hacer la prueba del FizzBuzz. La parte mecánica de resolver el problema es irrelevante

que es exactamente lo que yo pienso. No quiero hacerme ilusiones, pero pienso que la mayoría de los programadores, a cualquier nivel, pueden resolver tal programa fácilmente.

Sin embargo, orientado hacia la comunidad Ruby, el problema exponía algo más interesante: Bien, ya sabemos que todos pudieron resolver el quiz adecuadamente... entonces, ¿hay una solución mejor que otra?

En el resumen del quiz, James menciona:

La mayoría parece concordar en que al menos una meta [del quiz] es demostrar una mínima capacidad para escribir código. La otra meta que asumimos es que los entrevistadores buscan cierto grado de cleverness.

Siendo cleverness una palabra engañosa y difícil de traducir. En el sentido literal, significa astucia, pero en el contexto de la programación, significa utilizar trucos "listos" para hacer el código más corto, o rebuscado, sin necesariamente ser más sencillo, que suelen ser todo lo contrario.

Esto debido a las reacciones de muchos rubistas pretendiendo "golfear" su código. Sin embargo, esto no se apega tanto al quiz, ya que personalmente, no diría algo así en una entrevista de trabajo:

Pero hay muchos otros aspectos que hacen del programador, y del software por ende, un producto de calidad. Aspectos como la escalabilidad, la legibilidad, la robustez, etc.

Es por eso que llegaron soluciones extendiendo el método a la clase Numeric (una de las delicias de Ruby), para ser extendible; otros tomaron en cuenta los comentarios para la documentación; hubo quienes hicieron pruebas de unidad. Todas estas alternativas muy válidas. Sin echar guayabazos, una de mis soluciones contemplaba la escalabilidad, al extender la clase a cualquier rango y condición para los números. Hubiera sido interesante analizar este tipo de parámetros en el quiz.

En fin, creo que FizzBuzz ya ha demostrado lo que tenía que demostrar, y si bien hizo más ruido de lo que debería, la perspectiva que nos presenta es alarmante: tener que recurrir a programas tan sencillos para darse cuenta de la incapacidad de muchos programadores.

Microsoft Ruby

He de admitirlo, no me agrada del todo la manera en que trabaja Microsoft. Siendo sinceros, a Microsoft le tengo cierta antipatía, principalmente debido a la manera en que influencia todo dentro del mundo de las computadoras, en especial de la programación. He hablado mil cosas negativas sobre Microsoft, sin embargo trato de no caer en ese anti-fanatismo que no es sorpresa ver en quienes se dedican a la programación (y no están del lado de Microsoft, obviamente). Y vaya que tiene sus razones.

Sin embargo, no todo es malo. Veo en Microsoft muchas cosas buenas (que ya discutiré más a detalle en otro post), pero sobre todo, acepto la realidad: Microsoft es un monstruo comercial, que queramos o no tiene mucha influencia sobre nuestras vidas, tanto de los programadores como del mundo en general. Es entonces preciso no ignorar ese hecho, sino ser proactivos, y preguntarse: ¿qué es lo que no me gusta de Microsoft?, y lo más importante, ¿cómo puedo yo contribuir a cambiarlo?

Trasladando esto al mundo de Ruby, surge aquí una situación interesante: IronRuby. Ésta es una implementación de Ruby diseñada para ser portable al .NET Framework. Analicemos los hechos:

Ruby: un 'pobrecito' lenguaje de programación, que no cuenta con millones de dólares detrás de él, es open source y cuenta con una comunidad de entusiastas verdaderamente envidiable.
.NET: Todo lo contrario.

¿De qué se trata? No es la primera vez que Microsoft se alía con el Open Source, sin embargo, se me hace un tanto interesante, tomando en consideración que existe un proyecto similar.

El gran problema de IronRuby es la actitud que tiene Microsoft ante él. Es un proyecto que, según Martin Fowler, tiene claroscuros

Microsoft está lleno de fuerzas contradictorias, y no sabemos cuál ganará.

con esto queriendo decir que es un tanto difícil conciliar ambar partes: por una parte, IronRuby es un proyecto que no se beneficia en nada del open source por el hecho de que su licencia no le permite utilizar el MRI (O Matz' Ruby Implementation), aunque está abierto a la posibilidad de que la comunidad, una vez lanzado el código que genere el CLR, haga sus propios parches y tenga la misma inercia que tiene Ruby. La licencia que consiguieron para utilizar el *casi* extinto Ruby.NET fue un gran avance, pero ahora veamos cómo logran sacar adelante esa meta de tener Rails corriendo en .NET.

Este dilema parece inquietar más a Microsoft que a la comunidad de ruby: ellos saben que hacen bien las cosas, y creo que no hablaré de más si digo que en general comparten la idea de que Microsoft debe ampliar su visión y no tratar de competir contra la realidad: es un Goliat, sí, pero sabe que no debe luchar contra David.

Las intenciones de ambos aún me parecen un tanto inceiertas. Sin embargo, confío en que se haga de esto un buen paso para la liberación del software y para la coexistencia pacífica con Microsoft. En una nota aparte, del .NET Framework me gusta la integración que tiene, y paradójicamente, la libertad que da al programador (aunque sólo sea dentro del .NET y corriendo sobre Windows, Mono es un caso aparte) Ampliar sus fronteras me parece un buen paso, aunque he de decir que JRuby lleva las de ganar en ese sentido. Será cuestión de cómo reacciona la comunidad para ver el alcance que tiene el proyecto. Por lo pronto, esperemos que no sea sólo un vaporware más adornando Silverlight.