¿Quien es quien? Hoy: MotoGT

Para terminar con las presentaciones formales, voy a contarles sobre el tercer y último proyecto: MotoGT. En resumidas cuentas, es un juego de carreras de motos 2D de vista superior. Los gráficos son bastante feos ya que no soy un gran dibujante ni diseñador, y la mecánica del juego es por ahora muy básica ya que escribí todo el "engine" (va entre comillas porque no puedo llamarle engine a eso) de cero y sin muchas ambiciones. La verdad es que empezó como una, digamos, prueba de concepto, y después me entusiasme y terminé publicándolo.

Lo primero que hay que saber es que me encanta ese tipo de juego. Como referencia obligada, puedo recordar horas y horas de un verdadero grande del género como fue Death Rally (el original, que pueden bajar legalmente para Windows desde aqui, y que en GNU/Linux corre perfectamente con wine). Lo que mejor lograba este juego según mi criterio era un balance perfecto en la dificultad y el sistema de premios (mejores autos, más armas, la posibilidad de competir en carreras más difíciles, trampas, sabotajes, premios inesperados, un adversario final, etc). Con gráficos impecables para la época, una combinación excelente de carrera y combate, y un sinfín de agregados y personajes, hacían que uno no se cansara de ver y hacer siempre lo mismo como puede ocurrir fácilmente en un juego aparentemente tan simple. Desde chico intenté programar juegos de carrera de vista superior (además porque es relativamente fácil para empezar). Por otra parte, hay otra historia más personal sobre una deuda pendiente que será develada en otro post, y que me lleva a tener un especial cariño con estos juegos y a querer experimentar en el género.

Toolchains alternativos en ZinjaI

Wikipedia en inglés empieza la definición de toolchain con algo que traducido sería más o menos "el conjunto de herramientas de programación que se utilizan para crear un producto...". Esta definición involucra compilador, editor, depurador, etc. Pero en la práctica he visto usar este término para referirse mayormente al conjunto de herramientas que verdaderamente producen el ejecutable; es decir el compilador en sentido general, que incluye preprocesador, compilador, ensamblador, enlazador, y cualquier otra cosa que pueda ser necesaria para pasar del fuente al ejecutable. Mi compilador amigo es el archiconocido gcc en GNU/Linux (y su port para Windows de 32 bits, mingw32), pero existen muchos otros. Entre las alternativas puedo mencionar al compilador de intel (que nunca probé, pero que tiene muy buena fama en el ambiente científico porque logra ejecutables más rápidos en ciertas configuraciones y un set interesante de herramientas auxiliares), o al flamante conjunto LLVM+Clang. LLVM es un conjunto de herramientas que forman parte de un toolchain propio modular y flexible. Clang es el módulo que le falta para completar un conjunto enteramente basado en llvm que compile de principio a fin código C++. Su creciente popularidad y su rápida evolución, junto con otras ventajas que forman parte de su concepto me hacen pensar en integrarlo en ZinjaI. Y ya que voy a estar en el baile, pretendo hacer esta integración de una forma más o menos genérica para que al final ZinjaI permita configurar fácilmente toolchains alternativos, o incluso diferentes formas de construir un proyecto independientemente del toolchain.

Emparchar vs Reescribir: ¿qué hacer con un diseño limitado?

Rara vez, al comenzar un proyecto personal, el diseñador/programador sabe exactamente a donde va a llegar. Puede tener una idea bastante aproximada de hacia donde quiere ir, y hasta de qué podría llegar a cambiar, pero inevitablemente algo va a pasar que lo va a obligar a plantearse la posibilidad de rediseñar medio programa. Solo un experto iluminado con gran experiencia puede proponer desde el comienzo el diseño adecuado en un proyecto más o menos complejo. En general, el programa muta, el programador madura, y las cosas cambian. La mayoría de los mortales, empezamos con un diseño que por alguna razón en algún momento pareció correcto (o tal vez no pareció del todo correcto, pero si pareció ser la mejor de las posibles opciones), y luego vemos como el proyecto, si sobrevive al embate inicial, va cambiando lenta O dolorosamente: lentamente cuando las cosas se hacen bien, dolorosamente cuando se hacen rápido.

