Sin una idea preconcebida más allá de lo indicado, nos fuimos a que nos hablaran de Cassandra y CouchDB. Ya hemos tocado a veces algo de MongoDB, de manera que el tema no podía ser más complementario.

La teoría, básicamente, se centra en otra visión del Teorema de CAP, que viene a decir que no puedes tener más de 2 de las 3 gracias que todo sistema computacional distribuido puede aportarte: Consistency, Avalilability, Partition.

Es decir, el SQL de siempre se ha centrado mucho en la C y en la A, dejando la P para sistemas tan grandes que no había probablemente en aquel entonces. Hoy (varios años atrás en realidad), la P empieza a tener más importancia, dadas las ingentes cantidades de datos a procesar de manera suficientemente rápida, en aplicaciones web tales como Facebook o Twitter.

En los casos que nos ocupan, ganamos un mucho de P, penalizando un poco de C, de manera que es habitual que las bases de datos NO-SQL tengan lo que viene a llamarse “consistencia eventual”, algo así como “puede que lo que ves no sea lo que debes ver, pero si te esperas unos milisegundos, entonces seguro que sí”.

Además, prácticamente todas las NO-SQL tienen un punto en común: son orientadas a documento, y no existen las joins (que consumen demasiado en consultas sobre volúmenes de datos gigantescos).

Cassandra

Originalmente creada por Facebook y donada a Apache como software libre, se trata de una de las más relevantes a nivel mundial, usada por el propio Facebook, Twitter, Digg, entre otros.

Funciona mediante la creación de clusters de bases de datos a partir de nodos que pueden añadirse como nuevas instalaciones en nuevos servidores en cualquier momento. Modificando el fichero “conf/cassandra.yaml”, podremos configurar los distintos nodos, indicando, por ejemplo:

- Nombre del Cluster: Si dos nodos tienen el mismo nombre de cluster, son del mismo cluster. Fácil, no?

- Nodos Seed: Nodos especiales que se encargan de la comunicación y propagación de los datos entre todos ellos. Se recomienda que haya al menos 2 por cluster.

- Replication Factor: ¿Cuántas copias de la misma información quieres tener? Algo así como responder a “a cuántos fallos quieres ser inmune?”.

Con pocos parámetros más, a funcionar con un “cassandra -f” (si queremos ver los logs en foreground), incluso con un sólo nodo

Una vez levantado el servidor, podremos hacer uso del comando “cassandra-cli”, con el que podremos conectarnos a nuestra base de datos y tirar comandos como:

- show keyspaces: lo que sería análogo a un “show databases”

Los conceptos de guardado de “documentos” en Cassandra son los siguientes:

- keyspace: viene a ser un espacio de datos a nivel de base de datos de sql.

- columnfamily: viene a ser un conjunto de columnas que definen datos de un registro. Viene a ser algo similar a una tabla en sql, por la salvedad de que cada fila (row) puede tener unas columnas u otras. (Imaginad toda una base de datos sql condensada en una super-tabla con todos los campos nullables para poder dar salida a cualquier entidad).

- column: campo de dato de una fila, que se agrupan en columnfamilies. Viene a ser como un campo (field) de una tabla de sql, con la salvedad de que contiene siempre un nombre, un valor, y un timestamp.

- supercolumn: columna especial que permite tener dentro a otras columnas (no se pueden mezclar con columnas en un columnafamiliy, y hay dos niveles a anidamiento).

- Orden: cada columnfamily tiene configurado a priori sobre qué campo se va a poder ordenar

En general, la idea es que primero pienses qué consultas quieres realizar, y en base a ellas generes el modelo de datos como si fueran tablas denormalizadas de sql, y cada tabla responde a “su” consulta. Esto se puede hacer con sql, porque eres tú el encargado de mantener un determinado dato si está en varias columns, de manera que, por qué Cassandra? Porque si necesitas más rendimiento, aprovechas la “P” y con meter un nuevo nodo de manera muy sencilla lo vas a tener.

Programáticamente, se accede a Cassandra vía Thrift, una interfaz de comunicación que tiene implementaciones en casi todos los lenguajes. En particular, para Java, tenemos la librería Hector, que nos permite realizar las típicas acciones CRUD, etc… Se habla de que Avro será la nueva interfaz que entierre a Thrift, ya que parece que no tienen demasiado movimiento como proyecto libre.

Por último, a partir de la versión 0.8, disponemos de CQL (Cassandra Query Language) que nos acerca la sintaxis de Casssandra a SQL, que los que usamos HQL no podemos otra cosa que agradecer

CouchDB

