About GraphQL GraphQL has been invented by Facebook for the purpose of refactoring their mobile application. Facebook had reached the limits of the standard REST API mainly because: Getting that much information was requiring a huge amount of API endpoints The versioning of the API was counter-productive regarding Facebook’s frequents deployements. But graphql is not only a query language related to Facebook. GraphQL is not only applicable to social data.

For a change, I will start with a good soundtrack (youtube version for those who are spotify-less) This is my third article about the distributed coordination language Linda. The final target of the work is to use this coordination mechanism to deploy and maintain applications based on the description of their topology (using, for example, TOSCA as a DSL). Last time, I introduced a lisp based language (zygomys) as an embedded programing mechanism to describe the business logic.

In this post I will explain how to: Parse a CSV file and extract only certain columns Create a table in DynamoDB Insert all the data with an adaptive algorithm in order to use the provisioned capacity Reduce the capacity once the insertion is done. Exploring the problem: AWS Billing In a previous post I explained how I was using dynamodb to store a lot of data about aws billing.

The title is not a typo nor dyslexia. I will really talk about Lisp. In a previous post I explained my will to implement the dining of the philosophers with Linda in GO. The ultimate goal is to use a distributed and abstract language to go straight from the design to the runtime of an application. The problem I’ve faced I want to use a GO implementation for the Linda language because a go binary is a container by itself.

The hand is the tool of tools - Aristotle. It ain’t no secret to anyone actually knowing me: I am a fan of automation. Automation and configuration management have come a long way since Mark Burgess wrote the first version of cfengine. But even if the landscape has changed, operators are still scripting (only the DSL has changed), and the area targeted by those scripts remains technical. There is no real abstraction nor automation of a design.

The more I work with AWS, the more I understand their models. This goes far beyond the technical principles of micro service. As an example I recently had an opportunity to dig a bit into the billing process. I had an explanation given by a colleague whose understanding was more advanced than mine. In his explanation, he mentioned this blog post: New price list API. Understanding the model By reading this post and this explanation, I understand that the offers are categorized in families (eg AmazonS3) and that an offer is composed of a set of products.

It’s been a while since I last posted something. I will fill the gap with a quick post about rekognition. rekognition is a service from AWS that is described as: Deep learning-based image recognition Search, verify, and organize millions of images In this light post, I will present a simple method to grab a picture from my webcam, send it to rekognition and display the result. The part of the result I will focus on is the emotion.