SCADA, a full mini example

We are going to see how to make a mini SCADA, with a flask app running and simulating a system. Let's see the templates:


Let's see the main app in the client:


And in the server:


Now, finally, the flask app:


In the next posts I am going to explain certain aspects. It's not perfect, just a mini SCADA.

SCADA: basic percentage

Hi everyone, today we are going to create a widget for a project that I have in mind, a SCADA made with Meteor.

So we are going to see a widget that is a basic percentage, which color is green if it's minus 50%, and red in other case.

Let's see the code. how to use:


the template:

the helpers:

and the main.coffee


Now is suficient with update the element in the collection with a new value, and you will see the change. It's easy, is a super simple percentage bar.

xwidgets: xboolean

We are going to see how to make a widget (a boolean) that plays nicely with AutoForm. In this case it's a circle of color red (false) or green (true). Let's see the code, in first place the template:


And now the coffee file:

And you can see how to use from AutoForm:


- o - O - o -

I've been making changes to the code, so take a look at github.

autoform-extension

He publicado en atmosphere el smart package autoform-extension.

Este paquete me gusta mucho porque te permite usar typeahead para campos con autocompletado, ya sea éste referencial o no.

Es decir, podemos tener un campo authorId que apunta al _id de la colección authors, y typeahead puede mostrar el campo fullName en su lugar.

Otra opción es simplemente autocompletado. En ambos casos la fuente de datos de typeahead es un método remoto en la parte servidor de Meteor.

Por otro lado, también se encarga de formatear los dates, datetimes y times.

code-permissions

Ya he publicado en Atmosphere el paquete code-permission, que se suma a sym-i18n. Y espero que sean más. De momento una lectura pendiente.

boilerplate

Ya he liberado un boilerplate para Meteor. Tiene montones de ejemplos y ésta es la lista completa de paquetes incluidos:

standard-app-packages
autoform
accounts-ui
accounts-password
coffeescript
iron-router
typeahead
bootstrap-3
collection2
moment
publish-composite
collection-hooks
code-permissions
bootstrap3-datetimepicker
bootboxjs
less
sym-i18n
collection-helpers
browser-policy
simple-schema


Recordad, no clonéis, sino que debéis bajaros el zip y descomprimirlo en un lugar cualquiera. Entonces haced:

mrt install
meteor

i18n

Este va a ser un tutorial supersimple sobre como crearnos nuestro propio sistema de traducciones y pluralizaciones.

Lo primero, visible para ambos lados cliente y servidor, la siguiente colección:


En el servidor la publicación para un lenguage dado:


Y en el cliente registramos un helper i18n que será utilizado desde el html:


El template html:


- o - O - o -

Registrar un helper es crear una función que pueda ser llamada desde los templates, y pasándole argumentos. En este caso i18n es una función que recibe un tag (clave para buscar una traducción concreta) y un hash con el resto de parámetros. Hay un parámetro especial que es count. Se utiliza para afinar en la búsqueda de la traducción, pues no es lo mismo decir "no hay manzanas" que "hay 13 manzanas".

En el git tenéis más información al respecto.

Un café con leche

Vamos a ver un ejemplo al que he llamado cowboy-coding. Lo puedes clonar desde el repositorio.
 La estructura de ficheros es como sigue:
 .
├── client
│   ├── index.html
│   └── main.coffee
├── lib
│   └── collection.coffee
├── server
│   └── publications.coffee
├── smart.json
└── smart.lock

Y pasamos a explicar cada cosa. Lo primero es que aquello que está bajo la carpeta client se empaqueta y se manda al cliente. Al servidor por el contrario se le enviará un paquete con todo aquello bajo la carpeta server. Lo que está en la carpeta lib se manda a ambos: aquí es donde se pondrá todo el código que debe ser visible para ambos lados, como las colecciones de datos o las funciones de validación de un objeto, que debe ser validado tanto en el cliente como en el lado del servidor.

Veamos el fichero collection.coffee:

Se ejecuta tanto en el lado del cliente como en el servidor. En el cliente se trata de objetos proxy (minimongo) que redirigen las llamadas al servidor, el cuál ya insertará los datos en BDD. Meteor se basa en el concepto de latency compensation, que significa que en el lado del cliente, por ejemplo, se acepta el insert y se pinta en pantalla antes de tener noticia desde el servidor que efectivamente ha sido exitoso el insert. En las raras ocasiones en que no lo es, simplemente el sistema de renderizado del template ya no hace visible al objeto (se elimina de minimongo por supuesto).

Continuamos con el servidor, publications.coffee:

En el lado del servidor especificamos un sistema simple de permisos (lo podemos hacer más granular; ese es el propósito de mi paquete code-permissions) y las publicaciones de datos. En este caso permitimos a los clientes subscribirse a una publicación de todos los items que comienzan por la letra que se especifique. Así, si el cliente A se subscribe a los items que comienzan por la letra 'a', y el cliente B inserta un nuevo item que comienza por esa letra, el cliente A verá inmediatamente el nuevo item.

Veamos pues el lado del cliente:

y:

En el lado del cliente hay que filtrar de nuevo por los items que comienzan por la letra subscrita (en lugar de hacer items.find({}) ). Esto es debido a que si estamos subscritos a otra publicación (por ejemplo los que terminan por otra letra), si no hacemos el filtro en el lado del cliente, se pintarán en pantalla todos los items que están en el minimongo del cliente.

un café solo

Un café en la Luna pretende ser un rincón de encuentro para hispanohablantes de programación en Meteor y Coffeescript.

Si tuviéramos que definir en una palabra a Meteor, ésta sería reactivo. Una celda de una hoja excel es reactiva, ya que se autocalcula cada vez que una de las celdas de que depende cambia.

En nuestro caso, la pantalla (templates) se actualizan automáticamente cada vez que el modelo cambia. Esto ya lo hacen Ember o AngularJS, por ejemplo, pero Meteor va más allá, ya que gracias a sus colecciones Mongodb, la persistencia también es automática. Ember y AngularJS se acercan a esto mediante el uso de REST, pero no lo alcanzan. Y ya aquello por lo que Meteor brilla indiscutiblemente es el patrón observador extendido a tantos dispositivos como se quiera, por lo que cuando el modelo cambia, todos los templates de los dispositivos interesados se actualizan.

Las tecnologías usadas son:

• javascript, coffeescript
• handlebars (templates), html, css, less
• mongodb

 En el siguiente post veremos un ejemplo sencillo, en la forma que yo llamo cowboy coding, ya que también veremos que hay formas más elegantes de programar en Meteor.