Es decir, a la hora de implementar algo no previsto en el diseño inicial de un sistema, podemos tomarnos todo el tiempo necesario replantear el diseño inicial para hacerlo más flexible, recodificar lo que sea necesario recodificar para cumplir con el nuevo diseño, actualizar la documentación, etc. y luego agregar pacíficamente la nueva funcionalidad; o bien podemos empezar a parchear el código poco flexible que escribimos en un primer momento para tener rápidamente al menos un prototipo andando. Por lo general, cuando el cambio no es tan grande, voy por la segunda alternativa, hasta que llega un día en que mi código es 90% parches y 10% del pobre diseño original, y se hace imposible seguir añadiendo cosas (o al menos hacerlo sin romper lo que ya estaba andando).

Las mil y una distribuciones

Sabido es que hay cientos de distribuciones de GNU/Linux dando vueltas, y que de cada una conviven varias versiones al mismo tiempo. Es decir, unos usuarios tienen Fedora, otros Ubuntu, otros Arch, algunos Mint, unos pocos Slackware, aquel usa Gentoo, un amigo OpenSuse, etc, etc, etc. Y además, supongamos que solo existiera Ubuntu, alguno usará la de 32 bits, otro la de 64, alguno seguirá con la 10.04 porque es LTS, otro tendrá la 12.04 porque le gusta tener siempre lo último, el más pacífico tal vez corra la 11.10 porque aún no aplicó las actualizaciones, y hasta uno por alla con un hardware viejo y raro se quedó en la 9.10 porque es la única que le reconoce todo y le anda rápido con su poca memoria.

Tanta variedad trae problemas (y ventajas, pero vengo a plantear algunos problemas). Para empezar, los programas de terceros de los que dependen ZinjaI o PSeInt varían enormemente. Por ejemplo, si quiero correr algo en una terminal gráfica, ¿uso xterm? o ¿konsole? o ¿gnome-terminal? ¿o qué?. Supongamos que uso konsole, los argumentos que recibía en kde3 eran unos, pero en kde4 son otros, y hasta varían entre versiones de kde4. O supongamos que uso gnome-terminal. Hasta cierta versión de gnome uno lanzaba un proceso en esta terminal y esperaba a que termine, pero a partir de no se cuando empezó a lanzar el proceso algo así como en segundo plano, entonces el comando que hace la llamada finaliza enseguida, aunque el proceso que quería ver tal vez ni siquiera alcanzó a comenzar. Otros casos podrían ser instalar íconos y asociar tipos de archivos con los muchos exploradores de archivos (soluciones como xdg empiezan a parecer estándar pero aún no están en todos lados), o lanzar un comando como administrador (gksudo es lo más común, pero tampoco está en todos lados).

El autocompletado y yo (capítulo 1)

Si hay algo que hace cosas raras en ZinjaI es el autocompletado. A veces funciona, a veces no, a veces se confunde, y otras inventa. Un buen programador sabrá notar sus defectos. Por eso voy a intentar, con una serie de artículos, justificar algunos con sus virtudes, contarles porqué tomé estas decisiones a la hora de diseñarlo, y de paso explicar en lineas generales cómo funciona, qué hace bien, qué hace mal, qué no hace, y qué planes tengo para mejorarlo.

La culpa de todo la tienen Basic y Borland C++ Builder. Como ya comenté antes en algún que otro post, aprendí a programar con Basic y jugué con eso por muchos años. Y allí no había autocompletado alguno (a menos que llamemos a los atajos de teclado que escribían palabras clave autocompletado, pero no es lo mismo). De hecho en los primeros Basics que usé no había siquiera un "editor" (entre comillas porque es discutible), hasta que descubrí QBasic y QuickBasic. Es por esto que en mis comienzos no estaba acostumbrado al autocompletado, y entonces no tenía mucho con que comparar cuando usaba uno como para opinar sobre sus virtudes y defectos. Pero en Builder, que es lo que usábamos en la facultad cuando aprendí C++, había algo que cualquiera podía notar aún sin saber nada del asunto: era desesperantemente lento. Las PCs de los laboratorios de la universidad no eran aviones ni mucho menos, pero tampoco estaban tan mal para ese momento. Y aún así, cuando uno ponía un punto después de un objeto, o la flecha después de un puntero (cosa que ocurre cada 3 segundos mientras se programa en C++), podía irse a tomar un café y volver al rato a ver si había terminado de cargar el menú de autocompletado. Y esto me sacaba de quicio, claro está. Así que cuando empecé a pensar en el autocompletado de ZinjaI, solo impuse una condición: tenía que ser rápido.

