Cuando se recibe una petición, por ejemplo una llamada a un API, es frecuente que para atenderla haya que que recabar información de múltiples orígenes. Estos orígenes pueden ser directamente un repositorio de información (un acceso JDBC), o bien, un servicio interno independiente que gestiona una determinada funcionalidad (microservice). Así mismo, algunas de estas informaciones serán independientes unas de otras, pero habrá casos en las que existan dependencias entre ellas. Por otro lado, sería muy interesante que no se bloquearan innecesariamente recursos del sistema (reactive), que son siempre muy escasos.

Por lo tanto, el sistema más eficiente sería aquel:

• que permitiera paralelizar todas las operaciones que fuera posible
• que permitiera combinar los resultados de operaciones intermedias para obtener el resultado final
• que evitara bloquear ningún recurso de manera innecesaria

En Scala esto es algo inherente al ADN del lenguaje, los elementos básicos del lenguaje proporcionan lo necesario, pero y en Java?

Supongamos un sistema de Gamificación en el que el API que devuelve el perfil del jugador proporciona la siguiente información:

• Datos básicos de perfil (nickname, nivel)
• Posición en los rankings
• Última medalla conseguida en su nivel actual

Por ejemplo, en este caso: los datos básicos del perfil y la posición en el ranking son operaciones independientes que podrían lanzarse sobre los correspondientes servicios, y la identificación de la última medalla conseguida depende de conocer previamente el nivel último nivel del usuario.

 Scala Flavour

Scala ofrece las Futures como mecanismo para la parelización de acciones, y las operaciones flatMap y map para la combinación de las mismas dentro del propio lenguaje.

Las siguientes Futures modelizan las operaciones a realizar:

• Recuperación de la posición en el Ranking [fBasicProfile]
• Recuperación del perfil básico [fRanking]
• Recuperación de la última medalla del nivel actual [fLastMedalInLevel], que depende del valor devuelto por [fBasicProfile]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

def fBasicProfile =
  (user: String) =>
        Future {
          doAction(s"Select BasicProfile ($user)")
          "basicProfile:MoonWalker"
        }

def fRanking =
  (user: String) =>
        Future {
          doAction(s"Select Ranking Position ($user)")
          "125"
        }

def fLastMedalInLevel =
  (basicProfile: String) =>
        Future {
          doAction(s"Select LastMedalInLevel ($basicProfile)")
          if (basicProfile.endsWith("MoonWalker"))
              "MoonConquest" else "NoMedalYet"
        }

One of the new features incorporated into Java 8 is Optional , representing the possibility that a concept may not have value, and its clearest application is when applied to the value returned by a method or function.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class SubscribersRepo{
  ...
  public String findAddressByPhone(final String theNumber) {
    ... some access to a data repository
  }
  ...
}

...
    String address =
        SubscribersRepo.findAddressByPhone("+930700555555");

    if(address != null) {
       sendSomeGift(address);
    }
...

Two things to take into account:

1. It is not modelized that the requested information might not exist
2. If the information does not exist, returns null or throws an exception

The problem is with point 1, because if something is not modeled, it is obviously an exceptional case.

Optional allows the modelization of the possible absence of information and avoids the “exceptionality” of the situation.

1
2
3
4
5
6
7
8
9
10
11
12

public class SubscribersRepo{
  ...
  public Optional<String> findAddressByPhone(final String theNumber){
    ... some access to a data repository
  }
  ...
}

...
  SubscribersRepo.findAddressByPhone("+930700555555")
                 .ifPresent(address -> sendSomeGift(address));
...

Now it is clear that the information might not exist, and in any case (exists or not exists), the flow of the program is the same, no special treatment.

… una Empresa que fabricaba ordenadores, y en un momento dado decidió ceder la fabricación de algunos circuitos a un Suministrador. Al de un tiempo el Suministrador le propuso:

– Qué te parece si fabrico también la placa madre y lo hago un 20% más barato? De todos modos no es el núcleo de tu negocio.

A la Empresa le pareció fantástico, iban a ganar más y con menos esfuerzo. Al de un cierto tiempo el Suministrador volvió con nuevas propuestas para hacerse cargo de la fabricación del resto de componentes, del ensamblado, del diseño … de todo.

La Empresa cada vez estaba más contenta, cada vez tenía que dedicar menos esfuerzo a construir su producto, y sin embargo cada vez ganaba más.

Al final el Suministrador sabía hacer ordenadores completos, así que ya no acudió más a la Empresa … ahora comenzaba a hablar directamente con el Distribuidor …

