El dragón en la luna

Cada día que pasa veo más y más información sobre Python y Ruby, y comentarios diciendo que PHP ya paso la historia, que ya no se debería de utilizar y hay cosas mejores disponibles.

Esto es normal, nada nuevo, el mundo tecnológico cambia aceleradamente y lo que es “cool” hoy es la cosa más obsoleta el día de mañana. Si estas en este mundo, ya estas preparado para estas cosas, y si sientes que el mundo se acaba, no eres un buen programador como dijeron en Cristalab sobre un tema similar.

Sin embargo, el mundo no es blanco y negro, y quisiera aclarar un par de puntos acerca de lo que significaría la muerte de PHP y el advenimiento de nuevas tecnologías.

En primer lugar, PHP no esta muerto ni agonizante. Que existan cosas mejores disponibles y más desarrolladores las utilicen no significa nada. PHP sigue estando disponible en una gran cantidad de servidores web a distintos precios. La diferencia es que ahora la mayor parte de estos servidores también soportan Python y Ruby, lo cual es una ventaja para los que están migrando a lo nuevo.

En segundo lugar, si todavía utilizas PHP no significa que te estas convirtiendo en una momia. PHP funciona, ha funcionado durante años, y no esta dejando de funcionar, simplemente están viniendo cosas mejores. A menos de que tengas un trabajo que te lo exija, lo único que pierdes al seguir utilizando PHP es la oportunidad de hacer las cosas de una manera más sencilla.

Mi recomendación personal es: si utilizas PHP de una manera cruda, insertando código en el html y donde cada una de tus páginas es un archivo pagina.php individual, necesitas migrar inmediatamente, debes de salir de ese mundo oscuro y hostil. Por el otro lado, si estas acostumbrado a trabajar con un framework, con mucho código preconstruido que hace feliz tu vida, es mejor que te tomes tu tiempo, explores las nuevas opciones y vayas encontrando nuevas herramientas que se adapten a tu estilo. Puedes tardarte un tiempo en hacerlo, no es una carrera, se trata de programar con las mejores herramientas que dispongas.

A mí en lo personal no me gusta ni Ruby on Rails ni Django, no me gusta la aproximación de escribe un comando y mira como mágicamente se hace la mitad de tu trabajo, pero al final terminaré haciendo lo mismo que he hecho con PHP, adaptar el lenguaje a mi estilo.

Y finalmente, una recomendación tan importante que si no la conoces todavía, no puedes considerarte un buen programador: sigue investigando y aprendiendo cosas nuevas, no te quedes estancado. HTML5, python, ruby y otros nombres bonitos que están sonando por la red son solamente puntos en tu lista de las cosas que tienes que investigar y evaluar.

No necesariamente tienes que aprender algo nuevo, basta con conocer las nuevas herramientas, ver que beneficios te traen y como puedes aprovecharlos. Si sientes que no te traerá nuevos beneficios, no es necesario que pases una semana leyendo tutoriales. Incluso si los beneficios existen, no necesitas leer todos los manuales que encuentres en la red, aprende a hacer lo que necesitas, y busca siempre algo nuevo que quisieras poder hacer.

Y cuando salga el próximo lenguaje de programación super cool que cambiara el mundo, nada cambiará, será lo mismo de nuevo.

Después de aproximadamente dos semanas de concentración total (y explotación) para poder terminar el proyecto en el que estaba trabajando (esta vez remunerado) finalmente estoy libre para recuperar mi vida.

Sinceramente ahorita no tengo nada de que escribir, he apagado todos los procesos mentales que no estuvieran relacionados con el proyecto y supervivencia (comer, dormir), e incluso algunos de estos últimos también han sido apagados (dormir).

A lo mejor soy un adicto a la programación, realmente di en el clavo con mi vocación, porque lo primero que quiero hacer en este momento es retomar el hilo de los proyectos que deje en el aire al iniciar el trabajo, principalmente MoonDragon. Hay otras cosas que quiero reorganizar con más calma, como mi página personal que la siento ya bastante obsoleta.

