Cómo hacer una aplicación que soporte precios con decimales sin errores

En Programación      14 comentarios

Sep
8

Hace algunos días comentaba, en un artículo muy básico, cuáles eran las operaciones matemáticas o fórmulas para sacar y extraer el IVA de los importes. Sin embargo, manipular decimales, cuando se trata de precios, requiere seguir una serie de pautas muy importantes si no queremos encontrarnos con situaciones como la de la imagen.

Y no me refiero a usar simplemente el tipo de datos apropiado, sino a como gestionar los precios y manipularlos durante todo el flujo de la aplicación si queremos que estos sean coherentes durante todo su ciclo de vida: alta de productos, compras, descuentos, impuestos, etc.

La visión del artículo es funcional: hay poco código, pocos tecnicismos y muchas recomendaciones de negocio, principalmente. Si quieres literatura técnica, puedes ir directamente al final, donde hay algunos buenos enlaces y un FAQ propio. Mi idea no es ser un experto en coma flotante, si no cómo hacer una aplicación donde se trabaja con precios de una manera robusta y a prueba de errores de cálculo.

1 Tipo de datos

Olvídate de float y long. Solamente con que hagas un

System.out.println(0.1F+0.2F) // 0.30000000447034836

verás que contiene un minúsculo margen de error en la parte decimal. Es posible que desaparezca si redondeas, pero puede romper realmente tu aplicación. Ojo, esto no es un bug de Java, viene determinado por la naturaleza del tipo de datos decimal cuando es transformado a binario. Así que esto también sucede en tu base de datos si usas float (o double):

CREATE TABLE prueba (chungo float, suelto double);
INSERT INTO prueba VALUES (0.1, 0.1);
INSERT INTO prueba VALUES (0.2, 0.2);
SELECT SUM(chungo), SUM(suelto) FROM prueba;

| 0.30000000447034836 | 0.30000000000000004 |

La explicación de porqué sucede esto la tienes abajo en el FAQ.

Solución:

• Usa en tus clases de dominio BigDecimal, el cual no tiene este problema. Es tratado como un número entero que contiene simplemente una coma en cierta posición, por lo que cualquier operación decimal realizada es exacta. El único problema es que los cálculos son más lentos (las operaciones las realiza la clase BigDecimal dentro de la JVM) que con primitivos int, long, float y double (las operaciones son realizadas por la CPU). Pero eso es algo con lo que podemos -y debemos- vivir.
• Usa en tu base de datos el tipo DECIMAL(M, D). Donde M es el tamaño del número (parte entera y decimal) y D es el tamaño de la parte decimal solo. Así un tipo decimal(15, 2) nos permitirá guardar hasta 9999999999999.99

En Java no existe un tipo de datos primitivo para BigDecimal, por lo que todas las operaciones matemáticas realizadas con este tipo se deben hacer mediante métodos, con cosas tan barrocas como esta:

System.out.println(new BigDecimal("0.2").add(new BigDecimal("0.1"))); // -> 0.3

En Groovy no es necesario, ya que todas las operaciones en las que se ve involucrado un número decimal (float, double o BigDecimal) son realizadas con BigDecimal automáticamente.

// Código Groovy, decimales son BigDecimal por defecto
println(0.1 + 0.2) // -> 0.3

2 Como guardar los precios de los productos antes de venderlos

Pese a que en nuestra aplicación siempre vamos a mostrar todos los importes con solo dos decimales (redondeando además), nuestro modelo de datos debe guardar el importe de los productos siempre sin impuestos (sin IVA en España) y con tres decimales. Y el importe con IVA debe ser siempre calculado al extraerlo de base de datos. La pregunta es ¿pero para qué necesito tres decimales, si solo voy a mostrar dos? Veamos los casos posibles:

Que el administrador introduzca el precio del producto sin IVA directamente.
En este caso solo permitimos que teclee dos decimales, aunque guardemos luego tres (es decir, el tercer decimal será siempre 0). Ejemplo: el administrador introduce “11,95€”, por lo que guardamos 11.950. Para mostrar el precio en la web, simplemente leemos el importe sin IVA de base de datos y calculamos el importe con IVA: “11,950€ + IVA 21% = 14,46€” (el cálculo sería 11.95 * 1.21 = 14.4595, que redondeando a dos decimales da 14.46)

Que el administrador introduzca el precio del producto con IVA incluido.
¿Y por qué querría hacer tal cosa? Pues simplemente para asegurarse de que el producto se vende al público con un precio que a él le parece apropiado, por ejemplo “108,99€ IVA incluido”, y desea que la obtención de la base imponible sea calculada por el sistema (o sea nosotros). En este caso, nuestra aplicación recibe el número “108,99″ y después le quita el IVA (para un IVA del 21% lo divide entre 1.21) y lo guarda en base de datos. Aquí es donde puede haber un problema: el sistema debría poder volver a aplicar el IVA al importe guardado en base de datos y obtener exactamente el mismo importe que el administrador había introducido. Y si guardamos el importe sin IVA con solo dos decimales, al volvérselo a añadir, el resultado puede ser distinto. Veamos un ejemplo (haciendo los cálculos con todos los decimales que disponemos, pero redondeando siempre a dos decimales al mostrarlos): el administrador desea que el importe de su producto sea de “108,99€ IVA incluido”.

Si usamos en base de datos dos decimales con tipo DECIMAL(15, 2), el resultado es incorrecto:

• El administrador introduce “108,99€” IVA incluido.
• Le quitamos el IVA: 108.99 / 1.21 = 90.07 y lo guardamos en base de datos con dos decimales.
• Leemos de base de datos y le añadimos el IVA: 90.07 * 1.21 = 108.9847
• Mostramos ”90,07€ + IVA 21% = 108,98€” -> INCORRECTO! no coincide con los 108.99 del importe inicial.

Pero si usamos en base de datos tres decimales con tipo DECIMAL(16, 3) es correcto:

• El administrador introduce “108,99€” IVA incluido.
• Le quitamos el IVA: 108.99 / 1.21 = 90.074 y lo guardamos en base de datos con tres decimales.
• Leemos de base de datos y le añadimos el IVA: 90.074 * 1.21 = 108.98954
• Mostramos ”90,07€ + IVA 21% = 108,99€” -> CORRECTO! si coincide con el importe inicial.

Resumen: para conservar un número que tiene N decimales al multiplicarlo y dividirlo por otro, debemos usar N+1 decimales. En nuestro caso, al ser precios en euros, nuestros números tienen dos decimales, por lo que si queremos quitar el IVA y volvérselo añadir, y obtener el mismo número, debemos usar tres decimales: DECIMAL(15, 3)

3 Como guardar los precios de las compras

Al comprar un producto se deben hacer dos cosas:

1. Primero se realizan todos los cálculos y después se guardan en base de datos. Esto incluye el IVA (y descuentos aplicados), tanto el tipo (por ejemplo 21% para el IVA) como la cantidad. El hecho de guardar todos los importes parciales y tipos usados nos previene ante posibles cambios de IVA y nos evita hacer cálculos cada vez que necesitemos generar una factura o informe. Y también nos ayuda a hacer sumatorios en base de datos de estos parciales. Por ejemplo, si necesitamos saber el importe total de todo el IVA cobrado a todos los usuarios en sus compras.
2. Todos los importes guardados tendrán solamente DOS decimales y serán los importes que han sido mostrados al usuario (y, por lo tanto, previamente redondeados). Esto debe ser así porque no importa que el cálculo del total a cobrar al usuario haya sido 85.431€, si al usuario le estamos mostrando “85,43€”, se le deben cobrar 85,43€ en la pasarela de pago y se debe almacenar en la base de datos 85.43. Si no se hiciera así y guardásemos 85.431, una suma de todas las compras del usuario podría dar un importe superior al acumular decimales en todas las compras. Si se almacena el número ya redondeado y con dos decimales, esto nunca sucede.

