Probando otros sabores de GNU/Linux

Hace algo más de un mes cambié el disco de mi notebook y tuve que reinstalar todo. Y por primera vez desde que uso GNU/Linux, instalé en mi PC principal algo que no es Slackware. Pasé más de 20 años usando exclusivamente Slackware en mis PCs de trabajo. Probé otras distros en otras PCs o en máquinas virtuales, pero con ninguna había trabajado demasiado en serio. Ahora intenté con Fedora 32. Esperaba encontrar problemas durante la transición, y lo hice. Pero no fueron del tipo de problemas que esperaba.

ZinjaI+GIT y scripts de bash con interfaz gráfica

Iba a empezar describiendo lo maravilloso que es git, pero voy a dar eso por sentado e ir al grano: ¿cómo es que en ZinjaI no hay ninguna funcionalidad específica de integración con git? Antes de que se ilusionen, les adelanto que no, no estoy trabajando en eso. Peeeero... además de justificar mi no, en este post les cuento cómo integrar igual algunas acciones habituales.

And the winner is... (II)

Todas las semanas alguien del staff de SourceForge elige 10 proyectos para destacar, con algún criterio que no estoy seguro cual es, pero que por suerte le da iguales oportunidades a proyectos chicos y grandes. Luego, a fin de mes, de entre todos los destacados de ese mes, se elige un subgrupo de 9 o 10 proyectos y se somete a votación para determinar cual es el próximo "Community Choice Project Of The Month" (proyecto del mes (POTM) elegido por la comunidad). El ganador ostenta el título durante un mes. A veces, los editores eligen uno más como "Staff Choice POTM". Si entran al home de SF, lo primero que verán serán los proyectos destacados del mes, y lo segundo, los de la semana. Para cada proyecto destacado del mes, además, SF publica una entrevista con alguno de los desarrolladores en su blog. Pues bien, este mes (Septiembre 2015) el "Community Choice POTM" es nada más ni nada menos que PSeInt!!!

Primeros pasos con git (parte 0)

Trabajé durante mil años sin usar sistemas de control de versiones (cosas como svn, cvs, git, mercurial, bazaar, etc) ni nada parecido, y durante todo ese tiempo no sentí la necesidad de hacerlo. Principalmente porque trabajaba solo, o en pequeños grupos, entonces el modelo de llevar y traer zips/tgzs fechados alcanzaba como para no complicarse "por demás" con todo un repositorio. Sin embargo, en algún momento quise ofrecer el código de ZinjaI y PSeInt "en tiempo real" (que cada cambio que haga esté inmediatamente disponible para quien lo quiera probar), porque eso es algo que me gusta de muchos proyectos de los que soy usuario, y porque tiene otras ventajas adicionales (como por ejemplo que algunos usuarios puedan ayudar con el testing de forma temprana).

Hasta entonces, como dije, solo había usado los sistemas de control de versiones para clonar repositorios ajenos y nada más. A partir de ese momento, empecé a experimentar un poco con crear repositorios, hacer y publicar cambios, etc. Y tuve que elegir un sistema en particular, y me incliné por git porque era el que estaba de moda, y porque es un producto que nace de la mano del mismísimo Torvalds para gestionar nada menos que El Kernel, así que potencia y flexibilidad estaban garantizadas. Además, su popularidad prometía mucha documentación actualizada, es decir, un fácil y rápido aprendizaje.

La importancia del testing

Cualquiera que trabaja en un ambiente profesional sabe que en un proyecto de software se dedican tiempo y recursos planificados para testing y control de calidad en general (QA). Se requiere gente capacitada y con un sexto sentido para averiguar como reventar un sistema en dos simples pasos (mi novia trabaja como tester y creanme que es increíble la facilidad que tiene para encontrar errores que jamás se me habría ocurrido siquiera buscar). Pero también, cualquier programador que desarrolla un proyecto artesanalmente por hobbie, fuera de toda formalidad como sucede a muchísimos proyectos de software libre, sabe lo tedioso que puede ser lograr eso. Ya lo dije muchas veces, en ZinjaI, en PSeInt, y en MotoGT desarrollo a mi ritmo, lo que creo necesario, y soy accidentalmente mi propio tester cuando uso las dos primeras herramientas en mi trabajo, o cuando juego un rato con el tercero.