En la misma situación que Cassandra en cuanto a importancia de la A y la P del Teorema del CAP, CouchDB es una sorprendente implementación de base de datos NO-SQL, por su total orientación web. Desde su gestión a través de documentos JSON, hasta su interfaz RESTful, sorprende el diseño de esta base de datos.

Se instala en nodos, de manera distribuida, y se posibilita el uso offline de los mismos, de manera que si un nodo se cae de la red, puede seguir operando y sincronizarse con el resto cuando esté de nuevo online (esto hace su uso especialmente indicado para plataformas móviles). Para la sincronización de datos, se usa un modelo tipo SVN (MVCC), en el que se van marcando las versiones de los documentos guardados. Ojo a datos muy cambiantes que pueden hacer crecer la base de datos demasiado para nuestros intereses; por suerte, se puede configurar el número de históricos a guardar.

A diferencia de Cassandra, el cliente de CouchDB no es otro que cualquier cosa que implemente el protocolo HTTP, con el siguiente mapeo simple de acciones:

- GET: Es un “read” de CRUD.

- POST: Es un “create” de CRUD

- PUT: Es un “update” de CRUD

- DELETE: Es un “delete” de CRUD

Es decir, RESTful.

Casi cualquier lenguaje de programación tiene implementados estos métodos HTTP, de manera que, por ejemplo, podríamos generar aplicaciones vía AJAX directamente contra la base de datos sin la necesidad de una capa servidora (:-O). De hecho, como CouchDB es un servidor HTTP en sí mismo, es posible “subir” aplicaciones html+javascript y hacerlas funcionar directamente en la base de datos.

Otra de las gracias que tiene es que la “programación” es vía javascript. Todo.

Es posible generar “vistas” (en cierto modo análogas a las de SQL) definiendo un método map que determinará si un documento (las vistas se aplican primero a tooooodos los documentos y luego incremental, como si fueran vistas materializadas de SQL) entra en dicha vista o no. Esto nos permite generar respuestas a consultas que no tienen por qué estar directamente mapeadas en los datos, pero además, si acompañamos a la función map con una función reduce, podemos realizar distintos tipos de agregaciones, desde counts, sums, etc… hasta lo que se nos ocurra que podamos hacer con una función javascript. Esto nos da muchas posibilidades

Es posible generar validadores javascript para controlar un determinado valor de un campo obligatorio o cosas así.

Es posible generar show/list que permitirán ver respuestas diferentes a JSON (por ejemplo, HTML, XML, etc…) de un determinado documento o conjunto de los mismos.

NO-SQL, no relations

Es posible generar funciones update que creará o modificará documentos.

…

Todo esto se puede gestionar vía navegador, o un cliente http cualquier tipo curl, pero una de las mayores gracias que tiene CouchDB es su “Futón“, que nos hará la vida más sencilla. Se trata de una interfaz web que nos permitirá gestionar las bases de datos, documentos, vistas y demás elementos de nuestra instancia.

En particular, nos ayudará mucho a gestionar un tipo de documento especial, los documentos “de diseño”, que contienen todos los elementos anteriores.

Como la sintaxis de su definición no es simple, y se trata de objetos json no demasiado intuitivos, la guinda del pastel de CouchDB: CouchApp.

CouchApp es un framework de creación de aplicaciones que permite generar documentos de diseño de CouchDB de manera mucho más sencilla.

En fin, que a modo de resumen y de primer contacto con estas NO-SQL, espero que os pueda servir para que os hagáis una idea. En general, me parece que la mayor gracia está en las posibilidades de escalabilidad horizontal que nos dan estas bases de datos (la P del CAP), así como su rendimiento, pero a cierto coste computacional en las aplicaciones que generemos sobre ellas.

¿Trabajáis habitualmente con NO-SQL? ¿Tenéis alguna aplicación donde os hubiera gustado usarlas? ¿Os habéis encontrado con problemas de escalabilidad SQL que compense migrarlo todo a una NO-SQL? ¿Pensáis que no todo el monte es orégano y que no es para tanto? ¿Una moda pasajera tal vez?

• Arreglo de bugfixes, muchos relacionados con la autenticación. En nuestro caso, no nos habíamos encontrado con ninguno.
• Ya se puede utilizar logrotate con windows (¿alguien usa windows con mongodb?)
• Mejoras con capped collections y replica.

Se puede ver todo el ChangeLog en su JIRA: https://jira.mongodb.org/browse/SERVER/fixforversion/11001

Se puede actualizar sin ningún problema desde la versión 2.0.2 a la versión 2.0.3, utilizando vuestro gestor de actualizaciones favorito.

Se recomienda empezar con los SECONDARY, y luego con los PRIMARY. Por último, actualizad vuestro cliente, y ala, ya tenemos mongo actualizado sin dolores de cabeza.

