Karmacracy y como integrarlo en Blogger

Hoy en día los que tienen un medio en el cual publican contenido ya se un blog, un periódico, agregador de noticias, foro u otra forma saben que añadir una barra de botones para que los usuarios puedan compartirlo es una buena idea ya que son los propios usuarios, a los que les parece interesante el contenido tanto como para compartirlo en alguna de sus redes sociales, los que ayudan a difundirlo. Esto es bueno para los medios ya que ayuda a atraer más visitas hacia ese contenido pero hasta el momento para los usuarios el hecho de compartirlo no tiene ningún aliciente adicional, lo más, formar parte de un número de usuarios que han compartido anteriormente.

Si habéis visitado este blog alguna otra vez tal vez os hayáis dado cuenta que debajo de cada entrada y de los tradicionales botones que ofrece blogger para compartir ha aparecido un bloque a través del cual también se puede compartir las entradas de una forma muy sencilla y en un par de clics en tus redes sociales como twitter, facebook o linkedin. Este bloque es proporcionado por Karmacracy, una herramienta que descubrí hace unos meses y ha sido ahora cuando me ha convencido para añadirlo por las ventajas que puede ofrecer tanto para un medio como este como para los usuarios que comparten el contenido en él.

Para el medio porque permite conocer a los usuarios que comparten cada contenido y ayuda a formar una comunidad de usuarios.

Para los usuarios porque muy probablemente les permita conocer usuarios con los mismos intereses y conseguir más contactos y seguidores en sus redes sociales, descubrir nuevo contenido de su círculo de usuarios que puede les interese, obtener estadísticas acerca del uso del contenido compartido y divertirse compartiendo al conseguir unos premios, llamados nuts, de los que hay más de 115.

En la página de base de conocimiento y ayuda se puede obtener toda la información para conocer en detalle Karmacracy y de su fórmula vitaminada para compartir y acortar URLs.

Si la información de esas páginas te convence también para añadirlo a tu blog ahora voy a explicar como añadirlo a blogger en cada entrada. Dentro de la administración del blog vamos a la sección de Plantilla, pulsamos sobre el botón Edición de HTML y pulsamos sobre continuar, buscamos un texto tal que <div class='post-footer'> en el widget Blog1. Esta sección del html de la plantilla es la parte que aparece debajo de cada entrada en el blog con lo que al final de la misma añadiremos el código del widget de karmacracy que hemos obtenido. Algo similar a lo siguiente, a fijarse son los atributos precedidos por expr: y data:.

Dado el poco tiempo que lleva karmacracy en El blog de pico.dev la mayoría de las entradas aún están vacías de usuarios pero listas a que impulséis su contenido, desde ahora os recomiendo que preferiblemente lo utilicéis ya que me permitirá conoceros y formar una pequeña comunidad que seguro será beneficiosa para todos.

Referencia:
Karmacracy

Herramienta de construcción Gradle

Gradle es una de las muchas herramientas que existen para construir proyectos de forma automatizada pero tiene unas cuantas ventajas sobre otras que se han estado utilizado ampliamente hasta el momento como Ant y Maven en el mundo Java.

Primero vamos a ver los problemas de Ant y Maven. El problema de Ant es que para definir las tareas a ejecutar para la construcción del proyecto se utiliza XML y usar XML para describir las acciones de las tareas da resultado ficheros grandes y de difícil mantenimiento en cuanto el problema de la construcción es complicado. Otro problema es que Ant no tiene la noción de dependencias por lo que tendremos que descargarlas una a una, si posteriormente actualizamos a una nueva versión tendremos que volver revisar manualmente las dependencias que tengamos. Usando Ant con Ivy puede superarse esa dificultad. Por otra parte si tenemos varios proyectos relacionados y que dependen unos de otros la construcción de los mismos con Ant quizá no sea la herramienta más adecuada a día de hoy. A parte de esos problemas con Ant tendremos la sensación no solo de estar programando nuestro proyecto sino también la herramienta para la construcción del mismo.

Maven trata de solucionar varios defectos de Ant. En él se pueden definir las dependencias de un proyecto y Maven se encargará de descargarlas de forma automática incluyendo las dependencias que tengan estas a su vez, es decir, realizando la obtención de las mismas de forma transitiva. Además por defecto establece una serie de convenciones en cuanto a estructura de carpetas y sin que al contrario de Ant tengamos que describirla. Pero el problema de Maven empieza cuando necesitamos personalizar nuestra construcción llegando incluso a ser peor que en el caso de Ant. Los plugins de Maven suelen estar poco y mal documentados y tratar de hacer lo que queremos puede ser frustante y una pérdida de tiempo.

