¿Qué es NotABug?

NotABug o NotABug.org es una plataforma que permite gestionar repositorios de código con Git. La plataforma utiliza un programa llamado Gogs, que es software libre, lo que permite que pueda ser instalado localmente o en un servidor.

Entre sus características destacan las siguientes:

  • Alojamiento para proyectos públicos y privados.
  • Repositorios Git, Wiki y sistema de seguimiento de errores.
  • Privacidad para los usuarios y visitantes: funciona también en la red Tor y tiene todo el código JavaScript alojado en su propio servidor.
  • Interfaz gráfica sencilla y muy rápida.
  • Alojamiento gratuito para proyectos de software libre.

Estoy registrado en NotABug desde el 26 de julio de 2016, y es la única plataforma que utilizo actualmente para desarrollar mis propios proyectos. También he colaborado con proyectos interesantes en NotABug como Awesome gamedev, LibreVideoJS, LibreVideoJS-wp, Résumér, mkblog.sh y la página web de la comunidad Peer. Puedes encontrar más información sobre los proyectos en los que estoy involucrado visitando mi perfil de NotABug.

Hasta ahora NotABug es la mejor plataforma que conozco para desarrollar programas usando Git. Es fácil de usar y de realizar proyectos colaborativos. Además, la interfaz gráfica es muy sencilla y ágil, a diferencia de otras alternativas como Gitlab.

Desarrolladores ingratos

cr1 cr2

Nunca me había pasado que alguien despreciara los errores que le señalara ni rechazara mis contribuciones a pesar de ser correctas. Anteriormente, incluso cuando me equivoqué al hacer una corrección, siempre me respondieron más amablemente.

En particular, a dicho personaje le señalé un error y pasó de él excusándose diciendo que se trataba de un componente que usa el proyecto pero no forma parte de él. Esto es una escusa pésima, ya que el error afecta a su proyecto. En contraposición, los desarrollares del fork de gogs para notabug.org y Unknown Horizons (por poner ejemplos que conozco de primera mano) hacen lo correcto: han sido notificados varios errores de los que no tenían la culpa directamente, pero hasta que no los corrigieron colaborando con el otro proyecto o actualizaron a una versión del software sin los errores, no cerraron los tiques (también llamado issues). Es absurdo ignorar los problemas por pequeños que sean, y más cuando te afectan, pues forman parte de las dependencias de tu proyecto. Al idiota que os he mencionado le arreglé el error a dicho proyecto (aunque el individuo cerró la incidencia antes de que lo hiciera).

Al individuo, también le avisé en otro tique de que la licencia Creative Commons no sirve para el código y le insté a que usara una que tuviera validez para el software. La licencia Creative Commons sirve para el contenido de un libro, sitio web, etc., no para el código fuente.

Lo más extraño fue que aún habiéndole dicho esto mostrándole las explicaciones de los propios creadores de la licencia, volvió a ignorar el tique irresponsablemente. En resumen, pasó de los dos errores que le mostré y me contestó con desprecio. Exactamente lo contrario a lo que estoy acostumbrado y lo que me ha pasado con otros equipos de desarrollo.

En el equipo de desarrollo de Unknown Horizons del que formo parte siempre nos agradamos de que alguien contribuya a nuestro proyecto y le agradecemos su trabajo, aceptamos con gusto correcciones de nuestros errores, les aclaramos cosas que no entienden y ayudamos a los colaboradores a terminar las mejoras que han empezado. Siempre estamos agradecidos y les respondemos amablemente porque son nuestros amigos, ya que nos ayudan recibiendo poco o nada a cambio.

Si por el contrario, una persona que colabora con un repositorio se encuentra con un equipo de desarrolladores que son incapaces de admitir sus errores y que responden altivamente, siente que no tiene sentido perder el tiempo en volver a ayudar a personas con el síndrome de Estocolmo que van a despreciar e insultar su buena voluntad.

No escribáis espacios a final de línea

Este artículo va dirigido a programadores y a personas que editan texto sin formato. Los espacios a final de línea son algo molesto e inútil cuando la gente los pone sin pensar. Muchas veces porque no utilizan un buen editor que les señale dónde hay espacios a final de línea.

Textos a final de línea resaltados en Vim
Así veo yo los espacios a final de línea

A continuación, expongo algunas de las razones por las que son un problema:

  • Hacen que el tamaño de los archivos sea mayor.
  • Hacen difícil la navegación por el código. Por ejemplo, cuando pulsas la tecla Fin, lo que esperas es llegar a la última letra de la línea. Si el código o el texto que estás editando tiene caracteres al final de línea, puedes acabar varios espacios detrás del texto que quieres editar.
  • Pueden ocasionar errores muy difíciles de detectar. Por ejemplo, en Python,
    print('Hola\
        Mundo')
    

produce un error.

  File "", line 1
      print('Hola\
                ^
  SyntaxError: EOL while scanning string literal
  • Si introduces espacios a final de línea, estás cambiando el contenido del fichero innecesariamente. En la mayoría de sistemas de control de versiones esto es algo muy difícil de ver y puede generar problemas.

La mayoría de editores de texto permiten solucionar este problema. Si utilizas Vim, puedes eliminar todos los espacios a final de línea de un fichero con la siguiente orden: :%s/\s\+$//e.

Probablemente haya alguna razón más para no usar espacios de línea que tú conozcas y yo no conozca. Dímela en los comentarios para que la añada a la lista de razones de este artículo y cuéntame los problemas que te han ocasionado los espacios al final de línea.

¿Qué es Python?

Python es el nombre de un lenguaje de programación muy popular. Te recomiendo leer estas diapositivas si quieres conocer las características de este lenguaje.

Si no tienes un programa capaz de leer el formato .odp, puedes ver las diapositivas en formato .pdf aquí.