Libros gratis de O’Reilly

La colección gratis de O’Reilly cuenta con muchos temas de interés y en este post hemos seleccionado los relacionados a la programación funcional y los sistemas reactivos.

Los pueden descargar desde los siguientes enlaces:

Object-Oriented vs. Functional Programming
http://www.oreilly.com/programming/free/object-oriented-vs-functional-programming.csp

Functional Programming in Python
http://www.oreilly.com/programming/free/functional-programming-python.csp

Why Reactive?
http://www.oreilly.com/programming/free/why-reactive.csp

Developing Reactive Microservices (requiere registro)
https://info.lightbend.com/COLL-20XX-Developing-Reactive-Microservices_Landing-Page.html?lst=OR

Reactive Microservices Architecture
http://www.oreilly.com/programming/free/reactive-microservices-architecture-orm.csp

 

Libros gratis de O’Reilly

Apple libera el código fuente de Swift

Tal como prometió Apple en el WWDC 2015, el código fuente de Swift ha sido liberado en un repositorio público en Github bajo la licencia de Apache.

https://github.com/apple

Para todos aquellos del mundo de Linux que estén interesados en probar Swift, actualmente ya existe un port para Ubuntu en la página de descargas de Swift.

https://swift.org/download/#latest-development-snapshots

Ahora que Swift es open source es muy probable que la comunidad trabaje rápidamente en la implementación para otros sistemas, estaremos atentos a novedades.

Apple libera el código fuente de Swift

MongoDB presenta MongoDB Compass

El 9 de Diciembre MongoDB presentará una introducción a MongoDB Compass. Esta nueva herramienta permite visualizar el esquema asi como también construir querys en la misma.

Si bien existen otros programas que permiten realizar estas acciones, MongoDB Compass es la herramienta oficial de MongoDB.

En Evolbit estamos convencidos que es una muy buena opción que irá creciendo con el tiempo para cubrir las necesidades de los usuarios de MongoDB, por esa razón les recomendamos asistir al webinar que se hará el día 9 de Diciembre.

Más información del webinar y registro en el siguiente enlace:

https://www.mongodb.com/webinar/an-introduction-to-mongodb-compass

 

MongoDB presenta MongoDB Compass

¿Cómo nos ayuda BDD en el desarrollo de un proyecto?

Antes de empezar primero aclaremos ¿qué es BDD?. BDD es un conjunto de prácticas de ingeniería que están basadas en prácticas ágiles, específicamente TDD y DDD, para ayudar a desarrollar y entregar software de calidad y con mayor valor para el cliente. BDD otorga un lenguaje común, basado en oraciones estructuradas que permite la fácil comunicación entre los miembros del equipo y los stakeholders.

El flujo que BDD promueve consta en:

  1. Identificar las metas del negocio.
  2. Identificar las características a desarrollar que contribuyen a las metas del negocio.
  3. Creación de ejemplos para las características definidas y planteamiento de escenarios utilizando un lenguaje común (Given, When, Then).
  4. Codificación a nivel de pruebas de los escenarios.
  5. Codificación de características de bajo nivel.
  6. Codificación del código de la aplicación.

BDD está orientado al comportamiento (Behaviour driven development) ya que de esa forma las pruebas reflejan las características esperadas por el cliente.

En la práctica, cada característica del software puede ser descrita en un formato de una historia de usuario si el equipo lo desea y de cada una de ellas se identifican por medio de ejemplos los escenarios que se deben de probar y estos escenarios cumplen la función de criterios de aceptación para las posibles historias que creemos de nuestras características.

Ejemplo:

Primero definimos una característica

Feature: Disposición de efectivo de un cajero

(As [role], I want [feature], So that [benefit])

Como [titular de la cuenta]
Quiero [disponer de efectivo desde un cajero]
Para [obtener dinero cuando el banco está cerrado]

Luego encontramos los escenarios

(Given [context], And [more context…], When [event], Then [outcome], And [another outcome])

Escenario: La cuenta no tiene fondos suficientes

Dado que el balance de la cuenta es S/.100
Y la cuenta es válida
Y el cajero tiene suficiente dinero
Cuando el titular de la cuenta solicita S/. 20
Entonces el cajero debe otorgar S/. 20
Y el balance de la cuenta debe ser S/. 80
Y la tarjeta debe ser devuelta

