Antes de ayer leo la noticia de que Amazon va a realizar un concurso sobre la creación de aplicaciones que usen los servicios web de Amazon.
El premio para el que gane serán 100.000 $, para participar sólo es necesario rellenar el formulario online y asegurarse de que se cumplen las condiciones mencionadas.
(Amazon Web Services Start-Up Challenge)
(Vía pensamientos ágiles)
No sé si lo sabéis, pero la máquina virtual de Sun es como Excel y de números sabe lo justo. Por eso, si en vuestros proyectos estáis utilizando valores de tipo double la estáis cagando, deberíais utilizar BigDecimal, que tiene más precisión y no comete errores de bulto al multiplicar 141’48 por 100 y cosas así.
Imaginemos el siguiente código:
int total = 5642; String valor = "878"; Math.rint ((Double.parseDouble (valor) * 100 / total) * 100) / 100;
Lo que hace este código es calcular qué porcentaje sobre 100 representa valor sobre total y redondear el resultado a 2 decimales. Es el ejemplo típico que encontraréis si buscáis cómo redondear.
Nos quedaría algo como esto una vez utilizada la nueva clase:
int total = 5642; String valor = "878"; (new BigDecimal (valor).multiply (new BigDecimal (100)).divide ( new BigDecimal (total), 2, BigDecimal.ROUND_HALF_EVEN)).doubleValue ();
Multiplicamos valor por 100 y dividimos por total, con 2 decimales (escala) con redondeo. Aunque aún podemos ser un pelín más exactos:
int total = 5642;
String valor = "878";
(new BigDecimal (valor).multiply (new BigDecimal ("100")).divide (
new BigDecimal (String.valueOf (total)), 2,
BigDecimal.ROUND_HALF_EVEN)).doubleValue ();
Ver explicación de porqué utilizar String en lugar de valores númericos al crear un BigDecimal
Tranquilos, sólo tendréis que revisar todos los programas que hayáis realizado desde el principio de los tiempos. No me odiéis a mí, sólo soy el mensajero.
Empecemos con algo lúdico-festivo:
Juanito fue contratado para pintar una carretera. El primer día pintó 100 km, el segundo 70 y el tercero 30. Su jefe, preocupado por esta alarmante bajada en su rendimiento le preguntó qué le pasaba, a lo que Juanito le contestó: “Es que el cubo de pintura cada vez me queda más lejos”
El rendimiento de un programa es, a grosso modo, lo que tarda en realizar su cometido. Es, de todas las métricas de calidad, una de las más difíciles de evaluar para mí. No solemos disponer de ejemplos lo suficientemente grandes, en ocasiones el problema aparece en una librería de terceros o, simplemente, se escapa de nuestro control (hasta que aparece). Lo que suele ser común en todos los casos es el mal uso de los tipos String (o similar), y es que en todos los lenguajes que conozco el tratamiento de los String es una mierda (bueno, en realidad suele estar entre una puta mierda y una putísima mierda).
Os expongo como ejemplo lo que me ha pasado con un proyecto recientemente. Consistía en generar unos ficherucos y enviarlos a un servidor vía HTTP. No problem. Los ficheros con los que probamos funcionaban a las mil maravillas y el proyecto pasó a pilotaje dividido en 2 partes: la generación y el envío. Cuando quisieron hacer una prueba enviando datos de un mes (en lugar de un día), aquello explotó. Revisando toda la parte de generación solventamos el problema y pasó de tardar 8 horas a 15 segundos, ¡¡cambiando sólo 3 líneas de código!!. La cosa siguió funcionando hasta la semana pasada, en que empezaron a fallar ficheros de 75 y 40 megas respectivamente, ahora en la parte de envío (solventado el jueves :)).
Éste es un tema para hablar largo y tendido, porque ejemplos hay miles y creo que todos los que hayamos programado habremos sufrido estas pérdidas, en principio inexplicables. Y, además, está relacionado con algo de lo que hablaré dentro de poco (espero): trampear los límites.
Siendo éste un blog de programación, no estaría de más ir definiendo algunos de los conceptos de esta ciencia que algunos convierten en auténtico arte. Y uno de los términos más importantes (y ambiguos) es el de abstracción. No la abstracción de mirar por la ventana, evidentemente. He rebuscado en mis apuntes de la carrera por dar una definición formal y que no sea copiada de la Wikipedia (Abstracción, programación orientada a objetos, aunque es un concepto válido para cualquier tipo de programación).
La abstracción nos permite simplificar el análisis y resolución de un problema separando las características que son relevantes de aquéllas que no lo son. La relevancia dependerá fuertemente del contexto. Un ejemplo típico de abstracción es una jerarquía de objetos determinada por sus características comunes (mamíferos -> primates -> humanos) (…)
Aunque la abstracción es un concepto general aplicable a cualquier campo, nosotros estamos interesados en la abstracción que proporciona un lenguaje de programación. En este sentido, la aportación más importante ha sido el desarrollo de los lenguajes de alto nivel, que nos permiten utilizar ciertas construcciones de alto nivel en lugar de una secuencia de instrucciones máquina.
Personalmente, siempre he definido la abstracción como la capacidad de, viendo un jarrón, ver también todo el proceso de creación del jarrón; y viceversa. Cambiad “jarrón” por programa y “proceso” por código y tenéis el concepto.
En este mundo que está tan de moda poner nombres un tanto raritos a los niños, pueden surgir problemas como este:
PD: Seguramente ya lo hayáis visto en muchos otros sitios, pero es que la tira es genial.