Siguiendo el ejemplo anterior: un usuario compra un libro por “90,07€” (que, recordemos, se guarda en base de datos con tres decimales como 90.074). En nuestra tabla de compras debemos guardar una foto de todos los importes en ese preciso momento con dos decimales ya redondeados:

 base imponible = 90.07    // El importe del producto con 3 decimales redondeado a 2 decimales
 tipo IVA       = 0.21     // Constante configurable
 importe final  = 108.99   // 90.074 * 1.21 = 108.98954 redondeado a 2 decimales
 IVA            = 18.92    // 108.99 - 90.07 no necesita redondear

Ahora podemos obtener las compras de un usuario y hacer sumas totales con dos decimales sin temor a perder exactitud, porque una vez cobrado el importe, ya no hace falta conservar más decimales: los precios se quedan congelados en la tabla para saber que se cobró, que IVA se aplicó (cantidad y tipo), etc. En cualquier momento podemos volver a generar una factura o extraer un informe con esta información, sin necesidad de hacer nuevos cálculos, pues ya han sido precalculados y cobrados, por lo que son inmutables.

Resumen

Siguiendo estas tres reglas protegeremos nuestra aplicación:

1. Evitando datos incorrectos producidos por la inexactitud de los tipos en float y double gracias al uso de BigDecimal en nuestras clases de dominio y al tipo DECIMAL(M, D) en nuestra base de datos.
2. Para que al extraer y después añadir el IVA al precio de un producto obtengamos después exactamente el mismo importe debemos guardar en base de datos los importes con tres decimales (regla de conservación de importes: para N decimales, guadar N+1)
3. Para poder obtener una factura o informe con exactamente los mismos datos que han sido cobrados en su momento al usuario, no tenemos que usar tres decimales: debemos guardar todos los importes parciales y totales ya calculados, pero con dos decimales. Tambien hay que guardar el tipo de IVA utilizado (18, 21, etc).

Errores comunes

Fórmulas para el IVA

En Programación      1 comentario

Sep
1

Hoy acaba de subir el IVA, así que para refrescar un poco nuestras matemáticas básicas, vamos a ver que operaciones podemos hacer con él. El lenguaje de programación es Groovy, pero con algunos cambios es compatible en Java.

Obtener el IVA de un producto

public static BigDecimal calcIva(BigDecimal p, BigDecimal IVA)   { return p * (IVA/100) }

assert calcIva(100, 21) == 21

Obtener el precio con IVA de un producto que no tiene IVA

public static BigDecimal sumaIva(BigDecimal p, BigDecimal IVA)   { return p * (1+(IVA/100)) }

assert sumaIva(100, 21) == 121

Dado el precio con IVA de un producto, averiguar su valor sin IVA

public static BigDecimal quitaIva(BigDecimal p, BigDecimal IVA)  { return p / (1+(IVA/100))  }

assert quitaIva(121, 21) == 100

Obtener solo el IVA de un producto con IVA

public static BigDecimal extraeIva(BigDecimal p, BigDecimal IVA) { return p / (1+(100/IVA))  }

assert extraeIva(121, 21) == 21

Supongamos, que es mucho suponer, que sube el IVA del 18% al 21%. Y que el comercio decide “asumir” esta subida, bajando el importe del producto para que, al aplicar el nuevo IVA, tenga el mismo precio final.

public static BigDecimal asumeIva(BigDecimal p, BigDecimal IVA, BigDecimal IVA_NUEVO) {
    return quitaIva(sumaIva(p, IVA), IVA_NUEVO)
}

println asumeIva(100, 18, 21) // devuelve 97.520661157

Es decir, que si antes nuestro producto de 100€ lo vendíamos por 118€ con IVA al 18%, ahora para seguir vendiéndolo a 118€ pero con el IVA al 21% debemos rebajar la base imponible a 97.52€

El uso de BigDecimal en las operaciones no es fortuito. En otro post un poco más avanzado (este ha sido muy básico) explicaremos como guardar y operar correctamente precios con decimales, donde se verá que los Float y Double no son precisamente la mejor opción, y BigDecimal es el único tipo que nos ofrece seguridad a la hora de hacer operaciones matemáticas con importes.

Usando BitSet para guardar ids

En Programación      1 comentario

Sep
1

Todos los programadores conocemos de sobra la mayoría de estructuras de datos que existen. Bien porque las usamos a diario o porque las hemos estudiado en la facultad, a nadie le resulta raro un array, un mapa (o hash) o una lista enlazada entre otras muchas. Para los programadores Java (u otro lenguaje de la JVM), las interfaces Collection y Map, junto con todas las clases que las implementan son el pan nuestro de cada día.

Sin embargo, hay algunas estructuras de datos que quizá (solo quizá) no conocemos tanto y que son sumamente interesantes. Una de ellas es java.util.BitSet. Quizá sea poco conocida por varias razones: primero porque no implementa ni Collection ni Map ni ninguna otra interfaz del api colecciones. Tampoco hereda de ninguna clase especial: el BitSet es una clase suelta, sin más. Segundo porque su uso típico parece un tanto alejado de lo que usamos cada día. Es interesante tener cientos o miles de bits juntos, y poder hacer operaciones and, or y xor con ellos, pero en realidad pocas veces necesitamos hacer operaciones a nivel de bit. Sin embargo, es posible darle otros usos a BitSet. Veamos uno de ellos.

Otros usos de BitSet

Supongamos que queremos guardar una gran cantidad de números enteros. Por ejemplo, los ids de un tabla en una aplicación con una base da datos. Si, de acuerdo, podríamos decir que para eso basta con crear otra tabla relacionada donde puedo guardar estos ids, filtrarlos, ordenarlos, etc. Pero no, supongamos que por cualquier razón, no queremos/podemos hacer esto. Si no conociéramos la clase BitSet, una primera solución sería guardar los ids en un List (ArrayList/LinkedList, no importa), el cual crecerá linealmente a medida que guardamos los ids.

Es decir, el tamaño que ocupa en memoria el List es directamente proporcional al número de elementos que almacena. Y aquí el problema viene cuando tenemos muchos, muchos elementos que guardar, por ejemplo 10.000.000. Tener 10 millones de integers es un array muy muy grande. Quizá podemos ahorrar algo de espacio con un BitSet, usando algunos trucos.

Veamos un BitSet como un array de booleanos, donde podemos preguntar una posición y que nos diga si es true o false (si el bit está a 1, es true; y si está a 0, es false). Usando el BitSet desde este punto de vista, podemos aprovechar para guardar los elementos posicionalmente. Es decir, en vez de guardar los valores, como se hacía en un List, el BitSet almacena las posiciones donde están los valores a guardar. Así, si queremos guardar el id 14, llamamos a nuestro BitSet y activamos el bit de la posición 14.

Un BitSet guardando el valor 14 simplemente tiene el bit 14 activo (a 1) y el resto desactivos (a 0)

              bit 14
                  v
000000000000000000100000000000000

Repetimos sucesivamente la misma operación con el resto de valores. Si ahora guardamos el 3 y 7, tendríamos un BitSet así:

              bit 14     7   3
                  v      v   v
000000000000000000100000010001000

Crecimiento de un BitSet