En este artículo, Why amazon can’t make a kindle in the USA?, explican la situación del outsourcing en Estados Unidos.

El caso del “cuento” se refiere a una industria llamenosle “física”, pero en el caso del software sería muy similar. Si no estás en los elementos básicos de lo que haces, te desconectas del proceso base y pierdes la capacidad (el know-how) para aumentar el valor de lo que construyes.

En la tercera temporada de Mad Men Don Draper conoce casualmente a Conrad Hilton, el fundador de la cadena de hoteles, y se hacen amigos. En un capítulo posterior Conrad llama a Don para comentarle “algo” y, más o menos, lo que comentan es lo siguiente:

C.H.: Don, tengo aquí unos bocetos para una nueva campaña. ¿Qué te parecen?

D.D.: Que si trabajaras gratis no estarías ahora en la Suite Presidencial

C.H.: Oh, vamos Don, somos amigos…

D.D.: Conrad, es mi profesión…

¿Qué le dice Don a Conrad? Algo básico: respeto por el profesional, respeto por su tiempo y respeto por su profesión.

Bueno pues todas las herramientas de Atlassian están estos días un poco más asequibles, la verdad es que me parece que tienen esta opción desde enero, pero lo he visto hoy. Están ofreciendo un paquete “starter” que incluye un acceso a todas sus herramientas (no estoy seguro si a Clover también) para 10 usuarios por 10$ ($60 aprox. 44€ el conjunto completo JIRA, Confluence, Green Hopper, Bamboo, FishEye y Crowd). La verdad es que para pequeños grupos de trabajo que quieran utilizar estas herramientas es muy interesante, además lo que recaudan con esto lo donan enteramente a Room To Read, que es una gente que se dedica a apoyar la educación de niños en zonas con pocas posibilidades (De la instrucción nace la grandeza a las naciones – José Rizal).

Estaba leyendo hoy una noticia sobre Zappos, uno de los mayores sitios de comercio electrónico de USA (recientemente adquirido por Amazon), acerca del cambio de plataforma que han realizado, y he ido a echar un ojo a sus cabeceras a ver si se veía algo por ahí (sip, a veces se ven cosas), y esta vez sí que se veía algo… Ellos añaden dos cabeceras simpáticas:

• X-Core-Value: en la que ponen en cada petición un punto de una especie de decálogo

• X-Recruiting: en la que literalmente ponen “If you’re reading this, maybe you should be working at Zappos instead. Check out jobs.zappos.com”

Sobre su decálogo:

• Deliver WOW Through Service
• Embrace and Drive Change
• Create Fun and A Little Weirdness
• Be Adventurous, Creative, and Open-Minded
• Pursue Growth and Learning
• Build Open and Honest Relationships With Communication
• Build a Positive Team and Family Spirit
• Do More With Less
• Be Passionate and Determined
• Be Humble

Curioso, y simpático…estos de Zappos…parece que aún queda gente que aprecia el trabajo bien hecho, y además con humor.

Akismet es el servicio de detección de spam que utiliza WordPress, pero no solamente es utilizable desde WordPress, sino que cualquier aplicación puede utilizarlo a través del API REST que ofrece. Akismet no es un servicio gratuito, pero las modalidades de uso que ofrece son bastante asequibles, teniendo en cuenta los ahorros que puede suponer el no tener que tratar con el spam en tu sistema (o al menos, no tanto como sin él). El API es muy simple, son únicamente cuatro operaciones:

• Verificar la clave de uso (verifiy-key)
• Comprobar un comentario (comment-check)
• Notificar un falso negativo (submit-spam)
• Notificar un falso positico (submit-ham)

Bueno, esto está bien, pero lo que realmente quería, era aprovechar este sencillo API y un wrapper sobre él en Groovy (AkismetDrops), para ver por encima alguna de las características que, desde mi punto de vista, hacen de Groovy algo interesante:

En los últimos dos años se ha producido la consolidación de un proceso, que venía fraguándose de un tiempo antes, en el que la JVM ha pasado de ser la máquina virtual en la que se ejecutaba Java a transformarse en una plataforma sobre la que corren un conjunto muy amplio de lenguajes. Esto es interesante fundamentalmente por tres cosas:

• es posible elegir, de entre todos estos lenguajes, el que mejor se ajuste a las necesidades de cada proyecto en particular
• ofrecen una gran integración e interoperabilidad con Java, de modo que su combinación es sencilla pudiendo incluso utilizarlos simultáneamente
• aprovechan la infraestructura de JVMs ya existentes en multitud de instalaciones