Pero lo que definitivamente más quiero hacer es pasar tiempo con mi novia preciosa, porque casi no la he visto últimamente.

A ver si me abunda el tiempo y escribo un poco más de todo lo que pienso hacer.

Una de las cosas más problemáticas al trabajar desarrollando software son los tiempos de entrega. Cuando eres joven y con poca experiencia, te sientes todo un superman y crees que puedes programar 1000 líneas de código por hora, que no necesitas comer ni dormir, y que el cansancio mental no es un impedimento para crear software. Luego vienen los atrasos, los clientes insatisfechos, la fatiga acumulada, el código mal hecho.

Una de las reglas de la sociedad en que vivimos es que todas nuestras acciones tienen consecuencias directas o indirectas sobre las personas que nos rodean. La razón por la que desarrollamos software la mayoría de las veces no es por pasatiempo, sino que para resolver las necesidades de un cliente. Los clientes están muy mal acostumbrados y no se dan cuenta que el desarrollo de software es un proceso complejo, y suelen solicitar soluciones milagrosas al instante para problemas críticos en sus negocios.

Muchas veces estamos tentados en caer en la compasión, arriesgándolo todo para satisfacer los caprichos ayudar a nuestros clientes. Pero en realidad, lo que estamos haciendo es brindarles un mal servicio y creando un producto de mala calidad, que en el peor de los casos puede perjudicar tanto a nuestro cliente como a nosotros mismos.

Es muy importante conocer adecuadamente cual es tu capacidad de trabajo, y la carga que puedes llevar. Existen limitaciones físicas que no puedes ignorar al momento de desarrollar, como la cantidad de palabras que puedes pueden teclear por minuto. El primer paso es darte cuenta de esto tú mismo, y el segundo es hacérselo ver a tu cliente.

Si el tiempo que te tomas en desarrollar un proyecto en específico es demasiado extenso y no te es rentable, entonces debes buscar las herramientas necesarias para acelerar el proceso. Algunas formas de agilizar tiempo es a través de frameworks, mejores equipos de trabajo, una programación más ordenada y reutilizable; sin embargo, ninguna de estas cosas solucionará magicamente tus necesidades y requieren tiempo para ser implementadas.

Escribo esto como una guía de consejos para mí mismo, para que mis experiencias anteriores no queden en el olvido y sirvan para mejorar en el futuro. Me hace recordar que empecé a desarrollar MoonDragon con el propósito de minimizar los tiempos de desarrollo y que ha funcionado, pero que todavía es largo el camino que queda por recorrer.

Para los que quieran comentar y dar sus sugerencias respecto los tiempos de desarrollo, son bienvenidos.

Hace relativamente poco tiempo que he empezado a utilizar Bazaar como sistema de control de versiones en lugar de CVS, tal y como lo mencione en este otro post , y con la reciente noticia de que bazaar se ha convertido en un proyecto GNU creo que vale la pena aprovechar para escribir algo en el blog hablar un poco sobre mis impresiones con el sistema.

Llevo ya casi un año de haber empezado a trabajar con los sistemas de control de versiones, desde que empecé a travesear en Sourceforge . Al principio no tenía idea de como funcionaban y tuve que pasar un par de días leyendo al respecto, y para bien o para mal, empecé con CVS. Me costo bastante adaptarme, habían muchas cosas que no eran intuitivas y cometí muchos errores, incluso varios meses después de haber empezado a usarlo.

Consideré la posibilidad de cambiarme a Subversion , pero las diferencias no me parecieron significativas como para eso. La primera vez que escuche sobre Bazaar me pareció que era solamente un sistema de control más que andaba por ahí, pero ya viéndolo con detenimiento me di cuenta que éste si aporta muchas cosas interesantes.

Creo que una de las cosas que más me gusto de Bazaar en un comienzo es que cada revisión guarda una copia de todos los archivos, estén modificados o no. CVS solía tratar cada archivo individualmente, y si no marcabas explícitamente que todos estaban relacionados, era imposible saber que revisión de X archivo era compatible con otro archivo Y. Sien embargo, esta no es la característica más importante de Bazaar y, si no me equivoco, Subversion también funciona de esta manera.