El tamaño y crecimiento de un BitSet viene dado por la posición más alta que en él guardamos. Así que no importa cuantos elementos introduzcamos en el BitSet, éste ocupará siempre lo mismo y solo crecerá cuando introduzcamos un elemento con un valor mayor. Es decir, ocupará lo mismo con los bits 3, 7 y 14, que si añadimos todos los bits 0, 1, 2, 3…12, 13 y 14. En ambos casos tiene que reservar sitio para 14 bits.

En resumen, un BitSet crece en función del bit más grande que almacena y un List en función del número de elementos que tiene. Para saber hasta cuanto puede crecer un BitSet tenemos que saber cual es el bit más grande. Después dividimos entre 32 (un Integer son 32 bits, de esta manera podemos hacer una comparación directa con el List de Integers) y ya sabemos cuanto ocupa en memoria. Por otro lado, un ArrayList crece en función del número de elementos que tiene, por lo que para saber cuanto ocupa, tan solo tenemos que ver cuantos elementos hemos insertado.

Todo esto provoca algunas situaciones que debemos valorar. Si vamos a guardar pocos elementos, y estos además tienen un valor muy alto, entonces vamos a desaprovechar mucho espacio. Por ejemplo: tenemos que guardar los valores 14 y 2510. En un List esto supone solo 2 Integers, uno para cada elemento. En un BitSet supone gastar bits hasta la posición 2510 (lo que hacen 79 elementos de 32 bits, o 79 Integers)

Pero si vamos a guardar más elementos, entonces es posible que nos compense un BitSet frente al List. Por ejemplo, queremos guardar solo los números pares del 0 al 2000, lo que suponen 1000 valores. Ahora el BitSet necesita bits hasta la posición 2000, lo que suponen 64 Integers, mientras que el ArrayList necesitaría 1000 Integers, uno por cada valor.

Hacer unos cuantos números antes de decidir qué colección usar nos puede hacer ahorrar bastante espacio. Por lo que la fórmula mágica es, usando la implementación de Java 6 usa en la que se usa un Long por cada 58 bits, si la densidad de tu colección es mayor que 1/58, entonces es preferible usar BitSet. Es decir, si (nº de elementos/valor más alto) > 0,01724 (1,72%). Todo esto suponiendo que nuestro List sea de Integers, si es de Longs, que ocupan el doble, entonces es la mitad.

- Resumen a ojo: si en nuestra tabla el id más alto es un millón, entonces nos compensa usar un BitSet a partir de 1720 ids por colección. -

Trabajando con la clase BitSet

Manipular un BitSet es extremadamente sencillo, si bien difiere un poco a como estamos acostumbrado de las clases List

BitSet bs = new BitSet();

// Número de elementos que tiene "activos" (bits a 1)
assert 0 == bs.cardinality();

// Añadimos 3 elementos: 0, 14, 2400 y el 80000
bs.set(0, true);
bs.set(14, true);
bs.set(2400, true);
bs.set(80000);  // Si no pasamos parametro, por defecto es true

// Número de elementos que tiene "activos" (bits a 1)
assert 4 == bs.cardinality();

// Borrar un elemento es simplemente asignarlo a false
bs.set(14, false);

// Para saber si hay un elemento activo
assert bs.get(0) == true;
assert bs.get(14) == false;
assert bs.get(2400) == true;

Hasta aquí muy fácil. Pero, ¿cómo itero los valores? No tenemos iterator(), así que tendremos que hacerlo así:

int value = -1;
while ((value = bs.nextSetBit(value+1)) != -1) {
    System.out.println(value);
}

Finalmente y de regalo, si queremos persistir a disco nuestro BitSet, podemos usar este código (que en realidad sirve para persistir cualquier objeto):

// Como guardarlo (comprimido, para que ocupe menos)
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(new java.util.zip.GZIPOutputStream(baos));
oos.writeObject(bs);
oos.close();

// Como volverlo a leer
ObjectInputStream ois = new ObjectInputStream(
    new java.util.zip.GZIPInputStream(new ByteArrayInputStream(bytes)));
BitSet bs = (BitSet) ois.readObject();
ois.close();

¡Espero que os haya sido de utilidad!

Bola extra: como siempre, esto es solo la punta del iceberg. Hay otras implementaciones de BitSet optimizadas para que el tamaño que necesitan en memoria no sea lineal con respecto al tamaño del bit más grande que almacenan, como FastBitSet de Javolution, o Javaewah.

Grails tip: mostrar la fecha y último commit de tu build

En Groovy, Programación      2 comentarios

Mar
29

Un pequeño truco para saber en todo momento que versión de nuestra aplicación Grails hemos desplegado en nuestro servidor. La idea es que, cuando construyamos nuestro war, se introduzcan algunos valores en el application.properties, como la fecha+hora actual y el id del último commit de Subversión con el que se ha hecho la compilación. Después, crearemos un servicio que nos muestre esta información en un controlador, de manera que la podamos consultar o consumir desde algún script por ejemplo.

Modificando el application.properties durante la compilación.

Creamos un fichero llamado _Events.groovy en la carpeta scripts de nuestro proyecto (o si nuestro proyecto se compone de varias aplicaciones Grails y usamos un plugin in-place común para todas, lo podemos incluir en este plugin in-place)

import org.tmatesoft.svn.core.internal.io.dav.*
import org.tmatesoft.svn.core.internal.io.fs.*
import org.tmatesoft.svn.core.internal.io.svn.*
import org.tmatesoft.svn.core.wc.*

eventWarStart = { type ->

    DAVRepositoryFactory.setup()
    SVNRepositoryFactoryImpl.setup()
    FSRepositoryFactory.setup()

    SVNWCClient wcClient = SVNClientManager.newInstance().WCClient
    SVNInfo svninfo = wcClient.doInfo(new File(basedir), SVNRevision.WORKING)
    def svnCommit = "#${svninfo.revision.number} - ${svninfo.committedDate.format("yyyy-MM-dd HH:mm:ss")} (${svninfo.author})"
    println "| Commit: ${svnCommit}"

    metadata.'build.svn.commit' = svnCommit.toString()
    metadata.'build.date' = new Date().format("yyyy-MM-dd HH:mm:ss")
    metadata.persist()

}

Mostrando la información

Después creamos un controlador llamado SystemInfoController.groovy (o como queramos)

class SystemInfoController {
    def grailsApplication
    def index() {
        def versionInfo = "${grailsApplication.metadata.get("app.name")}-${grailsApplication.metadata.get("app.version")}
"+
                          "Build date: ${grailsApplication.metadata.get("build.date")}
"+
                          "SVN ${grailsApplication.metadata.get("build.svn.commit")}
"
        render versionInfo as String
    }
}

Ahora, después de construir con grails war y desplegar nuestra aplicación, solo tenemos que ir a nuestro proyecto: http://localhost:8080/mi-app/systemInfo y veremos algo como esto:

mi-app-1.5.0
Build date: 2012-03-29 16:16:44
SVN #1472 - 2012-03-29 16:16:20 (avilches)

Con esta información podremos saber la fecha exacta de la compilación y evitar esa típica situación de no saber si esta realmente desplegada la última versión o no (que siempre se resuelve mirando el tamaño del war generado y comparándolo con el del war desplegado, borrando todos los temporal, contruyendo y desplegando desde cero otra vez)

Vitaminas para tu proyecto Java

En Groovy, Programación      1 comentario

Feb
12

El próximo 17 y 18 de Febrero se celebrará la segunda edición de Spring IO en Madrid. Habrá tres tracks con charlas y ponencias muy interesantes; y yo tendré el placer de impartir un taller de horas práctico llamado “Vitaminas para tu proyecto Java” (el jueves 17 a las 11:40)