¿Quien es quien? Hoy: ZinjaI

Siguiendo con las presentaciones, toca hablar de ZinjaI (aclaración: la ultima letra es una i, pero en mayúsculas, no una L como parece con muchas fuentes, y lo pronuncio zinyai, por su significado: "ZinjaI is not just another IDE"). ZinjaI es actualmente un IDE (entorno de desarrollo integrado) para programar en C/C++, que debería ser útil tanto para principiantes como para programadores avanzados. Pero originalmente, no iba a ser así.

Todo empezó por un programa de becas que tienen en mi facultad para que alumnos de grado se inicien en investigación. El alumno se presenta con un director y un plan de trabajo para dedicarle algunas horas a la semana durante año y medio a algun proyecto de investigación o relacionado. A cambio recibe, entre otras cosas, una formación básica, una primer experiencia, y un punto más en su CV.  En un momento de mi carrera, el docente titular de las primeras materias de programación, aprovechando lo que ya tenía encaminado con las primeras versiones de PSeInt me ofreció aplicar para una de estas becas, para formalizar ese desarrollo y continuarlo.

Como la parte más importante (el intérprete en sí) de PSeInt ya estaba desarrollada, me puse a pensar qué otra herramienta nueva podría ser de utilidad en el aula. Dado que en nuestra carrera, luego de pseudocódigo pasamos a utilizar C++, lo lógico era pensar en una herramienta para empezar a trabajar con C++. 

Juguemos al diagrama de flujo

El diagrama de flujo es una alternativa directa al pseudocódigo. Siempre digo a mis alumnos que se puede pasar del pseudocódigo al diagrama y al revés mecánicamente, todas las veces que se quiera, y sin perder nada en el intento. Esto es bastante cierto, la información importante para el intérprete no varía. Es decir, no se pierde ninguna instrucción ni ningún argumento en el pasaje. A algunos estudiantes les resulta más fácil empezar planteando sus algoritmos en un diagrama antes que en un código. Cuando el algoritmo involucra estructuras de control (condicionales y/o bucles), el diagrama de flujo permite visualizar mejor las posibles lineas de ejecución que un código escrito secuencialmente.

Actualmente PSeInt permite ir del pseudocódigo al diagrama, pero no al revés, no permite editar el diagrama. Además de que los diagramas que muestra no son de los más lindos, y el visor no es de los más rápidos, siempre me pareció un punto bajo, un hueco donde se podía aportar mucho. Pues bien, en la próxima versión incluiré nuevo y fantabuloso visor/editor de diagramas de flujo, parecido al que se muestra en el video:

Su consulta no nos molesta

Antes de que lean esta entrada tengo que hacer una aclaración: en un proyecto de software libre, los usuarios son uno de los recursos más valiosos, no solo lo digo yo, lo deja muy claro Eric Raymond en "La Catedral y el Bazar" (no dejen de leer ese ensayo). En particular, en mis proyectos, donde no hay un gran equipo trabajando en el testing, el diseño, la documentación, etc. como sí puede suceder en una gran empresa, o en una fundación con más recursos, el feedback de los usuarios es vital, y por eso hay que cuidarlos, y no atacarlos como voy a hacer a continuación.

Creo que el problema se debe en gran medida a que el usuario medio, por decirlo de alguna manera, está acostumbrado a utilizar software privativo (pensando en enlatados de uso diario, no en desarrollos a medida para una empresa), y esto le ha generado muy malos hábitos, al menos desde la perspectiva de un desarrollador de software libre. Más allá de mis alegatos a favor del software libre, no soy un extremista, y sé que hay software privativo de muy buena calidad, que hay empresas serias y desarrolladores muy capaces en ellas; pero la forma en que se trabaja de un lado y del otro es muy diferente, y los usuarios, en consecuencia, también lo son.

Sobre tipos de variables y bolas de cristal