Gradle tiene varias de las ventajas de ambos sin poseer ninguna de sus desventajas comentadas. Posee la personalización de Ant, y la automatización de dependencias y convenciones de Maven además de un mejor soporte para la construcción de varios proyectos relacionados. Un de las primeras diferencias es que en vez de XML utiliza Groovy, un lenguaje mucho más adaptado a la tarea. Si estamos acostumbrados a Ant la migración no nos será muy complicada ya que desde Gradle podremos usar las tareas de Ant pero de una forma más cómoda que en XML al usar Groovy como lenguaje pudiendo incluso llamar a targets definidos en archivos XML de Ant. Una de las pegas que tiene es que es un poco lento en su inicialización y tal vez para tareas que usamos mucho y necesitamos que se ejecuten rápido sea más adecuado definirlas en Ant (con la opción --daemon de Gradle se soluciona en gran medida). Con tan solo definir el siguiente archivo estaremos listos para construir un proyecto web Java, en este caso para un proyecto Tapestry que utilice Hibernate, Quartz, FreeMarker, Java Mail, Groovy, HtmlUnit y Mockito:

description = 'Tapestry Project'
version = '0.0.1'

apply plugin: 'eclipse'
apply plugin: 'java'
apply plugin: 'groovy'
apply plugin: 'war'

// Propiedades de configuración
//Eclipse
downloadJavadoc = true

// Java
sourceCompatibility = 1.6

repositories { 
 flatDir name: 'Local', dirs: 'misc/lib'
 mavenRepo name: 'Apache (Staging)', url: 'https://repository.apache.org/content/groups/staging/'
 mavenRepo name: 'JBoss', url: 'https://repository.jboss.org/nexus/content/repositories/releases/'
 mavenRepo name: 'Java', url: 'http://download.java.net/maven/2/'
    mavenCentral()
}

dependencies {
 compile 'org.apache.tapestry:tapestry5-annotations:5.3.2'
 compile 'org.apache.tapestry:tapestry-core:5.3.2'
 compile 'org.apache.tapestry:tapestry-beanvalidator:5.3.2'
 compile 'org.apache.tapestry:tapestry-hibernate-core:5.3.2'
 compile 'org.apache.tapestry:tapestry-hibernate:5.3.2'
 compile 'org.apache.tapestry:tapestry-func:5.3.2'
 compile 'org.apache.tapestry:tapestry-ioc:5.3.2'
 compile 'org.apache.tapestry:tapestry-javadoc:5.3.2'
 compile 'org.apache.tapestry:tapestry-jmx:5.3.2'
 compile 'org.apache.tapestry:tapestry-json:5.3.2'
 compile 'org.apache.tapestry:tapestry-test:5.3.2'
 compile 'org.apache.tapestry:tapestry-upload:5.3.2'
 compile 'org.apache.tapestry:tapestry-yuicompressor:5.3.2'

 compile 'org.hibernate:hibernate-core:3.6.8.Final'
 compile 'org.hibernate:hibernate-ehcache:3.6.8.Final'
 compile 'org.hibernate:hibernate-validator:4.2.0.Final'

 compile 'org.quartz-scheduler:quartz:2.1.0'
 compile 'org.freemarker:freemarker:2.3.18'
 compile 'org.apache.commons:commons-lang3:3.0'

 providedCompile 'javax.servlet:servlet-api:2.5'
 providedCompile 'javax.mail:mail:1.4.4'

 groovy 'org.codehaus.groovy:groovy-all:1.8.3'

 // Test
 testCompile 'junit:junit:4.8.2'
 testCompile 'net.sourceforge.htmlunit:htmlunit:2.9'

 testCompile 'org.mockito:mockito-all:1.9.0'
}

Incluyendo los plugins de gradle eclipse, java, groovy y war algunas de las tareas que disponemos son:

• eclipse: Genera los archivos para poder importar el proyecto en eclipse incluyendo todas las dependencias del proyecto.
• clean: limpia los archivos tenporales creados por gralde en la ejecución de las tareas.
• classes: compila los archivos fuente de java, además haciendo uso del plugin de java tambien se compilan los archivos de codigo fuente de groovy.
• javadoc: crea la documentación de javadoc de los archivos del proyecto.
• jar: crea un jar con los archivos fuente de java.
• war: crea un war del proyecto.