Pero ¿por qué un taller de groovy para programadores Java? Pues porque Groovy y Grails están tan unidos que a veces se confunden con la misma cosa. Y aunque mucha gente piensa que solo es posible programar con Groovy usando Grails, esto no es así. Sin importar como sea tu proyecto actual, Groovy puede ayudarte de muchas maneras. Así que en este taller de 2 horas trataré varios aspectos de Groovy que podemos explotar desde nuestra aplicación 100% Java. Aprenderemos a hacer testing y mocks de tus componentes Java con Groovy, crearemos un pequeño DSL y aprovecharemos las capacidades dinámicas de Groovy para crear, editar y ejecutar scripts directamente desde la interfaz web de tu aplicación. También aprenderemos a parsear Xml, trabajar con JDBC y muchas cosas más, todo de una manera práctica, con ejercicios y recetas que puedes llevarte a casa y ponerlas en marcha el lunes siguiente en tu trabajo.

El objetivo no es hablar de las bondades de Grails, como llevo haciendo desde hace un par de años, sino demostrar a los que todavía no conocen Groovy, que pueden ayudarles mucho en su día a día. Groovy ¡vitaminas para tu proyecto Java! El nivel de la charla es intermedio y el idioma es el castellano. ¡Nos vemos en el SpringIO 2012! Más información en: http://springio.net/agenda

JSONP, o la inserción dinámica de scripts que podría sustituir a Ajax

En Programación      15 comentarios

Sep
15

Parece una tecnología nueva, pero no lo es ni mucho menos. Sugerida en diciembre del 2005 por Bob Ippolito (ver este post en su blog) como una solución para cargar código de manera asíncrona desde diferentes dominios, se hizo popular cuando Google la utilizó para implementar Google Instant Search. Sin embargo, tras este nombre peculiar, se esconde algo muy sencillo y extremadamente útil que, para mi gusto, es más potente y sencillo que Ajax. En este post voy a intentar explicar cómo funciona Ajax por dentro junto con una alternativa mucho más sencilla, que es la que usa Jsonp.

Ajax por dentro

Hace ya tiempo que todos conocemos Ajax y lo usamos a diario en nuestras aplicaciones web, pero tenemos que recordar que el objeto XMLHttpRequest fue una invención de Microsoft en el 1999 que no estandarizó hasta el 2006 y que, hasta hoy en día, sigue siendo un hack que funcione en cualquier navegador. De hecho, nadie usa Ajax directamente, sino que siempre se hace uso de alguna librería (como jQuery, Prototype, Mootols o cualquier otra), y ninguna de ellas se libra de tener algo parecido a esto:

var httpRequest;
if (window.XMLHttpRequest) {
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) {
    try { httpRequest = new ActiveXObject("MSXML2.XMLHTTP");
    } catch (e) {
        try { httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
        } catch (e) {}
    }
}

Lo cual es bastante aberrante, pero funciona.

Cómo solemos usar Ajax

Aunque inicialmente Ajax se ideó para hacer peticiones Xml (la “x” final de Ajax viene precisamente de Xml), el coste que supone parsear este tipo de formato en Javascript hizo que se sustituyera por algo mucho más sencillo de parsear y que, además, viene implícito de manera nativa en el lenguaje Javascript: JSON.

JSON es un formato extremadamente sencillo para guardar colecciones, basicamente listas de elementos y mapas de parejas clave/valor (también conocidos en Javascript como Objetos y en otros lenguajes como tablas hash), que se pueden combinar entre sí para hacer estructuras más complejas:

["Primer elemento","Segundo", 800, true, false, null]