(Ejemplo adaptado en español de la página de Dan North & Associates. Dan North es el creador de BDD)

Como se puede apreciar en el ejemplo, de esta forma se pueden definir los escenarios que se deben cubrir para que una caracteristica (feature) sea aceptada como completa (criterios de aceptación). Uno de los puntos más importantes a resaltar es que el lenguaje que expresa los escenarios es fácil de entender tanto para personas con habilidades técnicas como para los que no, de esta forma todos los miembros del equipo están alineados y además las pruebas pueden servir de documentación.

A continuación veremos un ejemplo de una implementación en BDD del escenario visto en lineas anteriores, para eso usaremos Cucumber para Scala.

(Código en español para que sea fácil de entender, se puede usar ES en vez de EN para usar Cuando en vez de Given por ejemplo)

Como se puede ver, tanto la especificación como el código son exactamente iguales. Cucumber lee las especificaciones en texto plano y realiza un comparación con el código para capturar los valores que sean necesarios (en este caso los valores numéricos).

Al ejecutar las pruebas se puede ver el resultado detallado.

bdd_example

Además, las pruebas se pueden exportar como html para que puedan ser compartidas con el cliente.

De esta forma podemos mejorar el flujo de trabajo teniendo mejores definiciones con el cliente, orientadas al comportamiento y que aportan valor al negocio, además están reflejadas directamente en el trabajo realizado en el código y se pueden usar como documentación.

El código utilizado para la demostración puede ser descargado desde GitHub.

https://github.com/evolbit/cucumber-play

¿Cómo nos ayuda BDD en el desarrollo de un proyecto?

¿Sabes qué son los sistemas reactivos?

A estas alturas el término reactivo debería ser algo que las empresas y desarrolladores identifican con facilidad, sin embargo, la realidad es que muchos lo desconocen y siguen pensando de forma antigua tanto en el desarrollo como en la gestión (ver así que sigues usando cascada).

En Evolbit creemos que el desarrollo se debe tomar seriamente, que es un proceso muy delicado y que ha cambiado mucho para alinearse a estos tiempos, por esa razón nos alineamos al manifiesto reactivo.

¿Que es un sistema reactivo?

Los sistemas reactivos no son nuevos, en 1985 David Harel y Amir Pnueli plantearon una nueva dicotomía para caracterizar sistemas de computador complejos, los sistemas transformativos versus reactivos. Los sistemas transformativos aceptan un conjunto de entradas, transforman esas entradas y producen salidas, por otro lado, los sistemas reactivos, son estimulados continuamente por su entorno y su rol es responder continuamente a esas estimulaciones.

Unos años después Gérard Berry redefine lo expuesto anteriormente introduciendo la diferencia entre sistemas interactivos y reactivos, donde los programas interactivos definen la velocidad en la que interactúan con el entorno mientras que los reactivos determinan su velocidad por el entorno.

Podemos decir que un programa reactivo tiene las siguientes características:

  • Está disponible para interactuar continuamente con el entorno
  • Se ejecuta a la velocidad determinada por el entorno
  • Trabaja en base a la demanda externa

Cuando se analiza con detalle, las características expuestas anteriormente son como las aplicaciones web deberían funcionar. El manifiesto reactivo engloba las características vistas anteriormente en 4 principios básicos:

  • Responsivos: reaccionar a los usuarios
  • Resilientes: reaccionar a fallos
  • Elásticos: reaccionar a la carga
  • Orientado a mensajes: reaccionar a eventos

reactive-manifesto

Una aplicación responsiva satisface la expectativa del usuario en términos de disponibilidad y tiempo real. La aplicación responde con muy poca latencia.

Como bien sabemos, todas las aplicaciones incluso las más simples tienden a fallar, por eso las aplicaciones reactivas deben ser resilientes a fallas para poder cumplir con la demanda de disponibilidad continua.

Para poder interactuar continuamente con su entorno, una aplicación reactiva debe ser capaz de ajustarse de acuerdo a la carga que está recibiendo. Para responder correctamente de acuerdo a la carga, una aplicación reactiva debe poder ser elástica y escalar a demanda. Debe sacar provecho de todos los recursos de una maquina y debe saber como interactuar con más nodos de computación.

