rutha - past, present and what's next

Origins

The fact that rutha is based in Hapi and Angular is a weird story. A while ago I worked for Admios who back then had a outsourcing service to a Santa Barbara cloud computing brokerage startup (or a grown up one at least).

The fashion trends back then was Backbone, so we build from zero to one a whole framework using Backbone, Underscore and Grunt, with Bootstrap as CSS theme and NodeJS running the boilerplate.

I had probably the best time building and using all these new things. Then Angular showed up. 

Don't you call this a regular jam

I'm gonna rock this land

I'm gonna take this itty bitty world by storm

And I'm just getting warm

 - Mama Said Knock You Out - LL Cool J

Being this a team focused on value, we might had tried to sell our boilerplate with workshops or presentations. But Angular was being supported by Google and in the end time to market is the rule in most places.

By the end of outsourcing gig, our 2 years tech baby was already "legacy".

One of the engineers went to another place and we tried to get the code open source but it never got traction. At least we tried.

In the meantime, I started using Express and Angular to learn what the fuss was all about. I think I figure out I needed a mentor so I asked my good friend Edgar to teach me. It worked. And it was like taking the pill to the rabbit hole.

Ah roomie zoom zim, I'm off to be wed

To Rhymealinda I remember umm, when we first met

In eighty-two back in school used to play up all the fools

 - 4 better or 4 worse - The Pharcyde

And I kind of disliked Express. It was like Sinatra all over again, spend time finding out good, community supported gems to get a good, web boilerplate. Somehow I stumble upon Hapi and remembered my good old days of ASP.NET. Comparing what I'd in Express vs what (in theory) could be accomplished, I was stuck. And the journey to rule them all Hapi and Angular began.

Present

With 100 commits and version stuck at 1.0.0, we have over 20 likes and over 300 page views, I can say the idea that started around August 2014 has worked. Currently, we have 3 projects using it and hopefully more. Our time to market has been reduced and developers can focus on Hapi and Angular and forget about tooling.

What's Next

Our roadmap will focus on pragmatism over bleeding edge patterns and trends, with two exceptions: ES6 and Angular 2.

Things we are considering and would like feedback

• Client side modules: We might moved to all npm, it depends on how easy is to get ES6 with angular.
• API CLI: For Hapi APIs, is something I see useful.
• John Papa/Todd Motto ng conventions CLI
• Sample apps
• Mobile First: Is very likely we'll take a NativeScript or Kendo UI Mobile approach. 

Thanks

Rogelio Morrell and rutha team

AngularJS - Por que es AngularJS tan complejo ?

Introducción

Hace unos dias conversaba con un amigo sobre AngularJS y la razon de su complejidad. En si no es complejo del todo, tiene que ver mas bien con previas experiencias que el equipo de AngularJS obtuvo en proyectos anteriores (por ejemplo Google Closure, quizas GWT). Pero mis puntos claves que he descubierto son los siguientes.

Tiempo de curva de aprendizaje vs tiempo al mercado

Yo estuve en un proyecto de 24 a 28 meses usando Backbone, jQuery y Bootstrap. Al principio seguiamos todos los patrones y mejores practicas. El codigo era escalable. Pero fallamos en varios aspectos que a continuacion describo:

Entrenamiento y divulgacion interna

Eramos malos documentando el API recien creado. Otros equipos encontraron dificultad en adaptarse.

Obsolesencia

A los seis meses, el mismo Backbone de nuestro framework nunca lo actualizamos.

Tiempo al mercado (Time to Market)

Cuando finalmente llego AngularJS al cliente, la entrega de los otros equipos de algun modo era mas rapida que la nuestra. Seguramente porque evitaron el sindrome NIH (Not Invented Here).

La curva

Obsolesencia y divulgacion son dos puntos claves. Pero no explica por si solo el "Time to Market". Es aqui la diferencia de "Angular Way" vs tu framework con librerias. AngularJS "normaliza" el conocimiento, al tener directivas como la forma para interactuar con jQuery y factorias/servicios como la forma de creacion de objetos. Esto permite desarrollar sumamente rapido con los mismos conceptos entre equipos. De tal modo que con 100 horas (casi un mes solo en Angular) obtienes un conocimiento intermedio al que obtendrias con la misma cantidad que con Backbone, jQuery y todo lo relacionado (templates, grunt, requirejs, stickit, marionette, thorax, etc)

La curva de aprendizaje siempre va ser importante como tambien el time to market. Yo lo veo como un Ying Yang. Hay un balance entre estos dos.

Realmente debo usar AngularJS para todo emprendimiento?