A continuación mostramos una guía paso a paso. Esta guía se ha realizado en Febrero de 2012, y puede que en un futuro el panel haya modificado (por ejemplo, recientemente han incorporado la posibilidad de indicar tu cifrado SSL). Allá vamos:

- Primero vas a necesitar el certificado público y la clave privada, para que el ELB lo muestre. El certificado, lógicamente, lo debes pedir a tu suministrador de certificados (verisign, geotrust, rapidssl, etc.). Generalmente te piden el CSR, y con ello, te devuelven el certificado en formato PEM. Eso es lo que necesitas. El único punto a tener en cuenta es que al generar el CSR, debes exportar también la clave privada. Para ello, puedes hacerlo como se indica a continuación:

openssl req -nodes -newkey rsa:2048 -keyout claveprivada.key -out midominio.csr
openssl rsa -in ./claveprivada.key -out claveprivada.pem

- Como puedes ver, primero se genera el CSR (te pedirá los datos del certificado), y en segundo lugar, se convierte la clave privada a formato PEM (formato necesario para Amazon).

- Haz la petición de tu certificado a tu entidad certificadora.

- En el servicio ELB (dentro de EC2, del panel de Amazon AWS), pulsa sobre “Crear Nuevo Balanceador”.

- Configura los listeners. Verás uno configurado inicialmente (http 80 > http 80). Aquí tienes dos opciones:

• Agregar https (443) > http (80) [ SSL desde cliente a ELB, pero NO SSL desde ELB a servidor ]
• Agregar https (443) > http (443) [ SSL total, desde cliente a servidor ]

La diferencia está en lo que el servidor web verá, ya que lo que hace el ELB es transformar la petición HTTPS y traspasarla a HTTP (primer caso) o HTTPS (segundo caso). En el primero de los casos, el servidor web pensará que está dando un servicio HTTP (aunque hasta el balanceador llega con SSL), y en el segundo un servicio HTTPS. De ese modo, piensa qué es lo que más te interesa a tí (la segunda opción tendrá como desventaja que el servidor web también tendrá que procesar el desencriptado SSL).

- Pulsa “save” y continuar.

- Ahora te pedirá los datos del certificado: la clave privada (el contenido del archivo “claveprivada.pem”), el certificado público (lo que te envíe la entidad certificadora) y cualquier certificado intermedio (idem).

- Una vez que los introduces, te pedirá escoger el conjunto de cifrados SSL que deseas proporcionar desde la terminación ELB. En principio, la selección inicial por defecto es suficiente para un buen balance entre el rango más común de navegadores y la seguridad del cifrado. Si aun así, necesitas gestionar más concretamente dichos cifrados, el balanceador lo permite. Aquí puedes obtener más información sobre cómo modificar los cifrados SSL de tu ELB.

- Y el resto de parámetros, son los mismos que en un ELB normal.

Esperamos que esta guía te haya servido. A nosotros lo que nos faltó inicialmente fue la conversión de la clave privada al formato PEM que requiere el ELB (sino te indica que “Private Key not valid”).

Si tienes dudas, pregunta pregunta

En CentOS también ocurre, ya que la versión que hay en EPEL de gearman es la 0.14. Por lo tanto, se recomienda descargar gearman e instalar.

Pero al hacerlo, nos encontraremos con un problema que también nos hemos encontrado con Ubuntu:

checking Boost headers version >=1.39.0...no
 configure: error: cannot find Boost headers version >=1.39.0

El problema aquí es que la versión de boost en CentOS 5 es la 1.33, y por tanto, no nos vale para Gearman.

Para resolverlo:

- Añadir el repositorio EPEL si no lo tenemos ya (instrucciones aquí)

- Instalar boost141 boost141-devel mediante yum (yum install boost141-devel boost141)

Si ahora intentamos ejecutar “configure”; nos dará todavía el mismo error, y es que boost141 se instala en otra ruta. Se puede solucionar gracias al mail de google-groups localizado aquí.

Además de lo indicado, yo tuve que ir a la carpeta /usr/lib/boost141 y copiar todo su contenido a la carpeta /usr/lib para que lo encontrara el configure.

¡ Esperamos que os funcione !

Sencillo, Phonegap es un framework para desarrollar aplicaciones móviles que es un claro sinónimo de sencillo. Basándose en tecnologías como HTML, CSS, Javascript, JQuery o Sencha Touch entre otras podremos realizar nuestras aplicaciones móviles en muy poco tiempo, todo depende de los conocimientos de programación web de los que dispongas, desde luego la curva de aprendizaje de Javascript o HTML siempre son mucho menos pronunciadas que aprender Cocoa y Objetive C.