Un mecanismo que ayuda a cumplir con todas las propiedades anteriores es la orientación a eventos basado en comunicación asíncrona. El sistema o subsistema reacciona a eventos como pedidos HTTP sin necesidad de monopolizar los recursos mientras espera por un evento. Como consecuencia de este mecanismo la concurrencia alcanza mejores tasas de latencia (por ser asíncrono) y los componentes son más desacoplados.

Por lo tanto, sabemos que una aplicación es reactiva si cumple con los 4 principios del manifiesto reactivo.

Existen algunas tecnologías para crear programas basados en eventos y asíncronos, por ejemplo Microsoft’s Reactive Extensions (Rx), NodeJs, Netty o Apache Mina sin embargo el único framework maduro en este tema y que ha sido creado para cumplir exitosamente lo que dicta el manifiesto reactivo es playframework.

play_full_color

 

www.playframework.com

En estos días las aplicaciones deben responder a nuevas demandas y el manifiesto reactivo establece 4 principios que se deben cumplir para responder a las exigencias de hoy en día.

¿Estás desarrollando aplicaciones reactivas en tu empresa?, si la respuesta es no, te recomendamos que evalúes la situación actual para empezar a hacerlo y puedas tomar a tu favor las ventajas que una arquitectura reactiva ofrece.

¿Sabes qué son los sistemas reactivos?

Así que sigues usando cascada…

Hace varios años el Dr. Winston Royce presentó una propuesta para el manejo de proyectos de gran escala. Por varios años esa propuesta ha sido usada por muchas empresas pero no muchos saben una pequeña verdad acerca de ella, el mismo autor (Winston Royce) cree que es riesgosa y que invita a fallar.

Managing The Development of Large Software Systems

I believe in this concept, but the implementation described above is risky and invites failure. (Creo en este concepto, pero la implementación descrita anteriormente es riesgosa e invita a fallar)

Este pequeño detalle ha resaltado mucho en la práctica. Los proyectos manejados con cascada sufren muchos conflictos por diferentes razones, una de las razones más importantes es intentar diseñar el sistema y analizar todos los requerimientos intentando manejar una verdad única, rígida y desde un único punto de vista. Sabemos por experiencia que los sistemas cambian durante el desarrollo por muchas razones (cliente, tecnologías, otros) y por esa razón, mucho del tiempo invertido en la etapa de análisis perderá sentido.

Por la razón expuesta anteriormente y muchas otras, en Evolbit usamos Scrum como marco de desarrollo. Es usado a nivel mundial por grandes empresas que ya han comprobado su efectividad. Scrum sigue los principios del manifiesto ágil (http://www.agilemanifesto.org/) y promueve lo siguiente:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Scrum-overview

Si tu o tu empresa aún siguen usando cascada te recomendamos que revises más sobre Scrum (u otra metodología ágil), a continuación te dejamos una página con muy buenos videos que te ayudarán a introducirte en las metodologías ágiles.

http://scrummethodology.com/

 

Así que sigues usando cascada…

Docker es el futuro!

dockerDocker es una tecnología que nos permite utilizar un sistema de archivos completo en lo que lo creadores llaman “contenedores”, de esta forma se pueden ejecutar programas, herramientas del sistema, librerías y otros.

Instalar Docker es muy sencillo y la página cuenta con muy buena documentación de como hacerlo. En Evolbit usamos docker-compose (evolución de lo que en algún momento fue Fig) para facilitar la configuración de los contenedores. Docker compose también es súper útil para separar la configuración para diferentes entornos ya que permite especificar el archivo de configuración.

Con Docker podemos olvidarnos de las configuración en el servidor, solo basta que el servidor de producción tenga Docker instalado y el software podrá ser instalado con unos cuantos comandos (muy fácil). Además, el uso de Docker trae la ventaja de que el equipo de desarrollo trabaja en el mismo entorno usando los contenedores de Docker.

Para quienes no conocen Docker les recomendamos que empiecen a revisar la documentación de Docker y Docker compose.

Docker

https://docs.docker.com

Docker Compose

https://docs.docker.com/compose/

Docker es el futuro!