{key:"value", anotherKey:293

{id:201,
 nombre:"Alberto",
 profesion:"Programador",
 lenguajes: ["Java", "Groovy", "Flex", "Javascript"],
 webs: [{id:21, nombre:"Coderfacts", url:"http://coderfacts.com"},
        {id:178, nombre:"Blog", url:"http://albertovilches.com"},
        {id:44, nombre:"Greach", url:"http://greach.es"}
       ],
 contacto: {twitter:"@albertovilches",
            email:"vilches ARROBA gmail.com",
            skype:"alberto_vilches"
           }
}

Y parsearlo es algo tan sencillo como evaluarlo como expresión. Es decir, el formato JSON es exactamente el mismo que usa Javascript para guardar colecciones:

def texto = "['hola', {quien:'Mundo'}]"
def json = eval(texto)
alert(json[0])          // Muestra hola
alert(json[1].quien)    // Muestra mundo

Por esta razón, la mayoría de frameworks Ajax nos permiten decidir que tipo de respuesta esperamos: texto, html, xml o json. Son muchas las veces que usamos Ajax para obtener código html que inyectamos en el Dom de nuestra página web, pero poco a poco hemos ido cambiando el hábito y preferimos que las peticiones devuelvan Json en vez de html. Las ventajas son muchas: en el servidor, nos ahorramos renderizar el resultado para convertirlo en html, y nos limitamos a enviar la información transformada en Json, que ocupa mucho menos. Y en el cliente, podemos utilizar el Json recibido para cambiar el Dom y renderizar el resultado de la petición, pero también podemos hacer transformaciones y cálculos antes de convertirlo en algo visible en nuestra web. Sin duda, Json ha permitido aligerar la carga en los servidores, y delegar que la decisión sobre como renderizar los resultados se haga donde se tiene que mostrar, en la propia página.

Veamos donde estamos: tenemos una aplicación web que necesita ser modificada. Hacemos una petición Ajax al servidor solicitando una información determinada. El servidor recibe la petición, lee los parámetros, busca en la base de datos (o donde sea) y genera un json con la información. El cliente, nuestra página web, recibe el Json, lo parsea con Javascript y renderiza el resultado, modificando la página actual. Podemos continuar.

Javascript dinámico frente a Ajax

Intentemos responder a esta pregunta: si solo usamos Ajax para cargar Json, el cual solo puede ser parseado y utilizado desde Javascript, ¿porqué no cargar el Javascript con el Json y ejecutarlo directamente desde el servidor?

Supongamos este ejemplo básico y casi minimalista:

Nombre <span id="nombre"></span><br/>
Profesión <span id="profesion"></span>

<script type="text/javascript">
function pintaPersona(data) {
    document.getElementById("nombre").innerHTML = data.nombre;
    document.getElementById("profesion").innerHTML = data.profesion;
}
</script>

Solo tiene un par de etiquetas <span> donde mostrar un nombre y profesión, y una función cargaPersona() que se encargará de rellenar estas etiquetas con el objeto json recibido como parámetro. Así que podemos llamar en cualquier momento a la función cargaPersona() para rellenar los campos simplemente con:

pintaPersona({nombre:"Alberto", profesion:"Programador"});

Pero también podemos generar este Javascript dinámicamente en servidor a partir de una url, usando Java, Php, Ruby, etc. Por ejemplo:

<script src="cargaPersona.php?id=25" type="text/javascript"></script>

Esta url podría buscar un usuario (usando el parámetro id con valor 25) y generar directamente la función pintaPersona() con sus datos:

GET /cargaPersona.php?id=25
pintaPersona({nombre:"Alberto", profesion:"Programador"});

No es más que un ejemplo muy sencillo, ya que la función podría hacer algo mucho más completo, pero la idea es la misma: generar dinámicamente Javascript en servidor que llame a una función que ya tenemos previamente definida en nuestra página, con unos datos determinados.

Pero para que este Javascript dinámico pueda competir con Ajax, necesitamos que sea asíncrono. Es decir, poder cargarlo cuantas veces queramos y en cualquier momento, por ejemplo cuando se hace click en un listado de usuarios. Para ello, lo que haremos es crear una etiqueta <script> y añadirla al dom (por ejemplo, al final del body). El navegador cargará dicho Javascript (que puede estar en cualquier dominio) y lo ejecutará en ese mismo momento. Para crear y añadir scripts al Dom no hace falta ningún framework, basta con esto:

var script = document.createElement("script")
script.src = "cargaPersona.php?id=25"
script.type = 'text/javascript';
document.getElementsByTagName("body")[0].appendChild(script)

Aunque es mejorable, ya que la etiqueta script se puede reutilizar una y otra vez, desde mi punto de vista, no hay color con Ajax y la complejidad interna que supone crear y procesar una petición con XMLHttpRequest.

Un ejemplo con todo funcionando

Veamos un ejemplo de los dos sistemas juntos:

Nombre <span id="nombre"> /span><br/>
Profesión <span id="profesion"></span>
<script type="text/javascript">
    function pintaPersona(data) {
        document.getElementById("nombre").innerHTML = data.nombre;
        document.getElementById("profesion").innerHTML = data.profesion;
    }
</script>

<!-- Ajax jQuery flavor -->
<script type="text/javascript" src="http://code.jquery.com/jquery-1.6.4.js"></script>
<script type="text/javascript">
    function cargaPersonaAjax(id) {
        $.ajax({url: "http://localhost/cargaPersonaJson.php", data: {id:id},
                dataType: "json", success: function(json) { pintaPersona(json) }});
    }
</script>

<!-- No framework, script dynamic flavor -->
<script type="text/javascript">
    function cargaPersonaScript(id) {
        var script = document.createElement("script")
        script.src = "http://localhost/cargaPersonaScript.php?id=" + id
        document.getElementsByTagName("body")[0].appendChild(script)
    }
</script>

<ul>
    <li>Usuario 1 <a href="javascript:void(cargaPersonaAjax(1))">Mostrar</a></li>
    <li>Usuario 2 <a href="javascript:void(cargaPersonaScript(2))">Mostrar</a></li>
</ul>

Siendo el resultado de cargaPersonaScript.php un Javascript que llama a la función pintaPersona:

GET /cargaPersonaScript.php?id=25
pintaPersona({"nombre":"Alberto", "profesion":"Programador"});

Y el de cargaPersonaJson.php solamente Json puro, por lo que será responsabilidad del handler “success” de jQuery el llamar a pintaPersona() de nuevo con el Json recibido.

GET /cargaPersonaJson.php?id=25
{"nombre":"Alberto", "profesion":"Programador"}

JSONP

Muy bien, ahora que ya sabemos cargar scripts dinámicamente y que incluso podemos sustituir a Ajax con él (aunque también tiene sus limitaciones), ¿qué es JSONP? Si nos fijamos en el resultado de las dos peticiones anteriores, vemos que la diferencia es que una es Json puro, y la otra es el mismo Json, pero envuelto en una función.

JSON               {"nombre":"Alberto", "profesion":"Programador"}
JSONP pintaPersona({"nombre":"Alberto", "profesion":"Programador"});

Jsonp establece que el nombre de la función que envolverá el Json de respuesta lo debe decidir el usuario, enviándoselo en un parámetro llamado “callback”. Así que JsonP no es más que la carga dinámica de scripts definiendo en uno de los parámetros el nombre de la función que se va a llamar cuando se ejecute. De esta manera, podemos reutilizar la misma llamada para ejecutar diferentes funciones usando los mismos datos.

Siguiendo con nuestro ejemplo anterior, la función cargaPersona, responsable de hacer la llamada Jsonp, deberá enviarle al servidor en uno de los parámetros el nombre de la función de vuelta (callback) a ejecutar, en nuestro caso “pintaPersona”:

function cargaPersonaScript(id) {
    var script = document.createElement("script")
    script.src = "http://localhost/cargaPersonaJsonP.js?id=" + id;
    // Añadimos el nombre de la función callback
    script.src = script.src + "&callback=pintaPersona";
    script.type = 'text/javascript';
    document.getElementsByTagName("body")[0].appendChild(script)
}

En resumen, una llamada JSONP devuelve un JSON envuelto en una llamada a una función Javascript cuyo nombre se especifica en la propia petición como parámetro.

GET /cargaPersonaJsonP.php?id=25&callback=pintaPersona
pintaPersona({nombre:"Alberto", profesion:"Programador"});

GET /cargaPersonaJsonP.php?id=25&callback=otraFuncionDistinta
otraFuncionDistinta({nombre:"Alberto", profesion:"Programador"});

Incluso la versión jQuery del equivalente al ejemplo anterior es más reducida y simple:

function cargaPersonaAjax(id) {
    $.ajax({url: "http://localhost/b.js", data: {id:id},
            dataType: "jsonp", jsonpCallback: "pintaPersona"});
}

Internamente, el hecho de especificar Jsonp como método de envío hace que la petición se ejecute usando la inserción de una etiqueta <script> en vez Ajax, aunque el resultado es el mismo.

Conclusión

¿Debería Jsonp o la carga dinámica de etiquetas <script> sustituir a Ajax? No, ni mucho menos. Las dos formas son equivalentes en resultado y tienen sus ventajas e inconvenientes: con la inserción dinámica de scripts no se pueden hacer POST (aunque ¿quién los necesita realmente?) pero permite cargar contenidos en diferentes dominios (cross domain), cosa que no es posible con Ajax. De hecho, todas las soluciones llamadas Ajax cross-domain usan esta técnica, como ésta o esta otra. Eso sin contar lo obvio: que con Ajax podemos cargar cualquier tipo de contenido (texto,html,script,json o binario), pero tenemos que parsearlo, y que con JsonP nos limitamos a cargar Javascript, pero se ejecuta automáticamente por el navegador, al formar parte de una etiqueta <script>. Aunque esto también tiene sus riesgos: alguien puede interceptar la carga del javascript desde otro servidor y modificar el código que luego se ejecutará en nuestra página, así que solo deberemos usar esta técnica con sitios en los que confiemos, o hayamos creado nosotros. Y, por supuesto, asegurarnos de que no se usa el parámetro callback para inyectar código de vuelta, y para eso tenemos algunos trucos como sanitizar los parámetros.

Personalmente, si voy a trabajar con Json, usaré Jsonp, y dejaré Ajax para trabajar con html y binarios. Si estás dudando qué usar, siempre puedes hacer unos tests de rendimiento en tu propio navegador. Parece ser que JsonP es bastante más rápido y en algunos sitios importantes ya lo están usando, como Delicious, Flickr, Twitpic o Youtube. De todas formas, aprender a usar las dos y saber, además, como funcionan por dentro, son la clave para tomar la decisión correcta en el momento en el que lo necesitemos.

Bola Extra: limitaciones de las peticiones Get

La inserción de <script> solo permite el uso de urls que llegan al servidor como una petición GET. Por un lado, esto hace que sea imposible hacer upload de ficheros, que requieren una petición POST con un enctype “multipart/form-data”. Y por otro lado, la especificación de Htpp no define un límite para el tamaño de las urls, así que cada navegador tiene el suyo propio que debemos tener en cuenta:

• Internet Explorer: 2083, según nota oficial de Microsoft, pero gente comenta en Stackoverflow que ha llegado a probar longitudes mucho mayores, como 4.000 caracteres en IE8.
• Firefox: 65.536 de límite en teoría, pero acepta 100.000 en la práctica
• Safari: 80.000
• Opera: 190.000

Puedes ver las pruebas prácticas que han hecho algunas personas en este post.

Abierto el registro de Greach

En Crónicas, Groovy      Comments Off

Sep
10

El 1 de septiembre se abrió el registro de Greach, un evento que estoy organizando, dedicado exclusivamente al lenguaje Groovy y a todos los frameworks y herramientas que se han creado a su alrededor. Se celebrará el próximo viernes 4 de Noviembre en la universidad San Pablo CEU de Madrid. De un solo día de duración, será corto pero intenso: dos tracks llenos de charlas y talleres sobre Groovy, Grails y Griffon, con primeras figuras nacionales e internacionales como Guillaume Laforge y Andrés Almiray (líderes del proyecto Groovy y Griffon, respectivamente).

Podéis visitar la web de Greach para conocer el programa y horario (todavía no definitivo) de las charlas, conocer un poco más a los sponsors y ver la localización del evento. Algunos speakers españoles ya han confirmado el tema de sus charlas y tenemos temas tan interesantes como programación funcional con Groovy, un taller de Koans de metaprogramación y MongoDB sobre Grails. Todavía quedan por confirmar nuevos speakers y nuevas ponencias.

• Compra de entradas: http://greach.es/registro

Grails, enumerados, combos, i18n y otras historias

En Groovy, Programación      6 comentarios

Aug
22

Los tipos enumerados aparecieron en Java 5 para aliviar todo el uso (y abuso) de constantes que usábamos en nuestros proyectos. Y en Grails podemos usarlos como atributos en nuestras clases de dominio de una manera muy sencilla.

Antes de ver los enumerados, vamos a ver como manejábamos antes la situación sin ellos. Supongamos que tenemos una tabla y clase de dominio Usuario, y tenemos un campo estado en el que queremos guardar el estado de ese usuario. Podríamos tener algo así:

class Usuario {
    String nombre, password, email
    String estado

    static constraints = {
        estado(inList: estados)
    }

    static String estado_valido = "valido"
    static String estado_eliminado = "eliminado"
    static String estado_bloqueado = "bloqueado"
    static List estados = [estado_valido, estado_eliminado, estado_bloqueado]
}

El valor que le demos a las constantes valido, eliminado y bloqueado no importa demasiado, podrían haber sido los valores 0, 1 y 2 perfectamente. Pero es que ese valor es el que vamos a ver cuando consultemos la base de datos con SQL, así que es interesante que sea descriptivo, por lo que elegimos una cadena de texto.

¿Cuál es el problema? Que los estados no son más que valores, y no tienen información adicional. Además, mezclamos la definición de los estados en la propia clase. Puede que no parezca muy grave si solo tenemos tres estados, pero imagina que tuviéramos 20 estados. O imagina que, además, tuviéramos otros campos como “tipoDeUsuario”, “sexo”, “situaciónLaboral” o lo que sea, que también fueran susceptibles de tener varios valores como el campo estado. El resultado sería una clase llena de constantes, colecciones de constantes y atributos que usan esas constantes.

Con un enumerado todo esto es mucho más sencillo. Un enumerado es igual que una clase, pero define una serie de instancias únicas con un nombre concreto. Para crear el enumerado, podemos hacerlo en un fichero aparte, como si fuera una clase más, o podemos hacerlo dentro de nuestra clase de dominio:

class Usuario {
    String nombre, password, email
    Estado estado
}
enum Estado {
    valido, eliminado, bloqueado
}

Muy bien, y ahora ¿cómo accedemos a estos datos? Simplemente usamos cada enumerado como si fuera un valor estático de la clase Estado:

Usuario u = new Usuario(estado: Estado.valido) // creación
u.estado = Estado.eliminado // asignación
if (u.estado == Estado.bloqueado) println "Oh oh!" // lectura y comparación

Gorm se encargará de leer y persistir este dato en nuestra tabla, usando el propio nombre del enumerado “valido”, “eliminado” y “bloqueado”.

Métodos values() y name()

Los enumerados tienen dos métodos muy interesantes. Uno de ellos es values(), que se usa a nivel de clase y devuelve una colección con todos los enumerados posibles. Y el otro es name(), que se usa a nivel de instancia del enumerado y devuelve un String con el nombre de la instancia.

def u = new Usuario(estado: Estado.valido)
String nombreEstado = u.estado.name()
println nombreEstado // pintará "valido"

Estado.values().each { println it.name() } // pintará valido eliminado bloqueado

Para acceder a un enumerado usando su nombre, podemos hacerlo de varias maneras:

String nombreEstado = "valido"
println Estado[nombreEstado]
println Estado."$nombreEstado"

¿Para qué querríamos hacer una cosa así? Pues por ejemplo cuando el valor viene en un fichero de texto, o a través de un formulario como parámetro de una petición http. En este último caso no sería realmente necesario, pues el binding de Grails transforma automáticamente los campos de texto en su enumerado correspondiente, pero siempre es bueno saber como hacerlo a mano.

def u = new Usuario(params) // Esto funciona si hay un parámetro "estado"
u.estado = Estado."${params.otroEstado}" // Y esto también funciona

Añadiendo información a cada enumerado

Una de las ventajas que tiene el usar enumerados, es que podemos ampliar la información que tiene cada valor. Por ejemplo, en el caso de los estados, podemos añadir un texto con el nombre y un color, que usaremos después para mostrar el estado junto con los datos del usuario.

enum Estado {
    valido("Valido", "blue"),
    eliminado("Eliminado", "gray"),
    bloqueado("Bloqueado", "red")

    String text, color
    Estado(text, color) {
        this.text = text
        this.text = color
    }
}

Ahora, desde nuestros gsp, cuando mostremos la información del usuario, podemos hacer:

Nombre: ${usuario.nombre}, email: ${usuario.email}
Estado: <span style="color: ${usuario.estado.color};">${usuario.estado.text}</span>

Ponemos texto y color, pero bien podríamos haber puesto su código i18n y un nombre de estilo CSS.

Un ejemplo de uso desde un Gsp con un combo:

<g:select name="estado" from="${Estado.values()}" optionValue="text"/>

El atributo optionValue especifica el atributo del enumerado a mostrar en el combo (lo que ve el usuario). También se pueden definir un closure que se ejecutará en cada enumerado. Si no se especifica nada, se muestra el resultado de toString()

Por defecto, el key de cada elemento del combo es el toString() del enumerado, que devuelve lo mismo que name(). Pero si hemos sobreescrito el método toString() para que devuelva otra cosa, entonces tendremos que añadir el atributo optionKey a nuestra etiqueta, especificando un closure que devuelva el name() de cada enumerado:

<g:select name="estado" from="${Estado.values()}" optionValue="text"
          optionKey="${ {estado -> estado.name()} }"/>

Internacionalización en enums y combos

Si queremos internacionalizar nuestros enumerados y combos, solo tenemos que hacer que el atributo text tenga el código de nuestro resource bundle.

enum Estado {
    valido("enum.estado.valido", "blue"),
    eliminado("enum.estado.eliminado", "gray"),
    bloqueado("enum.estado.bloqueado", "red")

    String text, color
    Estado(text, color) {
        this.text = text
        this.text = color
    }
}

En nuestro messages_es.properties:

enum.estado.valido=Valido
enum.estado.eliminado=Eliminado
enum.estado.bloqueado=Bloqueado

Y a la hora de mostrar nuestros datos:

Nombre: ${usuario.nombre}, email: ${usuario.email}
Estado: <span style="color: ${usuario.estado.color}"><g:message code="${usuario.estado.text}"/></span>

Los combos tendrán ahora un closure como optionValue, en vez de un atributo como tenían antes, con el fin de transformar el código del atributo text, en su correspondiente traducción usando el taglib g.message :

<g:select name="estado" from="${Estado.values()}"
          optionValue="${ {estado -> g.message(code:estado.text)} }"/>

Aunque también podemos usar la solución que proponen en este post, aunque personalmente me parece un poco más rebuscada.

Lógica en los enumerados y buenas prácticas

Los enumerados al igual que las clases pueden tener métodos. Una buena práctica es separar la lógica de los enumerados en métodos dentro. ¿Para que querríamos hacer esto? A veces nuestra aplicación se debe comportar de manera diferente en función de si una variable es un enumerado u otro. Una manera de cambiar este comportamiento es añadir una condición que compare el valor de una variable con un enumerado (o varios) en concreto, y obrar en consecuencia. Sin embargo, esto es una mala práctica. Veamos como arreglarlo.

Ejemplo de código que sería una mala práctica:

// EJEMPLO DE MALA PRACTICA
def login(nombre, password) {
    def usuario = Usuario.findByNombreAndPassword(nombre, password)
    if (usuario.estado == Estado.bloqueado || usuario.estado == Estado.eliminado) // NO PASAR
    else …. // OK
}

Estamos usando el valor que hay en usuario.estado para compararlo dos enumerados (bloqueado y eliminado). Si la condición es cierta, no se permite la entrada al usuario a la aplicación. Pero, ¿no sería más legible si, en vez de comparar los valores, le preguntáramos al enumerado si se le permite la entrada a la aplicación?

// EJEMPLO DE BUENA PRACTICA
def login(nombre, password) {
    def usuario = Usuario.findByNombreAndPassword(nombre, password)

    if (usuario.estado.canLogin()) // NO PASAR
    else …. // OK
}

Queda bastante más claro. Ahora tenemos que ser capaces de que cada enumerado tenga un método que devuelva true o false si se le permite entrar en la aplicación o no. La manera más cómoda de hacerlo es añadiendo un atributo boolean a cada enumerado, especificando su valor durante su creación. Y que el método canLogin() devuelva este valor, que será distinto para cada enumerado.

enum Estado {
    valido(true), eliminado(false), bloqueado(false)

    boolean logable
    Estado(logable) {
        this.logable = logable
    }
    boolean canLogin() { logable }
}

Esto tiene la gran ventaja de que si añadimos un nuevo enumerado, no tendremos que buscar por toda nuestra aplicación donde se usa para modificar las condiciones. O si queremos cambiar el comportamiento de la aplicación donde se use el enumerado, solo tendremos que modificar la implementación, no todas las veces donde se use.

En general, podemos decir que tener en la lógica de nuestra aplicación una condición en la que se compara un enumerado con otro es siempre una mala práctica. En su lugar, se debería usar un método dentro del enumerado que devuelva el resultado de esta condición. Y que cada enumerado defina, en su creación como atributos, los valores necesarios que se usarán para evaluar dicha condición.

Resumiendo…

Y nada más. El soporte de enumerados en Grails es muy bueno: se transforman correctamente en el binding de los controladores y se persisten facilmente en nuestras clases de dominio. Y desde el punto de vista del diseño, el código es más claro y estructurado, y permite añadir atributos y lógica a cada enumerado. En definitiva, usar enumerados es una gran solución que solo proporciona ventajas.

Bola extra: alguien se preguntará para que sirve el método name(), si el método toString() de los enumerados ya devuelve el nombre de éste. Sencillo: toString() se puede sobreescribir, y name() no porque es final. Y esto es bueno porque name() nunca debe cambiar, ya que el nombre es una propiedad intrínseca e inmutable de cada enumerado. Y el toString() es simplemente su representación visual, y puede devolver cualquier cadena que decida el que diseñe la aplicación.

Cómo saber si le hace falta más memoria a tu Mac

En Tutoriales      Comments Off

Aug
7

¿Tu Mac no va todo lo suave que te gustaría? ¿Notas que tienes que cerrar aplicaciones para que te vaya más rápido? Es posible que te falte memoria RAM, pero ¿como lo averiguo?

Lo primero que tenemos que hacer es usar nuestro Mac durante un tiempo, cuanto más mejor. Después de tener “trabajando” al ordenador, abrimos el monitor de actividad, que está en Aplicaciones -> Utilidades -> Monitor de actividad. Una vez abierto, buscamos las pestañas de abajo y pinchamos en la segunda, la que pone “Memoria del sistema”.

En mi caso, lo he dejado cinco días encendido con un alto uso. Vale que no soy diseñador gráfico que necesite renderizar 3D, pero si tengo funcionando varios servidores Java a la vez, una base de datos, máquinas virtuales, dos IDEs, dos navegadores, Spotify, Skype y muchas cosas más. Bueno, pues después de cinco días esta es la información de memoria que da mi Monitor de actividad.

• Libre: es la memoria que está todavía sin usar y disponible para cualquier aplicación que la necesite.
• “Wired”: es la memoria usada por el sistema y que no puede ser paginada (más adelante veremos lo que es la paginación)
• Activo: memoria actualmente usada por las aplicaciones abiertas y que es susceptible de ser paginada si el sistema lo necesita.
• Inactivo: memoria que ha sido usada por aplicaciones que han sido cerradas y que ya no la necesitan. Si una de estas aplicaciones es abierta de nuevo, puede recuperar la memoria usada anteriormente de esta región y cargar más rápido. Si el sistema necesita memoria, usará primero este espacio inactivo.
• En uso: es la memoria real usada de tu sistema. Yo tengo 4GB, pero nunca llegará a ese consume y siempre marcará algo menos porque la memoria es compartida con la tarjeta gráfica, tal y como explican en este post.
• Espacio de intercambio usado: es el tamaño de la memoria virtual que estamos realmente usando.

Para saber cuanta memoria RAM tenemos disponible, es necesario saber primero como se obtiene cuando se necesita. Supongamos que arrancamos la aplicación X y que esta necesita para ejecutarse y abrir algunos datos un total de 300Mb. Esto es lo que hace, más o menos (ojo, no soy un experto ni me dedico a programar el kernel de MacOS, así que esta información la he obtenido de diferentes artículos de internet):

1. Primero se busca si la aplicación ya había sido abierta con anterioridad, y si la memoria usada entonces esta todavía intacta en la region inactiva. Si es así, se recupera esa región de memoria y se usa.
2. En caso de que necesite más memoria, o si no estuviera en la región inactiva, o estuviera en la región inactiva pero de manera incompleta (porque ha sido usada por otra aplicación), entonces se usa la memoria libre.
3. Si no queda memoria libre o se necesita más, se utilizará memoria inactiva de otras aplicaciones (recodemos que la memoria inactiva es como un caché para que las aplicaciones que acaban de cerrar carguen más rápido si se vuelven a abrir, pero esta memoria en realidad no está siendo usada y se puede utilizar).
4. Si todavía se necesita más memoria, se obtiene de otro proceso activo. Pero como ese proceso la necesitará en algún momento, pues todavía sigue activo, no se le puede quitar sin más, así que es necesario guardar esa información en disco en el “espacio de intercambio usado”, lo que se conoce como paginación.

Entonces, la verdadera memoria RAM que tenemos disponible = memoria libre + memoria inactiva. Pero el sistema nunca se va a quedar sin memoria, porque si necesita más, la usará de otros procesos activos usando el archivo de paginación, es decir, copiará la memoria usada por otros procesos en el archivo de paginación, y dejará ese nuevo espacio libre a la aplicación que la necesita. A costa de no quedarnos nunca sin memoria, tenemos un sistema más lento, ya que escribir y leer de disco siempre toma más tiempo que hacerlo desde la memoria RAM.

Para más información podéis consultar la documentación oficial de Apple sobre como interpretar la información de memoria del Monitor de actividad/ Memory Usage Performance, y también este post.

Cómo saber si realmente te hace falta memoria

Con la paginación. Cuando una aplicación X necesita memoria y al sistema no le queda libre más RAM, lo que hace es coger una porción de memoria de otra aplicación que está inactiva (aplicación Y), la escribe a disco, y la libera para que la aplicación X pueda usarla. A eso se le llama swap out o paginación de salida. Ahora el caso contrario, cuando una aplicación Y vuelve a necesitar ese porción de memoria que está en disco (en vez de en la memoria RAM), el sistema la lee y la vuelve a cargar en memoria para que pueda ser usada de nuevo (swap in o paginación de entrada). Claro que si el sistema tampoco tiene espacio libre, tendrá que coger otra aplicación inactiva y repetir el proceso una y otra vez. Es posible que esto pase de vez en cuando, no pasa nada. Pero si tu Mac está siempre escaso de memoria, se pasará mucho tiempo paginando y dará como resultado un rendimiento peor, ya que el acceso a disco y la propia paginación tienen un alto coste.

En mi caso vemos que tengo 17Gb de paginación de salida. Es decir, que desde el último inicio del sistema operativo, se han escrito a disco 75GB de la memoria RAM en diferentes ocasiones porque no ha habido espacio suficiente. Y de estos 75GB escritos, se han vuelto a recuperar 17GB que han sido leídos del disco y vueltos a poner en memoria. Es decir, entrada = 75GB y salida = 17GB. Por lo que he podido investigar en blogs especializados, el ratio entre swap in/out debe ser del 10% o menos. En mi caso, 17 / 75 = 0.22 es mayor que 0.10, luego necesito más RAM.

Cómo saber qué tipo de memoria necesito y dónde la compro

Para los últimos Macbooks Pro podéis comprar estas memorias en Amazon. La diferencia es que los Macbooks del 2010 tienen memoria DD3 a 1066Mhz y los del 2011 a 1333Mhz. El precio es parecido (he cogido las más baratas de la marca Corsair).

• 8GB para Macbook Pro del 2011 (también vale para los últimos iMac QuadCore i7 del 2011) por $49.99 o 35€: Corsair 8 GB DDR3 1333Mhz CMSO8GX3M2A1333C9
• 8Gb para Macbook Pro del 2010 por $44.99 o 31€: Corsair 8 GB DDR3 1066Mhz CM3X8GSDKIT1066
  Esta es la que acabo de comprar yo…¡ayer mismo! :-)

