R3b3l10Nn

Últimamente me ha dado por realizar pequeñas prácticas que hace mucho realicé como parte de mi descubrimiento en algunos lenguajes de programación. He leído mucho respecto a los sabores y performance de cada lenguaje, cuyos argumentos no trataré por ser sumamente objetivos. Algunos valoran la facilidad, otros la poca verborrea que facilitan la construcción de complejos componentes de software. A continuación expongo los códigos comparados y las salidas en terminal. Características de la computadora. CPU: 2 CPUs con 2 Cores AMD Turion(tm) 64 X2 Mobile Technology TL-60 a 1800.000 Mhz. Memoria RAM: 3.7G Sistema Operativo: Fedora release 20 (Heisenbug) Versiones de compiladores/interpretes Python: 2.7 C: gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) Java: 1.7 hotspot a 64 bits Ruby: 2.0 Go: 1.4.2 64 bits Python for my_range in range(1,90000000): print (my_range) Tiempo de ejecución real    10m24.691s ...

El tema del monitoreo es por sí solo vasto y exige cierto nivel de especialización y comprensión. Como todas las soluciones de software , el establecimiento de una arquitectura y elección de productos conlleva un conocimiento profundo del las necesidades y las mejores opciones disponibles, no solo en términos de costos, sino de prestaciones y flexibilidad de los productos que están en el mercado. No es cosa fácil establecer un flujo y tratamiento adecuado de las métricas recolectadas. En lo que mi experiencia acontece, éste rubro de las TI apenas se le da importancia, se mira como un gasto que no tiene retorno. Los profesionales lo entienden como la manera en detectar problemas en los ambientes productivos, pero que si se detectan vía registros, el problema está cuasi resuelto, por tanto, la necesidad de un sistema complejo de monitoreo no es necesario.  No estoy a favor de acumular datos y sólo mantenerlos por si llegasen a requerirse en algún punto, si l...