blog de ezamudio

HolaMundo en Scala II: Actores

Apenas ayer publiqué mis pininos en Scala. He seguido leyendo un poco al respecto y después hice una segunda versión, con una clase menos, que fue sustituida por una función.

Ahora hice una tercera versión, usando actores. Esto de los actores ya seguramente el Dr. Ferro nos lo explicará mejor en la serie que está escribiendo de Scala. Los actores es la manera en que se maneja concurrencia de manera sencilla en Scala. Aquí me doy cuenta que sí tomaron algunas cosas prestadas de Erlang, un lenguaje de programación funcional creado expresamente para programación concurrente que alguna vez empecé a aprender pero por falta de práctica (porque no tenía un proyecto real que pudiera realizar con él) lo dejé.

Ahora que veo Scala, el modelo de comunicación entre procesos es muy similar, obviamente con algunas diferencias importantes: En Erlang se manejan procesos ligeros, que no corresponden con hilos como los conocemos; la comunicación entre procesos es muy rápida y los procesos ocupan muy poca memoria, por lo que se pueden tener varios miles de procesos corriendo en una aplicación Erlang sin que represente un alto costo al hardware (en términos de CPU/RAM); Erlang no tiene variables, en el sentido de que sean modificables; cuando se crea una variable, y se le asigna un valor, ya así se queda, no se puede modificar.

HolaMundo (en Scala)

Hace tiempo que quiero aprender Scala, pero no he tenido oportunidad de hacerlo. Hoy me decidí a aprender aunque sea un poquitititito, y me topé con una buena idea para hacer mi primer programa: Un servidorsito muy simple, que implemente el protocolo "hola mundo".

Hay que poner un servidor a escuchar conexiones TCP en un puerto; cada conexión que se recibe, debe leer un renglón de texto (se espera un nombre) y devolver un saludo a ese nombre, para después cerrar la conexión.

Tomé la idea de un ejemplo que puse como comentario en un foro aquí mismo. Así puedo comparar...

Pues bien. Primero que nada, la clase que implementa el protocolo, utilizando streams. Lo primero que me topé es con que aquí sí tengo que importar java.io, java.net, etc. Y otra cosa, que no se puede poner * para importar todas las clases, sino que hay que usar subguión.

Cómo NO hacer un web service

He leído incontables blogs acerca de cómo hacer web services, cómo exponer funcionalidad existente en forma de web service, las distintas maneras de exponerlo en Java (Axis2, CXF, la funcionalidad integrada de Java 6, etc).

Pero todos esos artículos (incluyendo uno que yo mismo escribí hace tiempo) se enfocan únicamente a la parte de exponer la funcionalidad, es decir, poner una interfaz SOAP que se puede invocar desde otra aplicación, probar que responde, y listo. Algunos artículos que he visto incluso no pasan de ser un tutorial de cómo crear el esqueleto del web service en Eclipse, NetBeans, Visual Studio (para los .NETeros) lo cual hace ver a los artículos que detallan herramientas de línea de comando como algo innecesariamente complicado.

Supongo que mucha gente lee estos artículos y se llevan la impresión de que es muy fácil hacer un web service. Simplemente siguen el tutorial o blog, y con eso tienen el esqueleto. El paso siguiente seguramente es invocar un método de un componente que hicieron o que ya tenían hecho, y luego probar que funciona, creando un cliente del web service y haciendo un par de invocaciones. ¡Listo! ¡Que lo pasen a producción!

Construcción de proyectos existentes en Gradle

En una ocasión anterior escribí acerca de Gradle, un sistema de automatización para construcción de proyectos, de manera muy básica. En esta ocasión quiero profundizar un poco sobre una de sus funciones, la cual nos atañe a todos en esta comunidad: construir un proyecto Java.

Gradle tiene una arquitectura de plugins muy buena, y varios plugins muy buenos, por ejemplo el plugin para Java. El plugin para Java permite construir proyectos de manera MUY sencilla si se siguen ciertos lineamientos (y de manera también sencilla si no se siguen dichos lineamientos, como veremos más adelante). Por ejemplo, tener la típica estructura mavenesca en un proyecto ayuda mucho porque son los defaults para construir un proyecto Java:

src/main/java
src/main/resources
src/test/java
src/test/resources

Grape: Manejo de dependencias en Groovy

El manejo de dependencias generalmente es una pesadilla, incluso cuando usamos herramientas como Maven o Ivy. Hay que crear archivos de configuración y de construcción de proyectos, y eso ayuda mucho para proyectos complejos, pero cuando tenemos un script en Groovy, un programita rápido, pensamos que no queda otra opción que poner las dependencias en la línea de comandos.

Pero no es así.

Groovy incluye un excelente mecanismo para manejo de dependencias, llamado Grape, y es muy simple de usar. Supongamos que queremos hacer un script para conectarse a una base de datos y procesar algunos registros, y enviar al final un correo (ah y por supuesto dejar todo en un log con SLF4J).