Para ver la estructura de directorios consultar la documentación de cada uno de los plugins:

• java: http://www.gradle.org/current/docs/userguide/java_plugin.html
• groovy: http://www.gradle.org/current/docs/userguide/groovy_plugin.html
• war: http://www.gradle.org/current/docs/userguide/war_plugin.html

La cantidad de plugins para gradle va en aumento. Algunos de los más útiles son: checkstyle, codenarc, pmd, tomcat, jetty.

Para instalarlo basta con descargar sus binarios, descompromirlos en una carpeta y crear una variable de entorno para $GRADLE_HOME. Una vez hecho esto su uso es similar al de ant y maven, nos colocamos en el directorio donde está el archivo .gradle y ejecutamos:

$GRADLE_HOME/bin/gradle [tarea]

Si queremos tener una experiencia de uso más agradable con gradle es muy útil usar su modo demonio ya que de otra manera tarda en cargarse bastantes segundos, si lo usamos cada poco tiempo y muchas veces aunque luego el tiempo de las propias tareas sea poco notaremos que perdemos tiempo esperando. Para evitarlo añadimos el parámetro --daemon, notaremos mucha diferencia respecto a lo se tarda en cargarse sin él y la ejecución de nuestras pequeñas tareas serán mucho más rápidas.

$GRADLE_HOME/bin/gradle --daemon [tarea]

La diferencia es notable de casi 12 segundos a casi 5, un poco menos de la mitad.

Referencia:
http://www.gradle.org/
http://www.gradle.org/current/docs/userguide/userguide.html
Usar Gradle mediante Gradle wrapper

http://ant.apache.org/
http://maven.apache.org/
http://ant.apache.org/ivy/

Patrones de diseño en la programación orientada a objetos

La programación orientada a objetos (POO) es un paradigma en la que los sistemas se diseñan mediante clases y relaciones entre ellas. Se utilizan conceptos como la herencia, polimorfismo, abstración, encapsulamiento y ocultación. Resumidamente estas propiedades son:

• Clase: Abstracción que recoge las propiedades y comportamiento de los objetos en el sistema. Una clase puede instanciarse en objetos tantas veces como se necesite.
• Objeto: instancia de una clase que se relaciona con el resto de objetos a través de los métodos definidos en sus clases.
• Herencia: las clases no están aisladas y se relacionan entre ellas, mediante esta propiedad forman una jerarquía en la que las clases heredan las propiedades y métodos de las clases superiores.
• Polimorfismo: es la propiedad de las instancias de las clases, los objetos, por la que pueden responder de forma diferente a un mismo nombre de método en función de su tipo concreto.
• Abstracción: Permite modelar una entidad del ámbito de trabajo con las características relevantes para el sistema.
• Encapsulamiento: los elementos relacionados se agrupan juntos en una misma clase para aumentar la cohesión.
• Ocultación: las clases tienen una interfaz a través de la cual el resto de clases interactuan con ella de forma que no necesiten conocer sus detalles y evita que clases externas modifiquen el estado de manera inesperada.

Conocer estas propiedades es importante para programar en un lenguaje orietado a objetos sin embargo no es suficiente para diseñar sistemas que sean fáciles de mantener y que permitan adaptarse a nuevos cambios sin rediseñar los sistemas.

Aquí es donde aparecen los patrones de diseño y unos principios a la hora de diseñar los sistemas OO. Los patrones de diseño son formas identificadas que resuelve de forma correcta diferentes problemas comunes a algunos escenarios. Los principios son unas guías que dirigen el diseño que realizamos y que en gran medida están presentes en los patrones de diseño.

Muy resumidamente los patrones de diseño tienen como objetivo permitir hacer frente a toda constante que posee cualquier aplicación, el cambio, de tal forma que permitan escalar a los sistemas incorporando nuevas funcionalidades y prefiriendo añadir nuevo código a modificar código existente.

Algunos principios que deberían guiar nuestras decisiones son:

• Encapsula lo que varía
• Favorece la composición sobre herencia
• Programa sobre interfaces, no implementaciones
• Abierto a extensión, cerrado a cambio
• Depende sobre abstracciones, no sobre clases concretas
• Conocimiento solo de clase amigas
• No nos llames, nosotros te llamaremos
• Una clase debería tener solo una razón para cambiarla
• Inversión de dependencias

Algunos patrones identificados y que resulven de forma correcta algunos problemas son:

• Strategy
• Observer
• Decorator
• Factory
• Simple factory
• Factory method
• Abstract factory
• Singleton
• Command
• Null object
• Adapter & Facade
• Object adapter
• Class adapter
• Template Method
• Iterator & Composite
• State
• Proxy Patttern
• Compound Pattterns
• Otros
• Bridge
• Builder
• Chain of responsability
• Flyweight
• Interpreter
• Mediator
• Memento
• Prototype
• Visitor

Un muy buen libro que recoge todos estos principios y patrones es «Head First Design Patterns » y en el que se describe de forma más detallada y con ejemplos la aplicación de los principios y el uso de los patrones de una forma sencilla y bien explicada. Aunque es un libro con los ejemplos en Java es una lectura muy recomendada para cualquiera que quiera subir un nivel como desarrollador.

Después de leer el libro es buena idea tener una hoja de referencia con todos los patrones, en DZone hay una disponible que se puede descargar libremente design patterns cheat sheet. Si no quieres registrarte para descargarla usa Bug me not.

Referencia:
Programación orientada a objetos (Wikipedia)
Libro Head First - Desing Patterns de O'Reilly
Ejemplo del patrón de diseño Command y programación concurrente en Java
Ejemplo del patrón de diseño State
Ejemplo del patrón de diseño No Operation

Guía post instalación Minix

Hace ya un tiempo escribí un par de entradas sobre el sistema Minix porque tiene algunas características muy interesantes que ya les gustaría tener a otros sistemas operativos, El sistema operativo Minix donde daba una descripción de él y una Guía de instalación Minix donde explicaba como era su instalación en una máquina virtual con VirtualBox. Ahora con la reciente salida de la versión 3.2.0 de Minix y la adición de nuevas características escribo esta entrada para saber que hacer después de instalarlo con el objetivo de intentar hacer de Minix usable para algo y no quedarme con la sensación de que es algo experimental (aunque aún tengo la sensación de ello).

Los paquetes disponibles para Minix no son muchos y por tanto las posibilidades están limitadas pero en esta entrada voy a explicar algún uso útil que le podríamos dar a Minix.

Cambiar la contraseña al usuario root
Una de las primeras cosas que deberíamos hacer después de instalarlo es cambiar la contraseña del usuario root con:

# passwd

Cambiar la zona horaria
Modificaremos la zona horaria. Para ello añadimos al archivo /etc/rc.tomezone lo siguiente:

export TZ=Europe/Madrid

Crear un usuarios y grupos
Dado que Minix casi seguro no será nuestro sistema principal no nos preocupará mucho la seguridad pero deberíamos estar acostumbrados a no trabajar con la cuenta del superusuario root. Para ello podemos crear un grupo (wheel), un usuario (minix) para usarlo de forma normal en tareas no administrativas, le cambiamos de contraseña al usuario y el nombre completo del usuario (o algunos otros datos).

# group add wheel
# user add -m -g users minix
# passwd minix
# chfn minix

Editores, navegador web, correo electrónico, transferencia de archivos
Vim es un editor muy versátil y aunque el paquete de Minix no sea la última versión nos ayudará a trabajar de forma más cómoda. Hay otros editores como ed, nano y elvis. Los instalamos con el gestor de paquetes de minix, pkgin. Otros programas de utilidad básicos con un navegador web (links), un programa para enviar y leer los correos electrónicos (mutt) y programas para la trasnferencia de archivos (ftp y curl).

# pkgin install vim
# pkgin install links
# pkgin install mutt
# pkgin install curl

Servidor web, Python, OpenSSH
Si somos desarrolladores y queremos desarrollar algo básico tenemos a nuestra disposición algunos paquetes que nos lo permitirán. Estos son un servidor web (apache), el lenguaje de programación python, también podremos desarrollar programas en c, y una herramienta para conectarnos a la máquina minix de forma remota a través de ssh (OpenSSH).

Para iniciar el servicio de apache en minix ejecutarmos:

# /usr/pkg/sbin/apachectl start

Aquí podemos ver la página de bienvenida devuelta Apache y servida por la máquina minix y el típico hola mundo programado en Python y su ejecución en Minix.

# pkgin install apache
# pkgin install python
# pkgin install openssh

Juegos
También hay disponibles algunos juegos, en modo texto. Dungeon es una aventura donde iremos obteniendo una descripción de las habitaciones por donde vamos pasando y podremos realizar acciones introduciendolas en texto. gnugo es un juego de tablero del juego go donde deberemos controlar la mayor parte posible del mismo. En aop deberemos dirigir mediante las fechas del teclado un caracter que nos representa a otro punto de la pantalla evitando los obstáculos.