Pero como buen seguidor del modelo de bazar de Raymond, trato de liberar seguido y esto convierte a mis usuarios en mi mayor recurso de testing. El proceso suele ser: cambio algo, lo pruebo en mi notebook mientras lo desarrollo (una prueba para nada general), lo publico creyendo ingénuamente que les va a funcionar a todos, y luego recibo unos cuantos reportes de errores. A veces son solo detalles, otras veces burradas importantes que no debieron publicarse nunca. Estos errores pueden hacerme perder muchos usuarios, ya que se pueden llevar una muy mala primera imágen y no volver. Pero más allá de eso creo que tengo que hacer una consideración especial, principalmente para con PSeInt: los usuarios son estudiantes que recién empiezan, y el software promete facilitarles el aprendizaje, pero el estudiante por su inexperiencia podría no distinguir un error en la interpretación de un error en su algoritmo. Esto ocurre, y atenta directamente contra el objetivo del proyecto, confunde al estudiante, va en una dirección perfectamente opuesta. Y entonces es doblemente preocupante. Por eso, hace un tiempo empecé a construir de a poco un sistema muy muy básico de testing automático para el núcleo del intérprete, y de eso habla este artículo.

Sobre medios y objetivos

¿Qué guía el desarrollo de un proyecto de software libre? Esta es para mí una pregunta muy interesante, donde hay muchas respuestas válidas. Con ella apunto a analizar cómo se decide hacia dónde debe ir el futuro de un proyecto, cuáles son sus objetivos a corto, mediano y largo plazo, en qué aspectos del proyecto se deben centrar los mayores esfuerzos, o cómo descubrir los puntos fuertes y débiles del mismo, entre otras cosas. En general se distinguen muy fácilmente los casos extremos. Por un lado, proyectos respaldados por grandes organizaciones que toman decisiones en grupo, luego de discusiones (que pueden ser formales y protocolares, o simples encuentros en una sala de chat o mediante envío de mails informales en listas dedicadas). Estos proyectos suelen tener una buena estructura jerárquica, objetivos claros en varios frentes a largo plazo bien documentados, a veces intereses políticos, etc. Por otro lado están los proyectos pequeños, que empiezan una o unas pocas personas, y que básicamente suelen seguir los caprichos de esas pocas personas, o guiarse por sus necesidades e intereses particulares. En el medio de todo esto, está la gran mayoría de los proyectos, y hay tantas y tan diversas variantes que no se me ocurre ni cómo agruparlas.

SourceForge, cada día mejor

Desde que comencé a publicar mis proyectos de software libre utilizo SourceForge. Allá por el 2004 cuando decidí "colgar" PSeInt en algún lugar de la web, la gente de la lista de mails de gleducar me sugirió SourceForge, y dado que yo no conocía casi nada al respecto, acepté la sugerencia. Desde entonces y hasta el día de hoy, mis proyectos se han alojado exclusivamente allí, y después de varios años de utilizar sus servicios puedo sacar algunas conclusiones.

Para empezar, tuvo sus puntos flojos en algunas ocasiones. Hace un tiempo solía tener problemas con algunos mirrors que en combinación con ciertos navegadores me dejaban a veces las descargas incompletas. En otros momentos el acceso al sitio era bastante lento. Las interfaces para realizar algunas tareas solían ser tediosas. Pero todo eso fue cambiando, a veces de a poco, a veces de golpe, y mantener mi confianza en este servicio cuando aparecieron alternativas muy prometedoras y populares (como pueden ser google code o github), está pagando con creces.

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.