Bien, Symfony es un framework de PHP para el desarrollo de aplicaciones web, creado por SensioLabs. Cómo cualquier framework que se precie, se basa en el patrón MVC, pero además, nos permite flexibilidad en cuánto a qué tecnologías utilizar para ello.

En nuestro caso emplearemos Twig para las vistas, Doctrine para el modelo, y el propio Symfony cómo framework sobre PHP para el controlador.(La versión empleada de Symfony será la 2+ , de modo que el tutorial puede no ser compatible con Symfony 1.5 e inferiores…)

Instalando Symfony

El primer paso será acceder a la web de Symfony y descargar el .zip con los fuentes, en nuestro caso elegiremos la siguiente versión:

http://symfony.com/download?v=Symfony_Standard_Vendors_2.1.4.zip

Una vez descargado, extraemos su contenido en el raíz de nuestra aplicación.

Una vez hecho esto, si accedemos a través del navegador a la siguiente URL:

http://localhost/nuestraAplicacion/web/app_dev.php

Podremos ver la página de bienvenida de Symfony que nos indica que el proyecto está montado correctamente.

Symfony instalado correctamente

Una vez hecho esto y para asegurarnos de que nuestra instalación de PHP es adecuada para Symfony, podemos acceder a la siguiente URL:

http://localhost/nuestraAplicacion/web/config.php

Puntos a corregir en la instalación de PHP

y corregir los puntos que indique, en caso de indicar algo.

Una vez hecho ésto, podemos acceder al entorno de desarrollo y ver la única URL accesible de momento.

http://localhost/nuestraAplicacion/web/app_dev.php/demo/hello/igomez

Ejemplo action con parámetro de un controller que devuelve un render de una vista

Creando nuestro bundle

Una vez tenemos Symfony instalado correctamente, es hora de comenzar con nuestra aplicación. Para ello, lo primero que vamos a hacer es crear los diferentes bundles en que ésta va a dividirse.

Un bundle es una forma de empaquetar diferentes apartados de nuestra aplicación.

En nuestro caso crearemos 2, uno para el frontend de la aplicación y otro para el backoffice, ya que son dos ámbitos diferenciados e independientes de nuestra aplicación.

Lo haremos a través de los comandos que pone a nuestra disposición Symfony, mediante línea de comando.(Debemos tener PHP configurado para ejecutar tareas por este medio)

php app/console generate:bundle --namespace=watchKeeper/frontEndBundle --format=yml

bundle namespace:[watchKeeper/frontEndBundle]
bundle name: [ffrontEndBundle]

Target directory [C:/Users/igomez/Desktop/Mowes/www/watchKeeper/watchKeeper/sr
c]:

Determine the format to use for the generated configuration.

Configuration format (yml, xml, php, or annotation) [yml]:

To help you get started faster, the command can generate some
code snippets for you.

Do you want to generate the whole directory structure [no]?

You are going to generate a "watchKeeper\frontEndBundle\frontEndBundle" bundle
in "C:/Users/igomez/Desktop/Mowes/www/watchKeeper/watchKeeper/src/" using the
"yml" format.

Do you confirm generation [yes]? yes

  Bundle generation

Generating the bundle code: OK
Checking that the bundle is autoloaded: OK
Confirm automatic update of your Kernel [yes]? yes

Enabling the bundle inside the Kernel: OK
Confirm automatic update of the Routing [yes]? yes
Importing the bundle routing resource: OK

  You can now start using the generated code!

c:\Users\igomez\Desktop\Mowes\www\watchKeeper\watchKeeper

Ésto creará la estructura completa de nuestros bundles, dentro del directorio src de nuestro proyecto.

En nuestro caso las rutas generadas serán:

src/watchKeeper/frontEndBundle

src/watchKeeper/backOfficeBundle

La estructura básica del bundle contiene algunos directorios esenciales con los que estructurar nuestra aplicación.

Controller-> dónde guardaremos nuestros controllers, que serán los paquetes encargados de contener nuestros actions y funciones.

Resources/config-> aquí se encuentra el routing.yml que contiene las rutas(URLs) de nuestro proyecto

Resources/public-> aquí alojaremos los css,js, imágenes y demás recursos específicos de nuestro bundle.

Resources/translations->directorio para los ficheros de textos en diferentes idiomas (messages.es.xliff, messages.en.xlf…)

Resources/views->aquí guardaremos las plantillas .twig de nuestro bundle, que se corresponderán a las diferentes pantallas.

De momento tenemos Symfony funcionando y hemos creado los bundles de nuestra aplicación.
Lo siguiente que deberemos hacer será crear los controllers, y views de nuestro proyecto y configurar nuestro routing con las URLs que queramos para nuestras pantallas. Lo veremos, en el siguiente post.