# pkgin install dungeon gnugo aop

Desde luego Minix no dispone de la cantidad de herramientas de otros sistemas y tampoco en sus últimas versiones, tiene casi la categoría de exprimental pero como vemos hay algunos usos que le podemos dar.

Referencia:
El sistema operativo Minix
Guía instalación Minix
http://wiki.minix3.org/en/UsersGuide/PostInstallation
http://wiki.minix3.org/en/UsersGuide
http://wiki.minix3.org/en/UsersGuide/ManagingUserAccounts
http://wiki.minix3.org/en/DevelopersGuide

Conversiones de datos entre el cliente y servidor en Apache Tapestry

Las clases que implementan la interfaz Translator en Tapestry permiten convertir el valor de un campo de texto a un objeto (a través del método parseClient) y de un objeto a un texto que será incluido en un elemento de formulario en el cliente (a través del método toClient). Esta conversión es necesaria ya que lo que enviamos al cliente y lo que recibimos de él es un String. Al recibir los datos desde cliente en el servidor necesitaremos alguna forma de convertir esos datos representados en formato texto a su representación en objeto que hagamos en el el servidor. Estas dos tareas que en un principio no son muy complejas son tremendamente necesarias y básicas en cualquier aplicación web, siendo algo básico es el framework que usemos el que debería dar un buen soporte para estas tareas. Con los translators podremos evitar repetirnos en diferentes puntos de la aplicación.

Una vez que tengamos definido el translator, Tapestry buscará el adecuado según el tipo de objeto a traducir y lo usará según sea necesario sin necesidad de que tengamos que hacer nada más. Vamos a ver un ejemplo, supongamos que en un campo de un formulario necesitamos mostrar una fecha con un determinado formato. En nuestras clases trabajaremos con objetos de tipo Date. El usuario deberá introducir la fecha con formato «dd/MM/yyyy».

...
import org.apache.tapestry5.internal.translator.AbstractTranslator;
import org.apache.tapestry5.services.FormSupport;

import com.evandti.ticketbis.domain.CodigoDescuento;
import com.evandti.ticketbis.misc.Utilidades;
import com.evandti.ticketbis.tapestry.services.TicketbisService;

public class DateTranslator extends AbstractTranslator<Date> {

 private String patron;

 public DateTranslator(String patron) {
  super("date", Date.class, "date-format-exception");
  this.patron = patron;
 }

 @Override
 public String toClient(Date value) {
  if (value == null) {
   return null;
  }
  
  return new SimpleDateFormat(patron).format(value);
 }

 @Override
 public Date parseClient(Field field, String clientValue, String message) throws ValidationException {
  if (clientValue == null) {
   return null;
  }

  try {
   return new SimpleDateFormat(patron).parse(clientValue);
  } catch (ParseException e) {
   throw new ValidationException(message);
  }
 }

 @Override
 public void render(Field field, String message, MarkupWriter writer, FormSupport formSupport) {
 }
}

Estamos extendiendo una clase del paquete org.apache.tapestry5.internal que es algo no recomendado pero la utilizamos por sencillez y para no tener que implementar nosotros lo que hace el propio AbstractTranslator. Para que Tapestry lo utilice deberemos hacer una contribución en el módulo de nuestra aplicación donde básicamente decimos que para una determinada clase se utilice un determinado Translator.

/* AppModule.java */
 public static void contributeTranslatorSource(MappedConfiguration configuration) {
  configuration.add(Date.class, new DateTranslator("dd/MM/yyyy"));
 }

A partir de este momento podríamos tener en archivo .tml de una página o componente lo siguiente y en la propiedad fecha del componente o página tendríamos un objeto de tipo Date olvidándonos por completo de la traducción.

<t:label for="fecha"/>: <t:textfield t:id="fecha" value="fecha" size="12" label="Fecha"/>

Hay otra interfaz que hacen algo similar a los Translators, es la interfaz ValueEncoder pero la diferencia entre las dos está en que en los translators puede ser necesaria algún tipo de validación por nuestra parte ya que son datos que introduce el usuario y en los encoders no ya que no son datos que introduce el usuario. Esto se ve claramente en los parámetros de los componentes TextField, Hidden y Select, el primero utiliza un Translator y los dos últimos un ValueEndoder.

Tapestry ya proporciona un ValueEncoder para las entidades de nuestro dominio si utilizamos Hibernate, la clase es HibernateEntityValueEncoder. Para terminar, indicar Tapestry también proporciona un ValueEncoder por defecto para los tipos Enum.