Algunos de los más populares son: Scala, considerado uno de los lenguajes del futuro, Clojure, con un foco especial en la programación concurrente, Groovy, como un superconjunto de Java, Ruby (a través de JRuby), capaz de ejecutar Rails, PHP (a través de Quercus), Javascript (Rhino)…

Entre todos ellos, Groovy es uno de los más interesantes para los desarrolladores Java, porque:

• su sintaxis es muy similar a la de Java, la curva de aprendizaje es baja, no es un lenguaje diferente
• ofrece las ventajas de un lenguaje dinámico
• extiende el JDK, complementa a Java, simplifica el tratamiento de listas, maps, XML…
• proporciona soporte para DSLs
• incorpora flavors de programación funcional (closures)…

Pero lo que, desde mi punto de vista, hace a Groovy especialmente relevante para los desarrolladores Java es que dispone de un framework para desarrollo de aplicaciones web, Grails, que podemos decir equivalente en cuanto a funcionalidad, posibilidades y velocidad de desarrollo a Ruby On Rails, con todo lo que ello significa. Actualmente SpringSource (creadores de Spring) se encarga del desarrollo de Grails, y si lo combinamos con su CloudFoundry, podemos ir haciéndonos una idea de las posibilidades que esto ofrece…

Dentro de las herramientas de seguimiento de errores existe un amplio abanico que va desde las más simples, o más centradas en su funcionalidad original, como Bugzilla o Mantis (ambos OpenSource), hasta las más evolucionadas como Redmine (OpenSource), JIRA o FogBugz (ambos comerciales), que complementan su funcionalidad original de seguimiento de errores con un conjunto de funcionalidades adicionales, que les permiten saltar un nivel y convertirse en herramientas con las que poder efectuar el control y la gestión de un proyecto.

TRAC (OpenSource) es originalmente un sistema de seguimiento de issues, esto es importante porque se posiciona no como un sistema orientado principalmente a la gestión de bugs, como Bugzilla o Mantis (aunque luego hagan más cosas), sino que busca ofrecer los mecanismos básicos para poder efectuar la gestión de un proyecto, y en este sentido se aproxima a lo ofrecido por JIRA o FogBugz.

TRAC es flexible, no impone ninguna metodología, simplemente ofrece un conjunto de herramientas para que se puedan hacer las cosas, algunas de estas herramientas son:

• Sistema completo de gestión de Tickets, que permiten establecer y asignar las funcionalidades que se desarrollarán en el proceso (nuevas características, errores, tareas…)
• Wiki, como repositorio común de información/documentación para el proyecto (estructura del proyecto, dónde están los servidores, cómo configurar los entornos, guías de estilo y codificación…tooodooo)
• Integración con el sistema de control de versiones (Subversion y Git…entre otros)
• Roadmap, o calendario de versiones, que permite ver el grado de avance y cuándo se preve que sean liberadas las nuevas funcionalidades
• TimelIne, o lugar en el que se registran y se pueden revisar todas las operaciones realizadas en el proyecto desde el cambio en una página del wiki hasta el último commit en el repositorio de código.
• RSS como mecanismo de seguimiento en casi todos los módulos de TRAC
• …otras muchas…

En la vida diaria casi todas las personas hacen un esfuerzo por agradar y facilitar las cosas a los demás: preguntas por una calle, dejas un recado, pides ayuda para levantar algo… de acuerdo, hay excepciones, pero son las menos. Es algo que va en la condición humana. Sin embargo, lo que es bueno en el día a día, no es tan bueno cuando se traslada a otros ámbitos. Cuando se define un proyecto es de vital importancia mantenerlo dentro de su alcance, la salida fácil de la completa aquiescencia ante las demandas no contempladas, no es más que una dilación del problema, que no hará sino agravarse. La definición de un sistema es algo complejo, no es una mera toma de notas, en realidad se trata de un proceso de negociación, que debe manejarse de manera flexible para dar cabida a las cuestiones no previstas inicialmente, pero que deban contemplarse, y para dar salida a contrapartes equivalentes. En este proceso habrá ocasiones en las que será necesario decir que no, y, aunque parezca extraño, se estará haciendo un gran servicio al sistema. Un enfoque simplista del tipo lo ha pedido el cliente, sin ninguna medida que efectúe un ajuste, introducirá un grave riesgo para la consecución del éxito final, porque amplificará sin control su alcance.

Alguna vez he leído lo siguiente atribuído a Alan Cox: “La gente siempre pide más, pero algunas veces lo correcto es decirles simplemente que no“… en este caso mas que no, sería un negociemoslo.