Generar Servicios RESTful a partir de Modelos de Datos

Al momento de desarrollar aplicaciones, casi siempre el punto de partida es la creacion del modelo de datos (y la base de datos). Una vez que tenemos un hogar para nuestras data, el siguiente paso natural es querer generar servicios RESTful para que sean consumidos por nuestras aplicaciones clientes; bien sea un website o un app móvil.

Es entonces cuando nos encontramos con muchísimas opciones para el desarrollo de nuestros servicios. Plataformas, tecnologías, lenguajes de programación, entre otros. Sin duda alguna, puede ser complicado y tardado el comenzar a desarrollar nuestras API’s. En este post trato de comentar mi experiencia con diferentes servicios de generación automática de servicios REST.

Pero primero un disclaimer: Ningún generador nos va a proveer de servicios perfectamente personalizado y según las necesidades particulares. La idea es darnos un comienzo rápido con las conexiones a la BD, el manejo de rutas y la selección de datos de nuestras tablas. Esto quiere decir que las uniones y transformaciones de datos quedan de nuestra parte.

Sin mas preambulos, les dejo las opciones que he probado:

Apiplug: Apiplug es un SAAS (Software Como Servicio) que ofrece la generacion de API’s partiendo de un esquema definido o una BD existente, por un precio. Las opciones de tecnologías justo ahora varían entre PHP5+Laravel5.1, PHP7+Laravel5.2, NodeJS+Express y Python3+Django. Tambien ofrecen ayuda para desplegar los proyectos y como extra, puedes generar un proyecto Android que haga uso de tu recién generado API.

Dashboard de Apiplug
Dashboard de Apiplug

Apigility: Apigility es un proyecto de Zend Framework que debes correr en una intancia de WAMP/XAMPP antes de que puedas llegar a las pantallas de generacion. Una vez allí, ofrece exactamente lo requerido con muy buenas posibilidades de personalización. EL detalle: Naturalmente, el proyecto generado es exclusivamente en PHP.

En futuras actualizaciones, agregare un par de opciones mas a la lista.

Big Data: El ecosistema básico en las empresas.

Es bien sabido que en la actualidad, cuando hablamos de Big Data, no nos referimos a una sola herramienta (aunque a muchos nos venga el nombre ‘Hadoop’ a la mente). En este corto post, listo algunas de las herramientas mas básicas y comunes en despliegues empresariales de soluciones Big Data:

El Stack de una solución Big Data clásica. (Sin Spark).
El Stack de una solución Big Data clásica. (Sin Spark).

El ecosistema básico

  • Hadoop: La herramienta base de cualquier solución Big Data. Fundamentado en el procesamiento paralelo usando una tecnica llamada ‘Map-Reduce’ y un sistema de archivos distribuidos denominado ‘Hadoop File-System (HDFS)’. El origen de su nombre es todo un misterio…
  • Hive: Desarrollado en Facebook para facilitar la tarea de programar tareas Map-Reduce para hacer consultas en Hadoop. Permite consultar la data usando HQL (ANSI SQL con algunas modificaciones). De esta manera, se disminuye la dificultad al obtener resultados de la data.
  • Sqoop: Permite realizar tareas de importación de datos desde diversas bases de datos relacionales, encargándose de la conversión tipos de datos y de las transformaciones que sean necesarias.
  • Spark: Desarrollado para superar las deficiencias de Map-Reduce, Spark ofrece resultados mucho mas rápidos usando el mismo cluster que Hadoop. Su mayor ventaja es que el procesamiento es en la memoria y no en el disco. Ademas, tiene sus propios módulos de SQL e Inteligencia Artificial.

Para conocer un poco mas de la historia y evolución de estas herramientas, recomiendo el siguiente articulo: https://medium.com/@markobonaci/the-history-of-hadoop

Programación funcional vs procedimental: Un enfoque Big Data.

Recientemente, durante un conversación sobre Big Data, Hadoop y el análisis de data, surgió el tema de los lenguajes funcionales en los mismos. Es bien sabido que los lenguajes funcionales son ideales para Big Data, pero no nos quedaba claro porqué. Buscando un poco, ésta respuesta de SO nos dió más luces al respecto:

As a consequence, a purely functional program always yields the same value for an input, and the order of evaluation is not well-defined; which means that uncertain values like user input or random values are hard to model in purely functional languages.

Podemos resumir en que: Los lenguajes funcionales siempre arrojarán un valor para determinada entrada (La orden de evaluación no está bien definida). Ésto es totalmente deseable para la computación distribuida y el Big Data, puesto que la idea es asegurar una salida consistente en todos los nodos donde se procese.

Para saber un poco más al respecto, les recomiendo ésta lectura.

Por otro lado, recomiendo muchísimo ésta la especialización en SCALA, (un lenguaje funcional que corre en el JVM) dictado por la École Polytechnique Fédérale de Lausanne en Coursera.

Notas de Preparación para el examen de certificación de Linux Foundation

En un Google Hangout con varios candidatos y próximos certificados por la Linux Foundation como «System Administrator», me fue compartida por su autor el siguiente trabajo de recopilación (Podría llamarse manual) de los conocimientos básicos que debe tener quien tome el examen.

Linux Foundation Certified System Administrator (LFCS) [PDF, 900Kb]

Twitter suprimirá las contraseñas de acceso: ¿Cómo entraremos en nuestra cuenta?

 

Twitter Passwords

En la conferencia de desarrolladores en San Francisco, Jeff Seibert, director de plataformas móviles de Twitter, presentó el sistema Digits, que la red social ofrece de forma gratuita en 28 idiomas de 216 países.

El funcionamiento del Digits será sencillo: al introducir el número de móvil asociado a la cuenta, le llega un SMS con un código temporal. Para cada sesión hay que repetir la operación. Los gastos del envío del mensaje corren a cargo de Twitter.

A su juicio, el nuevo sistema es mejor que la combinación actual de un ‘e-mail’, que resulta difícil de teclear en los teléfonos móviles y son más susceptible de pirateo.

«Cada vez más y más, el número de teléfono se convierte en el identificador principal de un individuo en comparación con  la dirección de correo electrónico. En los mercados en desarrollo a menudo es el único identificador, ya que algunos propietarios de teléfonos inteligentes a menudo no tienen direcciones de correo electrónico», anunció Twitter en un comunicado.