Headless CMSs are becoming quite popular and make up one of the important ingredients of a JAMstack site. At SuprNation we have been tinkering with headless CMSs for quite a while and we have succesfully implemented one using Wordpress (WP), Advanced Custom Fields (ACF) and ACF-to-Rest API in one of our experiments. This trio can be used to implement a cheap and flexible headless CMS but as anyone who has worked with ACF knows, retrieving the underlying data can be slow if one relies on the current WP plugins. In this post I am going to describe how we have overcome this problem and introduce our open source initiative that drastically reduces the number of queries and round trips to the database.
The original definition of Actors by Hewitt, Bishop and Steiger stated that i) everything is an actor ii) actors have their own memory and iii) actors communicate by sending and receiving messages asynchronously. When responding to messages an actor can i) send a finite number of messages ii) create a finite number of actors, and iii) designate new behaviour. Designating behaviour in Akka is done through the
unbecome primitives. Although these primitives are adequate for systems with a small number of states, state management in large systems requires a higher level of abstraction. One of the abstractions used to control states is the Akka FSM Mixin. In this post we will describe how to use the Akka FSM Mixin through a classic Akka example - the Wire Transfer example. We will also extend this example to show how one can implement At Most Once semantics.
A router is a software component responsible for creating, activating, deactivating and destroying component sub-trees. A specific subset of components selected at a certain point in time is called a router state and hence one can think of a router as a software component which synchronises the router state with what the user sees on screen (my tongue hurts!). All possible router states are configured statically at configuration time. At this stage a URL pattern is supplied to the router together with a declaration of the desired router state. This approach works for the majority of cases however there are times when we would like to specify the URL pattern associated with a state declaration at runtime rather than statically. Supporting multilingual routes is one such example.
Here is a simple fact: the free lunch is over. CPUs aren’t getting any faster but rather they are getting wider. Nowadays we can find multiple execution cores within one chip with shared memory or virtual cores sharing a single physical execution core however CPU’s aren’t doubling in speed. What this means is that concurrency is inevitable and we have to adapt to this new programming landscape in order to create event-driven, scalable, resilient and (hence) responsive programs. In this blog we are going to introduce the Actor Model and create a Crawl Server using Akka and Scala to piece everything together.
Programming languages have evolved largely through a series of abstractions; these abstractions mostly deal with control (e.g. functions) or data. In the post, Houses, Arrays and Higher Order Functions, we have focused on the use of functions as control elements and have delved into the concept of higher order functions. Today we will revisit functions and focus on their use as data elements. Using functions to represent data might seem pretty counter intuitive at first but this blurred line between functions as control elements and functions as data elements is a powerful concept.
It has been quite a while since my last post; things have been pretty busy in preparation for the launch of our new product VoodooDreams. Now that we have shipped our baby, I am super eager to try out Kotlin - a new programming language from JetBrains targeting the JVM. One interesting aspect about Kotlin (similar to Scala and other JVM-based languages) is that it treats functions as first class citizens (IMO Functional Interfaces just patch the gap). In order to try out this language we will create a Decision Tree Learning algorithm which is one of the most used and practical methods for learning inductive inference.
One of the advantages of using TypeScript is that it augments ES6 with type information and annotations. When using JSON, data might not be represented using camelCase notation and hence one cannot simply typecast a JSON object directly onto a TypeScript “typed” object. Traditionally one would solve this problem by creating custom mappers for all the data objects. In this post we will create a generic custom mapper which automates this process by using declarative annotations on Typescript objects. Finally we will package this custom mapper in a class which can be used directly from Angular to handle conversion of JSON objects to “typed” objects.
AngularJS is a great framework to consider when developing Single Page Applications however, as the displayed datasets grow in size, the application response times deteriorate quickly. In this post I will go through a number of techniques which can be used to tackle these performance problems and I will suggest a new technique to solve this problem. So let’s get started.
In our previous post we have described the general process of training an N-Gram language detector. If you have not yet read the post describing the general technique I suggest that you have a look at that first. In this post we will go through the implementation details and creation of a simple language detector using Node. To keep this post concise I will set the language detection parameters - top n-grams to select and n-gram length - manually. In a future post I will show you how to optimise the selection of these parameters by splitting the dataset into three parts; training, validation and test.
At SuprNation we have been using Docker for quite a while now. Docker has been an amazing tool in our arsenal - it has enabled us to package and deploy microservices without having to worry about inconsistencies (library, servers, OS) between live, staging and dev environments. In this post we will create a simple Java/Spring application, container-ise it using Docker, and deploy it on Google Cloud Platform using Kubernetes.
Modules are normally divided into two parts: i) Authoring which loosely refers to how one can export and import modules and ii) Loading which defines how a module is loaded under each environment (e.g. Node vs Browser). Initially ES6 Harmony included both aspects within the specification but in 2014 the loader specification was removed from the spec. WHATWG, has filled in this gap by creating a loader spec API. But why should we care about this today? - because of SystemJS. SystemJS is a universal module loader which is based on the WHATWG loader spec (through the ES6 Loader polyfill). Using SystemJS in our application relieves us from having to choose between today’s popular module formats (AMD, CommonJS and globals) and allows us to load multiple module formats within the same application. In this post we will create global modules from scratch and basic CommonJS and AMD loaders. In a future post we will see how these module formats can be universally loaded through SystemJS.
At SuprNation we are using Slack as our primary communication tool. Slack is great, it has great search capabilities, allows rich messaging and most of all is able to integrate with other software components e.g. integrate Jenkins to post build updates to a slack channel. In this post we will integrate Slack with Hubot. Hubot is a virtual bot which will login to slack and provide some awesome and fun features e.g. automate deployment, language translation, integration with Google Maps, react to comments by posting an image from Imgr and so on. There are various scripts which you can add-on to hubot but the fun really starts when you create your own scripts to automate some of your own processes. Apart from our Slack integration with Hubot we will also create a plugin which integrates with GitHub to illustrate this idea.
In the previous post we made use of higher order functions to generalise the summation function. Using HOFs we managed to implement a solution that was much simpler - as defined by Rich Hickey over here - than its iterative (and less evolved) cousin. In this post we are going to apply the same technique on arrays and apply this on a dataset of house prices. Who knows maybe this techniques will help you find your dream home!