¿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.

5 maneras de escapar del trabajo

Me agrada mucho la frase de Confucio que dice: "Si amas lo que haces, no tendrás que trabajar nunca más en tu vida."

Y es cierto. Personalmente, es lo que me motiva a seguir con la escuela, a buscar un trabajo en el que me sienta realmente a gusto, y a explorar todo aquello que me apasiona. Y vivir de eso si se puede.

Siendo sinceros, aún me sigue aterrando la idea de tener que esclavizarme treinta años trabajando para una compañía, especialmente si tengo que hacer algo que no me guste, a pesar de que estoy ya pisando esa frontera entre la vida escolar y el mundo laboral. Hay mucho qué aprender de Dilbert.

Sin embargo, es precisamente esa mentalidad la que hay evitar. He aquí un post interesante que precisamente marca la diferencia entre una mentalidad de trabajador y una de emprendedor:

1. Empieza por preguntarte: ¿qué tipo de trabajo quiero hacer?, en lugar de ¿qué tipo de negocio debo comenzar?
   
   
   
2. Olvídate de la permanencia.
   
   
3. Opera en un estado consciente y confidente de ignorancia.
   
   
4. Aleja tus expectativas tradicionales de salario.
   
   
5. Siempre considera despedirte a tí mismo.
   

Así que, ya saben, si quieren un trabajo mediocre, y ser medianamente felices el resto de su vida, sólo se requiere un paso muy sencillo: ignorar todo esto, y aceptar el primer trabajo ofrecido.

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.

Sonidos de videojuegos

Porque soy un nerd. No, en serio. Si alguien me pregunta qué tipo de música es la que más me gusta, diría que la de videojuegos.

¿WTF? Eso no es un estilo de música, lo sé. Es más bien toda una superclase, un concepto totalmente diferente, que aunque extraño, ha ganado mucho terreno. Me refiero a todas esas composiciones que desde los inicios de los videojuegos, los han acompañado, dando vida a esa gran experiencia.

La música de videojuegos, o gametracks, incluye estilos de todo tipo, desde la música clásica, instrumental, rock, funk, electrónica, etc. Sin embargo, creo que más que la música per se, lo que más me agrada es lo que representan, esa sensación de regresar al juego. No lo sé, pero hay algo que hace que me gusten más que otras.

OCRemix es el paraíso. Puedo decir que de ahí son algunas de mis canciones favoritas, y vaya que son muchas. Es increíble lo que se puede hacer con un gametrack. Y tampoco me avergonzaría alguna vez de ir a un concierto. ¡Sí, concierto! ¿a poco pensaron que era el único nerd? La música de videojuegos tiene muchos seguidores. Es toda una cultura.

Creo que ahora, a falta de tiempo para jugar, me conformo con escuchar música todo el día.


P.S. Koji Kondo rules!

FizzBuzz y los programadores de la tierra del yo-puedo

La historia comienza aquí. Un artículo ponía en tela de juicio la capacidad de quienes se dicen buenos programadores o desarrolladores, a través de un sencillo experimento. Se trata de un programa simplísimo:

Escribe un programa que imprima los números del 1 al 100, sustituyendo los múltiplos de 3 por la palabra 'Fizz', los múltiplos de 5 por la palabra 'Buzz', y los múltiplos de ambos por la palabra 'FizzBuzz'

Pero...

La mayoría de los buenos programadores son capaces de escribir tal programa en papel en menos de un par de minutos.

¿Quieren saber algo feo? - la mayoría de los graduados en ciencias computacionales no pueden. He visto auto-llamados expertos programadores que toman más de 10 - 15 minutos en solucionarlo.

Así pues se creó la leyenda del FizzBuzz. En una respuesta al mismo sitio de donde se generó la polémica, el autor menciona que muchos programadores inmediatamente lo tomaron como un reto personal, y las respuestas no se hicieron esperar. Miles de ellas, en todos los lenguajes y de todo tipo rápidamente comenzaron a surgir.

Todo esto viene al caso por el Ruby Quiz de esta semana. Para sorpresa de muchos, el quiz pedía realizar un programa de FizzBuzz, con la siguiente cláusula:

Imagina que has ido a una entrevista de trabajo y te han pedido esto.

que es precisamente lo que lo hace más interesante.

La respuesta ha sido igualmente vertiginosa, y ha habido mil y un formas diferentes de resolverlo. Sin embargo, esperaré hasta el jueves, en que se publique el resumen del quiz, y estaré pendiente en la comunidad. Sin duda, es un problema bastante interesante, pues pienso que es más un ejercico psicológico colectivo que un verdadero reto de programación.

Bloguear o no bloguear.

No tengo excusa.
Qué mejor manera de reiniciar un blog con esta cita en Microsiervos:

No trates de hacerlo… Hazlo o no lo hagas. De lo contrario, ni siquiera vale la pena que lo intentes.

No contaré la historia de nuevo. Sólo diré, voy a bloguear. Si no funciona esta vez, es buena señal de que debo dejar de hacerlo.