Una parte fundamental de hacer sistemas incluye la de hacer pruebas. ¿Parece obvio no? Sin pruebas no puedes garantizar que estás haciendo un buen trabajo. Si no pruebas lo que haces, ¿vas a esperar a que tu usuario lo pruebe, o sea básicamente a que lo use pensando que es producto terminado, y le explote en la cara?

¡Hablemos de DRY! O por qué repetirse es el peor trabajo del mundo En la mitología griega, Sísifo era un pobre sujeto que se veía condenado, por circunstancias que no vienen al caso, a realizar el peor trabajo del mundo: tenía que empujar una enorme piedra cuesta arriba de una ladera. Y siempre que llegaba a la cima, la piedra rodaba cuesta abajo y el desgraciado debía volver a empezar. Constante e interminablemente. Sin sentido, debía repetir el mismo exacto trabajo cada vez.

DevOps se ha vuelto todo un fenómeno en los ambientes de desarrollo de software. Casi una auténtica revolución. Aunque, como veremos, muchos de sus principios y prácticas llevan existiendo en la industria y en otras industrias por varias décadas, el haber integrado todo en esto que hoy conocemos como DevOps es lo que ha permitido a muchos equipos de TI lograr resultados en tiempos cada vez más exponenciales. Como se dijo, una auténtica revolución. Con este artículo terminamos la serie para hablar de DevOps en Podemos TI. Cerramos hablando ahora sí de cómo hemos ido aplicando todo esto...

DevOps se ha vuelto todo un fenómeno en los ambientes de desarrollo de software. Casi una auténtica revolución. Aunque, como veremos, muchos de sus principios y prácticas llevan existiendo en la industria y en otras industrias por varias décadas, el haber integrado todo en esto que hoy conocemos como DevOps es lo que ha permitido a muchos equipos de TI lograr resultados en tiempos cada vez más exponenciales. Como se dijo, una auténtica revolución. Con este artículo continuamos la serie para hablar de DevOps en Podemos TI. Ahora vamos a hablar un poco de cómo medir DevOps...

DevOps se ha vuelto todo un fenómeno en los ambientes de desarrollo de software. Casi una auténtica revolución. Aunque, como veremos, muchos de sus principios y prácticas llevan existiendo en la industria y en otras industrias por varias décadas, el haber integrado todo en esto que hoy conocemos como DevOps es lo que ha permitido a muchos equipos de TI lograr resultados en tiempos cada vez más exponenciales. Como se dijo, una auténtica revolución. Con este artículo comenzamos una pequeña serie, ¡la primera de este blog!, para hablar de DevOps en Podemos TI. Esta entrega sólo repasa los conceptos...

Un viejo dicho reza "somos lo que comemos"...

Si en un futuro lejano, un ser de otro planeta quisiera conocer nuestro mundo, le bastaría asomarse a nuestra basura.

Con ver cualquier depósito sabría todo sobre la humanidad: qué nos motiva, qué apreciamos, lo que amamos y cómo amamos, en qué creemos, cómo vestimos, en qué nos transportamos, qué nos quita la sed y qué comemos...

Así que también "somos lo que desechamos".

Hace un tiempo, describíamos la arquitectura de los sistemas que desarrollamos en Podemos. Nos enfocamos en describir la misma, una arquitectura de capas, con las clásicas Modelo, API e Interfaz. El post además habla de los límites que debe haber en el código que se coloque en cada uno.

De ese artículo podemos extraer también algunos puntos importantes.

Configurar una aplicación es la manera en que los programadores le damos al usuario capacidades para que el programa sea más potente por sí mismo, sin depender de tener que hacer más cambios y programarlos. Es, de entrada, la puerta con la que el usuario se puede empoderar para hacer un mejor uso de la información que el programa le entregará. Y por eso es una parte importante y esencial de un software bien implementado. Cuando se diseña un sistema, se tienen que tomar muchas decisiones, y hacerse muchas preguntas.

En la última entrada, hice alusión a que el debuggeo de un programa puede ser visto como una especie de juego de detectives, hay un crimen por resolver y pistas que deben llevar al origen de la falla, que luego se deberá resolver.

Resulta que en desarrollo de sistemas, las analogías de juegos abundan. Y un escenario donde también disfruto jugando es mientras sigo una metodología de trabajo en particular a la hora de estar programando.

Debuggear* es todo un arte.

De hecho casi todo en el desarrollo de software y sistemas es un arte. Al menos así lo vemos aquí.

El arte detrás de esto está en la parte creativa, en la parte donde creas algo que al usuario le resulta útil. E implica muchísimas habilidades que caen en el rango de 'artes'. Es un arte poder entender una necesidad y luego plasmarla en un software (empezando por la interfaz y terminando por la arquitectura, o al revés). Es un arte diseñarlo. Es un arte realizarlo.

Y también es un arte depurarlo.