En PSeInt siempre tuve un dilema interesante, y aún hoy no tengo certezas sobre cual es la mejor solución. El problema es cómo determinar el tipo de una variable. En este lenguaje, no es necesario declarar las variables y decir de que tipo son, pero sin embargo cada variable tiene un tipo asociado. Es decir, hay variables para guardar texto, otras para números, y otras para valores de verdad. El usuario casi nunca dice explícitamente de qué tipo son las variables que usa en su algoritmo (en realidad a veces sí, se puede configurar, pero en la mayoría de los perfiles no). Entonces, el interprete debe "adivinarlo", y para ello debe analizar qué se hace con estas variables, o qué datos se guardan. O sea, en realidad debe tratar de deducirlo. Pero no siempre se puede, y el problema es ¿qué hacer cuando no?.

Por ejemplo, tomando el siguiente fragmento de pseudocódigo:
    Leer A
    Escribir "Usted ingreso: ",A
La variable A podría ser de cualquier tipo, según qué ingrese el usuario. Si analizamos qué ingresa el usuario para determinar el tipo, en cualquier caso el algoritmo funciona. Pero este otro fragmento:
    Leer Clave
    Si Clave="123" entonces ...
funcionaría mal, ya que al leer 123 el interprete deduciría que es numérica, pero al querer comparar con la cadena de texto "123" generaría un error.

¿Quién es quién? Hoy: PSeInt

Antes de poder escribir sobre tópicos o problemas específicos de alguno de mis tres proyectos, por prolijidad debería escribir artículos presentándolos. Debería contar para qué sirven, como nacieron, en qué estado están, hacia a donde van, qué tienen de interesante, etc. Por eso, este artículo inaugura una trilogía de posts llamada ¿quién es quién? donde trataré de hacer las debidas presentaciones. Según el orden cronológico, de los tres proyectos que se considerarán centrales por ahora en este blog (no quiere decir que no haya tenido otros más chicos dando vueltas, o que no aparezca uno nuevo en el futuro), el primero en cobrar vida fue PSeInt; y su historia comienza así:

Tuve la suerte de aprender a programar (o algo similar, porque era un cavernícola, pero me las rebuscaba) mucho antes de entrar en la universidad. Aprendí de muy chico con Logo y Basic, y seguí con este último y sus derivados durante largos años, tal vez más de lo aconsejable. Probé desde el primer Basic para DOS hasta los modernosos Visual Basics de la época, pasando por apbasic, zbasic, qbasic, quickbasic, etc. Aunque podría resumirlo en Quick Basic y Visual Basic, los demás son solo leves variaciones. Programar siempre fue un hobbie, casi un arte, como tocar la guitarra, o escribir cuentos, algo divertido, así que hice mucha mucha práctica. El punto es que llegué a la universidad sin saber lo que era una clase o un puntero, pero con un dominio casi absoluto sobre los ifs anidados, los fors, los whiles, y las expresiones matemáticas que uno usa habitualmente al programar.

Actualizaciones automáticas, instalación de complementos, y Windows haciendo cosas raras

En el sitio de ZinjaI agregé hace un tiempo una sección de complementos y versiones de prueba entre las descargas. Lo que uno encuentra allí son ejecutables de versiones no estables (¿alguna lo es realmente?... no, pero estos no están ni testeados a veces) y archivos para facilitar el trabajo con bibliotecas (templates de proyectos, archivos para el autocompletado, binarios, documentación, etc.). Estos archivos se presentan como comprimidos (zip o tgz) y la "instalación" consiste en que el usuario lo descargue y lo descomprima encima de la instalación original de ZinjaI.

Por el momento sólo hay un complemento (para trabajar con la biblioteca SFML) y encima no muy actualizado, pero me gustaría mejorar esa situación actualizándolo y agregando algunos otros. Dándole vueltas al asunto empecé a analizar la idea de incorporar una opción de menú para instalar los complementos directamente desde ZinjaI. Es decir, que ZinjaI los descomprima donde el sabe de modo que no haya forma de equivocarse, y podría ser que en el futuro, además de descomprimir, también ejecute algunas acciones como alterar configuraciones para colocar botones accesos a las referencias en la barra de herramientas.

