Si hemos programado en Windows pero estamos interesados en la programación en Linux, estos consejos resultan especialmente útiles para cambiar algunas de las ideas y minimizar el choque ocasionado por el cambio de cultura cuando encontramos diferentes ideas y formas de pensar.

EVALUAR CADA ALTERNATIVA DISPONIBLE

A diferencia de la Interfaz de Programación de Aplicaciones (API) unificada en Windows que provee a los programadores con un único método para alcanzar un cierto objetivo, Linux provee diversas formas de alcanzar el mismo objetivo. Por ejemplo hay una variedad de cajas de herramientas (toolkits) de abstracción de la Interfaz Gráfica de Usuario (GUI), siendo las más importantes QT y GTK para escribir programas de Interfaz Gráfica de Usuario. Además, no se necesita elegir entre C o C++.

Hay muchas opciones para programar, incluyendo la escritura de una serie de comandos en un archivo de texto para el intérprete de comandos (shell scripting), Perl, Python y PHP. Así que no siempre hay que tener una idea fija de que se necesita aprender del modo “difícil”. No hay que abrumarse con las opciones. Sólo hay que ser consciente de ellas y tomar aquellas herramientas y técnicas con las que nos sintamos mejor.

LOS IDEs NO SON NECESARIAMENTE MÁS PRODUCTIVOS

Los programadores que han utilizado extensamente el Visual Studio de Microsoft para realizar sus desarrollos posiblemente se sientan incómodos al adaptarse a la manera en que se hacen las cosas en Linux. Aunque hay algunos Entornos Integrados de Desarrollo (IDEs, por sus siglas en inglés) bastante decentes en Linux, incluyendo a Kdevelop, Anjuta, Eclipse, ZendStudio y netBeans pudiéramos encontrar que utilizando un editor de texto y creando un archivo de descripción (make file, en inglés) sea una mejor idea a largo plazo. Cuando desarrollamos aplicaciones de Software Libre, posiblemente no queramos atar el desarrollo a una plataforma o a un Entorno Integrado de Desarrollo específicos, teniendo en cuenta que nuestro código será compartido y que otros programadores pudieran contribuir en el proyecto. A pesar de que los Entornos Integrados de Desarrollo no son una mala idea, posiblemente encontremos que al desarrollar proyectos más pequeños utilizando un editor de texto simple y un archivo de descripción sea una mejor idea.

NO BUSCAR CARACTERÍSTICAS ESPECÍFICAS DE UNA DISTRIBUCIÓN

Pudiera sorprender a muchos programadores de Windows saber que prácticamente se puede no hacer supuestos de la configuración por defecto de Linux en la máquina del usuario final. Diferentes distribuciones usan diferentes ubicaciones de archivos de configuración y ajustes. A menos de que estemos escribiendo una utilidad de configuración del sistema para una distribución en particular, no hay que hacer supuestos específicos de una distribución. De igual modo nunca hay que forzar a los usuarios a que trabajen como un administrador, a menos de que el propósito exclusivo de la aplicación sea el de modificar ajustes específicos del sistema.

NO MODIFICAR NI TRATAR DE MODIFICAR ARCHIVOS DEL SISTEMA.

Además de no ser una buena práctica de programación, no se puede asumir que determinado archivo de sistema existe en la máquina del usuario final (debido a diferencias específicas de la distribución). Tampoco podemos modificar archivos de sistema como un usuario “normal” (sin los privilegios necesarios) y no se supone que una aplicación normal de productividad sea ejecutada como administrador. En la mayoría de los casos, encontraremos que apenas tenemos alguna razón buena para tocar archivos específicos.

SER VISUALMENTE CONSISTENTE

Los programadores de la Interfaz Gráfica de Usuario, especialmente programadores de GTK y QT, necesitan entender que estas bibliotecas son bastante modificables (el usuario final puede modificar la apariencia visual de la Interfaz Gráfica de Usuario en casi cualquier forma posible). Por lo tanto, hay que evitar usar fuentes (de letra) o colores específicos en nuestra Interfaz Gráfica de Usuario. No es necesario. No hay que forzar al usuario final a que instale alguna fuente (de letra) particular en su sistema. Hay que dejar el despliegue visual de la aplicación exclusivamente a la biblioteca de la Interfaz Gráfica de Usuario que utilizamos. A menos de que estemos escribiendo un procesador de palabras casi nunca requeriremos manejar fuentes (de letra) en el código de nuestra aplicación.

ESTAR PREPARADOS PARA REALIZAR ALGO DE INVESTIGACIÓN

Linux no viene con una herramienta parecida al MSDN que nos proporcione documentación para cada herramienta de programación individual o para cada Interfaz de Programación de Aplicaciones que se encuentre disponible allá fuera. Esto no es práctico debido a que Linux no es desarrollado por una sola compañía. La mayoría de las veces si estamos utilizando bibliotecas de terceros, podremos encontrar documentación (ya sea a través de una descarga o en línea) en el sitio en Internet oficial del encargado de la biblioteca. También hay que estar conscientes de que muchas bibliotecas vienen con documentación incompleta o sin ella. Posiblemente tengamos que buscar código de muestra o hasta archivos de cabecera para aprender más acerca de una biblioteca en particular. Lo bueno es que probablemente no nos topemos con esta situación con la mayoría de las bibliotecas populares de terceros, aunque siempre es bueno estar preparados (por si acaso).

NO EMPAQUETAR DEPENDENCIAS

Cuando estamos creando paquetes que pueden ser distribuidos no hay que incluir dependencias junto con nuestra tarball (Bola de Alquitrán, paquete de archivos creados con la utilidad Unix tar). Sólo hay que incluir el código fuente y ofrecer instrucciones de compilación (entre más genéricas, mejor). También hay que mencionar las dependencias que son requeridas en los archivos LÉEME (README) o INSTALACÍON (INSTALL) y en nuestro sitio en Internet.

Ya que la mayoría de las distribuciones Linux poseen sus propios sistemas de gestión de paquetes (y si nuestra aplicación es lo suficientemente buena, posiblemente pueda ser incluida en el depósito de paquetes oficial), debemos de dejar el manejo de las dependencias al usuario final que compila nuestro programa en forma manual o al encargado del paquete de la distribución que envía nuestra aplicación como parte de su paquete.

Puesto que toda distribución Linux tiene una forma distinta de administrar las dependencias, no hay que intervenir con ellas creando una rutina de instalación que intente ser inteligente e instale otras bibliotecas. Aparte de crear problemas con las versiones, resulta tedioso y engorroso incluir dependencias con el programa.

También hay que probar y mantener las dependencias al mínimo, especialmente si nuestro programa tiende a usar bibliotecas exóticas de terceros.