La respuesta es facil, todo va depender de tu escenario, en las habilidades de tu equipo, el presupuesto y la crema, que tanto "edgy" o en boga quieran usar tecnologia innovadora (Polymer WebComponents, ES6 transpiler, ClojureScript/Om)

En las siguientes entregas tocare brevemente el tema del empleo y los informales, despues continuo con mas AngularJS y posteriormente un poco de HapiJS y Joi

Hasta la siguiente entrega

AngularJS - Validaciones de formularios #1

Introducción

En este articulo explicamos brevemente ciertas cualidades de AngularJS 1.3.x

Validar debería ser fácil con Angular

Sin embargo, hay flujos de validaciones que no son soportados, por ejemplo:

• Cargar formulario con campos "required": En Angular, siempre son mostrados. No hay forma sencilla de decirle después que salga del foco.
• Validaciones cuando haces clic el botón de submit o un botón cualquiera.

Usando Angular 1.3 ngMessages

Yearofmoo describe ngMessages de una manera correcta. Lo esencial es que ngMessages lee el $error del campo (ejemplo form.campo.$error) y toma el primer key/value y presenta este error en caso de estar activo.

Lo cual funciona de perfectamente bien. Hasta que queremos resolver los dos casos extremos mencionados (que en Backbone son fáciles de implementar ciertamente).

Caso #1 - Solo debe mostrarme requerido al perder el foco

Mi solución rudimentaria fue usar un combo de ng-blur y ng-change, mantener el required message en el conjunto de ng-messages y tener una simple función en el controller. Esto se puede mejorar mucho mas con un Angular Directive.

Ahora, al cargar el formulario, solo se muestra requerido al perder el foco (blur). Lo bueno de esto es que reusamos ngMessages tal como esta.

En la próxima entrega explicaremos como resolver el Caso #2 con el submit.

Correciones: En vez de setear invalid = true, debe usarse $setValidity

Hasta la siguiente entrega
Rogelio Morrell

HapiJS - View Partials con UnderscoreJS

Introducción

En este articulo explicamos el uso de "view partials" o vistas parciales, que son en esencia pedazos de HTML.

Para que usamos parciales

Son utiles cuando tienes una plantilla maestra (master template) y quieres por ejemplo generar la barra de navegacion que contiene el enlace de perfil de usuario.

Configurando parciales en HapiJS

En la variable partialsPath se agrega donde residen las plantillas parciales.

Usando parciales con Underscore

Por medio de server.render logramos obtener el parcial generado. Estoy pensando en que seria posible precargar los parciales y posteriormente sean accedidos para ser usados, como un tipo de precompilacion. Otra forma es usar promises para cuando se requieran generar mas de un partial y usarlos en una vista.

Usando LoDash

Con LoDash debe funcionar igualmente y podriamos usar el imports para los parciales precargados. De tal modo que se podria llamar a la funcion desde la plantilla, en vez de enviar el HTML como otra variable a la plantilla maestra. Esta tarea se la dejo a los seguidores del blog para que investiguen.

Hasta la siguiente entrega
Rogelio Morrell

HapiJS - Autenticacion REST con hapi-auth-bearer-token plugin

Introducción

En este articulo explicamos el uso de Bearer token plugin para HapiJS.

API  publico o privado?

Un REST API recurso puede ser privado si por medio de routing lo podemos crear  de uso exclusivo para una aplicacion de server. En este caso cada llamado debe ser de HapiJS UI server page a REST API. Dado que Rutha utiliza ambos, y nuestra aplicacion es un SPA (Single  Page Application), la opcion de API privado no es factible. En este caso optamos por utilizar autenticacion a nivel de REST.

Modelo ideal segun Twitter de autenticacion 'Application Only'

Segun Twitter, son tres pasos que se requieren:

• Una aplicacion codifica la llave y secreto del usuario (consumer key and secret) en un set de credenciales. Esto es lo que adquieres en la mayoria de los OAuth APIs y el cual debes incluir en tus aplicaciones.
• Una aplicacion crea una llamada POST a un recurso o 'endpoint' OAuth2/token para intercambio de token (bearer token o token al portador).
• Para acceder al API REST, la aplicacion utiliza el token al portador para autenticar.

Usando HapiJS

En este ejemplo no explicaremos completame el flujo, solo nos enfocamos en el punto #3, en donde autenticamos llamados al API REST. El punto 1 y 2 para aplicaciones no publicas como Twitter, es posible con la autenticacion del usuario generar un token al portador permitiendo al usuario acceder el API REST que requiere ser autenticado.

En el bootloader de HapiJS

Registramos el plugin de 'hapi-auth-bearer-token' y la estrategia con validateFunc, que contiene la logica del token. Esto se puede reemplazar por un datastore en Redis o MongoDB que almacene la sesion, o algun otro metodo criptografico.