Sobrecarga de operadores y otras monerías de Groovy

Recientemente he estado empezando a integrar código Groovy a aplicaciones que tengo hechas en Java. Esto implica que al final compilo las clases Groovy, y la aplicación Java sigo ejecutándola con java, pero ahora tengo que agregar un par de bibliotecas (hasta la fecha, con Groovy 1.7.10, solamente tengo que agregar groovy-1.7.10.jar y asm-3.2.jar, no he tenido que agregar otras, y prefiero meter esas dos que groovy-all-1.7.10.jar porque este último trae varias cosas que podrían causarme conflictos en aplicaciones con muchas dependencias).

También he visto de qué manera puedo usar mejor mis clases Java desde Groovy. Y he descubierto que hay algunas monerías que se pueden implementar en Java, para simplificar el uso de algunas clases desde Groovy.

Gradle: Un ejemplo sencillo

Gradle es un sistema de automatización para construcción de proyectos, similar a Ant, Ivy, Maven, etc. Está construido en Groovy, pero no es solamente para construir proyectos en Groovy; puede usarse en proyectos Java sin ningún problema.

La arquitectura es muy interesante. Ha tomado muchas de las cosas buenas de Maven, Ivy y Ant, dejando atrás las desventajas de cada uno. Decidí echarle un ojo, y pensé que sería bueno empezar con algo sencillo: reescribir un script de Ant con el que creo varios jars.

Uso de memcached desde Java

Tal vez algunos hayan escuchado de memcached, un software que provee un cache en memoria para cualquier cosa que quieran almacenar de manera temporal. El concepto detrás de este software es muy simple: es como tener un mapa gigante, al cual ustedes le pasan una llave, un valor y una duración o fecha de expiración. El software almacena el valor, que será accesible al pedirlo por la llave bajo la cual fue almacenado; cuando la fecha de expiración pase, el cache ya no devuelve el valor para esa llave, porque ya expiró.

Este software se ha vuelto muy utilizado en varias aplicaciones web por las siguientes razones:

  • Es muy fácil de instalar (en Linux/*NIX al menos) y configurar.
  • Meter valor al cache y leerlos es bastante rápido, incluso cuando hay varias miles de llaves vigentes.
  • Se puede utilizar de manera distribuida, teniendo varias instancias en distintos equipos y ninguna tiene que saber de la existencia de las otras; el cliente es quien hace la distribución de valores a las distintas instancias.
  • Hay clientes para varios lenguajes y plataformas: Ruby, C, PHP, y por supuesto Java.

Web Services políglotas con Spring

Hace poco tuve que crear un web service para un cliente. Después de muchas vueltas y estar evaluando opciones, decidí usar el JAX-WS 2.1 que viene integrado en Java 6, cosa de lo cual me enteré hace tiempo gracias a willyxoft aquí mismo, junto con Spring para publicar el servicio, ya que lo tengo que poner en una aplicación JavaSE, como gateway hacia otro sistema; a fin de cuentas es solamente una traducción de protocolos, porque el cliente no quiere manejar un protocolo asíncrono y tenemos que darle un web service.

Dado que he estado incursionando un poco en el mundo de Groovy, quise implementar algunas partes de la aplicación usando este lenguaje. Y vaya que me ha ahorrado varias líneas de código... simplemente los beans que se usan como parámetros y valores de retorno en los métodos del web service, son bastante compactos, por ejemplo:

@XmlAccessorType(XmlAccessType.FIELD)
class Datos {
  String id
  String user
  String password
  String producto
  BigDecimal monto
  Date fecha
}

Procesamiento de anotaciones y AOP

(Un título alterno podría ser "Mi primera experiencia implementando AOP con AspectJ")

Recientemente, durante mi conferencia de jAlarms en la primera edición de las OpenTalks de javaMéxico, me fue sugerido hacer algo con AOP para poder interceptar excepciones y enviar una alarma con jAlarms. La idea me pareció bastante interesante y la verdad en cuanto pude me puse a trabajar en el asunto.

Lo primero fue leer un poco acerca de AOP, sobre todo acerca de la implementación de aspectos, pues aunque conozco la teoría de cómo funciona e incluso he configurado algunos proxies, esta vez requiero un conocimiento más detallado del funcionamiento interno para poder implementar algo útil.

El objetivo final es muy sencillo: Crear una anotación que se pueda poner a un método o a una clase, y que en tiempo de ejecución si el método anotado (o cualquier método de la clase anotada) arroja una excepción que no maneja, se envíe una alarma con algunos detalles de la excepción. Algo así:

@AlarmOnException
public class UnaClase {

  public void metodo1() {
    //Una excepcion en este metodo causa envio de alarma
  }

  public void metodo2() {

Distribuir contenido