Si tenéis otro Mac y no sabéis que memoria necesitáis, la mejor manera es descargar el scanner de Crucial: nos detectará el ordenador que tenemos, la memoria que necesita y nos llevará a la página donde comprar esa memoria en su tienda, aunque podemos usar la información para comprarla en otro sitio claro (como Alternate, Amazon, etc). Podéis obtenerlo en esta dirección: http://www.crucial.com/systemscanner.

Y para buscar donde comprar Ram, lo mejor es usar Ramseeker, que es como la cotización diaria de la memoria Ram en las tiendas más importantes, como si de la bolsa se tratara.

Como instalar la memoria

Si te da miedo meter mano en las tripas de tu Mac, no te preocupes, aquí tienes las guías oficiales de Apple. Es muy fácil:

• Instrucciones para ampliar memoria en un Macbook.
• Instrucciones para ampliar memoria en un Macbook Pro.
• Instrucciones para ampliar memoria en un iMac.

PhoneGap vs. Flex vs. Appcelerator vs. Corona: nuevas conclusiones

En Programación      13 comentarios

Aug
6

Pasada ya casi una semana desde los últimos post en los que evaluaba estas herramientas, he tenido constancia de dos hechos que me han hecho cambiar de opinión. Además, revisando la tabla del último post, creo que no he sido todo lo exacta que me habría gustado, así que en vez de modificar todo el artículo, me he decidido a hacer una nueva tabla y sacar nuevas conclusiones. Si no sabes de qué va todo esto, aquí tienes los posts anteriores relacionados