Referencia:
Documentación sobre Apache Tapesty

5 opciones de hosting para aplicaciones Java

La tecnología avanza y hoy en día tenemos nuevas opciones para hospedar las aplicaciones de tal forma que estén las 24 horas de los 365 días del año (o 366) disponibles para ofrecer sus servicios. Veamos algunas de las que hemos tenido hasta el momento con algunas de sus características.

Servidor propio
Disponer de un servidor propio tiene varias ventajas como que tenemos total control sobre la máquina y en la que podremos instalar todo lo que necesitemos sin ninguna limitación, sin embargo, esta ventaja también puede ser una desventaja ya que tendremos que tener los conocimientos y tiempo para administrar la máquina. Otra desventaja es que deberemos solventar los fallos de hardware que se produzcan como una rotura de un disco duro, un sobrecalentamiento de la placa base, memoria, procesador o router lo que puede afectar a la disponibilidad de la aplicación. Además, tendremos que disponer de un sitio adecuado para alojar la máquina y de los costes que conlleva tenerla encendida en todo el momento que no hay que despreciar. También tenemos que tener en cuenta que si necesitamos escalar la aplicación tendremos más dificultades que otras opciones ya que tal vez tengamos que adquirir nuevo hardware y haya que adaptar la aplicación.

En definitiva esta opción nos obliga no solo a centrarnos en nuestra aplicación sino también en la infraestructura donde se despliega y en su administración. Sin embargo, hay que decir que una gran ventaja es que nuestros datos están bajo nuestro control y no en segundas o terceras partes.

A pesar de todas sus desventajas esta opción puede ser muy interesante para un uso personal. Como por ejemplo disponer de un servidor para descargas, compartir archivos u ofrecer servicios de red a los equipos de nuestra casa. Hay diferentes plataformas sobre las que podemos implementar nuestro propio servidor, algunas de las más conocidas en estos momentos son las placas Pandaboard, SheevaPlug, BeagleBoard, TimSlice o las inminentes Raspberry Pi (¡que cuestan 35$!). Todas ellas tienen en común que son un ordenador completo que no ocupan mucho más que un disco duro de 2.5" y están basadas en microprocesadores ARM con lo que tienen un consumo muy reducido que notaremos en la factura de la luz (consumen entre 2W y 9W, ¡un ordenador de sobremesa consume entre 150W y 300W! por lo que el coste de las placas se amortiza con el tiempo). Al ser ordenadores completos y de propósito general podremos darle otros usos como centro multimedia para reproducir películas, vídeos o fotos en la televisión ya que algunas placas tienen una salida HDMI.

Proveedores de hosting
Si no queremos administrar el hardware ni tampoco el software y nos queremos olvidar de los fallos del mismo podemos hacer uso de alguna de las opciones que ofrecen los proveedores de hosting. Sin embargo, con estas opciones no tendremos posibilidad de elegir la plataforma con la que construir nuestra aplicación ya que la mayoría solo ofrece bases de datos MySQL, la plataforma ASP o ASP.NET o PHP y tal vez no en la versión que queramos. Tradicionalmente los proveedores de hosting que ofrecían la plataforma Java han sido muy pocos con lo que los programadores de Java tendremos que buscar otras opciones. A no ser que dispongamos de un servidor dedicado nuestra aplicación competirá con las otras aplicaciones por los recursos del servidor lo que puede afectar a la capacidad de nuestra aplicación. En caso de que optemos por un servidor dedicado tendremos el problema de la escalabilidad si la aplicación lo demanda.

Algunos de los proveedores más conocidos son Arsys y Piensasolutions.

Actualmente la tendencia en diferentes ámbitos está en la computación en la nube y en esta tendencia el hospedaje de las aplicaciones se ofrecen como servicio. Hay diferentes opciones entre las que poder elegir y con diversas características que deberemos evaluar según las necesidades. Veamos algunas de las más conocidas.

Otra opción es el alojamiento web de anw que tiene la ventaja de ser una opción más económica que un servidor privador virtual dedicado o una máquina cloud, ofreciendo hosting Java con JDK y servidor de aplicaciones dedicado pero a precios de hosting compartido. Poseen un panel de administración mediante el que elegir tanto la versión del JDK como del servidor de aplicaciones entre los que están los principales como Tomcat, Glassfish/Payara o WildFly y disponer del servidor funcionando en pocos minutos y en todo momento con soporte técnico. También ofrecen alojamiento web para aquellos que utilizan WordPress.