Lo que hoy venimos a destacar aquí es que una de las muchas ventajas del OpenCMS es que permite el uso de módulos. Sinceramente, desde mi humilde punto de vista, la comunidad open source externa a la empresa que promueve el opencms (Alkacon) es pequeña, lo que hace el número de módulos del opencms no sea muy grande. Y eso hace que los módulos realmente necesarios sean promovidos por la propia Alkacon.

La consecuencia de ésto es que Alkacon está muy centrada en el desarrollo de su producto; producto que ya va por la octava versión y media; lo cual hace del OpenCMS un producto especialmente estable y funcional. Sin embargo, no así ocurre con los módulos que liberan, y que de vez en cuando tienen pequeñas sorpresas.

Uno en concreto es el módulo de Optimización Web. Para nosotros fue una sorpresa encontrarlo entre los módulos OAMP (opencms Add On Module Package): un  módulo que permite comprimir CSS e imágenes (con el YUI compressor, como el archiconocido minify en php). Este módulo se puede encontrar en la sección de módulos opensource realizados por Alkacon: http://www.opencms.org/en/download/alkacon_modules.html 

El funcionamiento es sencillo: permite crear un elemento estructurado “optimized-js” (idem para css), en el que se definen en su interior N elementos js que se quieren unir y optimizar. Al hacer la inclusión de este elemento “optimized-js”, automáticamente “pega y minifica” los N elementos en su interior. Muy útil para comprimir JS y CSS.

El problema sin embargo es que al instalarlo en una versión OpenCMS 8.0.4 recién instalada, el elemento JS no funcionaba, y provocaba el siguiente error: “Not supported resource type 282 of given resource /sites/default/….”. 

Curiosamente, lo mismo ocurre con los elementos de ejemplo que el propio módulo trae consigo.

 ¿Existe solución?

Afortunadamente, sí, y es sencilla: el problema viene derivado por el mal uso de una constante en el módulo. Aunque no es necesario, si nos descargamos del GitHub, la versión del OAMP actual, veremos que la clase  CmsOptimizationJs tiene una variable estática RESOURCE_TYPE_JS de valor igual a 762; es decir, que el módulo debería importar el objeto “optimized-js” con un ID igual a 762. Sin embargo, si al importar el módulo abrimos el opencms-modules.xml, y buscamos el “optimized-js”, veremos que su ID es 282.

Por lo tanto, la solución es sencilla: se debe editar el opencms-modules.xml una vez importado el paquete, cambiar el ID 282 por 762, guardar y reiniciar el servidor de aplicaciones. OJO: lo mismo ocurre con los CSS y los sprite, por lo que se deben cambiar los ID 282, 283 y 284, por 762, 763 y 764 respectivamente.

Una vez realizado esto, todo debería funcionar. Es importante destacar que si ya tienes elementos definidos, el sistema no los reconocerá. Puedes (a) eliminarlos y volver a crearlos, o (b) Cambiar el tipo en las opciones avanzadas del menú contextual al seleccionar el objeto.

Si has llegado aquí buscando el error, esperamos haber solucionado vuestro problema.

Por cierto, hay una comunidad de habla hispana en torno al opencms llamada OpenCMS hispano: http://www.opencmshispano.com

Si vienes de trabajar con Hibernate, sabrás que podemos usar las formulas para calcular al vuelo aquello que nosotros queramos. En nuestro caso, estas formulas las encontraremos en la documentación de Gorm bajo el nombre de Derived Properties.

Pongamos un ejemplo sencillo:

class Rectangulo{
String nombre
Float base
Float altura
Float superficie
}


Lo primero será declarar los campos en nuestro domain. Nosotros para el ejemplo hemos usado Base, Altura y Superficie, siendo esta última variable donde guardaremos el resultado de la formula.

¡Pero yo no quiero que persista en BBDD! -Tranquilo, los campos que definimos como resultados de formulas no persisten en base de datos

Lo próximo que haremos será añadir al “Mapeo” la formula que queramos.


class Rectangulo{
String nombre
Float base
Float altura
Float superficie

static mapping = {
superficie formula: 'BASE * ALTURA'
}
}


De esta manera cada vez que hagamos la consulta a la BBDD para obtener el o los objetos Rectangulo, este nos devolverá todos los campos y la superficie calculada.

¡Pero mis campos no se llaman así! -Tienes razón, las fórmulas pertenecen al modelo de datos que estamos usando y no tienen nada que ver con nuestros objetos, tendremos que usar los nombres que tienen en BBDD


// Objeto Rect1 tiene una altura de 5 y una base de 10
def rect1 = Rectangulo.findByNombre(Rectangulo.RECT1)
def superficie = rect1.superficie

println(superficie) //Pinta 50


Realizando una sentencia como la siguiente

select
rectangulo0_.id as id1_0_,
rectangulo0_.nombre as nombre1_0_,
rectangulo0_.version as version1_0_,
rectangulo0_.base as base1_0_,
rectangulo0_.altura as altura4_1_0_,
rectangulo0_.BASE * rectangulo0_.ALTURA as formula1_0_
from
rectangulo rectangulo0_
where
rectangulo0_.name=?