• Parte 1: Aplicaciones móviles: web vs nativas vs multiplataforma
• Parte 2: Desarrollo de apps. móviles multiplataforma: Phonegap y Titanium Appcelerator
• Parte 3: Desarrollo de apps. móviles multiplataforma: Corona y Adobe Air mobile y conclusiones

¿Qué es lo que me ha hecho cambiar de opinión? Para empezar, mi tabla anterior era demasiado “estricta” o “personalizada” y ponía características como “regulares” cuando no eran más que temas subjetivos. Por ejemplo, que a mi me parezca mejor lenguaje ActionScript que JavaScript no significa que si una herramienta usa JavaScript tenga que tener peor nota. Por esta razón, he igualado las características de las herramientas basadas en opiniones subjetivas. ¿Cuando evalúo una característica como mala? cuando supone un impedimento real para el desarrollo. Por ejemplo, el hecho de que para construir una aplicación para IOS sea necesario tener un Mac es una característica regular, pero no es impedimento, por lo que no la he puesto como roja (y antes sí).

¿Que es lo que he puesto entonces como rojo/malo/impedimento? 3 cosas nada más:

1. El precio: Flash Builder 4 y Corona.
2. Que la aplicación se distribuya con el código fuente: PhoneGap.
3. Que requiera un modelo específico de dispositivos: Adobe Air mobile para Android requiere terminales de gama alta con procesador de Arm7 (gracias Erik por avisar!).