Rutas

En las rutas, toda ruta que requiera previa autenticacion, le asignamos en config.auth el nombre de la estrategia a utilizar.

Consumidor del API

Finalmente, en el cliente nos aseguramos de enviar el header de autorizacion con el token al portador.


Hasta la siguiente entrega
Rogelio Morrell

Rutha Stack - Ambiente de desarrollo web con AngularJS y HapiJS (y como no reinventar la rueda)

Introducción

Iniciar a desarrollar aplicaciones front end, ya sea Angular, Backbone, Ember y otras requiere de lo que llamamos un 'developer workflow' o 'stack'. Hay diversos stacks como MEAN y generadores como Yeoman, inclusive otros Github repos como Angular-Seed. Yo buscaba algo que tuviera tanto HapiJS y AngularJS. Y no encontré algo existente. De este modo surgió "Rule Them All HapiJS AngularJS" o Rutha.

Reinventar la rueda?

Mis requerimientos para un stack ideal con lo cual Rutha contiene:

A nivel de server

REST

Debe solo enfocarse en REST y tener validación de usuarios, validación de cada REST route y tener health check. Con HapiJS Joi y hapi-auth-bearer esto es posible.

Módulos

HapiJS soporta plugins, lo cual se basan en npm.

Documentación

El API debe ser capaz de documentarse. Usando HapiJS Joi, el modulo de HapiJS Lout auto genera la documentación.

Test Driven Development con Jasmine 2.0

Por medio de server.inject de HapiJS, integramos Jasmine 2.0 y obtenemos uno de los mejores TDD engine en el mercado. Porque no HapiJS Lab? Simplemente necesitaba Jasmine 2.0. Lab todavía no utiliza la ultima versión de Jasmine.

Errores predeterminados

HapiJS tiene incluido una forma de errores predeterminados que siguen la definición HTTP. No mas json generados a manos.

A nivel de UI

Mismo ambiente de desarrollo que en producción

Puedo asumir que esto es lo mas revolucionario. En modo de desarrollo, empaquetamos todos los activos o 'assets' en la carpeta 'dist' (o la puedes cambiar a tu nombre preferido) con la excepción de minificacion. En modo de producción, ocurre el mismo proceso incluyendo en este caso la minificacion. A continuación los procesos que ocurren.

Generación por medio de ngTemplates

Compacta los templates de AngularJS dentro de funciones Javascript.

Concatenación

Todo el contenido de javascript se concatena y se crean dos archivos: app.js y templates.js

Generación de anotaciones de los módulos de Angular con ngAnnotate

Los módulos de Angular necesitan anotación antes de la minificacion para evitar problemas con la ofuscación.

Uglify (conocido como minificacion que es  una forma de ofuscar el código)

En modo de desarrollo, solo genera el sourcemap del código para permitir depuración. En modo de producción, permite sourcemap y minificacion. El sourcemap no se distribuye como tal a la hora de publicación.

Enlazar con el HTML de inicio

Se enlaza y renueva referencias basadas en la configuración de Bower. Esto permite siempre tener los módulos utilizados enlazados al HTML de desarrollo en el SPA (Single Page Application).

BrowserSync

Tanto como LiveReload y fb-flo me parecieron complicado configurar. BrowserSync fue super sencillo. Esto permite que cada cambio en tu editor (Vim, Sublime, etc) sea refrescado automáticamente en tu browser preferido.

Otras tecnologías

Grunt JIT realiza precompilacion o precargado de ciertos pasos de Grunt, lo cual ejecutar los grunt tasks sean mas rápido que antes.

Adoptamos el modelo de 'dev stack' con código de demostración. Esto es la clave y lo herede de la época de .NET y VS.NET.

De tal modo, usamos una variación de patrones de AngularSeed, PacktPub Mastering Web Application Development with AngularJS y la guía de estilo o patrones de AngularJS por Todd Motto.

Que vendrá a continuación

Tengo un conjunto de cosas que agregar, pueden esperar el siguiente roadmap:

• 0.2.x:
• Patrones de HapiJS para Autenticación de UI y API
• 0.3.x:
• Definir si nos vamos con Restangular o angular-restmod

• CSS (LESS O SCSS), esto necesitare tiempo y ayuda. Se aceptan contribuciones.
• 0.4.x:
• Instanbul para code coverage
• 0.5.x:
• Abierto a ideas. Puede ser desde generadores hasta soporte a React en el server. Pero seguramente sean rutha-contrib-* modulos y no parte del main branch.

Hasta la siguiente entrega

Rogelio Morrell