¿Qué hace?

Este conjunto de herramientas, porta casi cualquier código HTML, CSS, Javascript y demás en código nativo listo para compilar en el SDK. Abstrayendo al programador de aprender código nuevo y/o más complejo, agilizando así el desarrollo y el mantenimiento de las aplicaciones.

¿Cómo?

Phonegap basa todo su potencial en un fichero javascript y una librería que se encargan de hacer el port de un lenguaje a otro. Aparte, dispone de varias API´s para poder interactuar con elementos nativos del dispositivo como la cámara de fotos o vídeo, el acelerómetro, las redes, etc. Si queremos usar los elementos propios de la interfaz gráfica del SO (pj: En iOS los navigation tool bar o los tab bars) también es posible acceder a los mismos mediante la instalación de plugins como NativeControls.

¿En qué me beneficia?

El tiempo de desarrollo es menor, bastante menor. Posiblemente sea más sencillo encontrar un programador web que un programador de iOS o Android. Es más probable disponer de un trabajador en plantilla que pueda desarrollar código HTML, Javascript y JQuery.
Y por último, pero no por ello menos importante, podremos disponer de una web basada en la aplicación móvil sin muchas dificultades o portar un proyecto web a aplicación móvil en tiempo récord.

¿Es fácil de usar?

Sí. Necesitarás bajarte el SDK correspondiente a la plataforma para la que estés desarrollando, yo pondré por ejemplo Android e iOS que son con las que he estado trabajando, así que, Eclipse y XCode 4 respectivamente. En el caso de eclipse podremos descargarnos el siguiente plugin:

https://svn.codespot.com/a/eclipselabs.org/mobile-web-development-with-phonegap/tags/r1.2/download

Esto nos generará un icono para poder realizar proyectos con phonegap de manera sencilla, dándonos la posibilidad de introducir las librerías de JQuery o Sencha directamente. Por defecto nos dirá para usar una versión que el plugin considera la última para crear el proyecto, si no estamos de acuerdo, siempre podremos introducir el Path de fichero de Phonegap que nosotros queramos.

En el caso del XCode, cuando nos descargamos los archivos de la web de Phonegap, tendremos en la carpeta de iOS un .dmg que nos instalará el plugin directamente en el XCode, con esto cuando creemos nuestra aplicación usaremos la opción “Phonegap Based Aplication”.

En ambos casos es necesaria una caperta “www” en el proyecto donde meteremos nuestros ficheros .html, .css y .js así como el fichero phonegap-version.js.

Video oficial de Phonegap @ YouTube

Venga, va… ¿No serás comercial de Phonegap, no?

La verdad es que no. Como siempre, no es oro todo lo que reluce y Phonegap tiene sus carencias. En principio no tiene trazas, y hacer debug de una app móvil se puede convertir en un verdadero incordio por mucho “console.log()” o “alert()” que tengamos en javascript.
Por otro lado Phonegap es rápido, pero código puramente nativo es más rápido aún.

Por último, si nuestro proyecto es de una complejidad muy elevada, deberíamos de plantearnos si usar este framework o no, ya que las API´s se nos podrían quedar algo limitadas, como por ejemplo el uso de la cámara del dispositivo u controles nativos específicos a los cuales no podamos acceder mediante los plugins de terceros.

¿Existe alguna alternativa?

Si nos ponemos un poco frente a Google, encontraremos AppGeiser o Titanum. Yo personalmente me quedo con Phonegap ya que el resultado que nos está dando es muy satisfactorio.

Appcelerator Titanium

AppGeyser

¿Conocéis algún otro framework? ¿Habéis trabajado con Phonegap o cualquier otra herramienta de este tipo? Cuéntanos tus experiencias con este tipo de herramientas en los comentarios.

Un saludo!

Para los tests, hemos elegido a “ab”, que como ya se tiene directamente en Ubuntu, parecía la opción más “normal”.

Si bien es muy sencillo de usar, os dejo el enlace a su página oficial, donde podéis consultar el detalle de cada opción.

Nosotros hemos tirado la siguiente prueba:

ab -n 10000 -c 1000 http://vitallogistics.es/

Es decir, hemos tirado un total de 10000 peticiones, con 1000 de ellas concurrentes, con un ssh abierto al servidor por lo que pudiera pasar.