Así que mis conclusiones son distintas. Flex baja muchos puestos por el hecho de que no funciona en todos los dispositivos Android, y PhoneGap también, al permitir que cualquier pueda bajarse tu aplicación y verle todas las tripas. Entonces, ¿cuál elijo?

Primero hay que preguntarse el objetivo de la aplicación

• Publicarla en el AppStore/Android Market con un precio por descarga (aplicación de pago). No puedes usar PhoneGap porque podrá ser “pirateada” con extrema facilidad, al incluir el código fuente. Ni deberías usar AdobeAir porque no funcionará en todos los dispositivos Android. Te queda solo Corona para juegos y Appcelerator para el resto de aplicaciones.
• Publicarla en el AppStore/Android Market como aplicación gratuita. Puedes usar PhoneGap, siempre que no te importe que el mundo entero vea tu código. No deberías usar Adobe Air por la misma razón que el punto anterior, así que te queda Corona y Appcelerator.
• Aplicación a medida. Puedes usar PhoneGap, tu cliente quiere que le desarrolles una aplicación a medida, no robarte el código. Puedes usar Adobe Air mobile siempre y cuando te asegures de que tu cliente va a tener terminales con el procesador Arm7, y le dejes bien claro (por escrito) que no funcionará con terminales que no lo tenga, para evitar sorpresas posteriores. Aquí puedes elegir el que quieras y usar la guía para programadores con prisa de mi anterior post.

Nada más, si quieres saber de qué va todo esto, puedes ver mi posts anteriores sobre desarrollo de aplicaciones móviles multiplataforma:

• Parte 1: Aplicaciones móviles: web vs nativas vs multiplataforma.
• Parte 2: Desarrollo de aplicaciones móviles multiplataforma: Phonegap y Titanium Appcelerator.
• Parte 3: Aplicaciones móviles multiplataforma: Corona y Adobe Air mobile.