My take on Time Series Database requirements

Some time ago, doing some research related to my current work, i stumble upon this excellent article by Baron Schwartz on the topic of Time Series Database requirements. This article is in my opinion the best thing on my reading list for that subject and in this post i will try to expose my own take on this matter building on top of it. Definition of Data Type Baron identify series using two elements: source identifier and metric identifier. I have seem this used on existing products, but from my perspective this is needed for organization purposes and not for series identification. For me the only hard requirement on this matter is that series can be uniquely identified. Therefore a single series identifier is sufficient. You can always provide organization using some kind of namespacing over identifiers (consider the following identifiers “source1.metric1” and “source1.metric2”) or using an independent component to build the relations between series and other elements (groups, asset…

Mi aproximación al diseño de APIs RESTful

El diseño de APIs siguiendo el estilo arquitectónico REST es tema de debate constante en la red. Existen innumerables publicaciones sobre el tema tanto post personales como artículos respaldados por organizaciones. Separar la paja del grano en este tema es difícil dado que la fuente canónica de información son documentos académicos. Me encantaría leer algo mas aterrizado a la práctica del mismo Roy Fielding pero respeto su compromiso con la comunidad y su incansable trabajo en los procesos de estandarización. En este post voy a compartir con ustedes mi propia aproximación al problema. La parte en negritas sería la descripción necesaria de la API.

El caso de estudio para este post será la clásica aplicación de Cosas Por Hacer.

Lo primero es modelar el recurso Cosa Por Hacer o Todo como se le conoce en Ingles. Aquí vamos a asumir que es algo tan simple como que tiene 2 atributos: el titulo y la bandera de completado.

Lo segundo sería identificar las acciones y el posible flujo del usuar…

Concurrent Alarms Processing

Currently I am working on a development project of a Control System and am faced with the task of massive event processing of measurements for signaling alarm conditions (alarms that are activated when a certain value becomes above or below a certain level, etc.). This control system notifies the alarm processing component each of the measured variables (tags) and the component ​​must update the state machine of each of the alarms set in the control system. The problem I face is that we want the system as a whole to be scalable (we need to resize depending on the load to which it is submitted) and therefore in some scenarios the number of notifications to the component of alarm processing is such that exceeds its handling capacity so it is impossible for a single computing entity (task or process) of performing real-time processing. Given this scenario, I raised the possibility of horizontally scale the alarms processing component.
But the problem of scaling alarm  processing componen…

My worst programming mistake

Some months ago i become member of a small organization working on the development of a new product and i was charged with the responsibility of developing the front end Web site for that with some degree of freedom to chose the technology to use for that purpose. The biggest challenge on the product development effort was the use by the first time (for everyone on the team) of a Big Data store to address a project requirement. I start working on the low level user management features (authentication and authorization services, etc.) and once i have a functional prototype (backed by a SQL database because user related data will never be Big Data in our case) the general project manager make me change the SQL store by the Big Data store selected to be used on the project (Cassandra) based on the idea of speed the adoption of the last.
That was my first days as member of the organization and not fighting that decision of the manager is the worst mistake i have done on my time as develop…