Pese a no persistir en base de datos, Grails nos da además la oportunidad de realizar búsquedas sobre ese campo mediante los “Dynamic Finders”, de este modo podríamos realizar la siguiente consulta

Rectangulo.findAllWhereSuperficieGreaterThan(valor)


La complejidad de las formulas puede aumentar en base a nuestras necesidades, así que anímate a usarlas que son muy útiles para realizar cálculos sin obstaculizar el flujo de tu web.

Consultar datos para mostrar en el frontOffice

Cualquier módulo que créemos tendrá que mostrar cierta información en pantalla, o tener alguna clase de funcionalidad. En nuestro caso, al haber creado un bloque, queremos que éste muestre información sobre las ofertas especiales de nuestra tienda, para ello, vamos a modificar nuestro método ” function hookLeftColumn($params)” qué es el encargado de mostrar nuestro bloque en la columna izquierda.
(Efectivamente ésta funcionalidad ya la ofrece el blockSpecials, pero para nuestro ejemplo básico no vamos a complicarnos demasiado)

Cómo ya hemos visto anteriormente, la lógica de negocio se ejecuta desde la capa de controlador, por lo que és ahí dónde deberemos realizar las consultas oportunas para recuperar la información deseada, ésto es, en nuestro fichero “testmodule.php”.

function hookLeftColumn($params){
		global $smarty;

		if ($special = Product::getRandomSpecial(intval($params['cookie']->id_lang)))
			$smarty->assign(array(
			'special' => $special,
			'priceWithoutReduction_tax_excl' => Tools::ps_round($special['price_without_reduction'] / (1 + $special['rate'] / 100), 2),
			'oldPrice' => $special['price'] + $special['reduction'],
			'mediumSize' => Image::getSize('medium')));

		return $this->display(__FILE__, 'testModule.tpl');
	}

Primero, definimos una variable global $smarty, que será un array dónde almacenaremos cualquier información que queramos que esté disponible desde las .tpl (Vista).

Después crearemos una variable $special para almacenar los resultados de nuestra consulta, y para ello utilizaremos la función getRandomSpecial de la clase Product que nos ofrece Prestashop.
(Para conocer más funciones disponibles, basta con entrar al directorio classes en el directorio raíz de prestashop e inspeccionar la clase deseada)

Una vez recuperada la información pasaremos a hacerla disponible para la capa de Vista, asignando a la variable global $smarty un índice llamado “special” que contendrá un array con los resultados de la consulta a bbdd.

Hecho ésto continuamos con la presentación de la plantilla .tpl

Recorrer los datos y mostrarlos en el frontOffice

Para recorrer los datos en nuestro bloque del frontOffice deberemos recuperar la información del array global $smarty.

<!-- Block testModule -->
<!-- @import url({$base_dir}modules/testModule/css/testModule.css); -->
<div id="testModule_block_left" class="block">
<h4>{l s='testModule Block' mod='testModule'}</h4>
<div class="block_content">
{if $special}
<ul class="products">
	<li class="product_image">
				<a href="{$special.link}"><img title="{$special.name|escape:html:'UTF-8'}" src="{$link->getImageLink($special.link_rewrite, $special.id_image, 'medium')}" alt="{$special.legend|escape:html:'UTF-8'}" width="{$mediumSize.width}" height="{$mediumSize.height}" /></a></li>
	<li>
<h5><a title="{$special.name|escape:html:'UTF-8'}" href="{$special.link}">{$special.name|escape:html:'UTF-8'}</a></h5>
				<span class="price-discount">{if !$priceDisplay}{displayWtPrice p=$special.price_without_reduction}{else}{displayWtPrice p=$priceWithoutReduction_tax_excl}{/if}</span>
				{if $special.reduction_percent}<span class="reduction">(-{$special.reduction_percent}%)</span>{/if}
				<span class="price">{if !$priceDisplay}{displayWtPrice p=$special.price}{else}{displayWtPrice p=$special.price_tax_exc}{/if}</span></li>
</ul>
			<a class="button_large" title="{l s='All specials' mod='testModule'}" href="{$base_dir}prices-drop.php">{l s='All specials' mod='testModule'}</a>

{else}

{l s='No specials at this time' mod='testModule'}

{/if}</div>
</div>
<!-- /Block testModule -->

Cómo podéis apreciar, para utilizar propiedades de un objeto en una plantilla de Smarty basta con utilizar la siguiente sintáxis:
{$special.link}
dónde $special es el objeto, en éste caso un array asociativo, y link es un campo de ese array.

Módulo en el frontOffice

Con ésto, ya seríamos capaces de construir nuestro propio módulo para mostrar cierta información. A partir de aquí, tan sólo nos quedaría investigar un poco los fuentes de prestashop para ver hasta dónde podemos llegar.

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?