En donde se encuentra realmente el potencial de Bazaar es en su manejo de ramas o branchs. CVS y Subversion tienen sus maneras de utilizar ramas, pero siempre me pareció que crear una rama era una decisión muy importante que no se debía tomar a la ligera. Con Bazaar, las ramas son la forma ordinaria de trabajar, permitiendo e incluso fomentando a que cada desarrollador trabaje en su propia rama, e incluso tenga varias ramas a su disposición.

El orden dentro de un proyecto es probablemente el factor más importante para que este siga creciendo. La experimentación también es importante, un proyecto que deja de probar cosas nuevas esta condenado a desaparecer. Bazaar permite combinar las dos cosas, un desarrollador puede tener su propia rama experimental, en la que puede hacer y deshacer a su antojo con todas las ventajas de un VCS ordinario, como tener distintas revisiones, sin contaminar la rama principal de desarrollo que debe de mantenerse impecable.

La mezcla entre las ramas es un proceso muy delicado, no queremos que el trabajo de otros se pierda por un error de compatibilidad, y tampoco queremos perder la línea de los cambios que se han realizado. Bazaar trata de hacer este proceso lo más sencillo posible y lleva un control bastante estricto de las ramas que se han mezclado y los aportes que se han incluído. Hay muchos conflictos que siempre necesitarán asistencia humana para resolverse, pero hay que recordar que el software es una herramienta y no debe servir para hacer el trabajo en nuestro lugar.

Por el momento estoy bastante contento con este sistema de control de versiones, junto con el sistema de blueprints de Launchpad , me ha ayudado mucho con la organización y el avance de MoonDragon . Espero que Bazaar siempre siga mejorando, personalmente espero el día en el que su plugin para Eclipse sea estable y completamente funcional.

El mundo en que vivimos va cada vez más acelerado, y eso puede verse en todo tipo de situaciones en nuestra vida cotidiana. Uno de los paradigmas más comunes que encontramos el día de hoy es “velocidad vs calidad”, y desgraciadamente el ambiente nos presiona cada vez más a preferir la velocidad y pisotear vilmente la calidad.

El mundo del software sufre también con esto, y para los estudiantes o los desarrolladores independientes puede llegar a convertirse en un infierno. Los tiempos de entrega cortos, la falta de preparación del proyecto y el código improvisado son el pan de cada día, y para aquellos que quieren hacer las cosas bien ( ¡incluso los maestros! ) la vida se convierte en un calvario insufrible contra las personas que quieren que sus cosas estén ¡YA!, como por arte de magia.

Hace poco leía en Cristalab como la mayoría de los cms populares modernos son una verdadera vergüenza en términos de codificación. Pero la gente se conforma con que funcionen, y sí es cierto que la gente común y corriente no sabe nada de programación, ¡pero los desarrolladores del software se conforman con que la gente este contenta! Y luego eso nos lleva a los verdaderos fiascos como Windows Vista.

Y es que de la calidad del código muchas veces depende la seguridad del software, la adaptabilidad a situaciones nuevas o imprevistas, la portabilidad a diversos entornos y la curva de aprendizaje para otros desarrolladores. Muchas veces limpiar tu código es como limpiar tu cuarto, sabes que debes hacerlo y que vivirías mejor si lo haces pero crees que esta tan desordenado que no hay forma de comenzar, o que simplemente volverá a quedar igual. Sin embargo, si te acostumbras a un ambiente limpio luego la limpieza vendrá por si sola.

Es posible que MoonDragon sea feo gráficamente carezca de diseño gráfico, tenga por el momento poca funcionalidad e interfaces incompletas, pero su código esta ordenado y correctamente documentado, además de que sus bases están bastante bien sentadas en la programación de objetos (si es cierto que hay unos objetos que no están definidos correctamente , pero ya los corregiré, lo prometo ).

Más adelante me plantearé seriamente eso de limpiar el cuarto…