Amazon EC2

Amazon EC2 ofrece su infraestructura como servicio (IaaS) en la que nuestra aplicación estará hospedada en sus servidores. En esta opción tendremos un gran control sobre el software que instalamos en el servidor ya que en gran medida lo que la diferencia de un servidor propio es que nos conectamos al servidor de forma remota para administrarlo, si el servidor propio lo administrásemos de forma remota ni eso.

Al igual que otras opciones de la nube tiene la ventaja de que en caso de que nuestra aplicación escale podemos adquirir mas recursos de cómputo, como capacidad de procesamiento, memoria o almacenamiento en disco. En realidad Amazon no dispone una máquina física para cada servidor de sus usuarios sino que da una representación lógica de un servidor, por esto motivo, si necesitemos disponer de una nueva máquina podremos disponer de ella en pocos minutos y la podremos aprovisionar rápidamente con imágenes de software (AMI) buscando una que se adecue a nuestras necesidades. Aunque necesitemos más tiempo de configuración que en las opciones de Google App Engine y Jelastic.

Se puede probar durante un año gratis en una instancia micro. Aquí pueden consultarse los precios de Amazon EC2 y aquí los tipos y características de las instancias. A la hora de pagar hay que preseleccionar un tipo de instancia por lo que necesitaremos evaluar nuestras necesidades por lo alto y probablemente estemos pagando por capacidad que luego no aprovechamos.

Amazon también proporciona una plataforma PaaS, AWS Elastic Beanstalk, sino queremos ser responsables de administrar a bajo nivel las máquinas. Beanstalk nos permite centrarnos en el desarrollo de la aplicación en vez de la administración de la infraestructura.

Google App Engine (GAE)

La solución de Google para el «cloud computing» ofrece una plataforma como servicio (PaaS) para las aplicaciones con una serie de API que deberán usar para conseguir ciertas funcionalidades, como persistencia. Tiene como ventaja que no tenemos que preocuparnos de administrar un servidor y todas las herramientas para hacerlas funcionar entre si, solo nos preocuparmos por nuestra aplicación. Tiene como desventaja que deberemos adaptar nuestra aplicación a las API que nos ofrece GAE y por tanto estaremos encadenados a su plataforma. También estaremos limitados a utilizar Python o Java por el momento.

Dispone de cuotas parte de las cuales pueden usarse de forma gratuita y aquí los precios de los recursos consumidos.

Jelastic

Una opción más reciente para únicamente la platforma Java, por el momento, es Jelastic. Se trata de una PaaS sin la desventaja de tener que administrar un servidor como en Amazon y sin la desventaja de estar encadenados a ciertas API como en el caso de Google App Engine de tal modo que si queremos cambiar de proveedor no tendremos que reimplementar la aplicación. Nos ofrece herramientas estándares sobre las que de desarrollar la aplicación como son nginx como servidor web, apache tomcat 6/7, jetty o glashfish como contenedores de aplicaciones, Maria DB, MySQL o PostgreSQL como bases de datos relacionales y MongoDB o CouchDB como bases de datos no-sql y el JDK 6 o 7.

Esta opción permite centrarse en el desarrollo de la aplicación y posiblemente sea la opción más adecuada para un equipo de developers puro que no dispone de sysadmins. La aplicación se puede tener en funcionamiento en minutos (en vez de horas como en Amazon EC2) ya que todos los elementos de la infraestructura ya están configurados para funcionar entre si. Dado que no hay que aprender nuevas API como en el caso de GAE permite aprovechar los conocimientos que todo desarrollador Java ya tiene.

La escalabilidad y el coste se mide en cloudlets. Un cloudlet se corresponde con 128 MiB de memoria y 200 Mhz de cómputo y tiene un precio de 0,016 €/hora (para el proveedor dogado). Aún en estado beta puede probarse de forma gratuita. La aplicación puede escalar de forma transparente de forma vertical hasta un máximo de 16 cloudlets y en horizontal hasta un máximo de 4 máquinas.

OpenShift
OpenShift (de la mano de RedHat) es una opción similar a Jelastic, es un PaaS, pero soporta diferentes tecnologías además de Java como PHP, Ruby, Node.js y Python. También diferentes bases de datos como MySql, PostgreSql y MongoDB. Puede ser probada de forma gratuita con un límite de 3 gears, donde cada gear se corresponde con 512 MiB y 1 GiB de espacio en disco. Otra opción similar es AppFog que también tiene una capa gratuita.