De la instalación de complementos desde el mismo programa surgen dos tópicos interesantes para comentar: 1) ¿que tal si hago que ZinjaI acceda al sitio y descargue él los complementos para que el proceso sea todavía más fácil y rápido?, y 2) algunas cuestiones de implementación relacionadas a los privilegios y permisos de usuario que requiere esta instalación.

Como abandonar los frames de html en 3 simples pasos

En estos días tuve que hacer pequeñas modificaciones en los sitios web de ZinjaI y PSeInt, y esto me llevó a recordar lo poco recomendable que era utilizar frames html para armarlas. Tengo que aclarar que no se casi nada sobre lenguajes de programación y marcado para web. Es decir, entiendo como funcionan, pero no estoy realmente familiarizado con ninguno de ellos. Simplemente aprendí lo escensial de html y javascript durante un curso en mi carrera de grado y completé esta formación con un curso de php muy muy básico que tomé por separado (no tengo ni idea de la sintaxis para hacer una clase en php por ejemplo). Con este poco conocimiento y google a mano me las rebusco para armar los sitios webs de mis proyectos, ya que son sitios bastante simples, razón por la cual tampoco me tomé el tiempo de profundizar mucho sobre estos temas. Y entonces, como era de esperar, la implementación es horrible.

Basicamente me gustan los diseños claros: una pequeña cabecera que no moleste, un menú bien a mano, y el contenido al centro ocupando la mayor parte de la ventana. Una forma muy fácil de implementar esta organización en html es usando frames. Los frames básicamente particionan el espacio en varias sub-areas y dentro de cada una se carga una página web individualmente. Entonces, cuando empecé hace años a armar el sitio del pseint, dividí la ventana en tres: cabecera, menú y contenido, escribí un html para cada una y listo. Lo bueno de los frames es que cada área puede ser independiente y cargar una página completa hasta de otro sitio si se quiere. Además, al acceder a un enlace en el contenido por ejemplo se actualiza esa área, manteniendo el menú y la cabecera intactos.

Bienvenido Al Mundo Del Mañana

Probando, probando... Sí, ssssí, hola... hola... 1,2,3, probando. Bien, parece que está encendido...

Tengo el agrado de dirigirme a ustedes con el vital objetivo de informarles de que va este nuevo blog. Para empezar hay que saber que tengo, hasta ahora, tres proyectos de sofware que empecé hace tiempo y mantengo en mis ratos libres: PSeInt, ZinjaI y MotoGT. El primero es una herramienta para aprender a programar, el segundo un IDE para programar en C++, y el tercero un juego de carreras.

Resulta que estos programas no son perfectos en muchísimos aspectos, no se ajustan a lo que algunos usuarios esperan o imaginan en otros, o simplemente tienen cosas medio raras que, para bien o para mal, llaman la atención del programador más avesado. Entonces, suelo recibir preguntas cuyas respuestas no son cortas o directas, sino que tienen historia, que hay que considerar casos, hay que analizar alternativas, o simplemente hay que aceptar errores y limitaciones. Pues bien, este será el lugar donde trate esos temas, explayandome lo necesario y sin estructura alguna.

Por ejemplo: mil veces me han pedido que agregue la posibilidad de definir funciones en PSeInt; o me han preguntado por qué el autocompletado de ZinjaI actúa extraño; etc. Publicaré mis respuestas esperando que se entienda lo que me llevó a hacer las cosas de ese modo, y tal vez alguien se enriquezca de mi experiencia para no cometer en sus proyectos los mismos errores, aprenda de mis pocos aciertos, o simplemente sacie su infinita curiosidad. Además, va a ser un buen lugar para publicar las cosas que pasan actualmente en mi cabeza y las discusiones que tengo conmigo mismo o con otros usuarios en relación a nuevas funcionalidades que planeo implementar y que presentan algún desafío interesante.

Leerán artículos de todo tipo, desde aquellos que simplemente expliquen cuestiones funcionales sin entrar en detalles, hasta otros que discutan cuestiones de implementación, con contenido algo más técnico. Algunos estarán muy relacionados con lo que hacen mis programas, otros tocarán temas más generales, como la programación multiplataforma, el desarrollo de software libre, etc. En lo personal, me servirá para documentar muchas decisiones, pero espero que a alguien más le resulte útil o al menos interesante.