Los resultados que nos da ab son los siguientes:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking vitallogistics.es (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software:        Apache/2.2.3
Server Hostname:        vitallogistics.es
Server Port:            80

Document Path:          /
Document Length:        55 bytes

Concurrency Level:      1000
Time taken for tests:   73.232 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Non-2xx responses:      10000
Total transferred:      4890000 bytes
HTML transferred:       550000 bytes
Requests per second:    136.55 [#/sec] (mean)
Time per request:       7323.236 [ms] (mean)
Time per request:       7.323 [ms] (mean, across all concurrent requests)
Transfer rate:          65.21 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       24  817 2848.3     51   25652
Processing:    24 1271 3818.2     89   59049
Waiting:       24 1249 3763.0     89   59049
Total:         53 2088 4879.3    185   62111

Percentage of the requests served within a certain time (ms)
  50%    185
  66%    420
  75%    931
  80%   3126
  90%   7301
  95%  11156
  98%  14142
  99%  24905
 100%  62111 (longest request)

Es decir, nos da un buen número de datos generales, como el tiempo totales invertidos en la prueba, el tamaño total descargado, número de errores, tiempos medios de respuesta y velocidad media de la respuesta .

Pero lo interesante, creemos, de interpretar, viene al final.

Podemos ver en qué parte de la petición se está consumiendo qué tiempo. Si es en la conexión y procesamiento de la petición, puede que nuestro equipo sea el cuello de botella (desde donde hacemos las peticiones), pero si el tiempo está en la espera, entonces tenemos un potencial de mejora en la configuración del apache.

Finalmente, podemos ver qué porcentaje de peticiones han sido atendidas en un determinado tiempo. Tiene una interpretación muy interesante. En nuestro caso, por ejemplo, el 75% de las peticiones se respondieron en menos de un segundo, un 95% antes de once segundos (ya es mucho, pero en un escenario de 1000 concurrentes significa que a 950 se les responde antes de 11 segundos) y sólo a un 2% se les responde en más de catorce.

Un ejercicio paralelo interesante mientras se hace la prueba es tirar un “top” en el servidor de destino para ver los hilos del apache multiplicarse para atender las peticiones, y ver si el consumo de memoria se acerca al barranco del swapping, donde tendremos un descenso acusado del rendimiento (añade RAM para evitarlo), o si estamos llevando al límite a la CPU (añade otra…).

En fin, que una prueba sencilla, de un par de minutos, puede darnos suficiente información como para dejar tranquilos a los clientes o realizar acciones preventivas antes de llegar a tener caídas de rendimiento significativas sin control.

¿Hacéis pruebas de este tipo habitualmente sobre vuestros entornos de producción o son los departamentos de sistemas de vuestros clientes quienes se encargan? ¿Tenéis algún software de testing similar? ¿Es el rendimiento final algo que se tiene en cuenta en vuestros desarrollos o suele quedar para el mantenimiento / fase 2?

Para ello, tras las habituales y típicas tareas de generación de índices en la base de datos, lo que nos ha permitido agilizar los tiempos únicos de acceso a diferentes pantallas (esto daría para otro post, si me animáis me animo…), nos encontramos con la necesidad de medirnos y hacer previsiones de cuánta carga podremos soportar. Es decir, más allá de lentitudes de acceso de datos, ¿el servidor aguantará? ¿a cuántos usuarios concurrentes podemos dar servicio? ¿estamos exprimiendo todo lo que podemos a la máquina?

Estas y otras preguntas surgen naturalmente ante el alud que esperamos tener (seguro que nos va bien, equipo!) en forma de requests a responder; y una de las formas de responderla utiliza esta herramienta de Apache que se llama Jmeter.

Si bien el funcionamiento, una vez hechas un par de cosas, es bastante sencillo, los inicios siempre son difíciles, de manera que paso a comentaros las diferentes fuentes de información que hemos utilizado para llevar a buen puerto nuestras pruebas de carga. Si bien la documentación oficial es estupenda, se queda un poco a medias cuando te enfrentas con el programa de nuevas, como en esos libros de cocina que en realidad saben previamente la conversión al sistema métrico decimal de otras curiosas unidades como: pizca, vaso, puñado, etc… si se me entiende la analogía.

Pues bien, lo primero que hacemos es instalarnos el cliente. Queda fuera del objetivo de este post, pero básicamente, descargar y siguiente, siguiente, siempre y cuando tengamos la versión 6 de java (¿de qué pensabais que era la “J” de “Jmeter”?). Si a alguien le interesa, se puede descargar directamente con apt-get en ubuntu.

Una vez instalado, arrancamos y vemos una pantalla tal que así:

Fría e inhóspita, esperando a que comencemos a configurar. Inicialmente, un nombre para el proyecto, definir variables globales, y la posibilidad de incluir librerías externas (para ejecutar algo que hayamos programado nosotros, por ejemplo, dentro de un plan).

Como asusta un poco, los primeros pasos los podemos ver en el siguiente vídeo y luego comentamos su contenido:

Apache JMeter – The basics tutorial from Jörg Erdmenger on Vimeo.

Básicamente, nos enseña a crearnos un “grupo de hilos” (conjunto de tests a ejecutar) sobre un “plan de pruebas” (se pueden cambiar todos estos nombres para organizarlos por proyecto, etc…), para incluir en él diferentes tests y definir cómo se van a ejecutar. Podemos elegir el número de hilos (accesos concurrentes), tiempo de “ramp-up” y planificar la ejecución para una hora determinada (si no la queremos hacer en el momento).

El que hemos utilizado esta vez es el “HTTP Request”, porque vamos a testear el rendimiento de una aplicación web, pero los hay de todo tipo disponibles según versiones (desde conexiones a bases de datos hasta consumición de web-services).

Le damos un nombre, le ponemos la ruta (path) que queremos sobre el servidor (nombre o IP) en cuestión (nunca mejor dicho), y listo, ya podemos correr el plan de pruebas. Opcionalmente, podemos incluir parámetros a enviar por get o post (incluso ficheros adjuntos), esta parte es bastante intuitiva.

Dentro de cada test, nos creamos un elemento de aserción que queramos. Esto determina cuándo una prueba se considera buena o no. Podemos poner desde aserciones de respuesta (un 200 OK, el contenido del resultado contiene la palabra “OK” o “no contiene 404″, etc…), que es la que hemos usado nosotros, pero nos ha quedado la gusa de probar las aserciones HTML, XML, XPath y MD5, que permiten, en cada caso, inspeccionar el documento html de respuesta como html, xml, una determinada ruta XPath, y el MD5 de la página resultante. Esta última me resulta especialmente curiosa (es esa página, y SÓLO ESA!!).

Bien, pero demasiado manual. Lo más recomendable es generarnos, además, dentro de los elementos de configuración, unos “valores por defecto para peticiones HTTP”. De esta manera, podemos configurar parámetros como el servidor, el puerto, protocolo, etc de una vez y reutilizarlos para todas las peticiones que tengamos. Así, por ejemplo, será fácil cambiarlo para hacer el mismo test en diferentes máquinas de un balanceo, o para entornos de desarrollo, pre-producción y producción, etc…

Lo mismo ocurre con un “manager de cabeceras http”, que permite identificarnos como un determinado navegador (si la aplicación en cuestión tiene comportamientos diferentes según este parámetro), con un determinado idioma, etc…

Muy bien, corremos el test… ¿y? ¿La primera en la frente? Bueno, en realidad no, pero si no creamos un “listener de resultados”, jmeter ejecuta, pero no muestra. Lo generamos. Por ejemplo un “informe agregado”, que nos mostrará cada uno de los tests con un porcentaje de éxito (en función de la aserción indicada en cada test), tiempos de carga, etc… Podemos generarnos listeners/informes de muchos tipos, con gráficas de lo más completo sólo con incluirlos dentro del plan.

Hasta aquí nada que no se diga en el vídeo, de manera que vamos a lo interesante. Nuestra aplicación, como casi todas, tiene un login y prácticamente el 95% de las páginas están ocultas tras él, de manera que necesitamos, por este orden:

- Hacer login; que seguro ya adivináis que se hace enviando los parámetros user/pass a la url que corresponda.

- Mantener el login para los accesos a las páginas ocultas. Es decir, la session.

Para el primer punto, ciertamente enviamos las credenciales, pero como se trata de una aplicación sobre Grails con Spring Security, se deben enviar j_username y j_password a la url “/contexto/j_spring_security_check” por POST o no funcionará. Spring es así de listo, así que ojo a cambiar el método de GET a POST.

Para el segundo punto, debemos mantener el login como una cookie de session, por lo que necesitamos un nuevo elemento de configuración: Gestor de Cookies. Simplemente con ponerlo en el proyecto, listo, él se encargará de recopilar los datos que nos devuelva el login (la cookie de session) y mantenerlo para las páginas que lo necesiten. No es necesario incluir nada, a menos que tengamos una cookie fija, especial para las pruebas o algo así.

Si alguien se lo ha preguntado, todo tiene una estructura jerárquica, de manera que cada elemento influye en sus hermanos/padres, pero no em sus tíos. Es decir, si pongo un elemento de valores por defecto DEBAJO de un test, dichas variables sólo afectarán a dicho test, y no a los demás. Así pues, el gestor de cookies debería ir al mismo nivel que los tests.

Para finalizar, en nuestros tests, necesitamos generar datos dinámicos para enviar como parámetros, de manera que necesitamos un nuevo elemento de configuración “contador” que nos permita tener valores tipo “midato0001″, “midato0002″, etc… Como lo queremos para todo el plan, lo pondremos al mismo nivel que el resto. En el contador podemos configurar un nombre, un valor inicial y un incremento hasta un valor final. En nuestro caso no hemos necesitado ningún formato especial, pero si lo necesitáis, se define como los de la clase DecimalFormat.

Ahora estaríais deseosos de incluir la variable en el valor del campo en cuestión (“user${contador}”), pero no. Resulta que no funciona. En esta página lo explican bastante bien, tiene que ver con cuándo se declaran e inicializan las variables en el momento de la ejecución. La forma de hacerlo es con un elemento nuevo, un pre-procesador de variables de usuario, que se inicializan cuando las variables del contador ya están definidas e inicializadas. Ahí sí funciona la original idea.

Con lo cual, ya tendremos el plan preparado para acceder con distintos logins / passwords generados dinámicamente (user01/pass01, etc…) a pantallas que requieren logueo previo.

Al final, el plan ha quedado de esta forma:

¡Mission accomplished!

¿Os habéis encontrado con algún problema similar en Jmeter? ¿No os pasa siempre que todos los how-to, tutoriales, etc parecen recopilaciones para gente experimentada con la herramienta en cuestión y lo más básico se queda en el aire?

¿Nos recomendáis alguna otra herramienta que tenga menos de estos pequeños trucos que tener en cuenta?

- Suponiendo directorio donde se montará “/data”, y de tipo ext4

sudo mkfs -t ext4 /dev/xvdf
sudo mkdir /data
sudo mount /dev/xvdf /data

Esto realmente no cuesta mucho, pero a veces suele ser una lata, y sobretodo, si se quiere automatizar la creación de las máquinas, de los EBS y de su montaje.

Para resolver esto, los chicos de Turnkey, han generado un proyecto EBSmount, que permite hacerlo de forma automática.
Más info en: http://www.turnkeylinux.org/blog/ebsmount

Entre las funcionalidades de esta utilidad, queremos destacar que permite:
- Montar las unidades tan pronto como perciba que están attacheadas.
- Configurar los filesystems que se usarán
- Que se monten en directorios cuyo nombre será unívocamente identificable
- Que se ejecuten hook-scripts al montarse (por ejemplo, para recoger un backup, crear enlace simbólico para un acceso directo, etc.)

Gearman in gearman.org

Estamos trabajando para un proyecto con Gearman, y algunas pruebas las hemos lanzado en nuestros servidores locales Ubuntu 11.04 y Ubuntu 11.10. Sin embargo, la instalación nos ha fallado estrepitosamente, y sin mucha mención por internet del error que nos daba. Así que nos hemos lanzado a contarlo a través del blog.

El objetivo era instalar Gearman y la extensión Gearman para PHP.

La primera instalación la hemos podido cumplir sin problemas:

sudo apt-get install gearman libgearman-dev

Sin ningún problema, instalación realizada.

La segunda parte era instalar la extensión Gearman para PHP:

sudo pecl install gearman

Y el fatídico error que nos devuelve el phpize es:

checking for gearman_client_set_context in -lgearman... yes
checking for gearman_worker_set_server_option in -lgearman... no
configure: error: libgearman version 0.21 or later required
ERROR: `/tmp/pear/temp/gearman/configure' failed

Con lo que se comprueba, que la versión en los repositorios de Ubuntu son diferentes a la versión que el pecl te intenta instalar.

Así que procedemos a instalar directamente compilando la última versión del repositorio launchpad (en nuestro caso, gearman-1.0.1)

Al descargarlo y hacer el make, nos devuelve este error:

configure: error: cannot find the flags to link with Boost program_options

Que según aquí, nos dice que tenemos que instalar la librería libboost-program-options-dev.

Avisamos que además de libboost-program-options-dev, también nos ha sido necesario instalar uuid-dev.

Una vez realizadas las instalaciones, procedemos al configure, make y make install. Ahora sí, todo funciona perfectamente.

Sin embargo, nos pasa algo curioso, y es que al instalar con APT el gearman, se nos ha quedado en /usr/lib/libgearman.so una librería que hemos tenido que apuntar manualmente a /usr/local/lib/libgearman.so.

Ahora sí, si ejecutamos gearman y gearmand, funciona perfectamente.

Una vez instalado el servidor, instalamos la extensión PHP como indicábamos anteriormente, y si todo funciona bien, leeréis las últimas líneas:

sudo pecl install gearman

install ok: channel://pecl.php.net/gearman-1.0.1
configuration option "php_ini" is not set to php.ini location
You should add "extension=gearman.so" to php.ini

Felicidades. En posts siguientes os contaremos cómo han ido los procesos en Gearman. Sinceramente, parece una buenísima y sencilla utilidad. Echadle un ojo. Por cierto, ¿utilizáis alguna otra aplicación para el envío, sincronización y distribución de procesos?

ACTUALIZACION: Si tenéis problemas con que un ubuntu no encuentra las headers de boost necesarias, ejecutad sudo apt-get install libboost-all-dev

Esta nueva versión no es solo un lavado de cara a la interfaz de los teléfonos sino también un añadido considerable de nuevas características que hacen de Android un SO aún más codiciado. Realizaremos un repaso por las características y cambios más importantes en esta entrada.

System Bar y Action Bar

Android 4.0 aporta unos cuantos botones virtuales en la parte inferior de la pantalla que permite al usuario poder visualizar areas tales como los contactos o las llamadas. Estas están siempre presentes pero se atenúan ante la necesidad de una aplicación de ejecutarse a pantalla completa.
También podremos acceder a otras opciones contextuales de cada aplicaciones mediante la barra situada en la parte superior de la pantalla.

Voice Control

Se ha introducido un nuevo motor de introducción de texto por voz, una vez introducido el texto tendremos la posibilidad de añadir las palabras desconocidas al diccionario del teléfono haciendo click sobre las palabras subrayadas.

Multitask

Multitasking

Que nuestro dispositivo disponga de multitarea ya no es nada nuevo, pero Google ha conseguido renovar este concepto introduciendo una pequeña preview a modo de captura de pantalla de aquellas aplicaciones que estemos ejecutando en el momento. Esto ya lo vimos en las versiones 3.x de los tablets y es una de las funcionalidades que ha migrado hacia los teléfonos móviles.
De esta manera tenemos una multitarea más visual y agradable con la que navegar entre las aplicaciones.

Face Unlock

Es posible acceder a la cámara del dispositivo sin necesidad de desbloquear el terminal, esto nos permite realizar un desbloqueo del mismo usando la herramienta de reconocimiento facial que nos brinda Ice Cream Sandwich. Realmente no se si esta nueva funcionalidad es comoda para usar pero desde luego es bastante curiosa.

Home Screen folders

Ahora es posible crear carpeta al estilo iOS arrastrando el icono de una aplicación sobre otra en la pantalla principal de aplicaciones. Desde el punto de vista organizativo deberíais plantearos si os compensa el tener que buscar entre carpetas aquella aplicación que andeis buscando, si usais muchas aplicaciones sería una buena idea.

Notificaciones

También se han mejorado las notificaciones, pudiendo visualizarlas desde la pantalla de bloqueo o como tradicionalmente hemos estado haciendo desde la barra de notificaciones en la parte superior de la pantalla.

Widgets

Si algo caracteriza a Android son los widgets, es algo que por ahora en iOS no podemos encontrar. En esta nueva versión, se nos permite redimensionarlos y se vuelven más interactivos (controles para la música, navegar entre las tareas, etc.).

Datos

En versiones anteriores podríamos encontrar ciertas aplicaciones en el Market que nos ayudaban a tener un control sobre el gasto de datos que teníamos, cuanto tiempo estábamos hablando por teléfono, uso de la batería, etc. Ahora todo ese control pasa a ser nativo de Android, mostrando de una manera muy detalla y con un diseño y acabado estupendos.

Control sobre los datos

Control sobre los datos 2

Cámara

Declaraciones por parte de Google afirman que han estado trabajando conjuntamente con Samsung en el apartado de la cámara. Gracias a esta colaboración han podido mejorar toda la interfaz de la aplicación que maneja este apartado. Ahora es posible capturar una imagen, mover la cámara y el dispositivo irá montando las imagenes para obtener una panorámica. Ahora podemos añadir efectos, tenemos también reconocimiento facial y capacidad de compartir con nuestras redes sociales favoritas.

Entre las actualizaciones menores nos encontramos con, mejoras en copiar pegar, registro de información y la posibilidad al fin de realizar capturas de pantallas pulsando la tecla de volumen y el boton de encendido. Los diccionarios y el teclado han sido revisados, se puede ver una mejora en el auto completado o la corrección de palabras.

Conclusión

Nos encontramos ante la ultima hornada de Android y eso siempre es bueno. Viene cargada de novedades de las cuales dependiendo de nuestros usos o intereses generales usaremos más o menos. El primer terminal en disponer de este nuevo S.O sera el nuevo Galaxy Nexus que ya se encuentra en el mercado. Todavía se desconoce la lista definitiva de los terminales que actualizaran a esta nueva versión pero de momento el Nexus One se queda fuera y tendrá que recurrir a los cocineros de ROM´s para poder obtener la versión 4.0 de este tan conocido sistema operativo.