Otras opciones son AppFog (esta es muy recomendable), Cloud Foundry (VMWare), Heroku, Azure (Microsoft) y Google Compute Engine (Google Cloud Platform).

Como se ve las opciones de hosting o alojamiento no son pocas cada una con varias características, precios y formas de cobro diferentes.

Después de unos años he revisado este artículo con algunas opciones más de hosting que en el momento de escribirlo no conocía. El artículo es Nueva visita a 5+ opciones de «hosting» para aplicaciones.

Referencia:
http://es.wikipedia.org/wiki/Computaci%C3%B3n_en_la_nube
http://archlinuxarm.org/
http://www.raspberrypi.org/
http://pandaboard.org/
http://www.danielclemente.com/consumo/
http://www.arsys.es/
http://www.piensasolutions.com/
http://aws.amazon.com/es/ec2/
http://code.google.com/intl/es-ES/appengine/
http://cloud.google.com/
http://jelastic.com/
https://www.appfog.com
https://openshift.redhat.com
http://www.windowsazure.com/es-es/
http://blog.jelastic.com/2012/02/09/jelastic-versus-heroku/

Debug de una aplicación Java

Durante el desarrollo de una aplicación es normal que se produzcan excepciones y errores. Para descubrir sus causas y depurarlos se pueden utilizar varias herramientas. Una de ellas es utilizando un sistema de trazas como slf4j en el que podamos ver que ha estado haciendo la aplicación en el momento del fallo. Con la traza de la excepción la mayoría de las veces es suficiente para reproducir el error en una máquina de desarrollo pero en ocasiones hay «bugs» que si no se «tracean» o «debuggean» con un depurador no es fácil seguir la pista al código que se está ejecutando.

Para depurar una aplicación en Java hay que arrancar la máquina virtual en modo debug de tal forma que luego con un IDE como eclipse podamos depurar la aplicación. Los parámetros a añadir a la linea de comandos que arranca la JVM son:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Si estamos depurando una aplicación web que se ejecuta en el contenedor Tomcat los shell scripts que lo arrancan nos lo ponen más fácil, tan solo tendremos que iniciar Tomcat con el siguiente comando y él se encargará de pasar los parámetros anteriores a la JVM:

catalina.sh jpda start

Para arrancar Tomcat en modo debug desde Ant podemos utilizar la siguiente tarea:

...
<condition property="LIB_HOME" value="/home/picodotdev/java">
 <and><os family="unix"/></and>
</condition>

<property name="TOMCAT" value="apache-tomcat-7.0.25"/>

<condition property="TOMCAT_STARTUP" value="startup.sh">
 <and><os family="unix"/></and>
</condition>
<condition property="TOMCAT_CATALINA" value="catalina.sh">
 <and><os family="unix"/></and>
</condition>
<condition property="TOMCAT_SHUTDOWN" value="shutdown.sh">
 <and><os family="unix"/></and>
</condition>
...
<target name="serverStartDebug">
 <exec executable="${LIB_HOME}/${TOMCAT}/bin/${TOMCAT_CATALINA}" dir="${LIB_HOME}/${TOMCAT}/bin/">
     <arg line="jpda start"/>
 </exec>
    <waitfor maxwait="10" maxwaitunit="second">
     <socket server="localhost" port="8080"/>
 </waitfor>
</target>
...

Una vez que tenemos la máquina virtual arrancada en modo debug podremos depurar la aplicación desde un IDE. En el siguiente paso veremos como hacerlo desde eclipse. Para ello en el eclipse iremos al menú «Debug > Debug Configurations > Remote Java Application» e indicaremos los parámetros: proyecto que queremos depurar, tipo de conexión (Standard (Socket Attach)), Host (localhost, si la JVM donde está ejecutandose la aplicación es la máquina local) y puerto (8000, lo mismo indicado que en el parámetro address).

Dado que en realidad nos estamos conectando a la máquina virtual de Java de forma remota y a través de la red tal vez necesitemos abrir el puerto 8000. Si tenemos un sistema Linux y ufw como firewall lo podremos hacer con:

$ sudo ufw allow 8000
$ sudo ufw status

 Una vez hayamos realizado los pasos anteriores estamos listos para «debuggear», podremos añadir puntos de ruptura donde queramos en la aplicación y podremos ver las variables y sus valores presentes en el ámbito de donde se ha parado la aplicación.

Referencia:
http://wiki.apache.org/tomcat/FAQ/Developing#Q2