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.

"The Art of Unix Programming" es un libro de Eric S. Raymond. A quince años de haber sido escrito considero que ha envejecido bien. Todo el contenido hace que el título cobre sentido: programar en Unix es nada menos que un Arte.

Es éticamente mejor usar software libre (y en nuestro caso desarrollarlo también), porque la cultura de compartir y ayudar a los demás, propia de la esencia en la que surge el software libre, es 100% compatible con nuestros valores: Nuestro legado es lo que hacemos por otros, no lo que hacemos por nosotros ; Somos una tribu; cuidamos, valoramos y desarrollamos a todos nuestros miembros.